Dears, Let me ask the question more detail below. 1. So linux 2.6.30 has bug, "it can work over night" is wrong. 2. the meaning of yours is uvc video driver submit new urb too late, right? but as my understand, the new urb is submited when the urb has complete. so, the time for urb complete is too long, right? the time duration for ehci irq service function to finish is too long, right? Or, ehci irq service function can not be run due to CPU resource has been occupied by other device, right? 3. do you have any suggestion for work around ? Thanks a lot ! Best Regards, Soho ================================================================= 2011/5/26 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 26 May 2011, Soho Soho123 wrote: > >> Dears, >> >> let me describe the detail about my testing: >> Stream Server is MJPG-Streamer >> ================================================================ >> A. >> Using linux 2.6.30 kernel do the testing, and DO NOT update linux usb >> subsystem code (usb core , usb host driver), and DO NOT update UVC >> driver >> >> RESULT: IP Cam stream can work over night > > This is because the code in 2.6.30 is buggy. It should have stopped > with an error, but it didn't. > >> ------------------------------------------------------------------------------------------------------------------------------ >> B. >> Using Linux 2.6.30 kernel do the testing, and Update linux usb >> subsystem code up to linux 2.6.39 (include the patch that I have >> mentioned) and DO NOT update UVC driver >> >> RESULT: IP cam stream can work for a few minutes only, then UVC driver >> will get submit urb error (-27) , error message list below: >> # [ 1067.188000] iso_stream_schedule:line=1514, request 812acc00 would >> overflow (3914+31 >= 3936) >> [ 1067.188000] uvcvideo: Failed to resubmit video URB (-27). >> [ 1067.192000] iso_stream_schedule:line=1514, request 8145bc00 would >> overflow (3917+31 >= 3936) >> [ 1067.192000] uvcvideo: Failed to resubmit video URB (-27). >> [ 1067.292000] iso_stream_schedule:line=1514, request 81769000 would >> overflow (3919+31 >= 3936) >> [ 1067.292000] uvcvideo: Failed to resubmit video URB (-27). >> [ 1067.392000] iso_stream_schedule:line=1514, request 81769400 would >> overflow (3918+31 >= 3936) >> [ 1067.392000] uvcvideo: Failed to resubmit video URB (-27). >> [ 1067.492000] iso_stream_schedule:line=1514, request 81769800 would >> overflow (3917+31 >= 3936) >> [ 1067.492000] uvcvideo: Failed to resubmit video URB (-27). > > This happens because the uvcvideo driver is falling behind. It is > submitting new isochronous URBs too late -- more than 20 ms after the > previuos isochronous URB finished. > >> ------------------------------------------------------------------------------------------------------------------------------- >> C. >> Using Linux 2.6.30 kernel do the testing, and Update linux usb >> subsystem code up to linux 2.6.39 (include the patch that I have >> mentioned) and Update UVC driver, we modify the number of URBs in >> vuvcideo.h >> UVC_URBS 5 >> to >> UVC_URBS 20 >> >> RESULT: IP cam stream can work for over night, but there is some urb >> submit error occur. The stream can keep working even the urb submit >> error. > > This is because now there is more room for latency. The real problem > is that uvcvideo needs to submit new URBs periodically, but on your > system it was delayed by 20 ms. In other words, something on your > system is causing interrupt latencies that are several tens of > milliseconds. > >> ================================================================ >> We would like to figure out the reason about new usb subsystem code >> need more UVC_URB for working long time.Coule you provide the hints >> for us, such that we can go in depth for tracing the flow in ehci iso >> schedule scheme? > > >> the error log is : >> ========================================================== >> 474.348000] iso_stream_schedule:line=1514, request 8176bc00 would overflow (3936+31 >= 3936) >> [ 474.348000] iso_stream_schedule >> [ 474.348000] mod=4096, sched->span=32 > > You should look at span, not sched->span. You should also look at > stream->next_uframe. > >> [ 474.348000] now=773 >> [ 474.348000] start=4709 >> [ 474.348000] next=773 >> [ 474.348000] period=1 >> [ 474.348000] uvcvideo: Failed to resubmit video URB (-27). >> [ 474.352000] iso_stream_schedule:line=1514, request 8176b000 would overflow (3932+31 >= 3936) >> [ 474.352000] iso_stream_schedule >> [ 474.352000] mod=4096, sched->span=32 >> [ 474.352000] now=784 >> [ 474.352000] start=4716 >> [ 474.352000] next=784 >> [ 474.352000] period=1 >> [ 474.352000] uvcvideo: Failed to resubmit video URB (-27). >> ========================================================== >> it seems the index of schedule list is corrupt, right? > > No. The schedule list is correct. > > In iso_stream_schedule(), "now" is the current microframe, and "next" > is the earliest microframe a new URB can be added to. "mod" is the > length of the schedule. > > You didn't print out the value of "excess", but I figure it was 3935 > for the first URB and 3931 for the second. "excess" is the how many > microframes will pass before the currently scheduled URBs are finished. > Values greater than 4096 - 160 = 3936 are taken to be negative numbers > modulo 4096 (i.e., they indicate the currently scheduled URBs are > _already_ finished). > > In your case, it looks like the currently scheduled URBs are indeed > already finished, but more than 160 microframes ago since 3935 and > 3931 are both less than 3936. > > 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
