This is a discussion on double panic, and whats apic_cmd? (kqemu crash...) - FreeBSD ; Ok I finally have an amd64 smp box here that i can play with, and tried to reproduce http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 - and I got the following crash: iapetus# kgdb kernel.debug /var/crash/vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: ...
Ok I finally have an amd64 smp box here that i can play with, and tried
to reproduce http://www.freebsd.org/cgi/query-pr.cgi?pr=113430 - and I got
the following crash:
iapetus# kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x1
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff804e4fa2
stack pointer = 0x10:0xffffffff9fd27530
frame pointer = 0x10:0xffffffff9fd276a0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 43 (acpi_thermal)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x17a
trap_fatal() at trap_fatal+0x29f
trap_pfault() at trap_pfault+0x22d
trap() at trap+0x300
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0xffffffff804e4fa2, rsp = 0xffffffff9fd27530, rbp = 0xffffffff9fd276a0 ---
strlen() at strlen+0x2
dmapbase() at 0xffffff00020e6ca8
Physical memory: 986 MB
Dumping 114 MB: 99 83 67 51 35 19 3
#0 doadump () at pcpu.h:194
194 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
#0 doadump () at pcpu.h:194
#1 0xffffffff8046572f in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0xffffffff80465b47 in panic (fmt=Variable "fmt" is not available.
) at ../../../kern/kern_shutdown.c:563
#3 0xffffffff806bc0bf in trap_fatal (frame=0xc, eva=Variable "eva" is not available.
#4 0xffffffff806bc43d in trap_pfault (frame=0xffffffff9fd27480, usermode=0)
#5 0xffffffff806bcd30 in trap (frame=0xffffffff9fd27480)
#6 0xffffffff806a371e in calltrap () at ../../../amd64/amd64/exception.S:169
#7 0xffffffff804e4fa2 in strlen (str=0x1 )
#8 0xffffffff8048c5f5 in kvprintf (
fmt=0xffffffff807aee73 " while in %s mode\n",
, arg=0xffffffff9fd276b0, radix=10, ap=Variable "ap" is not available.
#9 0xffffff00020e6ca8 in ?? ()
#10 0x0000000000000008 in ?? ()
#11 0x0000000000000153 in ?? ()
#12 0xffffffff807add18 in apic_cmd ()
#13 0x0000000000000000 in ?? ()
#14 0xffffffff9fd27700 in ?? ()
#15 0xffffffff8045c28f in _mtx_lock_flags (m=0xffffffff8049668b,
to continue, or q to quit---
opts=36477624, file=0xffffffff9fd276d0 "", line=-2137032800)
Previous frame inner to this frame (corrupt stack?)
" while in %s mode\n" seems to come from /sys/amd64/amd64/trap.c so it's
a double panic, but what is apic_cmd? And what does one do with a double
For anyone who wants to reproduce it (you need an amd64 smp box, mine
runs 7.0beta2), I installed the qemu-devel port with kqemu selected in
config and then ran it in X like
qemu -cdrom sidux.iso -m 256
, booted its grub, quickly switched to a texconsole, just in time for the
panic (sidux is a linux livecd but I guess almost any guest will do, probably
also a freebsd install iso... and maybe if you don't have X you can
get away with a qemu built with sdl/x deselected and then running that with
-nographic. Of course you won't see guest output then so it will have to
boot by itslef, unless it talks to a serial console...)
Btw, to get meaningful backtraces on amd64 I think you need to
rebuild the debug kernel with ddb compiled in, otherwise stuff is left
built with -fomit-frame-pointer which makes gdb unhappy. (shouldn't
-fomit-frame-pointer be disabled for any kind of debug kernel because
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"