On Friday 07 January 2005 05:07 pm, Pawel Worach wrote: > Nate Lawson wrote: > > Pawel, can you split out the lines so we can isolate where the panic is > > occurring? At the end of acpi_pcib.c, before the call to > > acpi_pci_link_route_interrupt(), add: > > > > { > > device_t foo = acpi_get_device(lnkdev); > > printf("acpi handle %p, name %s\n", lnkdev, lnkdev? acpi_name(lnkdev) : > > "none"); > > printf("link device: %p index %d\n", foo, prt->SourceIndex); > > printf("device parent %s, state %x\n", > > device_get_nameunit(device_get_parent(foo)), device_get_state(foo)); > > } > > Doesn't look like device_get_state() likes this device either. Is something > strange with the trace below? I'm certain I added the printf's right above > http://fxr.watson.org/fxr/source/dev/acpica/acpi_pcib.c#L257 so shouldn't > there be a frame with acpi_pcib_route_interrupt() in between the > device_get_state() and acpi_pcib_acpi_route_interrupt() frames? > > acpi_MatchHid() Hid: PNP0A03 > acpi_MatchHid() Hid: PNP0A03 > pcib0: <ACPI Host-PCI bridge> on acpi0 > pci0: <ACPI PCI bus> on pcib0 > acpi handle 0xc1ec8d20, name \LPUS > link device: 0 index 0 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. The stack trace weirdness appears to be a recently added(?) bug in ddb in that it now sometimes skips over some frames. :( -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orgReceived on Fri Jan 07 2005 - 21:27:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC