On Thu, May 03, 2007 at 08:37:55PM +0200, Carl-Daniel Hailfinger wrote:
On 03.05.2007 19:45, Marc Jones wrote:
In the legacy/APM world power management and fan control were mostly done in SMM.
In the ACPI world that has been moved to the OS. Proper drivers and applications and SMM all play a part but SMM's role is greatly reduced and latency much less of an issue. You might also want to look at the OpenIPMI project to see how some of this is being done now. http://openipmi.sourceforge.net/IPMI.pdf
Thanks for the pointer! However, the paper suggests that an extra controller/processor is needed for IPMI. Do we have such a thing on recent x86 mainboards?
Some do. It's usually an optional component for server boards.
I have had fairly extensive dealing with IPMI on Supermicro and Tyan boards, and to be honest, these things are pathetic. There are IPMI 'standards' (v1, v1.5, v2), which never seem to be implemented properly. In my experience, the IPMI cards lock up, crash, become unresponsive, and are so poorly implemented that they often require the use of - even buggier - proprietary tools to even talk to the things; the free software ipmitool is a great piece of software, but it's hard having to work around IPMI implemenations that are broken in undocumented and unpredictable ways. Hence, getting ipmitool to work with a particular IPMI card is very much a game of hit and miss.
And don't get me started on IPMI cards sharing physical network connections with the mainboard - in some implementations they piggyback on the onboard ethernet controller and just pick up whatever traffic they need from the wire, whereas on other boards they actually have a separate ethernet controller on the same socket (!). Of course one can configure the mac and ip address for the IPMI card in *all* the implementations I've seen, leading to interesting situations where sometimes the mac address for the IPMI card *has* to be the same as the one for the onboard ethernet interface, and sometimes it *may not* be the same.
Best of all - the whole point of IPMI is out of band management of machines. Get this: I've seen machines crash *and take the IPMI daughterboard with them*. IPMI daugtherboards obviously rely on some parts of the host system to remain in a non-locked up state, which kind of goes against the whole point of having IPMI in the first place...
On paper, IPMI is a great idea. The implementations I've seen suck royally. Proprietary software...
Thanks, Ward.