tree e6f630c08223f71d1cbb502213503404ec65d86f
parent 4dddbc26c3895ecdab1f4b16435685b47f96f599
author Alan Stern <[EMAIL PROTECTED]> Thu, 31 Mar 2005 01:05:45 -0500
committer James Bottomley <[EMAIL PROTECTED](none)> Wed, 07 Sep 2005 03:19:23 

[SCSI] return success after retries in scsi_eh_tur

The problem lies in the way the error handler uses TEST UNIT READY to
tell whether error recovery has succeeded.  The scsi_eh_tur function
gives up after one round of retrying; after that it decides that more
error recovery is needed.

However TUR is liable to report sense data indicating a retry is needed
when in fact error recovery has succeeded.  A typical example might be
SK=2, ASC=4, ASCQ=1 (Logical unit in process of becoming ready).  The mere
fact that we were able to get a sensible reply to the TUR should indicate
that the device is working well enough to stop error recovery.

I ran across a case back in January where this happened.  A CD-ROM drive
timed out the INQUIRY command, and a device reset fixed the blockage.
But then the drive kept responding with 2/4/1 -- because it was spinning
up I suppose -- until the error handler gave up and placed it offline.
If the initial INQUIRY had received the 2/4/1 instead, everything would
have worked okay.  It doesn't seem reasonable for things to fail just
because the error handler had started running.

Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>

 drivers/scsi/scsi_error.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -776,9 +776,11 @@ retry_tur:
                __FUNCTION__, scmd, rtn));
        if (rtn == SUCCESS)
                return 0;
-       else if (rtn == NEEDS_RETRY)
+       else if (rtn == NEEDS_RETRY) {
                if (retry_cnt--)
                        goto retry_tur;
+               return 0;
+       }
        return 1;
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to