Hi Alan, Thanks for taking the time to provide feedback. I'm just noticing now that I left off the subject line, which all the more reason makes me thankful that you bothered to read an email with as uninteresting a subject line as is possible. :-) On Tue, Jul 2, 2013 at 11:21 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > That's weird. But it might not be the scheduler so much; it could be > related more to the total CPU load. Sorry, I didn't mean to suggest the scheduler itself was at fault - just that the high context switching may be changing the timing in a way that exposes a missing spinlock in usb core or increases the likelihood that a call that is sleepable is taking the path of the context switch. >> The problem has been seen on both the stock EHCI driver (on x86) as >> well as the musb driver used on the TI Davinci platform (ARM). The >> transfer buffer itself is being allocated using usb_alloc_coherent(), >> and I've seen it when allocating with vmalloc() as well. > > Do you mean kmalloc()? Memory allocated with vmalloc() is generally > not suitable for DMA mapping. Yeah, typo. Sorry. >> This feels like some sort of DMA or cache related issue, since the >> behavior of the URB completion handler itself appears completely >> consistent regardless of the system load. I'm seeing the issue on >> 3.10-rc6 all the way back to 2.6.31 (the earliest I can go on my >> Ubuntu box given some udev related dependencies). >> >> I've done plenty of work on USB drivers under Linux over the years, >> but haven't dug too much into the USB core. Anybody who has any >> suggestions on how to debug such a timing problem, such suggestions >> would be very welcomed. > > This is an interesting problem, but I don't think you'll get much > insight from looking at the USB side of things. You could try asking > the people in charge of the DMA- and cache-related parts of the kernel. I finally dug out my Beagle 480 USB, so I will get that hooked up this week, write a decoder to reassemble the video frames based on the USB trace, and know once and for all whether the device is delivering correct video or not. If the video being delivered by the device has no corruption, then we're talking about some sort of memory consistency or DMA issue (or perhaps some sort of problem with the USB core populating the finished URBs before calling the completion handler). If the video coming down the bus is corrupted, then we're probably talking about some sort of timing problem with the URB submission (combined with the FIFO on the chip poorly handling the incorrect timing). Anyway, thanks for your suggestions. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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
