Re: general protection fault panic

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.

-- 
John Baldwin