Pi 5: continuous Ethernet link flapping since EEE enabled by default in rpi-6.18.y (#7270), mostly with AVM Fritz!Box link partners
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- c, linux
- Bereich
- networking, operating-systems
Rechercherichtung
Start by comparing the rpi-6.18.y EEE changes from #7270 with the rpi-6.12.y state and the eee-broken-1000t/eee-broken-100tx workaround from #6900. Reproduce with an affected link partner using dmesg and dtparam=eee=off; done means the Pi 5 link remains stable with EEE enabled across the reported partner setups.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Note: The report below was largely generated with AI assistance. I have read through it to verify that the claims are accurate and reflect what our users report in the Home Assistant OS issue tracker.
Describe the bug
Since Home Assistant OS moved from a rpi-6.12.y based kernel to rpi-6.18.y, we have received multiple reports of Raspberry Pi 5 devices whose onboard Ethernet link flaps continuously:
macb 1f00100000.ethernet end0: Link is Down
macb 1f00100000.ethernet end0: Link is Up - 1Gbps/Full - flow control off
This repeats every few seconds (in some cases starting within seconds after boot), with packet loss towards the default gateway and effectively unusable networking. Rolling back to the 6.12-based OS release restores a stable link on identical hardware, cabling and switch port.
Setting dtparam=eee=off resolves the problem on 6.18. This has been confirmed by three affected users, one of them with a full on/off/on cycle: flapping with EEE enabled, stable for two days with it disabled, flapping returned after re-enabling.
Disabling EEE on the link partner side also resolves the flapping: confirmed on Fritz!Box 7490 and 7590 (LAN port energy setting changed from "automatic" to "none") and on managed switches that offer an EEE toggle. Partners without such an option keep flapping unless EEE is disabled on the Pi.
Our 6.12-based releases used rpi-6.12.y at 89050b1059997d38d55462b323b099a6436dc10d, which still contained the eee-broken-1000t/eee-broken-100tx properties from #6900 — EEE was never negotiated there. rpi-6.18.y enables EEE by default on the RP1 GEM since #7270 (macb EEE/TX LPI support, BCM54213PE switched from AutogrEEEn to native EEE mode, eee_enabled_default = true with a 250 ms TX LPI timer; earlier testing round in #7251). This matches the observed behavior change exactly.
Affected setups (from our issue tracker)
Four users have reported the link flapping so far, one more with the same hardware combination is holding back the update in anticipation. Where the direct link partner is known:
- AVM Fritz!Box 7590 — three users (at least two directly connected, no switch in between)
- One of the four reproduced the flapping against a whole range of devices: TP-Link TL-SG608E, TP-Link TL-SG1016DE, TP-Link ER605, Netgear GS105NA, Fritz!Box 7490 and Fritz!Box 7590. This user verified the link behavior (LAN LED fully down and back up in ~5 s intervals, matching the dmesg pattern above) and confirmed that disabling EEE on either side — the Pi or a partner that offers an EEE setting — stops the flapping, while unmanaged partners without an EEE option keep flapping until EEE is disabled on the Pi.
AVM Fritz!Box devices are clearly overrepresented as link partner, but the last report suggests the problem is not limited to a single vendor's LPI handling: on that Pi, every EEE-capable partner tested triggered the flapping.
For scale: we have roughly 100 000 Raspberry Pi 5 installations on 6.18-based OS releases, so the overall incidence is low — most link partners appear to handle the newly negotiated EEE fine.
Environment
- Raspberry Pi 5 Model B (one confirmed Rev 1.1, revision
d04171) - Kernels: rpi-6.18.y 6.18.33 (
stable_20260527) and 6.18.34 (stable_20260609) - Not reproducible on rpi-6.12.y (6.12.75, which contains the #6900 DT workaround)
Steps to reproduce
- Raspberry Pi 5 with an affected link partner (e.g. Fritz!Box 7590), rpi-6.18.y kernel with default EEE configuration
- Boot and run
dmesg | grep "Link is"— the link flaps every few seconds - Add
dtparam=eee=offto config.txt and reboot — the link is stable
Additional context
- Symptom-wise this resembles the Raspberry Pi 4 / bcmgenet situation after EEE was enabled there (#7365): a broad, vendor-diverse set of link partners affected, resolved by Pi-side fixes (#7372, #7373, #7388) rather than by blaming partner equipment. We have not ruled out either direction for the Pi 5 yet — partner devices mishandling LPI vs. marginal TX LPI signaling from the RP1 GEM.
- Downstream reports: home-assistant/operating-system#4861, home-assistant/operating-system#4881
Device(s)
Raspberry Pi 5
System
Home Assistant OS 18.0/18.1 (rpi-6.18.y 6.18.33 / 6.18.34, stable_20260527 / stable_20260609)
- Vorherrschende Sprache
- C
- Sterne
- 13.3k
- Forks
- 5.5k
- Ø Merge
- 3 T. 20 Std.
- Gemergte PRs (30 T.)
- 27
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus raspberrypi/linux
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 63/100
raspberrypi/linux#7718 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
raspberrypi/linux#7415 · 2 Kommentare · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
rp1-cfe doesn't forward V4L2_EVENT_SOURCE_CHANGE event from csi-2 sensor driver to userspace appOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
raspberrypi/linux#7399 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
raspberrypi/linux#7357 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
raspberrypi/linux#7054 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in raspberrypi/linux
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
Maintainer antworten meist innerhalb von 1 Tag
-
good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
dfa1/rocksdb-ffm#292 ·
Maintainer antworten meist innerhalb von 1 Tag
-
SPIDevice selects an active-high device as soon as it is createdEvtl. vergeben @mikeysklar hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
adafruit/circuitpython#11869 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 78/100
gnif/LookingGlass#1352 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 1 Tag