linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian King <brking@linux.vnet.ibm.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: linux-ide <linux-ide@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: Need help with libata error handling in libsas
Date: Mon, 25 Feb 2008 10:34:29 -0600	[thread overview]
Message-ID: <47C2EE15.3060105@linux.vnet.ibm.com> (raw)
In-Reply-To: <1203886936.3135.75.camel@localhost.localdomain>

James Bottomley wrote:
> I keep hearing that we need to convert libsas to use libata's new error
> handling.  Unfortunately, I have very little conception of what that
> means.  Right at the moment, libsas doesn't use any error handling
> functions of libata at all.
> 
> I've looked through the libata-eh functions, and I find them frankly
> incomprehensible.
> 
> Firstly, let me say what SAS error handling actually does:

Let me chime in with what ipr error handling does/can do. The ipr firmware
provides two basic SATA error handling methods with some modifiers to each.

Cancel All - This cancels all outstanding commands to the device. When issued
to an ATA device, this gets escalated by the firmware to an SRST. When issued
to an ATAPI device, an ATA NOOP is issued.

Reset Device - This command has modifiers to indicate either a soft reset
or a hard reset.

Currently, the only SATA devices that ipr officially attaches are ATAPI
DVD devices. In our testing we've come to the conclusion that trying to
use anything but a hard reset for ERP is generally more trouble than it
is worth.

> All of this leads me to conclude, that all libsas needs is to plumb in
> the ATA equivalent of abort, junk the task query for libata devices and
> simply proceed, as if the task is held at the target, along the
> escalating reset path.

The new libata-eh is used for more than just EH. It is used for device
probing, device revalidation, and power management. It is also woken for
all command failures and is where the request sense for ATAPI devices is
issued. Device revalidation following reset is also critical for ATA and
ATAPI devices. One example of this is some SATA/PATA converter chips
lose their DMA xfer settings following a reset and default to PIO mode
only. Any DMA transfer that is attempted simply hangs.

The other issue is PMP support. The more that gets pushed into libsas,
the more libsas needs to know about things such as PMP.

-Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center




  reply	other threads:[~2008-02-25 16:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 21:02 Need help with libata error handling in libsas James Bottomley
2008-02-25 16:34 ` Brian King [this message]
2008-02-25 16:57   ` James Bottomley
2008-02-25 17:45     ` 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=47C2EE15.3060105@linux.vnet.ibm.com \
    --to=brking@linux.vnet.ibm.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@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).