Re: usb HC busted?

[Mathias Nyman <mathias.nyman-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

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