linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
 	}
 }

  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).