From nobody Wed Mar 19 22:07:04 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZJ2qv2RV8z5qmfj for ; Wed, 19 Mar 2025 22:07:07 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Certum Domain Validation CA SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZJ2qt6bnDz3G0n; Wed, 19 Mar 2025 22:07:06 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:9c78:4c6f:f974:aed5]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id C38D3721E2817; Wed, 19 Mar 2025 23:07:04 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: panic: tcp_do_segment: sent too much From: Michael Tuexen In-Reply-To: <29fe13ff-decc-456e-8afb-031de496932d@FreeBSD.org> Date: Wed, 19 Mar 2025 23:07:04 +0100 Cc: freebsd-net@freebsd.org, Gleb Smirnoff Content-Transfer-Encoding: quoted-printable Message-Id: References: <020C5409-C587-4D06-B764-1AD0C5783AB2@lurchi.franken.de> <29fe13ff-decc-456e-8afb-031de496932d@FreeBSD.org> To: Kyle Evans X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-Rspamd-Queue-Id: 4ZJ2qt6bnDz3G0n X-Spamd-Bar: ---- > On 19. Mar 2025, at 17:34, Kyle Evans wrote: >=20 > On 1/13/25 13:01, Michael Tuexen wrote: >>> On 13. Jan 2025, at 02:44, Kyle Evans wrote: >>>=20 >>> Hi, >>>=20 >>> I seem to have hit this panic during normal laptop usage with a = -CURRENT running at 2832af7b4ea256b18ef4dbf2ff97a50765f0609a: >>>=20 >>> panic: tcp_do_segment: sent too much >>> cpuid =3D 5 >>> time =3D 1736731772 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe015b74b9b0 >>> vpanic() at vpanic+0x136/frame 0xfffffe015b74bae0 >>> panic() at panic+0x43/frame 0xfffffe015b74bb40 >>> tcp_do_segment() at tcp_do_segment+0x2998/frame 0xfffffe015b74bc20 >>> tcp_input_with_port() at tcp_input_with_port+0x10f8/frame = 0xfffffe015b74bd70 >>> tcp_input() at tcp_input+0xb/frame 0xfffffe015b74bd80 >>> ip_input() at ip_input+0x28f/frame 0xfffffe015b74bde0 >>> swi_net() at swi_net+0x19b/frame 0xfffffe015b74be60 >>> ithread_loop() at ithread_loop+0x266/frame 0xfffffe015b74bef0 >>> fork_exit() at fork_exit+0x82/frame 0xfffffe015b74bf30 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe015b74bf30 >>>=20 >>> Doing a little bit of inspection: >>>=20 >>> (kgdb) print tp->t_dupacks >>> $1 =3D 1 >>> (kgdb) print tp->snd_limited >>> $6 =3D 0 '\000' >>> (kgdb) p/x tp->t_flags >>> $4 =3D 0x10000264 >>> (kgdb) print maxseg >>> $1 =3D 1428 >>>=20 >>> `sent` appears to be optimized out. As far as I know, I don't hit = this one often, but I'm wondering if there's anything else useful I = could extract here / if anyone has a theory about what happened. >> Hi Kyle, >> you can run your system with TCP black box logging enabled by using >> sysctl net.inet.tcp.bb.log_auto_all=3D1 >> sysctl net.inet.tcp.bb.log_auto_ratio=3D1 >> sysctl net.inet.tcp.bb.log_auto_mode=3D1 >> Also have the tcplog_dumper running. You can use >> tcplog_dumper_enable=3D"YES" >> in /etc/rc.conf >> You can install tcplog_dumper by >> pkg intall tcplog_dumper >> Using these settings (mode =3D TCP_LOG_STATE_TAIL), keeps the = trailing events of all TCP connections, but does not dump anything to = disk. If the kernel panics, we can get the BBLog information from the = core. >> Please note that Gleb has just committed two fixes which also address = a panic() like the one you are experiencing. > I've seen another of these on a tree branched from early March @ = d4c81623accede ("universe: Update the default GCC toolchain to GCC 14") > with the above enabled; what can I provide, or has another likely = cause been addressed since then? I think the problem will be address by https://reviews.freebsd.org/D49414 Best regards Michael >=20 > Thanks, >=20 > Kyle Evans