Re: acpi_find_bmc() and acpi_get_table()

From: Corey Minyard <minyard@acm.org>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jordan_Hargrave@dell.com, linux-acpi@vger.kernel.org,
	Matt_Domsch@dell.com, alexey.y.starikovskiy@linux.intel.com,
	openipmi-developer@lists.sourceforge.net, lenb@kernel.org
Subject: Re: acpi_find_bmc() and acpi_get_table()
Date: Fri, 20 Jul 2007 09:11:15 -0500	[thread overview]
Message-ID: <46A0C283.7020906@acm.org> (raw)
In-Reply-To: <200707181319.41081.bjorn.helgaas@hp.com>

I"m not sure how close we are on this, but I'm getting ready to release 
the 2.6.22 version of the driver, and I'd really like to get this in for 
testing if possible.  Jordan, do you have any idea on how long it will 
be before this is resolved?

-corey

Bjorn Helgaas wrote:
> On Wednesday 18 July 2007 10:49:58 am Jordan_Hargrave@dell.com wrote:
>   
>> I've done some more investigating on this and found why this works
>> in RHEL5 but not other releases (RHEL4/SLES9/SLES10). 
>>
>> The acpi motherboard driver is claiming all devices with _HID or
>> _CID of PNP0C01.  Our BIOS declares the IPI0001 with a _CID of
>> PNP0C01, so the acpi motherboard driver normally claims it.  When
>> the IPMI driver loads it can't find the IPI0001 device as it is
>> already claimed.    
>>     
>
> I think this is dumb.  PNP0C01 is a generic "system board" identifier
> with no clear programming model that I can see.  What good does it
> do to have a _CID of PNP0C01?  The only useful thing that happens in
> Linux is that the "motherboard" driver claims PNP0C01 devices and
> reserves their resources.  But PNP ought to reserve the resources of
> *all* active devices, even if no driver claims them.
>
> So I think this sounds like a BIOS defect.  Of course, I'm sure it's
> already in the field, so even if we agree that it's a BIOS problem,
> we'd have to work around it in Linux.  What if we had some sort of
> quirk that removes that _CID?
>
>   
>> In RHEL5 there was a change made to the acpi motherboard driver to
>> not attach if any of the _CRS values are not I/O ports.
>>     
>
> Yes.  This is part of linux-2.6-x86_64-memory-hotplug.patch, and it
> apparently helps fix a bug:
>   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208445,
> But I can't read the bugzilla, so I don't know exactly how.  I suspect
> some hot-addable memory device also had a _CID of PNP0C01, and they
> had the same problem you now have with IPMI.
>
> But making the motherboard driver ignore devices if they have any
> non-I/O port resources seems like the wrong fix.
>
>   
>> Technically the only reason it is working in RHEL5 is due to the
>> bug of the motherboard driver not attaching. 
>>     
>
> Right.  I'm sure you've noticed that the ACPI motherboard driver has
> been removed completely upstream.  It's been replaced by the PNP
> "system" driver, which claims all PNP0C01 and PNP0C02 devices regardless
> of what sort of resources they have.
>
>   
>> So using acpi_bus_register_driver looks like it won't work as a general solution.
>> I'm investigating walking the whole namespace to detect the IPI0001 device.
>>     
>
> I think we should make acpi_bus_register_driver() work.  It looks like
> we already have two cases (IPMI and memory hotplug), so I'd like to
> have a general solution rather than a collection of workarounds.
>
> Bjorn
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/