From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: ucc_geth: nf_conntrack: table full, dropping packet. Date: Mon, 23 Mar 2009 19:08:42 +0100 Message-ID: <49C7D02A.6080104@cosmosbay.com> References: <49C77D71.8090709@trash.net> <49C780AD.70704@trash.net> <49C7CBB2.4020205@cosmosbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: avorontsov@ru.mvista.com, Patrick McHardy , netdev@vger.kernel.org To: Joakim Tjernlund Return-path: Received: from gw1.cosmosbay.com ([212.99.114.194]:37370 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760280AbZCWSIy convert rfc822-to-8bit (ORCPT ); Mon, 23 Mar 2009 14:08:54 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Joakim Tjernlund a =E9crit : > Eric Dumazet wrote on 23/03/2009 18:49:38: >=20 >> Joakim Tjernlund a =E9crit : >>> Patrick McHardy wrote on 23/03/2009 13:29:33: >>> >>>> Joakim Tjernlund wrote: >>>>> Patrick McHardy wrote on 23/03/2009 13:15:45: >>>>>> Joakim Tjernlund wrote: >>>>>>> doing a "ping -f -l 3" on my host towards my board on linus tre= e=20 > as=20 >>> of=20 >>>>>>> Friday results in lots of: >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> __ratelimit: 11 callbacks suppressed >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> nf_conntrack: table full, dropping packet. >>>>>>> >>>>>>> for ucc_geth on a MPC832x. >>>>>>> This really looks strange to me, ideas? >>>>>> What does /proc/net/netfilter/nf_conntrack show? >>>>> There is no /proc/net/netfilter/nf_conntrack. There is a >>>>> /proc/net/nf_conntrack though and it is empty. If I telnet >>>>> to the board I see: >>>> That means that something is leaking conntrack references, most=20 > likely >>>> by leaking skbs. Since I haven't seen any other reports, my guess=20 > would >>>> be the ucc_geth driver. >>>> >>> Mucking around with the ucc_geth driver I found that if I: >>> - Move TX from IRQ to NAPI context >>> - double the weight. >>> - after booting up, wait a few mins until the JFFS2 GC kernel thre= ad=20 > has=20 >>> stopped >>> scanning the FS=20 >>> >>> Then the "nf_conntrack: table full, dropping packet." msgs stops. >>> Does this seem right to you guys? >>> >> How many cpus do you have ? >=20 > Just one, it is an embedded board running at 266 MHz >=20 >> What kernel version do you use ? >=20 > Linus tree as of Friday >=20 > I suspect RCU problem. Maybe the GC kernel threads blocks synchronize_r= cu() ?