During heavy I/O the scsi cmd might be stuck in the cmdqueue
and hasn't even been sent at the time the command timeout
strikes. So we should be resetting the command timer here
and not aborting the command.
Signed-off-by: Hannes Reinecke <h...@suse.de>
---
drivers/scsi/libiscsi.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 41bb177..e5b79cf 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1795,6 +1795,14 @@ static enum blk_eh_timer_return
iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
goto done;
}
+ if (!list_empty(&conn->cmdqueue)) {
+ ISCSI_DBG_EH(session, "cmdqueue busy, reset timeout. "
+ "Last data recv at %lu. Last timeout was at "
+ "%lu\n", task->last_xfer, task->last_timeout);
+ rc = BLK_EH_RESET_TIMER;
+ goto done;
+ }
+
if (!conn->recv_timeout && !conn->ping_timeout)
goto done;
/*
--
1.5.3.2
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
