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. -- 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
