(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
davem@caip.rutgers.edu
|