Dear Alan, Haha,, Thanks a lot first for your parse!! By your opinion, it seems the another part cause ehci irq can not service at once. We will check other driver, like WiFi , etc. in advance. The target is: Create a WiFi Cam product with Linux OS. In our system have other driver for networking, ethernet , WiFi. Usb is necessary for usb application, network driver is also necessary for Router, but when IP Cam application is required, then both USB and network driver will working simultaneously . The WiFi Router function was ready for a long time in our system. USB application was added recently, when the issue has reported, we think that maybe the problem from usb sub-system. In the next , we will invoke the other people that are skill in the driver field for the issue. It is very sorry to bother you form long time. it is very appreciate for your help, that give us the hints for usb ehci discussing. And if it necessary, can we send you e-mail about usb ehci question in the future? Thanks again!! Best Regards, Soho 2011/6/5 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Sat, 4 Jun 2011, Soho Soho123 wrote: > >> Dear Alan,, >> >> the attached is test log. > > This is very good. It shows clearly that the problem does not lie in > either the ehci-hcd scheduling code or uvcvideo. > > The "where 1" lines get printed every time scan_periodic() starts, > which happens every time the EHCI controller generates an interrupt. > Since the video URBs contain 32 iso packet descriptors with period 1, > you get an interrupt every 32 microframes. > > Here are the last 20 "where 1" lines in the log file: > > [ 52.510000] stat[1730]: now_uframe 608 clock 638 where 1 cycles 1422490 > [ 52.510000] stat[1771]: now_uframe 640 clock 670 where 1 cycles 1353017 > [ 52.510000] stat[1812]: now_uframe 672 clock 702 where 1 cycles 1366230 > [ 52.510000] stat[1853]: now_uframe 704 clock 734 where 1 cycles 1366945 > [ 52.510000] stat[1894]: now_uframe 736 clock 766 where 1 cycles 1362202 > [ 52.510000] stat[1935]: now_uframe 768 clock 798 where 1 cycles 1350501 > [ 52.510000] stat[1976]: now_uframe 800 clock 830 where 1 cycles 1320953 > [ 52.510000] stat[2017]: now_uframe 832 clock 862 where 1 cycles 1184474 > [ 52.510000] stat[2058]: now_uframe 864 clock 894 where 1 cycles 1409951 > [ 52.510000] stat[2099]: now_uframe 896 clock 926 where 1 cycles 1327215 > [ 52.510000] stat[2140]: now_uframe 928 clock 958 where 1 cycles 1330450 > [ 52.510000] stat[2181]: now_uframe 960 clock 990 where 1 cycles 1343450 > [ 52.510000] stat[2222]: now_uframe 992 clock 1022 where 1 cycles 1356164 > [ 52.510000] stat[2263]: now_uframe 1024 clock 1054 where 1 cycles 1306609 > [ 52.510000] stat[2304]: now_uframe 1056 clock 1086 where 1 cycles 1338844 > [ 52.510000] stat[2345]: now_uframe 1088 clock 1118 where 1 cycles 1261811 > [ 52.510000] stat[2386]: now_uframe 1120 clock 1150 where 1 cycles 1345394 > [ 52.510000] stat[2427]: now_uframe 1152 clock 1182 where 1 cycles 1371405 > [ 52.510000] stat[2468]: now_uframe 1184 clock 1214 where 1 cycles 1350546 > [ 52.510000] stat[2509]: now_uframe 1216 clock 1567 where 1 cycles 17006763 > > You can see that now_uframe and clock both go up by 32 each time > through -- except the last, where clock goes up by 353. Likewise, the > cycle count is about 1340000 each time, except the last where it is 12 > times larger. > > This means something in the system prevented the interrupt from being > delivered when it should have been. The interrupt was handled 353 - 32 > = 321 microframes too late, so some part of the kernel blocked the > interrupt for over 40 ms! That's why you see such a huge latency. > > There's no way to tell from this what part of the kernel was > responsible. It wasn't uvcvideo; we know that from the cycle counts. > It almost certainly wasn't ehci-hcd either. It must have been some > other driver, but I don't know how to tell which. > > What else was running on the system while you carried out the test? > > 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
