On Wed, 18 Nov 2015, Michael Reutman wrote: > On Tue, Nov 17, 2015 at 12:21 PM, Alan Stern <st...@rowland.harvard.edu> > wrote: > > On Tue, 17 Nov 2015, Michael Reutman wrote: > >> 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. > > > > Okay, that sounds good. If everything works out, I'll write a patch > > that does all this properly and ask you to test it. > > I ended up setting the usb test to run until the user decided to > cancel it and ran it overnight for a total of 18 hours. Appears to > have avoided the "stuck" state!
Great! > > PS: Assuming it does work out, I would appreciate seeing the usb_snoop > > output for a run containing just 20 iterations or so. > > Do you want me to grab usb_snoop for the last patch you provided or > with the formal patch? Also, do you want usb_snoop_max enabled as > well? For the last patch. And yes, do set usb_snoop_max. > Glad to be reaching a definite conclusion to this problem. I hope so. There is one thing I'm still undecided about: Should this workaround be applied only to AMD/ATI controllers or should it apply to everything? It does have a small probability of slowing down transfers under certain circumstances, but on the other hand, it's quite possible that other controller types will have the same sort of weakness as the AMD ones. Alan Stern -- 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
