From owner-freebsd-current@FreeBSD.ORG Wed Dec 29 22:15:38 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 2EB9516A4CE for ; Wed, 29 Dec 2004 22:15:38 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5B3C43D67 for ; Wed, 29 Dec 2004 22:15:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2448 invoked from network); 29 Dec 2004 22:15:37 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 29 Dec 2004 22:15:37 -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 iBTMFN34005110; Wed, 29 Dec 2004 17:15:24 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Pawel Worach Date: Wed, 29 Dec 2004 17:15:51 -0500 User-Agent: KMail/1.6.2 References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200412281539.38333.jhb@FreeBSD.org> <41D1ED23.6060207@telia.com> In-Reply-To: <41D1ED23.6060207@telia.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200412291715.51125.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: njl@FreeBSD.org 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 22:15:38 -0000 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? > found-> vendor=0x1166, dev=0x0212, revid=0x93 > bus=0, slot=15, func=1 > class=01-01-82, hdrtype=0x00, mfdev=1 > cmdreg=0x0155, statreg=0x0200, cachelnsz=8 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 1, range 32, base febfe000, size 12, enabled > rman_reserve_resource: request: [0xfebfe000, > 0xfebfefff], length 0x1000, flags 0, device (null) > considering [0xfe000000, 0xfebfefff] > truncated region: [0xfebfe000, 0xfebfefff]; size 0x1000 (requested 0x1000) > candidate region: [0xfebfefff, 0xfebfe000], size 0x1000 > allocating at the end > pcib0: matched entry for 0.15.INTA (src \LPUS:0) > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x48 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc051edc7 > stack pointer = 0x10:0xc082095c > frame pointer = 0x10:0xc0820970 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at device_get_softc+0x7: movl 0x48(%eax),%eax > db> trace > Tracing pid 0 tid 0 td 0xc06ef1e0 > device_get_softc(c07dd4a0,c07d894d,355,c1e841c0,c1e841c0) at > device_get_softc+0x7 acpi_pci_link_route_interrupt(0,0,c0820a28,f,41) at > acpi_pci_link_route_interrupt+0x3a > acpi_pcib_route_interrupt(c1f16d00,c1f8b780,1,c1f7e214,1) at > acpi_pcib_route_interrupt+0x33c > acpi_pcib_acpi_route_interrupt(c1f16d00,c1f8b780,1,c06c7850,c1f8b808) at > acpi_pcib_acpi_route_interrupt+0x2f > pci_assign_interrupt_method(c1f16a00,c1f8b780,f,2,24) at > pci_assign_interrupt_method+0x71 > pci_add_child(c1f16a00,c1f8b800,f,2,80) at pci_add_child+0x207 > pci_add_children(c1f16a00,0,80,c0820b54,c05211cf) at pci_add_children+0x123 > acpi_pci_attach(c1f16a00,c1f4484c,c06c0e3c,c06aa034,0) at > acpi_pci_attach+0x86 > device_attach(c1f16a00,c1ed5d80,c0820bdc,c07c435c,c1f16d00) at > device_attach+0x2c9 bus_generic_attach(c1f16d00,c07d8227,0,c0820bcc,0) at > bus_generic_attach+0x18 > acpi_pcib_attach(c1f16d00,c1f7e214,0,c0820c04,c07bef67) at > acpi_pcib_attach+0xec > acpi_pcib_acpi_attach(c1f16d00,c1f4384c,c06c0e3c,c06aa034,0) at > acpi_pcib_acpi_attach+0xf9 > device_attach(c1f16d00,2f,c0820cbc,c07c1794,c1ed5d80) at > device_attach+0x2c9 bus_generic_attach(c1ed5d80,2e,2f,c1f7dc48,2e) at > bus_generic_attach+0x18 acpi_attach(c1ed5d80,c1f4604c,c06c0e3c,c06aa034,0) > at acpi_attach+0x7b4 > device_attach(c1ed5d80,c1f15000,c0820d18,c06799ca,c1f15000) at > device_attach+0x2c9 > bus_generic_attach(c1f15000,c1f1504c,c0820d54,c0520179,c1f15000) at > bus_generic_attach+0x18 > nexus_attach(c1f15000,c1f3c04c,c06c0e3c,c06aa034,0) at nexus_attach+0x1a > device_attach(c1f15000,c06dd2b0,c0820d78,c0666aa8,c1f15680) at > device_attach+0x2c9 > root_bus_configure(c1f15680,c06bacbe,0,c0820d98,c04d09c6) at > root_bus_configure+0x19 configure(0,0,c1e6f774,81ec00,81e000) at > configure+0x28 > mi_startup() at mi_startup+0xd6 > begin() at begin+0x2c -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org