No ethernet connectivity on P3B+ with Trixie linux-image-6.18.33+rpt-rpi-v7

[haidinger]

Describe the bug

After upgrading to the 6.18.x tree (linux-image-6.18.33+rpt-rpi-v7) from 6.12.75 on a Pi 3B+ Rev 1.3, ethernet access is "dead".

No firewall enabled. Serial console still works. Headless system, no screen attached.

Note: perhaps related to raspberrypi/firmware#2034 but then again downgrading the raspi-firmware from 1:1.20260521-2 to 1:1.20260521-1 did not fix the issue for me. I had to revert to the 6.12.75 kernel.

Steps to reproduce the behaviour

Update to latest Trixie (as of 2026-06-12) with linux-image-6.18.33+rpt-rpi-v7 and reboot. Ethernet stops working.
kernel logs "lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped" messages frequently.

To revert, restore old 6.12.x kernel:
cp /boot/vmlinuz-6.12.75+rpt-rpi-v7 /boot/firmware/kernel7.img
cp /boot/initrd.img-6.12.75+rpt-rpi-v7 /boot/firmware/initramfs7

Reproduce by reinstalling current kernel:
apt reinstall linux-image-6.18.33+rpt-rpi-v7

Device (s)

Raspberry Pi 3 Mod. B+

System

cat /etc/rpi-issue
Raspberry Pi reference 2014-01-07 (armhf)
Generated using spindle, http://asbradbury.org/projects/spindle/, 0e00a4f, stage
4-lxde-edu.qed

uname -a
Linux pi3-sms 6.18.33+rpt-rpi-v7 #1 SMP Raspbian 1:6.18.33-1+rpt1 (2026-06-01) a
rmv7l GNU/Linux

#vcgencmd version
May 21 2026 11:22:12
Copyright (c) 2012 Broadcom
version 288930ab4712b99596f32732664aaaeb881ef1e0 (clean) (release) (start_cd)

Logs

[ 74.833005] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 74.840410] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 79.838322] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 87.018984] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped

Additional context

ifconfig shows packet counts, notably TX errors
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
...
RX packets 1002 bytes 74128 (72.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 129 bytes 15089 (14.7 KiB)
TX errors 2818 dropped 0 overruns 0 carrier 0 collisions 0

[pelwell]

An equivalent 64-bit kernel is working for me - I'll try with a 32-bit build in a moment, but I'm not expecting anything different.

What do the following commands return:

$ dmesg -l err,warn
$ ethtool --show-eee eth0

Now try running sudo ethtool --set-eee eth0 eee off and see if it makes any difference.

[pelwell]

6.18.33+rpt-rpi-v7 1:6.18.33-1+rpt1 (2026-06-01) is also behaving itself in my network environment.

[nbuchwitz]

lan78xx was converted to phylink in 6.17. One notable change relevant here: the TX LPI timer default dropped from 600 us to 50 us, so the MAC enters TX LPI much more aggressively on idle.

If TX recovers with EEE disabled, could you also try restoring the old timer at runtime without disabling EEE:

sudo ethtool --set-eee eth0 eee on tx-lpi-timer 600

If that makes it work too, it points to an interop issue with your link partner, and we probably want to keep the old default downstream (I also would check with upstream).

For what it's worth, my test system can't reproduce the issue so far:

nbw@rpi3bp:~ $ sudo ethtool --show-eee  eth0
EEE settings for eth0:
	EEE status: enabled - active
	Tx LPI: 50 (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
nbw@rpi3bp:~ $ uname -a
Linux rpi3bp 6.18.33+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.33-1+rpt1 (2026-06-01) aarch64 GNU/Linux

[haidinger]

I think the bug is more high-level (i.e. not eee/phy related) but merely limited to sending packets, see below.

But let me first address your question.
For the record, eee settings with the working 6.12 kernel tree:

#uname -a
Linux pi3-sms 6.12.75+rpt-rpi-v7 #1 SMP Raspbian 1:6.12.75-1+rpt1 (2026-03-11) armv7l GNU/Linux

#ethtool --show-eee eth0
EEE settings for eth0:
EEE status: disabled
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: Not reported
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full

The default settings with the 6.18 kernel:

#uname -a
Linux pi3-sms 6.18.33+rpt-rpi-v7 #1 SMP Raspbian 1:6.18.33-1+rpt1 (2026-06-01) a
rmv7l GNU/Linux
#ethtool --show-eee eth0
EEE settings for eth0:
EEE status: enabled - active
Tx LPI: 50 (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

I've tried to disable eee with combinations of tx-lpi on and off and with tx-timers upto (EDIT: fixed typo) 1000 us but to no avail.

No other notable dmesg messages other than the kevent ones:

[ 216.858578] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 221.816773] lan78xx 1-1.1.1:1.0 eth0: Link is Down
[ 224.957495] lan78xx 1-1.1.1:1.0 eth0: Link is Up - 1Gbps/Full - flow controloff
[ 228.548077] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 236.879680] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 241.884949] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 243.564785] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped

As for the interop problem: I doubt that because during troubleshooting and multiple restores from backup
(took me a while to narrow down the issue to the kernel itself, suspected some usb issue first)
the Pi3+ was connected to three switches of different vendors, managed and unmanaged without any difference.

That being said: I initially reported that I did not see any incoming traffic. Well, that was because the (managed) switch did it's job...
However, with the Pi3B+ connected to a much simpler (unmanaged) switch, I do see e.g. ARP traffic of other devices as well as the arp requests for the PI3B's mac.

After adding a static arp entry, I can see all the incoming traffic (icmp, tcp, etc) with tcpdump on the Pi3B.
It seems that only outgoing packets won't leave the system. This also correlates with the TX errors shown:

#ifconfig eth0
...
RX packets 1851 bytes 138581 (135.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 129 bytes 15089 (14.7 KiB)
TX errors 4311 dropped 0 overruns 0 carrier 0 collisions 0

Stats show zero TX packets...

#ethtool -S eth0
NIC statistics:
RX FCS Errors: 0
RX Alignment Errors: 0
Rx Fragment Errors: 0
RX Jabber Errors: 0
RX Undersize Frame Errors: 0
RX Oversize Frame Errors: 0
RX Dropped Frames: 0
RX Unicast Byte Count: 28471
RX Broadcast Byte Count: 110854
RX Multicast Byte Count: 34713
RX Unicast Frames: 234
RX Broadcast Frames: 1650
RX Multicast Frames: 357
RX Pause Frames: 0
RX 64 Byte Frames: 1942
RX 65 - 127 Byte Frames: 212
RX 128 - 255 Byte Frames: 37
RX 256 - 511 Bytes Frames: 46
RX 512 - 1023 Byte Frames: 0
RX 1024 - 1518 Byte Frames: 3
RX Greater 1518 Byte Frames: 0
EEE RX LPI Transitions: 2289
EEE RX LPI Time: 638188762
TX FCS Errors: 0
TX Excess Deferral Errors: 0
TX Carrier Errors: 0
TX Bad Byte Count: 0
TX Single Collisions: 0
TX Multiple Collisions: 0
TX Excessive Collision: 0
TX Late Collisions: 0
TX Unicast Byte Count: 0
TX Broadcast Byte Count: 0
TX Multicast Byte Count: 0
TX Unicast Frames: 0
TX Broadcast Frames: 0
TX Multicast Frames: 0
TX Pause Frames: 0
TX 64 Byte Frames: 0
TX 65 - 127 Byte Frames: 0
TX 128 - 255 Byte Frames: 0
TX 256 - 511 Bytes Frames: 0
TX 512 - 1023 Byte Frames: 0
TX 1024 - 1518 Byte Frames: 0
TX Greater 1518 Byte Frames: 0
EEE TX LPI Transitions: 0
EEE TX LPI Time: 0

#dmesg -l err,warn
[ 1.796292] Core Release: 2.80a
[ 1.796331] Setting default values for core params
[ 1.796375] Finished setting default values for core params
[ 1.997510] Using Buffer DMA mode
[ 1.998483] Periodic Transfer Interrupt Enhancement - disabled
[ 1.999462] Multiprocessor Interrupt Enhancement - disabled
[ 2.000432] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 2.001419] Dedicated Tx FIFOs mode
[ 2.002746] INFO:: FIQ DMA bounce buffers: virt = ba514000 dma = 0xfa514000 len=9024
[ 2.003786] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 2.008834] INFO:: FIQ on core 1
[ 2.009821] INFO:: FIQ ASM at 80949d30 length 36
[ 2.010804] INFO:: MPHI regs_base at be810000
[ 2.014838] Init: Port Power? op_state=1
[ 2.015801] Init: Power Port (0)
[ 2.151955] Indeed it is in host mode hprt0 = 00021501
[ 2.375087] Indeed it is in host mode hprt0 = 00001101
[ 3.827389] mmc0: host does not support reading read-only switch, assuming write-enable
[ 18.587995] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 18.682043] vc_sm_cma_vchi_init: failed to open VCHI service (-22)
[ 18.682070] [vc_sm_connected_init]: failed to initialize shared memory service
[ 18.778139] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 18.964144] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[ 18.994097] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 19.007087] bcm2835_mmal_vchiq: Failed to open VCHI service connection (status=-22)
[ 19.091965] bcm2835_mmal_vchiq: Failed to open VCHI service connection (status=-22)
[ 19.127895] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 19.168291] bcm2835_mmal_vchiq: Failed to open VCHI service connection (status=-22)
[ 23.842958] sr 0:0:0:0: Power-on or device reset occurred
[ 30.328320] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 31.362480] sr 0:0:0:0: Power-on or device reset occurred
[ 31.484378] sd 0:0:0:1: Power-on or device reset occurred
[ 74.483395] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 84.503845] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 115.661841] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 130.672865] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 139.732437] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped
[ 142.268735] lan78xx 1-1.1.1:1.0 eth0: kevent 0 may have been dropped

[nbuchwitz]

#uname -a
Linux pi3-sms 6.12.75+rpt-rpi-v7 #1 SMP Raspbian 1:6.12.75-1+rpt1 (2026-03-11) armv7l GNU/Linux
#ethtool --show-eee eth0
EEE settings for eth0:
EEE status: disabled
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: Not reported
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full

Probably a red hering, but why is EEE disabled on 6.12.75? Here a fresh trixie without any updates and 6.12.47 reported EEE to be default on:

Linux rpi3bp 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux
nbw@rpi3bp:~ $ sudo ethtool --show-eee  eth0
EEE settings for eth0:
        EEE status: enabled - active
        Tx LPI: 600 (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

Same for 6.18.33, but with new tx lpi time

[gt-whaid]

I don't know why EEE is disabled. I haven't disabled it explicitly unless this is caused by dwc_otg.lpm_enable=0 in cmdline.txt:
dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait usbcore.autosuspend=-1 dtoverlay=disable-bt consoleblank=0

[pelwell]

unless this is caused by dwc_otg.lpm_enable=0 in cmdline.txt

No - that won't do it.

But dtoverlay=disable-bt doesn't belong in cmdline.txt - that goes in config.txt.