[RPi4-bcmgenet] regression: EEE reporting/dtparam support broken (EEE always enabled)

[julienrobin28]

Describe the bug

Just noticed some link stability issues and huge lags today while using SSH to some of my Pi 4.
Turned out dmesg is showing recurrent network link resets:

[...]
[    9.208361] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
[    9.211047] bcmgenet fd580000.ethernet eth0: Link is Down
[   13.309882] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  120.829975] bcmgenet fd580000.ethernet eth0: Link is Down
[  122.878105] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  255.999156] bcmgenet fd580000.ethernet eth0: Link is Down
[  259.071376] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  283.647776] bcmgenet fd580000.ethernet eth0: Link is Down
[  286.720047] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  301.056130] bcmgenet fd580000.ethernet eth0: Link is Down
[  304.128371] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[...]

Not 100% sure if this is due to a recent kernel update, or a recent eeprom update.

It looks like the cmdline.txt option dtparam=eee=off has no effect anymore, and ethtool --show-eee eth0 indicates there is no more ability to report EEE status:

EEE settings for eth0:
	EEE status: not supported

Strangely enough however, on Pi 3 B+ the ethtool --show-eee eth0 is still working.

Also, playing ethtool --set-eee eth0 eee off still seems to successfully disable EEE on Pi 4 despite being unable to report EEE status.

Thanks in advance if this can be fixed (at least for the dtparam option)

Steps to reproduce the behaviour

Connect a recently updated Pi 4 to a GigE device (computer or switch) which supports EEE, and during low network activity, link stability issues are likely to occur, despite cmdline.txt containing dtparam=eee=off.
The ethtool --show-eee eth0 and ethtool --set-eee eth0 eee off effect may also be tested.

Device (s)

Raspberry Pi 4 Mod. B

System

raspinfo: https://pastebin.com/LL09cwJS

Output of cat /etc/rpi-issue:

Raspberry Pi reference 2025-10-01
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7dadcf1fc5ce1648ab09409ab978831690c9a955, stage2

Output of vcgencmd version:

May  8 2026 18:13:05 
Copyright (c) 2012 Broadcom
version ae9a8ea9f3ca745de6f357bd7fc8307721ad38b7 (clean) (release) (start)

Output of uname -a:
Linux pi4-spycrobe 6.18.29+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.29-1+rpt1 (2026-05-12) aarch64 GNU/Linux

Logs

dmesg.txt

Additional context

No response

[pelwell]

You've referred to cmdline.txt twice - do you actually mean config.txt?

[pelwell]

Because it works for me.

Out of the box:

pi@philscratch:~$ ethtool --show-eee eth0
EEE settings for eth0:
        EEE status: enabled - active
        Tx LPI: 34 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full

With dtparam=eee=off in config.txt:

pi@philscratch:~$ ethtool --show-eee eth0
EEE settings for eth0:
        EEE status: not supported

[julienrobin28]

Sorry I was meaning config.txt you are right, for the dtparam=eee=off option.

However, despite having ethtool --show-eee eth0 saying EEE status: not supported, it looks like EEE is still enabled until ethtool --set-eee eth0 eee off is played

[pelwell]

OK. There are a number of other issues open about EEE on Pi 4 (#7371, #7365), so this is already under investigation.

[pelwell]

While I think of it:

Strangely enough however, on Pi 3 B+ the ethtool --show-eee eth0 is still working.

Everything about the Ethernet on Pi 3B+ is different compared to the 4B, so this is not surprising.

[pelwell]

it looks like EEE is still enabled until ethtool --set-eee eth0 eee off is played

With a Pi 5 as a link partner, I can confirm that even with dtparam=eee=off it still sees EEE as being enabled until, as you say, it's turned off at the PHY on the Pi 4.

[DonPablo1010]

Same experience here on Pi 4B Rev 1.5 (8GB RAM) with DietPi Trixie and an unmanaged 1Gb consumer switch (Netgear) that advertises EEE.

Note: I tested dtparam=eee=off still on kernel 6.12.75. After adding it to config.txt and rebooting, ethtool --show-eee eth0 still shows EEE status: enabled - inactive instead of not supported or disabled. So the dtparam option appears to have no effect when the link partner also advertises EEE.

However, manually running ethtool --set-eee eth0 eee off does work and shows EEE status: disabled, so the PHY-level command works, but the dtparam boot option does not.

I have not yet tested on 6.18.29 with dtparam=eee=off as I rolled back to 6.12.75 due to the network connectivity loss and put packages on hold.

[pelwell]

Thanks for the feedback. I think we now all agree that the problem is with the EEE support, and that the dtparam is not doing a good job of disabling it.

[nbuchwitz]

I will have a look later. Seems that the mark as broken in the dt is not handed down to the mac driver (or it's another permutation of the "great" AutoGreeen...)

[nbuchwitz]

Looks like we found a bug in phylib. Patch for testing: #7373

If feedback is positive, I will send it to the elders of netdev ...

@pelwell or others: Can you please trigger the build in the linked PR? Thanks

[julienrobin28]

Hi @nbuchwitz

Tested the patch you mentioned on the current rpi-6.18.y which is 6.18.29 as I'm writing, and it works 👍️

In details, with the patched kernel:

• Adding dtparam=eee=off to config.txt makes EEE disabled, and ethtool --show-eee eth0 says EEE status: not supported. Despite advertised as "not supported", both ethtool --set-eee eth0 eee off and ethtool --set-eee eth0 eee on commands are working anyway.

• By double check I also tested without the dtparam=eee=off and EEE is then enabled by default (which is the expected behavior). In this case the ethtool --show-eee eth0 commands says EEE status: enabled - active and both ethtool --set-eee eth0 eee off and ethtool --set-eee eth0 eee on commands are working.

I also checked ping duration and looked at link stability as a triple check.

[MacFlurry]

I can reproduce what looks like the same regression on a Raspberry Pi 4

Environment:

• Raspberry Pi 4 Model B Rev 1.2
• Debian GNU/Linux 13 / trixie, arm64
• Ethernet via eth0 / bcmgenet
• No Docker installed, no docker0/br-/veth interfaces
• Pi-hole + Unbound running
• Kernel upgraded by apt to: 6.18.29+rpt-rpi-v8

Observed on 6.18.29+rpt-rpi-v8:

• SSH became extremely slow and eventually unreachable, requiring a reboot.
• eth0 stayed nominally up at 1Gbps/Full, with no repeated Link Down/Up events after boot.
• Latency from the Pi to the router became extremely high but without packet loss.

Example measurement on 6.18.29:

ping -c 50 -i 0.2 192.168.25.1
50 packets transmitted, 50 received, 0% packet loss
rtt min/avg/max/mdev = 8.488/423.449/1027.859/220.077 ms

I then forced boot back to 6.12.75+rpt-rpi-v8 on the same hardware, same cable, same router, same network.

Result on 6.12.75+rpt-rpi-v8:

ping -c 50 -i 0.2 192.168.25.1
50 packets transmitted, 50 received, 0% packet loss
rtt min/avg/max/mdev = 0.144/0.189/0.415/0.038 ms

I also tested dtparam=eee=off on 6.18.29, but it did not resolve the high latency in my case. On 6.12.75, both with EEE disabled and with dtparam=eee=off commented out again, latency remains normal.

The key difference in my test is only the active kernel: 6.18.29 bad
kernel: 6.12.75 good.

[MacFlurry]

I looked at the bcmgenet source changes between rpi-6.12.y and rpi-6.18.y. In my case this does not look like EEE alone.

On my RPi4:

• 6.18.29+rpt-rpi-v8 with dtparam=eee=off still showed very high latency.
• 6.12.75+rpt-rpi-v8 is stable even after re-enabling EEE.
• Same hardware, cable, switch/router.

Measurements:
6.18.29+rpt-rpi-v8:

ping -c 50 -i 0.2 192.168.25.1
50 transmitted, 50 received, 0% loss
rtt min/avg/max/mdev = 8.488/423.449/1027.859/220.077 ms

6.12.75+rpt-rpi-v8:

50 transmitted, 50 received, 0% loss
rtt min/avg/max/mdev = 0.168/0.224/0.535/0.050 ms

The source change that looks most suspicious to me is the default flow move from DESC_INDEX / ring 16 to ring 0:

• old path: default RX/TX via DESC_INDEX / ring 16
• new path: default flow via ring 0 using a default HFB filter
• interrupt handling changes from the special ring16 INTRL2_0 path to ring0 INTRL2_1

This seems consistent with the observed symptom: packets are not necessarily lost, but processing appears massively delayed.

Other possibly relevant changes:

• e987bc1 / upstream 908c344: bcmgenet EEE converted to phylib-managed state
• e6f13c8: adds brcm,powerdown-enable to the Pi 4 PHY node
• 13c70a0: reverts the old Pi4 Ethernet skip_umac_reset workaround

Given that dtparam=eee=off did not fix 6.18.29 in my case, I would suspect the ring0/default-HFB/interrupt path before EEE.