Tejun Heo wrote:
Mark Lord wrote:
..
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, I've implemented this, and it sort of works now.
But libata-eh is interfering in a different way.
It reads the SCR_ERROR register for the PMP link,
notices that the SERR_COMM_RECOVERED bit is set,
and then decides to perform a full reset.
This bit seems to be always set whenever sata_mv tries
to report device-errors (media errors) in NCQ for a pmp.
I'll have to dig some more, but it's probably just leftover
from the initial probe/reset time or something.
This is a Marvell PM.
My understanding was, that this particular bit is supposed
to be for information purposes only, letting us know that
the hardware has automatically recovered from a soft error.
So why are we taking a hammer to things there?
Cheers
--
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
