On Fri, 23 Jul 1999, D. Lance Robinson wrote:
> Gerard Roudier wrote:
> >
> > On Thu, 22 Jul 1999, D. Lance Robinson wrote:
> >
> > About the patch below, it should be fine, but NO_CONNECT is not the usual
> > abbreviation used to designate SELECTION TIMEOUT. Perhaps something
> > defined as DID_SEL_TIMEOUT and matching DID_NO_CONNECT would make driver
> > code more readable.
>
> Looking at scsi_error.c, it has the following code that leads me to
> think that using DID_NO_CONNECT is okay. My purpose for doing this is in
I didn't mean that it is not okay, but that this define is just confusing.
Never saw of such a way to designate a SELECTION TIMEOUT status. I just
suggest to add the following:
#define DID_SEL_TIMEOUT DID_NO_CONNECT
and to use DID_SEL_TIMEOUT instead in low-level driver sources.
The difference is that the source code get understandable at the time you
read it.
> the case that someone hot-removes a scsi disk and it will get a select
> timeout. Without being more specific about the timeout condition in the
> low level return code, the error recovery code tries too hard to
> recover.
People that want to remove SCSI devices from a SCSI BUS that is not
compliant with the "removal and insertion of SCSI devices" clause of the
SPI spec, must not expect any guarantee of recovery, neither they want to
expect all their SCSI devices to still be alive after such an operation.
Only conformant stuff is to be supported. Any tampering that may happen to
be usefull but that can break something (or everything) is _not_ supported
at all. Wild hot-plugging is not supported. I am pleased if it works for
somebody and even hope it will work for everybody, but I just give a _no_
support statement to such operations.
> Or, are there times when a device will lock-up and not even
> select--times where a reset would slap it awake? If the device is that
> much out-to-lunch, I'm not sure I want to reset and retry the operation
> ;-) Just say bye-bye to the drive.
> In the code below, I don't think that SUCCESS is the best definition
The sense of such a SUCCESS return value is explained in the source,
it seems. I agree that it is as confusing as the DID_NO_CONNECT define.;)
> for a select timeout action, but of all the available options, it is
> okay. hopefully, the upper layer will see than nothing actually
> happened.
Selection timeouts are commonly used in device discovery process as a 'non
existing device' status. The timeout is usually set to 250 ms. In
mono-initiator environments, this heuristic never fails, but it is just an
heuristic.
> Comments...
> <>< Lance
>
> Here is a snippet from scsi_error.c...
>
> int scsi_decide_disposition( ?? ) {
> ...
> ...
> case DID_NO_CONNECT:
> case DID_BAD_TARGET:
> case DID_ABORT:
> /*
> * Note - this means that we just report the status back to the
> * top level driver, not that we actually think that it indicates
> * success.
> */
> return SUCCESS;
> ...
> ...
> case DID_TIME_OUT:
> /*
> * When we scan the bus, we get timeout messages for
> * these commands if there is no device available.
> * Other hosts report DID_NO_CONNECT for the same thing.
> */
> if( (SCpnt->cmnd[0] == TEST_UNIT_READY ||
> SCpnt->cmnd[0] == INQUIRY) )
> {
> return SUCCESS;
> }
> ...
> ...
By the way, I donnot see any advantage of returning DID_NO_CONNECT instead
of DID_TIMEOUT from the code above, in case of a SELECTION TIMEOUT for a
command.
Regards,
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
