Dear Alan, in this e-mail that you mentioned below: linux 2.6.30 has bug, it can not check wrong schedule index for re-submit urb. But today we do the verification: We measure CPU cycles for : 1. decode function in UVC complete call back function 2. big for loop in scan_periodic We compare the result between 2.6.30 and update code we used. UVC driver is the same, the big difference is A: 2.6.30: NO any update for USB subsystem and usb host driver B: update code we used : included ehci schedule patch up to 2.6.39 and we disable "printk" when submit urb error in iso_stream_schedule() and complete call back function, since that will cause cpu cycle inaccuracy. ================================================= Result: in CPU cycle: we do not find any strange. becasue we save some data to array, then dump data by command. and both code does not trigger the threshold that we set to treat error case. it means : decode function in UVC driver and scan_periodic do not cause long irq latency, when we use Code B for testing, IP cam is dissconnect but the error case do not triggered. ========================================================== it seems the irq latency is not cause. The cause mybe the check rule for schedule index. it seems something wrong about maintenance of iso schedule index in new ehci code. Do you have any idea? Thanks a lot ! best Regards, Soho 2011/5/27 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Thu, 26 May 2011, Soho Soho123 wrote: > >> Dears, >> >> >> Let me ask the question more detail below. >> >> 1. So linux 2.6.30 has bug, "it can work over night" is wrong. > > Yes. > >> 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? > > Yes. If you use usbmon (see Documentation/usb/usbmon.txt) you'll see > exactly when each URB is submitted and when it completes. > >> 3. do you have any suggestion for work around ? > > Start with usbmon to make sure my analysis is correct. Then try to > figure out what part of your system is responsible for the high > interrupt latency and fix it. > > Another thing to try is applying commit > 1e12c910eed82da6971f1c0421a069c680faba2e (EHCI: don't rescan interrupt > QHs needlessly) from the USB development tree: > > https://git.kernel.org/?p=linux/kernel/git/gregkh/usb-2.6.git;a=commitdiff;h=1e12c910eed82da6971f1c0421a069c680faba2e > > That was specifically intended to help reduce latency. > > You can also try increasing the number of URBs to 32. But that's not > going to do anything about the source of the problem. > > 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
