From: Andrew Vasquez <andrew.vasquez@qlogic.com>
To: Patrick Mansfield <patmans@us.ibm.com>
Cc: James.Smart@Emulex.Com, James.Bottomley@SteelEye.com,
linux-scsi@vger.kernel.org
Subject: Re: Mid-layer handling of NOT_READY conditions...
Date: Mon, 31 Jan 2005 23:21:45 -0800 [thread overview]
Message-ID: <1107242505.6305.15.camel@plap> (raw)
In-Reply-To: <20050131173629.GA29928@us.ibm.com>
On Mon, 2005-01-31 at 09:36 -0800, Patrick Mansfield wrote:
> On Mon, Jan 31, 2005 at 11:56:02AM -0500, James.Smart@Emulex.Com 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.
>
Here's a small patch against the latest scsi-rc-fixes tree I've been
running with which allows my basic cable-pull test to complete without
incident.
Please consider for inclusion.
As per Patrick M's suggestions:
* reset a command's retries count in scsi_decide_disposition() in
case of additional requiring by upper layer.
* remove redundant check for NOT_READY (ASC: 0x04 ASCQ: 0x01) in
scsi_check_sense().
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
scsi_error.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
===== drivers/scsi/scsi_error.c 1.86 vs edited =====
--- 1.86/drivers/scsi/scsi_error.c 2005-01-17 22:54:45 -08:00
+++ edited/drivers/scsi/scsi_error.c 2005-01-31 23:01:54 -08:00
@@ -327,12 +327,6 @@ static int scsi_check_sense(struct scsi_
return NEEDS_RETRY;
}
/*
- * if the device is in the process of becoming ready, we
- * should retry.
- */
- if ((sshdr.asc == 0x04) && (sshdr.ascq == 0x01))
- return NEEDS_RETRY;
- /*
* if the device is not started, we need to wake
* the error handler to start the motor
*/
@@ -1405,7 +1399,10 @@ int scsi_decide_disposition(struct scsi_
} else {
/*
* no more retries - report this one back to upper level.
+ * clear retries in case the command is requeued by
+ * upper level.
*/
+ scmd->retries = 0;
return SUCCESS;
}
}
next prev parent reply other threads:[~2005-02-01 7:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-31 16:56 Mid-layer handling of NOT_READY conditions James.Smart
2005-01-31 17:36 ` Patrick Mansfield
2005-02-01 7:21 ` Andrew Vasquez [this message]
2005-01-31 18:22 ` Andrew Vasquez
-- strict thread matches above, loose matches on Subject: below --
2005-01-31 19:07 James.Smart
2005-01-31 14:07 Mid-Layer handling of NOT READY conditions goggin, edward
2005-01-31 9:46 EXT / DEVOTEAM VAROQUI Christophe
2005-01-28 23:24 Mid-layer handling of NOT_READY conditions Andrew Vasquez
2005-01-29 5:46 ` Andrew Vasquez
2005-01-29 16:16 ` Matthew Wilcox
2005-01-29 16:44 ` James Bottomley
2005-01-29 19:34 ` Patrick Mansfield
2005-01-30 1:40 ` James Bottomley
2005-01-30 2:33 ` Douglas Gilbert
2005-01-31 7:47 ` Andrew Vasquez
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=1107242505.6305.15.camel@plap \
--to=andrew.vasquez@qlogic.com \
--cc=James.Bottomley@SteelEye.com \
--cc=James.Smart@Emulex.Com \
--cc=linux-scsi@vger.kernel.org \
--cc=patmans@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).