Date: Fri, 7 Jan 2005 14:51:01 -0500 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@FreeBSD.org Cc: Nate Lawson <nate@root.org> Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt Message-ID: <200501071451.01876.jhb@FreeBSD.org> In-Reply-To: <41DED722.7070801@root.org> References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DEC937.5030709@telia.com> <41DED722.7070801@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501071451.01876.jhb>