On Mon, Jan 31, 2005 at 11:56:02AM -0500, [EMAIL PROTECTED] wrote: > > On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
> > > > > > Why not just set scmd->retries to zero in scsi_requeue_command()? > > > > > > > This is exactly what I was thinking would be a fairly straight-forward > > approach at solving the problem... > > This is ultimately a hack, and raises the potential for the retries value > to perpetually be rezero'd. The better solution is the use the block > primitives available to avoid the i/o being issued at all if the transport > can't handle it. No, it does not change the potential to retry forever, someone still has to requeue the IO again outside of the NEEDS_RETRY/scsi_retry_command case for that to happen. We only check retries in scsi_decide_disposition (well not counting error handling), and if we hit the limit, return SUCCESS. The change is that we reset retries to zero if the command is *not* retried via NEEDS_RETRY/scsi_retry_command. It would be even clearer to zero retries in scsi_decide_disposition. For NOT_READY, we would be better off always using the scsi_requeue_command path ever: get rid of the check in scsi_check_sense, as it will be requeued via scsi_io_completion code. This would have to happen even if delaying retries to NOT_READY devices. But yes, it is better to stop IO if the transport can't handle it, and would likely avoid the problem (if we only got NOT_READY's and never returned DID_BUS_BUSY). But it is still a bug to not reset retries. Maybe I need to hack scsi_debug to demonstrate the problem ... -- Patrick Mansfield - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
