Mark Lord wrote:
Does the bit get set for the host link or pmp fanout links?
It's only on the pmp fanout link. Dunno why it gets set, but it does.
..
Oh, wait a sec.. I think I know what's going on.
We're back to the original problem in this thread again:
Aieee...
Mark Lord wrote:
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.
..
So what is happening now, is that libata-eh is going and attempting
to access the per-port SCRs *after* the READ_LOG_EXT commands.
And those per-port SCRs are not actually accessible: the shadow
registers are misbehaving -- known errata -- and cannot be accurately
used without a port reset.
Mmm.. gotta figure out a way to mark the port for RESET,
without having that action taint the commands already analyzed.
I suppose I'll have to just clone some code from libata-eh to
do the READ_LOG_EXT and then qc_complete() those commands
before continuing. Or something.
The usual way to handle this is to clear the controller state (not the
PHY) from ->error_handler() before calling the generic error_handler.
Many drivers do similar things - ahci restarts the engine, sil24 calls
sil24_init_port() and so on. Does mv need PHY reset to get it working
again?
--
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
