Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Ultrix tape job is unkillable!
Message-ID: <15048@mimsy.UUCP>
Date: 17 Dec 88 17:14:05 GMT
References: <476@larry.UUCP> <43200057@uicsrd.csrd.uiuc.edu> <8555@alice.UUCP> <9221@smoke.BRL.MIL>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 51

In article <8555@alice.UUCP> debra@alice.UUCP (Paul De Bra) writes:
>... Ultrix 2.0 on a Microvax II, where puttinga TK-50 offline could
>only be recovered from by a reboot.
>An identical machine with Unix 9Vr2 does not have this problem. So
>it clearly is something in the Berkeley device driver.

Blame where credit is due department :-) :

The Ultrix 2.0 TK50 driver is not the same as the `Berkeley' TK50
driver.  The `Berkeley' driver was contributed by DEC and is probably a
variant of the Ultrix 1.1 or 1.2 driver.  One should be grateful to DEC
for the existence of the driver at all; but bugs in it are not the
fault of someone at Berkeley.

In article <9221@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>That wouldn't surprise me very much.  VAX (and PDP-11) magtape drivers
>have been pretty horrible in most UNIXes I've seen, partly due to the
>tendency of most controllers to generate one interrupt when a rewind
>(for example) command is accepted, and another when BOT is reached.
>This implies that some state must be maintained in the driver, and
>you know how notoriously easy it is to get into trouble doing that.

Indeed.  In this case, the driver is usually waiting for a DONE
interrupt of some kind, and gets an OFFLINE error interrupt instead.
It should then clean up and perhaps close the tape drive; user programs
should be able recover by closing and reopening the drive, then
positioning the tape as appropriate.

>It could be much worse -- when I was using a prerelease of VAX/VMS
>(as a DEC subcontractor) ages ago, I took the TE16 off-line manually
>while it was rewinding (in order to be sure it wouldn't be overwritten,
>since it still had the write ring installed), and the WHOLE SYSTEM
>wedged until the rewind completed.  I nearly died laughing..

This sort of thing is not always the fault of software.  Early
revisions of the firmware for the Emulex SC41/MS (a UDA50 emulator that
speaks SMD II or II+ or IIe or XMD or something---anyway, it plugs into
the big CDC 14 inch drives---where was I?  Oh yes, SC41/MS firmware)
had a bug that would, under high load, hang a VAX-11/750 so utterly
that only power cycling, or pushing the little white `reset' button,
would bring it back.  (All console microcode function, including ^P,
was suspended.)  I told Emulex of the bug's existence, but they
did nothing about it until VMS V4 came out and began exercising it.
I think they doubted me :-) .

At any rate, the device driver situation is likely to suddenly become
better.  Read all about it in a future Usenix conference proceedings
. . . I hope.  (Not San Diego.  Maybe Baltimore.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris