From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: albertcc@tw.ibm.com, linux-ide@vger.kernel.org
Subject: Re: [RFC] libata new EH document
Date: Wed, 07 Sep 2005 04:25:08 -0400 [thread overview]
Message-ID: <431EA3E4.5060402@pobox.com> (raw)
In-Reply-To: <20050829061124.GA2725@htj.dyndns.org>
Tejun Heo wrote:
> Hello, Jeff, Albert & ATA developers.
>
> This is the final one of recent document series for libata EH - SCSI
> EH, ATA exceptions, libata EH and, this one - libata new EH.
>
> This document tries to discuss how to implement new advanced EH. It
> also describes some proposed mechanisms in detail. I'm aware that
> things are vague without actual code, but I still think this document
> alone can at least help discussion if nothing else. As long as some
> consensus is reached regarding general desing, I'll follow up with
> patches.
>
> Jeff, a lot are from my previous new EH/NCQ patchset but also quite
> a bit has changed (for better, I hope).
>
> Thanks.
>
>
> libata new EH
> ======================================
>
> As discussed in the previous libata EH doc, the current libata EH
> needs some improvements. This document discusses goals of new libata
> EH and how to reach them. Please read SCSI EH, ATA exceptions and
> libata EH documents first.
>
> TABLE OF CONTENTS
>
> [1] Goals & design choices
> [1-1] Use SCSI hostt->eh_strategy_handler()
> [1-2] Unified error path in an EH thread
> [1-3] Synchronization
> [1-4] Clean mechanism to hand off qc's to EH
> [1-5] Separate EH qc
> [1-6] SCSI/libata separation
> [2] Designs
> [2-1] Handoff of failed qc's
> [2-2] Timed out scmd's and qc's
> [2-3] Summary of [2-1] and [2-2]
> [2-4] EH processing & completion
> [3] Ideas
> [3-1] Using EH for non-error exceptions and dynamic reconfiguration
> [3-2] Using EH for host_set level exclusion
> [4] Implementation plan
>
>
> [1] Goals & design choices
>
> The final goal is implementing advanced error handling as described
> in ATA exceptions document including NCQ EH, dynamic transport
> reconfiguration and non-error exception handling for power management
> and hot plugging.
>
> The followings are sub goals and design choices to reach the final
> goal.
>
>
> [1-1] Use SCSI hostt->eh_strategy_handler()
>
> We have two other alternatives here - one is using fine-grained
> SCSI EH callbacks and the other is implementing separate EH for
> libata.
>
> Using fine-grained SCSI EH callbacks is possible, but it has too
> much SCSI/SPI assumptions in it -
Not really. When you notice an error, and inform the SCSI stack of that, it
- tries to abort the command using abort_handler
- if that failed, tries to reset the device
- if that failed, tries to reset the bus
- if that failed, tries to reset the host
Nothing SPI-specific about that.
Nothing SCSI-specific about that, either :)
That is the ordering that we would like to use, and it maps directly to
SCSI EH
> Also, as described in the
> SCSI EH doc, it issues several SCSI commands for recovery. They
> can be translated but recovery through translation is a bit
> creepy, IMHO.
Agreed RE translation
I'll reply to more of this doc when I have some sleep :)
Jeff
prev parent reply other threads:[~2005-09-07 8:25 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-29 6:11 [RFC] libata new EH document Tejun Heo
2005-08-29 6:13 ` Tejun Heo
2005-08-30 9:10 ` Albert Lee
2005-08-30 10:26 ` Tejun Heo
2005-08-30 14:32 ` Luben Tuikov
2005-09-01 1:17 ` Tejun Heo
2005-09-01 2:22 ` Jeff Garzik
2005-09-01 2:42 ` Tejun Heo
2005-09-01 3:33 ` Luben Tuikov
2005-09-01 3:30 ` Luben Tuikov
2005-09-01 3:44 ` Tejun Heo
2005-09-01 4:38 ` Luben Tuikov
2005-09-01 5:44 ` Tejun Heo
2005-09-01 5:54 ` Jeff Garzik
2005-09-01 13:24 ` James Bottomley
2005-09-01 21:40 ` Luben Tuikov
2005-09-01 21:46 ` Jeff Garzik
2005-09-01 22:09 ` Luben Tuikov
2005-09-01 22:27 ` Jeff Garzik
2005-09-01 23:17 ` Luben Tuikov
2005-09-02 7:09 ` Stefan Richter
2005-09-01 22:22 ` Luben Tuikov
2005-09-01 22:31 ` Jeff Garzik
2005-09-01 21:55 ` James Bottomley
2005-09-01 22:07 ` Luben Tuikov
2005-09-01 22:23 ` James Bottomley
2005-09-01 22:36 ` Luben Tuikov
2005-09-01 23:01 ` James Bottomley
2005-09-01 23:03 ` Luben Tuikov
2005-09-01 23:27 ` Luben Tuikov
2005-09-01 2:22 ` Jeff Garzik
2005-08-30 14:27 ` James Bottomley
2005-09-07 8:25 ` 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=431EA3E4.5060402@pobox.com \
--to=jgarzik@pobox.com \
--cc=albertcc@tw.ibm.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 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).