home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.next.sysadmin:4781 comp.sys.next.hardware:1453
- Path: sparky!uunet!usc!sdd.hp.com!samsung!transfer!quiensabe.az.stratus.com
- 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
- Message-ID: <5771@transfer.stratus.com>
- Date: 21 Aug 92 03:59:17 GMT
- Sender: usenet@transfer.stratus.com
- Reply-To: dan@az.stratus.com
- Followup-To: comp.sys.next.sysadmin
- Lines: 109
-
- 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
-