OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Kernel
  • Assigned To
    Chuanhong Guo
  • Operating System All
  • Severity High
  • Priority Medium
  • Reported Version openwrt-19.07
  • Due in Version Undecided
  • Due Date 30.09.2020
    21 days overdue
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by SpiderVice - 01.04.2019
Last edited by Chuanhong Guo - 11.10.2020

FS#2216 - ath79 - eth0 Spasmodic Link Speed After Driver Changes? - 841NDv9

I’ve built the latest version of OpenWRT with stock packages and configuration, however, after random amounts of time, all clients lose connectivity because the eth0 link speed drops from the regular 100 Mbps Full Duplex to 10 Mbps Half Duplex, only to reconnect again after a couple of minutes (seconds to mintes, it depends), and do it again at another random time.

[18580.106696] eth0: link up (100Mbps/Full duplex)
[19014.825937] eth0: link up (10Mbps/Half duplex)
[19055.384105] eth0: link up (100Mbps/Full duplex)
[21927.853366] eth0: link up (10Mbps/Half duplex)
[22003.771999] eth0: link up (100Mbps/Full duplex)
[23743.685216] eth0: link down
[23744.723679] eth0: link up (100Mbps/Full duplex)
[23756.242265] eth0: link down
[23757.283590] eth0: link up (100Mbps/Full duplex)
[24075.522397] eth0: link up (10Mbps/Half duplex)
[24090.081802] eth0: link up (100Mbps/Full duplex)
[24100.481809] eth0: link up (10Mbps/Half duplex)
[24166.001178] eth0: link up (100Mbps/Full duplex)
[24500.880989] eth0: link up (10Mbps/Half duplex)

The logs aren’t very useful, it seems. Both syslog and dmesg show the same.

I suspect this started happening after this series of commits (ending with this one) where there were driver changes to the switch, as it didn’t happen before I recompiled a new build with all those newer changes:
https://github.com/openwrt/openwrt/commit/3d93b35f039de86830565420968715b300066475

Closed by  Chuanhong Guo
11.10.2020 05:01
Reason for closing:  Fixed
Project Manager
Chuanhong Guo commented on 08.04.2019 14:15

Would you mind to test if reverting only these two commits fixes your problem?

3d93b35f03 ath79: ag71xx: remove switch driver in ag71xx
443fc9ac35 ath79: use ar8216 for builtin switch

I don't have the actual hardware with me now and can't do any tests. Reverting the above two commits will switch back to old switch driver.

SpiderVice commented on 14.04.2019 18:52

Yes, I reverted my build to before those commits and it's working fine thus far.

Levin commented on 13.11.2019 01:32

I can confirm this issue on a v8 with 19.07-rc1

eth1: link up (10Mbps/Half duplex)
eth1: link up (100Mbps/Full duplex)
eth1: link up (10Mbps/Half duplex)
eth1: link up (100Mbps/Full duplex)
eth1: link down
eth1: link up (100Mbps/Full duplex)
eth1: link up (10Mbps/Half duplex)
eth1: link down
eth1: link up (100Mbps/Full duplex)
eth1: link down
eth1: link up (100Mbps/Full duplex)
eth1: link down
eth1: link up (100Mbps/Full duplex)
eth1: link down
eth1: link up (100Mbps/Full duplex)

As the cause seems to be known, maybe this should be fixed?

SpiderVice commented on 30.01.2020 12:50

Not sure if this commit (https://github.com/openwrt/openwrt/commit/0d416a8d3b990e3b78628f0e7546527709c877f7) was an attempt at fixing the issue, but my trunk build built yesterday is still showing the issue if so.

The only solutions for now are reverting those two April 2019 commits or going back to a build from back then.

Damian commented on 24.05.2020 23:52

Hi, I'm have the same issue.

tplink cpe220 v3 (OpenWrt 19.07.3 r11063-85e04e9f46)

Qualcomm Atheros QCA9533 ver 2 rev 0

Thank

[81834.557578] br-lan: port 1(eth1) entered disabled state
[81835.594706] eth1: link up (100Mbps/Full duplex)
[81835.599609] br-lan: port 1(eth1) entered blocking state
[81835.605093] br-lan: port 1(eth1) entered forwarding state
[82885.986062] eth1: link down
[82885.990081] br-lan: port 1(eth1) entered disabled state
[82887.027251] eth1: link up (100Mbps/Full duplex)
[82887.032023] br-lan: port 1(eth1) entered blocking state
[82887.037504] br-lan: port 1(eth1) entered forwarding state
[83591.100142] eth1: link up (10Mbps/Half duplex)
[83603.579855] eth1: link up (100Mbps/Full duplex)
[83720.057687] eth1: link down
[83720.061676] br-lan: port 1(eth1) entered disabled state
[83721.098979] eth1: link up (100Mbps/Full duplex)
[83721.103894] br-lan: port 1(eth1) entered blocking state
[83721.109377] br-lan: port 1(eth1) entered forwarding state
[96991.402515] eth1: link down
[96991.406876] br-lan: port 1(eth1) entered disabled state
[96992.443303] eth1: link up (100Mbps/Full duplex)
[96992.448108] br-lan: port 1(eth1) entered blocking state
[96992.453614] br-lan: port 1(eth1) entered forwarding state
[102147.684865] eth1: link up (10Mbps/Half duplex)
[102370.242133] eth1: link up (100Mbps/Full duplex)

LinuxKernel1 commented on 21.08.2020 14:00

Had the same problem on WA850RE & WA860RE (OpenWrt 19.07-SNAPSHOT, r11151-afaa978b74).

git revert 3d93b35f03 –no-edit
and
git revert 443fc9ac35 –no-edit
fixed the issue for me.

The link problems were easy to reproduce...just had to generate some higher load (e.g. a download via wifi with about 50 Mbit/s).

Any more information needed to solve this?

Jakob commented on 20.09.2020 15:11

I can confirm the issue on latest master (7190fb2da46bca02c233432db2cad57655208b68) on a Mikrotik LHG XL 2.
Only difference was that the link drops every few minutes for a short time (less than a second, the other end of the link doesn't even notice a link drop) and comes right back up to 100mbit and never drops to 10mbit.

The solution to revert the two commits mentioned by LinuxKernel1 also worked for me.
I can also provide additional infos if necessary.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing