Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt

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

--- acpi.c.orig	2005-01-07 19:18:56.000000000 -0800
+++ acpi.c	2005-01-07 19:19:22.000000000 -0800
_at__at_ -1403,7 +1403,7 _at__at_
     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__);