cracraft@sri-tsc.ARPA (12/05/84)
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
"E. Howard Alt" <alt@sri-tsc.ARPA> (12/06/84)
the problem is that the end of tape mark isn't on the tape. it is a tape problem. throw that one away and use a new one. Howard.
wallen@sdcsla.UUCP (Mark Wallen) (12/07/84)
> 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@nprdc ARPA