Thanks for the heads-up. Is fixed with 5e248c23d995a059d24f4784d5a256cddd42e557
Richard
From: Baptiste Daroussin
Sent: Samstag, 24. Februar 2024 19:24
To: Richard Scheffenegger ; src-committ...@freebsd.org;
dev-commits-src-...@freebsd.org; dev-commits-src-main@FreeBSD.org
Subject: Re: git: f74
Let's discuss this during the next @transport call on thursday; I would want to
hold off for next weekend at least for the MFC to apply all related patches in
close succession. (and quite frankly didn't think about it)
Richard Scheffenegger
-Ursprüngliche Nachricht-
Von: Michael Tuexen
Hi Peter,
Hmm... the panic appears to be due to a stale entry in the sack scoreboard - a
hole not having been closed up to snd_una...
Unlikely that this was solely due to this change by itself.
Can I get the vmcore and kernel.debug for a close investigation?
Richard Scheffenegger
-Ursprü
Created D34181 to address this.
Both macros currently resolve to counter_s64_add() eventually, but that may
change eventually.
-Original Message-
From: Gleb Smirnoff
Sent: Samstag, 5. Februar 2022 16:17
To: Richard Scheffenegger
Cc: src-committ...@freebsd.org; dev-commits-src-...@fre
Hi John,
No, we don't think so. The symptoms fixed by this are markedly different when
performing error-injection to exercise these codepaths, than what we have
observed with additional logging from the systems reported in bug 264257...
Here, we fix an issue when a data segment + FIN is retran