Mass driver (fast dump) bug, shows up on TU77s

[Chris Torek]

[We interrupt this newsgroup to bring you an important message.  If
 you are using the mass driver with a TU77, please read on.]

I've run into a problem involving the mass driver (dump speedup).  It
shows up when writing TU77 tapes.  (It does *not* happen when writing a
TS11 or TU78; vaxuba/ts.c and in vaxmba/mt.c only treat the raw tape
specially when they get a wrong-length read.)

The problem is simply that the drivers check ``bp == &rxxbuf[xxunit]''
when certain errors occur, and if so, ignore some of them.  When using
the mass driver, bp doesn't point to the raw transfer buffer header, so
this doesn't work.  In particular, this makes correctable CRC errors on
TU77s generate hard errors (because the massbuss status register has
the data transfer aborted and massbuss exception bits [DTABT|MBEXC]
set).*

A very ugly hack fix is to change vaxmba/ht.c to test B_CALL as well,
since the B_CALL flag is invariably set on mass driver transfers, and
no others (the only other places that use it are the pageout code,
which isn't invoked on tapes, and the TU58 driver, which doesn't have a
raw interface).  But this is ugly, since B_CALL isn't *supposed* to
have anything to do with ``rawness''.  A better solution would be to
add a new flag (or take over B_XXX) that can be used for any random
device-dependent stuff.  Call it B_PERDEVUSE, for example.  Then
setting B_PERDEVUSE in htphys() and htmass(), and changing bp==&rhtbuf
to bp->b_flags&B_PERDEVUSE, would fix it in a relatively clean manner.
This would also allow mass driver reads on raw tapes, by making the
same changes in the other tape drivers (along with writing read code
in the mass driver).

To install the hack fix, find the line that says

		if (bp == &rhtbuf[HTUNIT(bp->b_dev)]) {

(it is right above these three lines:)

			er &= ~HTER_FCE;
			mbs &= ~(MBSR_DTABT|MBSR_MBEXC);
		}

and change it to

		/* the test on B_CALL is a hack, to be cleaned up soon */
		if (bp == &rhtbuf[HTUNIT(bp->b_dev)] || bp->b_flags&B_CALL) {

------
*I think this is actually a bug in the TU77 driver, since block device
transfers that get correctable CRC errors will run into the same
problem.  It might not be a bad idea to turn off DTABT and MBEXC
whenever any CORCRC error occurs....  But then who uses the block tape
interface anyway?
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland