From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 11:56:33 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBE4106564A; Fri, 28 Oct 2011 11:56:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 74C618FC1A; Fri, 28 Oct 2011 11:56:33 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5BFAD46B09; Fri, 28 Oct 2011 07:56:27 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F011C8A02E; Fri, 28 Oct 2011 07:56:26 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Fri, 28 Oct 2011 07:56:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111022084931.GD1697@garage.freebsd.pl> <4EA9F76E.9010008@freebsd.org> <20111028054605.GF1667@garage.freebsd.pl> In-Reply-To: <20111028054605.GF1667@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201110280756.23317.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 28 Oct 2011 07:56:27 -0400 (EDT) Cc: Kostik Belousov , Lawrence Stewart , freebsd-current@freebsd.org, Andre Oppermann , freebsd-net@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. 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: Fri, 28 Oct 2011 11:56:33 -0000 On Friday, October 28, 2011 1:46:07 am Pawel Jakub Dawidek wrote: > On Fri, Oct 28, 2011 at 11:29:34AM +1100, Lawrence Stewart wrote: > > On 10/26/11 22:53, John Baldwin wrote: > > > The assertion would be triggered when the next packet arrives (as I said > > > above). Try modifying your debugging output to also log if the ACK is > > > delayed. I suspect it is not delayed until the last one. (Pushing out an > > > ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case > > > of an immediate ACK, rcv_nxt> rcv_adv is only a transient condition all > > > under a single lock invocation so never visible to other consumers of the > > > protocol control block.) If that is what you see, then that confirms what > > > I guessed above and I will likely just remove the assertion in tcp_input() > > > and patch the timewait code to handle this case. > > > > > > > Pawel, have you been able to confirm John's hypothesis? [...] > > Yeah, sorry. I moved the debug to the points where we drop the t_inpcb > lock and I still see rcv_nxt being greater than rcv_adv: > > tcp_do_segment:2970 negative window: tp 0xfffffe00685ee3d0 rcv_nxt 1312878324 rcv_adv 1312878187 Yes, I still expect this. What I want to see is if 'delack' is always true in this case. > This is just before the INP_WUNLOCK(tp->t_inpcb) under 'check_delack' > label. I see this a lot (it was logged 545 times for 11 different tp > pointers during 24h period). > > tcp_do_segment:3009 negative window: tp 0xfffffe005cfc6000 rcv_nxt 1442546453 rcv_adv 1442545722 > > This is just before calling tcp_output(). This one was logged 65 times > for 3 different tp pointers. > I placed a debug also after tcp_output() call, but it is not logged, so > once we return from tcp_output() everything is fine. That is consistent with what I expect then, since in the delack case, tcp_output() isn't called. -- John Baldwin