On Wed, 14 Jul 2010, Alessio Sangalli wrote: > On 05/28/2010 08:08 AM, Alan Stern wrote: > > > Try running a test: Use usbmon to see what gets sent to and from the > > memory stick both with and without your change in place. Instructions > > are in Documentation/usb/usbmon.txt. > > > >> Any idea what could be that triggers this problem? Please note, the > >> problem is present only if I attach a hub; without hubs everything's > >> fine (but 2.6.19 was working even with hubs) > > > > No, I have no idea. Nor can I imagine why having a hub might make a > > difference. > > So I did several tests with a friend that know how to use a hardware > "trace" tool that gave a lot of interesting information. Bottom line, it > happens that: > > - ehci_watchdog() gets called by a timer > - interrupt processing is disabled completely with spin_lock_irqsave() > - ehci_work() gets executed > - interrupts are enabled again > > I found out that: > 1) when an empty hub is inserted, ehci_watchdog() gets called several > times per second > 2) the execution of ehci_work() very often takes close to one > millisecond, and this creates the problem with my other device that > needs to be fed very quickly. A good part of this time, up to 20-30%, is > taken by the code that performs arithmetic divisions! Do you know exactly which code that is? Maybe the divisions can be removed or simplified. For example, see http://marc.info/?l=linux-usb&m=127911981822386&w=2 > 3) I tried to disable only the EHCI interrupt instead of global, and > this seems to fix the issue, but I am not sure there are no side effects. > > So I have a couple of questions: > 1) why is ehci_watchdog() even called? I would think EHCI operations to > be fully interrupt-driven. So would I. However some EHCI hardware is buggy and requires the watchdog interrupt in order to run correctly. In recent kernels it is possible to turn off the watchdog interrupt for controllers that are known to be good. See the references to ehci->need_io_watchdog in ehci-pci.c:ehci_pci_setup(). > 2) is it really necessary to keep global interrupts disabled for so long > during ehci_work? I feel there is something wrong here. Yes, it is necessary. Otherwise an interrupt could cause some other driver to submit or cancel an URB while ehci_work is busy, leading to data corruption or a system hang. > Also, I reported on 2.6.19 I did not have this problem; it is due to the > fact that on that version ehci_work() is slightly (50-100us) faster and > does not show the problem, but everything else I mentioned still happens > on that version too. If your system is this sensitive to timing issues then perhaps you should be using a kernel with the Real-Time extensions instead of a vanilla kernel. 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
