Mike Christie wrote:
On Sun, 2005-09-18 at 20:40 +0300, Kai Makisara wrote:
The command triggering these problems is a 6-byte read of 10240 bytes. It
should not a this point return anything but finish with some sense data.
I am debugging the problem but it is going slowly because the system disk
is a SCSI disk. I have to be careful with the debugging output and changes
outside st.c require a reboot ;-) So far I have found out that
scsi_check_sense() is called correctly and returns SUCCESS as it should.
What happens after that is a mystery.
I think something like this would give us something like the old
behavior back. This way we do not let scsi_io_completion further process
the error.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1126,7 +1126,7 @@ static int scsi_issue_flush_fn(request_q
static void scsi_generic_done(struct scsi_cmnd *cmd)
{
BUG_ON(!blk_pc_request(cmd->request));
- scsi_io_completion(cmd, cmd->result == 0 ? cmd->bufflen : 0, 0);
+ scsi_io_completion(cmd, cmd->bufflen, 0);
}
static int scsi_prep_fn(struct request_queue *q, struct request *req)
this is over 1-6 of my other patches.
-
: 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
