Re: IPMI SOL and console baud rate

[Zack Brown <zrbrown%iastate.edu@localhost>]

On Mon, Feb 7, 2011 at 5:34 PM, Jonathan A. Kollasch
<jakllsch%kollasch.net@localhost> wrote:
> On Thu, Feb 03, 2011 at 04:14:15PM -0600, Zack Brown wrote:
>> Hello,
>>
>> I asked a while back about setting up IPMI Serial Over LAN on NetBSD and
>> received some help on it, but I got busy with other work and am just now
>> getting back to it.
>>
>> Through BIOS options, I can redirect BIOS output over SOL, that's been
>> working fine.  Using the advice I received previously, I used installboot to
>> change the console to com1 at a speed of 115200 (consistent with the BIOS
>> options of COM2 at 115200).  /etc/ttys has everything off except tty01 using
>> '...getty std.115200 unknown...' and constty using '...getty (Pc or
>> std.115200, doesn't seem to make a difference) vt100...'  I've also
>> uncommented screen 0 in /etc/wscons.conf.
>>
>> Using these settings, I see everything up to the bootloader, where I'm able
>> to select different boot options as I would from a regular console (using
>> consdev com1 doesn't seem to affect anything).  Once NetBSD starts booting,
>> I get all of the kernel output on the computer I'm connecting from, but it
>> suddenly cuts off at or a little after listing vendor products at pci0.  If
>> I wait until getty starts (which I can tell by seeing if ctrl+Fn does
>> anything from a keyboard/monitor connected to the server) then hard power
>> off the server, a few seconds later the rest of the kernel output plus all
>> of the NetBSD starting messages including the login: prompt on tty01 get
>> dumped to the remote computer.  However, this does not work if I wait too
>> long after getty starts - in that case nothing happens on the remote
>> computer.
>
> Interesting, almost as if some packets are getting stuck in a queue.
>
>> As far as I can tell, this looks like a speed difference problem, but I
>> don't know any other places to change the console baud rate.  If I'm right
>> in my conclusion, is there anywhere else speed can be changed?  If not, any
>> ideas what's happening?
>>
>> This is on a Dell PowerEdge R210 using NetBSD 5.1_RC4.
>>
>
> I somewhat doubt it's a baud rate issue.
>
> I'm curious, does the IPMI controller have an exclusive ethernet port?
> If it doesn't, we might need to be careful about what we do with the
> NIC it's using.

The controller doesn't have its own port, it shares.

>
> You might try playing with the SOL port when something else is the
> console device, perhaps try upping the NICs and then trying serial.
> But it's entirely possible we've reset too much of the chip by then.

Ahah!  'ifconfig -a' listed bnx0 and bnx1, which I thought was the
second ethernet port.  Turns out bnx1 is what NetBSD is recognizing
IPMI on.  So now as soon as getty runs, I quickly log in on the
physical console and run 'ifconfig bnx1 up', which causes the IPMI I/O
to immediately start working on the remote computer.

>
> Are the NICs of the wm(4) variety?  Intel has a manual that covers
> some remote management capabilities that were added to the family
> after wm(4) was originally written.
>
>        Jonathan Kollasch
>

According to the man page, yes, wm(4) is being used.

So now my only problem is waking up bnx1 automatically.  I stumbled on
this mail chain from the freebsd-stable list, which seems to concern
the same problem:
http://old.nabble.com/IPMI-Console%3A-No-luck-once-OS-is-booted-td18910013.html
In particular, this message
http://old.nabble.com/Re%3A-IPMI-Console%3A-No-luck-once-OS-is-booted-p18914044.html
mentions removing the em driver from the kernel, would this be likely
to work in NetBSD (using wm instead)?

Thanks so much for the help!
Zack