page fault panic in device_get_softc/acpi_pcib_route_interrupt

[Pawel Worach]

Nate Lawson wrote:
> 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.

sys/dev/acpica/acpi.c:acpi_probe_child() around line 1529
             /* Associate the handle with the device_t and vice versa. */
             acpi_set_handle(child, handle);
             AcpiAttachData(handle, acpi_fake_objhandler, child);

             printf("adding child %s, dev %p\n", acpi_name(handle),
                    acpi_get_device(child));

>> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> --- 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__);
>  

Ok, this fixed the ACPI panic. Thank you! :)

Now I'm back to the original problem with the mpt device attachment I started to
investigate before, seems to be PCI and resource allocation related. (New thread
about that though).

-- 
Pawel