On Thursday 17 January 2013, Soeren Moch wrote:

quoted

On 17.01.2013 11:49, Arnd Bergmann wrote:

quoted

On Wednesday 16 January 2013, Soeren Moch wrote:

quoted

quoted

quoted

I will see what I can do here. Is there an easy way to track the buffer
usage without having to wait for complete exhaustion?

DMA_API_DEBUG

OK, maybe I can try this.

quoted

Any success with this? It should at least tell you if there is a
memory leak in one of the drivers.

Not yet, sorry. I have to do all the tests in my limited spare time.
Can you tell me what to search for in the debug output?

Actually now that I've looked closer, you can't immediately see
all the mappings as I thought.

But please try enabling DMA_API_DEBUG in combination with this
one-line patch:

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..3df74ac 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c

@@ -497,6 +497,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
  		pr_err_once("ERROR: %u KiB atomic DMA coherent pool is too small!\n"
  			    "Please increase it with coherent_pool= kernel parameter!\n",
  			    (unsigned)pool->size / 1024);
+		debug_dma_dump_mappings(NULL);
  	}
  	spin_unlock_irqrestore(&pool->lock, flags);

That will show every single allocation that is currently active. This lets
you see where all the memory went, and if there is a possible leak or
excessive fragmentation.

	Arnd