From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 18:38:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F20BC16A4CE; Fri, 7 Jan 2005 18:38:41 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A931E43D46; Fri, 7 Jan 2005 18:38:41 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-95.dsl.snfc21.pacbell.net [64.171.186.95]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j07IcdGV015287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2005 10:38:40 -0800 Message-ID: <41DED722.7070801@root.org> Date: Fri, 07 Jan 2005 10:38:26 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Worach 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> In-Reply-To: <41DEC937.5030709@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: John Baldwin Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 18:38:42 -0000 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