Thanks to all who responded, and Jon Peatfield for the fix. The motherboards have something that watches a pair of ports to hand things off to the IPMI card *even when the IPMI card isn't installed*. So if we have xinetd watch that port with a fake service, the problems go away. The docs I had seen suggested all the intelligence was on the IPMI card, which is why when this happened without the card, we discounted IPMI involvement. Jon and his cohorts were looking for a similar problem to ours and stumbled across the fix. Jon (and now we) installed four port watchers: /etc/xinetd.d/rmcps-tcp /etc/xinetd.d/rmcps-udp /etc/xinetd.d/rmcp-tcp /etc/xinetd.d/rmcp-udp and restarted xinetd. Each of these looks something like this: ----------------------------------------------------- # default: on # description: Dummy entry for rmcps-tcp tcp version service rmcps-tcp { type = UNLISTED id = rmcps-tcp socket_type = stream protocol = tcp user = root wait = no disable = no port = 664 server = /bin/true } ----------------------------------------------------- The rmcps services listen on port 664; rmcp services listen on 623. Once again, the SL community does a great job of support. Thanks. -Miles