Gigabit Ethernet "EEE" causing trouble between Pi 4 boards and almost any device

[julienrobin28]

Hi there,

I finally found a (temporary?) solution to all my last years link stability issues with RPi4 (I use a lot of them in many scenarios, lot of them actively using the integrated NIC).

"EEE" (which stands for Energy-Efficient Ethernet) was the culprit: it causes a lots of trouble with the Pi 4 integrated NIC in half of the situations in which I'm using a Pi 4. I even started using cheap Amazon USB3 NIC to workaround those issues.

But EEE can finally be disabled by running

Code: Select all

ethtool --set-eee eth0 eee off

Disabling "eee" corrected ALL of my problems listed below!

The problems I had were:

• 1) First packets are dropped and following ones are transmitted right

• 2) Sometimes I had to unplug and replug the cable up to 5 or 6 times to avoid 1)

• 3) The problem exists with several switch trademark (at least trendnet and tplink), and even connected directly to my computer (MS-7B79)

• 4) It exists with any cable (20m, 1m, cat 5e, cat6, cat 7...), with Pi4 1.1 2GB model to 1.4 8GB model, with genuine power supplies

• 5) I had cases of link going down, up, down up... while an USB NIC (ax88179) or any other device was running fine on the same cable

But... on others computers, EEE is enabled with no issues. Do you know if this bad "EEE" behavior on Pi4 can be corrected by firmware? If it's hardware, then I guess I'll just keep it disabled.

Thank you in advance for your feedback

[julienrobin28]

I discovered that even where I believed my Pi 4 Gigabit Ethernet were working fine (without disabling eee), actually they weren't working as well as I thought. One of them was, but after unplugging / replugging the ethernet cable, the issue appeared too, so it was pure luck.

Which tends to say that maybe, this issue affects most Pi 4 users around the world (more or less silently).

Running this little script as root / sudo from another computer (against your Pi address if it's connected trough Ethernet) is supposed to give you 100 packets transmitted, 100 received, 0% packet loss, time 25ms (time depends on you computer)

Code: Select all

#!/bin/sh
while true
do
	ping -f 192.168.28.104 -c 100
	sleep 0.75
done

If your target Pi isn't transferring anything, then EEE will make it enter and exit power saving every ~0.8 seconds, which helps to see if you have the same fault.

If you let it run few minutes, then you look with ctrl+f for "transmitted," and "transmitted, 100" and you should have the same amount.

If you have packet loss, then you disable "eee", then you don't have packet loss anymore, you are affected by the issue

[julienrobin28]

Hi back

By reading back my original messages and title, I realized I should say that EEE is working perfectly fine on all of my devices, apart from Pi 4.

What I meant was: EEE is causing troubles with all my Pi 4 boards, no matter what device is connected to it (as long as it is EEE capable, if EEE is active and enabled, I have the issues).


After some tests, I found EEE is saving 250 mW (0.05 Ampers on 5V) compared to when it's disabled. On boards which are running 7/7 - 24/24, it's about 2200 W.h per year!

Does somebody know if EEE poor link performance/stability of Raspberry Pi 4 can be solved by firmware update?
Having it disabled does not seems to be the ideal solution.

Thank you in advance

[pidd]

Absolutely no problem with mine running from a Pi4 to a Pi4 through a TP-Link switch that uses Green Energy Technology which is a superset of EEE (IEEE 802.3az).

[julienrobin28]

Hi, and thanks for your feedback

Can you double check if you have EEE status: enabled - active when playing

Code: Select all

ethtool --show-eee eth0 

So when from another computer you play several times

Code: Select all

ping -f IP_ofThePI4 -c 100

you have no packets loss?

[pidd]

Ah, interesting ....

Code: Select all

ethtool --show-eee eth0
EEE Settings for eth0:
	EEE status: enabled - inactive
	Tx LPI: disabled
	Supported EEE link modes:  100baseT/Full 
	                           1000baseT/Full 
	Advertised EEE link modes:  100baseT/Full 
	                            1000baseT/Full 
	Link partner advertised EEE link modes:  Not reported

Looks like TP-Link's GET doesn't like EEE, or perhaps they binned it because it has too many problems.

[julienrobin28]

Hi pidd thank you for this information

It's strange but you're not alone, for one of my switches which is supposed to be "Green Ethernet compatible", none of my devices have EEE mode active. It's pretty strange!
TL-SG1008D V6 - https://www.tp-link.com/ca/home-network ... l-sg1008d/

Confirmation
To be a little bit more sure about all this, a made some test-bench with one of my spare switch (which is EEE compatible, Trendnet TEG-S8g) and once again I can confirm there is a problem with Raspberry Pi 4 link, and not with others devices link.


All of the computers had EEE enabled and active.
There is a 2nd Pi4 behind the laptop

One of the Pi 4 had a few packet loss (until I unplugged / re-plugged it).

Code: Select all

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.188/0.224/0.021 ms, ipg/ewma 0.198/0.196 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.201/0.205/0.216/0.019 ms, ipg/ewma 0.229/0.207 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
. 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 18ms
rtt min/avg/max/mdev = 0.187/0.199/0.227/0.020 ms, ipg/ewma 2.046/0.208 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.199/0.227/0.020 ms, ipg/ewma 0.217/0.206 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.183/0.304/0.941/0.221 ms, ipg/ewma 0.356/0.276 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.192/0.226/0.023 ms, ipg/ewma 0.206/0.199 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.187/0.213/0.016 ms, ipg/ewma 0.196/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.204/0.016 ms, ipg/ewma 0.194/0.190 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.187/0.212/0.016 ms, ipg/ewma 0.196/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.187/0.215/0.019 ms, ipg/ewma 0.197/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.213/0.020 ms, ipg/ewma 0.195/0.192 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.189/0.202/0.014 ms, ipg/ewma 0.201/0.192 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.240/0.318/0.055 ms, ipg/ewma 0.268/0.242 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.217/0.015 ms, ipg/ewma 0.196/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.182/0.186/0.209/0.019 ms, ipg/ewma 0.196/0.191 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.204/0.014 ms, ipg/ewma 0.195/0.190 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.201/0.010 ms, ipg/ewma 0.193/0.189 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.219/0.013 ms, ipg/ewma 0.196/0.195 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.191/0.203/0.018 ms, ipg/ewma 0.216/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.189/0.215/0.017 ms, ipg/ewma 0.203/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.189/0.203/0.018 ms, ipg/ewma 0.203/0.192 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.191/0.215/0.010 ms, ipg/ewma 0.208/0.196 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.190/0.205/0.013 ms, ipg/ewma 0.206/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.192/0.215/0.016 ms, ipg/ewma 0.211/0.198 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.191/0.205/0.018 ms, ipg/ewma 0.222/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.193/0.214/0.017 ms, ipg/ewma 0.218/0.197 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.191/0.212/0.013 ms, ipg/ewma 0.207/0.195 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.192/0.210/0.006 ms, ipg/ewma 0.216/0.196 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.192/0.204/0.014 ms, ipg/ewma 0.216/0.195 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.191/0.235/0.017 ms, ipg/ewma 0.202/0.200 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.186/0.200/0.017 ms, ipg/ewma 0.194/0.189 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.187/0.212/0.016 ms, ipg/ewma 0.195/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.215/0.021 ms, ipg/ewma 0.201/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.182/0.187/0.215/0.014 ms, ipg/ewma 0.195/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.182/0.185/0.198/0.015 ms, ipg/ewma 0.193/0.188 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.188/0.212/0.011 ms, ipg/ewma 0.196/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.201/0.011 ms, ipg/ewma 0.193/0.189 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.185/0.198/0.016 ms, ipg/ewma 0.193/0.188 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.188/0.210/0.009 ms, ipg/ewma 0.196/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.197/0.004 ms, ipg/ewma 0.193/0.188 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.187/0.212/0.018 ms, ipg/ewma 0.196/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.187/0.212/0.013 ms, ipg/ewma 0.195/0.192 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.190/0.202/0.008 ms, ipg/ewma 0.209/0.192 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.193/0.216/0.020 ms, ipg/ewma 0.218/0.198 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.190/0.223/0.014 ms, ipg/ewma 0.203/0.197 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.186/0.213/0.019 ms, ipg/ewma 0.195/0.192 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.192/0.211/0.011 ms, ipg/ewma 0.215/0.196 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.192/0.206/0.008 ms, ipg/ewma 0.216/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.191/0.232/0.020 ms, ipg/ewma 0.206/0.200 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.194/0.228/0.017 ms, ipg/ewma 0.217/0.202 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.193/0.215/0.018 ms, ipg/ewma 0.222/0.198 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.193/0.215/0.011 ms, ipg/ewma 0.219/0.197 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.182/0.188/0.213/0.021 ms, ipg/ewma 0.201/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 0.183/0.265/0.978/0.238 ms, ipg/ewma 0.289/0.424 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.216/0.020 ms, ipg/ewma 0.201/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.182/0.186/0.206/0.015 ms, ipg/ewma 0.196/0.190 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.215/0.019 ms, ipg/ewma 0.201/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.213/0.020 ms, ipg/ewma 0.201/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.190/0.218/0.012 ms, ipg/ewma 0.203/0.196 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.184/0.190/0.217/0.015 ms, ipg/ewma 0.204/0.195 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.183/0.188/0.214/0.019 ms, ipg/ewma 0.201/0.194 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.190/0.202/0.009 ms, ipg/ewma 0.209/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.193/0.214/0.020 ms, ipg/ewma 0.222/0.198 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.185/0.191/0.199/0.017 ms, ipg/ewma 0.218/0.193 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
. 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 16ms
rtt min/avg/max/mdev = 0.194/0.197/0.216/0.006 ms, ipg/ewma 1.817/0.202 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.194/0.233/0.331/0.061 ms, ipg/ewma 0.273/0.247 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
. 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 16ms
rtt min/avg/max/mdev = 0.193/0.196/0.215/0.016 ms, ipg/ewma 1.792/0.201 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.187/0.194/0.213/0.019 ms, ipg/ewma 0.226/0.198 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 0.186/0.193/0.205/0.005 ms, ipg/ewma 0.220/0.195 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
. 
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 17ms
rtt min/avg/max/mdev = 0.193/0.196/0.216/0.014 ms, ipg/ewma 1.853/0.201 ms

The other Pi 4 even had link loss (disconnected then reconnected without touching it, when I tried to communicate with it)

However Desktop and Laptop computers had no issue communicating with each others. They only had issue communicating with both of the Pi 4, same issue when having both Pi 4 communicating with each other trough the switch.

I tried to switch the cables but it made no difference, apart from the second Pi 4 not having link loss anymore (I guess cables have some impact but aren't the main cause of the troubles). Reconnecting and disconnecting Pi 4 cable several time makes the tiny packet loss appear or disappear.
Using original power supply or not does nothing.

Disabling "EEE" on both Pi 4 once again made the issue disappear.

Connecting both Pi4 together (with EEE) didn't show any issue. However, connecting a Raspberry Pi 4 to the computer give catastrophic "first packets loss" amount half of the time (when disconnecting and reconnecting the cables I have 50% chances of having the issue), until EEE is disabled (with EEE disabled everything is solved).

Communication between Pi 4 and rtl8153 USB3 devices (with EEE enabled and active) shows no problem, so the issue isn't guaranteed to exist with any device!

I hope all this information may help people who are in troubles with Raspberry Pi 4 link stability, but I would also be interested if some firmware correction could make EEE working better with Raspberry Pi 4, as normally, EEE is supposed to work as fine on Raspberry Pi 4 and others devices

[julienrobin28]

Hi all,

I looked for information about firmware and BCM54213PE, but found nothing about firmware: looks like there is no possible firmware update to solve the issue.

Which probably means firsts packets loss and poor link stability between Raspberry Pi 4 and most others devices when EEE is active, may never be corrected: as EEE implementation of Raspberry Pi 4 seems to be defective, it could be better to disable it.

In order to disable EEE at each boot, I had some issue. I tried using /etc/rc.local or even a "oneshot" systemd service for running

Code: Select all

ethtool --set-eee eth0 eee off

at each boot. I can confirm it encountered no error.

But it seems that even if applied fine, something is turning it on again later in the boot process. Some "ethtool" commands seems to be called from /etc/network/

So I created the following service

/etc/systemd/system/eee-disabling-eth0.service

Code: Select all

[Unit]
Description=Improving eth0 link stability by disabling defective EEE
After=network.target

[Service]
ExecStart=/usr/local/sbin/eee-disabling-eth0.sh

[Install]
WantedBy=multi-user.target

/usr/local/sbin/eee-disabling-eth0.sh

Code: Select all

#!/bin/sh
while true
do
	/sbin/ethtool --set-eee eth0 eee off > /dev/null 2>&1
	sleep 1
done

If "eee" is enabled, this command will disable it. After a maximum time of 1 second when it is re-enabled, this command will re-disable again.
When it is already disabled, this command does nothing appart telling it's already disabled. So I added " > /dev/null 2>&1" in order not to flood systemd log.
This file should be made executable

To enable the service so that it is started at each boot :

Code: Select all

systemctl enable eee-disabling-eth0.service
systemctl start eee-disabling-eth0.service

[photopuppet]

I'm getting exactly the same symptoms with my Pi 4 8GB when the EEE is enabled... A laptop using EEE is working fine plugged into the same switch, and when the Pi was on, it actually seemed to be interfering with the laptop's network connection! (making it constantly reconnect)

It definitely seems like a bug in the Pi firmware...

How can we all get the appropriate Pi network adapter logs so this can be submitted as a bug?

[photopuppet]

Does anyone know if dtparam=eee=off still works if in config.txt?

Please fix this Pi team as it definitely seems to be a Pi 4 driver or firmware problem... No issues with any other network computers plugged into the same port!!

[huguescmoi]

Hi,

In my case it is even worse : a new RPI4 8G, fresh Raspbian install : absolutely impossible to use an ethernet connection. It simply does not work. I tried configuring a static IP address but any attempt to use the network (even a ping command) returns a network unreachable error.

Come on Raspberry team, using an ethernet connection should be a no brainer and plug and play. We have to fiddle around and mess with dhcpd.conf file and other tricks to try get a network access. Ridiculous and a shame really. I guess RPI has still lots of room to grow and mature.

PS : still no working solution to use eth0...

[jamesh]

Hi,

In my case it is even worse : a new RPI4 8G, fresh Raspbian install : absolutely impossible to use an ethernet connection. It simply does not work. I tried configuring a static IP address but any attempt to use the network (even a ping command) returns a network unreachable error.

Come on Raspberry team, using an ethernet connection should be a no brainer and plug and play. We have to fiddle around and mess with dhcpd.conf file and other tricks to try get a network access. Ridiculous and a shame really. I guess RPI has still lots of room to grow and mature.

PS : still no working solution to use eth0...

It is a no-brainer and it is plug and play. It should "just work", and if it doesn't work out of the box, then the HW is probably defective. We are not stupid, we've made it as easy as possible.

So before you accuse us of immaturity, consider, we make nearly a million devices a month. If the ethernet did not work, I suspect we would have many more than just your comment.

I would return it for a warranty replacement.

The only odd thing is that the ethernet is tested during manufacture, so must have died between there and delivery.

[Mr. Anderson]

Hi,

just for a "me too" I have now registered here. Multiple Raspberry Pi 4 B with 4 GB RAM have the same problem when connecting to a particular Gigabit switch. The behaviour is exactly as described by julienrobin28 in point 5:

5) I had cases of link going down, up, down up... while an USB NIC (ax88179) or any other device was running fine on the same cable

Switch and Raspberry negotiate Gigabit Ethernet in full duplex mode, but during the first packets of payload (I think the number varies) the connection is reset (at first glance, the switch seems to tear down the connection, but I am not really sure about this).

Tested with brand new Raspberry Pis (at least two, but I can try more), the switch is also brand new (I will also test another one of those) and with various cables:

• Cat. 5e ranging from 20 cm to 5 m
• Cat. 6 (1m)
• Cat. 7 (2m, fresh from the packaging)

The switch and the Raspberry work fine with all other devices that I tried, in particular both work fine when not connecting them directly, but adding another switch (also Gigabit) between them.

A successful workaround is to mask advertising of full duplex Gigabit Ethernet on the Raspberry Pi:

Code: Select all

ethtool -s eth0 advertise 0x01f

Negotiation then falls back to Gigabit Ethernet in half duplex mode which probably implies not to enable EEE (I have not verified that, though).

Another workaround to make Gigabit Ethernet work (for me) in full duplex mode is to explicitly disable EEE as julienrobin28 described:

Code: Select all

ethtool --set-eee eth0 eee off

(see above)

However, this second workaround works for me only after updating from buster to bullseye and installing a more recent firmware. With buster, the NIC always reported to run in MII mode and I could not change that. After the update it now reports as TP mode. To summarize: full duplex Gigabit Ethernet between Raspberry Pi 4 B and the particular switch works for me only with bullseye, recent firmware and EEE disabled.

[jamesgill]

Maybe this is just a coincidence, but I seem to be having the same problem. I have a Raspberry Pi 4 (8GB Model) connected with a CAT6 flat cable to a gigabit Ethernet router (will add the model when I get home). I noticed that my SSH connection was repeatedly terminated, and I could not always connect to it, so I used

Code: Select all

ping [IP ADDRESS] -t

and it showed that every ~10 requests a couple would time out. I tried the command above, and tried again. This time, there were no timeouts, and my SSH connection ran for over half an hour uninterrupted. If a better solution than an infinite loop can be found, I would appreciate it greatly.

[Mr. Anderson]

Maybe this is just a coincidence, but I seem to be having the same problem. I have a Raspberry Pi 4 (8GB Model) connected with a CAT6 flat cable to a gigabit Ethernet router (will add the model when I get home). I noticed that my SSH connection was repeatedly terminated, and I could not always connect to it, so I used

Code: Select all

ping [IP ADDRESS] -t

and it showed that every ~10 requests a couple would time out. I tried the command above, and tried again. This time, there were no timeouts, and my SSH connection ran for over half an hour uninterrupted. If a better solution than an infinite loop can be found, I would appreciate it greatly.

My current workaround (although not thoroughly tested so far) is a udev rule, e.g. in a separate file /etc/udev/rules.d/99-disable-bcmgenet-eee.rules:

Code: Select all

ACTION=="add", SUBSYSTEM=="net", DRIVERS=="bcmgenet", RUN+="/usr/local/bin/disable_eee.sh '%k'"

with something like this as /usr/local/bin/disable_eee.sh:

Code: Select all

#!/bin/bash

device=$1

/usr/sbin/ip l set dev "${device}" up
/usr/sbin/ethtool --set-eee "${device}" eee off
/usr/sbin/ip l set dev "${device}" down