Date: Wed, 29 Dec 2004 15:19:34 -0800 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt Message-ID: <41D33B86.3060109@root.org> In-Reply-To: <200412291715.51125.jhb@FreeBSD.org> References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412281539.38333.jhb@FreeBSD.org> <41D1ED23.6060207@telia.com> <200412291715.51125.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41D33B86.3060109>