On 1/13/25 13:01, Michael Tuexen wrote:
On 13. Jan 2025, at 02:44, Kyle Evans <kev...@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
