Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt

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_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org