Subject: Re: esp Disconnect Problems
To: None <mjacob@feral.com>
From: James Graham <greywolf@siva.captech.com>
List: port-sparc
Date: 10/15/1996 11:00:10
Matthew Jacob sez:
# 
# 
# 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.

[loudly]:  Hey, look, everyone!  We have a volunteer for re-writing
the esp driver for the SPARC port!

Mr. Jacob, I'd _love_ to see something like this, but your claim of
having "market encouragement" does nothing to help us poor sots who
are running on outdated but _free_ equipment.  I currently have:

	SUN0669
	SUN0424
	FUJITSU M2652F (1G)
	EXB-8200
	SUN 1x CDROM

hanging off my SLC's SCSI bus.  That's 2G of disk space that I'd really
rather not have to outlay cash to _replace_!  I mean, 2G is nothing to
sneeze at, especially considering the entire aforementioned system
was _given_ to me.  Now if you want to buy me a reasonable system,
I'll accept your offer.  But for now, it's a system and it WORKS!

And the prospect of "blowing the xfer away (noisily)" is exactly what
was happening to me on EVERY transfer that happened while more than
one SCSI event was queued on the bus.  This meant that I could not
do backups or restores on my system, and that I could not UPGRADE
my system to 1.2_BETA from 1.1 until I managed to get someone to compile
a kernel for me.

# 
# 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.

I saw stuff like this in SunOS 4.1.2; it appeared to have been fixed
(or silenced) in SunOS 4.1.3 and thereafter.  I never saw the hangs,
but I did see backoffs reported.

But it's not better than knobs if the knobs work and the algorithms
don't.  Until this can get fixed without getting too bloatful and resemblent
of the Lee brothers (Home and Ug), knobs are fine.

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

By the time this stuff is "worked out", it will _still_ have been worth
the wait.  In the meantime we have a workaround.  If you have a better one,
implement it, test it rigorously, and send-pr it until it gets put into the
release branch.  If, for whatever reason, you will not or can not help with
a better driver, live with the workaround.

I, for one, am extremely grateful that a workaround even exists, because
it means that I can now run my system.

Oh, yeah...

#undef SOAPBOX

	(--*(struct _u *)greywolf)->u_flags |= U_GRATEFUL_FOR_NETBSD_SPARC;