Subject: check this out...

From: "David S. Miller" <[email-masked]>
Date: Fri, 10 May 1996 07:19:33 -0400

(Leonard, I thought you'd get a kick out of this...)

I stress tested my new Sparc SCSI driver with the following bus
configuration:

	ID 3: SCSI2 Seagate disk
	ID 4: pre-CCS SCSI1 disk of unknown vendor type ;-)
	ID 5: FAST SCSI2 Conner drive

I ran three instances of a program which just did random seeks
forever, one on each drive. (thank god for lmbench programs which have
dual role as stress/stability testers ;-)

I was getting bus lockups now and then, and happily my abort/reset
code completely recovered the bus back into a working state and things
proceeded.  After about 30 minutes of analyzing state dumps from my
driver when this would happen I figure out what was going on.  My
driver now fixes this problem and does not reset anymore no matter how
hard I smash all the drives on this chain.

Anyways, to get to the point, for your edification Leonard, here is
the comment above my fix for the problem. Enjoy ;-)

		/* A fix for broken SCSI1 targets, when they disconnect
		 * they lock up the bus and confuse ESP.  So disallow
		 * disconnects for SCSI1 targets for now until we
		 * find a better fix.
		 *
		 * Addendum: This is funny, I figured out what was going
		 *           on.  The blotzed SCSI1 target would disconnect,
		 *           one of the other SCSI2 targets or both would be
		 *           disconnected as well.  The SCSI1 target would
		 *           stay disconnected long enough that we start
		 *           up a command on one of the SCSI2 targets.  As
		 *           the ESP is arbitrating for the bus the SCSI1
		 *           target begins to arbitrate as well to reselect
		 *           the ESP.  The SCSI1 target refuses to drop it's
		 *           ID bit on the data bus even though the ESP is
		 *           at ID 7 and is the obvious winner for any
		 *           arbitration.  The ESP is a poor sport and refuses
		 *           to lose arbitration, it will continue indefinately
		 *           trying to arbitrate for the bus and can only be
		 *           stopped via a chip reset or SCSI bus reset.
		 *           Therefore _no_ disconnects for SCSI1 targets
		 *           thank you very much. ;-)
		 */

Later,
David S. Miller
[email-masked]