Comment 52 for bug 1063474

On 9/17/2013 8:40 PM, Robert Hancock wrote:
> On Tue, Sep 17, 2013 at 6:35 PM, Bruce Link <Bruce@1045.ca> wrote:
>>> Hello,
>>>
>>> On Fri, Sep 06, 2013 at 07:53:49PM -0600, Robert Hancock wrote:
>>>>> Is there any more information I can supply that would be helpful?
>>>> I'm not quite sure what the next step would be. It's quite possible
>>>> that the NVIDIA driver in Windows is doing some magic to work around
>>>> the problem that we don't know about, but it's hard to say what that
>>>> might be. The fact that the default drivers used in the WinPE boot
>>>> don't seem to work would tend to point toward some kind of hardware
>>>> incompatibility issue.
>>>>
>>>> Tejun, think you poked with some of this stuff before - any ideas?
>>> It has been years since I looked at MCP quirks, of which there are too
>>> many. It's likely another quirk on the controller side that nvidia
>>> worked around somehow without telling anyone. Given the history and
>>> that nvidia is out of chipset market, I think it's highly unlikely to
>>> learn what the issue and workaround are without reverse engineering
>>> it. So, um, no idea.
>>>
>>> Thanks.
>>>
>>> --
>>> tejun
>>> --
>>
>> Robert,
>>
>> I've inquired about this problem with Allen Martin at Nvidia, he had the
>> following reply:
>>
>> /--------SNIP---------------/
>> Hi Bruce, I did work on the Windows SATA driver for those chipsets, so I’m
>> familiar with it. I’m not aware of any of any timing workarounds for any
>> devices in the driver, but it’s certainly true that there are devices that
>> have timing sensitivity, especially around the IDENTIFY command and it may
>> inadvertently work with one driver and not another.
>>
>> From the bug reports it looks like it’s always timing out on a
>> TEST_UNIT_READY command? I assume this is probably the first command sent
>> down after IDENTIFY to check for presense of a CD in the drive? If so it’s
>> likely the drive is locked up and any command at that point will fail. If
>> you want to test out the theory about it being a timing issue, I would stick
>> some udelay()s in the identify code path, both before and after starting the
>> transfer to see if it makes any difference. Also do you know if the driver
>> does a PHY reset when it resets the link? If not, you can try doing that by
>> writing a 0 to SControl and then restoring it with the original value.
>>
>> Hope this helps,
>>
>> -Allen
>> /--------SNIP---------------/
>>
>> Does this provide any actionable information? I've tried searching for the
>> proper location to impliment these delays in the sata_nv.c and libata-eh.c
>> files but admittedly, am in over my head.
> Don't think there's any earth-shaking revelations but it might be a
> few things to try. First, though, apparently there is a firmware
> update for this drive of at least one revision up (WL0G) available
> from Lite-ON that you could try updating to. (You'll likely need to
> use Windows for that.) Given that it seems broken in at least two
> different environments on this controller, it's possible they fixed
> something related in the drive.
Robert,

I can report that the new firmware for the drive does not solve the problem.

watchtv@teevee:~$ dmesg |grep ata5
[ 1.090360] ata5: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xc400
irq 20
[ 1.556044] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.564199] ata5.00: ATAPI: ATAPI iHOS104, WL0G, max UDMA/100
[ 1.580140] ata5.00: configured for UDMA/100
[ 6.580035] ata5.00: qc timeout (cmd 0xa0)
[ 6.580043] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 7.048042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 7.072124] ata5.00: configured for UDMA/100
[ 12.072029] ata5.00: qc timeout (cmd 0xa0)
[ 12.072037] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 12.072041] ata5: limiting SATA link speed to 1.5 Gbps
[ 12.072043] ata5.00: limiting speed to UDMA/100:PIO3
[ 12.540058] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 12.564141] ata5.00: configured for UDMA/100
[ 17.564038] ata5.00: qc timeout (cmd 0xa0)
[ 17.564045] ata5.00: TEST_UNIT_READY failed (err_mask=0x4)
[ 17.564048] ata5.00: disabled
[ 17.564063] ata5: hard resetting link
[ 17.564065] ata5: nv: skipping hardreset on occupied port
[ 18.032068] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 18.032082] ata5: EH complete
watchtv@teevee:~$

My apologies for not noticing the firmware update earlier. I do recall
checking at one time, though it may have been prior to Sept. 2011.

Bruce