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. Is it possible that something in parallel just fast enough to free the allocated resource from pool? -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- 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
