Cannot disable EEE on Raspberry Pi 5 #6065
Comments
|
If your problem is the link always negotiating, you can just use these two commands here: Obviously set the speed as the one you want, for 1Gbps you will put 1000, like I've already done in the example. Also ensure to run the command as a root user / using sudo since you cannot do these changes with a normal user. |
|
I don't believe it's a negotiation issue; I'd already checked playing with ethtool settings before hand. It still happened with 1gb autoneg off, but was fine when forced to 100mb with/without autoneg. This mirrors what other people had previously observed on Pi4's. I was able to borrow a different switch (Netgear, same as my current one, but slightly newer version) and so far it's been fine. This also mirrors what people observed on Pi4, where it seems to be an incompatibility with EEE between the Pi and some switch models. Again, I can't confirm this as it's impossible to turn off EEE (AFAIK) on the Pi 5 |
|
Interesting to know @b4dpxl, that seems to be related more on the switch side, I know not being able to disable EEE can be seen as a bad thing but I also see no reason of why it would hurt not having that... the problem comes with non-compliant network equipment... If you got the model of such switch let us know, would be nice to have a list around so people having connection issues know the reason... Also EEE is mainly hardware related and I am not really sure if the chip used in Pi4/5 even allow such feature. PS. Everything is fine here with a Cisco Catalyst switch, in 100 and 1000 modes. |
|
In my case the problematic switch is a Netgear GS108Ev3, but a newer version Netgear GS108PEv3 is fine. I suspect most Pi users aren't running Cisco network equipment though 🤨 Well, as I understand it, the Pi4 and Pi5 both share the ethernet chip, and the Pi4 definitely allows you to disable EEE. It's referenced here in the overlays document and here is the pull request which was merged to allow it to be disabled via dtparam. Clearly this was a known issue, otherwise this wouldn't have been added. As per the pull:
IMO it's not fair to place the blame on the switch when there are multiple reported switches at issue, and one common factor (the Pi). Did you actually look at any of the links I provided before? |
Yes, I've looked into the links you shared but not really deeply since I had not much time, anyways since you mentioned that it can be disabled on Pi4, I will later test out on a 4 and see the results I get and if there's something possible in the 5... |
|
Just tested on a 4 and I can see the NIC shutting down and powering back on... Will check later what could cause the problem on the 5. |
|
Turns out I've found difference between the Pi4 and the Pi5, if you run "lspci" you can see that on the Pi5 the ethernet controller is connected through PCI unlike the 4... I think this is causing some issues to ethtool at this moment, will continue to look around. PS. I think that the PCI ethernet controller is practically the new RP1 chip. |
|
Also @b4dpxl if you're interested into the RP1 chip you can find some infos here: https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf Sadly there's nothing about EEE so I guess we can do nothing at this moment : / |
|
After looking around the current implementation of Ethernet on RP1 doesn't support EEE at all since the implementation of it is included in IEEE 802.3az, meanwhile on the RP1 docs it is just IEEE 802.3... Not sure if this will be changed in the future but I doubt anything will come soon, even because EEE is a good feature to always have enabled. |
|
I have seen no mention of EEE or 802.3az in the documentation for the Ethernet MAC in RP1. |
|
Large file transfer between mbp and rpi5[fe80::e02a:17b4:c527:84e3%en9] using direct cat6 cable link between the two:
Sustained data transfer rate was between 80-100 Mbytes/s until getting stalled. Doing the same between rpi5 and rpi4 failed at 11% file transfer, data transfer rate prior to stall was 40MBytes/s. Rpi5 also loses it's ipv6 network address binding even when idling. It's either is an issue within rpi5 ethernet stack or my rpi5 ethernet is bad. I don't have another rpi5 at hand, someone else may try reproducing this problem. |
I cannot replicate this since I am not able to disconnect my Pi5 but, have you tried using something like a USB -> Ethernet adapter? Would be nice to know if the problem is the hardware or something that is broken in general in the kernel with networking... I think that this still is a RP1 related problem tho. |
I managed to find an old USB-A wifi adapter. The following tests rule out my PI5's hardware being an issue. In these tests two consecutive downloads were performed with PI5 and then the same repeated with one of my PI4 using the the same usb wifi adapter but using a much bigger BIG.tar! MBP downloading BIG.tar from RPI5 over usb ethernet (wifi router turned off)*** Connection stalled in just over 2 mins of data transfer MBP downloading BIG.tar from RPI4 over usb ethernet (wifi router turned off)*** Connection stable over 43 mins of data transfer In an earlier test I had used PI5's native Ethernet connected to the wifi router's Ethernet port for the same download test, which worked fine. The only thing different was PI's eth0 got allocated an IPV4 address by the router. An issue within Bookworm's IPV6 stack? |
I just tried copying over a 10GB file between my laptop (Debian) using SCP too and the Pi5 without having any issue... Also I am not sure if there are issues within Bookworm IPv6 stack. I got the idea that the RP1 stack is still not fully working well... Either ways, could you run the command: uname -aSo we can at least understand what kernel you are running on, the output in my case is this one: Just finished transferring 100GBs... I guess the problem is not happening here at all: |
That's good to hear. Problem occurs at my end only when using direct cable between PI5 and any other host, for some reason Perhaps repeating a file transfer with IPV6 src and dst addresses may reproduce the problem I am seeing. |
I was running on kernel 6.22 so I will update my system to the latest kernel 6.30 and see if anything changes (I don't remember seeing any change on eth related stuff tho) Just tested again and I confirm to have no issues with IPv4/6 at all when sharing my network using Debian. Are you sure your network cable is functional, also if you run "ifconfig" do you see any Tx/Rx error on the eth interface? That would mean something is going really wrong, here's my output: As you can see I've got no errors at all and the transfer went well (I stopped it at 26GB). I could try on a MBP with M1 but I doubt the problem relies on MacOS. |
Great suggestions. I have tried multiple cables of various lengths and the tests are with a CAT6 cert cable. Also it matters not whether it's mbp of a Debian. This time I tested between PI5 and PI4.
RPI4 SCP RPI5 -> RPI4 (Bullseye Linux rpi4c 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux) Now this is what really happened during this SCP session: RPI5 I then did a bash script to grep PI5's eth0 inet6 address every 15 secs, here are the outputs: PI5's eth0 IPV6 binding regularly flaps between 3 mins up and 5 mins down |
Hi there, the issue has been closed by @pelwell a little bit too fast, on a mistake: peers that are connected to the Pi 5 are showing that in reality, EEE is both active and enabled on the Pi 5 Ethernet MAC, even if not mentioned into its documentation. Result from an EEE capable laptop directly connected to the Pi 5: When this laptop is connected to a device or switch on which EEE is disabled or not supported, it says Just to confirm that disabling EEE is solving the link stability issue between the laptop and the Pi 5, from the Laptop: And this solves the link stability issues with the Pi 5. But when both my Laptop and the Pi 5 are connected to an EEE compliant switch (unmanaged switch), this can't be done from Pi 5 (and then in my case, link stability issue then occurs again, between the switch and the Pi 5). On most of my Pi 4, there was the same stability issue in the same circumstances. However the ability to disable EEE from the Pi 4 allowed to retrieve a stable link everywhere. Today, we would clearly need it for the Pi 5 too. Is it really needed?I was surprised to see how much efforts were provided here to contradict and challenge the reality of the issue, instead of looking possible ways to just disable this. We probably shouldn't be spending so much efforts questioning the usefulness of a feature that has already been approved, used, and implemented in so much drivers for so long already. Of course, EEE wasn't supposed to need disabling. Most of the time, we don't need to. To be honest, Pi 4 and 5 are the only devices on which I sometimes encounter link stability issues with EEE, and not even with all peers. Is this Pi 5 fault? Is this not? Let's say we aren't sure yet, because this doesn't matter anyway: the need to disable EEE from Pi 5 in some circumstances remains the same. |
|
Hey, Regarding the EEE issue. Its always a mix between mac and phy. Lets sort it out a bit: How can this impact the link performance? If the transmitter is disabled from time to time two things can happen: a) Packets will be delayed until the transmitter left low power mode (my problem with PTP) or the receiving phy interprets the disabled transmitter as link-down. (Seams like the problem in this ticket).
|
|
Hi @go2sh, As you explained, I can confirm once you succeeded to disable EEE at one side, it becomes inactive on both (from Linux machines that are able to report or change EEE status, you can use What may be improved there, is that For the original cause of the link stability issue when EEE is active, I'm 99.9% the issue isn't due to a faulty driver or faulty Cadence MAC IP, because the only other device on which I encountered the same issue is Raspberry Pi 4, which (despite using another GbE controller and driver) shares the same BCM54213PE chip and physical/electrical stuff around it for the RJ45 port (which may be the common and problematic stuff there). However Pi 4 had the ability to disable EEE itself thanks to its different associated driver (using PS:
This looks convincing 👍 had some packets drops too (sometimes without having eth port reported disconnected and reconnected), so I suspect that in low power mode, being on Pi 4 or 5, for some reason the BCM54213PE chip isn't working as good as expected, and causes the misfires, despite being advertised EEE compatible. Is this because of voltage, capacitive, inductive or resistive issues (or something else), I don't really know. |
|
I have access to the complete cadence documentation. But you can also check other chips like the traveo 2 or xilinx socs, which internally use gem as well. Unfortunately, I have no access to the broadcom phy. I'm really interested also with regards to the internal delay for accurate ptp delay measurement. |
|
I have pi zero's, pi 3, and pi 4s with this eee issue. |
|
The Pi 3 Ethernet does not support EEE, and it should never be enabled by the switch. Pi Zero doesn't have an Ethernet interface. |
Good to know I can take those things of the list of items to fiddle with. I suppose the correct thing to do would be to start a new issue. This issue with the Pi Zero I solved by having /sbin/iw wlan0 set power_save run at boot. The Pi 3 I'm not sure of the issue. It's a headless system running it a shed that drops every week or so directly connected to ethernet. I added a big capacitor, that did nothing to help stability. Sometimes it randomly comes back online. I added a UPS figuring the power was dropping and that didn't help either. I experienced this issue with pi-star and WPSD. Swapping OSs is not an option given the purpose of use. |
Doubt it's a software issue tho... if you solved it by setting "power_save" run at boot... maybe it might be the actual regulator on-board failing? For how long do you have this PI, did it always have this issue since you got it? |
The pi zero had this issue. Pretty sure it's always had a wireless stability issue. I found that idea on another forum so it's either a unknown consistent problem or a unacknowledged problem. The pi3 I rebooted this morning and it came right back to life. It sucks because it's headless and remote and takes time to fault out. At this point I'm going to "solve" the issue by forcing a reboot every morning at 2:25 AM. But I'd sure as heck like to actually solve the problem instead of just hacking it. |
Describe the bug
My Raspberry Pi5, running bookworm, is experiencing frequent eth0 droppages. Example:
I've changed switch ports, cables, etc. This was also an issue on RPi 4, which could be resolved by disabling EEE, either with ethtool or dtparam. I want to see if this also solves the problem on Pi5, but neither of these options work on RPi5, and trying to run ethtool reports "Operation not supported".
See https://forums.raspberrypi.com/viewtopic.php?t=360924
Can EEE be disabled on RPi5 via another method, or is there an ETA when disabling it will be supported on Pi5?
Steps to reproduce the behaviour
run
ethtool --set-eee eth0 eee off.Get the response:
netlink error: Operation not supportedDevice (s)
Raspberry Pi 5
System
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: