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 -- 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
