Sun-3 shoeboxes on SPARCs

[Yuval Tamir]

In article <1003 at brchh104.bnr.ca> I wrote:
>Sun does not support the use of old Sun-3 shoeboxes on SPARCstations.
>However, many people are using them successfully.
>Problems occur when you connect to the same SCSI bus
>a modern SCSI disk (embedded SCSI) with the old shoeboxes
>(with their SCSI-ESDI converter).
...

I received several useful messages.

I now believe that the situation is as follows:

The default transmission mode in SCSI is always Async. It is only when a
successful negotiation between an initiator (the Sparcstation in this
case) and a specific SCSI target occurs that Synchronous Data Transfers
will occur. The host adapter driver maintains the state on a per-target
basis w.r.t. sync. capabilities.  This state is cleared on each CHECK
CONDITION (to catch the case that somebody powered off and on a specific
target), and starts out as unknown at boot time.

In order to run sync. SCSI you need a *very* clean signal environment.
There is some concern that the older devices contribute to making the
signals a bit noisy, hence the 'official' position about not mixing and
matching.

Some people say that mixing old and new devices does not work:

|I know from bitter experience that it flat out does not work to mix those
|two different types of drives.  Usually the shoebox drive isn't even
|"seen" by the OS.

|The old Sun3 shoebox works just fine by itself.  Would NOT work when I
|tried an internal Quantum 104 as well (the system just didn't see the
|shoebox disk).  That was with SunOS4.1.

|I've heard rumors of folks who sort of have gotten the internal + shoebox
|combo to sort of work, but I suspect not reliably.

|Our local Sun field service engineer (an old friend, who I trust to know
|what he's talking about), says to stay away from the combination like you
|would the black plague.

After trying it myself, and learning the hard way, I agree with him.
Others don't have any problems.  It just works.

One possibility is to disable sync SCSI in the kernel.  This will prevent
the use of sync even for the new disks and thus reduce the potential for
problems caused by the old device (see above).  One response to this idea
was:

|Well, it's cautious. Failures caused by noise problems are always
|detectable, and usually are recoverable (although not a 100%). There are
|two syndromes that are known to be 'noise' related: active SCSI command
|timeouts (where it times out during a data phase), and DATA OVERRUN
|conditions. With the former, the host adapter driver correctly adjudges
|this to be a noise related problem and marks the state for the target
|being talked to as 'weak' so that when the next command to that target is
|sent async. mode is renegotiated (the data overrun condition should have
|this too, but it doesn't yet). At any rate, the only recovery path when
|the target is hung due to a noise related problem is to reset the SCSI
|bus.  The command that was active is usually considered safe to retry if
|it was the disk (sd) driver that had sent it, but tape operations are
|always lost (a SCSI bus reset causes tapes to lose state information).

|I guess what I'm saying is that for all the reasonable configurations I've
|ever worked with that mixing and matching is okay, but if you want to be
|extra cautious, you can disable sync. mode.

My conclusion is to disable sync mode. As I mentioned in my original
message, this can be done by commenting out the SCSI_OPTIONS_SYNC line in
/sys/scsi/conf/scsi_confdata.c There is also a way to do it via adb (I am
not sure of the details).

Thanks to all the people who sent me information.  I am not mentioning any
names to protect the helpful.  It would have been nice if Sun had released
all this information instead of simply saying "not supported".

			   Yuval Tamir

Internet: tamir at cs.ucla.edu
    UUCP: ...!{uunet,ucbvax,rutgers}!cs.ucla.edu!tamir