Subject: Re: esp Disconnect Problems
To: None <curt@portal.ca, greywolf@siva.captech.com, torek@BSDI.COM>
From: Matthew Jacob <mjacob@feral.feral.com>
List: port-sparc
Date: 10/15/1996 08:29:49
>From torek@forge.BSDI.COM Tue Oct 15 04:41:05 1996
>
>>Why are these even needing to be settable things at all??????????????
>
>You need some way to disable disconnect to use certain broken SCSI
>devices.

Yes, this is select w/o ATN, or select with ATN but send the IDENTIFY
message w/o "Can Disconnect" bit set.

>  Also, the Emulex+NCR core `esp' device found in SPARC
>chipsets has quite a collection of bugs, most of which crop up
>only when using synchronous mode and/or reselection and/or `fast'
>mode.  Each rev has a different bug-set, so having a way to avoid
>triggering the hardware bugs is useful, in case the chipset *you*
>have has a bug that has not yet been seen and worked around.
>

Yes, I'm familiar with them. I did the esp driver for SunOS and
still have 18 inches of shelf space with Emulex (now Qlogic)
errata.

I guess that I'm alarmed that at this point bits turn off disc/rec
are still needed. I found them useful, but *rarely* necessary
in 1988 (helloooo! It's 1996....). Disconnect/reconnect should really
not be a problem any more. If they are because of a few devices, a
reasonable approach is to be unfriendly to these devices: run, w DISC/REC
enabled, but if the devices boob things, let a command timeout blow the
xfer away (noisily) and then restart the command (possibly with
disco/reco disabled automatically)- this might give market
encouragement to moving onto reasonable devices.

Now, SYNC mode is a problem, but mostly because of poor cabling
and termination (active termination has helped a lot), but automatic
(with hangs) determination (backoff to async and thence to dirty
cable mode) is still better than knobs.

Sigh... This stuff is *still* not worked out. Time for fibre channel.....