All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@suse.de>
To: linux-scsi <linux-scsi@vger.kernel.org>,
	linux-ide <linux-ide@vger.kernel.org>
Cc: Brian King <brking@linux.vnet.ibm.com>,
	Robert Jennings <rcj@linux.vnet.ibm.com>
Subject: [PATCH 0/2] convert libsas to the libata new eh
Date: Sun, 23 Jan 2011 09:41:00 -0600	[thread overview]
Message-ID: <1295797260.3007.118.camel@mulgrave.site> (raw)

The bad news is that this is a pretty horrific conversion.  Because of
the amount of control the new eh wants (and the slew of monolithic
assumptions it makes), the entire error handler routine has to be sliced
apart and sewn back together to make it callable as part of an existing
error handler (rather than trying to do everything on its own).

The even worse news is that unless you have an existing strategy
handler, you can't make use of this.  That means that ipr is
unconvertable in its current form.  Given the two really nasty options:
give ipr its own error handler via its own transport class, or attach
ipr to libsas and let it do the work, I'd choose the latter.
Unfortunately, my power box with IPR has been non-functional for a year
(and all pleas to IBM to fix it have so far gone unanswered), so I can't
really do this myself.

Once we carve up libata, it's still a rather complex call sequence for
libsas because of libata's annoying insistance on calling the error
handler at the drop of a hat.  The principle differentiator used is the
fact that if a SCSI command no longer has an associated SAS task, (i.e.
libsas thinks it's complete) it must be destined for libata.  This works
correctly in all the ATAPI sense processing instances I've tested.
Finally, we still have to call port recovery.  Currently, it's
impossible to tell which port libata thinks is in error (libata knows
because it has one host per port, but libsas doesn't), so the final
solution is just to call port recovery for every SATA/STP attached port.

I've tested all of this with mvsas over expander attached ATA devices
using STP (aic94xx seems to have developed some handling fault for STP,
which I'll look into next).

James

---

James Bottomley (2):
  libata: separate error handler into usable components
  libsas: convert to libata new error handler

 drivers/ata/libata-eh.c             |   53 ++++++++++++++++++----
 drivers/scsi/libsas/sas_ata.c       |   87 ++++++++++++++++++++++++++++++++--
 drivers/scsi/libsas/sas_scsi_host.c |   14 +++++-
 include/linux/libata.h              |    2 +
 include/scsi/sas_ata.h              |   22 +++++++++
 5 files changed, 161 insertions(+), 17 deletions(-)



             reply	other threads:[~2011-01-23 15:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-23 15:41 James Bottomley [this message]
2011-01-23 15:42 ` [PATCH 1/2] libata: separate error handler into usable components James Bottomley
2011-01-23 15:44 ` [PATCH 2/2] libsas: convert to libata new error handler James Bottomley
2011-01-24 21:12 ` [PATCH 0/2] convert libsas to the libata new eh Jeff Garzik
2011-01-24 21:16   ` James Bottomley
2011-01-25 18:56 ` Brian King
2011-01-26 14:08   ` James Bottomley
2011-01-26 17:46     ` Jeff Garzik
2011-01-26 17:55       ` James Bottomley
2011-02-13 19:18 ` James Bottomley
2011-02-15  7:03   ` Jeff Garzik
2011-02-15 14:15     ` James Bottomley

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=1295797260.3007.118.camel@mulgrave.site \
    --to=james.bottomley@suse.de \
    --cc=brking@linux.vnet.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rcj@linux.vnet.ibm.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 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.