Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Feb 2015 12:15:00 -0800
From:      Navdeep Parhar <np@FreeBSD.org>
To:        Gleb Smirnoff <glebius@FreeBSD.org>, =?windows-1252?Q?Roger_Pau_M?= =?windows-1252?Q?onn=E9?= <royger@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r278977 - in head/sys: dev/cxgb dev/cxgb/sys dev/cxgb/ulp/tom dev/xen/netfront sys
Message-ID:  <54E64444.8030506@FreeBSD.org>
In-Reply-To: <20150219200257.GK15484@FreeBSD.org>
References:  <201502190119.t1J1JhSI025601@svn.freebsd.org> <54E62FB6.6050800@FreeBSD.org> <20150219200257.GK15484@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
> R> xn0: Ethernet address: 00:16:3e:51:85:e3
> R> xenbusb_back0: <Xen Backend Devices> 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.
>





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54E64444.8030506>