785 + UDA50 + 4BSD = Hang (was Re: bsd4.2 on 11/785)

[Chris Torek]

Your problem with the mysterious hangs is almost surely the infamous
UDA50 microcode bug.  After the system hangs, open up the Unibus
box and take a look at the UDA50 lights.  They will be stuck in an
odd state (normal state is a little ripple down four LEDs, and
another four blinking between 1010 and 1000, or something like
that).

I surmise that the problem is caused by sending MSCP GTUNT commands
to the controller faster than it can handle them.  I think this
was the old timing bug that DEC `fixed' long ago, and that the
timing window was merely tightened down to the point where 780s no
longer invoked it---but 785s are faster.

A `quick hack' fix is to put a DELAY(1000) (more or less; 1000
seems to work but is likely higher then necessary) under the `case
M_OP_GTUNT|M_OP_END' in /sys/vaxuba/uda.c$udrsp().  The right way
to fix the the problem is to stop hammering GTUNT commands at the
UDA50; they are necessary only because the driver is not using the
appropriate Unibus resource allocation protocols.

Indeed, this last is the source of another problem with the UDA50
driver:  it causes frequent data-late errors on RK07s, as it ignores
the Unibus lock normally granted to transfers on RK disks.  Someday,
when my input event queue drops back below the high water mark, I
shall fix that. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu