https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239240
--- Comment #44 from [email protected] ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=69c3e0de01c1938792d319f18ba0a9ffa60dfa96
commit 69c3e0de01c1938792d319f18ba0a9ffa60dfa96
Author: Alexander Leidinger <[email protected]>
AuthorDate: 2026-08-04 16:44:52 +0000
Commit: Alexander Leidinger <[email protected]>
CommitDate: 2026-08-04 17:13:43 +0000
iflib: restore TX watchdog functionality
Since f6afed726b00 the TX-hang check in iflib_timer() has required a
queue state other than IFLIB_QUEUE_IDLE, but nothing ever sets
IFLIB_QUEUE_WORKING, so IFLIB_QUEUE_HUNG has been unreachable ever
since: stalled TX queues are not detected, not reported, and not
reset - the TX watchdog of every iflib(4) driver has been dead code.
Instead of resurrecting the queue-state machine, detect the hang
directly. A transmit queue is frozen while it holds descriptors the
hardware has not reported as completed and none were reclaimed over a
timer period. Being frozen is not a fault: the hardware may defer
marking descriptors as completed indefinitely. The check therefore
arms only when a frozen queue also takes on new work, while the link
is up, no pause frames were received and no doorbell is pending; and
it acts only after the queue has stayed frozen for
net.iflib.tx_watchdog_periods consecutive periods. It then asks the
hardware through the driver's read-only credits peek
(isc_txd_credits_update with clear=false, the same call the mp_ring
can_drain callback makes routinely): if completions are ready but were
not harvested for this long, the completion interrupt went missing -
kick the queue's task instead of resetting; if the hardware reports
nothing although the queue kept receiving work, it is hung and the
existing watchdog reset machinery takes over.
Neither software counters alone nor mere persistence of unharvested
work can make this decision. iflib reclaims lazily (up to
isc_tx_nsegments completed descriptors stay unharvested indefinitely)
and defers report-status requests, so "descriptors in use" and "no
cleaning progress" are normal states of an idle healthy queue. And
hardware that coalesces completion reports (e.g. 8254x,
TXDCTL.WTHRESH) legitimately withholds the last one of a quiet queue
indefinitely, so a zero credits peek is a normal idle state, not a
hang indicator: arming on persistence alone reset healthy interfaces
on every traffic lull (field-tested on 82541PI). Only growth across
frozen periods separates a wedged queue from a coalescing one. The
threshold is a threshold in time, not in device work: a period is one
iflib_timer interval (hz/2 by default), so at the default of four
periods the verdict falls after roughly two seconds. It was
calibrated from counter traces on that old and slow hardware, where
healthy coalescing always cleared within two periods; newer hardware
reports completions far sooner and leaves the frozen state earlier, so
the default needs no recalibration for more modern devices. Setting
the sysctl to zero disables the check.
A queue whose link is down is never flagged - preserving what
f6afed726b00 fixed.
The new per-queue state goes into padding the transmit queue structure
already had, rather than next to the counters it is derived from: that
region is packed, so an insertion there would grow the structure. What
is left of that padding is now spelled out instead of being implicit.
The size of the structure is unchanged on amd64, arm64, riscv64, i386
and armv7.
The IFLIB_QUEUE_* states no longer participate in the watchdog
decision; they will be removed in a followup commit.
PR: 220997, 239240
Fixes: f6afed726b00 ("iflib: Prevent watchdog from resetting idle
queues")
Suggested by: gallatin (mxge-style detection)
Reviewed by: adrian, markj
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D58266
Assisted-by: Claude Code (Fable 5, Opus 5)
share/man/man4/iflib.4 | 11 +++-
sys/net/iflib.c | 135 +++++++++++++++++++++++++++++++++++++++----------
2 files changed, 118 insertions(+), 28 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.