Date: Sat, 08 Jan 2005 05:13:30 +0100 From: Pawel Worach <pawel.worach@telia.com> To: Nate Lawson <nate@root.org> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt Message-ID: <41DF5DEA.3030904@telia.com> In-Reply-To: <41DF5159.1090106@root.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <ACPI CPU> on acpi0
>> cpu1: <ACPI CPU> on acpi0
>> pcib0: <ACPI Host-PCI bridge> on acpi0
>> pci0: <ACPI PCI bus> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41DF5DEA.3030904>