Another data point, from a very different workload: Ubuntu linux-raspi 7.0.0-1017 on a Pi 5 Model B 16GB, driver macb, Cadence GEM via RP1. That kernel version is not in the affected list above.
@elflensky (#49/#50): your idle-TX report matches mine closely, and I think a third independent site is worth having. No Kubernetes, no Cilium, no Swarm here, just a handful of Docker containers serving almost no traffic, and the stall still happens. Onset conditions, from sar -n DEV for the 10-minute bucket before onset: eth0 at 46 pkt/s, 3 kB/s rx / 20 kB/s tx, %ifutil 0.02, load average 0.38, runqueue 0. Five occurrences so far; the longest ran 132 minutes and ended only on a power cycle. Relevant to the DVFS-transition idea in #50: this box is also on "ondemand", scaling_min_freq 1500000 / scaling_max_freq 2400000, sampled at 2000000 while idle, 38.6C. So it is another ondemand box doing periodic small work, i.e. another high-transition case rather than a high-load one. MAC-level picture, consistent with #49: - tx_frames frozen at exactly 13111057 for the entire outage while rx_frames climbed 12995958 -> 13011695 - /proc/net/snmp Ip InReceives / InDelivers kept rising throughout - tx_underrun 0, link detected yes, default route present and correct - gateway ARP entry went INCOMPLETE, i.e. our ARP requests never left the wire - no NETDEV WATCHDOG, which is expected rather than informative: macb registers no .ndo_tx_timeout, so __netdev_watchdog_up() never arms the timer at all One thing I have not seen posted here yet: the macb register dump at stall time, now armed via "ethtool -d eth0" in the same snapshot that captures the counters. Decoding against macb_get_regs(), the useful words are buf[0] NCR, buf[3] TSR, buf[5] TBQP, buf[8] tx_tail, buf[9] tx_head (note ethtool dumps a buffer, so those offsets are not the hardware register offsets). A healthy baseline here reads head == tail with TBQP == tx_dma(head) == tx_dma(tail). If the next stall shows head != tail with TBQP frozen, that is the descriptor-fetch halt captured directly, and TSR should say whether anything latched. I will post the raw dump when it fires; it should complement the qdisc-side capture in #49 from the other end of the path. On why nothing recovers it by itself: IMR here reads 0x3ffff305, which leaves TXUBR, ISR_TUND, ISR_RLE and TXERR unmasked. So if the hardware had raised any TX error, macb_interrupt_misc() would have scheduled macb_tx_error_task() and the ring would have reset itself. It never does. Whatever stops the transmitter raises nothing at all. @elflensky, on "I have not yet tried tso off sg off" in #49: I applied it on 2026-09-03 (both, persisted via a systemd unit), governor deliberately left at ondemand. That makes this box roughly equivalent to your swarm02/swarm03 arm, but on a different kernel and a very different workload. Stalls here were days to weeks apart rather than one per 14 node-hours, so it will take several weeks of clean runtime before absence of stalls means anything. I will report back either way, including a negative result. AI DISCLOSURE: I have been heavily assisted by Claude Opus 5 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
