From a9bddd74630b2a1f2dedc537417c372b2d9edc76 Mon Sep 17 00:00:00 2001 From: James Bottomley Date: Mon, 30 Mar 2009 16:55:51 +0000 Subject: [SCSI] fix recovered error handling We have a problem with recovered error handling in that any command which goes down as BLOCK_PC but which returns a sense code of RECOVERED ERROR gets completed with -EIO. For actual SG_IO commands, this doesn't matter at all, since the error return code gets dropped in favour of req->errors which contain the SCSI completion code. However, if this command is part of the block system, then it will pay attention to the returned error code. In particularly if a SYNCHRONIZE CACHE from a barrier command completes with RECOVERED ERROR, the resulting -EIO on the barrier causes block to error the request and return it to the filesystem. Fix this by converting the -EIO for recovered error to zero, plus remove the printing of this from sd and sr so the message isn't double printed. Signed-off-by: James Bottomley --- drivers/scsi/scsi_lib.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'drivers/scsi/scsi_lib.c') diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 4b13e36d3aa..d1cb64ad1a3 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -791,7 +791,22 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes) "%d bytes done.\n", req->nr_sectors, good_bytes)); - /* A number of bytes were successfully read. If there + /* + * Recovered errors need reporting, but they're always treated + * as success, so fiddle the result code here. For BLOCK_PC + * we already took a copy of the original into rq->errors which + * is what gets returned to the user + */ + if (sense_valid && sshdr.sense_key == RECOVERED_ERROR) { + if (!(req->cmd_flags & REQ_QUIET)) + scsi_print_sense("", cmd); + result = 0; + /* BLOCK_PC may have set error */ + error = 0; + } + + /* + * A number of bytes were successfully read. If there * are leftovers and there is some kind of error * (result != 0), retry the rest. */ -- cgit v1.2.3-70-g09d2 From b4efdd586bc08cdf5977cad0a90091f44546a930 Mon Sep 17 00:00:00 2001 From: Mike Christie Date: Thu, 9 Apr 2009 15:57:10 -0500 Subject: [SCSI] fix q->lock not held warning when target is busy We cannot call blk_plug_device from scsi_target_queue_ready because the q lock is not held. And we do not need to call it from there because when we return 0, the scsi_request_fn not_ready handling will plug the queue for us if needed. Signed-off-by: Mike Christie Signed-off-by: James Bottomley --- drivers/scsi/scsi_lib.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) (limited to 'drivers/scsi/scsi_lib.c') diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index d1cb64ad1a3..bb218c8b6e9 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1291,10 +1291,8 @@ static inline int scsi_target_queue_ready(struct Scsi_Host *shost, if (--starget->target_blocked == 0) { SCSI_LOG_MLQUEUE(3, starget_printk(KERN_INFO, starget, "unblocking target at zero depth\n")); - } else { - blk_plug_device(sdev->request_queue); + } else return 0; - } } if (scsi_target_is_busy(starget)) { -- cgit v1.2.3-70-g09d2