From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 04:14:10 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 0CBD516A4CE; Sat, 8 Jan 2005 04:14:10 +0000 (GMT) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E0A43D1D; Sat, 8 Jan 2005 04:14:09 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: from [127.0.0.1] (81.225.14.129) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.6) (authenticated as u86211448) id 4199C6960003A661; Sat, 8 Jan 2005 05:13:37 +0100 Message-ID: <41DF5DEA.3030904@telia.com> Date: Sat, 08 Jan 2005 05:13:30 +0100 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0 (X11/20041223) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DEED05.4040000@root.org> <41DF0839.6040700@telia.com> <200501071728.16828.jhb@FreeBSD.org> <41DF2BB3.60800@root.org> <41DF347E.6010305@telia.com> <41DF5159.1090106@root.org> In-Reply-To: <41DF5159.1090106@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: John Baldwin 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: Sat, 08 Jan 2005 04:14:10 -0000 Nate Lawson wrote: > Are you sure you put the printf _after_ AcpiAttachData? It's surprising > that none of the handles has a device attached. This is not the primary > problem but is something we need to fix if you put the printf in the > right spot. sys/dev/acpica/acpi.c:acpi_probe_child() around line 1529 /* Associate the handle with the device_t and vice versa. */ acpi_set_handle(child, handle); AcpiAttachData(handle, acpi_fake_objhandler, child); printf("adding child %s, dev %p\n", acpi_name(handle), acpi_get_device(child)); >> adding child \_SB_.PCI1, dev 0 >> adding child \_SB_.PCI2, dev 0 >> adding child \_SB_.PCI3, dev 0 >> adding child \_SB_.PCI4, dev 0 >> acpi0: reservation of 460, 2 (4) failed >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 >> cpu0: on acpi0 >> cpu1: on acpi0 >> pcib0: on acpi0 >> pci0: on pcib0 >> acpi handle 0xc1ec8d20, name \LPUS >> link device: 0 index 0 > > > Ok, I also know what the main issue is. Your link devices are in \ but > it's invalid to have devices outside of \_SB. We only scan a few sub > namespaces of \ (see acpi_probe_children) so your links are never > probed/attached. The workaround is to scan all of \ instead of the > subspaces. This is very wrong from the acpi standards but probably > won't hurt anything. Try the attached patch. This worked before > because we probed links directly through _PRT and the reference was > correct there, so it didn't matter that the link was in \ instead of \_SB. > > > ------------------------------------------------------------------------ > > --- acpi.c.orig 2005-01-07 19:18:56.000000000 -0800 > +++ acpi.c 2005-01-07 19:19:22.000000000 -0800 > @@ -1403,7 +1403,7 @@ > ACPI_HANDLE parent; > ACPI_STATUS status; > int i; > - static char *scopes[] = {"\\_PR_", "\\_TZ_", "\\_SI", "\\_SB_", NULL}; > + static char *scopes[] = {"\\", NULL}; > > ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); > Ok, this fixed the ACPI panic. Thank you! :) Now I'm back to the original problem with the mpt device attachment I started to investigate before, seems to be PCI and resource allocation related. (New thread about that though). -- Pawel