Kern.info kernel: eth0: tx timeout

This error occurs when you restart the tl-wa901nd device and you do not have an internet connection, the way to solve the error manually is by disconnecting the ethernet cable and waiting for a few seconds and reconnecting it once restarted.
In the rc.local file place:

eth0 connection

/etc/init.d/network stop
logger -t kludge "eth0 stop sama"
sleep 10
/etc/init.d/network start
logger -t kludge "eth0 start sama"

waiting to be solved, but still fails, do any of you know how to solve it?

I know it's an somehow old topic.

What version of tl-wa901nd? By any chance V1 (AR7240) or V4 (TP9343) or V5 (TP9343)?
Also what version of OpenWRT 18.6.x, 19.7.x?

I ask because I have a somehow similar problem. In my case the switch is basicaly getting stuck after tx timeout and it's only in the case of the 4 lan ports, the wan port is not affected (but the wan port is separated compared to the 4 ports switch).
wireless is not affected so the problem is entirely with the lan switch and nothing else.

an ifup lan from wireless is fixing it... not a viable solution when this is used as a wireless client so i kinda need the eth switch working...

L.E.: I can constantly trigger the eth0: tx timeout on my 841nd v5 (ar7200) followed by the eth switch getting stuck and no longer sending any usefull trafic on the eth ports (sometimes it recover after some minutes sometimes it just remain stuck, ifup lan temp fix it but it will happen again). First time it's happening the log show the following:

Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.693553] ------------[ cut here ]------------
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.698221] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 0x802a9738
Sun Apr 26 11:48:59 2020 kern.info kernel: [25447.705315] NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.711854] Modules linked in: ath9k ath9k_common ath9k_hw ath nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables gpio_button_hotplug
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.764877] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.219 #0
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.770718] Stack : 80447522 00000032 00000000 00000001 00000000 00000000 00000000 00000000
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.779167]         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.787617]         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.796095]         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.804546]         00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.812979]         ...
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.815465] Call Trace:
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.817785] [<8006ab8c>] 0x8006ab8c
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.821283] [<8006ab8c>] 0x8006ab8c
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.824808] [<8007f9a4>] 0x8007f9a4
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.828310] [<802a9738>] 0x802a9738
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.831824] [<8007f9dc>] 0x8007f9dc
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.835360] [<802a9738>] 0x802a9738
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.838862] [<80092d00>] 0x80092d00
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.842368] [<802a95c4>] 0x802a95c4
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.845880] [<800b36fc>] 0x800b36fc
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.849387] [<8006d690>] 0x8006d690
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.852894] [<800b3944>] 0x800b3944
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.856407] [<800aa878>] 0x800aa878
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.859918] [<800823cc>] 0x800823cc
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.863417] [<800ae4bc>] 0x800ae4bc
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.866934] [<800a9fbc>] 0x800a9fbc
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.870439] [<801e3eb8>] 0x801e3eb8
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.873947] [<800660b8>] 0x800660b8
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.877438]
Sun Apr 26 11:48:59 2020 kern.warn kernel: [25447.878936] ---[ end trace 3c20d976bd0e1077 ]---
Sun Apr 26 11:48:59 2020 kern.info kernel: [25447.883580] eth0: tx timeout

starting from second time it happens it's just:

eth0: tx timeout

Atm I test a self-built OpenWRT 18.06 on my 841n v5 with:

pdata->use_flow_control = 1;

removed for ar7200 in

target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c

So far the 841nd v5 has 14 hours of uptime without a crash or tx timeout error or eth switch getting stuck, basicaly I'm no longer capable to replicate the problem (simply opening 2 particular websites was triggering it, anyway high traffic is what is triggering it) with pdata->use_flow_control = 1; removed.
The ideea came up after reading:
https://bugs.openwrt.org/index.php?do=details&task_id=106

By looking at
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=refs%2Fheads%2Fmaster&st=commit&s=flow+control
I kinda think flow control is just not working on some SoCs.
It has been enabled for AR7200, disabled for AR7200, enabled for a couple more SoCs (AR7200 included), disabled for AR934x and now I see how disabling it for AR7200 is fixing my problem.

I belive that the following commit
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=26b8db253745b0591bfffa21f02323428f11a88f
added this bug.

My main concern is the fact that is basicaly crashing the eth switch. If it happens during sysupgrade it will brick the device...

14 hours is not exactly enough to call it fixed, if I will hit 48 hours without being able to replicate it I will call it fixed :smiley: .