From owner-svn-src-head@FreeBSD.ORG Thu Feb 19 20:15:04 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFD592A2; Thu, 19 Feb 2015 20:15:04 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75EC7C23; Thu, 19 Feb 2015 20:15:04 +0000 (UTC) Received: by pabkx10 with SMTP id kx10so2261703pab.0; Thu, 19 Feb 2015 12:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MgLHwC9Q9Z0yxCn5+dTFo87zCQMzzkGZoAbFbCKTTIg=; b=Qshi1aQy9qsFqt2S5U4OQKdd9J2DSbxTJUs/5zlIr5AsvlZ4wRbFAr4gG6cA29ySD0 v/QLwgwbB6p/RYnmXjX/ixbTQ4UxA54H1zZ26A1K9VlwJXTqpAgQJ5iSIbagYZCxNcvm 9wmh3yK11rWIqMbtPGOEanO9SFeA0Dl3BjmhHaDTMFWq1WpJrwug7fx8O4NbiqTkNI4c fd/zvlXs+JlgArj84k1J540r3s81ylfCg2PT32WdSi9KyGpYdFq8Hv8boestK+GXUvFM oKIfcWoe/hoRWBfyb0AcetUHWBv4yQbu0H/Nlqx+D/zzVKJCuf7GQ77r6TY8GdSnGJVq 10xQ== X-Received: by 10.66.233.74 with SMTP id tu10mr10462322pac.135.1424376903952; Thu, 19 Feb 2015 12:15:03 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id bw3sm24599062pbb.9.2015.02.19.12.15.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Feb 2015 12:15:02 -0800 (PST) Sender: Navdeep Parhar Message-ID: <54E64444.8030506@FreeBSD.org> Date: Thu, 19 Feb 2015 12:15:00 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff , =?windows-1252?Q?Roger_Pau_M?= =?windows-1252?Q?onn=E9?= Subject: Re: svn commit: r278977 - in head/sys: dev/cxgb dev/cxgb/sys dev/cxgb/ulp/tom dev/xen/netfront sys References: <201502190119.t1J1JhSI025601@svn.freebsd.org> <54E62FB6.6050800@FreeBSD.org> <20150219200257.GK15484@FreeBSD.org> In-Reply-To: <20150219200257.GK15484@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 20:15:04 -0000 On 02/19/15 12:02, Gleb Smirnoff wrote: > On Thu, Feb 19, 2015 at 07:47:18PM +0100, Roger Pau Monn=E9 wrote: > R> El 19/02/15 a les 2.19, Gleb Smirnoff ha escrit: > R> > Author: glebius > R> > Date: Thu Feb 19 01:19:42 2015 > R> > New Revision: 278977 > R> > URL: https://svnweb.freebsd.org/changeset/base/278977 > R> > > R> > Log: > R> > Provide a set of inline functions to manage simple mbuf(9) queue= s, based > R> > on queue(3)'s STAILQ. Utilize them in cxgb(4) and Xen, deleting= home > R> > grown implementations. > R> > > R> > Sponsored by: Netflix > R> > Sponsored by: Nginx, Inc. > R> > R> Have you tested this commit on Xen? I'm getting the following: > R> > R> xn0: at device/vif/0 on xenbusb_front0 > R> xn0: Ethernet address: 00:16:3e:51:85:e3 > R> xenbusb_back0: on xenstore0 > R> xbd0: Back-end specified ring-pages of 15 is not a power of 2. Limit= ed to 8. > R> xn0: backend features: feature-sg feature-gso-tcp4 > R> panic: no mbufs processed > R> cpuid =3D 0 > R> KDB: stack backtrace: > R> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe= 007adc3920 > R> vpanic() at vpanic+0x189/frame 0xfffffe007adc39a0 > R> kassert_panic() at kassert_panic+0x132/frame 0xfffffe007adc3a10 > R> network_alloc_rx_buffers() at network_alloc_rx_buffers+0x439/frame 0= xfffffe007adc3ac0 > R> network_connect() at network_connect+0xac1/frame 0xfffffe007adc3b50 > R> netfront_backend_changed() at netfront_backend_changed+0xed/frame 0x= fffffe007adc3b90 > R> xenwatch_thread() at xenwatch_thread+0x1a2/frame 0xfffffe007adc3bb0 > R> fork_exit() at fork_exit+0x84/frame 0xfffffe007adc3bf0 > R> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe007adc3bf0 > R> --- trap 0, rip =3D 0, rsp =3D 0xfffffe007adc3cb0, rbp =3D 0 --- > R> KDB: enter: panic > R> [ thread pid 15 tid 100038 ] > R> Stopped at kdb_enter+0x3e: movq $0,kdb_why > > I guess the problem is that the queue limit isn't initialized. Please > try the attached patch. > > The problem with older mbufq was that it doesn't have any sane limit > on it. So, converting to new, I simply put INT_MAX, which is ugly. Is mq_len supposed to count the number of mbufs in the mbufq? Then it=20 doesn't work for m_next linked chains. It pretends to enforce a cap on=20 the number of mbufs in the mbufq while doing no such thing. If it's not = trying to count the number of mbufs then I'd like to know exactly what=20 it does? Regards, Navdeep > > I'd appreciate if you fix mbufq_init()s in netfront.c to some appropria= te > values. >