From owner-svn-src-head@FreeBSD.ORG Fri Feb 20 08:34:12 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43E7343A; Fri, 20 Feb 2015 08:34:12 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (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 C3D967B8; Fri, 20 Feb 2015 08:34:11 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id l2so11691624wgh.9; Fri, 20 Feb 2015 00:34:10 -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=NJ65Z+1dNxZAxQIAGeBMnL8hPcnFoPizauRzM2Aiysw=; b=tzHWjydQiRIYJbFz4GnfztKGz79V7R6rvhMKjEQQalop/pd5oXVsWU0YfFIy35g8fz CKNrTp2StPYgnjgim4KCs8+omMO/6NpjeRyXBSdP1jtg4hl2VlJd2xmwbfxgioeUe2eU Nyx1uBD52c6A3fYPBmHP6wErCUDG/e6JSPiKmRAMM7OrZbqdL2+wYWs0yFvPjBaknv6a 5Oj+tjWzhuyQvL8o39t7oloQZ+o74QEVbRjvnG9SVituDKk0C+H6owGwYYR0dOp7VY87 oL/E89yn6vSSHDuTOMKX28h7Z6Ip0cfft2KXGBBpvkXoBgSd72YhJE+D4nbAtun2Uf2t eq7Q== X-Received: by 10.180.12.233 with SMTP id b9mr13540024wic.49.1424421250271; Fri, 20 Feb 2015 00:34:10 -0800 (PST) Received: from [172.16.1.30] (150.Red-81-39-62.dynamicIP.rima-tde.net. [81.39.62.150]) by mx.google.com with ESMTPSA id u18sm40975220wjq.42.2015.02.20.00.34.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Feb 2015 00:34:09 -0800 (PST) Sender: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Message-ID: <54E6F17A.4020702@FreeBSD.org> Date: Fri, 20 Feb 2015 09:34:02 +0100 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gleb Smirnoff 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 Content-Transfer-Encoding: 8bit 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: Fri, 20 Feb 2015 08:34:12 -0000 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: 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. 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: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:0a:80:c2 xenbusb_back0: 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.