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 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.