Re: panic: tcp_do_segment: sent too much

From: Kyle Evans <kevans_at_FreeBSD.org>
Date: Wed, 19 Mar 2025 16:34:00 UTC
On 1/13/25 13:01, Michael Tuexen wrote:
>> On 13. Jan 2025, at 02:44, Kyle Evans <kevans@FreeBSD.org> wrote:
>>
>> Hi,
>>
>> I seem to have hit this panic during normal laptop usage with a -CURRENT running at 2832af7b4ea256b18ef4dbf2ff97a50765f0609a:
>>
>> panic: tcp_do_segment: sent too much
>> cpuid = 5
>> time = 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
>>
>> Doing a little bit of inspection:
>>
>> (kgdb) print tp->t_dupacks
>> $1 = 1
>> (kgdb) print tp->snd_limited
>> $6 = 0 '\000'
>> (kgdb) p/x tp->t_flags
>> $4 = 0x10000264
>> (kgdb) print maxseg
>> $1 = 1428
>>
>> `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=1
> sysctl net.inet.tcp.bb.log_auto_ratio=1
> sysctl net.inet.tcp.bb.log_auto_mode=1
> 
> Also have the tcplog_dumper running. You can use
> 
> tcplog_dumper_enable="YES"
> 
> in /etc/rc.conf
> 
> You can install tcplog_dumper by
> 
> pkg intall tcplog_dumper
> 
> Using these settings (mode = 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?

Thanks,

Kyle Evans