On Thu, 11 Jul 2013, Devin Heitmueller wrote: > It looks like I may have created some confusion by attempting to > correlate the usbmon trace against the Beagle data. I've got two > environments I'm debugging on: an x86 box with the stock Intel EHCI > HCD, and a Davinci TI8147 ARM system which has the musb HCD. Because > I was seeing what visually looks like identical behavior on both > platforms, I had been actively going back and forth between them > during debugging. In this case, the Beagle trace was collected > against the Davinci board but the usbmon traces were collected against > the x86 system. Aha. Well, that's a relief -- now we don't have to worry about how the computer received data that the device didn't send. > Looking closer at the Beagle trace on the x86 system -- while there > aren't 250us gaps prior to the corruption, there *is* a delay between > the SOF and the IN packet on the order of 30-50us. This is present in > all instances where there is corruption, and in all other cases the IN > packet occurs within 1us of the SOF. In theory, delays of this sort are not supposed to matter. USB makes no guarantees about _when_ in the microframe an isochronous transfer will occur. It could be at the very start of one microframe and the very end of the next one. Devices are supposed to be able to cope with this sort of variation. > I suspect we've got the same basic issue on both platforms where there > is a delay between SOF and the IN packet, but the x86 system is so > much faster than the ti8147 platform that there's still time to grab > the microframe within the frame interval (albeit delayed), while on > the 8147 platform the HCD skips the microframe entirely (the HCD is > expected to skip a microframe if it concludes that it would not be > finished before the next SOF). The musb hardware is much crankier and more difficult to work with than EHCI. It's not at all surprising that small delays could get magnified. > Because of the difference in behavior between x86 and ti1847, I > figured it would be a worthwhile exercise to go back to the 8147 > platform and apply the ISO_ASAP fix that Alan mentioned yesterday, as > well as a fix for an incorrect spin_lock() call which I had tried on > the x86 box but hadn't yet applied to my 8147 tree (which out of dumb > luck, Ming Lei happened to submit a patch for this morning as well). > > http://www.mail-archive.com/linux-usb@xxxxxxxxxxxxxxx/msg24178.html Using spin_lock() is not incorrect with the current kernel. But it will be wrong in the future. The ISO_ASAP thing won't make any difference in your setting. It matters only when the pipeline length is quite low (on the order of 1 ms), but yours is 40 ms. You may just as well leave it turned on all the time. > The ISO_ASAP change had no visible effect on the URB handling. > However the change from spin_lock() to spin_lock_irqsave() had a > unexpectedly *huge* effect. Now essentially every frame is corrupted > and it would appear that the system can no longer keep up with the > stream. It's not clear to me why this would cause any change in > behavior. Probably also worth noting that with that change, I was not > getting *multiple* microframes being skipped (e.g. 250, 500, 750us > gaps), at a much higher frequency than before. Very bizarre. > Another strange thing: If I change the completion handler on the 8147 > to comment out the actual processing of the URB (such that all the > completion handler does is resubmit the URB), the problem disappears. > The isoc stream as captured by the Beagle shows no video corruption, > and no 250us gaps. If I were to speculate, I think this might be > either because I've reduced the overall load on the system (not only > is the URB handler not actually doing anything, but the userland code > which process the video is no longer receiving frames), or > alternatively the URB completion handler takes such a long time to > execute that it actually prevents the hardware from sending out > microframes (due to raw CPU load, the fact it's happening in interrupt > context, or because of some shared lock). The musb driver makes much greater demands on the CPU than the EHCI driver, relative to the different CPU speeds. Reducing the total load on the ti8147 thus could significantly improve the performance. > No clear conclusions based on all of this, other than that I really > need to independently debug on the x86 versus the TI8147 platform, as > they are not in fact behaving in the same manner (despite both of them > showing essentially the same symptoms in terms of the appearance of > the video). The question becomes: Why would the packets be delayed with EHCI? One possible reason is that there is other activity on the USB bus. But it would have to be isochronous too, and in any case I imagine you don't have any other ongoing activity while running the tests. The only other explanation I can think of is memory/PCI bus contention. 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
