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

[Eric van Gyzen]

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.  :-/

Thanks!
Eric

====

panic: arithmetic trap
panic messages:
---
Fatal trap 6: arithmetic trap while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x8:0xc07e07b4
stack pointer           = 0x10:0xd8a08cc8
frame pointer           = 0x10:0xd8a08cc8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 50 (tcsh)
trap number             = 6
panic: arithmetic trap
cpuid = 0; 

syncing disks, buffers remaining...
[snip]

(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     }

(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc0631967 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc0631cde in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc07db60c in trap_fatal (frame=0xd8a08c88, eva=0)
    at /usr/src/sys/i386/i386/trap.c:821
#4  0xc07db062 in trap (frame=
      {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 22,
       tf_ebp = -660566840, tf_isp = -660566860, tf_ebx = 582, tf_edx = 0,
       tf_ecx = 134996160, tf_eax = -660566560, tf_trapno = 6, tf_err = 0,
       tf_eip = -1065482316, tf_cs = 8, tf_eflags = 65606,
       tf_esp = -660566792, tf_ss = -1065482847})
    at /usr/src/sys/i386/i386/trap.c:618
#5  0xc07c8258 in calltrap () at {standard input}:94
#6  0xc07e05a1 in npxdna () at /usr/src/sys/i386/isa/npx.c:840
#7  0xc07dae4a in trap (frame=
      {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077949216,
       tf_esi = 134996208, tf_ebp = -1077949192, tf_isp = -660566668,
       tf_ebx = 2, tf_edx = 134531002, tf_ecx = 134996160, tf_eax = 0,
       tf_trapno = 22, tf_err = 0, tf_eip = 672467452, tf_cs = 31,
       tf_eflags = 66198, tf_esp = -1077949316, tf_ss = 47})
    at /usr/src/sys/i386/i386/trap.c:396
#8  0xc07c8258 in calltrap () at {standard input}:94
---Can't read userspace from dump, or kernel process---

(kgdb) frame 6
#6  0xc07e05a1 in npxdna () at /build/src/sys/i386/isa/npx.c:840
[snip]

(kgdb) list 815,841
815       if ((pcb->pcb_flags & PCB_NPXINITDONE) == 0) {
816               /*
817                * This is the first time this thread has used the FPU or
818                * the PCB doesn't contain a clean FPU state.  Explicitly
819                * initialize the FPU and load the default control word.
820                */
821               fninit();
822               control = __INITIAL_NPXCW__;
823               fldcw(&control);
824               pcb->pcb_flags |= PCB_NPXINITDONE;
825       } else {
826               /*
827                * The following frstor may cause an IRQ13 when the state
828                * being restored has a pending error.  The error will
829                * appear to have been triggered by the current (npx) user
830                * instruction even when that instruction is a no-wait
831                * instruction that should not trigger an error (e.g.,
832                * fnclex).  On at least one 486 system all of the no-wait
833                * instructions are broken the same as frstor, so our
834                * treatment does not amplify the breakage.  On at least
835                * one 386/Cyrix 387 system, fnclex works correctly while
836                * frstor and fnsave are broken, so our treatment breaks
837                * fnclex if it is the first FPU instruction after a context
838                * switch.
839                */
840               fpurstor(&pcb->pcb_save);
841       }