Bug #928

FXRSTR: illegal FP MXCSR ffff002f didinit = 0

Added by eric.j.christeson almost 7 years ago. Updated almost 6 years ago.

Status:ClosedStart date:
Priority:UrgentDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I'm getting this error message printed once every 6 seconds to the console.
Every 30 seconds I get:
pid 349 (syslogd) signal return from user: illegal FP MXCSR ffff002f

The messages vary slightly

FXRSTR: illegal FP MXCSR ffff0000 didinit = 1
FXRSTR: illegal FP MXCSR ffff0000 didinit = 0
FXRSTR: illegal FP MXCSR ffff002f didinit = 0

I found this thread:
http://archive.netbsd.se/?ml=dfbsd-bugs&a=2007-12&t=5918415
and it seems related. I commented out the SIGFPE that was being
thrown so I could at least boot the system.

Any ideas? I'm running -HEAD from a couple of days ago and I can't
think of anything that would be linked against libc_r as suggested in
the thread.

Eric

History

#1 Updated by dillon almost 7 years ago

:I'm getting this error message printed once every 6 seconds to the console.
:Every 30 seconds I get:
:pid 349 (syslogd) signal return from user: illegal FP MXCSR ffff002f
:
:The messages vary slightly
:
:FXRSTR: illegal FP MXCSR ffff0000 didinit = 1
:FXRSTR: illegal FP MXCSR ffff0000 didinit = 0
:FXRSTR: illegal FP MXCSR ffff002f didinit = 0
:
:I found this thread:
:http://archive.netbsd.se/?ml=dfbsd-bugs&a=2007-12&t=5918415
:and it seems related. I commented out the SIGFPE that was being
:thrown so I could at least boot the system.
:
:Any ideas? I'm running -HEAD from a couple of days ago and I can't
:think of anything that would be linked against libc_r as suggested in
:the thread.
:
:Eric

Did you do a full buildworld/installworld along with the recent
HEAD ? This problem is related to older versions of the threaded
libc overwriting the signal FP save area with the older fsave
instruction. The kernel then tries to restore it with the newer
fxrstr instruction and generates that output.

This hasn't been a problem in a long time, so I expect your world is
simply out of sync with your kernel.

-Matt
Matthew Dillon
<>

#2 Updated by corecode almost 7 years ago

But init or sh shouldn't use libc_r in the first place, so something else
must be wrong.

cheers
simon

#3 Updated by stevesw over 6 years ago

I have the same message over boot and then system halted:
Mounting root from ufs:/dev/ar0s1a
FXRSTR: illegal FP MXCSR ffff0010 didinit = 1
init: fatal signal: Floating point exception

My HW configuration:
Intel 200 MMX; 2x128 MB RWM; 2x80 GB HDD in mirror RAID, 3xNIC 3com
I'm updateing from lastest HEAD cvs sources (DragonFly 1.11.0-DEVEL).

#4 Updated by swildner almost 6 years ago

Do these problems still occur with current HEAD or can the issue be closed?

#5 Updated by corecode almost 6 years ago

i believe the fp context save code has been fixed

#6 Updated by eric.j.christeson almost 6 years ago

On Thu, Jan 22, 2009 at 5:41 PM, Simon 'corecode' Schubert (via
DragonFly issue tracker) <> wrote:
>
> Simon 'corecode' Schubert <> added the comment:
>
> i believe the fp context save code has been fixed

Yes, I believe that was fixed in HEAD soon after I reported it.

Eric

Also available in: Atom PDF