On Thu, 14 Sep 2017, Andrey Konovalov wrote: > Looked at this a little more. > > dummy_timer() stucks in an infinite loop. It calls > usb_hcd_giveback_urb(), which in turn calls usbtouch_irq(), which > calls usb_submit_urb(), which calls dummy_urb_enqueue() and puts urb > back into dummy urb queue. dummy_timer() then does goto restart, finds > the urb and calls usb_hcd_giveback_urb() again. And this process goes > on again and again. It seems that something should either process the > urb and set urb->status or it should just expire. There is some throttling code, but it applies only to bulk transfers. Probably because the bandwidth limits for other types are slightly different. However, I don't think we need to worry about this level of detail, since the driver makes a number of other approximations anyway. Try the patch below; it should fix the problem. Alan Stern Index: usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c =================================================================== --- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c +++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c @@ -1781,7 +1781,6 @@ restart: struct dummy_request *req; u8 address; struct dummy_ep *ep = NULL; - int type; int status = -EINPROGRESS; urb = urbp->urb; @@ -1789,14 +1788,10 @@ restart: goto return_urb; else if (dum_hcd->rh_state != DUMMY_RH_RUNNING) continue; - type = usb_pipetype(urb->pipe); - /* used up this frame's non-periodic bandwidth? - * FIXME there's infinite bandwidth for control and - * periodic transfers ... unrealistic. - */ - if (total <= 0 && type == PIPE_BULK) - continue; + /* Used up this frame's bandwidth? */ + if (total <= 0) + break; /* find the gadget's ep for this request (if configured) */ address = usb_pipeendpoint (urb->pipe); -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
