Am 2026-08-27 04:36, schrieb Kevin Bowling:
On Wed, Aug 26, 2026 at 4:09 PM Tomoaki AOKI <[email protected]> wrote:On Wed, 26 Aug 2026 12:38:25 -0700 Gleb Smirnoff <[email protected]> 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 [email protected]: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org [email protected] : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
