From owner-freebsd-current@FreeBSD.ORG Wed Jun 8 04:25:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1EBEF16A41C for ; Wed, 8 Jun 2005 04:25:15 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: from web80604.mail.yahoo.com (web80604.mail.yahoo.com [66.218.79.93]) by mx1.FreeBSD.org (Postfix) with SMTP id EE26C43D1F for ; Wed, 8 Jun 2005 04:25:14 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20050608042514.19223.qmail@web80604.mail.yahoo.com> Received: from [64.172.45.214] by web80604.mail.yahoo.com via HTTP; Tue, 07 Jun 2005 21:25:14 PDT Date: Tue, 7 Jun 2005 21:25:14 -0700 (PDT) From: Mohan Srinivasan To: Andrey Chernov In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: raja@moselle.com, current@freebsd.org, demizu@dd.iij4u.or.jp Subject: Re: Still something wrong with tcp_sack_option () X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 04:25:15 -0000 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 @@ -458,13 +458,19 @@ * 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 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >