From owner-freebsd-net@FreeBSD.ORG Sun May 17 10:49:37 2015 Return-Path: Delivered-To: freebsd-net@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 678056D5 for ; Sun, 17 May 2015 10:49:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5121D1010 for ; Sun, 17 May 2015 10:49:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HAnbEl022383 for ; Sun, 17 May 2015 10:49:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200221] em0 watchdog timeout under load Date: Sun, 17 May 2015 10:49:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: anthony@ury.org.uk X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 10:49:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221 --- Comment #4 from anthony@ury.org.uk --- Disabled tso4 on em0, not had any problems so far over two backup runs. I'll keep monitoring it, as it doesn't happen every time. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sun May 17 17:15:00 2015 Return-Path: Delivered-To: freebsd-net@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 A47E49CF for ; Sun, 17 May 2015 17:15:00 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EFB61723 for ; Sun, 17 May 2015 17:15:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HHF04M068802 for ; Sun, 17 May 2015 17:15:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Date: Sun, 17 May 2015 17:15:00 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: saper@saper.info X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 17:15:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193246 Marcin Cie=C5=9Blak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |saper@saper.info --- Comment #12 from Marcin Cie=C5=9Blak --- Thanks for excellent analysis! I ran into this one today at https://discuss.gradle.org/t/messagingservicestest-cannot-join-mcast-group-= on-freebsd-invalid-argument/9662 --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From owner-freebsd-net@FreeBSD.ORG Sun May 17 21:00:43 2015 Return-Path: Delivered-To: freebsd-net@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 623744F1 for ; Sun, 17 May 2015 21:00:43 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 39D181DB3 for ; Sun, 17 May 2015 21:00:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HL0hxn038830 for ; Sun, 17 May 2015 21:00:43 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201505172100.t4HL0hxn038830@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 17 May 2015 21:00:43 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 21:00:43 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t 3 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon May 18 00:22:24 2015 Return-Path: Delivered-To: freebsd-net@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 E0B0A3A5 for ; Mon, 18 May 2015 00:22:24 +0000 (UTC) Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41B0311A4 for ; Mon, 18 May 2015 00:22:23 +0000 (UTC) X-QQ-mid: Yesmtp34t1431908520t325t2679 Received: from C2EKPN1BD517DFX (unknown [58.23.129.114]) by esmtp4.qq.com (ESMTP) with SMTP id 0 for ; Mon, 18 May 2015 08:21:59 +0800 (CST) X-QQ-SSF: 00100000000000F0Fw12000A0000000 X-QQ-FEAT: CyjWbnmJW4+pvQ8a4g59IC/HBWKBNag1LS9FJf4gTEi1KoSk/vyM2L3ji01Ik bz5rA/NrH41BCr0mOfmqZk2lkyC7wy7ZmHTbdWc0811UKCFlHzmB3ceDEzHgRwXx/T9nNC4 a/aYV3G36dwmR1INyxbq+v9kXzxMwFdvboNklAAVm04xlAE99+S2PoKBqH1dJzFI8Na8T91 M6RcvT/SwSg== X-QQ-GoodBg: 0 Date: Mon, 18 May 2015 08:23:36 +0800 From: "jack@beyond-hk.com" To: freebsd-net Subject: RFQ X-Priority: 3 X-GUID: 10D6EAB9-499D-4895-BEB2-612553F98724 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 6, 42[cn] Mime-Version: 1.0 Message-ID: <201505180822527463610@beyond-hk.com> X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 00:22:25 -0000 DQpEZWVyIHNpcnMvTWFkYW0sDQogDQpUaGlzIGlzIEphY2sgZnJvbSBCRVlPTkQgSU1QT1JUICYg RVhQT1JUIChISylMSU1JVEVEIHNwZWNpYWxpemluZyBpbiBpbXBvcnQgYW5kIGV4cG9ydCBvZiBl bGVjdHJvbmljcyBjb21wb25lbnRzLCBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkIHRvIFRJLCBP TiwgQUQsIE5TQywgQkIsIElOVEVSU0lMICxNQVhJTSxNT1QsTFRORUFSLElEVCxBTExFR1JPLEhB UlJJUyBhbmQgb3RoZXIgYWN0aXZlIG9yIHBvc2l0aXZlIElDIHBhcnRzLg0KIA0KU2hvdWxkIGFu eSBvZiB0aGVzZSBpdGVtcyBiZSBvZiBpbnRlcmVzdCB0byB5b3UsIHBsZWFzZSBsZXQgdXMga25v dywgV2Ugd2lsbCBiZSBoYXBweSB0byBnaXZlIHlvdSBkZXRhaWxzLg0KIA0KSW4gb3VyIHRyYWRl IHdpdGggY3VzdG9tZXJzIG9mIHZhcmlvdXMgY291bnRyaWVzLCB3ZSBhbHdheXMgYWRoZXJlIHRv IHRoZSANCnByaW5jaXBsZSBvZiBlcXVhbGl0eSBhbmQgbXV0dWFsIGJlbmVmaXQuDQogDQpXZSBs b29rIGZvcndhcmQgdG8gcmVjZWl2aW5nIHlvdXIgZW5xdWlyaWVzIHNvb24uIA0KIA0KQmVzdCBy ZWdhcmRzDQpKYWNrDQoNCkJFWU9ORCBJTVBPUlQgJiBFWFBPUlQgKEhLKUxJTUlURUQNCnNreXBl o7pqYWNrXzY4NzMNClRlbDogICg4NTIpIDIyMDYgMDA5MiAgICAgIA0KRmF4OiAoODUyKSAzMDAz IDAxMzMNCkFkcmVzczogIFJvb21zIDExMDItMTEwMywxMS9GLCBLb3dsb29uIEJ1aWxkaW5nLCA1 NTUgTmF0aGFuIFJvYWQsIE1vbmdrb2ssIEtvd2xvb24sIEhvbmcgS29uZ0YNCg== From owner-freebsd-net@FreeBSD.ORG Mon May 18 02:37:34 2015 Return-Path: Delivered-To: freebsd-net@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 92D65433 for ; Mon, 18 May 2015 02:37:34 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7BEF11E21 for ; Mon, 18 May 2015 02:37:34 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4I2bYRf096848 for ; Mon, 18 May 2015 02:37:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200185] [PATCH] Deprecate net.link.tap.user_open sysctl: opening by user is based on node permissions, no need for this variable Date: Mon, 18 May 2015 02:37:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: needs-qa, patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 02:37:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200185 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon May 18 10:52:20 2015 Return-Path: Delivered-To: freebsd-net@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 5A832C4A for ; Mon, 18 May 2015 10:52:20 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (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 D86C4143B for ; Mon, 18 May 2015 10:52:19 +0000 (UTC) Received: by laat2 with SMTP id t2so212975646laa.1 for ; Mon, 18 May 2015 03:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5D9kawbZBYGz1txpU1KjTkxlLJ5BTXN/o1krNjeFayU=; b=r8BINTIwbzjzfKuJTaCG6ca9TFJ9TJ5UtcgqhOmueeeeFTDVZbzfiLtWUwLLpt4fPv xX0COuNP6de/AO6UADlFl+swmzb5W4DJdNJ8f5QjQmDYnwbEj4xxBU/k7CfRDY//IkWM x7pLLxtnWARuGsBrlm17IC2f+slM8PDGr228oOH4q3jgViMjKPtEvthrpyIQt0oomv7E iL/Z10mn8lZhmWoW6fMRBSbAsv3B0gFRrqsfCsO11W9Jp1pB3gg0L82fpg8gjus6PriD zkSsQSzOgN2R6jNp6KYvK5gxS8vM+zEjbaXMnXXKwi1TQFm7hdKhqtm6HPUQ/RBHnDkf uYCw== MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr16615224lab.119.1431946337854; Mon, 18 May 2015 03:52:17 -0700 (PDT) Received: by 10.112.58.232 with HTTP; Mon, 18 May 2015 03:52:17 -0700 (PDT) Date: Mon, 18 May 2015 16:22:17 +0530 Message-ID: Subject: Setting up the Network using GUI From: vinay saini To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 10:52:20 -0000 Hello All I am using freebsd as a voip server. And Its working perfect after setting the static IP in the /etc/rc.conf file. Now my question is, What is the best way to make it configure using browser. For example: If I give one default IP where the user can access the the configuration page and can setup there own IPs based on there requirement. It could be either DHCP or Static IP configuration. Please let me know if we have any open source project or something related to this. Thanks Vinay Saini From owner-freebsd-net@FreeBSD.ORG Mon May 18 16:35:54 2015 Return-Path: Delivered-To: freebsd-net@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 77C4055A for ; Mon, 18 May 2015 16:35:54 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 582F51129 for ; Mon, 18 May 2015 16:35:54 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4IGZsZZ013849 for ; Mon, 18 May 2015 16:35:54 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4IGZs4U013848; Mon, 18 May 2015 16:35:54 GMT (envelope-from daemon-user) Date: Mon, 18 May 2015 16:35:54 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Accepted] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFVaFOo= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 16:35:54 -0000 rodrigc accepted this revision. rodrigc added a comment. This revision has a positive review. Looks OK to me. We can hopefully fix some of the LOR's later. @glebius : can you provide your feedback on this patch? REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, glebius, kristof, gnn, rodrigc Cc: julian, robak, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon May 18 17:40:47 2015 Return-Path: Delivered-To: freebsd-net@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 9D747168 for ; Mon, 18 May 2015 17:40:47 +0000 (UTC) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 682A61939 for ; Mon, 18 May 2015 17:40:47 +0000 (UTC) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-10v.sys.comcast.net with comcast id VVg11q0092XD5SV01VgkwN; Mon, 18 May 2015 17:40:44 +0000 Received: from resmail-ch2-217v.sys.comcast.net ([162.150.48.251]) by resomta-ch2-20v.sys.comcast.net with comcast id VVgk1q00c5RAVJS01VgkXS; Mon, 18 May 2015 17:40:44 +0000 Date: Mon, 18 May 2015 17:40:44 +0000 (UTC) From: rondzierwa@comcast.net To: freebsd-net@freebsd.org Message-ID: <1759362154.14467567.1431970844614.JavaMail.zimbra@comcast.net> In-Reply-To: <693283707.14467075.1431970807422.JavaMail.zimbra@comcast.net> Subject: FCIP MIME-Version: 1.0 X-Originating-IP: [::ffff:50.241.136.195] X-Mailer: Zimbra 8.0.7_GA_6031 (ZimbraWebClient - FF28 (Win)/8.0.7_GA_6031) Thread-Topic: FCIP Thread-Index: j/0N3/91IZ1JB0mes8bg39HfsiuG3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1431970844; bh=095VVUuIm+4KLQcFFN/n35ProchwyMdQ0Vsyy2OSQYM=; h=Received:Received:Date:From:To:Message-ID:Subject:MIME-Version: Content-Type; b=EBeFh3QB2YGUYrUs9q6lY8ehKdpKNDG59Ra4iJ3wzy/XM/v+oJVlnnw8zygBcu6Jm oCRuoGiioI3k/5CPnYuHH7PJqTSuUkwiu1z5nbe6tdyNaCdwVGZAKv55J/VuS/cfUz P01P7ybGpEptd6XGpPVJ2pEqxnf9Fl4A8tqRhsAa5cEjjleRcrP4UcGcjUy5Zy4ouX dkih127NwmerGXduXA9bMtUW9w7M13TjZpwv20ESQi/D79AsM/dUe28QTCCLbf3mXN wDR8fDd7iW1VGFzJ4YqTjTM9jOVlR/41Bs1KqjBug3a2PwwkI30u9z2cMSmtJ4lNKl X9ZIEKo+RfCQQ== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 17:40:47 -0000 Does FreeBSD support IP over FiberChannel? thanks, ron. From owner-freebsd-net@FreeBSD.ORG Tue May 19 07:41:27 2015 Return-Path: Delivered-To: freebsd-net@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 2ED31F06 for ; Tue, 19 May 2015 07:41:27 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFEC91B24 for ; Tue, 19 May 2015 07:41:26 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A407120AC6 for ; Tue, 19 May 2015 03:41:24 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 19 May 2015 03:41:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=0x89.net; h= content-type:date:from:message-id:mime-version:subject:to :x-sasl-enc:x-sasl-enc; s=mesmtp; bh=CySvGkMkeT8xTrUJkb8GMjMcxsQ =; b=mCvG+4HFfqzaNvv+mxI0y5AJ+3oqVwNNBNgEmcjiAfaLiNHCNoBJbjLAfzG VUWeqOQZazybZFfr4NymbiTLlw2qxx5fs8PXqlXK0qqYuStHOWvCm+AiEen/KP3t Mm23+Zx2hZIQfWRZA8BfEVYS79XptJaAvSM5ZopuLsMLqBuU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Cy SvGkMkeT8xTrUJkb8GMjMcxsQ=; b=j5je7Tz2aaYiYmn2EKZJcq869vvhhFjc24 auR9RDWr8nVIeqDkLMIrwZViDrjKo+vrnD6Zp3RwiQa5lT2MNsJ8fAWJF0j6kHXs aj+f1FUsfK1BJKyTblQethjMcEPxVJUkGbdCiMphmJo4qtynhvHF0L+YBit7pI1A unf+uxhj4= X-Sasl-enc: VHoh+K6tF1f49Qn+dxfJUHHFeGjCUWeKsJHIm7wPMPMp 1432021284 Received: from [192.168.0.200] (unknown [98.248.32.245]) by mail.messagingengine.com (Postfix) with ESMTPA id EE51B680176 for ; Tue, 19 May 2015 03:41:23 -0400 (EDT) From: Wojciech Wojtyniak Subject: Problem with ipfw, in-kernel NAT and port redirection to jails Message-Id: Date: Tue, 19 May 2015 00:41:22 -0700 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 07:41:27 -0000 Hello, I have a vps on vultr.com running FreeBSD 10.1-p9 = and a generic kernel: % uname -a FreeBSD tzar 10.1-RELEASE-p9 FreeBSD 10.1-RELEASE-p9 #0: Tue Apr 7 = 01:09:46 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 My goal is to run multiple services in jails (hopefully using ezjail or = other convenient manager) and make them accessible from the Internet = only on arbitrary ports (like 80 for http(s) server). So far my approach = is as follows: I clone the lo0 interface and assign IP from 127.0.0.0/8 = space to the jail and redirect port in ipfw nat definition to given = address (example in configs below, I tried also with other addresses on = vtnet0, which is my base network interface, with similar issues). = Unfortunately this configuration doesn=E2=80=99t work for me. I tested this for znc (IRC bouncer) and nginx. If I run them on main = host (without NAT in front of them) everything works fine. However, if I = run them in jail, behind NAT and send a HTTP(S) request to get some = file, connections get dropped (znc has a web admin module, which is = broken because of that). It works fine for small files but breaks for = larger (I haven=E2=80=99t check the threshold but can do this if this is = necessary). For example given curl command and znc service: % curl http://$my_ip:6697/pub/jquery-1.11.2.min.js > /dev/null # (stats cut out) curl: (18) transfer closed with 58648 bytes remaining to read if I tcpdump connection, transfer looks fine for some time and then ends = with a following sequence (run on main host, jail master): % sudo tcpdump port 6697 tcpdump: verbose output suppressed, use -v or -vv for full protocol = decode listening on vtnet0, link-type EN10MB (Ethernet), capture size 65535 = bytes 23:37:28.621409 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [S], seq 3967654146, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 601353780 ecr 0,sackOK,eol], length 0 23:37:28.621468 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [S.], seq 517055725, ack 3967654147, win 65535, options [mss = 1460,nop,wscale 6,sackOK,TS val 2553669008 ecr 601353780], length 0 23:37:28.635788 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [.], ack 1, win 4117, options [nop,nop,TS val 601353791 ecr = 2553669008], length 0 23:37:28.635865 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [P.], seq 1:109, ack 1, win 4117, options [nop,nop,TS val = 601353791 ecr 2553669008], length 108 23:37:28.636122 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [P.], seq 1:18, ack 109, win 1040, options [nop,nop,TS val = 2553669022 ecr 601353791], length 17 23:37:28.650153 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [.], ack 18, win 4117, options [nop,nop,TS val 601353805 ecr = 2553669022], length 0 23:37:29.123244 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [.], seq 18:1466, ack 109, win 1040, options [nop,nop,TS val = 2553669510 ecr 601353805], length 1448 (transfer goes normally) 23:37:35.519163 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [F.], seq 37666, ack 109, win 1040, options [nop,nop,TS val = 2553675906 ecr 601360615], length 0 23:37:35.531004 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [.], ack 33322, win 4096, options [nop,nop,TS val 601360640 ecr = 2553675880], length 0 23:37:36.165352 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [.], seq 33322:34770, ack 109, win 1040, options [nop,nop,TS val = 2553676552 ecr 601360640], length 1448 23:37:36.184582 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [.], ack 34770, win 4050, options [nop,nop,TS val 601361283 ecr = 2553676552], length 0 23:37:36.801437 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [.], seq 34770:36218, ack 109, win 1040, options [nop,nop,TS val = 2553677188 ecr 601361283], length 1448 23:37:36.910742 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [.], ack 36218, win 4050, options [nop,nop,TS val 601362012 ecr = 2553677188], length 0 23:37:36.910796 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [FP.], seq 36218:37666, ack 109, win 1040, options [nop,nop,TS val = 2553677297 ecr 601362012], length 1448 23:37:36.922685 IP $my_home_host.51256 > $my_vultr_host.vultr.com.6697: = Flags [F.], seq 109, ack 37667, win 4096, options [nop,nop,TS val = 601362025 ecr 2553677297], length 0 23:37:36.922742 IP $my_vultr_host.vultr.com.6697 > $my_home_host.51256: = Flags [.], ack 110, win 1040, options [nop,nop,TS val 2553677309 ecr = 601362025], length 0 My ipfw log doesn=E2=80=99t show any rejected packages in this case. For = comparison when I run service on the main host (without NAT and port = redirection) sending transfer is longer and ending sequence looks like = follows: % sudo tcpdump port 6696 tcpdump: verbose output suppressed, use -v or -vv for full protocol = decode listening on vtnet0, link-type EN10MB (Ethernet), capture size 65535 = bytes 23:44:54.151840 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [S], seq 3928283896, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 601797509 ecr 0,sackOK,eol], length 0 23:44:54.151879 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [S.], seq 3837375255, ack 3928283897, win 65535, options [mss = 1460,nop,wscale 6,sackOK,TS val 1729228577 ecr 601797509], length 0 23:44:54.167015 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [.], ack 1, win 4117, options [nop,nop,TS val 601797522 ecr = 1729228577], length 0 23:44:54.167052 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [P.], seq 1:109, ack 1, win 4117, options [nop,nop,TS val = 601797522 ecr 1729228577], length 108 23:44:54.167508 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [P.], seq 1:18, ack 109, win 1040, options [nop,nop,TS val = 1729228593 ecr 601797522], length 17 23:44:54.167573 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [P.], seq 18:4479, ack 109, win 1040, options [nop,nop,TS val = 1729228593 ecr 601797522], length 4461 23:44:54.167585 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [P.], seq 4479:8575, ack 109, win 1040, options [nop,nop,TS val = 1729228593 ecr 601797522], length 4096 23:44:54.167599 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [P.], seq 8575:12671, ack 109, win 1040, options [nop,nop,TS val = 1729228593 ecr 601797522], length 4096 23:44:54.167611 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [.], seq 12671:14481, ack 109, win 1040, options [nop,nop,TS val = 1729228593 ecr 601797522], length 1810 23:44:54.178628 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [.], ack 14481, win 4039, options [nop,nop,TS val 601797540 ecr = 1729228593], length 0 (transfer goes normally) 23:44:54.257686 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [P.], seq 85433:96314, ack 109, win 1040, options [nop,nop,TS val = 1729228683 ecr 601797608], length 10881 23:44:54.271581 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [.], ack 86881, win 4096, options [nop,nop,TS val 601797622 ecr = 1729228683], length 0 23:44:54.271614 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [F.], seq 96314, ack 109, win 1040, options [nop,nop,TS val = 1729228697 ecr 601797622], length 0 23:44:54.276925 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [F.], seq 109, ack 96314, win 4096, options [nop,nop,TS val = 601797624 ecr 1729228683], length 0 23:44:54.276939 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [F.], seq 96314, ack 110, win 1040, options [nop,nop,TS val = 1729228703 ecr 601797624], length 0 23:44:54.286060 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [F.], seq 109, ack 96315, win 4096, options [nop,nop,TS val = 601797633 ecr 1729228697], length 0 23:44:54.286085 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [.], ack 110, win 1040, options [nop,nop,TS val 1729228712 ecr = 601797624], length 0 23:44:54.291528 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [.], ack 96315, win 4096, options [nop,nop,TS val 601797637 ecr = 1729228697], length 0 23:44:54.720336 IP $my_vultr_host.vultr.com.6696 > $my_home_host.51368: = Flags [.], ack 109, win 0, length 0 23:44:54.974955 IP $my_home_host.51368 > $my_vultr_host.vultr.com.6696: = Flags [.], ack 96315, win 4096, options [nop,nop,TS val 601798310 ecr = 1729228712], length 0 Of course file transfer in the latter case works just fine. Connections = initiated from the jail seem to work just fine (I am able to download = larger files, like distfiles to build ports).=20 I=E2=80=99m grateful for every help. I=E2=80=99m happy to fix my configs = or even change approach as long as I can achieve my goals. My configs = are included below. % cat /etc/rc.conf hostname=3D=E2=80=9Cfoobar" ifconfig_vtnet0=3D"dhcp" sshd_enable=3D"YES" static_routes=3Dlinklocal route_linklocal=3D"-net 169.254.0.0/16 -interface vtnet0" crypto_load=3DYES cryptodev_load=3DYES aesni_load=3DYES virtio_random_load=3DYES ifconfig_vtnet0_ipv6=3D"inet6 2001:aaaa:bbbb:cccc::64 prefixlen 64" rtsold_enable=3DYES ipv6_activate_all_interfaces=3DYES rtsold_flags=3D"-aF" # Firewall configuration firewall_enable=3D"Yes" firewall_script=3D"/etc/ipfw.rules" firewall_logging=3D"YES" firewall_nat_enable=3D"YES" firewall_nat_interface=3D"vtnet0" # Internal network configuration cloned_interfaces=3D"${cloned_interfaces} lo1" gateway_enable=3D"YES" # enables the gateway # (ezjail is not here as I run it with: service ezjail onestart command) % cat /etc/sysctl.conf net.inet.ip.fw.one_pass=3D0 # Allow multiple passes for packet, = necessary for fw+nat to work net.inet.ip.fw.verbose_limit=3D25 % cat /etc/ipfw.rules #!/bin/sh ipfw -q -f flush # Set rules command prefix cmd=3D"ipfw add" pif=3D"vtnet0" # interface name of NIC attached to Internet skip=3D"skipto 10000" mip=3D=E2=80=9C111.222.111.222" # public ipv4 address ipfw nat 100 config ip $mip log reset same_ports \ redirect_port tcp 127.0.66.1:6697 6697 \ redirect_port tcp 127.0.66.1:80 80=20 ipfw add 1 allow log ip from any to any via lo0 $cmd 0003 allow tcp from $my_home_ip/32 to me 22 in setup keep-state=20 $cmd 5 allow icmp6 from any to any via vtnet0 # NAT for incoming packets $cmd 100 nat 100 log ip from any to $mip in $cmd 101 check-state log $cmd 500 $skip log tcp from 127.0.0.0/8 to any out setup keep-state $cmd 501 allow log tcp from me to any out setup keep-state $cmd 502 $skip log udp from 127.0.0.0/8 to any out keep-state $cmd 503 allow log udp from me to any out keep-state $cmd 504 $skip log icmp from 127.0.0.0/8 to any out keep-state $cmd 505 allow log icmp from me to any out keep-state $cmd 506 allow log icmp6 from me to any out keep-state $cmd 610 $skip log tcp from any to me 6697 in setup keep-state $cmd 620 $skip log tcp from any to me 80 in setup keep-state $cmd 630 allow log tcp from any to me 6696 in setup keep-state # Deny rest $cmd 9998 deny log all from any to any in via $pif $cmd 9999 deny log all from any to any out via $pif $cmd 10000 nat 100 log ip4 from 127.0.0.0/8 to any out $cmd 10001 allow log ip from any to any $cmd 10002 deny log ip from any to any % cat /usr/local/etc/ezjail/znc export jail_znc_hostname=3D"znc" export jail_znc_ip=3D"lo1|127.0.66.1" # export = jail_znc_ip=3D"lo1|127.0.66.1,lo1|::6697,vtnet0|10.0.0.66,vtnet0|2001:aaaa= :bbbb:cccc::6697" #export = jail_znc_ip=3D"vtnet0|10.0.0.66/0xffffff00,vtnet0|10.0.0.66,vtnet0|2001:aa= aa:bbbb:cccc::6697" export jail_znc_rootdir=3D"/usr/jails/znc" export jail_znc_exec_start=3D"/bin/sh /etc/rc" export jail_znc_exec_stop=3D"" export jail_znc_mount_enable=3D"YES" export jail_znc_devfs_enable=3D"YES" export jail_znc_devfs_ruleset=3D"devfsrules_jail" export jail_znc_procfs_enable=3D"YES" export jail_znc_fdescfs_enable=3D"YES" export jail_znc_image=3D"" export jail_znc_imagetype=3D"" export jail_znc_attachparams=3D"" export jail_znc_attachblocking=3D"" export jail_znc_forceblocking=3D"" export jail_znc_zfs_datasets=3D"" export jail_znc_cpuset=3D"" export jail_znc_fib=3D"" export jail_znc_parentzfs=3D"" export jail_znc_parameters=3D"" export jail_znc_post_start_script=3D"" export jail_znc_retention_policy=3D"" ### Only for debugging export jail_znc_parameters=3D"allow.raw_sockets=3D1=E2=80=9D If you need any more configs or tests, please tell me. Thanks for your = help! --=20 BRs, Wojciech Wojtyniak From owner-freebsd-net@FreeBSD.ORG Tue May 19 14:33:56 2015 Return-Path: Delivered-To: freebsd-net@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 E42163D1 for ; Tue, 19 May 2015 14:33:56 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C5033144B for ; Tue, 19 May 2015 14:33:56 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JEXuS4047862 for ; Tue, 19 May 2015 14:33:56 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JEXuIe047861; Tue, 19 May 2015 14:33:56 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 14:33:56 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Subject: [Differential] [Requested Changes To] D1944: PF and VIMAGE fixes Message-ID: <830d1a185c3d30f344536a0c0e122e4e@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFVbSdQ= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 14:33:57 -0000 glebius requested changes to this revision. glebius added a comment. This revision now requires changes to proceed. Thanks a lot, Nikos. I've fixed the problem of sleeping in UMA on kldunload. It was out the scope of the patch. I also committed the first part of the patch - mutexes initialization. Nikos, can you please svn update and then arc update, so that updated patch is posted here? REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, rodrigc, glebius Cc: julian, robak, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Tue May 19 17:08:39 2015 Return-Path: Delivered-To: freebsd-net@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 40CE3ED5 for ; Tue, 19 May 2015 17:08:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BDF918CF for ; Tue, 19 May 2015 17:08:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JH8diY056451 for ; Tue, 19 May 2015 17:08:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 139387] [ipsec] Wrong lenth of PF_KEY messages in promiscuous mode Date: Tue, 19 May 2015 17:08:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 17:08:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139387 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org CC| |ae@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue May 19 22:04:21 2015 Return-Path: Delivered-To: freebsd-net@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 65DCD910; Tue, 19 May 2015 22:04:21 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0066.outbound.protection.outlook.com [65.55.169.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9494B1C85; Tue, 19 May 2015 22:04:19 +0000 (UTC) Received: from CY1PR08MB1803.namprd08.prod.outlook.com (25.162.218.25) by SN1PR0801MB1566.namprd08.prod.outlook.com (25.163.133.156) with Microsoft SMTP Server (TLS) id 15.1.160.19; Tue, 19 May 2015 22:04:11 +0000 Received: from CY1PR08MB1803.namprd08.prod.outlook.com ([25.162.218.25]) by CY1PR08MB1803.namprd08.prod.outlook.com ([25.162.218.25]) with mapi id 15.01.0160.009; Tue, 19 May 2015 22:04:11 +0000 From: "Pokala, Ravi" To: "freebsd-net@freebsd.org" , "jfv@freebsd.org" , "erj@freebsd.org" CC: "freebsd-hackers@freebsd.org" , "Lewis, Fred" , "Sundararajan, Lakshmi" Subject: Performance issues with Intel Fortville (XL710/ixl(4)) Thread-Topic: Performance issues with Intel Fortville (XL710/ixl(4)) Thread-Index: AQHQkn+7WBa4imHGwkeMI3kSTJaMlQ== Date: Tue, 19 May 2015 22:04:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [64.80.217.3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0801MB1566; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR0801MB1566; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0801MB1566; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(164054003)(5001960100002)(189998001)(5001830100001)(5001860100001)(5001770100001)(106356001)(106116001)(102836002)(2900100001)(83506001)(229853001)(36756003)(50986999)(54356999)(101416001)(64706001)(4001540100001)(86362001)(2656002)(87936001)(66066001)(2201001)(97736004)(81156007)(92566002)(40100003)(77156002)(46102003)(2501003)(4001350100001)(122556002)(68736005)(62966003)(105586002)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0801MB1566; H:CY1PR08MB1803.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 22:04:10.2974 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0801MB1566 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:04:21 -0000 Hi folks, At Panasas, we are working with the Intel XL710 40G NIC (aka Fortville), and we're seeing some performance issues w/ 11-CURRENT (r282653). Motherboard: Intel S2600KP (aka Kennedy Pass) CPU: E5-2660 v3 @ 2.6GHz (aka Haswell Xeon) (1 socket x 10 physical cores x 2 SMT threads) =3D 20 logical cores NIC: Intel XL710, 2x40Gbps QSFP, configured in 4x10Gbps mode RAM: 4x 16GB DDR4 DIMMs What we've seen so far: - TX performance is pretty consistently lower than RX performance. All numbers below are for unidrectional tests using `iperf': 10Gbps links threads/link TX Gbps RX Gbps TX/RX 1 1 9.02 9.85 91.57% 1 8 8.49 9.91 85.67% 1 16 7.00 9.91 70.63% 1 32 6.68 9.92 67.40% - With multiple active links, both TX and RX performance suffer greatly; the aggregate bandwidth tops out at about a third of the theoretical 40Gbps implied by 4x 10Gbps. 10Gbps links threads/link TX Gbps RX Gbps % of 40Gbps 4 1 13.39 13.38 33.4% - Multi-link bidirectional throughput is absolutely terrible; the aggregate is less than a tenth of the theoretical 40Gbps. 10Gbps links threads/link TX Gbps RX Gbps % of 40Gbps 4 1 3.83 2.96 9.6% / 7.4% - Occasional interrupt storm messages are seen from the IRQs associated with the NICs. Since that can impact performance, those runs were not included in the data listed above. Our questions: - How stable is ixl(4) in -CURRENT? By that, we mean both how quickly is the driver changing, and does the driver cause any system instability? - What type of performance have others been getting w/ Fortville? In 40Gbps mode? In 4x10Gbps mode? - Does anyone have any tuning parameters they can recommend for this card? - We did our testing w/ 11-CURRENT, but we will initially ship Fortville running on 10.1-RELEASE or 10.2-RELEASE. The presence of RSS - even though it is disabled by default - makes the driver back-port non-trivial. Is there an estimate on when the 11-CURRENT version of the driver (1.4.1) will get MFCed to 10-STABLE? My colleagues Lakshmi and Fred (CCed) are working on this; please make sure to include them if you have any comments. Thanks, Ravi From owner-freebsd-net@FreeBSD.ORG Wed May 20 13:27:53 2015 Return-Path: Delivered-To: freebsd-net@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 2AA5E568 for ; Wed, 20 May 2015 13:27:53 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 B7766185E for ; Wed, 20 May 2015 13:27:52 +0000 (UTC) Received: by wicmx19 with SMTP id mx19so154942458wic.0 for ; Wed, 20 May 2015 06:27:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=R321FTqNbOzUgyyAH1ABZe2+KMr+RAg8lfCv6vRmI+w=; b=EW5EV8Ym5DBxPHJBmVO0wvPV3Y0UfEHe5I/DFvukyRZO/Kznmwp8SG03rriF7kt/u8 +ubg0bp+AhpJBhzr6QHwEWGm076eMBJzGKPFLTrYAHmNAlsAd2lRHM0rOcdzUIHGqUuv iqiRZW6E1B3fpiFL1ck9UzGkbzgQEfLbm/8ZBqJlMbDVK9hA24MfudK+rLrjn5ouYVnh GqjVSnx1g+XwV9BdpA8mPuJVSafhOhCaBgemBzVxoVFhpl2/FQuS7+QRWWdsYhH/7cit /N5vmgdN/ME6sJWluEoYg45Vcs1Dgv+FxcoQCelDhjZh1S9L1kHUbN+ymR9OyiHWKsdH YVNQ== X-Gm-Message-State: ALoCoQk1KWX1jl/qr3fkO8duDB/YJ6LYOLTfVR70lPLr0YP91zvpc9OhgJXNT1Wl3HjRwWr7//9B X-Received: by 10.194.109.97 with SMTP id hr1mr62950828wjb.10.1432128465424; Wed, 20 May 2015 06:27:45 -0700 (PDT) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id gw7sm3493433wib.15.2015.05.20.06.27.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 06:27:44 -0700 (PDT) Message-ID: <555C8BC9.2080304@freebsd.org> Date: Wed, 20 May 2015 15:27:37 +0200 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Adrian Chadd , freebsd-net@freebsd.org Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> <537FB51D.2060401@verisign.com> <537FBFA4.1010902@FreeBSD.org> <53834368.6070103@verisign.com> In-Reply-To: <53834368.6070103@verisign.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="epFRD7QcQ1FxABumOFJwiRdXf3pSI0Al1" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:27:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --epFRD7QcQ1FxABumOFJwiRdXf3pSI0Al1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On 26/05/14 15:36, Julien Charbon wrote: > On 23/05/14 23:37, Navdeep Parhar wrote: >> On 05/23/14 13:52, Julien Charbon wrote: >>> On 23/05/14 14:06, Julien Charbon wrote: >>>> On 27/02/14 11:32, Julien Charbon wrote: >>>>> On 07/11/13 14:55, Julien Charbon wrote: >>>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>>>>> wrote: >>>>>>> I have put technical and how-to-repeat details in below >>>>>>> PR: >>>>>>> >>>>>>> kern/183659: TCP stack lock contention with short-lived >>>>>>> connections >>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D183659 >>>>>>> >>>>>>> We are currently working on this performance improvement >>>>>>> effort; it will impact only the TCP locking strategy not >>>>>>> the TCP stack logic itself. We will share on freebsd-net >>>>>>> the patches we made for reviewing and improvement >>>>>>> propositions; anyway this change might also require enough >>>>>>> eyeballs to avoid tricky race conditions introduction in >>>>>>> TCP stack. >>> >>> [...] >=20 > Below, just for your information, more details on context of these > changes: >=20 > o The rough consensus at BSDCan was that there is a shared interest fo= r > scalability improvement of TCP workloads with potential high rate of > connections establishment and tear-down. >=20 > o Our requirements for this task were: > - Achieve more than 100k TCP connections per second without dropping = a > single packet in reception > - Use a strategy that does not require to change all network stacks i= n > a row (TCP, UDP, RAW, etc.) > - Be able to progressively introduce better performance, leveraging > already in place mutex strategy > - Keep the TCP stack stable (obviously) For people interested about this short-lived TCP connection scalability effort, you can subscribe to the review of our latest (and biggest so far) change: Decompose TCP INP_INFO lock to increase short-lived connections scalabili= ty https://reviews.freebsd.org/D2599 The main goal of this review is ideally to start the rough discussion before BSDCan (and then discuss details in person at BSDCan), and ease tests by other people with more exotic configurations (thanks Adrian for your early tests). This patch still improves the short-lived TCP connection rate (setup and teardown) from 60k/sec to 150k/sec. My 2 cents. -- Julien --epFRD7QcQ1FxABumOFJwiRdXf3pSI0Al1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVXIvPAAoJEKVlQ5Je6dhx57MIAOvKPS+Y+6HFOIoxobowKu6C kmwNwEmgwhCPuQK58carrEkXZXgjaYmfnhiHii02qzwanwope2V+UrpfkZ4eBzdQ TT2U0U6XWbB/iOCWcaQjJKNZlryAUsFZG6U/jNj9xOK/MTF5lfeTq6l6/N6sTJ/R HZhqLcHwC3eTlEuWfiYrw6X6iKxiTbNMWCaBqT+K5CJY+rk9YGnAYKKBP/IhBRoP oP8LXo0XCcptmGzIFzAjsE3lxmLZGj/Kuk0GW1EqIhOIuqXKJF45wRSfDYxgcMZG sOabDj+242O1YQDtL+Cxj9a6UWrHFzV64oTyaA5b1pdM76p28+XdMFy0yIPd1aI= =CF03 -----END PGP SIGNATURE----- --epFRD7QcQ1FxABumOFJwiRdXf3pSI0Al1-- From owner-freebsd-net@FreeBSD.ORG Wed May 20 14:21:07 2015 Return-Path: Delivered-To: freebsd-net@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 3E03F1EF for ; Wed, 20 May 2015 14:21:07 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 1014E1EC9 for ; Wed, 20 May 2015 14:21:06 +0000 (UTC) Received: by igbsb11 with SMTP id sb11so40850936igb.0 for ; Wed, 20 May 2015 07:21:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=HXRc8RrvsbAFMurkZaGb0Xlx73idz8G9J9sIlGcfOVM=; b=cmifTzx77O/BAOKwYJATUaZm+Q9/3wowu/0YrvGxhSw508tZJmTbw/HuP/LHHn6h69 vLcG+BPPncA7UKdza03s2rFQjmUOouplGEem/WiOeV88cx2ExRzwNT3fK6aOTaslbeVr r6wMM2gommhXgMum5fRe7YpdcmXVelvgnf95ulaW7WomJ1qn9SIAZIuQbCkWdUefgUHn pAeKq7X6dc133dtX8vYmNi/bxjtzI1Au2+3zk6FaBh8D0ZWlY9gHrkw5P/m7To15cxaf kW6MiEL6mNbDiXdf1zPNSzYsc8AFx02jsa1uSGKmT+Y5ngwV7DW0xX3gb8gYcJSuAzJq 3AzA== X-Gm-Message-State: ALoCoQmZMIbRXXa4iNUVc5mGZXN5oOVbv+VGT8fDYGCKchshvkiZFn52BBSOizkWclGZGYobdbuL X-Received: by 10.43.152.204 with SMTP id kx12mr24031274icc.51.1432131178937; Wed, 20 May 2015 07:12:58 -0700 (PDT) Received: from vpn-cuboulder31-97-dhcp.colorado.edu (vpn-cuboulder31-97-dhcp.colorado.edu. [198.11.31.97]) by mx.google.com with ESMTPSA id i4sm1719218igm.2.2015.05.20.07.12.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 07:12:58 -0700 (PDT) From: Blake Caldwell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: netmap and mlx4 driver status (linux) Message-Id: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> Date: Wed, 20 May 2015 07:13:07 -0700 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:21:07 -0000 Hello, I noticed that the mlx4_en patch for netmap is LINUX/wip-patches, so = they are not enabled in the normal build process. I=E2=80=99m curious = about the status of mlx4 support? If additional work to the patches is needed, any details as to what the = issues were. Any info would be great! Thanks in advance! Blake= From owner-freebsd-net@FreeBSD.ORG Wed May 20 14:49:48 2015 Return-Path: Delivered-To: freebsd-net@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 B4601798 for ; Wed, 20 May 2015 14:49:48 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76B4D123D for ; Wed, 20 May 2015 14:49:47 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 274BC1FE023; Wed, 20 May 2015 16:49:39 +0200 (CEST) Message-ID: <555C9F30.8070405@selasky.org> Date: Wed, 20 May 2015 16:50:24 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Blake Caldwell , freebsd-net@freebsd.org, Oded Shanoon Subject: Re: netmap and mlx4 driver status (linux) References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> In-Reply-To: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:49:48 -0000 On 05/20/15 16:13, Blake Caldwell wrote: > Hello, > > I noticed that the mlx4_en patch for netmap is LINUX/wip-patches, so they are not enabled in the normal build process. I’m curious about the status of mlx4 support? > > If additional work to the patches is needed, any details as to what the issues were. > > Any info would be great! Thanks in advance! > Hi Blake, The MLX4 driver is being actively maintained in -stable and -current. Regarding netmap support for the FreeBSD MLX4 en driver, I'm not sure. Maybe Oded knows, CC'ed? Do you have a link for the patch you are referring? This there any particular use-case you are interested in? --HPS From owner-freebsd-net@FreeBSD.ORG Wed May 20 14:51:46 2015 Return-Path: Delivered-To: freebsd-net@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 7E3E291D for ; Wed, 20 May 2015 14:51:46 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40AEC1308 for ; Wed, 20 May 2015 14:51:46 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5A4C41FE023; Wed, 20 May 2015 16:51:44 +0200 (CEST) Message-ID: <555C9FAE.6030904@selasky.org> Date: Wed, 20 May 2015 16:52:30 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Blake Caldwell , freebsd-net@freebsd.org, Oded Shanoon Subject: Re: netmap and mlx4 driver status (linux) References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> <555C9F30.8070405@selasky.org> In-Reply-To: <555C9F30.8070405@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:51:46 -0000 On 05/20/15 16:50, Hans Petter Selasky wrote: > This there s/This there/Is there/ --HPS From owner-freebsd-net@FreeBSD.ORG Wed May 20 14:57:49 2015 Return-Path: Delivered-To: freebsd-net@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 558FECA5; Wed, 20 May 2015 14:57:49 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 1E4FA1391; Wed, 20 May 2015 14:57:49 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so104469186igb.1; Wed, 20 May 2015 07:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hkhd3DBxXDDo0g7jt/t1apapy5ujMOoXXjG8yvGQxhA=; b=C09ctowRUoJFO5C8rmDZXvxoVZHrnl75t7yP9UQh87mbUMdw96nzXwZ8/UXcsAtAtW GFrsgH/+Vrggc+C+JsVJRjsnrSeZeK/NXNvCqnKCO6kv3Wy6pBD7JsFmDVKtU/5oe62A qfKTxaHbrwEQywWV5MfDWQ5u/ioHeDF7J0KBdb3H9gTiB9yAViAIuilYLg5BqvbjD3P2 Vw3cAgB2bK6j6KosClU/P2kPMo9ca1kvYMqWJfSQxU9+PnkYF7hC1coX4x6k2fZlduLj aZeg9zlFGdJ74fE1lsfaAsLNPc/yCanwOvLh/hYFn4I03jC6nkPUY2tcMhu3HX/mqkPU tHXA== MIME-Version: 1.0 X-Received: by 10.43.163.129 with SMTP id mo1mr45588685icc.61.1432133868542; Wed, 20 May 2015 07:57:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 20 May 2015 07:57:48 -0700 (PDT) In-Reply-To: <555C8BC9.2080304@freebsd.org> References: <537F39DF.1090900@verisign.com> <537FB51D.2060401@verisign.com> <537FBFA4.1010902@FreeBSD.org> <53834368.6070103@verisign.com> <555C8BC9.2080304@freebsd.org> Date: Wed, 20 May 2015 07:57:48 -0700 X-Google-Sender-Auth: wI4aHP4MOrfabFMQM4W9U56qnko Message-ID: Subject: Re: TCP stack lock contention with short-lived connections From: Adrian Chadd To: Julien Charbon Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:57:49 -0000 On 20 May 2015 at 06:27, Julien Charbon wrote: > > Hi, > > On 26/05/14 15:36, Julien Charbon wrote: >> On 23/05/14 23:37, Navdeep Parhar wrote: >>> On 05/23/14 13:52, Julien Charbon wrote: >>>> On 23/05/14 14:06, Julien Charbon wrote: >>>>> On 27/02/14 11:32, Julien Charbon wrote: >>>>>> On 07/11/13 14:55, Julien Charbon wrote: >>>>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>>>>>> wrote: >>>>>>>> I have put technical and how-to-repeat details in below >>>>>>>> PR: >>>>>>>> >>>>>>>> kern/183659: TCP stack lock contention with short-lived >>>>>>>> connections >>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=183659 >>>>>>>> >>>>>>>> We are currently working on this performance improvement >>>>>>>> effort; it will impact only the TCP locking strategy not >>>>>>>> the TCP stack logic itself. We will share on freebsd-net >>>>>>>> the patches we made for reviewing and improvement >>>>>>>> propositions; anyway this change might also require enough >>>>>>>> eyeballs to avoid tricky race conditions introduction in >>>>>>>> TCP stack. >>>> >>>> [...] >> >> Below, just for your information, more details on context of these >> changes: >> >> o The rough consensus at BSDCan was that there is a shared interest for >> scalability improvement of TCP workloads with potential high rate of >> connections establishment and tear-down. >> >> o Our requirements for this task were: >> - Achieve more than 100k TCP connections per second without dropping a >> single packet in reception >> - Use a strategy that does not require to change all network stacks in >> a row (TCP, UDP, RAW, etc.) >> - Be able to progressively introduce better performance, leveraging >> already in place mutex strategy >> - Keep the TCP stack stable (obviously) > > For people interested about this short-lived TCP connection scalability > effort, you can subscribe to the review of our latest (and biggest so > far) change: > > Decompose TCP INP_INFO lock to increase short-lived connections scalability > https://reviews.freebsd.org/D2599 > > The main goal of this review is ideally to start the rough discussion > before BSDCan (and then discuss details in person at BSDCan), and ease > tests by other people with more exotic configurations (thanks Adrian for > your early tests). This patch still improves the short-lived TCP > connection rate (setup and teardown) from 60k/sec to 150k/sec. Hi! I'm using this in our testing lab at work. I get to around 105k/sec, but I think that's primarily because of other lock contention in the kernel (things doing unnecessary ioctl()s.) -adrian From owner-freebsd-net@FreeBSD.ORG Wed May 20 14:58:00 2015 Return-Path: Delivered-To: freebsd-net@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 63021D30 for ; Wed, 20 May 2015 14:58:00 +0000 (UTC) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (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 300021398 for ; Wed, 20 May 2015 14:57:59 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so136111454igb.0 for ; Wed, 20 May 2015 07:57:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=PF+/cStJNhdl3eM5VBBgklHI/icLG7TOUByKHSMG47o=; b=nNYcY4ccUUbKBqX3DDw0Znb68I9HItdvMiqv1DyZsMS0rY53teNSlI1x3+QBPA7Xns pQsgiIuNigYASBtlsOYjoMaqJxx7IgNzqkAiEa0TKO72NJcNG9CNVwalV/66m0/y0Dhj BNZcKX3GkaKlbprxdx7xiyQNAFVVwg+fZtPLk3c+ktogjq5hchdZvYLLFpcLPk3pR6nN R5VVrS8w+vJqPksYbPRHOg24PnTNP7VpKP9NeQEILrR0IuvoCScH3cJ3cvydt2Xu/IIz MxTFxC7HIMXI2rur4qwjXO60+zxMBydZtDsexeikfJmuFQ75yIBvV7UICp5/3nK2ytiR N7gA== X-Gm-Message-State: ALoCoQn+ORjhKnMRBzzcID8ere2ygQF8IboRU7rH039Z2t3RJazcasrn1/oOjhQrLByPWs1wWgoo X-Received: by 10.43.65.19 with SMTP id xk19mr47763781icb.20.1432133873021; Wed, 20 May 2015 07:57:53 -0700 (PDT) Received: from vpn-cuboulder31-97-dhcp.colorado.edu (vpn-cuboulder31-97-dhcp.colorado.edu. [198.11.31.97]) by mx.google.com with ESMTPSA id j84sm3014601ioo.3.2015.05.20.07.57.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 07:57:52 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: netmap and mlx4 driver status (linux) From: Blake Caldwell In-Reply-To: <555C9FAE.6030904@selasky.org> Date: Wed, 20 May 2015 07:58:01 -0700 Cc: freebsd-net@freebsd.org, Oded Shanoon Message-Id: <0C3708DB-35F5-4B47-B377-0BA289E9B653@colorado.edu> References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> <555C9F30.8070405@selasky.org> <555C9FAE.6030904@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:58:00 -0000 I may be confusing the matter sending this to the freebsd-net list. = Sorry=E2=80=A6 I was following a mention on netmap page that discussion = happens on the freebsd-net mailing list. Anyway my use case is specific to 1) Linux=20 2) mlx4_en 3) netmap The patch in question is this one. = https://code.google.com/p/netmap/source/browse/LINUX/wip-patches/diff--mlx= 4--20630--30200 = Thanks for your time looking at this. Regards, Blake > On May 20, 2015, at 7:52 AM, Hans Petter Selasky = wrote: >=20 > On 05/20/15 16:50, Hans Petter Selasky wrote: >> This there >=20 > s/This there/Is there/ >=20 > --HPS From owner-freebsd-net@FreeBSD.ORG Wed May 20 15:18:38 2015 Return-Path: Delivered-To: freebsd-net@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 9F974413 for ; Wed, 20 May 2015 15:18:38 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010: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 0EFF616BE for ; Wed, 20 May 2015 15:18:38 +0000 (UTC) Received: by labbd9 with SMTP id bd9so79558429lab.2 for ; Wed, 20 May 2015 08:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Vz0QBtTal2TwaQB7ukoNRv/gI7gZF/Zrh05JpzBDwPk=; b=UWP+EuFdGqiq24+CIeOOlX/VhVWVk89gJhZkAymMVNdQshmTe293zdFNqc+378IfuR EKalQCNHYe1MNWhbzLGo0qqW7Y34kN4aTS6eL5177P9F+jfr6vzh3tb6gIetkzsrGGjv 9fErzDyqPy0MvsQdsHQXpSDDDEHlQK39UP0Du5HxVj/eVPvfvboR9Tq3WhtYYXcdB9FL +rysFP0U8OB/F02SH5WG9Cy5dM4+8IV0ouYNmDds2Ep9hvhEnAJ/sm9/bD3TYesE53b5 ygYZkqorYd2eF7FEUk97Kz/Q0mC5KK7kudJZtAsq8VASvmLaJL8tbC5lrXJBLtK+ba9z kx3w== MIME-Version: 1.0 X-Received: by 10.112.173.167 with SMTP id bl7mr26179489lbc.83.1432135116107; Wed, 20 May 2015 08:18:36 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.20.232 with HTTP; Wed, 20 May 2015 08:18:36 -0700 (PDT) In-Reply-To: <555C9F30.8070405@selasky.org> References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> <555C9F30.8070405@selasky.org> Date: Wed, 20 May 2015 17:18:36 +0200 X-Google-Sender-Auth: 55nnFpCyMR0uMrHPvvfxMRdSWHo Message-ID: Subject: Re: netmap and mlx4 driver status (linux) From: Luigi Rizzo To: Hans Petter Selasky Cc: Blake Caldwell , "freebsd-net@freebsd.org" , Oded Shanoon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:18:38 -0000 hi all, the mlx4 netmap patch (for linux only) was something i did long ago when i had some mellanox hardware available, but no documentation so i had to resort to interpreting what the linux driver did. At the time i had the following performance (on PCIe v2 bus): 10G ports: tx/rx at about 7 Mpps with 64 byte packets could saturate the link with 192 or 256 byte packets 40G ports: tx/rx at about 11 Mpps with 64 byte packets max 28 Gbit/s even with 1500 byte frames I don't know if the limited performance was due to bus, firmware or lack of documentation, anyways this is not something i can or want to deal with. My understanding is that Mellanox does not release programming documentation, so the only way to have native netmap support for that card would be to have Mellanox work on that and provide a suitable patch. I do not expect more than a week's work (the typical extra code in each driver is about 500 lines, and very simple) for someone with access to documentation. Also, the patch for FreeBSD and Linux is typically very similar so once we have a driver for one, the other would be trivial. It would be of course great to add Mellanox to the list of devices with native netmap support, together with Chelsio and Intel. Perhaps Hans (who may have contacts) can talk to the right people and figure out. On my side, I am happy to give directions on what needs to be done and import any patch that should be made available. cheers luigi On Wed, May 20, 2015 at 4:50 PM, Hans Petter Selasky wrote: > On 05/20/15 16:13, Blake Caldwell wrote: > >> Hello, >> >> I noticed that the mlx4_en patch for netmap is LINUX/wip-patches, so they >> are not enabled in the normal build process. I'm curious about the status >> of mlx4 support? >> >> If additional work to the patches is needed, any details as to what the >> issues were. >> >> Any info would be great! Thanks in advance! >> >> > Hi Blake, > > The MLX4 driver is being actively maintained in -stable and -current. > Regarding netmap support for the FreeBSD MLX4 en driver, I'm not sure. > Maybe Oded knows, CC'ed? Do you have a link for the patch you are referring? > > This there any particular use-case you are interested in? > > --HPS > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Wed May 20 16:35:12 2015 Return-Path: Delivered-To: freebsd-net@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 D9E074B1 for ; Wed, 20 May 2015 16:35:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C47CA114F for ; Wed, 20 May 2015 16:35:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KGZC1Q014409 for ; Wed, 20 May 2015 16:35:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200319] Bridge+CARP crashes/freezes Date: Wed, 20 May 2015 16:35:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:35:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed May 20 16:37:21 2015 Return-Path: Delivered-To: freebsd-net@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 2530C822 for ; Wed, 20 May 2015 16:37:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 100E21196 for ; Wed, 20 May 2015 16:37:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KGbKtD015070 for ; Wed, 20 May 2015 16:37:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200321] [ip] [pf] pfSync generates demotion events to carp when not needed Date: Wed, 20 May 2015 16:37:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc keywords short_desc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:37:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200321 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-net@FreeBSD.org Keywords| |patch Summary|pfSync generates demotion |[ip] [pf] pfSync generates |events to carp when not |demotion events to carp |needed |when not needed Assignee|freebsd-bugs@FreeBSD.org |freebsd-pf@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Wed May 20 16:38:08 2015 Return-Path: Delivered-To: freebsd-net@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 B2AFD950 for ; Wed, 20 May 2015 16:38:08 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E1D811B2 for ; Wed, 20 May 2015 16:38:08 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KGc8ip015362 for ; Wed, 20 May 2015 16:38:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200323] BPF userland misuse can crash the system Date: Wed, 20 May 2015 16:38:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:38:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200323 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Wed May 20 23:53:29 2015 Return-Path: Delivered-To: freebsd-net@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 40FE7AC for ; Wed, 20 May 2015 23:53:29 +0000 (UTC) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 CD947197E for ; Wed, 20 May 2015 23:53:28 +0000 (UTC) Received: by wicmx19 with SMTP id mx19so2757089wic.0 for ; Wed, 20 May 2015 16:53:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=nkn7DXxZhZu5Lj9W1pv0xz/L5FBCD/w94hHcM6zOaMQ=; b=ff9QA7OVTD7OrgUY7cL8W5rwK2y55vq9wzeFarppnLOCQhCsJcKZ+SbOHNA7OiO+zk Iv2TehnR1zg6lCiS4f3dAT0+u9bYlPTp0oLBkPOmNWItInmRUYxk3KXq5V4iJC5xAZ6B 1th+Imx+GTFMMm5oQ+CQwC7gjkIfWea2tTbmzni6ab7t3oLy/8vC49t8+jqbFe6YLMYM STUMiSQXRZy4u/5d7qNP9KJWI2bCeWJtYzw3Ua3t0WIIV1l+pFJ+pHg8vN3yGpGz/Faj vlcfTz+51SGub4jq7nZ0rtl8gfvyw7dIo4T6xqUSxmls9YwDpXhqMiA+W9W3WbO/bJEI jQJQ== X-Gm-Message-State: ALoCoQnr10v0DM/Y23ZKbW7iUMiw04Lumt5c4Iyb5X0OXf+/XJHHUeDadZ8BkwUNU1vrZhvZG3Eg X-Received: by 10.194.5.74 with SMTP id q10mr68928830wjq.27.1432166001511; Wed, 20 May 2015 16:53:21 -0700 (PDT) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id 9sm29230040wjr.11.2015.05.20.16.53.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 16:53:20 -0700 (PDT) Message-ID: <555D1E67.6090108@freebsd.org> Date: Thu, 21 May 2015 01:53:11 +0200 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Adrian Chadd CC: FreeBSD Net Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> <537FB51D.2060401@verisign.com> <537FBFA4.1010902@FreeBSD.org> <53834368.6070103@verisign.com> <555C8BC9.2080304@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0EgAKMmkr6i04pt5gn7Ko509NsudC6ALP" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 23:53:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0EgAKMmkr6i04pt5gn7Ko509NsudC6ALP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 20/05/15 16:57, Adrian Chadd wrote: > On 20 May 2015 at 06:27, Julien Charbon wrote: >> On 26/05/14 15:36, Julien Charbon wrote: >> [...] >> >> For people interested about this short-lived TCP connection scalabili= ty >> effort, you can subscribe to the review of our latest (and biggest so >> far) change: >> >> Decompose TCP INP_INFO lock to increase short-lived connections scalab= ility >> https://reviews.freebsd.org/D2599 >> >> The main goal of this review is ideally to start the rough discussion= >> before BSDCan (and then discuss details in person at BSDCan), and ease= >> tests by other people with more exotic configurations (thanks Adrian f= or >> your early tests). This patch still improves the short-lived TCP >> connection rate (setup and teardown) from 60k/sec to 150k/sec. >=20 > I'm using this in our testing lab at work. I get to around 105k/sec, > but I think that's primarily because of other lock contention in the > kernel (things doing unnecessary ioctl()s.) Nice, always good to see other people running/testing changes. On pure number size, I would add that benchmarks are basically lies [:)] as you get highest numbers from ideal conditions that are never met in production. Then, more interesting(/less lie) part is the relative improvement you get using the exact same setup and for us it is currently from 60k/sec to 150k/sec. As example, on our older hardware/older configuration it was from 35k/sec to 105k/sec. My 2 cents. -- Julien --0EgAKMmkr6i04pt5gn7Ko509NsudC6ALP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVXR5vAAoJEKVlQ5Je6dhxI5AIAKGEBkWvYu9J5dgfANHnddP1 Zh7NvxB424DSaIP1zM7D5EcH2OFQ/bkfDCsrR2mxDcJrsTNHo8VpzSJD751zy+aU FVIXvKdAgCADQW3YVW9wimtufbLH+XNrLRJpqJ6s97ZxOp/qPOeMRJ2DiYwsIgr8 37nJQdohknU9fAe0Q1wAVK7oxVp9ZEM8XbPVYjIPAglLZoMeDsBzurAwWg0REg96 J4q6B1L2poiTQ704IpCYul5k2wIQmGQgG4McTxN3XEcXy1zAEZN1z9W0JSupyqZq 7zgANH5FcjpaUQdiNXVaDHC4GklDQLao462ze4vTNcVBK48G5dWxjD8XdB7Xbvg= =+Sqi -----END PGP SIGNATURE----- --0EgAKMmkr6i04pt5gn7Ko509NsudC6ALP-- From owner-freebsd-net@FreeBSD.ORG Thu May 21 02:41:27 2015 Return-Path: Delivered-To: freebsd-net@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 661D3C17 for ; Thu, 21 May 2015 02:41:27 +0000 (UTC) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 2D5D41D0B for ; Thu, 21 May 2015 02:41:27 +0000 (UTC) Received: by oihd6 with SMTP id d6so7571602oih.2 for ; Wed, 20 May 2015 19:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Nbhug0Q6FZ3ygg6CP7zm9gExeyf3ih5gvyZufmzxKvg=; b=uRfiNldFRc1nvzFLRQu0OVSqwrruFgBJTNK6LvQNLlnsKXLkAmRLPmebzsegwBKtpx OPHCQCL0PrMkxoLaUvw36jAhHkZ3tnNh8CFbfqOZ8Q+suPAOfdu87pS9Nh1q6iB1pDSP xk6z3zKco0j/H2LELyIWNeQv3X8m0evStBK6Afuzft1WilCRjFqzlm5DI4ibLYwPax9T HVh4zO/nm3iU4rqfwQios4uLR6BW0lfjPCtrPKdOVpLyGUeW9wZaSljxQ0oMkFXJf8Kb 1N8ecY74SMsWAxLEJm80qL63reu/Et9gOaTexNrvZMKQMuRcgPW1JOdu2QKw4qnsseJL ye0w== MIME-Version: 1.0 X-Received: by 10.60.128.130 with SMTP id no2mr394675oeb.70.1432176086387; Wed, 20 May 2015 19:41:26 -0700 (PDT) Received: by 10.202.216.3 with HTTP; Wed, 20 May 2015 19:41:26 -0700 (PDT) Date: Thu, 21 May 2015 05:41:26 +0300 Message-ID: Subject: New CC modules not loading after Kernel recompilation From: Karlis Laivins To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:41:27 -0000 Good Morning, I have a following issue, maybe someone has encountered this and can provide me with a quick solution to a following issue. I have compiled a module, which is a modified version of the NewReno congestion control algorithm. I tried to load it into Kernel successfully before I recompiled Kernel with a following config file, so I can use Imunes and test the new module: include GENERIC nooptions FLOWTABLE options VIMAGE options VNET_DEBUG options MROUTING options IPSEC device crypto options IPSEC_DEBUG options DDB options KDB The problem is - after the Kernel has been reompiled, I can no longer load the module with kldload. The error I get is: link_elf: symbol tcp_do_rfc3465 undefined kldload: can't load cc_changedreno.ko: No such file or directory And this is despite the fact the cc_changedreno.ko module is in /boot/kernel/. Thank you in advance! BR, Karlis From owner-freebsd-net@FreeBSD.ORG Thu May 21 04:31:01 2015 Return-Path: Delivered-To: freebsd-net@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 630356AB for ; Thu, 21 May 2015 04:31:01 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 2E3261A17 for ; Thu, 21 May 2015 04:31:01 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so652037igb.1 for ; Wed, 20 May 2015 21:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YI/jz3X0l201dKvId6b7/O5R6ulP1DnBY3ygjURA2E0=; b=WKbK03m0iMLGQeuojfclSmaVwQ49/S40tbzVCu0n/2XVa9VKA02D4qw1ecwpGv2WlF UIH7H7hwxe2n9MsN03UM0Oz8rb6wEAlyaVejd4dGm7YMbaMep8y4q565CF2/bF2813Go //igNU7/VxqTCBhpmeegpPaYfjSL5KGNal/Nru+Ul1W6Nn70AVTkeIzaAHzCmsM1mxR8 /df0lrA6xu+/4fokxiKdNRc9EQPG7bUZ4gXvQSL1u10YCIsJP6AbN4hGbB5Z66Rcqzca p+zvTdQbmvzm5hoy2vgMd8Wp+0mcofgQ+oCp64j8QTzZU9/F/o8e4cr6LabReiXWeZVV U7fA== MIME-Version: 1.0 X-Received: by 10.50.114.9 with SMTP id jc9mr18089655igb.49.1432182660598; Wed, 20 May 2015 21:31:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 20 May 2015 21:30:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 May 2015 21:30:59 -0700 X-Google-Sender-Auth: KX9HPzh5rBLVt9uUqX4DEcYLhIg Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: Adrian Chadd To: Karlis Laivins Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 04:31:01 -0000 Hi, Try kldxref /boot/kernel If it doesn't help, try recompiling the module. -a On 20 May 2015 at 19:41, Karlis Laivins wrote: > Good Morning, > > I have a following issue, maybe someone has encountered this and can > provide me with a quick solution to a following issue. > > I have compiled a module, which is a modified version of the NewReno > congestion control algorithm. I tried to load it into Kernel successfully > before I recompiled Kernel with a following config file, so I can use > Imunes and test the new module: > > include GENERIC > nooptions FLOWTABLE > options VIMAGE > options VNET_DEBUG > options MROUTING > > options IPSEC > device crypto > options IPSEC_DEBUG > > options DDB > options KDB > > The problem is - after the Kernel has been reompiled, I can no longer load > the module with kldload. The error I get is: > > link_elf: symbol tcp_do_rfc3465 undefined > kldload: can't load cc_changedreno.ko: No such file or directory > > And this is despite the fact the cc_changedreno.ko module is in > /boot/kernel/. > > Thank you in advance! > > BR, > Karlis > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 21 04:31:03 2015 Return-Path: Delivered-To: freebsd-net@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 0225F6AC for ; Thu, 21 May 2015 04:31:03 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2F5D1A18 for ; Thu, 21 May 2015 04:31:02 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 9A12011112D; Wed, 20 May 2015 21:30:56 -0700 (PDT) Date: Wed, 20 May 2015 21:30:56 -0700 From: hiren panchasara To: Karlis Laivins Cc: freebsd-net@freebsd.org Subject: Re: New CC modules not loading after Kernel recompilation Message-ID: <20150521043056.GD95600@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9UV9rz0O2dU/yYYn" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 04:31:03 -0000 --9UV9rz0O2dU/yYYn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 05/21/15 at 05:41P, Karlis Laivins wrote: > Good Morning, >=20 > I have a following issue, maybe someone has encountered this and can > provide me with a quick solution to a following issue. >=20 > I have compiled a module, which is a modified version of the NewReno > congestion control algorithm. I tried to load it into Kernel successfully > before I recompiled Kernel with a following config file, so I can use > Imunes and test the new module: >=20 > include GENERIC > nooptions FLOWTABLE > options VIMAGE > options VNET_DEBUG > options MROUTING >=20 > options IPSEC > device crypto > options IPSEC_DEBUG >=20 > options DDB > options KDB >=20 > The problem is - after the Kernel has been reompiled, I can no longer load > the module with kldload. The error I get is: >=20 > link_elf: symbol tcp_do_rfc3465 undefined Does the module itself build fine? Do you need V_tcp_do_rfc3465 instead? It's a VNETified variable: tcp_var.h:VNET_DECLARE(int, tcp_do_rfc3465); Just a guess. Cheers, Hiren > kldload: can't load cc_changedreno.ko: No such file or directory >=20 > And this is despite the fact the cc_changedreno.ko module is in > /boot/kernel/. >=20 > Thank you in advance! >=20 > BR, > Karlis > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --9UV9rz0O2dU/yYYn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVXV+AXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lmLoH/RzNEpOciodyzJtwDPC0WvNQ a4ygBNuh2B6POs96IwdE5KFYSLchYrsepdA1XzXcD8VHsYORUlZbDvPsGl1tTZbw buPBUQ//GOX2k/aV/7RxdCdpTAm30V/wRofhafFzN66IpqJ+/Dgme5Y/zeswSpb+ GCIKznNjtpvwExFLRbTmG1MSW7zrJ23UtfWN42EzCahVRRUoFRfPpubGRmUIiU9L KrQPy2wiqtSM1aYpFX0EQB/JWR/IcSPCMweacj2CeBrIzbuetRsosbJQFhc2UguO 90r/lwdpJI5YaMgjdyUpq1X+ZMHTfvJhgIUgp563m0jqiQBI5a5FPdbuIF8IZAs= =q3i6 -----END PGP SIGNATURE----- --9UV9rz0O2dU/yYYn-- From owner-freebsd-net@FreeBSD.ORG Thu May 21 07:53:02 2015 Return-Path: Delivered-To: freebsd-net@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 5363C9BF for ; Thu, 21 May 2015 07:53:02 +0000 (UTC) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 10B8B1111 for ; Thu, 21 May 2015 07:53:02 +0000 (UTC) Received: by ykec202 with SMTP id c202so23971738yke.2 for ; Thu, 21 May 2015 00:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xZV1M4FOKTDQYB6g6sm+TVjKYyvyHKV0nqEX8MS9QlI=; b=Keo8w1MdOZiE9oNpPXwg978QIBZgOCwCqJm5LGqWT5M5rgdyYxCfrgDxBQguUY7/wA 1mzvm/w/2BvR2YtfdYR05ZThNFAoNeKDsSVxPPHRuvla6Jq5bRFxv8qWAJW6ASRsvv/M 3Of/Djlmj4zyNLYxvIA4ArDzSgB/z92X4z4dxd1TVTxdm4vU+ipDVfkRLEfuEbu4Jr6B Soev+LrVK8OoWgs1BWcgA/kJCJxKJNTr5qAuTlEagNhJyQdZwhe7IzodyCuyzb2xZuBT sgQRSS4KBta98Z70o+9l22VF0/orQKyVOXX2UvpslDgVB0xI17WLfTTr5qfXe4yLr7po QHSQ== MIME-Version: 1.0 X-Received: by 10.236.40.79 with SMTP id e55mr1515566yhb.65.1432194781244; Thu, 21 May 2015 00:53:01 -0700 (PDT) Received: by 10.129.115.197 with HTTP; Thu, 21 May 2015 00:53:00 -0700 (PDT) In-Reply-To: <20150521043056.GD95600@strugglingcoder.info> References: <20150521043056.GD95600@strugglingcoder.info> Date: Thu, 21 May 2015 10:53:00 +0300 Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: Karlis Laivins To: hiren panchasara Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:53:02 -0000 Hi, Yes, the module builds fine and the variable is needed. BR, KL On Thu, May 21, 2015 at 7:30 AM, hiren panchasara < hiren@strugglingcoder.info> wrote: > On 05/21/15 at 05:41P, Karlis Laivins wrote: > > Good Morning, > > > > I have a following issue, maybe someone has encountered this and can > > provide me with a quick solution to a following issue. > > > > I have compiled a module, which is a modified version of the NewReno > > congestion control algorithm. I tried to load it into Kernel successfully > > before I recompiled Kernel with a following config file, so I can use > > Imunes and test the new module: > > > > include GENERIC > > nooptions FLOWTABLE > > options VIMAGE > > options VNET_DEBUG > > options MROUTING > > > > options IPSEC > > device crypto > > options IPSEC_DEBUG > > > > options DDB > > options KDB > > > > The problem is - after the Kernel has been reompiled, I can no longer > load > > the module with kldload. The error I get is: > > > > link_elf: symbol tcp_do_rfc3465 undefined > Does the module itself build fine? Do you need V_tcp_do_rfc3465 instead? > It's a VNETified variable: tcp_var.h:VNET_DECLARE(int, tcp_do_rfc3465); > > Just a guess. > > Cheers, > Hiren > > kldload: can't load cc_changedreno.ko: No such file or directory > > > > And this is despite the fact the cc_changedreno.ko module is in > > /boot/kernel/. > > > > Thank you in advance! > > > > BR, > > Karlis > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 21 07:54:20 2015 Return-Path: Delivered-To: freebsd-net@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 5CAE9A69; Thu, 21 May 2015 07:54:20 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (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 1A3B41126; Thu, 21 May 2015 07:54:20 +0000 (UTC) Received: by yhom41 with SMTP id m41so19019804yho.1; Thu, 21 May 2015 00:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sMSI6HHLVAxSI9gHrRs9WxJup/p0bNNg7RKNHn+Zdsc=; b=GN1xBoAq7ossCj6OxDk7ZNLOpPX1ITTZFKERmd5iDlZXxQ/PWQ+U411vGUhHIiK0zV GRDuQ90O7xBhprVLZp7EHwDQWBy8KmZS/mrY03g+Ku1rClTDAo6WxwOutYRYKpRCmKvA mioI2ESv3B+QQRyrLYyZ+xDvtYmMCauPGlkmihprMhpRd/Pzc1wHfgryAKZs2h0yNMUB zwb2ulp0Fob5UCSo6ix6PH/yJWqBxmETOfUBEAwE2weqO9SenYiGT9rrzqCRIKcPqp8p JDuHKtuC28ThIY+h/dX+uulKRf/11cy9W1HYUHPDb84EkEZR/C7pSBx06LE3XM5hPys3 F8tw== MIME-Version: 1.0 X-Received: by 10.236.109.36 with SMTP id r24mr1519141yhg.113.1432194859237; Thu, 21 May 2015 00:54:19 -0700 (PDT) Received: by 10.129.115.197 with HTTP; Thu, 21 May 2015 00:54:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 10:54:19 +0300 Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: Karlis Laivins To: Adrian Chadd Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 07:54:20 -0000 Hello, Tried both, still the same issue... BR, KL On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd wrote: > Hi, > > Try kldxref /boot/kernel > > If it doesn't help, try recompiling the module. > > > -a > > > On 20 May 2015 at 19:41, Karlis Laivins wrote: > > Good Morning, > > > > I have a following issue, maybe someone has encountered this and can > > provide me with a quick solution to a following issue. > > > > I have compiled a module, which is a modified version of the NewReno > > congestion control algorithm. I tried to load it into Kernel successfully > > before I recompiled Kernel with a following config file, so I can use > > Imunes and test the new module: > > > > include GENERIC > > nooptions FLOWTABLE > > options VIMAGE > > options VNET_DEBUG > > options MROUTING > > > > options IPSEC > > device crypto > > options IPSEC_DEBUG > > > > options DDB > > options KDB > > > > The problem is - after the Kernel has been reompiled, I can no longer > load > > the module with kldload. The error I get is: > > > > link_elf: symbol tcp_do_rfc3465 undefined > > kldload: can't load cc_changedreno.ko: No such file or directory > > > > And this is despite the fact the cc_changedreno.ko module is in > > /boot/kernel/. > > > > Thank you in advance! > > > > BR, > > Karlis > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 21 09:59:27 2015 Return-Path: Delivered-To: freebsd-net@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 D4E6591F for ; Thu, 21 May 2015 09:59:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B615512A9 for ; Thu, 21 May 2015 09:59:27 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4L9xRLt095352 for ; Thu, 21 May 2015 09:59:27 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4L9xRbI095351; Thu, 21 May 2015 09:59:27 GMT (envelope-from daemon-user) Date: Thu, 21 May 2015 09:59:27 +0000 To: freebsd-net@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: <09d4bc9974b7e44767a237060a187633@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFVdrH8= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 09:59:27 -0000 nvass-gmx.com added a comment. In https://reviews.freebsd.org/D1944#47915, @glebius wrote: > Thanks a lot, Nikos. > > I've fixed the problem of sleeping in UMA on kldunload. It was out the scope of the patch. I also committed the first part of the patch - mutexes initialization. > > Nikos, can you please svn update and then arc update, so that updated patch is posted here? Sure, I am currently on vacation. I think I will make some time soon to update it. REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, rodrigc, glebius Cc: julian, robak, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu May 21 10:53:12 2015 Return-Path: Delivered-To: freebsd-net@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 41593B4D; Thu, 21 May 2015 10:53:12 +0000 (UTC) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (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 F3102198D; Thu, 21 May 2015 10:53:11 +0000 (UTC) Received: by yhom41 with SMTP id m41so19945774yho.1; Thu, 21 May 2015 03:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=64bmc55FqAoq5djF4vqi4d0tusUFM/Xy9u9MyK5ZY0Y=; b=IaCAbbIlQObRCTqdgUZoxLC+tTCNCzdPdb+RGeSQqmL5+5ywKYUHYzfv0fxOS2yCn3 I3/7mO/DfDLNyfdCN22d/d6zdItDqTH1QEHLOqfaPf6xUjDboFYLteZVEYd88DTOTT2D xLJOvfvKAXOMROKFlgNlvKj9fzPk1ychdQpVCDmtK4ppVVtdLthHkmUO7wYTDbFLt6OY WHEf+KmhjpkVrVJUN5hPxbUV5O1VTyXPy0ptdoThtAby3/FzKS7p/R+wRLZgR6m3XVNY fE2CqofbzLuv43jIpZnmK5IbaPBgozouJW3SorHamtOkfF4ubtrlHYLgG+0AZ0K51D2J QeKA== MIME-Version: 1.0 X-Received: by 10.236.40.79 with SMTP id e55mr2099203yhb.65.1432205591003; Thu, 21 May 2015 03:53:11 -0700 (PDT) Received: by 10.129.115.197 with HTTP; Thu, 21 May 2015 03:53:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 13:53:10 +0300 Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: Karlis Laivins To: Adrian Chadd Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 10:53:12 -0000 Hello again, A little update - the problem occurs only when trying to load a modified NewReno algorithm module. When I create a dummy module from, for example, Vegas implementation (with some trivial changes made besides the function and module names), the module can be loaded successfully. Is there a way (if no other way can be found to fix this right away), to trick the system into using my NewReno module instead of the one hard coded in the system? (I know, sounds silly - change the hard coded settings, but, maybe there is a way...) Thank you in advance! BR, Karlis On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins wrote: > Hello, > > Tried both, still the same issue... > > BR, > KL > > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd wrote: > >> Hi, >> >> Try kldxref /boot/kernel >> >> If it doesn't help, try recompiling the module. >> >> >> -a >> >> >> On 20 May 2015 at 19:41, Karlis Laivins wrote: >> > Good Morning, >> > >> > I have a following issue, maybe someone has encountered this and can >> > provide me with a quick solution to a following issue. >> > >> > I have compiled a module, which is a modified version of the NewReno >> > congestion control algorithm. I tried to load it into Kernel >> successfully >> > before I recompiled Kernel with a following config file, so I can use >> > Imunes and test the new module: >> > >> > include GENERIC >> > nooptions FLOWTABLE >> > options VIMAGE >> > options VNET_DEBUG >> > options MROUTING >> > >> > options IPSEC >> > device crypto >> > options IPSEC_DEBUG >> > >> > options DDB >> > options KDB >> > >> > The problem is - after the Kernel has been reompiled, I can no longer >> load >> > the module with kldload. The error I get is: >> > >> > link_elf: symbol tcp_do_rfc3465 undefined >> > kldload: can't load cc_changedreno.ko: No such file or directory >> > >> > And this is despite the fact the cc_changedreno.ko module is in >> > /boot/kernel/. >> > >> > Thank you in advance! >> > >> > BR, >> > Karlis >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Thu May 21 13:33:25 2015 Return-Path: Delivered-To: freebsd-net@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 35DE1F14 for ; Thu, 21 May 2015 13:33:25 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 F11191E11 for ; Thu, 21 May 2015 13:33:24 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so10033079igb.0 for ; Thu, 21 May 2015 06:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=QjvrX+561hiWYjb4Yw7Ef+TUXRJOE5j4qCZm7f1N/DQ=; b=tVhzaCTbUd9b+6NDvzEvvdjEzXYusxRRFysvTvffplfcEuOSJNREa3ijXs2CfDT6T1 doY1R1YSNaPTEoK2hxF3Zm/OuNbRov4wzXhvRRKQkX3x47hQLa6OGnD3gxjzG3bQDskD ZsmVnSFkO6/Q52gpVElzKk+NdwjVyeUAVMLYgEpnY7XLEjQmRE5ZmwfirajXHrm3R+Uc gETfUEq1HNhx1m3u2PpKR58RjvmAdmzeACH7RBiVnxuInxjyl+1N9edczQgUZkWpsylP 7yxGvUHlCnDCZZPsOpCZIfq6/uE+2/ncPcf0iQH4QRdspgw9yDJO+6XUD5RLZtxECpVC 8lhw== X-Received: by 10.43.5.74 with SMTP id of10mr3262661icb.67.1432215204407; Thu, 21 May 2015 06:33:24 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by mx.google.com with ESMTPSA id h138sm14902915ioe.2.2015.05.21.06.33.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 06:33:23 -0700 (PDT) From: Guy Helmer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD 9.3 - Intel X520-SR2 stops passing packets Message-Id: Date: Thu, 21 May 2015 08:33:31 -0500 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:33:25 -0000 I=E2=80=99ve noticed that there have been reports of problems with Intel = X520-SR2 network interfaces stopping working. I think I=E2=80=99m seeing = a similar issue where the 10Gb interfaces stop receiving traffic = (they=E2=80=99re being used in promiscuous mode to sniff traffic from a = tap). ifconfig shows the interfaces are still active and the links are = OK. ifconfig down/up restores activity. I=E2=80=99ve changed = hw.intr_storm_threshold=3D8000 but I couldn=E2=80=99t tell if the = interrupt storm threshold had been triggered at the time the interfaces = stopped passing traffic. Output from sysctl: # sysctl dev.ix.0 dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - = 2.5.15 dev.ix.0.%driver: ix dev.ix.0.%location: slot=3D0 function=3D0 dev.ix.0.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 = subdevice=3D0x0003 class=3D0x020000 dev.ix.0.%parent: pci4 dev.ix.0.fc: 0 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.link_irq: 3 dev.ix.0.queue0.interrupt_rate: 500000 dev.ix.0.queue0.irqs: 454449470 dev.ix.0.queue0.txd_head: 0 dev.ix.0.queue0.txd_tail: 0 dev.ix.0.queue0.tso_tx: 0 dev.ix.0.queue0.no_tx_dma_setup: 0 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 0 dev.ix.0.queue0.rxd_head: 1437 dev.ix.0.queue0.rxd_tail: 1436 dev.ix.0.queue0.rx_packets: 547499168 dev.ix.0.queue0.rx_bytes: 87201112584 dev.ix.0.queue0.rx_copies: 7934870 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 500000 dev.ix.0.queue1.irqs: 466235043 dev.ix.0.queue1.txd_head: 0 dev.ix.0.queue1.txd_tail: 0 dev.ix.0.queue1.tso_tx: 0 dev.ix.0.queue1.no_tx_dma_setup: 0 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 0 dev.ix.0.queue1.rxd_head: 277 dev.ix.0.queue1.rxd_tail: 276 dev.ix.0.queue1.rx_packets: 547668680 dev.ix.0.queue1.rx_bytes: 86205679601 dev.ix.0.queue1.rx_copies: 7846653 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 500000 dev.ix.0.queue2.irqs: 473958473 dev.ix.0.queue2.txd_head: 0 dev.ix.0.queue2.txd_tail: 0 dev.ix.0.queue2.tso_tx: 0 dev.ix.0.queue2.no_tx_dma_setup: 0 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 0 dev.ix.0.queue2.rxd_head: 576 dev.ix.0.queue2.rxd_tail: 575 dev.ix.0.queue2.rx_packets: 555704840 dev.ix.0.queue2.rx_bytes: 87294164455 dev.ix.0.queue2.rx_copies: 8297211 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 500000 dev.ix.0.queue3.irqs: 477587504 dev.ix.0.queue3.txd_head: 0 dev.ix.0.queue3.txd_tail: 0 dev.ix.0.queue3.tso_tx: 0 dev.ix.0.queue3.no_tx_dma_setup: 0 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 0 dev.ix.0.queue3.rxd_head: 267 dev.ix.0.queue3.rxd_tail: 266 dev.ix.0.queue3.rx_packets: 559921557 dev.ix.0.queue3.rx_bytes: 86832161258 dev.ix.0.queue3.rx_copies: 7918011 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 500000 dev.ix.0.queue4.irqs: 558339677 dev.ix.0.queue4.txd_head: 0 dev.ix.0.queue4.txd_tail: 0 dev.ix.0.queue4.tso_tx: 0 dev.ix.0.queue4.no_tx_dma_setup: 0 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 0 dev.ix.0.queue4.rxd_head: 1240 dev.ix.0.queue4.rxd_tail: 1239 dev.ix.0.queue4.rx_packets: 646909190 dev.ix.0.queue4.rx_bytes: 87117307815 dev.ix.0.queue4.rx_copies: 7944848 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 500000 dev.ix.0.queue5.irqs: 467836647 dev.ix.0.queue5.txd_head: 0 dev.ix.0.queue5.txd_tail: 0 dev.ix.0.queue5.tso_tx: 0 dev.ix.0.queue5.no_tx_dma_setup: 0 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 0 dev.ix.0.queue5.rxd_head: 1411 dev.ix.0.queue5.rxd_tail: 1410 dev.ix.0.queue5.rx_packets: 549666835 dev.ix.0.queue5.rx_bytes: 84671540121 dev.ix.0.queue5.rx_copies: 8258025 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 500000 dev.ix.0.queue6.irqs: 490798561 dev.ix.0.queue6.txd_head: 0 dev.ix.0.queue6.txd_tail: 0 dev.ix.0.queue6.tso_tx: 0 dev.ix.0.queue6.no_tx_dma_setup: 0 dev.ix.0.queue6.no_desc_avail: 0 dev.ix.0.queue6.tx_packets: 0 dev.ix.0.queue6.rxd_head: 160 dev.ix.0.queue6.rxd_tail: 159 dev.ix.0.queue6.rx_packets: 590187606 dev.ix.0.queue6.rx_bytes: 92115960421 dev.ix.0.queue6.rx_copies: 8262802 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 500000 dev.ix.0.queue7.irqs: 471051540 dev.ix.0.queue7.txd_head: 0 dev.ix.0.queue7.txd_tail: 0 dev.ix.0.queue7.tso_tx: 0 dev.ix.0.queue7.no_tx_dma_setup: 0 dev.ix.0.queue7.no_desc_avail: 0 dev.ix.0.queue7.tx_packets: 0 dev.ix.0.queue7.rxd_head: 640 dev.ix.0.queue7.rxd_tail: 639 dev.ix.0.queue7.rx_packets: 553362982 dev.ix.0.queue7.rx_bytes: 84470102891 dev.ix.0.queue7.rx_copies: 7954102 dev.ix.0.queue7.lro_queued: 0 dev.ix.0.queue7.lro_flushed: 0 dev.ix.0.mac_stats.crc_errs: 2091 dev.ix.0.mac_stats.ill_errs: 26 dev.ix.0.mac_stats.byte_errs: 140 dev.ix.0.mac_stats.short_discards: 0 dev.ix.0.mac_stats.local_faults: 0 dev.ix.0.mac_stats.remote_faults: 0 dev.ix.0.mac_stats.rec_len_errs: 0 dev.ix.0.mac_stats.xon_txd: 0 dev.ix.0.mac_stats.xon_recvd: 0 dev.ix.0.mac_stats.xoff_txd: 0 dev.ix.0.mac_stats.xoff_recvd: 0 dev.ix.0.mac_stats.total_octets_rcvd: 17956217280225 dev.ix.0.mac_stats.good_octets_rcvd: 17945313085409 dev.ix.0.mac_stats.total_pkts_rcvd: 15243381335 dev.ix.0.mac_stats.good_pkts_rcvd: 4550864350 dev.ix.0.mac_stats.mcast_pkts_rcvd: 0 dev.ix.0.mac_stats.bcast_pkts_rcvd: 0 dev.ix.0.mac_stats.rx_frames_64: 721599526 dev.ix.0.mac_stats.rx_frames_65_127: 950131946 dev.ix.0.mac_stats.rx_frames_128_255: 918463009 dev.ix.0.mac_stats.rx_frames_256_511: 291858186 dev.ix.0.mac_stats.rx_frames_512_1023: 237479208 dev.ix.0.mac_stats.rx_frames_1024_1522: 12114578925 dev.ix.0.mac_stats.recv_undersized: 0 dev.ix.0.mac_stats.recv_fragmented: 0 dev.ix.0.mac_stats.recv_oversized: 0 dev.ix.0.mac_stats.recv_jabberd: 5 dev.ix.0.mac_stats.management_pkts_rcvd: 0 dev.ix.0.mac_stats.management_pkts_drpd: 0 dev.ix.0.mac_stats.checksum_errs: 4379061 dev.ix.0.mac_stats.good_octets_txd: 0 dev.ix.0.mac_stats.total_pkts_txd: 0 dev.ix.0.mac_stats.good_pkts_txd: 0 dev.ix.0.mac_stats.bcast_pkts_txd: 0 dev.ix.0.mac_stats.mcast_pkts_txd: 0 dev.ix.0.mac_stats.management_pkts_txd: 0 dev.ix.0.mac_stats.tx_frames_64: 0 dev.ix.0.mac_stats.tx_frames_65_127: 0 dev.ix.0.mac_stats.tx_frames_128_255: 0 dev.ix.0.mac_stats.tx_frames_256_511: 0 dev.ix.0.mac_stats.tx_frames_512_1023: 0 dev.ix.0.mac_stats.tx_frames_1024_1522: 0 # sysctl dev.ix.1 dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - = 2.5.15 dev.ix.1.%driver: ix dev.ix.1.%location: slot=3D0 function=3D1 dev.ix.1.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 = subdevice=3D0x0003 class=3D0x020000 dev.ix.1.%parent: pci4 dev.ix.1.fc: 0 dev.ix.1.enable_aim: 1 dev.ix.1.advertise_speed: 0 dev.ix.1.dropped: 0 dev.ix.1.mbuf_defrag_failed: 0 dev.ix.1.watchdog_events: 0 dev.ix.1.link_irq: 3 dev.ix.1.queue0.interrupt_rate: 500000 dev.ix.1.queue0.irqs: 537134504 dev.ix.1.queue0.txd_head: 0 dev.ix.1.queue0.txd_tail: 0 dev.ix.1.queue0.tso_tx: 0 dev.ix.1.queue0.no_tx_dma_setup: 0 dev.ix.1.queue0.no_desc_avail: 0 dev.ix.1.queue0.tx_packets: 0 dev.ix.1.queue0.rxd_head: 1757 dev.ix.1.queue0.rxd_tail: 1756 dev.ix.1.queue0.rx_packets: 565486932 dev.ix.1.queue0.rx_bytes: 7763122874 dev.ix.1.queue0.rx_copies: 40953968 dev.ix.1.queue0.lro_queued: 0 dev.ix.1.queue0.lro_flushed: 0 dev.ix.1.queue1.interrupt_rate: 500000 dev.ix.1.queue1.irqs: 561383741 dev.ix.1.queue1.txd_head: 0 dev.ix.1.queue1.txd_tail: 0 dev.ix.1.queue1.tso_tx: 0 dev.ix.1.queue1.no_tx_dma_setup: 0 dev.ix.1.queue1.no_desc_avail: 0 dev.ix.1.queue1.tx_packets: 0 dev.ix.1.queue1.rxd_head: 138 dev.ix.1.queue1.rxd_tail: 137 dev.ix.1.queue1.rx_packets: 577262064 dev.ix.1.queue1.rx_bytes: 8709306631 dev.ix.1.queue1.rx_copies: 40844466 dev.ix.1.queue1.lro_queued: 0 dev.ix.1.queue1.lro_flushed: 0 dev.ix.1.queue2.interrupt_rate: 500000 dev.ix.1.queue2.irqs: 547852317 dev.ix.1.queue2.txd_head: 0 dev.ix.1.queue2.txd_tail: 0 dev.ix.1.queue2.tso_tx: 0 dev.ix.1.queue2.no_tx_dma_setup: 0 dev.ix.1.queue2.no_desc_avail: 0 dev.ix.1.queue2.tx_packets: 0 dev.ix.1.queue2.rxd_head: 386 dev.ix.1.queue2.rxd_tail: 385 dev.ix.1.queue2.rx_packets: 562301518 dev.ix.1.queue2.rx_bytes: 6698895889 dev.ix.1.queue2.rx_copies: 40867897 dev.ix.1.queue2.lro_queued: 0 dev.ix.1.queue2.lro_flushed: 0 dev.ix.1.queue3.interrupt_rate: 500000 dev.ix.1.queue3.irqs: 551254360 dev.ix.1.queue3.txd_head: 0 dev.ix.1.queue3.txd_tail: 0 dev.ix.1.queue3.tso_tx: 0 dev.ix.1.queue3.no_tx_dma_setup: 0 dev.ix.1.queue3.no_desc_avail: 0 dev.ix.1.queue3.tx_packets: 0 dev.ix.1.queue3.rxd_head: 1446 dev.ix.1.queue3.rxd_tail: 1445 dev.ix.1.queue3.rx_packets: 566052657 dev.ix.1.queue3.rx_bytes: 8010009389 dev.ix.1.queue3.rx_copies: 41116971 dev.ix.1.queue3.lro_queued: 0 dev.ix.1.queue3.lro_flushed: 0 dev.ix.1.queue4.interrupt_rate: 500000 dev.ix.1.queue4.irqs: 546581703 dev.ix.1.queue4.txd_head: 0 dev.ix.1.queue4.txd_tail: 0 dev.ix.1.queue4.tso_tx: 0 dev.ix.1.queue4.no_tx_dma_setup: 0 dev.ix.1.queue4.no_desc_avail: 0 dev.ix.1.queue4.tx_packets: 0 dev.ix.1.queue4.rxd_head: 965 dev.ix.1.queue4.rxd_tail: 964 dev.ix.1.queue4.rx_packets: 561519824 dev.ix.1.queue4.rx_bytes: 7656671816 dev.ix.1.queue4.rx_copies: 41183608 dev.ix.1.queue4.lro_queued: 0 dev.ix.1.queue4.lro_flushed: 0 dev.ix.1.queue5.interrupt_rate: 500000 dev.ix.1.queue5.irqs: 557099892 dev.ix.1.queue5.txd_head: 0 dev.ix.1.queue5.txd_tail: 0 dev.ix.1.queue5.tso_tx: 0 dev.ix.1.queue5.no_tx_dma_setup: 0 dev.ix.1.queue5.no_desc_avail: 0 dev.ix.1.queue5.tx_packets: 0 dev.ix.1.queue5.rxd_head: 1788 dev.ix.1.queue5.rxd_tail: 1787 dev.ix.1.queue5.rx_packets: 572588639 dev.ix.1.queue5.rx_bytes: 7259699024 dev.ix.1.queue5.rx_copies: 43207640 dev.ix.1.queue5.lro_queued: 0 dev.ix.1.queue5.lro_flushed: 0 dev.ix.1.queue6.interrupt_rate: 500000 dev.ix.1.queue6.irqs: 574139280 dev.ix.1.queue6.txd_head: 0 dev.ix.1.queue6.txd_tail: 0 dev.ix.1.queue6.tso_tx: 0 dev.ix.1.queue6.no_tx_dma_setup: 0 dev.ix.1.queue6.no_desc_avail: 0 dev.ix.1.queue6.tx_packets: 0 dev.ix.1.queue6.rxd_head: 45 dev.ix.1.queue6.rxd_tail: 44 dev.ix.1.queue6.rx_packets: 589160795 dev.ix.1.queue6.rx_bytes: 7475849844 dev.ix.1.queue6.rx_copies: 40589940 dev.ix.1.queue6.lro_queued: 0 dev.ix.1.queue6.lro_flushed: 0 dev.ix.1.queue7.interrupt_rate: 500000 dev.ix.1.queue7.irqs: 552769977 dev.ix.1.queue7.txd_head: 0 dev.ix.1.queue7.txd_tail: 0 dev.ix.1.queue7.tso_tx: 0 dev.ix.1.queue7.no_tx_dma_setup: 0 dev.ix.1.queue7.no_desc_avail: 0 dev.ix.1.queue7.tx_packets: 0 dev.ix.1.queue7.rxd_head: 1050 dev.ix.1.queue7.rxd_tail: 1049 dev.ix.1.queue7.rx_packets: 567580543 dev.ix.1.queue7.rx_bytes: 7210216689 dev.ix.1.queue7.rx_copies: 41856967 dev.ix.1.queue7.lro_queued: 0 dev.ix.1.queue7.lro_flushed: 0 dev.ix.1.mac_stats.crc_errs: 40044743 dev.ix.1.mac_stats.ill_errs: 4347098 dev.ix.1.mac_stats.byte_errs: 7192103 dev.ix.1.mac_stats.short_discards: 49169 dev.ix.1.mac_stats.local_faults: 0 dev.ix.1.mac_stats.remote_faults: 0 dev.ix.1.mac_stats.rec_len_errs: 41772 dev.ix.1.mac_stats.xon_txd: 0 dev.ix.1.mac_stats.xon_recvd: 0 dev.ix.1.mac_stats.xoff_txd: 0 dev.ix.1.mac_stats.xoff_recvd: 0 dev.ix.1.mac_stats.total_octets_rcvd: 1741353301146 dev.ix.1.mac_stats.good_octets_rcvd: 1704100700961 dev.ix.1.mac_stats.total_pkts_rcvd: 9354020520 dev.ix.1.mac_stats.good_pkts_rcvd: 4561867527 dev.ix.1.mac_stats.mcast_pkts_rcvd: 139746 dev.ix.1.mac_stats.bcast_pkts_rcvd: 0 dev.ix.1.mac_stats.rx_frames_64: 3314959123 dev.ix.1.mac_stats.rx_frames_65_127: 4610233544 dev.ix.1.mac_stats.rx_frames_128_255: 256517169 dev.ix.1.mac_stats.rx_frames_256_511: 304326606 dev.ix.1.mac_stats.rx_frames_512_1023: 223999237 dev.ix.1.mac_stats.rx_frames_1024_1522: 591102680 dev.ix.1.mac_stats.recv_undersized: 0 dev.ix.1.mac_stats.recv_fragmented: 0 dev.ix.1.mac_stats.recv_oversized: 0 dev.ix.1.mac_stats.recv_jabberd: 71008 dev.ix.1.mac_stats.management_pkts_rcvd: 0 dev.ix.1.mac_stats.management_pkts_drpd: 0 dev.ix.1.mac_stats.checksum_errs: 3901883 dev.ix.1.mac_stats.good_octets_txd: 0 dev.ix.1.mac_stats.total_pkts_txd: 0 dev.ix.1.mac_stats.good_pkts_txd: 0 dev.ix.1.mac_stats.bcast_pkts_txd: 0 dev.ix.1.mac_stats.mcast_pkts_txd: 0 dev.ix.1.mac_stats.management_pkts_txd: 0 dev.ix.1.mac_stats.tx_frames_64: 0 dev.ix.1.mac_stats.tx_frames_65_127: 0 dev.ix.1.mac_stats.tx_frames_128_255: 0 dev.ix.1.mac_stats.tx_frames_256_511: 0 dev.ix.1.mac_stats.tx_frames_512_1023: 0 dev.ix.1.mac_stats.tx_frames_1024_1522: 0= From owner-freebsd-net@FreeBSD.ORG Thu May 21 13:52:57 2015 Return-Path: Delivered-To: freebsd-net@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 EBD8CC03 for ; Thu, 21 May 2015 13:52:57 +0000 (UTC) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 A17A910B1 for ; Thu, 21 May 2015 13:52:57 +0000 (UTC) Received: by qkgv12 with SMTP id v12so54655057qkg.0 for ; Thu, 21 May 2015 06:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BZIbzF5Y4QhbPRX/k2RFmpDz5DSa7Np36SSWfYtPtYY=; b=cZtIz1asLHwBPEcU4qhc4GoSMDFD1tM8qhOH0vuHPCqbycw88x2y5hd1C7xBC0cVwp ebV0R/U2P8aua6BWe99UDc/esPEfyiib2DebeDLlAPrdfvrCLDxfe9Jsi7RUKLnFoyfL 7abSXWmD4HSSLAdemekUn8WYalhP6v+JULyd75Kf8Pz67z5TvEOF6J1Mq65ieSEupgIC e1kipf+X3qVlO9ESly2nJWOMGvwQE/a3z92qelAHyRexcLsWxPZHd2vN7QKz5ADKaD0W DaUFudNFIevydDHZGkJHQm/FNnWhb6aeXGzkj/86NZZDUCaN3RIFYWe4JwA/GCFVbv17 0NRg== MIME-Version: 1.0 X-Received: by 10.140.144.67 with SMTP id 64mr3947479qhq.40.1432216376688; Thu, 21 May 2015 06:52:56 -0700 (PDT) Received: by 10.96.110.229 with HTTP; Thu, 21 May 2015 06:52:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 10:52:56 -0300 Message-ID: Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets From: Christopher Forgeron To: Guy Helmer Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 13:52:58 -0000 A few things: 1) How long before you have this behaviour? 2) What's the output of 'netstat -m' when you have the problem? 3) What is your MTU set to, and do you have TSO on or off? On Thu, May 21, 2015 at 10:33 AM, Guy Helmer wrote: > I=E2=80=99ve noticed that there have been reports of problems with Intel = X520-SR2 > network interfaces stopping working. I think I=E2=80=99m seeing a similar= issue > where the 10Gb interfaces stop receiving traffic (they=E2=80=99re being u= sed in > promiscuous mode to sniff traffic from a tap). ifconfig shows the > interfaces are still active and the links are OK. ifconfig down/up restor= es > activity. I=E2=80=99ve changed hw.intr_storm_threshold=3D8000 but I could= n=E2=80=99t tell if > the interrupt storm threshold had been triggered at the time the interfac= es > stopped passing traffic. > > Output from sysctl: > > # sysctl dev.ix.0 > dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - > 2.5.15 > dev.ix.0.%driver: ix > dev.ix.0.%location: slot=3D0 function=3D0 > dev.ix.0.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 > subdevice=3D0x0003 class=3D0x020000 > dev.ix.0.%parent: pci4 > dev.ix.0.fc: 0 > dev.ix.0.enable_aim: 1 > dev.ix.0.advertise_speed: 0 > dev.ix.0.dropped: 0 > dev.ix.0.mbuf_defrag_failed: 0 > dev.ix.0.watchdog_events: 0 > dev.ix.0.link_irq: 3 > dev.ix.0.queue0.interrupt_rate: 500000 > dev.ix.0.queue0.irqs: 454449470 > dev.ix.0.queue0.txd_head: 0 > dev.ix.0.queue0.txd_tail: 0 > dev.ix.0.queue0.tso_tx: 0 > dev.ix.0.queue0.no_tx_dma_setup: 0 > dev.ix.0.queue0.no_desc_avail: 0 > dev.ix.0.queue0.tx_packets: 0 > dev.ix.0.queue0.rxd_head: 1437 > dev.ix.0.queue0.rxd_tail: 1436 > dev.ix.0.queue0.rx_packets: 547499168 > dev.ix.0.queue0.rx_bytes: 87201112584 > dev.ix.0.queue0.rx_copies: 7934870 > dev.ix.0.queue0.lro_queued: 0 > dev.ix.0.queue0.lro_flushed: 0 > dev.ix.0.queue1.interrupt_rate: 500000 > dev.ix.0.queue1.irqs: 466235043 > dev.ix.0.queue1.txd_head: 0 > dev.ix.0.queue1.txd_tail: 0 > dev.ix.0.queue1.tso_tx: 0 > dev.ix.0.queue1.no_tx_dma_setup: 0 > dev.ix.0.queue1.no_desc_avail: 0 > dev.ix.0.queue1.tx_packets: 0 > dev.ix.0.queue1.rxd_head: 277 > dev.ix.0.queue1.rxd_tail: 276 > dev.ix.0.queue1.rx_packets: 547668680 > dev.ix.0.queue1.rx_bytes: 86205679601 > dev.ix.0.queue1.rx_copies: 7846653 > dev.ix.0.queue1.lro_queued: 0 > dev.ix.0.queue1.lro_flushed: 0 > dev.ix.0.queue2.interrupt_rate: 500000 > dev.ix.0.queue2.irqs: 473958473 > dev.ix.0.queue2.txd_head: 0 > dev.ix.0.queue2.txd_tail: 0 > dev.ix.0.queue2.tso_tx: 0 > dev.ix.0.queue2.no_tx_dma_setup: 0 > dev.ix.0.queue2.no_desc_avail: 0 > dev.ix.0.queue2.tx_packets: 0 > dev.ix.0.queue2.rxd_head: 576 > dev.ix.0.queue2.rxd_tail: 575 > dev.ix.0.queue2.rx_packets: 555704840 > dev.ix.0.queue2.rx_bytes: 87294164455 > dev.ix.0.queue2.rx_copies: 8297211 > dev.ix.0.queue2.lro_queued: 0 > dev.ix.0.queue2.lro_flushed: 0 > dev.ix.0.queue3.interrupt_rate: 500000 > dev.ix.0.queue3.irqs: 477587504 > dev.ix.0.queue3.txd_head: 0 > dev.ix.0.queue3.txd_tail: 0 > dev.ix.0.queue3.tso_tx: 0 > dev.ix.0.queue3.no_tx_dma_setup: 0 > dev.ix.0.queue3.no_desc_avail: 0 > dev.ix.0.queue3.tx_packets: 0 > dev.ix.0.queue3.rxd_head: 267 > dev.ix.0.queue3.rxd_tail: 266 > dev.ix.0.queue3.rx_packets: 559921557 > dev.ix.0.queue3.rx_bytes: 86832161258 > dev.ix.0.queue3.rx_copies: 7918011 > dev.ix.0.queue3.lro_queued: 0 > dev.ix.0.queue3.lro_flushed: 0 > dev.ix.0.queue4.interrupt_rate: 500000 > dev.ix.0.queue4.irqs: 558339677 > dev.ix.0.queue4.txd_head: 0 > dev.ix.0.queue4.txd_tail: 0 > dev.ix.0.queue4.tso_tx: 0 > dev.ix.0.queue4.no_tx_dma_setup: 0 > dev.ix.0.queue4.no_desc_avail: 0 > dev.ix.0.queue4.tx_packets: 0 > dev.ix.0.queue4.rxd_head: 1240 > dev.ix.0.queue4.rxd_tail: 1239 > dev.ix.0.queue4.rx_packets: 646909190 > dev.ix.0.queue4.rx_bytes: 87117307815 > dev.ix.0.queue4.rx_copies: 7944848 > dev.ix.0.queue4.lro_queued: 0 > dev.ix.0.queue4.lro_flushed: 0 > dev.ix.0.queue5.interrupt_rate: 500000 > dev.ix.0.queue5.irqs: 467836647 > dev.ix.0.queue5.txd_head: 0 > dev.ix.0.queue5.txd_tail: 0 > dev.ix.0.queue5.tso_tx: 0 > dev.ix.0.queue5.no_tx_dma_setup: 0 > dev.ix.0.queue5.no_desc_avail: 0 > dev.ix.0.queue5.tx_packets: 0 > dev.ix.0.queue5.rxd_head: 1411 > dev.ix.0.queue5.rxd_tail: 1410 > dev.ix.0.queue5.rx_packets: 549666835 > dev.ix.0.queue5.rx_bytes: 84671540121 > dev.ix.0.queue5.rx_copies: 8258025 > dev.ix.0.queue5.lro_queued: 0 > dev.ix.0.queue5.lro_flushed: 0 > dev.ix.0.queue6.interrupt_rate: 500000 > dev.ix.0.queue6.irqs: 490798561 > dev.ix.0.queue6.txd_head: 0 > dev.ix.0.queue6.txd_tail: 0 > dev.ix.0.queue6.tso_tx: 0 > dev.ix.0.queue6.no_tx_dma_setup: 0 > dev.ix.0.queue6.no_desc_avail: 0 > dev.ix.0.queue6.tx_packets: 0 > dev.ix.0.queue6.rxd_head: 160 > dev.ix.0.queue6.rxd_tail: 159 > dev.ix.0.queue6.rx_packets: 590187606 > dev.ix.0.queue6.rx_bytes: 92115960421 > dev.ix.0.queue6.rx_copies: 8262802 > dev.ix.0.queue6.lro_queued: 0 > dev.ix.0.queue6.lro_flushed: 0 > dev.ix.0.queue7.interrupt_rate: 500000 > dev.ix.0.queue7.irqs: 471051540 > dev.ix.0.queue7.txd_head: 0 > dev.ix.0.queue7.txd_tail: 0 > dev.ix.0.queue7.tso_tx: 0 > dev.ix.0.queue7.no_tx_dma_setup: 0 > dev.ix.0.queue7.no_desc_avail: 0 > dev.ix.0.queue7.tx_packets: 0 > dev.ix.0.queue7.rxd_head: 640 > dev.ix.0.queue7.rxd_tail: 639 > dev.ix.0.queue7.rx_packets: 553362982 > dev.ix.0.queue7.rx_bytes: 84470102891 > dev.ix.0.queue7.rx_copies: 7954102 > dev.ix.0.queue7.lro_queued: 0 > dev.ix.0.queue7.lro_flushed: 0 > dev.ix.0.mac_stats.crc_errs: 2091 > dev.ix.0.mac_stats.ill_errs: 26 > dev.ix.0.mac_stats.byte_errs: 140 > dev.ix.0.mac_stats.short_discards: 0 > dev.ix.0.mac_stats.local_faults: 0 > dev.ix.0.mac_stats.remote_faults: 0 > dev.ix.0.mac_stats.rec_len_errs: 0 > dev.ix.0.mac_stats.xon_txd: 0 > dev.ix.0.mac_stats.xon_recvd: 0 > dev.ix.0.mac_stats.xoff_txd: 0 > dev.ix.0.mac_stats.xoff_recvd: 0 > dev.ix.0.mac_stats.total_octets_rcvd: 17956217280225 > dev.ix.0.mac_stats.good_octets_rcvd: 17945313085409 > dev.ix.0.mac_stats.total_pkts_rcvd: 15243381335 > dev.ix.0.mac_stats.good_pkts_rcvd: 4550864350 > dev.ix.0.mac_stats.mcast_pkts_rcvd: 0 > dev.ix.0.mac_stats.bcast_pkts_rcvd: 0 > dev.ix.0.mac_stats.rx_frames_64: 721599526 > dev.ix.0.mac_stats.rx_frames_65_127: 950131946 > dev.ix.0.mac_stats.rx_frames_128_255: 918463009 > dev.ix.0.mac_stats.rx_frames_256_511: 291858186 > dev.ix.0.mac_stats.rx_frames_512_1023: 237479208 > dev.ix.0.mac_stats.rx_frames_1024_1522: 12114578925 > dev.ix.0.mac_stats.recv_undersized: 0 > dev.ix.0.mac_stats.recv_fragmented: 0 > dev.ix.0.mac_stats.recv_oversized: 0 > dev.ix.0.mac_stats.recv_jabberd: 5 > dev.ix.0.mac_stats.management_pkts_rcvd: 0 > dev.ix.0.mac_stats.management_pkts_drpd: 0 > dev.ix.0.mac_stats.checksum_errs: 4379061 > dev.ix.0.mac_stats.good_octets_txd: 0 > dev.ix.0.mac_stats.total_pkts_txd: 0 > dev.ix.0.mac_stats.good_pkts_txd: 0 > dev.ix.0.mac_stats.bcast_pkts_txd: 0 > dev.ix.0.mac_stats.mcast_pkts_txd: 0 > dev.ix.0.mac_stats.management_pkts_txd: 0 > dev.ix.0.mac_stats.tx_frames_64: 0 > dev.ix.0.mac_stats.tx_frames_65_127: 0 > dev.ix.0.mac_stats.tx_frames_128_255: 0 > dev.ix.0.mac_stats.tx_frames_256_511: 0 > dev.ix.0.mac_stats.tx_frames_512_1023: 0 > dev.ix.0.mac_stats.tx_frames_1024_1522: 0 > > # sysctl dev.ix.1 > dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - > 2.5.15 > dev.ix.1.%driver: ix > dev.ix.1.%location: slot=3D0 function=3D1 > dev.ix.1.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 > subdevice=3D0x0003 class=3D0x020000 > dev.ix.1.%parent: pci4 > dev.ix.1.fc: 0 > dev.ix.1.enable_aim: 1 > dev.ix.1.advertise_speed: 0 > dev.ix.1.dropped: 0 > dev.ix.1.mbuf_defrag_failed: 0 > dev.ix.1.watchdog_events: 0 > dev.ix.1.link_irq: 3 > dev.ix.1.queue0.interrupt_rate: 500000 > dev.ix.1.queue0.irqs: 537134504 > dev.ix.1.queue0.txd_head: 0 > dev.ix.1.queue0.txd_tail: 0 > dev.ix.1.queue0.tso_tx: 0 > dev.ix.1.queue0.no_tx_dma_setup: 0 > dev.ix.1.queue0.no_desc_avail: 0 > dev.ix.1.queue0.tx_packets: 0 > dev.ix.1.queue0.rxd_head: 1757 > dev.ix.1.queue0.rxd_tail: 1756 > dev.ix.1.queue0.rx_packets: 565486932 > dev.ix.1.queue0.rx_bytes: 7763122874 > dev.ix.1.queue0.rx_copies: 40953968 > dev.ix.1.queue0.lro_queued: 0 > dev.ix.1.queue0.lro_flushed: 0 > dev.ix.1.queue1.interrupt_rate: 500000 > dev.ix.1.queue1.irqs: 561383741 > dev.ix.1.queue1.txd_head: 0 > dev.ix.1.queue1.txd_tail: 0 > dev.ix.1.queue1.tso_tx: 0 > dev.ix.1.queue1.no_tx_dma_setup: 0 > dev.ix.1.queue1.no_desc_avail: 0 > dev.ix.1.queue1.tx_packets: 0 > dev.ix.1.queue1.rxd_head: 138 > dev.ix.1.queue1.rxd_tail: 137 > dev.ix.1.queue1.rx_packets: 577262064 > dev.ix.1.queue1.rx_bytes: 8709306631 > dev.ix.1.queue1.rx_copies: 40844466 > dev.ix.1.queue1.lro_queued: 0 > dev.ix.1.queue1.lro_flushed: 0 > dev.ix.1.queue2.interrupt_rate: 500000 > dev.ix.1.queue2.irqs: 547852317 > dev.ix.1.queue2.txd_head: 0 > dev.ix.1.queue2.txd_tail: 0 > dev.ix.1.queue2.tso_tx: 0 > dev.ix.1.queue2.no_tx_dma_setup: 0 > dev.ix.1.queue2.no_desc_avail: 0 > dev.ix.1.queue2.tx_packets: 0 > dev.ix.1.queue2.rxd_head: 386 > dev.ix.1.queue2.rxd_tail: 385 > dev.ix.1.queue2.rx_packets: 562301518 > dev.ix.1.queue2.rx_bytes: 6698895889 > dev.ix.1.queue2.rx_copies: 40867897 > dev.ix.1.queue2.lro_queued: 0 > dev.ix.1.queue2.lro_flushed: 0 > dev.ix.1.queue3.interrupt_rate: 500000 > dev.ix.1.queue3.irqs: 551254360 > dev.ix.1.queue3.txd_head: 0 > dev.ix.1.queue3.txd_tail: 0 > dev.ix.1.queue3.tso_tx: 0 > dev.ix.1.queue3.no_tx_dma_setup: 0 > dev.ix.1.queue3.no_desc_avail: 0 > dev.ix.1.queue3.tx_packets: 0 > dev.ix.1.queue3.rxd_head: 1446 > dev.ix.1.queue3.rxd_tail: 1445 > dev.ix.1.queue3.rx_packets: 566052657 > dev.ix.1.queue3.rx_bytes: 8010009389 > dev.ix.1.queue3.rx_copies: 41116971 > dev.ix.1.queue3.lro_queued: 0 > dev.ix.1.queue3.lro_flushed: 0 > dev.ix.1.queue4.interrupt_rate: 500000 > dev.ix.1.queue4.irqs: 546581703 > dev.ix.1.queue4.txd_head: 0 > dev.ix.1.queue4.txd_tail: 0 > dev.ix.1.queue4.tso_tx: 0 > dev.ix.1.queue4.no_tx_dma_setup: 0 > dev.ix.1.queue4.no_desc_avail: 0 > dev.ix.1.queue4.tx_packets: 0 > dev.ix.1.queue4.rxd_head: 965 > dev.ix.1.queue4.rxd_tail: 964 > dev.ix.1.queue4.rx_packets: 561519824 > dev.ix.1.queue4.rx_bytes: 7656671816 > dev.ix.1.queue4.rx_copies: 41183608 > dev.ix.1.queue4.lro_queued: 0 > dev.ix.1.queue4.lro_flushed: 0 > dev.ix.1.queue5.interrupt_rate: 500000 > dev.ix.1.queue5.irqs: 557099892 > dev.ix.1.queue5.txd_head: 0 > dev.ix.1.queue5.txd_tail: 0 > dev.ix.1.queue5.tso_tx: 0 > dev.ix.1.queue5.no_tx_dma_setup: 0 > dev.ix.1.queue5.no_desc_avail: 0 > dev.ix.1.queue5.tx_packets: 0 > dev.ix.1.queue5.rxd_head: 1788 > dev.ix.1.queue5.rxd_tail: 1787 > dev.ix.1.queue5.rx_packets: 572588639 > dev.ix.1.queue5.rx_bytes: 7259699024 > dev.ix.1.queue5.rx_copies: 43207640 > dev.ix.1.queue5.lro_queued: 0 > dev.ix.1.queue5.lro_flushed: 0 > dev.ix.1.queue6.interrupt_rate: 500000 > dev.ix.1.queue6.irqs: 574139280 > dev.ix.1.queue6.txd_head: 0 > dev.ix.1.queue6.txd_tail: 0 > dev.ix.1.queue6.tso_tx: 0 > dev.ix.1.queue6.no_tx_dma_setup: 0 > dev.ix.1.queue6.no_desc_avail: 0 > dev.ix.1.queue6.tx_packets: 0 > dev.ix.1.queue6.rxd_head: 45 > dev.ix.1.queue6.rxd_tail: 44 > dev.ix.1.queue6.rx_packets: 589160795 > dev.ix.1.queue6.rx_bytes: 7475849844 > dev.ix.1.queue6.rx_copies: 40589940 > dev.ix.1.queue6.lro_queued: 0 > dev.ix.1.queue6.lro_flushed: 0 > dev.ix.1.queue7.interrupt_rate: 500000 > dev.ix.1.queue7.irqs: 552769977 > dev.ix.1.queue7.txd_head: 0 > dev.ix.1.queue7.txd_tail: 0 > dev.ix.1.queue7.tso_tx: 0 > dev.ix.1.queue7.no_tx_dma_setup: 0 > dev.ix.1.queue7.no_desc_avail: 0 > dev.ix.1.queue7.tx_packets: 0 > dev.ix.1.queue7.rxd_head: 1050 > dev.ix.1.queue7.rxd_tail: 1049 > dev.ix.1.queue7.rx_packets: 567580543 > dev.ix.1.queue7.rx_bytes: 7210216689 > dev.ix.1.queue7.rx_copies: 41856967 > dev.ix.1.queue7.lro_queued: 0 > dev.ix.1.queue7.lro_flushed: 0 > dev.ix.1.mac_stats.crc_errs: 40044743 > dev.ix.1.mac_stats.ill_errs: 4347098 > dev.ix.1.mac_stats.byte_errs: 7192103 > dev.ix.1.mac_stats.short_discards: 49169 > dev.ix.1.mac_stats.local_faults: 0 > dev.ix.1.mac_stats.remote_faults: 0 > dev.ix.1.mac_stats.rec_len_errs: 41772 > dev.ix.1.mac_stats.xon_txd: 0 > dev.ix.1.mac_stats.xon_recvd: 0 > dev.ix.1.mac_stats.xoff_txd: 0 > dev.ix.1.mac_stats.xoff_recvd: 0 > dev.ix.1.mac_stats.total_octets_rcvd: 1741353301146 > dev.ix.1.mac_stats.good_octets_rcvd: 1704100700961 > dev.ix.1.mac_stats.total_pkts_rcvd: 9354020520 > dev.ix.1.mac_stats.good_pkts_rcvd: 4561867527 > dev.ix.1.mac_stats.mcast_pkts_rcvd: 139746 > dev.ix.1.mac_stats.bcast_pkts_rcvd: 0 > dev.ix.1.mac_stats.rx_frames_64: 3314959123 > dev.ix.1.mac_stats.rx_frames_65_127: 4610233544 > dev.ix.1.mac_stats.rx_frames_128_255: 256517169 > dev.ix.1.mac_stats.rx_frames_256_511: 304326606 > dev.ix.1.mac_stats.rx_frames_512_1023: 223999237 > dev.ix.1.mac_stats.rx_frames_1024_1522: 591102680 > dev.ix.1.mac_stats.recv_undersized: 0 > dev.ix.1.mac_stats.recv_fragmented: 0 > dev.ix.1.mac_stats.recv_oversized: 0 > dev.ix.1.mac_stats.recv_jabberd: 71008 > dev.ix.1.mac_stats.management_pkts_rcvd: 0 > dev.ix.1.mac_stats.management_pkts_drpd: 0 > dev.ix.1.mac_stats.checksum_errs: 3901883 > dev.ix.1.mac_stats.good_octets_txd: 0 > dev.ix.1.mac_stats.total_pkts_txd: 0 > dev.ix.1.mac_stats.good_pkts_txd: 0 > dev.ix.1.mac_stats.bcast_pkts_txd: 0 > dev.ix.1.mac_stats.mcast_pkts_txd: 0 > dev.ix.1.mac_stats.management_pkts_txd: 0 > dev.ix.1.mac_stats.tx_frames_64: 0 > dev.ix.1.mac_stats.tx_frames_65_127: 0 > dev.ix.1.mac_stats.tx_frames_128_255: 0 > dev.ix.1.mac_stats.tx_frames_256_511: 0 > dev.ix.1.mac_stats.tx_frames_512_1023: 0 > dev.ix.1.mac_stats.tx_frames_1024_1522: 0 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 21 15:45:58 2015 Return-Path: Delivered-To: freebsd-net@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 A77CE301; Thu, 21 May 2015 15:45:58 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 694941E6A; Thu, 21 May 2015 15:45:58 +0000 (UTC) Received: by obbea2 with SMTP id ea2so28744431obb.3; Thu, 21 May 2015 08:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Q6V88IfmpDBpPisWVajL6NvDapqR3YYEBkAPLxCowhU=; b=vSWKZlfll03Ug8t3LtqPXae1FDVP/bZ5ZaVGlenAsSZHXB2ndFb8Wpb9dp5eomhpE7 p3d8fYnhBsRHOroa7v4PEyPxvTyTV0UTryIcM2r4OXqgCmXrZrijXvziF9RS5/b6m62D 4xlP6wkAcTsLt37a8ll0pGJoET1XBJJnRsZpRQx/A5K6Q7fvUMp3mc2cXgMi7Lt9vhLT 0xXkdTCkPrRu9TVjfVUUPSd8EJ/lq4prodt4Zp3sjapsMNrvLLGeKXm7RdYTxq0zNaSm aH1Dl7kiBYHKjWSd1kTpcuNa7zCRohPCbykr/4l0sn0nezqxUr0adPurQtf30mmjdQkD aMRw== MIME-Version: 1.0 X-Received: by 10.202.216.138 with SMTP id p132mr2665432oig.133.1432223157785; Thu, 21 May 2015 08:45:57 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.202.21.132 with HTTP; Thu, 21 May 2015 08:45:57 -0700 (PDT) Received: by 10.202.21.132 with HTTP; Thu, 21 May 2015 08:45:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 08:45:57 -0700 X-Google-Sender-Auth: SOBsSfvvpSNkpzlO6UmD9mIpEDY Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: "K. Macy" To: Karlis Laivins Cc: freebsd-net@freebsd.org, Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:45:58 -0000 Your module references a variable that the kernel doesn't define. As soon as you either define it or figure out what you should really be referencing it as your module will load. On May 21, 2015 3:53 AM, "Karlis Laivins" wrote: > Hello again, > > A little update - the problem occurs only when trying to load a modified > NewReno algorithm module. When I create a dummy module from, for example, > Vegas implementation (with some trivial changes made besides the function > and module names), the module can be loaded successfully. > > Is there a way (if no other way can be found to fix this right away), to > trick the system into using my NewReno module instead of the one hard coded > in the system? (I know, sounds silly - change the hard coded settings, but, > maybe there is a way...) > > Thank you in advance! > > BR, > Karlis > > On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins > > wrote: > > > Hello, > > > > Tried both, still the same issue... > > > > BR, > > KL > > > > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd > wrote: > > > >> Hi, > >> > >> Try kldxref /boot/kernel > >> > >> If it doesn't help, try recompiling the module. > >> > >> > >> -a > >> > >> > >> On 20 May 2015 at 19:41, Karlis Laivins > wrote: > >> > Good Morning, > >> > > >> > I have a following issue, maybe someone has encountered this and can > >> > provide me with a quick solution to a following issue. > >> > > >> > I have compiled a module, which is a modified version of the NewReno > >> > congestion control algorithm. I tried to load it into Kernel > >> successfully > >> > before I recompiled Kernel with a following config file, so I can use > >> > Imunes and test the new module: > >> > > >> > include GENERIC > >> > nooptions FLOWTABLE > >> > options VIMAGE > >> > options VNET_DEBUG > >> > options MROUTING > >> > > >> > options IPSEC > >> > device crypto > >> > options IPSEC_DEBUG > >> > > >> > options DDB > >> > options KDB > >> > > >> > The problem is - after the Kernel has been reompiled, I can no longer > >> load > >> > the module with kldload. The error I get is: > >> > > >> > link_elf: symbol tcp_do_rfc3465 undefined > >> > kldload: can't load cc_changedreno.ko: No such file or directory > >> > > >> > And this is despite the fact the cc_changedreno.ko module is in > >> > /boot/kernel/. > >> > > >> > Thank you in advance! > >> > > >> > BR, > >> > Karlis > >> > _______________________________________________ > >> > freebsd-net@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org > " > >> > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 21 15:55:11 2015 Return-Path: Delivered-To: freebsd-net@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 C1AD25C6; Thu, 21 May 2015 15:55:11 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 88F221FC5; Thu, 21 May 2015 15:55:10 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B67FD7300A; Thu, 21 May 2015 18:02:13 +0200 (CEST) Date: Thu, 21 May 2015 18:02:13 +0200 From: Luigi Rizzo To: current@freebsd.org Cc: freebsd-net@freebsd.org, g.lettieri@iet.unipi.it, stefanogarzarella@gmail.com Subject: heads up: netmap code update next week. Message-ID: <20150521160213.GD66725@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:55:11 -0000 Hi, some time next week we will push to head (and hopefully, to stable/10 before the code slush) an update to the netmap code. There will be no API changes, and the changes are mostly internal restructuring of the netmap kernel code and simplification of device drivers (we will ll handle most of them ourselves and talk to Navdeep for the chelsio bits). These changes are needed to ease upcoming work on separate memory allocators, and the passthrough code which we are working on. If anyone has local diffs that would like to submit, please let us know so we can merge them as well if appropriate cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu May 21 16:09:44 2015 Return-Path: Delivered-To: freebsd-net@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 7955EE50; Thu, 21 May 2015 16:09:44 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::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 DDE5511CA; Thu, 21 May 2015 16:09:43 +0000 (UTC) Received: by lagr1 with SMTP id r1so106127746lag.0; Thu, 21 May 2015 09:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=agQRzeEelYRQJwhxaTUsdDMs5nIxVE9xmU5bVkdWrLw=; b=dBFT5WMOzShEulRJ0+Lp+sjoHKLX9Z4vanIB3/uEBLiQtSyPBW6s6TIuRpovp5ZqxE QbJqlbiYOIj7qUYfCD5CtgFmLC7kIykOiJPpdP6urqHjVWlAa6Hzm8w09e6ueuF2DHVU hfJIsvMMsLdjU8rD8aatw/A8ZYTS5H5hUZcv1xceHxZaIvyui6W5CmDdnJ2ofbx8c/MN C2fbC2aNZIF8bm8HoUZ7A14alniNhLGLyQ9IB2DQgCm39Ir8jhxzQytQE3dyBD6yDzcL jtddG6zZiMhZDt/JZdwL4g0KxbWufFSjpzbia3i4vf6wZVVKSq+Viyh8OTYBSGq4owlT nkog== MIME-Version: 1.0 X-Received: by 10.152.6.69 with SMTP id y5mr2852865lay.72.1432224581687; Thu, 21 May 2015 09:09:41 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.20.232 with HTTP; Thu, 21 May 2015 09:09:41 -0700 (PDT) Date: Thu, 21 May 2015 18:09:41 +0200 X-Google-Sender-Auth: 9MmPuqzilt7SDZj2gFbn0Ju9nBc Message-ID: Subject: sys/netinet/ip_var.h: enum value exceeding 2^31-1 From: Luigi Rizzo To: "freebsd-net@freebsd.org" Cc: Luigi Rizzo , "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:09:44 -0000 in pedantic mode the compiler complains about an enum value out of range (in sys/netinet/ip_var.h) Would people object to the following change ? It seems to be used internally only in a handful of places =E2=80=8B+=E2=80=8B /* ISO C restricts enumerator values to range of 'int' =E2=80=8B+=E2=80=8B * so we need =E2=80=8BIPFW_INFO_=E2=80=8B IN to have a smaller value =E2=80=8B+=E2=80=8B */ =E2=80=8B =E2=80=8B enum { IPFW_INFO_MASK =3D 0x0000ffff, IPFW_INFO_OUT =3D 0x00000000, /* outgoing, just for convenience= */ =E2=80=8B- =E2=80=8B IPFW_INFO_IN =3D 0x8 =E2=80=8B00=E2=80=8B 00000, /* incoming, overloads dir */ =E2=80=8B+=E2=80=8B IPFW_INFO_IN =3D 0x00800000, /* incoming, overloads dir */ IPFW_ONEPASS =3D 0x40000000, /* One-pass, do not reinject */ head/sys/netpfil/ipfw/ip_fw2.c: cmd->arg1 & ((i & IPFW_INFO_IN) ? 1 : 2); head/sys/netgraph/ng_ipfw.c: if (r->info & IPFW_INFO_IN) { head/sys/netgraph/ng_ipfw.c: r->info |=3D dir ? IPFW_INFO_IN : IPFW_INFO_OUT; head/sys/netinet/ip_var.h: IPFW_INFO_IN =3D 0x80000000, /* incoming, overloads dir */ head/sys/netinet/ip_divert.c: dt->info |=3D IPFW_IS_DIVERT | IPFW_INFO_IN; =E2=80=8Bcheers luigi From owner-freebsd-net@FreeBSD.ORG Thu May 21 16:10:32 2015 Return-Path: Delivered-To: freebsd-net@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 28203FC2 for ; Thu, 21 May 2015 16:10:32 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 E267211D4 for ; Thu, 21 May 2015 16:10:31 +0000 (UTC) Received: by igcau1 with SMTP id au1so12406268igc.1 for ; Thu, 21 May 2015 09:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=l3pqTG4Z8jlsh7EkzqW/JpozAEib6ZUVWbW91sI46ZE=; b=jiYAcFoXzwmbVtPral1vNHk3FkErRwliKLtF4D36IK6+hI7aUFT3K2TojzlzI0IjmM GNMKNDW2ehSaTDQ6kz1d1EexpjwqKG4VmE9nSvZM633mHfDmr7u6XdNbbIeFh13aA+1p +VkeFLpkgSOTVCeE0POJ+jDoXQZh/dkgZzmR8wP7fCvpeFIe1stYahGBxMPxBblwh8aH VJssNFWiKatEofqjN5mQ5XRfnykJiVp7Cc41RtZaK81pwbKYFrFL4OOiZ8TU1DrnJs57 4geN+UIGBEeYaXKJkgmGT36qxjqeSMCDyG8l7yjedo5S6tMTWB90jlV5HM5ddVzrNC/g pCrA== X-Received: by 10.42.128.84 with SMTP id l20mr4231976ics.21.1432224631446; Thu, 21 May 2015 09:10:31 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by mx.google.com with ESMTPSA id q10sm1624875ige.16.2015.05.21.09.10.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 May 2015 09:10:30 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets From: Guy Helmer In-Reply-To: Date: Thu, 21 May 2015 11:10:38 -0500 Cc: FreeBSD Net Message-Id: References: To: Christopher Forgeron X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:10:32 -0000 > On May 21, 2015, at 8:52 AM, Christopher Forgeron = wrote: >=20 > A few things: >=20 > 1) How long before you have this behaviour? >=20 > 2) What's the output of 'netstat -m' when you have the problem? >=20 > 3) What is your MTU set to, and do you have TSO on or off? >=20 > On Thu, May 21, 2015 at 10:33 AM, Guy Helmer > wrote: > I=E2=80=99ve noticed that there have been reports of problems with = Intel X520-SR2 network interfaces stopping working. I think I=E2=80=99m = seeing a similar issue where the 10Gb interfaces stop receiving traffic = (they=E2=80=99re being used in promiscuous mode to sniff traffic from a = tap). ifconfig shows the interfaces are still active and the links are = OK. ifconfig down/up restores activity. I=E2=80=99ve changed = hw.intr_storm_threshold=3D8000 but I couldn=E2=80=99t tell if the = interrupt storm threshold had been triggered at the time the interfaces = stopped passing traffic. It seems to run from hours to days without problems. I don=E2=80=99t have the output of =E2=80=9Cnetstat -m=E2=80=9D = available, but it did not indicate any mbuf or cluster allocation = failures. No jumbo clusters (4k, 9k, or 16k) were allocated. MTU is 1500. TSO is =E2=80=9Con=E2=80=9D but would seem to be irrelevant = =E2=80=94 no packets are transmitted out of these interfaces (verified = using =E2=80=9Cnetstat -i=E2=80=9D). Thanks, Guy= From owner-freebsd-net@FreeBSD.ORG Thu May 21 16:34:30 2015 Return-Path: Delivered-To: freebsd-net@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 A23295FA; Thu, 21 May 2015 16:34:30 +0000 (UTC) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 652931568; Thu, 21 May 2015 16:34:30 +0000 (UTC) Received: by obfe9 with SMTP id e9so64333013obf.1; Thu, 21 May 2015 09:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l9Bjt9PrGi3aGlWxz2r8hnzgs+aaD0AY7AYSOlQe6JI=; b=Dj9H3gcOXTgDyfRYXrVn/upO/11qhOukgSM4x3tO7TEPgkUXMU4ORtKlwsQ4xrKlcF c2FwCmgcIVsWSu6197t+0aWiaTYgX5O+CX9tznZH2A4iHM/CgX7kG1fCK6WuJ9/ZOfJq uUhnHtACXKJkPhsI3LQUpORdtemPmzu0CfAnzYQ8q1uxUUCELXDclqYhfEIotQW0b6Pz AG8y8OwkNPYpxPSUJh7DEi2+8bLd/EejHqDUwi/nSOA2pC57AJgkYhqk4xcJRlujIPd3 I/SkrbbK4K4B7An3vwOTCSo0NebQPXROZxg3Xt0jCW4ZM1kMzVwHyj2B09sj0Zton0p/ deWA== MIME-Version: 1.0 X-Received: by 10.182.70.74 with SMTP id k10mr3080050obu.2.1432226069741; Thu, 21 May 2015 09:34:29 -0700 (PDT) Received: by 10.202.216.3 with HTTP; Thu, 21 May 2015 09:34:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 19:34:29 +0300 Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: Karlis Laivins To: "K. Macy" Cc: FreeBSD Net , Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:34:30 -0000 Hi, The source of the module has netinet/tcp_var.h included, in which the variable is defined. Why it still gives me the aforementioned error? And more importantly, why did it work without problems before I recompiled the Kernel? BR, KL On Thu, May 21, 2015 at 6:45 PM, K. Macy wrote: > Your module references a variable that the kernel doesn't define. As soon > as you either define it or figure out what you should really be referencing > it as your module will load. > On May 21, 2015 3:53 AM, "Karlis Laivins" > wrote: > >> Hello again, >> >> A little update - the problem occurs only when trying to load a modified >> NewReno algorithm module. When I create a dummy module from, for example, >> Vegas implementation (with some trivial changes made besides the function >> and module names), the module can be loaded successfully. >> >> Is there a way (if no other way can be found to fix this right away), to >> trick the system into using my NewReno module instead of the one hard >> coded >> in the system? (I know, sounds silly - change the hard coded settings, >> but, >> maybe there is a way...) >> >> Thank you in advance! >> >> BR, >> Karlis >> >> On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins < >> karlis.laivins@gmail.com> >> wrote: >> >> > Hello, >> > >> > Tried both, still the same issue... >> > >> > BR, >> > KL >> > >> > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd >> wrote: >> > >> >> Hi, >> >> >> >> Try kldxref /boot/kernel >> >> >> >> If it doesn't help, try recompiling the module. >> >> >> >> >> >> -a >> >> >> >> >> >> On 20 May 2015 at 19:41, Karlis Laivins >> wrote: >> >> > Good Morning, >> >> > >> >> > I have a following issue, maybe someone has encountered this and can >> >> > provide me with a quick solution to a following issue. >> >> > >> >> > I have compiled a module, which is a modified version of the NewReno >> >> > congestion control algorithm. I tried to load it into Kernel >> >> successfully >> >> > before I recompiled Kernel with a following config file, so I can use >> >> > Imunes and test the new module: >> >> > >> >> > include GENERIC >> >> > nooptions FLOWTABLE >> >> > options VIMAGE >> >> > options VNET_DEBUG >> >> > options MROUTING >> >> > >> >> > options IPSEC >> >> > device crypto >> >> > options IPSEC_DEBUG >> >> > >> >> > options DDB >> >> > options KDB >> >> > >> >> > The problem is - after the Kernel has been reompiled, I can no longer >> >> load >> >> > the module with kldload. The error I get is: >> >> > >> >> > link_elf: symbol tcp_do_rfc3465 undefined >> >> > kldload: can't load cc_changedreno.ko: No such file or directory >> >> > >> >> > And this is despite the fact the cc_changedreno.ko module is in >> >> > /boot/kernel/. >> >> > >> >> > Thank you in advance! >> >> > >> >> > BR, >> >> > Karlis >> >> > _______________________________________________ >> >> > freebsd-net@freebsd.org mailing list >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> > To unsubscribe, send any mail to " >> freebsd-net-unsubscribe@freebsd.org" >> >> >> > >> > >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Thu May 21 18:06:00 2015 Return-Path: Delivered-To: freebsd-net@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 8F04135D; Thu, 21 May 2015 18:06:00 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 4FF381140; Thu, 21 May 2015 18:06:00 +0000 (UTC) Received: by obbnx5 with SMTP id nx5so4372112obb.0; Thu, 21 May 2015 11:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=44ZM4XgEJrQaAvtHf6iLkgurdPcPaDonLlv6UAPPbWM=; b=Xza9V5S1FopBMxUH3D3aDxMoWbE0GkycjqpFicSQvShZ0K3Pn4xt7QQ9LsnJNol4EI EP22nahnxe3odlw3K0CYNyWXg6hTtO/iOsCQ/gsyV76ws/N0waUE9U6/I0bfAfqLtQaY 7PC6VZRj4jwYywDea4LqyqfJC+QEPJpo+v97P/mwSpC+WMYEH+/KiI5QaPQQvGyaB8CK wFmK9ynbBb9fBBj9zjNdyLkzST+qvmZ+N7a1H7z4DdLn4J83LoC1qqkqRCmaywOm9nUy O0BPmHBpTXQjQqaxKizwXCszGI4ts9PXNxeynAz/tzwNyod2B+BuEq1HHmCOcLjbcGoe dljg== MIME-Version: 1.0 X-Received: by 10.182.48.231 with SMTP id p7mr3355059obn.19.1432231559673; Thu, 21 May 2015 11:05:59 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.202.21.132 with HTTP; Thu, 21 May 2015 11:05:59 -0700 (PDT) Received: by 10.202.21.132 with HTTP; Thu, 21 May 2015 11:05:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 11:05:59 -0700 X-Google-Sender-Auth: ShTGOt6uNnpkrKnNf6ykPfLBZmY Message-ID: Subject: Re: New CC modules not loading after Kernel recompilation From: "K. Macy" To: Karlis Laivins Cc: Adrian Chadd , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:06:00 -0000 On May 21, 2015 9:34 AM, "Karlis Laivins" wrote: > > Hi, > > The source of the module has netinet/tcp_var.h included, in which the variable is defined. Why it still gives me the aforementioned error? And more importantly, why did it work without problems before I recompiled the Kernel? > Headers declare variables. The variable is defined in the actual source. I can't tell what's different with the kernel before and after without more context than I'm prepared to sift through. 'nm' on the unstripped kernel will list all the symbols. So you can grep for if it's a substring of something actually defined. > BR, > KL > > On Thu, May 21, 2015 at 6:45 PM, K. Macy wrote: >> >> Your module references a variable that the kernel doesn't define. As soon as you either define it or figure out what you should really be referencing it as your module will load. >> >> On May 21, 2015 3:53 AM, "Karlis Laivins" wrote: >>> >>> Hello again, >>> >>> A little update - the problem occurs only when trying to load a modified >>> NewReno algorithm module. When I create a dummy module from, for example, >>> Vegas implementation (with some trivial changes made besides the function >>> and module names), the module can be loaded successfully. >>> >>> Is there a way (if no other way can be found to fix this right away), to >>> trick the system into using my NewReno module instead of the one hard coded >>> in the system? (I know, sounds silly - change the hard coded settings, but, >>> maybe there is a way...) >>> >>> Thank you in advance! >>> >>> BR, >>> Karlis >>> >>> On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins < karlis.laivins@gmail.com> >>> wrote: >>> >>> > Hello, >>> > >>> > Tried both, still the same issue... >>> > >>> > BR, >>> > KL >>> > >>> > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd wrote: >>> > >>> >> Hi, >>> >> >>> >> Try kldxref /boot/kernel >>> >> >>> >> If it doesn't help, try recompiling the module. >>> >> >>> >> >>> >> -a >>> >> >>> >> >>> >> On 20 May 2015 at 19:41, Karlis Laivins wrote: >>> >> > Good Morning, >>> >> > >>> >> > I have a following issue, maybe someone has encountered this and can >>> >> > provide me with a quick solution to a following issue. >>> >> > >>> >> > I have compiled a module, which is a modified version of the NewReno >>> >> > congestion control algorithm. I tried to load it into Kernel >>> >> successfully >>> >> > before I recompiled Kernel with a following config file, so I can use >>> >> > Imunes and test the new module: >>> >> > >>> >> > include GENERIC >>> >> > nooptions FLOWTABLE >>> >> > options VIMAGE >>> >> > options VNET_DEBUG >>> >> > options MROUTING >>> >> > >>> >> > options IPSEC >>> >> > device crypto >>> >> > options IPSEC_DEBUG >>> >> > >>> >> > options DDB >>> >> > options KDB >>> >> > >>> >> > The problem is - after the Kernel has been reompiled, I can no longer >>> >> load >>> >> > the module with kldload. The error I get is: >>> >> > >>> >> > link_elf: symbol tcp_do_rfc3465 undefined >>> >> > kldload: can't load cc_changedreno.ko: No such file or directory >>> >> > >>> >> > And this is despite the fact the cc_changedreno.ko module is in >>> >> > /boot/kernel/. >>> >> > >>> >> > Thank you in advance! >>> >> > >>> >> > BR, >>> >> > Karlis >>> >> > _______________________________________________ >>> >> > freebsd-net@freebsd.org mailing list >>> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> >> > To unsubscribe, send any mail to " freebsd-net-unsubscribe@freebsd.org" >>> >> >>> > >>> > >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu May 21 19:49:58 2015 Return-Path: Delivered-To: freebsd-net@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 2424663C for ; Thu, 21 May 2015 19:49:58 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 9DDCD1E41 for ; Thu, 21 May 2015 19:49:57 +0000 (UTC) Received: by lbcmx3 with SMTP id mx3so25893756lbc.1 for ; Thu, 21 May 2015 12:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9o+pQ8s6/E9igriCQGJ80oM6grEWKCLnuHaw8lEJiks=; b=opCsJ/9P7wcEJOrfEtdtctgejZkMdrcgxLuQ8lIUAZtpBHQBp1TtplWZaIehJK6CWg p8y65POaf/9hazVcfK+Jc0GlCK9L/bHCXJvdlDA3CFcL3WbIctm+WG0TKRwxun1PRfLO +4Rgxg/YHELow4IOVR8tofuj2zKw0IhKIQu5MaBNiVlL2IDd1iDu/ZE65eCeygyC5oYQ oFSJFvx40hE6ocwrHk3hCo1XoXEfyMN2zLF1TmcnutoXO7AchFj+Lvk+gt+iFNgNR/r+ Vc5GN8ZASNc3IhyBbSPvpdJITFENRWa4VViA/QxkIBP4AhYC6oepiOBeD5osn49z7xeK 4Z1A== MIME-Version: 1.0 X-Received: by 10.112.172.35 with SMTP id az3mr3388923lbc.99.1432237795622; Thu, 21 May 2015 12:49:55 -0700 (PDT) Received: by 10.152.132.135 with HTTP; Thu, 21 May 2015 12:49:55 -0700 (PDT) In-Reply-To: <1759362154.14467567.1431970844614.JavaMail.zimbra@comcast.net> References: <693283707.14467075.1431970807422.JavaMail.zimbra@comcast.net> <1759362154.14467567.1431970844614.JavaMail.zimbra@comcast.net> Date: Thu, 21 May 2015 15:49:55 -0400 Message-ID: Subject: Re: FCIP From: Joe Nosay To: rondzierwa@comcast.net Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 19:49:58 -0000 I'm not sure. We would need someone who has the time and is willing to work on this protocol. On Mon, May 18, 2015 at 1:40 PM, wrote: > > Does FreeBSD support IP over FiberChannel? > > thanks, > ron. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu May 21 20:25:50 2015 Return-Path: Delivered-To: freebsd-net@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 8B99D330 for ; Thu, 21 May 2015 20:25:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52C9B12C9 for ; Thu, 21 May 2015 20:25:50 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4LKPolh022199 for ; Thu, 21 May 2015 20:25:50 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4LKPob9022198; Thu, 21 May 2015 20:25:50 GMT (envelope-from daemon-user) Date: Thu, 21 May 2015 20:25:50 +0000 To: freebsd-net@freebsd.org From: "avg (Andriy Gapon)" Subject: [Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9) Message-ID: <719df076f7040cf32ba07538d34a712d@localhost.localdomain> X-Priority: 3 Thread-Topic: D1881: Allow Illumos code to co-exist with nv(9) X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OGQwMzFkNjQ5NDRkZTRmM2I0ZmU5NDZhMGJmIFVeP04= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:25:50 -0000 avg added a subscriber: avg. avg added a comment. This has already been committed, so I've missed the train, but I still would like to comment. And I hope that my comment won't be just a rant. So, I don't like this change for several reasons. For one, given that nv(9) is a new thing while libnvpair already existed it would have been wise to select non-conflicting names for the new interfaces. And I think that it's still not too late to do that. Then, it seems that this change has solved a theoretical problem as I don't think that currently there is any executable that links to both libraries.Perhaps I am wrong. Also, libnvpair.so was treated like a "private" library: its ABI was wildly changed but its version hasn't been bumped. Finally, from ABI point of view libnvpair now appears very inconsistent: many of its interfaces are prefixed with "illumos_" while quite a few don't have that prefix. Now, why am I interested in libnvpair? At work we have a Python module that interfaces libzfs_core and by necessity libnvpair through CFFI. The module used to work perfectly well across FreeBSD, illumos and Linux because the library interfaces on ABI level are the same (from CFFI's point of view) across platforms. After this change FreeBSD is an odd platform. I have to add a workaround to keep the module working. And even the workaround is not trivial because of the mix of prefixed and non-prefixed names. Hope you sympathize. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1881 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rstone, jfv, will Cc: avg, will, emaste, pjd, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu May 21 20:52:25 2015 Return-Path: Delivered-To: freebsd-net@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 E1E91CF8 for ; Thu, 21 May 2015 20:52:25 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4FCA1654 for ; Thu, 21 May 2015 20:52:25 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4LKqPmq030367 for ; Thu, 21 May 2015 20:52:25 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4LKqP2w030366; Thu, 21 May 2015 20:52:25 GMT (envelope-from daemon-user) Date: Thu, 21 May 2015 20:52:25 +0000 To: freebsd-net@freebsd.org From: "avg (Andriy Gapon)" Subject: [Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9) Message-ID: X-Priority: 3 Thread-Topic: D1881: Allow Illumos code to co-exist with nv(9) X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: OGQwMzFkNjQ5NDRkZTRmM2I0ZmU5NDZhMGJmIFVeRYk= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:52:26 -0000 avg added a comment. Another thought. Or was the intention only to make nv(9) and hrm.. nvpair compatible only within the kernel? Section 9 seems like a big hint here, but I am not sure. If the intention was such, then my previous comment is to inform that that change affected the userland as well. REPOSITORY rS FreeBSD src repository REVISION DETAIL https://reviews.freebsd.org/D1881 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rstone, jfv, will Cc: avg, will, emaste, pjd, freebsd-net From owner-freebsd-net@FreeBSD.ORG Thu May 21 23:16:13 2015 Return-Path: Delivered-To: freebsd-net@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 957C8C77 for ; Thu, 21 May 2015 23:16:13 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (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 605F91656 for ; Thu, 21 May 2015 23:16:13 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so22844466igb.0 for ; Thu, 21 May 2015 16:16:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Hck+qk4ZHtPuAgUrgKoFmq3KZvcIaxCSim8fMv9OYy8=; b=hcCXm2fxD8/7++pwJa/qhq7l6KKf9DhcUJyLIOBDZuCY+oYiURx1cHt1w4tsvdyTE4 Eo0G4xGe0OneXuJu6x0IG3NVIfRSVz3NwLqwDYiMGl0Hgv2z/rUBt+jk6zMywJ2H9vCx V/UgfQAg2i4xG3zuZ2wHM7mpPSmL13YOqo13xl7qcgLJ+yJ1x2kT2aC2fKSuW1DS8avP Xomb928Gh4vmgGYGO8U5PxoRiql17WJbpYo95xxhjmTSMRXyUrXLQy/rXChmLcAImjaA s0oKvA0Qr2XiwqnL4iOO0xzevNEC//9YBWxzIQYoDAKw389B0DAcMrzHEcucMA7cGf58 L1mQ== X-Received: by 10.107.133.154 with SMTP id p26mr6664827ioi.7.1432249778422; Thu, 21 May 2015 16:09:38 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com. [209.85.213.182]) by mx.google.com with ESMTPSA id j194sm280886ioe.7.2015.05.21.16.09.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 16:09:38 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so23319141igb.1 for ; Thu, 21 May 2015 16:09:37 -0700 (PDT) X-Received: by 10.42.119.142 with SMTP id b14mr6036830icr.29.1432249777922; Thu, 21 May 2015 16:09:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Joyner Date: Thu, 21 May 2015 23:09:37 +0000 Message-ID: Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets To: Guy Helmer , Christopher Forgeron Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 23:16:13 -0000 Are there any log messages printed out by the driver? The sysctls don't really look out of the ordinary, other than the number of sub-64 byte packets. On Thu, May 21, 2015 at 9:10 AM Guy Helmer wrote: > > > On May 21, 2015, at 8:52 AM, Christopher Forgeron > wrote: > > > > A few things: > > > > 1) How long before you have this behaviour? > > > > 2) What's the output of 'netstat -m' when you have the problem? > > > > 3) What is your MTU set to, and do you have TSO on or off? > > > > On Thu, May 21, 2015 at 10:33 AM, Guy Helmer > wrote: > > I=E2=80=99ve noticed that there have been reports of problems with Inte= l > X520-SR2 network interfaces stopping working. I think I=E2=80=99m seeing = a similar > issue where the 10Gb interfaces stop receiving traffic (they=E2=80=99re b= eing used > in promiscuous mode to sniff traffic from a tap). ifconfig shows the > interfaces are still active and the links are OK. ifconfig down/up restor= es > activity. I=E2=80=99ve changed hw.intr_storm_threshold=3D8000 but I could= n=E2=80=99t tell if > the interrupt storm threshold had been triggered at the time the interfac= es > stopped passing traffic. > > It seems to run from hours to days without problems. > > I don=E2=80=99t have the output of =E2=80=9Cnetstat -m=E2=80=9D available= , but it did not indicate > any mbuf or cluster allocation failures. No jumbo clusters (4k, 9k, or 16= k) > were allocated. > > MTU is 1500. TSO is =E2=80=9Con=E2=80=9D but would seem to be irrelevant = =E2=80=94 no packets are > transmitted out of these interfaces (verified using =E2=80=9Cnetstat -i= =E2=80=9D). > > Thanks, > Guy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri May 22 01:35:44 2015 Return-Path: Delivered-To: freebsd-net@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 B5EB9B95 for ; Fri, 22 May 2015 01:35:44 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A09D814A8 for ; Fri, 22 May 2015 01:35:44 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M1ZiL6064537 for ; Fri, 22 May 2015 01:35:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200379] SCTP stack is not FIB aware Date: Fri, 22 May 2015 01:35:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:35:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 Craig Rodrigues changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |tuexen@freebsd.org CC| |freebsd-net@FreeBSD.org, | |rrs@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 01:44:17 2015 Return-Path: Delivered-To: freebsd-net@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 719CBDFA for ; Fri, 22 May 2015 01:44:17 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8EF15BD for ; Fri, 22 May 2015 01:44:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M1iHUv073226 for ; Fri, 22 May 2015 01:44:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200379] SCTP stack is not FIB aware Date: Fri, 22 May 2015 01:44:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:44:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #1 from Craig Rodrigues --- Created attachment 157024 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157024&action=edit server.c -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 01:44:42 2015 Return-Path: Delivered-To: freebsd-net@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 C382AE8E for ; Fri, 22 May 2015 01:44:42 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADEEF15CA for ; Fri, 22 May 2015 01:44:42 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M1igWc073328 for ; Fri, 22 May 2015 01:44:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200379] SCTP stack is not FIB aware Date: Fri, 22 May 2015 01:44:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:44:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #2 from Craig Rodrigues --- Created attachment 157025 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157025&action=edit client.c -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 01:49:52 2015 Return-Path: Delivered-To: freebsd-net@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 77901FED for ; Fri, 22 May 2015 01:49:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 61ED915FD for ; Fri, 22 May 2015 01:49:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M1nqY5075062 for ; Fri, 22 May 2015 01:49:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200379] SCTP stack is not FIB aware Date: Fri, 22 May 2015 01:49:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rodrigc@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:49:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #3 from Craig Rodrigues --- In sys/netinet/sctp_os_bsd.h , the SCTP_RTALLOC macro calls the rtalloc_ign() function which ignores fibs. It should probably be changed to call rtalloc_ign_fib() In addition, it may be necessary to store the fib_num in the inp and inherit it when accepting/peelingoff. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 04:23:01 2015 Return-Path: Delivered-To: net@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 56922364 for ; Fri, 22 May 2015 04:23:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40EB51607 for ; Fri, 22 May 2015 04:23:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M4N1Os023364 for ; Fri, 22 May 2015 04:23:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 200382] Loading netgraph via bsnmpd, etc can cause domain to be registered after domain_finalize has been called Date: Fri, 22 May 2015 04:23:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ngie@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 04:23:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200382 Garrett Cooper,425-314-3911 changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |net@FreeBSD.org --- Comment #1 from Garrett Cooper,425-314-3911 --- I'm not entirely sure if bsnmpd will load netgraph automatically, BUT if you load netgraph before you start bsnmpd, it might also repro this issue... -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 07:46:01 2015 Return-Path: Delivered-To: freebsd-net@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 520EB929 for ; Fri, 22 May 2015 07:46:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2D01BDE for ; Fri, 22 May 2015 07:46:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M7k1LP081475 for ; Fri, 22 May 2015 07:46:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200379] SCTP stack is not FIB aware Date: Fri, 22 May 2015 07:46:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tuexen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tuexen@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 07:46:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379 --- Comment #4 from Michael Tuexen --- Hi Craig, thank you very much for reporting the issue and providing steps to reproduce the problem. I'll look into it. Best regards Michael -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 09:48:36 2015 Return-Path: Delivered-To: freebsd-net@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 3FD8FC9 for ; Fri, 22 May 2015 09:48:36 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2892A1B03 for ; Fri, 22 May 2015 09:48:36 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4M9mab9014372 for ; Fri, 22 May 2015 09:48:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 148807] [panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" Date: Fri, 22 May 2015 09:48:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sebastian.huber@embedded-brains.de X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 09:48:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 --- Comment #19 from sebastian.huber@embedded-brains.de --- (In reply to sebastian.huber from comment #18) I found one problem with the driver. In the RTEMS port of the network stack I don't use the BUS_DMA(9) support and instead directly use cache invalidate/flush routines (the Altera Cyclone V has no automatic cache coherency between the Ethernet module and the processors). In the receive path it was done like this: invalidate buffer (mcluster) register buffer in receive DMA descriptor ... DMA done hand over buffer to interface input It seems that due to a cache line prefetch sometimes cache lines of the buffer are loaded to the cache after the invalidate, but before the receive DMA completed its transfers. I changed the sequence like this: invalidate buffer (mcluster) register buffer in receive DMA descriptor ... DMA done invalidate buffer hand over buffer to interface input Now it works very stable and I didn't observe a mbuf or socketbuf corruption any more. So as an off hand guess it seems in case the network stack is presented with partially invalid data (previously received IP and TCP headers mixed with new data most likely), then this could lead to a crash in the TCP input processing. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 15:21:31 2015 Return-Path: Delivered-To: freebsd-net@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 CC3644F0; Fri, 22 May 2015 15:21:31 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::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 90C7D130D; Fri, 22 May 2015 15:21:31 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so38853261igb.0; Fri, 22 May 2015 08:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZLAaeDd8x9nV7CdE9A0VBtf5zvJ/FZSK2Xt9bJqmzgc=; b=GGwoPVSk7eYzYLhcWg8WJszZcwUs1QSITGG6Gf2B5+VRP4Mz8zys3HTLQ0mcuToUr6 BU/5E6e8JKamzd0SJnkFH7wGeohcurYWYMuS+eTiORDmUwcv53KzBarOXsKxbN1bhCj3 Ot0EelxXxBvP7stQ8QoO1drGY08cI0PDcuR6/aABnscg1wIn2k4Uz4uPPTROZIKJ42xV 1Q53owZye6Pu0iyVBXJUaw8vBNLbV2Z4lAe7myvQj6hZLM2V521QIaU9DsXbv8eSMQEs 4elNvtMRKSBS+uXzawB/UtqRPrqZr54u6F6ne0bIz+H8SBylWpuiKmeTfzhclXHmUSTv i4AA== X-Received: by 10.107.133.154 with SMTP id p26mr11397581ioi.7.1432308091027; Fri, 22 May 2015 08:21:31 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by mx.google.com with ESMTPSA id p4sm4014113igg.20.2015.05.22.08.21.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 May 2015 08:21:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets From: Guy Helmer In-Reply-To: Date: Fri, 22 May 2015 10:21:41 -0500 Cc: Christopher Forgeron , FreeBSD Net Message-Id: References: To: Eric Joyner X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:21:32 -0000 > On May 21, 2015, at 6:09 PM, Eric Joyner wrote: >=20 > Are there any log messages printed out by the driver? The sysctls = don't really look out of the ordinary, other than the number of sub-64 = byte packets. Not that I could tell =E2=80=94 grep of /var/log/messages and the text = from the rotated messages.*.gz logs yielded nothing. Guy >=20 > On Thu, May 21, 2015 at 9:10 AM Guy Helmer > wrote: >=20 > > On May 21, 2015, at 8:52 AM, Christopher Forgeron = > wrote: > > > > A few things: > > > > 1) How long before you have this behaviour? > > > > 2) What's the output of 'netstat -m' when you have the problem? > > > > 3) What is your MTU set to, and do you have TSO on or off? > > > > On Thu, May 21, 2015 at 10:33 AM, Guy Helmer >> wrote: > > I=E2=80=99ve noticed that there have been reports of problems with = Intel X520-SR2 network interfaces stopping working. I think I=E2=80=99m = seeing a similar issue where the 10Gb interfaces stop receiving traffic = (they=E2=80=99re being used in promiscuous mode to sniff traffic from a = tap). ifconfig shows the interfaces are still active and the links are = OK. ifconfig down/up restores activity. I=E2=80=99ve changed = hw.intr_storm_threshold=3D8000 but I couldn=E2=80=99t tell if the = interrupt storm threshold had been triggered at the time the interfaces = stopped passing traffic. >=20 > It seems to run from hours to days without problems. >=20 > I don=E2=80=99t have the output of =E2=80=9Cnetstat -m=E2=80=9D = available, but it did not indicate any mbuf or cluster allocation = failures. No jumbo clusters (4k, 9k, or 16k) were allocated. >=20 > MTU is 1500. TSO is =E2=80=9Con=E2=80=9D but would seem to be = irrelevant =E2=80=94 no packets are transmitted out of these interfaces = (verified using =E2=80=9Cnetstat -i=E2=80=9D). >=20 > Thanks, > Guy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net = > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org = " From owner-freebsd-net@FreeBSD.ORG Fri May 22 16:48:14 2015 Return-Path: Delivered-To: freebsd-net@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 29F2A1D4; Fri, 22 May 2015 16:48:14 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 E19231D87; Fri, 22 May 2015 16:48:13 +0000 (UTC) Received: by iepj10 with SMTP id j10so35338287iep.3; Fri, 22 May 2015 09:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=yHntIgapTmjXTMIdN9mfQCX3bIfmnwkTzUdsKkKvvBI=; b=jR8M2pf5BeTHKdpr1q09V4+QXSFieYU/ibSKO1w+lKpDbskRnN/3F28OA3+QItu4a2 NL76h2seDvUjtsMg/JwFYAw7R6wS1O2tJg99OHdreqYiyrOCi2A4aBhk3NAwRev1Oksh HIC+qk5tSd2wqqYUug/dgQbLuk9xpfNIHQbMqbWmvIikBbKSPvuwQv1omjyAM5I/0KEN z4ta4mPtVBf2eLlmILTIwG6j3u5XrDoNoMpvLO2ke7s9BCoTlrXp8lnwtfv4U4v7ML90 s3zpuiSgPpYHJM4FiYiT82OGYXbbLEIk/jTDMA2qedN+780nW2YgqwERJ5AUMiGaLq4n /o2A== X-Received: by 10.107.34.140 with SMTP id i134mr10136539ioi.88.1432313293176; Fri, 22 May 2015 09:48:13 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by mx.google.com with ESMTPSA id k37sm2131599iod.39.2015.05.22.09.48.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 May 2015 09:48:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets From: Guy Helmer In-Reply-To: Date: Fri, 22 May 2015 11:48:23 -0500 Cc: Christopher Forgeron , FreeBSD Net Message-Id: References: To: Eric Joyner X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 16:48:14 -0000 > On May 22, 2015, at 10:21 AM, Guy Helmer wrote: >=20 >=20 >> On May 21, 2015, at 6:09 PM, Eric Joyner > wrote: >>=20 >> Are there any log messages printed out by the driver? The sysctls = don't really look out of the ordinary, other than the number of sub-64 = byte packets. >=20 > Not that I could tell =E2=80=94 grep of /var/log/messages and the text = from the rotated messages.*.gz logs yielded nothing. >=20 > Guy This is interesting - I was not looking at the Ierrs or Idrop columns of = netstat before, but as the problem has recurred, I=E2=80=99ve found = it=E2=80=99s dropping nearly all packets received on the ix interfaces: > netstat -i Name Mtu Network Address Ipkts Ierrs Idrop = Opkts Oerrs Coll ix0 1500 90:e2:ba:35:aa:8c 8310484539 3913 16255003933 = 0 0 0 ix0 1500 fe80::92e2:ba fe80::92e2:baff:f 0 - - = 0 - - ix1 1500 90:e2:ba:35:aa:8d 6897310372 58387379 = 8207969523 0 0 0 ix1 1500 fe80::92e2:ba fe80::92e2:baff:f 0 - - = 0 - - > netstat -i Name Mtu Network Address Ipkts Ierrs Idrop = Opkts Oerrs Coll ix0 1500 90:e2:ba:35:aa:8c 8310484538 3920 16299121753 = 0 0 0 ix0 1500 fe80::92e2:ba fe80::92e2:baff:f 0 - - = 0 - - ix1 1500 90:e2:ba:35:aa:8d 6897310369 58470675 = 8237532419 0 0 0 ix1 1500 fe80::92e2:ba fe80::92e2:baff:f 0 - - = 0 - - # vmstat -z =E2=80=94 related to mbufs: ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP mbuf_packet: 256, 12982305, 38834, = 5203,9171090979,196374, 0 mbuf: 256, 12982305, 3, 167430,8518885166, 0, = 0 mbuf_cluster: 2048, 262144, 44037, = 9849,70443362,399118,892109 mbuf_jumbo_page: 4096, 1014242, 0, 4619, 9721759, 0, = 0 mbuf_jumbo_9k: 9216, 300516, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 169040, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 # vmstat -z | grep mbuf mbuf_packet: 256, 12982305, 38834, = 5203,9171103748,196374, 0 mbuf: 256, 12982305, 5, 167428,8518902143, 0, = 0 mbuf_cluster: 2048, 262144, 44037, = 9849,70443362,399118,892109 mbuf_jumbo_page: 4096, 1014242, 0, 4747, 9721896, 0, = 0 mbuf_jumbo_9k: 9216, 300516, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 169040, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 No interface errors logging in /var/log/messages=E2=80=A6 ifconfig down / ifconfig up on the ix0 and ix1 interfaces gets traffic = flowing again. Guy >=20 >>=20 >> On Thu, May 21, 2015 at 9:10 AM Guy Helmer > wrote: >>=20 >> > On May 21, 2015, at 8:52 AM, Christopher Forgeron = > wrote: >> > >> > A few things: >> > >> > 1) How long before you have this behaviour? >> > >> > 2) What's the output of 'netstat -m' when you have the problem? >> > >> > 3) What is your MTU set to, and do you have TSO on or off? >> > >> > On Thu, May 21, 2015 at 10:33 AM, Guy Helmer >> wrote: >> > I=E2=80=99ve noticed that there have been reports of problems with = Intel X520-SR2 network interfaces stopping working. I think I=E2=80=99m = seeing a similar issue where the 10Gb interfaces stop receiving traffic = (they=E2=80=99re being used in promiscuous mode to sniff traffic from a = tap). ifconfig shows the interfaces are still active and the links are = OK. ifconfig down/up restores activity. I=E2=80=99ve changed = hw.intr_storm_threshold=3D8000 but I couldn=E2=80=99t tell if the = interrupt storm threshold had been triggered at the time the interfaces = stopped passing traffic. >>=20 >> It seems to run from hours to days without problems. >>=20 >> I don=E2=80=99t have the output of =E2=80=9Cnetstat -m=E2=80=9D = available, but it did not indicate any mbuf or cluster allocation = failures. No jumbo clusters (4k, 9k, or 16k) were allocated. >>=20 >> MTU is 1500. TSO is =E2=80=9Con=E2=80=9D but would seem to be = irrelevant =E2=80=94 no packets are transmitted out of these interfaces = (verified using =E2=80=9Cnetstat -i=E2=80=9D). >>=20 >> Thanks, >> Guy >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net = >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org = " >=20 From owner-freebsd-net@FreeBSD.ORG Fri May 22 17:02:26 2015 Return-Path: Delivered-To: freebsd-net@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 E24A56F2 for ; Fri, 22 May 2015 17:02:26 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCFD11F73 for ; Fri, 22 May 2015 17:02:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4MH2Qfi072075 for ; Fri, 22 May 2015 17:02:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199716] em doesn't increment adapter->rx_overruns in msix mode Date: Fri, 22 May 2015 17:02:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:02:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: sbruno Date: Fri May 22 17:01:44 UTC 2015 New revision: 283290 URL: https://svnweb.freebsd.org/changeset/base/283290 Log: Bump rx_overruns when indicated by the ICR mask. PR: 199716 MFC after: 3 days Sponsored by: Limelight Networks Changes: head/sys/dev/e1000/if_em.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri May 22 17:02:56 2015 Return-Path: Delivered-To: freebsd-net@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 72927791 for ; Fri, 22 May 2015 17:02:56 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D84E1F8E for ; Fri, 22 May 2015 17:02:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4MH2uiX072227 for ; Fri, 22 May 2015 17:02:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199716] em doesn't increment adapter->rx_overruns in msix mode Date: Fri, 22 May 2015 17:02:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: sbruno@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:02:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 Sean Bruno changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat May 23 12:48:23 2015 Return-Path: Delivered-To: freebsd-net@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 A9D40740 for ; Sat, 23 May 2015 12:48:23 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 949D71BDE for ; Sat, 23 May 2015 12:48:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4NCmNHv069914 for ; Sat, 23 May 2015 12:48:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200221] em0 watchdog timeout under load Date: Sat, 23 May 2015 12:48:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: anthony@ury.org.uk X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 12:48:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221 --- Comment #5 from anthony@ury.org.uk --- It's now been a week, disabling tso4 does seem to have resolved this. What could be the reason for this now being required? As mentioned, I don't recall this happening before it was upgraded to 10.1-RELEASE (previously 10.0-RELEASE). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat May 23 18:20:11 2015 Return-Path: Delivered-To: freebsd-net@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 08B8D554 for ; Sat, 23 May 2015 18:20:11 +0000 (UTC) Received: from mail.imenpardis.com (mail.imenpardis.com [188.121.128.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E60EA1D50 for ; Sat, 23 May 2015 18:20:09 +0000 (UTC) Received: from swordfish.local (unknown [31.59.224.177]) (Authenticated sender: babak@farrokhi.net) by mail.imenpardis.com (Postfix) with ESMTPA id 4BFB234CD66; Sat, 23 May 2015 22:44:48 +0430 (IRDT) Message-ID: <5560C395.8020807@farrokhi.net> Date: Sat, 23 May 2015 22:44:45 +0430 From: Babak Farrokhi User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Guy Helmer CC: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 18:20:11 -0000 Look at the interrupts per queue. 500,000 is the maximum and it is the reason your interface is not accepting new packets. > Guy Helmer > May 21, 2015 at 6:03 PM > I’ve noticed that there have been reports of problems with Intel > X520-SR2 network interfaces stopping working. I think I’m seeing a > similar issue where the 10Gb interfaces stop receiving traffic > (they’re being used in promiscuous mode to sniff traffic from a tap). > ifconfig shows the interfaces are still active and the links are OK. > ifconfig down/up restores activity. I’ve changed > hw.intr_storm_threshold=8000 but I couldn’t tell if the interrupt > storm threshold had been triggered at the time the interfaces stopped > passing traffic. > > Output from sysctl: > > # sysctl dev.ix.0 > dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version > - 2.5.15 > dev.ix.0.%driver: ix > dev.ix.0.%location: slot=0 function=0 > dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > subdevice=0x0003 class=0x020000 > dev.ix.0.%parent: pci4 > dev.ix.0.fc: 0 > dev.ix.0.enable_aim: 1 > dev.ix.0.advertise_speed: 0 > dev.ix.0.dropped: 0 > dev.ix.0.mbuf_defrag_failed: 0 > dev.ix.0.watchdog_events: 0 > dev.ix.0.link_irq: 3 > dev.ix.0.queue0.interrupt_rate: 500000 > dev.ix.0.queue0.irqs: 454449470 > dev.ix.0.queue0.txd_head: 0 > dev.ix.0.queue0.txd_tail: 0 > dev.ix.0.queue0.tso_tx: 0 > dev.ix.0.queue0.no_tx_dma_setup: 0 > dev.ix.0.queue0.no_desc_avail: 0 > dev.ix.0.queue0.tx_packets: 0 > dev.ix.0.queue0.rxd_head: 1437 > dev.ix.0.queue0.rxd_tail: 1436 > dev.ix.0.queue0.rx_packets: 547499168 > dev.ix.0.queue0.rx_bytes: 87201112584 > dev.ix.0.queue0.rx_copies: 7934870 > dev.ix.0.queue0.lro_queued: 0 > dev.ix.0.queue0.lro_flushed: 0 > dev.ix.0.queue1.interrupt_rate: 500000 > dev.ix.0.queue1.irqs: 466235043 > dev.ix.0.queue1.txd_head: 0 > dev.ix.0.queue1.txd_tail: 0 > dev.ix.0.queue1.tso_tx: 0 > dev.ix.0.queue1.no_tx_dma_setup: 0 > dev.ix.0.queue1.no_desc_avail: 0 > dev.ix.0.queue1.tx_packets: 0 > dev.ix.0.queue1.rxd_head: 277 > dev.ix.0.queue1.rxd_tail: 276 > dev.ix.0.queue1.rx_packets: 547668680 > dev.ix.0.queue1.rx_bytes: 86205679601 > dev.ix.0.queue1.rx_copies: 7846653 > dev.ix.0.queue1.lro_queued: 0 > dev.ix.0.queue1.lro_flushed: 0 > dev.ix.0.queue2.interrupt_rate: 500000 > dev.ix.0.queue2.irqs: 473958473 > dev.ix.0.queue2.txd_head: 0 > dev.ix.0.queue2.txd_tail: 0 > dev.ix.0.queue2.tso_tx: 0 > dev.ix.0.queue2.no_tx_dma_setup: 0 > dev.ix.0.queue2.no_desc_avail: 0 > dev.ix.0.queue2.tx_packets: 0 > dev.ix.0.queue2.rxd_head: 576 > dev.ix.0.queue2.rxd_tail: 575 > dev.ix.0.queue2.rx_packets: 555704840 > dev.ix.0.queue2.rx_bytes: 87294164455 > dev.ix.0.queue2.rx_copies: 8297211 > dev.ix.0.queue2.lro_queued: 0 > dev.ix.0.queue2.lro_flushed: 0 > dev.ix.0.queue3.interrupt_rate: 500000 > dev.ix.0.queue3.irqs: 477587504 > dev.ix.0.queue3.txd_head: 0 > dev.ix.0.queue3.txd_tail: 0 > dev.ix.0.queue3.tso_tx: 0 > dev.ix.0.queue3.no_tx_dma_setup: 0 > dev.ix.0.queue3.no_desc_avail: 0 > dev.ix.0.queue3.tx_packets: 0 > dev.ix.0.queue3.rxd_head: 267 > dev.ix.0.queue3.rxd_tail: 266 > dev.ix.0.queue3.rx_packets: 559921557 > dev.ix.0.queue3.rx_bytes: 86832161258 > dev.ix.0.queue3.rx_copies: 7918011 > dev.ix.0.queue3.lro_queued: 0 > dev.ix.0.queue3.lro_flushed: 0 > dev.ix.0.queue4.interrupt_rate: 500000 > dev.ix.0.queue4.irqs: 558339677 > dev.ix.0.queue4.txd_head: 0 > dev.ix.0.queue4.txd_tail: 0 > dev.ix.0.queue4.tso_tx: 0 > dev.ix.0.queue4.no_tx_dma_setup: 0 > dev.ix.0.queue4.no_desc_avail: 0 > dev.ix.0.queue4.tx_packets: 0 > dev.ix.0.queue4.rxd_head: 1240 > dev.ix.0.queue4.rxd_tail: 1239 > dev.ix.0.queue4.rx_packets: 646909190 > dev.ix.0.queue4.rx_bytes: 87117307815 > dev.ix.0.queue4.rx_copies: 7944848 > dev.ix.0.queue4.lro_queued: 0 > dev.ix.0.queue4.lro_flushed: 0 > dev.ix.0.queue5.interrupt_rate: 500000 > dev.ix.0.queue5.irqs: 467836647 > dev.ix.0.queue5.txd_head: 0 > dev.ix.0.queue5.txd_tail: 0 > dev.ix.0.queue5.tso_tx: 0 > dev.ix.0.queue5.no_tx_dma_setup: 0 > dev.ix.0.queue5.no_desc_avail: 0 > dev.ix.0.queue5.tx_packets: 0 > dev.ix.0.queue5.rxd_head: 1411 > dev.ix.0.queue5.rxd_tail: 1410 > dev.ix.0.queue5.rx_packets: 549666835 > dev.ix.0.queue5.rx_bytes: 84671540121 > dev.ix.0.queue5.rx_copies: 8258025 > dev.ix.0.queue5.lro_queued: 0 > dev.ix.0.queue5.lro_flushed: 0 > dev.ix.0.queue6.interrupt_rate: 500000 > dev.ix.0.queue6.irqs: 490798561 > dev.ix.0.queue6.txd_head: 0 > dev.ix.0.queue6.txd_tail: 0 > dev.ix.0.queue6.tso_tx: 0 > dev.ix.0.queue6.no_tx_dma_setup: 0 > dev.ix.0.queue6.no_desc_avail: 0 > dev.ix.0.queue6.tx_packets: 0 > dev.ix.0.queue6.rxd_head: 160 > dev.ix.0.queue6.rxd_tail: 159 > dev.ix.0.queue6.rx_packets: 590187606 > dev.ix.0.queue6.rx_bytes: 92115960421 > dev.ix.0.queue6.rx_copies: 8262802 > dev.ix.0.queue6.lro_queued: 0 > dev.ix.0.queue6.lro_flushed: 0 > dev.ix.0.queue7.interrupt_rate: 500000 > dev.ix.0.queue7.irqs: 471051540 > dev.ix.0.queue7.txd_head: 0 > dev.ix.0.queue7.txd_tail: 0 > dev.ix.0.queue7.tso_tx: 0 > dev.ix.0.queue7.no_tx_dma_setup: 0 > dev.ix.0.queue7.no_desc_avail: 0 > dev.ix.0.queue7.tx_packets: 0 > dev.ix.0.queue7.rxd_head: 640 > dev.ix.0.queue7.rxd_tail: 639 > dev.ix.0.queue7.rx_packets: 553362982 > dev.ix.0.queue7.rx_bytes: 84470102891 > dev.ix.0.queue7.rx_copies: 7954102 > dev.ix.0.queue7.lro_queued: 0 > dev.ix.0.queue7.lro_flushed: 0 > dev.ix.0.mac_stats.crc_errs: 2091 > dev.ix.0.mac_stats.ill_errs: 26 > dev.ix.0.mac_stats.byte_errs: 140 > dev.ix.0.mac_stats.short_discards: 0 > dev.ix.0.mac_stats.local_faults: 0 > dev.ix.0.mac_stats.remote_faults: 0 > dev.ix.0.mac_stats.rec_len_errs: 0 > dev.ix.0.mac_stats.xon_txd: 0 > dev.ix.0.mac_stats.xon_recvd: 0 > dev.ix.0.mac_stats.xoff_txd: 0 > dev.ix.0.mac_stats.xoff_recvd: 0 > dev.ix.0.mac_stats.total_octets_rcvd: 17956217280225 > dev.ix.0.mac_stats.good_octets_rcvd: 17945313085409 > dev.ix.0.mac_stats.total_pkts_rcvd: 15243381335 > dev.ix.0.mac_stats.good_pkts_rcvd: 4550864350 > dev.ix.0.mac_stats.mcast_pkts_rcvd: 0 > dev.ix.0.mac_stats.bcast_pkts_rcvd: 0 > dev.ix.0.mac_stats.rx_frames_64: 721599526 > dev.ix.0.mac_stats.rx_frames_65_127: 950131946 > dev.ix.0.mac_stats.rx_frames_128_255: 918463009 > dev.ix.0.mac_stats.rx_frames_256_511: 291858186 > dev.ix.0.mac_stats.rx_frames_512_1023: 237479208 > dev.ix.0.mac_stats.rx_frames_1024_1522: 12114578925 > dev.ix.0.mac_stats.recv_undersized: 0 > dev.ix.0.mac_stats.recv_fragmented: 0 > dev.ix.0.mac_stats.recv_oversized: 0 > dev.ix.0.mac_stats.recv_jabberd: 5 > dev.ix.0.mac_stats.management_pkts_rcvd: 0 > dev.ix.0.mac_stats.management_pkts_drpd: 0 > dev.ix.0.mac_stats.checksum_errs: 4379061 > dev.ix.0.mac_stats.good_octets_txd: 0 > dev.ix.0.mac_stats.total_pkts_txd: 0 > dev.ix.0.mac_stats.good_pkts_txd: 0 > dev.ix.0.mac_stats.bcast_pkts_txd: 0 > dev.ix.0.mac_stats.mcast_pkts_txd: 0 > dev.ix.0.mac_stats.management_pkts_txd: 0 > dev.ix.0.mac_stats.tx_frames_64: 0 > dev.ix.0.mac_stats.tx_frames_65_127: 0 > dev.ix.0.mac_stats.tx_frames_128_255: 0 > dev.ix.0.mac_stats.tx_frames_256_511: 0 > dev.ix.0.mac_stats.tx_frames_512_1023: 0 > dev.ix.0.mac_stats.tx_frames_1024_1522: 0 > > # sysctl dev.ix.1 > dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version > - 2.5.15 > dev.ix.1.%driver: ix > dev.ix.1.%location: slot=0 function=1 > dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > subdevice=0x0003 class=0x020000 > dev.ix.1.%parent: pci4 > dev.ix.1.fc: 0 > dev.ix.1.enable_aim: 1 > dev.ix.1.advertise_speed: 0 > dev.ix.1.dropped: 0 > dev.ix.1.mbuf_defrag_failed: 0 > dev.ix.1.watchdog_events: 0 > dev.ix.1.link_irq: 3 > dev.ix.1.queue0.interrupt_rate: 500000 > dev.ix.1.queue0.irqs: 537134504 > dev.ix.1.queue0.txd_head: 0 > dev.ix.1.queue0.txd_tail: 0 > dev.ix.1.queue0.tso_tx: 0 > dev.ix.1.queue0.no_tx_dma_setup: 0 > dev.ix.1.queue0.no_desc_avail: 0 > dev.ix.1.queue0.tx_packets: 0 > dev.ix.1.queue0.rxd_head: 1757 > dev.ix.1.queue0.rxd_tail: 1756 > dev.ix.1.queue0.rx_packets: 565486932 > dev.ix.1.queue0.rx_bytes: 7763122874 > dev.ix.1.queue0.rx_copies: 40953968 > dev.ix.1.queue0.lro_queued: 0 > dev.ix.1.queue0.lro_flushed: 0 > dev.ix.1.queue1.interrupt_rate: 500000 > dev.ix.1.queue1.irqs: 561383741 > dev.ix.1.queue1.txd_head: 0 > dev.ix.1.queue1.txd_tail: 0 > dev.ix.1.queue1.tso_tx: 0 > dev.ix.1.queue1.no_tx_dma_setup: 0 > dev.ix.1.queue1.no_desc_avail: 0 > dev.ix.1.queue1.tx_packets: 0 > dev.ix.1.queue1.rxd_head: 138 > dev.ix.1.queue1.rxd_tail: 137 > dev.ix.1.queue1.rx_packets: 577262064 > dev.ix.1.queue1.rx_bytes: 8709306631 > dev.ix.1.queue1.rx_copies: 40844466 > dev.ix.1.queue1.lro_queued: 0 > dev.ix.1.queue1.lro_flushed: 0 > dev.ix.1.queue2.interrupt_rate: 500000 > dev.ix.1.queue2.irqs: 547852317 > dev.ix.1.queue2.txd_head: 0 > dev.ix.1.queue2.txd_tail: 0 > dev.ix.1.queue2.tso_tx: 0 > dev.ix.1.queue2.no_tx_dma_setup: 0 > dev.ix.1.queue2.no_desc_avail: 0 > dev.ix.1.queue2.tx_packets: 0 > dev.ix.1.queue2.rxd_head: 386 > dev.ix.1.queue2.rxd_tail: 385 > dev.ix.1.queue2.rx_packets: 562301518 > dev.ix.1.queue2.rx_bytes: 6698895889 > dev.ix.1.queue2.rx_copies: 40867897 > dev.ix.1.queue2.lro_queued: 0 > dev.ix.1.queue2.lro_flushed: 0 > dev.ix.1.queue3.interrupt_rate: 500000 > dev.ix.1.queue3.irqs: 551254360 > dev.ix.1.queue3.txd_head: 0 > dev.ix.1.queue3.txd_tail: 0 > dev.ix.1.queue3.tso_tx: 0 > dev.ix.1.queue3.no_tx_dma_setup: 0 > dev.ix.1.queue3.no_desc_avail: 0 > dev.ix.1.queue3.tx_packets: 0 > dev.ix.1.queue3.rxd_head: 1446 > dev.ix.1.queue3.rxd_tail: 1445 > dev.ix.1.queue3.rx_packets: 566052657 > dev.ix.1.queue3.rx_bytes: 8010009389 > dev.ix.1.queue3.rx_copies: 41116971 > dev.ix.1.queue3.lro_queued: 0 > dev.ix.1.queue3.lro_flushed: 0 > dev.ix.1.queue4.interrupt_rate: 500000 > dev.ix.1.queue4.irqs: 546581703 > dev.ix.1.queue4.txd_head: 0 > dev.ix.1.queue4.txd_tail: 0 > dev.ix.1.queue4.tso_tx: 0 > dev.ix.1.queue4.no_tx_dma_setup: 0 > dev.ix.1.queue4.no_desc_avail: 0 > dev.ix.1.queue4.tx_packets: 0 > dev.ix.1.queue4.rxd_head: 965 > dev.ix.1.queue4.rxd_tail: 964 > dev.ix.1.queue4.rx_packets: 561519824 > dev.ix.1.queue4.rx_bytes: 7656671816 > dev.ix.1.queue4.rx_copies: 41183608 > dev.ix.1.queue4.lro_queued: 0 > dev.ix.1.queue4.lro_flushed: 0 > dev.ix.1.queue5.interrupt_rate: 500000 > dev.ix.1.queue5.irqs: 557099892 > dev.ix.1.queue5.txd_head: 0 > dev.ix.1.queue5.txd_tail: 0 > dev.ix.1.queue5.tso_tx: 0 > dev.ix.1.queue5.no_tx_dma_setup: 0 > dev.ix.1.queue5.no_desc_avail: 0 > dev.ix.1.queue5.tx_packets: 0 > dev.ix.1.queue5.rxd_head: 1788 > dev.ix.1.queue5.rxd_tail: 1787 > dev.ix.1.queue5.rx_packets: 572588639 > dev.ix.1.queue5.rx_bytes: 7259699024 > dev.ix.1.queue5.rx_copies: 43207640 > dev.ix.1.queue5.lro_queued: 0 > dev.ix.1.queue5.lro_flushed: 0 > dev.ix.1.queue6.interrupt_rate: 500000 > dev.ix.1.queue6.irqs: 574139280 > dev.ix.1.queue6.txd_head: 0 > dev.ix.1.queue6.txd_tail: 0 > dev.ix.1.queue6.tso_tx: 0 > dev.ix.1.queue6.no_tx_dma_setup: 0 > dev.ix.1.queue6.no_desc_avail: 0 > dev.ix.1.queue6.tx_packets: 0 > dev.ix.1.queue6.rxd_head: 45 > dev.ix.1.queue6.rxd_tail: 44 > dev.ix.1.queue6.rx_packets: 589160795 > dev.ix.1.queue6.rx_bytes: 7475849844 > dev.ix.1.queue6.rx_copies: 40589940 > dev.ix.1.queue6.lro_queued: 0 > dev.ix.1.queue6.lro_flushed: 0 > dev.ix.1.queue7.interrupt_rate: 500000 > dev.ix.1.queue7.irqs: 552769977 > dev.ix.1.queue7.txd_head: 0 > dev.ix.1.queue7.txd_tail: 0 > dev.ix.1.queue7.tso_tx: 0 > dev.ix.1.queue7.no_tx_dma_setup: 0 > dev.ix.1.queue7.no_desc_avail: 0 > dev.ix.1.queue7.tx_packets: 0 > dev.ix.1.queue7.rxd_head: 1050 > dev.ix.1.queue7.rxd_tail: 1049 > dev.ix.1.queue7.rx_packets: 567580543 > dev.ix.1.queue7.rx_bytes: 7210216689 > dev.ix.1.queue7.rx_copies: 41856967 > dev.ix.1.queue7.lro_queued: 0 > dev.ix.1.queue7.lro_flushed: 0 > dev.ix.1.mac_stats.crc_errs: 40044743 > dev.ix.1.mac_stats.ill_errs: 4347098 > dev.ix.1.mac_stats.byte_errs: 7192103 > dev.ix.1.mac_stats.short_discards: 49169 > dev.ix.1.mac_stats.local_faults: 0 > dev.ix.1.mac_stats.remote_faults: 0 > dev.ix.1.mac_stats.rec_len_errs: 41772 > dev.ix.1.mac_stats.xon_txd: 0 > dev.ix.1.mac_stats.xon_recvd: 0 > dev.ix.1.mac_stats.xoff_txd: 0 > dev.ix.1.mac_stats.xoff_recvd: 0 > dev.ix.1.mac_stats.total_octets_rcvd: 1741353301146 > dev.ix.1.mac_stats.good_octets_rcvd: 1704100700961 > dev.ix.1.mac_stats.total_pkts_rcvd: 9354020520 > dev.ix.1.mac_stats.good_pkts_rcvd: 4561867527 > dev.ix.1.mac_stats.mcast_pkts_rcvd: 139746 > dev.ix.1.mac_stats.bcast_pkts_rcvd: 0 > dev.ix.1.mac_stats.rx_frames_64: 3314959123 > dev.ix.1.mac_stats.rx_frames_65_127: 4610233544 > dev.ix.1.mac_stats.rx_frames_128_255: 256517169 > dev.ix.1.mac_stats.rx_frames_256_511: 304326606 > dev.ix.1.mac_stats.rx_frames_512_1023: 223999237 > dev.ix.1.mac_stats.rx_frames_1024_1522: 591102680 > dev.ix.1.mac_stats.recv_undersized: 0 > dev.ix.1.mac_stats.recv_fragmented: 0 > dev.ix.1.mac_stats.recv_oversized: 0 > dev.ix.1.mac_stats.recv_jabberd: 71008 > dev.ix.1.mac_stats.management_pkts_rcvd: 0 > dev.ix.1.mac_stats.management_pkts_drpd: 0 > dev.ix.1.mac_stats.checksum_errs: 3901883 > dev.ix.1.mac_stats.good_octets_txd: 0 > dev.ix.1.mac_stats.total_pkts_txd: 0 > dev.ix.1.mac_stats.good_pkts_txd: 0 > dev.ix.1.mac_stats.bcast_pkts_txd: 0 > dev.ix.1.mac_stats.mcast_pkts_txd: 0 > dev.ix.1.mac_stats.management_pkts_txd: 0 > dev.ix.1.mac_stats.tx_frames_64: 0 > dev.ix.1.mac_stats.tx_frames_65_127: 0 > dev.ix.1.mac_stats.tx_frames_128_255: 0 > dev.ix.1.mac_stats.tx_frames_256_511: 0 > dev.ix.1.mac_stats.tx_frames_512_1023: 0 > dev.ix.1.mac_stats.tx_frames_1024_1522: 0 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Babak Farrokhi