I'd really point the finger to faulty hw. Please run all the necessary diagnostic tools for catching it.
Attilio 2011/8/11 Andriy Gapon <[email protected]>: > on 10/08/2011 18:35 Steven Hartland said the following: >> Fatal double fault >> rip = 0xffffffff8052f6f1 >> rsp = 0xffffff86ce600fb0 >> rbp = 0xffffff86ce601210 >> cpuid = 0; apic id = 00 >> panic: double fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff803af91e at kdb_backtrace+0x5e >> #1 0xffffffff8037d817 at panic+0x187 >> #2 0xffffffff80574316 at dblfault_handler+0x96 >> #3 0xffffffff8055d06d at Xdblfault+0xad > [snip] >> #0 sched_switch (td=0xffffffff80830bc0, newtd=0xffffff000a73f8c0, >> flags=Variable >> "flags" is not available.) >> at /usr/src/sys/kern/sched_ule.c:1858 >> 1858 cpuid = PCPU_GET(cpuid); >> (kgdb) >> #0 sched_switch (td=0xffffffff80830bc0, newtd=0xffffff000a73f8c0, >> flags=Variable >> "flags" is not available.) >> at /usr/src/sys/kern/sched_ule.c:1858 >> #1 0xffffffff80385c86 in mi_switch (flags=260, newtd=0x0) >> at /usr/src/sys/kern/kern_synch.c:449 >> #2 0xffffffff803b92d2 in sleepq_timedwait (wchan=0xffffffff80830760, pri=68) >> at /usr/src/sys/kern/subr_sleepqueue.c:644 >> #3 0xffffffff803861e1 in _sleep (ident=0xffffffff80830760, lock=0x0, >> priority=Variable "priority" is not available. >> ) at /usr/src/sys/kern/kern_synch.c:230 >> #4 0xffffffff80532c29 in scheduler (dummy=Variable "dummy" is not available. >> ) at /usr/src/sys/vm/vm_glue.c:807 >> #5 0xffffffff80335d67 in mi_startup () at /usr/src/sys/kern/init_main.c:254 >> #6 0xffffffff8016efac in btext () at /usr/src/sys/amd64/amd64/locore.S:81 >> #7 0xffffffff808556e0 in sleepq_chains () >> #8 0xffffffff8083b1e0 in cpu_top () >> #9 0x0000000000000000 in ?? () >> #10 0xffffffff80830bc0 in proc0 () >> #11 0xffffffff80ba4b90 in ?? () >> #12 0xffffffff80ba4b38 in ?? () >> #13 0xffffff000a73f8c0 in ?? () >> #14 0xffffffff803a2cc9 in sched_switch (td=0x0, newtd=0x0, flags=Variable >> "flags" >> is not available. >> ) >> at /usr/src/sys/kern/sched_ule.c:1852 >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) > > Looks like this is just the first thread in the kernel. > Perhaps 'thread apply all bt' could help to find the culprit. > > -- > Andriy Gapon > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[email protected]" > -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
