On Sat, 4 Feb 2006, Helmut Toplitzer wrote: > On Saturday 04 February 2006 05:57, Mike Isely wrote: > > On Sat, 4 Feb 2006, Helmut Toplitzer wrote: > > > On Saturday 04 February 2006 02:08, Helmut Toplitzer wrote: > > >> Hi! > > >> > > >> > > >> Just in case .... > > >> > > >> Maybe Ingo Flaschberger's idea should be the default (tolerating > > >> errors). > > > > > > But it doesn't work either... > > > > No surprise there. Covering a symptom does not solve the problem. > > > > > Maybe device should be reset. > > > > Resetting the device is a very disruptive operation. There's not even any > > evidence that a reset of the device would help - especially if it isn't > > the device that is the cause. I could try to code for something like > > that, but again as I've said before, the device seems to be operating > > reliably for pretty much everyone else which leads me to wonder if there > > still isn't something unique to your configuration which is causing this > > that has not yet been isolated. > > > > Don't get me wrong. I'm not trying to ignore you here. I'm just not > > convinced that we have a real problem with the driver or the device in > > general.
It could be something as silly as electromagnetic interference from the fluorescent lights causing occasional packets to be messed up. (Yes, that actually happened to somebody -- his device would stop working whenever he switched the lights on or off.) The point is that I/O errors _do_ occur from time to time, and a robust driver should be prepared to tolerate them. If the error takes the form of a burst of interference which goes away after a few milliseconds, then retrying an operation or simply skipping over the missing data will suffice. If the error affects the device badly enough or the error is caused by a problem in the device then retrying may fail, leaving no alternative but to reset the device or to give up altogether. A good first step would be to add some debugging code, so that Helmut can tell exactly where the driver encounters the problem, what the relevant error codes are, and what happens when the driver and userspace program try to continue. Does the software somehow get out of sync with the device's I/O stream? Does the device stop responding entirely? You said above that there's no evidence that a device reset would help. You need to find a way to get that evidence, either positive or negative. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
