Re: [PATCH]: Flexible timeout infrastructure

[Luben Tuikov <luben_tuikov@adaptec.com>]

James Bottomley wrote:
> On Wed, 2004-06-16 at 10:27, Mike Anderson wrote:
>  > Does this mean scsi_times_out will complete the command by calling a
>  > SCSI mid layer internal form of the scsi_done function (less the
>  > scsi_delete_timer call) or that the LLDD will call scsi_done and we will
>  > need to modify scsi_done to accept these no timer running cases.
> 
> Yes.  We'll just abstract all of scsi_done() bar the timer check into
> __scsi_done, which will be private, and called in this instance.

So, now, there will be a 2nd, "fuzzy" way of returning a command
back to SCSI Core:

a) LLDD calls scsi_done() when all went well, an antagonist to the 
   one and only queuecommand(),
XOR
b) command timed out, LLDD's eh_cmd_timed_out() was called and returned
   EH_HANDLED, and then _SCSI_Core_ calls __scsi_done().

I.e. in b) the LLDD _never_ gets to call scsi_done() (or a completion method)
on that command.

Anyway, do we have a patch for *this* solution?

>  > >
>  > > c. I need more time, reset the timer and notify me again when it 
> fails.
>  > >
>  > > For (c), I propose that we use the same timeout period, but increment
>  > > the retry count (and do this up to allowed retries plus one [so that
>  > > no-retry commands have one crack at being recovered by the LLD]) when
>  > > retries are exhausted, normal error handling would proceed on timer
>  > > expiry leading to certain failure of the command since it would be
>  > > ineligible to be retried.
>  >
>  > The comment on the no-retry commands appears counter to the intent of
>  > FASTFAIL. On a multi-ported device if there really is a port / 
> controller
>  > issue we have increased the failover time 2x the timeout value which
>  > IIRC was one case that FASTFAIL wished to address.
> 
> Well ... perhaps the solution's to shorten the timers then for this
> case?

-- 
Luben