Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!teddy!panda!talcott!harvard!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.unix-wizards Subject: Mass driver (fast dump) bug, shows up on TU77s Message-ID: <2575@umcp-cs.UUCP> Date: Thu, 17-Jan-85 20:57:56 EST Article-I.D.: umcp-cs.2575 Posted: Thu Jan 17 20:57:56 1985 Date-Received: Mon, 21-Jan-85 02:32:40 EST Distribution: net Organization: U of Maryland, Computer Science Dept., College Park, MD Lines: 57 [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@umcp-cs ARPA: chris@maryland