----- Original Message -----
From: Matthew Jacob <[EMAIL PROTECTED]>
To: Richard Waltham <[EMAIL PROTECTED]>
Cc: Kurt Garloff <[EMAIL PROTECTED]>; Linux SCSI list
<[EMAIL PROTECTED]>
Sent: Sunday, February 21, 1999 10:30 AM
Subject: Re: delay after SCSI bus reset
>
>> >The answer is to have a SCSI middle layer that defers (re)queueing
>> >commands to the HBA's until after a (tunable) delay has occurred.
>> >Strictly speaking the delay is a per-target value since the amount of
>> >recovery time after a reset until a target can actually accept selection
>> >is not covered by the SCSI specification.
>> >
>> >
>>
>> Section 5.7 of the SCSI 2 spec mentions a value of 250ms for a hard reset
to
>> selection time - but its only a recommendation.
>>
>
>I don't have my SCSI spec in front of me- this may simply be the
>propagation of the recommended selection timeout of 250ms - if initiators
>will wait up to 250ms then try and be ready before that time has elapsed.
>But there's no guarantee past SCSI bus reset whether a device will respond
or
>not.
>
>
Very true:)
The spec says:
"5.7.14 Reset to Selection time
The recommended maximum time after a hard RESET condition until a SCSI
target is able to respond with appropriate status and sense data to the TEST
UNIT READY, INQUIRY, and REQUEST SENSE commands."
However this doesn't mean it will be able to do anything useful. A tape unit
for example could take several minutes to get back to a usable state if it
is way down tape and does a rewind in response to a reset. But the SCSI code
should be able to use the status returned by Test Unit Ready and Request
Sense data to recover reasonable gracefully.
In my experience a timeout on a device is more often than not caused by some
other device holding on to the SCSI bus for too long, even if it is working
correctly. Doing something about this type of event would avoid unnecessary
bus resets and subsequent problems recovering from resets.
An extreme example:) A disk is executing commands. At some point in a
command it disconnects. A tape command is started, say a rewind which can
take some time, If the tape drive does not disconnect, allowing the disk to
finish the command, the disk command is almost certain to timeout. BUT the
tape unit is executing a perfectly valid command. IMHO the disk should wait
for the tape to complete or the tape to timeout! This is all to do with
timeout strategy rather than actual timeout values. The only way round this
at the moment, as far as I see it, to avoid unnecessary device timeouts is
to set all the timeouts to the maximum timeout of the slowest device. :( Or
put slower devices on a separate controller. I use the second approach even
though my tape drive behaves perfectly reasonably and does disconnect.;)
Richard
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
