Date: Sun, 24 Jan 2021 21:32:02 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 252958] [tcp] Kernel panic in tcp_prr_partialack() Message-ID: <bug-252958-7501-w3ChEOcfah@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-252958-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-252958-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252958 --- Comment #4 from Richard Scheffenegger <rscheff@freebsd.org> --- I'm not sure how to end up with a PRR_partialack, without recover_fs being initialized. Potentially with ACK reordering (unlikely), or spurious RTO rollback (where TF_FASTRECOVERY may be set, but recover_fs was cleared already. Do you observe non-zero "data packets unnecessarily retransmitted" in=20 the output of netstat -snp tcp? https://reviews.freebsd.org/D28326 has a patch to fix the div/0 in that sec= tion of code, although knowing explicitly the system ends up going there would be interesting. If the frequence of the above counter incrementing (and no more panics with that patch) matches the typical runtime when it happend, it's like to have = to do with RTO rollbacks. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252958-7501-w3ChEOcfah>