Re: IPMI SOL and console baud rate

["Jonathan A. Kollasch" <jakllsch%kollasch.net@localhost>]

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)?

> 
> 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