On Thu, Nov 12, 2015 at 10:46 AM, Michael Reutman <mreut...@epiqsolutions.com> wrote: > On Mon, Nov 9, 2015 at 9:21 AM, Alan Stern <st...@rowland.harvard.edu> wrote: >> Here's a revised quick-and-dirty workaround. It replaces the earlier >> one. (And like the earlier one, it is meant to apply on top of >> the usbfs-snoop patch, but I don't think that makes any difference >> now.) >> >> The idea is to wait until the QH has remain unchanged for at least 2 ms >> before deciding that the host controller has stopped using it. If this >> doesn't fix the problem then I will be completely out of ideas and will >> have to ask for help from someone at AMD. >> >> When testing this, don't bother with the usbfs-snoop stuff. With luck >> it won't matter, because the test program won't hang. > > Apologies for the delay, been working on another project recently that > has taken up most of my time. > > I applied the patch and have ran our application for 20 to 30 minutes > thus far without issue. Later on tonight I'll set it up for an > overnight test to ensure that it doesn't get stuck somewhere further > down the line. > > Hopefully this is the fix!
Ran 1 million operations of launch+cancel usb transfers last night without getting into the stuck state. I'll bump up the iterations to 10 million or so and run it again tonight just to be certain, but I think the last patch has the fix needed for this particular hardware. Michael Reutman Software Engineer Epiq Solutions 847-598-0218 x68 www.epiqsolutions.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
