Re: [PATCH #upstream-fixes 2/2] libata: implement ATAPI_HORKAGE_NOPIO and apply it to GGW-H10N

[Jeff Garzik <jeff@garzik.org>]

On 11/15/2009 01:22 PM, Robert Hancock wrote:
> On Sun, Nov 15, 2009 at 2:16 AM, Tejun Heo<tj@kernel.org>  wrote:
>> Hello,
>>
>> 11/14/2009 09:11 AM, Robert Hancock wrote:
>>> Luke/Tejun, do you have some error output from those wodim or growisofs
>>> errors? It would be useful to know what commands those were that failed
>>> and whether they were also an unusual data size.
>>
>> I don't have anything.  For some reason, ahci works fine on the setups
>> here.  :-(
>>
>> I'm waiting for Dan's further report.  I still am not sure whether
>> we're actually seeing a lot of ahci ATAPI failures or it's just that a
>> lot of reports are on ahci because it's the most often used driver
>> now.  I don't think anything fundamental is broken.  The reports are
>> too infrequent for that to be true.  It might have something to do
>> with the buffer padding / draining we do or how the controller and
>> driver react.
>
>> From the bug 10091 it looks like the failing command was a MODE SELECT
> with data transfer length of 66 bytes which is definitely odd..
>
> My suspicion is that we're either padding out the data buffer and the
> indicated PRD length to a longer length than the drive actually wants
> to transfer, and the controller isn't happy with that, OR maybe
> vice-versa (i.e. we don't pad out the length and it wants us to). It's
> not clear if this and Jeff's issue are actually the same thing as the
> response is fairly different (interface fatal error and SError
> indications on the NV vs. a timeout on whatever chipset Jeff's using),
> but that may just be a chipset difference.
>
> If Jeff has a repeatable test case then that's likely the most
> promising place to start poking at things..

Nope, I replied to that original thread, well after the fact, noting my 
hardware likely flaky.  Unable to reproduce the problem anymore, 
unfortunately.

	Jeff