[comp.unix.sysv386] Tar Tape problems

rme@spl26.spl.fac.com (Richard M Emberson Jr) (11/19/90)

I've got a 386 AT clone, ISC2.2, and an Archive drive. After reading four
or five tape (tar -xfv /dev/rmt0) the next attempt to read a tape hangs.
I can kill the process but the device remains busy. The only way I
have found to clear the busy device is to powerdown to the reboot state.

Is there a way to fix this?? Can I unbusy the device?

Richard M. Emberson
rme@spl1.spl.fac.com

jdeitch@jadpc.cts.com (Jim Deitch) (11/21/90)

In article <1990Nov19.153249.4308@wdl1.wdl.fac.com> rme@spl26.spl.fac.com (Richard M Emberson Jr) writes:
>I've got a 386 AT clone, ISC2.2, and an Archive drive. After reading four
>or five tape (tar -xfv /dev/rmt0) the next attempt to read a tape hangs.
>I can kill the process but the device remains busy. The only way I
>have found to clear the busy device is to powerdown to the reboot state.
>
>Is there a way to fix this?? Can I unbusy the device?
>
>Richard M. Emberson
>rme@spl1.spl.fac.com

Hmmm... I told Archive about this 3 months ago.  They said they had
never heard of it, nor experienced it.  I just got off the phone with
them and apparently there is a new driver for ISC 2.2.  The girl on
the phone didn't know if the new driver fixed the problem or not.
Hopefully someone from Archive will call me back before  get old and
gray to tell me that they will be sending me the new drivers.  I will
let you know what I turn up.

Jim

-- 
ARPANET:    jadpc!jdeitch@nosc.mil
INTERNET:   jdeitch@jadpc.nosc.mil
UUCP:	    nosc!jadpc!jdeitch

johncore@compnect.UUCP (John Core ) (11/28/90)

In article <1990Nov20.205828.9217@jadpc.cts.com>, jdeitch@jadpc.cts.com (Jim Deitch) writes:
> In article <1990Nov19.153249.4308@wdl1.wdl.fac.com> rme@spl26.spl.fac.com (Richard M Emberson Jr) writes:
> >I've got a 386 AT clone, ISC2.2, and an Archive drive. After reading four
> >or five tape (tar -xfv /dev/rmt0) the next attempt to read a tape hangs.
> >I can kill the process but the device remains busy. The only way I
> >have found to clear the busy device is to powerdown to the reboot state.
> >
> Hmmm... I told Archive about this 3 months ago.  They said they had
> never heard of it, nor experienced it.



I told archive about that problem 2 years ago, the standard answer
UPGRADE)

they now have a bbs running so you can download new drivers


Wizard Systems              |    UUCP:   uunet!wa3wbu!compnect!johncore
P.O. Box 6269               |INTERNET:   johncore@compnect.wa3wbu
Harrisburg, Pa. 17112-6269  |a public bbs since 1978. Data(717)657-4992 & 4997
John Core, SYSOP            |-------------------------------------------------
----------------------------| No matter where you go, there you are!
a woman is just a woman, but a good cigar is a smoke.   -R. Kipling

ronald@robobar.co.uk (Ronald S H Khoo) (11/29/90)

In article <879@compnect.UUCP> johncore@compnect.UUCP (John Core ) writes:

> I told archive about that problem 2 years ago, the standard answer
> UPGRADE)

> they now have a bbs running so you can download new drivers

Anyone gonna post the number?

-- 
ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)

chan@chansw.UUCP (Jerry H. Chan) (11/29/90)

In article <1990Nov20.205828.9217@jadpc.cts.com>, jdeitch@jadpc.cts.com (Jim Deitch) writes:
> In article <1990Nov19.153249.4308@wdl1.wdl.fac.com> rme@spl26.spl.fac.com (Richard M Emberson Jr) writes:
> >I've got a 386 AT clone, ISC2.2, and an Archive drive. After reading four
> >or five tape (tar -xfv /dev/rmt0) the next attempt to read a tape hangs.
> >I can kill the process but the device remains busy. The only way I
> >have found to clear the busy device is to powerdown to the reboot state.
> 
> Hmmm... I told Archive about this 3 months ago.  They said they had
> never heard of it, nor experienced it.  I just got off the phone with

I talked to an Archive tech support rep. just a few days ago reporting a
variation of this same problem.  Although first reported over a year ago and
then again in June of this year, they either misplaced my complaints or are
ignoring it.  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.

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

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.
-- 
Jerry Chan 508-853-0747, Fax 508-853-2262  |"My views necessarily reflect the
Chan Smart!Ware Computer Services & Prods  | views of the Company because
Worcester, MA 01606                        | I *am* the Company." :-)
{bu.edu,husc6}!m2c!chansw!chan             \---------------------------------

bill@bilver.uucp (Bill Vermillion) (11/30/90)

In article <124@chansw.UUCP> chan@chansw.UUCP (Jerry H. Chan) writes:
 
>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.

Hey. Don't get you hopes up.

We had a local meeting of a rag-tag groups that consist of consultants,
hackers, designers, etc. last night, and this very problem came up.

One person sent back the Archive/Maynard hardware yesterday.  He said the
more he talked to tech support the worse it got.

I am having problem with tape drivers. The new ones are about 1/2 the speed
of the old ones, and they are not writing new drivers for the older '286
Xenix releases - so one site I work at may have to move on to others.
It's going to cost them a few grand as we are using multiple units.

The consensus was that the Maynard/Archive support was some of the worst we
have seen.  It was such  good company at one time.

I was promised that I would get a return phone call with expected release
date.  I call every couple of weeks, leave my name and number, and get
ignored.  We thought we had driver problem in June/July.  They sent us new
disks.  Turned out it's their problem, and they don't seem to give a damn.
I even talked to someone who was either head of tech support or above that
department.  Guess because I don't buy 200-300 drives at a time I don't
count.

Keep us posted.   We are looking into getting different interface cards for
the Teac data cassette drives, and going with some other drivers, if we can
do it.

-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill@bilver.UUCP

rh@smds.UUCP (Richard Harter) (11/30/90)

In article <124@chansw.UUCP>, chan@chansw.UUCP (Jerry H. Chan) writes:
> In article <1990Nov20.205828.9217@jadpc.cts.com>, jdeitch@jadpc.cts.com (Jim Deitch) writes:
> > In article <1990Nov19.153249.4308@wdl1.wdl.fac.com> rme@spl26.spl.fac.com (Richard M Emberson Jr) writes:
> > >I've got a 386 AT clone, ISC2.2, and an Archive drive. After reading four
> > >or five tape (tar -xfv /dev/rmt0) the next attempt to read a tape hangs.
> > >I can kill the process but the device remains busy. The only way I
> > >have found to clear the busy device is to powerdown to the reboot state.

The problem is probably a zombie process that hangs the device.  We have
ESIX rather ISC so the following may or may not work for you.  Touch the
device file (touch /dev/rmt0).  What this does is wake up the zombie so
that it can die.  No guarantees on this, but you might give it a try.
It may take two or three touches to clear the device.


-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.

martin@mwtech.UUCP (Martin Weitzel) (12/01/90)

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

grant@bluemoon.uucp (Grant DeLorean) (12/05/90)

martin@mwtech.UUCP (Martin Weitzel) writes:

> 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 have two more versions, 2.02 (came from ISC) and 2.04 (came direct
from Archive, and is the latest with no planned revisions in the near
future). I don't have the problem you two are talking about, but
things aren't quite rosey here either. I seem to have a problem (with
both versions of the driver) with files getting corrupted while
switching tracks at tape's end (out of synch, actually). 

> 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.

 Hmm, I am using their vp150 (the L version, not the SCSI version). I
am moving up to a Wangtek (on my 1542B)...


 Grant DeLorean 
grant@bluemoon  ...osu-cis!n8emr!bluemoon!grant  ...towers!bluemoon!grant
###
 So just remember, if a weirdo in a blue suit comes up and offers you
some DOS, just say NO!
    (a message from the President's War on DOS committee)
###

jdeitch@jadpc.cts.com (Jim Deitch) (12/05/90)

In article <262@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
>In article <124@chansw.UUCP>, chan@chansw.UUCP (Jerry H. Chan) writes:
>> In article <1990Nov20.205828.9217@jadpc.cts.com>, jdeitch@jadpc.cts.com (Jim Deitch) writes:
>> > In article <1990Nov19.153249.4308@wdl1.wdl.fac.com> rme@spl26.spl.fac.com (Richard M Emberson Jr) writes:
>> > >I've got a 386 AT clone, ISC2.2, and an Archive drive. After reading four
>> > >or five tape (tar -xfv /dev/rmt0) the next attempt to read a tape hangs.
>> > >I can kill the process but the device remains busy. The only way I
>> > >have found to clear the busy device is to powerdown to the reboot state.
>
>The problem is probably a zombie process that hangs the device.  We have
>ESIX rather ISC so the following may or may not work for you.  Touch the
>device file (touch /dev/rmt0).  What this does is wake up the zombie so
>that it can die.  No guarantees on this, but you might give it a try.
>It may take two or three touches to clear the device.
>
>

Nope.  Tried it tonight and didn't work.  I wish that SOMEONE (even
the janitor) at Archive would please return a call.  After 10 touches
the process was still hung.

-- 
ARPANET:    jadpc!jdeitch@nosc.mil
INTERNET:   jdeitch@jadpc.cts.com
UUCP:	    nosc!jadpc!jdeitch