usb HC busted?

On 21.06.2018 03:53, Sudip Mukherjee wrote:

Hi Mathias, Andy,

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

quoted

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>

quoted

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?

I tried to reproduce it by quickly hacking xhci to allocate and free 50 segments each time
we normally allocate one segment from dmapool.
I let it run for 3 days on a Atom based platform, but could not reproduce it.

xhci testhack can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git dmapool-test
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=dmapool-test

Tested by just leaving the following running for a few days:

while true; do echo 0 > authorized; sleep 3; echo 1 > authorized; sleep 3; done;
For some usb device (for example: /sys/bus/usb/devices/1-8)

Then grep logs for "MATTU dmatest match! "

Can you share a bit more details on the platform you are using, and what types of test you are running.
Does my test above trigger the case? (show "MATTU dmatest match!")

-Mathias
---
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