Dear Alan, We test again with 2 case: Case 1: without WiFi, just using ethernet interface for IP cam test. result: It can work for over night. hence, we may focus on WiFi driver. Case 2: we modify WiFi driver in TX direction. the function netdev->hard_xmit() originally, the function use:spin_lock_irqsave and spin_unlock_irqrestore for protection We modify the code : using spin_lock_irq and spin_unlock_irq to replace the original code. Then, the result is better. At least we can see IP cam can work for several hours. As we have known, in case 2, spin_lock_irq and spin_unlock_irq may cause irq loss, but it seems usb and wifi can work more smooth. It seems the "irq count" is the cause of problem from the testing Case 1 &2. Since irq from WiFi is very much in the testing. if the Irq is so busy in the system that WiFi has included, then "usb irq will not be service at once" is sure. Do you have any idea? And the question from Laurent, ."If the URB is resubmitted too late, why can't it just be queued for the next (micro-)frame " Thanks a lot best Regards, Soho 2011/6/6 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Sun, 5 Jun 2011, Soho Soho123 wrote: > >> 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. > > It's quite possible that the WiFi driver is responsible for your > problem. Can you run a test with that driver not present? > >> 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. > > If you find the source of the problem, it would be nice to know. > Maybe you can post an email with a full explanation after you have the > solution. > >> It is very sorry to bother you form long time. > > That's okay; I enjoy solving problems. > >> 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? > > Yes, of course. > >> Thanks again!! > > You're welcome. > > 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
