On Wed, 1 Jun 2011, Soho Soho123 wrote: > Dear Alan, > > > We have questions: > We still do not get unstanding about :why we get -FEBIG error when uvc > driver re-submit urb yet. > Because we try to use another platform that CPU is faster. The error > is still occur. > And,the amount of URB is 5 totally. > the another platform : CPU 620MHz, RAM 64MB Do you still see "now" > stream->next_uframe + 160? > if each urb must use 5 iTDs, then totally 25 iTDs will be occupied in > schedule list. The max schedule list is also large enough for that. > And the new urb will be submit when the previous urb had complete. > it is strange why urb submit is too late: in iso_stream_schedule() > start - now is negative > Do you have idea? Look at an example you posted earlier: [1943592448] iso_stream_schedule:line=1514, request 81631800 would overflow (3908+31 >= 3936) [1943592448] iso_stream_schedule [1943592448] mod=4096, span=32 [1943592448] now=1195 [1943592448] start=5103 [1943592448] next=1195 [1943592448] period=1 [1943592448] excess=3907 [1943592448] stream->next_uframe=1007 [1943592448] uvcvideo: Failed to resubmit video URB (-27). This means that the last URB ended in microframe 1006. The URB being submitted should start in microframe 1007. But "now" indicates that the current microframe is 1195, so the URB was submitted 188 microframes late! That's more than 23 ms after the previous URB completed, so you have an interrupt latency of 23 ms or more. > About the precision of timestamp that I post from usbmon. > the precision is in microsecond, do you mean nano is needed, right? No. Look at the timestamps; you'll see that even though the times printed are in microseconds, the last four digits are always 2448. (That's also true in the log messages above.) This means the actual precision is only 10 ms. 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
