From: Tejun Heo <htejun@gmail.com>
To: linux-ide@vger.kernel.org
Cc: Jeff Garzik <jgarzik@pobox.com>,
albertcc@tw.ibm.com, mlord@pobox.com, lkosewsk@gmail.com,
luben_tuikov@adaptec.com
Subject: [SUMMARY] libata EH
Date: Sat, 20 Aug 2005 11:33:51 +0900 [thread overview]
Message-ID: <20050820023351.GA690@htj.dyndns.org> (raw)
Hello, Jeff & libata developers.
I've been spending some time on libata EH and am trying to make a
list of things which can be improved. If you have something, please
add to the list.
1. Errors are handled in multiple paths.
* ATA errors are handled directly in intr context
* timeouts are handled by ->eng_timeout via SCSI EH
* ATAPI errors are forwarded to ->eng_timeout in somewhat hackish way
2. Synchronization
* SCSI EH entrance is not synchronized with normal processing.
ATAPI error handling/timeout handling can run concurrently
with normal command processing. Albert, I think it's the
same problem you're trying to solve by moving ATA_QCFLAG_ACTIVE
clearing.
http://marc.theaimsgroup.com/?l=linux-ide&m=112417360223374&w=2
* SCSI EH entrance is not synchronized with polling tasks.
We should cancel & wait for polling tasks on entry to EH, but
we don't.
3. Error handling too weak
* We need to check the device responds to commands (say, w/
IDENTIFY or CHK_POWER) after an error, and then reset if it
doens't. To do this, we need to handle all errors in EH.
4. Better error reporting
* We currently depend on ATA_STAT and ATA_ERR register values
to check for and report errors. As Jeff said, this is way
too crude. We need better error reporting. I think having
unified code path for error handling will help implementing
this.
5. EH is currently holding off other improvements
* NCQ controllers (or any other non-legacy ATA interface based
ones) don't fit nicely into current ATA error handling in
interrupt scheme. As NCQ errors require issuing read log
command, we need to be in EH context to handle these errors.
* To properly implement hotplug, we need to have solid error
handling. IMHO, implementing hotplug with current EH will
be quite fragile.
Whether we choose to stay with ->eh_strategy_handler or move over to
fine-grained SCSI EH, IMHO, libata EH needs some work. So... how
should we proceed?
Thanks.
--
tejun
next reply other threads:[~2005-08-20 2:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-20 2:33 Tejun Heo [this message]
2005-08-20 4:48 ` [SUMMARY] libata EH Jeff Garzik
2005-08-20 17:31 ` Tejun Heo
2005-08-20 20:02 ` Alan Cox
2005-08-21 4:09 ` Jeff Garzik
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=20050820023351.GA690@htj.dyndns.org \
--to=htejun@gmail.com \
--cc=albertcc@tw.ibm.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=lkosewsk@gmail.com \
--cc=luben_tuikov@adaptec.com \
--cc=mlord@pobox.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).