From owner-freebsd-current@FreeBSD.ORG Mon Mar 26 17:18:44 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D2F6106564A for ; Mon, 26 Mar 2012 17:18:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D9478FC15 for ; Mon, 26 Mar 2012 17:18:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id B6FAB46B09; Mon, 26 Mar 2012 13:18:38 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2151FB93F; Mon, 26 Mar 2012 13:18:38 -0400 (EDT) From: John Baldwin To: Steve Kargl Date: Mon, 26 Mar 2012 13:18:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120323222313.GA1331@troutmask.apl.washington.edu> <20120326154359.GB14611@troutmask.apl.washington.edu> <20120326162129.GB1373@troutmask.apl.washington.edu> In-Reply-To: <20120326162129.GB1373@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203261318.37373.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 26 Mar 2012 13:18:38 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: general protection fault panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:18:44 -0000 On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote: > On Mon, Mar 26, 2012 at 08:43:59AM -0700, Steve Kargl wrote: > > On Mon, Mar 26, 2012 at 10:59:35AM -0400, John Baldwin wrote: > > > On Friday, March 23, 2012 6:23:13 pm Steve Kargl wrote: > > > > Haven't seen one of these in a long time. > > > > > > > > %uname -a > > > > FreeBSD troutmask.apl.washington.edu 10.0-CURRENT FreeBSD > > > > 10.0-CURRENT #0 r233282: Wed Mar 21 12:39:16 PDT 2012 > > > > kargl@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64 > > > > > > > > Hand transcribed > > > > > > > > Fatal trap 9: general protection fault while in kernel mode > > > > cpuid = 1; apic id = 01 > > > > instruction pointer = 0x20:0xffffffff80570b89 > > > > > > Can you run gdb on your kernel.debug and 'l *' this address? > > > > > > > Unfortunately, I don't have that kernel.debug anymore. I saw > > that alc had committed a few changes, so updated the kernel. > > I do have the kernel and kernel.symbol files. Loading > > kernel.symbol into gdb shows > > > > (gdb) l *0xffffffff80570b89 > > 0xffffffff80570b89 is in strcmp (/usr/src/sys/libkern/strcmp.c:45). > > 40 */ > > 41 int > > 42 strcmp(s1, s2) > > 43 register const char *s1, *s2; > > 44 { > > 45 while (*s1 == *s2++) > > 46 if (*s1++ == 0) > > 47 return (0); > > 48 return (*(const unsigned char *)s1 - *(const unsigned char *)(s2 - 1)); > > 49 } > > > > Don't know if the above helps or is a red-herring. > > > > I may be able to reproduce the crash. I give it a try in a > > few moments. > > > > The above gdb is probably a red-herring. I can 100% > reproduce the panic with > > 1) Insert old MS-formatted floppy into drive. > 2) mount_msdosfs /dev/fd0 /mnt > > %kgdb /usr/obj/usr/src/sys/SPEW/kernel.debug vmcore.0 > > Unread portion of the kernel message buffer: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x33 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff80751232 > stack pointer = 0x28:0xffffff8000229a50 > frame pointer = 0x28:0xffffff8000229b30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 10 (idle: cpu0) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 2d16h49m51s > Dumping 1209 out of 8116 MB:..2%..11%..22%..31%..42%..51%..61%..71%..81%..92% > > Reading symbols from /usr/local/libexec/linux_adobe/linux_adobe.ko...done. > Loaded symbols for /usr/local/libexec/linux_adobe/linux_adobe.ko > #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268 > 268 if (textdump && textdump_pending) { > (kgdb) bt > #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:268 > #1 0xffffffff804c8140 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:454 > #2 0xffffffff804c8617 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:642 > #3 0xffffffff806f6180 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. > ) > at /usr/src/sys/amd64/amd64/trap.c:838 > #4 0xffffffff806f64ff in trap_pfault (frame=0xffffff80002299a0, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:755 > #5 0xffffffff806f69ee in trap (frame=0xffffff80002299a0) > at /usr/src/sys/amd64/amd64/trap.c:454 > #6 0xffffffff806e12bf in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff80751232 in lapic_handle_intr (vector=51, frame=0xffffff8000229a70) > at /usr/src/sys/x86/x86/local_apic.c:777 > #8 0x0000000000001008 in ?? () > #9 0xffffff8000229b54 in ?? () > #9 0xffffff8000229b54 in ?? () > #10 0x0000000000000000 in ?? () > #11 0x000000000000100b in ?? () > #12 0x0000000000000000 in ?? () > #13 0x0000000000000000 in ?? () > #14 0x0000000000000000 in ?? () > #15 0x0000000000000000 in ?? () > #16 0xffffff8000229b30 in ?? () > #17 0x0000000000000000 in ?? () > #18 0x0000000000000000 in ?? () > #19 0xfffffe00032e3600 in ?? () > #20 0xfffffe00032e3628 in ?? () > #21 0xffffff8000229c40 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x001b0013032e3628 in ?? () > #24 0xffffff8000229c40 in ?? () > #25 0x003b003b00000001 in ?? () > #26 0xffffff8000229b30 in ?? () > #27 0xffffffff806dc186 in acpi_cpu_c1 () > at /usr/src/sys/amd64/acpica/acpi_machdep.c:97 > > (kgdb) l *0xffffffff80751232 > 0xffffffff80751232 is in lapic_handle_intr (/usr/src/sys/x86/x86/local_apic.c:777). > 772 lapic->eoi = 0; > 773 } > 774 > 775 void > 776 lapic_handle_intr(int vector, struct trapframe *frame) > 777 { > 778 struct intsrc *isrc; > 779 > 780 isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), > 781 vector)); Hmmmm. Odd. I don't think that should generate a fault. (But now I wonder about stray IRQ 0 messages I now see on boot.) You know your APIC ID is 0, so you should be able to find the IRQ for vector 51 from here in apic_idt_to_irq(): irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]; Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to do this in kgdb: p lapics[0].la_ioint_irqs[3] That should give you an index, and intr_lookup_source() just does an array lookup. However, I'd be curious to see what the assembly looks like (x/10i $rip at this frame). -- John Baldwin