Hi Alan, On Tuesday 19 June 2012 11:40:35 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. Oops. The following patch should fix this. >From 3bd3cb5fabd1088be51c3c7492bba84f9059cbb6 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> Date: Thu, 21 Jun 2012 11:35:04 +0200 Subject: [PATCH] uvcvideo: Fix alternate setting selection The alternate setting number is not equal to the alternate setting index in the interface alternate settings table. Use the alternate setting number from the interface descriptor when calling usb_set_interface(). Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> --- drivers/media/video/uvc/uvc_video.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c index 6fc1659..d27c23a 100644 --- a/drivers/media/video/uvc/uvc_video.c +++ b/drivers/media/video/uvc/uvc_video.c @@ -1597,7 +1597,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; } -- 1.7.3.4 > 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. -- 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
