Date: Sun, 18 Nov 2007 03:05:33 +0100 From: Juergen Lock <nox@jelal.kn-bremen.de> To: freebsd-hackers@FreeBSD.org, freebsd-emulation@FreeBSD.org Subject: double panic, and whats apic_cmd? (kqemu crash...) Message-ID: <20071118020533.GA57425@saturn.kn-bremen.de>
next in thread | raw e-mail | index | archive | help
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: <0> 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 Uptime: 9m41s 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)); (kgdb) bt #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. ) at ../../../amd64/amd64/trap.c:697 #4 0xffffffff806bc43d in trap_pfault (frame=0xffffffff9fd27480, usermode=0) at ../../../amd64/amd64/trap.c:614 #5 0xffffffff806bcd30 in trap (frame=0xffffffff9fd27480) at ../../../amd64/amd64/trap.c:383 #6 0xffffffff806a371e in calltrap () at ../../../amd64/amd64/exception.S:169 #7 0xffffffff804e4fa2 in strlen (str=0x1 <Address 0x1 out of bounds>) at ../../../libkern/strlen.c:41 #8 0xffffffff8048c5f5 in kvprintf ( fmt=0xffffffff807aee73 " while in %s mode\n", func=0xffffffff8048d000 <putchar>, arg=0xffffffff9fd276b0, radix=10, ap=Variable "ap" is not available. ) at ../../../kern/subr_prf.c:750 #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, ---Type <return> to continue, or q <return> to quit--- opts=36477624, file=0xffffffff9fd276d0 "", line=-2137032800) at ../../../kern/kern_mutex.c:189 Previous frame inner to this frame (corrupt stack?) (kgdb) q iapetus# exit " 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 panic? :) 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 of that?) Thanx, Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071118020533.GA57425>