On Tue, Feb 18, 2014 at 02:28:55PM -0500, Prarit Bhargava wrote:
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.
If the system firmware is sending messages then the default assumption
ought to be that it's doing so for a reason.
Maybe that can be solved through an 'ipmi=off' option, or
maybe off should be
the default state for handling of these messages?
You can disable the various ipmi_si probings via the tryacpi, trydmi and
so on options.
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.
Sending enough traffic to keep kipmid at 100% for extended periods of
time implies that there's a *lot* of traffic appearing. What's sending
it, and why? What kind of responses are expected? Is the fact that we're
sending nothing back upsetting it?
--
Matthew Garrett | mjg59(a)srcf.ucam.org