From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 23:19:37 2004 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 A7E6A16A4CE; Wed, 29 Dec 2004 23:19:37 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67FE843D5E; Wed, 29 Dec 2004 23:19:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBTNJZGV002630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Dec 2004 15:19:36 -0800 Message-ID: <41D33B86.3060109@root.org> Date: Wed, 29 Dec 2004 15:19:34 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412281539.38333.jhb@FreeBSD.org> <41D1ED23.6060207@telia.com> <200412291715.51125.jhb@FreeBSD.org> In-Reply-To: <200412291715.51125.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 29 Dec 2004 23:19:37 -0000 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