Possible uda50 driver problem

[Chris Torek]

In article <189 at miduet.gec-mi-at.co.uk> steve at gec-mi-at.co.uk
(Steve Lademann) writes:

>... It all started when the air-flow sensor got bunged up with a
>ball of fluff, thus precipitating several removals of power from
>the system. Now, it panic traps ... from the uda50 driver in routine
>'udrsp' at infrequent intervals....

Strict-typists take heed: lint can create bugs as well as detect
them!  :-)

>Now, it is probably a hardware fault ... to save time, does anyone
>out there know of any problems with the May 1985 version of the RIACS
>driver containing Mike Muuss' unit/type detection code, and the bad
>block replcement software?

Well, yes, but I know of none in udrsp().  Incidentally, I believe
the unit type detection code is by Alex White (watmath!arwhite).

Obligatory Disclaimer:  The following information has not been
officially verified by anyone.  It is all based upon guesswork on
my part, or reverse engineering, if you will.

In particular, this driver---along with every other released UDA50
driver---can occasionally invoke a UDA50 microcode bug, in which
the drives go off line, and the controller stops responding and
must be re-set.  There may be many ways to provoke the problem,
but the primary path concerns rapid-fire Get Unit Status operations.
The RIACS driver, and I think the 4.3BSD driver, try to avoid this,
but can miss if there are other devices on the same Unibus that
use BDPs.  DEC `fixed' the problem in microcode revision 4 ... on
780s and slower machines only, as a CPU conversion later proved.

I have also been told that the bad block forwarding algorithm in
the RIACS driver is based upon, or related to, a flawed algorithm
that was once used in VMS.  I have not looked further into this;
since the last of our RA81 HDAs were upgraded past the `falling
glue' revisions, we have had no real trouble with the HDAs themselves.
The UDA50s, on the other hand ... well, even Emulex has bugs in
their UDA50 emulator (and Emulex finally admitted this: a major
milestone in itself).

It may be a bit early for this, but here goes:  I plan to distribute
a completely rewritten 4.3BSD UDA50/MSCP driver.  As far as I know,
it has no bugs (but then, I said that last week!).  It does not do
dynamic bad block replacement; I now believe that this should be
done outside the driver, at least in the main.  In any case, I have
had no bad blocks to replace, and so I have neither incentive to
write, nor a way to test, such code.  The hooks, however, are there,
in the generic MSCP part of the driver.  Generic: for I have split
the driver into a UDA50-specific portion, and another piece that
deals only with the MSC protocol itself.  I hope that this may be
useful in reducing the size of the TK50/TU81/TA81 driver (a whopping
fifty-seven thousand bytes of C code in the 4.3 distribution).  I
have not looked beyond its copyright notice at the top, as will
no doubt become painfully obvious to anyone who actually tries to
merge my code with DEC's: but the potential is there.

Well, this has become rather long, so perhaps I should say this,
to legitimise the length after the fact (as it were).  If you are
running 4.3BSD, and would like to beta test my driver, let me know.
It will help if you have ARPAnet access, or some other way to
transfer large amounts of data quickly: the code currently totals
some 85K; and that includes neither instructions nor the changes
to the Unibus allocation code.  uda.c alone is 47820 bytes, though
that drops to 28520 bytes when comments are stripped!
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu