Hey Paul, > While re-running this, via top I do see kipmi0 using ~1% - 7% (yes, > not a good metric ;-)), but that's about it. The machine is otherwise > as snappy as usual.
The kipmi is from OpenIpmi kernel driver. So I don't think it'll have any affect on SOL. Al -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ----- Original Message ----- From: Paul Armor <[EMAIL PROTECTED]> Date: Monday, March 27, 2006 12:03 pm Subject: Re: [Openipmi-developer] Re: [Ipmitool-devel] SOL connection issue, BMC "locked up" > Hi, > > On Mon, 27 Mar 2006, Albert Chu wrote: > > > Hi Paul, > >> I'd enabled hardware flow control (as Steffen Grunewald had > described>> on the ipmitool list, thanks Steffen!) > > > > I can't remember the exact kernel internals logic/reason, but I > believe> if hardware flow control is turned on, the kernel will > spin(?) (atleast > > eat up a lot of cycles) waiting for the ability to dump data out the > > console. We've only seen this with normal serial connections, > but it > > wouldn't surprise me if the same applied for SOL. > > While re-running this, via top I do see kipmi0 using ~1% - 7% (yes, > not a > good metric ;-)), but that's about it. The machine is otherwise as > snappy > as usual. > > > If the above case happend, it would suggest ipmitool wasn't > capable of > > handling the SOL traffic quickly enough. That's unlikely. But > as you > > said, perhaps things haven't been stress tested. > > I'm not sure... one thing about these BMC's is that they use what I > think > to be ridiculously small packets (with my test, 144B)... in fact a > simple > test shows that they'll only respond to pings of <= 302B. > > > A few UDP packets lost > > here and there on the network and ipmitool not ack-ing SOL packets > > outside of a certain sequence number range could probably cause it. > > (Note, I don't know the internal logic of ipmitool for this > example, its > > just an idea.) > > Interesting. > > > >> Has anyone else done any "stress" testing and seen a BMC just fall > >> down? > > > > Never to the degree that you've stated. Although there are > situations I > > can imagine where it can happen. For example, if the maximum > number of > > Lan sessions were alive and connected to the BMC (presumably in > > background/sleeping processes you weren't aware of it), then the BMC > > could be out of resources and may not respond to additional traffic. > > But that's just a guess. > > OK, perhaps Duncan can chime in? ;-) > > > A fun black-magic trick I found with some "locked up" BMCs was to > > simultaneously ping the node w/ rmcp and ipmi at the same time. For > > some magical reason, this "unlocked" some BMCs for me. I use > 'rmcpping'> and 'ipmiping' which are in the FreeIPMI project. > > nifty! I'll see what happens, if I'm able to reproduce... > > Thanks! > Paul > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > languagethat extends applications into web and mobile media. Attend > the live webcast > and join the prime developer group breaking into this new coding > territory!http://sel.as- > us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642_______________________________________________ > Ipmitool-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/ipmitool-devel > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
