On Tue, 7 Jun 2011, Soho Soho123 wrote: > 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 may lead to problems, though. spin_unlock_irq() may enable interrupts at a time when they are supposed to remain disabled. > 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? No, not really. You might want to post a question to people on the linux-wireless mailing list. > And the question from Laurent, > ."If the URB is resubmitted too late, why can't it just be queued for > the next (micro-)frame " We _do_ queued it for the next microframe. But if the URB is resubmitted _too_ late (i.e., more than 20 ms too late) then ehci-hcd doesn't realize the URB is late -- it thinks the URB is very early! For example, suppose there are 512 frames in the periodic schedule. Suppose the last URB ended in frame 500, so the next available slot is frame 501. But suppose the next URB was submitted 40 ms too late, and the current frame number is already 28 ( = 500 + 40 mod 512). Then ehci-hcd thinks the URB was submitted 473 ( = 501 - 28) frames early, not 40 frames late. That's why you get errors. 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
