Fix up an off by one error in calculating retries for scsi
commands. This bug was discovered when an SG_IO request
was sent to scsi core with retries = 0, causing the overall
timeout check to go off in scsi_softirq_done.
Signed-off-by: Brian King <brking@xxxxxxxxxx>
---
linux-2.6-bjking1/drivers/scsi/scsi_error.c | 4 ++--
linux-2.6-bjking1/drivers/scsi/scsi_lib.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff -puN drivers/scsi/scsi_lib.c~scsi_fixup_retries drivers/scsi/scsi_lib.c
--- linux-2.6/drivers/scsi/scsi_lib.c~scsi_fixup_retries 2006-02-24 13:53:28.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/scsi_lib.c 2006-02-24 13:53:47.000000000 -0600
@@ -1498,7 +1498,7 @@ static void scsi_kill_request(struct req
static void scsi_softirq_done(struct request *rq)
{
struct scsi_cmnd *cmd = rq->completion_data;
- unsigned long wait_for = cmd->allowed * cmd->timeout_per_command;
+ unsigned long wait_for = (cmd->allowed + 1) * cmd->timeout_per_command;
int disposition;
INIT_LIST_HEAD(&cmd->eh_entry);
diff -puN drivers/scsi/scsi_error.c~scsi_fixup_retries drivers/scsi/scsi_error.c
--- linux-2.6/drivers/scsi/scsi_error.c~scsi_fixup_retries 2006-02-24 13:53:51.000000000 -0600
+++ linux-2.6-bjking1/drivers/scsi/scsi_error.c 2006-02-24 14:50:34.000000000 -0600
@@ -1308,7 +1308,7 @@ int scsi_decide_disposition(struct scsi_
* the request was not marked fast fail. Note that above,
* even if the request is marked fast fail, we still requeue
* for queue congestion conditions (QUEUE_FULL or BUSY) */
- if ((++scmd->retries) < scmd->allowed
+ if ((++scmd->retries) <= scmd->allowed
&& !blk_noretry_request(scmd->request)) {
return NEEDS_RETRY;
} else {
@@ -1433,7 +1433,7 @@ static void scsi_eh_flush_done_q(struct
list_del_init(&scmd->eh_entry);
if (scsi_device_online(scmd->device) &&
!blk_noretry_request(scmd->request) &&
- (++scmd->retries < scmd->allowed)) {
+ (++scmd->retries <= scmd->allowed)) {
SCSI_LOG_ERROR_RECOVERY(3, printk("%s: flush"
" retry cmd: %p\n",
current->comm,
_
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
