DragonFlyBSD

: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 
                    <dillon@backplane.com>

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

cheers
simon

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).

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

i believe the fp context save code has been fixed

On Thu, Jan 22, 2009 at 5:41 PM, Simon 'corecode' Schubert (via
DragonFly issue tracker) <bugs@crater.dragonflybsd.org> wrote:

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> 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