Rpi4 loses network connectivity via eth0 after kernel update to 6.18.24

[antoniosk]

Describe the bug

On Raspberry Pi OS Trixie, after the yesteday (13/5/2026) kernel update to 6.18.29, when Firefox or Chromium is launched, the eth0 connection dies.
Nether unplugging the cable nor restarting the systemd-networkd.service works. Ping works only for the assigned IPv4 address to eth0.
No errors are reported to syslog/kernel.log.
The wlan0 is not connected to a wireless network.
The eth0 gets its's IPv4 address from isc-dhcpd running on an Rpi2B, acting also as a gateway. There are no issues with other machines on the network.

Steps to reproduce the behaviour

Launch a browser (Firefox/Chromium).

Device (s)

Raspberry Pi 4 Mod. B

System

cat /etc/rpi-issue
Raspberry Pi reference 2025-10-01
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7dadcf1fc5ce1648ab09409ab978831690c9a955, stage5

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

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

Logs

No response

Additional context

No response

[JustArchi]

This is a serious issue and it doesn't consider only web browser. I have fully headless (raspberry pi os lite) version that only replicates my postgresql database, and after 6.12.75+rpt-rpi-v8 -> 6.18.29+rpt-rpi-v8 kernel upgrade it has VERY unstable network connection shortly after boot, even though the activity there is minimal, within 50 mbps or less.

Please investigate, I've downgraded to 6.12 for now. I've double-verified that other machines have no issues, and triple-verified that 6.18 gives issues, rebooting to 6.12 fixes them, and rebooting back to 6.18 brings the issues back.

Raspberry Pi 4 Model B Rev 1.4

BOOTLOADER: up to date
   CURRENT: Tue 14 Apr 21:17:01 UTC 2026 (1776201421)

     VL805: up to date
   CURRENT: 000138c0

It's very hard for me to believe that this wasn't caught earlier, as it's a serious regression observable right away on any network-connected system. Should be easy to reproduce - I can't even download bigger file without network dropping in the middle of it.

wget -O /dev/null https://proof.ovh.net/files/10Gb.dat

[spockfish]

Could this be related to #7304 ?

[antoniosk]

After further investigation, this is not browser related. The issue appears after network activity other than a simple ping via eth0. The workarounds are (1) to downgrade to the old kernel, or (2) to disconnect eth0 and use wlan instead.

[DonPablo1010]

Exactly the same problem here on a Pi4B 8GB, after a 6.12.75+rpt-rpi-v8 → 6.18.29+rpt-rpi-v8 kernel upgrade it came up and after a few minutes lost LAN connectivity. As I run it headless I thought it froze, but I think it’s running but with no connectivity at all. Had to go back to 6.12.75+rpt-rpi-v8 and put the packages on hold. Waiting for a fix!🙏🏻

[pelwell]

Does adding dtparam=eee=off to config.txt improve things? It's working fine for me on 6.18.29, but I don't think I'm getting EEE from the switch.

[Windkracht8]

As I had the same issue today, wanted to share some of my findings.
The connection works for a few seconds, when the cable is plugged in or when interface is brought down and up again, the internet connection works for a few pings before it goes down.
arp -n shows working connection to gateway for a few seconds before going to incomplete.
ethtool eth0 shows the link is UP and cable connection is detected, stays like this after connection is lost.
This only shows with a static ip, a dynamic ip takes too long, the connection is already broken by then.

Downgrading to previous kernel fixes the issue (apt install --reinstall linux-headers-6.12.75+rpt-common-rpi linux-headers-6.12.75+rpt-rpi-2712 linux-headers-6.12.75+rpt-rpi-v8 linux-image-6.12.75+rpt-rpi-2712 linux-image-6.12.75+rpt-rpi-v8 linux-kbuild-6.12.75+rpt)

[popcornmix]

t's very hard for me to believe that this wasn't caught earlier, as it's a serious regression observable right away on any network-connected system. Should be easy to reproduce - I can't even download bigger file without network dropping in the middle of it.
wget -O /dev/null https://proof.ovh.net/files/10Gb.dat

On a pi4, 6.18.24 kernel:

pi@dompi4:~ $ time wget -O /dev/null https://proof.ovh.net/files/10Gb.dat
--2026-05-15 11:15:18--  https://proof.ovh.net/files/10Gb.dat
Resolving proof.ovh.net (proof.ovh.net)... 2001:41d0:242:d300::, 141.95.207.211
Connecting to proof.ovh.net (proof.ovh.net)|2001:41d0:242:d300::|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10737418240 (10G) [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null                                                  100%[====================================================================================================================================>]  10.00G  8.96MB/s    in 19m 4s  

2026-05-15 11:34:22 (8.95 MB/s) - ‘/dev/null’ saved [10737418240/10737418240]


real	19m3.906s
user	18m35.777s
sys	0m25.215s

So it doesn't affect everyone. We need to find what if different in your network that triggers the issue.

[pelwell]

The same question about dtparam=eee=off applies to you, when you get a chance. My 4B has been running YouTube in Chromium with occasional Raspberry Pi homepage updates for about an hour now.

[JustArchi]

FYI I'm not getting kernel panics myself and the network connectivity goes back on after a while. ping in the background while downloading file is good indicator. If you just leave file being downloaded, you might miss the problem, as the only visibile thing is download speed being less than what normally should apply to your network (due to those drops).

Gonna check dtparam=eee=off in a second.

[JustArchi]

@pelwell I can confirm dtparam=eee=off resolves the issue entirely for me on 6.18 kernel.

--- 10.10.10.2 ping statistics ---
420 packets transmitted, 420 received, 0% packet loss, time 419490ms
rtt min/avg/max/mdev = 43.641/50.967/121.754/5.678 ms

Let me know if I can help any further.

[Windkracht8]

dtparam=eee=off also works for me.

On the old kernel, this is the output for EEE settings
EEE settings for eth0: EEE status: enabled - active 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: 100baseT/Full 1000baseT/Full

I am booting on USB, there is no SD-card in the Raspberry.
Raspberry model: Raspberry Pi 4 Model B Rev 1.5

[pelwell]

If anyone still has (or can revert to) a system that stalls in this way, does dmesg -l err,warn show anything after the first 20 seconds when it fails?