Messages in this thread | | | Date | Tue, 26 Feb 2008 19:46:12 -0500 | From | Jeff Garzik <> | Subject | Re: regression: CD burning (k3b) went broke |
| |
Andrew Morton wrote: > On Tue, 26 Feb 2008 14:36:43 +0100 Mike Galbraith <efault@gmx.de> 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
| |