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 13:06:30 -0400 Message-ID: <4CAA0996.5080403@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> 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.183]:63631 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753576Ab0JDRGc (ORCPT ); Mon, 4 Oct 2010 13:06:32 -0400 In-Reply-To: <4CAA0885.8060906@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: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