On Friday, January 16, 2009 12:08 pm Len Brown wrote:
> > > 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);
> > > }
Agreed. It's funky that we're getting back a NULL here, but we definitely
don't want people's machines to crash while we figure out what's going
wrong...
--
Jesse Barnes, Intel Open Source Technology Center
--
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
