Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!mit-eddie!uw-beaver!rice!sun-spots-request
From: dan@wind.bellcore.com (Daniel Strick)
Newsgroups: comp.sys.sun
Subject: Re: Exabyte on Sparcstation-1 ?  (the saga continues) [LONG]
Keywords: Hardware
Message-ID: <1885@brazos.Rice.edu>
Date: 3 Oct 89 00:15:21 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 76
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 149, message 10 of 10

In Sun-spots Digest v8n122, kandler@lan.informatik.tu-muenchen.dbp.de writes:

    I patched st.o as dan@wind.bellcore.com (Daniel Strick) suggested in
    <955@brazos.Rice.edu>. The positive result was that
         'st0: unsupported drive found - ignored'
    disappeared. Dan, your guess about ST_AUTODEN_OVERRIDE is correct. This
    flag must be set to stop complaints about mode selection failures.

    But I still can't write to the Exabyte. I tried fixed and variable record
    size and experimented whith the other driver options flags. During write
    I get the error message:
         esp0: 4.0 data exhaust, stat 0x10<XZERO>
         laststate 'UNKNOWN' last cmd dma tran_info
         last dma 0xfff048b8 current dma 0xfff04cb8;dma csr 0x80000000
         command transport failed: reason 'reset.., retrying command

While I don't actually know what this error message means, I am willing to
speculate:  the Exabyte 8200 is operating in fixed block mode with a block
size of 1024.  The SCSI driver is expecting a fixed block size of only 512
bytes (QIC standard).

Quickie Tutorial: In SCSI "variable block mode" the transfer length is
specified in the SCSI Command Descriptor Block (aka "CDB") as a number of
bytes.  The data associated with a single SCSI read or write command is
stored on tape in a single block (aka "record") of the specified size.  In
SCSI "fixed block mode" the transfer length is specified in the CDB not as
a number of bytes but as a number of blocks and the data is stored on tape
in that many different blocks.  The mode (fixed or variable) and the block
size (if in fixed block mode) are determined by the device and are somehow
known to the device driver ("somehow" is too complicated to explain here).
The driver sets a special flag bit in each read/write CDB if it thinks the
device is in fixed block mode.  If the "fixed bit" is wrong, the device is
supposed to return the "illegal request" error code.

Now suppose the driver thinks the block size is 512, the tape drive thinks
the block size is 1024, and we attempt a 10 KB write using the unix "raw"
device.  When the driver builds the CDB, it decides that 10 KB translates
into a transfer count of 20 blocks.  When the tape drive interprets the
CDB, it figures that 20 blocks means 20 KB.  After the first 10 KB have
been transferred, the SCSI host adapter runs out of data but the SCSI
device wants to keep going.  (In my not so humble opinion, the transfer
length should always be specified in bytes and there should be no
distinction between fixed and variable mode CDBs.  The drive should be
free to use fixed record lengths and to reject I/O requests with
inappropriate transfer lengths.  The Fixed Block Mode CDB is one of the
greatest gratuitous blunders in the history of Western technology.
Backward compatibility is not adequate justification for an aesthetic
botch of such magnitude.)

As evidence for the plausibility of this scenario, I note that the device
type related definitions in the header file for the new SCSI device driver
are essentially identical to the same definitions in the older SCSI
driver.  I bet the header file was lifted from the old driver and that
therefore the new driver might not implement features implied by the
header file.  In particular, it might not use the block size value in the
st_drivetype struct and it might not use the ST_VARIABLE option flag.  As
evidence for this speculation, I note that the drive type list actually
used by the driver includes only QIC drives.

If I am right so far, then the only way to make an Exabyte 8200 work on a
pizza box using the current driver would be to put the drive into 512 byte
block mode.  As far as I know, there is no way to jumper an Exabyte 8200
to power up in this mode (it likes 1024 byte blocks).  If we could make
the the driver try to set the density code to zero then it might set the
block size as a side effect, but such speculation is not profitable.
Operating an Exabyte 8200 in 512 byte fixed block mode might be a mistake.
It would waste half the tape and half the transfer rate.  I concede that
1/2 of 2 GB is better than none and that 1/2 of 240 KB/sec beats out a QIC
drive, but the use of 512 byte blocks would also produce tapes that could
not be exchanged with the vast majority of Sun/Exabyte systems that still
run in 1024 byte fixed block mode.

The bottom line is: you can't use an Exabyte 8200 on a Sparcstation-1
until the driver is significantly enhanced.

Dan Strick, Bellcore, dan@bellcore.com, bellcore!dan, (201)829-4624