Re: panic: tcp_do_segment: sent too much

On Sun, Oct 27, 2024 at 1:14 PM Scheffenegger, Richard <
Richard.Scheffenegger@netapp.com> wrote:

>
> It's possible;
>
> D43355 and D43470 were quite strongly interrelated if my memory serves -
> any currently only the former is committed.
>
> OK. I give D43470 a green light for now, based on my initial test result
https://wiki.freebsd.org/chengcui/testD43470.
Any bugs found shall be fixed after these two. 😉

cc

-----Original Message-----
> From: Gleb Smirnoff <glebius@freebsd.org>
> Sent: Sonntag, 27. Oktober 2024 17:39
> To: rscheff@freebsd.org; tuexen@freebsd.org
> Cc: current@freebsd.org
> Subject: panic: tcp_do_segment: sent too much
>
> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
>
>
>
>
>   Hi,
>
> I just got this panic on my desktop running latest stabweek snapshot.
>
> panic: tcp_do_segment: sent too much
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame
> 0xfffffe0209deb440
> kdb_backtrace() at kdb_backtrace+0x46/frame 0xfffffe0209deb4f0
> vpanic() at vpanic+0x23d/frame 0xfffffe0209deb630
> panic() at panic+0x4e/frame 0xfffffe0209deb690
> tcp_do_segment() at tcp_do_segment+0x3a6c/frame 0xfffffe0209deb8d0
> tcp_input_with_port() at tcp_input_with_port+0x15db/frame
> 0xfffffe0209deba60
> tcp_input() at tcp_input+0x27/frame 0xfffffe0209deba90
> ip_input() at ip_input+0x1131/frame 0xfffffe0209debb00
> netisr_dispatch_src() at netisr_dispatch_src+0x18c/frame 0xfffffe0209debb70
> netisr_dispatch() at netisr_dispatch+0x21/frame 0xfffffe0209debb90
> ether_demux() at ether_demux+0x2a5/frame 0xfffffe0209debbd0
> ether_input_internal() at ether_input_internal+0x613/frame
> 0xfffffe0209debc10
> ether_nh_input() at ether_nh_input+0xb1/frame 0xfffffe0209debc30
> netisr_dispatch_src() at netisr_dispatch_src+0x18c/frame 0xfffffe0209debca0
> netisr_dispatch() at netisr_dispatch+0x21/frame 0xfffffe0209debcc0
> ether_input() at ether_input+0x16c/frame 0xfffffe0209debd10
>
> My kernel is compiled with -O0, which alleviates debugging:
>
> (kgdb) frame 4
> #4  0xffffffff80ea6c3c in tcp_do_segment (tp=0xfffff814a6f96000,
> m=0xfffff8044d546a00, th=0xfffff8044d546a82, drop_hdrlen=64, tlen=0,
>     iptos=72 'H') at /usr/src/FreeBSD/sys/netinet/tcp_input.c:2812
> 2812
> KASSERT((tp->t_dupacks == 2 &&
> (kgdb) p tp->t_dupacks
> $1 = 1
> (kgdb) p tp->snd_limited
> $2 = 0 '\000'
> (kgdb) p/x tp->t_flags
> $4 = 0x110003e4
> (kgdb) p/x tp->t_flags & 0x00000010     # TF_SENTFIN
> $5 = 0x0
> (kgdb) p tp->t_flags & 1                # TF_ACKNOW
> $15 = 0
> (kgdb) p sent
> $6 = 1507
> (kgdb) p maxseg
> $7 = 1400
> (kgdb) p oldcwnd
> $8 = 1400
> (kgdb) p oldsndmax
> $9 = 2473784830
> (kgdb) p tp->snd_max
> $10 = 2473786337
> (kgdb) p 2473786337 - 2473784830
> $11 = 1507
> (kgdb) p tp->snd_cwnd
> $12 = 2800
> (kgdb) p avail
> $13 = 2018
> (kgdb) p tp->snd_nxt - tp->snd_una
> $16 = 2018
> (kgdb) p so->so_snd.sb_acc
> $17 = 2018
> (kgdb) p *tp->snd_holes.tqh_first
> $22 = {start = 2473784319, end = 2473784358, rxmit = 2473784319, scblink =
> {tqe_next = 0x0, tqe_prev = 0xfffff814a6f96350}}
>
> Apparently tcp_output() has sent more than one segment. I don't know if
> this old assertion is correct, but looks like it started to trigger.
>
> Could this be related to 440f4ba18e3a?
>
> --
> Gleb Smirnoff
>


-- 
Best Regards,
Cheng Cui