attached the trap script that takes the captures above.
REQUEST: PLEASE CHERRY-PICK THE UPSTREAM FIX INTO RESOLUTE LINUX-RASPI
----------------------------------------------------------------------
This is a follow-up to my previous comment with the test results.
A fix exists upstream. It will not reach this kernel by itself, because
the 7.0 stable series is no longer maintained upstream. So I ask for a
cherry-pick.
[Impact]
Raspberry Pi 5 and CM5 on Ubuntu 26.04 LTS (linux-raspi 7.0) stop all
TX on eth0 at random. The interval is hours to days. The load does not
matter. It also occurs near idle. RX continues. No error counter moves.
No watchdog fires. Without an external detector, the node is
unreachable until a power cycle. 17 users are affected on this bug,
plus duplicate #2150334.
[Fix]
Mainline commit e438ec3e9e95, "net: macb: add TX stall timeout
callback to recover from lost TSTART write" (Raczylo, Jaeckel, della
Porta). The macb maintainer reviewed it. It carries "Fixes:
dc110d1b2356", the commit that added RP1 support to macb.
Where it is today:
- mainline v7.2-rc1 and later
- stable 7.1.y as 9acbcb89190a
- the Raspberry Pi kernel since 2026-07-14 (raspberrypi/linux PR
#7472). That PR replaced an earlier four-patch series with this
single commit, to align with mainline.
It is not in 7.0.y.
The commit adds a .ndo_tx_timeout callback for macb. When the TX queue
stops, the callback runs the existing restart path and writes TSTART
again. This is recovery, not root cause. The stall still occurs. The
driver then recovers it in seconds instead of never.
[Test Case]
Run Pi 5 nodes with default offloads. Read
/sys/class/net/eth0/statistics/tx_packets every 30 s. Two unchanged
readings in a row with carrier up is a stall. Baseline on 7.0.0-1017:
24 stalls in 344 node-hours. With the fix, dmesg should show "TX stall
detected on queue 0 ... re-kicking TSTART" and no userspace action
should be necessary. I can run this on a -proposed kernel and report
node-hours to first stall against the baseline above.
[Regression Potential]
Low. The change is limited to drivers/net/ethernet/cadence/macb_main.c.
It only runs when a TX queue has been stopped for longer than the
netdev watchdog timeout. That path never runs on a healthy device.
Mainline, 7.1.y and Raspberry Pi OS ship it today.
Workaround until then, confirmed in my previous comment and in #34 and #45:
ethtool -K eth0 tso off sg off
Persist it with a networkd-dispatcher routable.d hook. The setting does
not survive a reboot on its own.
AI DISCLOSURE: I have been heavily assisted by Claude Fable when
diagnosing this issue
** Attachment added: "txwatch.sh"
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877/+attachment/5998328/+files/txwatch.sh
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2133877
Title:
Complete network hang on Raspberry Pi 5 with kernel 6.17 under load -
possibly related to CPU frequency scaling
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/2133877/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
