From owner-freebsd-net@FreeBSD.ORG Thu Apr 26 18:54:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 080AC16A401 for ; Thu, 26 Apr 2007 18:54:53 +0000 (UTC) (envelope-from agile@sunbay.com) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [194.54.153.34]) by mx1.freebsd.org (Postfix) with ESMTP id 5337A13C45E for ; Thu, 26 Apr 2007 18:54:52 +0000 (UTC) (envelope-from agile@sunbay.com) Received: from frog.sunbay.crimea.ua (frog.sunbay.crimea.ua [192.168.4.67]) (authenticated bits=0) by whale.sunbay.crimea.ua (8.13.4/8.13.4/Sunbay) with ESMTP id l3QIO5LP086141 for ; Thu, 26 Apr 2007 21:24:06 +0300 (EEST) (envelope-from agile@sunbay.com) Message-ID: <4630EE4F.4060706@sunbay.com> Date: Thu, 26 Apr 2007 21:24:15 +0300 From: Oleg Dolgov User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (whale.sunbay.crimea.ua [192.168.4.65]); Thu, 26 Apr 2007 21:24:06 +0300 (EEST) Subject: full mbuf queue in tap device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 18:54:53 -0000 In our project we use tap device to make a VPN between clients. Server make a block read on opened and configured tap device, than send it to client, etc... If I connect to server with our client and begin to download many files from FTP throughout tunnel (300 Mb), than, after some time, tap mbuf output queue (ifp->if_snd) will full (ifp->if_snd.ifq_len = 49, ifp->if_snd.ifq_maxlen = 50), so, ip_output will drop packet and return ENOBUFS. And, even, if I will disconnect client, and just try to ping some network ip address, that will go throughout tap (except tap ip addrs): no mbufs error returned. From ddb, I see, that my server thread locked in waiting queue named "taprd". I turn on "net.link.tap.debug" and add debug line in ether_output_frame, here is last line from log (qlen is ifp->if_snd.ifq_len, where ifp is tap device): ... qlen 0 tap0 starting tap0 reading, minor = 0 qlen 0 tap0 starting qlen 1 tap0 starting qlen 2 tap0 starting qlen 3 tap0 starting qlen 4 tap0 starting qlen 5 tap0 starting qlen 6 tap0 starting qlen 7 tap0 starting qlen 8 tap0 starting qlen 9 tap0 starting qlen 10 tap0 starting qlen 11 tap0 starting qlen 12 tap0 starting qlen 13 tap0 starting qlen 14 tap0 starting qlen 15 tap0 starting qlen 16 tap0 starting qlen 17 tap0 starting qlen 18 tap0 starting tap0 writting, minor = 0 qlen 19 tap0 starting tap0 writting, minor = 0 tap0 writting, minor = 0 qlen 20 tap0 starting qlen 21 tap0 starting tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 qlen 22 tap0 starting qlen 23 tap0 starting qlen 24 tap0 starting qlen 25 tap0 starting qlen 26 tap0 starting qlen 27 tap0 starting qlen 28 tap0 starting qlen 29 tap0 starting qlen 30 tap0 starting qlen 31 tap0 starting qlen 32 tap0 starting qlen 33 tap0 starting qlen 34 tap0 starting qlen 35 tap0 starting qlen 36 tap0 starting qlen 37 tap0 starting qlen 38 tap0 starting qlen 39 tap0 starting qlen 40 KDB: enter: beginning tap0 starting qlen 41 tap0 starting tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 qlen 42 tap0 starting qlen 43 tap0 starting qlen 44 tap0 starting qlen 45 tap0 starting qlen 46 tap0 starting qlen 47 tap0 starting tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 tap0 writting, minor = 0 qlen 48 tap0 starting As I sad early, seems, that tapifstart doesn't wakeup tapread. I can't determine a reason of fail, because don't have experience in the freebsd kernel development. How and why this can happen, and how to fix? Please, help me.