Mark Lord wrote:
Mark Lord wrote:
Tejun Heo wrote:
So, this is specific to SATA (the host side at least) piix && PIO READ,
right? I think we can fit this code nicely into
piix_sata_error_handler() if we make sure that it triggers under the
right condition - after a PIO READ command fails due to HSM violation
caused by stuck DRQ.
Yeah, so far it's just PIO FROM DEVICE on a "SATA" device on ata_piix.
It *may* be more widespread than that, but we'll have to test some
others.
I retested this again today on my new pure-SATA notebook with ata_piix.
In this case, the DRQ drain is not necessary, but also doesn't harm
anything.
Tested it both ways. This is with a Hitachi HTS541612J9SA00 SATA drive.
The original fault was on ata_piix SATA, with some kind of external
bridge (on the motherboard) to a Seagate PATA drive. Sometime in the
next few days I'll have the exact same drive, but with a SATA interface,
and we'll try that in the pure-SATA situation.
This will tell us whether it's the bridge, or the drive, that was the
issue.
The fix remains the same: drain the data fifo when DRQ is left high.
Okay, I finally got round to testing this with the new pure-SATA
notebook I have here. Same problem: without draining the DRQ fifo,
the system *never* recovers.
But with the patch to drain DRQ, all is well. That patch is now a keeper
for my own kernels. Tejun, did you want to cook up a better-placed variant
of it for mainline? I'm away for a few days now..
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
