tscb

[Mark Wallen]

> This sounds like a device error.  Has anyone else seen this type of
> error before?  In the past, when Unix tapes have run off the end of the
> reel, the solution has usually been to retry the dump/incremental with
> a smaller set of valid dates for which the dump is done.
> 
> Here's a reprint of the error in case anyone can't remember it:
> 
> CS2=100300 <DLT, DR, IR> DS=100701 <SVAL, DDT, DRDY, VV, DRA> ER=0
> 
> 	Stuart

My guess is that DLT is data late.  We experienced a problem
like this on our 11/750 on both 4.1a and 4.2BSD.  The problem
we had was the tape drive getting BGL errors (BUS Grant Late--the
tape drives tiny buffer was empty and it couldn't get the bus
in time to fill before it had to write to tape again).  The
driver considers BGL errors to be soft, so it would retry
but with a "write extended inter-record gap" which amounts
to 6 inches of tape instead of the usual .6.  After several
hundred of these, poor dump could be several hundred feet
out of sync with where it really was on the tape.  And we used
to rack up to 800 BGLs per tape!  Since these were soft errors
and the retry almost always worked, no errors were printed/reported.

We resorted to telling dump that the tapes were only 2100 feet
long with the s option.  In the meantime, after looking at the
sources, it looked like BGLs might be causing the problem; I
put in some metering, and BINGO.  After chatting (;-) with the
manufacturer of the tape subsystem and that of one of our
disk subsystems, we concluded that the disk controller was
a bus hog (256 word bursts, really!).  A new prom set pretty
much cured the problem.

Mark R Wallen
Institute for Cognitive Science
UC San Diego

ucbvax!sdcsvax!sdcsla!wallen	UUCP
wallen at nprdc			ARPA