netdev
[Top] [All Lists]

Re: iptables breakage WAS(Re: dummy as IMQ replacement

To: hadi@xxxxxxxxxx
Subject: Re: iptables breakage WAS(Re: dummy as IMQ replacement
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Fri, 25 Mar 2005 20:01:18 +0100
Cc: Andy Furniss <andy.furniss@xxxxxxxxxxxxx>, Harald Welte <laforge@xxxxxxxxxxxx>, Remus <rmocius@xxxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>, Nguyen Dinh Nam <nguyendinhnam@xxxxxxxxx>, Andre Tomt <andre@xxxxxxxx>, syrius.ml@xxxxxxxxxx, Damion de Soto <damion@xxxxxxxxxxxx>
In-reply-to: <1111775660.1092.571.camel@jzny.localdomain>
References: <1107123123.8021.80.camel@jzny.localdomain> <423B7BCB.10400@dsl.pipex.com> <1111410890.1092.195.camel@jzny.localdomain> <423F41AD.3010902@dsl.pipex.com> <1111444869.1072.51.camel@jzny.localdomain> <423F71C2.8040802@dsl.pipex.com> <1111462263.1109.6.camel@jzny.localdomain> <42408998.5000202@dsl.pipex.com> <1111550254.1089.21.camel@jzny.localdomain> <4241C478.5030309@dsl.pipex.com> <1111607112.1072.48.camel@jzny.localdomain> <4241D764.2030306@dsl.pipex.com> <1111612042.1072.53.camel@jzny.localdomain> <4241F1D2.9050202@dsl.pipex.com> <4241F7F0.2010403@dsl.pipex.com> <1111625608.1037.16.camel@jzny.localdomain> <424212F7.10106@dsl.pipex.com> <1111663947.1037.24.camel@jzny.localdomain> <1111665450.1037.27.camel@jzny.localdomain> <4242DFB5.9040802@dsl.pipex.com> <1111749220.1092.457.camel@jzny.localdomain> <1111754346.1092.480.camel@jzny.localdomain> <42444A14.3090809@trash.net> <1111775660.1092.571.camel@jzny.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1
jamal wrote:
On Fri, 2005-03-25 at 12:27, Patrick McHardy wrote:

What does ps -eo args,wchan show?

It shows tc stuck on wait_for_packet;


user space is stuck in recvmsg(). It seems to be waiting for an
NLMSG_DONE to complete the transaction - but that never comes.

One thing i've verified so far is it has nothing to do with the module
replay code. I am also doubting it has naything to do with locks in
the kernel. Its also a possibility that something changed in the
iproute2 causing this stuck waiting for NLMSG_DONE.

Could it be that it is simply not making any forward progress? tcf_dump_walker() doesn't save the number of skipped entries, but the last order dumped, so it could dump the same entries again and again when they exceed the room in the skb.

Regards
Patrick

<Prev in Thread] Current Thread [Next in Thread>