Re: IPMI SOL and console baud rate

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

On Tue, Feb 8, 2011 at 6:40 PM, Jonathan A. Kollasch
<jakllsch%kollasch.net@localhost> wrote:
> On Tue, Feb 08, 2011 at 06:19:59PM -0600, Zack Brown wrote:
>> 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.
>
> Not bnx(4)?

Whoops, my bsd-newbieness is showing :).  Yeah, I guess I'm using bnx(4).

>
>>
>> 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)?
>
> I think the general idea would be to whitelist the NIC that doesn't have
> the IPMI SOL console running on it in the kernel config(5) file.
>
> Something like appending:
>
> no bnx* at pci?
> bnx0 at pciX dev Y function Z
> (where X Y and Z are appropriate for the bnx(4) that isn't the console)
>
> (And then of course recompiling.)
>
> But ideally, the solution is to not down the interface when we attach it...
>
>> Thanks so much for the help!
>
> You're welcome.
>
>        Jonathan Kollasch
>

After I sent the mail, I messed around with /etc/rc.conf.  It turns
out I can get it to work by adding 'ifconfig_bnx1=[inet addr, netmask,
media autoselect]" to rc.conf.  This still causes the freeze partway
through the kernel output, but it all gets spit out as soon as getty
starts.  I'm thinking the freeze is probably remedied by modifying the
kernel config like you said above.  This has really helped me out a
lot, thank you again!

Zack