UDA50/RA81 problems....

[chris at umcp-cs.UUCP]

First:  Please post diff's to the 4.2 UDA driver.

Second:

The reason for the Get Unit Status command in the first place (the one
which floods the UBA and UDA with interrupts) is because *something*
has to be done at that point, and I suppose the author of the original
code felt that M_OP_GTUNT was the least drastic.  Here's the scenario:

	N requests for Unibus BDPs all granted.  (N depends on CPU
	type.)

	UDA50 requests BDP.  Request is denied because the UBA is out
	of BDPs.  The driver can't wait for one because this is
	happening at interrupt level.  What to do?

Solution 1: return from the interrupt code, without doing anything at
all.  This would work except for one snag:  what if there are no
transfers pending on that controller?  No more interrupts will occur,
and we'll never get another shot at grabbing a BDP and starting the
transfer.  (Another thing would need to be done is allocate the MSCP
packet *after* getting the BDP, not before.  Unless you know a way
to give back an MSCP packet . . . ?)

Solution 2: do a Get Unit Status.  That doesn't need a BDP and can use
the handy MSCP packet that's already been allocated.  Unfortunately, it
floods the UBA with interrupts until a BDP is finally released.

Solution 3 (my favourite but requires hacking the UBA code):  Return
from the interrupt code after exacting a promise from the UBA code to
call the interrupt routine again once a BDP is free.  Requires some
sort of queueing, alas.  Another possibility is to just set a flag
someplace and have a callout daemon (the udwatch watchdog routine that
isn't there for some reason, perhaps) call the interrupt routine.
Easier but not as aesthetic.

Solution 4: apply Solution 1 after moving all other devices that use
BDPs to another Unibus.  That would guarantee that the snag never
occurs.  However, while technically feasible, it may not be a viable
option.  (I can just see trying to justify another UBA to the state
``because we can't write the software right''. . . .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland