Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Mar 2012 13:43:49 -0700
From:      Jos Backus <jos@catnook.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Ryan Stone <rstone@freebsd.org>, freebsd-current@freebsd.org, Rui Paulo <rpaulo@freebsd.org>, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: general protection fault panic
Message-ID:  <CAETOPp0od3qEfuXsadJP-gSUh7QL06Vp3p8zBb1VBBzanEn5kw@mail.gmail.com>
In-Reply-To: <201203261629.28986.jhb@freebsd.org>
References:  <20120323222313.GA1331@troutmask.apl.washington.edu> <20120326174155.GA1931@troutmask.apl.washington.edu> <CAETOPp2XhjbESoqtDKU0ecuK73npSPdpQrz3nfgRBCMSy1=9pg@mail.gmail.com> <201203261629.28986.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 26, 2012 at 1:29 PM, John Baldwin <jhb@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@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():
>> >>
>> >> =A0 =A0 =A0 irq =3D lapics[apic_id].la_ioint_irqs[vector - APIC_IO_IN=
TS];
>> >>
>> >> Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able to d=
o
> 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. =A0However, I'd be curious to see what the assembly looks lik=
e
>> >> (x/10i $rip at this frame).
>> >>
>> >
>> >
>> > (kgdb) p lapics[0].la_ioint_irqs[3]
>> > $1 =3D 16
>> > (kgdb) frame 27
>> > #27 0xffffffff806dc186 in acpi_cpu_c1 ()
>> > =A0 =A0at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
>> > 97 =A0 =A0 =A0 =A0 =A0 =A0 =A0__asm __volatile("sti; hlt");
>> > (kgdb) x/10i $rip
>> > 0xffffffff806dc186 <acpi_cpu_c1+6>: =A0 =A0 leaveq
>> > 0xffffffff806dc187 <acpi_cpu_c1+7>: =A0 =A0 retq
>> > 0xffffffff806dc188 <acpi_cpu_c1+8>: =A0 =A0 nopl =A0 0x0(%rax,%rax,1)
>> > 0xffffffff806dc190 <nexus_acpi_attach>: push =A0 %rbp
>> > 0xffffffff806dc191 <nexus_acpi_attach+1>: =A0 =A0 =A0 mov =A0 =A0%rsp,=
%rbp
>> > 0xffffffff806dc194 <nexus_acpi_attach+4>: =A0 =A0 =A0 push =A0 %r12
>> > 0xffffffff806dc196 <nexus_acpi_attach+6>: =A0 =A0 =A0 push =A0 %rbx
>> > 0xffffffff806dc197 <nexus_acpi_attach+7>: =A0 =A0 =A0 mov =A0 =A0%rdi,=
%rbx
>> > 0xffffffff806dc19a <nexus_acpi_attach+10>:
>> > =A0 =A0callq =A00xffffffff807551b0 <nexus_init_resources>
>> > 0xffffffff806dc19f <nexus_acpi_attach+15>: =A0 =A0 =A0mov =A0 =A0%rbx,=
%rdi
>> >
>> >
>> > In another email thread, it appears that jkim is chasing
>> > down some issues with the latest ACPI code. =A0Perhaps, 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@freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@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 =A0-std=3Dc99 -g -Wall -Wredundant-decls
>> -Wnested-externs -Wstrict-prototypes =A0-Wmissing-prototypes
>> -Wpointer-arith -Winline -
>> Wcast-qual =A0-Wundef -Wno-pointer-sign -fformat-extensions
>> -Wmissing-include-dirs -fdiagnostics-show-option
>> -Wno-error-tautological-compare
>> =A0-Wno-error-empty-body =A0-Wno-error-parentheses-equality -nostdinc =
=A0-I.
>> -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OP
>> TION_HEADERS -include opt_global.h =A0-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]
>> =A0 =A0 =A0 =A0 lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_I=
NTS] =3D
>> =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> /usr/src/sys/x86/x86/local_apic.c:123:2: note: array 'la_ioint_irqs'
>> declared here
>> =A0 =A0 =A0 =A0 int la_ioint_irqs[APIC_NUM_IOINTS + 1];
>> =A0 =A0 =A0 =A0 ^
>> 1 error generated.
>> *** [local_apic.o] Error code 1
>
> No, that is just a straight up bug from when IDT_DTRACE_RET was changed t=
o
> 0x20 from some high number. =A0Hmm, 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. :( =A0We 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
--=20
Jos Backus
jos at catnook.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAETOPp0od3qEfuXsadJP-gSUh7QL06Vp3p8zBb1VBBzanEn5kw>