On 14-02-04 02:10 PM, Sarah Sharp wrote: > On Mon, Feb 03, 2014 at 04:45:14PM +0000, David Laight wrote: > >> From the end of section 4.10.1.1 (Short transfers) >> - If the Short Packet occurred while processing a Transfer TRB with only an >> ISP flag set, then two events shall be generated for the transfer; >> one for the Transfer TRB that the short packet occurred on, and a second >> for the last TRB with the IOC flag set. >> - Software shall not interpret an Short Packet Event as indicating that the >> TD that it is associated with is “complete”, unless the TRB Pointer field >> of the Transfer Event references the last TRB of the TD. > > And there's code in the xHCI driver to ignore the second successful > event. See ep->last_td_was_short. Yes, this is a slight race > condition, and we should wait for the successful event. However, we > have not seen any issues with this race condition. > >> Which means that the controller is obeying the rules, and the software is wrong. .. > In this case, the bug has been worked around (not perfectly), but we've > had no customer reports that this is an issue. There is no user-visible > impact as far as we know. So fixing this race condition is a really low > priority for me, and the fix would have to very minimally touch the > driver. .. There are a gazillion reports out there (google) that using any XHCI controller other than the NEC chip (and some Intel chips) causes instability, in particular when using the AMD and VIA chips. Right now, Linux USB3 has a very bad reputation -- buggy and unstable. If there's a bug we/you know about, then let's get it fixed. It could help some of those anonymous reports. Cheers -- Mark Lord Real-Time Remedies Inc. mlord@xxxxxxxxx -- 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
