chap@art-sy.detroit.mi.us (j chapman flack) (05/19/91)
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.
Similarly, I then do a find ... | cpio ... to write on the tape, and a
screenful of file names flies by (about a blocksize worth, I guess) and then
cpio gives me a write error and exits. I repeat exactly the same command
again, the same file names whiz by, then the drive whirrs into action and the
command executes through to completion successfully.
But SOMETIMES things work the FIRST time. I haven't found a pattern.
"tape status" ALWAYS shows:
status :
soft errors : 0
hard errors : 0
underruns : 0
no matter what. The man page lists messages like "Beginning of tape,"
"Write protected," "No tape," etc. I get the above non-message under all
circumstances.
If I do a tar to a non-write-enabled tape, the file names whiz by on my
screen and the command completes successfully. The tape just never moves,
is all. (The FIRST TIME I try it, I might get a "write error" message, but
that's just the same message I get the FIRST TIME with a write-enabled tape.)
There's more. I've been trying to use the no-rewind-on-close device to put
multiple files on one tape. (What fun is a 150MB tape otherwise?) My idea
has been to write a small "header" file, then tar something, say, then
another header file, tar something else, etc. I could write a little shell
script to read the header file and then either tar in the tarchive or skip
it with a "tape rfm" and read the next header, etc. (If there already exists
a utility for doing this, I'd like to hear about it.)
But when I put, say, a tarchive on the tape, and then write a little header
file, in MOST cases it works right and a "tape rfm" at the beginning of the
tarchive will skip it and the next read gets the header file. BUT SOMETIMES
IT DOESN'T! The little header gets appended to the end of the tarchive, so
"tape rfm" skips BOTH of them and the next read FAILS. tar, of course, now
finds rubbish at the end of the tarchive.
What the Dickens is going on? Is the SysV SCSI tape driver this buggy? Is
it a SCO problem? Is my tape drive busted? (I got it used....) What do I
need to make it work?
--
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@tmcsys.UUCP (L. Hirschbiegel) (05/21/91)
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 -----------------------------------------------
pvr@wang.com (Peter Reilley) (05/23/91)
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. The "tape load" command is totally unnecessary. I have exactly the same system and have a scsi analyzer. The first time the command is issued you get a notification that the tape has been changed, the second time nothing. Cartridge tapes do not need a load command. The reason that the tape moves the second time has to do with the internal drive microcode and not unix or the device driver. >Similarly, I then do a find ... | cpio ... to write on the tape, and a >screenful of file names flies by (about a blocksize worth, I guess) and then >cpio gives me a write error and exits. I repeat exactly the same command >again, the same file names whiz by, then the drive whirrs into action and the >command executes through to completion successfully. >But SOMETIMES things work the FIRST time. I haven't found a pattern. This can occur when you have a marginal tape or a dirty drive head. >"tape status" ALWAYS shows: > status : >soft errors : 0 >hard errors : 0 > underruns : 0 >no matter what. The man page lists messages like "Beginning of tape," >"Write protected," "No tape," etc. I get the above non-message under all >circumstances. This data structure is cleared when the device is closed. You can only obtain the status when the device remains open. If the device is open you can access the /dev/xct0 device to get the status. This control device is indicated by the high bit on in the minor number. >If I do a tar to a non-write-enabled tape, the file names whiz by on my >screen and the command completes successfully. The tape just never moves, >is all. (The FIRST TIME I try it, I might get a "write error" message, but >that's just the same message I get the FIRST TIME with a write-enabled tape.) The SCO driver has a large buffer in the device driver to enhance streaming. You can write to the buffer before the tape drive is accessed. Only when the tape is accessed does the driver relalize that the tape is write protected. >There's more. I've been trying to use the no-rewind-on-close device to put >multiple files on one tape. (What fun is a 150MB tape otherwise?) My idea >has been to write a small "header" file, then tar something, say, then >another header file, tar something else, etc. I could write a little shell >script to read the header file and then either tar in the tarchive or skip >it with a "tape rfm" and read the next header, etc. (If there already exists >a utility for doing this, I'd like to hear about it.) >But when I put, say, a tarchive on the tape, and then write a little header >file, in MOST cases it works right and a "tape rfm" at the beginning of the >tarchive will skip it and the next read gets the header file. BUT SOMETIMES >IT DOESN'T! The little header gets appended to the end of the tarchive, so >"tape rfm" skips BOTH of them and the next read FAILS. tar, of course, now >finds rubbish at the end of the tarchive. I don't understand what could be causing this, but be aware that buffering, if improperly done, can cause a misconception between what you think that you are writting to the tape and what gets put on the tape. QIC format tape drives are fixed at 512 block size and buffering can make you think that you can write or read other block sizes. >What the Dickens is going on? Is the SysV SCSI tape driver this buggy? Is >it a SCO problem? Is my tape drive busted? (I got it used....) What do I >need to make it work? The Archive drive is quite good most of the time. You should occassionally clean the heads and tapes do go bad. The driver does have some odd characteristics, especially with variable block tape drives, but seems pretty good with the Archive drive. -- >>>>>>>>>>>>>>>> Peter Reilley ..... pvr@wang.com <<<<<<<<<<<<<<<<<<<<<<< Well, that about says it.