page fault panic in device_get_softc/acpi_pcib_route_interrupt

John Baldwin jhb at FreeBSD.org
Thu Dec 30 12:33:51 PST 2004


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.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-current mailing list