[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <4B65D0F9.2020602@majjas.com>
Date: Sun, 31 Jan 2010 13:50:33 -0500
From: Michael Breuer <mbreuer@...jas.com>
To: Jarek Poplawski <jarkao2@...il.com>
Cc: Stephen Hemminger <shemminger@...ux-foundation.org>,
David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
flyboy@...il.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, Michael Chan <mchan@...adcom.com>,
Don Fry <pcnet32@...izon.net>,
Francois Romieu <romieu@...zoreil.com>,
Matt Carlson <mcarlson@...adcom.com>
Subject: Re: [PATCH] sky2: receive dma mapping error handling
On 1/30/2010 11:55 PM, Michael Breuer wrote:
> On 01/30/2010 07:34 PM, Jarek Poplawski wrote:
>>
>> Could you try the patch below to show maybe some other users of
>> dma-debug entries?
>>
>> Jarek P.
>> ---
>>
> With the default # entries & dma_debug_driver=sky2:
>
> 6:00 is eth0 & 4:00 is eth1.
>
> Jan 30 23:53:14 mail kernel: DMA-API: 0000:06:00.0: entries: 31961
> ...
>
I put a printk as a third else case in sky2_tx_unmap. Looks like the
issue is that a large number (perhaps all) calls to sky2_tx_unmap have
re->flags set to neither TX_MAP_SINGLE or TX_MAP_PAGE. Thus the elements
are never being unmapped.
I suspect that the system collapses when using DMAR sooner than if not
using DMAR. Probably some hardware limitation on the number of mapped
elements that is less than the software limitation. I don't see at
present how a ring element can ever get to this code without re->flags
being set to one or the other.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists