linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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