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>