Hi, On Fri, Mar 29, 2013 at 10:49:48AM -0700, Albert Chu wrote: > A) It seems you are using a console manager of some sort. We use Conman > here and have never seen this issue. Is it possible the console manager > is doing something to send the breaks/sysrqs?
We're using conserver. I seriously doubt the latter is to blame, as we've never seen this using ipmitool. > Note that I am aware of two console managers (Conman & Conserver) that > have "native" IPMI console support via FreeIPMI's libipmiconsole > library. So if you use one of those, you wouldn't have to run > 'ipmitool' or 'ipmiconsole' in a separate process. Conserver doesn't support IPMI. Good to know Conman does, though. > B) The default escape character in ipmiconsole is '&', which may not > match with whatever the console manager wants to use or would expect? I > think ipmitool's is '~'. Conserver uses a very long escape sequence, which is IMHO a good idea as it reduces the chances to accidentally send a break sequence. As for our previous setup, we were using '[' for the ipmitool sequence, but conserver doesn't actually know/care about it. This being said, I don't think this is relevant, as the SysRq were sent without anyone attached to the consoles, so the break must have been sent internally, I guess. > C) You note there was a lot of garbage when you switched from ipmitool > to ipmiconsole. It is possible (depending on many factors) that > ipmiconsole was receiving packets from the previous ipmitool's console > session. The garbage is corrupted b/c ipmiconsole doesn't have the > right information to decrypt the data. This can have unexpected side > affects. This is what I was thinking, as ipmiconsole tries to stop the existing connection. Maybe it wrongly assumes the latter is consumed by another ipmiconsole process? Moreover, I think this is a bug: freeipmi really shouldn't send data without any user input, should it? > Do you continue to see this garbage on subsequent reboots? If not, it > may have been a one-time problem. No, after reboot all was fine, although it lasted quite long as one of the servers was found in the boot configuration screen of its RAID adapter. We were lucky the garbage didn't reconfigure the ARRAY using random characters (or the complete works of William Shakespeare for that matter). > Those are just some ideas. Thanks for looking into this. Maybe there is some evidence in the routine handling the disconnection in the code. Oh, and the two servers this happened on were IBM (3550 and 3650). Cheers _______________________________________________ Freeipmi-users mailing list [email protected] https://lists.gnu.org/mailman/listinfo/freeipmi-users
