From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 22:27:50 2005 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 8FE9716A4CE for ; Fri, 7 Jan 2005 22:27:50 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 303BD43D1F for ; Fri, 7 Jan 2005 22:27:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13885 invoked from network); 7 Jan 2005 22:27:50 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 7 Jan 2005 22:27:46 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j07MRbx2091869; Fri, 7 Jan 2005 17:27:41 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Pawel Worach Date: Fri, 7 Jan 2005 17:28:16 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DEED05.4040000@root.org> <41DF0839.6040700@telia.com> In-Reply-To: <41DF0839.6040700@telia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501071728.16828.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: Nate Lawson 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: Fri, 07 Jan 2005 22:27:50 -0000 On Friday 07 January 2005 05:07 pm, Pawel Worach wrote: > Nate Lawson wrote: > > Pawel, can you split out the lines so we can isolate where the panic is > > occurring? At the end of acpi_pcib.c, before the call to > > acpi_pci_link_route_interrupt(), add: > > > > { > > device_t foo = acpi_get_device(lnkdev); > > printf("acpi handle %p, name %s\n", lnkdev, lnkdev? acpi_name(lnkdev) : > > "none"); > > printf("link device: %p index %d\n", foo, prt->SourceIndex); > > printf("device parent %s, state %x\n", > > device_get_nameunit(device_get_parent(foo)), device_get_state(foo)); > > } > > Doesn't look like device_get_state() likes this device either. Is something > strange with the trace below? I'm certain I added the printf's right above > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pcib.c#L257 so shouldn't > there be a frame with acpi_pcib_route_interrupt() in between the > device_get_state() and acpi_pcib_acpi_route_interrupt() frames? > > acpi_MatchHid() Hid: PNP0A03 > acpi_MatchHid() Hid: PNP0A03 > pcib0: on acpi0 > pci0: on pcib0 > acpi handle 0xc1ec8d20, name \LPUS > link device: 0 index 0 So it appears the handle doesn't have a device_t associated with it. :( The next step is to maybe do a printf in the code that adds the device_t's to see if one shows up for this handle, and if the handle is the same for the given name. The stack trace weirdness appears to be a recently added(?) bug in ddb in that it now sometimes skips over some frames. :( -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org