Hi, Noritoshi Demizu sent me a fix for this issue. Can you try this fix ? I'll get this committed to -current shortly. It looks like because you run with larger windows, generating a lot of sack holes, we ran into the sackhole limits that caused allocation of a new sackhole to fail, causing the bug. thanks ! mohan Index: tcp_sack.c =================================================================== RCS file: /home/cvsup/FreeBSD/ncvs/src/sys/netinet/tcp_sack.c,v retrieving revision 1.22 diff -u -r1.22 tcp_sack.c --- tcp_sack.c 6 Jun 2005 19:46:53 -0000 1.22 +++ tcp_sack.c 8 Jun 2005 03:18:42 -0000 _at__at_ -458,13 +458,19 _at__at_ * beyond the current fack, they will be inserted by * way of hole splitting in the while-loop below. */ - tcp_sackhole_insert(tp, tp->snd_fack, sblkp->start, NULL); + temp = tcp_sackhole_insert(tp, tp->snd_fack,sblkp->start,NULL); + if (temp == NULL) + return 0; tp->snd_fack = sblkp->end; /* Go to the previous sack block. */ sblkp--; } else if (SEQ_LT(tp->snd_fack, sblkp->end)) /* fack is advanced. */ tp->snd_fack = sblkp->end; + /* + * At this point, at least one SACK hole must exist. + */ + KASSERT(!TAILQ_EMPTY(&tp->snd_holes), ("SACK scoreboard is emtpy")); cur = TAILQ_LAST(&tp->snd_holes, sackhole_head); /* Last SACK hole */ /* * Since the incoming sack blocks are sorted, we can process them --- Andrey Chernov <ache_at_nagual.pp.ru> wrote: > On Tue, Jun 07, 2005 at 07:01:22PM -0700, Mohan Srinivasan wrote: > > Yes. That will work around it too. > > > > I forget to mention that I use relatively large send/recvspace, about > 128K, it may increase bug trigger because SACK happens often. > > -- > http://ache.pp.ru/ > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Wed Jun 08 2005 - 02:25:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:36 UTC