All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: SCSI EH tidbit
Date: Tue, 18 Oct 2005 23:56:23 -0400	[thread overview]
Message-ID: <4355C3E7.6090507@pobox.com> (raw)
In-Reply-To: <434DCBBC.70106@gmail.com>

Tejun Heo wrote:
> Jeff Garzik wrote:
>> scsi_finish_command unconditionally completes the command, rather than 
>> running it through scsi_decide_disposition() decision tree again.  
>> That prevents us from using the standard command-retry path, for 
>> PCI/ATA bus errors where we want to resubmit the command.
> 
> 
>  That can be done by finishing with scsi_queue_insert as done by the 
> current SCSI EH implementation.  And, yes, that also can be done by 
> generating appropriate sense data and run it through __scsi_done again.

good point.


>  The thing is that I don't really see much difference between finishing 
> with scsi_queue_insert/scsi_queue_insert and using __scsi_done.  I'm 
> opting for not using __scsi_done mainly because that's how the current 
> SCSI EH implementation is implemented and I don't really think it would 
> be a good idea to do things differently from SCSI EH without clear reason.

I like transport separation, since libata needs to be a bit closer to 
its "pure" form:  an ATA API, which is used by libata-scsi client.


>  The situation is similar when generating sense data.  We can always 
> generate sense data for which scsi_decide_disposition() would never 
> return FAILED.  But IMHO it doesn't look like a very good idea.

SCSI keeps an internal counter to make sure that commands are not 
retried forever.

	Jeff




      reply	other threads:[~2005-10-19  3:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-12 15:05 SCSI EH tidbit Jeff Garzik
2005-10-12 15:27 ` Tejun Heo
2005-10-12 20:00   ` Jeff Garzik
2005-10-13  2:51     ` Tejun Heo
2005-10-19  3:56       ` Jeff Garzik [this message]

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=4355C3E7.6090507@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    /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.