All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luben Tuikov <ltuikov@yahoo.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Andrew Morton <akpm@osdl.org>,
	mdr@sgi.com, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Infinite retries reading the partition table
Date: Thu, 7 Dec 2006 11:14:22 -0800 (PST)	[thread overview]
Message-ID: <367656.23632.qm@web31810.mail.mud.yahoo.com> (raw)
In-Reply-To: <1165515378.4698.24.camel@mulgrave.il.steeleye.com>

--- James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Wed, 2006-12-06 at 12:24 -0800, Luben Tuikov wrote:
> > 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).
> 
> I agree that it's useful behaviour.  However, the change header should
> be something like "scsi_error: don't retry for unrecoverable medium
> errors" not "infinite retries .."
> 
> > > > -	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).
> 
> But, logically, this isn't part of the change set ... the behaviour
> you're altering is unrelated to the change set details, so this piece
> shouldn't be in.

It is.  If good_bytes=0 then nothing is up to date and uptodate should
be set to 0.

Look at my comment before the function call:
   /* A number of bytes were successfully read. ...

I repeat again: it doesn't make sense to call scsi_end_request
with uptodate=1 and good_bytes=0, since _no bytes are uptodate_.

  reply	other threads:[~2006-12-07 19:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30  1:22 Infinite retries reading the partition table 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
2006-12-07 18:16                   ` James Bottomley
2006-12-07 19:14                     ` Luben Tuikov [this message]
2006-12-07 21:15                       ` James Bottomley
2006-12-06 10:48       ` Etienne.Vogt
  -- strict thread matches above, loose matches on Subject: below --
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=367656.23632.qm@web31810.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 \
    /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.