linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
@ 2012-11-08  6:38 Marek Szyprowski
  2012-11-11 17:22 ` Andrew Lunn
  2012-11-19  0:18 ` Jason Cooper
  0 siblings, 2 replies; 59+ messages in thread
From: Marek Szyprowski @ 2012-11-08  6:38 UTC (permalink / raw)
  To: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel
  Cc: Marek Szyprowski, Kyungmin Park, Arnd Bergmann, Soren Moch,
	Thomas Petazzoni, Sebastian Hesselbarth, Andrew Lunn

dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
the flags provided by the caller. This causes excessive pruning of
emergency memory pools without any good reason. This patch changes the code
to correctly use gfp flags provided by the dmapool caller. This should
solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
allocations can be served only from the special, very limited memory pool.

Reported-by: Soren Moch <smoch@web.de>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 mm/dmapool.c |   27 +++++++--------------------
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..86de9b2 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -62,8 +62,6 @@ struct dma_page {		/* cacheable header for 'allocation' bytes */
 	unsigned int offset;
 };
 
-#define	POOL_TIMEOUT_JIFFIES	((100 /* msec */ * HZ) / 1000)
-
 static DEFINE_MUTEX(pools_lock);
 
 static ssize_t
@@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)
 		memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
 #endif
 		pool_initialise_page(pool, page);
-		list_add(&page->page_list, &pool->page_list);
 		page->in_use = 0;
 		page->offset = 0;
 	} else {
@@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 	might_sleep_if(mem_flags & __GFP_WAIT);
 
 	spin_lock_irqsave(&pool->lock, flags);
- restart:
 	list_for_each_entry(page, &pool->page_list, page_list) {
 		if (page->offset < pool->allocation)
 			goto ready;
 	}
-	page = pool_alloc_page(pool, GFP_ATOMIC);
-	if (!page) {
-		if (mem_flags & __GFP_WAIT) {
-			DECLARE_WAITQUEUE(wait, current);
 
-			__set_current_state(TASK_UNINTERRUPTIBLE);
-			__add_wait_queue(&pool->waitq, &wait);
-			spin_unlock_irqrestore(&pool->lock, flags);
+	/* pool_alloc_page() might sleep, so temporarily drop &pool->lock */
+	spin_unlock_irqrestore(&pool->lock, flags);
 
-			schedule_timeout(POOL_TIMEOUT_JIFFIES);
+	page = pool_alloc_page(pool, mem_flags);
+	if (!page)
+		return NULL;
 
-			spin_lock_irqsave(&pool->lock, flags);
-			__remove_wait_queue(&pool->waitq, &wait);
-			goto restart;
-		}
-		retval = NULL;
-		goto done;
-	}
+	spin_lock_irqsave(&pool->lock, flags);
 
+	list_add(&page->page_list, &pool->page_list);
  ready:
 	page->in_use++;
 	offset = page->offset;
@@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 #ifdef	DMAPOOL_DEBUG
 	memset(retval, POOL_POISON_ALLOCATED, pool->size);
 #endif
- done:
 	spin_unlock_irqrestore(&pool->lock, flags);
 	return retval;
 }
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-08  6:38 [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Marek Szyprowski
@ 2012-11-11 17:22 ` Andrew Lunn
  2012-11-12  9:48   ` Soeren Moch
  2012-11-19  0:18 ` Jason Cooper
  1 sibling, 1 reply; 59+ messages in thread
From: Andrew Lunn @ 2012-11-11 17:22 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn

On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the caller. This causes excessive pruning of
> emergency memory pools without any good reason. This patch changes the code
> to correctly use gfp flags provided by the dmapool caller. This should
> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
> allocations can be served only from the special, very limited memory pool.
> 
> Reported-by: Soren Moch <smoch@web.de>
> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>

Tested-by: Andrew Lunn <andrew@lunn.ch>

I tested this on a Kirkwood QNAP after removing the call to
init_dma_coherent_pool_size().

	Andrew


> ---
>  mm/dmapool.c |   27 +++++++--------------------
>  1 file changed, 7 insertions(+), 20 deletions(-)
> 
> diff --git a/mm/dmapool.c b/mm/dmapool.c
> index c5ab33b..86de9b2 100644
> --- a/mm/dmapool.c
> +++ b/mm/dmapool.c
> @@ -62,8 +62,6 @@ struct dma_page {		/* cacheable header for 'allocation' bytes */
>  	unsigned int offset;
>  };
>  
> -#define	POOL_TIMEOUT_JIFFIES	((100 /* msec */ * HZ) / 1000)
> -
>  static DEFINE_MUTEX(pools_lock);
>  
>  static ssize_t
> @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)
>  		memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
>  #endif
>  		pool_initialise_page(pool, page);
> -		list_add(&page->page_list, &pool->page_list);
>  		page->in_use = 0;
>  		page->offset = 0;
>  	} else {
> @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
>  	might_sleep_if(mem_flags & __GFP_WAIT);
>  
>  	spin_lock_irqsave(&pool->lock, flags);
> - restart:
>  	list_for_each_entry(page, &pool->page_list, page_list) {
>  		if (page->offset < pool->allocation)
>  			goto ready;
>  	}
> -	page = pool_alloc_page(pool, GFP_ATOMIC);
> -	if (!page) {
> -		if (mem_flags & __GFP_WAIT) {
> -			DECLARE_WAITQUEUE(wait, current);
>  
> -			__set_current_state(TASK_UNINTERRUPTIBLE);
> -			__add_wait_queue(&pool->waitq, &wait);
> -			spin_unlock_irqrestore(&pool->lock, flags);
> +	/* pool_alloc_page() might sleep, so temporarily drop &pool->lock */
> +	spin_unlock_irqrestore(&pool->lock, flags);
>  
> -			schedule_timeout(POOL_TIMEOUT_JIFFIES);
> +	page = pool_alloc_page(pool, mem_flags);
> +	if (!page)
> +		return NULL;
>  
> -			spin_lock_irqsave(&pool->lock, flags);
> -			__remove_wait_queue(&pool->waitq, &wait);
> -			goto restart;
> -		}
> -		retval = NULL;
> -		goto done;
> -	}
> +	spin_lock_irqsave(&pool->lock, flags);
>  
> +	list_add(&page->page_list, &pool->page_list);
>   ready:
>  	page->in_use++;
>  	offset = page->offset;
> @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
>  #ifdef	DMAPOOL_DEBUG
>  	memset(retval, POOL_POISON_ALLOCATED, pool->size);
>  #endif
> - done:
>  	spin_unlock_irqrestore(&pool->lock, flags);
>  	return retval;
>  }
> -- 
> 1.7.9.5
> 

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-11 17:22 ` Andrew Lunn
@ 2012-11-12  9:48   ` Soeren Moch
  2012-11-12 10:38     ` Andrew Lunn
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2012-11-12  9:48 UTC (permalink / raw)
  To: Andrew Lunn, Marek Szyprowski
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Thomas Petazzoni,
	Sebastian Hesselbarth

On 11.11.2012 18:22, Andrew Lunn wrote:
 > On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
 >> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, 
regardless
 >> the flags provided by the caller. This causes excessive pruning of
 >> emergency memory pools without any good reason. This patch changes 
the code
 >> to correctly use gfp flags provided by the dmapool caller. This should
 >> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
 >> allocations can be served only from the special, very limited memory 
pool.
 >>
 >> Reported-by: Soren Moch <smoch@web.de>
Please use
Reported-by: Soeren Moch <smoch@web.de>

 >> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
 >
 > Tested-by: Andrew Lunn <andrew@lunn.ch>
 >
 > I tested this on a Kirkwood QNAP after removing the call to
 > init_dma_coherent_pool_size().
 >
 >     Andrew

Tested-by: Soeren Moch <smoch@web.de>

Now I had a chance to test this patch on my Kirkwood guruplug
system with linux-3.6.6 . It is running much better now, but with the
original 256K coherent pool size I still see errors after several hours
of runtime:

Nov 12 09:42:32 guru kernel: ERROR: 256 KiB atomic DMA coherent pool is 
too small!
Nov 12 09:42:32 guru kernel: Please increase it with coherent_pool= 
kernel parameter!

   Soeren

 >> ---
 >>  mm/dmapool.c |   27 +++++++--------------------
 >>  1 file changed, 7 insertions(+), 20 deletions(-)
 >>
 >> diff --git a/mm/dmapool.c b/mm/dmapool.c
 >> index c5ab33b..86de9b2 100644
 >> --- a/mm/dmapool.c
 >> +++ b/mm/dmapool.c
 >> @@ -62,8 +62,6 @@ struct dma_page {        /* cacheable header for 
'allocation' bytes */
 >>      unsigned int offset;
 >>  };
 >>
 >> -#define    POOL_TIMEOUT_JIFFIES    ((100 /* msec */ * HZ) / 1000)
 >> -
 >>  static DEFINE_MUTEX(pools_lock);
 >>
 >>  static ssize_t
 >> @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct 
dma_pool *pool, gfp_t mem_flags)
 >>          memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
 >>  #endif
 >>          pool_initialise_page(pool, page);
 >> -        list_add(&page->page_list, &pool->page_list);
 >>          page->in_use = 0;
 >>          page->offset = 0;
 >>      } else {
 >> @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, 
gfp_t mem_flags,
 >>      might_sleep_if(mem_flags & __GFP_WAIT);
 >>
 >>      spin_lock_irqsave(&pool->lock, flags);
 >> - restart:
 >>      list_for_each_entry(page, &pool->page_list, page_list) {
 >>          if (page->offset < pool->allocation)
 >>              goto ready;
 >>      }
 >> -    page = pool_alloc_page(pool, GFP_ATOMIC);
 >> -    if (!page) {
 >> -        if (mem_flags & __GFP_WAIT) {
 >> -            DECLARE_WAITQUEUE(wait, current);
 >>
 >> -            __set_current_state(TASK_UNINTERRUPTIBLE);
 >> -            __add_wait_queue(&pool->waitq, &wait);
 >> -            spin_unlock_irqrestore(&pool->lock, flags);
 >> +    /* pool_alloc_page() might sleep, so temporarily drop 
&pool->lock */
 >> +    spin_unlock_irqrestore(&pool->lock, flags);
 >>
 >> -            schedule_timeout(POOL_TIMEOUT_JIFFIES);
 >> +    page = pool_alloc_page(pool, mem_flags);
 >> +    if (!page)
 >> +        return NULL;
 >>
 >> -            spin_lock_irqsave(&pool->lock, flags);
 >> -            __remove_wait_queue(&pool->waitq, &wait);
 >> -            goto restart;
 >> -        }
 >> -        retval = NULL;
 >> -        goto done;
 >> -    }
 >> +    spin_lock_irqsave(&pool->lock, flags);
 >>
 >> +    list_add(&page->page_list, &pool->page_list);
 >>   ready:
 >>      page->in_use++;
 >>      offset = page->offset;
 >> @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, 
gfp_t mem_flags,
 >>  #ifdef    DMAPOOL_DEBUG
 >>      memset(retval, POOL_POISON_ALLOCATED, pool->size);
 >>  #endif
 >> - done:
 >>      spin_unlock_irqrestore(&pool->lock, flags);
 >>      return retval;
 >>  }
 >> --
 >> 1.7.9.5
 >>


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-12  9:48   ` Soeren Moch
@ 2012-11-12 10:38     ` Andrew Lunn
  2012-11-12 11:03       ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Andrew Lunn @ 2012-11-12 10:38 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Andrew Lunn, Marek Szyprowski, linux-arm-kernel, linaro-mm-sig,
	linux-mm, linux-kernel, Kyungmin Park, Arnd Bergmann,
	Thomas Petazzoni, Sebastian Hesselbarth

On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
> On 11.11.2012 18:22, Andrew Lunn wrote:
> > On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> >> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless
> >> the flags provided by the caller. This causes excessive pruning of
> >> emergency memory pools without any good reason. This patch
> changes the code
> >> to correctly use gfp flags provided by the dmapool caller. This should
> >> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
> >> allocations can be served only from the special, very limited
> memory pool.
> >>
> >> Reported-by: Soren Moch <smoch@web.de>
> Please use
> Reported-by: Soeren Moch <smoch@web.de>
> 
> >> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >
> > Tested-by: Andrew Lunn <andrew@lunn.ch>
> >
> > I tested this on a Kirkwood QNAP after removing the call to
> > init_dma_coherent_pool_size().
> >
> >     Andrew
> 
> Tested-by: Soeren Moch <smoch@web.de>
> 
> Now I had a chance to test this patch on my Kirkwood guruplug
> system with linux-3.6.6 . It is running much better now, but with the
> original 256K coherent pool size I still see errors after several hours
> of runtime:
> 
> Nov 12 09:42:32 guru kernel: ERROR: 256 KiB atomic DMA coherent pool
> is too small!
> Nov 12 09:42:32 guru kernel: Please increase it with coherent_pool=
> kernel parameter!

Hi Soeren

Could you tell us what DVB devices you are using.

Thanks
	Andrew

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-12 10:38     ` Andrew Lunn
@ 2012-11-12 11:03       ` Soeren Moch
  0 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2012-11-12 11:03 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Marek Szyprowski, linux-arm-kernel, linaro-mm-sig, linux-mm,
	linux-kernel, Kyungmin Park, Arnd Bergmann, Thomas Petazzoni,
	Sebastian Hesselbarth

On 12.11.2012 11:38, Andrew Lunn wrote:
> On Mon, Nov 12, 2012 at 10:48:02AM +0100, Soeren Moch wrote:
>> On 11.11.2012 18:22, Andrew Lunn wrote:
>>> On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
>>>> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
>> regardless
>>>> the flags provided by the caller. This causes excessive pruning of
>>>> emergency memory pools without any good reason. This patch
>> changes the code
>>>> to correctly use gfp flags provided by the dmapool caller. This should
>>>> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
>>>> allocations can be served only from the special, very limited
>> memory pool.
>>>> Reported-by: Soren Moch <smoch@web.de>
>> Please use
>> Reported-by: Soeren Moch <smoch@web.de>
>>
>>>> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> Tested-by: Andrew Lunn <andrew@lunn.ch>
>>>
>>> I tested this on a Kirkwood QNAP after removing the call to
>>> init_dma_coherent_pool_size().
>>>
>>>      Andrew
>> Tested-by: Soeren Moch <smoch@web.de>
>>
>> Now I had a chance to test this patch on my Kirkwood guruplug
>> system with linux-3.6.6 . It is running much better now, but with the
>> original 256K coherent pool size I still see errors after several hours
>> of runtime:
>>
>> Nov 12 09:42:32 guru kernel: ERROR: 256 KiB atomic DMA coherent pool
>> is too small!
>> Nov 12 09:42:32 guru kernel: Please increase it with coherent_pool=
>> kernel parameter!
> Hi Soeren
>
> Could you tell us what DVB devices you are using.
>
> Thanks
> 	Andrew

from lsusb:
Bus 001 Device 005: ID 0ccd:00b2 TerraTec Electronic GmbH
Bus 001 Device 006: ID 2040:5200 Hauppauge
Bus 001 Device 009: ID 2304:0242 Pinnacle Systems, Inc.

If you want to check the drivers, I recommend to start with "em28xx".

Regards,
Soeren

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-08  6:38 [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Marek Szyprowski
  2012-11-11 17:22 ` Andrew Lunn
@ 2012-11-19  0:18 ` Jason Cooper
  2012-11-19 22:48   ` Andrew Morton
  1 sibling, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2012-11-19  0:18 UTC (permalink / raw)
  To: Marek Szyprowski, Andrew Morton, KAMEZAWA Hiroyuki, Michal Hocko,
	Mel Gorman, Johannes Weiner
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Thomas Petazzoni, Andrew Lunn, Arnd Bergmann, Kyungmin Park,
	Soren Moch, Sebastian Hesselbarth

Marek,

I've added the maintainers for mm/*.  Hopefully they can let us know if
this is good for v3.8...

thx,

Jason.

On Thu, Nov 08, 2012 at 07:38:57AM +0100, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless
> the flags provided by the caller. This causes excessive pruning of
> emergency memory pools without any good reason. This patch changes the code
> to correctly use gfp flags provided by the dmapool caller. This should
> solve the dmapool usage on ARM architecture, where GFP_ATOMIC DMA
> allocations can be served only from the special, very limited memory pool.
> 
> Reported-by: Soren Moch <smoch@web.de>
> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  mm/dmapool.c |   27 +++++++--------------------
>  1 file changed, 7 insertions(+), 20 deletions(-)
> 
> diff --git a/mm/dmapool.c b/mm/dmapool.c
> index c5ab33b..86de9b2 100644
> --- a/mm/dmapool.c
> +++ b/mm/dmapool.c
> @@ -62,8 +62,6 @@ struct dma_page {		/* cacheable header for 'allocation' bytes */
>  	unsigned int offset;
>  };
>  
> -#define	POOL_TIMEOUT_JIFFIES	((100 /* msec */ * HZ) / 1000)
> -
>  static DEFINE_MUTEX(pools_lock);
>  
>  static ssize_t
> @@ -227,7 +225,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)
>  		memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
>  #endif
>  		pool_initialise_page(pool, page);
> -		list_add(&page->page_list, &pool->page_list);
>  		page->in_use = 0;
>  		page->offset = 0;
>  	} else {
> @@ -315,30 +312,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
>  	might_sleep_if(mem_flags & __GFP_WAIT);
>  
>  	spin_lock_irqsave(&pool->lock, flags);
> - restart:
>  	list_for_each_entry(page, &pool->page_list, page_list) {
>  		if (page->offset < pool->allocation)
>  			goto ready;
>  	}
> -	page = pool_alloc_page(pool, GFP_ATOMIC);
> -	if (!page) {
> -		if (mem_flags & __GFP_WAIT) {
> -			DECLARE_WAITQUEUE(wait, current);
>  
> -			__set_current_state(TASK_UNINTERRUPTIBLE);
> -			__add_wait_queue(&pool->waitq, &wait);
> -			spin_unlock_irqrestore(&pool->lock, flags);
> +	/* pool_alloc_page() might sleep, so temporarily drop &pool->lock */
> +	spin_unlock_irqrestore(&pool->lock, flags);
>  
> -			schedule_timeout(POOL_TIMEOUT_JIFFIES);
> +	page = pool_alloc_page(pool, mem_flags);
> +	if (!page)
> +		return NULL;
>  
> -			spin_lock_irqsave(&pool->lock, flags);
> -			__remove_wait_queue(&pool->waitq, &wait);
> -			goto restart;
> -		}
> -		retval = NULL;
> -		goto done;
> -	}
> +	spin_lock_irqsave(&pool->lock, flags);
>  
> +	list_add(&page->page_list, &pool->page_list);
>   ready:
>  	page->in_use++;
>  	offset = page->offset;
> @@ -348,7 +336,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
>  #ifdef	DMAPOOL_DEBUG
>  	memset(retval, POOL_POISON_ALLOCATED, pool->size);
>  #endif
> - done:
>  	spin_unlock_irqrestore(&pool->lock, flags);
>  	return retval;
>  }
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-19  0:18 ` Jason Cooper
@ 2012-11-19 22:48   ` Andrew Morton
  2012-11-20 10:48     ` Marek Szyprowski
  2012-11-20 14:31     ` [PATCH v2] " Marek Szyprowski
  0 siblings, 2 replies; 59+ messages in thread
From: Andrew Morton @ 2012-11-19 22:48 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Marek Szyprowski, KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman,
	Johannes Weiner, linux-arm-kernel, linaro-mm-sig, linux-mm,
	linux-kernel, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	Kyungmin Park, Soren Moch, Sebastian Hesselbarth

On Sun, 18 Nov 2012 19:18:46 -0500
Jason Cooper <jason@lakedaemon.net> wrote:

> I've added the maintainers for mm/*.  Hopefully they can let us know if
> this is good for v3.8...

As Marek has inexplicably put this patch into linux-next via his tree,
we don't appear to be getting a say in the matter!

The patch looks good to me.  That open-coded wait loop predates the
creation of bitkeeper tree(!) but doesn't appear to be needed.  There
will perhaps be some behavioural changes observable for GFP_KERNEL
callers as dma_pool_alloc() will no longer dip into page reserves but I
see nothing special about dma_pool_alloc() which justifies doing that
anyway.

The patch makes pool->waitq and its manipulation obsolete, but it
failed to remove all that stuff.

The changelog failed to describe the problem which Soren reported. 
That should be included, and as the problem sounds fairly serious we
might decide to backport the fix into -stable kernels.

dma_pool_alloc()'s use of a local "struct dma_page *page" is
distressing - MM developers very much expect a local called "page" to
have type "struct page *".  But that's a separate issue.

As this patch is already in -next and is stuck there for two more
weeks I can't (or at least won't) merge this patch, so I can't help
with any of the above.


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-19 22:48   ` Andrew Morton
@ 2012-11-20 10:48     ` Marek Szyprowski
  2012-11-20 19:52       ` Andrew Morton
  2012-11-20 14:31     ` [PATCH v2] " Marek Szyprowski
  1 sibling, 1 reply; 59+ messages in thread
From: Marek Szyprowski @ 2012-11-20 10:48 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Jason Cooper, KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman,
	Johannes Weiner, linux-arm-kernel, linaro-mm-sig, linux-mm,
	linux-kernel, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	Kyungmin Park, Soren Moch, Sebastian Hesselbarth

Hello,

On 11/19/2012 11:48 PM, Andrew Morton wrote:
> On Sun, 18 Nov 2012 19:18:46 -0500
> Jason Cooper <jason@lakedaemon.net> wrote:
>
> > I've added the maintainers for mm/*.  Hopefully they can let us know if
> > this is good for v3.8...
>
> As Marek has inexplicably put this patch into linux-next via his tree,
> we don't appear to be getting a say in the matter!

I've just put this patch to linux-next via my dma-mapping tree to give it
some testing asap to check if other changes to arm dma-mapping are required
or not.

> The patch looks good to me.  That open-coded wait loop predates the
> creation of bitkeeper tree(!) but doesn't appear to be needed.  There
> will perhaps be some behavioural changes observable for GFP_KERNEL
> callers as dma_pool_alloc() will no longer dip into page reserves but I
> see nothing special about dma_pool_alloc() which justifies doing that
> anyway.
>
> The patch makes pool->waitq and its manipulation obsolete, but it
> failed to remove all that stuff.

Right, I missed that part, I will update it asap.

> The changelog failed to describe the problem which Soren reported.
> That should be included, and as the problem sounds fairly serious we
> might decide to backport the fix into -stable kernels.

Ok, I will extend the changelog.

> dma_pool_alloc()'s use of a local "struct dma_page *page" is
> distressing - MM developers very much expect a local called "page" to
> have type "struct page *".  But that's a separate issue.

I will prepare a separate patch cleaning it. I was also a bit surprised
by such naming scheme, but it is probably related to the fact that this
come has not been touched much since a very ancient times.

> As this patch is already in -next and is stuck there for two more
> weeks I can't (or at least won't) merge this patch, so I can't help
> with any of the above.

I will fix both issues in the next version of the patch. Would like to
merge it to your tree or should I keep it in my dma-mapping tree?

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



^ permalink raw reply	[flat|nested] 59+ messages in thread

* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-19 22:48   ` Andrew Morton
  2012-11-20 10:48     ` Marek Szyprowski
@ 2012-11-20 14:31     ` Marek Szyprowski
  2012-11-20 19:33       ` Andrew Morton
  2013-01-14 11:56       ` Soeren Moch
  1 sibling, 2 replies; 59+ messages in thread
From: Marek Szyprowski @ 2012-11-20 14:31 UTC (permalink / raw)
  To: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel
  Cc: Marek Szyprowski, Kyungmin Park, Arnd Bergmann, Soren Moch,
	Thomas Petazzoni, Sebastian Hesselbarth, Andrew Lunn,
	Andrew Morton, Jason Cooper, KAMEZAWA Hiroyuki, Michal Hocko,
	Mel Gorman

dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
regardless the flags provided by the caller. This causes excessive
pruning of emergency memory pools without any good reason. Additionaly,
on ARM architecture any driver which is using dmapools will sooner or
later  trigger the following error: 
"ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!".
Increasing the coherent pool size usually doesn't help much and only
delays such error, because all GFP_ATOMIC DMA allocations are always
served from the special, very limited memory pool.

This patch changes the dmapool code to correctly use gfp flags provided
by the dmapool caller.

Reported-by: Soeren Moch <smoch@web.de>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Soeren Moch <smoch@web.de>
---

changelog
v2:
 - removed all waitq related stuff
 - extended commit message

 mm/dmapool.c |   31 +++++++------------------------
 1 file changed, 7 insertions(+), 24 deletions(-)

diff --git a/mm/dmapool.c b/mm/dmapool.c
index c5ab33b..da1b0f0 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -50,7 +50,6 @@ struct dma_pool {		/* the pool */
 	size_t allocation;
 	size_t boundary;
 	char name[32];
-	wait_queue_head_t waitq;
 	struct list_head pools;
 };
 
@@ -62,8 +61,6 @@ struct dma_page {		/* cacheable header for 'allocation' bytes */
 	unsigned int offset;
 };
 
-#define	POOL_TIMEOUT_JIFFIES	((100 /* msec */ * HZ) / 1000)
-
 static DEFINE_MUTEX(pools_lock);
 
 static ssize_t
@@ -172,7 +169,6 @@ struct dma_pool *dma_pool_create(const char *name, struct device *dev,
 	retval->size = size;
 	retval->boundary = boundary;
 	retval->allocation = allocation;
-	init_waitqueue_head(&retval->waitq);
 
 	if (dev) {
 		int ret;
@@ -227,7 +223,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)
 		memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
 #endif
 		pool_initialise_page(pool, page);
-		list_add(&page->page_list, &pool->page_list);
 		page->in_use = 0;
 		page->offset = 0;
 	} else {
@@ -315,30 +310,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 	might_sleep_if(mem_flags & __GFP_WAIT);
 
 	spin_lock_irqsave(&pool->lock, flags);
- restart:
 	list_for_each_entry(page, &pool->page_list, page_list) {
 		if (page->offset < pool->allocation)
 			goto ready;
 	}
-	page = pool_alloc_page(pool, GFP_ATOMIC);
-	if (!page) {
-		if (mem_flags & __GFP_WAIT) {
-			DECLARE_WAITQUEUE(wait, current);
 
-			__set_current_state(TASK_UNINTERRUPTIBLE);
-			__add_wait_queue(&pool->waitq, &wait);
-			spin_unlock_irqrestore(&pool->lock, flags);
+	/* pool_alloc_page() might sleep, so temporarily drop &pool->lock */
+	spin_unlock_irqrestore(&pool->lock, flags);
 
-			schedule_timeout(POOL_TIMEOUT_JIFFIES);
+	page = pool_alloc_page(pool, mem_flags);
+	if (!page)
+		return NULL;
 
-			spin_lock_irqsave(&pool->lock, flags);
-			__remove_wait_queue(&pool->waitq, &wait);
-			goto restart;
-		}
-		retval = NULL;
-		goto done;
-	}
+	spin_lock_irqsave(&pool->lock, flags);
 
+	list_add(&page->page_list, &pool->page_list);
  ready:
 	page->in_use++;
 	offset = page->offset;
@@ -348,7 +334,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 #ifdef	DMAPOOL_DEBUG
 	memset(retval, POOL_POISON_ALLOCATED, pool->size);
 #endif
- done:
 	spin_unlock_irqrestore(&pool->lock, flags);
 	return retval;
 }
@@ -435,8 +420,6 @@ void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma)
 	page->in_use--;
 	*(int *)vaddr = page->offset;
 	page->offset = offset;
-	if (waitqueue_active(&pool->waitq))
-		wake_up_locked(&pool->waitq);
 	/*
 	 * Resist a temptation to do
 	 *    if (!is_page_busy(page)) pool_free_page(pool, page);
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-20 14:31     ` [PATCH v2] " Marek Szyprowski
@ 2012-11-20 19:33       ` Andrew Morton
  2012-11-20 20:27         ` Jason Cooper
  2012-11-21  8:08         ` Marek Szyprowski
  2013-01-14 11:56       ` Soeren Moch
  1 sibling, 2 replies; 59+ messages in thread
From: Andrew Morton @ 2012-11-20 19:33 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

On Tue, 20 Nov 2012 15:31:45 +0100
Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless the flags provided by the caller. This causes excessive
> pruning of emergency memory pools without any good reason. Additionaly,
> on ARM architecture any driver which is using dmapools will sooner or
> later  trigger the following error: 
> "ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!".
> Increasing the coherent pool size usually doesn't help much and only
> delays such error, because all GFP_ATOMIC DMA allocations are always
> served from the special, very limited memory pool.
> 

Is this problem serious enough to justify merging the patch into 3.7? 
And into -stable kernels?


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-20 10:48     ` Marek Szyprowski
@ 2012-11-20 19:52       ` Andrew Morton
  0 siblings, 0 replies; 59+ messages in thread
From: Andrew Morton @ 2012-11-20 19:52 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: Jason Cooper, KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman,
	Johannes Weiner, linux-arm-kernel, linaro-mm-sig, linux-mm,
	linux-kernel, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	Kyungmin Park, Soren Moch, Sebastian Hesselbarth

On Tue, 20 Nov 2012 11:48:44 +0100
Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> > As this patch is already in -next and is stuck there for two more
> > weeks I can't (or at least won't) merge this patch, so I can't help
> > with any of the above.
> 
> I will fix both issues in the next version of the patch. Would like to
> merge it to your tree or should I keep it in my dma-mapping tree?

The patch looks OK to me now (still wondering about the -stable
question though).

It would be a bit of a pain for me to carry a patch which conflicts
with one in linux-next, and this patch doesn't appear to conflict with
the other pending dmapool.c patches in -mm so you may as well keep it
in the dma-mapping tree now.


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-20 19:33       ` Andrew Morton
@ 2012-11-20 20:27         ` Jason Cooper
  2012-11-21  8:08         ` Marek Szyprowski
  1 sibling, 0 replies; 59+ messages in thread
From: Jason Cooper @ 2012-11-20 20:27 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Marek Szyprowski, linux-arm-kernel, linaro-mm-sig, linux-mm,
	linux-kernel, Kyungmin Park, Arnd Bergmann, Soren Moch,
	Thomas Petazzoni, Sebastian Hesselbarth, Andrew Lunn,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

On Tue, Nov 20, 2012 at 11:33:25AM -0800, Andrew Morton wrote:
> On Tue, 20 Nov 2012 15:31:45 +0100
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> 
> > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > regardless the flags provided by the caller. This causes excessive
> > pruning of emergency memory pools without any good reason. Additionaly,
> > on ARM architecture any driver which is using dmapools will sooner or
> > later  trigger the following error: 
> > "ERROR: 256 KiB atomic DMA coherent pool is too small!
> > Please increase it with coherent_pool= kernel parameter!".
> > Increasing the coherent pool size usually doesn't help much and only
> > delays such error, because all GFP_ATOMIC DMA allocations are always
> > served from the special, very limited memory pool.
> > 
> 
> Is this problem serious enough to justify merging the patch into 3.7? 
> And into -stable kernels?

kirkwood and orion5x currently have the following code in their early
init:

/*
 * Some Kirkwood devices allocate their coherent buffers from atomic
 * context. Increase size of atomic coherent pool to make sure such the
 * allocations won't fail.
 */
init_dma_coherent_pool_size(SZ_1M);

We have a pending patch to do the same for mvebu (new armv7 Marvell
SoCs).  There is at least one reported real world case where even the
above isn't sufficient [1].

thx,

Jason.

[1] http://www.spinics.net/lists/arm-kernel/msg205495.html

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-20 19:33       ` Andrew Morton
  2012-11-20 20:27         ` Jason Cooper
@ 2012-11-21  8:08         ` Marek Szyprowski
  2012-11-21  8:36           ` Andrew Morton
  1 sibling, 1 reply; 59+ messages in thread
From: Marek Szyprowski @ 2012-11-21  8:08 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

Hello,

On 11/20/2012 8:33 PM, Andrew Morton wrote:
> On Tue, 20 Nov 2012 15:31:45 +0100
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > regardless the flags provided by the caller. This causes excessive
> > pruning of emergency memory pools without any good reason. Additionaly,
> > on ARM architecture any driver which is using dmapools will sooner or
> > later  trigger the following error:
> > "ERROR: 256 KiB atomic DMA coherent pool is too small!
> > Please increase it with coherent_pool= kernel parameter!".
> > Increasing the coherent pool size usually doesn't help much and only
> > delays such error, because all GFP_ATOMIC DMA allocations are always
> > served from the special, very limited memory pool.
> >
>
> Is this problem serious enough to justify merging the patch into 3.7?
> And into -stable kernels?

I wonder if it is a good idea to merge such change at the end of current
-rc period. It changes the behavior of dma pool allocations and I bet there
might be some drivers which don't care much about passed gfp flags, as for
ages it simply worked for them, even if the allocations were done from
atomic context. What do You think? Technically it is also not a pure bugfix,
so imho it shouldn't be considered for -stable.

On the other hand at least for ARM users of sata_mv driver (which is just
an innocent client of dma pool, correctly passing GFP_KERNEL flag) it would
solve the issues related to shortage of atomic pool for dma allocations what
might justify pushing it to 3.7.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-21  8:08         ` Marek Szyprowski
@ 2012-11-21  8:36           ` Andrew Morton
  2012-11-21  9:20             ` Marek Szyprowski
  0 siblings, 1 reply; 59+ messages in thread
From: Andrew Morton @ 2012-11-21  8:36 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> Hello,
> 
> On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > On Tue, 20 Nov 2012 15:31:45 +0100
> > Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> >
> > > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > > regardless the flags provided by the caller. This causes excessive
> > > pruning of emergency memory pools without any good reason. Additionaly,
> > > on ARM architecture any driver which is using dmapools will sooner or
> > > later  trigger the following error:
> > > "ERROR: 256 KiB atomic DMA coherent pool is too small!
> > > Please increase it with coherent_pool= kernel parameter!".
> > > Increasing the coherent pool size usually doesn't help much and only
> > > delays such error, because all GFP_ATOMIC DMA allocations are always
> > > served from the special, very limited memory pool.
> > >
> >
> > Is this problem serious enough to justify merging the patch into 3.7?
> > And into -stable kernels?
> 
> I wonder if it is a good idea to merge such change at the end of current
> -rc period.

I'm not sure what you mean by this.

But what we do sometimes if we think a patch needs a bit more
real-world testing before backporting is to merge it into -rc1 in the
normal merge window, and tag it for -stable backporting.  That way it
gets a few weeks(?) testing in mainline before getting backported.


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-21  8:36           ` Andrew Morton
@ 2012-11-21  9:20             ` Marek Szyprowski
  2012-11-21 19:17               ` Andrew Morton
  0 siblings, 1 reply; 59+ messages in thread
From: Marek Szyprowski @ 2012-11-21  9:20 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

Hello,

On 11/21/2012 9:36 AM, Andrew Morton wrote:
> On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> > Hello,
> >
> > On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > > On Tue, 20 Nov 2012 15:31:45 +0100
> > > Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > >
> > > > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > > > regardless the flags provided by the caller. This causes excessive
> > > > pruning of emergency memory pools without any good reason. Additionaly,
> > > > on ARM architecture any driver which is using dmapools will sooner or
> > > > later  trigger the following error:
> > > > "ERROR: 256 KiB atomic DMA coherent pool is too small!
> > > > Please increase it with coherent_pool= kernel parameter!".
> > > > Increasing the coherent pool size usually doesn't help much and only
> > > > delays such error, because all GFP_ATOMIC DMA allocations are always
> > > > served from the special, very limited memory pool.
> > > >
> > >
> > > Is this problem serious enough to justify merging the patch into 3.7?
> > > And into -stable kernels?
> >
> > I wonder if it is a good idea to merge such change at the end of current
> > -rc period.
>
> I'm not sure what you mean by this.
>
> But what we do sometimes if we think a patch needs a bit more
> real-world testing before backporting is to merge it into -rc1 in the
> normal merge window, and tag it for -stable backporting.  That way it
> gets a few weeks(?) testing in mainline before getting backported.

I just wondered that if it gets merged to v3.7-rc7 there won't be much time
for real-world testing before final v3.7 release. This patch is in
linux-next for over a week and I'm not aware of any issues, but -rc releases
gets much more attention and testing than linux-next tree.

If You think it's fine to put such change to v3.7-rc7 I will send a pull
request and tag it for stable asap.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-21  9:20             ` Marek Szyprowski
@ 2012-11-21 19:17               ` Andrew Morton
  2012-11-22 12:55                 ` Marek Szyprowski
  0 siblings, 1 reply; 59+ messages in thread
From: Andrew Morton @ 2012-11-21 19:17 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

On Wed, 21 Nov 2012 10:20:07 +0100
Marek Szyprowski <m.szyprowski@samsung.com> wrote:

> Hello,
> 
> On 11/21/2012 9:36 AM, Andrew Morton wrote:
> > On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> >
> > > Hello,
> > >
> > > On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > > > On Tue, 20 Nov 2012 15:31:45 +0100
> > > > Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > > >
> > > > > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > > > > regardless the flags provided by the caller. This causes excessive
> > > > > pruning of emergency memory pools without any good reason. Additionaly,
> > > > > on ARM architecture any driver which is using dmapools will sooner or
> > > > > later  trigger the following error:
> > > > > "ERROR: 256 KiB atomic DMA coherent pool is too small!
> > > > > Please increase it with coherent_pool= kernel parameter!".
> > > > > Increasing the coherent pool size usually doesn't help much and only
> > > > > delays such error, because all GFP_ATOMIC DMA allocations are always
> > > > > served from the special, very limited memory pool.
> > > > >
> > > >
> > > > Is this problem serious enough to justify merging the patch into 3.7?
> > > > And into -stable kernels?
> > >
> > > I wonder if it is a good idea to merge such change at the end of current
> > > -rc period.
> >
> > I'm not sure what you mean by this.
> >
> > But what we do sometimes if we think a patch needs a bit more
> > real-world testing before backporting is to merge it into -rc1 in the
> > normal merge window, and tag it for -stable backporting.  That way it
> > gets a few weeks(?) testing in mainline before getting backported.
> 
> I just wondered that if it gets merged to v3.7-rc7 there won't be much time
> for real-world testing before final v3.7 release. This patch is in
> linux-next for over a week and I'm not aware of any issues, but -rc releases
> gets much more attention and testing than linux-next tree.
> 
> If You think it's fine to put such change to v3.7-rc7 I will send a pull
> request and tag it for stable asap.
> 

What I'm suggesting is that it be merged for 3.8-rc1 with a -stable
tag, then it will be backported into 3.7.x later on.


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-21 19:17               ` Andrew Morton
@ 2012-11-22 12:55                 ` Marek Szyprowski
  0 siblings, 0 replies; 59+ messages in thread
From: Marek Szyprowski @ 2012-11-22 12:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Soren Moch, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman


On 11/21/2012 8:17 PM, Andrew Morton wrote:
> On Wed, 21 Nov 2012 10:20:07 +0100
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > On 11/21/2012 9:36 AM, Andrew Morton wrote:
> > > On Wed, 21 Nov 2012 09:08:52 +0100 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > > > On 11/20/2012 8:33 PM, Andrew Morton wrote:
> > > > > On Tue, 20 Nov 2012 15:31:45 +0100
> > > > > Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > > > >
> > > > > > dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> > > > > > regardless the flags provided by the caller. This causes excessive
> > > > > > pruning of emergency memory pools without any good reason. Additionaly,
> > > > > > on ARM architecture any driver which is using dmapools will sooner or
> > > > > > later  trigger the following error:
> > > > > > "ERROR: 256 KiB atomic DMA coherent pool is too small!
> > > > > > Please increase it with coherent_pool= kernel parameter!".
> > > > > > Increasing the coherent pool size usually doesn't help much and only
> > > > > > delays such error, because all GFP_ATOMIC DMA allocations are always
> > > > > > served from the special, very limited memory pool.
> > > > > >
> > > > >
> > > > > Is this problem serious enough to justify merging the patch into 3.7?
> > > > > And into -stable kernels?
> > > >
> > > > I wonder if it is a good idea to merge such change at the end of current
> > > > -rc period.
> > >
> > > I'm not sure what you mean by this.
> > >
> > > But what we do sometimes if we think a patch needs a bit more
> > > real-world testing before backporting is to merge it into -rc1 in the
> > > normal merge window, and tag it for -stable backporting.  That way it
> > > gets a few weeks(?) testing in mainline before getting backported.
> >
> > I just wondered that if it gets merged to v3.7-rc7 there won't be much time
> > for real-world testing before final v3.7 release. This patch is in
> > linux-next for over a week and I'm not aware of any issues, but -rc releases
> > gets much more attention and testing than linux-next tree.
> >
> > If You think it's fine to put such change to v3.7-rc7 I will send a pull
> > request and tag it for stable asap.
>
> What I'm suggesting is that it be merged for 3.8-rc1 with a -stable
> tag, then it will be backported into 3.7.x later on.

OK, I will push it to v3.8-rc1 then and tag for stable.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2012-11-20 14:31     ` [PATCH v2] " Marek Szyprowski
  2012-11-20 19:33       ` Andrew Morton
@ 2013-01-14 11:56       ` Soeren Moch
  2013-01-15 16:56         ` Jason Cooper
  1 sibling, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-14 11:56 UTC (permalink / raw)
  To: Marek Szyprowski
  Cc: linux-arm-kernel, linaro-mm-sig, linux-mm, linux-kernel,
	Kyungmin Park, Arnd Bergmann, Thomas Petazzoni,
	Sebastian Hesselbarth, Andrew Lunn, Andrew Morton, Jason Cooper,
	KAMEZAWA Hiroyuki, Michal Hocko, Mel Gorman

On 20.11.2012 15:31, Marek Szyprowski wrote:
> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> regardless the flags provided by the caller. This causes excessive
> pruning of emergency memory pools without any good reason. Additionaly,
> on ARM architecture any driver which is using dmapools will sooner or
> later  trigger the following error:
> "ERROR: 256 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!".
> Increasing the coherent pool size usually doesn't help much and only
> delays such error, because all GFP_ATOMIC DMA allocations are always
> served from the special, very limited memory pool.
>
> This patch changes the dmapool code to correctly use gfp flags provided
> by the dmapool caller.
>
> Reported-by: Soeren Moch <smoch@web.de>
> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Andrew Lunn <andrew@lunn.ch>
> Tested-by: Soeren Moch <smoch@web.de>

Now I tested linux-3.7.1 (this patch is included there) on my Marvell
Kirkwood system. I still see

   ERROR: 1024 KiB atomic DMA coherent pool is too small!
   Please increase it with coherent_pool= kernel parameter!

after several hours of runtime under heavy load with SATA and
DVB-Sticks (em28xx / drxk and dib0700).

As already reported earlier this patch improved the behavior compared to 
linux-3.6.x and 3.7.0 (error after several ten minutes runtime), but
I still see a regression compared to linux-3.5.x. With this kernel the
same system with same workload runs flawlessly.

Regards,
Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-14 11:56       ` Soeren Moch
@ 2013-01-15 16:56         ` Jason Cooper
  2013-01-15 17:50           ` Greg KH
  2013-01-15 20:05           ` Sebastian Hesselbarth
  0 siblings, 2 replies; 59+ messages in thread
From: Jason Cooper @ 2013-01-15 16:56 UTC (permalink / raw)
  To: Soeren Moch, Greg KH
  Cc: Marek Szyprowski, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	Michal Hocko, linux-kernel, linaro-mm-sig, linux-mm,
	Kyungmin Park, KAMEZAWA Hiroyuki, Andrew Morton, Mel Gorman,
	linux-arm-kernel, Sebastian Hesselbarth

Greg,

I've added you to the this thread hoping for a little insight into USB
drivers and their use of coherent and GFP_ATOMIC.  Am I barking up the
wrong tree by looking a the drivers?

On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
> On 20.11.2012 15:31, Marek Szyprowski wrote:
> >dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
> >regardless the flags provided by the caller. This causes excessive
> >pruning of emergency memory pools without any good reason. Additionaly,
> >on ARM architecture any driver which is using dmapools will sooner or
> >later  trigger the following error:
> >"ERROR: 256 KiB atomic DMA coherent pool is too small!
> >Please increase it with coherent_pool= kernel parameter!".
> >Increasing the coherent pool size usually doesn't help much and only
> >delays such error, because all GFP_ATOMIC DMA allocations are always
> >served from the special, very limited memory pool.
> >
> >This patch changes the dmapool code to correctly use gfp flags provided
> >by the dmapool caller.
> >
> >Reported-by: Soeren Moch <smoch@web.de>
> >Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> >Tested-by: Andrew Lunn <andrew@lunn.ch>
> >Tested-by: Soeren Moch <smoch@web.de>
> 
> Now I tested linux-3.7.1 (this patch is included there) on my Marvell
> Kirkwood system. I still see
> 
>   ERROR: 1024 KiB atomic DMA coherent pool is too small!
>   Please increase it with coherent_pool= kernel parameter!
> 
> after several hours of runtime under heavy load with SATA and
> DVB-Sticks (em28xx / drxk and dib0700).

Could you try running the system w/o the em28xx stick and see how it
goes with v3.7.1?

thx,

Jason.

> As already reported earlier this patch improved the behavior
> compared to linux-3.6.x and 3.7.0 (error after several ten minutes
> runtime), but
> I still see a regression compared to linux-3.5.x. With this kernel the
> same system with same workload runs flawlessly.
> 
> Regards,
> Soeren
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-15 16:56         ` Jason Cooper
@ 2013-01-15 17:50           ` Greg KH
  2013-01-15 20:16             ` Jason Cooper
  2013-01-15 20:05           ` Sebastian Hesselbarth
  1 sibling, 1 reply; 59+ messages in thread
From: Greg KH @ 2013-01-15 17:50 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Soeren Moch, Marek Szyprowski, Thomas Petazzoni, Andrew Lunn,
	Arnd Bergmann, Michal Hocko, linux-kernel, linaro-mm-sig,
	linux-mm, Kyungmin Park, KAMEZAWA Hiroyuki, Andrew Morton,
	Mel Gorman, linux-arm-kernel, Sebastian Hesselbarth

On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
> Greg,
> 
> I've added you to the this thread hoping for a little insight into USB
> drivers and their use of coherent and GFP_ATOMIC.  Am I barking up the
> wrong tree by looking a the drivers?

I don't understand, which drivers are you referring to?  USB host
controller drivers, or the "normal" drivers?  Most USB drivers use
GFP_ATOMIC if they are creating memory during their URB callback path,
as that is interrupt context.  But it shouldn't be all that bad, and the
USB core hasn't changed in a while, so something else must be causing
this.

greg k-h

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-15 16:56         ` Jason Cooper
  2013-01-15 17:50           ` Greg KH
@ 2013-01-15 20:05           ` Sebastian Hesselbarth
  2013-01-15 20:19             ` Jason Cooper
  1 sibling, 1 reply; 59+ messages in thread
From: Sebastian Hesselbarth @ 2013-01-15 20:05 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Soeren Moch, Greg KH, Marek Szyprowski, Thomas Petazzoni,
	Andrew Lunn, Arnd Bergmann, Michal Hocko, linux-kernel,
	linaro-mm-sig, linux-mm, Kyungmin Park, KAMEZAWA Hiroyuki,
	Andrew Morton, Mel Gorman, linux-arm-kernel

On 01/15/2013 05:56 PM, Jason Cooper wrote:
> Greg,
>
> I've added you to the this thread hoping for a little insight into USB
> drivers and their use of coherent and GFP_ATOMIC.  Am I barking up the
> wrong tree by looking a the drivers?
>
> On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
>> On 20.11.2012 15:31, Marek Szyprowski wrote:
>>> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
>>> regardless the flags provided by the caller. This causes excessive
>>> pruning of emergency memory pools without any good reason. Additionaly,
>>> on ARM architecture any driver which is using dmapools will sooner or
>>> later  trigger the following error:
>>> "ERROR: 256 KiB atomic DMA coherent pool is too small!
>>> Please increase it with coherent_pool= kernel parameter!".
>>> Increasing the coherent pool size usually doesn't help much and only
>>> delays such error, because all GFP_ATOMIC DMA allocations are always
>>> served from the special, very limited memory pool.
>>>
>>> This patch changes the dmapool code to correctly use gfp flags provided
>>> by the dmapool caller.
>>>
>>> Reported-by: Soeren Moch<smoch@web.de>
>>> Reported-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>>> Signed-off-by: Marek Szyprowski<m.szyprowski@samsung.com>
>>> Tested-by: Andrew Lunn<andrew@lunn.ch>
>>> Tested-by: Soeren Moch<smoch@web.de>
>>
>> Now I tested linux-3.7.1 (this patch is included there) on my Marvell
>> Kirkwood system. I still see
>>
>>    ERROR: 1024 KiB atomic DMA coherent pool is too small!
>>    Please increase it with coherent_pool= kernel parameter!
>>
>> after several hours of runtime under heavy load with SATA and
>> DVB-Sticks (em28xx / drxk and dib0700).
>
> Could you try running the system w/o the em28xx stick and see how it
> goes with v3.7.1?

Jason,

can you point out what you think we should be looking for?

I grep'd for 'GFP_' in  drivers/media/usb and especially for dvb-usb
(dib0700) it looks like most of the buffers in usb-urb.c are allocated
GFP_ATOMIC. em28xx also allocates some of the buffers atomic.

If we look for a mem leak in one of the above drivers (including sata_mv),
is there an easy way to keep track of allocated and freed kernel memory?

Sebastian

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-15 17:50           ` Greg KH
@ 2013-01-15 20:16             ` Jason Cooper
  2013-01-15 21:56               ` Jason Cooper
  0 siblings, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2013-01-15 20:16 UTC (permalink / raw)
  To: Greg KH
  Cc: Thomas Petazzoni, Andrew Lunn, Arnd Bergmann, linux-arm-kernel,
	linux-kernel, Michal Hocko, linux-mm, Kyungmin Park, Soeren Moch,
	Mel Gorman, Andrew Morton, Sebastian Hesselbarth, linaro-mm-sig,
	KAMEZAWA Hiroyuki, Marek Szyprowski

On Tue, Jan 15, 2013 at 09:50:20AM -0800, Greg KH wrote:
> On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
> > Greg,
> > 
> > I've added you to the this thread hoping for a little insight into USB
> > drivers and their use of coherent and GFP_ATOMIC.  Am I barking up the
> > wrong tree by looking a the drivers?
> 
> I don't understand, which drivers are you referring to?  USB host
> controller drivers, or the "normal" drivers?

Sorry I wasn't clear, I was referring specifically to the usb dvb
drivers em28xx, drxk and dib0700.  These are the drivers reported to be
in heavy use when the error occurs.

sata_mv is also in use, however no other users of sata_mv have reported
problems.  Including myself. ;-)

> Most USB drivers use GFP_ATOMIC if they are creating memory during
> their URB callback path, as that is interrupt context.  But it
> shouldn't be all that bad, and the USB core hasn't changed in a while,
> so something else must be causing this.

Agreed, so I went and did more reading.  The key piece of the puzzle
that I was missing was in arch/arm/mm/dma-mapping.c 660-684.

/*
 * Allocate DMA-coherent memory space and return both the kernel
 * remapped
 * virtual and bus address for that space.
 */
void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
                    gfp_t gfp, struct dma_attrs *attrs)
{
        pgprot_t prot = __get_dma_pgprot(attrs, pgprot_kernel);
        void *memory;

        if (dma_alloc_from_coherent(dev, size, handle, &memory))
                return memory;

        return __dma_alloc(dev, size, handle, gfp, prot, false,
                           __builtin_return_address(0));
}

static void *arm_coherent_dma_alloc(struct device *dev, size_t size,
        dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
{
        pgprot_t prot = __get_dma_pgprot(attrs, pgprot_kernel);
        void *memory;

        if (dma_alloc_from_coherent(dev, size, handle, &memory))
                return memory;

        return __dma_alloc(dev, size, handle, gfp, prot, true,
                           __builtin_return_address(0));
}


My understanding of this code is that when a driver requests dma memory,
we will first try to alloc from the per-driver pool.  If that fails, we
will then attempt to allocate from the atomic_pool.

Once the atomic_pool is exhausted, we get the error:

  ERROR: 1024 KiB atomic DMA coherent pool is too small!
  Please increase it with coherent_pool= kernel parameter!

If my understanding is correct, one of the drivers (most likely one)
either asks for too small of a dma buffer, or is not properly
deallocating blocks from the per-device pool.  Either case leads to
exhaustion, and falling back to the atomic pool.  Which subsequently
gets wiped out as well.

Am I on the right track?

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-15 20:05           ` Sebastian Hesselbarth
@ 2013-01-15 20:19             ` Jason Cooper
  0 siblings, 0 replies; 59+ messages in thread
From: Jason Cooper @ 2013-01-15 20:19 UTC (permalink / raw)
  To: Sebastian Hesselbarth
  Cc: Soeren Moch, Greg KH, Marek Szyprowski, Thomas Petazzoni,
	Andrew Lunn, Arnd Bergmann, Michal Hocko, linux-kernel,
	linaro-mm-sig, linux-mm, Kyungmin Park, KAMEZAWA Hiroyuki,
	Andrew Morton, Mel Gorman, linux-arm-kernel

On Tue, Jan 15, 2013 at 09:05:50PM +0100, Sebastian Hesselbarth wrote:
> If we look for a mem leak in one of the above drivers (including sata_mv),
> is there an easy way to keep track of allocated and freed kernel memory?

I'm inclined to think sata_mv is not the cause here, as there are many
heavy users of it without error reports.  The only thing different here
are the three usb dvb dongles.

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-15 20:16             ` Jason Cooper
@ 2013-01-15 21:56               ` Jason Cooper
  2013-01-16  0:17                 ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2013-01-15 21:56 UTC (permalink / raw)
  To: Greg KH
  Cc: Thomas Petazzoni, Andrew Lunn, Arnd Bergmann, KAMEZAWA Hiroyuki,
	linux-kernel, Michal Hocko, linux-mm, Kyungmin Park, Soeren Moch,
	Mel Gorman, Andrew Morton, Marek Szyprowski, linaro-mm-sig,
	linux-arm-kernel, Sebastian Hesselbarth

Soeren,

On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> If my understanding is correct, one of the drivers (most likely one)
> either asks for too small of a dma buffer, or is not properly
> deallocating blocks from the per-device pool.  Either case leads to
> exhaustion, and falling back to the atomic pool.  Which subsequently
> gets wiped out as well.

If my hunch is right, could you please try each of the three dvb drivers
in turn and see which one (or more than one) causes the error?

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-15 21:56               ` Jason Cooper
@ 2013-01-16  0:17                 ` Soeren Moch
  2013-01-16  2:40                   ` Jason Cooper
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-16  0:17 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 15.01.2013 22:56, Jason Cooper wrote:
> Soeren,
>
> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>> If my understanding is correct, one of the drivers (most likely one)
>> either asks for too small of a dma buffer, or is not properly
>> deallocating blocks from the per-device pool.  Either case leads to
>> exhaustion, and falling back to the atomic pool.  Which subsequently
>> gets wiped out as well.
>
> If my hunch is right, could you please try each of the three dvb drivers
> in turn and see which one (or more than one) causes the error?
>

In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
demodulator, and dib0700 usb bridge plus dib7000p demod.

I would bet for em28xx causing the error, but this is not thoroughly
tested. Unfortunately testing with removed sticks is not easy, because
this is a production system and disabling some services for the long
time we need to trigger this error will certainly result in unhappy
users.

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?

In linux-3.5.x there is no such problem. Can we use all available memory
for dma buffers here on armv5 architectures, in contrast to newer
kernels?

Regards,
Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16  0:17                 ` Soeren Moch
@ 2013-01-16  2:40                   ` Jason Cooper
  2013-01-16  3:24                     ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2013-01-16  2:40 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

Soeren,

On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
> On 15.01.2013 22:56, Jason Cooper wrote:
> >On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> >>If my understanding is correct, one of the drivers (most likely one)
> >>either asks for too small of a dma buffer, or is not properly
> >>deallocating blocks from the per-device pool.  Either case leads to
> >>exhaustion, and falling back to the atomic pool.  Which subsequently
> >>gets wiped out as well.
> >
> >If my hunch is right, could you please try each of the three dvb drivers
> >in turn and see which one (or more than one) causes the error?
> 
> In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
> demodulator, and dib0700 usb bridge plus dib7000p demod.
> 
> I would bet for em28xx causing the error, but this is not thoroughly
> tested. Unfortunately testing with removed sticks is not easy, because
> this is a production system and disabling some services for the long
> time we need to trigger this error will certainly result in unhappy
> users.

Just out of curiosity, what board is it?

> 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

> In linux-3.5.x there is no such problem. Can we use all available memory
> for dma buffers here on armv5 architectures, in contrast to newer
> kernels?

Were the loads exactly the same when you tested 3.5.x?  I looked at the
changes from v3.5 to v3.7.1 for all four drivers you mentioned as well
as sata_mv.

The biggest thing I see is that all of the media drivers got shuffled
around into their own subdirectories after v3.5.  'git show -M 0c0d06c'
shows it was a clean copy of all the files.

What would be most helpful is if you could do a git bisect between
v3.5.x (working) and the oldest version where you know it started
failing (v3.7.1 or earlier if you know it).

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16  2:40                   ` Jason Cooper
@ 2013-01-16  3:24                     ` Soeren Moch
  2013-01-16  8:55                       ` Soeren Moch
  2013-01-17 10:49                       ` Arnd Bergmann
  0 siblings, 2 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-16  3:24 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 03:40, Jason Cooper wrote:
> Soeren,
>
> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>> On 15.01.2013 22:56, Jason Cooper wrote:
>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>> If my understanding is correct, one of the drivers (most likely one)
>>>> either asks for too small of a dma buffer, or is not properly
>>>> deallocating blocks from the per-device pool.  Either case leads to
>>>> exhaustion, and falling back to the atomic pool.  Which subsequently
>>>> gets wiped out as well.
>>>
>>> If my hunch is right, could you please try each of the three dvb drivers
>>> in turn and see which one (or more than one) causes the error?
>>
>> In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
>> demodulator, and dib0700 usb bridge plus dib7000p demod.
>>
>> I would bet for em28xx causing the error, but this is not thoroughly
>> tested. Unfortunately testing with removed sticks is not easy, because
>> this is a production system and disabling some services for the long
>> time we need to trigger this error will certainly result in unhappy
>> users.
>
> Just out of curiosity, what board is it?

The kirkwood board? A modified Guruplug Server Plus.
>
>> 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.
>
>> In linux-3.5.x there is no such problem. Can we use all available memory
>> for dma buffers here on armv5 architectures, in contrast to newer
>> kernels?
>
> Were the loads exactly the same when you tested 3.5.x?

Exactly the same, yes.

>I looked at the
> changes from v3.5 to v3.7.1 for all four drivers you mentioned as well
> as sata_mv.
>
> The biggest thing I see is that all of the media drivers got shuffled
> around into their own subdirectories after v3.5.  'git show -M 0c0d06c'
> shows it was a clean copy of all the files.
>
> What would be most helpful is if you could do a git bisect between
> v3.5.x (working) and the oldest version where you know it started
> failing (v3.7.1 or earlier if you know it).
>
I did not bisect it, but Marek mentioned earlier that commit
e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
new code for dma allocations. This is probably the root cause for the
new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
I'm not very familiar with arm mm code, and from the patch itself I
cannot understand what's different. Maybe CONFIG_CMA is default
also for armv5 (not only v6) now? But I might be totally wrong here,
maybe someone of the mm experts can explain the difference?

Regards,
Soeren






^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16  3:24                     ` Soeren Moch
@ 2013-01-16  8:55                       ` Soeren Moch
  2013-01-16 15:50                         ` [PATCH] ata: sata_mv: fix sg_tbl_pool alignment Jason Cooper
  2013-01-16 17:32                         ` [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Soeren Moch
  2013-01-17 10:49                       ` Arnd Bergmann
  1 sibling, 2 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-16  8:55 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 04:24, Soeren Moch wrote:
> On 16.01.2013 03:40, Jason Cooper wrote:
>> Soeren,
>>
>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>>> If my understanding is correct, one of the drivers (most likely one)
>>>>> either asks for too small of a dma buffer, or is not properly
>>>>> deallocating blocks from the per-device pool.  Either case leads to
>>>>> exhaustion, and falling back to the atomic pool.  Which subsequently
>>>>> gets wiped out as well.
>>>>
>>>> If my hunch is right, could you please try each of the three dvb
>>>> drivers
>>>> in turn and see which one (or more than one) causes the error?
>>>
>>> In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
>>> demodulator, and dib0700 usb bridge plus dib7000p demod.
>>>
>>> I would bet for em28xx causing the error, but this is not thoroughly
>>> tested. Unfortunately testing with removed sticks is not easy, because
>>> this is a production system and disabling some services for the long
>>> time we need to trigger this error will certainly result in unhappy
>>> users.
>>
OK, I could trigger the error
   ERROR: 1024 KiB atomic DMA coherent pool is too small!
   Please increase it with coherent_pool= kernel parameter!
only with em28xx sticks and sata, dib0700 sticks removed.

>> Just out of curiosity, what board is it?
>
> The kirkwood board? A modified Guruplug Server Plus.
em28xx sticks: "TerraTec Cinergy HTC Stick HD" and "PCTV Quatro Stick"
dib0700 sticks: "WinTV-NOVA-TD Stick"
>>
>>> 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.
>>
>>> In linux-3.5.x there is no such problem. Can we use all available memory
>>> for dma buffers here on armv5 architectures, in contrast to newer
>>> kernels?
>>
>> Were the loads exactly the same when you tested 3.5.x?
>
> Exactly the same, yes.
>
>> I looked at the
>> changes from v3.5 to v3.7.1 for all four drivers you mentioned as well
>> as sata_mv.
>>
>> The biggest thing I see is that all of the media drivers got shuffled
>> around into their own subdirectories after v3.5.  'git show -M 0c0d06c'
>> shows it was a clean copy of all the files.
>>
>> What would be most helpful is if you could do a git bisect between
>> v3.5.x (working) and the oldest version where you know it started
>> failing (v3.7.1 or earlier if you know it).
>>
> I did not bisect it, but Marek mentioned earlier that commit
> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> new code for dma allocations. This is probably the root cause for the
> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).

I don't want to say that Mareks patch is wrong, probably it triggers a
bug somewhere else! (in em28xx?)

> I'm not very familiar with arm mm code, and from the patch itself I
> cannot understand what's different. Maybe CONFIG_CMA is default
> also for armv5 (not only v6) now? But I might be totally wrong here,
> maybe someone of the mm experts can explain the difference?
>
Regards,
Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16  8:55                       ` Soeren Moch
@ 2013-01-16 15:50                         ` Jason Cooper
  2013-01-16 17:05                           ` Soeren Moch
  2013-01-16 17:32                         ` [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Soeren Moch
  1 sibling, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2013-01-16 15:50 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
> On 16.01.2013 04:24, Soeren Moch wrote:
> >On 16.01.2013 03:40, Jason Cooper wrote:
> >>On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
> >>>On 15.01.2013 22:56, Jason Cooper wrote:
> >>>>On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:

> OK, I could trigger the error
>   ERROR: 1024 KiB atomic DMA coherent pool is too small!
>   Please increase it with coherent_pool= kernel parameter!
> only with em28xx sticks and sata, dib0700 sticks removed.

Did you test the reverse scenario?  ie dib0700 with sata_mv and no
em28xx.

What kind of throughput are you pushing to the sata disk?

> >>What would be most helpful is if you could do a git bisect between
> >>v3.5.x (working) and the oldest version where you know it started
> >>failing (v3.7.1 or earlier if you know it).
> >>
> >I did not bisect it, but Marek mentioned earlier that commit
> >e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> >new code for dma allocations. This is probably the root cause for the
> >new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
> 
> I don't want to say that Mareks patch is wrong, probably it triggers a
> bug somewhere else! (in em28xx?)

Of the four drivers you listed, none are using dma.  sata_mv is the only
one.

If one is to believe the comments in sata_mv.c:~151, then the alignment
is wrong for the sg_tbl_pool.

Could you please try the following patch?

thx,

Jason.

---8<----------
>From 566c7e30285e4c31d76724ea4811b016b753f24f Mon Sep 17 00:00:00 2001
From: Jason Cooper <jason@lakedaemon.net>
Date: Wed, 16 Jan 2013 15:43:37 +0000
Subject: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment

If the comment is to be believed, the alignment should be 16B, and the
size 4K.  The current code sets both to 4K.  On some arm boards
(kirkwood), this causes:

   ERROR: 1024 KiB atomic DMA coherent pool is too small!
   Please increase it with coherent_pool= kernel parameter!

Set alignment to 16B to prevent exhausting the atomic_pool.

Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
 drivers/ata/sata_mv.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 68f4fb5..e2e5a8a 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -148,6 +148,9 @@ enum {
 	 * CRPB needs alignment on a 256B boundary. Size == 256B
 	 * ePRD (SG) entries need alignment on a 16B boundary. Size == 16B
 	 */
+	MV_CRQB_Q_ALIGN		= 1024,
+	MV_CRPB_Q_ALIGN		= 256,
+	MV_SG_TBL_ALIGN		= 16,
 	MV_CRQB_Q_SZ		= (32 * MV_MAX_Q_DEPTH),
 	MV_CRPB_Q_SZ		= (8 * MV_MAX_Q_DEPTH),
 	MV_MAX_SG_CT		= 256,
@@ -3975,17 +3978,17 @@ done:
 static int mv_create_dma_pools(struct mv_host_priv *hpriv, struct device *dev)
 {
 	hpriv->crqb_pool   = dmam_pool_create("crqb_q", dev, MV_CRQB_Q_SZ,
-							     MV_CRQB_Q_SZ, 0);
+							MV_CRQB_Q_ALIGN, 0);
 	if (!hpriv->crqb_pool)
 		return -ENOMEM;
 
 	hpriv->crpb_pool   = dmam_pool_create("crpb_q", dev, MV_CRPB_Q_SZ,
-							     MV_CRPB_Q_SZ, 0);
+							MV_CRPB_Q_ALIGN, 0);
 	if (!hpriv->crpb_pool)
 		return -ENOMEM;
 
 	hpriv->sg_tbl_pool = dmam_pool_create("sg_tbl", dev, MV_SG_TBL_SZ,
-							     MV_SG_TBL_SZ, 0);
+							MV_SG_TBL_ALIGN, 0);
 	if (!hpriv->sg_tbl_pool)
 		return -ENOMEM;
 
-- 
1.8.1.1


^ permalink raw reply related	[flat|nested] 59+ messages in thread

* Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16 15:50                         ` [PATCH] ata: sata_mv: fix sg_tbl_pool alignment Jason Cooper
@ 2013-01-16 17:05                           ` Soeren Moch
  2013-01-16 17:52                             ` Jason Cooper
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-16 17:05 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 16:50, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>> On 16.01.2013 04:24, Soeren Moch wrote:
>>> On 16.01.2013 03:40, Jason Cooper wrote:
>>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>
>> OK, I could trigger the error
>>    ERROR: 1024 KiB atomic DMA coherent pool is too small!
>>    Please increase it with coherent_pool= kernel parameter!
>> only with em28xx sticks and sata, dib0700 sticks removed.
>
> Did you test the reverse scenario?  ie dib0700 with sata_mv and no
> em28xx.

Maybe I can test this next night.

> What kind of throughput are you pushing to the sata disk?

Close to nothing. In the last test I had the root filesystem running
on the sata disk plus a few 10 megabytes per hour.

>>>> What would be most helpful is if you could do a git bisect between
>>>> v3.5.x (working) and the oldest version where you know it started
>>>> failing (v3.7.1 or earlier if you know it).
>>>>
>>> I did not bisect it, but Marek mentioned earlier that commit
>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>> new code for dma allocations. This is probably the root cause for the
>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>
>> I don't want to say that Mareks patch is wrong, probably it triggers a
>> bug somewhere else! (in em28xx?)
>
> Of the four drivers you listed, none are using dma.  sata_mv is the only
> one.

usb_core is doing the actual DMA for the usb bridge drivers, I think.

> If one is to believe the comments in sata_mv.c:~151, then the alignment
> is wrong for the sg_tbl_pool.
>
> Could you please try the following patch?

OK, what should I test first, the setup from last night (em28xx, no
dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
without your patch, or my normal setting (all dvb sticks) plus your
patch?

Regards,
Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16  8:55                       ` Soeren Moch
  2013-01-16 15:50                         ` [PATCH] ata: sata_mv: fix sg_tbl_pool alignment Jason Cooper
@ 2013-01-16 17:32                         ` Soeren Moch
  2013-01-16 17:47                           ` Jason Cooper
  1 sibling, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-16 17:32 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 09:55, Soeren Moch wrote:
> On 16.01.2013 04:24, Soeren Moch wrote:
>> On 16.01.2013 03:40, Jason Cooper wrote:
>>> Soeren,
>>>
>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>>>> If my understanding is correct, one of the drivers (most likely one)
>>>>>> either asks for too small of a dma buffer, or is not properly
>>>>>> deallocating blocks from the per-device pool.  Either case leads to
>>>>>> exhaustion, and falling back to the atomic pool.  Which subsequently
>>>>>> gets wiped out as well.
>>>>>
>>>>> If my hunch is right, could you please try each of the three dvb
>>>>> drivers
>>>>> in turn and see which one (or more than one) causes the error?
>>>>
>>>> In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
>>>> demodulator, and dib0700 usb bridge plus dib7000p demod.
>>>>
>>>> I would bet for em28xx causing the error, but this is not thoroughly
>>>> tested. Unfortunately testing with removed sticks is not easy, because
>>>> this is a production system and disabling some services for the long
>>>> time we need to trigger this error will certainly result in unhappy
>>>> users.
>>>
> OK, I could trigger the error
>    ERROR: 1024 KiB atomic DMA coherent pool is too small!
>    Please increase it with coherent_pool= kernel parameter!
> only with em28xx sticks and sata, dib0700 sticks removed.
>
>>> Just out of curiosity, what board is it?
>>
>> The kirkwood board? A modified Guruplug Server Plus.
> em28xx sticks: "TerraTec Cinergy HTC Stick HD" and "PCTV Quatro Stick"
> dib0700 sticks: "WinTV-NOVA-TD Stick"
>>>
>>>> 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.
>>>
>>>> In linux-3.5.x there is no such problem. Can we use all available
>>>> memory
>>>> for dma buffers here on armv5 architectures, in contrast to newer
>>>> kernels?
>>>
>>> Were the loads exactly the same when you tested 3.5.x?
>>
>> Exactly the same, yes.
>>
>>> I looked at the
>>> changes from v3.5 to v3.7.1 for all four drivers you mentioned as well
>>> as sata_mv.
>>>
>>> The biggest thing I see is that all of the media drivers got shuffled
>>> around into their own subdirectories after v3.5.  'git show -M 0c0d06c'
>>> shows it was a clean copy of all the files.
>>>
>>> What would be most helpful is if you could do a git bisect between
>>> v3.5.x (working) and the oldest version where you know it started
>>> failing (v3.7.1 or earlier if you know it).
>>>
>> I did not bisect it, but Marek mentioned earlier that commit
>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>> new code for dma allocations. This is probably the root cause for the
>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>
> I don't want to say that Mareks patch is wrong, probably it triggers a
> bug somewhere else! (in em28xx?)

The em28xx sticks are using isochronous usb transfers. Is there a
special handling for that?

>> I'm not very familiar with arm mm code, and from the patch itself I
>> cannot understand what's different. Maybe CONFIG_CMA is default
>> also for armv5 (not only v6) now? But I might be totally wrong here,
>> maybe someone of the mm experts can explain the difference?
>>
Regards,
Soeren



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16 17:32                         ` [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Soeren Moch
@ 2013-01-16 17:47                           ` Jason Cooper
  2013-01-16 22:36                             ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2013-01-16 17:47 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
> On 16.01.2013 09:55, Soeren Moch wrote:
> >On 16.01.2013 04:24, Soeren Moch wrote:
> >>I did not bisect it, but Marek mentioned earlier that commit
> >>e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> >>new code for dma allocations. This is probably the root cause for the
> >>new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
> >
> >I don't want to say that Mareks patch is wrong, probably it triggers a
> >bug somewhere else! (in em28xx?)
> 
> The em28xx sticks are using isochronous usb transfers. Is there a
> special handling for that?

I'm looking at that now.  It looks like the em28xx wants (as a maximum)
655040 bytes (em28xx-core.c:1088).  There are 5 transfer buffers, with
64 max packets and 2047 max packet size (runtime reported max & 0x7ff).

If it actually needs all of that, then the answer may be to just
increase coherent_pool= when using that driver.  I'll keep digging.

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16 17:05                           ` Soeren Moch
@ 2013-01-16 17:52                             ` Jason Cooper
  2013-01-16 18:35                               ` Jason Cooper
                                                 ` (2 more replies)
  0 siblings, 3 replies; 59+ messages in thread
From: Jason Cooper @ 2013-01-16 17:52 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Wed, Jan 16, 2013 at 06:05:59PM +0100, Soeren Moch wrote:
> On 16.01.2013 16:50, Jason Cooper wrote:
> >On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
> >>On 16.01.2013 04:24, Soeren Moch wrote:
> >>>On 16.01.2013 03:40, Jason Cooper wrote:
> >>>>On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
> >>>>>On 15.01.2013 22:56, Jason Cooper wrote:
> >>>>>>On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> >
> >>OK, I could trigger the error
> >>   ERROR: 1024 KiB atomic DMA coherent pool is too small!
> >>   Please increase it with coherent_pool= kernel parameter!
> >>only with em28xx sticks and sata, dib0700 sticks removed.
> >
> >Did you test the reverse scenario?  ie dib0700 with sata_mv and no
> >em28xx.
> 
> Maybe I can test this next night.

Please do, this will tell us if it is in the USB drivers or lower
(something in common).

> >>>>What would be most helpful is if you could do a git bisect between
> >>>>v3.5.x (working) and the oldest version where you know it started
> >>>>failing (v3.7.1 or earlier if you know it).
> >>>>
> >>>I did not bisect it, but Marek mentioned earlier that commit
> >>>e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> >>>new code for dma allocations. This is probably the root cause for the
> >>>new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
> >>
> >>I don't want to say that Mareks patch is wrong, probably it triggers a
> >>bug somewhere else! (in em28xx?)
> >
> >Of the four drivers you listed, none are using dma.  sata_mv is the only
> >one.
> 
> usb_core is doing the actual DMA for the usb bridge drivers, I think.

Yes, my mistake.  I'd like to attribute that statement to pre-coffee
rambling. :-)

> >If one is to believe the comments in sata_mv.c:~151, then the alignment
> >is wrong for the sg_tbl_pool.
> >
> >Could you please try the following patch?
> 
> OK, what should I test first, the setup from last night (em28xx, no
> dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
> without your patch, or my normal setting (all dvb sticks) plus your
> patch?

if testing time is limited, please do the test I outlined at the top of
this email.  I've been digging more into the dma code and while I think
the patch is correct, I don't see where it would fix your problem (yet).

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16 17:52                             ` Jason Cooper
@ 2013-01-16 18:35                               ` Jason Cooper
  2013-01-16 22:26                                 ` Soeren Moch
  2013-01-16 23:10                               ` Soeren Moch
  2013-01-17  9:11                               ` Soeren Moch
  2 siblings, 1 reply; 59+ messages in thread
From: Jason Cooper @ 2013-01-16 18:35 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Thomas Petazzoni, Andrew Lunn, Arnd Bergmann, linux-arm-kernel,
	Greg KH, linux-kernel, Michal Hocko, linux-mm, Kyungmin Park,
	Mel Gorman, Andrew Morton, Sebastian Hesselbarth, linaro-mm-sig,
	KAMEZAWA Hiroyuki, Marek Szyprowski

> > >On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
> > >>I don't want to say that Mareks patch is wrong, probably it triggers a
> > >>bug somewhere else! (in em28xx?)

Could you send the output of:

lsusb -v -d VEND:PROD

for the em28xx?

thx,

Jason.

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16 18:35                               ` Jason Cooper
@ 2013-01-16 22:26                                 ` Soeren Moch
  0 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-16 22:26 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Thomas Petazzoni, Andrew Lunn, Arnd Bergmann, linux-arm-kernel,
	Greg KH, linux-kernel, Michal Hocko, linux-mm, Kyungmin Park,
	Mel Gorman, Andrew Morton, Sebastian Hesselbarth, linaro-mm-sig,
	KAMEZAWA Hiroyuki, Marek Szyprowski

On 16.01.2013 19:35, Jason Cooper wrote:
>>>> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>>>>> I don't want to say that Mareks patch is wrong, probably it triggers a
>>>>> bug somewhere else! (in em28xx?)
>
> Could you send the output of:
>
> lsusb -v -d VEND:PROD
>
> for the em28xx?
>
> thx,
>
> Jason.
>

Here is the lsusb output for both of my em28xx sticks.

Regards,
Soeren


Bus 001 Device 005: ID 0ccd:00b2 TerraTec Electronic GmbH
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               2.00
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0        64
   idVendor           0x0ccd TerraTec Electronic GmbH
   idProduct          0x00b2
   bcdDevice            1.00
   iManufacturer           3 TERRATEC
   iProduct                1 Cinergy HTC Stick
   iSerial                 2 123456789ABCD
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength          305
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0x80
       (Bus Powered)
     MaxPower              500mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       1
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       2
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0ad0  2x 720 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       3
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0c00  2x 1024 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       4
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x1300  3x 768 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       5
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x1380  3x 896 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       6
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x13c0  3x 960 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       7
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x1400  3x 1024 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
Device Qualifier (for other device speed):
   bLength                10
   bDescriptorType         6
   bcdUSB               2.00
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0        64
   bNumConfigurations      1
Device Status:     0x0000
   (Bus Powered)





Bus 001 Device 009: ID 2304:0242 Pinnacle Systems, Inc.
Device Descriptor:
   bLength                18
   bDescriptorType         1
   bcdUSB               2.00
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0        64
   idVendor           0x2304 Pinnacle Systems, Inc.
   idProduct          0x0242
   bcdDevice            1.00
   iManufacturer           1 Pinnacle Systems
   iProduct                2 PCTV 510e
   iSerial                 3 123456789012
   bNumConfigurations      1
   Configuration Descriptor:
     bLength                 9
     bDescriptorType         2
     wTotalLength          305
     bNumInterfaces          1
     bConfigurationValue     1
     iConfiguration          0
     bmAttributes         0x80
       (Bus Powered)
     MaxPower              500mA
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       0
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       1
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0000  1x 0 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       2
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0ad0  2x 720 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       3
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0c00  2x 1024 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       4
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x1300  3x 768 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       5
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x1380  3x 896 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       6
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x13c0  3x 960 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
     Interface Descriptor:
       bLength                 9
       bDescriptorType         4
       bInterfaceNumber        0
       bAlternateSetting       7
       bNumEndpoints           4
       bInterfaceClass       255 Vendor Specific Class
       bInterfaceSubClass      0
       bInterfaceProtocol    255
       iInterface              0
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x81  EP 1 IN
         bmAttributes            3
           Transfer Type            Interrupt
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x0001  1x 1 bytes
         bInterval              11
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x82  EP 2 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x1400  3x 1024 bytes
         bInterval               1
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x83  EP 3 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x00c4  1x 196 bytes
         bInterval               4
       Endpoint Descriptor:
         bLength                 7
         bDescriptorType         5
         bEndpointAddress     0x84  EP 4 IN
         bmAttributes            1
           Transfer Type            Isochronous
           Synch Type               None
           Usage Type               Data
         wMaxPacketSize     0x03ac  1x 940 bytes
         bInterval               1
Device Qualifier (for other device speed):
   bLength                10
   bDescriptorType         6
   bcdUSB               2.00
   bDeviceClass            0 (Defined at Interface level)
   bDeviceSubClass         0
   bDeviceProtocol         0
   bMaxPacketSize0        64
   bNumConfigurations      1
Device Status:     0x0000
   (Bus Powered)


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16 17:47                           ` Jason Cooper
@ 2013-01-16 22:36                             ` Soeren Moch
  0 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-16 22:36 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 18:47, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
>> On 16.01.2013 09:55, Soeren Moch wrote:
>>> On 16.01.2013 04:24, Soeren Moch wrote:
>>>> I did not bisect it, but Marek mentioned earlier that commit
>>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>>> new code for dma allocations. This is probably the root cause for the
>>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>>
>>> I don't want to say that Mareks patch is wrong, probably it triggers a
>>> bug somewhere else! (in em28xx?)
>>
>> The em28xx sticks are using isochronous usb transfers. Is there a
>> special handling for that?
>
> I'm looking at that now.  It looks like the em28xx wants (as a maximum)
> 655040 bytes (em28xx-core.c:1088).  There are 5 transfer buffers, with
> 64 max packets and 2047 max packet size (runtime reported max & 0x7ff).
>
> If it actually needs all of that, then the answer may be to just
> increase coherent_pool= when using that driver.  I'll keep digging.

I already tested with 4M coherent pool size and could not see
significant improvement. Would it make sense to further increase the
buffer size?

Regards,
Soeren




^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16 17:52                             ` Jason Cooper
  2013-01-16 18:35                               ` Jason Cooper
@ 2013-01-16 23:10                               ` Soeren Moch
  2013-01-17  9:11                               ` Soeren Moch
  2 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-16 23:10 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 18:52, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 06:05:59PM +0100, Soeren Moch wrote:
>> On 16.01.2013 16:50, Jason Cooper wrote:
>>> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>>>> On 16.01.2013 04:24, Soeren Moch wrote:
>>>>> On 16.01.2013 03:40, Jason Cooper wrote:
>>>>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>
>>>> OK, I could trigger the error
>>>>    ERROR: 1024 KiB atomic DMA coherent pool is too small!
>>>>    Please increase it with coherent_pool= kernel parameter!
>>>> only with em28xx sticks and sata, dib0700 sticks removed.
>>>
>>> Did you test the reverse scenario?  ie dib0700 with sata_mv and no
>>> em28xx.
>>
>> Maybe I can test this next night.
>
> Please do, this will tell us if it is in the USB drivers or lower
> (something in common).
>
>>>>>> What would be most helpful is if you could do a git bisect between
>>>>>> v3.5.x (working) and the oldest version where you know it started
>>>>>> failing (v3.7.1 or earlier if you know it).
>>>>>>
>>>>> I did not bisect it, but Marek mentioned earlier that commit
>>>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>>>> new code for dma allocations. This is probably the root cause for the
>>>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>>>
>>>> I don't want to say that Mareks patch is wrong, probably it triggers a
>>>> bug somewhere else! (in em28xx?)
>>>
>>> Of the four drivers you listed, none are using dma.  sata_mv is the only
>>> one.
>>
>> usb_core is doing the actual DMA for the usb bridge drivers, I think.
>
> Yes, my mistake.  I'd like to attribute that statement to pre-coffee
> rambling. :-)
>
>>> If one is to believe the comments in sata_mv.c:~151, then the alignment
>>> is wrong for the sg_tbl_pool.
>>>
>>> Could you please try the following patch?
>>
>> OK, what should I test first, the setup from last night (em28xx, no
>> dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
>> without your patch, or my normal setting (all dvb sticks) plus your
>> patch?
>
> if testing time is limited, please do the test I outlined at the top of
> this email.  I've been digging more into the dma code and while I think
> the patch is correct, I don't see where it would fix your problem (yet).

Unfortunately test time is limited, and the test has to run about
10 hours to trigger the error.

I also think that sata is not causing the problem.
Maybe your patch even goes in the wrong direction. Perhaps the dma
memory pool is not too small, there might be enough memory available,
but it is too much fragmented to satisfy larger block allocations. With 
different drivers allocating totally different block sizes aligned to
bytes or words, perhaps we end up with lots of very small free blocks
in the dma pool after several hours of runtime?
So maybe it would help to align all allocations in the dma pool to 256B?

Regards,
Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
  2013-01-16 17:52                             ` Jason Cooper
  2013-01-16 18:35                               ` Jason Cooper
  2013-01-16 23:10                               ` Soeren Moch
@ 2013-01-17  9:11                               ` Soeren Moch
  2 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-17  9:11 UTC (permalink / raw)
  To: Jason Cooper
  Cc: Greg KH, Thomas Petazzoni, Andrew Lunn, Arnd Bergmann,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 16.01.2013 18:52, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 06:05:59PM +0100, Soeren Moch wrote:
>> On 16.01.2013 16:50, Jason Cooper wrote:
>>> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>>>> On 16.01.2013 04:24, Soeren Moch wrote:
>>>>> On 16.01.2013 03:40, Jason Cooper wrote:
>>>>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>
>>>> OK, I could trigger the error
>>>>    ERROR: 1024 KiB atomic DMA coherent pool is too small!
>>>>    Please increase it with coherent_pool= kernel parameter!
>>>> only with em28xx sticks and sata, dib0700 sticks removed.
>>>
>>> Did you test the reverse scenario?  ie dib0700 with sata_mv and no
>>> em28xx.
>>
>> Maybe I can test this next night.
>
> Please do, this will tell us if it is in the USB drivers or lower
> (something in common).

Until now there is no error with dib0700 + sata, without em28xx.

But to be sure that there is absolutely no problem with this setting
we probably need additional testing hours.
BTW, these dib0700 sticks use usb bulk transfers (and maybe smaller
dma buffers?).

Regards,
Soeren



^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-16  3:24                     ` Soeren Moch
  2013-01-16  8:55                       ` Soeren Moch
@ 2013-01-17 10:49                       ` Arnd Bergmann
  2013-01-17 13:47                         ` Soeren Moch
  1 sibling, 1 reply; 59+ messages in thread
From: Arnd Bergmann @ 2013-01-17 10:49 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Wednesday 16 January 2013, Soeren Moch wrote:
> >> 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.
> >

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

	Arnd

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-17 10:49                       ` Arnd Bergmann
@ 2013-01-17 13:47                         ` Soeren Moch
  2013-01-17 20:26                           ` Arnd Bergmann
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-17 13:47 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 17.01.2013 11:49, Arnd Bergmann wrote:
> On Wednesday 16 January 2013, Soeren Moch wrote:
>>>> 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.
>>>
>
> 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?

Soeren

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-17 13:47                         ` Soeren Moch
@ 2013-01-17 20:26                           ` Arnd Bergmann
  2013-01-19 15:29                             ` Soeren Moch
  2013-01-19 16:24                             ` Andrew Lunn
  0 siblings, 2 replies; 59+ messages in thread
From: Arnd Bergmann @ 2013-01-17 20:26 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Thursday 17 January 2013, Soeren Moch wrote:
> On 17.01.2013 11:49, Arnd Bergmann wrote:
> > On Wednesday 16 January 2013, Soeren Moch wrote:
> >>>> 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.
> >>>
> >
> > 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

^ permalink raw reply related	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-17 20:26                           ` Arnd Bergmann
@ 2013-01-19 15:29                             ` Soeren Moch
  2013-01-19 18:59                               ` Andrew Lunn
  2013-01-19 20:05                               ` Arnd Bergmann
  2013-01-19 16:24                             ` Andrew Lunn
  1 sibling, 2 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-19 15:29 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

On 17.01.2013 21:26, Arnd Bergmann wrote:
> On Thursday 17 January 2013, Soeren Moch wrote:
>> On 17.01.2013 11:49, Arnd Bergmann wrote:
>>> On Wednesday 16 January 2013, Soeren Moch wrote:
>>>>>> 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.
>>>>>
>>>
>>> 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
>

Please find attached a debug log generated with your patch.

I used the sata disk and two em28xx dvb sticks, no other usb devices,
no ethernet cable connected, tuners on saa716x-based card not used.

What I can see in the log: a lot of coherent mappings from sata_mv and 
orion_ehci, a few from mv643xx_eth, no other coherent mappings.
All coherent mappings are page aligned, some of them (from orion_ehci)
are not really small (as claimed in __alloc_from_pool).

I don't believe in a memory leak. When I restart vdr (the application
utilizing the dvb sticks) then there is enough dma memory available
again.

Regards,
Soeren



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: dma_debug.log --]
[-- Type: text/x-log; name="dma_debug.log", Size: 215198 bytes --]


Jan 19 13:54:58 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool is too small!
Jan 19 13:54:58 guruvdr kernel: Please increase it with coherent_pool= kernel parameter!
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 0 P=20a03000 D=1f001000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 1 P=20a05000 D=1f002000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 1 P=20a07000 D=1f003000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 3 P=20a09000 D=1f006000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 3 P=20a0b000 D=1f007000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 4 P=20a2d000 D=1f008000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 4 P=20a2f000 D=1f009000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 5 P=20a31000 D=1f00a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 5 P=20a33000 D=1f00b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 6 P=20a35000 D=1f00c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 6 P=20a37000 D=1f00d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 7 P=20a39000 D=1f00e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 7 P=20a3b000 D=1f00f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 8 P=20a1d000 D=1f010000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 8 P=20a1f000 D=1f011000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 9 P=20a21000 D=1f012000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 9 P=20a23000 D=1f013000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 10 P=20a25000 D=1f014000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 10 P=20a27000 D=1f015000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 11 P=20a29000 D=1f016000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 11 P=20a2b000 D=1f017000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 12 P=20a15000 D=1f018000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 12 P=20a17000 D=1f019000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 13 P=20a19000 D=1f01a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 13 P=20a1b000 D=1f01b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 14 P=20a53000 D=1f01c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 14 P=20a55000 D=1f01d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 15 P=20a57000 D=1f01e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 15 P=20a59000 D=1f01f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 16 P=20a3d000 D=1f021000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 17 P=20a3f000 D=1f022000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 17 P=20a41000 D=1f023000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 18 P=20a43000 D=1f024000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 18 P=20a45000 D=1f025000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 19 P=20a4f000 D=1f026000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 19 P=20a51000 D=1f027000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 20 P=20a5b000 D=1f028000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 20 P=20a5d000 D=1f029000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 21 P=20a5f000 D=1f02a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 21 P=20a61000 D=1f02b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 22 P=20a63000 D=1f02c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 22 P=20a65000 D=1f02d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 23 P=20a67000 D=1f02e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 23 P=20a69000 D=1f02f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: coherent idx 42 P=21495000 D=1c855000 L=800 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 49 P=20a6e000 D=1f062000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 49 P=20a70000 D=1f063000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 50 P=20a72000 D=1f064000 L=800 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: single idx 54 P=1f06c2c0 D=1f06c2c0 L=1 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c088020 D=1c088020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c088700 D=1c088700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c088de0 D=1c088de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c0894c0 D=1c0894c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c089ba0 D=1c089ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08a280 D=1c08a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08a960 D=1c08a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08b040 D=1c08b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08b720 D=1c08b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08be00 D=1c08be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08c4e0 D=1c08c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08cbc0 D=1c08cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08d2a0 D=1c08d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08d980 D=1c08d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08e060 D=1c08e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08e740 D=1c08e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08ee20 D=1c08ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08f500 D=1c08f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c090020 D=1c090020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c090700 D=1c090700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c090de0 D=1c090de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c0914c0 D=1c0914c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c091ba0 D=1c091ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c092280 D=1c092280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c092960 D=1c092960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c093040 D=1c093040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c093720 D=1c093720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c093e00 D=1c093e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c0944e0 D=1c0944e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c094bc0 D=1c094bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c0952a0 D=1c0952a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c095980 D=1c095980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c096060 D=1c096060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c096740 D=1c096740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c096e20 D=1c096e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c097500 D=1c097500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c098020 D=1c098020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c098700 D=1c098700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c098de0 D=1c098de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c0994c0 D=1c0994c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c099ba0 D=1c099ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09a280 D=1c09a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09a960 D=1c09a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09b040 D=1c09b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09b720 D=1c09b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09be00 D=1c09be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 78 P=1c09c4e0 D=1c09c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 78 P=1c09cbc0 D=1c09cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 128 P=20804000 D=1f900000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 128 P=20805000 D=1f901000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 129 P=20806000 D=1f902000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 129 P=20807000 D=1f903000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 130 P=20808000 D=1f904000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 130 P=20809000 D=1f905000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 131 P=2080a000 D=1f906000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 131 P=2080b000 D=1f907000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 132 P=2080c000 D=1f908000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 132 P=2080d000 D=1f909000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 133 P=2080e000 D=1f90a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 133 P=2080f000 D=1f90b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 134 P=20810000 D=1f90c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 134 P=20811000 D=1f90d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 135 P=20812000 D=1f90e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 135 P=20813000 D=1f90f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 136 P=20814000 D=1f910000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 136 P=20815000 D=1f911000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 137 P=20816000 D=1f912000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 137 P=20817000 D=1f913000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 138 P=20818000 D=1f914000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 138 P=20819000 D=1f915000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 139 P=2081a000 D=1f916000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 139 P=2081b000 D=1f917000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 140 P=2081c000 D=1f918000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 140 P=2081d000 D=1f919000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 141 P=2081e000 D=1f91a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 141 P=2081f000 D=1f91b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 142 P=20820000 D=1f91c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 142 P=20821000 D=1f91d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 143 P=20822000 D=1f91e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 143 P=20823000 D=1f91f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 144 P=20824000 D=1f920000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 144 P=20825000 D=1f921000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 145 P=20826000 D=1f922000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 145 P=20827000 D=1f923000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 146 P=20828000 D=1f924000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 146 P=20829000 D=1f925000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 147 P=2082a000 D=1f926000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 147 P=2082b000 D=1f927000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 148 P=2082c000 D=1f928000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 148 P=2082d000 D=1f929000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 149 P=2082e000 D=1f92a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 149 P=2082f000 D=1f92b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 150 P=20830000 D=1f92c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 150 P=20831000 D=1f92d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 151 P=20832000 D=1f92e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 151 P=20833000 D=1f92f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 152 P=20834000 D=1f930000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 152 P=20835000 D=1f931000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 153 P=20836000 D=1f932000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 153 P=20837000 D=1f933000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 154 P=20838000 D=1f934000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 154 P=20839000 D=1f935000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 155 P=2083a000 D=1f936000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 155 P=2083b000 D=1f937000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 156 P=2083c000 D=1f938000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 156 P=2083d000 D=1f939000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 157 P=2083e000 D=1f93a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 157 P=2083f000 D=1f93b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 158 P=20840000 D=1f93c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 158 P=20841000 D=1f93d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 159 P=20842000 D=1f93e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 159 P=20843000 D=1f93f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 160 P=20844000 D=1f940000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 160 P=20845000 D=1f941000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 161 P=20846000 D=1f942000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 161 P=20847000 D=1f943000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 162 P=20848000 D=1f944000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 162 P=20849000 D=1f945000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 163 P=2084a000 D=1f946000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 163 P=2084b000 D=1f947000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 164 P=2084c000 D=1f948000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 164 P=2084d000 D=1f949000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 165 P=2084e000 D=1f94a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 165 P=2084f000 D=1f94b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 166 P=20850000 D=1f94c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 166 P=20851000 D=1f94d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 167 P=20852000 D=1f94e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 167 P=20853000 D=1f94f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 168 P=20854000 D=1f950000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 168 P=20855000 D=1f951000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 169 P=20856000 D=1f952000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 169 P=20857000 D=1f953000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 170 P=20858000 D=1f954000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 170 P=20859000 D=1f955000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 171 P=2085a000 D=1f956000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 171 P=2085b000 D=1f957000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 172 P=2085c000 D=1f958000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 172 P=2085d000 D=1f959000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 173 P=2085e000 D=1f95a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 173 P=2085f000 D=1f95b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 174 P=20860000 D=1f95c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 174 P=20861000 D=1f95d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 175 P=20862000 D=1f95e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 175 P=20863000 D=1f95f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 176 P=20864000 D=1f960000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 176 P=20865000 D=1f961000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 177 P=20866000 D=1f962000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 177 P=20867000 D=1f963000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 178 P=20868000 D=1f964000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 178 P=20869000 D=1f965000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 179 P=2086a000 D=1f966000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 179 P=2086b000 D=1f967000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 180 P=2086c000 D=1f968000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 180 P=2086d000 D=1f969000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 181 P=2086e000 D=1f96a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 181 P=2086f000 D=1f96b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 182 P=20870000 D=1f96c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 182 P=20871000 D=1f96d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 183 P=20872000 D=1f96e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 183 P=20873000 D=1f96f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 184 P=20874000 D=1f970000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 184 P=20875000 D=1f971000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 185 P=20876000 D=1f972000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 185 P=20877000 D=1f973000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 186 P=20878000 D=1f974000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 186 P=20879000 D=1f975000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 187 P=2087a000 D=1f976000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 187 P=2087b000 D=1f977000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 188 P=2087c000 D=1f978000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 188 P=2087d000 D=1f979000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 189 P=2087e000 D=1f97a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 189 P=2087f000 D=1f97b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 190 P=20880000 D=1f97c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 190 P=20881000 D=1f97d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 191 P=20882000 D=1f97e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 191 P=20883000 D=1f97f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 192 P=20884000 D=1f980000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 192 P=20885000 D=1f981000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 193 P=20886000 D=1f982000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 193 P=20887000 D=1f983000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 194 P=20888000 D=1f984000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 194 P=20889000 D=1f985000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 195 P=2088a000 D=1f986000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 195 P=2088b000 D=1f987000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 196 P=2088c000 D=1f988000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 196 P=2088d000 D=1f989000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 197 P=2088e000 D=1f98a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 197 P=2088f000 D=1f98b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 198 P=20890000 D=1f98c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 198 P=20891000 D=1f98d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 199 P=20892000 D=1f98e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 199 P=20893000 D=1f98f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 200 P=210c1000 D=1c990000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 200 P=20894000 D=1f990000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 200 P=20895000 D=1f991000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 201 P=20896000 D=1f992000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 201 P=20897000 D=1f993000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 202 P=20898000 D=1f994000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 202 P=20899000 D=1f995000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 203 P=2089a000 D=1f996000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 203 P=2089b000 D=1f997000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 204 P=2089c000 D=1f998000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 204 P=2089d000 D=1f999000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 205 P=2089e000 D=1f99a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 205 P=2089f000 D=1f99b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 206 P=208a0000 D=1f99c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 206 P=208a1000 D=1f99d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 207 P=208a2000 D=1f99e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 207 P=208a3000 D=1f99f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 208 P=210d1000 D=1c9a0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 208 P=208a4000 D=1f9a0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 208 P=208a5000 D=1f9a1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 209 P=208a6000 D=1f9a2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 209 P=208a7000 D=1f9a3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 210 P=208a8000 D=1f9a4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 210 P=208a9000 D=1f9a5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 211 P=208aa000 D=1f9a6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 211 P=208ab000 D=1f9a7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 212 P=208ac000 D=1f9a8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 212 P=208ad000 D=1f9a9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 213 P=208ae000 D=1f9aa000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 213 P=208af000 D=1f9ab000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 214 P=208b0000 D=1f9ac000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 214 P=208b1000 D=1f9ad000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 215 P=208b2000 D=1f9ae000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 215 P=208b3000 D=1f9af000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 216 P=210e1000 D=1c9b0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 216 P=208b4000 D=1f9b0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 216 P=208b5000 D=1f9b1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 217 P=208b6000 D=1f9b2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 217 P=208b7000 D=1f9b3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 218 P=208b8000 D=1f9b4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 218 P=208b9000 D=1f9b5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: single idx 219 P=1f1b6580 D=1f1b6580 L=1 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 219 P=208ba000 D=1f9b6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 219 P=208bb000 D=1f9b7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 220 P=208bc000 D=1f9b8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 220 P=208bd000 D=1f9b9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 221 P=208be000 D=1f9ba000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 221 P=208bf000 D=1f9bb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 222 P=208c0000 D=1f9bc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 222 P=208c1000 D=1f9bd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 223 P=208c2000 D=1f9be000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 223 P=208c3000 D=1f9bf000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 224 P=210f1000 D=1c9c0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 224 P=208c4000 D=1f9c0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 224 P=208c5000 D=1f9c1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 225 P=208c6000 D=1f9c2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 225 P=208c7000 D=1f9c3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 226 P=208c8000 D=1f9c4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 226 P=208c9000 D=1f9c5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 227 P=208ca000 D=1f9c6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 227 P=208cb000 D=1f9c7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 228 P=20ba6000 D=1f1c8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 228 P=208cc000 D=1f9c8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 228 P=208cd000 D=1f9c9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 229 P=208ce000 D=1f9ca000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 229 P=208cf000 D=1f9cb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 230 P=208d0000 D=1f9cc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 230 P=208d1000 D=1f9cd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 231 P=208d2000 D=1f9ce000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 231 P=208d3000 D=1f9cf000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 232 P=21101000 D=1c9d0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 232 P=208d4000 D=1f9d0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 232 P=208d5000 D=1f9d1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 233 P=208d6000 D=1f9d2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 233 P=208d7000 D=1f9d3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 234 P=208d8000 D=1f9d4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 234 P=208d9000 D=1f9d5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 235 P=208da000 D=1f9d6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 235 P=208db000 D=1f9d7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 236 P=208dc000 D=1f9d8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 236 P=208dd000 D=1f9d9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 237 P=208de000 D=1f9da000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 237 P=208df000 D=1f9db000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 238 P=208e0000 D=1f9dc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 238 P=208e1000 D=1f9dd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 239 P=208e2000 D=1f9de000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 239 P=208e3000 D=1f9df000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 240 P=208e4000 D=1f9e0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 240 P=208e5000 D=1f9e1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 241 P=208e6000 D=1f9e2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 241 P=208e7000 D=1f9e3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 242 P=208e8000 D=1f9e4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 242 P=208e9000 D=1f9e5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 243 P=208ea000 D=1f9e6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 243 P=208eb000 D=1f9e7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 244 P=208ec000 D=1f9e8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 244 P=208ed000 D=1f9e9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 245 P=208ee000 D=1f9ea000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 245 P=208ef000 D=1f9eb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 246 P=208f0000 D=1f9ec000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 246 P=208f1000 D=1f9ed000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 247 P=208f2000 D=1f9ee000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 247 P=208f3000 D=1f9ef000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 248 P=208f4000 D=1f9f0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 248 P=208f5000 D=1f9f1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 249 P=208f6000 D=1f9f2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 249 P=208f7000 D=1f9f3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 250 P=208f8000 D=1f9f4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 250 P=208f9000 D=1f9f5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 251 P=208fa000 D=1f9f6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 251 P=208fb000 D=1f9f7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 252 P=208fc000 D=1f9f8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 252 P=208fd000 D=1f9f9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 253 P=208fe000 D=1f9fa000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 253 P=208ff000 D=1f9fb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 254 P=20900000 D=1f9fc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 254 P=20901000 D=1f9fd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 255 P=20902000 D=1f9fe000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 255 P=20903000 D=1f9ff000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 296 P=2111d000 D=1ca50000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 304 P=2112d000 D=1ca60000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 312 P=2113d000 D=1ca70000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 320 P=2114d000 D=1ca80000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 328 P=20a0d000 D=1fa90000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 328 P=20a0f000 D=1fa91000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 328 P=2115d000 D=1ca90000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 329 P=20a11000 D=1fa92000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 329 P=20a13000 D=1fa93000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 342 P=20a47000 D=1faac000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 342 P=20a49000 D=1faad000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 359 P=20a4b000 D=1face000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 359 P=20a4d000 D=1facf000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 392 P=1f311000 D=1f311000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 393 P=1f312000 D=1f312000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 393 P=1f313000 D=1f313000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 394 P=1f314000 D=1f314000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 394 P=1f315000 D=1f315000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 395 P=1f316000 D=1f316000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 395 P=1f317000 D=1f317000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 396 P=1f318000 D=1f318000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 396 P=1f319000 D=1f319000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 397 P=1f31a000 D=1f31a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 397 P=1f31b000 D=1f31b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 398 P=1f31c000 D=1f31c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 398 P=1f31d000 D=1f31d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 399 P=1f31e000 D=1f31e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 399 P=1f31f000 D=1f31f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 400 P=1f320000 D=1f320000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 400 P=1f321000 D=1f321000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 401 P=1f322000 D=1f322000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 401 P=1f323000 D=1f323000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 402 P=1f325000 D=1f325000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 403 P=1f326000 D=1f326000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 403 P=1f327000 D=1f327000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 404 P=1f328000 D=1f328000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 404 P=1f329000 D=1f329000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 405 P=1f32a000 D=1f32a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 405 P=1f32b000 D=1f32b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 406 P=1f32c000 D=1f32c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 406 P=1f32d000 D=1f32d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 407 P=1f32e000 D=1f32e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 407 P=1f32f000 D=1f32f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 408 P=1f330000 D=1f330000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 408 P=1f331000 D=1f331000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 409 P=1f332000 D=1f332000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 409 P=1f333000 D=1f333000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 410 P=1f334000 D=1f334000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 410 P=1f335000 D=1f335000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 411 P=1f337000 D=1f337000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 412 P=1f338000 D=1f338000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 412 P=1f339000 D=1f339000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 413 P=1f33a000 D=1f33a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 413 P=1f33b000 D=1f33b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 414 P=1f33c000 D=1f33c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 414 P=1f33d000 D=1f33d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 415 P=1f33e000 D=1f33e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 415 P=1f33f000 D=1f33f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 416 P=1f340000 D=1f340000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 416 P=1f341000 D=1f341000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 417 P=1f342000 D=1f342000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 417 P=1f343000 D=1f343000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 418 P=1f344000 D=1f344000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 418 P=1f345000 D=1f345000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 419 P=1f346000 D=1f346000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 419 P=1f347000 D=1f347000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 420 P=1f349000 D=1f349000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 421 P=1f34a000 D=1f34a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 421 P=1f34b000 D=1f34b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 422 P=1f34c000 D=1f34c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 422 P=1f34d000 D=1f34d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 423 P=1f34e000 D=1f34e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 423 P=1f34f000 D=1f34f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 424 P=1f350000 D=1f350000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 424 P=1f351000 D=1f351000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb50020 D=1cb50020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb50700 D=1cb50700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb50de0 D=1cb50de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb514c0 D=1cb514c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb51ba0 D=1cb51ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 425 P=1f352000 D=1f352000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 425 P=1f353000 D=1f353000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb52280 D=1cb52280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb52960 D=1cb52960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb53040 D=1cb53040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb53720 D=1cb53720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb53e00 D=1cb53e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 426 P=1f354000 D=1f354000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 426 P=1f355000 D=1f355000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb544e0 D=1cb544e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb54bc0 D=1cb54bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb552a0 D=1cb552a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb55980 D=1cb55980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 427 P=1f356000 D=1f356000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 427 P=1f357000 D=1f357000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb56060 D=1cb56060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb56740 D=1cb56740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb56e20 D=1cb56e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb57500 D=1cb57500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 428 P=1f358000 D=1f358000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 428 P=1f359000 D=1f359000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 429 P=1f35b000 D=1f35b000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 430 P=1f35c000 D=1f35c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 430 P=1f35d000 D=1f35d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 431 P=1f35e000 D=1f35e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 431 P=1f35f000 D=1f35f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 432 P=1f360000 D=1f360000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 432 P=1f361000 D=1f361000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 433 P=1f362000 D=1f362000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 433 P=1f363000 D=1f363000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 434 P=1f364000 D=1f364000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 434 P=1f365000 D=1f365000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 435 P=1f366000 D=1f366000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 435 P=1f367000 D=1f367000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 436 P=1f368000 D=1f368000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 436 P=1f369000 D=1f369000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 437 P=1f36a000 D=1f36a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 437 P=1f36b000 D=1f36b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 438 P=1f36d000 D=1f36d000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 439 P=1f36e000 D=1f36e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 439 P=1f36f000 D=1f36f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 440 P=209e7000 D=1fb71000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 440 P=1f370000 D=1f370000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 440 P=1f371000 D=1f371000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 441 P=209e9000 D=1fb73000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 441 P=1f372000 D=1f372000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 441 P=1f373000 D=1f373000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 442 P=209eb000 D=1fb74000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 442 P=209ed000 D=1fb75000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 442 P=1f374000 D=1f374000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 442 P=1f375000 D=1f375000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 443 P=209ef000 D=1fb76000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 443 P=209f1000 D=1fb77000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 443 P=1f376000 D=1f376000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 443 P=1f377000 D=1f377000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 444 P=209f3000 D=1fb78000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 444 P=209f5000 D=1fb79000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 444 P=1f378000 D=1f378000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 444 P=1f379000 D=1f379000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 445 P=209f7000 D=1fb7a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 445 P=209f9000 D=1fb7b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 445 P=1f37a000 D=1f37a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 445 P=1f37b000 D=1f37b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 446 P=209fb000 D=1fb7c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 446 P=209fd000 D=1fb7d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 446 P=1f37c000 D=1f37c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 446 P=1f37d000 D=1f37d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 447 P=209ff000 D=1fb7e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 447 P=20a01000 D=1fb7f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 447 P=1f37f000 D=1f37f000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 448 P=1f380000 D=1f380000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 448 P=1f381000 D=1f381000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 449 P=1f382000 D=1f382000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 449 P=1f383000 D=1f383000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 450 P=1f384000 D=1f384000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 450 P=1f385000 D=1f385000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 451 P=1f386000 D=1f386000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 451 P=1f387000 D=1f387000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 452 P=1f388000 D=1f388000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 452 P=1f389000 D=1f389000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 453 P=1f38a000 D=1f38a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 453 P=1f38b000 D=1f38b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 454 P=1f38c000 D=1f38c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 454 P=1f38d000 D=1f38d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 455 P=1f38e000 D=1f38e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 455 P=1f38f000 D=1f38f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 456 P=1f391000 D=1f391000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 457 P=1f393000 D=1f393000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 458 P=1f394000 D=1f394000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 458 P=1f395000 D=1f395000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 459 P=1f396000 D=1f396000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 459 P=1f397000 D=1f397000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 460 P=1f398000 D=1f398000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 460 P=1f399000 D=1f399000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 461 P=1f39a000 D=1f39a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 461 P=1f39b000 D=1f39b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 462 P=1f39c000 D=1f39c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 462 P=1f39d000 D=1f39d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 463 P=1f39e000 D=1f39e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 463 P=1f39f000 D=1f39f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 464 P=1f3a0000 D=1f3a0000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 464 P=1f3a1000 D=1f3a1000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 465 P=1f3a2000 D=1f3a2000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 615 P=1eccf000 D=1eccf000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 616 P=1ecd0000 D=1ecd0000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 616 P=1ecd1000 D=1ecd1000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 617 P=1ecd2000 D=1ecd2000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 617 P=1ecd3000 D=1ecd3000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 618 P=1ecd4000 D=1ecd4000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 618 P=1ecd5000 D=1ecd5000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 619 P=1ecd6000 D=1ecd6000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 619 P=1ecd7000 D=1ecd7000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 620 P=1ecd8000 D=1ecd8000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 620 P=1ecd9000 D=1ecd9000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 621 P=1ecda000 D=1ecda000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 621 P=1ecdb000 D=1ecdb000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 622 P=1ecdc000 D=1ecdc000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 622 P=1ecdd000 D=1ecdd000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 623 P=1ecde000 D=1ecde000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 623 P=1ecdf000 D=1ecdf000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 624 P=1ece1000 D=1ece1000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 625 P=1ece2000 D=1ece2000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 625 P=1ece3000 D=1ece3000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 626 P=1ece4000 D=1ece4000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 626 P=1ece5000 D=1ece5000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 627 P=1ece6000 D=1ece6000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 627 P=1ece7000 D=1ece7000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 628 P=1ece8000 D=1ece8000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 628 P=1ece9000 D=1ece9000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 629 P=1ecea000 D=1ecea000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 629 P=1eceb000 D=1eceb000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 630 P=1ecec000 D=1ecec000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 630 P=1eced000 D=1eced000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 632 P=1ecf0000 D=1ecf0000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 632 P=1ecf1000 D=1ecf1000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 633 P=1ecf3000 D=1ecf3000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 634 P=1ecf4000 D=1ecf4000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 634 P=1ecf5000 D=1ecf5000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 635 P=1ecf6000 D=1ecf6000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 635 P=1ecf7000 D=1ecf7000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 636 P=1ecf8000 D=1ecf8000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 636 P=1ecf9000 D=1ecf9000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 637 P=1ecfa000 D=1ecfa000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 637 P=1ecfb000 D=1ecfb000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 638 P=1ecfc000 D=1ecfc000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 638 P=1ecfd000 D=1ecfd000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 639 P=1ecfe000 D=1ecfe000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 639 P=1ecff000 D=1ecff000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 640 P=1ed00000 D=1ed00000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 640 P=1ed01000 D=1ed01000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 641 P=1ed02000 D=1ed02000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 641 P=1ed03000 D=1ed03000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 642 P=1ed05000 D=1ed05000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 643 P=1ed06000 D=1ed06000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 643 P=1ed07000 D=1ed07000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 644 P=1ed08000 D=1ed08000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 644 P=1ed09000 D=1ed09000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 645 P=1ed0a000 D=1ed0a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 645 P=1ed0b000 D=1ed0b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 646 P=1ed0c000 D=1ed0c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 646 P=1ed0d000 D=1ed0d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 647 P=1ed0e000 D=1ed0e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 647 P=1ed0f000 D=1ed0f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 648 P=1ed10000 D=1ed10000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 648 P=1ed11000 D=1ed11000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 649 P=1ed12000 D=1ed12000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 649 P=1ed13000 D=1ed13000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 650 P=1ed14000 D=1ed14000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 650 P=1ed15000 D=1ed15000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 651 P=1ed17000 D=1ed17000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 652 P=1ed18000 D=1ed18000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 652 P=1ed19000 D=1ed19000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 653 P=1ed1a000 D=1ed1a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 653 P=1ed1b000 D=1ed1b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 654 P=1ed1c000 D=1ed1c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 654 P=1ed1d000 D=1ed1d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 655 P=1ed1e000 D=1ed1e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 655 P=1ed1f000 D=1ed1f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 656 P=1ed20000 D=1ed20000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 656 P=1ed21000 D=1ed21000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 657 P=1ed22000 D=1ed22000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 657 P=1ed23000 D=1ed23000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 658 P=1ed24000 D=1ed24000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 658 P=1ed25000 D=1ed25000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 659 P=1ed26000 D=1ed26000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 659 P=1ed27000 D=1ed27000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 660 P=1ed29000 D=1ed29000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 661 P=1ed2a000 D=1ed2a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 661 P=1ed2b000 D=1ed2b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 662 P=1ed2c000 D=1ed2c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 662 P=1ed2d000 D=1ed2d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 663 P=1ed2e000 D=1ed2e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 663 P=1ed2f000 D=1ed2f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 664 P=1ed30000 D=1ed30000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 664 P=1ed31000 D=1ed31000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 665 P=1ed32000 D=1ed32000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 665 P=1ed33000 D=1ed33000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 666 P=1ed34000 D=1ed34000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 666 P=1ed35000 D=1ed35000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 667 P=1ed36000 D=1ed36000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 667 P=1ed37000 D=1ed37000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 668 P=1ed38000 D=1ed38000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 668 P=1ed39000 D=1ed39000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 670 P=1ed3c000 D=1ed3c000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 670 P=1ed3d000 D=1ed3d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 671 P=1ed3e000 D=1ed3e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 671 P=1ed3f000 D=1ed3f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 672 P=1ed40000 D=1ed40000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 672 P=1ed41000 D=1ed41000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 673 P=1ed42000 D=1ed42000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 673 P=1ed43000 D=1ed43000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 674 P=1ed44000 D=1ed44000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 674 P=1ed45000 D=1ed45000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 675 P=1ed46000 D=1ed46000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 675 P=1ed47000 D=1ed47000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 676 P=1ed48000 D=1ed48000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 676 P=1ed49000 D=1ed49000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 677 P=1ed4a000 D=1ed4a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 677 P=1ed4b000 D=1ed4b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 678 P=1ed4c000 D=1ed4c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 679 P=1ed4e000 D=1ed4e000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 679 P=1ed4f000 D=1ed4f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 680 P=1ed50000 D=1ed50000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 680 P=1ed51000 D=1ed51000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 681 P=1ed52000 D=1ed52000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 681 P=1ed53000 D=1ed53000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 682 P=1ed54000 D=1ed54000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 682 P=1ed55000 D=1ed55000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 683 P=1ed56000 D=1ed56000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 683 P=1ed57000 D=1ed57000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 684 P=1ed58000 D=1ed58000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 684 P=1ed59000 D=1ed59000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 685 P=1ed5a000 D=1ed5a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 685 P=1ed5b000 D=1ed5b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 686 P=1ed5c000 D=1ed5c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 686 P=1ed5d000 D=1ed5d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 687 P=1ed5e000 D=1ed5e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee70020 D=1ee70020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee70700 D=1ee70700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee70de0 D=1ee70de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee714c0 D=1ee714c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee71ba0 D=1ee71ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee72280 D=1ee72280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee72960 D=1ee72960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee73040 D=1ee73040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee73720 D=1ee73720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee73e00 D=1ee73e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee744e0 D=1ee744e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee74bc0 D=1ee74bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee752a0 D=1ee752a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee75980 D=1ee75980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee76060 D=1ee76060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee76740 D=1ee76740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee76e20 D=1ee76e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee77500 D=1ee77500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee78020 D=1ee78020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee78700 D=1ee78700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee78de0 D=1ee78de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee794c0 D=1ee794c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee79ba0 D=1ee79ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7a280 D=1ee7a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7a960 D=1ee7a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7b040 D=1ee7b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7b720 D=1ee7b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7be00 D=1ee7be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7c4e0 D=1ee7c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7cbc0 D=1ee7cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7d2a0 D=1ee7d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7d980 D=1ee7d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7e060 D=1ee7e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7e740 D=1ee7e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7ee20 D=1ee7ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7f500 D=1ee7f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee80020 D=1ee80020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee80700 D=1ee80700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee80de0 D=1ee80de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee814c0 D=1ee814c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee81ba0 D=1ee81ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee82280 D=1ee82280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee82960 D=1ee82960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee83040 D=1ee83040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee83720 D=1ee83720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee83e00 D=1ee83e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee844e0 D=1ee844e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee84bc0 D=1ee84bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee852a0 D=1ee852a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee85980 D=1ee85980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee86060 D=1ee86060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee86740 D=1ee86740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee86e20 D=1ee86e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee87500 D=1ee87500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 852 P=1eea8020 D=1eea8020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 852 P=1eea8700 D=1eea8700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eeac8a0 D=1eeac8a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eeacf80 D=1eeacf80 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eead660 D=1eead660 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eeadd40 D=1eeadd40 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeae420 D=1eeae420 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeaeb00 D=1eeaeb00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeaf1e0 D=1eeaf1e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeaf8c0 D=1eeaf8c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb0020 D=1eeb0020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb0700 D=1eeb0700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb0de0 D=1eeb0de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb14c0 D=1eeb14c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb1ba0 D=1eeb1ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb2280 D=1eeb2280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb2960 D=1eeb2960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb3040 D=1eeb3040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb3720 D=1eeb3720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb3e00 D=1eeb3e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb44e0 D=1eeb44e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb4bc0 D=1eeb4bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb52a0 D=1eeb52a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb5980 D=1eeb5980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb6060 D=1eeb6060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb6740 D=1eeb6740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb6e20 D=1eeb6e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb7500 D=1eeb7500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed8020 D=1eed8020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed8700 D=1eed8700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed8de0 D=1eed8de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed94c0 D=1eed94c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed9ba0 D=1eed9ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eeda280 D=1eeda280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eeda960 D=1eeda960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eedb040 D=1eedb040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eedb720 D=1eedb720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eedbe00 D=1eedbe00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedc4e0 D=1eedc4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedcbc0 D=1eedcbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedd2a0 D=1eedd2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedd980 D=1eedd980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eede060 D=1eede060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eede740 D=1eede740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eedee20 D=1eedee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eedf500 D=1eedf500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: coherent idx 885 P=21497000 D=1eeeb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef00020 D=1ef00020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef00700 D=1ef00700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef00de0 D=1ef00de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef014c0 D=1ef014c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef01ba0 D=1ef01ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef02280 D=1ef02280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef02960 D=1ef02960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef03040 D=1ef03040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef03720 D=1ef03720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef03e00 D=1ef03e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef044e0 D=1ef044e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef04bc0 D=1ef04bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef052a0 D=1ef052a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef05980 D=1ef05980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef06060 D=1ef06060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef06740 D=1ef06740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef06e20 D=1ef06e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef07500 D=1ef07500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: coherent idx 918 P=2144c000 D=1ef2c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef38020 D=1ef38020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef38700 D=1ef38700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef38de0 D=1ef38de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef394c0 D=1ef394c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef39ba0 D=1ef39ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3a280 D=1ef3a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3a960 D=1ef3a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3b040 D=1ef3b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3b720 D=1ef3b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3be00 D=1ef3be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3c4e0 D=1ef3c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3cbc0 D=1ef3cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3d2a0 D=1ef3d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3d980 D=1ef3d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3e060 D=1ef3e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3e740 D=1ef3e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3ee20 D=1ef3ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3f500 D=1ef3f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef40020 D=1ef40020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef40700 D=1ef40700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef40de0 D=1ef40de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef414c0 D=1ef414c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef41ba0 D=1ef41ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef42280 D=1ef42280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef42960 D=1ef42960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef43040 D=1ef43040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef43720 D=1ef43720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef43e00 D=1ef43e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef444e0 D=1ef444e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef44bc0 D=1ef44bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef452a0 D=1ef452a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef45980 D=1ef45980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef46060 D=1ef46060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef46740 D=1ef46740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef46e20 D=1ef46e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef47500 D=1ef47500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: coherent idx 933 P=2144a000 D=1ef4b000 L=800 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef70020 D=1ef70020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef70700 D=1ef70700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef70de0 D=1ef70de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef714c0 D=1ef714c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef71ba0 D=1ef71ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef72280 D=1ef72280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef72960 D=1ef72960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef73040 D=1ef73040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef73720 D=1ef73720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef73e00 D=1ef73e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef744e0 D=1ef744e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef74bc0 D=1ef74bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef752a0 D=1ef752a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef75980 D=1ef75980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef76060 D=1ef76060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef76740 D=1ef76740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef76e20 D=1ef76e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef77500 D=1ef77500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef78020 D=1ef78020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef78700 D=1ef78700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef78de0 D=1ef78de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef794c0 D=1ef794c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef79ba0 D=1ef79ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7a280 D=1ef7a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7a960 D=1ef7a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7b040 D=1ef7b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7b720 D=1ef7b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7be00 D=1ef7be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7c4e0 D=1ef7c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7cbc0 D=1ef7cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7d2a0 D=1ef7d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7d980 D=1ef7d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7e060 D=1ef7e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7e740 D=1ef7e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7ee20 D=1ef7ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7f500 D=1ef7f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 0 P=20a03000 D=1f001000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 1 P=20a05000 D=1f002000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 1 P=20a07000 D=1f003000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 3 P=20a09000 D=1f006000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 3 P=20a0b000 D=1f007000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 4 P=20a2d000 D=1f008000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 4 P=20a2f000 D=1f009000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 5 P=20a31000 D=1f00a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 5 P=20a33000 D=1f00b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 6 P=20a35000 D=1f00c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 6 P=20a37000 D=1f00d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 7 P=20a39000 D=1f00e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 7 P=20a3b000 D=1f00f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 8 P=20a1d000 D=1f010000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 8 P=20a1f000 D=1f011000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 9 P=20a21000 D=1f012000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 9 P=20a23000 D=1f013000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 10 P=20a25000 D=1f014000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 10 P=20a27000 D=1f015000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 11 P=20a29000 D=1f016000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 11 P=20a2b000 D=1f017000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 12 P=20a15000 D=1f018000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 12 P=20a17000 D=1f019000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 13 P=20a19000 D=1f01a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 13 P=20a1b000 D=1f01b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 14 P=20a53000 D=1f01c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 14 P=20a55000 D=1f01d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 15 P=20a57000 D=1f01e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 15 P=20a59000 D=1f01f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 16 P=20a3d000 D=1f021000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 17 P=20a3f000 D=1f022000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 17 P=20a41000 D=1f023000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 18 P=20a43000 D=1f024000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 18 P=20a45000 D=1f025000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 19 P=20a4f000 D=1f026000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 19 P=20a51000 D=1f027000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 20 P=20a5b000 D=1f028000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 20 P=20a5d000 D=1f029000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 21 P=20a5f000 D=1f02a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 21 P=20a61000 D=1f02b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 22 P=20a63000 D=1f02c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 22 P=20a65000 D=1f02d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 23 P=20a67000 D=1f02e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 23 P=20a69000 D=1f02f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: coherent idx 42 P=21495000 D=1c855000 L=800 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 49 P=20a6e000 D=1f062000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 49 P=20a70000 D=1f063000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 50 P=20a72000 D=1f064000 L=800 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: single idx 54 P=1f06c2c0 D=1f06c2c0 L=1 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c088020 D=1c088020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c088700 D=1c088700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c088de0 D=1c088de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c0894c0 D=1c0894c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 68 P=1c089ba0 D=1c089ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08a280 D=1c08a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08a960 D=1c08a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08b040 D=1c08b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08b720 D=1c08b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 69 P=1c08be00 D=1c08be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08c4e0 D=1c08c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08cbc0 D=1c08cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08d2a0 D=1c08d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 70 P=1c08d980 D=1c08d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08e060 D=1c08e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08e740 D=1c08e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08ee20 D=1c08ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 71 P=1c08f500 D=1c08f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c090020 D=1c090020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c090700 D=1c090700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c090de0 D=1c090de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c0914c0 D=1c0914c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 72 P=1c091ba0 D=1c091ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c092280 D=1c092280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c092960 D=1c092960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c093040 D=1c093040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c093720 D=1c093720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 73 P=1c093e00 D=1c093e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c0944e0 D=1c0944e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c094bc0 D=1c094bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c0952a0 D=1c0952a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 74 P=1c095980 D=1c095980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c096060 D=1c096060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c096740 D=1c096740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c096e20 D=1c096e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 75 P=1c097500 D=1c097500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c098020 D=1c098020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c098700 D=1c098700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c098de0 D=1c098de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c0994c0 D=1c0994c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 76 P=1c099ba0 D=1c099ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09a280 D=1c09a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09a960 D=1c09a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09b040 D=1c09b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09b720 D=1c09b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 77 P=1c09be00 D=1c09be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 78 P=1c09c4e0 D=1c09c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 78 P=1c09cbc0 D=1c09cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 128 P=20804000 D=1f900000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 128 P=20805000 D=1f901000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 129 P=20806000 D=1f902000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 129 P=20807000 D=1f903000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 130 P=20808000 D=1f904000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 130 P=20809000 D=1f905000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 131 P=2080a000 D=1f906000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 131 P=2080b000 D=1f907000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 132 P=2080c000 D=1f908000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 132 P=2080d000 D=1f909000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 133 P=2080e000 D=1f90a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 133 P=2080f000 D=1f90b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 134 P=20810000 D=1f90c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 134 P=20811000 D=1f90d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 135 P=20812000 D=1f90e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 135 P=20813000 D=1f90f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 136 P=20814000 D=1f910000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 136 P=20815000 D=1f911000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 137 P=20816000 D=1f912000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 137 P=20817000 D=1f913000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 138 P=20818000 D=1f914000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 138 P=20819000 D=1f915000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 139 P=2081a000 D=1f916000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 139 P=2081b000 D=1f917000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 140 P=2081c000 D=1f918000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 140 P=2081d000 D=1f919000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 141 P=2081e000 D=1f91a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 141 P=2081f000 D=1f91b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 142 P=20820000 D=1f91c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 142 P=20821000 D=1f91d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 143 P=20822000 D=1f91e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 143 P=20823000 D=1f91f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 144 P=20824000 D=1f920000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 144 P=20825000 D=1f921000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 145 P=20826000 D=1f922000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 145 P=20827000 D=1f923000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 146 P=20828000 D=1f924000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 146 P=20829000 D=1f925000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 147 P=2082a000 D=1f926000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 147 P=2082b000 D=1f927000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 148 P=2082c000 D=1f928000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 148 P=2082d000 D=1f929000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 149 P=2082e000 D=1f92a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 149 P=2082f000 D=1f92b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 150 P=20830000 D=1f92c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 150 P=20831000 D=1f92d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 151 P=20832000 D=1f92e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 151 P=20833000 D=1f92f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 152 P=20834000 D=1f930000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 152 P=20835000 D=1f931000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 153 P=20836000 D=1f932000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 153 P=20837000 D=1f933000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 154 P=20838000 D=1f934000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 154 P=20839000 D=1f935000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 155 P=2083a000 D=1f936000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 155 P=2083b000 D=1f937000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 156 P=2083c000 D=1f938000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 156 P=2083d000 D=1f939000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 157 P=2083e000 D=1f93a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 157 P=2083f000 D=1f93b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 158 P=20840000 D=1f93c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 158 P=20841000 D=1f93d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 159 P=20842000 D=1f93e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 159 P=20843000 D=1f93f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 160 P=20844000 D=1f940000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 160 P=20845000 D=1f941000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 161 P=20846000 D=1f942000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 161 P=20847000 D=1f943000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 162 P=20848000 D=1f944000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 162 P=20849000 D=1f945000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 163 P=2084a000 D=1f946000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 163 P=2084b000 D=1f947000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 164 P=2084c000 D=1f948000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 164 P=2084d000 D=1f949000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 165 P=2084e000 D=1f94a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 165 P=2084f000 D=1f94b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 166 P=20850000 D=1f94c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 166 P=20851000 D=1f94d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 167 P=20852000 D=1f94e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 167 P=20853000 D=1f94f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 168 P=20854000 D=1f950000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 168 P=20855000 D=1f951000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 169 P=20856000 D=1f952000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 169 P=20857000 D=1f953000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 170 P=20858000 D=1f954000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 170 P=20859000 D=1f955000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 171 P=2085a000 D=1f956000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 171 P=2085b000 D=1f957000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 172 P=2085c000 D=1f958000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 172 P=2085d000 D=1f959000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 173 P=2085e000 D=1f95a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 173 P=2085f000 D=1f95b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 174 P=20860000 D=1f95c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 174 P=20861000 D=1f95d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 175 P=20862000 D=1f95e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 175 P=20863000 D=1f95f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 176 P=20864000 D=1f960000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 176 P=20865000 D=1f961000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 177 P=20866000 D=1f962000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 177 P=20867000 D=1f963000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 178 P=20868000 D=1f964000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 178 P=20869000 D=1f965000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 179 P=2086a000 D=1f966000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 179 P=2086b000 D=1f967000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 180 P=2086c000 D=1f968000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 180 P=2086d000 D=1f969000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 181 P=2086e000 D=1f96a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 181 P=2086f000 D=1f96b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 182 P=20870000 D=1f96c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 182 P=20871000 D=1f96d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 183 P=20872000 D=1f96e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 183 P=20873000 D=1f96f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 184 P=20874000 D=1f970000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 184 P=20875000 D=1f971000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 185 P=20876000 D=1f972000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 185 P=20877000 D=1f973000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 186 P=20878000 D=1f974000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 186 P=20879000 D=1f975000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 187 P=2087a000 D=1f976000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 187 P=2087b000 D=1f977000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 188 P=2087c000 D=1f978000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 188 P=2087d000 D=1f979000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 189 P=2087e000 D=1f97a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 189 P=2087f000 D=1f97b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 190 P=20880000 D=1f97c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 190 P=20881000 D=1f97d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 191 P=20882000 D=1f97e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 191 P=20883000 D=1f97f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 192 P=20884000 D=1f980000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 192 P=20885000 D=1f981000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 193 P=20886000 D=1f982000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 193 P=20887000 D=1f983000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 194 P=20888000 D=1f984000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 194 P=20889000 D=1f985000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 195 P=2088a000 D=1f986000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 195 P=2088b000 D=1f987000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 196 P=2088c000 D=1f988000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 196 P=2088d000 D=1f989000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 197 P=2088e000 D=1f98a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 197 P=2088f000 D=1f98b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 198 P=20890000 D=1f98c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 198 P=20891000 D=1f98d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 199 P=20892000 D=1f98e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 199 P=20893000 D=1f98f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 200 P=210c1000 D=1c990000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 200 P=20894000 D=1f990000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 200 P=20895000 D=1f991000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 201 P=20896000 D=1f992000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 201 P=20897000 D=1f993000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 202 P=20898000 D=1f994000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 202 P=20899000 D=1f995000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 203 P=2089a000 D=1f996000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 203 P=2089b000 D=1f997000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 204 P=2089c000 D=1f998000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 204 P=2089d000 D=1f999000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 205 P=2089e000 D=1f99a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 205 P=2089f000 D=1f99b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 206 P=208a0000 D=1f99c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 206 P=208a1000 D=1f99d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 207 P=208a2000 D=1f99e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 207 P=208a3000 D=1f99f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 208 P=210d1000 D=1c9a0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 208 P=208a4000 D=1f9a0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 208 P=208a5000 D=1f9a1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 209 P=208a6000 D=1f9a2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 209 P=208a7000 D=1f9a3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 210 P=208a8000 D=1f9a4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 210 P=208a9000 D=1f9a5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 211 P=208aa000 D=1f9a6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 211 P=208ab000 D=1f9a7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 212 P=208ac000 D=1f9a8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 212 P=208ad000 D=1f9a9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 213 P=208ae000 D=1f9aa000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 213 P=208af000 D=1f9ab000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 214 P=208b0000 D=1f9ac000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 214 P=208b1000 D=1f9ad000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 215 P=208b2000 D=1f9ae000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 215 P=208b3000 D=1f9af000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 216 P=210e1000 D=1c9b0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 216 P=208b4000 D=1f9b0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 216 P=208b5000 D=1f9b1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 217 P=208b6000 D=1f9b2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 217 P=208b7000 D=1f9b3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 218 P=208b8000 D=1f9b4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 218 P=208b9000 D=1f9b5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: single idx 219 P=1f1b6580 D=1f1b6580 L=1 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 219 P=208ba000 D=1f9b6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 219 P=208bb000 D=1f9b7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 220 P=208bc000 D=1f9b8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 220 P=208bd000 D=1f9b9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 221 P=208be000 D=1f9ba000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 221 P=208bf000 D=1f9bb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 222 P=208c0000 D=1f9bc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 222 P=208c1000 D=1f9bd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 223 P=208c2000 D=1f9be000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 223 P=208c3000 D=1f9bf000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 224 P=210f1000 D=1c9c0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 224 P=208c4000 D=1f9c0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 224 P=208c5000 D=1f9c1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 225 P=208c6000 D=1f9c2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 225 P=208c7000 D=1f9c3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 226 P=208c8000 D=1f9c4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 226 P=208c9000 D=1f9c5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 227 P=208ca000 D=1f9c6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 227 P=208cb000 D=1f9c7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 228 P=20ba6000 D=1f1c8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 228 P=208cc000 D=1f9c8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 228 P=208cd000 D=1f9c9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 229 P=208ce000 D=1f9ca000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 229 P=208cf000 D=1f9cb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 230 P=208d0000 D=1f9cc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 230 P=208d1000 D=1f9cd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 231 P=208d2000 D=1f9ce000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 231 P=208d3000 D=1f9cf000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 232 P=21101000 D=1c9d0000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 232 P=208d4000 D=1f9d0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 232 P=208d5000 D=1f9d1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 233 P=208d6000 D=1f9d2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 233 P=208d7000 D=1f9d3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 234 P=208d8000 D=1f9d4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 234 P=208d9000 D=1f9d5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 235 P=208da000 D=1f9d6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 235 P=208db000 D=1f9d7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 236 P=208dc000 D=1f9d8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 236 P=208dd000 D=1f9d9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 237 P=208de000 D=1f9da000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 237 P=208df000 D=1f9db000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 238 P=208e0000 D=1f9dc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 238 P=208e1000 D=1f9dd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 239 P=208e2000 D=1f9de000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 239 P=208e3000 D=1f9df000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 240 P=208e4000 D=1f9e0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 240 P=208e5000 D=1f9e1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 241 P=208e6000 D=1f9e2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 241 P=208e7000 D=1f9e3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 242 P=208e8000 D=1f9e4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 242 P=208e9000 D=1f9e5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 243 P=208ea000 D=1f9e6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 243 P=208eb000 D=1f9e7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 244 P=208ec000 D=1f9e8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 244 P=208ed000 D=1f9e9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 245 P=208ee000 D=1f9ea000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 245 P=208ef000 D=1f9eb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 246 P=208f0000 D=1f9ec000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 246 P=208f1000 D=1f9ed000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 247 P=208f2000 D=1f9ee000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 247 P=208f3000 D=1f9ef000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 248 P=208f4000 D=1f9f0000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 248 P=208f5000 D=1f9f1000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 249 P=208f6000 D=1f9f2000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 249 P=208f7000 D=1f9f3000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 250 P=208f8000 D=1f9f4000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 250 P=208f9000 D=1f9f5000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 251 P=208fa000 D=1f9f6000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 251 P=208fb000 D=1f9f7000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 252 P=208fc000 D=1f9f8000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 252 P=208fd000 D=1f9f9000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 253 P=208fe000 D=1f9fa000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 253 P=208ff000 D=1f9fb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 254 P=20900000 D=1f9fc000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 254 P=20901000 D=1f9fd000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 255 P=20902000 D=1f9fe000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 255 P=20903000 D=1f9ff000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 296 P=2111d000 D=1ca50000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 304 P=2112d000 D=1ca60000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 312 P=2113d000 D=1ca70000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 320 P=2114d000 D=1ca80000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 328 P=20a0d000 D=1fa90000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 328 P=20a0f000 D=1fa91000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: orion-ehci orion-ehci.0: coherent idx 328 P=2115d000 D=1ca90000 L=eb00 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 329 P=20a11000 D=1fa92000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 329 P=20a13000 D=1fa93000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 342 P=20a47000 D=1faac000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 342 P=20a49000 D=1faad000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 359 P=20a4b000 D=1face000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 359 P=20a4d000 D=1facf000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 392 P=1f311000 D=1f311000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 393 P=1f312000 D=1f312000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 393 P=1f313000 D=1f313000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 394 P=1f314000 D=1f314000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 394 P=1f315000 D=1f315000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 395 P=1f316000 D=1f316000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 395 P=1f317000 D=1f317000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 396 P=1f318000 D=1f318000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 396 P=1f319000 D=1f319000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 397 P=1f31a000 D=1f31a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 397 P=1f31b000 D=1f31b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 398 P=1f31c000 D=1f31c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 398 P=1f31d000 D=1f31d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 399 P=1f31e000 D=1f31e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 399 P=1f31f000 D=1f31f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 400 P=1f320000 D=1f320000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 400 P=1f321000 D=1f321000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 401 P=1f322000 D=1f322000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 401 P=1f323000 D=1f323000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 402 P=1f325000 D=1f325000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 403 P=1f326000 D=1f326000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 403 P=1f327000 D=1f327000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 404 P=1f328000 D=1f328000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 404 P=1f329000 D=1f329000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 405 P=1f32a000 D=1f32a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 405 P=1f32b000 D=1f32b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 406 P=1f32c000 D=1f32c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 406 P=1f32d000 D=1f32d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 407 P=1f32e000 D=1f32e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 407 P=1f32f000 D=1f32f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 408 P=1f330000 D=1f330000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 408 P=1f331000 D=1f331000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 409 P=1f332000 D=1f332000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 409 P=1f333000 D=1f333000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 410 P=1f334000 D=1f334000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 410 P=1f335000 D=1f335000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 411 P=1f337000 D=1f337000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 412 P=1f338000 D=1f338000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 412 P=1f339000 D=1f339000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 413 P=1f33a000 D=1f33a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 413 P=1f33b000 D=1f33b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 414 P=1f33c000 D=1f33c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 414 P=1f33d000 D=1f33d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 415 P=1f33e000 D=1f33e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 415 P=1f33f000 D=1f33f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 416 P=1f340000 D=1f340000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 416 P=1f341000 D=1f341000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 417 P=1f342000 D=1f342000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 417 P=1f343000 D=1f343000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 418 P=1f344000 D=1f344000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 418 P=1f345000 D=1f345000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 419 P=1f346000 D=1f346000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 419 P=1f347000 D=1f347000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 420 P=1f349000 D=1f349000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 421 P=1f34a000 D=1f34a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 421 P=1f34b000 D=1f34b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 422 P=1f34c000 D=1f34c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 422 P=1f34d000 D=1f34d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 423 P=1f34e000 D=1f34e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 423 P=1f34f000 D=1f34f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 424 P=1f350000 D=1f350000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 424 P=1f351000 D=1f351000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb50020 D=1cb50020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb50700 D=1cb50700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb50de0 D=1cb50de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb514c0 D=1cb514c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 424 P=1cb51ba0 D=1cb51ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 425 P=1f352000 D=1f352000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 425 P=1f353000 D=1f353000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb52280 D=1cb52280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb52960 D=1cb52960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb53040 D=1cb53040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb53720 D=1cb53720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 425 P=1cb53e00 D=1cb53e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 426 P=1f354000 D=1f354000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 426 P=1f355000 D=1f355000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb544e0 D=1cb544e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb54bc0 D=1cb54bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb552a0 D=1cb552a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 426 P=1cb55980 D=1cb55980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 427 P=1f356000 D=1f356000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 427 P=1f357000 D=1f357000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb56060 D=1cb56060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb56740 D=1cb56740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb56e20 D=1cb56e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 427 P=1cb57500 D=1cb57500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 428 P=1f358000 D=1f358000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 428 P=1f359000 D=1f359000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 429 P=1f35b000 D=1f35b000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 430 P=1f35c000 D=1f35c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 430 P=1f35d000 D=1f35d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 431 P=1f35e000 D=1f35e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 431 P=1f35f000 D=1f35f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 432 P=1f360000 D=1f360000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 432 P=1f361000 D=1f361000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 433 P=1f362000 D=1f362000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 433 P=1f363000 D=1f363000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 434 P=1f364000 D=1f364000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 434 P=1f365000 D=1f365000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 435 P=1f366000 D=1f366000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 435 P=1f367000 D=1f367000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 436 P=1f368000 D=1f368000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 436 P=1f369000 D=1f369000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 437 P=1f36a000 D=1f36a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 437 P=1f36b000 D=1f36b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 438 P=1f36d000 D=1f36d000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 439 P=1f36e000 D=1f36e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 439 P=1f36f000 D=1f36f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 440 P=209e7000 D=1fb71000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 440 P=1f370000 D=1f370000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 440 P=1f371000 D=1f371000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 441 P=209e9000 D=1fb73000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 441 P=1f372000 D=1f372000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 441 P=1f373000 D=1f373000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 442 P=209eb000 D=1fb74000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 442 P=209ed000 D=1fb75000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 442 P=1f374000 D=1f374000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 442 P=1f375000 D=1f375000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 443 P=209ef000 D=1fb76000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 443 P=209f1000 D=1fb77000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 443 P=1f376000 D=1f376000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 443 P=1f377000 D=1f377000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 444 P=209f3000 D=1fb78000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 444 P=209f5000 D=1fb79000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 444 P=1f378000 D=1f378000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 444 P=1f379000 D=1f379000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 445 P=209f7000 D=1fb7a000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 445 P=209f9000 D=1fb7b000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 445 P=1f37a000 D=1f37a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 445 P=1f37b000 D=1f37b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 446 P=209fb000 D=1fb7c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 446 P=209fd000 D=1fb7d000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 446 P=1f37c000 D=1f37c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 446 P=1f37d000 D=1f37d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 447 P=209ff000 D=1fb7e000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: sata_mv sata_mv.0: coherent idx 447 P=20a01000 D=1fb7f000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 447 P=1f37f000 D=1f37f000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 448 P=1f380000 D=1f380000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 448 P=1f381000 D=1f381000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 449 P=1f382000 D=1f382000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 449 P=1f383000 D=1f383000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 450 P=1f384000 D=1f384000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 450 P=1f385000 D=1f385000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 451 P=1f386000 D=1f386000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 451 P=1f387000 D=1f387000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 452 P=1f388000 D=1f388000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 452 P=1f389000 D=1f389000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 453 P=1f38a000 D=1f38a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 453 P=1f38b000 D=1f38b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 454 P=1f38c000 D=1f38c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 454 P=1f38d000 D=1f38d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 455 P=1f38e000 D=1f38e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 455 P=1f38f000 D=1f38f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 456 P=1f391000 D=1f391000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 457 P=1f393000 D=1f393000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 458 P=1f394000 D=1f394000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 458 P=1f395000 D=1f395000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 459 P=1f396000 D=1f396000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 459 P=1f397000 D=1f397000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 460 P=1f398000 D=1f398000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 460 P=1f399000 D=1f399000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 461 P=1f39a000 D=1f39a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 461 P=1f39b000 D=1f39b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 462 P=1f39c000 D=1f39c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 462 P=1f39d000 D=1f39d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 463 P=1f39e000 D=1f39e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 463 P=1f39f000 D=1f39f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 464 P=1f3a0000 D=1f3a0000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 464 P=1f3a1000 D=1f3a1000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 465 P=1f3a2000 D=1f3a2000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 615 P=1eccf000 D=1eccf000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 616 P=1ecd0000 D=1ecd0000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 616 P=1ecd1000 D=1ecd1000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 617 P=1ecd2000 D=1ecd2000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 617 P=1ecd3000 D=1ecd3000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 618 P=1ecd4000 D=1ecd4000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 618 P=1ecd5000 D=1ecd5000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 619 P=1ecd6000 D=1ecd6000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 619 P=1ecd7000 D=1ecd7000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 620 P=1ecd8000 D=1ecd8000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 620 P=1ecd9000 D=1ecd9000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 621 P=1ecda000 D=1ecda000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 621 P=1ecdb000 D=1ecdb000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 622 P=1ecdc000 D=1ecdc000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 622 P=1ecdd000 D=1ecdd000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 623 P=1ecde000 D=1ecde000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 623 P=1ecdf000 D=1ecdf000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 624 P=1ece1000 D=1ece1000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 625 P=1ece2000 D=1ece2000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 625 P=1ece3000 D=1ece3000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 626 P=1ece4000 D=1ece4000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 626 P=1ece5000 D=1ece5000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 627 P=1ece6000 D=1ece6000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 627 P=1ece7000 D=1ece7000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 628 P=1ece8000 D=1ece8000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 628 P=1ece9000 D=1ece9000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 629 P=1ecea000 D=1ecea000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 629 P=1eceb000 D=1eceb000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 630 P=1ecec000 D=1ecec000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 630 P=1eced000 D=1eced000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 632 P=1ecf0000 D=1ecf0000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 632 P=1ecf1000 D=1ecf1000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 633 P=1ecf3000 D=1ecf3000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 634 P=1ecf4000 D=1ecf4000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 634 P=1ecf5000 D=1ecf5000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 635 P=1ecf6000 D=1ecf6000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 635 P=1ecf7000 D=1ecf7000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 636 P=1ecf8000 D=1ecf8000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 636 P=1ecf9000 D=1ecf9000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 637 P=1ecfa000 D=1ecfa000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 637 P=1ecfb000 D=1ecfb000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 638 P=1ecfc000 D=1ecfc000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 638 P=1ecfd000 D=1ecfd000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 639 P=1ecfe000 D=1ecfe000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 639 P=1ecff000 D=1ecff000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 640 P=1ed00000 D=1ed00000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 640 P=1ed01000 D=1ed01000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 641 P=1ed02000 D=1ed02000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 641 P=1ed03000 D=1ed03000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 642 P=1ed05000 D=1ed05000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 643 P=1ed06000 D=1ed06000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 643 P=1ed07000 D=1ed07000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 644 P=1ed08000 D=1ed08000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 644 P=1ed09000 D=1ed09000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 645 P=1ed0a000 D=1ed0a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 645 P=1ed0b000 D=1ed0b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 646 P=1ed0c000 D=1ed0c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 646 P=1ed0d000 D=1ed0d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 647 P=1ed0e000 D=1ed0e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 647 P=1ed0f000 D=1ed0f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 648 P=1ed10000 D=1ed10000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 648 P=1ed11000 D=1ed11000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 649 P=1ed12000 D=1ed12000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 649 P=1ed13000 D=1ed13000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 650 P=1ed14000 D=1ed14000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 650 P=1ed15000 D=1ed15000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 651 P=1ed17000 D=1ed17000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 652 P=1ed18000 D=1ed18000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 652 P=1ed19000 D=1ed19000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 653 P=1ed1a000 D=1ed1a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 653 P=1ed1b000 D=1ed1b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 654 P=1ed1c000 D=1ed1c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 654 P=1ed1d000 D=1ed1d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 655 P=1ed1e000 D=1ed1e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 655 P=1ed1f000 D=1ed1f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 656 P=1ed20000 D=1ed20000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 656 P=1ed21000 D=1ed21000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 657 P=1ed22000 D=1ed22000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 657 P=1ed23000 D=1ed23000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 658 P=1ed24000 D=1ed24000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 658 P=1ed25000 D=1ed25000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 659 P=1ed26000 D=1ed26000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 659 P=1ed27000 D=1ed27000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 660 P=1ed29000 D=1ed29000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 661 P=1ed2a000 D=1ed2a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 661 P=1ed2b000 D=1ed2b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 662 P=1ed2c000 D=1ed2c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 662 P=1ed2d000 D=1ed2d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 663 P=1ed2e000 D=1ed2e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 663 P=1ed2f000 D=1ed2f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 664 P=1ed30000 D=1ed30000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 664 P=1ed31000 D=1ed31000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 665 P=1ed32000 D=1ed32000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 665 P=1ed33000 D=1ed33000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 666 P=1ed34000 D=1ed34000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 666 P=1ed35000 D=1ed35000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 667 P=1ed36000 D=1ed36000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 667 P=1ed37000 D=1ed37000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 668 P=1ed38000 D=1ed38000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 668 P=1ed39000 D=1ed39000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 670 P=1ed3c000 D=1ed3c000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 670 P=1ed3d000 D=1ed3d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 671 P=1ed3e000 D=1ed3e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 671 P=1ed3f000 D=1ed3f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 672 P=1ed40000 D=1ed40000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 672 P=1ed41000 D=1ed41000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 673 P=1ed42000 D=1ed42000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 673 P=1ed43000 D=1ed43000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 674 P=1ed44000 D=1ed44000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 674 P=1ed45000 D=1ed45000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 675 P=1ed46000 D=1ed46000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 675 P=1ed47000 D=1ed47000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 676 P=1ed48000 D=1ed48000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 676 P=1ed49000 D=1ed49000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 677 P=1ed4a000 D=1ed4a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 677 P=1ed4b000 D=1ed4b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 678 P=1ed4c000 D=1ed4c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: single idx 679 P=1ed4e000 D=1ed4e000 L=1000 DMA_TO_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 679 P=1ed4f000 D=1ed4f000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 680 P=1ed50000 D=1ed50000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 680 P=1ed51000 D=1ed51000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 681 P=1ed52000 D=1ed52000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 681 P=1ed53000 D=1ed53000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 682 P=1ed54000 D=1ed54000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 682 P=1ed55000 D=1ed55000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 683 P=1ed56000 D=1ed56000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 683 P=1ed57000 D=1ed57000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 684 P=1ed58000 D=1ed58000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 684 P=1ed59000 D=1ed59000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 685 P=1ed5a000 D=1ed5a000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 685 P=1ed5b000 D=1ed5b000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 686 P=1ed5c000 D=1ed5c000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 686 P=1ed5d000 D=1ed5d000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: SAA716x FF 0000:00:01.0: scather-gather idx 687 P=1ed5e000 D=1ed5e000 L=1000 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee70020 D=1ee70020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee70700 D=1ee70700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee70de0 D=1ee70de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee714c0 D=1ee714c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 824 P=1ee71ba0 D=1ee71ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee72280 D=1ee72280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee72960 D=1ee72960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee73040 D=1ee73040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee73720 D=1ee73720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 825 P=1ee73e00 D=1ee73e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee744e0 D=1ee744e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee74bc0 D=1ee74bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee752a0 D=1ee752a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 826 P=1ee75980 D=1ee75980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee76060 D=1ee76060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee76740 D=1ee76740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee76e20 D=1ee76e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 827 P=1ee77500 D=1ee77500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee78020 D=1ee78020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee78700 D=1ee78700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee78de0 D=1ee78de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee794c0 D=1ee794c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 828 P=1ee79ba0 D=1ee79ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7a280 D=1ee7a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7a960 D=1ee7a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7b040 D=1ee7b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7b720 D=1ee7b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 829 P=1ee7be00 D=1ee7be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7c4e0 D=1ee7c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7cbc0 D=1ee7cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7d2a0 D=1ee7d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 830 P=1ee7d980 D=1ee7d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7e060 D=1ee7e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7e740 D=1ee7e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7ee20 D=1ee7ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 831 P=1ee7f500 D=1ee7f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee80020 D=1ee80020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee80700 D=1ee80700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee80de0 D=1ee80de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee814c0 D=1ee814c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 832 P=1ee81ba0 D=1ee81ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee82280 D=1ee82280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee82960 D=1ee82960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee83040 D=1ee83040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee83720 D=1ee83720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 833 P=1ee83e00 D=1ee83e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee844e0 D=1ee844e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee84bc0 D=1ee84bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee852a0 D=1ee852a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 834 P=1ee85980 D=1ee85980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee86060 D=1ee86060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee86740 D=1ee86740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee86e20 D=1ee86e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 835 P=1ee87500 D=1ee87500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 852 P=1eea8020 D=1eea8020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 852 P=1eea8700 D=1eea8700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eeac8a0 D=1eeac8a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eeacf80 D=1eeacf80 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eead660 D=1eead660 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 854 P=1eeadd40 D=1eeadd40 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeae420 D=1eeae420 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeaeb00 D=1eeaeb00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeaf1e0 D=1eeaf1e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 855 P=1eeaf8c0 D=1eeaf8c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb0020 D=1eeb0020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb0700 D=1eeb0700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb0de0 D=1eeb0de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb14c0 D=1eeb14c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 856 P=1eeb1ba0 D=1eeb1ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb2280 D=1eeb2280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb2960 D=1eeb2960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb3040 D=1eeb3040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb3720 D=1eeb3720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 857 P=1eeb3e00 D=1eeb3e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb44e0 D=1eeb44e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb4bc0 D=1eeb4bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb52a0 D=1eeb52a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 858 P=1eeb5980 D=1eeb5980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb6060 D=1eeb6060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb6740 D=1eeb6740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb6e20 D=1eeb6e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 859 P=1eeb7500 D=1eeb7500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed8020 D=1eed8020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed8700 D=1eed8700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed8de0 D=1eed8de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed94c0 D=1eed94c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 876 P=1eed9ba0 D=1eed9ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eeda280 D=1eeda280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eeda960 D=1eeda960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eedb040 D=1eedb040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eedb720 D=1eedb720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 877 P=1eedbe00 D=1eedbe00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedc4e0 D=1eedc4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedcbc0 D=1eedcbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedd2a0 D=1eedd2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 878 P=1eedd980 D=1eedd980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eede060 D=1eede060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eede740 D=1eede740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eedee20 D=1eedee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 879 P=1eedf500 D=1eedf500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: coherent idx 885 P=21497000 D=1eeeb000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef00020 D=1ef00020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef00700 D=1ef00700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef00de0 D=1ef00de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef014c0 D=1ef014c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 896 P=1ef01ba0 D=1ef01ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef02280 D=1ef02280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef02960 D=1ef02960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef03040 D=1ef03040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef03720 D=1ef03720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 897 P=1ef03e00 D=1ef03e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef044e0 D=1ef044e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef04bc0 D=1ef04bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef052a0 D=1ef052a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 898 P=1ef05980 D=1ef05980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef06060 D=1ef06060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef06740 D=1ef06740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef06e20 D=1ef06e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 899 P=1ef07500 D=1ef07500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: coherent idx 918 P=2144c000 D=1ef2c000 L=1000 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef38020 D=1ef38020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef38700 D=1ef38700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef38de0 D=1ef38de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef394c0 D=1ef394c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 924 P=1ef39ba0 D=1ef39ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3a280 D=1ef3a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3a960 D=1ef3a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3b040 D=1ef3b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3b720 D=1ef3b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 925 P=1ef3be00 D=1ef3be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3c4e0 D=1ef3c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3cbc0 D=1ef3cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3d2a0 D=1ef3d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 926 P=1ef3d980 D=1ef3d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3e060 D=1ef3e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3e740 D=1ef3e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3ee20 D=1ef3ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 927 P=1ef3f500 D=1ef3f500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef40020 D=1ef40020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef40700 D=1ef40700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef40de0 D=1ef40de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef414c0 D=1ef414c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 928 P=1ef41ba0 D=1ef41ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef42280 D=1ef42280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef42960 D=1ef42960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef43040 D=1ef43040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef43720 D=1ef43720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 929 P=1ef43e00 D=1ef43e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef444e0 D=1ef444e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef44bc0 D=1ef44bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef452a0 D=1ef452a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 930 P=1ef45980 D=1ef45980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef46060 D=1ef46060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef46740 D=1ef46740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef46e20 D=1ef46e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: single idx 931 P=1ef47500 D=1ef47500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.1: coherent idx 933 P=2144a000 D=1ef4b000 L=800 DMA_BIDIRECTIONAL
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef70020 D=1ef70020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef70700 D=1ef70700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef70de0 D=1ef70de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef714c0 D=1ef714c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 952 P=1ef71ba0 D=1ef71ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef72280 D=1ef72280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef72960 D=1ef72960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef73040 D=1ef73040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef73720 D=1ef73720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 953 P=1ef73e00 D=1ef73e00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef744e0 D=1ef744e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef74bc0 D=1ef74bc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef752a0 D=1ef752a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 954 P=1ef75980 D=1ef75980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef76060 D=1ef76060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef76740 D=1ef76740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef76e20 D=1ef76e20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 955 P=1ef77500 D=1ef77500 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef78020 D=1ef78020 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef78700 D=1ef78700 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef78de0 D=1ef78de0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef794c0 D=1ef794c0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 956 P=1ef79ba0 D=1ef79ba0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7a280 D=1ef7a280 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7a960 D=1ef7a960 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7b040 D=1ef7b040 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7b720 D=1ef7b720 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 957 P=1ef7be00 D=1ef7be00 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7c4e0 D=1ef7c4e0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7cbc0 D=1ef7cbc0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7d2a0 D=1ef7d2a0 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 958 P=1ef7d980 D=1ef7d980 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7e060 D=1ef7e060 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7e740 D=1ef7e740 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7ee20 D=1ef7ee20 L=600 DMA_FROM_DEVICE
Jan 19 13:54:58 guruvdr kernel: mv643xx_eth_port mv643xx_eth_port.0: single idx 959 P=1ef7f500 D=1ef7f500 L=600 DMA_FROM_DEVICE

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-17 20:26                           ` Arnd Bergmann
  2013-01-19 15:29                             ` Soeren Moch
@ 2013-01-19 16:24                             ` Andrew Lunn
  1 sibling, 0 replies; 59+ messages in thread
From: Andrew Lunn @ 2013-01-19 16:24 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Soeren Moch, Jason Cooper, Greg KH, Thomas Petazzoni,
	Andrew Lunn, KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko,
	linux-mm, Kyungmin Park, Mel Gorman, Andrew Morton,
	Marek Szyprowski, linaro-mm-sig, linux-arm-kernel,
	Sebastian Hesselbarth

On Thu, Jan 17, 2013 at 08:26:45PM +0000, Arnd Bergmann wrote:
> On Thursday 17 January 2013, Soeren Moch wrote:
> > On 17.01.2013 11:49, Arnd Bergmann wrote:
> > > On Wednesday 16 January 2013, Soeren Moch wrote:
> > >>>> 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.

I tried this. Not what i expected. We have at least one problem with
the ethernet driver:

WARNING: at lib/dma-debug.c:933 check_unmap+0x4b8/0x8a8()
mv643xx_eth_port mv643xx_eth_port.0: DMA-API: device driver failed to check map error[device address=0x000000001f22be00] [size=1536 bytes] [mapped as single]
Modules linked in:
[<c000db10>] (unwind_backtrace+0x0/0xf4) from [<c0016c44>] (warn_slowpath_common+0x4c/0x64)
[<c0016c44>] (warn_slowpath_common+0x4c/0x64) from [<c0016cf0>] (warn_slowpath_fmt+0x30/0x40)
[<c0016cf0>] (warn_slowpath_fmt+0x30/0x40) from [<c01ab540>] (check_unmap+0x4b8/0x8a8)
[<c01ab540>] (check_unmap+0x4b8/0x8a8) from [<c01abbb8>] (debug_dma_unmap_page+0x8c/0x98)
[<c01abbb8>] (debug_dma_unmap_page+0x8c/0x98) from [<c025cb1c>] (mv643xx_eth_poll+0x630/0x800)
[<c025cb1c>] (mv643xx_eth_poll+0x630/0x800) from [<c0331d9c>] (net_rx_action+0xcc/0x1d4)
[<c0331d9c>] (net_rx_action+0xcc/0x1d4) from [<c001e1b0>] (__do_softirq+0xa8/0x170)
[<c001e1b0>] (__do_softirq+0xa8/0x170) from [<c001e3e8>] (do_softirq+0x5c/0x6c)
[<c001e3e8>] (do_softirq+0x5c/0x6c) from [<c001e610>] (local_bh_enable+0xcc/0xdc)
[<c001e610>] (local_bh_enable+0xcc/0xdc) from [<c0359c74>] (ip_finish_output+0x1c8/0x39c)
[<c0359c74>] (ip_finish_output+0x1c8/0x39c) from [<c03571a4>] (ip_local_out+0x28/0x2c)
[<c03571a4>] (ip_local_out+0x28/0x2c) from [<c0359564>] (ip_queue_xmit+0x118/0x338)
[<c0359564>] (ip_queue_xmit+0x118/0x338) from [<c036e58c>] (tcp_transmit_skb+0x3fc/0x8e4)
[<c036e58c>] (tcp_transmit_skb+0x3fc/0x8e4) from [<c0371218>] (tcp_write_xmit+0x228/0xb08)
[<c0371218>] (tcp_write_xmit+0x228/0xb08) from [<c0371b6c>] (__tcp_push_pending_frames+0x30/0x9c)
[<c0371b6c>] (__tcp_push_pending_frames+0x30/0x9c) from [<c0362940>] (tcp_sendmsg+0x158/0xdc4)
[<c0362940>] (tcp_sendmsg+0x158/0xdc4) from [<c0386620>] (inet_sendmsg+0x38/0x74)
[<c0386620>] (inet_sendmsg+0x38/0x74) from [<c031f370>] (sock_aio_write+0x12c/0x138)
[<c031f370>] (sock_aio_write+0x12c/0x138) from [<c00a62f4>] (do_sync_write+0xa0/0xd0)
[<c00a62f4>] (do_sync_write+0xa0/0xd0) from [<c00a6f18>] (vfs_write+0x13c/0x144)
[<c00a6f18>] (vfs_write+0x13c/0x144) from [<c00a6ff0>] (sys_write+0x44/0x70)
[<c00a6ff0>] (sys_write+0x44/0x70) from [<c0008ce0>] (ret_fast_syscall+0x0/0x2c)
---[ end trace b75faa8779652e63 ]---

I'm getting about 4 errors reported a second from the ethernet driver.

Before i look at issues with em28xx i will first try to get the noise
from the ethernet driver sorted out.

     Andrew

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-19 15:29                             ` Soeren Moch
@ 2013-01-19 18:59                               ` Andrew Lunn
  2013-01-23 15:30                                 ` Soeren Moch
  2013-01-19 20:05                               ` Arnd Bergmann
  1 sibling, 1 reply; 59+ messages in thread
From: Andrew Lunn @ 2013-01-19 18:59 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Arnd Bergmann, Jason Cooper, Greg KH, Thomas Petazzoni,
	Andrew Lunn, KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko,
	linux-mm, Kyungmin Park, Mel Gorman, Andrew Morton,
	Marek Szyprowski, linaro-mm-sig, linux-arm-kernel,
	Sebastian Hesselbarth

> Please find attached a debug log generated with your patch.
> 
> I used the sata disk and two em28xx dvb sticks, no other usb devices,
> no ethernet cable connected, tuners on saa716x-based card not used.
> 
> What I can see in the log: a lot of coherent mappings from sata_mv
> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> All coherent mappings are page aligned, some of them (from orion_ehci)
> are not really small (as claimed in __alloc_from_pool).
> 
> I don't believe in a memory leak. When I restart vdr (the application
> utilizing the dvb sticks) then there is enough dma memory available
> again.

Hi Soeren

We should be able to rule out a leak. Mount debugfg and then:

while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done

while you are capturing. See if the number goes down.

      Andrew

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-19 15:29                             ` Soeren Moch
  2013-01-19 18:59                               ` Andrew Lunn
@ 2013-01-19 20:05                               ` Arnd Bergmann
  2013-01-21 15:01                                 ` Soeren Moch
  1 sibling, 1 reply; 59+ messages in thread
From: Arnd Bergmann @ 2013-01-19 20:05 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Saturday 19 January 2013, Soeren Moch wrote:
> What I can see in the log: a lot of coherent mappings from sata_mv and 
> orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> All coherent mappings are page aligned, some of them (from orion_ehci)
> are not really small (as claimed in __alloc_from_pool).

Right. Unfortunately, the output does not show which of the mappings
are atomic, so we still need to look through those that can be atomic
to understand what's going on. There are a few megabytes of coherent
mappings in total according to the output, but it seems that a significant
portion of them is atomic, which is a bit unexpected.

> I don't believe in a memory leak. When I restart vdr (the application
> utilizing the dvb sticks) then there is enough dma memory available
> again.

I found at least one source line that incorrectly uses an atomic
allocation, in ehci_mem_init():

                dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
                        ehci->periodic_size * sizeof(__le32),
                        &ehci->periodic_dma, 0);

The last argument is the GFP_ flag, which should never be zero, as
that is implicit !wait. This function is called only once, so it
is not the actual culprit, but there could be other instances
where we accidentally allocate something as GFP_ATOMIC.

The total number of allocations I found for each type are

sata_mv: 66 pages (270336 bytes)
mv643xx_eth: 4 pages == (16384 bytes)
orion_ehci: 154 pages (630784 bytes)
orion_ehci (atomic): 256 pages (1048576 bytes)

from the distribution of the numbers, it seems that there is exactly 1 MB
of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
in individual pages. This matches the size of your pool, so it's definitely
something coming from USB, and no single other allocation, but it does not
directly point to a specific line of code.

One thing I found was that the ARM dma-mapping code seems buggy in the way
that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.

I believe we need the patch below, but it is not clear to me if that issue
is related to your problem or now.

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..c57975f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -640,7 +641,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 
 	if (is_coherent || nommu())
 		addr = __alloc_simple_buffer(dev, size, gfp, &page);
-	else if (gfp & GFP_ATOMIC)
+	else if (!(gfp & __GFP_WAIT))
 		addr = __alloc_from_pool(size, &page);
 	else if (!IS_ENABLED(CONFIG_CMA))
 		addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, caller);
@@ -1272,7 +1273,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
 	*handle = DMA_ERROR_CODE;
 	size = PAGE_ALIGN(size);
 
-	if (gfp & GFP_ATOMIC)
+	if (!(gfp & __GFP_WAIT))
 		return __iommu_alloc_atomic(dev, size, handle);
 
 	pages = __iommu_alloc_buffer(dev, size, gfp, attrs);
8<-------

There is one more code path I could find, which is usb_submit_urb() =>
usb_hcd_submit_urb => ehci_urb_enqueue() => submit_async() =>
qh_append_tds() => qh_make(GFP_ATOMIC) => ehci_qh_alloc() =>
dma_pool_alloc() => pool_alloc_page() => dma_alloc_coherent()

So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
causes the low-level allocation to be GFP_ATOMIC, because 
qh_append_tds() is called under a spinlock. If we have hundreds
of URBs in flight, that will exhaust the pool rather quickly.

	Arnd

^ permalink raw reply related	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-19 20:05                               ` Arnd Bergmann
@ 2013-01-21 15:01                                 ` Soeren Moch
  2013-01-21 18:55                                   ` Arnd Bergmann
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-21 15:01 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 01/19/13 21:05, Arnd Bergmann wrote:
> I found at least one source line that incorrectly uses an atomic
> allocation, in ehci_mem_init():
>
>                  dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
>                          ehci->periodic_size * sizeof(__le32),
>                          &ehci->periodic_dma, 0);
>
> The last argument is the GFP_ flag, which should never be zero, as
> that is implicit !wait. This function is called only once, so it
> is not the actual culprit, but there could be other instances
> where we accidentally allocate something as GFP_ATOMIC.
>
> The total number of allocations I found for each type are
>
> sata_mv: 66 pages (270336 bytes)
> mv643xx_eth: 4 pages == (16384 bytes)
> orion_ehci: 154 pages (630784 bytes)
> orion_ehci (atomic): 256 pages (1048576 bytes)
>
> from the distribution of the numbers, it seems that there is exactly 1 MB
> of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
> in individual pages. This matches the size of your pool, so it's definitely
> something coming from USB, and no single other allocation, but it does not
> directly point to a specific line of code.
Very interesting, so this is no fragmentation problem nor something 
caused by sata or ethernet.
> One thing I found was that the ARM dma-mapping code seems buggy in the way
> that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
> not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.
>
> I believe we need the patch below, but it is not clear to me if that issue
> is related to your problem or now.
Out of curiosity I checked include/linux/gfp.h. GFP_ATOMIC is defined as 
__GFP_HIGH (which means 'use emergency pool', and no wait), so this 
patch should not make any difference for "normal" (GPF_ATOMIC / 
GFP_KERNEL) allocations, only for gfp_flags accidentally set to zero. 
So, can a new test with this patch help to debug the pool exhaustion?
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 6b2fb87..c57975f 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -640,7 +641,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
>   
>   	if (is_coherent || nommu())
>   		addr = __alloc_simple_buffer(dev, size, gfp, &page);
> -	else if (gfp & GFP_ATOMIC)
> +	else if (!(gfp & __GFP_WAIT))
>   		addr = __alloc_from_pool(size, &page);
>   	else if (!IS_ENABLED(CONFIG_CMA))
>   		addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, caller);
> @@ -1272,7 +1273,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
>   	*handle = DMA_ERROR_CODE;
>   	size = PAGE_ALIGN(size);
>   
> -	if (gfp & GFP_ATOMIC)
> +	if (!(gfp & __GFP_WAIT))
>   		return __iommu_alloc_atomic(dev, size, handle);
>   
>   	pages = __iommu_alloc_buffer(dev, size, gfp, attrs);
> 8<-------
>
> There is one more code path I could find, which is usb_submit_urb() =>
> usb_hcd_submit_urb => ehci_urb_enqueue() => submit_async() =>
> qh_append_tds() => qh_make(GFP_ATOMIC) => ehci_qh_alloc() =>
> dma_pool_alloc() => pool_alloc_page() => dma_alloc_coherent()
>
> So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
> causes the low-level allocation to be GFP_ATOMIC, because
> qh_append_tds() is called under a spinlock. If we have hundreds
> of URBs in flight, that will exhaust the pool rather quickly.
>
Maybe there are hundreds of URBs in flight in my application, I have no 
idea how to check this. It seems to me that bad reception conditions 
(lost lock / regained lock messages for some dvb channels) accelerate 
the buffer exhaustion. But even with a 4MB coherent pool I see the 
error. Is there any chance to fix this in the usb or dvb subsystem (or 
wherever)? Should I try to further increase the pool size, or what else 
can I do besides using an older kernel?

   Soeren

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-21 15:01                                 ` Soeren Moch
@ 2013-01-21 18:55                                   ` Arnd Bergmann
  2013-01-21 21:01                                     ` Greg KH
  0 siblings, 1 reply; 59+ messages in thread
From: Arnd Bergmann @ 2013-01-21 18:55 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Jason Cooper, Greg KH, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Monday 21 January 2013, Soeren Moch wrote:
> On 01/19/13 21:05, Arnd Bergmann wrote:
> > from the distribution of the numbers, it seems that there is exactly 1 MB
> > of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
> > in individual pages. This matches the size of your pool, so it's definitely
> > something coming from USB, and no single other allocation, but it does not
> > directly point to a specific line of code.
> Very interesting, so this is no fragmentation problem nor something 
> caused by sata or ethernet.

Right.

> > One thing I found was that the ARM dma-mapping code seems buggy in the way
> > that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
> > not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.
> >
> > I believe we need the patch below, but it is not clear to me if that issue
> > is related to your problem or now.
> Out of curiosity I checked include/linux/gfp.h. GFP_ATOMIC is defined as 
> __GFP_HIGH (which means 'use emergency pool', and no wait), so this 
> patch should not make any difference for "normal" (GPF_ATOMIC / 
> GFP_KERNEL) allocations, only for gfp_flags accidentally set to zero. 

Yes, or one of the rare cases where someone intentionally does something like
(GFP_ATOMIC & !__GFP_HIGH) or (GFP_KERNEL || __GFP_HIGH), which are both
wrong.

> So, can a new test with this patch help to debug the pool exhaustion?

Yes, but I would not expect this to change much. It's a bug, but not likely
the one you are hitting.

> > So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
> > causes the low-level allocation to be GFP_ATOMIC, because
> > qh_append_tds() is called under a spinlock. If we have hundreds
> > of URBs in flight, that will exhaust the pool rather quickly.
> >
> Maybe there are hundreds of URBs in flight in my application, I have no 
> idea how to check this.

I don't know a lot about USB, but I always assumed that this was not
a normal condition and that there are only a couple of URBs per endpoint
used at a time. Maybe Greg or someone else with a USB background can
shed some light on this.

> It seems to me that bad reception conditions 
> (lost lock / regained lock messages for some dvb channels) accelerate 
> the buffer exhaustion. But even with a 4MB coherent pool I see the 
> error. Is there any chance to fix this in the usb or dvb subsystem (or 
> wherever)? Should I try to further increase the pool size, or what else 
> can I do besides using an older kernel?

There are two things that I think can be done if hundreds of URBs is
indeed the normal working condition for this driver:

* change the locking in your driver so it can actually call usb_submit_urb
using GFP_KERNEL rather than GFP_ATOMIC
* after that is done, rework the ehci_hcd driver so it can do the
allocation inside of the submit_urb path to use the mem_flags rather
than unconditional GFP_ATOMIC.

Note that the problem you are seeing does not just exist in the case of
the atomic coherent pool getting exhausted, but also on any platform
that runs into an out-of-memory condition.

	Arnd

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-21 18:55                                   ` Arnd Bergmann
@ 2013-01-21 21:01                                     ` Greg KH
  2013-01-22 18:13                                       ` Arnd Bergmann
  0 siblings, 1 reply; 59+ messages in thread
From: Greg KH @ 2013-01-21 21:01 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Soeren Moch, Jason Cooper, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Mon, Jan 21, 2013 at 06:55:25PM +0000, Arnd Bergmann wrote:
> On Monday 21 January 2013, Soeren Moch wrote:
> > On 01/19/13 21:05, Arnd Bergmann wrote:
> > > from the distribution of the numbers, it seems that there is exactly 1 MB
> > > of data allocated between bus addresses 0x1f90000 and 0x1f9ffff, allocated
> > > in individual pages. This matches the size of your pool, so it's definitely
> > > something coming from USB, and no single other allocation, but it does not
> > > directly point to a specific line of code.
> > Very interesting, so this is no fragmentation problem nor something 
> > caused by sata or ethernet.
> 
> Right.
> 
> > > One thing I found was that the ARM dma-mapping code seems buggy in the way
> > > that it does a bitwise and between the gfp mask and GFP_ATOMIC, which does
> > > not work because GFP_ATOMIC is defined by the absence of __GFP_WAIT.
> > >
> > > I believe we need the patch below, but it is not clear to me if that issue
> > > is related to your problem or now.
> > Out of curiosity I checked include/linux/gfp.h. GFP_ATOMIC is defined as 
> > __GFP_HIGH (which means 'use emergency pool', and no wait), so this 
> > patch should not make any difference for "normal" (GPF_ATOMIC / 
> > GFP_KERNEL) allocations, only for gfp_flags accidentally set to zero. 
> 
> Yes, or one of the rare cases where someone intentionally does something like
> (GFP_ATOMIC & !__GFP_HIGH) or (GFP_KERNEL || __GFP_HIGH), which are both
> wrong.
> 
> > So, can a new test with this patch help to debug the pool exhaustion?
> 
> Yes, but I would not expect this to change much. It's a bug, but not likely
> the one you are hitting.
> 
> > > So even for a GFP_KERNEL passed into usb_submit_urb, the ehci driver
> > > causes the low-level allocation to be GFP_ATOMIC, because
> > > qh_append_tds() is called under a spinlock. If we have hundreds
> > > of URBs in flight, that will exhaust the pool rather quickly.
> > >
> > Maybe there are hundreds of URBs in flight in my application, I have no 
> > idea how to check this.
> 
> I don't know a lot about USB, but I always assumed that this was not
> a normal condition and that there are only a couple of URBs per endpoint
> used at a time. Maybe Greg or someone else with a USB background can
> shed some light on this.

There's no restriction on how many URBs a driver can have outstanding at
once, and if you have a system with a lot of USB devices running at the
same time, there could be lots of URBs in flight depending on the number
of host controllers and devices and drivers being used.

Sorry,

greg k-h

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-21 21:01                                     ` Greg KH
@ 2013-01-22 18:13                                       ` Arnd Bergmann
  2013-01-23 14:37                                         ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Arnd Bergmann @ 2013-01-22 18:13 UTC (permalink / raw)
  To: Greg KH
  Cc: Soeren Moch, Jason Cooper, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Monday 21 January 2013, Greg KH wrote:
> > 
> > I don't know a lot about USB, but I always assumed that this was not
> > a normal condition and that there are only a couple of URBs per endpoint
> > used at a time. Maybe Greg or someone else with a USB background can
> > shed some light on this.
> 
> There's no restriction on how many URBs a driver can have outstanding at
> once, and if you have a system with a lot of USB devices running at the
> same time, there could be lots of URBs in flight depending on the number
> of host controllers and devices and drivers being used.

Ok, thanks for clarifying that. I read some more of the em28xx driver,
and while it does have a bunch of URBs in flight, there are only five
audio and five video URBs that I see simultaneously being submitted,
and then resubmitted from their completion handlers. I think this
means that there should be 10 URBs active at any given time in this
driver, which does not explain why we get 256 allocations.

I also noticed that the initial submissions are all atomic but don't
need to, so it may be worth trying the patch below, which should also
help in low-memory situations. We could also try moving the resubmission
into a workqueue in order to let those be GFP_KERNEL, but I don't think
that will help.

	Arnd

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c b/drivers/media/usb/em28xx/em28xx-audio.c
index 2fdb66e..8b789f4 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -177,12 +177,12 @@ static int em28xx_init_audio_isoc(struct em28xx *dev)
 		struct urb *urb;
 		int j, k;
 
-		dev->adev.transfer_buffer[i] = kmalloc(sb_size, GFP_ATOMIC);
+		dev->adev.transfer_buffer[i] = kmalloc(sb_size, GFP_KERNEL);
 		if (!dev->adev.transfer_buffer[i])
 			return -ENOMEM;
 
 		memset(dev->adev.transfer_buffer[i], 0x80, sb_size);
-		urb = usb_alloc_urb(EM28XX_NUM_AUDIO_PACKETS, GFP_ATOMIC);
+		urb = usb_alloc_urb(EM28XX_NUM_AUDIO_PACKETS, GFP_KERNEL);
 		if (!urb) {
 			em28xx_errdev("usb_alloc_urb failed!\n");
 			for (j = 0; j < i; j++) {
@@ -212,7 +212,7 @@ static int em28xx_init_audio_isoc(struct em28xx *dev)
 	}
 
 	for (i = 0; i < EM28XX_AUDIO_BUFS; i++) {
-		errCode = usb_submit_urb(dev->adev.urb[i], GFP_ATOMIC);
+		errCode = usb_submit_urb(dev->adev.urb[i], GFP_KERNEL);
 		if (errCode) {
 			em28xx_errdev("submit of audio urb failed\n");
 			em28xx_deinit_isoc_audio(dev);
diff --git a/drivers/media/usb/em28xx/em28xx-core.c b/drivers/media/usb/em28xx/em28xx-core.c
index bed07a6..c5a2c4b 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -1166,7 +1166,7 @@ int em28xx_init_isoc(struct em28xx *dev, enum em28xx_mode mode,
 
 	/* submit urbs and enables IRQ */
 	for (i = 0; i < isoc_bufs->num_bufs; i++) {
-		rc = usb_submit_urb(isoc_bufs->urb[i], GFP_ATOMIC);
+		rc = usb_submit_urb(isoc_bufs->urb[i], GFP_KERNEL);
 		if (rc) {
 			em28xx_err("submit of urb %i failed (error=%i)\n", i,
 				   rc);

^ permalink raw reply related	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-22 18:13                                       ` Arnd Bergmann
@ 2013-01-23 14:37                                         ` Soeren Moch
  0 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-23 14:37 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg KH, Jason Cooper, Thomas Petazzoni, Andrew Lunn,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 22.01.2013 19:13, Arnd Bergmann wrote:
> On Monday 21 January 2013, Greg KH wrote:
>>>
>>> I don't know a lot about USB, but I always assumed that this was not
>>> a normal condition and that there are only a couple of URBs per endpoint
>>> used at a time. Maybe Greg or someone else with a USB background can
>>> shed some light on this.
>>
>> There's no restriction on how many URBs a driver can have outstanding at
>> once, and if you have a system with a lot of USB devices running at the
>> same time, there could be lots of URBs in flight depending on the number
>> of host controllers and devices and drivers being used.

I only use one host controller and (in this test) two usb devices with
the same driver.

> Ok, thanks for clarifying that. I read some more of the em28xx driver,
> and while it does have a bunch of URBs in flight, there are only five
> audio and five video URBs that I see simultaneously being submitted,
> and then resubmitted from their completion handlers. I think this
> means that there should be 10 URBs active at any given time in this
> driver, which does not explain why we get 256 allocations.

I think the audio part of the em28xx bridge is not used in my DVB tests.

Are there other allocations from orion-ehci directly? Maybe something
special for isochronous transfers (since there is no problem with my 
other dvb sticks using bulk transfers)?

> I also noticed that the initial submissions are all atomic but don't
> need to, so it may be worth trying the patch below, which should also
> help in low-memory situations. We could also try moving the resubmission
> into a workqueue in order to let those be GFP_KERNEL, but I don't think
> that will help.

I built a linux-3.7.4 with the em28xx patch and both of your dma-mapping.c
patches. I still see the
   ERROR: 1024 KiB atomic DMA coherent pool is too small!

Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-19 18:59                               ` Andrew Lunn
@ 2013-01-23 15:30                                 ` Soeren Moch
  2013-01-23 16:25                                   ` Andrew Lunn
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-23 15:30 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Arnd Bergmann, Jason Cooper, Greg KH, Thomas Petazzoni,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 19.01.2013 19:59, Andrew Lunn wrote:
>> Please find attached a debug log generated with your patch.
>>
>> I used the sata disk and two em28xx dvb sticks, no other usb devices,
>> no ethernet cable connected, tuners on saa716x-based card not used.
>>
>> What I can see in the log: a lot of coherent mappings from sata_mv
>> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
>> All coherent mappings are page aligned, some of them (from orion_ehci)
>> are not really small (as claimed in __alloc_from_pool).
>>
>> I don't believe in a memory leak. When I restart vdr (the application
>> utilizing the dvb sticks) then there is enough dma memory available
>> again.
>
> Hi Soeren
>
> We should be able to rule out a leak. Mount debugfg and then:
>
> while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done
>
> while you are capturing. See if the number goes down.
>
>        Andrew

Now I built a kernel with debugfs enabled.
It is not clear to me what I can see from the dma-api/num_free_entries 
output. After reboot (vdr running) I see decreasing numbers (3453 3452 
3445 3430...), min_free_entries is lower (3390). Sometimes the output is 
constant for several minutes ( 3396 3396 3396 3396 3396,...)

   Soeren

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-23 15:30                                 ` Soeren Moch
@ 2013-01-23 16:25                                   ` Andrew Lunn
  2013-01-23 17:07                                     ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Andrew Lunn @ 2013-01-23 16:25 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Andrew Lunn, Arnd Bergmann, Jason Cooper, Greg KH,
	Thomas Petazzoni, KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko,
	linux-mm, Kyungmin Park, Mel Gorman, Andrew Morton,
	Marek Szyprowski, linaro-mm-sig, linux-arm-kernel,
	Sebastian Hesselbarth

On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
> On 19.01.2013 19:59, Andrew Lunn wrote:
> >>Please find attached a debug log generated with your patch.
> >>
> >>I used the sata disk and two em28xx dvb sticks, no other usb devices,
> >>no ethernet cable connected, tuners on saa716x-based card not used.
> >>
> >>What I can see in the log: a lot of coherent mappings from sata_mv
> >>and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
> >>All coherent mappings are page aligned, some of them (from orion_ehci)
> >>are not really small (as claimed in __alloc_from_pool).
> >>
> >>I don't believe in a memory leak. When I restart vdr (the application
> >>utilizing the dvb sticks) then there is enough dma memory available
> >>again.
> >
> >Hi Soeren
> >
> >We should be able to rule out a leak. Mount debugfg and then:
> >
> >while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done
> >
> >while you are capturing. See if the number goes down.
> >
> >       Andrew
> 
> Now I built a kernel with debugfs enabled.
> It is not clear to me what I can see from the
> dma-api/num_free_entries output. After reboot (vdr running) I see
> decreasing numbers (3453 3452 3445 3430...), min_free_entries is
> lower (3390). Sometimes the output is constant for several minutes (
> 3396 3396 3396 3396 3396,...)

We are interesting in the long term behavior. Does it gradually go
down? Or is it stable? If it goes down over time, its clearly a leak
somewhere.

	Andrew

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-23 16:25                                   ` Andrew Lunn
@ 2013-01-23 17:07                                     ` Soeren Moch
  2013-01-23 17:20                                       ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-23 17:07 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Arnd Bergmann, Jason Cooper, Greg KH, Thomas Petazzoni,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 23.01.2013 17:25, Andrew Lunn wrote:
> On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
>> On 19.01.2013 19:59, Andrew Lunn wrote:
>>>> Please find attached a debug log generated with your patch.
>>>>
>>>> I used the sata disk and two em28xx dvb sticks, no other usb devices,
>>>> no ethernet cable connected, tuners on saa716x-based card not used.
>>>>
>>>> What I can see in the log: a lot of coherent mappings from sata_mv
>>>> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
>>>> All coherent mappings are page aligned, some of them (from orion_ehci)
>>>> are not really small (as claimed in __alloc_from_pool).
>>>>
>>>> I don't believe in a memory leak. When I restart vdr (the application
>>>> utilizing the dvb sticks) then there is enough dma memory available
>>>> again.
>>>
>>> Hi Soeren
>>>
>>> We should be able to rule out a leak. Mount debugfg and then:
>>>
>>> while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done
>>>
>>> while you are capturing. See if the number goes down.
>>>
>>>        Andrew
>>
>> Now I built a kernel with debugfs enabled.
>> It is not clear to me what I can see from the
>> dma-api/num_free_entries output. After reboot (vdr running) I see
>> decreasing numbers (3453 3452 3445 3430...), min_free_entries is
>> lower (3390). Sometimes the output is constant for several minutes (
>> 3396 3396 3396 3396 3396,...)
>
> We are interesting in the long term behavior. Does it gradually go
> down? Or is it stable? If it goes down over time, its clearly a leak
> somewhere.
>

Now (in the last hour) stable, occasionally lower numbers:
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396 
3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 
3394 3396 3396 3396 3396 3396 3396 3396

Before the last pool exhaustion going down:
3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336 
3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265 
3247 3247 3247 3242 3236 3236

Soeren

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-23 17:07                                     ` Soeren Moch
@ 2013-01-23 17:20                                       ` Soeren Moch
  2013-01-23 18:10                                         ` Andrew Lunn
  0 siblings, 1 reply; 59+ messages in thread
From: Soeren Moch @ 2013-01-23 17:20 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Arnd Bergmann, Jason Cooper, Greg KH, Thomas Petazzoni,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 23.01.2013 18:07, Soeren Moch wrote:
> On 23.01.2013 17:25, Andrew Lunn wrote:
>> On Wed, Jan 23, 2013 at 04:30:53PM +0100, Soeren Moch wrote:
>>> On 19.01.2013 19:59, Andrew Lunn wrote:
>>>>> Please find attached a debug log generated with your patch.
>>>>>
>>>>> I used the sata disk and two em28xx dvb sticks, no other usb devices,
>>>>> no ethernet cable connected, tuners on saa716x-based card not used.
>>>>>
>>>>> What I can see in the log: a lot of coherent mappings from sata_mv
>>>>> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
>>>>> All coherent mappings are page aligned, some of them (from orion_ehci)
>>>>> are not really small (as claimed in __alloc_from_pool).
>>>>>
>>>>> I don't believe in a memory leak. When I restart vdr (the application
>>>>> utilizing the dvb sticks) then there is enough dma memory available
>>>>> again.
>>>>
>>>> Hi Soeren
>>>>
>>>> We should be able to rule out a leak. Mount debugfg and then:
>>>>
>>>> while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep
>>>> 60 ; done
>>>>
>>>> while you are capturing. See if the number goes down.
>>>>
>>>>        Andrew
>>>
>>> Now I built a kernel with debugfs enabled.
>>> It is not clear to me what I can see from the
>>> dma-api/num_free_entries output. After reboot (vdr running) I see
>>> decreasing numbers (3453 3452 3445 3430...), min_free_entries is
>>> lower (3390). Sometimes the output is constant for several minutes (
>>> 3396 3396 3396 3396 3396,...)
>>
>> We are interesting in the long term behavior. Does it gradually go
>> down? Or is it stable? If it goes down over time, its clearly a leak
>> somewhere.
>>
>
> Now (in the last hour) stable, occasionally lower numbers:
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> 3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> 3394 3396 3396 3396 3396 3396 3396 3396
>
> Before the last pool exhaustion going down:
> 3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> 3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> 3247 3247 3247 3242 3236 3236
>
Here I stopped vdr (and so closed all dvb_demux devices), the number was 
remaining the same 3236, even after restart of vdr (and restart of 
streaming).

> Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-23 17:20                                       ` Soeren Moch
@ 2013-01-23 18:10                                         ` Andrew Lunn
  2013-01-28 20:59                                           ` Soeren Moch
  0 siblings, 1 reply; 59+ messages in thread
From: Andrew Lunn @ 2013-01-23 18:10 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Andrew Lunn, Arnd Bergmann, Jason Cooper, Greg KH,
	Thomas Petazzoni, KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko,
	linux-mm, Kyungmin Park, Mel Gorman, Andrew Morton,
	Marek Szyprowski, linaro-mm-sig, linux-arm-kernel,
	Sebastian Hesselbarth

> >>
> >
> >Now (in the last hour) stable, occasionally lower numbers:
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> >3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >3394 3396 3396 3396 3396 3396 3396 3396
> >
> >Before the last pool exhaustion going down:
> >3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> >3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> >3247 3247 3247 3242 3236 3236
> >
> Here I stopped vdr (and so closed all dvb_demux devices), the number
> was remaining the same 3236, even after restart of vdr (and restart
> of streaming).

So it does suggest a leak. Probably somewhere on an error path,
e.g. its lost video sync.

     Andrew

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-23 18:10                                         ` Andrew Lunn
@ 2013-01-28 20:59                                           ` Soeren Moch
  2013-01-29  0:13                                             ` Jason Cooper
  2013-01-29 11:02                                             ` Andrew Lunn
  0 siblings, 2 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-28 20:59 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Arnd Bergmann, Jason Cooper, Greg KH, Thomas Petazzoni,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On 23.01.2013 19:10, Andrew Lunn wrote:
>>>>
>>>
>>> Now (in the last hour) stable, occasionally lower numbers:
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
>>> 3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
>>> 3394 3396 3396 3396 3396 3396 3396 3396
>>>
>>> Before the last pool exhaustion going down:
>>> 3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
>>> 3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
>>> 3247 3247 3247 3242 3236 3236
>>>
>> Here I stopped vdr (and so closed all dvb_demux devices), the number
>> was remaining the same 3236, even after restart of vdr (and restart
>> of streaming).
>
> So it does suggest a leak. Probably somewhere on an error path,
> e.g. its lost video sync.
>

Now I activated the debug messages in em28xx. From the messages I see no 
correlation of the pool exhaustion and lost sync. Also I cannot see any 
error messages from the em28xx driver.
I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without draining 
the coherent pool (checked with 'cat /debug/dma-api/num_free_entries', 
which gave stable numbers), but after half an hour there are only 
init_isoc messages without corresponding stop_urbs messages and 
num_free_entries decreased until coherent pool exhaustion.

Any idea where the memory leak is? What is allocating coherent buffers 
for orion-ehci?

   Soeren


Jan 28 20:46:03 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each 
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx: 
called em28xx_init_isoc in mode 2
Jan 28 20:46:03 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each 
with 64 x 940 bytes
Jan 28 20:46:03 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx: 
called em28xx_init_isoc in mode 2
Jan 28 20:46:23 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx: 
called em28xx_stop_urbs
Jan 28 20:46:23 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx: 
called em28xx_stop_urbs
Jan 28 20:46:24 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each 
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx: 
called em28xx_init_isoc in mode 2
Jan 28 20:46:24 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each 
with 64 x 940 bytes
Jan 28 20:46:24 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx: 
called em28xx_init_isoc in mode 2
Jan 28 20:46:44 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx: 
called em28xx_stop_urbs
Jan 28 20:46:44 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx: 
called em28xx_stop_urbs
Jan 28 20:46:45 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers each 
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx: 
called em28xx_init_isoc in mode 2
Jan 28 20:46:45 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers each 
with 64 x 940 bytes
Jan 28 20:46:45 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx: 
called em28xx_init_isoc in mode 2
Jan 28 20:54:33 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool 
is too small!
Jan 28 20:54:33 guruvdr kernel: Please increase it with coherent_pool= 
kernel parameter!


^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-28 20:59                                           ` Soeren Moch
@ 2013-01-29  0:13                                             ` Jason Cooper
  2013-01-29 11:02                                             ` Andrew Lunn
  1 sibling, 0 replies; 59+ messages in thread
From: Jason Cooper @ 2013-01-29  0:13 UTC (permalink / raw)
  To: Soeren Moch, gennarone, mchehab
  Cc: Andrew Lunn, Arnd Bergmann, Greg KH, Thomas Petazzoni,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth

On Mon, Jan 28, 2013 at 09:59:18PM +0100, Soeren Moch wrote:
> On 23.01.2013 19:10, Andrew Lunn wrote:
> >>>>
> >>>
> >>>Now (in the last hour) stable, occasionally lower numbers:
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3396 3396 3396 3396 3396 3396 3396 3396 3365 3396 3394 3396 3396
> >>>3396 3396 3373 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3396 3353 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396 3396
> >>>3394 3396 3396 3396 3396 3396 3396 3396
> >>>
> >>>Before the last pool exhaustion going down:
> >>>3395 3395 3389 3379 3379 3374 3367 3360 3352 3343 3343 3343 3342 3336
> >>>3332 3324 3318 3314 3310 3307 3305 3299 3290 3283 3279 3272 3266 3265
> >>>3247 3247 3247 3242 3236 3236
> >>>
> >>Here I stopped vdr (and so closed all dvb_demux devices), the number
> >>was remaining the same 3236, even after restart of vdr (and restart
> >>of streaming).
> >
> >So it does suggest a leak. Probably somewhere on an error path,
> >e.g. its lost video sync.
> >
> 
> Now I activated the debug messages in em28xx. From the messages I
> see no correlation of the pool exhaustion and lost sync. Also I
> cannot see any error messages from the em28xx driver.
> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
> draining the coherent pool (checked with 'cat
> /debug/dma-api/num_free_entries', which gave stable numbers), but
> after half an hour there are only init_isoc messages without
> corresponding stop_urbs messages and num_free_entries decreased
> until coherent pool exhaustion.
> 
> Any idea where the memory leak is? What is allocating coherent
> buffers for orion-ehci?

Keeping in mind that I am completely unfamiliar with usb dvb, my best
guess is that the problem is in em28xx-core.c:1131

According to your log messages, it is in mode 2, which is
EM28XX_DIGITAL_MODE.

There seem to be good hints in

86d38d1e [media] em28xx: pre-allocate DVB isoc transfer buffers

I added the relevant parties to the To:...

For Gianluca and Mauro, the whole thread may be found at:

http://markmail.org/message/wm4wlgzoudixd4so#query:+page:1+mid:o7phz7cosmwpcsrz+state:results

thx,

Jason.

> 
>   Soeren
> 
> 
> Jan 28 20:46:03 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:03 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:03 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:03 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:23 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:23 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:24 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:24 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:24 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:24 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:44 guruvdr kernel: em28xx #1 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:44 guruvdr kernel: em28xx #0 em28xx_stop_urbs :em28xx:
> called em28xx_stop_urbs
> Jan 28 20:46:45 guruvdr kernel: em28xx #1/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:45 guruvdr kernel: em28xx #1 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:46:45 guruvdr kernel: em28xx #0/2-dvb: Using 5 buffers
> each with 64 x 940 bytes
> Jan 28 20:46:45 guruvdr kernel: em28xx #0 em28xx_init_isoc :em28xx:
> called em28xx_init_isoc in mode 2
> Jan 28 20:54:33 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent
> pool is too small!
> Jan 28 20:54:33 guruvdr kernel: Please increase it with
> coherent_pool= kernel parameter!
> 

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-28 20:59                                           ` Soeren Moch
  2013-01-29  0:13                                             ` Jason Cooper
@ 2013-01-29 11:02                                             ` Andrew Lunn
  2013-01-29 11:50                                               ` Soeren Moch
  1 sibling, 1 reply; 59+ messages in thread
From: Andrew Lunn @ 2013-01-29 11:02 UTC (permalink / raw)
  To: Soeren Moch
  Cc: Andrew Lunn, Arnd Bergmann, Jason Cooper, Greg KH,
	Thomas Petazzoni, KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko,
	linux-mm, Kyungmin Park, Mel Gorman, Andrew Morton,
	Marek Szyprowski, linaro-mm-sig, linux-arm-kernel,
	Sebastian Hesselbarth

> Now I activated the debug messages in em28xx. From the messages I
> see no correlation of the pool exhaustion and lost sync. Also I
> cannot see any error messages from the em28xx driver.
> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
> draining the coherent pool (checked with 'cat
> /debug/dma-api/num_free_entries', which gave stable numbers), but
> after half an hour there are only init_isoc messages without
> corresponding stop_urbs messages and num_free_entries decreased
> until coherent pool exhaustion.

Hi Soeren

em28xx_stop_urbs() is only called by em28xx_stop_streaming().

em28xx_stop_streaming() is only called by em28xx_stop_feed()
when 0 == dvb->nfeeds.

em28xx_stop_feed()and em28xx_start_feed() look O.K, dvb->nfeeds is
protected by a mutex etc.

Now, em28xx_init_isoc() is also called by buffer_prepare(). This uses
em28xx_alloc_isoc() to do the actual allocation, and that function
sets up the urb such that on completion the function
em28xx_irq_callback() is called.

It looks like there might be issues here:

Once the data has been copied out, it resubmits the urb:

       urb->status = usb_submit_urb(urb, GFP_ATOMIC);
        if (urb->status) {
                em28xx_isocdbg("urb resubmit failed (error=%i)\n",
                               urb->status);
        }
  
However, if the ubs_submit_urb fails, it looks like the urb is lost.

If you look at other code submitting urbs you have this pattern:

               rc = usb_submit_urb(isoc_bufs->urb[i], GFP_ATOMIC);
                if (rc) {
                        em28xx_err("submit of urb %i failed (error=%i)\n", i,
                                   rc);
                        em28xx_uninit_isoc(dev, mode);
                        return rc;
                }
 
Do you have your build such that you would see "urb resubmit failed"
in your logs? Are there any?

     Andrew

^ permalink raw reply	[flat|nested] 59+ messages in thread

* Re: [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
  2013-01-29 11:02                                             ` Andrew Lunn
@ 2013-01-29 11:50                                               ` Soeren Moch
  0 siblings, 0 replies; 59+ messages in thread
From: Soeren Moch @ 2013-01-29 11:50 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Arnd Bergmann, Jason Cooper, Greg KH, Thomas Petazzoni,
	KAMEZAWA Hiroyuki, linux-kernel, Michal Hocko, linux-mm,
	Kyungmin Park, Mel Gorman, Andrew Morton, Marek Szyprowski,
	linaro-mm-sig, linux-arm-kernel, Sebastian Hesselbarth,
	gennarone, mchehab

On 29.01.2013 12:02, Andrew Lunn wrote:
>> Now I activated the debug messages in em28xx. From the messages I
>> see no correlation of the pool exhaustion and lost sync. Also I
>> cannot see any error messages from the em28xx driver.
>> I see a lot of init_isoc/stop_urbs (maybe EPG scan?) without
>> draining the coherent pool (checked with 'cat
>> /debug/dma-api/num_free_entries', which gave stable numbers), but
>> after half an hour there are only init_isoc messages without
>> corresponding stop_urbs messages and num_free_entries decreased
>> until coherent pool exhaustion.
>
> Hi Soeren
>
> em28xx_stop_urbs() is only called by em28xx_stop_streaming().
>
> em28xx_stop_streaming() is only called by em28xx_stop_feed()
> when 0 == dvb->nfeeds.
>
> em28xx_stop_feed()and em28xx_start_feed() look O.K, dvb->nfeeds is
> protected by a mutex etc.
>
> Now, em28xx_init_isoc() is also called by buffer_prepare(). This uses
> em28xx_alloc_isoc() to do the actual allocation, and that function
> sets up the urb such that on completion the function
> em28xx_irq_callback() is called.
>
> It looks like there might be issues here:
>
> Once the data has been copied out, it resubmits the urb:
>
>         urb->status = usb_submit_urb(urb, GFP_ATOMIC);
>          if (urb->status) {
>                  em28xx_isocdbg("urb resubmit failed (error=%i)\n",
>                                 urb->status);
>          }
>
> However, if the ubs_submit_urb fails, it looks like the urb is lost.
>
> If you look at other code submitting urbs you have this pattern:
>
>                 rc = usb_submit_urb(isoc_bufs->urb[i], GFP_ATOMIC);
>                  if (rc) {
>                          em28xx_err("submit of urb %i failed (error=%i)\n", i,
>                                     rc);
>                          em28xx_uninit_isoc(dev, mode);
>                          return rc;
>                  }
>
> Do you have your build such that you would see "urb resubmit failed"
> in your logs? Are there any?

I only had "urb resubmit failed" messages _after_ the coherent pool 
exhaustion. So I guess something below the usb_submit_urb call is 
allocating (too much) memory, sometimes. Or can dvb_demux allocate 
memory and blame orion-ehci for it?

   Soeren


^ permalink raw reply	[flat|nested] 59+ messages in thread

end of thread, other threads:[~2013-01-29 11:52 UTC | newest]

Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-08  6:38 [PATCH] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Marek Szyprowski
2012-11-11 17:22 ` Andrew Lunn
2012-11-12  9:48   ` Soeren Moch
2012-11-12 10:38     ` Andrew Lunn
2012-11-12 11:03       ` Soeren Moch
2012-11-19  0:18 ` Jason Cooper
2012-11-19 22:48   ` Andrew Morton
2012-11-20 10:48     ` Marek Szyprowski
2012-11-20 19:52       ` Andrew Morton
2012-11-20 14:31     ` [PATCH v2] " Marek Szyprowski
2012-11-20 19:33       ` Andrew Morton
2012-11-20 20:27         ` Jason Cooper
2012-11-21  8:08         ` Marek Szyprowski
2012-11-21  8:36           ` Andrew Morton
2012-11-21  9:20             ` Marek Szyprowski
2012-11-21 19:17               ` Andrew Morton
2012-11-22 12:55                 ` Marek Szyprowski
2013-01-14 11:56       ` Soeren Moch
2013-01-15 16:56         ` Jason Cooper
2013-01-15 17:50           ` Greg KH
2013-01-15 20:16             ` Jason Cooper
2013-01-15 21:56               ` Jason Cooper
2013-01-16  0:17                 ` Soeren Moch
2013-01-16  2:40                   ` Jason Cooper
2013-01-16  3:24                     ` Soeren Moch
2013-01-16  8:55                       ` Soeren Moch
2013-01-16 15:50                         ` [PATCH] ata: sata_mv: fix sg_tbl_pool alignment Jason Cooper
2013-01-16 17:05                           ` Soeren Moch
2013-01-16 17:52                             ` Jason Cooper
2013-01-16 18:35                               ` Jason Cooper
2013-01-16 22:26                                 ` Soeren Moch
2013-01-16 23:10                               ` Soeren Moch
2013-01-17  9:11                               ` Soeren Moch
2013-01-16 17:32                         ` [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls Soeren Moch
2013-01-16 17:47                           ` Jason Cooper
2013-01-16 22:36                             ` Soeren Moch
2013-01-17 10:49                       ` Arnd Bergmann
2013-01-17 13:47                         ` Soeren Moch
2013-01-17 20:26                           ` Arnd Bergmann
2013-01-19 15:29                             ` Soeren Moch
2013-01-19 18:59                               ` Andrew Lunn
2013-01-23 15:30                                 ` Soeren Moch
2013-01-23 16:25                                   ` Andrew Lunn
2013-01-23 17:07                                     ` Soeren Moch
2013-01-23 17:20                                       ` Soeren Moch
2013-01-23 18:10                                         ` Andrew Lunn
2013-01-28 20:59                                           ` Soeren Moch
2013-01-29  0:13                                             ` Jason Cooper
2013-01-29 11:02                                             ` Andrew Lunn
2013-01-29 11:50                                               ` Soeren Moch
2013-01-19 20:05                               ` Arnd Bergmann
2013-01-21 15:01                                 ` Soeren Moch
2013-01-21 18:55                                   ` Arnd Bergmann
2013-01-21 21:01                                     ` Greg KH
2013-01-22 18:13                                       ` Arnd Bergmann
2013-01-23 14:37                                         ` Soeren Moch
2013-01-19 16:24                             ` Andrew Lunn
2013-01-15 20:05           ` Sebastian Hesselbarth
2013-01-15 20:19             ` Jason Cooper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).