James Bottomley wrote:
On Mon, 2008-02-25 at 10:34 -0600, Brian King wrote:
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.
Strongly seconded. Doing your own ATA EH would be foolish, as that
would imply duplicating all that carefully-time-tested logic handling
devices which follow the ATA specs... about 98% of the time :)
Just the set-transfer-mode logic took years to get right for the
majority of ATA devices.
OK ... I'm grepping around in the source trying to figure out all of
this. Is it documented anywhere? That would really help me out at the
moment.
Unfortunately, not really. The simplistic version is... freeze, set
some flags, call a function to schedule EH as needed -- most notably
when your HBA signals an ATA device error or some other error in the ATA
domain.
Regardless of all this... libsas IMO will cause some libata-EH growing
pains. libsas needs libata-EH for probing, revalidation,
initialization, etc. But libsas probably does NOT need libata-EH for
certain duties like SATA PHY diagnosis and link handling.
libsas needs libata-EH. Unfortunately for libsas, libata-EH was written
from the "libata controls the world" point of view, and probably needs
some modifications to play well in the new SATA/SAS shared worldview.
Brian's recommendation is quite sane... your ->error_handler() probably
just needs hard reset (aka COMRESET) capability.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
