Skip to content

Commit

Permalink
[SCSI] return success after retries in scsi_eh_tur
Browse files Browse the repository at this point in the history
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 <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
  • Loading branch information
Alan Stern authored and James Bottomley committed Sep 6, 2005
1 parent 4dddbc2 commit e47373e
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion drivers/scsi/scsi_error.c
Original file line number Diff line number Diff line change
Expand Up @@ -776,9 +776,11 @@ static int scsi_eh_tur(struct scsi_cmnd *scmd)
__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;
}

Expand Down

0 comments on commit e47373e

Please sign in to comment.