On Mon, Dec 21, 2015 at 03:41:23PM +0100, Mark Kettenis wrote: > > Date: Mon, 21 Dec 2015 22:31:22 +0900 > > From: Masao Uebayashi <[email protected]> > > > > This is the first part of the big ipmi(4) patch I sent in another thread. > > > > This removes complicate polling timeout code. Serial communication > > with BMC is slow but considered as reliable. Communication failure > > is a fatal problem. Returning error doesn't make sense. > > > > This also removes unfinished interrupt handling. Access is always done in > > polling manner. > > > > OK? > > I don't think so. Because... > > > diff --git a/sys/dev/ipmi.c b/sys/dev/ipmi.c > > index a1156d8..91aa147 100644 > > --- a/sys/dev/ipmi.c > > +++ b/sys/dev/ipmi.c > > @@ -1082,11 +1017,7 @@ void > > ipmi_delay(struct ipmi_softc *sc, int period) > > { > > /* period is in 10 ms increments */ > > - if (cold || sc->sc_poll) > > - delay(period * 10000); > > - else > > - while (tsleep(sc, PWAIT, "ipmicmd", period) != EWOULDBLOCK) > > - continue; > > + delay(period * 10000); > > } > > Doing a spinning delay like that for such a long time is pretty bad.
This ipmi_delay() is called after send and receive command routines. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ipmi.c#rev1.47 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ipmi.c.diff?r1=1.46&r2=1.47 I don't believe such a wait is needed for slow serial controllers; they usually handle everything synchronously. I've removed those waits locally. FreeBSD's ipmi(4) doesn't have such a wait either.
