On Wed, 20 Jun 2012, Ming Lei wrote:
> 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;
> }
Yes, that definitely looks like a bug. It could be responsible for the
wrong packet lengths, although I can't tell from the information in the
bug report.
> But the bug may not relate with the above.
>
> Probably it is caused by mistaken intf->num_altsetting of 12, instead of
> 13.
How do you know intf->num_altsetting was set to 12?
> Also from the usbmon trace, all packets are completed with length of 12,
> which indicates that there aren't capture data at all.
Maybe there wasn't supposed to be any. Anyway, that's a separate
problem.
> > 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.
What is the irqsoff tracer?
Alan Stern
--
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
