page fault panic in device_get_softc/acpi_pcib_route_interrupt
Nate Lawson
nate at root.org
Fri Jan 7 19:20:22 PST 2005
Pawel Worach wrote:
> Nate Lawson wrote:
>
>> John Baldwin wrote:
>>> So it appears the handle doesn't have a device_t associated with it.
>>> :( The next step is to maybe do a printf in the code that adds the
>>> device_t's to see if one shows up for this handle, and if the handle
>>> is the same for the given name.
>>
>> Ok, add this to acpi.c:acpi_add_child(), after AcpiAttachData():
>>
>> printf("adding child %s, dev %p\n", acpi_name(handle),
>> acpi_get_device(child));
>>
>> Then send the output.
>>
>
> real memory = 1073590272 (1023 MB)
> avail memory = 1046142976 (997 MB)
> ACPI APIC Table: <IBM SERONYXP>
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
> cpu0 (BSP): APIC ID: 0
> cpu1 (AP): APIC ID: 6
> MADT: Forcing active-low polarity and level trigger for SCI
> ioapic2 <Version 1.1> irqs 32-47 on motherboard
> ioapic1 <Version 1.1> irqs 16-31 on motherboard
> ioapic0 <Version 1.1> irqs 0-15 on motherboard
> npx0: [FAST]
> npx0: <math processor> on motherboard
> npx0: INT 16 interface
> acpi0: <IBM SERONYXP> on motherboard
> acpi0: Power Button (fixed)
> adding child \_PR_.CPU1, dev 0
> adding child \_PR_.CPU0, dev 0
Are you sure you put the printf _after_ AcpiAttachData? It's surprising
that none of the handles has a device attached. This is not the primary
problem but is something we need to fix if you put the printf in the
right spot.
> adding child \_SB_.PCI0, dev 0
> adding child \_SB_.PCI0.ISA_, dev 0
> adding child \_SB_.PCI0.ISA_.SIOM, dev 0
> adding child \_SB_.PCI0.ISA_.PS2K, dev 0
> adding child \_SB_.PCI0.ISA_.PS2M, dev 0
> adding child \_SB_.PCI0.ISA_.FDC0, dev 0
> adding child \_SB_.PCI0.ISA_.COM1, dev 0
> adding child \_SB_.PCI0.ISA_.COM2, dev 0
> adding child \_SB_.PCI0.ISA_.PIC_, dev 0
> adding child \_SB_.PCI0.ISA_.DMA0, dev 0
> adding child \_SB_.PCI0.ISA_.TMR_, dev 0
> adding child \_SB_.PCI0.ISA_.RTC_, dev 0
> adding child \_SB_.PCI0.ISA_.SPKR, dev 0
> adding child \_SB_.PCI0.ISA_.COPR, dev 0
> adding child \_SB_.PCI0.ISA_.SBD1, dev 0
> adding child \_SB_.PCI0.USB0, dev 0
> adding child \_SB_.PCI0.CI10, dev 0
> adding child \_SB_.PCI0.CI12, dev 0
> adding child \_SB_.PCI0.CI20, dev 0
> adding child \_SB_.PCI0.CI22, dev 0
> adding child \_SB_.PCI1, dev 0
> adding child \_SB_.PCI2, dev 0
> adding child \_SB_.PCI3, dev 0
> adding child \_SB_.PCI4, dev 0
> acpi0: reservation of 460, 2 (4) failed
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0
> cpu0: <ACPI CPU> on acpi0
> cpu1: <ACPI CPU> on acpi0
> pcib0: <ACPI Host-PCI bridge> on acpi0
> pci0: <ACPI PCI bus> on pcib0
> acpi handle 0xc1ec8d20, name \LPUS
> link device: 0 index 0
Ok, I also know what the main issue is. Your link devices are in \ but
it's invalid to have devices outside of \_SB. We only scan a few sub
namespaces of \ (see acpi_probe_children) so your links are never
probed/attached. The workaround is to scan all of \ instead of the
subspaces. This is very wrong from the acpi standards but probably
won't hurt anything. Try the attached patch. This worked before
because we probed links directly through _PRT and the reference was
correct there, so it didn't matter that the link was in \ instead of \_SB.
--
Nate
-------------- next part --------------
--- acpi.c.orig 2005-01-07 19:18:56.000000000 -0800
+++ acpi.c 2005-01-07 19:19:22.000000000 -0800
@@ -1403,7 +1403,7 @@
ACPI_HANDLE parent;
ACPI_STATUS status;
int i;
- static char *scopes[] = {"\\_PR_", "\\_TZ_", "\\_SI", "\\_SB_", NULL};
+ static char *scopes[] = {"\\", NULL};
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
More information about the freebsd-current
mailing list