Xref: utzoo comp.sys.sun:9957 comp.periphs.scsi:610
Path: utzoo!attcan!uunet!cs.utexas.edu!rice!sun-spots-request
From: dar@nucleus.mi.org (Dario Alcocer)
Newsgroups: comp.sys.sun,comp.periphs.scsi
Subject: Re: Exabyte and file positioning...
Keywords: Hardware
Message-ID: <8668@brazos.Rice.edu>
Date: 7 Jun 90 20:51:34 GMT
Sender: root@rice.edu
Followup-To: comp.sys.sun
Organization: Sun-Spots
Lines: 38
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n197, Replies: v9n202, Related: v9n141
X-Sun-Spots-Digest: Volume 9, Issue 202, message 13

felix@warbucks.ai.sri.com (Felix Ingrand) writes:

>We are running 4.0.3 on a Sun-4/280.  Our Exabyte is on the SCSI port
>using the driver rst0. It looks like we are having some troubles with the
>file positioning on the tape. We are only using nrst0, and we are getting
>the following:

>Jun  5 13:22:43 sunset vmunix: st0:  illegal command
>Jun  5 13:22:43 sunset vmunix: st0:  failed cmd =  a  0  0  c8  0  0  
>Jun  5 13:22:43 sunset vmunix: st0 error:  sense key(0x5): illegal request
>Jun  5 13:22:43 sunset vmunix:            sense = 70  0  5  0  0  0  0  12  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  22  f3  99  0  0  
>Jun  5 13:22:43 sunset vmunix: 

>Felix

I'm not exactly sure what's the problem, but I have a few observations:

The command that failed was a WRITE command; 1st byte in cmd is the
operation code.  In the failed cmd, the 2nd byte is 0, implying that a
variable-length block write of 0xc800 bytes (3rd, 4th, and 5th bytes in
cmd) was requested.

However, if the length isn't between MINBLKLEN and MAXBLKLEN, you'll get
an illegal request sense key, as per the ANSI document.  Incidentlly,
according to the Exabyte docs (EXB-8200 User's Manual) I have, a maximum
variable length block can be at most 0x3c00, which is _smaller_ than
0xc800 bytes, may be a problem there, don't know what model you're using.

Also, the drive may have already been in fixed-length block mode, which
will also result in illegal request.  That's the SCSI end of things.  I'm
not sure as to tar and mt, I'm not familiar enough to know if there is
something they are doing to cause this.

Hope this helps somewhat.

Dario Alcocer                | Internet: dar@nucleus.mi.org
Associate Software Engineer  | voice: 619-673-2161, x5119
Emerald Systems              | Standard disclaimers apply.