usb HC busted?

[Sudip Mukherjee <sudipm.mukherjee@gmail.com>]

Hi Andy,

And we meet again. :)

On Wed, Jun 06, 2018 at 06:36:35PM +0300, Andy Shevchenko wrote:
> 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.

So, I am adding another trace event for dma_pool_free() and continuing
with the test. Is there anything else that I should be adding as debug?
---
Regards
Sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html