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 themselves occasionally 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. Thanks, Ward. -- Ward Vandewege <w...@gnu.org> -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot