Andrew Morton wrote:
On Tue, 26 Feb 2008 14:36:43 +0100 Mike Galbraith <efault@xxxxxx> wrote:
On Tue, 2008-02-26 at 10:48 +0100, Mike Galbraith wrote:
Greetings,
I straced both a good and a bad kernel (good being .git with attached
revert patch applied) and filtered/diffed/merged the output. Scroll
down to "HERE" to see the problem (resid).
I'm poking around, but not having much luck.
cc's added.
I'm told this is part of "Tejun's DMA drain handling".
Correct.
Seems the problem is data_len changes, but raw_data_len doesn't. I've
not the foggiest IO-land clue, but k3b works again, so the below may
have some diagnostic value.
So this change fixes a bug? Can we have a recap of how it does this?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index ba21d97..7a6f784 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -871,7 +871,7 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
scsi_end_bidi_request(cmd);
return;
}
- req->data_len = scsi_get_resid(cmd);
+ req->data_len = req->raw_data_len = scsi_get_resid(cmd);
}
I would love to get an answer as to what data_len (and of course
raw_data_len) should be set to AFTER the command completes, which is
what is going on here.
I can see the above being correct -- scsi_get_resid() returns the length
of the left-over data after the command is processed -- but I am mainly
curious why setting [raw_]data_len matters after I/O completion.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
