From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 22:50:05 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 0E9B216A4CE for ; Thu, 6 Jan 2005 22:50:05 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id B387043D54 for ; Thu, 6 Jan 2005 22:50:04 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7417 invoked from network); 6 Jan 2005 22:50:04 -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 22:50:04 -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 j06MnxnE084386; Thu, 6 Jan 2005 17:50:00 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Nate Lawson Date: Thu, 6 Jan 2005 17:41:30 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DD9806.6060301@telia.com> <41DDAD7B.2020602@root.org> In-Reply-To: <41DDAD7B.2020602@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501061741.30367.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: Thu, 06 Jan 2005 22:50:05 -0000 On Thursday 06 January 2005 04:28 pm, Nate Lawson wrote: > Pawel Worach wrote: > > pci_add_children(c1f16a00,0,80,c0820b54,c052188f) at > > pci_add_children+0x123 > > acpi_pci_attach(c1f16a00,c1f4484c,c06c14ec,c06aa680,0) at > > acpi_pci_attach+0x86 > > device_attach(c1f16a00,c1ed5d80,c0820bdc,c07c538c,c1f16d00) at > > device_attach+0x2c9 > > bus_generic_attach(c1f16d00,c07d92a7,0,c0820bcc,0) at > > bus_generic_attach+0x18 > > acpi_pcib_attach(c1f16d00,c1f7e1f4,0,c0820c04,c07bff97) at > > acpi_pcib_attach+0xec > > acpi_pcib_acpi_attach(c1f16d00,c1f4384c,c06c14ec,c06aa680,0) at > > acpi_pcib_acpi_attach+0xf9 > > device_attach(c1f16d00,2f,c0820cbc,c07c27c4,c1ed5d80) at > > device_attach+0x2c9 > > bus_generic_attach(c1ed5d80,2e,2f,c1f7dc28,2e) at bus_generic_attach+0x18 > > acpi_attach(c1ed5d80,c1f4604c,c06c14ec,c06aa680,0) at acpi_attach+0x7b4 > > device_attach(c1ed5d80,c1f15000,c0820d18,c0679ffa,c1f15000) at > > device_attach+0x2c9 > > bus_generic_attach(c1f15000,c1f1504c,c0820d54,c0520839,c1f15000) at > > bus_generic_attach+0x18 > > John, perhaps this is the problem. pci_add_child is attempting to route > interrupts. However, if the link device is under the PCI bus device, it > may not have a handle/device association yet. I thought you said we did all the handle/device associations earlier before we probed any ACPI devices? (Which would include pcib0 - the Host-PCI bridge). > acpi_pci_attach(): > /* Add pci children and route interrupts */ > pci_add_children(dev, busno, sizeof(struct acpi_pci_devinfo)); > > /* Whoops, haven't assigned handles for link devices > * under "dev" yet! */ > AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1, > acpi_pci_save_handle, dev, NULL); Note that this function is called when pci0 is attached. pci0 is attached when pcib0 calls bus_generic_attach() in its attach routine: /* * Now go scan the bus. */ prt_walk_table(prt, prt_attach_devices, dev); return_VALUE (bus_generic_attach(dev)); Note that we force-attach all the referenced link devices via prt_attach_devices before pci0 gets its probe and attach routines called, and thus before pci_add_children() is called. > Pawel, can you send a link to your asl? acpidump -t -d > pawel.asl > I expect we'll see something like this: > > Device (PCI0) > Method (_PRT) > [reference to LNK0] > Device (LNK0) > Device (USB0) > > My question is why is pci_add_child() routing interrupts? That should > be done in the attach method for the PCI bus, before probing/attaching > children, not when the child devices are being added. I think we'll > have to split this into two separate steps: pci_add_children(), set up > device/handle associations, pci_init_children(). The last function > would do the irq routing. PCi allocates any resources already enabled in a PCI device via the bus when the device is added, and doing an alloc_resource() of an IRQ causes it to be routed. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org