On Tue, 15 Oct 2013, Marcus Overhagen wrote: > On Tue, Oct 15, 2013 at 6:07 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > Why does the driver make this mistake? > > My initial assumption was wrong, the driver doesn't infrequently poll, but > does so more often. I was misled by the confusing source. > However, I now made usbmon traces and analyzed them with LibreOffice. > > During data transfer, the driver does a interrupt transfer about 48ms after > the last one, and has to wait about 15ms for the result. But every 40 transfers, > it executes 3 transfers without waiting inbetween and has to wait 63ms for the > result. This is with transfer interval set to 10 on xhci. > I also compiled the driver with transfer interval set to 1 (the > original setting before > my patch [1]), but the result is similar, an interrupt transfer every > 44ms, and waiting > of 19ms for the result. I don't have ehci hardware to test it. > > When the URB completition callback is executed, it calles complete(), > while the driver > is using wait_for_completion_interruptible_timeout() for this signal > with 100ms timeout > (originally that was 50ms but I changed it in patch [2] to make it > work with xhci) > > This function seems to timeout on ehci hardware after about 700MB to > 7GB transfered. > > I guess that the thread isn't scheduled fast enough under load, although the USB > transfer was successful. That could be the explanation. It would also explain why increasing the timeout fixes the problem. > > bInterval = 10 means the polling period is 64 ms (for a high-speed > > device). So a timeout of 100 ms should be adequate -- provided the > > device always sends data over the interrupt endpoint without any > > further delay. > > What i do not understand: with ehci hardware, the driver works when > interval in the urb is set to 1 and the timeout is 50ms. > > With xhci, the urb appears to be scheduled not more often then every > 64ms even if the interval in the urb is set to 1. This is because ehci-hcd pays attention to urb->interval whereas xhci-hcd ignores it. > I'm just looking for the correct solution for this issue. Here's a suggestion: Have the URB's completion routine set a new flag somewhere. When the wait_for_completion_interruptible_timeout() call returns, check whether the new flag is set instead of checking whether a timeout occurred. 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
