[LinuxBIOS] AMD Geode LX support for LinuxBIOS

[Ward Vandewege]

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.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator