Xref: utzoo comp.periphs.scsi:2647 comp.unix.sysv386:8223
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!math.fu-berlin.de!fauern!unido!aega84!tmcsys!lothar
From: lothar@tmcsys.UUCP (L. Hirschbiegel)
Newsgroups: comp.periphs.scsi,comp.unix.sysv386,sco.opendesktop
Subject: Re: Archive 2150S behaves erratically under SCO SysV/386 3.2
Message-ID: <379@tmcsys.UUCP>
Date: 20 May 91 21:37:19 GMT
References: <9105191215.aa04054@art-sy.detroit.mi.us>
Reply-To: lothar@tmcsys.UUCP (L. Hirschbiegel)
Organization: Private Site
Lines: 52

In article <9105191215.aa04054@art-sy.detroit.mi.us> chap@art-sy.detroit.mi.us (j chapman flack) writes:
>The system: SCO Open Desktop 1.0.1 UFE (System V/386 3.2),
>	    Adaptec 1540A SCSI host adapter
>	    one Archive 2150S QIC tape drive, SCSI ID 2
>	    one fixed disk, Seagate ST1201N, SCSI ID 0
>
>What it does:  The 2150S seems to like to respond to commands the SECOND
>time.  For instance, I pop a tape in the drive and say "tape load".  The
>command returns, successfully, immediately, and the drive has done nothing.
>The light remains off.  I type exactly the same command a second time,
>the light comes on, the drive whirrs, and the tape is loaded.
>

I don't know if its just by accident, but my Archive 2150 behaves
exactly the same way.
It's NOT a SCSI version, but one with a separate controller (SC402),
so in your case this could also be a problem with wrong jumpers or something
like this, but anyway - intriguing coincidence...

Since I wrote my own driver for the Archive (that does not need any interrupt
and runs circles around the original Archive driver as shipped by ISC ;-)
I was able to experiment a bit. What happens is: 
The drives status register is not updated correctly! Normally you read the
drives status with command 0xC0 from the status port, which is located
at base adress + 1 . With my own controller this gives wrong results for
the first time. For example after inserting the cartridge it insists, that there
is still no cartridge in the drive (but no status error is generated).
After issueing a second read status call every works fine...
This is exactly where your tar or cpio would hang with an error message.
Looks very similar to your problem.
One other thing I've found out: its a problem with the drive itself, NOT
the controller. (I tried with different controllers)
It was easy for my own driver to correct this: I duplicate the status call
if necessary. If you (have to) use the SCO/ISC drivers - bad luck, I guess...

I don't know whether the SCSI and non-SCSI version of the drives are
*completely* different, but could it be there are some problems with certain
Archive drives?? Anyone else with a similar problem ??

>-- 
>Chap Flack                         Their tanks will rust.  Our songs will last.
>chap@art-sy.detroit.mi.us                                    -MIKHS 0EODWPAKHS
>
>Nothing I say represents Appropriate Roles for Technology unless I say it does.

Lothar Hirschbiegel

-- 
-----------------------------------------------
L. Hirschbiegel, AEG - A84, Frankfurt (Germany) 
email: unido!aega84!lh     tel: -49-69-66414316  
-----------------------------------------------