Patchwork [BUG] libahci returns stale result tf much of the time.

login
register
mail settings
Submitter Mark Lord
Date Sept. 24, 2010, 1:11 p.m.
Message ID <4C9CA385.5090709@teksavvy.com>
Download mbox | patch
Permalink /patch/65651/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Mark Lord - Sept. 24, 2010, 1:11 p.m.
On 10-09-24 03:01 AM, Seed wrote:
> On Fri, Sep 24, 2010 at 4:27 PM, Mark Lord<kernel@teksavvy.com>  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.

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Sept. 24, 2010, 1:24 p.m.
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@teksavvy.com> 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:

[~] hdparm --verbose -M128 /dev/sdb

/dev/sdb:
  setting acoustic management to 128
outgoing cdb:  85 06 20 00 42 00 80 00 00 00 00 00 00 40 ef 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: sb[]:  72 00 00 00 00 00 00 0e 09 0c 00 00 00 80 00 00 00 00 00 00 e0 50 00 00 00 00 00 00 00 00 00 00
SG_IO: desc[]:  09 0c 00 00 00 80 00 00 00 00 00 00 e0 50
       ATA_16 stat=50 err=00 nsect=80 lbal=00 lbam=00 lbah=00 dev=e0
outgoing cdb:  85 08 2e 00 00 00 00 00 00 00 00 00 00 40 ec 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: sb[]:  72 0b 47 00 00 00 00 0e 09 0c 00 fd 00 fd 00 fd 00 fd 00 fd fd fd 00 00 00 00 00 00 00 00 00 00
incoming_data:  5a 04 ff 3f c8 37 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 20 20 4e 56 43 36 48 4d 43 43 54 44 32 59 44 4e 03 00 04 3e 04 00 33 56 4f 33 36 41 41 4d 44 48 37 53 32 32 31 35 56 32 53 4c 38 41 20 30 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 00 00 2f 00 40 00 02 00 02 07 00 ff 3f 10 00 3f 00 10 fc fb 00 00 01 40 41 61 0e 00 00 07 00 03 00 78 00 78 00 f0 00 78 00 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 02 00 00 00 00 00 00 00 7c 00 19 00 eb 74 ea 7f 23 40 e9 74 02 3e 23 40 3f 20 21 00 00 00 00 00 fe ff 00 00 80 80 00 00 00 00 00 00 00 00 00 00 40 41 61 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 0b 00 00 00 00 00 82 3a b1 0c 60 fe 01 00 00 40 00 00 00 00 00 00 00 00 f7 01 04 2a 00 14 00 04 80 02 7f 3f c0 00 40 00 00 ac 00 80 00 00 4f 33 36 43 00 00 13 c0 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 c0
SG_IO: desc[]:  09 0c 00 fd 00 fd 00 fd 00 fd 00 fd fd fd
       ATA_16 stat=fd err=fd nsect=fd lbal=fd lbam=fd lbah=fd dev=fd
I/O error, ata_op=0xec ata_status=0xfd ata_error=0xfd
outgoing cdb:  85 08 2e 00 00 00 00 00 00 00 00 00 00 40 a1 00
SG_IO: ATA_16 status=0x2, host_status=0x0, driver_status=0x8
SG_IO: sb[]:  72 0b 00 00 00 00 00 0e 09 0c 00 04 00 00 00 00 00 00 00 00 e0 51 00 00 00 00 00 00 00 00 00 00
incoming_data:  5a 04 ff 3f c8 37 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 20 20 4e 56 43 36 48 4d 43 43 54 44 32 59 44 4e 03 00 04 3e 04 00 33 56 4f 33 36 41 41 4d 44 48 37 53 32 32 31 35 56 32 53 4c 38 41 20 30 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 00 00 2f 00 40 00 02 00 02 07 00 ff 3f 10 00 3f 00 10 fc fb 00 00 01 40 41 61 0e 00 00 07 00 03 00 78 00 78 00 f0 00 78 00 00 00 00 00 00 00 00 00 00 00 00 00 1f 00 02 00 00 00 00 00 00 00 7c 00 19 00 eb 74 ea 7f 23 40 e9 74 02 3e 23 40 3f 20 21 00 00 00 00 00 fe ff 00 00 80 80 00 00 00 00 00 00 00 00 00 00 40 41 61 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 0b 00 00 00 00 00 82 3a b1 0c 60 fe 01 00 00 40 00 00 00 00 00 00 00 00 f7 01 04 2a 00 14 00 04 80 02 7f 3f c0 00 40 00 00 ac 00 80 00 00 4f 33 36 43 00 00 13 c0 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 c0
SG_IO: desc[]:  09 0c 00 04 00 00 00 00 00 00 00 00 e0 51
       ATA_16 stat=51 err=04 nsect=00 lbal=00 lbam=00 lbah=00 dev=e0
I/O error, ata_op=0xa1 ata_status=0x51 ata_error=0x04
  HDIO_DRIVE_CMD(identify) failed: Input/output error
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Robert Hancock - Sept. 24, 2010, 11:26 p.m.
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@teksavvy.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo - Oct. 4, 2010, 9:18 a.m.
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?

Thanks.
Mark Lord - Oct. 4, 2010, 5:01 p.m.
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.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Oct. 4, 2010, 5:06 p.m.
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Oct. 4, 2010, 5:31 p.m.
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.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Oct. 4, 2010, 6:50 p.m.
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeff Garzik - Oct. 4, 2010, 7:27 p.m.
On 10/04/2010 02:50 PM, Mark Lord wrote:
> 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 ??


Very interesting...  poking at this now on pre- and post-libahci 
platforms.  As you said, don't see much difference in behavior WRT 
libahci -- which I expected/hoped, since that split shouldn't have 
changed behavior at all[1].

	Jeff


[1] though clearly there were bugs, eg. the SHT issue, so nothing's out 
of the question
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Oct. 4, 2010, 7:35 p.m.
On 10-10-04 03:27 PM, Jeff Garzik wrote:
> On 10/04/2010 02:50 PM, Mark Lord wrote:
>> 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 ??
>
>
> Very interesting... poking at this now on pre- and post-libahci platforms. As you said, don't see much difference in behavior WRT libahci -- which I expected/hoped, since that split shouldn't have changed behavior at all[1].


Yeah.  Non-data commands still get a (correct) updated result_tf from AHCI,
but data commands don't get one, unless they fail.

Weird, but I've worked around it now.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeff Garzik - Oct. 4, 2010, 7:42 p.m.
On 10/04/2010 03:35 PM, Mark Lord wrote:
> On 10-10-04 03:27 PM, Jeff Garzik wrote:
>> On 10/04/2010 02:50 PM, Mark Lord wrote:
>>> 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 ??
>>
>>
>> Very interesting... poking at this now on pre- and post-libahci
>> platforms. As you said, don't see much difference in behavior WRT
>> libahci -- which I expected/hoped, since that split shouldn't have
>> changed behavior at all[1].
>
>
> Yeah. Non-data commands still get a (correct) updated result_tf from AHCI,
> but data commands don't get one, unless they fail.
>
> Weird, but I've worked around it now.

Might be that we just get a single-bit "OK" notification from hardware 
for successfully completed commands, a la NCQ's SDB FIS.

Which opcodes are you using?  I see set-acoustic-mgmt in one email...

	Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Lord - Oct. 4, 2010, 7:51 p.m.
On 10-10-04 03:42 PM, Jeff Garzik wrote:
> On 10/04/2010 03:35 PM, Mark Lord wrote:
>> Yeah. Non-data commands still get a (correct) updated result_tf from AHCI,
>> but data commands don't get one, unless they fail.
>>
>> Weird, but I've worked around it now.
>
> Might be that we just get a single-bit "OK" notification from hardware for successfully completed commands, a la NCQ's SDB FIS.
>
> Which opcodes are you using? I see set-acoustic-mgmt in one email...


opcode 0xec : IDENTIFY

The result_tf it receives is from whatever non-data command last preceeds it.
So if the previous non-data command failed (eg. hdparm -Z),
then the IDENTIFY command actually works, but appears to fail.

Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo - Oct. 5, 2010, 7:07 a.m.
Hello,

On 10/04/2010 09:51 PM, Mark Lord wrote:
>> Which opcodes are you using? I see set-acoustic-mgmt in one email...
> 
> opcode 0xec : IDENTIFY
> 
> The result_tf it receives is from whatever non-data command last preceeds it.
> So if the previous non-data command failed (eg. hdparm -Z),
> then the IDENTIFY command actually works, but appears to fail.

I've been thinking about it and it occurred to me that PIO data
commands don't use D2H Reg FIS for command completion.  I don't recall
exactly but the PIO Setup FIS contains the result register, right?  It
seems like we should look at different places or simulate output
depending on the command executed.  Hmmm....

Thanks.
Mark Lord - Oct. 5, 2010, 2:06 p.m.
On 10-10-05 03:07 AM, Tejun Heo wrote:
> Hello,
>
> On 10/04/2010 09:51 PM, Mark Lord wrote:
>>> Which opcodes are you using? I see set-acoustic-mgmt in one email...
>>
>> opcode 0xec : IDENTIFY
>>
>> The result_tf it receives is from whatever non-data command last preceeds it.
>> So if the previous non-data command failed (eg. hdparm -Z),
>> then the IDENTIFY command actually works, but appears to fail.
>
> I've been thinking about it and it occurred to me that PIO data
> commands don't use D2H Reg FIS for command completion.  I don't recall
> exactly but the PIO Setup FIS contains the result register, right?  It
> seems like we should look at different places or simulate output
> depending on the command executed.  Hmmm....
..

Yeah, maybe something like that.

But do note that I have verified that "hdparm -C" does work correctly,
and is dependent upon correctly returned result_tf values.

It's not a PIO "data" command, though.  Does it get issued the same way?

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tejun Heo - Oct. 5, 2010, 4:06 p.m.
Hello,

On 10/05/2010 04:06 PM, Mark Lord wrote:
> Yeah, maybe something like that.
> 
> But do note that I have verified that "hdparm -C" does work correctly,
> and is dependent upon correctly returned result_tf values.
> 
> It's not a PIO "data" command, though.  Does it get issued the same way?

PIO Setup FIS is not used for nodata commands.  IIRC, nodata uses D2H
Reg FIS for command completion.  I think the only exception is PIO
data commands.  The weird hack is to satisfy PIO data command protocol
timing requirement stemming from PATA specification.  Eh... ugly.

Thanks.
Robert Hancock - Oct. 6, 2010, 1 a.m.
On Tue, Oct 5, 2010 at 10:06 AM, Tejun Heo <htejun@gmail.com> wrote:
> Hello,
>
> On 10/05/2010 04:06 PM, Mark Lord wrote:
>> Yeah, maybe something like that.
>>
>> But do note that I have verified that "hdparm -C" does work correctly,
>> and is dependent upon correctly returned result_tf values.
>>
>> It's not a PIO "data" command, though.  Does it get issued the same way?
>
> PIO Setup FIS is not used for nodata commands.  IIRC, nodata uses D2H
> Reg FIS for command completion.  I think the only exception is PIO
> data commands.  The weird hack is to satisfy PIO data command protocol
> timing requirement stemming from PATA specification.  Eh... ugly.

From my reading of the SATA spec, with the PIO data-in protocol, the
device can raise a D2H register FIS prior to transmitting data if the
command is aborted due to an error, but for normal completion, the
state machine just goes back to idle after the last data FIS is
transmitted and there's no final D2H register FIS - the final status
is set by the last PIO Setup FIS received. According to the AHCI spec,
the host adapter is supposed to copy the PIO Setup FIS to memory as
well. Presumably when retrieving the result taskfile for such PIO
data-in transfers we should be pulling it from that area, not the D2H
register FIS area, at least if the device transferred any data?
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- 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;
  }