On 09/24/2010 07:24 AM, Mark Lord wrote:
On 10-09-24 09:11 AM, Mark Lord wrote:
On 10-09-24 03:01 AM, Seed wrote:
On Fri, Sep 24, 2010 at 4:27 PM, Mark Lord<kernel@xxxxxxxxxxxx> wrote:
The bug seems to be in the libahci code somewhere.
ahci_qc_fill_rtf seems to be the function converting FIS to result_tf.
..
Yeah, that's as far as I got with it last night.
If you apply this patch (below), it makes the problem more "obvious",
though I still don't see exactly how that struct gets updated.
--- a/drivers/ata/libahci.c 2010-09-24 02:40:24.722887047 -0400
+++ b/drivers/ata/libahci.c 2010-09-24 09:10:21.761520099 -0400
@@ -1838,6 +1838,7 @@
d2h_fis += qc->dev->link->pmp * AHCI_RX_FIS_SZ;
ata_tf_from_fis(d2h_fis, &qc->result_tf);
+ memset(d2h_fis, 0xfd, AHCI_RX_FIS_SZ);
return true;
}
..
And here's an example of the bug, which should work (as a demo)
for most folks out there with the same controller ahci / JMB360:
Here, I'll use hdparm to do a "set acoustic" command
on a drive which does NOT have the "Acoustic Management" feature set.
Just look for the fd fd fd strings in the returned data,
and notice how the final IDENTIFY at the end works, but returns
bad ATA status 0x51 from the stale result_tf:
The d2h_fis area is supposed to be updated by the controller with the
last FIS received from the device. Maybe this controller just isn't
doing that for some reason?
--
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
