On Sun, 2008-01-06 at 18:19 +0200, Boaz Harrosh wrote: > On Sun, Jan 06 2008 at 5:43 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > > > > This all still leaves the question unanswered why that commit > > 6f5391c283d7fdcf24bf40786ea79061919d1e1d changed any behaviour at all. > > Because the thing that Peter is describing has nothing to do with any > > low-level drivers what-so-ever. > > > > Linus > > > > James Matthew. > I have a (very) wild guess at what maybe have changed with the cmnd->done > patch: > > Do you remember the effective loop in scsi_lib:scsi_end_request() where > if bufflen was smaller then original request size, do to truncation > of bufflen by ULD, then the remaining of the request is re-queued again > as a new scsi-command. Well I think that the old system would call > cmnd->done for every iteration, and the new system, since the done is > called by the block-Q, does not see the resubmit of the new command.
Actually, this is cmnd->done, not req->done we're removing. cmnd->done() isn't seen by the block layer; all its uses are in the SCSI mid-layer. > I have not followed all code path of the matter, but I know that sr does > alters bufflen in some cases. > All this is not a bug in itself, but it is a change in behavior that might > cause the current sr hack to fail. It's a good thought. You're right, the old code calls done for every iteration. However, it calls it in scsi_finish_completion. The new code will actually call drv->done() in that same spot for every iteration as well. The requeue is done via scsi_requeue_request which calls blk_requeue_request, which resets the START flag and sends the command right back through the system (including the prep function because scsi_requeue_request unpreps the command), so even with the new code we'll go back through all the same done paths. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
