From owner-freebsd-current@FreeBSD.ORG Wed Jan 5 22:50:24 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 BC04C16A4CE for ; Wed, 5 Jan 2005 22:50:24 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69FD743D1D for ; Wed, 5 Jan 2005 22:50:24 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4111 invoked from network); 5 Jan 2005 22:50:24 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Jan 2005 22:50:23 -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 j05MoIZi076800; Wed, 5 Jan 2005 17:50:19 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Wed, 5 Jan 2005 17:31:32 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412301527.07327.jhb@FreeBSD.org> <41D8935F.20505@root.org> In-Reply-To: <41D8935F.20505@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501051731.32915.jhb@FreeBSD.org> 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: Wed, 05 Jan 2005 22:50:24 -0000 On Sunday 02 January 2005 07:35 pm, Nate Lawson wrote: > John Baldwin wrote: > > On Wednesday 29 December 2004 06:19 pm, Nate Lawson wrote: > >>John Baldwin wrote: > >>>On Tuesday 28 December 2004 06:32 pm, Pawel Worach wrote: > >>>>John Baldwin wrote: > >>>>>Are you still seeing this? > >>>> > >>>>Yes I am, updated boot -v with debug.rman_debug=1 below. > >>>>Sources are from 16:00 UTC today. Last working kernel I > >>>>have is from November 20, I can start a binary search if > >>>>you want. > >>> > >>>No, I'm fairly sure I know what the search would find. :) Nate, I think > >>>the problem here is that his link device doesn't have an associated > >>>device_t yet when he gets to this point. Can we force ACPI to enumerate > >>>all its devices and assign the associated device_t's via the > >>>GetData/SetData stuff before we actually probe any of the children, or > >>> do we do that already? > >> > >>What you want, my friend, is multi-pass newbus. Oh wait, you were one > >>of the proponents of that. :) > >> > >>You can overload the hack I have in acpi_probe_order() for sysresource > >>objects. Just do a manual check for the PNPID for PCI links and have > >>them probe first. > > > > I don't need them to probe first, I just need them to have a device_t > > associated with each ACPI handle (even an unprobed one) before any of the > > child devices are probed and attached. It actually wouldn't hurt to go > > ahead and probe them up front if that is easy to do though. > > 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. > I do think the problem is that his link devices are not being probed > (and thus lack a softc) before the device that wants to route interrupts > via that link. The acpi_probe_order() hack would make sure that this > happens. Since all acpi devices are ordered by default based on the AML > tree hammered flat, dependencies have to be set by the bus drivers. PCI > does this correctly and I updated FDC to do this. ATA and others > currently do not but they don't use acpi yet. I already force-attach link devices when walking the _PRT during a pci bridge device's attach routine, meaning that any links mentioned in the _PRT for a given bridge are guaranteed to be attached before any child devices of that bridge (including the pci bus and all the pci devices on it). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org