From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: regression: CD burning (k3b) went broke Date: Tue, 26 Feb 2008 19:46:12 -0500 Message-ID: <47C4B2D4.109@garzik.org> References: <1203583379.6244.27.camel@homer.simson.net> <20080222073228.GZ23197@kernel.dk> <1203752563.5225.4.camel@homer.simson.net> <1203839683.17463.9.camel@homer.simson.net> <1204019283.8731.11.camel@homer.simson.net> <1204033003.11828.22.camel@homer.simson.net> <20080226150845.2196bc1a.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:46756 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753860AbYB0AqU (ORCPT ); Tue, 26 Feb 2008 19:46:20 -0500 In-Reply-To: <20080226150845.2196bc1a.akpm@linux-foundation.org> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Andrew Morton Cc: Mike Galbraith , Jens Axboe , LKML , Tejun Heo , linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org Andrew Morton wrote: > On Tue, 26 Feb 2008 14:36:43 +0100 Mike Galbraith 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