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@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
