RHEL builds the ipmi_si into the kernel by default, rather than as a module, because it is required early in order to be available for ACPI opregion access. However, it appears that some of our customers have custom ipmi drivers, and this gets in their way.
Stratus is currently evaluating your suggestions, and we are expecting a response from them sometime today or early next week. On 12/13/2012 02:51 PM, Corey Minyard wrote:
Well, the built-in driver works on systems that have more than one interface and more than one BMC, and multiple IPMBs (and all of the other channel types for that matter, and the driver handles all the multiplexing and nasty addressing). There is, in fact, no arbitrary limit, and IBM tested this fairly extensively with some of their systems. I'm not sure why you would need a custom driver, and if there are some custom things that need to be done for your servers, I'd be happy to add that. I've worked with a number of other vendors to get changes like this in. And then ipmitool, freeipmi, openipmi, etc. will work with the device. I don't have a big problem with this patch. I wonder why you would want to compile the standard driver into your kernel if you expected to load a module with a custom driver later, though. None of the distros I know of compile it in, it's always a module. You can also dynamically remove the device from the driver using the hot add/remove capability. To remove it, you can do: echo remove,`cat /proc/ipmi/0/params` and it will disassociate that device (IPMI interface 0 in this case) from the driver. So you can iterate through all the devices in /proc/ipmi and remove them all at startup. If none of the above options work for you, we can go ahead with this patch. Just wanted to let you know that current options exist, and see if you wanted to take a different direction. -corey
_______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
