Date: Tue, 31 May 2022 11:26:15 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 263445] Fatal trap 12: page fault while in kernel mode // supervisor read data, page not present // 13.1-RC3 Message-ID: <bug-263445-7501-NiOdAw2S8i@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263445-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-263445-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=3D263445 --- Comment #8 from Richard Scheffenegger <rscheff@freebsd.org> --- Hi Victor, sorry for the delay. Can you verify, that in all your cores the tcp t_state= (p *tp in the first frame of tcp_do_segment) is TCPS_LAST_ACK (8)? And that you have some unacknowledged SACK information, where one byte is outstanding? p *tp->sackhint.nexthole f 10 p tp->t_state p *tp->sackhint.nexthole $4 =3D {start =3D 3327712881, end =3D 3327714341, rxmit =3D 3327714340, scb= link =3D {tqe_next =3D 0x0, tqe_prev =3D 0xfffffe044ba66578}} It seems as if there is a little bit of data being sent, and before all of = the data is fully acked by the client, the application closes the socket, but o= nly receives a SACK for the FIN (?), while the two prior data packets are still outstanding - and probably an off-by-one error happens during SACK processing... As a stopgap measure, you can disable SACK (net.inet.tcp.sack.enable=3D0), = or disable PRR - this is one new SACK-related feature, but should only affect timing (when to send, NOT what to send) with net.inet.tcp.do_prr=3D0. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263445-7501-NiOdAw2S8i>