Re: August 2026 stabilization week

On Wed, Aug 26, 2026 at 4:09 PM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
>
> On Wed, 26 Aug 2026 12:38:25 -0700
> Gleb Smirnoff <glebius@freebsd.org> wrote:
>
> > On Wed, Aug 26, 2026 at 08:30:02PM +0200, Alexander Leidinger wrote:
> > A> Am 2026-08-26 19:49, schrieb Gleb Smirnoff:
> > A> > On Tue, Aug 25, 2026 at 10:22:02AM -0700, Gleb Smirnoff wrote:
> > A> > T> My personal testing on a SOHO router, Intel video laptop and nVidia
> > A> > video
> > A> > T> desktop also didn't find any regressions.
> > A> >
> > A> > Update.  My SOHO router actually has a minor regression with Intel
> > A> > NICs:
> > A> >
> > A> > igb0: Watchdog timeout (TX: 0 desc avail: 979 pidx: 106) -- resetting
> > A> > igb0: link state changed to DOWN
> > A> > igb0: link state changed to UP
> > A> > igb1: Watchdog timeout (TX: 7 desc avail: 980 pidx: 543) -- resetting
> > A> > igb1: link state changed to DOWN
> > A> > igb1: link state changed to UP
> > A> >
> > A> > This never happened on this machine for 10 years.  It is just a single
> > A> > link loss for ~ 24 hours, but the traffic on this router is really
> > A> > minimal.
> > A>
> > A> The watchdog was not working for years. Commit
> > A> https://cgit.freebsd.org/src/commit/?id=69c3e0de01c1938792d319f18ba0a9ffa60dfa96
> > A> restores the functionality.
> > A>
> > A> net.iflib.timer_default is 4 by default (that's number of timer intervals).
> > A> If your hardware delays the update of the state longer than that, you can
> > A> increase that value. I have one slow and old hardware which needs the kick
> > A> by the watchdog, and the setting was tuned on that. Your more modern
> > A> hardware (igb should be way more modern than what this was tuned on) should
> > A> complete that stuff much faster, so the initial expectation is, that there
> > A> really is an issue.
> >
> > What have happened before?  The watchdog wasn't working for years, but the NIC
> > seemed to perform alright without it.  To be fair, this is very lightly loaded
> > machine without any precise monitoring, so it could be there were some network
> > lags that were not logged anywhere and if I experienced them in an interactive
> > sessions, I attributed to the rest of the Internet.  So, to put it short what
> > were the symptoms before the 69c3e0de01c1?
> >
> > --
> > Gleb Smirnoff
>
> Just a prediction, but usually in cases something was working but
> watchdog fires once configured are:
>   *Worked slowly that need more time than configured watchdog timeout.
> Or
>   *Worked but quite heavy-loaded that cannot have time to reset
>    watchdog timeouts.
>
> In both cases, assuming it's actually working fine, the workaround
> would be to increase watchdog timeout value to meet actual demands.

I believe this is a false positive in the new TX watchdog code
https://cgit.freebsd.org/src/commit/?id=69c3e0de01c1938792d319f18ba0a9ffa60dfa96

I've tested a fix on an igb 85280 including forced TX stalls with a
test probe and only the expected recovery occurred.

Gleb, Alexander, please test https://reviews.freebsd.org/D59204.  This
wouldn't affect stable yet but my change, if it works for you, should
land with that during MFC.

> Regards.
>
> --
> Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
>