I have a 1950-III 1U on the floor here that I'm loading. After configuring
IPMI in the BIOS, I can:
[2:6:306]root@strike:~> ipmitool -I lanplus -U root -H 192.168.221.160 shell
Password:
ipmitool> power on
Chassis Power Control: Up/On
Now. strike is not the 1U in question... and does not, in fact, have IPMI of
it's own, but it can talk to the 1950-III, but...
[1:1:301]root@test1:~> dmesg | grep ipmi
ipmi0: KCS mode found at io 0xca8 on acpi
ipmi0: KCS error: ff
ipmi1: <IPMI System Interface> on isa0
device_attach: ipmi1 attach returned 16
ipmi0: IPMI device rev. 0, firmware rev. 2.2, version 2.0
ipmi0: Number of channels 4
ipmi0: Attached watchdog
... and it will respond to local use of the ipmi tool.
Serial console works --- although it seems like it has a finite buffer and
too much output overflows the buffer (flow control doesn't seem to fix
this). You also have to custom compile the kernel and boot blocks to use
COM2 (sio1) as the console. The BIOS seems to have settings to make the
external serial port COM2 and use COM1 for IPMI, but the settings don't
work. You need to use COM2. While you're at it, the default speed is 57600
(might as well compile in that default, too).
The R200's that I have also seem to work fine. I haven't tested serial
consoles with them --- but it's on the list.
Curiously, IPMI shares the ethernet ports with the onboard ethernet
controllers without FreeBSD's knowledge. It does use a different MAC
address. It is also apparently capable of using vlans (haven't tested this
yet). I'm most nervous about how this might behave if the port was being
nailed with traffic --- but I can't easily test this to my satisfaction.
What controls the contention for the port between whatever IPMI magic is
going on and the OS use of the port?
Anyways... the really cool thing about IPMI is that it's cheap enough to be
included. The original poster spoke of a PCI card (likely one of the
management cards) --- these are expensive options --- especially if you
don't need graphics or remote media.