On 1 Jan 1999, Marc SCHAEFER wrote:
> Matthew Jacob <[EMAIL PROTECTED]> wrote:
> > Should-
> > Disable SCSI resets if you can or expect some 'startup heartburn'
> > whenever either side reboots.
>
> This is not sufficient. This means that if the SCSI bus gets stuck,
> you won't be able to unstuck it. Probability of it is very low,
> however. But proper implementations means
>
> when bus locked -> SCSI RESET
> when SCSI reset (from us or other side) -> restart commands
>
> This is detail, however you can't assume that there won't be any
> RESET ... especially since most Linux drivers do SCSI reset for
> peanuts, such as parity errors.
A peanut can sometimes hide a coconut. :)
A SCSI parity error is not peanuts. It just means that a signal level
has been wrongly transmitted and if this happens to handshaking signals
then the BUS may get locked or overflow may happen. On the other hand
a double SCSI parity error may lead to undetected errors.
On a reliable SCSI BUS, the probability of a SCSI parity error is so low
that resetting the BUS on such an error is not a problem.
Anyway, not resetting means that the recovery procedure worked gracefully
and, to be frank, I haven't been ever able to recover a SCSI parity error
without locking the BUS using the ncr53c8xx driver.
BTW, if you want to really support multi-initiator, then you will also
want to implement support for the SCSI reservation protocol and be
carefull about sense data returned by devices, notably when a device is
resetted by another initiator.
You may also want to consider that it may happen that many SCSI devices
will not behave correctly in multi-initiator environment for the simple
reason that they are rarely used this way.
Regards,
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
