[pups] Sigma RQD11s, ESDI, and other naughty words

[Norman Wilson]

A couple of weeks ago, I asked if anyone had any suggestions to help
me convince a Sigma RQD11 Qbus-to-ESDI controller that it had disks
attached.  The trouble turned out to be pretty silly--the A-cable
terminator in the disk I was testing with was in backwards--but later
I discovered what may be a genuine controller botch that is worth
reporting.

Like most Qbus disk controllers, the RQD11 speaks the MSCP protocol
to the host.  More precisely it understands MSCP messages and uses
UQSSP to transmit them; UQSSP is the transport protocol used by
UNIBUS and Qbus controllers like the UDA50 and KDA50 and RQDX3 and
TQK50 and so on.  In general, the host sends commands like `bring
drive online' or `read a block' to the controller, and the controller
sends back response messages like `command succeeded' or `command failed.'
(Never mind how the data part of the block is sent to memory for now.)

The host sets up a ring of buffers for the controller to place messages
in.  Each buffer has an ownership flag: messages owned by the controller
are available to hold new messages; messages owned by the host are not,
usually because there's already a message there.  When the controller
has a message to send, it waits (if necessary) until it owns the next
buffer in the ring (the ring is used in strict round-robin order);
puts the message there; and sets the ownership flag to `host.'
When the host has handled the message, or at least copied it elsewhere,
it sets the flag back to `controller.'

When the controller gives a message to host, it also generates an
interrupt.  There are several other reasons for generating an interrupt,
so it is also supposed to set a single flag elsewhere in a communication
area in host memory to mean `there are new messages.'

My UQSSP driver code checked for new messages only if the flag was set,
and that caused me grief; it turns out that, at least when the host is
a MicroVAX III, the RQD11 sets the `new messages' flag inconsistently,
or perhaps too late.  Presumably it should have been set before requesting
the interrupt, but empirically I can see that sometimes it gets set later.
The effect was that the controller did what I told it, but my device driver
never heard the acknowledgement that said it did.  Obviously this makes
I/O unreasonably slow.

Fortunately there's a simple way around this: my driver's interrupt routine
now peeks at the ownership flag for the buffer where the next message
should appear.  (Remember that the message buffers are used in strict order,
so the host always knows exactly which buffer that is.)  When I do that,
all is well.

I suspect that many existing UQSSP drivers already did what my code does
now; in particular, the controllers and disks I am testing are known to
have worked for many years with Ultrix, and while searching for data on
the controller I came across various notes suggesting that the RQD11 works
under NetBSD/VAX as well.  But those who are writing new code or making
changes to existing code should beware; the RQD11 appears to be breaking
the rules (according to the old UQSSP manual I still have), and (as in
many real-world protocol situations) if you write your code from the spec
(as I did, in fact, albeit many years ago), the real world may trip it up.

Norman Wilson