From: "Justin T. Gibbs" <gibbs@scsiguy.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Christoph Hellwig <hch@lst.de>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] allow drivers to hook into watchdog timeout
Date: Tue, 10 Feb 2004 13:26:57 -0700 [thread overview]
Message-ID: <2549730000.1076444817@aslan.btc.adaptec.com> (raw)
In-Reply-To: <1076443541.2080.56.camel@mulgrave>
> On Tue, 2004-02-10 at 14:44, Justin T. Gibbs wrote:
>> > If you need to stall a command after you've accepted it by returning
>> > zero from queuecommand, you return it to the mid-layer with status
>> > either BUSY or QUEUE_FULL.
>>
>> BUSY and QUEUE_FULL status have particular meanings when associated
>> with an SCSI peripheral. Using them for this purpose will only confuse
>> the mid-layer into taking unwarranted action, like trying to throttle
>> the queue depth. The times that I want to use this have nothing to
>> do with BUSY or QUEUE_FULL in their SCSI sense.
>
> 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.
>> They will only be issued up to their command retry count which may be zero
>> for certain commands. This may also confuse the peripheral or mid-layer
>> drivers into believing that a unit attention condition is expected and
>> should be ignored. The commands that were affected by the recovery action
>> should be marked accordingly, but marking the commands that are still waiting
>> on the sidelines is the equivalent of a drive-by-shooting.
>
> 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.
> It will not cause any unit attention exception processing. That only
> happens if the error handler knows it reset something, or the driver
> reports that it is resetting something.
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.
--
Justin
next prev parent reply other threads:[~2004-02-10 20:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-20 13:20 [PATCH] allow drivers to hook into watchdog timeout Christoph Hellwig
2004-01-20 15:53 ` Mike Anderson
2004-01-20 16:00 ` Christoph Hellwig
2004-01-20 16:47 ` Mike Anderson
2004-01-22 13:59 ` Christoph Hellwig
2004-01-22 14:27 ` Justin T. Gibbs
2004-01-20 17:00 ` Brian King
2004-01-20 18:06 ` Christoph Hellwig
2004-02-10 16:34 ` Justin T. Gibbs
2004-02-10 16:42 ` James Bottomley
2004-02-10 17:47 ` Justin T. Gibbs
2004-02-10 18:41 ` James Bottomley
2004-02-10 19:44 ` Justin T. Gibbs
2004-02-10 20:05 ` James Bottomley
2004-02-10 20:26 ` Justin T. Gibbs [this message]
2004-02-10 22:47 ` Clay Haapala
2004-02-11 20:05 ` James Bottomley
2004-02-12 0:15 ` Justin T. Gibbs
2004-02-12 14:42 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2549730000.1076444817@aslan.btc.adaptec.com \
--to=gibbs@scsiguy.com \
--cc=James.Bottomley@SteelEye.com \
--cc=hch@lst.de \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.