On 10-10-04 01:01 PM, Mark Lord wrote:
On 10-10-04 05:18 AM, Tejun Heo wrote:
Hello,
On 09/25/2010 01:26 AM, Robert Hancock wrote:
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?
Hmm... one possibility is that the controller takes some time to
update the area and the driver is reading it off too early. Maybe
adding a delay would resolve the issue? Mark, do you know whether
this problem is isolated to JMB360?
..
That's my theory, too (slow updating of the area).
I haven't pursued it further yet, but I will.
This is really disruptive for me here, as my primary eSATA
adaptor in my notebook is JMB360, and it gets used a LOT.
Okay, I just now ran a quick test on another machine with AHCI: Same bug:
00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA AHCI Controller (rev 02)
So it's probably universal. Try it with this simple test:
hdparm -I /dev/sdX ## this works
hdparm -Z /dev/sdX ## this will fail --> obsolete vendor-specific command
hdparm -I /dev/sdX ## this fails when following the above
hdparm -z /dev/sdX ## force some regular I/O, to clear the bad state from the driver
hdparm -I /dev/sdX ## this now works again
Cheers
-ml
--
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
