RX packet drops on Raspberry Pi 5 not reflected in ethtool or softnet_stat

[richaso]

Describe the bug

RX dropped packets on Raspberry Pi 5 (RP1 Ethernet) not accounted for by ethtool or softnet_stat

Summary

Using a Raspberry Pi 5 (Model B Rev 1.0) with Raspberry Pi OS and the onboard RP1 Ethernet (driver: macb), I'm experiencing a consistent increase in RX packet drops as reported by ip -s link show eth0. However, these drops are not reflected in ethtool -S eth0 or /proc/net/softnet_stat.

This strongly suggests the packet loss is occurring between the NIC and the kernel network stack, likely due to RP1 driver (or DMA/IRQ handling) issues.

---

Symptoms

1. RX drops seen with ip -s link show eth0:

   RX:  bytes packets errors dropped missed mcast
        4972630 27502   0      617     0     4248
   

2. No drops shown with ethtool -S eth0:

   q0_rx_dropped: 0
   rx_resource_errors: 0
   rx_overruns: 0
   

3. No softnet backlog congestion:

   grep . /proc/net/softnet_stat
   # all second columns (softnet drops) are 0
   

4. IRQs are handled only by CPU0 by default:

   cat /proc/interrupts | grep eth
   104:  44535  0  0  0  rp1_irq_chip  6 Level  eth0
   

5. Installing and enabling irqbalance does not stop the RX drops.

6. Behavior persists even using USB 3.0 Ethernet adapters (tested with AX88179).

---

Diagnosis

• The kernel is counting dropped RX packets.
• The NIC driver (macb) and DMA interface do not acknowledge drops.
• The loss appears to happen in the path between NIC → driver → netdev → socket.
• The issue could be related to the RP1 integration or IRQ/DMA handling.
• Affects onboard Ethernet on Pi 5, not specific to cables or switch.

---

Request

Please advise on:

• Whether this is a known issue with the RP1 or the macb driver
• Any recommended kernel module parameters or overlays
• Whether there are upcoming fixes in rpi-firmware or kernel updates
• How to help trace or test this further

Happy to provide more debug logs if needed.

Steps to reproduce the behaviour

Reproducing the issue

1. Boot Raspberry Pi 5 with default Raspberry Pi OS.
2. Connect to gigabit network.
3. Run any kind of sustained traffic (ping, DNS, iperf3).
4. Monitor ip -s link show eth0 and observe dropped increasing.
5. Check ethtool -S eth0 and /proc/net/softnet_stat: no errors reported.

Device (s)

Raspberry Pi 5

System

• Model: Raspberry Pi 5 Model B Rev 1.0
• OS: Raspberry Pi OS (64-bit, aarch64)
• Kernel:

  uname -a
  Linux pihole6 6.12.25+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux
  

• Ethernet driver:

  ethtool -i eth0
  driver: macb
  version: 6.12.25+rpt-rpi-2712
  

The issue is not related to physical network components. The following were tested and ruled out:

• Multiple high-quality Ethernet cables (Cat6 and Cat7)
• Different switch ports and switches (1 Gbps)
• Direct connection to a known-good Asus ET12 router
• USB 3.0 Ethernet adapters (with AX88179 chipset)
• The problem persists regardless of the physical interface used

This confirms that the RX packet drops are not caused by link instability, faulty cables, or external hardware.

[pelwell]

Duplicate of #6855?

[richaso]

Duplicate of #6855?

I've reviewed related issues (e.g., #6855), but my case appears to be different:

• In my case, RX drops are persistent and consistently reproducible, not intermittent.
• USB 3.0 Ethernet adapters (e.g. AX88179) also show drops, unlike in #6855.

[Rtigger]

I am seeing the same issue on Rpi4 (bcmgenet) and Rpi5 (bmac) with the latest Trixie 64 bit and software updates. RX packets seem to arrive (activity light blinking away), but the network doesn't seem to see all of them. A ping between two Rpi4's loses about 3% RX. Switching to a usb dongle (ax88179) makes things worse.

The RX packet loss affects an RTSP stream to the Rpi4 from a network camera, so much so that ffplay finally stops updating. Don't see these issues with Windows laptops or Linux Mint boxes.

One workaround that helps a lot, is to let a ping run from the Rpi4 to any box on the local network. This reduces the dropped packets from hundreds to the tens or less. RX dropped length of time drops way down.

I have no idea if there is a solution to this issue which seems to have been around for a long time.