[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <4B65FD12.7090101@majjas.com>
Date: Sun, 31 Jan 2010 16:58:42 -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/31/2010 1:50 PM, Michael Breuer wrote:
> 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.
>
>
Put some more debugging code in... re->flags is always NULL upon entry
to sky2_tx_unmap.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists