On Fri, Aug 11, 2000 at 05:16:00PM +0200, Martin Peschke wrote:
> The mentioned behavior should depend on whether we have an environment
> with several initiators or not. (Is it possible to detect this by means of
> INQUIRY?)
In general, it's not possible.
I disagree, the behaviour should NOT depend on the question how many
inititators there are on a bus.
The error handling strategy should be such, that detected SCSI resets do not
lead to further resets.
If a driver just resets its negotiated parameters and does give back all
sent (and queued) commands back to the mid-layer with DID_RESET, they will
be just requeued and not time out or be aborted (which could lead to a bus
reset).
That's the right thing, and I have no idea, what some drivers (or the new
EH?) do in order to screw things up and start reset wars.
BTW, I have a Am53c974 (tmscsim), a sym53c875 and a TRM-S1040 (dc395x_trm)
on a SCSI bus and never managed to start a reset war, despite manually
resetting the bus quite often.
> A more defensive error handling should be applied in such
> environments. A compromise: let the user decide, i.e. during kernel
> configuration by means of a SCSI midlayer option forcing defensive error
> recovery.
A more defensive strategy would be nice in all environments.
However, I disagree with those people that claim that a bus reset is never
any good. It is. As the last thing before finally failing, I prefer SCSI bus
resets. And I've seen devices saved by this.
However, the SCSI subsystem should get some memory. If there are a like two
consecutive bus resets caused by the same device, it should be just taken
offline.
Regards,
--
Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
PGP signature
