Date: Wed, 5 Jan 2005 17:31:32 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt Message-ID: <200501051731.32915.jhb@FreeBSD.org> In-Reply-To: <41D8935F.20505@root.org> References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412301527.07327.jhb@FreeBSD.org> <41D8935F.20505@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501051731.32915.jhb>