On Fri, 28 Sep 2012, Sarah Sharp wrote: > > This shows that the problem began when the device was sent a command it > > didn't recognize: 0xA1, which is a 12-byte ATA pass-through, in this > > case for an IDENTIFY DEVICE command (0xEC). Presumably the Western > > Digital device doesn't support ATA pass-through. The device halted its > > bulk-IN endpoint and then replied with a STALL to the > > Clear-Endpoint-Halt request (which is an invalid response). This is > > why the reset was tried. > > A stall is a valid response, if the device detected an error in the > status phase of the Clear Feature Halt control transfer. How could clearing the endpoint's Halt feature cause an error? Or are you suggesting that a low-level error in the transaction protocol caused the device to respond with STALL? > Maybe the link > becomes unstable when LPM is enabled, and that causes transfer issues on > the beginning of some transfers? Maybe so. It's odd that the problem seems to affect only control transfers. All the bulk transfers in the usbmon trace went through properly. > I've been running some tests with a couple USB 3.0 devices I have. A > Pluggable USB 3.0 hard drive seems to work fine with the new LPM code. > However, when I plug it into a VIA USB 3.0 hub and suspend and resume > the system, transfers to the device start to complete with transfer > errors. The device is reset, LPM is re-enabled, a transfer error > occurs, LPM is disabled, the device is reset, etc, over and over. > > I also have the vague recollection that the Intel Windows team was > having issues with devices with very long LPM exit latencies. Maybe we > need to disable LPM altogether for devices that have a long U2 latency. > I think both the VIA hub and the WD device had pretty long U2 latencies. Some careful bus monitoring could go a long way toward answering these questions... Being at Intel, you must have access to a USB-3 bus analyzer, yes? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
