On 10-10-04 01:31 PM, Mark Lord wrote:
On 10-10-04 01:06 PM, Mark Lord wrote:
..
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
The issue also seems to be present in 2.6.32.8 on that same Intel AHCI platform,
so it probably has nothing to do with the libahci split.
I've dug a bit deeper, and worked around the issue.
It seems that libata is not always happy about DATA-xfer commands
that also have the check-sense bit set (0x20 in cdb[2]).
Perhaps that's not even valid in SCSI ??
Anyway, I'm updating hdparm to only set that bit for non-DATA commands,
and leave it unset for data commands (eg. IDENTIFY).
That's how libata itself does things internally.
Seems to fix whatever the issue was.
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
