On Thu, 26 Nov 2009, Stephan Diestelhorst wrote: > Am Donnerstag 26 November 2009 00:45:14 schrieb Stephan Diestelhorst: > > Now back to bumping up the value. > > 900 us seems to do the trick. Tested with: > 500 us broken > 1000 us works > 600 us broken > 800 us broken > 900 us works > > Please see the dmesgs of the 500 - 900 us runs in the attached > archive. The 900 us have been tested with more than 80 modprobe / > rmmod rounds, with 1.0 s and 0.5 s delay. So the delay should be set to 1000 us, to include a margin of safety. That's a long time to delay, but it's the easiest solution. > All these runs had a working cam initially, that's what fooled us in > the initial estimation. > > I am curious, if I understand correctly that this is a chipset issue? > If so, why has it not been triggered with other USB devices? The device has nothing to do with it; what matters is the pattern of transfers done by the driver. In particular, the uvcvideo driver starts a periodic transfer when a program opens the device file, and then stops it when the device file is closed. If the stop occurs less than 900 us or so after the start, the bug will be triggered. So the answer is that with other USB devices, either the driver doesn't start up a periodic transfer when the device file is opened, or else programs opening the device file keep it open for longer than 900 us. 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
