On Fri, 2006-07-07 at 21:09 -0700, Luben Tuikov wrote:
> - if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> + if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
Um, why?
I merely reverted this hunk back to the original code to fix the SATA
flushing problem. The requeue code in scsi_end_request() is
if (end_that_request_chunk(req, uptodate, bytes)) {
[...]
/* kill remainder if no retrys */
if (!uptodate && blk_noretry_request(req))
end_that_request_chunk(req, 0, leftover);
else {
if (requeue) {
/*
* Bleah. Leftovers again. Stick the
* leftovers in the front of the
* queue, and goose the queue again.
*/
scsi_requeue_command(q, cmd);
cmd = NULL;
}
return cmd;
}
however, since we go into scsi_end_request() with uptodate == 1, we
always hit the else code if good_bytes is less than the actual request
size. Now, if we have an actual error, i.e. result != 0 it looks to me
like we want to continue on in scsi_io_completion and process it (i.e.
return and don't requeue). I think if good_bytes is less than the
request size and result == 0 we want to requeue (this is for the case
where we had to process the request with a SCSI command that couldn't
contain the entire request length, so we have to keep going around until
we complete it---realistically only READ/WRITE(6), I think).
James
-
: 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
