Daniel Eischen writes:
> > > On further reflection, this DEFINITELY has to do with the work done on
> > > npx(4)/signals/etc. in the past week. I _must_ be getting a GPF because the
> > > fpu state that it's attempting to restore is corrupt (i.e.: the control word
> > > is incorrect), so something is not being initialized somewhere that it used
> > > to be, or is being initialized incorrectly.
> >
> > The last few commits to machdep.c bother me, rev 1.539 in particular.
> >
> > If you are in a position to be able to quickly test it, it would be great
> > to know if backing out the last few changes fixes this, and which change in
> > particular.
>
> There have been two commits since 1.539; what version of machdep.c
> is being used?
1.539 works. 1.540 crashes. The failure mode is:
login: kernel trap 9 with interrupts disabled
Fatal trap 9: general protection fault while in kernel mode
instruction pointer = 0x8:0xc0348eb9
stack pointer = 0x10:0xdbb9d9c8
frame pointer = 0x10:0xdbb9d9c8
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 607 (nautilus)
kernel: type 9 trap, code=0
Stopped at fpurstor+0xf:
db> Context switches not allowed in the debugger.
db> t
fpurstor(dbb9da90,2f,280e002f,dbb9da90,dbb9d9fc) at fpurstor+0xf
npxsetregs(c421a9c0,dbb9da90,200,212,c421a9c0) at npxsetregs+0x34
set_fpcontext(c421a9c0,dbb9da28,2b4,1f,c45a7c08) at set_fpcontext+0xa9
sigreturn(c421a9c0,dbb9dd14,c03a1b89,418,1) at sigreturn+0x1be
syscall(2f,2f,2f,2899e100,0) at syscall+0x294
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (344, FreeBSD ELF32, sigreturn), eip = 0x28c8ca07, esp =
0xbfbfeef0, ebp = 0xbfbfef0c ---
db>
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
