Re: Latest -current complete lockup (tcp changes?)

On 2007-03-24 15:47, Andrey Chernov <ache_at_freebsd.org> wrote:
> Very recent -current cause complete lockup in case and after small
> amount of network activity happens. No panic, no ddb console - nothing
> just lockup. Previously working kernel is from Mar 22. I suspect
> recent round of TCP changes.

I'm seeing kernel panics with a kernel updates to:

    changeset:   129918:f239d4a0fa1e
    tag:         tip
    user:        imp
    date:        Fri Mar 23 23:47:59 2007 +0000
    summary:     Default to booting off the SD card.  It is more useful, [...]

The panic happens after a small amount of network activity, inside the
TCP SACK code:

---------------------------------------------------------------------------
Physical memory: 495 MB
Dumping 54 MB: 39 23 7

#0  doadump () at pcpu.h:172
172     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:172
#1  0xc048043f in db_fncall (dummy1=-747300744, dummy2=0, dummy3=-1065545344, dummy4=0xd3751854 "_at_\037\206ΐ") at /home/build/src/sys/ddb/db_command.c:486
#2  0xc048024b in db_command (last_cmdp=0xc07dec24, cmd_table=0x0) at /home/build/src/sys/ddb/db_command.c:401
#3  0xc0480306 in db_command_loop () at /home/build/src/sys/ddb/db_command.c:453
#4  0xc0481f51 in db_trap (type=3, code=0) at /home/build/src/sys/ddb/db_main.c:222
#5  0xc058a574 in kdb_trap (type=3, code=0, tf=0xd37519ec) at /home/build/src/sys/kern/subr_kdb.c:502
#6  0xc07164c9 in trap (frame=0xd37519ec) at /home/build/src/sys/i386/i386/trap.c:621
#7  0xc070041b in calltrap () at /home/build/src/sys/i386/i386/exception.s:139
#8  0xc058a29b in kdb_enter (msg=0x12 <Address 0x12 out of bounds>) at cpufunc.h:60
#9  0xc056b628 in panic (fmt=0xc0776652 "%s: SACK invalid") at /home/build/src/sys/kern/kern_shutdown.c:547
#10 0xc0627513 in tcp_sack_doack (tp=0xc300f740, to=0xd3751ac8, th_ack=3759729646) at /home/build/src/sys/netinet/tcp_sack.c:374
#11 0xc0623f88 in tcp_do_segment (m=0xc310ca00, th=0xc3140834, so=0xc3020570, tp=0xc300f740, drop_hdrlen=52, tlen=138) at /home/build/src/sys/netinet/tcp_input.c:1900
#12 0xc0622f01 in tcp_input (m=0xc310ca00, off0=20) at /home/build/src/sys/netinet/tcp_input.c:1004
#13 0xc061c3a5 in ip_input (m=0xc310ca00) at /home/build/src/sys/netinet/ip_input.c:662
#14 0xc05ee3c4 in netisr_dispatch (num=2, m=0x0) at /home/build/src/sys/net/netisr.c:278
#15 0xc05e7f85 in ether_demux (ifp=0xc2a55800, m=0xc310ca00) at /home/build/src/sys/net/if_ethersubr.c:829
#16 0xc05e7dc5 in ether_input (ifp=0xc2a55800, m=0xc310ca00) at /home/build/src/sys/net/if_ethersubr.c:687
#17 0xc04bdb18 in fxp_intr_body (sc=0xc2a74000, ifp=0xc2a55800, statack=0 '\0', count=-1) at /home/build/src/sys/dev/fxp/if_fxp.c:1705
#18 0xc04bd871 in fxp_intr (xsc=0xc2a74000) at /home/build/src/sys/dev/fxp/if_fxp.c:1526
#19 0xc0556d85 in ithread_execute_handlers (p=0xc2a4f480, ie=0xc2976800) at /home/build/src/sys/kern/kern_intr.c:682
#20 0xc0556eab in ithread_loop (arg=0xc2a7bad0) at /home/build/src/sys/kern/kern_intr.c:766
#21 0xc0555e84 in fork_exit (callout=0xc0556e44 <ithread_loop>, arg=0xc2a7bad0, frame=0xd3751d38) at /home/build/src/sys/kern/kern_fork.c:814
#22 0xc0700490 in fork_trampoline () at /home/build/src/sys/i386/i386/exception.s:205
(kgdb) up 10
#10 0xc0627513 in tcp_sack_doack (tp=0xc300f740, to=0xd3751ac8, th_ack=3759729646) at /home/build/src/sys/netinet/tcp_sack.c:374
374             KASSERT(to->to_flags & TOF_SACK, ("%s: SACK invalid", __func__));
(kgdb) list
369             struct sackhole *cur, *temp;
370             struct sackblk sack, sack_blocks[TCP_MAX_SACK + 1], *sblkp;
371             int i, j, num_sack_blks;
372
373             INP_LOCK_ASSERT(tp->t_inpcb);
374             KASSERT(to->to_flags & TOF_SACK, ("%s: SACK invalid", __func__));
375
376             num_sack_blks = 0;
377             /*
378              * If SND.UNA will be advanced by SEG.ACK, and if SACK holes exist,
(kgdb)
---------------------------------------------------------------------------

Disabling SACK lets me use my laptop again:

    net.inet.tcp.sack.enable=0

without any panics.