What does the tcp_fastretrans_alert error mean?

Question

I found this error a couple of times in /var/log/messages after experiencing some odd TCP behavior: For some reason, if I connect to for example SSH for the first time in say an hour, the connection is dropped by the server.

I tried doing a Google Search but was unable to find useful information. Could anybody tell me if the TCP problem and this error are related? And if so, how do I fix it?

I'm running CentOS 6.5, and IPtables accepts all incoming TCP connections.

Jan 10 03:01:17 ns507369 kernel: ------------[ cut here ]------------
Jan 10 03:01:17 ns507369 kernel: WARNING: at net/ipv4/tcp_input.c:2789 tcp_fastretrans_alert+0x33d/0xc40()
Jan 10 03:01:17 ns507369 kernel: CPU: 3 PID: 0 Comm: swapper/3 Tainted: G        W    3.10.23-xxxx-std-ipv6-64 #1
Jan 10 03:01:17 ns507369 kernel: Hardware name: Supermicro X9SRE/X9SRE-3F/X9SRi/X9SRi-3F/X9SRE/X9SRE-3F/X9SRi/X9SRi-3F, BIOS 3.0 07/05/2013
Jan 10 03:01:17 ns507369 kernel: 0000000000000009 ffff88087fcc3940 ffffffff81d38724 ffff88087fcc3980
Jan 10 03:01:17 ns507369 kernel: ffffffff810bc696 ffff88087fcc3970 ffff8807fa2ef080 0000000000004f0e
Jan 10 03:01:17 ns507369 kernel: 0000000000000000 000000000000003b 00000000000000b6 ffff88087fcc3990
Jan 10 03:01:17 ns507369 kernel: Call Trace:
Jan 10 03:01:17 ns507369 kernel: <IRQ>  [<ffffffff81d38724>] dump_stack+0x19/0x1b
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810bc696>] warn_slowpath_common+0x66/0x90
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810bc795>] warn_slowpath_null+0x15/0x20
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bf19cd>] tcp_fastretrans_alert+0x33d/0xc40
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bf2ed8>] tcp_ack+0x978/0xee0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bf3fc2>] tcp_rcv_established+0x282/0x8c0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81c30a19>] ? nf_nat_ipv4_fn+0x1e9/0x250
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bfcf21>] tcp_v4_do_rcv+0x161/0x310
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81c2b81e>] ? ipv4_confirm+0xae/0x110
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bfee09>] tcp_v4_rcv+0x649/0x790
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bdb0f0>] ? ip_rcv_finish+0x340/0x340
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b8cc8c>] ? nf_hook_slow+0x6c/0x130
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bdb0f0>] ? ip_rcv_finish+0x340/0x340
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bdb19c>] ip_local_deliver_finish+0xac/0x200
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bdb4b0>] ip_local_deliver+0x80/0x90
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bdae2b>] ip_rcv_finish+0x7b/0x340
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bdb72d>] ip_rcv+0x26d/0x390
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b5f382>] __netif_receive_skb_core+0x4e2/0x630
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81bff0b9>] ? tcp4_gro_receive+0x99/0x110
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b5f4f1>] __netif_receive_skb+0x21/0x70
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b62a68>] netif_receive_skb+0x28/0x90
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b63038>] napi_gro_receive+0x88/0xc0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81944c86>] igb_poll+0x6c6/0xf50
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810e4f45>] ? check_preempt_curr+0x75/0xa0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b6341b>] net_rx_action+0xfb/0x1a0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810ca1cf>] ? get_next_timer_interrupt+0x1df/0x270
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810c390a>] __do_softirq+0xca/0x1a0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81d4283c>] call_softirq+0x1c/0x30
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810426ad>] do_softirq+0x4d/0x80
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810c3b35>] irq_exit+0x95/0xa0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810422ae>] do_IRQ+0x5e/0xd0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81d40f6a>] common_interrupt+0x6a/0x6a
Jan 10 03:01:17 ns507369 kernel: <EOI>  [<ffffffff81b1d0a6>] ? cpuidle_enter_state+0x56/0xd0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b1d0a2>] ? cpuidle_enter_state+0x52/0xd0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81b1d1be>] cpuidle_idle_call+0x9e/0x150
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810e107d>] ? __atomic_notifier_call_chain+0xd/0x10
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81048db9>] arch_cpu_idle+0x9/0x20
Jan 10 03:01:17 ns507369 kernel: [<ffffffff810f0cf6>] cpu_startup_entry+0xd6/0x1b0
Jan 10 03:01:17 ns507369 kernel: [<ffffffff81d26be0>] start_secondary+0x1e1/0x1e8
Jan 10 03:01:17 ns507369 kernel: ---[ end trace 48a4051d21162239 ]---

Answer 1

That's caused by a kernel bug. It was patched over a year ago in the distribution kernels, but you are not running the kernel provided by your distribution. Either switch to a distribution kernel or contact whoever built your kernel.