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

From: Eric van Gyzen (vangyzen_at_stat.duke.edu)
Date: 02/19/04

  • Next message: Aaron Peterson: "Re: bcwipe won't wipe a block device..."
    To: freebsd-current@freebsd.org
    Date: Thu, 19 Feb 2004 15:42:54 -0500
    
    

    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       }
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: Aaron Peterson: "Re: bcwipe won't wipe a block device..."