Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.sysv386
Subject: Re: Tar Tape problems
Keywords: tar tape
Message-ID: <984@mwtech.UUCP>
Date: 1 Dec 90 13:10:38 GMT
References: <1990Nov19.153249.4308@wdl1.wdl.fac.com> <1990Nov20.205828.9217@jadpc.cts.com> <124@chansw.UUCP>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 65

In article <124@chansw.UUCP> chan@chansw.UUCP (Jerry H. Chan) writes:
[about problems with ARCHIVE tape drives]
 A (former?) tech support person acknowledged this problem during
>my 6/90 conversation stating that it was a *driver* problem. I have no reason
>to doubt her.

As I'm constantly bitten by this problem too, I'm also very interested
in this. I've posted to the net and had some communication with friendly
people at ISC. It seems that not everyone suffers under this. I have
sometimes thought that possibly a certain firmware version could be the
source of the problem.

>The date on ISC's drivers appears to be an older version of the Archive
>drivers (May 3, 1989); the newest drivers (Feb 16, 1990) fixes a few problems
>with the previous version, but the infamous "hung tape" bug remains.

How did you get these dates? A `what' on the two drivers I have here
shows only:

1)	achv1:Driver.o  386/ix 3.2 - Version 2.0.1

2)	INTERACTIVE UNIX System, ARCHIVE Cartridge Tape Driver Version 2.0.1

Number 1) was given to me ~summer 1989, number 2) came with ISC's
release 2.2; the release number seems to be the same, though the
binary isn't (but this may be due to the changed copyright message).

>I can
>reproduce this bug consistently by attempting to access the non-rewind
>device (/dev/ntape) more than four times.

I have noticed that before the driver really hangs, the last previous
access to the drive doesn't stream any more, but is "start-stop".
There are not only a few stops from time to time, but absolutely
regular stops every second or so. I conclude from this that the
hung tape occurs because the driver slowly looses some of its internal
buffers: If there is only one -> start-stop; if there is none -> hung
tape. "Loosing" this buffers may come from not correcly reseting a
busy flag. I suppose that this occurs among several conditions, one is
aborting tape operation by a signal, others may be accessing /dev/ntape,
or not using a certain buffer size.

BTW: Has anyone on the net ever tried to do certain tape operations
with the resp. ioctl() ? I can rewind, retension, and erase the tape,
that way, but requesting the tape status seems to return garbage (and
the values change from call to call, even if I do nothing with the tape
between the calls).

>Anyways, to put pressure on Archive to fix the driver, call Archive Corp.
>at 800-537-2724 and ask for tech support, OR call GREG at 407-263-3538 (FL).
>Greg told me that there are no current plans to fix this "supposed" problem,
>but if enough folks call in with the same complaint, they could be
>coerced into looking at it.

Maybe there's another way if someone could talk the guys at ARCHIVE
into giving the driver source away (possibly after signing some
non-disclosure agreement). As I understand ARCHIVE makes it profits
from selling hardware. The reason they have also software is more or
less to help selling hardware. In the current situation, if someone
asked me, I'd definately *not* recommend to buy the FT60/ST600 drive
from ARCHIVE if it should be used with ISC UNIX. So ARCHIVE could only
win if someone with more expertise looks through the sources and fixes
this annoying bug.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83