usb HC busted?

Hi Mathias, Andy,

On Thu, Jun 07, 2018 at 10:40:03AM +0300, Mathias Nyman wrote:

On 06.06.2018 19:45, Sudip Mukherjee wrote:

quoted

Hi Andy,

And we meet again. :)

On Wed, Jun 06, 2018 at 06:36:35PM +0300, Andy Shevchenko wrote:

quoted

On Wed, 2018-06-06 at 17:12 +0300, Mathias Nyman wrote:

quoted

On 04.06.2018 18:28, Sudip Mukherjee wrote:

quoted

On Thu, May 24, 2018 at 04:35:34PM +0300, Mathias Nyman wrote:

quoted

quoted

Odd and unlikely, but to me this looks like some issue in allocating
dma memory
from pool using dma_pool_zalloc()


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.

Sudip has a full (394M unpacked) trace at:
https://drive.google.com/open?id=1h-3r-1lfjg8oblBGkzdRIq8z3ZNgGZx-

<snip>

But then it gets stuck, for the whole ring2 dma_pool_zalloc() just returns the same dma address as the last segment for
ring1:0x2d92b000. Last part of trace snippet is just another ring being freed.

A gentle ping on this. Any idea on what the problem might be and any
possible fix?
---
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