All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 1/2] SCSI: simplify scsi_io_completion()
Date: Wed, 26 Nov 2008 16:29:49 -0600	[thread overview]
Message-ID: <1227738589.3387.57.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0811261447100.29893-100000@netrider.rowland.org>

On Wed, 2008-11-26 at 15:03 -0500, Alan Stern wrote:
> On Wed, 26 Nov 2008, James Bottomley wrote:
> 
> > On Mon, 2008-11-03 at 15:56 -0500, Alan Stern wrote:
> > > This patch (as1142b) consolidates a lot of repetitious code in
> > > scsi_io_completion().  It also fixes a few comments.  Most
> > > importantly, however, it clearly distinguishes among the three sorts
> > > of retries that can be done when a command fails to complete:
> 
> > OK, how about this as an update to the patch.  It corrects several
> > things:
> > 
> >      1. For several error conditions, we would now print the sense twice
> >         in slightly different ways, so unify the location of sense
> >         printing.
> >      2. I added more descriptions to actual failure conditions for
> >         better debugging
> >      3. according to spec, ABORTED_COMMAND is supposed to be retried
> >         (except on DIF failure).  Our old behaviour of erroring it looks
> >         to be a bug.
> >      4. I'd prefer not to default initialise the action variable because
> >         that ensures that every leg of the error handler has an
> >         associated action and the compiler will warn if someone later
> >         accidentally misses one or removes one.
> 
> This looks very good.  I'm pleased you didn't find anything actually 
> wrong with the original patch aside from the ABORTED COMMAND handling. 
> 
> I was going to suggest adding a description to the ILLEGAL REQUEST
> case.  But that case arises normally under various circumstances, so
> perhaps it wouldn't be appropriate.  In fact, do you really want to
> print out the result and sense data every time that case occurs?

I think it's OK.  I thought some of the CD probing routines triggered
illegal requests, but I can't seem to see it on my test machines (it
could be I have the wrong type of CD, though).

> > It also looks like 
> 
> ... ?

it also looks like I didn't finish my sentence.

James



  reply	other threads:[~2008-11-26 22:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-03 20:56 [PATCH 1/2] SCSI: simplify scsi_io_completion() Alan Stern
2008-11-26 19:02 ` James Bottomley
2008-11-26 20:03   ` Alan Stern
2008-11-26 22:29     ` James Bottomley [this message]
2008-11-26 23:31       ` Alan Stern
2008-11-27  4:13         ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2008-11-17 19:10 Alan Stern

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=1227738589.3387.57.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=bharrosh@panasas.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.