general protection fault panic
John Baldwin
jhb at freebsd.org
Tue Mar 27 14:30:20 UTC 2012
On Monday, March 26, 2012 4:45:30 pm Steve Kargl wrote:
> On Mon, Mar 26, 2012 at 04:17:50PM -0400, John Baldwin wrote:
> > On Monday, March 26, 2012 1:59:18 pm Steve Kargl wrote:
> > > On Mon, Mar 26, 2012 at 01:53:25PM -0400, John Baldwin wrote:
> > > > On Monday, March 26, 2012 1:41:55 pm Steve Kargl wrote:
> > > > > On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote:
> > > > > > On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote:
> > > > > >
> > > > > > 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).
> > > > > >
> > > > >
> > > > >
> > > > > (kgdb) p lapics[0].la_ioint_irqs[3]
> > > > > $1 = 16
> > > > > (kgdb) frame 27
> > > > > #27 0xffffffff806dc186 in acpi_cpu_c1 ()
> > > > > at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
> > > >
> > > > Sorry, I meant down at the frame that faulted (frame 7 in this case).
> > > >
> > >
> > > (kgdb) frame 7
> > > #7 0xffffffff80751232 in lapic_handle_intr (vector=51,
> > > frame=0xffffff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
> > > 777 {
> > > (kgdb) x/10i $rip
> > > 0xffffffff80751232 <lapic_handle_intr+2>: stos %eax,%es:(%rdi)
> > > 0xffffffff80751233 <lapic_handle_intr+3>: (bad)
> > > 0xffffffff80751234 <lapic_handle_intr+4>: pop %rbp
> > > 0xffffffff80751235 <lapic_handle_intr+5>: pop %rsi
> > > 0xffffffff80751236 <lapic_handle_intr+6>: fsubr %st(3),%st
> > > 0xffffffff80751238 <lapic_handle_intr+8>: (bad)
> > > 0xffffffff80751239 <lapic_handle_intr+9>: or $0xac1ae6b3,%eax
> > > 0xffffffff8075123e <lapic_handle_intr+14>: out %eax,$0x19
> > > 0xffffffff80751240 <lapic_handle_intr+16>:
> > > jl 0xffffffff8075125e <lapic_handle_intr+46>
> > > 0xffffffff80751242 <lapic_handle_intr+18>: adc
%r12d,0xc6aa671(%rdi)
> >
> > Looks like the instruction pointer is busted. Try doing 'x/10i
lapic_handle_intr'.
> > I suspect you will not see 'lapic_handle_intr+2' as a valid instruction
offset. :(
> >
>
> I'm assuming you want this in frame 7
>
> (kgdb) frame 7
> #7 0xffffffff80751232 in lapic_handle_intr (vector=51,
> frame=0xffffff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
> (kgdb) x/10i lapic_handle_intr
> 0xffffffff80751230 <lapic_handle_intr>: sbb $0xa7,%al
> 0xffffffff80751232 <lapic_handle_intr+2>: stos %eax,%es:(%rdi)
> 0xffffffff80751233 <lapic_handle_intr+3>: (bad)
> 0xffffffff80751234 <lapic_handle_intr+4>: pop %rbp
> 0xffffffff80751235 <lapic_handle_intr+5>: pop %rsi
> 0xffffffff80751236 <lapic_handle_intr+6>: fsubr %st(3),%st
> 0xffffffff80751238 <lapic_handle_intr+8>: (bad)
> 0xffffffff80751239 <lapic_handle_intr+9>: or $0xac1ae6b3,%eax
> 0xffffffff8075123e <lapic_handle_intr+14>: out %eax,$0x19
> 0xffffffff80751240 <lapic_handle_intr+16>:
> jl 0xffffffff8075125e <lapic_handle_intr+46>
Hmmm, odd. In this case the frame doesn't matter (global symbol).
Are you sure you are using the correct kernel.debug file?
--
John Baldwin
More information about the freebsd-current
mailing list