Re: libata-eh/pmp command sequence on NCQ media error

[Tejun Heo <htejun@gmail.com>]

Mark Lord wrote:
> Tejun,
> 
> During testing of my internal version of sata_mv.c here,
> I noticed the following:
> 
> With no port-multiplier attached, a media error during NCQ
> results in an immediate READ_LOG_EXT_10H to retrieve the
> task file for the failed I/O.
> 
> With a port-multiplier, there is instead a flurry of sata_pmp_read()
> attempts.  I'm guessing that the READ_LOG_EXT_10H would normally
> then follow those ?
> 
> The problem is, on most of the Marvell chips, non-data commands
> cannot succeed after any kind of error (until after the port is reset),
> so they fail, and we never then get to the READ_LOG_EXT_10H stage.
> Oddly, the READ_LOG_EXT_10H command itself is okay (with some errata
> goodness tossed in).
> 
> So, for sata_mv at least, I'd kinda like to have libata-eh attempt
> the READ_LOG_EXT_10H before it tries to (unsuccessfully) access the
> per-port SCRs on the PMP.
> 
> For now, I'll try and hack something into my local tree to ensure
> that things will actually work that way around without any other
> unforseen complications.
> 
> But for upstream, I'm thinking maybe a HORKAGE flag or something?
> I'm still trying to avoid having to pull a lot of libata-eh/pmp code
> into sata_mv for local customizations.

w00t w00t I thought about that when I wrote NCQ EH.  All you have to do 
is to export ata_eh_analyze_ncq_error() can call it right after 
error_handler starts and put the controller into a working state (so 
that SCR accesses work again).  After it finishes, call the generic 
handler.  The second time around ata_eh_analyze_ncq_error() will be 
no-op and you should get what you want.

-- 
tejun