From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 21:21:16 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 0442516A574 for ; Thu, 6 Jan 2005 21:21:16 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B780143D5C for ; Thu, 6 Jan 2005 21:21:15 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 8105 invoked from network); 6 Jan 2005 21:21:15 -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 21:21:15 -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 j06LKeBD083753; Thu, 6 Jan 2005 16:21:09 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Pawel Worach Date: Thu, 6 Jan 2005 15:41:39 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200501061345.44146.jhb@FreeBSD.org> <41DD9806.6060301@telia.com> In-Reply-To: <41DD9806.6060301@telia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501061541.39673.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: Nate Lawson 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 21:21:16 -0000 On Thursday 06 January 2005 02:56 pm, Pawel Worach wrote: > John Baldwin wrote: > > 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; > > CURRENT from 16:00 UTC and the patch above seems to result in the same > thing :( > > Copyright (c) 1992-2005 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 6.0-CURRENT #0: Thu Jan 6 20:31:16 CET 2005 > root@zero:/usr/obj/usr/src/sys/ZERO > ... > pcib0: matched entry for 0.15.INTA (src \LPUS:0) > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x48 The fact that the source is '\LPUS' is bothersome, it should probably just be 'LPUS' (without the leading slash). Do you have your acpidump somewhere where we can look at it? Also, is there a BIOS upgrade available? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org