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