From: Brian King <brking@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [RFC] IBM Power RAID driver (ipr)
Date: Tue, 20 Jan 2004 14:13:29 -0600 [thread overview]
Message-ID: <400D8BE9.2070108@us.ibm.com> (raw)
In-Reply-To: 20040120192822.A19908@infradead.org
Christoph Hellwig wrote:
>>The reason I have a pending_q is so that when I reset the adapter
>>without the mid-layer knowing about it, I need to fail back any
>>outstanding ops so they get retried as appropriate. I suppose a way
>>around this would be a mid-layer interface that an LLD could call which
>>would cause a host reset. Then the midlayer could drive the reset and
>>take care of doing the right thing with any outstanding ops.
>
>
> Does scsi_reset_provider fit your needs?
scsi_reset_provider needs to be called at task level, I often need to
initiate a reset from interrupt level. Also, it doesn't seem to touch
outstanding ops. The interface would really need to walk all the device
queues, failing all the outstanding ops, putting them on the eh queue,
then wake the eh thread to do the reset.
Also, regarding the pending_q discussion, one issue with not having a
pending_q would be additional complexity in my eh_host_reset_handler. I
would need to be able to find all the ops that timed out so I could free
up my command block, unmap the data buffer, etc. Currently I can just
walk my pending_q. Without it, I would need to walk all the device
queues, which seems like it might be a bad thing for a LLD to do.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
next prev parent reply other threads:[~2004-01-20 20:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-16 21:59 [RFC] IBM Power RAID driver (ipr) Brian King
2004-01-16 23:01 ` Muli Ben-Yehuda
2004-01-16 23:46 ` Brian King
2004-01-18 14:10 ` Anton Blanchard
2004-01-19 16:16 ` Brian King
2004-01-19 18:34 ` Christoph Hellwig
2004-01-19 19:33 ` Mike Anderson
2004-01-19 19:35 ` Christoph Hellwig
2004-01-20 5:57 ` Douglas Gilbert
2004-01-20 13:21 ` Christoph Hellwig
2004-01-19 20:30 ` Brian King
2004-01-20 13:38 ` Christoph Hellwig
2004-01-20 16:41 ` Brian King
2004-01-20 17:18 ` Mike Anderson
2004-01-20 18:01 ` Christoph Hellwig
2004-01-20 19:13 ` Brian King
2004-01-20 19:28 ` Christoph Hellwig
2004-01-20 20:13 ` Brian King [this message]
2004-01-21 20:49 ` Brian King
2004-01-22 14:02 ` Christoph Hellwig
2004-01-22 16:39 ` Patrick Mansfield
2004-01-22 16:56 ` Patrick Mansfield
2004-01-22 17:09 ` Brian King
2004-01-22 17:27 ` Patrick Mansfield
2004-01-22 17:33 ` Brian King
2004-01-20 20:35 ` Patrick Mansfield
2004-01-20 22:37 ` Brian King
2004-01-20 22:39 ` 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=400D8BE9.2070108@us.ibm.com \
--to=brking@us.ibm.com \
--cc=hch@infradead.org \
--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 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.