diff mbox

3.4-rc: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out

Message ID 20120612052631.GA14567@electric-eye.fr.zoreil.com
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Francois Romieu June 12, 2012, 5:26 a.m. UTC 
Tomas Papan <tomas.papan@gmail.com> :
[...]
> [    2.780758] r8169 0000:03:00.0: eth1: RTL8168e/8111e at
> 0xffffc9000001c000, 80:ee:73:10:ad:44, XID 0c200000 IRQ 46

Let's see if it behaves like RTL_GIGA_MAC_VER_34.

Can you try the patch below ?



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Tomas Papan June 12, 2012, 6:51 a.m. UTC | #1 
Hi Francois,

I tried your patch, so far no exception has been generated (uptime 1
hour) . I'll keep it running for 1 day and then I'll come back to you.
Anyway thanks for the patch.

Regards
Tomas

On Tue, Jun 12, 2012 at 7:26 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Tomas Papan <tomas.papan@gmail.com> :
> [...]
>> [    2.780758] r8169 0000:03:00.0: eth1: RTL8168e/8111e at
>> 0xffffc9000001c000, 80:ee:73:10:ad:44, XID 0c200000 IRQ 46
>
> Let's see if it behaves like RTL_GIGA_MAC_VER_34.
>
> Can you try the patch below ?
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index bbacb37..da46588 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -3766,6 +3766,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
>        case RTL_GIGA_MAC_VER_22:
>        case RTL_GIGA_MAC_VER_23:
>        case RTL_GIGA_MAC_VER_24:
> +       case RTL_GIGA_MAC_VER_33:
>                RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
>                break;
>        default:
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomas Papan June 12, 2012, 2:34 p.m. UTC | #2 
Hi Francois,

Unfortunately after the warning occurred  once again after 28 000 seconds.
Is there anything else what can I do?

Regards
Tomas

[28914.344765] ------------[ cut here ]------------
[28914.344775] WARNING: at net/sched/sch_generic.c:256
dev_watchdog+0x16b/0x20f()
[28914.344779] Hardware name: SH55J
[28914.344782] NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out
[28914.344785] Modules linked in: vhost_net cls_route cls_u32 cls_fw
sch_sfq sch_htb ipt_REDIRECT ipt_MASQUERADE xt_limit xt_tcpudp
nf_conntrack_ipv6 nf_defrag_ipv6 xt_state iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip6table_filter
ip6_tables iptable_filter ip_tables x_tables kvm_intel kvm fuse r8169
[28914.344819] Pid: 0, comm: swapper/2 Not tainted 3.4.2 #1
[28914.344822] Call Trace:
[28914.344825]  <IRQ>  [<ffffffff81026881>] ? warn_slowpath_common+0x78/0x8c
[28914.344837]  [<ffffffff81026936>] ? warn_slowpath_fmt+0x45/0x4a
[28914.344843]  [<ffffffff81042fc2>] ? scheduler_tick+0xaf/0xc3
[28914.344850]  [<ffffffff81049f70>] ? ktime_get+0x5f/0xb9
[28914.344855]  [<ffffffff812535a0>] ? dev_watchdog+0x16b/0x20f
[28914.344861]  [<ffffffff8102f3ae>] ? run_timer_softirq+0x177/0x209
[28914.344868]  [<ffffffff8103e7b3>] ? hrtimer_interrupt+0x100/0x19b
[28914.344872]  [<ffffffff81253435>] ? qdisc_reset+0x35/0x35
[28914.344879]  [<ffffffff8102b256>] ? __do_softirq+0x7f/0x106
[28914.344884]  [<ffffffff812e298c>] ? call_softirq+0x1c/0x30
[28914.344890]  [<ffffffff81003376>] ? do_softirq+0x31/0x67
[28914.344895]  [<ffffffff8102b503>] ? irq_exit+0x44/0x75
[28914.344899]  [<ffffffff810032b5>] ? do_IRQ+0x94/0xad
[28914.344905]  [<ffffffff812e10a7>] ? common_interrupt+0x67/0x67
[28914.344908]  <EOI>  [<ffffffff81163f07>] ? intel_idle+0xde/0x103
[28914.344919]  [<ffffffff81163ee3>] ? intel_idle+0xba/0x103
[28914.344926]  [<ffffffff81220bfa>] ? cpuidle_idle_call+0x7e/0xc4
[28914.344933]  [<ffffffff81008e92>] ? cpu_idle+0x53/0x7c
[28914.344937] ---[ end trace 3d8459064a9171b4 ]---
[28914.347829] r8169 0000:01:00.0: eth1: link up
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tomas Papan June 25, 2012, 4:13 p.m. UTC | #3 
Hi,

The problem still exists in 3.4.4. I'm currently using 3.2.21, which is fine.
Unfortunately it is service affecting, after some time the machine
just froze. I'm using headless setup, so I can not tell if this causes
the problem (logs are empty). But I had with 3.2.x more than 30+ days
uptime and no problems or warnings whatsoever (dmesg and logs are
clear). I do not believe that I'm the only one with this problem,
r8169 is quite popular.
Is there anything what can I provide or try? I do not want to be stuck
on 3.2.x kernel.

[13513.912323] WARNING: at net/sched/sch_generic.c:256
dev_watchdog+0x16b/0x20f()
[13513.912327] Hardware name: SH55J
[13513.912330] NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out
[13513.912333] Modules linked in: vhost_net cls_route cls_u32 cls_fw
sch_sfq sch_htb ipt_REDIRECT ipt_MASQUERADE ipt_REJECT xt_limit
xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_state iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip6table_filter
ip6_tables iptable_filter ip_tables x_tables kvm_intel kvm fuse r8169
[13513.912369] Pid: 0, comm: swapper/2 Not tainted 3.4.4 #1
[13513.912372] Call Trace:
[13513.912374]  <IRQ>  [<ffffffff81026881>] ? warn_slowpath_common+0x78/0x8c
[13513.912386]  [<ffffffff81026936>] ? warn_slowpath_fmt+0x45/0x4a
[13513.912392]  [<ffffffff81042fc2>] ? scheduler_tick+0xaf/0xc3
[13513.912400]  [<ffffffff81049f70>] ? ktime_get+0x5f/0xb9
[13513.912404]  [<ffffffff812535f0>] ? dev_watchdog+0x16b/0x20f
[13513.912411]  [<ffffffff8102f3ae>] ? run_timer_softirq+0x177/0x209
[13513.912417]  [<ffffffff8103e7b3>] ? hrtimer_interrupt+0x100/0x19b
[13513.912421]  [<ffffffff81253485>] ? qdisc_reset+0x35/0x35
[13513.912428]  [<ffffffff8102b256>] ? __do_softirq+0x7f/0x106
[13513.912434]  [<ffffffff812e2a4c>] ? call_softirq+0x1c/0x30
[13513.912439]  [<ffffffff81003376>] ? do_softirq+0x31/0x67
[13513.912444]  [<ffffffff8102b503>] ? irq_exit+0x44/0x75
[13513.912448]  [<ffffffff810032b5>] ? do_IRQ+0x94/0xad
[13513.912454]  [<ffffffff812e1167>] ? common_interrupt+0x67/0x67
[13513.912457]  <EOI>  [<ffffffff81163f87>] ? intel_idle+0xde/0x103
[13513.912468]  [<ffffffff81163f63>] ? intel_idle+0xba/0x103
[13513.912475]  [<ffffffff81220c4a>] ? cpuidle_idle_call+0x7e/0xc4
[13513.912483]  [<ffffffff81008e92>] ? cpu_idle+0x53/0x7c
[13513.912487] ---[ end trace 635a32207d8c1b48 ]---
[13513.915428] r8169 0000:01:00.0: eth1: link up

Thanks in advance
Tomas


On Tue, Jun 12, 2012 at 4:34 PM, Tomas Papan <tomas.papan@gmail.com> wrote:
> Hi Francois,
>
> Unfortunately after the warning occurred  once again after 28 000 seconds.
> Is there anything else what can I do?
>
> Regards
> Tomas
>
> [28914.344765] ------------[ cut here ]------------
> [28914.344775] WARNING: at net/sched/sch_generic.c:256
> dev_watchdog+0x16b/0x20f()
> [28914.344779] Hardware name: SH55J
> [28914.344782] NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out
> [28914.344785] Modules linked in: vhost_net cls_route cls_u32 cls_fw
> sch_sfq sch_htb ipt_REDIRECT ipt_MASQUERADE xt_limit xt_tcpudp
> nf_conntrack_ipv6 nf_defrag_ipv6 xt_state iptable_nat nf_nat
> nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip6table_filter
> ip6_tables iptable_filter ip_tables x_tables kvm_intel kvm fuse r8169
> [28914.344819] Pid: 0, comm: swapper/2 Not tainted 3.4.2 #1
> [28914.344822] Call Trace:
> [28914.344825]  <IRQ>  [<ffffffff81026881>] ? warn_slowpath_common+0x78/0x8c
> [28914.344837]  [<ffffffff81026936>] ? warn_slowpath_fmt+0x45/0x4a
> [28914.344843]  [<ffffffff81042fc2>] ? scheduler_tick+0xaf/0xc3
> [28914.344850]  [<ffffffff81049f70>] ? ktime_get+0x5f/0xb9
> [28914.344855]  [<ffffffff812535a0>] ? dev_watchdog+0x16b/0x20f
> [28914.344861]  [<ffffffff8102f3ae>] ? run_timer_softirq+0x177/0x209
> [28914.344868]  [<ffffffff8103e7b3>] ? hrtimer_interrupt+0x100/0x19b
> [28914.344872]  [<ffffffff81253435>] ? qdisc_reset+0x35/0x35
> [28914.344879]  [<ffffffff8102b256>] ? __do_softirq+0x7f/0x106
> [28914.344884]  [<ffffffff812e298c>] ? call_softirq+0x1c/0x30
> [28914.344890]  [<ffffffff81003376>] ? do_softirq+0x31/0x67
> [28914.344895]  [<ffffffff8102b503>] ? irq_exit+0x44/0x75
> [28914.344899]  [<ffffffff810032b5>] ? do_IRQ+0x94/0xad
> [28914.344905]  [<ffffffff812e10a7>] ? common_interrupt+0x67/0x67
> [28914.344908]  <EOI>  [<ffffffff81163f07>] ? intel_idle+0xde/0x103
> [28914.344919]  [<ffffffff81163ee3>] ? intel_idle+0xba/0x103
> [28914.344926]  [<ffffffff81220bfa>] ? cpuidle_idle_call+0x7e/0xc4
> [28914.344933]  [<ffffffff81008e92>] ? cpu_idle+0x53/0x7c
> [28914.344937] ---[ end trace 3d8459064a9171b4 ]---
> [28914.347829] r8169 0000:01:00.0: eth1: link up
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Francois Romieu June 25, 2012, 8:25 p.m. UTC | #4 
Tomas Papan <tomas.papan@gmail.com> :
[...]
> Is there anything what can I provide or try? I do not want to be stuck
> on 3.2.x kernel.

You can try to revert 036dafa28da1e2565a8529de2ae663c37b7a0060
diff mbox

Patch

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bbacb37..da46588 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3766,6 +3766,7 @@  static void rtl_init_rxcfg(struct rtl8169_private *tp)
 	case RTL_GIGA_MAC_VER_22:
 	case RTL_GIGA_MAC_VER_23:
 	case RTL_GIGA_MAC_VER_24:
+	case RTL_GIGA_MAC_VER_33:
 		RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
 		break;
 	default: