From owner-freebsd-net@FreeBSD.ORG Sun May 24 21:00: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 BA8D9934 for ; Sun, 24 May 2015 21:00:53 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 92470822 for ; Sun, 24 May 2015 21:00:53 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4OL0rEp053225 for ; Sun, 24 May 2015 21:00:53 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201505242100.t4OL0rEp053225@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, 24 May 2015 21:00:53 +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, 24 May 2015 21:00:53 -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 25 00:30: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 B08D9C85 for ; Mon, 25 May 2015 00:30:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 9A5AFEE3 for ; Mon, 25 May 2015 00:30:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4P0UYBc047472 for ; Mon, 25 May 2015 00:30:34 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: Mon, 25 May 2015 00:30:33 +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: Closed 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: Mon, 25 May 2015 00:30:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199716 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: sbruno Date: Mon May 25 00:30:27 UTC 2015 New revision: 283504 URL: https://svnweb.freebsd.org/changeset/base/283504 Log: MFC r283290 Bump rx_overruns when indicated by the ICR mask. PR: 199716 Sponsored by: Limelight Networks Changes: _U stable/10/ stable/10/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 Mon May 25 07:36: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 D9873ABC for ; Mon, 25 May 2015 07:36:30 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.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 615DFD3A for ; Mon, 25 May 2015 07:36:30 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id 918D5250A88 for ; Mon, 25 May 2015 09:36:27 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpHRGeRwlaHE for ; Mon, 25 May 2015 09:36:24 +0200 (CEST) Received: from [192.168.52.11] (1F2EC6DD.catv.pool.telekom.hu [31.46.198.221]) by green.field.hu (Postfix) with ESMTPA id 6B027250A9A for ; Mon, 25 May 2015 09:36:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1432539384; bh=cIK0QsojvpCMXEZJYHbu37VCdxAmam63RxEYtjwcl/s=; h=Date:From:To:Subject; b=G6W7W67Y/PabNow8l1fJTDvtX7MbDlGH558CG0j6Gv5l+gIzaR0D73sVQ6zv0viej Q+FLEZD4SBdF8jl9+vSKe96tNDXAsL8ndppPXoIzoUyr9JcLIpDwKtowWTA4X0yZey PFiYfSsywSE/yAAMv/jUdVGJwN+FOXACvBFbiYAI= Message-ID: <5562D0F3.4070408@field.hu> Date: Mon, 25 May 2015 09:36:19 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic Content-Type: text/plain; charset=iso-8859-2; 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: Mon, 25 May 2015 07:36:31 -0000 Hi all, I have two FreeBSd 10.1-RELEASE servers connected to each other. They were connected via cross link, but they are connected to a cisco switch now (the problem was the same with cross link too). When transferring huge files (50-500GB backup files) via Gigabit (it is important!) the network randomly dies. The backup runs every day/week and sometimes the connection is ok for months sometimes it happens twice a week. When the network dies I can log in to the server via IPMI and use the console everything is OK, but can't send anything out on the network. ifconfig em0 down/up doesn't help nor netif restart. The problem never occured when I used 100Mbit connection between them, but it was 3com NIC (xl), gigabit adapter is Intel (em0). When I limit the transfer rate (rsync bandwith limit or ipfw pipe) the problem is much more rare. I tried to set these tuning parameters on both servers with different buffer size but nothing helped: # cat /etc/sysctl.conf security.bsd.see_other_uids=0 net.inet.tcp.recvspace=512000 net.route.netisr_maxqlen=2048 kern.ipc.nmbclusters=1310720 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 kern.ipc.soacceptqueue=32768 # cat /boot/loader.conf geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) ipfw_load="YES" net.inet.ip.fw.default_to_accept=1 kern.maxusers=4096 accf_data_load="YES" The duplex settings are identical on both servers. Server A: em1: flags=8843 metric 0 mtu 9000 options=4219b ether 00:25:90:24:52:66 inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Server B: em0: flags=8843 metric 0 mtu 9000 options=4219b ether 00:30:48:dd:fe:3e inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active Today I tried to set mtu to 9000 but in tcpdump I see that during scp it is still 1500: x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee (incorrect -> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS val 3103966325 ecr 853712893], length 0 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags [DF], proto TCP (6), length 1500) 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags [DF], proto TCP (6), length 1500) Any ideas? Thanks guys! From owner-freebsd-net@FreeBSD.ORG Mon May 25 08:30: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 A2B482CE for ; Mon, 25 May 2015 08:30:01 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from alcyone.saas.tuxis.net (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A218AEB for ; Mon, 25 May 2015 08:29:59 +0000 (UTC) (envelope-from mark@tuxis.nl) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=rNna/EAPZ9LOe/IBbTwzHzh2TRXYhkjJCfV9fxzgcc0=; b=Kbpy6XXK+q734YsJvTOioh/XK9jVYr+M2UaLYxOMMe6r4Bno6aq/c2yhJnLfw+9VwNE1BsDVq/3VZ hIhckx/oEeoLOAaYyosSLYpgxqJ5uem03PMi8wWISaGqBC7uZZIUNOH7gKdoBQsahwaVO46TB+Fr24 mTfZ1ENVN5nvFrQdcU8DE0dsONYTuUb2asXHelZ/XpnRhgIw9PNgnKrjx1IVWbzyMw5TDZUCm2chv9 47lrf1zGQaQ1IIVowqtsglUxqjgvSADc6325J3+hYhJeq4fmkGhPRX8NzBGXqaS6QCTX2JMP38PSHt 1/nJDaVZLDHabKJay3fNKIT+z2EWLNw== X-Footer: dHV4aXMubmw= Received: from [193.217.21.132] ([193.217.21.132]) by alcyone.saas.tuxis.net (Kerio Connect 8.5.0); Mon, 25 May 2015 09:59:45 +0200 From: "Mark Schouten" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <5562D0F3.4070408@field.hu> Mime-Version: 1.0 (1.0) In-Reply-To: <5562D0F3.4070408@field.hu> Message-Id: <13CD4CDB-1744-4E2F-8FD7-BFE2365121F3@tuxis.nl> Date: Mon, 25 May 2015 09:59:45 +0200 To: Cs Cc: "freebsd-net@freebsd.org" 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, 25 May 2015 08:30:01 -0000 Try lowering your mtu to 1500, that worked miracles for me.. --=20 Mark Schouten Tuxis Internet Engineering mark@tuxis.nl / 0318 200208 > On 25 May 2015, at 09:36, "Cs" wrote: >=20 > Hi all, >=20 > I have two FreeBSd 10.1-RELEASE servers connected to each other. They were= connected via cross link, but they are connected to a cisco switch now (the= problem was the same with cross link too). When transferring huge files (50= -500GB backup files) via Gigabit (it is important!) the network randomly die= s. The backup runs every day/week and sometimes the connection is ok for mon= ths sometimes it happens twice a week. When the network dies I can log in to= the server via IPMI and use the console everything is OK, but can't send an= ything out on the network. ifconfig em0 down/up doesn't help nor netif resta= rt. The problem never occured when I used 100Mbit connection between them, b= ut it was 3com NIC (xl), gigabit adapter is Intel (em0). When I limit the tr= ansfer rate (rsync bandwith limit or ipfw pipe) the problem is much more rar= e. >=20 > I tried to set these tuning parameters on both servers with different buff= er size but nothing helped: >=20 > # cat /etc/sysctl.conf > security.bsd.see_other_uids=3D0 > net.inet.tcp.recvspace=3D512000 > net.route.netisr_maxqlen=3D2048 > kern.ipc.nmbclusters=3D1310720 > net.inet.tcp.sendbuf_max=3D16777216 > net.inet.tcp.recvbuf_max=3D16777216 > kern.ipc.soacceptqueue=3D32768 >=20 > # cat /boot/loader.conf > geom_mirror_load=3D"YES" # RAID1 disk driver (see gmirror(8)) > ipfw_load=3D"YES" > net.inet.ip.fw.default_to_accept=3D1 > kern.maxusers=3D4096 > accf_data_load=3D"YES" >=20 > The duplex settings are identical on both servers. >=20 > Server A: > em1: flags=3D8843 metric 0 mtu 900= 0 > options=3D4219b=20 > ether 00:25:90:24:52:66 > inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > Server B: > em0: flags=3D8843 metric 0 mtu 900= 0 > options=3D4219b=20 > ether 00:30:48:dd:fe:3e > inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active >=20 > Today I tried to set mtu to 9000 but in tcpdump I see that during scp it i= s still 1500: > x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee (incorrect -> 0xda= 6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS val 3103966325 e= cr 853712893], length 0 > 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags [DF], proto T= CP (6), length 1500) > 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags [DF], proto T= CP (6), length 1500) >=20 >=20 > Any ideas? Thanks guys! > _______________________________________________ > 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 Mon May 25 09:12: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 8EBFC196 for ; Mon, 25 May 2015 09:12:44 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.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 443368A5 for ; Mon, 25 May 2015 09:12:43 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id BCB07250A6D; Mon, 25 May 2015 11:12:40 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ-drsMhZ_-S; Mon, 25 May 2015 11:12:38 +0200 (CEST) Received: from [192.168.3.114] (catv-80-98-134-30.catv.broadband.hu [80.98.134.30]) by green.field.hu (Postfix) with ESMTPA id C9655250A64; Mon, 25 May 2015 11:12:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1432545157; bh=Si2TB1nIVAqF7Z3UDfqPr74Ra7SwMuEyuYBnsP7K7lA=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=j5OwcWKbENTicDdysZc36JJugcruh/5f5ailieKCr/9xS8GDpu82ZErNnUpB+ZYUW oeA8evhWnEooOLzL/GrnSyrtTUq8A7eD03lVIJCmYywUoZ9/dAcUArfv5Bl6tZSAM+ KYk49Mr+1UBoREejnXSYQgGU6Wig4sx5wjdvWSUg= In-Reply-To: <13CD4CDB-1744-4E2F-8FD7-BFE2365121F3@tuxis.nl> References: <5562D0F3.4070408@field.hu> <13CD4CDB-1744-4E2F-8FD7-BFE2365121F3@tuxis.nl> X-Referenced-Uid: 90 Thread-Topic: Re: FreeBSD 10.1-REL - network unaccessible after high traffic User-Agent: Type for Android MIME-Version: 1.0 Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic From: Cs Date: Mon, 25 May 2015 11:12:35 +0200 To: Mark Schouten CC: freebsd-net@freebsd.org Message-ID: <440563e0-ec18-4853-8952-866006d06141@typeapp.com> 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: Mon, 25 May 2015 09:12:44 -0000 It was on 1500 for ~3 years :) Regards, Csaba On May 25, 2015, 10:30, at 10:30, Mark Schouten wrote: > >Try lowering your mtu to 1500, that worked miracles for me.. > >-- >Mark Schouten >Tuxis Internet Engineering >mark@tuxis.nl / 0318 200208 > >> On 25 May 2015, at 09:36, "Cs" wrote: >> >> Hi all, >> >> I have two FreeBSd 10.1-RELEASE servers connected to each other. They >were connected via cross link, but they are connected to a cisco switch >now (the problem was the same with cross link too). When transferring >huge files (50-500GB backup files) via Gigabit (it is important!) the >network randomly dies. The backup runs every day/week and sometimes the >connection is ok for months sometimes it happens twice a week. When the >network dies I can log in to the server via IPMI and use the console >everything is OK, but can't send anything out on the network. ifconfig >em0 down/up doesn't help nor netif restart. The problem never occured >when I used 100Mbit connection between them, but it was 3com NIC (xl), >gigabit adapter is Intel (em0). When I limit the transfer rate (rsync >bandwith limit or ipfw pipe) the problem is much more rare. >> >> I tried to set these tuning parameters on both servers with different >buffer size but nothing helped: >> >> # cat /etc/sysctl.conf >> security.bsd.see_other_uids=0 >> net.inet.tcp.recvspace=512000 >> net.route.netisr_maxqlen=2048 >> kern.ipc.nmbclusters=1310720 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.recvbuf_max=16777216 >> kern.ipc.soacceptqueue=32768 >> >> # cat /boot/loader.conf >> geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) >> ipfw_load="YES" >> net.inet.ip.fw.default_to_accept=1 >> kern.maxusers=4096 >> accf_data_load="YES" >> >> The duplex settings are identical on both servers. >> >> Server A: >> em1: flags=8843 metric 0 mtu >9000 >> >options=4219b > >> ether 00:25:90:24:52:66 >> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> Server B: >> em0: flags=8843 metric 0 mtu >9000 >> >options=4219b > >> ether 00:30:48:dd:fe:3e >> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> Today I tried to set mtu to 9000 but in tcpdump I see that during scp >it is still 1500: >> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee (incorrect -> >0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS val >3103966325 ecr 853712893], length 0 >> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags [DF], >proto TCP (6), length 1500) >> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags [DF], >proto TCP (6), length 1500) >> >> >> Any ideas? Thanks guys! >> _______________________________________________ >> 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 Mon May 25 22:10:18 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 AE041624 for ; Mon, 25 May 2015 22:10:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 9822EAE9 for ; Mon, 25 May 2015 22:10:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4PMAIwj060579 for ; Mon, 25 May 2015 22:10:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 200420] [igb] igb0: Watchdog timeout -- resetting Date: Mon, 25 May 2015 22:10:18 +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: Mon, 25 May 2015 22:10:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200420 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 Tue May 26 06:52:24 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 CD96B927 for ; Tue, 26 May 2015 06:52:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 B83F45F4 for ; Tue, 26 May 2015 06:52:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4Q6qOxW003442 for ; Tue, 26 May 2015 06:52:24 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: Tue, 26 May 2015 06:52:24 +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: shuriku@shurik.kiev.ua 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: Tue, 26 May 2015 06:52:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200221 --- Comment #6 from Alexandr Krivulya --- I think it's some bug due to em(4) upgrade in 10.1 https://svnweb.freebsd.org/base?view=revision&revision=269196 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue May 26 08:30: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 5E4D9A86 for ; Tue, 26 May 2015 08:30:20 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from alcyone.saas.tuxis.net (alcyone.saas.tuxis.net [31.3.111.19]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF6D7F80 for ; Tue, 26 May 2015 08:30:19 +0000 (UTC) (envelope-from mark@tuxis.nl) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuxis.nl; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to; bh=iWY57LvUq8A2+7lQYMnpb2djsHxAMKH/0cg7oTpWJv8=; b=rBWdpcRXazXTaAVKl1soYVnCh38GOyam4QuC41mfCYWtiMM5b/Hrp3zISiwvRmmasXhN0HKAMfzld zkyGOvN/PLw7vQnByTZFf84Ezk+dnjB2XMMHGQ1W/n6POqDFjz8OQPmCLFpSiqUoe1f8bAoySOzbv7 iyYPwv/2GTELHPxQNxOAx63twoyDS0pu44gCpjRByIHjax29uc8iAkQB5JYWwC7GmcdLQvJtsW4/bG ZE3M//qLp8Bjr55D0Yk10jOB3+6YhKXtfbFIOk+9jTUDipCHS5b3ymKq39OfpVhy/wCA+qgn9qe1jv LhiD0Wat2YDzr4Hu7o/ewy9K38EyWVA== X-Footer: dHV4aXMubmw= Received: from [31.3.104.222] ([31.3.104.222]) by alcyone.saas.tuxis.net (Kerio Connect 8.5.0) for bimmer@field.hu; Tue, 26 May 2015 10:30:08 +0200 Date: Tue, 26 May 2015 10:30:08 +0200 Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic X-Mailer: Kerio Connect 8.5.0/Kerio Connect Client X-User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36 Message-ID: <2404899099-25362@alcyone.saas.tuxis.net> From: Mark Schouten To: Cs Cc: freebsd-net@freebsd.org X-Priority: 3 Importance: Normal In-Reply-To: <440563e0-ec18-4853-8952-866006d06141@typeapp.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="=-3OH9LaMKEL0YtYwD6ebT" 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, 26 May 2015 08:30:20 -0000 --=-3OH9LaMKEL0YtYwD6ebT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Oh, didn't see your lowest remark. Then, the next thing that comes past her= e a few times per week is 'Try disabling TSO'. Met vriendelijke groeten, --=C2=A0 Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ Mark Schouten | Tuxis Internet Engineering KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ T: 0318 200208 | info@tuxis.nl Van: Cs =20 Aan: Mark Schouten =20 Cc: =20 Verzonden: 25-5-2015 11:12=20 Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after high traffi= c=20 It was on 1500 for ~3 years :)=20 =20 Regards,=20 Csaba=20 =20 =20 =20 On May 25, 2015, 10:30, at 10:30, Mark Schouten wrote:=20 >=20 >Try lowering your mtu to 1500, that worked miracles for me..=20 >=20 >-- =20 >Mark Schouten=20 >Tuxis Internet Engineering=20 >mark@tuxis.nl / 0318 200208=20 >=20 >> On 25 May 2015, at 09:36, "Cs" wrote:=20 >> =20 >> Hi all,=20 >> =20 >> I have two FreeBSd 10.1-RELEASE servers connected to each other. They=20 >were connected via cross link, but they are connected to a cisco switch=20 >now (the problem was the same with cross link too). When transferring=20 >huge files (50-500GB backup files) via Gigabit (it is important!) the=20 >network randomly dies. The backup runs every day/week and sometimes the=20 >connection is ok for months sometimes it happens twice a week. When the=20 >network dies I can log in to the server via IPMI and use the console=20 >everything is OK, but can't send anything out on the network. ifconfig=20 >em0 down/up doesn't help nor netif restart. The problem never occured=20 >when I used 100Mbit connection between them, but it was 3com NIC (xl),=20 >gigabit adapter is Intel (em0). When I limit the transfer rate (rsync=20 >bandwith limit or ipfw pipe) the problem is much more rare.=20 >> =20 >> I tried to set these tuning parameters on both servers with different=20 >buffer size but nothing helped:=20 >> =20 >> # cat /etc/sysctl.conf=20 >> security.bsd.see_other_uids=3D0=20 >> net.inet.tcp.recvspace=3D512000=20 >> net.route.netisr_maxqlen=3D2048=20 >> kern.ipc.nmbclusters=3D1310720=20 >> net.inet.tcp.sendbuf_max=3D16777216=20 >> net.inet.tcp.recvbuf_max=3D16777216=20 >> kern.ipc.soacceptqueue=3D32768=20 >> =20 >> # cat /boot/loader.conf=20 >> geom_mirror_load=3D"YES" # RAID1 disk driver (see gmirror(8))=20 >> ipfw_load=3D"YES"=20 >> net.inet.ip.fw.default_to_accept=3D1=20 >> kern.maxusers=3D4096=20 >> accf_data_load=3D"YES"=20 >> =20 >> The duplex settings are identical on both servers.=20 >> =20 >> Server A:=20 >> em1: flags=3D8843 metric 0 mtu=20 >9000=20 >>=20 >options=3D4219b=20 >=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:25:90:24:52:66=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet x.x.x.x netmask 0xfffffe00 broadcast x.x= .x.x=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0nd6 options=3D29=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (1000baseT )=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active=20 >> =20 >> Server B:=20 >> em0: flags=3D8843 metric 0 mtu=20 >9000=20 >>=20 >options=3D4219b=20 >=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:30:48:dd:fe:3e=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0inet x.x.x.x netmask 0xfffffe00 broadcast x.x= .x.x=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0nd6 options=3D29=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet autoselect (1000baseT )=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0status: active=20 >> =20 >> Today I tried to set mtu to 9000 but in tcpdump I see that during scp=20 >it is still 1500:=20 >> =C2=A0 =C2=A0x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee (incor= rect ->=20 >0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS val=20 >3103966325 ecr 853712893], length 0=20 >> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags [DF],=20 >proto TCP (6), length 1500)=20 >> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags [DF],=20 >proto TCP (6), length 1500)=20 >> =20 >> =20 >> Any ideas? Thanks guys!=20 >> _______________________________________________=20 >> freebsd-net@freebsd.org mailing list=20 >> http://lists.freebsd.org/mailman/listinfo/freebsd-net=20 >> To unsubscribe, send any mail to=20 >"freebsd-net-unsubscribe@freebsd.org"=20 _______________________________________________=20 freebsd-net@freebsd.org mailing list=20 http://lists.freebsd.org/mailman/listinfo/freebsd-net=20 To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=20 = --=-3OH9LaMKEL0YtYwD6ebT Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: Electronic Signature S/MIME Content-Transfer-Encoding: base64 MIIRwQYJKoZIhvcNAQcCoIIRsjCCEa4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCDt4w ggUbMIIEA6ADAgECAhAsv+VdGX6YsSHI/WRu2j2JMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE0MDcwMTAwMDAwMFoXDTE1MDcwMTIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNbWFya0B0dXhpcy5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANHu3SxlMZOG5GA0/mqtRXR1QmWwhUXzmCIprI0IPtSBWSA31YBJ5qcmXRhLzaiTB3Fr UpIGkW5aAZnDms9DD64kasF3oZE00Fvfnj/BDGbw098px1PukKfg4hasbTaELAjQTSUj8xRSHzKk VVynvLA/YmyRT/+u3ueK4wdaxcej241xH6mNfZeiKMAvbkv6Tm9vdup0BtqqbRSKcnc01KKrspun Eh73jLIUhP21uJv8vuOTxS1I9zJSlhIcMCEapjBQ+26cQl+s+qBuAs/LP3UPVytSbxvicdhDxtqH npN2h3jJ/+J86zGfQi8bG7EamsULTGHkbgIJL9AdKZRgAKECAwEAAaOCAd0wggHZMB8GA1UdIwQY MBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBR+dMZE22X/SMCyTxYzIP+NMZBNXTAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiG Rmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+BDW1hcmtA dHV4aXMubmwwDQYJKoZIhvcNAQEFBQADggEBAIB8FhqaML1EzfvgNwwHDC3k0ICeMerOncgee6uJ KLxwU2mstttX5jtAmgK9RuDOu+TrMkkpF2yxYMTPpSM8nL7r+N/kdogu5Bustol8WTsW1e5vs+Nh hJYFORk113ouur1kSjXuHF8TWy+/PjFJBS/xm/H+/fkghppRU+4Dj2IReUBvlexAPYr4VDxjV7AD xPOXqTQkP15LWGvhTz2YVbJ3IAVOyUNkRhr9QwzToUxXa9k/QAOpXMuvS74AT2RBV/YCEEx7ebRD MAR6lZcbYiV8sXv1ASbnMdO3Fh2F98g+5rJn5PfFH8qLpapsZx0I2/axtSG09QMDJqXd3Ab6NpEw ggUaMIIEAqADAgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hf ZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrh o/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0 mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MP bXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRc WzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAd BgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQI MAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwu dXNlcnRydXN0LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwu Y3JsMHQGCCsGAQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29t L1VUTkFkZFRydXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRy dXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ 9RtaxdKtG3NuPukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1 ei+eupN5yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B 080zX5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCC BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAg TmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5 MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcT DlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsT GGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQg QXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA sjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p 1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K 2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bU MSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjK aJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0 tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8E BAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDeg NYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUG CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5lDd1 ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJxggzpiDbj 2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTGCAqswggKnAgEBMIGo MIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAsv+VdGX6YsSHI/WRu2j2JMAkG BSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUw NTI2MDgzMDA4WjAjBgkqhkiG9w0BCQQxFgQUW4wDsENnszz1HoA8WPBqeTP9PDMweQYJKoZIhvcN AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAYtZI8I1rZhzywuB0azdxKJVdeRNEU3C4wCet7GNDfawbSEKjaa5h vLqU65lh1snsHt0Kx1cTIFXxOelwfAl0N/uY9dYA+HlE+7XUQhL1gfoxs7KjnYszNb1+CKJu9YxG 4y9wZKJAQVY7pqEQ85qv3gEK5qLbel/fVIw7qnggmTT4GO0Jud020n3hAV+IRHk8H4ja4/A+s+0p ExwtDPTsRA/gs8t1+efC4d11ISGGvzYUG1rdC21XON1clrJLvQzF3LdvVeMO8pmn1pQc725SMPg9 0nJrC3KKYa+Uh8JJeoSHteUw0sVWawi1fVZql2P+FyUnullA53rcJ/6PJn8Z1Q== --=-3OH9LaMKEL0YtYwD6ebT-- From owner-freebsd-net@FreeBSD.ORG Tue May 26 08:36: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 921DEEA5 for ; Tue, 26 May 2015 08:36:46 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (green.field.hu [217.20.130.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 1C65D20D for ; Tue, 26 May 2015 08:36:46 +0000 (UTC) (envelope-from bimmer@field.hu) Received: from green.field.hu (localhost [127.0.0.1]) by green.field.hu (Postfix) with ESMTP id EFA63250A99 for ; Tue, 26 May 2015 10:36:36 +0200 (CEST) X-Virus-Scanned: by Amavisd-new at field.hu Received: from green.field.hu ([127.0.0.1]) by green.field.hu (green.field.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gwVk8F_SAyk for ; Tue, 26 May 2015 10:36:33 +0200 (CEST) Received: from [10.10.10.139] (unknown [188.227.229.50]) by green.field.hu (Postfix) with ESMTPA id 250E4250A64 for ; Tue, 26 May 2015 10:36:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=field.hu; s=mail; t=1432629393; bh=ppDKh3W3KKaA0mpZIcKDnd1p7Ur2ho8rDkjljTfZfJo=; h=Date:From:To:Subject:References:In-Reply-To; b=DQ2PmM5Uf4QKPH6WxecfU/jKVuHaSgPuD3XYZC6XEvmFv++5sCwJuGGAab/vBF0sV dKd0HzEfRlPkPIyB6zIogFpQ7bhEaE9XtSJLG+1NGiNLq0TPkEaq8woTmHfwQg1l0f dKD3+WjXp/qHlmljV4Wr9iPPCM+i/+oiSNP3sCb4= Message-ID: <5564308A.7010502@field.hu> Date: Tue, 26 May 2015 10:36:26 +0200 From: Cs User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10.1-REL - network unaccessible after high traffic References: <2404899099-25362@alcyone.saas.tuxis.net> In-Reply-To: <2404899099-25362@alcyone.saas.tuxis.net> 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: Tue, 26 May 2015 08:36:46 -0000 Thanks Mark, good idea. I found this thread which is exactly the same problem as mine: https://forums.freebsd.org/threads/workaround-freebsd-10-1-sudden-network-down.49264/ Will see if it helps in a couple weeks. Regards, Csaba 2015.05.26. 10:30 keltezéssel, Mark Schouten írta: > Oh, didn't see your lowest remark. Then, the next thing that comes past here a few times per week is 'Try disabling TSO'. > > > Met vriendelijke groeten, > > -- > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet Engineering > KvK: 61527076 | http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl > > > > Van: Cs > Aan: Mark Schouten > Cc: > Verzonden: 25-5-2015 11:12 > Onderwerp: Re: FreeBSD 10.1-REL - network unaccessible after high traffic > > It was on 1500 for ~3 years :) > > Regards, > Csaba > > > > On May 25, 2015, 10:30, at 10:30, Mark Schouten wrote: >> Try lowering your mtu to 1500, that worked miracles for me.. >> >> -- >> Mark Schouten >> Tuxis Internet Engineering >> mark@tuxis.nl / 0318 200208 >> >>> On 25 May 2015, at 09:36, "Cs" wrote: >>> >>> Hi all, >>> >>> I have two FreeBSd 10.1-RELEASE servers connected to each other. They >> were connected via cross link, but they are connected to a cisco switch >> now (the problem was the same with cross link too). When transferring >> huge files (50-500GB backup files) via Gigabit (it is important!) the >> network randomly dies. The backup runs every day/week and sometimes the >> connection is ok for months sometimes it happens twice a week. When the >> network dies I can log in to the server via IPMI and use the console >> everything is OK, but can't send anything out on the network. ifconfig >> em0 down/up doesn't help nor netif restart. The problem never occured >> when I used 100Mbit connection between them, but it was 3com NIC (xl), >> gigabit adapter is Intel (em0). When I limit the transfer rate (rsync >> bandwith limit or ipfw pipe) the problem is much more rare. >>> >>> I tried to set these tuning parameters on both servers with different >> buffer size but nothing helped: >>> >>> # cat /etc/sysctl.conf >>> security.bsd.see_other_uids=0 >>> net.inet.tcp.recvspace=512000 >>> net.route.netisr_maxqlen=2048 >>> kern.ipc.nmbclusters=1310720 >>> net.inet.tcp.sendbuf_max=16777216 >>> net.inet.tcp.recvbuf_max=16777216 >>> kern.ipc.soacceptqueue=32768 >>> >>> # cat /boot/loader.conf >>> geom_mirror_load="YES" # RAID1 disk driver (see gmirror(8)) >>> ipfw_load="YES" >>> net.inet.ip.fw.default_to_accept=1 >>> kern.maxusers=4096 >>> accf_data_load="YES" >>> >>> The duplex settings are identical on both servers. >>> >>> Server A: >>> em1: flags=8843 metric 0 mtu >> 9000 >> options=4219b >> >>> ether 00:25:90:24:52:66 >>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>> nd6 options=29 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> Server B: >>> em0: flags=8843 metric 0 mtu >> 9000 >> options=4219b >> >>> ether 00:30:48:dd:fe:3e >>> inet x.x.x.x netmask 0xfffffe00 broadcast x.x.x.x >>> nd6 options=29 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> Today I tried to set mtu to 9000 but in tcpdump I see that during scp >> it is still 1500: >>> x.x.x.x.222 > x.x.x.x.37612: Flags [.], cksum 0xb6ee (incorrect -> >> 0xda6f), seq 35749, ack 113701596, win 7986, options [nop,nop,TS val >> 3103966325 ecr 853712893], length 0 >>> 09:27:33.912354 IP (tos 0x8, ttl 64, id 1028, offset 0, flags [DF], >> proto TCP (6), length 1500) >>> 09:27:33.912358 IP (tos 0x8, ttl 64, id 1029, offset 0, flags [DF], >> proto TCP (6), length 1500) >>> >>> >>> Any ideas? Thanks guys! >>> _______________________________________________ >>> 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 Tue May 26 13:36: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 63A13FD9 for ; Tue, 26 May 2015 13:36:56 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D7E1C87A for ; Tue, 26 May 2015 13:36:53 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. ([IPv6:fd00::77d]) by elf.hq.norma.perm.ru (8.14.9/8.14.9) with ESMTP id t4QDal5d002698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 26 May 2015 18:36:47 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <556476EF.1090706@norma.perm.ru> Date: Tue, 26 May 2015 18:36:47 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ng_netflow Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Tue, 26 May 2015 18:36:47 +0500 (YEKT) X-Spam-Status: No hits=-99.8 bayes=0.0000 testhits AWL=0.600,BAYES_00=-1.9, RDNS_NONE=0.793,SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on elf.hq.norma.perm.ru 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, 26 May 2015 13:36:56 -0000 Hi. I'm using ng_netflow along with flow-tools to collect traffic statistics. What is bothering me, is that I constantly see lost flow. What is even more weird - is that ng_netflow and flow-capture are on the same host, and are communication via lo0: May 26 18:33:16 balancer1 flow-capture[67265]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=49.51.57.55 d_version=5 expect ing=2033661856 received=2033666446 lost=4590 May 26 18:33:17 balancer1 flow-capture[67265]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=0.0.0.0 d_version=5 expecting= 2033666446 received=2033666476 lost=30 May 26 18:33:17 balancer1 flow-capture[67265]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=49.52.48.48 d_version=5 expect ing=2033461677 received=2033666926 lost=205249 May 26 18:33:17 balancer1 flow-capture[67265]: ftpdu_seq_check(): src_ip=127.0.0.1 dst_ip=0.0.0.0 d_version=5 expecting= 2033666926 received=2033666956 lost=30 Plus I see weird IPs like "dst_ip=0.0.0.0" or "dst_ip=0.2.0.4". Can someone point me what m I doing wrong ? I configure the netflow like this: /usr/sbin/ngctl -f- <<-SEQ mkpeer bge0: netflow lower iface0 name bge0:lower netflow connect bge0: netflow: upper out0 connect bge1: netflow: lower iface1 connect bge1: netflow: upper out1 msg netflow: setconfig { iface=0 conf=63 } msg netflow: setconfig { iface=1 conf=63 } msg netflow: setmtu { mtu=16384 } mkpeer netflow: ksocket export inet/dgram/udp msg netflow:export connect inet/127.0.0.1:4444 name netflow:export ksocket SEQ By the way setting MTU to 16384 doesn't change the packet size as tcpdump sees it on lo0. Thanks. Eugene. From owner-freebsd-net@FreeBSD.ORG Tue May 26 14:47: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 B1F2A5C0 for ; Tue, 26 May 2015 14:47:48 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (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 E4EF1C58 for ; Tue, 26 May 2015 14:47:47 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 573A830FC55 for ; Tue, 26 May 2015 11:38:03 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1432651079; x=1433515080; bh=DIHuwT6Dj6U5G8q5NhpfPA+XQRu1pC997Qr Q+AwpTI4=; b=R67MkMUmGW/KyQOp/R1tGZdS4vKBSUrNwoF43DlrbsnOD9zPAj3 Ds3ctrCTrQhUgvVU2xHv3Cn8FxqiZg8Ujat+tNWpwsJZ+4JAXQbk4rCXpgt7MCiD M2JPKB0NAIEbsPZsswMN29Ryj2bSHAICzTVp+g54jNzVgMAUIVLA1EpU= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZTEv55k5CNU for ; Tue, 26 May 2015 11:37:59 -0300 (BRT) Received: from [192.168.88.8] (unknown [10.255.0.12]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id EF18130FC57 for ; Tue, 26 May 2015 11:37:58 -0300 (BRT) Message-ID: <5564852D.8040008@bsdinfo.com.br> Date: Tue, 26 May 2015 11:37:33 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets References: <5560C395.8020807@farrokhi.net> In-Reply-To: <5560C395.8020807@farrokhi.net> 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: Tue, 26 May 2015 14:47:48 -0000 On 23-05-2015 15:14, Babak Farrokhi wrote: > 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" > Hi, I had this problem and one day updated the system 10.1- RELEASE to 10.1- STABLE and the problem stopped. I was one years with this problem and a script running and testing the interface when the interface stopped working I was doing exactly what you did. Today I no longer have that problem anymore. I'm using 10.1-STABLE r281235 Gondim From owner-freebsd-net@FreeBSD.ORG Tue May 26 18:09:32 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 5B1F268C for ; Tue, 26 May 2015 18:09:32 +0000 (UTC) (envelope-from lakshmi.n@msystechnologies.com) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) (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 309B28CF for ; Tue, 26 May 2015 18:09:31 +0000 (UTC) (envelope-from lakshmi.n@msystechnologies.com) Received: by pdea3 with SMTP id a3so96227852pde.2 for ; Tue, 26 May 2015 11:09:31 -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:mime-version:from:to:cc:subject :importance:date:in-reply-to:references:content-type; bh=T4jykpN85wz5JaFjxq/5sepM70Bm6GEe3BrCbxEO4Yg=; b=NENg3cHn+TJGxSAngea4aV88C58Ely5+3PXlFTCA/qjrAxdDkyA9XqF0NFXirK1uq4 NoORnqWBa7fXNsvFiZB9x14Xt+v7YZIN5fKeuuo2TvyILaJB1GeGSGhrtnIlLpwXCZRk TsizQlM5Mw3L8W2w3VwcGvV2vjPh8MPKu1xxWqBB8rQ9EMmMpnHjvBaEHTWkqourAS1V Q+oHk7HCPp3JvfRJ679+L9lBeG91WnuaI4muYeBY2vgt8NJtdw3iW303RHE84zQzRIDv d61wpGivSqZ9yDvtHHQuPh2WUq/KmFj2d34sOGaI8OQ0KUi95l/pa4L204NX1aA8pxVE TJiw== X-Gm-Message-State: ALoCoQl97ljhQ1essFyU0/qny3rbQ/9fhb4Bcai9yYz1LwaIzMBEqxHOyD1KZuYV3MHgwb6Frjia X-Received: by 10.70.37.69 with SMTP id w5mr50822792pdj.123.1432663365943; Tue, 26 May 2015 11:02:45 -0700 (PDT) Received: from GandivaPC ([64.80.217.3]) by mx.google.com with ESMTPSA id po2sm13703383pbb.13.2015.05.26.11.02.42 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 May 2015 11:02:45 -0700 (PDT) Message-ID: <5564b545.0287440a.5871.7050@mx.google.com> MIME-Version: 1.0 From: =?utf-8?Q?Lakshmi_Narasimhan_Sundararajan?= To: "=?utf-8?Q?Pokala,_Ravi?=" , "=?utf-8?Q?freebsd-net@freebsd.org?=" , "=?utf-8?Q?jfv@freebsd.org?=" , "=?utf-8?Q?erj@freebsd.org?=" CC: "=?utf-8?Q?freebsd-hackers@freebsd.org?=" , "=?utf-8?Q?Lewis,_Fred?=" Subject: =?utf-8?Q?Re:_Performance_issues_with_Intel_Fortville_(XL710/ixl(4))?= Importance: Normal Date: Thu, 21 May 2015 22:20:03 +0000 In-Reply-To: References: Content-Type: text/plain; charset="utf-8" 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: Tue, 26 May 2015 18:09:32 -0000 SGkgRnJlZUJTRCBUZWFtIQ0KDQpXZSBzZWVtIHRvIGhhdmUgZm91bmQgYSBwcm9ibGVtIHRvIFR4 IHBlcmZvcm1hbmNlLiANCg0KV2UgZm91bmQgdGhhdCB0aGUgdHggaGFuZGxpbmcgaXMgc3ByZWFk IG9uIGFsbCBDUFVzIGNhdXNpbmcgcHJvYmFibHkgY2FjaGUgdHJhc2hpbmcgcmVzdWx0aW5nIGlu IHBvb3IgcGVyZm9ybWFuY2UuIA0KDQpCdXQgb25jZSB3ZSB1c2VkIGNwdXNldCB0byBiaW5kIGlu dGVycnVwdCB0aHJlYWQgYW5kIGlwZXJmIHByb2Nlc3MgdG8gdGhlIHNhbWUgQ1BVLCBwZXJmb3Jt YW5jZSB3YXMgY2xvc2UgdG8gbGluZSByYXRlLiBJIHVzZWQgdXNlcmxhbmQgY3B1c2V0IGNvbW1h bmQgdG8gcGVyZm9ybSB0aGlzIG1hbnVhbGx5LiBJIHdhbnQgdGhpcyBjb25zdHJhaW5lZCBpbiB0 aGUga2VybmVsIGNvbmZpZy9jb2RlIHRocm91Z2ggc29tZSB0dW5hYmxlcywgYW5kIEkgYW0gc2Vl a2luZyB5b3VyIGhlbHAvcG9pbnRlcnMgaW4gdGhhdCByZWdhcmQuDQoNCg0KTXkgZm9sbG93dXAg cXVlc3Rpb25zIGFyZSBhcyBmb2xsb3dzLg0KDQphKSBIb3cgYXJlIFR4IGludGVycnVwdHMgc3Rl ZXJlZCBmcm9tIHRoZSBOSUMgdG8gdGhlIENQVSBvbiB0aGUgdHJhbnNtaXQgcGF0aD8gV291bGQg dHhfY29tcGxldGUjIGludGVycnVwdCBmb3IgcGFja2V0cyB0cmFuc21pdHRlZCBmcm9tIENQVSN4 LCBiZSBzZXJ2aWNlZCBvbiB0aGUgc2FtZSBDUFU/IElmIG5vdCwgaG93IHRvIGdldCB0aGlzIGJp bmRpbmcgZG9uZT8NCg0KDQpiKSBJIHdvdWxkIGxpa2UgdG8gdXNlIGEgcG9vbCBvZiBDUFVzIGRl ZGljYXRlZCB0byBzZXJ2aWNlIE5JQyBpbnRlcnJ1cHRzLiBFc3BlY2lhbGx5IG9uIHRoZSB0cmFu c21pdCBwYXRoLCBJIHdvdWxkIHdhbnQgdGhlIHR4X2ludGVycnVwdHMgdG8gYmUgaGFuZGxlZCBv biB0aGUgc2FtZSBDUFUgb24gd2hpY2ggcmVxdWVzdCB3YXMgc3VibWl0dGVkLiBIb3cgdG8gZ2V0 IHRoaXMgZG9uZT8NCg0KDQpJIHBsYXllZCB3aXRoIHRoZSBjdXJyZW50IElTUiBzZXR0aW5nIGJ1 dCBJIGRpZCBub3Qgc2VlIGFueSBkaWZmZXJlbmNlIGluIGhvdyBJbnRlcnJ1cHRzIGFyZSBzY2hl ZHVsZWQgYWNyb3NzIENQVS4gVGhlIG1heCBpbnRlcnJ1cHQgdGhyZWFkcyBldmVuIHRob3VnaCBz ZXQgdG8gb25lLCB0aGUgaW50ZXJydXB0IHRocmVhZHMgYXJlIHNjaGVkdWxlZCBvbiBhbnkgQ1BV LiBFdmVuIGlmIEkgc2V0IGJpbmR0aHJlYWRzIHRvIOKAmDHigJkuIFRoZXJlIGlzIG5vIGRpZmZl cmVuY2UgaW4gaW50ZXJydXB0IHRocmVhZCBzY2hlZHVsaW5nLg0KDQoNCnJvb3RAbWF1LWRhLTI3 LTQtMTp+ICMgc3lzY3RsIG5ldC5pc3INCm5ldC5pc3IuZGlzcGF0Y2g6IGRpcmVjdA0KbmV0Lmlz ci5tYXh0aHJlYWRzOiAxDQpuZXQuaXNyLmJpbmR0aHJlYWRzOiAwDQpuZXQuaXNyLm1heHFsaW1p dDogMTAyNDANCm5ldC5pc3IuZGVmYXVsdHFsaW1pdDogMjU2DQpuZXQuaXNyLm1heHByb3Q6IDE2 DQpuZXQuaXNyLm51bXRocmVhZHM6IDENCg0KDQpJIHdvdWxkIHNpbmNlcmVseSBhcHByZWNpYXRl IGlmIHlvdSBjYW4gcHJvdmlkZSBzb21lIHBvaW50ZXJzIG9uIHRoZXNlIGl0ZW1zIGFib3ZlLg0K DQoNCg0KDQpUaGFua3MNCg0KTE4NCg0KDQoNCg0KDQoNCg0KRnJvbTogUG9rYWxhLCBSYXZpDQpT ZW50OiDigI5XZWRuZXNkYXnigI4sIOKAjk1heeKAjiDigI4yMOKAjiwg4oCOMjAxNSDigI4z4oCO OuKAjjM04oCOIOKAjkFNDQpUbzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcsIGpmdkBmcmVlYnNk Lm9yZywgZXJqQGZyZWVic2Qub3JnDQpDYzogZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnLCBM ZXdpcywgRnJlZCwgU3VuZGFyYXJhamFuLCBMYWtzaG1pDQoNCg0KDQoNCg0KSGkgZm9sa3MsDQoN CkF0IFBhbmFzYXMsIHdlIGFyZSB3b3JraW5nIHdpdGggdGhlIEludGVsIFhMNzEwIDQwRyBOSUMg KGFrYSBGb3J0dmlsbGUpLA0KYW5kIHdlJ3JlIHNlZWluZyBzb21lIHBlcmZvcm1hbmNlIGlzc3Vl cyB3LyAxMS1DVVJSRU5UIChyMjgyNjUzKS4NCg0KICAgIE1vdGhlcmJvYXJkOiBJbnRlbCBTMjYw MEtQIChha2EgS2VubmVkeSBQYXNzKQ0KICAgIENQVTogRTUtMjY2MCB2MyBAIDIuNkdIeiAoYWth IEhhc3dlbGwgWGVvbikNCiAgICAgICAgKDEgc29ja2V0IHggMTAgcGh5c2ljYWwgY29yZXMgeCAy IFNNVCB0aHJlYWRzKSA9IDIwIGxvZ2ljYWwgY29yZXMNCiAgICBOSUM6IEludGVsIFhMNzEwLCAy eDQwR2JwcyBRU0ZQLCBjb25maWd1cmVkIGluIDR4MTBHYnBzIG1vZGUNCiAgICBSQU06IDR4IDE2 R0IgRERSNCBESU1Ncw0KDQpXaGF0IHdlJ3ZlIHNlZW4gc28gZmFyOg0KDQogIC0gVFggcGVyZm9y bWFuY2UgaXMgcHJldHR5IGNvbnNpc3RlbnRseSBsb3dlciB0aGFuIFJYIHBlcmZvcm1hbmNlLiBB bGwNCm51bWJlcnMgYmVsb3cgYXJlIGZvciB1bmlkcmVjdGlvbmFsIHRlc3RzIHVzaW5nIGBpcGVy Zic6DQogICAgICAgIDEwR2JwcyBsaW5rcyAgICB0aHJlYWRzL2xpbmsgICAgVFggR2JwcyAgICAg UlggR2JwcyAgICAgVFgvUlgNCiAgICAgICAgMSAgICAgICAgICAgICAgIDEgICAgICAgICAgICAg ICA5LjAyICAgICAgICA5Ljg1ICAgICAgICA5MS41NyUNCiAgICAgICAgMSAgICAgICAgICAgICAg IDggICAgICAgICAgICAgICA4LjQ5ICAgICAgICA5LjkxICAgICAgICA4NS42NyUNCiAgICAgICAg MSAgICAgICAgICAgICAgIDE2ICAgICAgICAgICAgICA3LjAwICAgICAgICA5LjkxICAgICAgICA3 MC42MyUNCiAgICAgICAgMSAgICAgICAgICAgICAgIDMyICAgICAgICAgICAgICA2LjY4ICAgICAg ICA5LjkyICAgICAgICA2Ny40MCUNCg0KICAtIFdpdGggbXVsdGlwbGUgYWN0aXZlIGxpbmtzLCBi b3RoIFRYIGFuZCBSWCBwZXJmb3JtYW5jZSBzdWZmZXIgZ3JlYXRseTsNCnRoZSBhZ2dyZWdhdGUg YmFuZHdpZHRoIHRvcHMgb3V0IGF0IGFib3V0IGEgdGhpcmQgb2YgdGhlIHRoZW9yZXRpY2FsDQo0 MEdicHMgaW1wbGllZCBieSA0eCAxMEdicHMuDQogICAgICAgIDEwR2JwcyBsaW5rcyAgICB0aHJl YWRzL2xpbmsgICAgVFggR2JwcyAgICAgUlggR2JwcyAgICAgJSBvZiA0MEdicHMNCiAgICAgICAg NCAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAxMy4zOSAgICAgICAxMy4zOCAgICAgICAz My40JQ0KDQogIC0gTXVsdGktbGluayBiaWRpcmVjdGlvbmFsIHRocm91Z2hwdXQgaXMgYWJzb2x1 dGVseSB0ZXJyaWJsZTsgdGhlDQphZ2dyZWdhdGUgaXMgbGVzcyB0aGFuIGEgdGVudGggb2YgdGhl IHRoZW9yZXRpY2FsIDQwR2Jwcy4NCiAgICAgICAgMTBHYnBzIGxpbmtzICAgIHRocmVhZHMvbGlu ayAgICBUWCBHYnBzICAgICBSWCBHYnBzICAgICAlIG9mIDQwR2Jwcw0KICAgICAgICA0ICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgIDMuODMgICAgICAgIDIuOTYgICAgICAgIDkuNiUgLyA3 LjQlDQoNCiAgLSBPY2Nhc2lvbmFsIGludGVycnVwdCBzdG9ybSBtZXNzYWdlcyBhcmUgc2VlbiBm cm9tIHRoZSBJUlFzIGFzc29jaWF0ZWQNCndpdGggdGhlIE5JQ3MuIFNpbmNlIHRoYXQgY2FuIGlt cGFjdCBwZXJmb3JtYW5jZSwgdGhvc2UgcnVucyB3ZXJlIG5vdA0KaW5jbHVkZWQgaW4gdGhlIGRh dGEgbGlzdGVkIGFib3ZlLg0KDQpPdXIgcXVlc3Rpb25zOg0KDQogIC0gSG93IHN0YWJsZSBpcyBp eGwoNCkgaW4gLUNVUlJFTlQ/IEJ5IHRoYXQsIHdlIG1lYW4gYm90aCBob3cgcXVpY2tseSBpcw0K dGhlIGRyaXZlciBjaGFuZ2luZywgYW5kIGRvZXMgdGhlIGRyaXZlciBjYXVzZSBhbnkgc3lzdGVt IGluc3RhYmlsaXR5Pw0KDQogIC0gV2hhdCB0eXBlIG9mIHBlcmZvcm1hbmNlIGhhdmUgb3RoZXJz IGJlZW4gZ2V0dGluZyB3LyBGb3J0dmlsbGU/IEluDQo0MEdicHMgbW9kZT8gSW4gNHgxMEdicHMg bW9kZT8NCg0KICAtIERvZXMgYW55b25lIGhhdmUgYW55IHR1bmluZyBwYXJhbWV0ZXJzIHRoZXkg Y2FuIHJlY29tbWVuZCBmb3IgdGhpcw0KY2FyZD8NCg0KICAtIFdlIGRpZCBvdXIgdGVzdGluZyB3 LyAxMS1DVVJSRU5ULCBidXQgd2Ugd2lsbCBpbml0aWFsbHkgc2hpcCBGb3J0dmlsbGUNCnJ1bm5p bmcgb24gMTAuMS1SRUxFQVNFIG9yIDEwLjItUkVMRUFTRS4gVGhlIHByZXNlbmNlIG9mIFJTUyAt IGV2ZW4gdGhvdWdoDQppdCBpcyBkaXNhYmxlZCBieSBkZWZhdWx0IC0gbWFrZXMgdGhlIGRyaXZl ciBiYWNrLXBvcnQgbm9uLXRyaXZpYWwuIElzDQp0aGVyZSBhbiBlc3RpbWF0ZSBvbiB3aGVuIHRo ZSAxMS1DVVJSRU5UIHZlcnNpb24gb2YgdGhlIGRyaXZlciAoMS40LjEpDQp3aWxsIGdldCBNRkNl ZCB0byAxMC1TVEFCTEU/DQoNCk15IGNvbGxlYWd1ZXMgTGFrc2htaSBhbmQgRnJlZCAoQ0NlZCkg YXJlIHdvcmtpbmcgb24gdGhpczsgcGxlYXNlIG1ha2UNCnN1cmUgdG8gaW5jbHVkZSB0aGVtIGlm IHlvdSBoYXZlIGFueSBjb21tZW50cy4NCg0KVGhhbmtzLA0KDQpSYXZp From owner-freebsd-net@FreeBSD.ORG Tue May 26 21:58:39 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 3438585A; Tue, 26 May 2015 21:58:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::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 EF2A783A; Tue, 26 May 2015 21:58:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcau1 with SMTP id au1so24747igc.1; Tue, 26 May 2015 14:58:38 -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:content-transfer-encoding; bh=O1JCFCOfun1InhigWx0spqSnjb2Izh2uMT/dH0LLj2g=; b=XONY0YUAZGrqkx2DXHBoxjDv+kYLd7a1CzgPDi1g6AThp4zddMPX/H3OhCqdrtslTl N9w88C8TNwAnZxPLflIUG5UkNEj0hvCUJ7dLKR9ZwrtwY7+wx9Iq2jGoFAA+Ut2w7xX8 eGLuUuSjweSfEgKCuIqxmcb3Lnf92kgCRp5cjEReJR3seoL54dHlXLu1DWKVau+5WdAK KltjrxZqF2g7xdZnYR88ydbn4LqA5qy4GonOY+75DjQlqWqgPSuNY7TM9O2lxtBziufc ZGOAnFpBSonm2kBUU5UpO6s3YiICRpwZv7H2tBPIsBU1jAfrvyWVaiyh8B5grAqK74TH UYuw== MIME-Version: 1.0 X-Received: by 10.107.155.81 with SMTP id d78mr37787128ioe.29.1432677518268; Tue, 26 May 2015 14:58:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Tue, 26 May 2015 14:58:38 -0700 (PDT) In-Reply-To: <5564b545.0287440a.5871.7050@mx.google.com> References: <5564b545.0287440a.5871.7050@mx.google.com> Date: Tue, 26 May 2015 14:58:38 -0700 X-Google-Sender-Auth: _-7uPVPEeehmQChtfdNpOKupnPI Message-ID: Subject: Re: Performance issues with Intel Fortville (XL710/ixl(4)) From: Adrian Chadd To: Lakshmi Narasimhan Sundararajan Cc: "Pokala, Ravi" , "freebsd-net@freebsd.org" , "jfv@freebsd.org" , "erj@freebsd.org" , "freebsd-hackers@freebsd.org" , "Lewis, Fred" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 26 May 2015 21:58:39 -0000 hi! Try enabling RSS and PCBGROUPS on -HEAD. The ixl driver should work. (I haven't tested it though; I've had other things going on here.) -adrian On 21 May 2015 at 15:20, Lakshmi Narasimhan Sundararajan wrote: > Hi FreeBSD Team! > > We seem to have found a problem to Tx performance. > > We found that the tx handling is spread on all CPUs causing probably cach= e trashing resulting in poor performance. > > But once we used cpuset to bind interrupt thread and iperf process to the= same CPU, performance was close to line rate. I used userland cpuset comma= nd to perform this manually. I want this constrained in the kernel config/c= ode through some tunables, and I am seeking your help/pointers in that rega= rd. > > > My followup questions are as follows. > > a) How are Tx interrupts steered from the NIC to the CPU on the transmit = path? Would tx_complete# interrupt for packets transmitted from CPU#x, be s= erviced on the same CPU? If not, how to get this binding done? > > > b) I would like to use a pool of CPUs dedicated to service NIC interrupts= . Especially on the transmit path, I would want the tx_interrupts to be han= dled on the same CPU on which request was submitted. How to get this done? > > > I played with the current ISR setting but I did not see any difference in= how Interrupts are scheduled across CPU. The max interrupt threads even th= ough set to one, the interrupt threads are scheduled on any CPU. Even if I = set bindthreads to =E2=80=981=E2=80=99. There is no difference in interrupt= thread scheduling. > > > root@mau-da-27-4-1:~ # sysctl net.isr > net.isr.dispatch: direct > net.isr.maxthreads: 1 > net.isr.bindthreads: 0 > net.isr.maxqlimit: 10240 > net.isr.defaultqlimit: 256 > net.isr.maxprot: 16 > net.isr.numthreads: 1 > > > I would sincerely appreciate if you can provide some pointers on these it= ems above. > > > > > Thanks > > LN > > > > > > > > From: Pokala, Ravi > Sent: =E2=80=8EWednesday=E2=80=8E, =E2=80=8EMay=E2=80=8E =E2=80=8E20=E2= =80=8E, =E2=80=8E2015 =E2=80=8E3=E2=80=8E:=E2=80=8E34=E2=80=8E =E2=80=8EAM > To: freebsd-net@freebsd.org, jfv@freebsd.org, erj@freebsd.org > Cc: freebsd-hackers@freebsd.org, Lewis, Fred, Sundararajan, Lakshmi > > > > > > 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 cor= es > 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 40Gb= ps > 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 40Gb= ps > 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 i= s > 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 Fortvill= e > running on 10.1-RELEASE or 10.2-RELEASE. The presence of RSS - even thoug= h > 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 > _______________________________________________ > 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 Wed May 27 13:51: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 49B27154 for ; Wed, 27 May 2015 13:51:29 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) 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 21D529ED for ; Wed, 27 May 2015 13:51:29 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) 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 t4RDpSeP053564 for ; Wed, 27 May 2015 13:51:28 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 t4RDpSd7053563; Wed, 27 May 2015 13:51:28 GMT (envelope-from daemon-user) Date: Wed, 27 May 2015 13:51:28 +0000 To: freebsd-net@freebsd.org From: "hselasky (Hans Petter Selasky)" Subject: [Differential] [Updated, 87 lines] D1761: Extend LRO support to accumulate more than 65535 bytes Message-ID: X-Priority: 3 Thread-Topic: D1761: Extend LRO support to accumulate more than 65535 bytes X-Herald-Rules: none, <28> 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-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: M2NjZGMxNGQwNjQ0ZTg4NzgyYzE1NGYxMTJmIFVly+A= 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-Type: multipart/mixed; boundary="b1_f7e9182c216193742db0a3516da431bc" 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: Wed, 27 May 2015 13:51:29 -0000 --b1_f7e9182c216193742db0a3516da431bc Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit hselasky updated this revision to Diff 5720. hselasky added a comment. Herald added a subscriber: imp. Minor fix for computing correct ip6_plen in ip6_input(). Previously only the first 64K of the payload was consumed. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1761?vs=3630&id=5720 REVISION DETAIL https://reviews.freebsd.org/D1761 AFFECTED FILES sys/conf/options sys/netinet/ip_input.c sys/netinet/ip_output.c sys/netinet/tcp_input.c sys/netinet/tcp_lro.c sys/netinet6/ip6_input.c sys/sys/mbuf.h EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: hselasky, rrs, glebius, gnn, emaste, lstewart, rwatson, bz, imp, np, jfv, adrian Cc: imp, freebsd-net --b1_f7e9182c216193742db0a3516da431bc Content-Type: text/x-patch; charset=utf-8; name="D1761.5720.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D1761.5720.patch" ZGlmZiAtLWdpdCBhL3N5cy9zeXMvbWJ1Zi5oIGIvc3lzL3N5cy9tYnVmLmgKLS0tIGEvc3lzL3N5 cy9tYnVmLmgKKysrIGIvc3lzL3N5cy9tYnVmLmgKQEAgLTMwNiw2ICszMDYsNyBAQAogI2RlZmlu ZQlNX0hBU0hUWVBFX1JTU19VRFBfSVBWNgkJOQkvKiBJUHY2IFVEUCA0LXR1cGxlICovCiAjZGVm aW5lCU1fSEFTSFRZUEVfUlNTX1VEUF9JUFY2X0VYCTEwCS8qIElQdjYgVURQIDQtdHVwbGUgKyBl eHQgaGRycyAqLwogCisjZGVmaW5lCU1fSEFTSFRZUEVfTFJPX1RDUAkJMjU0CS8qIFRDUCBsYXJn ZSByZWNlaXZlIG9mZmxvYWQgKi8KICNkZWZpbmUJTV9IQVNIVFlQRV9PUEFRVUUJCTI1NQkvKiBv cmRlcmluZywgbm90IGFmZmluaXR5ICovCiAKICNkZWZpbmUJTV9IQVNIVFlQRV9DTEVBUihtKQko KG0pLT5tX3BrdGhkci5yc3N0eXBlID0gMCkKZGlmZiAtLWdpdCBhL3N5cy9uZXRpbmV0Ni9pcDZf aW5wdXQuYyBiL3N5cy9uZXRpbmV0Ni9pcDZfaW5wdXQuYwotLS0gYS9zeXMvbmV0aW5ldDYvaXA2 X2lucHV0LmMKKysrIGIvc3lzL25ldGluZXQ2L2lwNl9pbnB1dC5jCkBAIC02OTQsNyArNjk0LDEz IEBACiAJICogbSBtYXkgYmUgbW9kaWZpZWQgaW4gaXA2X2hvcG9wdHNfaW5wdXQoKS4KIAkgKiBJ ZiBhIEp1bWJvUGF5bG9hZCBvcHRpb24gaXMgaW5jbHVkZWQsIHBsZW4gd2lsbCBhbHNvIGJlIG1v ZGlmaWVkLgogCSAqLwotCXBsZW4gPSAodV9pbnQzMl90KW50b2hzKGlwNi0+aXA2X3BsZW4pOwor CWlmIChNX0hBU0hUWVBFX0dFVChtKSA9PSBNX0hBU0hUWVBFX0xST19UQ1ApIHsKKwkJaWYgKG0t Pm1fcGt0aGRyLmxlbiA8IHNpemVvZihzdHJ1Y3QgaXA2X2hkcikpCisJCQlwbGVuID0gMDsKKwkJ ZWxzZQorCQkJcGxlbiA9IG0tPm1fcGt0aGRyLmxlbiAtIHNpemVvZihzdHJ1Y3QgaXA2X2hkcik7 CisJfSBlbHNlCisJCXBsZW4gPSAodV9pbnQzMl90KW50b2hzKGlwNi0+aXA2X3BsZW4pOwogCWlm IChpcDYtPmlwNl9ueHQgPT0gSVBQUk9UT19IT1BPUFRTKSB7CiAJCWlmIChpcDZfaW5wdXRfaGJo KG0sICZwbGVuLCAmcnRhbGVydCwgJm9mZiwgJm54dCwgJm91cnMpICE9IDApCiAJCQlyZXR1cm47 CmRpZmYgLS1naXQgYS9zeXMvbmV0aW5ldC90Y3BfbHJvLmMgYi9zeXMvbmV0aW5ldC90Y3BfbHJv LmMKLS0tIGEvc3lzL25ldGluZXQvdGNwX2xyby5jCisrKyBiL3N5cy9uZXRpbmV0L3RjcF9scm8u YwpAQCAtMzIsNiArMzIsNyBAQAogI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgogX19GQlNESUQoIiRG cmVlQlNEJCIpOwogCisjaW5jbHVkZSAib3B0X2xyby5oIgogI2luY2x1ZGUgIm9wdF9pbmV0Lmgi CiAjaW5jbHVkZSAib3B0X2luZXQ2LmgiCiAKQEAgLTYyLDYgKzYzLDE0IEBACiAjZGVmaW5lCUxS T19FTlRSSUVTCTgJLyogIyBvZiBMUk8gZW50cmllcyBwZXIgUlggcXVldWUuICovCiAjZW5kaWYK IAorI2lmbmRlZglMUk9fUEFZTE9BRF9NQVgKKyNkZWZpbmUJTFJPX1BBWUxPQURfTUFYCUlQX01B WFBBQ0tFVAorI2VuZGlmCisKKyNpZiAoTFJPX1BBWUxPQURfTUFYIDwgNjU1MzUpCisjZXJyb3Ig IkxST19QQVlMT0FEX01BWCBtdXN0IGJlIGF0IGxlYXN0IDY1NTM1IGJ5dGVzIgorI2VuZGlmCisK ICNkZWZpbmUJVENQX0xST19VUERBVEVfQ1NVTQkxCiAjaWZuZGVmCVRDUF9MUk9fVVBEQVRFX0NT VU0KICNkZWZpbmUJVENQX0xST19JTlZBTElEX0NTVU0JMHgwMDAwCkBAIC0yMTksOCArMjI4LDIw IEBACiAJaWYgKGxlLT5hcHBlbmRfY250ID4gMCkgewogCQlzdHJ1Y3QgdGNwaGRyICp0aDsKIAkJ dWludDE2X3QgcF9sZW47Ci0KLQkJcF9sZW4gPSBodG9ucyhsZS0+cF9sZW4pOworCQkvKgorCQkg KiBUaGUgVENQL0lQIHN0YWNrIHNob3VsZCB1c2UgdGhlICJtX3BrdGhkci5sZW4iCisJCSAqIGZp ZWxkIGluc3RlYWQgb2YgdGhlIElQLXBheWxvYWQgbGVuZ3RoIGZpZWxkIHRvCisJCSAqIGNvbXB1 dGUgdGhlIHRvdGFsIFRDUCBwYXlsb2FkIGxlbmd0aCB3aGVuIGl0CisJCSAqIHJlY29nbml6ZXMg dGhlIE1fSEFTSFRZUEVfTFJPX1RDUCBoYXNoIHR5cGUuIFRoaXMKKwkJICogYWxsb3dzIGFjY3Vt dWxhdGlvbiBvZiBtb3JlIHRoYW4gNjRLYnl0ZXMgd29ydGggb2YKKwkJICogcGF5bG9hZCBkYXRh LgorCQkgKi8KKwkJaWYgKGxlLT5wX2xlbiA+IElQX01BWFBBQ0tFVCkgeworCQkJTV9IQVNIVFlQ RV9TRVQobGUtPm1faGVhZCwgTV9IQVNIVFlQRV9MUk9fVENQKTsKKwkJCXBfbGVuID0gaHRvbnMo SVBfTUFYUEFDS0VUKTsKKwkJfSBlbHNlIHsKKwkJCXBfbGVuID0gaHRvbnMobGUtPnBfbGVuKTsK KwkJfQogCQlzd2l0Y2ggKGxlLT5laF90eXBlKSB7CiAjaWZkZWYgSU5FVDYKIAkJY2FzZSBFVEhF UlRZUEVfSVBWNjoKQEAgLTUwMSw3ICs1MjIsNyBAQAogCQl9CiAKIAkJLyogRmx1c2ggbm93IGlm IGFwcGVuZGluZyB3aWxsIHJlc3VsdCBpbiBvdmVyZmxvdy4gKi8KLQkJaWYgKGxlLT5wX2xlbiA+ ICg2NTUzNSAtIHRjcF9kYXRhX2xlbikpIHsKKwkJaWYgKGxlLT5wX2xlbiA+IChMUk9fUEFZTE9B RF9NQVggLSB0Y3BfZGF0YV9sZW4pKSB7CiAJCQlTTElTVF9SRU1PVkUoJmxjLT5scm9fYWN0aXZl LCBsZSwgbHJvX2VudHJ5LCBuZXh0KTsKIAkJCXRjcF9scm9fZmx1c2gobGMsIGxlKTsKIAkJCWJy ZWFrOwpAQCAtNTU5LDcgKzU4MCw3IEBACiAJCSAqIElmIGEgcG9zc2libGUgbmV4dCBmdWxsIGxl bmd0aCBwYWNrZXQgd291bGQgY2F1c2UgYW4KIAkJICogb3ZlcmZsb3csIHByby1hY3RpdmVseSBm bHVzaCBub3cuCiAJCSAqLwotCQlpZiAobGUtPnBfbGVuID4gKDY1NTM1IC0gbGMtPmlmcC0+aWZf bXR1KSkgeworCQlpZiAobGUtPnBfbGVuID4gKExST19QQVlMT0FEX01BWCAtIGxjLT5pZnAtPmlm X210dSkpIHsKIAkJCVNMSVNUX1JFTU9WRSgmbGMtPmxyb19hY3RpdmUsIGxlLCBscm9fZW50cnks IG5leHQpOwogCQkJdGNwX2xyb19mbHVzaChsYywgbGUpOwogCQl9IGVsc2UKZGlmZiAtLWdpdCBh L3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5jIGIvc3lzL25ldGluZXQvdGNwX2lucHV0LmMKLS0tIGEv c3lzL25ldGluZXQvdGNwX2lucHV0LmMKKysrIGIvc3lzL25ldGluZXQvdGNwX2lucHV0LmMKQEAg LTY0NCw3ICs2NDQsMTAgQEAKIAogCQlpcDYgPSBtdG9kKG0sIHN0cnVjdCBpcDZfaGRyICopOwog CQl0aCA9IChzdHJ1Y3QgdGNwaGRyICopKChjYWRkcl90KWlwNiArIG9mZjApOwotCQl0bGVuID0g c2l6ZW9mKCppcDYpICsgbnRvaHMoaXA2LT5pcDZfcGxlbikgLSBvZmYwOworCQlpZiAoTV9IQVNI VFlQRV9HRVQobSkgPT0gTV9IQVNIVFlQRV9MUk9fVENQKQorCQkJdGxlbiA9IG0tPm1fcGt0aGRy LmxlbiAtIG9mZjA7CisJCWVsc2UKKwkJCXRsZW4gPSBzaXplb2YoKmlwNikgKyBudG9ocyhpcDYt PmlwNl9wbGVuKSAtIG9mZjA7CiAJCWlmIChtLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9E QVRBX1ZBTElEX0lQVjYpIHsKIAkJCWlmIChtLT5tX3BrdGhkci5jc3VtX2ZsYWdzICYgQ1NVTV9Q U0VVRE9fSERSKQogCQkJCXRoLT50aF9zdW0gPSBtLT5tX3BrdGhkci5jc3VtX2RhdGE7CkBAIC02 OTUsOCArNjk4LDEwIEBACiAJCX0KIAkJaXAgPSBtdG9kKG0sIHN0cnVjdCBpcCAqKTsKIAkJdGgg PSAoc3RydWN0IHRjcGhkciAqKSgoY2FkZHJfdClpcCArIG9mZjApOwotCQl0bGVuID0gbnRvaHMo aXAtPmlwX2xlbikgLSBvZmYwOwotCisJCWlmIChNX0hBU0hUWVBFX0dFVChtKSA9PSBNX0hBU0hU WVBFX0xST19UQ1ApCisJCQl0bGVuID0gbS0+bV9wa3RoZHIubGVuIC0gb2ZmMDsKKwkJZWxzZQor CQkJdGxlbiA9IG50b2hzKGlwLT5pcF9sZW4pIC0gb2ZmMDsKIAkJaWYgKG0tPm1fcGt0aGRyLmNz dW1fZmxhZ3MgJiBDU1VNX0RBVEFfVkFMSUQpIHsKIAkJCWlmIChtLT5tX3BrdGhkci5jc3VtX2Zs YWdzICYgQ1NVTV9QU0VVRE9fSERSKQogCQkJCXRoLT50aF9zdW0gPSBtLT5tX3BrdGhkci5jc3Vt X2RhdGE7CmRpZmYgLS1naXQgYS9zeXMvbmV0aW5ldC9pcF9vdXRwdXQuYyBiL3N5cy9uZXRpbmV0 L2lwX291dHB1dC5jCi0tLSBhL3N5cy9uZXRpbmV0L2lwX291dHB1dC5jCisrKyBiL3N5cy9uZXRp bmV0L2lwX291dHB1dC5jCkBAIC0xMjQsMTMgKzEyNCwxNCBAQAogCXN0cnVjdCBpZm5ldCAqaWZw ID0gTlVMTDsJLyoga2VlcCBjb21waWxlciBoYXBweSAqLwogCXN0cnVjdCBtYnVmICptMDsKIAlp bnQgaGxlbiA9IHNpemVvZiAoc3RydWN0IGlwKTsKKwlpbnQgaXBfbGVuOwogCWludCBtdHU7CiAJ aW50IGVycm9yID0gMDsKIAlzdHJ1Y3Qgc29ja2FkZHJfaW4gKmRzdDsKIAljb25zdCBzdHJ1Y3Qg c29ja2FkZHJfaW4gKmd3OwogCXN0cnVjdCBpbl9pZmFkZHIgKmlhOwogCWludCBpc2Jyb2FkY2Fz dDsKLQl1aW50MTZfdCBpcF9sZW4sIGlwX29mZjsKKwl1aW50MTZfdCBpcF9vZmY7CiAJc3RydWN0 IHJvdXRlIGlwcm91dGU7CiAJc3RydWN0IHJ0ZW50cnkgKnJ0ZTsJLyogY2FjaGUgZm9yIHJvLT5y b19ydCAqLwogCXN0cnVjdCBpbl9hZGRyIG9kc3Q7CkBAIC0xNjksNyArMTcwLDExIEBACiAJCQlo bGVuID0gbGVuOyAvKiBpcC0+aXBfaGwgaXMgdXBkYXRlZCBhYm92ZSAqLwogCX0KIAlpcCA9IG10 b2QobSwgc3RydWN0IGlwICopOwotCWlwX2xlbiA9IG50b2hzKGlwLT5pcF9sZW4pOworCisJaWYg KE1fSEFTSFRZUEVfR0VUKG0pID09IE1fSEFTSFRZUEVfTFJPX1RDUCkKKwkJaXBfbGVuID0gbS0+ bV9wa3RoZHIubGVuOworCWVsc2UKKwkJaXBfbGVuID0gbnRvaHMoaXAtPmlwX2xlbik7CiAJaXBf b2ZmID0gbnRvaHMoaXAtPmlwX29mZik7CiAKIAlpZiAoKGZsYWdzICYgKElQX0ZPUldBUkRJTkd8 SVBfUkFXT1VUUFVUKSkgPT0gMCkgewpAQCAtNjg4LDkgKzY5MywxMyBAQAogCWludCBmaXJzdGxl bjsKIAlzdHJ1Y3QgbWJ1ZiAqKm1uZXh0OwogCWludCBuZnJhZ3M7Ci0JdWludDE2X3QgaXBfbGVu LCBpcF9vZmY7CisJaW50IGlwX2xlbjsKKwl1aW50MTZfdCBpcF9vZmY7CiAKLQlpcF9sZW4gPSBu dG9ocyhpcC0+aXBfbGVuKTsKKwlpZiAoTV9IQVNIVFlQRV9HRVQobTApID09IE1fSEFTSFRZUEVf TFJPX1RDUCkKKwkJaXBfbGVuID0gbTAtPm1fcGt0aGRyLmxlbjsKKwllbHNlCisJCWlwX2xlbiA9 IG50b2hzKGlwLT5pcF9sZW4pOwogCWlwX29mZiA9IG50b2hzKGlwLT5pcF9vZmYpOwogCiAJaWYg KGlwX29mZiAmIElQX0RGKSB7CS8qIEZyYWdtZW50YXRpb24gbm90IGFsbG93ZWQgKi8KZGlmZiAt LWdpdCBhL3N5cy9uZXRpbmV0L2lwX2lucHV0LmMgYi9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jCi0t LSBhL3N5cy9uZXRpbmV0L2lwX2lucHV0LmMKKysrIGIvc3lzL25ldGluZXQvaXBfaW5wdXQuYwpA QCAtMzk3LDcgKzM5Nyw4IEBACiAJc3RydWN0IGlmYWRkciAqaWZhOwogCXN0cnVjdCBpZm5ldCAq aWZwOwogCWludCAgICBjaGVja2lmLCBobGVuID0gMDsKLQl1aW50MTZfdCBzdW0sIGlwX2xlbjsK Kwl1aW50MzJfdCBpcF9sZW47CisJdWludDE2X3Qgc3VtOwogCWludCBkY2hnID0gMDsJCQkJLyog ZGVzdCBjaGFuZ2VkIGFmdGVyIGZ3ICovCiAJc3RydWN0IGluX2FkZHIgb2RzdDsJCQkvKiBvcmln aW5hbCBkc3QgYWRkcmVzcyAqLwogCkBAIC00NzQsNyArNDc1LDEwIEBACiAJCXJldHVybjsKICNl bmRpZgogCi0JaXBfbGVuID0gbnRvaHMoaXAtPmlwX2xlbik7CisJaWYgKE1fSEFTSFRZUEVfR0VU KG0pID09IE1fSEFTSFRZUEVfTFJPX1RDUCkKKwkJaXBfbGVuID0gbS0+bV9wa3RoZHIubGVuOwor CWVsc2UKKwkJaXBfbGVuID0gbnRvaHMoaXAtPmlwX2xlbik7CiAJaWYgKGlwX2xlbiA8IGhsZW4p IHsKIAkJSVBTVEFUX0lOQyhpcHNfYmFkbGVuKTsKIAkJZ290byBiYWQ7CkBAIC05MDAsNiArOTA0 LDcgQEAKIAlzdHJ1Y3QgaW5fYWRkciBkZXN0OwogCXN0cnVjdCByb3V0ZSBybzsKIAlpbnQgZXJy b3IsIHR5cGUgPSAwLCBjb2RlID0gMCwgbXR1ID0gMDsKKwlpbnQgaXBfbGVuOwogCiAJaWYgKG0t Pm1fZmxhZ3MgJiAoTV9CQ0FTVHxNX01DQVNUKSB8fCBpbl9jYW5mb3J3YXJkKGlwLT5pcF9kc3Qp ID09IDApIHsKIAkJSVBTVEFUX0lOQyhpcHNfY2FudGZvcndhcmQpOwpAQCAtOTY1LDggKzk3MCwx NCBAQAogCQltX2ZyZWUobWNvcHkpOwogCQltY29weSA9IE5VTEw7CiAJfQorCisJaWYgKE1fSEFT SFRZUEVfR0VUKG0pID09IE1fSEFTSFRZUEVfTFJPX1RDUCkKKwkJaXBfbGVuID0gbS0+bV9wa3Ro ZHIubGVuOworCWVsc2UKKwkJaXBfbGVuID0gbnRvaHMoaXAtPmlwX2xlbik7CisKIAlpZiAobWNv cHkgIT0gTlVMTCkgewotCQltY29weS0+bV9sZW4gPSBtaW4obnRvaHMoaXAtPmlwX2xlbiksIE1f VFJBSUxJTkdTUEFDRShtY29weSkpOworCQltY29weS0+bV9sZW4gPSBtaW4oaXBfbGVuLCBNX1RS QUlMSU5HU1BBQ0UobWNvcHkpKTsKIAkJbWNvcHktPm1fcGt0aGRyLmxlbiA9IG1jb3B5LT5tX2xl bjsKIAkJbV9jb3B5ZGF0YShtLCAwLCBtY29weS0+bV9sZW4sIG10b2QobWNvcHksIGNhZGRyX3Qp KTsKIAl9CkBAIC0xMDk0LDcgKzExMDUsNyBAQAogCQkJaWYgKGlhICE9IE5VTEwpCiAJCQkJbXR1 ID0gaWEtPmlhX2lmcC0+aWZfbXR1OwogCQkJZWxzZQotCQkJCW10dSA9IGlwX25leHRfbXR1KG50 b2hzKGlwLT5pcF9sZW4pLCAwKTsKKwkJCQltdHUgPSBpcF9uZXh0X210dShpcF9sZW4sIDApOwog CQl9CiAJCUlQU1RBVF9JTkMoaXBzX2NhbnRmcmFnKTsKIAkJYnJlYWs7CmRpZmYgLS1naXQgYS9z eXMvY29uZi9vcHRpb25zIGIvc3lzL2NvbmYvb3B0aW9ucwotLS0gYS9zeXMvY29uZi9vcHRpb25z CisrKyBiL3N5cy9jb25mL29wdGlvbnMKQEAgLTQwMiw2ICs0MDIsOCBAQAogRFVNTVlORVQJCW9w dF9pcGRuLmgKIElORVQJCQlvcHRfaW5ldC5oCiBJTkVUNgkJCW9wdF9pbmV0Ni5oCitMUk9fRU5U UklFUwkJb3B0X2xyby5oCitMUk9fUEFZTE9BRF9NQVgJCW9wdF9scm8uaAogSVBESVZFUlQKIElQ RklMVEVSCQlvcHRfaXBmaWx0ZXIuaAogSVBGSUxURVJfREVGQVVMVF9CTE9DSwlvcHRfaXBmaWx0 ZXIuaAoK --b1_f7e9182c216193742db0a3516da431bc-- From owner-freebsd-net@FreeBSD.ORG Wed May 27 15:26:20 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 C8694DEF for ; Wed, 27 May 2015 15:26:20 +0000 (UTC) (envelope-from oleg.prozorov@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 51907612 for ; Wed, 27 May 2015 15:26:20 +0000 (UTC) (envelope-from oleg.prozorov@gmail.com) Received: by wifw1 with SMTP id w1so27106376wif.0 for ; Wed, 27 May 2015 08:26:18 -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=YlwRatIljyB0c1yP1yxQ3+E6wSTmfWNbRNeyXgCbz4U=; b=Wr1XBbm2zydmu6+aKPfbMKWtsae7N/zazo/zrj2LkUM3Mscw75CRkBn9ez1O5zxyQO cVwqvwkFSd1tiLlJEe6Ch/Qr7DS89lKUrSAoXDLYu1P6sdF9mpJZw92yLUcvPQLXKUO1 /cWtG7mawEHUd85o0WTZHd9TIPdimvj3OoD6paL2/rGYum5eiqurvt3keZjzrs1hLgQg r+oxXIEr57vJhQnf+4v9TSfHxKp5d8QOmJK9HuQ/BUFu9nueXyRL07jDJ6CR3vcoiChT /GFZb9O5ud8UDhXkygve5EwTLZ4aMdM1U4nEOfVIWfiXYyHlmjFiqAAH1A7v2r+jynRx OAog== MIME-Version: 1.0 X-Received: by 10.180.72.176 with SMTP id e16mr7321010wiv.12.1432740378882; Wed, 27 May 2015 08:26:18 -0700 (PDT) Received: by 10.194.76.243 with HTTP; Wed, 27 May 2015 08:26:18 -0700 (PDT) Date: Wed, 27 May 2015 18:26:18 +0300 Message-ID: Subject: Netmap problem with e1000e driver From: Oleg Prozorov To: 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: Wed, 27 May 2015 15:26:20 -0000 Hello All, I am using Netmap technology in my program and have the problem : when I put eth link down and then have it up netmap goes down with kernel messages: log from dmesg: [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" option) [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 [ 2457.286298] Hardware name: System manufacturer System Product Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 ffffffff810bd10d [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 ffffffff810bd631 [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c 0000000000000000 [ 2457.286310] Call Trace: [ 2457.286312] [] ? dump_stack+0x41/0x51 [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 [ 2457.286328] [] ? note_interrupt+0x241/0x290 [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x190 [ 2457.286336] [] ? handle_irq_event+0x38/0x60 [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 [ 2457.286347] [] ? handle_irq+0x1d/0x30 [ 2457.286350] [] ? do_IRQ+0x49/0xe0 [ 2457.286355] [] ? common_interrupt+0x6d/0x6d [ 2457.286356] [] ? __hrtimer_start_range_ns+0x1cd/0x390 [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 [ 2457.286377] handlers: [ 2457.286384] [] e1000_msix_other [e1000e] [ 2457.286386] Disabling IRQ #44 before i have the next steps: insmod ./netmap.ko insmod ./e1000e/e1000e.ko log from dmesg: [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X [ 1645.704831] 635.291734 [2720] netmap_attach success for eth0 tx 1/256 rx 1/256 queues/slots [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 68:05:ca:28:36:f5 [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network Connection [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to eth5 [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready [ 1645.848756] 635.435799 [2720] netmap_attach success for eth0 tx 1/256 rx 1/256 queues/slots [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 68:05:ca:22:19:e7 [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network Connection [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to eth6 [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx My program used netmap desc: root@debian:/home/debian/Projects/bin# lsmod | grep netmap netmap 99228 5 e1000e Then even if it shows that link is up net map stops to work and only rmmod/insmod and restart of the netmap can bring it back to work. Could you please help me with it ? Thx a lot, Oleg. From owner-freebsd-net@FreeBSD.ORG Wed May 27 16:21:57 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 3CA53F97 for ; Wed, 27 May 2015 16:21:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c: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 BDAEE6B6 for ; Wed, 27 May 2015 16:21:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wicmx19 with SMTP id mx19so117408398wic.0 for ; Wed, 27 May 2015 09:21: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=6xvUKmsRncSWauIwvEN2uvRdfz+68AzBjlyh4abJw+Q=; b=1BVpKGv5+7bmG1LAYVgSK3EhPuKGpF7/PhTrwcY4XoUznM5Sv/cQKPBJGiBjFkULbW CcPxVQTYvLKB710Zyjj6XLHiZZZt/ho+MNv06+TUVq+KCo0hdu3QCCgYj8PDmf6GJOXp oFe9LRJfPnTx69cfVwPGu4Md4axl6dJcRylJobBo1atyfQlLqWm8NsNdD963FQn0XPIK QLYke/jGdia1eV+HZbWBJVjOVWB950aDeXSw9KI5542JyXmInKoprgli6St5EqEK0owS b0kRH208x8QmXpqlZkgHSW2COyWQxueqiBpLYw6GEKFTkgjNeT/PRQa1vVYqsj93dsjq 4EBg== MIME-Version: 1.0 X-Received: by 10.180.91.137 with SMTP id ce9mr7405815wib.76.1432743715102; Wed, 27 May 2015 09:21:55 -0700 (PDT) Received: by 10.194.162.8 with HTTP; Wed, 27 May 2015 09:21:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 09:21:55 -0700 Message-ID: Subject: Re: Netmap problem with e1000e driver From: Jack Vogel To: Oleg Prozorov Cc: "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: Wed, 27 May 2015 16:21:57 -0000 Maybe asking a Linux mailing list about a Linux driver would be more productive :) Jack On Wed, May 27, 2015 at 8:26 AM, Oleg Prozorov wrote: > Hello All, > I am using Netmap technology in my program and have the problem : > when I put eth link down and then have it up netmap goes down with kernel > messages: > > log from dmesg: > > [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" option) > [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O > 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 > [ 2457.286298] Hardware name: System manufacturer System Product > Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 > [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 > ffffffff810bd10d > [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 > ffffffff810bd631 > [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c > 0000000000000000 > [ 2457.286310] Call Trace: > [ 2457.286312] [] ? dump_stack+0x41/0x51 > [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 > [ 2457.286328] [] ? note_interrupt+0x241/0x290 > [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x190 > [ 2457.286336] [] ? handle_irq_event+0x38/0x60 > [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 > [ 2457.286347] [] ? handle_irq+0x1d/0x30 > [ 2457.286350] [] ? do_IRQ+0x49/0xe0 > [ 2457.286355] [] ? common_interrupt+0x6d/0x6d > [ 2457.286356] [] ? > __hrtimer_start_range_ns+0x1cd/0x390 > [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 > [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 > [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 > [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 > [ 2457.286377] handlers: > [ 2457.286384] [] e1000_msix_other [e1000e] > [ 2457.286386] Disabling IRQ #44 > > before i have the next steps: > > insmod ./netmap.ko > insmod ./e1000e/e1000e.ko > > log from dmesg: > > [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k > [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. > [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X > [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X > [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X > [ 1645.704831] 635.291734 [2720] netmap_attach success for eth0 > tx 1/256 rx 1/256 queues/slots > [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock > [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > 68:05:ca:28:36:f5 > [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network > Connection > [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 > [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X > [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X > [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X > [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to eth5 > [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready > [ 1645.848756] 635.435799 [2720] netmap_attach success for eth0 > tx 1/256 rx 1/256 queues/slots > [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock > [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > 68:05:ca:22:19:e7 > [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network > Connection > [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 > [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to eth6 > [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready > [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready > [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready > [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > > > My program used netmap desc: > root@debian:/home/debian/Projects/bin# lsmod | grep netmap > netmap 99228 5 e1000e > > > Then even if it shows that link is up net map stops to work and only > rmmod/insmod and restart of the netmap can bring it back to work. > > Could you please help me with it ? > > Thx a lot, > Oleg. > _______________________________________________ > 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 Wed May 27 21:47:25 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 78CC175C for ; Wed, 27 May 2015 21:47:25 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0066.outbound.protection.outlook.com [207.46.100.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 3D35E135 for ; Wed, 27 May 2015 21:47:24 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from SN2PR0801MB687.namprd08.prod.outlook.com (25.160.17.152) by SN2PR0801MB686.namprd08.prod.outlook.com (25.160.17.151) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 27 May 2015 21:47:17 +0000 Received: from SN2PR0801MB687.namprd08.prod.outlook.com ([25.160.17.152]) by SN2PR0801MB687.namprd08.prod.outlook.com ([25.160.17.152]) with mapi id 15.01.0160.009; Wed, 27 May 2015 21:47:16 +0000 From: David DeSimone To: "net@freebsd.org" Subject: RE: Netmap problem with e1000e driver Thread-Topic: Netmap problem with e1000e driver Thread-Index: AQHQmJGAGO6tR/YvmkOVuCaLnWADBJ2QAVuAgABamlA= Date: Wed, 27 May 2015 21:47:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ddesimone@verio.net; x-originating-ip: [173.74.95.3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB686; 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:SN2PR0801MB686; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0801MB686; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(51704005)(479174004)(53754006)(189002)(13464003)(377454003)(53474002)(24454002)(50986999)(19580405001)(54356999)(4001540100001)(450100001)(33656002)(81156007)(74316001)(64706001)(106356001)(5001960100002)(86362001)(76176999)(19580395003)(101416001)(77156002)(189998001)(2900100001)(68736005)(5001860100001)(46102003)(110136002)(62966003)(102836002)(66066001)(107886002)(97736004)(92566002)(87936001)(106116001)(76576001)(2656002)(99286002)(105586002)(2950100001)(2501003)(5890100001)(2351001)(5001830100001)(40100003)(122556002)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR0801MB686; H:SN2PR0801MB687.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: verio.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: verio.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 21:47:16.3073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 281c3918-264a-4db4-ab20-2dafa1dca324 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB686 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, 27 May 2015 21:47:25 -0000 Actually, Luigi has specifically requested that all users of netmap (Linux = or BSD) use this list to field all of their questions. -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Jack Vogel Sent: Wednesday, May 27, 2015 11:22 AM To: Oleg Prozorov Cc: net@freebsd.org Subject: Re: Netmap problem with e1000e driver Maybe asking a Linux mailing list about a Linux driver would be more productive :) Jack On Wed, May 27, 2015 at 8:26 AM, Oleg Prozorov wrote: > Hello All, > I am using Netmap technology in my program and have the problem : > when I put eth link down and then have it up netmap goes down with kernel > messages: > > log from dmesg: > > [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" optio= n) > [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O > 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 > [ 2457.286298] Hardware name: System manufacturer System Product > Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 > [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 > ffffffff810bd10d > [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 > ffffffff810bd631 > [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c > 0000000000000000 > [ 2457.286310] Call Trace: > [ 2457.286312] [] ? dump_stack+0x41/0x51 > [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 > [ 2457.286328] [] ? note_interrupt+0x241/0x290 > [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x190 > [ 2457.286336] [] ? handle_irq_event+0x38/0x60 > [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 > [ 2457.286347] [] ? handle_irq+0x1d/0x30 > [ 2457.286350] [] ? do_IRQ+0x49/0xe0 > [ 2457.286355] [] ? common_interrupt+0x6d/0x6d > [ 2457.286356] [] ? > __hrtimer_start_range_ns+0x1cd/0x390 > [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 > [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 > [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 > [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 > [ 2457.286377] handlers: > [ 2457.286384] [] e1000_msix_other [e1000e] > [ 2457.286386] Disabling IRQ #44 > > before i have the next steps: > > insmod ./netmap.ko > insmod ./e1000e/e1000e.ko > > log from dmesg: > > [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k > [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. > [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X > [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X > [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X > [ 1645.704831] 635.291734 [2720] netmap_attach success for et= h0 > tx 1/256 rx 1/256 queues/slots > [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock > [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > 68:05:ca:28:36:f5 > [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network > Connection > [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-0= 08 > [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X > [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X > [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X > [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to eth= 5 > [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready > [ 1645.848756] 635.435799 [2720] netmap_attach success for et= h0 > tx 1/256 rx 1/256 queues/slots > [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock > [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > 68:05:ca:22:19:e7 > [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network > Connection > [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-0= 08 > [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to eth= 6 > [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready > [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready > [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready > [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > > > My program used netmap desc: > root@debian:/home/debian/Projects/bin# lsmod | grep netmap > netmap 99228 5 e1000e > > > Then even if it shows that link is up net map stops to work and only > rmmod/insmod and restart of the netmap can bring it back to work. > > Could you please help me with it ? > > Thx a lot, > Oleg. This email message is intended for the use of the person to whom it has bee= n sent, and may contain information that is confidential or legally protect= ed. If you are not the intended recipient or have received this message in = error, you are not authorized to copy, distribute, or otherwise use this me= ssage or its attachments. Please notify the sender immediately by return e-= mail and permanently delete this message and any attachments. Verio Inc. ma= kes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed May 27 22:17:29 2015 Return-Path: Delivered-To: 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 7ADC6FE7 for ; Wed, 27 May 2015 22:17:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 02DEAA99 for ; Wed, 27 May 2015 22:17:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wicmx19 with SMTP id mx19so126745313wic.0 for ; Wed, 27 May 2015 15:17:27 -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=mWPBhhePpJU/kRs4XIajWGA7aFfbFzZLfxEaonm+aNc=; b=OL5r35hdsdIh7ew03jlYcBkB+yMIWevXKAILa2yhQL4x4pGGR4aAi2yPlOWU4A+lmK lWWiXd5vyMCq3K33HR8a4mQWRPEpd0b+46qHmsAWYYtuEY69VldV7nEPtSwyflZI+5IR LQTPpuuo54rRe1gJkQeC2CCxrppykxozPc4WuIR+C4BKuwojdenAvnAMbF13uMxy7rSn lk4mRzJol9rzdW6QQNnDFn4903RuvvuStB6Og8t0gyqGxURpgPuKY+aJVNfRK30bIf8p IZYbgm1o7VHnGa18s0f+vbrwa/Dun9PYd9+JT7AFW1lbPo+6UvDmQ/3axWUo/EreLdC1 xhHw== MIME-Version: 1.0 X-Received: by 10.195.11.168 with SMTP id ej8mr46463161wjd.150.1432765047347; Wed, 27 May 2015 15:17:27 -0700 (PDT) Received: by 10.194.162.8 with HTTP; Wed, 27 May 2015 15:17:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 15:17:27 -0700 Message-ID: Subject: Re: Netmap problem with e1000e driver From: Jack Vogel To: David DeSimone Cc: "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: Wed, 27 May 2015 22:17:29 -0000 Ah, didn't realize that, apologies, and I'll leave it to Luigi then :) Jack On Wed, May 27, 2015 at 2:47 PM, David DeSimone wrote: > Actually, Luigi has specifically requested that all users of netmap (Linux > or BSD) use this list to field all of their questions. > > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] > On Behalf Of Jack Vogel > Sent: Wednesday, May 27, 2015 11:22 AM > To: Oleg Prozorov > Cc: net@freebsd.org > Subject: Re: Netmap problem with e1000e driver > > Maybe asking a Linux mailing list about a Linux driver would be more > productive :) > > Jack > > > On Wed, May 27, 2015 at 8:26 AM, Oleg Prozorov > wrote: > > > Hello All, > > I am using Netmap technology in my program and have the problem : > > when I put eth link down and then have it up netmap goes down with kernel > > messages: > > > > log from dmesg: > > > > [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" > option) > > [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O > > 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 > > [ 2457.286298] Hardware name: System manufacturer System Product > > Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 > > [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 > > ffffffff810bd10d > > [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 > > ffffffff810bd631 > > [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c > > 0000000000000000 > > [ 2457.286310] Call Trace: > > [ 2457.286312] [] ? dump_stack+0x41/0x51 > > [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 > > [ 2457.286328] [] ? note_interrupt+0x241/0x290 > > [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x190 > > [ 2457.286336] [] ? handle_irq_event+0x38/0x60 > > [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 > > [ 2457.286347] [] ? handle_irq+0x1d/0x30 > > [ 2457.286350] [] ? do_IRQ+0x49/0xe0 > > [ 2457.286355] [] ? common_interrupt+0x6d/0x6d > > [ 2457.286356] [] ? > > __hrtimer_start_range_ns+0x1cd/0x390 > > [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 > > [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 > > [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 > > [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 > > [ 2457.286377] handlers: > > [ 2457.286384] [] e1000_msix_other [e1000e] > > [ 2457.286386] Disabling IRQ #44 > > > > before i have the next steps: > > > > insmod ./netmap.ko > > insmod ./e1000e/e1000e.ko > > > > log from dmesg: > > > > [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k > > [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. > > [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) > > set to dynamic conservative mode > > [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X > > [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X > > [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X > > [ 1645.704831] 635.291734 [2720] netmap_attach success for > eth0 > > tx 1/256 rx 1/256 queues/slots > > [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock > > [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > > 68:05:ca:28:36:f5 > > [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network > > Connection > > [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: > E46981-008 > > [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) > > set to dynamic conservative mode > > [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X > > [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X > > [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X > > [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to > eth5 > > [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready > > [ 1645.848756] 635.435799 [2720] netmap_attach success for > eth0 > > tx 1/256 rx 1/256 queues/slots > > [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock > > [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > > 68:05:ca:22:19:e7 > > [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network > > Connection > > [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: > E46981-008 > > [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to > eth6 > > [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready > > [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > > Control: Rx/Tx > > [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready > > [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > > Control: Rx/Tx > > [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready > > [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > > Control: Rx/Tx > > [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > > Control: Rx/Tx > > > > > > My program used netmap desc: > > root@debian:/home/debian/Projects/bin# lsmod | grep netmap > > netmap 99228 5 e1000e > > > > > > Then even if it shows that link is up net map stops to work and only > > rmmod/insmod and restart of the netmap can bring it back to work. > > > > Could you please help me with it ? > > > > Thx a lot, > > Oleg. > > This email message is intended for the use of the person to whom it has > been sent, and may contain information that is confidential or legally > protected. If you are not the intended recipient or have received this > message in error, you are not authorized to copy, distribute, or otherwise > use this message or its attachments. Please notify the sender immediately > by return e-mail and permanently delete this message and any attachments. > Verio Inc. makes no warranty that this email is error or virus free. Thank > you. > _______________________________________________ > 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 Wed May 27 23:42:29 2015 Return-Path: Delivered-To: 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 719BB81B for ; Wed, 27 May 2015 23:42:29 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E566511A for ; Wed, 27 May 2015 23:42:28 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4RNgIRY015898; Thu, 28 May 2015 01:42:18 +0200 (CEST) Received: from [IPv6:2003:55:6b2b:dc00:219c:2dbc:e356:f6c1] (p200300556B2BDC00219C2DBCE356F6C1.dip0.t-ipconnect.de [IPv6:2003:55:6b2b:dc00:219c:2dbc:e356:f6c1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lxpbt4GzVz8x3C; Thu, 28 May 2015 01:42:18 +0200 (CEST) Message-ID: <5566565A.7030200@tzi.de> Date: Thu, 28 May 2015 01:42:18 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "net@freebsd.org" Subject: Crash with GRE und IPFW fwd 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, 27 May 2015 23:42:29 -0000 Hi, I have recurring crashes if I forward GRE packets using IPFW with fwd: - The first fwd rule forwards incoming traffic into a GRE interface. - The second fwd rule forwards GRE packets to a gateway. If there is no GRE traffic, the system is stable. As soon as there is GRE traffic i takes araound one to five minutes until is crashes. If I omit the second fwd rule, it never crashes. I use a FreeBSD 10.1 on a PC Engines APU.1D board. Any Ideas how to debug this? Kind Regards Julian Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x7c fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80a58105 stack pointer = 0x28:0xfffffe00957335e0 frame pointer = 0x28:0xfffffe00957336e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1707 (tcpmssd) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80963000 at kdb_backtrace+0x60 #1 0xffffffff80928125 at panic+0x155 #2 0xffffffff80d258df at trap_fatal+0x38f #3 0xffffffff80d25bf8 at trap_pfault+0x308 #4 0xffffffff80d2525a at trap+0x47a #5 0xffffffff80d0b142 at calltrap+0x8 #6 0xffffffff81a15797 at gre_output+0x467 #7 0xffffffff80a59024 at ip_output+0x11b4 #8 0xffffffff819b257a at div_send+0x33a #9 0xffffffff8099e0b5 at sosend_generic+0x475 #10 0xffffffff809a4425 at kern_sendit+0x245 #11 0xffffffff809a4749 at sendit+0x129 #12 0xffffffff809a460d at sys_sendto+0x4d #13 0xffffffff80d26211 at amd64_syscall+0x351 #14 0xffffffff80d0b42b at Xfast_syscall+0xfb From owner-freebsd-net@FreeBSD.ORG Thu May 28 01:31:42 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 9B9E961E for ; Thu, 28 May 2015 01:31:42 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) 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 88E60E1E for ; Thu, 28 May 2015 01:31:42 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 580B510B092; Wed, 27 May 2015 18:31:35 -0700 (PDT) Date: Wed, 27 May 2015 18:31:35 -0700 From: hiren panchasara To: Julian Kornberger Cc: "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd Message-ID: <20150528013135.GR95600@strugglingcoder.info> References: <5566565A.7030200@tzi.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6nfUOKxk8V1TQsEu" Content-Disposition: inline In-Reply-To: <5566565A.7030200@tzi.de> 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, 28 May 2015 01:31:42 -0000 --6nfUOKxk8V1TQsEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 05/28/15 at 01:42P, Julian Kornberger wrote: > Hi, >=20 > I have recurring crashes if I forward GRE packets using IPFW with fwd: > - The first fwd rule forwards incoming traffic into a GRE interface. > - The second fwd rule forwards GRE packets to a gateway. >=20 > If there is no GRE traffic, the system is stable. As soon as there is=20 > GRE traffic i takes araound one to five minutes until is crashes. > If I omit the second fwd rule, it never crashes. >=20 > I use a FreeBSD 10.1 on a PC Engines APU.1D board. > Any Ideas how to debug this? >=20 > Kind Regards > Julian >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x7c > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80a58105 > stack pointer =3D 0x28:0xfffffe00957335e0 > frame pointer =3D 0x28:0xfffffe00957336e0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1707 (tcpmssd) Where is this from? net/tcpmssd port/package?=20 If so, try disabling/uninstalling it and see if that helps. cheers, Hiren > trap number =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff80963000 at kdb_backtrace+0x60 > #1 0xffffffff80928125 at panic+0x155 > #2 0xffffffff80d258df at trap_fatal+0x38f > #3 0xffffffff80d25bf8 at trap_pfault+0x308 > #4 0xffffffff80d2525a at trap+0x47a > #5 0xffffffff80d0b142 at calltrap+0x8 > #6 0xffffffff81a15797 at gre_output+0x467 > #7 0xffffffff80a59024 at ip_output+0x11b4 > #8 0xffffffff819b257a at div_send+0x33a > #9 0xffffffff8099e0b5 at sosend_generic+0x475 > #10 0xffffffff809a4425 at kern_sendit+0x245 > #11 0xffffffff809a4749 at sendit+0x129 > #12 0xffffffff809a460d at sys_sendto+0x4d > #13 0xffffffff80d26211 at amd64_syscall+0x351 > #14 0xffffffff80d0b42b at Xfast_syscall+0xfb > _______________________________________________ > 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" --6nfUOKxk8V1TQsEu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVZm/3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lLEMH/0PNo5hPdWdKLZ28T2SywVTq ky7ApXhhV5pWyJeS6YcXu2aXYYmnvkEnvqmEBEYmwlUhbDNbpOYJ5K6dYzdZjwE4 f5PEHt6t5Amqn4JJ96HEUbSvMekI0mGqBU6OHvsVfN4VhLs/w0lg/j4tQXxF9rFG T0eT7J0roAIsOIFBwcgexWGeBlTtePPe5+w473pCU14WJOXOuxdjo+s2QYnLSgeL 7ZYkD504Y+KllCCghO0hfFkVXV4h+J1yQWKFdT9nr9bCSjnabov06TEzbV7Bt6zp 1Qf7LHQIVBBMwmD6pY+EPssoVlUJSQsso3hk8mgZzhBN0SbCNwAWUdkUODIWBL8= =LtR5 -----END PGP SIGNATURE----- --6nfUOKxk8V1TQsEu-- From owner-freebsd-net@FreeBSD.ORG Thu May 28 03:29: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 3167952F for ; Thu, 28 May 2015 03:29:14 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F243BCB1 for ; Thu, 28 May 2015 03:29:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-250-63.lns20.per4.internode.on.net [121.45.250.63]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t4S3T96e073884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 27 May 2015 20:29:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <55668B7F.9010509@freebsd.org> Date: Thu, 28 May 2015 11:29:03 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <20150528013135.GR95600@strugglingcoder.info> In-Reply-To: <20150528013135.GR95600@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252; 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: Thu, 28 May 2015 03:29:14 -0000 On 5/28/15 9:31 AM, hiren panchasara wrote: > On 05/28/15 at 01:42P, Julian Kornberger wrote: >> Hi, >> >> I have recurring crashes if I forward GRE packets using IPFW with fwd: >> - The first fwd rule forwards incoming traffic into a GRE interface. >> - The second fwd rule forwards GRE packets to a gateway. >> >> If there is no GRE traffic, the system is stable. As soon as there is >> GRE traffic i takes araound one to five minutes until is crashes. >> If I omit the second fwd rule, it never crashes. >> >> I use a FreeBSD 10.1 on a PC Engines APU.1D board. >> Any Ideas how to debug this? >> >> Kind Regards >> Julian >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x7c >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80a58105 >> stack pointer = 0x28:0xfffffe00957335e0 >> frame pointer = 0x28:0xfffffe00957336e0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 1707 (tcpmssd) > Where is this from? net/tcpmssd port/package? > > If so, try disabling/uninstalling it and see if that helps. no it's inherrent kernel behaviour. Julian, I am guessing (with no actual information) that something in gre processing is assuming that the packet id going where it normally would go. (and not where fwd is sending it). you really need to use objdump or gdb to look at the gre module and work out where gre_output+0x467 is in the function. that should give you a clue on the problem. not too helpful I know... but you have a reproducible case at least. kgdb may be your friend if you have a serial cable or firewire cable. > > cheers, > Hiren >> trap number = 12 >> panic: page fault >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff80963000 at kdb_backtrace+0x60 >> #1 0xffffffff80928125 at panic+0x155 >> #2 0xffffffff80d258df at trap_fatal+0x38f >> #3 0xffffffff80d25bf8 at trap_pfault+0x308 >> #4 0xffffffff80d2525a at trap+0x47a >> #5 0xffffffff80d0b142 at calltrap+0x8 >> #6 0xffffffff81a15797 at gre_output+0x467 >> #7 0xffffffff80a59024 at ip_output+0x11b4 >> #8 0xffffffff819b257a at div_send+0x33a >> #9 0xffffffff8099e0b5 at sosend_generic+0x475 >> #10 0xffffffff809a4425 at kern_sendit+0x245 >> #11 0xffffffff809a4749 at sendit+0x129 >> #12 0xffffffff809a460d at sys_sendto+0x4d >> #13 0xffffffff80d26211 at amd64_syscall+0x351 >> #14 0xffffffff80d0b42b at Xfast_syscall+0xfb >> _______________________________________________ >> 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 28 04:40:15 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 8617BB41 for ; Thu, 28 May 2015 04:40:15 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::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 4561DE7A for ; Thu, 28 May 2015 04:40:15 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by yhda23 with SMTP id a23so8167997yhd.2 for ; Wed, 27 May 2015 21:40:14 -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:content-type; bh=DbajXVin1jwOnWtxsKaHtmNZ2UXeXGQcko9kKDrwvpM=; b=gtAc/5SSstkExhe2MCKznehlJX/8CTkESPw6K8cInA+DThhhZ6I41cSmybySIUjKOk 0v442gVqNG7yKj2ji/gQnAQxfO7w5pHgrJjS++8fqCxnT5xx5G2r+mtgKfceIzF5E9Ah BDbEZMb/eRnFKtcxJpYOgjl9gLdTY4iVvAqHd+AXNIhzL0HVUSdCb+UVGKRnY1IPeOw0 aQEa4t1cAZ/EXnD0FSTlraBdk2Nfn/m5DHxfsFNIoo1aoKFVQ7NKiXFaJMGsFxM41jKk boeLmE9D1C7FZgLN98EU2IMV76RNINvA5/vqeWaKEIz1cWaQ+4LwAah4EQfnHsOeMdIr D9Ig== MIME-Version: 1.0 X-Received: by 10.170.53.1 with SMTP id 1mr949933ykv.51.1432788014170; Wed, 27 May 2015 21:40:14 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.13.201.71 with HTTP; Wed, 27 May 2015 21:40:14 -0700 (PDT) Date: Thu, 28 May 2015 00:40:14 -0400 X-Google-Sender-Auth: GuXukhTxabuiwI-IYupo5nwS8PM Message-ID: Subject: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" From: Patrick Kelsey 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, 28 May 2015 04:40:15 -0000 Hi, I've had a patch for a capsicum-related issue in tcpdump sitting around since last September ( https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052049.html) that is still needed and that I want finally address in the tree (the patch was reviewed by rwatson@ and pjd@ back then). This issue was patched separately in the upstream tcpdump sources in February ( https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8c0ef9a5af1a95b43753e3ad2eb), along with a refactor of the associated capsicum code, and that work has been present in tcpdump releases since 4.7.3 ( http://www.tcpdump.org/tcpdump-changes.txt). The last tcpdump release imported into the FreeBSD tree was 4.6.2 ( http://svnweb.freebsd.org/base/vendor/tcpdump/). tcpdump release import/merges have recently resulted in some confusion/lost local patches due to the extent of the diffs (e.g., the thread at https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067853.html). I see three possible ways to proceed: 1. Apply the minimal-local-diff patch from last September to our local tcpdump sources. This seems like it might contribute to a future difficult/lossy tcpdump vendor import/merge. 2. Import tcpdump 4.7.3 or later to address this issue. Are there any reasons why this might not be desired? I don't have a feel for when/why past tcpdump vendor imports have been performed or avoided. 3. Cherry-pick the upstream patch and apply it to our local sources, directly addressing only this issue and avoiding future tcpdump vendor import/merge problems related to this issue. I'm looking for input on the above. If left to my own devices, I'd go with (3). Thanks! -Patrick From owner-freebsd-net@FreeBSD.ORG Thu May 28 04:55: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 9A1FAEA4; Thu, 28 May 2015 04:55:52 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) 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 8584D2FF; Thu, 28 May 2015 04:55:52 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 6884E10BA5B; Wed, 27 May 2015 21:55:51 -0700 (PDT) Date: Wed, 27 May 2015 21:55:51 -0700 From: hiren panchasara To: Patrick Kelsey Cc: "freebsd-net@freebsd.org" , delphij@FreeBSD.org Subject: Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" Message-ID: <20150528045551.GS95600@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7PFf0A+xzvFOD9h" 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, 28 May 2015 04:55:52 -0000 --i7PFf0A+xzvFOD9h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 05/28/15 at 12:40P, Patrick Kelsey wrote: > Hi, >=20 > I've had a patch for a capsicum-related issue in tcpdump sitting around > since last September ( > https://lists.freebsd.org/pipermail/freebsd-current/2014-September/052049= =2Ehtml) > that is still needed and that I want finally address in the tree (the pat= ch > was reviewed by rwatson@ and pjd@ back then). >=20 > This issue was patched separately in the upstream tcpdump sources in > February ( > https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8c0ef9a5= af1a95b43753e3ad2eb), > along with a refactor of the associated capsicum code, and that work has > been present in tcpdump releases since 4.7.3 ( > http://www.tcpdump.org/tcpdump-changes.txt). >=20 > The last tcpdump release imported into the FreeBSD tree was 4.6.2 ( > http://svnweb.freebsd.org/base/vendor/tcpdump/). >=20 > tcpdump release import/merges have recently resulted in some confusion/lo= st > local patches due to the extent of the diffs (e.g., the thread at > https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067853.htm= l). >=20 > I see three possible ways to proceed: >=20 > 1. Apply the minimal-local-diff patch from last September to our local > tcpdump sources. This seems like it might contribute to a future > difficult/lossy tcpdump vendor import/merge. >=20 > 2. Import tcpdump 4.7.3 or later to address this issue. Are there any > reasons why this might not be desired? I don't have a feel for when/why > past tcpdump vendor imports have been performed or avoided. >=20 > 3. Cherry-pick the upstream patch and apply it to our local sources, > directly addressing only this issue and avoiding future tcpdump vendor > import/merge problems related to this issue. >=20 > I'm looking for input on the above. If left to my own devices, I'd go wi= th > (3). Latest upstream release is 4.7.4 and the one before that was 4.6.2 which we already have in the tree. I think we should get latest instead of picking bits and pieces when possible. CCing Xin for his input as he has been doing last few imports. Cheers, Hiren --i7PFf0A+xzvFOD9h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVZp/WXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/ln3QH/0z4pGdaRzskjEu1QACKy1SG cElSl4yHVqv075EuQldrXsUkvJXgmnuQgVLdMrnepqWaHMf+MR5+LYYztV5HvnOO iP3QCk3XvGxpkGPtPCKwcfW6qcge4p/AN8h9gh1exjVhsceF6fxB1X5xmDC3XsSj 0MZmFUVSxF2Va27cBXPGNla+gwBp93mB7dhY8cBUljYN/5IS4V1r57ACsDxSDIAw LwEBSJO5AbNwGqagJfdklAKq2QjVhtPKd237dNNegC9QcJZVBMktIZbWPYwjMCbT mLNvfXlSGLKTDAoJQuf1FL/DdKalMKSCmZ00pv+gZFk+v1zlu9edCK68q/2ejgo= =MBWT -----END PGP SIGNATURE----- --i7PFf0A+xzvFOD9h-- From owner-freebsd-net@FreeBSD.ORG Thu May 28 06:47:30 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 38318620 for ; Thu, 28 May 2015 06:47:30 +0000 (UTC) (envelope-from caldweba@colorado.edu) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (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 0126CB0 for ; Thu, 28 May 2015 06:47:29 +0000 (UTC) (envelope-from caldweba@colorado.edu) Received: by ieczm2 with SMTP id zm2so31397175iec.1 for ; Wed, 27 May 2015 23:47:23 -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=Hfcc+INfdyQ0L2QY3ojV9p2Hk38YjSTLMg6Slysgzl4=; b=VmQzyW2dA0B1SN1WJ7YM7W0l62Q8h+vqRuai39C4b0lDdECA3OIqF3c3ilQ0j1RuKb XAphf5eM9kzFoXM0qy7AbrQHWN+pwBK2rFxlvXA7g8RCvBcpCpv1qwQEvNS1Bj84yEuM 8aCmOVgVv8RBFjiuIQxqySn+tSPRvCuvDFEiIKP8naJCn/QMMj9XXaFuC6Wtc85drQea 0OpV2qLhrOojN4b/TOdiDtN7MaFtIrc8APUwTP3lU7Y6uGZ0SJWEwy3/p8sCbs2L6vTO 582IESLS/zxRpP+6eozddRMITDw8sX8FfY2vXnv7OJ9SHOETs5X4AvS4EMqUCqfWHT/I mc6g== X-Gm-Message-State: ALoCoQmKYZGKjwYdWqVjmPMpL9oCVMShRjvZG5ZWN68EhB+HcbIi7hIIs2g1fFD8MpX+I39b1d7N X-Received: by 10.50.62.148 with SMTP id y20mr41716224igr.17.1432795643210; Wed, 27 May 2015 23:47:23 -0700 (PDT) Received: from vpn-cuboulder28-78-dhcp.colorado.edu (vpn-cuboulder28-78-dhcp.colorado.edu. [198.11.28.78]) by mx.google.com with ESMTPSA id fm3sm12541973igb.1.2015.05.27.23.47.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 May 2015 23:47:22 -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: Date: Thu, 28 May 2015 00:47:20 -0600 Cc: "freebsd-net@freebsd.org" Message-Id: References: <3010CFE2-66B7-416B-92DE-C1B669CC33BE@colorado.edu> <555C9F30.8070405@selasky.org> To: Luigi Rizzo , Hans Petter Selasky , Oded Shanoon X-Mailer: Apple Mail (2.2098) Content-Type: text/plain; charset=windows-1252 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, 28 May 2015 06:47:30 -0000 Hello, I have made necessary tweaks to the mlx4 patches for a successful build = on Linux 3.13.11 (Ubuntu 14.04) and enabled the driver in the Linux = build system. See: https://github.com/caldweba/netmap.git = for my additional commits. Without any core modifications to the mlx4 netmap driver, I am actually = getting reduced performance, 2.5 Mpps on a 40G port. I=92m interested in = improving the performance of this driver, but as I=92m new to netmap and = even these drivers, some assistance would be welcome. As Luigi = mentioned, the Mellanox developer documentation seems to be a stumbling = point. Would anyone from Mellanox be able to lend some expertise? It would appear mlx4_netmap_txsync() is the place to focus optimization, = and the comments Luigi put in will be helpful. Although I=92m a little = confused the on the remaining work for mlx4_netmap_tx_config (marked = TODO). See = https://github.com/caldweba/netmap/blob/master/LINUX/mlx4_netmap_linux.h = = for Luigi=92s current mlx4_netmap_txsync() code. Below is my output from pkt-gen and from ethtool on the device. Best regards, Blake =97=97=97=97=97 $ sudo build-apps/pkt-gen -i p2p1 -f tx -n 500111222 -l 60 -w 5 060.428278 main [1649] interface is p2p1 060.428770 extract_ip_range [287] range is 10.0.0.1:0 to 10.0.0.1:0 060.428782 extract_ip_range [287] range is 10.1.0.1:0 to 10.1.0.1:0 060.875064 main [1840] mapped 334980KB at 0x7fd1f04d5000 Sending on netmap:p2p1: 8 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> ff:ff:ff:ff:ff:ff) 060.875151 main [1924] Sending 512 packets every 0.000000000 s 060.875158 main [1926] Wait 5 secs for phy reset 065.875244 main [1928] Ready... 065.875276 nm_open [456] overriding ifname p2p1 ringid 0x0 flags 0x1 065.914805 sender_body [1014] start, fd 4 main_fd 3 065.958284 sender_body [1083] drop copy 066.915788 main_thread [1446] 2468560 pps (2471088 pkts in 1001024 usec) 067.916827 main_thread [1446] 2476292 pps (2478865 pkts in 1001039 usec) 068.917815 main_thread [1446] 2476261 pps (2478708 pkts in 1000988 usec) 069.918864 main_thread [1446] 2476232 pps (2478827 pkts in 1001048 usec) 070.919902 main_thread [1446] 2476031 pps (2478604 pkts in 1001039 usec) 071.920920 main_thread [1446] 2476304 pps (2478825 pkts in 1001018 usec) 072.921896 main_thread [1446] 2476349 pps (2478766 pkts in 1000976 usec) 073.922948 main_thread [1446] 2476327 pps (2478932 pkts in 1001052 usec) 074.923924 main_thread [1446] 2476301 pps (2478715 pkts in 1000975 usec) 075.924903 main_thread [1446] 2476257 pps (2478681 pkts in 1000979 usec) 076.925918 main_thread [1446] 2476195 pps (2478708 pkts in 1001015 usec) 077.926970 main_thread [1446] 2476242 pps (2478849 pkts in 1001053 usec) dmesg: [52591.017469] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.2-1 = (Feb 2014) [52591.017621] mlx4_en 0000:04:00.0: registered PHC clock [52591.017780] mlx4_en 0000:04:00.0: Activating port:1 [52591.023552] mlx4_en: eth0: Using 192 TX rings [52591.023554] mlx4_en: eth0: Using 8 RX rings [52591.023556] mlx4_en: eth0: frag:0 - size:1526 prefix:0 align:0 = stride:1536 [52591.040585] mlx4_en: eth0: Initializing port [52591.040732] 779.121252 [2720] netmap_attach success for = eth0 tx 8/512 rx 8/1024 queues/slots [52591.060580] mlx4_en 0000:04:00.0: Activating port:2 [52591.068337] mlx4_en: eth1: Using 192 TX rings [52591.068340] mlx4_en: eth1: Using 8 RX rings [52591.068342] mlx4_en: eth1: frag:0 - size:1526 prefix:0 align:0 = stride:1536 [52591.085696] mlx4_en: eth1: Initializing port [52591.085867] 779.166352 [2720] netmap_attach success for = eth1 tx 8/512 rx 8/1024 queues/slots [52591.960730] mlx4_en: eth0: Link Up [52593.029536] systemd-udevd[50993]: renamed network interface eth0 to = p2p1 [52593.061736] systemd-udevd[50996]: renamed network interface eth1 to = rename28 [52624.680481] mlx4_en: p2p1: frag:0 - size:1526 prefix:0 align:0 = stride:1536 [52624.834109] 812.888289 [ 473] mlx4_en_tx_irq XXXXXXXXX = tx_irq 0 unexpected, ignoring [55436.322304] 622.179577 [ 665] mlx4_netmap_config using only 8 = out of 192 tx queues [55436.339688] 622.196947 [ 672] mlx4_netmap_config txr 8 txd 512 = bufsize 32768 -- rxr 8 rxd 1024 act 1024 bufsize 16384 [55436.361877] 622.219119 [ 124] mlx4_netmap_reg setting = netmap mode for eth0 to ON [55436.379345] 622.236575 [ 127] mlx4_netmap_reg unloading = eth0 [55436.485781] 622.342926 [ 163] mlx4_netmap_reg loading eth0 [55436.501124] mlx4_en: p2p1: frag:0 - size:1526 prefix:0 align:0 = stride:1536 [55436.517514] 622.374635 [ 628] mlx4_netmap_rx_config stride 16 = possible frags 1 descsize 0 DS_SIZE 16 [55436.536462] 622.393570 [ 648] mlx4_netmap_rx_config ring 0 done [55436.551746] 622.408842 [ 648] mlx4_netmap_rx_config ring 1 done [55436.567111] 622.424194 [ 628] mlx4_netmap_rx_config stride 16 = possible frags 1 descsize 0 DS_SIZE 16 [55436.586261] 622.443330 [ 648] mlx4_netmap_rx_config ring 2 done [55436.601844] 622.458900 [ 648] mlx4_netmap_rx_config ring 3 done [55436.617525] 622.474569 [ 648] mlx4_netmap_rx_config ring 4 done [55436.633057] 622.490089 [ 648] mlx4_netmap_rx_config ring 5 done [55436.648376] 622.505396 [ 648] mlx4_netmap_rx_config ring 6 done [55436.780501] 622.637414 [ 165] mlx4_netmap_reg start_port = returns 0 [55436.796403] mlx4_en: p2p1: Link Down [55437.755281] mlx4_en: p2p1: Link Up $ ethtool p2p1 Settings for p2p1: Supported ports: [ TP ] Supported link modes: 10000baseT/Full=20 Supported pause frame use: No Supports auto-negotiation: No Advertised link modes: 10000baseT/Full=20 Advertised pause frame use: No Advertised auto-negotiation: No Speed: 40000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: off MDI-X: Unknown Cannot get wake-on-lan settings: Operation not permitted Current message level: 0x00000014 (20) link ifdown Link detected: yes $ ethtool -i p2p1 driver: mlx4_en version: 2.2-1 (Feb 2014) firmware-version: 2.30.3200 bus-info: 0000:04:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no supports-priv-flags: yes ethtool -g p2p1 Ring parameters for p2p1: Pre-set maximums: RX: 8192 RX Mini: 0 RX Jumbo: 0 TX: 8192 Current hardware settings: RX: 1024 RX Mini: 0 RX Jumbo: 0 TX: 512 Coalesce parameters for p2p1: Adaptive RX: on TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 400000 pkt-rate-high: 450000 rx-usecs: 16 rx-frames: 44 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 16 tx-frames: 16 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 128 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0 $ sudo ethtool -k p2p1 Features for p2p1: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: on udp-fragmentation-offload: off [fixed] generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off [fixed] receive-hashing: on highdma: on [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: off [fixed] tx-gre-segmentation: off [fixed] tx-ipip-segmentation: off [fixed] tx-sit-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-mpls-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: on loopback: off rx-fcs: off [fixed] rx-all: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off [fixed] > On May 20, 2015, at 9:18 AM, Luigi Rizzo wrote: >=20 > hi all, >=20 > 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. >=20 > At the time i had the following performance (on PCIe v2 bus): >=20 > 10G ports: tx/rx at about 7 Mpps with 64 byte packets > could saturate the link with 192 or 256 byte packets >=20 > 40G ports: tx/rx at about 11 Mpps with 64 byte packets > max 28 Gbit/s even with 1500 byte frames >=20 > 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. >=20 > 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. >=20 > 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. >=20 > It would be of course great to add Mellanox to the list of > devices with native netmap support, together with Chelsio > and Intel. >=20 > 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. >=20 > cheers > luigi >=20 > On Wed, May 20, 2015 at 4:50 PM, Hans Petter Selasky > wrote: > On 05/20/15 16:13, Blake Caldwell wrote: > Hello, >=20 > I noticed that the mlx4_en patch for netmap is LINUX/wip-patches, so = they are not enabled in the normal build process. I=92m curious about = the status of mlx4 support? >=20 > If additional work to the patches is needed, any details as to what = the issues were. >=20 > Any info would be great! Thanks in advance! >=20 >=20 > Hi Blake, >=20 > 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? >=20 > This there any particular use-case you are interested in? >=20 > --HPS >=20 >=20 > _______________________________________________ > 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 >=20 >=20 > --=20 > = -----------------------------------------+------------------------------- > 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 Thu May 28 09:54:28 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 25586911 for ; Thu, 28 May 2015 09:54:28 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 A3C58603 for ; Thu, 28 May 2015 09:54:27 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: by wizk4 with SMTP id k4so140495566wiz.1 for ; Thu, 28 May 2015 02:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qSvU56oGbotqz0spiP3D0qbzTY2kmtQCAeLJvgICXKg=; b=FFEYu/STOL4uf6LX0WnMPZlX2BEZau9zaPVOCRY8sTtNnzXyMwWfp1vEI75m+yeDTk +eyLwjpM+1jysyu4lAO1zdi8a6SmNJbY75xdKgqkQkOUmz7Mi5UmB0aPrVBCB+XTBLiT YKN7IETwnQmlg7tAcRWPGAM30VHERsgjpEVM+4aF+Up0RKJpYK/1ZgV+vP8u2UDGuxJz Snr3O3Ar1dE5XMqVSagFHRlAO3RvM0PNTh0YNRMka62TSwJL1xGZEteruOgg7umy3swY 4XrEJUAQfd8XhVNRNiJazo5z6x4CdMuK/KUrQxQx8/pBUUQN6tlSAktN3NsZKp5Q2B7j mbHg== X-Received: by 10.180.84.8 with SMTP id u8mr60043167wiy.39.1432806865982; Thu, 28 May 2015 02:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.9.76 with HTTP; Thu, 28 May 2015 02:54:05 -0700 (PDT) In-Reply-To: References: From: Stefano Garzarella Date: Thu, 28 May 2015 11:54:05 +0200 Message-ID: Subject: Re: Netmap problem with e1000e driver To: Oleg Prozorov Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri 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, 28 May 2015 09:54:28 -0000 Hi Oleg, I'm working on netmap with Luigi and Giuseppe (in cc). I tried to do the same steps, but I can not produce the crash. Can you you send us your kernel and netmap version? When you put down and up the interface, are you in tx or rx? Cheers, Stefano 2015-05-27 17:26 GMT+02:00 Oleg Prozorov : > Hello All, > I am using Netmap technology in my program and have the problem : > when I put eth link down and then have it up netmap goes down with kernel > messages: > > log from dmesg: > > [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" option) > [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O > 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 > [ 2457.286298] Hardware name: System manufacturer System Product > Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 > [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 > ffffffff810bd10d > [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 > ffffffff810bd631 > [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c > 0000000000000000 > [ 2457.286310] Call Trace: > [ 2457.286312] [] ? dump_stack+0x41/0x51 > [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 > [ 2457.286328] [] ? note_interrupt+0x241/0x290 > [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x190 > [ 2457.286336] [] ? handle_irq_event+0x38/0x60 > [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 > [ 2457.286347] [] ? handle_irq+0x1d/0x30 > [ 2457.286350] [] ? do_IRQ+0x49/0xe0 > [ 2457.286355] [] ? common_interrupt+0x6d/0x6d > [ 2457.286356] [] ? > __hrtimer_start_range_ns+0x1cd/0x390 > [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 > [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 > [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 > [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 > [ 2457.286377] handlers: > [ 2457.286384] [] e1000_msix_other [e1000e] > [ 2457.286386] Disabling IRQ #44 > > before i have the next steps: > > insmod ./netmap.ko > insmod ./e1000e/e1000e.ko > > log from dmesg: > > [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k > [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. > [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X > [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X > [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X > [ 1645.704831] 635.291734 [2720] netmap_attach success for eth0 > tx 1/256 rx 1/256 queues/slots > [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock > [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > 68:05:ca:28:36:f5 > [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network > Connection > [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 > [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) > set to dynamic conservative mode > [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X > [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X > [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X > [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to eth5 > [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready > [ 1645.848756] 635.435799 [2720] netmap_attach success for eth0 > tx 1/256 rx 1/256 queues/slots > [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock > [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) > 68:05:ca:22:19:e7 > [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network > Connection > [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008 > [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to eth6 > [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready > [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready > [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready > [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow > Control: Rx/Tx > > > My program used netmap desc: > root@debian:/home/debian/Projects/bin# lsmod | grep netmap > netmap 99228 5 e1000e > > > Then even if it shows that link is up net map stops to work and only > rmmod/insmod and restart of the netmap can bring it back to work. > > Could you please help me with it ? > > Thx a lot, > Oleg. > _______________________________________________ > 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" > -- *Stefano Garzarella* Software Engineer e-mail: stefano.garzarella@gmail.com github: http://github.com/stefano-garzarella linkedin: http://it.linkedin.com/pub/stefano-garzarella From owner-freebsd-net@FreeBSD.ORG Thu May 28 11:36: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 211AFC86 for ; Thu, 28 May 2015 11:36:53 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD237E1 for ; Thu, 28 May 2015 11:36:52 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4SBakrf006681; Thu, 28 May 2015 13:36:46 +0200 (CEST) Received: from [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e] (p200300556B2BD00030D9F27982B0BE8E.dip0.t-ipconnect.de [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3ly6SG2bNNz8xQs; Thu, 28 May 2015 13:36:46 +0200 (CEST) Message-ID: <5566FDCD.9000908@tzi.de> Date: Thu, 28 May 2015 13:36:45 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <20150528013135.GR95600@strugglingcoder.info> <55668B7F.9010509@freebsd.org> In-Reply-To: <55668B7F.9010509@freebsd.org> Content-Type: text/plain; charset=windows-1252; 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: Thu, 28 May 2015 11:36:53 -0000 Am 28.05.2015 um 05:29 schrieb Julian Elischer: > Julian, I am guessing (with no actual information) that something in gre > processing is > assuming that the packet id going where it normally would go. (and not > where fwd is sending it). > > you really need to use objdump or gdb to look at the gre module and > work out where > > gre_output+0x467 > > is in the function. that should give you a clue on the problem. > > not too helpful I know... but you have a reproducible case at least. > kgdb may be your friend if you > have a serial cable or firewire cable. It is a multihomed machine behind two DSL routers. All packets leave the interface with the default route unless I use IPFW with fwd. Is there another way to force packets to leave the correct interface? The problem does also appear if I shutdown the second WAN interface. This is the way the traffic goes: re0 (internal network) -> fwd to gre1 -> fwd to gateway of re1 -> re1 If the traffic source is the machine an not the internal network it seems to cause no problems. I guess the problem is to use fwd twice. I will do additional tests and I will try to debug this using a serial connection next week. kind regards, Julian From owner-freebsd-net@FreeBSD.ORG Thu May 28 12:39:48 2015 Return-Path: Delivered-To: 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 A3EED32D for ; Thu, 28 May 2015 12:39:48 +0000 (UTC) (envelope-from oleg.prozorov@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c: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 081D6314 for ; Thu, 28 May 2015 12:39:48 +0000 (UTC) (envelope-from oleg.prozorov@gmail.com) Received: by wicmx19 with SMTP id mx19so122232849wic.0 for ; Thu, 28 May 2015 05:39:46 -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=d+KMh38F7qTpRI9cu6+LI6mlFEBl0NqpGsN30U98jeQ=; b=KF/Bh1yKy5+kVx0JzKSOZQAyes9xB1kW2Z9kd2c4ijgChBK96/JPmSJj5bhSTct0UH oAlqXxqgCGZGwNHEtnj8/DvG7hA/vqnXeuUCw4NOoemggcfAbf/jIPqk1OEGW/KlKn7k l8AvCoqpwewrlcNz4+wNQ+Yhs/x6MRWJ2cx9vZwXRqBNkEE2TilPnzp2KSme+bLsRt/x eku7bbKxblxhKVPSXATsBoSsEd1KM3ijzKg6cTQmyhnWRRaYOQBI0R6hOCMEM5/Imyzl Q8+A4R2tZijANuJRmCzAMB4ZC7VZ8yJga3eM6Xtza4PwAqnQ0PGEmfbetZVTIx5r/IuW PyIg== MIME-Version: 1.0 X-Received: by 10.180.100.74 with SMTP id ew10mr62264130wib.12.1432816786506; Thu, 28 May 2015 05:39:46 -0700 (PDT) Received: by 10.194.76.243 with HTTP; Thu, 28 May 2015 05:39:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 May 2015 15:39:46 +0300 Message-ID: Subject: Re: Netmap problem with e1000e driver From: Oleg Prozorov To: Stefano Garzarella Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri 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, 28 May 2015 12:39:48 -0000 Hello Stefano, I am working on Debian 8 jessy: kernel version: 3.16.0-4-amd64 i used netmap from link : https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca760791= 3fc.tar.gz I did the next steps: 1) untar netmap achive 2) dowonload linux source 3) in netmap-32e06f9d18bf/LINUX directory 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ --drivers=3De1000e 3.2) make clean all 4) rmmod e1000e 5) insmod ./netmap.ko 6) insmod ./e1000e/e1000e.ko Ethernet adapter: 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection Subsystem: Intel Corporation Gigabit CT Desktop Adapter Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f7dc0000 (32-bit, non-prefetchable) [size=3D128K] Memory at f7d00000 (32-bit, non-prefetchable) [size=3D512K] I/O ports at e000 [size=3D32] Memory at f7de0000 (32-bit, non-prefetchable) [size=3D16K] Expansion ROM at f7d80000 [disabled] [size=3D256K] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-28-36-f5 Kernel driver in use: e1000e 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection Subsystem: Intel Corporation Gigabit CT Desktop Adapter Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at f7cc0000 (32-bit, non-prefetchable) [size=3D128K] Memory at f7c00000 (32-bit, non-prefetchable) [size=3D512K] I/O ports at d000 [size=3D32] Memory at f7ce0000 (32-bit, non-prefetchable) [size=3D16K] Expansion ROM at f7c80000 [disabled] [size=3D256K] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-22-19-e7 Kernel driver in use: e1000e My application work as netmap bridge. rx -tx in one thread 02:00.0 -> 03:00.0 rx-tx in one thread 03:00.0 -> 02:00.0 I have attached my Netmap engine NetmapStream.cpp. On Intel I350 T2 having Network adapter link bringing down/up ethernet adapter has recovered successfully approx in 3-5 sec without driver crash. Thx, Oleg. 2015-05-28 12:54 GMT+03:00 Stefano Garzarella = : > Hi Oleg, > I'm working on netmap with Luigi and Giuseppe (in cc). > > I tried to do the same steps, but I can not produce the crash. > > Can you you send us your kernel and netmap version? > When you put down and up the interface, are you in tx or rx? > > Cheers, > Stefano > > 2015-05-27 17:26 GMT+02:00 Oleg Prozorov : > >> Hello All, >> I am using Netmap technology in my program and have the problem : >> when I put eth link down and then have it up netmap goes down with kerne= l >> messages: >> >> log from dmesg: >> >> [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" >> option) >> [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O >> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 >> [ 2457.286298] Hardware name: System manufacturer System Product >> Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 >> [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 >> ffffffff810bd10d >> [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 >> ffffffff810bd631 >> [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c >> 0000000000000000 >> [ 2457.286310] Call Trace: >> [ 2457.286312] [] ? dump_stack+0x41/0x51 >> [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 >> [ 2457.286328] [] ? note_interrupt+0x241/0x290 >> [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x19= 0 >> [ 2457.286336] [] ? handle_irq_event+0x38/0x60 >> [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 >> [ 2457.286347] [] ? handle_irq+0x1d/0x30 >> [ 2457.286350] [] ? do_IRQ+0x49/0xe0 >> [ 2457.286355] [] ? common_interrupt+0x6d/0x6d >> [ 2457.286356] [] ? >> __hrtimer_start_range_ns+0x1cd/0x390 >> [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 >> [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 >> [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 >> [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 >> [ 2457.286377] handlers: >> [ 2457.286384] [] e1000_msix_other [e1000e] >> [ 2457.286386] Disabling IRQ #44 >> >> before i have the next steps: >> >> insmod ./netmap.ko >> insmod ./e1000e/e1000e.ko >> >> log from dmesg: >> >> [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k >> [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. >> [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec) >> set to dynamic conservative mode >> [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X >> [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X >> [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X >> [ 1645.704831] 635.291734 [2720] netmap_attach success for >> eth0 >> tx 1/256 rx 1/256 queues/slots >> [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock >> [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) >> 68:05:ca:28:36:f5 >> [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network >> Connection >> [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: >> E46981-008 >> [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) >> set to dynamic conservative mode >> [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X >> [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X >> [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X >> [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to et= h5 >> [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready >> [ 1645.848756] 635.435799 [2720] netmap_attach success for >> eth0 >> tx 1/256 rx 1/256 queues/slots >> [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock >> [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) >> 68:05:ca:22:19:e7 >> [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network >> Connection >> [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: >> E46981-008 >> [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to et= h6 >> [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready >> [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow >> Control: Rx/Tx >> [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready >> [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow >> Control: Rx/Tx >> [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready >> [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow >> Control: Rx/Tx >> [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow >> Control: Rx/Tx >> >> >> My program used netmap desc: >> root@debian:/home/debian/Projects/bin# lsmod | grep netmap >> netmap 99228 5 e1000e >> >> >> Then even if it shows that link is up net map stops to work and only >> rmmod/insmod and restart of the netmap can bring it back to work. >> >> Could you please help me with it ? >> >> Thx a lot, >> Oleg. >> _______________________________________________ >> 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" >> > > > > -- > *Stefano Garzarella* > Software Engineer > > e-mail: stefano.garzarella@gmail.com > github: http://github.com/stefano-garzarella > linkedin: http://it.linkedin.com/pub/stefano-garzarella > --=20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=9E=D0=BB=D0=B5=D0=B3 =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0=B2. From owner-freebsd-net@FreeBSD.ORG Thu May 28 13:26:56 2015 Return-Path: Delivered-To: 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 B61AAB2D for ; Thu, 28 May 2015 13:26:56 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 320C8E7 for ; Thu, 28 May 2015 13:26:56 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: by wizk4 with SMTP id k4so146876927wiz.1 for ; Thu, 28 May 2015 06:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KSNeV3cZhKNHSeJk2QF/Rd73vot4rr6bau8+OiXgFMw=; b=vW/ICX4X5C+7L3yac+cDmy47yQw2y0Hze04ZmHVjXHGlag3T6cd3CGyazmxDmmhuoo S74rJ8TvO2twgeLjrWyCftDA9OxeifiTFCUKIKJ4UiN+CsFWgbjLazh/F/j7VQJFUmW5 OHRDTjFAv9XnE+vBZClZBhh7+ZmS19NCHDAQQ//9mUCQz0b8+/wD2Vr6KPsVlw1u/GtW PRV0h6/dMI2p1WVoCFa+ry2jnStcF/DMNTHCnpHdDuVM/aF1TyQLFjKaS5JyaatXkasI Q3RYR6rw5XUflpNMc2eziYAQ1vsh7Ls/ZzfSUzzOVb0p3If0mOiokZJfx4+RAfLnk+1D 1Sjg== X-Received: by 10.180.14.135 with SMTP id p7mr16192910wic.8.1432819613735; Thu, 28 May 2015 06:26:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.9.76 with HTTP; Thu, 28 May 2015 06:26:32 -0700 (PDT) In-Reply-To: References: From: Stefano Garzarella Date: Thu, 28 May 2015 15:26:32 +0200 Message-ID: Subject: Re: Netmap problem with e1000e driver To: Oleg Prozorov Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri Content-Type: multipart/mixed; boundary=f46d040fa1d01b4c210517245007 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, 28 May 2015 13:26:56 -0000 --f46d040fa1d01b4c210517245007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Oleg, can you try to apply this patch in this way: 1) untar netmap achive 2) dowonload linux source 3) in netmap-32e06f9d18bf/LINUX directory 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ --drivers=3De1000e 3.2) make clean all 3.3) patch -p2 < path/to/e1000e_fix.patch 3.4) make 4) rmmod e1000e 5) insmod ./netmap.ko 6) insmod ./e1000e/e1000e.ko You must do make in LINUX dir before apply the patch and after that, you need to do again make (without clean). Tell me if it works. Thanks, Stefano --- netmap/LINUX/e1000e/netdev.c 2015-05-28 15:31:31.136816911 +0200 +++ netmap/LINUX/e1000e/netdev-new.c 2015-05-28 15:33:38.503484647 +0200 @@ -4028,6 +4028,10 @@ int e1000e_up(struct e1000_adapter *adap netif_start_queue(adapter->netdev); +#ifdef DEV_NETMAP + netmap_enable_all_rings(adapter->netdev); +#endif /* DEV_NETMAP */ + /* fire a link change interrupt to start the watchdog */ if (adapter->msix_entries) ew32(ICS, E1000_ICS_LSC | E1000_ICR_OTHER); 2015-05-28 14:39 GMT+02:00 Oleg Prozorov : > > Hello Stefano, > I am working on Debian 8 jessy: > > kernel version: 3.16.0-4-amd64 > > i used netmap from link : > https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca7607= 913fc.tar.gz > > > I did the next steps: > 1) untar netmap achive > 2) dowonload linux source > 3) in netmap-32e06f9d18bf/LINUX directory > 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ > --drivers=3De1000e > 3.2) make clean all > 4) rmmod e1000e > 5) insmod ./netmap.ko > 6) insmod ./e1000e/e1000e.ko > > > Ethernet adapter: > 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > Subsystem: Intel Corporation Gigabit CT Desktop Adapter > Flags: bus master, fast devsel, latency 0, IRQ 16 > Memory at f7dc0000 (32-bit, non-prefetchable) [size=3D128K] > Memory at f7d00000 (32-bit, non-prefetchable) [size=3D512K] > I/O ports at e000 [size=3D32] > Memory at f7de0000 (32-bit, non-prefetchable) [size=3D16K] > Expansion ROM at f7d80000 [disabled] [size=3D256K] > Capabilities: [c8] Power Management version 2 > Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ > Capabilities: [e0] Express Endpoint, MSI 00 > Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-28-36-f5 > Kernel driver in use: e1000e > > 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > Subsystem: Intel Corporation Gigabit CT Desktop Adapter > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at f7cc0000 (32-bit, non-prefetchable) [size=3D128K] > Memory at f7c00000 (32-bit, non-prefetchable) [size=3D512K] > I/O ports at d000 [size=3D32] > Memory at f7ce0000 (32-bit, non-prefetchable) [size=3D16K] > Expansion ROM at f7c80000 [disabled] [size=3D256K] > Capabilities: [c8] Power Management version 2 > Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ > Capabilities: [e0] Express Endpoint, MSI 00 > Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-22-19-e7 > Kernel driver in use: e1000e > > > My application work as netmap bridge. > > rx -tx in one thread > 02:00.0 -> 03:00.0 > > rx-tx in one thread > 03:00.0 -> 02:00.0 > > I have attached my Netmap engine NetmapStream.cpp. > > On Intel I350 T2 having Network adapter link bringing down/up ethernet > adapter has recovered successfully approx in 3-5 sec without driver crash= . > > > Thx, > Oleg. > > > 2015-05-28 12:54 GMT+03:00 Stefano Garzarella >: > >> Hi Oleg, >> I'm working on netmap with Luigi and Giuseppe (in cc). >> >> I tried to do the same steps, but I can not produce the crash. >> >> Can you you send us your kernel and netmap version? >> When you put down and up the interface, are you in tx or rx? >> >> Cheers, >> Stefano >> >> 2015-05-27 17:26 GMT+02:00 Oleg Prozorov : >> >>> Hello All, >>> I am using Netmap technology in my program and have the problem : >>> when I put eth link down and then have it up netmap goes down with kern= el >>> messages: >>> >>> log from dmesg: >>> >>> [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" >>> option) >>> [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O >>> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 >>> [ 2457.286298] Hardware name: System manufacturer System Product >>> Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 >>> [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 >>> ffffffff810bd10d >>> [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 >>> ffffffff810bd631 >>> [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c >>> 0000000000000000 >>> [ 2457.286310] Call Trace: >>> [ 2457.286312] [] ? dump_stack+0x41/0x51 >>> [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 >>> [ 2457.286328] [] ? note_interrupt+0x241/0x290 >>> [ 2457.286332] [] ? handle_irq_event_percpu+0xa1/0x1= 90 >>> [ 2457.286336] [] ? handle_irq_event+0x38/0x60 >>> [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 >>> [ 2457.286347] [] ? handle_irq+0x1d/0x30 >>> [ 2457.286350] [] ? do_IRQ+0x49/0xe0 >>> [ 2457.286355] [] ? common_interrupt+0x6d/0x6d >>> [ 2457.286356] [] ? >>> __hrtimer_start_range_ns+0x1cd/0x390 >>> [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 >>> [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 >>> [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 >>> [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 >>> [ 2457.286377] handlers: >>> [ 2457.286384] [] e1000_msix_other [e1000e] >>> [ 2457.286386] Disabling IRQ #44 >>> >>> before i have the next steps: >>> >>> insmod ./netmap.ko >>> insmod ./e1000e/e1000e.ko >>> >>> log from dmesg: >>> >>> [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k >>> [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. >>> [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate (ints/sec= ) >>> set to dynamic conservative mode >>> [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X >>> [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X >>> [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X >>> [ 1645.704831] 635.291734 [2720] netmap_attach success for >>> eth0 >>> tx 1/256 rx 1/256 queues/slots >>> [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock >>> [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1) >>> 68:05:ca:28:36:f5 >>> [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network >>> Connection >>> [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: >>> E46981-008 >>> [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec= ) >>> set to dynamic conservative mode >>> [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X >>> [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X >>> [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X >>> [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to >>> eth5 >>> [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready >>> [ 1645.848756] 635.435799 [2720] netmap_attach success for >>> eth0 >>> tx 1/256 rx 1/256 queues/slots >>> [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock >>> [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1) >>> 68:05:ca:22:19:e7 >>> [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network >>> Connection >>> [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: >>> E46981-008 >>> [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to >>> eth6 >>> [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready >>> [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow >>> Control: Rx/Tx >>> [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready >>> [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow >>> Control: Rx/Tx >>> [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready >>> [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow >>> Control: Rx/Tx >>> [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow >>> Control: Rx/Tx >>> >>> >>> My program used netmap desc: >>> root@debian:/home/debian/Projects/bin# lsmod | grep netmap >>> netmap 99228 5 e1000e >>> >>> >>> Then even if it shows that link is up net map stops to work and only >>> rmmod/insmod and restart of the netmap can bring it back to work. >>> >>> Could you please help me with it ? >>> >>> Thx a lot, >>> Oleg. >>> _______________________________________________ >>> 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" >>> >> >> >> >> -- >> *Stefano Garzarella* >> Software Engineer >> >> e-mail: stefano.garzarella@gmail.com >> github: http://github.com/stefano-garzarella >> linkedin: http://it.linkedin.com/pub/stefano-garzarella >> > > > > -- > =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, > =D0=9E=D0=BB=D0=B5=D0=B3 =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0=B2= . > --=20 *Stefano Garzarella* Software Engineer e-mail: stefano.garzarella@gmail.com github: http://github.com/stefano-garzarella linkedin: http://it.linkedin.com/pub/stefano-garzarella --f46d040fa1d01b4c210517245007 Content-Type: application/octet-stream; name="e1000e_fix.patch" Content-Disposition: attachment; filename="e1000e_fix.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ia87qjj61 LS0tIG5ldG1hcC9MSU5VWC9lMTAwMGUvbmV0ZGV2LmMJMjAxNS0wNS0yOCAxNTozMTozMS4xMzY4 MTY5MTEgKzAyMDAKKysrIG5ldG1hcC9MSU5VWC9lMTAwMGUvbmV0ZGV2LW5ldy5jCTIwMTUtMDUt MjggMTU6MzM6MzguNTAzNDg0NjQ3ICswMjAwCkBAIC00MDI4LDYgKzQwMjgsMTAgQEAgaW50IGUx MDAwZV91cChzdHJ1Y3QgZTEwMDBfYWRhcHRlciAqYWRhcAogCiAJbmV0aWZfc3RhcnRfcXVldWUo YWRhcHRlci0+bmV0ZGV2KTsKIAorI2lmZGVmIERFVl9ORVRNQVAKKwluZXRtYXBfZW5hYmxlX2Fs bF9yaW5ncyhhZGFwdGVyLT5uZXRkZXYpOworI2VuZGlmIC8qIERFVl9ORVRNQVAgKi8KKwogCS8q IGZpcmUgYSBsaW5rIGNoYW5nZSBpbnRlcnJ1cHQgdG8gc3RhcnQgdGhlIHdhdGNoZG9nICovCiAJ aWYgKGFkYXB0ZXItPm1zaXhfZW50cmllcykKIAkJZXczMihJQ1MsIEUxMDAwX0lDU19MU0MgfCBF MTAwMF9JQ1JfT1RIRVIpOwo= --f46d040fa1d01b4c210517245007-- From owner-freebsd-net@FreeBSD.ORG Thu May 28 13:43:40 2015 Return-Path: Delivered-To: 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 C3856F6D for ; Thu, 28 May 2015 13:43:40 +0000 (UTC) (envelope-from oleg.prozorov@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 4BC037D5 for ; Thu, 28 May 2015 13:43:40 +0000 (UTC) (envelope-from oleg.prozorov@gmail.com) Received: by wizk4 with SMTP id k4so147457270wiz.1 for ; Thu, 28 May 2015 06:43:38 -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=L2MGa0BnVKen6IKQ3MZkeAXGcjzArgPPhQyoKNgI/yg=; b=Wp9CBMqzMXIX3OkqzxVWaf+9s5YF+r/PO48tvcrSd9hF3bSHBOOKzGxwK9h6tbNdTo UvZYb8i8F8fcHh3W1EhdKiTKnkZfEOy1qy7WxDJm5uAYvPu+1CM2h3KsHqvzRq8DJ38z 8C4JtdNFArVaInyTXlcasqr5xViaa6aDuFgyH6441BoCze1hStM36Y1hk+AmYSE/2cUq xcRPiWP7cLWbhc2RLO5IdAmUtFjPSX05cXMv4uK1LRiRUaN7c9PSHY0m8nHae7tHWEgX +5cDccYtZJWIqqU8GlNY1XdRmSWCZ32KmdRgepry2LoiGjwhZG1f9/Pa3m7CvXHGJW9L 8brg== MIME-Version: 1.0 X-Received: by 10.180.231.4 with SMTP id tc4mr16484058wic.27.1432820618572; Thu, 28 May 2015 06:43:38 -0700 (PDT) Received: by 10.194.76.243 with HTTP; Thu, 28 May 2015 06:43:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 May 2015 16:43:38 +0300 Message-ID: Subject: Re: Netmap problem with e1000e driver From: Oleg Prozorov To: Stefano Garzarella Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri 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, 28 May 2015 13:43:41 -0000 Hello Stefano, You make my day :) It works. Greate job. Ths a lot, Oleg. 2015-05-28 16:26 GMT+03:00 Stefano Garzarella = : > Hi Oleg, > can you try to apply this patch in this way: > > 1) untar netmap achive > 2) dowonload linux source > 3) in netmap-32e06f9d18bf/LINUX directory > 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ > --drivers=3De1000e > 3.2) make clean all > > 3.3) patch -p2 < path/to/e1000e_fix.patch > 3.4) make > > 4) rmmod e1000e > 5) insmod ./netmap.ko > 6) insmod ./e1000e/e1000e.ko > > You must do make in LINUX dir before apply the patch and after that, you > need to do again make (without clean). > > Tell me if it works. > > Thanks, > Stefano > > > > --- netmap/LINUX/e1000e/netdev.c 2015-05-28 15:31:31.136816911 +0200 > +++ netmap/LINUX/e1000e/netdev-new.c 2015-05-28 15:33:38.503484647 +0200 > @@ -4028,6 +4028,10 @@ int e1000e_up(struct e1000_adapter *adap > > netif_start_queue(adapter->netdev); > > +#ifdef DEV_NETMAP > + netmap_enable_all_rings(adapter->netdev); > +#endif /* DEV_NETMAP */ > + > /* fire a link change interrupt to start the watchdog */ > if (adapter->msix_entries) > ew32(ICS, E1000_ICS_LSC | E1000_ICR_OTHER); > > 2015-05-28 14:39 GMT+02:00 Oleg Prozorov : > >> >> Hello Stefano, >> I am working on Debian 8 jessy: >> >> kernel version: 3.16.0-4-amd64 >> >> i used netmap from link : >> https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca760= 7913fc.tar.gz >> >> >> I did the next steps: >> 1) untar netmap achive >> 2) dowonload linux source >> 3) in netmap-32e06f9d18bf/LINUX directory >> 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ >> --drivers=3De1000e >> 3.2) make clean all >> 4) rmmod e1000e >> 5) insmod ./netmap.ko >> 6) insmod ./e1000e/e1000e.ko >> >> >> Ethernet adapter: >> 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >> Connection >> Subsystem: Intel Corporation Gigabit CT Desktop Adapter >> Flags: bus master, fast devsel, latency 0, IRQ 16 >> Memory at f7dc0000 (32-bit, non-prefetchable) [size=3D128K] >> Memory at f7d00000 (32-bit, non-prefetchable) [size=3D512K] >> I/O ports at e000 [size=3D32] >> Memory at f7de0000 (32-bit, non-prefetchable) [size=3D16K] >> Expansion ROM at f7d80000 [disabled] [size=3D256K] >> Capabilities: [c8] Power Management version 2 >> Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ >> Capabilities: [e0] Express Endpoint, MSI 00 >> Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- >> Capabilities: [100] Advanced Error Reporting >> Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-28-36-f5 >> Kernel driver in use: e1000e >> >> 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >> Connection >> Subsystem: Intel Corporation Gigabit CT Desktop Adapter >> Flags: bus master, fast devsel, latency 0, IRQ 17 >> Memory at f7cc0000 (32-bit, non-prefetchable) [size=3D128K] >> Memory at f7c00000 (32-bit, non-prefetchable) [size=3D512K] >> I/O ports at d000 [size=3D32] >> Memory at f7ce0000 (32-bit, non-prefetchable) [size=3D16K] >> Expansion ROM at f7c80000 [disabled] [size=3D256K] >> Capabilities: [c8] Power Management version 2 >> Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ >> Capabilities: [e0] Express Endpoint, MSI 00 >> Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- >> Capabilities: [100] Advanced Error Reporting >> Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-22-19-e7 >> Kernel driver in use: e1000e >> >> >> My application work as netmap bridge. >> >> rx -tx in one thread >> 02:00.0 -> 03:00.0 >> >> rx-tx in one thread >> 03:00.0 -> 02:00.0 >> >> I have attached my Netmap engine NetmapStream.cpp. >> >> On Intel I350 T2 having Network adapter link bringing down/up ethernet >> adapter has recovered successfully approx in 3-5 sec without driver cras= h. >> >> >> Thx, >> Oleg. >> >> >> 2015-05-28 12:54 GMT+03:00 Stefano Garzarella < >> stefanogarzarella@gmail.com>: >> >>> Hi Oleg, >>> I'm working on netmap with Luigi and Giuseppe (in cc). >>> >>> I tried to do the same steps, but I can not produce the crash. >>> >>> Can you you send us your kernel and netmap version? >>> When you put down and up the interface, are you in tx or rx? >>> >>> Cheers, >>> Stefano >>> >>> 2015-05-27 17:26 GMT+02:00 Oleg Prozorov : >>> >>>> Hello All, >>>> I am using Netmap technology in my program and have the problem : >>>> when I put eth link down and then have it up netmap goes down with >>>> kernel >>>> messages: >>>> >>>> log from dmesg: >>>> >>>> [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" >>>> option) >>>> [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O >>>> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 >>>> [ 2457.286298] Hardware name: System manufacturer System Product >>>> Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 >>>> [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 >>>> ffffffff810bd10d >>>> [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 >>>> ffffffff810bd631 >>>> [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c >>>> 0000000000000000 >>>> [ 2457.286310] Call Trace: >>>> [ 2457.286312] [] ? dump_stack+0x41/0x51 >>>> [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 >>>> [ 2457.286328] [] ? note_interrupt+0x241/0x290 >>>> [ 2457.286332] [] ? >>>> handle_irq_event_percpu+0xa1/0x190 >>>> [ 2457.286336] [] ? handle_irq_event+0x38/0x60 >>>> [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 >>>> [ 2457.286347] [] ? handle_irq+0x1d/0x30 >>>> [ 2457.286350] [] ? do_IRQ+0x49/0xe0 >>>> [ 2457.286355] [] ? common_interrupt+0x6d/0x6d >>>> [ 2457.286356] [] ? >>>> __hrtimer_start_range_ns+0x1cd/0x390 >>>> [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 >>>> [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 >>>> [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 >>>> [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 >>>> [ 2457.286377] handlers: >>>> [ 2457.286384] [] e1000_msix_other [e1000e] >>>> [ 2457.286386] Disabling IRQ #44 >>>> >>>> before i have the next steps: >>>> >>>> insmod ./netmap.ko >>>> insmod ./e1000e/e1000e.ko >>>> >>>> log from dmesg: >>>> >>>> [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k >>>> [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. >>>> [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate >>>> (ints/sec) >>>> set to dynamic conservative mode >>>> [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X >>>> [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X >>>> [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X >>>> [ 1645.704831] 635.291734 [2720] netmap_attach success for >>>> eth0 >>>> tx 1/256 rx 1/256 queues/slots >>>> [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock >>>> [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width x1= ) >>>> 68:05:ca:28:36:f5 >>>> [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network >>>> Connection >>>> [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: >>>> E46981-008 >>>> [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate >>>> (ints/sec) >>>> set to dynamic conservative mode >>>> [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X >>>> [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X >>>> [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X >>>> [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to >>>> eth5 >>>> [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready >>>> [ 1645.848756] 635.435799 [2720] netmap_attach success for >>>> eth0 >>>> tx 1/256 rx 1/256 queues/slots >>>> [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock >>>> [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1= ) >>>> 68:05:ca:22:19:e7 >>>> [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network >>>> Connection >>>> [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: >>>> E46981-008 >>>> [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to >>>> eth6 >>>> [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready >>>> [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow >>>> Control: Rx/Tx >>>> [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready >>>> [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow >>>> Control: Rx/Tx >>>> [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready >>>> [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flow >>>> Control: Rx/Tx >>>> [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow >>>> Control: Rx/Tx >>>> >>>> >>>> My program used netmap desc: >>>> root@debian:/home/debian/Projects/bin# lsmod | grep netmap >>>> netmap 99228 5 e1000e >>>> >>>> >>>> Then even if it shows that link is up net map stops to work and only >>>> rmmod/insmod and restart of the netmap can bring it back to work. >>>> >>>> Could you please help me with it ? >>>> >>>> Thx a lot, >>>> Oleg. >>>> _______________________________________________ >>>> 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" >>>> >>> >>> >>> >>> -- >>> *Stefano Garzarella* >>> Software Engineer >>> >>> e-mail: stefano.garzarella@gmail.com >>> github: http://github.com/stefano-garzarella >>> linkedin: http://it.linkedin.com/pub/stefano-garzarella >>> >> >> >> >> -- >> =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, >> =D0=9E=D0=BB=D0=B5=D0=B3 =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0= =B2. >> > > > > -- > *Stefano Garzarella* > Software Engineer > > e-mail: stefano.garzarella@gmail.com > github: http://github.com/stefano-garzarella > linkedin: http://it.linkedin.com/pub/stefano-garzarella > --=20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=9E=D0=BB=D0=B5=D0=B3 =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0=B2. From owner-freebsd-net@FreeBSD.ORG Thu May 28 13:50:22 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 3820A1DA for ; Thu, 28 May 2015 13:50:22 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 B14FC852 for ; Thu, 28 May 2015 13:50:21 +0000 (UTC) (envelope-from stefanogarzarella@gmail.com) Received: by wicmc15 with SMTP id mc15so124454148wic.1 for ; Thu, 28 May 2015 06:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jeTfpzOQiQVsQnUqs1YlJf1pzixAFVNB3b/zeF9Yn5o=; b=iqJrkmO3jm7BEMrWaEkj9+teQ4z9ZZo/mgvS0zzn0a6wcTjXf5HTD5x+zSQ7/JNvf+ 9yO/6PzRRnwNaSUDn8eYodjgK9br9kyF+/6fgubLrg9GH2JeEGWw1ilSw4oUAGSt8+SX mlY2lSRr8zZvEwsukRkOpxf0ImDazYH0fnt20l8A4zcDX9oU1+PCPods20XYDvRalRjg vG0TXlrk8ya/Bjj8wWkRhoSYaBoUayNjyojS1IdQR3f2fFzW/kLLdFi7fUKV8k0GGIqV /ekBCyUB/WqFGQd9Xc3sQYcTlOGz8RmnvxwmuiUygl6lFqqwJILcquGz2/dy2D5QRzkN SphQ== X-Received: by 10.194.7.97 with SMTP id i1mr5586504wja.107.1432821020182; Thu, 28 May 2015 06:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.9.76 with HTTP; Thu, 28 May 2015 06:49:59 -0700 (PDT) In-Reply-To: References: From: Stefano Garzarella Date: Thu, 28 May 2015 15:49:59 +0200 Message-ID: Subject: Re: Netmap problem with e1000e driver To: Oleg Prozorov Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , Giuseppe Lettieri 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, 28 May 2015 13:50:22 -0000 Thanks for your report! :) Cheers, Stefano 2015-05-28 15:43 GMT+02:00 Oleg Prozorov : > Hello Stefano, > > You make my day :) It works. Greate job. > > Ths a lot, > Oleg. > > 2015-05-28 16:26 GMT+03:00 Stefano Garzarella >: > >> Hi Oleg, >> can you try to apply this patch in this way: >> >> 1) untar netmap achive >> 2) dowonload linux source >> 3) in netmap-32e06f9d18bf/LINUX directory >> 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ >> --drivers=3De1000e >> 3.2) make clean all >> >> 3.3) patch -p2 < path/to/e1000e_fix.patch >> 3.4) make >> >> 4) rmmod e1000e >> 5) insmod ./netmap.ko >> 6) insmod ./e1000e/e1000e.ko >> >> You must do make in LINUX dir before apply the patch and after that, you >> need to do again make (without clean). >> >> Tell me if it works. >> >> Thanks, >> Stefano >> >> >> >> --- netmap/LINUX/e1000e/netdev.c 2015-05-28 15:31:31.136816911 +0200 >> +++ netmap/LINUX/e1000e/netdev-new.c 2015-05-28 15:33:38.503484647 +0200 >> @@ -4028,6 +4028,10 @@ int e1000e_up(struct e1000_adapter *adap >> >> netif_start_queue(adapter->netdev); >> >> +#ifdef DEV_NETMAP >> + netmap_enable_all_rings(adapter->netdev); >> +#endif /* DEV_NETMAP */ >> + >> /* fire a link change interrupt to start the watchdog */ >> if (adapter->msix_entries) >> ew32(ICS, E1000_ICS_LSC | E1000_ICR_OTHER); >> >> 2015-05-28 14:39 GMT+02:00 Oleg Prozorov : >> >>> >>> Hello Stefano, >>> I am working on Debian 8 jessy: >>> >>> kernel version: 3.16.0-4-amd64 >>> >>> i used netmap from link : >>> https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca76= 07913fc.tar.gz >>> >>> >>> I did the next steps: >>> 1) untar netmap achive >>> 2) dowonload linux source >>> 3) in netmap-32e06f9d18bf/LINUX directory >>> 3.1) ./configure --kernel-sources=3D/usr/src/linux-source-3.16/ >>> --drivers=3De1000e >>> 3.2) make clean all >>> 4) rmmod e1000e >>> 5) insmod ./netmap.ko >>> 6) insmod ./e1000e/e1000e.ko >>> >>> >>> Ethernet adapter: >>> 02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >>> Connection >>> Subsystem: Intel Corporation Gigabit CT Desktop Adapter >>> Flags: bus master, fast devsel, latency 0, IRQ 16 >>> Memory at f7dc0000 (32-bit, non-prefetchable) [size=3D128K] >>> Memory at f7d00000 (32-bit, non-prefetchable) [size=3D512K] >>> I/O ports at e000 [size=3D32] >>> Memory at f7de0000 (32-bit, non-prefetchable) [size=3D16K] >>> Expansion ROM at f7d80000 [disabled] [size=3D256K] >>> Capabilities: [c8] Power Management version 2 >>> Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ >>> Capabilities: [e0] Express Endpoint, MSI 00 >>> Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- >>> Capabilities: [100] Advanced Error Reporting >>> Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-28-36-f5 >>> Kernel driver in use: e1000e >>> >>> 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network >>> Connection >>> Subsystem: Intel Corporation Gigabit CT Desktop Adapter >>> Flags: bus master, fast devsel, latency 0, IRQ 17 >>> Memory at f7cc0000 (32-bit, non-prefetchable) [size=3D128K] >>> Memory at f7c00000 (32-bit, non-prefetchable) [size=3D512K] >>> I/O ports at d000 [size=3D32] >>> Memory at f7ce0000 (32-bit, non-prefetchable) [size=3D16K] >>> Expansion ROM at f7c80000 [disabled] [size=3D256K] >>> Capabilities: [c8] Power Management version 2 >>> Capabilities: [d0] MSI: Enable- Count=3D1/1 Maskable- 64bit+ >>> Capabilities: [e0] Express Endpoint, MSI 00 >>> Capabilities: [a0] MSI-X: Enable+ Count=3D5 Masked- >>> Capabilities: [100] Advanced Error Reporting >>> Capabilities: [140] Device Serial Number 68-05-ca-ff-ff-22-19-e7 >>> Kernel driver in use: e1000e >>> >>> >>> My application work as netmap bridge. >>> >>> rx -tx in one thread >>> 02:00.0 -> 03:00.0 >>> >>> rx-tx in one thread >>> 03:00.0 -> 02:00.0 >>> >>> I have attached my Netmap engine NetmapStream.cpp. >>> >>> On Intel I350 T2 having Network adapter link bringing down/up ethernet >>> adapter has recovered successfully approx in 3-5 sec without driver cra= sh. >>> >>> >>> Thx, >>> Oleg. >>> >>> >>> 2015-05-28 12:54 GMT+03:00 Stefano Garzarella < >>> stefanogarzarella@gmail.com>: >>> >>>> Hi Oleg, >>>> I'm working on netmap with Luigi and Giuseppe (in cc). >>>> >>>> I tried to do the same steps, but I can not produce the crash. >>>> >>>> Can you you send us your kernel and netmap version? >>>> When you put down and up the interface, are you in tx or rx? >>>> >>>> Cheers, >>>> Stefano >>>> >>>> 2015-05-27 17:26 GMT+02:00 Oleg Prozorov : >>>> >>>>> Hello All, >>>>> I am using Netmap technology in my program and have the problem : >>>>> when I put eth link down and then have it up netmap goes down with >>>>> kernel >>>>> messages: >>>>> >>>>> log from dmesg: >>>>> >>>>> [ 2457.286289] irq 44: nobody cared (try booting with the "irqpoll" >>>>> option) >>>>> [ 2457.286296] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G O >>>>> 3.16.0-4-amd64 #1 Debian 3.16.7-ckt9-3~deb8u1 >>>>> [ 2457.286298] Hardware name: System manufacturer System Product >>>>> Name/P8H61-MX R2.0, BIOS 0803 10/26/2012 >>>>> [ 2457.286300] ffff880198b544c4 ffffffff8150ac96 ffff880198b54400 >>>>> ffffffff810bd10d >>>>> [ 2457.286304] ffff880198b54400 000000000000002c 0000000000000000 >>>>> ffffffff810bd631 >>>>> [ 2457.286307] 0000000000000000 0000000000000000 000000000000002c >>>>> 0000000000000000 >>>>> [ 2457.286310] Call Trace: >>>>> [ 2457.286312] [] ? dump_stack+0x41/0x51 >>>>> [ 2457.286324] [] ? __report_bad_irq+0x2d/0xc0 >>>>> [ 2457.286328] [] ? note_interrupt+0x241/0x290 >>>>> [ 2457.286332] [] ? >>>>> handle_irq_event_percpu+0xa1/0x190 >>>>> [ 2457.286336] [] ? handle_irq_event+0x38/0x60 >>>>> [ 2457.286341] [] ? handle_edge_irq+0x85/0x150 >>>>> [ 2457.286347] [] ? handle_irq+0x1d/0x30 >>>>> [ 2457.286350] [] ? do_IRQ+0x49/0xe0 >>>>> [ 2457.286355] [] ? common_interrupt+0x6d/0x6d >>>>> [ 2457.286356] [] ? >>>>> __hrtimer_start_range_ns+0x1cd/0x390 >>>>> [ 2457.286364] [] ? cpuidle_enter_state+0x52/0xc0 >>>>> [ 2457.286368] [] ? cpuidle_enter_state+0x48/0xc0 >>>>> [ 2457.286372] [] ? cpu_startup_entry+0x2f8/0x400 >>>>> [ 2457.286375] [] ? start_secondary+0x20f/0x2d0 >>>>> [ 2457.286377] handlers: >>>>> [ 2457.286384] [] e1000_msix_other [e1000e] >>>>> [ 2457.286386] Disabling IRQ #44 >>>>> >>>>> before i have the next steps: >>>>> >>>>> insmod ./netmap.ko >>>>> insmod ./e1000e/e1000e.ko >>>>> >>>>> log from dmesg: >>>>> >>>>> [ 1645.548786] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k >>>>> [ 1645.548791] e1000e: Copyright(c) 1999 - 2014 Intel Corporation. >>>>> [ 1645.549056] e1000e 0000:02:00.0: Interrupt Throttling Rate >>>>> (ints/sec) >>>>> set to dynamic conservative mode >>>>> [ 1645.549089] e1000e 0000:02:00.0: irq 42 for MSI/MSI-X >>>>> [ 1645.549094] e1000e 0000:02:00.0: irq 43 for MSI/MSI-X >>>>> [ 1645.549098] e1000e 0000:02:00.0: irq 44 for MSI/MSI-X >>>>> [ 1645.704831] 635.291734 [2720] netmap_attach success >>>>> for eth0 >>>>> tx 1/256 rx 1/256 queues/slots >>>>> [ 1645.705079] e1000e 0000:02:00.0 eth0: registered PHC clock >>>>> [ 1645.705083] e1000e 0000:02:00.0 eth0: (PCI Express:2.5GT/s:Width >>>>> x1) >>>>> 68:05:ca:28:36:f5 >>>>> [ 1645.705086] e1000e 0000:02:00.0 eth0: Intel(R) PRO/1000 Network >>>>> Connection >>>>> [ 1645.705100] e1000e 0000:02:00.0 eth0: MAC: 3, PHY: 8, PBA No: >>>>> E46981-008 >>>>> [ 1645.705349] e1000e 0000:03:00.0: Interrupt Throttling Rate >>>>> (ints/sec) >>>>> set to dynamic conservative mode >>>>> [ 1645.705381] e1000e 0000:03:00.0: irq 45 for MSI/MSI-X >>>>> [ 1645.705386] e1000e 0000:03:00.0: irq 46 for MSI/MSI-X >>>>> [ 1645.705390] e1000e 0000:03:00.0: irq 47 for MSI/MSI-X >>>>> [ 1645.739490] systemd-udevd[2715]: renamed network interface eth0 to >>>>> eth5 >>>>> [ 1645.824716] IPv6: ADDRCONF(NETDEV_UP): eth5: link is not ready >>>>> [ 1645.848756] 635.435799 [2720] netmap_attach success >>>>> for eth0 >>>>> tx 1/256 rx 1/256 queues/slots >>>>> [ 1645.848851] e1000e 0000:03:00.0 eth0: registered PHC clock >>>>> [ 1645.848856] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width >>>>> x1) >>>>> 68:05:ca:22:19:e7 >>>>> [ 1645.848859] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network >>>>> Connection >>>>> [ 1645.848875] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: >>>>> E46981-008 >>>>> [ 1645.869528] systemd-udevd[2715]: renamed network interface eth0 to >>>>> eth6 >>>>> [ 1645.949935] IPv6: ADDRCONF(NETDEV_UP): eth6: link is not ready >>>>> [ 1648.795532] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flo= w >>>>> Control: Rx/Tx >>>>> [ 1648.795856] IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes read= y >>>>> [ 1648.843497] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flo= w >>>>> Control: Rx/Tx >>>>> [ 1648.843820] IPv6: ADDRCONF(NETDEV_CHANGE): eth6: link becomes read= y >>>>> [ 1668.060841] e1000e: eth5 NIC Link is Up 1000 Mbps Full Duplex, Flo= w >>>>> Control: Rx/Tx >>>>> [ 1668.212692] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flo= w >>>>> Control: Rx/Tx >>>>> >>>>> >>>>> My program used netmap desc: >>>>> root@debian:/home/debian/Projects/bin# lsmod | grep netmap >>>>> netmap 99228 5 e1000e >>>>> >>>>> >>>>> Then even if it shows that link is up net map stops to work and only >>>>> rmmod/insmod and restart of the netmap can bring it back to work. >>>>> >>>>> Could you please help me with it ? >>>>> >>>>> Thx a lot, >>>>> Oleg. >>>>> _______________________________________________ >>>>> 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= " >>>>> >>>> >>>> >>>> >>>> -- >>>> *Stefano Garzarella* >>>> Software Engineer >>>> >>>> e-mail: stefano.garzarella@gmail.com >>>> github: http://github.com/stefano-garzarella >>>> linkedin: http://it.linkedin.com/pub/stefano-garzarella >>>> >>> >>> >>> >>> -- >>> =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, >>> =D0=9E=D0=BB=D0=B5=D0=B3 =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0= =B2. >>> >> >> >> >> -- >> *Stefano Garzarella* >> Software Engineer >> >> e-mail: stefano.garzarella@gmail.com >> github: http://github.com/stefano-garzarella >> linkedin: http://it.linkedin.com/pub/stefano-garzarella >> > > > > -- > =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, > =D0=9E=D0=BB=D0=B5=D0=B3 =D0=9F=D1=80=D0=BE=D0=B7=D0=BE=D1=80=D0=BE=D0=B2= . > --=20 *Stefano Garzarella* Software Engineer e-mail: stefano.garzarella@gmail.com github: http://github.com/stefano-garzarella linkedin: http://it.linkedin.com/pub/stefano-garzarella From owner-freebsd-net@FreeBSD.ORG Thu May 28 13:54: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 744C6464 for ; Thu, 28 May 2015 13:54:25 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001: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 361D7A4C for ; Thu, 28 May 2015 13:54:25 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: by iebgx4 with SMTP id gx4so38694517ieb.0 for ; Thu, 28 May 2015 06:54:24 -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=Qt3KSxLm8fmdoeIYHWByLyJW49Fg89vgiiOdOOKkxXg=; b=w6E0Dc4ca6J+uFuR3V8iLc9iElUFUiELPn3brwTmjJD133rQzu4uwTl5lK0Ekq/Tza ZF/2eb+Z7OHScEczYn3sPQ8SvEjc9OEHJWfNTbP7djnd0lGBTOrqHiDsrxunFwsVKmMx Ho8bmHAvd8mdTrMT7f2DopQz0vD/8LVNE2d+xupsamTSXSSjOxy9m6FiLs3J9LfjB4YE Z9rYVPAmnFNc6YamZL+bq5JbdQISNV6SK8DxAzGHu1FuicWY1oOw8QzMxiOZoXV7sbSy 9jymxtb3bAOlT4Cm2Sf0xbC2foOy5YT/VFQHK4YLfkZxsEL5BAPtgJSCsO/8EwY21pgy 9goQ== X-Received: by 10.43.92.199 with SMTP id br7mr9639526icc.43.1432821264542; Thu, 28 May 2015 06:54:24 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by mx.google.com with ESMTPSA id p8sm2126690iga.13.2015.05.28.06.54.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 May 2015 06:54:23 -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: <5560C395.8020807@farrokhi.net> Date: Thu, 28 May 2015 08:54:19 -0500 Cc: freebsd-net@freebsd.org Message-Id: <51002FF3-06BF-4CDB-9D78-A25EA15DF263@gmail.com> References: <5560C395.8020807@farrokhi.net> To: Babak Farrokhi 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, 28 May 2015 13:54:25 -0000 > On May 23, 2015, at 1:14 PM, Babak Farrokhi = wrote: >=20 > Look at the interrupts per queue. 500,000 is the maximum and it is the = reason your interface is not accepting new packets. Thanks for the insight. Is there any possible mitigation for this issue? Regards, Guy >=20 >> Guy Helmer May 21, 2015 at 6:03 PM >> 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 >> Output from sysctl: >>=20 >> # 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 >>=20 >> # 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" = >=20 > --=20 > Babak Farrokhi >=20 From owner-freebsd-net@FreeBSD.ORG Thu May 28 14:01:23 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECD38864 for ; Thu, 28 May 2015 14:01:23 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 380414C27; Thu, 28 May 2015 14:01:22 +0000 (UTC) (envelope-from ae@FreeBSD.org) Message-ID: <55671F25.5070308@FreeBSD.org> Date: Thu, 28 May 2015 16:59:01 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julian Kornberger , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> In-Reply-To: <5566565A.7030200@tzi.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k0B3rCWNdoBLwid6ls7ikwIMcohfoUCDs" 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, 28 May 2015 14:01:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k0B3rCWNdoBLwid6ls7ikwIMcohfoUCDs Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 28.05.2015 02:42, Julian Kornberger wrote: > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x7c > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80a58105 > stack pointer =3D 0x28:0xfffffe00957335e0 > frame pointer =3D 0x28:0xfffffe00957336e0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1707 (tcpmssd) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff80963000 at kdb_backtrace+0x60 > #1 0xffffffff80928125 at panic+0x155 > #2 0xffffffff80d258df at trap_fatal+0x38f > #3 0xffffffff80d25bf8 at trap_pfault+0x308 > #4 0xffffffff80d2525a at trap+0x47a > #5 0xffffffff80d0b142 at calltrap+0x8 > #6 0xffffffff81a15797 at gre_output+0x467 > #7 0xffffffff80a59024 at ip_output+0x11b4 > #8 0xffffffff819b257a at div_send+0x33a > #9 0xffffffff8099e0b5 at sosend_generic+0x475 > #10 0xffffffff809a4425 at kern_sendit+0x245 > #11 0xffffffff809a4749 at sendit+0x129 > #12 0xffffffff809a460d at sys_sendto+0x4d > #13 0xffffffff80d26211 at amd64_syscall+0x351 > #14 0xffffffff80d0b42b at Xfast_syscall+0xfb Can you enable dumpon(8) in your rc.conf, then get the crash dump and show content of your /var/crash/core.txt.N file? Also can you try this module instead of one from your base system? https://people.freebsd.org/~ae/gre-10.tgz This is ported to stable/10 version from 11.0-CURRENT. --=20 WBR, Andrey V. Elsukov --k0B3rCWNdoBLwid6ls7ikwIMcohfoUCDs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVZx8mAAoJEAHF6gQQyKF6GF4H/1xnco029qdG7Q+d0sV9U1of DG+QEC8TkXSa/hu1XzyehzwMyFHEw1RwU7ZXXhA0vtHJ5uZLTdpUILeYhsvlDCae 9H0NK1LdkTl8PKXGgvE6VcxdQ2otG+PzEknxf7qLGiU/F7K8NgO0qSoh/873tajH TPEsvzMhl9Z0Qg3z5EcTsiLafpPhiumzUTciODS42Nav74oqkeM/tUUkfyNBt9bu boQZvS/M/lTop5gJC5ctsa72EXtRRATDMs3qG3o4nG56gyNjLtMrySg7VLlc92WM RTynknNJ9unUzmXRftOlEafw/iwtNiGAK008MTT7CpF9wIXM4N8Ac5FTtY5WL1E= =WcOp -----END PGP SIGNATURE----- --k0B3rCWNdoBLwid6ls7ikwIMcohfoUCDs-- From owner-freebsd-net@FreeBSD.ORG Thu May 28 14:09:53 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10B3B292 for ; Thu, 28 May 2015 14:09:53 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 4835E6665B; Thu, 28 May 2015 14:09:52 +0000 (UTC) (envelope-from ae@FreeBSD.org) Message-ID: <55672123.1090101@FreeBSD.org> Date: Thu, 28 May 2015 17:07:31 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julian Kornberger , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> In-Reply-To: <5566565A.7030200@tzi.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f0sVFN71psP7CX91X1KjeGkdS0ILJTg1u" 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, 28 May 2015 14:09:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f0sVFN71psP7CX91X1KjeGkdS0ILJTg1u Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 28.05.2015 02:42, Julian Kornberger wrote: > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x7c > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80a58105 > stack pointer =3D 0x28:0xfffffe00957335e0 > frame pointer =3D 0x28:0xfffffe00957336e0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1707 (tcpmssd) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff80963000 at kdb_backtrace+0x60 > #1 0xffffffff80928125 at panic+0x155 > #2 0xffffffff80d258df at trap_fatal+0x38f > #3 0xffffffff80d25bf8 at trap_pfault+0x308 > #4 0xffffffff80d2525a at trap+0x47a > #5 0xffffffff80d0b142 at calltrap+0x8 > #6 0xffffffff81a15797 at gre_output+0x467 > #7 0xffffffff80a59024 at ip_output+0x11b4 > #8 0xffffffff819b257a at div_send+0x33a Just noticed, you use ip_divert(4). gre(4) uses mbuf_tag to prevent infinity loop and stack exhausting. When packet goes through ip_divert, it loses this tag. You need to check your rules and avoid applying divert rules to GRE packets. Also you can use some netgraph based tcpmss implementation. --=20 WBR, Andrey V. Elsukov --f0sVFN71psP7CX91X1KjeGkdS0ILJTg1u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVZyEjAAoJEAHF6gQQyKF6qY4IAJu6TLB+5GobZafP5qkkrsHm ILadB6o26Pjv8VGUyuXB30dvgG1fWzw0s2FwQIpEsqpItRsJ7Se+LRmUkVXey4+L muuPr7U2rz1r5har4S0skCmIRzgIw5SKaMUKO3KNp4/tpnEfwDcaezrDi41cYPwA RSdmDPuDCd/Wyh7LSaMhpswr6CfSkYaUJ1IVzkSbvKTOWvIQbayTDeHJkXQZMHbQ ELWYM7hdBxiWqoSlEFGATzXiE74L1aSBed335TpguNJYYcB6ABuO+T+Bw1Y6u4uA iyC8LetgMw+mVlPNtyG2RfGEuSfmkGPQNo/eMkZ6231tmaIRtbXkz11i+2CcXbM= =WrQ8 -----END PGP SIGNATURE----- --f0sVFN71psP7CX91X1KjeGkdS0ILJTg1u-- From owner-freebsd-net@FreeBSD.ORG Thu May 28 14:14: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 EB7B151F for ; Thu, 28 May 2015 14:14:54 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 B2A84F6A for ; Thu, 28 May 2015 14:14:54 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: by igbhj9 with SMTP id hj9so115379927igb.1 for ; Thu, 28 May 2015 07:14:53 -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 :content-transfer-encoding:message-id:references:to; bh=S+MJy1xcB3/R+eN3QNFv34WGY7RoBOiFKwm/HFZHTjM=; b=a0gSBqYcBXfxSlxOiaNXWkseI2ljJZsj283Mz//HOhx/1BScBdhtrj+ZhhCsVyrFNs 7ykH0FWvlJi7vmnU6q6zpPEo6/irbBdV6XFVgyCm0zm/WPU8sGQ7Isk6VwycbycCJXWM dpyDzQz2RmZrYiPSpcckFDIFiT20IyIHyaMCnkMreJUo2FHMqZN06soYqRg93wdJlpue uXWQv7lXc3n3SCnfu6HdEBOVaNjYotAZ6Puyn2fREunSYSoFhxQ5mIbhprDGA9iDtD/e trtqs9+hqDQEKajMrQ3pRvSKqiQUjrQXk+Z2xKOallQO6hX1expLgLoeQ6DRHMYai+QS OHnQ== X-Received: by 10.107.40.144 with SMTP id o138mr3735975ioo.66.1432822493757; Thu, 28 May 2015 07:14:53 -0700 (PDT) Received: from [172.22.132.117] ([192.119.231.58]) by mx.google.com with ESMTPSA id 17sm1816072ioq.39.2015.05.28.07.14.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 May 2015 07:14:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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: <5564852D.8040008@bsdinfo.com.br> Date: Thu, 28 May 2015 09:14:49 -0500 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1FB15FA4-6185-4206-9517-AE9667A1A57C@gmail.com> References: <5560C395.8020807@farrokhi.net> <5564852D.8040008@bsdinfo.com.br> To: Marcelo Gondim 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, 28 May 2015 14:14:55 -0000 > On May 26, 2015, at 9:37 AM, Marcelo Gondim = wrote: >=20 > On 23-05-2015 15:14, Babak Farrokhi wrote: >> Look at the interrupts per queue. 500,000 is the maximum and it is = the >> reason your interface is not accepting new packets. >>=20 >>> Guy Helmer >>> May 21, 2015 at 6:03 PM >>> 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 >>> Output from sysctl: >>>=20 >>> . . . >>=20 > Hi, >=20 > I had this problem and one day updated the system 10.1- RELEASE to = 10.1- STABLE and the problem stopped. I was one years with this problem = and a script running and testing the interface when the interface = stopped working I was doing exactly what you did. Today I no longer have = that problem anymore. >=20 > I'm using 10.1-STABLE r281235 Thanks for the indication of success with 10.1-STABLE. I am locked into = using FreeBSD 9.x until I can go through the whole integration and = acceptance testing cycle for 10.x, so I=E2=80=99m trying to find a = solution that works on in 9.x. I have reviewed the diffs between 9.3 and = 10.1-STABLE for ixgbe driver and haven=E2=80=99t noticed anything that = stands out. Regards, Guy= From owner-freebsd-net@FreeBSD.ORG Thu May 28 14:22:08 2015 Return-Path: Delivered-To: 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 4A97D649; Thu, 28 May 2015 14:22:08 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4F211F1; Thu, 28 May 2015 14:22:07 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4SEM4Ym013354; Thu, 28 May 2015 16:22:04 +0200 (CEST) Received: from [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e] (p200300556B2BD00030D9F27982B0BE8E.dip0.t-ipconnect.de [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lyB701g2Cz8xcQ; Thu, 28 May 2015 16:22:04 +0200 (CEST) Message-ID: <5567248B.1040207@tzi.de> Date: Thu, 28 May 2015 16:22:03 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> In-Reply-To: <55671F25.5070308@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; 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: Thu, 28 May 2015 14:22:08 -0000 Am 28.05.2015 um 15:59 schrieb Andrey V. Elsukov:> Can you enable dumpon(8) in your rc.conf, then get the crash dump and > show content of your /var/crash/core.txt.N file? > > Also can you try this module instead of one from your base system? > https://people.freebsd.org/~ae/gre-10.tgz > > This is ported to stable/10 version from 11.0-CURRENT. > I already have some crash logs: http://91.202.42.216/ Some are with and some are without dummynet. -- Julian From owner-freebsd-net@FreeBSD.ORG Thu May 28 14:27:41 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 5E59CA1E; Thu, 28 May 2015 14:27:41 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8AB9276; Thu, 28 May 2015 14:27:40 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4SERbFu024331; Thu, 28 May 2015 16:27:37 +0200 (CEST) Received: from [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e] (p200300556B2BD00030D9F27982B0BE8E.dip0.t-ipconnect.de [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lyBFP4jZnz8xcb; Thu, 28 May 2015 16:27:37 +0200 (CEST) Message-ID: <556725D9.4090708@tzi.de> Date: Thu, 28 May 2015 16:27:37 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55672123.1090101@FreeBSD.org> In-Reply-To: <55672123.1090101@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; 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: Thu, 28 May 2015 14:27:41 -0000 Am 28.05.2015 um 16:07 schrieb Andrey V. Elsukov: > Just noticed, you use ip_divert(4). gre(4) uses mbuf_tag to prevent > infinity loop and stack exhausting. When packet goes through ip_divert, > it loses this tag. You need to check your rules and avoid applying > divert rules to GRE packets. Also you can use some netgraph based tcpmss > implementation. I only pass TCP SYN packets to divert. This should not affect GRE packets? ipfw add divert $tcpmssd_port tcp from any to not me setup Thanks for your GRE module. I will give it a try. -- Julian From owner-freebsd-net@FreeBSD.ORG Thu May 28 17:12:22 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 88A39C4A; Thu, 28 May 2015 17:12:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 68A3D27A; Thu, 28 May 2015 17:12:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (c-71-202-112-39.hsd1.ca.comcast.net [71.202.112.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id D85E3141D9; Thu, 28 May 2015 10:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1432833135; x=1432847535; bh=IKot36W9NfLqJhSb+V7kl8g9aNZvdLLazxqdZ9radGw=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=kJWxS1m6thfRl9+Ka7cmvyTZRCqJNxzp2MALBBBhLHrJ31rc2/Jyl3Cpgyx1Ah662 cjcq3XEE6xRzffkJ/n8JUlEzW5PCYjic4xNjFnZNN13hTUsT+gToeuBBEsja0SJp+5 XNeXDDopiGMTJDbfznHp5SsCQhqEiFTocrFEEtI4= Message-ID: <55674C6B.9050700@delphij.net> Date: Thu, 28 May 2015 10:12:11 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: hiren panchasara , Patrick Kelsey CC: "freebsd-net@freebsd.org" , delphij@FreeBSD.org Subject: Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" References: <20150528045551.GS95600@strugglingcoder.info> In-Reply-To: <20150528045551.GS95600@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252 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: Thu, 28 May 2015 17:12:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Hiren, On 05/27/15 21:55, hiren panchasara wrote: > On 05/28/15 at 12:40P, Patrick Kelsey wrote: >> Hi, >> >> I've had a patch for a capsicum-related issue in tcpdump sitting >> around since last September ( >> https://lists.freebsd.org/pipermail/freebsd-current/2014-September/05 2049.html) >> >> that is still needed and that I want finally address in the tree (the pa tch >> was reviewed by rwatson@ and pjd@ back then). >> >> This issue was patched separately in the upstream tcpdump sources >> in February ( >> https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8c0e f9a5af1a95b43753e3ad2eb), >> >> along with a refactor of the associated capsicum code, and that work has >> been present in tcpdump releases since 4.7.3 ( >> http://www.tcpdump.org/tcpdump-changes.txt). >> >> The last tcpdump release imported into the FreeBSD tree was 4.6.2 >> ( http://svnweb.freebsd.org/base/vendor/tcpdump/). >> >> tcpdump release import/merges have recently resulted in some >> confusion/lost local patches due to the extent of the diffs >> (e.g., the thread at >> https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067853 .html). >> >> >> I see three possible ways to proceed: >> >> 1. Apply the minimal-local-diff patch from last September to our >> local tcpdump sources. This seems like it might contribute to a >> future difficult/lossy tcpdump vendor import/merge. >> >> 2. Import tcpdump 4.7.3 or later to address this issue. Are >> there any reasons why this might not be desired? I don't have a >> feel for when/why past tcpdump vendor imports have been performed >> or avoided. >> >> 3. Cherry-pick the upstream patch and apply it to our local >> sources, directly addressing only this issue and avoiding future >> tcpdump vendor import/merge problems related to this issue. >> >> I'm looking for input on the above. If left to my own devices, >> I'd go with (3). > > Latest upstream release is 4.7.4 and the one before that was 4.6.2 > which we already have in the tree. I think we should get latest > instead of picking bits and pieces when possible. > > CCing Xin for his input as he has been doing last few imports. Yes, I think we should do the new import. (Are you willing to do that? I'm doing it only because nobody else were doing it...) Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVZ0xrAAoJEJW2GBstM+nstbUP/jER9jTYevNftIMcTrbDhtKn iV2QjquvGHQdf7bkKQujLuaMoZG9GKqzyg0XT+d9yL7vk+kBvAqPRuQ6hJgaf4GH VgzL1nN7g+U5PCA+98nszF81/NiFHkz1Ag5ayLl/X2TxQaTgMijT4hulkMEN8idh 6c17RC7YCWkkQAerrB4N0aj08MiXZJ3L2/SRsJZwHCfpzXZNSubA/mjxwD4QMtR2 kAFkLc0FfAVIWN8rxYEmmnj+YlYQRrMKhs0/ZfyrkPDHQDJ5MJZWHcrkTAdaJ8I+ Fp2sTezfCrkRrNyVOu2XQWRkV6IfQxXNsFmvzn3kbAzSO68SiKvZ6fG6uFaa2A21 anjoqBshTaxEXMq+v0BI2oCZDbJF9CKpjMUmvevDRofPWsr6ROb1ElUsXgLdvPoe QcvYC7S/Qf2DnRz3lbvSh4YeRowj9ridSQm3g3fdRQURCEWnsWK6NahclBqJqWy1 A15ZKPMLj/Su9po3dtl4gr0AvS2g7TPa9lcGMSjebQ+hiMYxE0Bc0RsGAvytZ+AE uUdbT+0u6IGn3QldkYJfwZFwuVYLJQFug8L3QOScGxZEBrxZcZdzAMVQffypPgPt bsiAk974pwqHHmf8C1mdmYf5H65wpnOTNg5o/uQ19KiMsjxpRPspWTy7BRDZlkUO kWm4dBZUgYxYIqZcFoT7 =0LqE -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu May 28 17:18: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 F1AF0F6E; Thu, 28 May 2015 17:18:53 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) 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 D1D68313; Thu, 28 May 2015 17:18:53 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 4AA9410D4BE; Thu, 28 May 2015 10:18:53 -0700 (PDT) Date: Thu, 28 May 2015 10:18:53 -0700 From: hiren panchasara To: d@delphij.net Cc: Patrick Kelsey , "freebsd-net@freebsd.org" , delphij@FreeBSD.org Subject: Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" Message-ID: <20150528171853.GU95600@strugglingcoder.info> References: <20150528045551.GS95600@strugglingcoder.info> <55674C6B.9050700@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KJvkvZqQCzHgjKcr" Content-Disposition: inline In-Reply-To: <55674C6B.9050700@delphij.net> 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, 28 May 2015 17:18:54 -0000 --KJvkvZqQCzHgjKcr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 05/28/15 at 10:12P, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi, Hiren, >=20 > On 05/27/15 21:55, hiren panchasara wrote: > > On 05/28/15 at 12:40P, Patrick Kelsey wrote: > >> Hi, > >>=20 > >> I've had a patch for a capsicum-related issue in tcpdump sitting > >> around since last September (=20 > >> https://lists.freebsd.org/pipermail/freebsd-current/2014-September/05 > 2049.html) > >> > >>=20 > that is still needed and that I want finally address in the tree (the pa > tch > >> was reviewed by rwatson@ and pjd@ back then). > >>=20 > >> This issue was patched separately in the upstream tcpdump sources > >> in February (=20 > >> https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8c0e > f9a5af1a95b43753e3ad2eb), > >> > >>=20 > along with a refactor of the associated capsicum code, and that work has > >> been present in tcpdump releases since 4.7.3 (=20 > >> http://www.tcpdump.org/tcpdump-changes.txt). > >>=20 > >> The last tcpdump release imported into the FreeBSD tree was 4.6.2 > >> ( http://svnweb.freebsd.org/base/vendor/tcpdump/). > >>=20 > >> tcpdump release import/merges have recently resulted in some > >> confusion/lost local patches due to the extent of the diffs > >> (e.g., the thread at=20 > >> https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067853 > .html). > >> > >> > >>=20 > I see three possible ways to proceed: > >>=20 > >> 1. Apply the minimal-local-diff patch from last September to our > >> local tcpdump sources. This seems like it might contribute to a > >> future difficult/lossy tcpdump vendor import/merge. > >>=20 > >> 2. Import tcpdump 4.7.3 or later to address this issue. Are > >> there any reasons why this might not be desired? I don't have a > >> feel for when/why past tcpdump vendor imports have been performed > >> or avoided. > >>=20 > >> 3. Cherry-pick the upstream patch and apply it to our local > >> sources, directly addressing only this issue and avoiding future > >> tcpdump vendor import/merge problems related to this issue. > >>=20 > >> I'm looking for input on the above. If left to my own devices, > >> I'd go with (3). > >=20 > > Latest upstream release is 4.7.4 and the one before that was 4.6.2 > > which we already have in the tree. I think we should get latest > > instead of picking bits and pieces when possible. > >=20 > > CCing Xin for his input as he has been doing last few imports. >=20 > Yes, I think we should do the new import. (Are you willing to do > that? I'm doing it only because nobody else were doing it...) I think Patrick volunteered to do the import. If he can't, I'll do it. Cheers, Hiren --KJvkvZqQCzHgjKcr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVZ038XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lioIH/ia2GJouELpIFgfea60Un3s1 L7lNOxqGxQSY9xowPv/n9GS1UMNb2PPuUhgCyuaEZKA5OxIR2J/1+rI0FNKHa8x4 sb5VSvcYC+U5xmmPIGRfQMmGn9WBcb9lI9U5eJQAmPjB8tZhezU4LsY07zGPM2Oh pz/m+FE46wqxwx9HBekjLAox19UpfAErj2S+FFSzdu/tXKy2AafCo61Tc6fFkzZ9 nMKk1IsKNvRD883o7HZWROUwOfmQ9a1BQoeTc87SH0ixuw2KiNSj098fMi1PguE3 NN1B89iZpNXgahu8IYYXxa38X9cxwRZAdzxOYoRwdy9kO4kTOjn5FwsaR3sMSts= =qXmK -----END PGP SIGNATURE----- --KJvkvZqQCzHgjKcr-- From owner-freebsd-net@FreeBSD.ORG Thu May 28 17:21:03 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 D2EA81A2; Thu, 28 May 2015 17:21:03 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::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 8DD8269B; Thu, 28 May 2015 17:21:03 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: by yhpn97 with SMTP id n97so12364834yhp.0; Thu, 28 May 2015 10:21:02 -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=rQNgLX2cmCuEujaHbIRlQUETz8PVQsnzy5ANVGc+CMM=; b=hsGYe34T/sz3PFZXSxYa4+O3a/tiyRdQO/UVinr87e21HM/Pt5d7Kbc5VzXFZ9GObE 8/3JUODC+dwBKXB9Hkkunfu79uMBss1RKhRsHnpHvrLfCQDQ/9OoB5C8fkR5QuRRW4ii 5HXw+a+xjEOeBCuz2Giw++pJIyhhKMISzLUyuKlzICBcOaGKQGihzUdTge6W7aVgMLMr LRKB6Ndc+BIBfIuy22MV6jVc2uPz1oSp9VpYLTZsjuy3dcikG3uc6nS3ohc9TrWJD3jn ZiQ4JKFMYDHZyZNte5LXmi0FT40Li7dB6X/+8JdNFPuVBtRRO4Pp56PfnCkzJBZ3QlwB jeQg== MIME-Version: 1.0 X-Received: by 10.236.198.138 with SMTP id v10mr3662219yhn.113.1432833662707; Thu, 28 May 2015 10:21:02 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.13.201.71 with HTTP; Thu, 28 May 2015 10:21:02 -0700 (PDT) In-Reply-To: <20150528171853.GU95600@strugglingcoder.info> References: <20150528045551.GS95600@strugglingcoder.info> <55674C6B.9050700@delphij.net> <20150528171853.GU95600@strugglingcoder.info> Date: Thu, 28 May 2015 13:21:02 -0400 X-Google-Sender-Auth: Qt4FTilrX-bwvI23X_Y8abqVKtE Message-ID: Subject: Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" From: Patrick Kelsey To: hiren panchasara Cc: d@delphij.net, "freebsd-net@freebsd.org" , delphij@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, 28 May 2015 17:21:03 -0000 Yes, I'll give it a go. I haven't yet done a dry-run to see how hairy it might be, so no predictions there. Thanks, Patrick On Thu, May 28, 2015 at 1:18 PM, hiren panchasara < hiren@strugglingcoder.info> wrote: > On 05/28/15 at 10:12P, Xin Li wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi, Hiren, > > > > On 05/27/15 21:55, hiren panchasara wrote: > > > On 05/28/15 at 12:40P, Patrick Kelsey wrote: > > >> Hi, > > >> > > >> I've had a patch for a capsicum-related issue in tcpdump sitting > > >> around since last September ( > > >> https://lists.freebsd.org/pipermail/freebsd-current/2014-September/05 > > 2049.html) > > >> > > >> > > that is still needed and that I want finally address in the tree (the pa > > tch > > >> was reviewed by rwatson@ and pjd@ back then). > > >> > > >> This issue was patched separately in the upstream tcpdump sources > > >> in February ( > > >> https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8c0e > > f9a5af1a95b43753e3ad2eb), > > >> > > >> > > along with a refactor of the associated capsicum code, and that work has > > >> been present in tcpdump releases since 4.7.3 ( > > >> http://www.tcpdump.org/tcpdump-changes.txt). > > >> > > >> The last tcpdump release imported into the FreeBSD tree was 4.6.2 > > >> ( http://svnweb.freebsd.org/base/vendor/tcpdump/). > > >> > > >> tcpdump release import/merges have recently resulted in some > > >> confusion/lost local patches due to the extent of the diffs > > >> (e.g., the thread at > > >> https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067853 > > .html). > > >> > > >> > > >> > > I see three possible ways to proceed: > > >> > > >> 1. Apply the minimal-local-diff patch from last September to our > > >> local tcpdump sources. This seems like it might contribute to a > > >> future difficult/lossy tcpdump vendor import/merge. > > >> > > >> 2. Import tcpdump 4.7.3 or later to address this issue. Are > > >> there any reasons why this might not be desired? I don't have a > > >> feel for when/why past tcpdump vendor imports have been performed > > >> or avoided. > > >> > > >> 3. Cherry-pick the upstream patch and apply it to our local > > >> sources, directly addressing only this issue and avoiding future > > >> tcpdump vendor import/merge problems related to this issue. > > >> > > >> I'm looking for input on the above. If left to my own devices, > > >> I'd go with (3). > > > > > > Latest upstream release is 4.7.4 and the one before that was 4.6.2 > > > which we already have in the tree. I think we should get latest > > > instead of picking bits and pieces when possible. > > > > > > CCing Xin for his input as he has been doing last few imports. > > > > Yes, I think we should do the new import. (Are you willing to do > > that? I'm doing it only because nobody else were doing it...) > > I think Patrick volunteered to do the import. If he can't, I'll do it. > > Cheers, > Hiren > From owner-freebsd-net@FreeBSD.ORG Thu May 28 17:26: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 6C33F3F7; Thu, 28 May 2015 17:26:20 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FCBA804; Thu, 28 May 2015 17:26:19 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (c-71-202-112-39.hsd1.ca.comcast.net [71.202.112.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 5EB1014369; Thu, 28 May 2015 10:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1432833979; x=1432848379; bh=0dcU5NKhYRSfY0M5DGkzy5CbBZVIJEtwRJNeOAGzlF0=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=1+17zA49O5WXxG/nCAS9d6W6QWBsHiiG6TPTe2mTzBdjH1SLxXRVmHED06lb9ZfL/ VNcn5gKi2guApfyXaFVg9ktNHUW0dBqavcMgMUwrHg+OuYekYnNMzHpM6IhWGQQnC/ C3bDkSkrLJypU7qiF8DZD9Pm60luiugDwyI6TUrM= Message-ID: <55674FBA.7050204@delphij.net> Date: Thu, 28 May 2015 10:26:18 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Patrick Kelsey , hiren panchasara CC: delphij@freebsd.org, "freebsd-net@freebsd.org" , d@delphij.net Subject: Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" References: <20150528045551.GS95600@strugglingcoder.info> <55674C6B.9050700@delphij.net> <20150528171853.GU95600@strugglingcoder.info> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Thu, 28 May 2015 17:26:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/28/15 10:21, Patrick Kelsey wrote: > Yes, I'll give it a go. I haven't yet done a dry-run to see how > hairy it might be, so no predictions there. Great! Please feel free to ask if you need any help from my side. Cheers, > Thanks, Patrick > > On Thu, May 28, 2015 at 1:18 PM, hiren panchasara < > hiren@strugglingcoder.info> wrote: > >> On 05/28/15 at 10:12P, Xin Li wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>> >>> Hi, Hiren, >>> >>> On 05/27/15 21:55, hiren panchasara wrote: >>>> On 05/28/15 at 12:40P, Patrick Kelsey wrote: >>>>> Hi, >>>>> >>>>> I've had a patch for a capsicum-related issue in tcpdump >>>>> sitting around since last September ( >>>>> https://lists.freebsd.org/pipermail/freebsd-current/2014-September /05 >>> >>>>> 2049.html) >>>>> >>>>> >>> that is still needed and that I want finally address in the >>> tree (the pa tch >>>>> was reviewed by rwatson@ and pjd@ back then). >>>>> >>>>> This issue was patched separately in the upstream tcpdump >>>>> sources in February ( >>>>> https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8 c0e >>> >>>>> f9a5af1a95b43753e3ad2eb), >>>>> >>>>> >>> along with a refactor of the associated capsicum code, and that >>> work has >>>>> been present in tcpdump releases since 4.7.3 ( >>>>> http://www.tcpdump.org/tcpdump-changes.txt). >>>>> >>>>> The last tcpdump release imported into the FreeBSD tree was >>>>> 4.6.2 ( http://svnweb.freebsd.org/base/vendor/tcpdump/). >>>>> >>>>> tcpdump release import/merges have recently resulted in >>>>> some confusion/lost local patches due to the extent of the >>>>> diffs (e.g., the thread at >>>>> https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067 853 >>> >>>>> .html). >>>>> >>>>> >>>>> >>> I see three possible ways to proceed: >>>>> >>>>> 1. Apply the minimal-local-diff patch from last September >>>>> to our local tcpdump sources. This seems like it might >>>>> contribute to a future difficult/lossy tcpdump vendor >>>>> import/merge. >>>>> >>>>> 2. Import tcpdump 4.7.3 or later to address this issue. >>>>> Are there any reasons why this might not be desired? I >>>>> don't have a feel for when/why past tcpdump vendor imports >>>>> have been performed or avoided. >>>>> >>>>> 3. Cherry-pick the upstream patch and apply it to our >>>>> local sources, directly addressing only this issue and >>>>> avoiding future tcpdump vendor import/merge problems >>>>> related to this issue. >>>>> >>>>> I'm looking for input on the above. If left to my own >>>>> devices, I'd go with (3). >>>> >>>> Latest upstream release is 4.7.4 and the one before that was >>>> 4.6.2 which we already have in the tree. I think we should >>>> get latest instead of picking bits and pieces when possible. >>>> >>>> CCing Xin for his input as he has been doing last few >>>> imports. >>> >>> Yes, I think we should do the new import. (Are you willing to >>> do that? I'm doing it only because nobody else were doing >>> it...) >> >> I think Patrick volunteered to do the import. If he can't, I'll >> do it. >> >> Cheers, Hiren >> > _______________________________________________ > 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" > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVZ0+6AAoJEJW2GBstM+nsDfoP/1XiBFyZ0mY1lA6zEj/7BegN COHHyPWc6BAgGB3uW6aTUNJ417B5udz9MPifG/582G/GzXKBJJiu5/O2eHNJ+e8T ioIaBt0+hy3+QyoAfa+LiYJ0IwuKErXmZ+CD4LuOZT6itZnru67DWG9voWJYCV+V RK7Ry585fDDNDE2qNUAZgKUH35OMjmhdGjLlV2wFOhWuo/le/ZasvsRuAMaBq7v8 NIZNs3QoeyJhhkgLn3427ntDXbmAVm1p62zRdTjbPVYc9Re8JkA8tWzCnEtz04em lcypZWZRafRvPYUCM9+qLpOpogXsotk1SRlm6QhXt0BZe782btJVgLNIROJPC851 enV8P2pgI7zudazLjO79Cb56UxAyKRJBxht5bxW3nAxRAB34KIe9018CHhi8nTGl ZAzOYESYijDUDwG22iskSBUWm4VcRLSXRZmH/+NgKvmrzaPD/L3NAipZ4REqDRkD Uls2H4kMsKf8IgmZQQF8nonJzg5k73pF37PvA4VHjqnPn3vi6GJfgKQani6oMGpW nKa9YrCF3z7vD+t1Mifn44+GWN73PZ3OjiHNKi4Sx8nXeSdC412SJo+Rrb/FTWYv LZ1Joaobl84JXuuogoLkG09yXwm90PsoHHr0OfdPd6DAF67UhUjmd2phEMW3vFHz R9ZicEtFxm9LeGqmBI9e =wtWn -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu May 28 17:49:40 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 81878BB1; Thu, 28 May 2015 17:49:40 +0000 (UTC) (envelope-from flewis@panasas.com) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0066.outbound.protection.outlook.com [157.56.110.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 2E520CA6; Thu, 28 May 2015 17:49:38 +0000 (UTC) (envelope-from flewis@panasas.com) Received: from BY2PR08MB1797.namprd08.prod.outlook.com (25.163.46.23) by BY2PR08MB157.namprd08.prod.outlook.com (10.242.39.16) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 17:49:29 +0000 Received: from CY1PR0801MB1563.namprd08.prod.outlook.com (25.163.143.139) by BY2PR08MB1797.namprd08.prod.outlook.com (25.163.46.23) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 17:49:25 +0000 Received: from CY1PR0801MB1563.namprd08.prod.outlook.com ([25.163.143.139]) by CY1PR0801MB1563.namprd08.prod.outlook.com ([25.163.143.139]) with mapi id 15.01.0172.012; Thu, 28 May 2015 17:49:25 +0000 From: "Lewis, Fred" To: Adrian Chadd , "Sundararajan, Lakshmi" CC: "Pokala, Ravi" , "freebsd-net@freebsd.org" , "jfv@freebsd.org" , "erj@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Performance issues with Intel Fortville (XL710/ixl(4)) Thread-Topic: Performance issues with Intel Fortville (XL710/ixl(4)) Thread-Index: AQHQkn+7WBa4imHGwkeMI3kSTJaMlZ2HA5GAgAfVrACAApv3AA== Date: Thu, 28 May 2015 17:49:24 +0000 Message-ID: References: <5564b545.0287440a.5871.7050@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=flewis@panasas.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.31.107.140] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BY2PR08MB1797; UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BY2PR08MB157; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BY2PR08MB1797; BCL:0; PCL:0; RULEID:; SRVR:BY2PR08MB1797; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(501624003)(24454002)(51704005)(189002)(164054003)(479174004)(199003)(377454003)(122556002)(81156007)(5001770100001)(15975445007)(50986999)(68736005)(102836002)(76176999)(106116001)(54356999)(2900100001)(101416001)(1720100001)(106356001)(2950100001)(105586002)(87936001)(4001540100001)(189998001)(40100003)(97736004)(2656002)(99286002)(62966003)(36756003)(77156002)(19580395003)(46102003)(86362001)(66066001)(64706001)(5001860100001)(19580405001)(92566002)(5001960100002)(5001830100001)(5002640100001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR08MB1797; H:CY1PR0801MB1563.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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 17:49:24.8514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR08MB1797 X-OriginatorOrg: panasas.com 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, 28 May 2015 17:49:40 -0000 Hi Adrian, It is my understanding that you are maintaining the RSS code. The Panasas folks have this question for you. We are doing our testing w/ 11-CURRENT, but we will initially ship Intel XL710 40G NIC (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 ixl driver (1.4.1) and (especially) the supporting RSS code infrastructure will get MFCed to 10-STABLE? Thanks, -Fred On 5/26/15 5:58 PM, "Adrian Chadd" wrote: >hi! > >Try enabling RSS and PCBGROUPS on -HEAD. The ixl driver should work. > >(I haven't tested it though; I've had other things going on here.) > > > >-adrian > > >On 21 May 2015 at 15:20, Lakshmi Narasimhan Sundararajan > wrote: >> Hi FreeBSD Team! >> >> We seem to have found a problem to Tx performance. >> >> We found that the tx handling is spread on all CPUs causing probably >>cache trashing resulting in poor performance. >> >> But once we used cpuset to bind interrupt thread and iperf process to >>the same CPU, performance was close to line rate. I used userland cpuset >>command to perform this manually. I want this constrained in the kernel >>config/code through some tunables, and I am seeking your help/pointers >>in that regard. >> >> >> My followup questions are as follows. >> >> a) How are Tx interrupts steered from the NIC to the CPU on the >>transmit path? Would tx_complete# interrupt for packets transmitted from >>CPU#x, be serviced on the same CPU? If not, how to get this binding done? >> >> >> b) I would like to use a pool of CPUs dedicated to service NIC >>interrupts. Especially on the transmit path, I would want the >>tx_interrupts to be handled on the same CPU on which request was >>submitted. How to get this done? >> >> >> I played with the current ISR setting but I did not see any difference >>in how Interrupts are scheduled across CPU. The max interrupt threads >>even though set to one, the interrupt threads are scheduled on any CPU. >>Even if I set bindthreads to =8C1=B9. There is no difference in interrupt >>thread scheduling. >> >> >> root@mau-da-27-4-1:~ # sysctl net.isr >> net.isr.dispatch: direct >> net.isr.maxthreads: 1 >> net.isr.bindthreads: 0 >> net.isr.maxqlimit: 10240 >> net.isr.defaultqlimit: 256 >> net.isr.maxprot: 16 >> net.isr.numthreads: 1 >> >> >> I would sincerely appreciate if you can provide some pointers on these >>items above. >> >> >> >> >> Thanks >> >> LN >> >> >> >> >> >> >> >> From: Pokala, Ravi >> Sent: Wednesday, May 20, 2015 3:34 AM >> To: freebsd-net@freebsd.org, jfv@freebsd.org, erj@freebsd.org >> Cc: freebsd-hackers@freebsd.org, Lewis, Fred, Sundararajan, Lakshmi >> >> >> >> >> >> 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 >> _______________________________________________ >> 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 28 19:00:26 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 E1D34CD5; Thu, 28 May 2015 19:00:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) 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 AA4D4160; Thu, 28 May 2015 19:00:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbpi8 with SMTP id pi8so316747igb.0; Thu, 28 May 2015 12:00:26 -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=ag6KQUNqk1xfU7eWchSItl3IOW3DeYaTzWiR4Ol0aog=; b=wBP+RGcok1k7rIm3gxXvD17k/BwIqKZiEiFQI0a8z8grqPHBG3JWBNv/HX6h76qx8n TQlPhJt/RIrrnlA7d1pmLr08/L7s8IM8kD+Y12H63ob/qKSHMCVXHwDF+FP7xmSDuTqW 24SAMpvaIVjk0Ked7ybnAhEiczfBq2Bd7PgR1J/W2oyoPLasQEwNTdV1F4/KQHuRKMEK L/GlpFtT9SKOj7VDBa8HkbCnZlb/LfLlas6FbzVaPf5I8xFK6F/mqvK4WLtdADsJ2dw7 1sPmC6/pSTL2I4j8nRkfqmVkuHK5AoPgAwxkLWtbD/K1rhvSxGzx1qCPKdTyA68djX5I 4VgA== MIME-Version: 1.0 X-Received: by 10.107.11.26 with SMTP id v26mr5397886ioi.8.1432839626090; Thu, 28 May 2015 12:00:26 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Thu, 28 May 2015 12:00:26 -0700 (PDT) In-Reply-To: References: <5564b545.0287440a.5871.7050@mx.google.com> Date: Thu, 28 May 2015 12:00:26 -0700 X-Google-Sender-Auth: EjVM6HuJqGj78gQ42nWqKbal6is Message-ID: Subject: Re: Performance issues with Intel Fortville (XL710/ixl(4)) From: Adrian Chadd To: "Lewis, Fred" Cc: "Sundararajan, Lakshmi" , "Pokala, Ravi" , "freebsd-net@freebsd.org" , "jfv@freebsd.org" , "erj@freebsd.org" , "freebsd-hackers@freebsd.org" 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, 28 May 2015 19:00:27 -0000 Hi, I've no plans to MFC the RSS stuff to stable/10 - there's still RSS work that needs to happen in -HEAD and it will likely change the ioctls and kernel API a little. I'd really appreciate help on developing the RSS stuff in -HEAD so we can call it done and merge it back. Thanks, -adrian From owner-freebsd-net@FreeBSD.ORG Thu May 28 19:02: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 C3219E68 for ; Thu, 28 May 2015 19:02:31 +0000 (UTC) (envelope-from babak@farrokhi.net) 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 A21B327B for ; Thu, 28 May 2015 19:02:30 +0000 (UTC) (envelope-from babak@farrokhi.net) Received: from swordfish.local (unknown [31.59.219.188]) (Authenticated sender: babak@farrokhi.net) by mail.imenpardis.com (Postfix) with ESMTPA id 1574134CD66; Thu, 28 May 2015 23:32:07 +0430 (IRDT) Message-ID: <5567662A.9060406@farrokhi.net> Date: Thu, 28 May 2015 23:32:02 +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: <5560C395.8020807@farrokhi.net> <51002FF3-06BF-4CDB-9D78-A25EA15DF263@gmail.com> In-Reply-To: <51002FF3-06BF-4CDB-9D78-A25EA15DF263@gmail.com> 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: Thu, 28 May 2015 19:02:31 -0000 If you are having high interrupt rate, it will be same on latest 10-STABLE. Are you using an unsupported SFP? > Guy Helmer > May 28, 2015 at 6:24 PM >> On May 23, 2015, at 1:14 PM, Babak Farrokhi wrote: >> >> Look at the interrupts per queue. 500,000 is the maximum and it is the reason your interface is not accepting new packets. > > Thanks for the insight. Is there any possible mitigation for this issue? > > Regards, > Guy > >>> 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 >> > > _______________________________________________ > 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 > May 23, 2015 at 10:44 PM > 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 From owner-freebsd-net@FreeBSD.ORG Thu May 28 23:12: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 063F59D4 for ; Thu, 28 May 2015 23:12:25 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BEFE9828 for ; Thu, 28 May 2015 23:12:24 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.200] (p508F01E5.dip0.t-ipconnect.de [80.143.1.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B8EAA1C02FF09 for ; Fri, 29 May 2015 01:12:20 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: No RTM_NEWADDR message generated when adding IPv6 addresses to a tun interface Message-Id: <0590FE39-614E-49D9-AD67-477DFA12630B@lurchi.franken.de> Date: Fri, 29 May 2015 01:12:19 +0200 To: FreeBSD Net 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, 28 May 2015 23:12:25 -0000 Dear all, I'm using a tun interface with the IFF_BROADCAST | IFF_MULTICAST mode. I can use ifconfig to add an IPv4 or IPv6 address. So far so good. I'm running a program which gets all messages from a routing socket. When I'm adding an IPv4 address to the tun interfaces, I receive a RTM_NEWADDR routing message with the added address. However, I do NOT receive one, when I'm adding an IPv6 address. When deleting an IPv4 or IPv6 address, I do receive the corresponding RTM_DELADDR message. Does anyone know why I'm not receiving the RTM_NEWADDR when adding an IPv6 address to a tun interface? If it matters, the above is tested on head... Best regards Michael From owner-freebsd-net@FreeBSD.ORG Thu May 28 23:38:22 2015 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7DB6ADB1 for ; Thu, 28 May 2015 23:38:22 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id AF1441123; Thu, 28 May 2015 23:38:21 +0000 (UTC) (envelope-from ae@FreeBSD.org) Message-ID: <5567A65E.1040505@FreeBSD.org> Date: Fri, 29 May 2015 02:35:58 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julian Kornberger , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> <5567248B.1040207@tzi.de> In-Reply-To: <5567248B.1040207@tzi.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2S183d0olNj4ujAG6s3lJW1XeQs8uNoxk" 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, 28 May 2015 23:38:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2S183d0olNj4ujAG6s3lJW1XeQs8uNoxk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 28.05.2015 17:22, Julian Kornberger wrote: > Am 28.05.2015 um 15:59 schrieb Andrey V. Elsukov:> Can you enable > dumpon(8) in your rc.conf, then get the crash dump and >> show content of your /var/crash/core.txt.N file? >> >> Also can you try this module instead of one from your base system? >> https://people.freebsd.org/~ae/gre-10.tgz >> >> This is ported to stable/10 version from 11.0-CURRENT. >> >=20 > I already have some crash logs: > http://91.202.42.216/ >=20 > Some are with and some are without dummynet. The actual panic occurs when ip_output() does RO_RTFREE() to cached route owned by gre(4). #7 0xffffffff80a58105 in ip_output (m=3D0xfffff800054bb000, opt=3D, flags=3D, imo=3D, inp=3D0x0) at /usr/src/sys/netinet/ip_output.c:218 #8 0xffffffff81a15797 in gre_output (ifp=3D0xfffff80005a33000, m=3D, dst=3D, ro=3D) at /usr/src/sys/modules/if_gre/../../net/if_gre.c:509 As I see you have two gre(4) tunnels: gre1: inet 10.9.0.9 --> 10.9.0.8 gre2: inet 10.9.0.11 --> 10.9.0.10 but which addresses do you use as tunnel endpoints? --=20 WBR, Andrey V. Elsukov --2S183d0olNj4ujAG6s3lJW1XeQs8uNoxk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVZ6ZfAAoJEAHF6gQQyKF6fQUH/3VkqfVKmr4dT+SNgkbBiZfM 4W50gT+oeEpKV8B8YL7puseWweeEKJo2LlLjIdiIp9Noz3A+5fV6MXFc4GxfCdTe hrOUmzNibxes57S85J621cNUoj6PKt+/MoK731smu/ZsXUHzM0gWbThmZdWXrZxX V/fX2xw/KxZAIHZwJZnzR0AMFaJvxEdNC6KOVdAiIh1KAkvGfNc8NYYBkQ9mnyly hRRnxTVm/YNy0zUZ8+jY9db0OroVO6U4cR34iUv4PkH3Xnhx8jgVSFJBHGrAdNpI 5brD6nj36GQUW6fjE3ed9NMQ8QqyYkDL77OJYBkzaMmp1B2wUm5F7kFVwMqoFmA= =E/fr -----END PGP SIGNATURE----- --2S183d0olNj4ujAG6s3lJW1XeQs8uNoxk-- From owner-freebsd-net@FreeBSD.ORG Fri May 29 01:13:40 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 3DDCBCE6; Fri, 29 May 2015 01:13:40 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C842114D1; Fri, 29 May 2015 01:13:39 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4T1DYwK003245; Fri, 29 May 2015 03:13:34 +0200 (CEST) Received: from [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e] (p200300556B2BD00030D9F27982B0BE8E.dip0.t-ipconnect.de [IPv6:2003:55:6b2b:d000:30d9:f279:82b0:be8e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lySZk3SfBz8y4K; Fri, 29 May 2015 03:13:34 +0200 (CEST) Message-ID: <5567BD3D.6050205@tzi.de> Date: Fri, 29 May 2015 03:13:33 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> <5567248B.1040207@tzi.de> <5567A65E.1040505@FreeBSD.org> In-Reply-To: <5567A65E.1040505@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; 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: Fri, 29 May 2015 01:13:40 -0000 Am 29.05.2015 um 01:35 schrieb Andrey V. Elsukov: > The actual panic occurs when ip_output() does RO_RTFREE() to cached > route owned by gre(4). > > #7 0xffffffff80a58105 in ip_output (m=0xfffff800054bb000, > opt=, flags=, > imo=, inp=0x0) > at /usr/src/sys/netinet/ip_output.c:218 > #8 0xffffffff81a15797 in gre_output (ifp=0xfffff80005a33000, > m=, dst=, > ro=) > at /usr/src/sys/modules/if_gre/../../net/if_gre.c:509 > > As I see you have two gre(4) tunnels: > > gre1: inet 10.9.0.9 --> 10.9.0.8 > gre2: inet 10.9.0.11 --> 10.9.0.10 > > but which addresses do you use as tunnel endpoints? I am running a VPN server with a single public address. The local tunnel endpoints are private ip addresses: gre1: 192.168.1.3/28 --> 5.9.77.235 (the vpn server address) gre2: 192.168.1.19/28 --> 5.9.77.235 (the vpn server address) Between my FreeBSD machine and the VPN server are NAT routers (192.168.1.1 and 192.168.1.17). I also added a second public ip address to my VPN server to have different public endpoints but it crashes too. I need to use multiple tunnels to load-balance the VPN traffic. -- Julian From owner-freebsd-net@FreeBSD.ORG Fri May 29 01:21: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 8E748DC5; Fri, 29 May 2015 01:21:03 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 65D2A15BB; Fri, 29 May 2015 01:21:02 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 401B95A9F25; Fri, 29 May 2015 01:21:02 +0000 (UTC) Date: Fri, 29 May 2015 01:21:02 +0000 From: Brooks Davis To: d@delphij.net Cc: Patrick Kelsey , hiren panchasara , "freebsd-net@freebsd.org" , delphij@freebsd.org Subject: Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?" Message-ID: <20150529012102.GI38480@spindle.one-eyed-alien.net> References: <20150528045551.GS95600@strugglingcoder.info> <55674C6B.9050700@delphij.net> <20150528171853.GU95600@strugglingcoder.info> <55674FBA.7050204@delphij.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ep0oHQY+/Gbo/zt0" Content-Disposition: inline In-Reply-To: <55674FBA.7050204@delphij.net> 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: Fri, 29 May 2015 01:21:03 -0000 --ep0oHQY+/Gbo/zt0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 28, 2015 at 10:26:18AM -0700, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > On 05/28/15 10:21, Patrick Kelsey wrote: > > Yes, I'll give it a go. I haven't yet done a dry-run to see how > > hairy it might be, so no predictions there. >=20 > Great! Please feel free to ask if you need any help from my side. I'm happy to review or help out as well. The only blocking issue I was aware of was the local pfsync code not being updated to the netdissect API, but I've done that. -- Brooks >=20 > Cheers, >=20 > > Thanks, Patrick > >=20 > > On Thu, May 28, 2015 at 1:18 PM, hiren panchasara <=20 > > hiren@strugglingcoder.info> wrote: > >=20 > >> On 05/28/15 at 10:12P, Xin Li wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > >>>=20 > >>> Hi, Hiren, > >>>=20 > >>> On 05/27/15 21:55, hiren panchasara wrote: > >>>> On 05/28/15 at 12:40P, Patrick Kelsey wrote: > >>>>> Hi, > >>>>>=20 > >>>>> I've had a patch for a capsicum-related issue in tcpdump > >>>>> sitting around since last September (=20 > >>>>> https://lists.freebsd.org/pipermail/freebsd-current/2014-September > /05 > >>> > >>>>>=20 > 2049.html) > >>>>>=20 > >>>>>=20 > >>> that is still needed and that I want finally address in the > >>> tree (the pa tch > >>>>> was reviewed by rwatson@ and pjd@ back then). > >>>>>=20 > >>>>> This issue was patched separately in the upstream tcpdump > >>>>> sources in February (=20 > >>>>> https://github.com/the-tcpdump-group/tcpdump/commit/887bf88fd058f8 > c0e > >>> > >>>>>=20 > f9a5af1a95b43753e3ad2eb), > >>>>>=20 > >>>>>=20 > >>> along with a refactor of the associated capsicum code, and that > >>> work has > >>>>> been present in tcpdump releases since 4.7.3 (=20 > >>>>> http://www.tcpdump.org/tcpdump-changes.txt). > >>>>>=20 > >>>>> The last tcpdump release imported into the FreeBSD tree was > >>>>> 4.6.2 ( http://svnweb.freebsd.org/base/vendor/tcpdump/). > >>>>>=20 > >>>>> tcpdump release import/merges have recently resulted in > >>>>> some confusion/lost local patches due to the extent of the > >>>>> diffs (e.g., the thread at=20 > >>>>> https://lists.freebsd.org/pipermail/svn-src-head/2015-February/067 > 853 > >>> > >>>>>=20 > .html). > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>> I see three possible ways to proceed: > >>>>>=20 > >>>>> 1. Apply the minimal-local-diff patch from last September > >>>>> to our local tcpdump sources. This seems like it might > >>>>> contribute to a future difficult/lossy tcpdump vendor > >>>>> import/merge. > >>>>>=20 > >>>>> 2. Import tcpdump 4.7.3 or later to address this issue. > >>>>> Are there any reasons why this might not be desired? I > >>>>> don't have a feel for when/why past tcpdump vendor imports > >>>>> have been performed or avoided. > >>>>>=20 > >>>>> 3. Cherry-pick the upstream patch and apply it to our > >>>>> local sources, directly addressing only this issue and > >>>>> avoiding future tcpdump vendor import/merge problems > >>>>> related to this issue. > >>>>>=20 > >>>>> I'm looking for input on the above. If left to my own > >>>>> devices, I'd go with (3). > >>>>=20 > >>>> Latest upstream release is 4.7.4 and the one before that was > >>>> 4.6.2 which we already have in the tree. I think we should > >>>> get latest instead of picking bits and pieces when possible. > >>>>=20 > >>>> CCing Xin for his input as he has been doing last few > >>>> imports. > >>>=20 > >>> Yes, I think we should do the new import. (Are you willing to > >>> do that? I'm doing it only because nobody else were doing > >>> it...) > >>=20 > >> I think Patrick volunteered to do the import. If he can't, I'll > >> do it. > >>=20 > >> Cheers, Hiren > >>=20 > > _______________________________________________=20 > > freebsd-net@freebsd.org mailing list=20 > > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > > unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > >=20 >=20 >=20 > - --=20 > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.1.4 (FreeBSD) >=20 > iQIcBAEBCgAGBQJVZ0+6AAoJEJW2GBstM+nsDfoP/1XiBFyZ0mY1lA6zEj/7BegN > COHHyPWc6BAgGB3uW6aTUNJ417B5udz9MPifG/582G/GzXKBJJiu5/O2eHNJ+e8T > ioIaBt0+hy3+QyoAfa+LiYJ0IwuKErXmZ+CD4LuOZT6itZnru67DWG9voWJYCV+V > RK7Ry585fDDNDE2qNUAZgKUH35OMjmhdGjLlV2wFOhWuo/le/ZasvsRuAMaBq7v8 > NIZNs3QoeyJhhkgLn3427ntDXbmAVm1p62zRdTjbPVYc9Re8JkA8tWzCnEtz04em > lcypZWZRafRvPYUCM9+qLpOpogXsotk1SRlm6QhXt0BZe782btJVgLNIROJPC851 > enV8P2pgI7zudazLjO79Cb56UxAyKRJBxht5bxW3nAxRAB34KIe9018CHhi8nTGl > ZAzOYESYijDUDwG22iskSBUWm4VcRLSXRZmH/+NgKvmrzaPD/L3NAipZ4REqDRkD > Uls2H4kMsKf8IgmZQQF8nonJzg5k73pF37PvA4VHjqnPn3vi6GJfgKQani6oMGpW > nKa9YrCF3z7vD+t1Mifn44+GWN73PZ3OjiHNKi4Sx8nXeSdC412SJo+Rrb/FTWYv > LZ1Joaobl84JXuuogoLkG09yXwm90PsoHHr0OfdPd6DAF67UhUjmd2phEMW3vFHz > R9ZicEtFxm9LeGqmBI9e > =3DwtWn > -----END PGP SIGNATURE----- > _______________________________________________ > 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 --ep0oHQY+/Gbo/zt0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVZ779AAoJEKzQXbSebgfAV/IH/iidF7ivYKnMhotfCg7X5Wvt YvibhrIXP18yVCiAZYcTA+EMXu1Nh9sjW/qWXTsue6HjW+IthHoLg4LJFvdYw8mh ylmOkFxgSMmKPaPXll0oWDkI0o2qiEc5uJcbQL/h+SS2iBCTGWG1Lcv0NN/qsNgY ECG2bTsZfkyq6ShxE+V24tIFcyOvq5iFX7jnJUa0F6KtFI/gs7/eBL8nJxh8COxU Iae6uTQ2t0xQndLLaIkEz1/ltLIVOb/lE3Cn5dtkFdB7M5MRSt8itUCim/lrdJDn L7kOQ03HjGIWionCj8u88F6peo+k1pGyMhxA/9bomd8tFbuXf6UAU1gT2UBfLRk= =E4uf -----END PGP SIGNATURE----- --ep0oHQY+/Gbo/zt0-- From owner-freebsd-net@FreeBSD.ORG Fri May 29 01:21:48 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D83CE5B for ; Fri, 29 May 2015 01:21:48 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 6051465FAF; Fri, 29 May 2015 01:21:47 +0000 (UTC) (envelope-from ae@FreeBSD.org) Message-ID: <5567BE9C.3060203@FreeBSD.org> Date: Fri, 29 May 2015 04:19:24 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julian Kornberger , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> <5567248B.1040207@tzi.de> <5567A65E.1040505@FreeBSD.org> <5567BD3D.6050205@tzi.de> In-Reply-To: <5567BD3D.6050205@tzi.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TFqMI9W7GOwgnveoCTPecoqfr1hO7MbTS" 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, 29 May 2015 01:21:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TFqMI9W7GOwgnveoCTPecoqfr1hO7MbTS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29.05.2015 04:13, Julian Kornberger wrote: > Am 29.05.2015 um 01:35 schrieb Andrey V. Elsukov: >> The actual panic occurs when ip_output() does RO_RTFREE() to cached >> route owned by gre(4). >> >> #7 0xffffffff80a58105 in ip_output (m=3D0xfffff800054bb000, >> opt=3D, flags=3D, >> imo=3D, inp=3D0x0) >> at /usr/src/sys/netinet/ip_output.c:218 >> #8 0xffffffff81a15797 in gre_output (ifp=3D0xfffff80005a33000, >> m=3D, dst=3D, >> ro=3D) >> at /usr/src/sys/modules/if_gre/../../net/if_gre.c:509 >> >> As I see you have two gre(4) tunnels: >> >> gre1: inet 10.9.0.9 --> 10.9.0.8 >> gre2: inet 10.9.0.11 --> 10.9.0.10 >> >> but which addresses do you use as tunnel endpoints? >=20 > I am running a VPN server with a single public address. > The local tunnel endpoints are private ip addresses: >=20 > gre1: 192.168.1.3/28 --> 5.9.77.235 (the vpn server address) > gre2: 192.168.1.19/28 --> 5.9.77.235 (the vpn server address) >=20 > Between my FreeBSD machine and the VPN server are NAT routers > (192.168.1.1 and 192.168.1.17). I also added a second public ip address= > to my VPN server to have different public endpoints but it crashes too.= >=20 > I need to use multiple tunnels to load-balance the VPN traffic. Did you try gre module from the 11.0-CURRENT? If it works for you, with stock module you can try to set link1 to both gre(4) interfaces. I think it will help. --=20 WBR, Andrey V. Elsukov --TFqMI9W7GOwgnveoCTPecoqfr1hO7MbTS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVZ76cAAoJEAHF6gQQyKF6ljkH/Rv8Fi2Vc8Lx73GTFuUKH1Ee ieVazkRvoJRIHVu+EMRZAoxqqFow3St7ZzU4npDqMMLae+byxDDd+tsvl9QGJvcy Zh/zPfspALiipj3fjLyNkARqtE1YQoOj+02nlMWZbAyYbxwfcxt6S26l5mnE5QEP gwxnvFSUB4Z8n/TTHe/GUIYk9J+GPnQaf+MNvd+o7K6Y1qoBlOicACBMxwgv9Roc ddNj+lUDkdgEOo0UgbmcqFmufJdZTv1N4Goyt1cIoBZ4px1KCeuH30DRs1d5BU0z 1fWjIPm/0WR59N/dyH6J3hlUYWNV2FjE2w1IzrUumrqOiRWAO9Wz1s40cPAOMXk= =BZl7 -----END PGP SIGNATURE----- --TFqMI9W7GOwgnveoCTPecoqfr1hO7MbTS-- From owner-freebsd-net@FreeBSD.ORG Fri May 29 13:26:33 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 021C0596 for ; Fri, 29 May 2015 13:26:33 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 724101E0C for ; Fri, 29 May 2015 13:26:31 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t4TDQQpG011097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2015 16:26:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t4TDQQvY011096; Fri, 29 May 2015 16:26:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 29 May 2015 16:26:26 +0300 From: Gleb Smirnoff To: "Eugene M. Zheganin" Cc: freebsd-net@freebsd.org Subject: Re: ng_netflow Message-ID: <20150529132626.GS73119@FreeBSD.org> References: <556476EF.1090706@norma.perm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556476EF.1090706@norma.perm.ru> 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: Fri, 29 May 2015 13:26:33 -0000 On Tue, May 26, 2015 at 06:36:47PM +0500, Eugene M. Zheganin wrote: E> I'm using ng_netflow along with flow-tools to collect traffic statistics. E> What is bothering me, is that I constantly see lost flow. What is even E> more weird - is that ng_netflow and flow-capture are on the same host, E> and are communication via lo0: Flows can be lost due to buffer overflows in the UDP socket, in the interface queue, in the network itself. That's nature of UDP. E> May 26 18:33:16 balancer1 flow-capture[67265]: ftpdu_seq_check(): E> src_ip=127.0.0.1 dst_ip=49.51.57.55 d_version=5 expect E> ing=2033661856 received=2033666446 lost=4590 E> May 26 18:33:17 balancer1 flow-capture[67265]: ftpdu_seq_check(): E> src_ip=127.0.0.1 dst_ip=0.0.0.0 d_version=5 expecting= E> 2033666446 received=2033666476 lost=30 E> May 26 18:33:17 balancer1 flow-capture[67265]: ftpdu_seq_check(): E> src_ip=127.0.0.1 dst_ip=49.52.48.48 d_version=5 expect E> ing=2033461677 received=2033666926 lost=205249 E> May 26 18:33:17 balancer1 flow-capture[67265]: ftpdu_seq_check(): E> src_ip=127.0.0.1 dst_ip=0.0.0.0 d_version=5 expecting= E> 2033666926 received=2033666956 lost=30 E> E> Plus I see weird IPs like "dst_ip=0.0.0.0" or "dst_ip=0.2.0.4". E> Can someone point me what m I doing wrong ? Not sure what traffic can cause that. You need to debug that. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri May 29 13:35:39 2015 Return-Path: Delivered-To: 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 38ADDE8C; Fri, 29 May 2015 13:35:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A65BC10A7; Fri, 29 May 2015 13:35:38 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t4TDZZvX011218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2015 16:35:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t4TDZZHq011217; Fri, 29 May 2015 16:35:35 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 29 May 2015 16:35:35 +0300 From: Gleb Smirnoff To: current@FreeBSD.org, net@FreeBSD.org Subject: [Testers needed!] WiFi drivers changes Message-ID: <20150529133535.GT73119@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Fri, 29 May 2015 13:35:39 -0000 Hi! As part of the "opaque ifnet project" [1], we are doing some code shake with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent interface for the wlan(4) interface. The core idea is that parent device loses its ifnet(9) structure. The code is already complete for the stack, but only 2 drivers are converted to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes are quite mechanical, but nevertheless testing is required before committing. So, if you run FreeBSD head and wlan(4), please sign up here as tester: https://wiki.freebsd.org/projects/ifnet/net80211 As soon as I see testers there, I will start converting more drivers. For those who want to review the patch, or even help with converting, you are welcome here: https://reviews.freebsd.org/D2655 Waiting for your feedback :) [1] https://wiki.freebsd.org/projects/ifnet -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri May 29 13:40: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 625373A9 for ; Fri, 29 May 2015 13:40:38 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 270BC1163 for ; Fri, 29 May 2015 13:40:38 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.1.200] (p508F01E5.dip0.t-ipconnect.de [80.143.1.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9CAB1200C0100 for ; Fri, 29 May 2015 15:40:35 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: No RTM_NEWADDR message generated when adding IPv6 addresses to a tun interface From: Michael Tuexen In-Reply-To: <0590FE39-614E-49D9-AD67-477DFA12630B@lurchi.franken.de> Date: Fri, 29 May 2015 15:40:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <145CC3C4-41BB-4CB3-89ED-3631761BE0B6@lurchi.franken.de> References: <0590FE39-614E-49D9-AD67-477DFA12630B@lurchi.franken.de> To: FreeBSD Net 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: Fri, 29 May 2015 13:40:38 -0000 > On 29 May 2015, at 01:12, Michael Tuexen = wrote: >=20 > Dear all, >=20 > I'm using a tun interface with the IFF_BROADCAST | IFF_MULTICAST mode. > I can use ifconfig to add an IPv4 or IPv6 address. So far so good. >=20 > I'm running a program which gets all messages from a routing socket. > When I'm adding an IPv4 address to the tun interfaces, I receive > a RTM_NEWADDR routing message with the added address. However, I > do NOT receive one, when I'm adding an IPv6 address. > When deleting an IPv4 or IPv6 address, I do receive the corresponding > RTM_DELADDR message. >=20 > Does anyone know why I'm not receiving the RTM_NEWADDR when adding > an IPv6 address to a tun interface? >=20 > If it matters, the above is tested on head... Just for the records: The issue was fixed in https://svnweb.freebsd.org/changeset/base/283696 Best regards Michael >=20 > Best regards > Michael > _______________________________________________ > 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 29 15:15:19 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 C8BD075F; Fri, 29 May 2015 15:15:19 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D15219C6; Fri, 29 May 2015 15:15:18 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.9/8.14.9) with ESMTP id t4TFE62e008520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2015 23:14:07 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.9/8.14.9/Submit) id t4TFE6ft008519; Fri, 29 May 2015 23:14:06 +0800 (CST) (envelope-from kevlo) Date: Fri, 29 May 2015 23:14:05 +0800 From: Kevin Lo To: Gleb Smirnoff Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: [Testers needed!] WiFi drivers changes Message-ID: <20150529151405.GA8509@ns.kevlo.org> References: <20150529133535.GT73119@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150529133535.GT73119@glebius.int.ru> 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: Fri, 29 May 2015 15:15:19 -0000 On Fri, May 29, 2015 at 04:35:35PM +0300, Gleb Smirnoff wrote: > > Hi! Hi Gleb, > As part of the "opaque ifnet project" [1], we are doing some code shake > with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent > interface for the wlan(4) interface. Thanks for putting the effort into making this happen. :) > The core idea is that parent device loses its ifnet(9) structure. The > code is already complete for the stack, but only 2 drivers are converted > to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes > are quite mechanical, but nevertheless testing is required before committing. > > So, if you run FreeBSD head and wlan(4), please sign up here as tester: > > https://wiki.freebsd.org/projects/ifnet/net80211 > > As soon as I see testers there, I will start converting more drivers. > > For those who want to review the patch, or even help with converting, > you are welcome here: > > https://reviews.freebsd.org/D2655 > > Waiting for your feedback :) I have a bunch of usb wifi dongles, I would like to help with converting. > [1] https://wiki.freebsd.org/projects/ifnet > > -- > Totus tuus, Glebius. Kevin From owner-freebsd-net@FreeBSD.ORG Fri May 29 15:35:15 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 AF067DF9; Fri, 29 May 2015 15:35:15 +0000 (UTC) (envelope-from juliank@tzi.de) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailhost.informatik.uni-bremen.de", Issuer "Universitaet Bremen CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44D8C1E98; Fri, 29 May 2015 15:35:14 +0000 (UTC) (envelope-from juliank@tzi.de) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t4TFZADx019362; Fri, 29 May 2015 17:35:10 +0200 (CEST) Received: from [IPv6:2001:470:7408:0:e0b3:734a:3c56:58e9] (unknown [IPv6:2001:470:7408:0:e0b3:734a:3c56:58e9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lyqht3TTLz2csS; Fri, 29 May 2015 17:35:10 +0200 (CEST) Message-ID: <5568872D.8050908@tzi.de> Date: Fri, 29 May 2015 17:35:09 +0200 From: Julian Kornberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , "net@freebsd.org" Subject: Re: Crash with GRE und IPFW fwd References: <5566565A.7030200@tzi.de> <55671F25.5070308@FreeBSD.org> <5567248B.1040207@tzi.de> <5567A65E.1040505@FreeBSD.org> <5567BD3D.6050205@tzi.de> <5567BE9C.3060203@FreeBSD.org> In-Reply-To: <5567BE9C.3060203@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; 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: Fri, 29 May 2015 15:35:15 -0000 Am 29.05.2015 um 03:19 schrieb Andrey V. Elsukov: > Did you try gre module from the 11.0-CURRENT? If it works for you, with > stock module you can try to set link1 to both gre(4) interfaces. I think > it will help. I will test the backported GRE module next week. Setting the link1 flag does not help - it still crashes. -- Julian From owner-freebsd-net@FreeBSD.ORG Sat May 30 02:27: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 9FDE6D92 for ; Sat, 30 May 2015 02:27:03 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [191.243.120.163]) (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 51B531F66 for ; Sat, 30 May 2015 02:27:03 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 8C9A430FC30 for ; Fri, 29 May 2015 23:26:20 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1432952779; x=1433816780; bh=RRrbIBenaJ0dmBOf3aWajP/H+tSS+BC2oPW IPQPpX/0=; b=cV9nTzTd+Stiglc1eKluKOUWEhT1Wl8394SLZPwMgwivlZJiMBI 87UdvO8ILK749MyLy2re6eCik1/OdQrfBIT+Q/WArkbt5v5j8yoO3dsuSg8CG1l+ B5hXmkYpgasSaZ9S91DJ5Dop5dOTuJlfTDggJgFi6b+D8WBDlxr/XxL4= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv7EFld_ypQG for ; Fri, 29 May 2015 23:26:19 -0300 (BRT) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 6CFBA30FC08 for ; Fri, 29 May 2015 23:26:19 -0300 (BRT) Message-ID: <55691FB6.5090307@bsdinfo.com.br> Date: Fri, 29 May 2015 23:25:58 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets References: <5560C395.8020807@farrokhi.net> <5564852D.8040008@bsdinfo.com.br> <1FB15FA4-6185-4206-9517-AE9667A1A57C@gmail.com> In-Reply-To: <1FB15FA4-6185-4206-9517-AE9667A1A57C@gmail.com> 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: Sat, 30 May 2015 02:27:03 -0000 On 28-05-2015 11:14, Guy Helmer wrote: >> On May 26, 2015, at 9:37 AM, Marcelo Gondim wrote: >> >> On 23-05-2015 15:14, Babak Farrokhi wrote: >>> 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: >>>> >>>> . . . >> Hi, >> >> I had this problem and one day updated the system 10.1- RELEASE to 10.1- STABLE and the problem stopped. I was one years with this problem and a script running and testing the interface when the interface stopped working I was doing exactly what you did. Today I no longer have that problem anymore. >> >> I'm using 10.1-STABLE r281235 > > Thanks for the indication of success with 10.1-STABLE. I am locked into using FreeBSD 9.x until I can go through the whole integration and acceptance testing cycle for 10.x, so I’m trying to find a solution that works on in 9.x. I have reviewed the diffs between 9.3 and 10.1-STABLE for ixgbe driver and haven’t noticed anything that stands out. > Guy, I may be wrong but I think the change was not the ixgbe driver. From owner-freebsd-net@FreeBSD.ORG Sat May 30 09:31: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 C0C2261E for ; Sat, 30 May 2015 09:31:47 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) Received: from nm11-vm5.access.bullet.mail.gq1.yahoo.com (nm11-vm5.access.bullet.mail.gq1.yahoo.com [216.39.63.129]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 853A41E00 for ; Sat, 30 May 2015 09:31:47 +0000 (UTC) (envelope-from mueller6724@bellsouth.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bellsouth.net; s=s2048; t=1432977899; bh=l5BSnFHJoHttLg2zfCDwaly/o4GhxNkrHo3tszCS21g=; h=Date:From:To:CC:Subject:References:From:Subject; b=iR6OTY1PxiedRNKNn5+eFA57XB7jFnhhwYq/v4Mbxv7Qmqjkm0TJZjh2RqzgBXKP1DjKLOz042T1MIv+FTqE1q/WjCrrbdy5QmTjiIKo8qsnjS56RV0m/3EycjsJHex0dS2qsVuUfrGJsZ6rtX25rAJjbCXBgXwFgbQpQ5A7IWCUuI96JaKN2ixFwiT3O7z707LliP/ZQbMBvoIWhh1T05cu5lDvafeS3LQJp7qpEm1m+rNaY4VDlZNWPPwO6oD5dQzdilXGk5lzcKVQ9SW9DGHMaj4BCSDGW2GzhmYdELBzOQ7r1G7XPGiH+JsBW/kKGYwBqQakoYGdpYXoQ0B5wg== Received: from [216.39.60.171] by nm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2015 09:24:59 -0000 Received: from [98.138.104.100] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2015 09:24:59 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 30 May 2015 09:24:59 -0000 X-Yahoo-Newman-Id: 629172.74920.bm@smtp120.sbc.mail.ne1.yahoo.com Message-ID: <629172.74920.bm@smtp120.sbc.mail.ne1.yahoo.com> X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YMtQ5lUVM1mrXH3gBWtNMFKDN9KNeqDo9JwLQOr4.LFo9xr A5M5Wjp7ijdMW.Umd4UvULBm05omHcome4BZu5HQvF4oRoefG1PFZnMCnimo BTHmGvoOQsVN_Ph5SwmAYSGX_S2mgWaLhchQp6kGqAz1mx3YkD2XGub7jLhS jXepuo2oQLRuzUJr9GWyW8qOf9hmKh.kwTqptap1H4xB4c9GkqF5ytepRLvq avchQKhOE.BGZxfD4vnGDoKDycTk3ftjZaRooQQ7p2GHiwrVhN75bD0gqXfr Bu5KKqnCFJiMi5JAKTWVhFtw5BM51Ti2a6HGVQxzdfqsr0FpgV849owz4ZFE eJIXMcBDLs5TQVDJrtUehHokNfFsT7Io6xKf4o9LqvLTab31fghOOuFJkgxb .o0Esnyct8SMl4f8MtdStFTuvQr9oEQZ_ttFrPpk07OkYtQgcsg.qoUu7F0u .hsU3L8_dykglz3870UFvK5Nfe.xLQaYeVr1siaUcf65ZC5lU8Ne9JMj2iVk 1KsnVKzbfWo3BLfQDZSXt5rkiO2jyU9_RUILCFUA.6LrvFbvUOkl3bcg- X-Yahoo-SMTP: Kz_aW1.swBBYof3zAD7.RWzXz9ZAQVDMml1VADsbgPT4Kq79LC0- Date: Sat, 30 May 2015 09:24:42 +0000 From: "Thomas Mueller" To: freebsd-current@freebsd.org CC: freebsd-net@freebsd.org Subject: Re: [Testers needed!] WiFi drivers changes References: <20150529133535.GT73119@glebius.int.ru> 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, 30 May 2015 09:31:47 -0000 > As part of the "opaque ifnet project" [1], we are doing some code shake > with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent > interface for the wlan(4) interface. > The core idea is that parent device loses its ifnet(9) structure. The > code is already complete for the stack, but only 2 drivers are converted > to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes > are quite mechanical, but nevertheless testing is required before committing. > So, if you run FreeBSD head and wlan(4), please sign up here as tester: > https://wiki.freebsd.org/projects/ifnet/net80211 > As soon as I see testers there, I will start converting more drivers. > For those who want to review the patch, or even help with converting, > you are welcome here: > https://reviews.freebsd.org/D2655 > Waiting for your feedback :) > [1] https://wiki.freebsd.org/projects/ifnet > Totus tuus, Glebius. There are two I could test: athn and rsu, but neither fits iwn or bwi, and athn is not in FreeBSD src at all. athn is in NetBSD-current and 7.0_BETA, sometimes is able to connect, but usually I get athn0: could not load firmware (35) Always fails with OpenBSD on USB stick (liveusb-openbsd.sourceforge.net), also fails with kernels from OpenBSD 5.5, 5.6 and 5.7 as does Ethernet (re); no success with rsu either in OpenBSD. I see on the website that sys/dev/re was tested. I notice, since the most recent change (2015-04-09) in sys/dev/re, that this Ethernet now works for me on new computer where it didn't before: MSI Z77 MPOWER motherboard. Also, the latest fix (2015-01-05) to sys/dev/usb/wlan/if_rsu.c seems to make Hiro H50191 USB WLAN adapter work again. This success is on current amd64 and i386; no such success on FreeBSD 10.1-STABLE. But my installed ports date to last July 26; I installed lang/gcc-aux last August 17; started updating last May 12 but hit a snag on the png update reverse dependencies, now am starting over on a new GPT partition while preserving the old (current amd64). Tom From owner-freebsd-net@FreeBSD.ORG Sat May 30 17:50: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 76BF0C84 for ; Sat, 30 May 2015 17:50:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 606D31AE5 for ; Sat, 30 May 2015 17:50:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4UHoQq9068960 for ; Sat, 30 May 2015 17:50:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Sat, 30 May 2015 17:50: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 Only Me X-Bugzilla-Who: david.keller@litchis.fr 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, 30 May 2015 17:50:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #16 from david.keller@litchis.fr --- Since freebsd-update 10.1-RELEASE-p6 -> p9, no freeze happened. Even after hours running iperf. That's quite strange as nothing new happened on e1000 since p6. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat May 30 19:23:59 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 6C96FFCB for ; Sat, 30 May 2015 19:23:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 56E451074 for ; Sat, 30 May 2015 19:23:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4UJNxtT077403 for ; Sat, 30 May 2015 19:23:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199174] em tx and rx hang Date: Sat, 30 May 2015 19:23:59 +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: sbruno@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: 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, 30 May 2015 19:23:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 --- Comment #17 from Sean Bruno --- (In reply to david.keller from comment #16) Its still happening on -current from what I can see in my testing. At least with MSI enabled. I'll push a patch that the Intel devs and I are working on after some verification. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat May 30 20:18: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 D04DDBD4 for ; Sat, 30 May 2015 20:18:42 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 555DC1BA0 for ; Sat, 30 May 2015 20:18:41 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: by labko7 with SMTP id ko7so73351630lab.2 for ; Sat, 30 May 2015 13:18:33 -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:content-transfer-encoding:message-id:references :to; bh=2Suk7kb+VXma22UsAJpvebnSU7q++4fb7KfZCLpeeL0=; b=HkItZXAzu/9P2EKB2biiJxKvscGuT+5JMEgDV9WPvnAJSzBJtoOC/eng/b3CenbdKn Ec8WKOMqkgFPclTdvd2rial0wm2ZGwiYvP/Bm0kSW9MsHNhtR5/gSt4ltI0oU9y+HKbS z4AQtwuweqL8yIEnoqhIECuOlRelPMMMszsVkv+TftaqDKiXSnAQT+Kti5H2ZFnPbr9c UrEQPsYZEDa7ebWsoL8A6a9f5JnM/ld4xSrw95uawYTdyEXXPb+daozZl318VqbQky82 5hvAiHSHEWlB25uDiVy8bMzqmOSB8ObH94y/z6nbCe/TynwCaP45UlANnGI6lPIqAhKP XBbg== X-Gm-Message-State: ALoCoQmsXow1nn6dJus7o+hZpq+KoXRz7yJSPNGbgWjgmHDMGSGmk/ShoCSfovCAaG7jceDwRMy9 X-Received: by 10.112.124.71 with SMTP id mg7mr13776197lbb.38.1433013757007; Sat, 30 May 2015 12:22:37 -0700 (PDT) Received: from grey.home.unixconn.com (h-75-17.a183.priv.bahnhof.se. [46.59.75.17]) by mx.google.com with ESMTPSA id df8sm2574878lac.3.2015.05.30.12.22.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 May 2015 12:22:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: [Bug 199174] em tx and rx hang From: mxb In-Reply-To: Date: Sat, 30 May 2015 21:22:34 +0200 Cc: freebsd-net@FreeBSD.org Content-Transfer-Encoding: 7bit Message-Id: References: To: bugzilla-noreply@freebsd.org 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: Sat, 30 May 2015 20:18:42 -0000 Linux-like BSD. Sorry, could not resist. /troll > On 30 maj 2015, at 19:50, bugzilla-noreply@freebsd.org wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199174 > > --- Comment #16 from david.keller@litchis.fr --- > Since freebsd-update 10.1-RELEASE-p6 -> p9, no freeze happened. > > Even after hours running iperf. > > That's quite strange as nothing new happened on e1000 since p6. > > -- > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > 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"