Re: general protection fault panic

From: Jos Backus <jos_at_catnook.com>
Date: Mon, 26 Mar 2012 13:43:49 -0700
On Mon, Mar 26, 2012 at 1:29 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> On Monday, March 26, 2012 1:51:59 pm Jos Backus wrote:
>> On Mon, Mar 26, 2012 at 10:41 AM, Steve Kargl
>> <sgk_at_troutmask.apl.washington.edu> 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
>> > 97              __asm __volatile("sti; hlt");
>> > (kgdb) x/10i $rip
>> > 0xffffffff806dc186 <acpi_cpu_c1+6>:     leaveq
>> > 0xffffffff806dc187 <acpi_cpu_c1+7>:     retq
>> > 0xffffffff806dc188 <acpi_cpu_c1+8>:     nopl   0x0(%rax,%rax,1)
>> > 0xffffffff806dc190 <nexus_acpi_attach>: push   %rbp
>> > 0xffffffff806dc191 <nexus_acpi_attach+1>:       mov    %rsp,%rbp
>> > 0xffffffff806dc194 <nexus_acpi_attach+4>:       push   %r12
>> > 0xffffffff806dc196 <nexus_acpi_attach+6>:       push   %rbx
>> > 0xffffffff806dc197 <nexus_acpi_attach+7>:       mov    %rdi,%rbx
>> > 0xffffffff806dc19a <nexus_acpi_attach+10>:
>> >    callq  0xffffffff807551b0 <nexus_init_resources>
>> > 0xffffffff806dc19f <nexus_acpi_attach+15>:      mov    %rbx,%rdi
>> >
>> >
>> > In another email thread, it appears that jkim is chasing
>> > down some issues with the latest ACPI code.  Perhaps, this
>> > is related?
>> >
>> > If it helps, I'll put kernel.debug and vmcore.0 at
>> > http://troutmask.apl.washington.edu/~kargl/jhb
>> > --
>> > Steve
>> > _______________________________________________
>> > freebsd-current_at_freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>>
>> Just in case it's related: I'm seeing the following error on my
>> -current system when building with clang:
>>
>> clang -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls
>> -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
>> -Wpointer-arith -Winline -
>> Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
>> -Wmissing-include-dirs -fdiagnostics-show-option
>> -Wno-error-tautological-compare
>>  -Wno-error-empty-body  -Wno-error-parentheses-equality -nostdinc  -I.
>> -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OP
>> TION_HEADERS -include opt_global.h  -mno-aes -mno-avx -mno-mmx
>> -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror
>> /usr/src/sys/
>> x86/x86/local_apic.c
>> /usr/src/sys/x86/x86/local_apic.c:312:2: error: array index of '-16'
>> indexes before the beginning of the array [-Werror,-Warray-bounds]
>>         lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] =
>>         ^                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> /usr/src/sys/x86/x86/local_apic.c:123:2: note: array 'la_ioint_irqs'
>> declared here
>>         int la_ioint_irqs[APIC_NUM_IOINTS + 1];
>>         ^
>> 1 error generated.
>> *** [local_apic.o] Error code 1
>
> No, that is just a straight up bug from when IDT_DTRACE_RET was changed to
> 0x20 from some high number.  Hmm, I wonder how the person who did that
> chose 0x20 since 0x20 is mapped to the 8259A IRQ 0 and may not really be
> safe to use. :(  We can come up with a different number (which at that
> point would make the relevant code in local_apic.c valid again).
>
> This should not be related to Steve's issue though I believe.

Okay, thanks for looking into this, John.

Cheers,
Jos
-- 
Jos Backus
jos at catnook.com
Received on Mon Mar 26 2012 - 18:43:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC