From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: [BUG] libahci returns stale result tf much of the time. Date: Mon, 04 Oct 2010 14:50:28 -0400 Message-ID: <4CAA21F4.5060000@teksavvy.com> References: <4C9C3878.9010206@teksavvy.com> <4C9C44D0.1030409@teksavvy.com> <4C9CA385.5090709@teksavvy.com> <4C9CA673.4090104@teksavvy.com> <4C9D33C0.8050900@gmail.com> <4CA99BCB.8080904@gmail.com> <4CAA0885.8060906@teksavvy.com> <4CAA0996.5080403@teksavvy.com> <4CAA0F6C.6080609@teksavvy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59792 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755029Ab0JDSuc (ORCPT ); Mon, 4 Oct 2010 14:50:32 -0400 In-Reply-To: <4CAA0F6C.6080609@teksavvy.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Tejun Heo Cc: Robert Hancock , Seed , Jeff Garzik , IDE/ATA development list 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