Re: [PATCH] allow drivers to hook into watchdog timeout

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

On Tue, 2004-02-10 at 15:26, Justin T. Gibbs wrote:
> > So if I give you an error code for this, like DID_REQEUEUE, you'll
> > eliminate the driver queueing from your queucommand and from your done
> > processing?
> 
> If I can freeze at per-device granularity and testing of the BUSY and
> QUEUE_FULL paths in the mid-layer pan out, I believe the answer is yes.

I believe we have everything that you need with regard to BUSY and
QUEUE_FULL.

It looks like a device_blocked interface won't be too much work, I'll
look at coding one up.

> > No, they won't.  DID_RESET doesn't count against the retry count (the
> > only things that affect the retry count are conditions that go through
> > the maybe_retry label in scsi_device_disposition()).
> 
> This is only true if the peripheral driver calls scsi_io_completion().
> The SG driver, for instance, does not.

But that's by design.  The application using SG_IO receives the error
code directly and is in control of deciding to retry.

> That reminds me.  Reported bus/target resets do not cause a
> bus/device-settle delay.  This is another one of the workarounds
> in my driver.

That's correct.  The interface is really designed to report that
something happened.  Since we may not know the actual timing of the
reported event, the philosophy is that is't better queue and retry
(while correctly processing the NOT_READY) than to impose an arbitrary
delay.

The rule is that the mid-layer only delays for events it initiated.

James