From owner-freebsd-stable@freebsd.org  Thu Oct 13 15:17:17 2016
Return-Path: <owner-freebsd-stable@freebsd.org>
Delivered-To: freebsd-stable@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92858C0C3DA
 for <freebsd-stable@mailman.ysv.freebsd.org>;
 Thu, 13 Oct 2016 15:17:17 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 507B580F;
 Thu, 13 Oct 2016 15:17:17 +0000 (UTC) (envelope-from slw@zxy.spb.ru)
Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD))
 (envelope-from <slw@zxy.spb.ru>)
 id 1buhkx-000G4V-23; Thu, 13 Oct 2016 18:17:15 +0300
Date: Thu, 13 Oct 2016 18:17:15 +0300
From: Slawa Olhovchenkov <slw@zxy.spb.ru>
To: Julien Charbon <jch@freebsd.org>
Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@FreeBSD.org,
 hiren panchasara <hiren@strugglingcoder.info>
Subject: Re: 11.0 stuck on high network load
Message-ID: <20161013151715.GL57714@zxy.spb.ru>
References: <20161012095233.GC57714@zxy.spb.ru>
 <e4f1343c-636a-0970-856b-e65955f79e1a@freebsd.org>
 <20161012121322.GB57876@zxy.spb.ru>
 <62d8861c-673e-6d86-e96e-751399e505e5@freebsd.org>
 <20161012130103.GD57714@zxy.spb.ru>
 <e8a46471-576d-e074-8a50-5c316fb98bce@freebsd.org>
 <20161012154229.GC57876@zxy.spb.ru>
 <bc6810d8-af4c-1716-cbc7-e64819b78ccd@freebsd.org>
 <20161013143825.GK57714@zxy.spb.ru>
 <33ab0bfc-7009-95a7-7752-c2c439092e85@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <33ab0bfc-7009-95a7-7752-c2c439092e85@freebsd.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: slw@zxy.spb.ru
X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>, 
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Oct 2016 15:17:17 -0000

On Thu, Oct 13, 2016 at 05:06:00PM +0200, Julien Charbon wrote:

> >> will give you that trace in the core, and without INVARIANT then it is
> >> better to use dtrace:
> >>
> >> $ cat tcp-twstart-dropped.d
> >> fbt::tcp_twstart:entry
> >> /args[0]->t_inpcb->inp_flags & 0x04000000/
> >> {
> >>   stack();
> >>   printf("INP_DROPPED in tcp_twstart: %x", args[0]->t_inpcb->inp_flags);
> >> }
> > 
> > Same code may be insert there too, IMHO.
> 
>  Hmm, I don't think so:
> 
>  - If you have INVARIANT, the kernel will panic in tcp_twstart() or
> tcp_detach() and you will have everything you need to debug.
>  - If you don't, dtrace is the right tool to use in all cases anyway.

dtrace don't executed in may case w/ diagnostic "dtrace: processing
aborted: Abort due to systemic unresponsiveness". This is for
tcp_close. May be tcp_twstart will be more successuful, may be not.
Also, using dtrace too complex in production (need complex startup
under screen and capture output) and for many peoples.
kdb_backtrace() have too less administrative overhead.