From: dan@quiensabe.az.stratus.com (Dan Danz)
Newsgroups: comp.sys.next.sysadmin,comp.sys.next.hardware
Subject: Cybertnetics SCSI Tape / rdump / rmt problem
Keywords: SCSI, tape, rdump, rmt
Date: 21 Aug 92 03:59:17 GMT
Reply-To: dan@az.stratus.com
Followup-To: comp.sys.next.sysadmin

I could use a little help trying to get a Cybernetics CY-8200/8500 SCSI
tape drive working REMOTELY on a NeXT (NextStation and/or Turbo).

rdump and gnu_tar (1.10) run on another workstation fail when using /bin/rmt
on the host with the drive.   The GNU version of rmt has been tried
as well.

dump and tar both work when the SCSI device is attached directly to
the workstation doing the dumping.

The basic problem is that the RMT operation fails because write(tape, buffer,  
n) fails and returns a value of 0.  The same write worked flawlessly for
(a hundred or so) blocks before the failure.

We've tried with/without compression, with different tapes (but like I said
before, I think we can rule out the tape media because the same tape works
when used to dump the local workstation).

We've added debugging code to GNU rmt to:

        1) validate that the value of n in the write call is really
           non-zero.  It is.   For rdump, the value given is 32,768
           and for gnu_tar it is 20,000.

        2) Do mt_get's after each write and show the value of the
           tape status.

Two blocks BEFORE the bad return, mt_get shows error status for the
first time:

[... from the trace in RMT, towards the end of the trace 

rmtd: W 10240                   < received Write cmd from gnu tar
rmtd: W i=10240 n=10240         < debug proof that n != 0
                                < (the write(tape, buffer, n) is done here
rmtd: W rval=10240 n=10240      < debug rval is value returned from write
rmtd: MT type=10                < mt get results
rmtd: MT ds=0
rmtd: MT err=0
rmtd: MT err0=0
rmtd: MT err1=0
rmtd: MT resid=0
rmtd: MT fileno=0
rmtd: MT blkno=0
rmtd: A 10240                   < good answer to gnu_tar

rmtd: W 10240
rmtd: W i=10240 n=10240
rmtd: W rval=10240 n=10240
rmtd: MT type=10
rmtd: MT ds=64                 what's this status
rmtd: MT err=0
rmtd: MT err0=256
rmtd: MT err1=0
rmtd: MT resid=0
rmtd: MT fileno=0
rmtd: MT blkno=0
rmtd: A 10240                   < good answer to gnu_tar

rmtd: W 10240
rmtd: W i=10240 n=10240
rmtd: W rval=10240 n=10240
rmtd: MT type=10
rmtd: MT ds=64              <<<  what's this status
rmtd: MT err=0
rmtd: MT err0=256
rmtd: MT err1=0
rmtd: MT resid=0
rmtd: MT fileno=0
rmtd: MT blkno=0
rmtd: A 10240                   < good answer to gnu_tar

rmtd: W 10240
rmtd: W i=10240 n=10240
rmtd: W rval=0 n=10240          < write returns 0 bytes written
rmtd: MT type=10
rmtd: MT ds=0
rmtd: MT err=0
rmtd: MT err0=0
rmtd: MT err1=0
rmtd: MT resid=0
rmtd: MT fileno=0
rmtd: MT blkno=0
rmtd: A 0                     <<< bad answer, causes abort 

rmtd: C
rmtd: A 0

One way to make it work is to make the blocksize 8192.   (10,000 fails,
20,000 fails, 32K fails, don't know about other values between 8192 and  
10,000).

Any ideas would be appreciated, especialy information about what the
mt_get is reporting two blocks before the error.  

./sys/mtio.h says:
ds is SCSI sense byte 0x02
err is error register sense byte 0x0C
err0 is sense bytes 0x13 and 0x14
err1 is sense bytes 0x15 and 0X16

Can anboy supplied bit definitions for those sense bytes?

--
L. W. "Dan" Danz                  VOS Mail:  Dan_Danz@vos.stratus.com
Sr Consulting Software SE         NeXT Mail: dan@az.stratus.com
Customer Assistance Center        Voice Mail/Pager: (602) 852-3107
Telecommunications Division       Customer Service: (800) 828-8513
Stratus Computer, Inc. 4455 E. Camelback #115-A, Phoenix AZ 85018
Newsgroups: comp.sys.next.sysadmin