Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt

Pawel Worach wrote:
> Nate Lawson wrote:
> 
>> Pawel Worach wrote:
>>
>>>
>>> I do not even see the code enter acpi_pci_link_attach(), even added a 
>>> dummy
>>> printf at the top of the method.
>>
>> That's a problem.  If the link isn't attached, you can't route 
>> interrupts by it.  Try adding this to  the if statemetns in 
>> sys/dev/acpica/acpi.c:acpi_probe_order() --
>>
>>     /* attach pci links early */
>>     } else if (acpi_MatchHid(handle, "PNP0C0F")) {
>>     *order = 3;
>>     ret = 1;
>>     }
> 
> acpi_probe_order() is called 26 times but PNP0C0F never seems to match
> the handle passed to it.

Oh, I think I know where I didn't understand John.  He doesn't probe 
links through the normal namespace probe, he goes through _PRT, 
dereferencing Source and probing those directly.  Since your PCI bus 
appears in the namespace before the links, the above does not get called 
  before the crash.  It's been a rough week, hence I'm more dense.  :)

A separate problem with this, John, is that you get a different _PRT 
based on whether in APIC mode or not.  So a link that is only referenced 
in PIC mode _PRT, for instance, will never be disabled on an APIC 
machine (since we enable APIC before PCI routing.)  We'd never see it if 
only probing links through _PRT.  I think it would be better to attach 
them through normal namespace methods and use the probe_order hack 
above.  The only thing it could potentially interfere with is 
sysresource, but since IRQ resources come from nexus above and are not 
defined in memory/IO port sysresource objects, there should be no actual 
conflict.

The ASL patch John just sent should fix your issue.  My question if this 
works is why it just started occuring and also, what the proper handle 
to use is for relative references (i.e., why didn't AcpiGetHandle(ROOT, 
"LPUS") work since \LPUS is right under the root?)

-- 
Nate