Re: ehci_hcd / uvcvideo bug

[Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>]

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