usb HC busted?

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, 2018-06-06 at 17:12 +0300, Mathias Nyman wrote:
> On 04.06.2018 18:28, Sudip Mukherjee wrote:
> > On Thu, May 24, 2018 at 04:35:34PM +0300, Mathias Nyman wrote:
> > > 

> Odd and unlikely, but to me this looks like some issue in allocating
> dma memory
> from pool using dma_pool_zalloc()
> 
> Adding people with DMA knowledge to cc, maybe someone knows what is
> going on.
> 
> Here's the story:
> Sudip sees usb issues on a Intel Atom based board with 4.14.2 kernel.
> All tracing points to dma_pool_zalloc() returning the same dma address
> block on
> consecutive calls.
> 
> In the failing case dma_pool_zalloc() is called 3 - 6us apart.
> 
> <...>-26362 [002] ....  1186.756739: xhci_ring_mem_detail: MATTU
> xhci_segment_alloc dma @ 0x000000002d92b000
> <...>-26362 [002] ....  1186.756745: xhci_ring_mem_detail: MATTU
> xhci_segment_alloc dma @ 0x000000002d92b000
> <...>-26362 [002] ....  1186.756748: xhci_ring_mem_detail: MATTU
> xhci_segment_alloc dma @ 0x000000002d92b000
> 
> dma_pool_zalloc() is called from xhci_segment_alloc() in
> drivers/usb/host/xhci-mem.c
> see:
> https://elixir.bootlin.com/linux/v4.14.2/source/drivers/usb/host/xhci-
> mem.c#L52
> 
> prints above are custom traces added right after dma_pool_zalloc()

For better understanding it would be good to have dma_pool_free() calls
debugged as well.

Is it possible that something in parallel just fast enough to free the
allocated resource from pool?