Hi Ming, On Wednesday 20 June 2012 22:59:03 Ming Lei wrote: > On Tue, Jun 19, 2012 at 11:40 PM, Alan Stern 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; > } Looks like we both came up with the same solution. I should have read your reply before posting a patch. > 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. -- Regards, Laurent Pinchart -- 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
