Date: Fri, 07 Jan 2005 10:38:26 -0800 From: Nate Lawson <nate@root.org> To: Pawel Worach <pawel.worach@telia.com> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt Message-ID: <41DED722.7070801@root.org> In-Reply-To: <41DEC937.5030709@telia.com> References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200501061345.44146.jhb@FreeBSD.org> <41DD9806.6060301@telia.com> <200501061541.39673.jhb@FreeBSD.org> <41DDBA4F.6010009@root.org> <41DDC941.9000609@telia.com> <41DE36FA.6070805@root.org> <41DEC937.5030709@telia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41DED722.7070801>