Tejun Heo wrote:
Hello,
The current EH speed down code is more of a feature demonstration and
goes through rdiculously many meaningless steps when condition is met.
This patchset tries to put some intelligence into speed down sequence.
The goal is to achieve reasonable number of speed down steps
reasonably spaced from one another and consider NCQ, cable type and
the current protocol when determining speed down steps, while not
bloating the code too much with nitty gritty details.
Roughly, the rules are...
1. If NCQ and protocol/timeout/unknown dev errors occur, turn off NCQ
2. If excessive transfer errors occur, speed down within the current
transfer mode (UDMA/MWDMA/PIO). If UDMA, it's first adjusted down
a step, if error conditions persist, 40c limit is applied. Speed
down is done only twice.
3. If PATA && used up all DMA speed down steps && a LOT of
transmission/unknown errors occur, switch to PIO. So, we never
automatically step down to PIO on SATA. This is intended. Some
SATA hdd even seems to have problem with PIO data transfer
commands.
The last patch makes ahci report HSM violation error on spurious
completion of NCQ commands, thus causing NCQ off after several such
incidents. These drives should be blacklisted for DMA eventually.
This patchset is against...
upstream (eb0e63cca36a3389f0ccab4584f6d479b983fad5)
+ [1] pata_platform-fix-devres-conversion
+ [2] libata-convert-to-iomap
Ric, I guess this resolves the to-do item from you which has been
sitting in my mailbox for way too long. What do you think about the
rules?
Thanks.
Thanks, this looks great!
The key here is making sure that we get a really good classification of
error types and don't go down the step down path when the error does not
indicate that the drive got the command and just correctly failed it.
(That behavior, which we hit with one specific issues earlier & you have
already fixed, reminds me of the American tourist abroad syndrome. If
someone does not understand what you asked in English, just say it again
slower and louder until they get it ;-)).
We might still want/need to be able to "lock" specific drives so that
they do not drop out of DMA mode, not as the default but as a system
tuning issue. What we see in the set of ATA drives that we have in the
field is that dropping out of DMA mode is basically useless (for us at
least) since it is so slow and we always have other drives to fall back
on. Clearly not the case for typical end users, but a common case in the
storage space where we pack as many disk drives into each box as we can.
On that other thread, I mentioned that we need to get some good testing
done with this kind of thing. With Mark's error injection fixes (or the
new ATA spec'ed ability to inject errors that Doug mentioned), along
with our population of real world flaky drives, I hope to be able to
beat on this in a realistic way in our labs,
ric
-
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
