Comment 57 for bug 1063474

On 9/18/2013 5:27 PM, Bruce Link wrote:
> 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
Robert,

Writing to you to bump this thread. Is there anything more I can do to
troubleshoot this issue?

Thanks
Bruce