Date: Mon, 18 Dec 2023 11:17:48 +0000 From: bugzilla-noreply@freebsd.org To: transport@FreeBSD.org Subject: [Bug 275798] panic: sackhint bytes rtx >= 0 Message-ID: <bug-275798-38102-fcJZoKrIj3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275798-38102@https.bugs.freebsd.org/bugzilla/> References: <bug-275798-38102@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=3D275798 --- Comment #6 from Richard Scheffenegger <rscheff@freebsd.org> --- can you please provide the core (w/ kernel & kernel.debug)? The bblog data = will have captured the evolution how we ended up in this state - but it currently requires the core to undig all that information manually. And I spotted an oversight in the tcp_output error path, but that's not the issue here...=20 But the problem happens quite early in the affected TCP session: iss =3D 331585966 recover =3D 14492=20 fack =3D 14492 una =3D 10936 max =3D 14492 in frame 6, the incoming tcp header option sack appears to cover: 11171-12164(993) in frame 5, the sack block seems to cover the entire range from una to max (10936-14492) - but this is probably after processing it in full. The sack_bytes_rexmit is -235, or the delta between snd_una and the left ed= ge of the to_sack block... I wonder if this is a DSACK block on a cumulative ack, after the holes have been retransmitted, ending up miscalculating this.. (So with reordering of packet delivery or ACKs carrying SACK information). --=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-275798-38102-fcJZoKrIj3>