> > It looks like acpi_pci_get_bridge_handle() is returning NULL, so this is
> > the fix that works for me.
> >
>
> I'm sorry for troubling you, and thank you for your patience.
>
> The patch seems to avoid the kernel panic, but I still don't know
> why acpi_pci_get_bridge_handle() returns NULL here. I assumed
> it should return non-NULL value here. So I'd like to investigate
> it more.
>
Kenji,
I'd like to push jejb's 1-liner upstream now.
It make sense, and it prevents a boot panic regression
that I'd rather not have others experience in rc2.
I agree that it is important to hotplug for you to figure out
why this machine runs down that path in the first place,
and I'm sure that James will continue to work with you
on that after the 1-liner is in.
thanks
Len Brown, Intel Open Source Technology Center
> >
> > diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
> > index f09b101..803d9dd 100644
> > --- a/drivers/pci/hotplug/acpiphp_glue.c
> > +++ b/drivers/pci/hotplug/acpiphp_glue.c
> > @@ -266,6 +266,8 @@ static int detect_ejectable_slots(struct pci_bus *pbus)
> > int found = acpi_pci_detect_ejectable(pbus);
> > if (!found) {
> > acpi_handle bridge_handle = acpi_pci_get_bridge_handle(pbus);
> > + if (!bridge_handle)
> > + return 0;
> > acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge_handle, (u32)1,
> > is_pci_dock_device, (void *)&found, NULL);
> > }
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
