On Fri, Sep 28, 2012 at 10:08:07PM -0400, Alan Stern wrote: > 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? Yes, I was suggesting a low-level error might have occurred. > > 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. Hmm, that is interesting. > > 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? Yes, I'll be looking at this drive with a bus analyzer as soon as I get it in the mail. :) Looking at the LPM handling, I have a couple hypothesis about what might have happened. First, I'm wondering if we're not waiting until the device exits U1/U2 before issuing the reset. If a device has a long U1/U2 exit latency, then we'll hit it with the reset before it comes out of U1/U2. Don's device started acting up after it was reset, so that might explain his issues. Second, I'm wondering if LPM is interacting with system suspend and resume in a bad way. I noticed in my log with the USB 3.0 hub and hard drive that LPM was disabled for the hub before the system went into suspend, but LPM was not disabled for the hard drive. We should have disabled LPM if usb_port_suspend() was called for the hard drive's port. I'll have to add some more debugging to see if it was called, but I don't think it is. ISTR that you said when the system is suspended or hibernated, only the roothub ports are placed into suspend, because the rest of the bus will be placed into global suspend when the system goes into S3/S4. However, there is no link state transition between U1/U2 into U3. If a USB 3.0 device in the second tier of the tree is in U1/U2 when the system is suspended, we're attempting to put it into U3 from U1 or U2. That could possibly cause us to hit bugs in the device firmware, since we're forcing the device through an undefined link state transition. Is my recollection of the system suspend procedure correct, or do I have something wrong here? Sarah Sharp -- 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
