Pi 5: continuous Ethernet link flapping since EEE enabled by default in rpi-6.18.y (#7270), mostly with AVM Fritz!Box link partners #7511

Activity

1. nbuchwitz commented on Jul 21, 2026

   

   nbuchwitz

   on Jul 21, 2026

   Contributor

   More actions

   Does the behavior change with a lower / higher lpi timer value?
2. XMaarten commented on Sep 2, 2026

   

   XMaarten

   on Sep 2, 2026

   More actions

   I can reproduce what appears to be another manifestation of this EEE issue on a Raspberry Pi 5, although in my case I do not see the continuous link flapping described in the original report.

   Environment

   • Raspberry Pi 5
   • Debian GNU/Linux 13 (trixie), Debian 13.6
   • Kernel: 6.18.39+rpt-rpi-2712 SMP PREEMPT Debian 1:6.18.39-1+rpt1 (2026-07-29) aarch64
   • Ethernet driver:

     driver: macb
     version: 6.18.39+rpt-rpi-2712
     bus-info: 1f00100000.ethernet
     

   • Link partner: Ubiquiti UniFi USW Flex Mini
   • Link: 1000 Mbps, Full Duplex, auto-negotiation enabled

   Symptoms

   With EEE enabled I consistently see substantial ICMP packet loss, typically around 5–20%, even when pinging the directly connected USW Flex Mini. The Ethernet link itself remains up at 1000 Mbps/full duplex; I have not observed the continuous link-down/link-up cycle described in the original report.

   The physical Ethernet statistics are clean:

   rx_frame_check_sequence_errors: 0
   rx_length_field_frame_errors: 0
   rx_symbol_errors: 0
   rx_alignment_errors: 0
   rx_resource_errors: 0
   rx_overruns: 0
   tx_carrier_sense_errors: 0
   q0_rx_dropped: 0
   q0_tx_dropped: 0
   

   Linux networking queues also do not show an obvious cause:

   IpInDiscards: 0
   UdpRcvbufErrors: 0
   TcpExtTCPBacklogDrop: 0
   TcpExtTCPRcvQDrop: 0
   

   fq_codel also reports 0 dropped packets.

   EEE/LPI was actively being used. Before disabling EEE, the NIC statistics included:

   rx_lpi_transitions: 4335627
   tx_lpi_transitions: 914108
   

   While continuously monitoring packet loss with fping, I disabled EEE at runtime and the packet loss then immediately disappeared and has remained at 0% so far.

   I had also already replaced the USW Flex Mini with another USW Flex Mini (including all the involved cables) before testing EEE, with no improvement.

   This suggests that the Pi 5 / RP1 macb EEE issue may also manifest as significant packet loss without actual link flapping, at least with a USW Flex Mini as the link partner.
3. danackerson commented on Nov 7, 2026

   

   danackerson

   on Nov 7, 2026

   Last edited by danackerson

   More actions

   Adding a data point that may narrow this down: on 6.18.60 the link flapping continues on my Pi 5 with EEE disabled on both ends, while the same setup was stable on 6.18.50.

   Setup

   • Raspberry Pi 5 Model B Rev 1.0 (d04170, raspberrypi,5-model-b), EEPROM 2026-10-30, Raspberry Pi OS trixie
   • Kernel 6.18.60+rpt-rpi-2712 (1:6.18.60-1+rpt1, Linux commit 0b41724521c9), previously 6.18.50+rpt-rpi-2712
   • macb + Broadcom BCM54213PE, 1000/Full
   • Link partner: AVM FRITZ!Box 7590 AX, direct cable, no switch in between

   Observations

   • 6.18.50: 0 carrier changes over the 7 days before the upgrade, according to node_exporter's node_network_carrier_changes_total. Kernel logs from that boot weren't kept, so this comes from metrics only.
   • 6.18.60: the first Link is Down came 21 s after boot (06:54:11 → 06:54:32 UTC). There were 209 carrier changes in the first ~28 h, in bursts lasting minutes, each drop ~3–4 s, separated by quiet periods of up to a few hours.
   • During one burst the TX queue also stalled for ~3 minutes, and the node lost networking for ~7 min:

     macb 1f00100000.ethernet eth0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 5284 ms
     ... (33 messages, 08:35:10–08:37:57 UTC, up to 20480 ms+)
     

     That's the only TX-stall episode I've seen so far.
   • EEE off from boot (dtparam=eee=off; ethtool --show-eee now reports not supported), with EEE also off on the FRITZ!Box: ~53 link drops in the first 5 h after boot, in the same bursty pattern, then quiet for 11+ h so far. One short NETDEV WATCHDOG (5 s) during that window.
   • Other wired hosts on the same FRITZ!Box (including non-Pi ones on other kernels) had no link drops in the same period, apart from one event where the router reset every LAN port in turn.
   • Physical-layer counters are basically clean: rx_frame_check_sequence_errors: 2, rx_symbol_errors: 2, rx_jabbers: 1 over ~70M frames. Load is low (peak ~7 MB/s TX).

   The bcm2712 DTBs also changed between the 6.18.50 and 6.18.60 packages (bcm2712-rpi-5-b.dtb hash differs). I haven't checked whether the Ethernet/PHY nodes are affected.

   Possibly related: a Pi 4 (bcmgenet) on the same FRITZ!Box went from 0 to 19 carrier changes after the same 6.18.50 → 6.18.60 upgrade, and once renegotiated down to 100 Mb/s.

   So on 6.18.60 there seems to be a second cause of flapping besides EEE, or one that EEE was only making worse, and it came in between 6.18.50 and 6.18.60. I can't stay on 6.18.50 because of CVE-2026-98432, but I'm happy to test patches or a candidate kernel and collect more data (e.g. PHY register dumps or ethtool -S at flap time) if that helps.
4. popcornmix commented on Nov 10, 2026

   

   popcornmix

   on Nov 10, 2026

   Collaborator

   More actions

   Claude:
   danackerson's report: flapping on 6.18.60 with EEE off
   Between 6.18.50 and 6.18.60, nothing that matters for the Pi 5 link changed:

   • No changes to the Broadcom PHY driver or the PHY core.
   • The macb changes are tidy-ups to its queue handling, timestamping and error paths.
   • One phylink change reorders how the PHY is attached when the interface comes up.
   • The only Pi 5 device tree change adds led-modes = <0 8>, which equals the driver's defaults, so it does nothing.
   • A Pi 4 on the same Fritz!Box also started flapping, and once dropped to 100 Mb/s. The Pi 4 driver shares none of the Pi 5 changes above.

   That points at something they share: the Fritz!Box (a FRITZ!OS update?), the cable or the router port. Worth asking them for their FRITZ!OS version history and to boot 6.18.50 again on the same setup to check.

   Also:

   • Nobody has answered nbuchwitz's question yet. Two tests would narrow it down:
     • ethtool --set-eee eth0 tx-lpi off: EEE is still agreed, but the Pi itself never goes idle. If the flapping stops, the Pi's sending side is at fault; if not, it's the router's idle mode or the PHY.
     • ethtool --set-eee eth0 tx-timer 1000000 (a longer idle timer, here 1 s), and a shorter one, to see if the flap rate changes.

   👍React with 👍1Reacted by Nicolai
5. nbuchwitz commented on Nov 10, 2026

   

   nbuchwitz

   on Nov 10, 2026

   Contributor

   More actions

   Also worth testing if #7667 helps