On Thu, 6 Oct 2005, Pete Zaitcev wrote: > On Thu, 6 Oct 2005 16:43:44 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote: > > > This patch (as576) removes some mistaken tests for disconnection from the > > HID driver. -EILSEQ refers to an arbitrary low-level protocol error, not > > necessarily a disconnection. Also, a completion routine will never see a > > status of -EPERM; that's used only to indicate a failure during > > usb_submit_urb. > > > --- usb-2.6.orig/drivers/usb/input/hid-core.c > > +++ usb-2.6/drivers/usb/input/hid-core.c > > @@ -923,9 +923,7 @@ static void hid_irq_in(struct urb *urb, > > break; > > case -ECONNRESET: /* unlink */ > > case -ENOENT: > > - case -EPERM: > > case -ESHUTDOWN: /* unplug */ > > - case -EILSEQ: /* unplug timeout on uhci */ > > return; > > case -ETIMEDOUT: /* NAK */ > > break; > > No freaking way, man.
[ :-) It's difficult to reconcile your command of English slang with your heavy accent... ] > Is there a particular scenario which this patch > fixes? Yes, at least in part. See kernel bug 4916. > Because that code is there for a reason. You cannot just do > it because some retarded document in Documentation/ suggests that it > might be a good idea. > > I have a bug assigned (bz#167070), which is, unfortunately, private. > But the summary goes like this > > HID driver completion handler prints -84(-EILSEQ) error messages > when a USB keyboard or mouse was unplugged. > > When a USB keyboard or mouse was unplugged, > HID driver completion handler hid_irq_in() > (@drivers/usb/input/hid-core.c) > continuously prints an error message "input irq status -84 received". > Once the USB was unplugged, the machine just hungs up. > > By the way, I have already found the patch to fix this > problem at http://lkml.org/lkml/2005/1/27/176. > The problem was settled by applying this patch to > drivers/usb/input/hid-core.c. If the problem is caused by the HID driver spamming the log and monopolizing the CPU when a disconnect occurs, the solution is to avoid logging so many messages and add a delay before resubmitting. Don't just treat any old error as a disconnect. (Unfortunately, adding a delay is not so easily done. I'm not familiar enough with the details of the HID driver to do it myself, otherwise I would have.) The code I removed was wrong in another way. -EILSEQ is the error code you get when a protocol error occurs for an IN transfer; exactly the same error on an OUT transfer yields -EPROTO. So the test in the handler for the interrupt-OUT URB was wrong. For the control-URB handler, either type of error could occur. And the test for -EPERM is just plain wrong. It can never occur. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
