Date: Fri, 20 Feb 2015 09:34:02 +0100 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= <royger@FreeBSD.org> To: Gleb Smirnoff <glebius@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: <54E6F17A.4020702@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
El 19/02/15 a les 21.02, Gleb Smirnoff ha escrit: > On Thu, Feb 19, 2015 at 07:47:18PM +0100, Roger Pau Monné 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) queues, 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. Limited to 8. > R> xn0: backend features: feature-sg feature-gso-tcp4 > R> panic: no mbufs processed > R> cpuid = 0 > R> KDB: stack backtrace: > R> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe007adc3920 > 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 0xfffffe007adc3ac0 > R> network_connect() at network_connect+0xac1/frame 0xfffffe007adc3b50 > R> netfront_backend_changed() at netfront_backend_changed+0xed/frame 0xfffffe007adc3b90 > 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 = 0, rsp = 0xfffffe007adc3cb0, rbp = 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. > > I'd appreciate if you fix mbufq_init()s in netfront.c to some appropriate > values. Hello, I've tried the attached patch and now I get a different panic: [...] xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:0a:80:c2 xenbusb_back0: <Xen Backend Devices> on xenstore0 xbd0: Back-end specified ring-pages of 15 is not a power of 2. Limited to 8. xn0: backend features: feature-sg feature-gso-tcp4 xbd0: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff80b0c60b stack pointer = 0x28:0xfffffe0096c18960 frame pointer = 0x28:0xfffffe0096c18a30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq778: xn0) [ thread pid 12 tid 100052 ] Stopped at tcp_lro_rx+0x1b: movw 0xc(%rbx),%r15w db> bt Tracing pid 12 tid 100052 td 0xfffff80002da2940 tcp_lro_rx() at tcp_lro_rx+0x1b/frame 0xfffffe0096c18a30 xn_intr() at xn_intr+0xa12/frame 0xfffffe0096c18b30 intr_event_execute_handlers() at intr_event_execute_handlers+0xe1/frame 0xfffffe0096c18b70 ithread_loop() at ithread_loop+0xac/frame 0xfffffe0096c18bb0 fork_exit() at fork_exit+0x84/frame 0xfffffe0096c18bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0096c18bf0 --- trap 0, rip = 0, rsp = 0xfffffe0096c18cb0, rbp = 0 --- db> addr2line however seems to be unable to resolve the IP address to a line number: # addr2line -e /boot/kernel/kernel ffffffff80b0c60b ??:0 Roger.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54E6F17A.4020702>