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. > -- PawelReceived 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