Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt

From: Pawel Worach <pawel.worach_at_telia.com>
Date: Thu, 06 Jan 2005 20:56:54 +0100
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
> _at__at_ -249,7 +249,8 _at__at_
>      /*
>       * 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_at_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
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc051f487
stack pointer           = 0x10:0xc0820958
frame pointer           = 0x10:0xc082096c
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> tr
Tracing pid 0 tid 0 td 0xc06ef960
device_get_softc(c07de4a0,c07d99cd,355,c1e841c0,c1e841c0) at device_get_softc+0x7
acpi_pci_link_route_interrupt(0,0,c0820a24,c0820a2c,41) at 
acpi_pci_link_route_interrupt+0x3a
acpi_pcib_route_interrupt(c1f16d00,c1f8b780,1,c1f7e1f4,1) at 
acpi_pcib_route_interrupt+0x3a1
acpi_pcib_acpi_route_interrupt(c1f16d00,c1f8b780,1,c06c7f10,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,c052188f) at pci_add_children+0x123
acpi_pci_attach(c1f16a00,c1f4484c,c06c14ec,c06aa680,0) at acpi_pci_attach+0x86
device_attach(c1f16a00,c1ed5d80,c0820bdc,c07c538c,c1f16d00) at device_attach+0x2c9
bus_generic_attach(c1f16d00,c07d92a7,0,c0820bcc,0) at bus_generic_attach+0x18
acpi_pcib_attach(c1f16d00,c1f7e1f4,0,c0820c04,c07bff97) at acpi_pcib_attach+0xec
acpi_pcib_acpi_attach(c1f16d00,c1f4384c,c06c14ec,c06aa680,0) at 
acpi_pcib_acpi_attach+0xf9
device_attach(c1f16d00,2f,c0820cbc,c07c27c4,c1ed5d80) at device_attach+0x2c9
bus_generic_attach(c1ed5d80,2e,2f,c1f7dc28,2e) at bus_generic_attach+0x18
acpi_attach(c1ed5d80,c1f4604c,c06c14ec,c06aa680,0) at acpi_attach+0x7b4
device_attach(c1ed5d80,c1f15000,c0820d18,c0679ffa,c1f15000) at device_attach+0x2c9
bus_generic_attach(c1f15000,c1f1504c,c0820d54,c0520839,c1f15000) at 
bus_generic_attach+0x18
nexus_attach(c1f15000,c1f3c04c,c06c14ec,c06aa680,0) at nexus_attach+0x1a
device_attach(c1f15000,c06dda30,c0820d78,c06670d8,c1f15680) at device_attach+0x2c9
root_bus_configure(c1f15680,c06bb361,0,c0820d98,c04d1126) at root_bus_configure+0x19
configure(0,0,c1e6f774,81ec00,81e000) at configure+0x28
mi_startup() at mi_startup+0xd6
begin() at begin+0x2c
db>

> 
>>Also, I'm not sure if you picked up the size issue with the _PRT struct
>>supplied by ACPI-CA.  Since Source is a variable-length string, if you
>>copy the struct you get from AcpiGetRoutingTable (or whatever), you only
>>get the first 4 bytes, non-null terminated, of the string.
>>
>>typedef struct acpi_pci_routing_table
>>{
>>     UINT32                      Length;
>>     UINT32                      Pin;
>>     ACPI_INTEGER                Address;
>>     UINT32                      SourceIndex;
>>     char                        Source[4];
>>} ACPI_PCI_ROUTING_TABLE;
>>
>>Note that Source above is not 4 bytes, it's variable-length.  That's why
>>I copied it to a different field in the old acpi_pci_link PRT struct.
> 
> 
> I don't ever store the Source anywhere, I just use it to lookup handles, so I 
> don't have to worry about the size change.
> 

-- 
Pawel
Received on Thu Jan 06 2005 - 18:57:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC