Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt

Pawel Worach wrote:
> 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));

That's because my addled brain (a week of only a couple hours sleep a 
night) got it wrong.  Change that to "acpi_get_device(handle)" and post 
the printout, just so I can make sure this part is working overall.

>> 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.
> 
> Ok, this fixed the ACPI panic. Thank you! :)

Now I need to figure out how many other systems will be impacted by 
changing this code to violate the standard.  It looks like we have no 
choice though so I'll commit something equivalent to -current and let it 
shake out there.  I suspect since we check the type of devices, it 
shouldn't cause any real-life problems if we become more lenient about 
where they are located.

-- 
Nate