Apologies for the delay in responding to this.


"R.Gopalakrishnan" <gopal@dworkin.wustl.edu> writes:

> 
> The problem is that setrunqueue() is also called in wakeup().
> Since splclock() cannot block all calls to wakeup(), it is possible
> that setrunqueue() is interrupted, wakeup() is called, which in
> turn calls setrunqueue() again. Is this possible ?

Yes, this sounds like a bug.

It used to be that calls to setrunqueue() (actually, setrq()) were
done at splclock(), and on a VAX, splclock() happened to block I/O.
In the 4.4BSD book, this relation appears to have been made explicit.

In 4.4BSD-Lite, this was all changed to use splstatclock().  (Sadly,
this wasn't documented in the book; I find no references at all to
splstatclock().)

Based on the current code, it would appear that the partial ordering
restrictions are as follows:

  If you have a separate statistics clock (stathz != 0),

    statclock >= clock
    statclock >= net
    statclock >= bio
    statclock >= tty

  else,

    statclock >= clock
    clock >= net
    clock >= bio
    clock >= tty

(Unless there's a particularly good reason not to, I'd suggest always
using the latter ordering.)

Currently, the following ports do not appear to comply with this
partial ordering:

  i386
  pc532
  pmax (on the 5000/25)

The i386 port will be updated before you see this.