LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Luben Tuikov <ltuikov@yahoo.com>
To: James Bottomley <James.Bottomley@SteelEye.com>,
	Andrew Morton <akpm@osdl.org>
Cc: ltuikov@yahoo.com, mdr@sgi.com, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Infinite retries reading the partition table
Date: Wed, 6 Dec 2006 12:24:59 -0800 (PST)	[thread overview]
Message-ID: <265807.57572.qm@web31813.mail.mud.yahoo.com> (raw)
In-Reply-To: <1165420788.2810.13.camel@mulgrave.il.steeleye.com>

--- James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Tue, 2006-12-05 at 21:08 -0800, Andrew Morton wrote:
> >  	case MEDIUM_ERROR:
> > +		if (sshdr.asc == 0x11 || /* UNRECOVERED READ ERR */
> > +		    sshdr.asc == 0x13 || /* AMNF DATA FIELD */
> > +		    sshdr.asc == 0x14) { /* RECORD NOT FOUND */
> > +			return SUCCESS;
> > +		}
> >  		return NEEDS_RETRY;
> 
> If the complaint is true; i.e. infinite retries, this is just a bandaid
> not a fix.  What it's doing is marking the unrecoverable medium errors
> for no retry.  However, what we really need to know is why NEEDS_RETRY
> isn't terminating after its allotted number of retries.  Can we please
> have a trace of this?

NEEDS_RETRY _does_ terminate, after it exhausts the retries.  But since
by the ASC value we know that no amount of retries is going to work,
this chunk of the patch resolves it quicker, i.e. eliminates the
"NEEDS_RETRY" pointless retries (given the SK/ASC combination).

> > -	if (scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> > +	if (good_bytes &&
> > +	    scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
> >  		return;
> 
> What exactly is this supposed to be doing?  its result is identical to
> the code it's replacing (because of the way scsi_end_request() processes
> its second argument), so it can't have any effect on the stated problem.

I suppose this is true, but I'd rather it not even go in
scsi_end_request as (cmd, uptodate=1, good_bytes=0, retry=0) and complete
at the bottom as (cmd, uptodate=0, total_xfer, retry=0).

    Luben


  reply	other threads:[~2006-12-06 20:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30  1:22 Luben Tuikov
2006-12-01  5:47 ` Andrew Morton
2006-12-01  6:34   ` Luben Tuikov
2006-12-01  7:29     ` Andrew Morton
2006-12-01  8:32       ` Luben Tuikov
2006-12-05 20:40         ` Michael Reed
2006-12-06  5:00           ` Luben Tuikov
2006-12-06  5:08             ` Andrew Morton
2006-12-06  6:10               ` Luben Tuikov
2006-12-06 15:59               ` James Bottomley
2006-12-06 20:24                 ` Luben Tuikov [this message]
2006-12-07 18:16                   ` James Bottomley
2006-12-07 19:14                     ` Luben Tuikov
2006-12-07 21:15                       ` James Bottomley
2006-12-06 10:48       ` Etienne.Vogt
2006-11-30  1:53 Luben Tuikov

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=265807.57572.qm@web31813.mail.mud.yahoo.com \
    --to=ltuikov@yahoo.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdr@sgi.com \
    --subject='Re: Infinite retries reading the partition table' \
    /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

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