Path: utzoo!utgpu!watmath!iuvax!mailrus!husc6!rice!sun-spots-request
From: dan@wind.bellcore.com (Daniel Strick)
Newsgroups: comp.sys.sun
Subject: Re: Exabyte on Sparcstation-1 ?
Keywords: Hardware
Message-ID: <955@brazos.Rice.edu>
Date: 12 Aug 89 04:58:16 GMT
Organization: Sun-Spots
Lines: 124
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 98, message 3 of 15

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-4624