From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 18:46:32 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 6101616A4CE for ; Thu, 6 Jan 2005 18:46:32 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1224643D31 for ; Thu, 6 Jan 2005 18:46:32 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24123 invoked from network); 6 Jan 2005 18:46:31 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 6 Jan 2005 18:46:31 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j06IkLoF082922; Thu, 6 Jan 2005 13:46:27 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Thu, 6 Jan 2005 13:45:44 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200501051731.32915.jhb@FreeBSD.org> <41DC7210.7090007@root.org> In-Reply-To: <41DC7210.7090007@root.org> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200501061345.44146.jhb@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org 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: Thu, 06 Jan 2005 18:46:32 -0000 On Wednesday 05 January 2005 06:02 pm, Nate Lawson wrote: > John Baldwin wrote: > > On Sunday 02 January 2005 07:35 pm, Nate Lawson wrote: > >>We already associate handles and devices in > >>sys/dev/acpica/acpi.c:acpi_probe_child() before probing anything. See > >>the AcpiAttachData() step. I don't think that's the problem. > > > > I do because he passes a null device_t pointer in as an argument to a > > function. The calling code is: > > > > /* > > * We have to find the source device (PCI interrupt link device). > > */ > > if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source, > > &lnkdev))) { device_printf(pcib, "couldn't find PCI interrupt link device > > %s\n", prt->Source); > > interrupt = acpi_pci_link_route_interrupt(acpi_get_device(lnkdev), > > prt->SourceIndex); > > > > And Pawel's trace shows that the first argument to > > acpi_pci_link_route_interrupt() is NULL. > > What's the value of prt->Source? If it's not a valid reference to a > link device (i.e. \_SB.PCIx.LNKx), then trying to get a device_t from it > would yield NULL. For instance, if it points to \_SB, you'll get a > valid handle from AcpiGetHandle but that handle obviously has no > associated device_t. > > Additionally, I see you're using the root handle ACPI_ROOT_OBJECT as the > base for lookup. If the reference is relative (doesn't start with \), > this won't work. You should be using the handle of the parent of _PRT > (the PCI bus handle) as the root of the lookup. Commonly, this will be > something like a \_SB.PCI0 string. > > This would fix this scenario: > \_SB.PCI0 > _PRT (Source = LNKA) > LNKA > LNKB Ok, that might be it. I'll work up a patch to use the relative roots instead. In fact, the patch is very simple. It already used relative lookups when force-attaching the link devices during attach. Pawel, the change is this: --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c 2004/12/27 05:40:30 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pcib.c 2005/01/06 18:40:54 @@ -249,7 +249,8 @@ /* * We have to find the source device (PCI interrupt link device). */ - if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source, &lnkdev))) { + if (ACPI_FAILURE(AcpiGetHandle(acpi_get_handle(pcib), prt->Source, + &lnkdev))) { device_printf(pcib, "couldn't find PCI interrupt link device %s\n", prt->Source); goto out; > Also, I'm not sure if you picked up the size issue with the _PRT struct > supplied by ACPI-CA. Since Source is a variable-length string, if you > copy the struct you get from AcpiGetRoutingTable (or whatever), you only > get the first 4 bytes, non-null terminated, of the string. > > typedef struct acpi_pci_routing_table > { > UINT32 Length; > UINT32 Pin; > ACPI_INTEGER Address; > UINT32 SourceIndex; > char Source[4]; > } ACPI_PCI_ROUTING_TABLE; > > Note that Source above is not 4 bytes, it's variable-length. That's why > I copied it to a different field in the old acpi_pci_link PRT struct. I don't ever store the Source anywhere, I just use it to lookup handles, so I don't have to worry about the size change. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org