On 12/8/2010 16:14, Mike Snitzer wrote:
From: Hannes Reinecke<hare@xxxxxxx>
Properly describe a "deferred error" as such in scsi_io_completion.
The deferred error (and the associated sense) will have nothing to do
with the victim scsi command that is also printed. The victim command
shall not have been processed and shall be retried.
I'm curious if the command will ever reach this level of code
(scsi_io_completion()) unless you happened to take the deferred error
(DE) on the very last retry of the command? Not to say this patch isn't
a good one, just that we need more.
It seems like scsi_check_sense() will see the DE first, drop it on the
floor, and order a retry of the victim command. Unless there are more
DEs, won't that be the last we see of the first DE?
But, I'm pretty new to this area, so I could be wrong. Simulating it
with scsi_debug seems to show the behavior I noted above.
-BR
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index eafeeda..0aa0d68 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -889,7 +889,10 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
break;
}
} else {
- description = "Unhandled error code";
+ if (sense_deferred)
+ description = "Deferred error";
+ else
+ description = "Unhandled error code";
action = ACTION_FAIL;
}
--
To unsubscribe from this list: 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
