FXRSTR: illegal FP MXCSR ffff002f didinit = 0

[ejc <eric.j.christeson@xxxxxxxxx>]

On Jan 25, 2008 6:54 AM, ejc <eric.j.christeson@gmail.com> wrote:
>
> On Jan 25, 2008 12:17 AM, Matthew Dillon <dillon@apollo.backplane.com> wrote:
> > :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.
>
> I had done the buildworld and was trying to reboot before installworld
> at first.  Then I found the discussion surrounding it and did an
> installworld thinking that would solve the problem.
> My plan is to sync src, full build(world|kernel) and
> install(world|kerenl) to see if that helps.
> One thing I might add is that this system is an Athlon 1Ghz.  I don't
> know if that platform requires any quirks or not.

Still no good.  I deleted /usr/obj and updated to latest -HEAD this
morning, recompiled/installed both world and GENERIC kernel.  Once
again, I took out the SIGFPE so I could run things.  I booted single
user and mounted my fs.  Both fsck and mount caused the error.  Idle
in single-user the error doesn't occur.  Other commands do too, but
some don't or sometimes do.  'ls' is one example.   By itself, it does
not produce the error, but ls -l does.  ls -R does not but ls -lR
does.  dmesg by itself doesn't, but dmesg with an invalid option
(dmesg -v) does.  Hopefully this is helpful.

Eric