Date: Thu, 6 Jan 2005 15:41:39 -0500 From: John Baldwin <jhb@FreeBSD.org> To: Pawel Worach <pawel.worach@telia.com> Cc: Nate Lawson <nate@root.org> Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt Message-ID: <200501061541.39673.jhb@FreeBSD.org> In-Reply-To: <41DD9806.6060301@telia.com> References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200501061345.44146.jhb@FreeBSD.org> <41DD9806.6060301@telia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 06 January 2005 02:56 pm, Pawel Worach wrote:
> John Baldwin wrote:
> > On Wednesday 05 January 2005 06:02 pm, Nate Lawson wrote:
> >>John Baldwin wrote:
> >>>On Sunday 02 January 2005 07:35 pm, Nate Lawson wrote:
> >>>>We already associate handles and devices in
> >>>>sys/dev/acpica/acpi.c:acpi_probe_child() before probing anything. See
> >>>>the AcpiAttachData() step. I don't think that's the problem.
> >>>
> >>>I do because he passes a null device_t pointer in as an argument to a
> >>>function. The calling code is:
> >>>
> >>> /*
> >>> * We have to find the source device (PCI interrupt link device).
> >>> */
> >>> if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source,
> >>>&lnkdev))) { device_printf(pcib, "couldn't find PCI interrupt link
> >>> device %s\n", prt->Source);
> >>> interrupt = acpi_pci_link_route_interrupt(acpi_get_device(lnkdev),
> >>> prt->SourceIndex);
> >>>
> >>>And Pawel's trace shows that the first argument to
> >>>acpi_pci_link_route_interrupt() is NULL.
> >>
> >>What's the value of prt->Source? If it's not a valid reference to a
> >>link device (i.e. \_SB.PCIx.LNKx), then trying to get a device_t from it
> >>would yield NULL. For instance, if it points to \_SB, you'll get a
> >>valid handle from AcpiGetHandle but that handle obviously has no
> >>associated device_t.
> >>
> >>Additionally, I see you're using the root handle ACPI_ROOT_OBJECT as the
> >>base for lookup. If the reference is relative (doesn't start with \),
> >>this won't work. You should be using the handle of the parent of _PRT
> >>(the PCI bus handle) as the root of the lookup. Commonly, this will be
> >>something like a \_SB.PCI0 string.
> >>
> >>This would fix this scenario:
> >>\_SB.PCI0
> >> _PRT (Source = LNKA)
> >> LNKA
> >> LNKB
> >
> > Ok, that might be it. I'll work up a patch to use the relative roots
> > instead. In fact, the patch is very simple. It already used relative
> > lookups when force-attaching the link devices during attach. Pawel, the
> > change is this:
> >
> > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c 2004/12/27
> > 05:40:30 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pcib.c 2005/01/06
> > 18:40:54 @@ -249,7 +249,8 @@
> > /*
> > * We have to find the source device (PCI interrupt link device).
> > */
> > - if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source,
> > &lnkdev))) {
> > + if (ACPI_FAILURE(AcpiGetHandle(acpi_get_handle(pcib), prt->Source,
> > + &lnkdev))) {
> > device_printf(pcib, "couldn't find PCI interrupt link device %s\n",
> > prt->Source);
> > goto out;
>
> CURRENT from 16:00 UTC and the patch above seems to result in the same
> thing :(
>
> Copyright (c) 1992-2005 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD 6.0-CURRENT #0: Thu Jan 6 20:31:16 CET 2005
> root@zero:/usr/obj/usr/src/sys/ZERO
> ...
> 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
The fact that the source is '\LPUS' is bothersome, it should probably just be
'LPUS' (without the leading slash). Do you have your acpidump somewhere
where we can look at it? Also, is there a BIOS upgrade available?
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501061541.39673.jhb>