On Tue, 3 Jan 2006, Pete Zaitcev wrote: > On Tue, 3 Jan 2006 10:44:12 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > > > This patch (as628) fixes the USB HID core's interpretation of the -EILSEQ > > error code. Contrary to the comments in the driver, the code does not > > always indicate a disconnection. The new treatment is not ideal because > > it doesn't retry the transfer, but at least it doesn't give up completely > > on the device and it won't spam the kernel log with error messages. > > I think I am confused here. The new treatment (in the patch) always retries > the transfer, whereaes old treatment was to give up... Here: > > > @@ -927,8 +927,9 @@ static void hid_irq_in(struct urb *urb, > > case -ENOENT: > > case -EPERM: > > case -ESHUTDOWN: /* unplug */ > > - case -EILSEQ: /* unplug timeout on uhci */ > > return; > > + case -EILSEQ: /* protocol error or unplug */ > > + case -EPROTO: /* protocol error or unplug */ > > case -ETIMEDOUT: /* NAK */ > > break; > > default: /* error */ > > Now the _very_ old treatment was to retransmit with an error message. > Is this what you mean?
I was talking about intr-OUT and control transfers; you're right that intr-IN transfers do get retried. > The problem you are going to hit with your always-resubmit patch is > when an unplug manages to loop and monopolize the CPU, thus not > allowing the disconnect thread to run. > > We were hashing this with Fujitsu and other sufferers of strange Intel > hardware (imagine UHCI on ia64) in bug 167070 (unfortunately, private), > and we zeroed on the attached patch. It came out with RHEL 4 U3 Beta > in December, so not a lot of generic testing mileage is on it yet, only > unit and function tests. It applies to not just old, but old-old > 2.6.9 base, so please keep it in mind. I submitted something similar, as you may recall, so I'm certainly open to the idea of more sophisticated error handling. Possibilities include backoff-and-retry and port reset. Both your patch here and mine only keep track of errors for the intr-IN endpoint. What about other errors? It would be good to get this right. I've been involved in a bug report http://marc.theaimsgroup.com/?t=106858508600004&r=1&w=2 where the problem actually turned out to be that the HID driver abandoned the mouse whenever one of these protocol errors occurred (which was fairly often). 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
