State captured at the stall
---------------------------
Captured automatically on the node while wedged (it is unreachable at
the time, so this is collected locally by a timer):
tc -s qdisc show dev eth0
qdisc pfifo_fast 0: root refcnt 2 ... qlen 1000
Sent ... (dropped 431, overlimits 0 requeues 5046)
backlog 364031b 1027p requeues 5046
ethtool -S eth0
tx_underrun: 0
tx_single/multiple/excessive/late_collision*: all 0
tx_carrier_sense_errors: 0
q0_tx_dropped: 0
ip -s link show eth0
TX: errors 0 dropped 0 carrier 0 collsns 0
ethtool eth0 -> Link detected: yes, 1000Mb/s, Full
dmesg -> nothing; no NETDEV WATCHDOG at any point
So the qdisc backlog runs up to and past qlen while every MAC-level
counter stays clean: the frames are never handed to the hardware. RX
continues throughout at ~13 pkt/s of broadcast/multicast. The CPU is
~99.8% idle with load 0.00, so nothing else on the box is wedged.
The absent NETDEV WATCHDOG matches your description of the stall being
silent - nothing above the driver ever intervenes.
Recovery
--------
ip link set eth0 down; sleep 2; ip link set eth0 up
restores it immediately and drains the backlog to 0. Before I automated
that, each stall lasted 25-40 minutes and was ended only by the switch's
PoE watchdog power-cycling the port, which is what made it look like a
power fault at first.
With detection at a 30s poll on tx_packets, plus that bounce, outages
are down to ~60 seconds.
I have not yet tried "tso off sg off". Given the load figures above I am
not sure it will help here, and I would rather report what it does than
guess - I will follow up either way.
Happy to provide the full before/after captures, or to run a patched
kernel and report node-hours to first stall against the baseline above.
AI DISCLOSURE: I have been heavily assisted by Claude Fable when
diagnosing this issue
--
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
