ward at gnu.org
Sat Mar 6 15:32:41 CET 2010
On Sat, Mar 06, 2010 at 01:12:51AM +0100, Carl-Daniel Hailfinger wrote:
> On 05.03.2010 19:26, ron minnich wrote:
> > What would coreboot need to do to "support" IPMI BMC?
> Depends on the IPMI BMC. If you're lucky, it works out of the box, and
> if you're unlucky, you have to implement undocumented BIOS interfaces.
> The easiest solution is to buy a card and try it, and if it doesn't
> work, reverse engineer it or try another card.
> Besides that, IPMI is a security nightmare (see the discussions on the
> linux-kernel mailing list about IPMI bypassing host network security).
Even worse - I have yet to encounter a reliable IPMI card. The sorts of
problems I've encountered are:
* specific packets can 'kill' the IPMI controller. Once the thing is hung,
the only fix is a *cold* boot of the entire machine.
* I've seen machines crash, taking the IPMI controller with them. Makes
the whole thing kind of pointless...
* general reliability issues. IPMI controllers also seem to like to hang
I really tried to make IPMI work reliably; I have an 80 machine cluster full
of these things. I wasted a ton of time on them (3 different generations from
2 vendors - Tyan and Supermicro).
I think that those issues were largely caused by extremely crappy proprietary
firmware. But there is a more fundamental issue; the IPMI BMC is pretty
tightly connected into the mainboard, by design. That's bad - how can you
guarantee that IPMI BMC will always be available, fully out of band, when it
is not 100% independent of the mainboard?
In the end I gave up; I now use serial console servers (opengear is highly
recommended) and switched PDUs (I've tried various brands, so far I like
Raritan's Dominion series the best). That works, 100% of the time.
Ward Vandewege <ward at gnu.org>
More information about the coreboot