lk 2.4.27 error handling, ad infinitum
PATCH 1/1 lk 2.4.27 error handling, ad infinitum
Quoted 11 lines · dougg
The following scenario has been brought to my attention.
While handling a error (e.g. a timeout) the
scsi_send_eh_cmnd()function issues a (stalled) queued command. Now that command hits a repeatable failure (e.g. MEDIUM ERROR).In this scaenario it would seem that the "goto retry" forms an infinite loop re-issuing that command on the same (broken) block.
Comments?
No comments, so how about this patch. When the eh retries are exhausted the code drops through to FAILED state. If a command in foreground (i.e. not sent by the eh handler) exceeds it retries then SUCCESS is returned??
Doug Gilbert
drivers/scsi/scsi_error.c2427retry renamed from drivers/scsi/scsi_error.c +3 -1
@@ -664,7 +664,9 @@ SCpnt->eh_state = SUCCESS; break; case NEEDS_RETRY: - goto retry; + if ((++SCpnt->retries) < SCpnt->allowed) + goto retry; + /* fall through to FAILED if retries exceeded */ case FAILED: default: SCpnt->eh_state = FAILED;
falling into FAILED status will put the device in offline state, isn't it? saeed
Quoted 37 lines · Douglas Gilbert
Quoted 11 lines · dougg
The following scenario has been brought to my attention.
While handling a error (e.g. a timeout) the
scsi_send_eh_cmnd()function issues a (stalled) queued command. Now that command hits a repeatable failure (e.g. MEDIUM ERROR).In this scaenario it would seem that the "goto retry" forms an infinite loop re-issuing that command on the same (broken) block.
Comments?
No comments, so how about this patch. When the eh retries are exhausted the code drops through to FAILED state. If a command in foreground (i.e. not sent by the eh handler) exceeds it retries then SUCCESS is returned??
Doug Gilbert
------------------------------------------------------------------------
drivers/scsi/scsi_error.c2427retry renamed from drivers/scsi/scsi_error.c +3
-1@@ -664,7 +664,9 @@ SCpnt->eh_state = SUCCESS; break; case NEEDS_RETRY: - goto retry; + if ((++SCpnt->retries) < SCpnt->allowed) + goto retry; + /* fall through to FAILED if retries exceeded */ case FAILED: default: SCpnt->eh_state = FAILED;
Quoted 11 lines · Douglas Gilbert
Quoted 10 lines · dougg
The following scenario has been brought to my attention.
While handling a error (e.g. a timeout) the
scsi_send_eh_cmnd()function issues a (stalled) queued command. Now that command hits a repeatable failure (e.g. MEDIUM ERROR).In this scaenario it would seem that the "goto retry" forms an infinite loop re-issuing that command on the same (broken) block.
Quoted 6 lines
Quoted 1 line
Comments?
No comments, so how about this patch. When the eh retries are exhausted the code drops through to FAILED state. If a command in foreground (i.e. not sent by the eh handler) exceeds it retries then SUCCESS is returned??
Saeed reports that breaking out of the retry loop with eh_state set to SUCCESS does successfully handle the problem.
Change:
- break out of a repeatable error retries when already in "eh" (error handling) mode
Doug Gilbert
drivers/scsi/scsi_error.c2427retry2 renamed from drivers/scsi/scsi_error.c +4 -1
@@ -664,7 +664,10 @@ SCpnt->eh_state = SUCCESS; break; case NEEDS_RETRY: - goto retry; + if ((++SCpnt->retries) < SCpnt->allowed) + goto retry; + SCpnt->eh_state = SUCCESS; + break; case FAILED: default: SCpnt->eh_state = FAILED;