public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian King <brking@us.ibm.com>
To: linux-scsi@vger.kernel.org
Subject: Re: host_self_blocked question/bug?
Date: Tue, 25 Nov 2003 16:31:09 -0600	[thread overview]
Message-ID: <3FC3D82D.2030604@us.ibm.com> (raw)
In-Reply-To: 1069797320.1787.220.camel@mulgrave

James Bottomley wrote:
> The original design was to allow short hiatuses when the HBA couldn't
> accept I/O.  It doesn't work if there's I/O pending (unless the stop is
> very short), because the SCSI timers are still ticking and error
> recovery doesn't see this flag.
> 
> There has been talk of making this interface robust to pending commands
> (halt the timers and freeze the error handler) for FC HBA's that take
> ages to process loop events, but no work has been done on this---it's
> quite a bit more work than simply not allowing the eh to emit TURs.

I'd like a way to be able to stop the mid-layer from sending me any 
commands. The scenarios I have today are:

1. Fatal error on the adapter.
2. microcode download to the adapter.
3. Adapter cache recovery commands.

All of these cases require me to run BIST on the adapter and bring it 
back up. To do this may take 20-30 seconds. I call scsi_block_requests, 
fail all pending ops back with DID_ERROR, reset the adapter, then call 
scsi_unblock_requests. My usage of it gets around the ticking timer 
problem. I agree that the error recovery thread doesn't see this either 
and that this is a potential problem. I had planned to work around that 
by failing abort and device reset, forcing the host_reset to be called, 
which would wait on the completion of the adapter reset, but it would be 
nice if I didn't have to do that.



-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center


  reply	other threads:[~2003-11-25 22:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-25 21:46 host_self_blocked question/bug? Brian King
2003-11-25 21:55 ` James Bottomley
2003-11-25 22:31   ` Brian King [this message]
2003-11-26  0:32     ` Patrick Mansfield
2003-11-26 13:44       ` Christoph Hellwig

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=3FC3D82D.2030604@us.ibm.com \
    --to=brking@us.ibm.com \
    --cc=linux-scsi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox