From owner-freebsd-current@FreeBSD.ORG Sat Jan 8 03:20:22 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 62DA416A4CE; Sat, 8 Jan 2005 03:20:22 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0356643D2D; Sat, 8 Jan 2005 03:20:22 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-95.dsl.snfc21.pacbell.net [64.171.186.95]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j083KGGV032726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Jan 2005 19:20:20 -0800 Message-ID: <41DF5159.1090106@root.org> Date: Fri, 07 Jan 2005 19:19:53 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Worach 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> In-Reply-To: <41DF347E.6010305@telia.com> Content-Type: multipart/mixed; boundary="------------040409010109020501010009" 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 03:20:22 -0000 This is a multi-part message in MIME format. --------------040409010109020501010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pawel Worach wrote: > Nate Lawson wrote: > >> John Baldwin wrote: >>> 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. >> >> Ok, add this to acpi.c:acpi_add_child(), after AcpiAttachData(): >> >> printf("adding child %s, dev %p\n", acpi_name(handle), >> acpi_get_device(child)); >> >> Then send the output. >> > > real memory = 1073590272 (1023 MB) > avail memory = 1046142976 (997 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic2 irqs 32-47 on motherboard > ioapic1 irqs 16-31 on motherboard > ioapic0 irqs 0-15 on motherboard > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > adding child \_PR_.CPU1, dev 0 > adding child \_PR_.CPU0, dev 0 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. > adding child \_SB_.PCI0, dev 0 > adding child \_SB_.PCI0.ISA_, dev 0 > adding child \_SB_.PCI0.ISA_.SIOM, dev 0 > adding child \_SB_.PCI0.ISA_.PS2K, dev 0 > adding child \_SB_.PCI0.ISA_.PS2M, dev 0 > adding child \_SB_.PCI0.ISA_.FDC0, dev 0 > adding child \_SB_.PCI0.ISA_.COM1, dev 0 > adding child \_SB_.PCI0.ISA_.COM2, dev 0 > adding child \_SB_.PCI0.ISA_.PIC_, dev 0 > adding child \_SB_.PCI0.ISA_.DMA0, dev 0 > adding child \_SB_.PCI0.ISA_.TMR_, dev 0 > adding child \_SB_.PCI0.ISA_.RTC_, dev 0 > adding child \_SB_.PCI0.ISA_.SPKR, dev 0 > adding child \_SB_.PCI0.ISA_.COPR, dev 0 > adding child \_SB_.PCI0.ISA_.SBD1, dev 0 > adding child \_SB_.PCI0.USB0, dev 0 > adding child \_SB_.PCI0.CI10, dev 0 > adding child \_SB_.PCI0.CI12, dev 0 > adding child \_SB_.PCI0.CI20, dev 0 > adding child \_SB_.PCI0.CI22, dev 0 > 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. -- Nate --------------040409010109020501010009 Content-Type: text/plain; name="acpi_scopes.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_scopes.diff" --- 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__); --------------040409010109020501010009--