Re: August 2026 stabilization week

Am 2026-08-27 04:36, schrieb Kevin Bowling:
> 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.

A buildworld after src-update is already running since 11 hours (current 
state: 32bit shim libs build). I just applied the patch, but it will 
take a while until it reaches the kernel build. This is an old and slow 
machine... After a reboot (with dev.em.0.allow_64bit_dma=1) I should be 
able to tell within a few hours if it still works.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF