Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Apr 1, 2019 · 8 comments
Closed
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Apr 1, 2019

Spider-Vice:

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:
3d93b35

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 8, 2019

gch981213:

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

3d93b35 ath79: ag71xx: remove switch driver in ag71xx
443fc9a 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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Apr 14, 2019

Spider-Vice:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 13, 2019

levin41:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Jan 30, 2020

Spider-Vice:

Not sure if this commit (0d416a8) 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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 24, 2020

lw9eau:

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)

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Aug 21, 2020

LinuxKernel1:

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

git revert 3d93b35 --no-edit
and
git revert 443fc9a --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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 20, 2020

XDjackieXD:

I can confirm the issue on latest master (7190fb2) 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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 21, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant