On Tue, 20 Mar 2007, Jiri Kosina wrote: > On Tue, 20 Mar 2007, Alan Stern wrote: > > > The USB HID driver fails to reset its error-retry timeout when there > > has been a long time interval between I/O errors with no successful URB > > completions in the meantime. As a result, the very next error would > > trigger an immediate reset, even if it was a chance event occurring > > long after the previous error. > > Thanks Alan, I will apply this to hid tree. Are you aware of any faulty > scenario/hardware which triggers this bug, or you detected this only by > reading the code? (i.e. is it 2.6.21 material, or is it enough to queue it > for 2.6.22 merge window?).
Sorry, there was a fair amount of additional background that didn't get included in the patch comment. More USB keyboards and mice than one might expect end up getting I/O errors. Almost always this results from hardware problems of one sort of another. For example, people attach the device to a USB extension cable, which degrades the signal. Or they simply have poor quality cables to begin with. Or they use a KVM switch which doesn't handle USB messages correctly. Etc... (On the other hand, there has been an ongoing thread on linux-usb-users in which Gordon Messmer determined that with one particular device/computer combination, the errors occurred if and only if he selected both CONFIG_PREEMPT and CONFIG_HZ_1000! With either one alone, or with neither, there were no errors. I don't have the slightest idea how that could happen.) At any rate, there have been reports from several users in which these I/O errors would occur more or less randomly, at intervals ranging from seconds to minutes. The error-handling code in hid-core.c was originally meant for situations where a single outage would persist for a few hundred ms (electromagnetic interference, for example). It didn't work right when these more sporadic errors occurred, because of a flaw in the logic which this patch fixes. The effect of the flaw was multiple device resets. Each reset is awkward because it interferes perceptibly with typing or mouse usage. With the patch, the resets occur only when two I/O errors happen in close proximity, which is a lot rarer (although it still does happen). It might be nice to avoid doing the resets entirely. However there is a case in Bugzilla (I don't remember the bug #) where a device really would freeze up every now and then, requiring a reset. So we can't just get rid of them. The number of people bothered by this is low enough that the patch doesn't need to be pushed into 2.6.21. And the patch isn't a complete fix since it doesn't eliminate the resets, it just makes them less frequent. Still, every little bit helps. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
