page fault panic in device_get_softc/acpi_pcib_route_interrupt

[John Baldwin]

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