Re: general protection fault panic

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_at_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