Re: [PATCH]: Flexible timeout infrastructure

[James Bottomley <James.Bottomley@steeleye.com>]

On Wed, 2004-06-16 at 13:58, Luben Tuikov wrote:
> EH_RESET_TIMER means "This command had nothing to do with why
> its timer timed out and is expected to complete shortly."
> 
> Do we want to increment its retry counter for this,
> as it isn't really a retry.

It's a simple way to ensure the interface doesn't get abused.  As long
as the command is truly completed, there won't be a problem.

> > handling into the behaviour the user has requested.  The only wrinkle
> > was the no retry streaming commands.  The assumption is that a retry
> 
> They also fall in the same category -- the application client cannot
> retry them, but the LLDD knows best and it may perform some magic
> for which SCSI Core shouldn't account for.

Yes, that's why the proposal permits a single retry of an ostensibly
non-retryable command.

> > doesn't actually happen under eh_timed_out, but only an attempt to
> > collect an existing command which may be delayed because of transport or
> > other problems the host knows about.
> 
> Can we get a finalised patch so we can test it?
> James, is the one you posted what you'll have in?

I need to add comments and things, it can probably be in scsi-misc-2.6
in a day or so.

James