Re: ACPI hotplug panic with current git head

[Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>]

James Bottomley wrote:
> On Thu, 2009-01-15 at 14:54 -0500, James Bottomley wrote:
>> On Thu, 2009-01-15 at 14:22 -0500, Len Brown wrote:
>>> On Thu, 15 Jan 2009, James Bottomley wrote:
>>>
>>>> On Mon, 2009-01-12 at 18:48 -0600, James Bottomley wrote:
>>>>> On Mon, 2009-01-12 at 16:16 -0500, Len Brown wrote:
>>>>>>> This is on an IBM Maia system with the calgary IOMMU enabled. It's a
>>>>>>> fatal boot up panic.
>>>>>>>
>>>>>> James,
>>>>>> A guided bisect...
>>>>>> Please let me know which of these fail
>>>>>>
>>>>>> a3a798c88a14b35e5d4ca30716dbc9eb9a1ddfe2 is 2.6.29 at ACPI merge
>>>>>> efcb3cf7f00c3c424db012380a8a974c2676a3c8 is 2.6.29 before ACPI merge
>>>>> Didn't try these (being after the failure)
>>>>>
>>>>>> ec9f168fcc344d2ffec1c8c822076bf22dab5c33 is 2.6.28 with most ACPI
>>>>> This is the failing one.
>>>>>
>>>>>> e8443c358c34f3fe65236e24147ddf0cd0e61b08 is 2.6.28 plus just ACPICA
>>>>> This one boots fine.
>>>>>
>>>>>> Please test the "2.6.28+ACPICA" one first.
>>>>>> If it fails, we are close so you can skip the others above
>>>>>> and bisect between that and 2.6.28.
>>>>> I'll try bisecting between ec9f168fcc344d2ffec1c8c822076bf22dab5c33 and
>>>>> e8443c358c34f3fe65236e24147ddf0cd0e61b08.
>>>> OK, bisection complete.  It's not actually coming from the ACPI tree but
>>>> from the PCI one (appropriate CC's added).
>>>>
>>>> The commit causing the boot panic is:
>>>>
>>>> commit e8c331e963c58b83db24b7d0e39e8c07f687dbc6
>>>> Author: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
>>>> Date:   Wed Dec 17 12:09:12 2008 +0900
>>>>
>>>>     PCI hotplug: introduce functions for ACPI slot detection
>>>>
>>>> I'm still not sure why, though
>>> Nothing jumped out at me in the patch.
>>> Does reverting e8c331e963c58b83db24b7d0e39e8c07f687dbc6
>>> make the boot crash go away?
>> Yes, but then it would ... the call sequence is through the reverted
>> code.
> 
> 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.

Thanks,
Kenji Kaneshige


> James
> 
> ---
> 
> 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-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>