just an update: this bug is not related to
ftp: it appears to me that after some
traffic (imap, http) linux stop receiving

there isn't any iptables rules
(there isn't even the iptables package

Ip:
    4808 total packets received
    28 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    4685 incoming packets delivered
    1226 requests sent out
Icmp:
    0 ICMP messages received
    0 input ICMP message failed.
    ICMP input histogram:
    68 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 47
        echo request: 21
IcmpMsg:
        OutType3: 47
        OutType8: 21
Tcp:
    21 active connections openings
    0 passive connection openings
    0 failed connection attempts
    0 connection resets received
    0 connections established
    1490 segments received
    1104 segments send out
    30 segments retransmited
    0 bad segments received.
    9 resets sent
Udp:
    4 packets received
    0 packets to unknown port received.
    0 packet receive errors
    24 packets sent
UdpLite:
TcpExt:
    10 TCP sockets finished time wait in fast timer
    27 delayed acks sent
    1240 packet headers predicted
    58 acknowledgments not containing data payload received
    5 predicted acknowledgments
    1 congestion windows recovered without slow start after partial ack
    5 other TCP timeouts
    4 connections aborted due to timeout
IpExt:

slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
isofs_inode_cache      0      0    320   12    1 : tunables    0    0    0 : slabdata      0      0      0
fat_inode_cache       23     23    344   23    2 : tunables    0    0    0 : slabdata      1      1      0
fat_cache            170    170     24  170    1 : tunables    0    0    0 : slabdata      1      1      0
sgpool-128        ...
[ message continues ]

Thanks Marco

You probably have the problem Ingo reported on lkml, please try Herbert fix :

http://marc.info/?l=linux-kernel&m=123790184128396&w=2

net: Fix netpoll lockup in legacy receive path

When I fixed the GRO crash in the legacy receive path I used
napi_complete to replace __napi_complete.  Unfortunately they're
not the same when NETPOLL is enabled, which may result in us
not calling __napi_complete at all.

While this is fishy in itself, let's make the obvious fix right
now of reverting to the previous state where we always called
__napi_complete.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/net/core/dev.c b/net/core/dev.c
index e3fe5c7..523f53e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2580,24 +2580,26 @@ static int process_backlog(struct napi_struct *napi, int quota)
 	int work = 0;
 	struct softnet_data *queue = &__get_cpu_var(softnet_data);
 	unsigned long start_time = jiffies;
+	struct sk_buff *skb;
 
 	napi->weight = weight_p;
 	do {
-		struct sk_buff *skb;
-
 		local_irq_disable();
 		skb = __skb_dequeue(&queue->input_pkt_queue);
-		if (!skb) {
-			local_irq_enable();
-			napi_complete(napi);
-			goto out;
-		}
 		local_irq_enable();
+		if (!skb)
+			break;
 
 		napi_gro_receive(napi, skb);
 	} while (++work < quota && jiffies == start_time);
 
 	napi_gro_flush(napi);
+	if (skb)
+		goto out;
+
+	local_irq_disable();
+	__napi_complete(napi);
+	local_irq_enable();
 
 out:
 	return work;


--

[ message continues ]