On Tue, Jun 19, 2012 at 11:40 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, 18 Jun 2012, Dave Jones wrote: > >> This bug has been around for a while. >> https://bugzilla.redhat.com/show_bug.cgi?id=746914 >> >> Seems that something changed circa 2.6.33 which prevents uvcvideo from >> getting enough bandwidth when plugged into an ehci port (ohci works) >> >> anyone have suggestions ? > > Can we move the discussion of the bug from Fedora's bugzilla onto this > mailing list? I don't have the email addresses of the principals, > apart from Hans. > > The usbmon trace attached to comment #13 shows three errors. The > first, a fairly innocuous mistake, is that the uvcvideo driver submits > requests in which the length values in the iso_frame_desc array are > too big. It sets the length of each packet to 3060 instead of 2460, > which is the correct value for altsetting 11 according to the lsusb > output. Looks there is an obvious bug in uvcvideo, and the below patch may fix it: diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c index b76b0ac..d1e7cb2 100644 --- a/drivers/media/video/uvc/uvc_video.c +++ b/drivers/media/video/uvc/uvc_video.c @@ -1594,7 +1594,7 @@ static int uvc_init_video(struct uvc_streaming *stream, gfp_t gfp_flags) psize = le16_to_cpu(ep->desc.wMaxPacketSize); psize = (psize & 0x07ff) * (1 + ((psize >> 11) & 3)); if (psize >= bandwidth && psize <= best_psize) { - altsetting = i; + altsetting = alts->desc.bAlternateSetting; best_psize = psize; best_ep = ep; } But the bug may not relate with the above. Probably it is caused by mistaken intf->num_altsetting of 12, instead of 13. Also from the usbmon trace, all packets are completed with length of 12, which indicates that there aren't capture data at all. > > More seriously, near the end of the usbmon trace we see that the > problems start when no interrupts occur during a period of at least 52 > ms (!). Obviously this sort of thing shouldn't happen; either IRQs are > lost or some other driver has disabled interrupts for far too long. > Since the isochronous pipeline set up by uvcvideo has a depth of only > 20 ms, this leads to a sizeable dropout. > > Finally, we have the EFBIG submission errors. They occurred because > the delay in interrupt delivery (52 ms) was longer than ehci-hcd's slop > amount (20 ms). This led ehci-hcd to think that the new URBs were > being scheduled very far in the future rather than in the past, so it > rejected them. > > Now the question is: Why were interrupts not delivered for such a long > period? I'm not at all sure how to find out. Maybe the irqsoff tracer can help troubleshoot it. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
