Re: panic: arithmetic trap in fpurstor() in sys/i386/isa/npx.c

Bruce Evans wrote:
> On Thu, 19 Feb 2004, Eric van Gyzen wrote:
> > I can reliably panic 5.2-RELEASE GENERIC running on three different AMD
> > Athlon CPUs with:
> >
> >   # echo 'q()' | R --no-save
> >
> > R is ports/math/R-letter, and q() just tells R to quit.  This does not
> > happen on an AthlonMP or P3 running the same kernel.  It did not happen
> > on the same three Athlon machines while running 5.1-RELEASE.  Some simple
> > gdb debugging follows.  If you need more info, please ask; I don't debug
> > the kernel very often, so I'm not sure what to provide.  :-/
>
> Try backing out rev.1.216 of vm_machdep.c.  I don't see exactly how this
> commit could cause the problem, but it is the only related thing that has
> changed since 5.1, and the first part of it has several bugs (it is a
> layering violation and is missing explicit disabling of interrupts).

I'll try that and reply later.  (For now, I have to do my /real/ job...)

> > panic: arithmetic trap
> > ...
> > (kgdb) list *0xc07e07b4
> > 0xc07e07b4 is in fpurstor (/usr/src/sys/i386/isa/npx.c:986).
> > [snip]
> >
> > (kgdb) list 976,987
> > 976     static void
> > 977     fpurstor(addr)
> > 978             union savefpu *addr;
> > 979     {
> > 980
> > 981     #ifdef CPU_ENABLE_SSE
> > 982             if (cpu_fxsr)
> > 983                     fxrstor(addr);
> > 984             else
> > 985     #endif
> > 986                     frstor(addr);
> > 987     }
>
> frstror() can only cause an arithmetic trap on broken CPUs.  I doubt
> that Athlons are that broken, so this trap is mysterious.  frstor()
> doesn't even trap for plain i386's; it may cause a bogus IRQ13 which
> the kernel has to be careful not to turn into an arithmetic trap.
>
> Please report the value and contents of addr (about 108 bytes of it
> in hex).

When I try to examine addr, gdb tells me 'No symbol "addr" in current 
context.'  So, I switched to its caller and...

#6  0xc07e05a1 in npxdna () at /build/src/sys/i386/isa/npx.c:840
840                     fpurstor(&pcb->pcb_save);
(kgdb) print &pcb->pcb_save
$4 = (union savefpu *) 0x40
(kgdb) print pcb
$5 = (struct pcb *) 0x0

Ummm...that doesn't look quite right.  Please tell me if I'm missing 
something.

Eric