On Thu, Feb 20, 2014 at 08:16:22PM +0000, Matthew Garrett wrote: > On Thu, 2014-02-20 at 14:14 -0600, Russ Anderson wrote: > > > The distro that added this change created all sorts of support > > problems. Problems include kipmi0 spinning at 100% of cpu > > (creating a performance hit) and long boot delays (as the > > kernel tries to talk to a BMC that will never respond). > > It has been a big mess. > > Why is the BMC not responding? Why is kipmi0 at 100%? Why are we not > fixing those bugs? Why build a driver into the kernel? The reason ipmi_si is a driver is so systems that want it can load it and systems that do not want it do not have to load it. Plus you can stop/start modules without rebooting. You can change module parameters without rebooting. There are any number of reasons why a BMC may not respond. BMCs are notorious for being flakey, with different types of BMCs that may or may not be reliable. You do not want to make the kernel boot dependent on an unreliable component. This is also a problem for systems with functional BMCs. Our large cluster systems do all IPMI traffic (monitoring) through a system controller back door. We do not want the kernel doing IPMI commands on those systems. On those systems we simply do not load the ipmi_si module. Building ipmi_si into the kernel means adding kernel boot line options to turn ipmi_si back off again. -- Russ Anderson, Kernel and Performance Software Team Manager SGI - Silicon Graphics Inc rja@xxxxxxx -- 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
