FXRSTR: illegal FP MXCSR ffff002f didinit = 0
ejc
eric.j.christeson at gmail.com
Fri Jan 25 12:34:30 PST 2008
On Jan 25, 2008 6:54 AM, ejc <eric.j.christeson at gmail.com> wrote:
>
> On Jan 25, 2008 12:17 AM, Matthew Dillon <dillon at 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
More information about the Bugs
mailing list