From nobody Tue Aug 4 17:16:02 2026 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4hF0Yz1WnVz6n590 for ; Tue, 04 Aug 2026 17:16:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "YR1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hF0Yy72xTz3tWL for ; Tue, 04 Aug 2026 17:16:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785863767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ynM+g9tE24JyC8dRvcXrM8wNa6YeVhVqCWQslrFc4kw=; b=FSxK8dixpJ1+K/0FZHh+Th7a3D+SNdqEuhZz8+3aSjvwga59bk7e2fD+75WyYVukaNZTA1 Ta8S6bE6iDI53cHgjkgWq4J3dakRLJzoSF1qwWWuhp174KYlKjy3dsvjRFBhuyRP7+xb3D qvCWSpa/HHZZlkeCNSl91IRIuGtDVlM1bWyGqw4G5/z0fGKXIsPHXZ9Sc2V66n5umKsPBt GBF+y4S/mQxxcZIko48TVhj4iDQOGEFexIo6MsnlQM8elFb81UE6TPp5irkSVhvxX1RAp2 wQyX6f9km791tvHIun14fzNyBxdHXlNKJJf7VIIug5HyQSDUGgvtx0nKrVe6UQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1785863767; a=rsa-sha256; cv=none; b=F/c6vsJn2W5WAPy62kCKRYD/JS+MrKjBR3ZTk1dONcxxyTUKgOc7H+/KiVB6SrrCUQ7stR 6u3XiJoFS/aYrStGPofRZ0Y4gXS3JnJRyWJmFHaaLbYdYg1e2iTDxEGDLBYnQ+o5xBU57d ew12XbAoHS6SzrC3qzvv0o+jcFhJlWIVCilze2UqVtuZeNWduUkPquEkv2zatHsjcIEqGU wIluqqL2EPvwUC9VOwIHOEPS6etqrzikSO6uLwlCx38dTdYvRUO7ziCg0ziOJ/cpd+BInj uF7NA1+2/Uak0p0rfaMYrIAzU0Yj9unFRMILpDM4tsGs3IohtbPL/DVb8xgAwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1785863767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ynM+g9tE24JyC8dRvcXrM8wNa6YeVhVqCWQslrFc4kw=; b=ghD5eMnwZtvWer4bPOaOTgHTaGf+bElQhyGEXyvErBWWVpBQfVdIiEUg348Vwh5LUZqzDd ulXz7Z7mNc56pMebNbnDjeqvAeOY2HodJTrUeXy+4A58wVbJTEm+Ea5gmqYIOMw9D2QyU9 pXtH8nNU43ulSQldFP/DFzuRaC8CM28arrROGk+girtL2JSqug/TrX/4JC/gqGJJbYl3vC g8tttLeZHrKwqTB/vCzGU571o2IE+7an92nPr8hfBrG3OsiiiX8sautBEZK/fRrVGoOIOK 8UBttTQ8rFZZMkNxjDVvFFkvpm4HDmaLdT8I8hEoKpz9Bztg8+ci4AuU4BAWKw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4hF0Yy64BWzwSw for ; Tue, 04 Aug 2026 17:16:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 674HG64l063967 for ; Tue, 4 Aug 2026 17:16:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 674HG6KK063966 for net@FreeBSD.org; Tue, 4 Aug 2026 17:16:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 239240] igb: TX(2) desc avail = 1024, pidx = 0 messages appear when the network card (igb/ixgbe/em) loses ethernet link Date: Tue, 04 Aug 2026 17:16:02 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: erj@freebsd.org X-Bugzilla-Flags: maintainer-feedback+ mfc-stable12+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239240 --- Comment #44 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D69c3e0de01c1938792d319f18ba0a9ffa= 60dfa96 commit 69c3e0de01c1938792d319f18ba0a9ffa60dfa96 Author: Alexander Leidinger AuthorDate: 2026-08-04 16:44:52 +0000 Commit: Alexander Leidinger 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=3Dfalse, 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 i= dle 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(-) --=20 You are receiving this mail because: You are on the CC list for the bug.=