[PATCH] Build in IPMI on x86

Prarit Bhargava prarit at redhat.com
Tue Feb 18 19:28:55 UTC 2014


On 02/18/2014 11:55 AM, Matthew Garrett wrote:
> On Tue, Feb 18, 2014 at 11:51:58AM -0500, Josh Boyer wrote:
>> On Tue, Feb 18, 2014 at 04:46:16PM +0000, Matthew Garrett wrote:
>>> The ACPI IPMI driver implements IPMI operation region support for the 
>>> ACPI core. Systems that declare ACPI operation regions may reference 
>>> them at any time, including during kernel initialisation. These accesses 
>>> will fail unless the ACPI IPMI driver is present, and undesirable system 
>>> behaviour may result. This can be avoided by building in the code rather 
>>> than leaving it as modules.
>>
>> Undesirable behavior how?  System crashes, random scribblings on kernel
>> memory, or just a lack of IPMI support?
> 
> Random scribblings or crashes are unlikely, and the system will probably 
> *boot*, but there's a chance of degraded functionality and it's not 
> necessarily a configuration tested by the vendor. The most likely 
> outcome is some errors on boot and then things carry on working.
> 
>> I'm not doubting your conclusions, but I'm curious why this is a problem
>> now when we've had the drivers set as modules for 2 years.  I can't
>> recall any major problems.
> 
> To an extent it's a correctness issue - the spec says this functionality 
> should be availble, we should ensure that it's actually available. The 
> fact that IPMI is only typically present on server systems probably also 
> limits the feedback we'd get.
> 

Matthew,

The problem is that we've seen users (especially those using clusters) who do
not want ipmi built in.  Their systems generate a tonne of ipmi traffic on their
systems which they want to ignore.  Building IPMI into the kernel results in
situations where processing these messages causes kipmi to climb to 100% for
long periods of time.

Maybe that can be solved through an 'ipmi=off' option, or maybe off should be
the default state for handling of these messages?

In any case, I think you're going down the right path here by building this into
the kernel but IMO there's still some upstream work to do so that we don't hit
users with 100% kipmi usage and no way of avoiding it.

P.


More information about the kernel mailing list