panagiot@ouranos.tn.cornell.edu (Thanasis Panagiotopoulos) (07/27/89)
I have an Exabyte EXB8200 tape drive, which I used to have connected to a Sun 3/50 running 4.0.3. No special device drivers were required and the tape behaved as a "standard" st tape to the system. I tried to move the tape to a Sparcstation-1 (4.0.3c), which required a special cable for the connection. On boot time, the message: st0 at esp0 target 4 lun 0 st0: unsupported drive found - ignored appears, and further attempts to access the tape are unsuccessful. Any suggestions as to what I may be doing wrong? Has anybody successfully installed an Exabyte on a Sparcstation-1? Thanasis Panagiotopoulos School of Chemical Engineering, Cornell University panagiot@ouranos.tn.cornell.edu
dan@wind.bellcore.com (Daniel Strick) (08/12/89)
In sun-spots digest v8n86, panagiot@ouranos.tn.cornell.edu said he
attached an Exabyte drive to a sun-4/60 and during autoconfiguration it
said:
st0 at esp0 target 4 lun 0
st0: unsupported drive found - ignored
I am not very familiar with SUN SCSI, but I have been working with other
SCSI recently and I think I can shed some light on the problem (or at
least substitute a new source of confusion). The following comments are
highly speculative, especially the suggested "fix". I doubt it is quite
correct. I don't have time to try it myself (and I don't have one of
those new SCSI adapter cables). If it is close enough to the truth,
perhaps someone else can experiment with it and work out the details. If
so, I would like to hear about it.
What the 4.0.3c SCSI driver says it did with the Exabyte drive is clear
(if you are familiar with SCSI and read between the lines). The driver
examined the SCSI inquiry data for the SCSI widget with bus id 4 and
decided it was not an acceptable widget. Therefore the driver did not
autoconfigure the unit.
I suspect that in this context "unsupported drive" means "unknown drive
type". While I don't condone such inflexibility, I do understand the
attitude. SCSI devices, particularly tape drives, do not always plug'n
play. At least the driver recognized a problem. This may actually be a
step forward.
I think we must be dealing with the "new Corporate SCSI driver" mentioned
by Kemp@DOCKMASTER.NCSC.MIL in sun-spots v7n297. If you have a sparc
station with 4.0.3c, take a look in /sys/scsi. I never saw this directory
before. Take a look at the SCSI widget configuration lines in the GENERIC
configuration file:
...
device-driver esp # Emulex SCSI interface
...
scsibus0 at esp # declare first scsi bus
disk sd0 at scsibus0 target 3 lun 0 # first hard SCSI disk
disk sd1 at scsibus0 target 1 lun 0 # second hard SCSI disk
disk sd2 at scsibus0 target 2 lun 0 # third hard SCSI disk
disk sd3 at scsibus0 target 0 lun 0 # fourth hard SCSI disk
tape st0 at scsibus0 target 4 lun 0 # first SCSI tape
tape st1 at scsibus0 target 5 lun 0 # first SCSI tape
Magic! No controllers with register addresses and interrupt vectors.
Instead we have SCSI address terminology ("target" and "lun").
Someone at SMI has been hacking on the Berkelix kernel config program.
Look at the mapping between disk numbers and physical unit (target) numbers.
Someone at SMI must be on drugs. I can't wait to see the new manual on
writing device drivers.
I went hunting in /sys/scsi for hints about configuration options and found
/usr/share/sys/scsi/targets/stdef.h. It contains #defines for many different
"supported tape device types" (including ST_TYPE_EXABYTE), #defines for a
bunch of "supported drive options", and a definition of "struct st_drivetype"
which looks like it maps inquiry data into drive feature descriptions.
Oddly enough (for a header file), there is an initialized array called
"st_drivetypes[]". Three drive types are defined. All are varieties of QIC.
Most of the #defines are unused.
(BEGIN salivation)
There is also a #define for MAX_TAPE_DEVICES (the number of defined drive
types). There is no global variable initialized to this value. There is
also no source file that #includes stdef.h. /usr/share/sys/sun4c/OBJ/st.o
contains a definition of the global symbol st_drivetypes in the initialized
data segment.
(END salivation)
It looks like we will need to patch the binary. Ick. First we must decide
which drive definition to replace. Pick one:
st_drivetypes+0: Emulex MT-02 (used with the old QIC-24 drives)
st_drivetypes+0x2c: Archive 2150S ? (QIC-150, 120, 24, 11?)
st_drivetypes+0x58: Wangtek ? (QIC-150?)
Then we need to decide what to use for the Exabyte. This will probably
require some experimentation. My first attempt would be a definition
like:
"Exabyte", 7, "EXABYTE", ST_TYPE_EXABYTE,
0, {0,0,0,0}, {0,0,0,0}, ST_VARIABLE|ST_AUTODEN_OVERRIDE
Then we need to convert this to numbers and patch. The first string is
used to initialize a character pointer. We can leave this alone.
I think the rest compiles to (see stdef.h):
addr+4: 0x07455841, 0x42595445, 0, 0, 0, 0, 0, 0x280000, 0, 0, 0x201
This would be for a variable record size mode of operation. We don't
actually know for sure the driver will generate a mode select, so it
might be useful to configure the drive this way. It might also be
a good idea to configure it for "even-byte" disconnect. I am guessing
that ST_AUTODEN_OVERRIDE means to use the default density. If my guess is
wrong, then the symptom might be complaints about mode selection failures.
If you really want a fixed record size mode, I assume it is to maintain
compatibility with old drivers and you want 1024 byte records. The second
line of the drive definition might change to:
1024, {0,0,0,0}, {0,0,0,0}, ST_AUTODEN_OVERRIDE
There are a bunch of driver option flags that might apply. We have to
guess at what they mean. ST_NODISCON might help if you seem to have very
low level SCSI problems, especially if you didn't go for the "even-byte"
disconnect, but this might have painful side effects. ST_BSF and
ST_BSR might apply, but ST_BSR might encourage the driver to try the
old backspace-and-overwrite-filemark hack and I don't think this works
quite traditionally on the Exabyte. I won't guess at interpretations of
the other flags.
I wouldn't bet that any of this stuff works. One possible explanation
for the very short builtin drive type list is that the other stuff is not
yet implemented or at least not tested. The defined but unused drive
type codes might represent good but overly optimistic intentions.
I suspect support for the Exabyte drive will show up in a future release.
It is very popular outside of SMI (I count references in 100 sun-spots
articles beginning with v5n46, 9/22/87). I hear it is popular inside SMI.
If you really want SUN SCSI to attempt to support generic device types,
you should let your SUN sales rep know that this is something you value
and that you consider this before filling out purchase requisitions.
Dan Strick, Bellcore, dan@bellcore.com, bellcore!dan, (201)829-4624jc%andataco.uucp@ucsd.edu (John Cornelius) (08/16/89)
On the Sparcstation version of 4.0.3 Sun has left the entry for the Exabyte out of the table of recognized device types. The table can be found in ....sundev/streg.h and is called st_drivetab1. The information in streg.h for Sun-3s can be used as a guide for patching ...OBJ/st.o. I'm going to be doing this later today on a Sparcstation at a customer's site. For details you can send mail to inquire%andataco.uucp@ucsd.edu and I'll send you the patch. John Cornelius Andataco
mike@uunet.uu.net (Mike Crawford) (08/31/89)
As long as we are discussing Exabytes... We have a peculiar bug in in which, whenever we do a restore from our Exabyte, our ALM-2 ports get trashed. What happens to them is when one types on them, nothing comes is echoed. When pressing the return key, what was typed is then echoed. Rebooting will fix this. I would like to be able to move my Exabyte from the 3/180 to our 3/60, partially to avoid this problem, but I do need a proper cable set and driver. It is not clear to me that this will work. I plan to go to 4.0.3 soon -- but I wanted to see what kind of excitement it would generate on the net! We have an exabyte on a Sun 3/180 running SunOS 4.0.1. We are using a Ciprico Rimfire SCSI controller. From /sys/sun3/conf/OCTEL: # the Rimfire (cipricol) Controller & SCSI for Exabyte # a SCSI tape (expbyte) at Target ID=5, Logical Unit Number=0, # controller rfsdc0 at vme16d32 ? csr 0x5000 priority 2 vector rfsdintr 0xF8 tape rfsd0 at rfsdc0 drive 40 flags 0x00211 # We also have for the mcp, pseudo-device mcpa64 device mcp0 at vme32d32 ? csr 0x01000000 flags 0x1ffff priority 4 vector mcpintr 0x8b Michael David Crawford Consulting for: Oddball Enterprises Octel Communications Corp 694 Nobel Drive 890 Tasman Drive Santa Cruz, CA 95060 Milpitas CA 95035 pyramid!vsi1,!octel!mike CI$ 72377,623
kandler@lan.informatik.tu-muenchen.dbp.de (Matthias Kandler) (09/05/89)
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
This is with almost every combination of 'ST_*' flags I tried. (I didn't
try all the 2^11 possibilities). The only exception is if I set ST_REEL. Then
the error message complains about 'illegal requests' which I think is even
worse.
You, who have some insight into the problems of SCSI. Do you know what is
going on ?
Matthias Kandler Inst. f. Informatik LOC=lan.informatik.tu-muenchen.dbp.de
TU Muenchen kandler@LOC
Postfach 20 24 20 kandler%LOC@{unido.uucp,relay.cs.net}
D-8000 Muenchen 2 Telefon: (089) 2105 2025mjacob@sun.com (Matt Jacob) (09/24/89)
Exabyte is *not* a supported drive. Trying to outsmart the driver is not smart in this instance. I put the message in for a reason- when I said 'not supported' I meant that. I don't play games with saying something works, and then it doesn't. Nor do I vouch for equipment I haven't either tested myself or have had someone test with my code. The fact of the matter was that I didn't *have* an Exabyte to work with during SS1 development- ergo, no support. I also understand that some of you out there had found that Exabytes worked with other Sun releases. This is being addressed as best as can be done. Contact Sun Consulting- a moderately cheap alternative may be available *very* soon. -matt jacob
dan@wind.bellcore.com (Daniel Strick) (10/03/89)
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