Date: Mon, 26 Mar 2012 13:18:37 -0400 From: John Baldwin <jhb@freebsd.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: general protection fault panic Message-ID: <201203261318.37373.jhb@freebsd.org> In-Reply-To: <20120326162129.GB1373@troutmask.apl.washington.edu> References: <20120323222313.GA1331@troutmask.apl.washington.edu> <20120326154359.GB14611@troutmask.apl.washington.edu> <20120326162129.GB1373@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203261318.37373.jhb>