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:
On 06.06.2018 19:45, Sudip Mukherjee wrote:
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()
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?
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
