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=263445 --- 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 = {start = 3327712881, end = 3327714341, rxmit = 3327714340, scblink = {tqe_next = 0x0, tqe_prev = 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 only 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=0), 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=0. -- 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>