From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH 0/2] convert libsas to the libata new eh Date: Sun, 13 Feb 2011 13:18:37 -0600 Message-ID: <1297624717.3001.2.camel@mulgrave.site> References: <1295797260.3007.118.camel@mulgrave.site> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from cantor2.suse.de ([195.135.220.15]:47002 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754606Ab1BMTSm (ORCPT ); Sun, 13 Feb 2011 14:18:42 -0500 In-Reply-To: <1295797260.3007.118.camel@mulgrave.site> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: linux-scsi Cc: linux-ide , Brian King , Robert Jennings On Sun, 2011-01-23 at 09:41 -0600, James Bottomley wrote: > 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). Since there's been remarkably little discussion of the ata changes, I think it's time to put this in linux-next to see what shakes out. James