linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
	"James Bottomley (jbottomley@parallels.com)"
	<jbottomley@parallels.com>, Hannes Reinecke <hare@suse.de>,
	Christoph Hellwig <hch@infradead.org>,
	"scameron@beardog.cce.hp.com" <scameron@beardog.cce.hp.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: scsi error handling thread and REQUEST SENSE
Date: Mon, 19 May 2014 13:40:39 +0200	[thread overview]
Message-ID: <5379EDB7.3030803@acm.org> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B402956F17E1F@G4W3202.americas.hpqcorp.net>

On 05/16/14 21:02, Elliott, Robert (Server Storage) wrote:
> The command is still outstanding; data transfers might still occur, 
> and a completion using its tag could still appear at any time. 
> However, the error handler declares that the command is done, 
> so all the buffers are freed and the tag is reused.
> 
> The SCSI error handler needs to escalate this to a reset that 
> ensures that the command is no longer outstanding: ABORT
> TASK (which already didn't work), ABORT TASK SET, LOGICAL 
> UNIT RESET, I_T NEXUS RESET, or hard reset.

If my interpretation of the SCSI mid-layer source code is correct then
even with the patch "improved eh timeout handler" applied the SCSI
mid-layer still guarantees for each SCSI host that at most one
eh_abort_handler() call is active at any given time (since tmf_work_q is
created with max_active = 1) and also that at least one of the eh_*
functions is invoked before the SCSI mid-layer finishes a command. Does
your comment mean that you have found a scenario in which none of the
LLD eh_* callback functions was invoked before the SCSI mid-layer
finished a SCSI command ?

Thanks,

Bart.

      parent reply	other threads:[~2014-05-19 11:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-16 19:02 scsi error handling thread and REQUEST SENSE Elliott, Robert (Server Storage)
2014-05-16 20:05 ` Ewan Milne
2014-05-19  8:32   ` Hannes Reinecke
2014-05-19 10:29     ` Bart Van Assche
2014-05-19 10:37       ` Hannes Reinecke
2014-05-19 11:26         ` Bart Van Assche
2014-05-19 13:41     ` James Bottomley
2014-05-19 15:15       ` Elliott, Robert (Server Storage)
2014-05-19 11:40 ` Bart Van Assche [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=5379EDB7.3030803@acm.org \
    --to=bvanassche@acm.org \
    --cc=Elliott@hp.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=jbottomley@parallels.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=scameron@beardog.cce.hp.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).