page fault panic in device_get_softc/acpi_pcib_route_interrupt

[John Baldwin]

On Friday 07 January 2005 01:38 pm, Nate Lawson wrote:
> 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.

Err, I just use the _PRT walk to force the device_t to attach if it doesn't 
already.  The device will always attach though, even it's not referenced, it 
just does so in the regular new-bus order, so all links are probed, and ones 
that aren't referenced by any _PRT's that we parse do get disabled via _DIS.

> 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?)

Yes, this is a good question, and I'm not sure my ASL patch will fix his 
problem.  I wonder if he is getting back a NULL ACPI_HANDLE?

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org