From owner-freebsd-net@FreeBSD.ORG Sun Dec 22 07:32:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B0C4B46; Sun, 22 Dec 2013 07:32:00 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF7D1760; Sun, 22 Dec 2013 07:32:00 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MY700FBP3GWF220@st11p09mm-asmtp002.mac.com>; Sun, 22 Dec 2013 06:31:53 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2013-12-22_01:2013-12-20,2013-12-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1312210300 From: Kimmo Paasiala Content-type: multipart/signed; boundary="Apple-Mail=_F303736B-0ABC-4FEB-9FC9-0910C548159A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-id: <54BF5D3A-8211-4D50-B453-A6301909CBDB@icloud.com> MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: gifconfig_gifX not working with cloned_interfaces? Date: Sun, 22 Dec 2013 08:31:38 +0200 References: <3688B949-7F3B-47FE-8C6A-193805AE2B27@icloud.com> To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org In-reply-to: <3688B949-7F3B-47FE-8C6A-193805AE2B27@icloud.com> X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 22 Dec 2013 07:32:00 -0000 --Apple-Mail=_F303736B-0ABC-4FEB-9FC9-0910C548159A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21.12.2013, at 22.27, Kimmo Paasiala wrote: > FreeBSD 10.0-RC2 r259413 i386. >=20 > I have this set up in rc.conf: >=20 > cloned_interfaces=3D"gif0" > gifconfig_gif0=3D"88.xxx.xxx.xxx 62.yyy.yyy.yyy" > ifconfig_gif0_ipv6=3D"inet6 2001:14b8:aaa:bbb::2 2001:14b8:aaa:bbb::1 = prefixlen 128=94 >=20 > I=92m not using gif_interfaces=3D=93gif0=94 since it=92s deprecated as = per the warning messages spewed by the rc(8) scripts. >=20 > However this does not work properly The =91ifconfig gif0 tunnel = 88.xxx.xxx.xxx 62.yyy.yyy.yyy=92 does not get executed. It looks to me = that the tunnel set up is only performed when gif0 is listed in = gif_interfaces. >=20 > I can work around this by doing this instead of the 'gifconfig_gif0' = line: >=20 > ifconfig_gif0=3D=93 tunnel 88.xxx.xxx.xxx 62.yyy.yyy.yyy=94 >=20 > Should I file a PR about this? >=20 >=20 > -Kimmo I have filed a PR, I feel this is serious enough bug that should be = fixed promptly. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D185080 -Kimmo --Apple-Mail=_F303736B-0ABC-4FEB-9FC9-0910C548159A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJStodPAAoJEFvLZC0FWRVpJPIH/1mPiDYoe9TxwHlZqgsrn+s+ lOik2fGbiKOaaDMgfPemEQL6+sLyjAJQQql5QLKAUHMbfLYRzq2Pr7yX+6TqPT/d 8CStZHhEy+NOxhO3G/FX4YfDmoparKCkHtRLTLGFNMdnr79u6daiYRzdd46eXguj Sc20khwSbhMqqgQCx0tPboK1WnWWEH4oO7GyNLXXkOedDhLEhmRSjkb2gseQ8byo 6UbZ6vzWc75xP11xHqZgAPuuXtTLFu581HNIDZ3pmfHTIgaZBO6SfSY55rNpk+7a Rr+0gr2E+0xZf0njfqRODLw+/B3x5qip42fuTaZxsG3vNj2eVacJGyGl21bGoms= =ly9y -----END PGP SIGNATURE----- --Apple-Mail=_F303736B-0ABC-4FEB-9FC9-0910C548159A-- From owner-freebsd-net@FreeBSD.ORG Sun Dec 22 10:06:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18C59355; Sun, 22 Dec 2013 10:06:17 +0000 (UTC) Received: from st11p09mm-asmtp002.mac.com (st11p09mm-asmtp002.mac.com [17.164.24.97]) by mx1.freebsd.org (Postfix) with ESMTP id DBA0710B6; Sun, 22 Dec 2013 10:06:16 +0000 (UTC) Received: from [10.71.14.16] (dsl-hkibrasgw1-58c380-33.dhcp.inet.fi [88.195.128.33]) by st11p09mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MY70022IDCQDA70@st11p09mm-asmtp002.mac.com>; Sun, 22 Dec 2013 10:05:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2013-12-22_01:2013-12-20,2013-12-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1312220021 Content-type: multipart/signed; boundary="Apple-Mail=_37552862-36B8-464A-8BED-D153161D38A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: gifconfig_gifX not working with cloned_interfaces? From: Kimmo Paasiala In-reply-to: Date: Sun, 22 Dec 2013 12:05:08 +0200 Message-id: References: <3688B949-7F3B-47FE-8C6A-193805AE2B27@icloud.com> To: =?iso-8859-1?Q?Olivier_Cochard-Labb=E9?= X-Mailer: Apple Mail (2.1827) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 22 Dec 2013 10:06:17 -0000 --Apple-Mail=_37552862-36B8-464A-8BED-D153161D38A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 22.12.2013, at 12.01, Olivier Cochard-Labb=E9 = wrote: > On Sat, Dec 21, 2013 at 9:27 PM, Kimmo Paasiala = wrote: > > > > FreeBSD 10.0-RC2 r259413 i386. > > > > I have this set up in rc.conf: > > > > cloned_interfaces=3D"gif0" > > gifconfig_gif0=3D"88.xxx.xxx.xxx 62.yyy.yyy.yyy" > > ifconfig_gif0_ipv6=3D"inet6 2001:14b8:aaa:bbb::2 = 2001:14b8:aaa:bbb::1 prefixlen 128=94 > > > > I=92m not using gif_interfaces=3D=93gif0=94 since it=92s deprecated = as per the warning messages spewed by the rc(8) scripts. > > > > However this does not work properly The =91ifconfig gif0 tunnel = 88.xxx.xxx.xxx 62.yyy.yyy.yyy=92 does not get executed. It looks to me = that the tunnel set up is only performed when gif0 is listed in = gif_interfaces. > > > > I can work around this by doing this instead of the 'gifconfig_gif0' = line: > > > > ifconfig_gif0=3D=93 tunnel 88.xxx.xxx.xxx 62.yyy.yyy.yyy=94 > > >=20 > Hi, >=20 > You can configure gif interface like a standard interface (without = using gifconfig_), here is an example: >=20 > cloned_interfaces=3D"gif0 gif1" > ifconfig_gif0=3D"inet 10.0.24.2/24 10.0.24.4 tunnel 10.0.23.2 = 10.0.34.4 up" > ifconfig_gif1_ipv6=3D"inet6 2001:db8:24::2 prefixlen 64 tunnel = 2001:db8:23::2 2001:db8:34::4 up" >=20 > Regards, >=20 > Olivier Hi, Yes I know. I did note that in my workaround for the problem. However, = the rc.conf(5) manual page claims that gifconfig_gifX should still work = and that=92s why I=92m reporting the issue. -Kimmo --Apple-Mail=_37552862-36B8-464A-8BED-D153161D38A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJStrlZAAoJEFvLZC0FWRVpfiMH/ilprchWvjN+9VpNxQq2T1NE 4hywEYh/c0yjEyI6gebMH4P+A5WgT41eZ3T1Wo29fkvZIGiDw0gEbczQXz1RM7mh 5AJU2CF1dlgOiuLAxmCVCt1alFUj9wrzvHcfpKd6heSqOq4u4R/oXZmAygOIBIkF KvpDkA6jGrGRpaNQn/QL+goAlRZtCrIm5+Juw3hLh46FsDagEHmS14ZgrUFbQP7I j+W2J6o676iVZ1vFh+FicvjTP5IHWHzzy4VifZWvj4lthHpay9sUwImHVBLwqHv+ M66QsIXOzsfDftv/ayx4CroOERnmL/N4qOcFyA01/FBIfC4W/fRliqg/4b2pQ/E= =crIx -----END PGP SIGNATURE----- --Apple-Mail=_37552862-36B8-464A-8BED-D153161D38A4-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 23 01:46:50 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A584E10 for ; Mon, 23 Dec 2013 01:46:50 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 141FD19E2 for ; Mon, 23 Dec 2013 01:46:49 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8EC6420C8C for ; Sun, 22 Dec 2013 20:46:43 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 22 Dec 2013 20:46:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=cTM j3nY9UtTmbA3GOwy6QYstHkk=; b=OxmcAQoWHGoCRWEry2l7pzJJ9tfrdL6jjVZ GqobxOWsjjCd2Grhsri7mbYks5pMm/kHZ9dK+mafWniTyiXZ91oCeKYC+6DrGqYY bxIQV/Lrmgmv6QFPYVgzrjD4Jp4w0HKzktKs+r1sPAHq1HOMA+TmgOJpT+OwwJVc 9g3CU0xg= X-Sasl-enc: CO1VJyEWwZvgyBX1vmw7kFCp0+faOZSNBd1PWKP3YEK4 1387763203 Received: from [172.16.1.145] (unknown [68.117.126.78]) by mail.messagingengine.com (Postfix) with ESMTPA id CF80AC00E80; Sun, 22 Dec 2013 20:46:42 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_5BE3EF23-E872-47A9-83D3-41B4A886AD31"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: 10.0-RC1: bad mbuf leak? From: Mark Felder In-Reply-To: Date: Sun, 22 Dec 2013 19:46:41 -0600 Message-Id: References: <1387204500.12061.60192349.19EAE1B4@webmail.messagingengine.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Net , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 23 Dec 2013 01:46:50 -0000 --Apple-Mail=_5BE3EF23-E872-47A9-83D3-41B4A886AD31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 19, 2013, at 2:41, Adrian Chadd wrote: > Hm, try reverting just the em code to that from a 10.0-BETA? Just in > case something changed there? >=20 finally found some free time today to try to look into this. I was = digging into the SVN changelogs of sys/dev/e1000 and couldn't see any = obvious changes that I should revert. Instead I went a different route = and jumped to HEAD/CURRENT. I'm not seeing the mbufs leaking yet. I'll = need another 24 hours to confirm. Hopefully this is a worthwhile clue. = I'm a bit surprised nobody else has reported this type of behavior... = maybe 10 isn't getting the amount of testing we expect? ...or maybe it's = just my lonely, haunted hardware :( --Apple-Mail=_5BE3EF23-E872-47A9-83D3-41B4A886AD31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSt5YBAAoJEJg7ZFAfE+JS4QgIAImK4EQCiDMgvQohGwzqXnEK f6wVu6X3gbS3+FPxMI4btW3GpWLholsRvLhQhbXNXKRU/60UE1P6A5jh3ONTaq24 unt6yJ0GhgjC/aUp+wsJaXIvISPUSUKkBC4tUNXcx1c9Ltwyui8CW6avFIRA6rdk xkCuNczaV2BSp9fmyDpb5FBLvifbbMvvp+CAqZf4QZH1glqjfTOMdYx9IYtRMxiZ 6elxIYGRwz8iHRx/sShqoJCZTWK21fJ5fEjzhPicNKQghfpGHAENFT6GpX/3cVG+ cCLiiDdIAQeuT+jKCS7vXXDSIYfBej6FxBpaa+XF6NpjJoe4iVBqAtUAgHqvUUk= =735b -----END PGP SIGNATURE----- --Apple-Mail=_5BE3EF23-E872-47A9-83D3-41B4A886AD31-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 23 10:16:30 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56C0D754 for ; Mon, 23 Dec 2013 10:16:30 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 12AB11DD7 for ; Mon, 23 Dec 2013 10:16:29 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id la4so2753389vcb.15 for ; Mon, 23 Dec 2013 02:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=ivEhfPzfpgNP6IQojSdOQb6l5KDcacJ80dDBF67yolQ=; b=dFdVab9ObISSrtjSBWLCD1OkONP78lX5f0oBlL2Mx3QgkxEs/8NvjecGVIyGS8B5Zj fhO24V7kiHIIOCZCDgg7O/r0/sXydK5fQ9NfhkU5Bce/LGONsJEOI6+jk7wQ1+2Owfw/ wTmcOZx4/WIbITf7xSO38XMDlsXeK/u7KEEz9z8a5fItusAjpzSqlPk3mvDraXYjoCHS cDQwloAP8MKDZApSSN3X2iZB4bLIgvBsft36vysHhqoxbHzKU6h9O/OdepFuK2/XJEng GJAdQQ06s92+0DT795shmYBzZFvMV3JcYyFa0rGWZm1QvbeD9dso3UuEeEy5Xlj9sxv8 Mbbw== X-Received: by 10.220.159.4 with SMTP id h4mr13017711vcx.1.1387793789159; Mon, 23 Dec 2013 02:16:29 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.123.5 with HTTP; Mon, 23 Dec 2013 02:16:09 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Mon, 23 Dec 2013 11:16:09 +0100 X-Google-Sender-Auth: Hgva0vM6Cy1GbZbXZMbGuzomDEo Message-ID: Subject: Problems with netmap pkt-gen (ip range and packet counter) To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 23 Dec 2013 10:16:30 -0000 Hi, I've got a first problem using IP source/destination range with netmap pkt-gen: Only packet that are using the first IP in the range have a correct checksum. For example with this command declaring only a range of 2 IP addresses as destination: #pkt-gen -f tx -i ix0 -n 10000000 -l 60 -d 2.3.3.1-2.3.3.2 -D a0:36:9f:1e:28:14 -s 1.3.3.1 -w 8 The receiver machine (just on the other side of a cross-over cable) see good packet only if destination IP is 2.3.3.1 (the first of the range) and not 2.3.3.2. [# tcpdump -pni ix0 -c 10 -v tcpdump: listening on ix0, link-type EN10MB (Ethernet), capture size 65535 bytes 09:57:03.986224 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986225 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46) 1.3.3.1.0 > 2.3.3.1.0: UDP, length 18 09:57:03.986226 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986228 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986228 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986229 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986229 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986230 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46, bad cksum 31a8 (->31a7)!) 1.3.3.1.0 > 2.3.3.2.0: UDP, length 18 09:57:03.986231 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 46) 1.3.3.1.0 > 2.3.3.1.0: UDP, length 18 My second problem is with the latest -current version of pkt-gen only: The first time (and only the first time) I'm using the pk-gen in sender mode with a max number of packet (-n option) to send: It doesn't stop and doesn't exit automatically when counter is reached. Example: # pkt-gen -f tx -i ix0 -n 1000000000 -l 60 -d 2.3.3.1:2000-2.3.3.1:4000 -D a0:36:9f:1e:28:14 -s 1.3.3.1 -w 8 extract_ip_range [149] extract IP range from 1.3.3.1 extract_ip_range [196] range is 1.3.3.1:0 to 1.3.3.1:0 extract_ip_range [149] extract IP range from 2.3.3.1:2000-2.3.3.1:4000 extract_ip_range [196] range is 2.3.3.1:2000 to 2.3.3.1:4000 extract_mac_range [203] extract MAC range from a0:36:9f:1e:1e:d8 extract_mac_range [218] a0:36:9f:1e:1e:d8 starts at a0:36:9f:1e:1e:d8 extract_mac_range [203] extract MAC range from a0:36:9f:1e:28:14 extract_mac_range [218] a0:36:9f:1e:28:14 starts at a0:36:9f:1e:28:14 main [1729] mapping 334980 Kbytes Sending on ix0: 4 queues, 1 threads and 1 cpus. 1.3.3.1 -> 2.3.3.1 (a0:36:9f:1e:1e:d8 -> a0:36:9f:1e:28:14) main [1788] Sending 512 packets every 0.000000000 s main [1790] Wait 8 secs for phy reset main [1792] Ready... start_threads [1270] memsize is 327 MB start_threads [1273] nifp flags 0x0 sender_body [901] start sender_body [978] drop copy main_thread [1335] 12754188 pps (12772733 pkts in 1001454 usec) main_thread [1335] 12829290 pps (12854961 pkts in 1002001 usec) main_thread [1335] 12833261 pps (12846107 pkts in 1001001 usec) main_thread [1335] 12833273 pps (12858914 pkts in 1001998 usec) main_thread [1335] 12829813 pps (12849135 pkts in 1001506 usec) main_thread [1335] 12831922 pps (12851093 pkts in 1001494 usec) main_thread [1335] 12835398 pps (12861094 pkts in 1002002 usec) (...) main_thread [1335] 12830105 pps (12850736 pkts in 1001608 usec) main_thread [1335] 12828343 pps (12846187 pkts in 1001391 usec) main_thread [1335] 12823898 pps (13221464 pkts in 1031002 usec) main_thread [1335] 12835396 pps (12848206 pkts in 1000998 usec) main_thread [1335] 12828231 pps (12841085 pkts in 1001002 usec) main_thread [1335] 12831354 pps (12856978 pkts in 1001997 usec) main_thread [1335] 8336696 pps (8345099 pkts in 1001008 usec) main_thread [1335] 0 pps (0 pkts in 1034995 usec) main_thread [1335] 0 pps (0 pkts in 1040276 usec) main_thread [1335] 0 pps (0 pkts in 1063222 usec) main_thread [1335] 0 pps (0 pkts in 1000508 usec) main_thread [1335] 0 pps (0 pkts in 1055996 usec) main_thread [1335] 0 pps (0 pkts in 1063497 usec) main_thread [1335] 0 pps (0 pkts in 1000499 usec) main_thread [1335] 0 pps (0 pkts in 1001006 usec) main_thread [1335] 0 pps (0 pkts in 1014997 usec) ^C => And it continue forever displaying "0 pps" But if I break it and re-start it: it will stop correctly the next times. My hardware is: Intel 10-Gigabit X540-AT on 11.0-CURRENT r259646M. Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Mon Dec 23 11:06:51 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C4EE5B0 for ; Mon, 23 Dec 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 577F811C5 for ; Mon, 23 Dec 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rBNB6poa030074 for ; Mon, 23 Dec 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rBNB6oC2030072 for freebsd-net@FreeBSD.org; Mon, 23 Dec 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Dec 2013 11:06:50 GMT Message-Id: <201312231106.rBNB6oC2030072@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 23 Dec 2013 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host o kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN RealtekŪ 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 472 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 23 19:44:25 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8623B79; Mon, 23 Dec 2013 19:44:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DA17193A; Mon, 23 Dec 2013 19:44:25 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 53058B98F; Mon, 23 Dec 2013 14:44:22 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: IFF_DRV_OACTIVE handling in *_stop() for intel nic drivers ? Date: Mon, 23 Dec 2013 12:23:56 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201312140008.rBE08tnO062920@mail.karels.net> <20131214012308.GB82745@onelab2.iet.unipi.it> In-Reply-To: <20131214012308.GB82745@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201312231223.56698.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 23 Dec 2013 14:44:24 -0500 (EST) Cc: Jack F Vogel , Adrian Chadd , Luigi Rizzo , Mike Karels , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 23 Dec 2013 19:44:25 -0000 On Friday, December 13, 2013 8:23:08 pm Luigi Rizzo wrote: > On Fri, Dec 13, 2013 at 06:08:55PM -0600, Mike Karels wrote: > > > ... OACTIVE by design is racy. We should just not be using it in newer drivers. > > > > > I think the correct thing to do is to just plain ignore setting it ever. > > > > I agree; OACTIVE is totally obsolete for drivers that use if_transmit, > > and not particularly useful for other drivers. It might be time to remove > > OACTIVE, or define it to be 0. (And I added the original IFF_OACTIVE). > > ok thanks for the clarification In particular, it is useless (and AFAIK ignored) if you are using if_transmit. I've fixed it in igb before, has it crept back in? It should only be used in drivers using if_start() when the ifq is full, and cleared when a tx completion interrupt fires. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Dec 23 19:45:22 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6884CD5; Mon, 23 Dec 2013 19:45:22 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D78A199F; Mon, 23 Dec 2013 19:45:22 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rBNJjFma025793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Dec 2013 11:45:16 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rBNJjFfQ025792; Mon, 23 Dec 2013 11:45:15 -0800 (PST) (envelope-from jmg) Date: Mon, 23 Dec 2013 11:45:15 -0800 From: John-Mark Gurney To: Guy Yur Subject: Re: 10.0-RC1: net/mpd5 crashes in NgMkSockNode due to stack alignment on ARM EABI Message-ID: <20131223194515.GS99167@funkthat.com> Mail-Followup-To: Guy Yur , freebsd-arm@freebsd.org, freebsd-net@freebsd.org References: <20131221191552.GE99167@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 23 Dec 2013 11:45:16 -0800 (PST) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 23 Dec 2013 19:45:22 -0000 Guy Yur wrote this message on Sun, Dec 22, 2013 at 00:46 +0200: > On Sat, Dec 21, 2013 at 9:15 PM, John-Mark Gurney wrote: > > Guy Yur wrote this message on Sat, Dec 21, 2013 at 19:24 +0200: > >> I am running 10.0-RC1 on the BeagleBone Black and the net/mpd5 port is > >> crashing in libnetgraph NgMkSockNode due to stack alignment. > >> > >> 10.0-RC1 World and kernel were compiled in a VirtualBox VM running > >> 9.2-RELEASE-p2 i386. > >> clang and ARM_EABI used as the default make options. > >> > >> Added prints in NgMkSockNode show rbuf is aligned on 2-byte and not > >> 4-byte which is needed to access ni->id (a uint32_t). > >> > >> ni = 0xbfffe87a > >> rbuf = 0xbfffe842 > >> sizeof(resp->header) = 56 > >> > >> > >> (gdb) bt > >> #0 0x201529a0 in NgMkSockNode (name=, csp=0xbfffe95c, > >> dsp=0xbfffe958) at /usr/src/lib/libnetgraph/sock.c:134 > >> #1 0x00037b9c in MppcTestCap () at ccp_mppc.c:754 > >> #2 0x0007c1f4 in main (ac=4, av=0xbfffeb90) at main.c:248 > >> #3 0x0000d1b0 in __start (argc=4, argv=0xbfffeb90, env=0xbfffeba4, > >> ps_strings=, obj=, > >> cleanup=) at /usr/src/lib/csu/arm/crt1.c:115 > >> #4 0x203e9dc0 in _thr_ast (curthread=0x200fd000) > >> at /usr/src/lib/libthr/thread/thr_sig.c:265 > >> > >> > >> Putting rbuf in a union with struct ng_mesg sorted the alignment to > >> 4-byte and mpd5 didn't crash. > >> I attached the changes I used to test mpd5 doesn't crash with correct alignment. > > > > The patch looks correct, but lets make sure that the -net people don't > > have an issue with it... > > > > I've reattached Guy's patch for review. > > > > Guy, bug me in a week or so if I haven't committed it, and I will... > > Should I still file a PR? Yes, please. It provides a link from the mailing list to the commit and provides historical reference... > 1. I noticed my patch causes a style bug with the rbuf line now taking > 87 columns. > 2. Since the union now has a ng_mesg struct, the casting to resp can > be skipped and the union member used directly. Thanks for these. > Attached new patch breaking the rbuf line and swapping resp usage with > res.res and &res.res > Maybe a different name than res should be used for the union or the member. Maybe, but at the same time, since you define the union locally, the reader shouldn't be TOO confused... :) > I only tested the new patch compiles for arm.armv6, haven't verified it. Can you please verify it? Even though I agree you didn't change anything w/ the new patch, you'd be surprised what computers think. :) Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Dec 24 16:04:35 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89DA188E; Tue, 24 Dec 2013 16:04:35 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DCB41D67; Tue, 24 Dec 2013 16:04:35 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rBOG4ZqA035063; Tue, 24 Dec 2013 16:04:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rBOG4Z8u035062; Tue, 24 Dec 2013 16:04:35 GMT (envelope-from linimon) Date: Tue, 24 Dec 2013 16:04:35 GMT Message-Id: <201312241604.rBOG4Z8u035062@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/185148: [ip6] [patch] Cleanup ip6_mroute.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 24 Dec 2013 16:04:35 -0000 Old Synopsis: Cleanup ip6_mroute.c New Synopsis: [ip6] [patch] Cleanup ip6_mroute.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 24 16:04:11 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=185148 From owner-freebsd-net@FreeBSD.ORG Tue Dec 24 16:54:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54380879; Tue, 24 Dec 2013 16:54:45 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C45010B1; Tue, 24 Dec 2013 16:54:44 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8F82420AEA; Tue, 24 Dec 2013 11:54:36 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 24 Dec 2013 11:54:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=wBg qbMCKVOSAg8GnSVMI1l4wsAc=; b=q3oFSMBO1vOoZGQZDM6z20u9XaMVl7wXgO7 WlmRQxYSvEgc7FdyWtDydFynan8cBHW/j7iuX4AEVWfQntGNLVHLA+k8W6pmv75Y TV0YY9iTVOpIjxCB6Uueu0woAtBi+rOzBo3P8o9543NXTRO5OEfBncYQuO96+1aK yxuD0IXY= X-Sasl-enc: G2J0QEEnNJUftqZ3SAUXiYBTqWxEnNrjO7n0MKhXEPhd 1387904076 Received: from [172.16.1.145] (unknown [68.117.126.78]) by mail.messagingengine.com (Postfix) with ESMTPA id D800468010F; Tue, 24 Dec 2013 11:54:35 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_B49F6881-C63B-4F0A-8AAE-927A39DE1F15"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: 10.0-RC1: bad mbuf leak? From: Mark Felder In-Reply-To: Date: Tue, 24 Dec 2013 10:54:33 -0600 Message-Id: <3A115E20-3ADB-49BA-885D-16189B97842B@FreeBSD.org> References: <1387204500.12061.60192349.19EAE1B4@webmail.messagingengine.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1827) Cc: FreeBSD Net , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 24 Dec 2013 16:54:45 -0000 --Apple-Mail=_B49F6881-C63B-4F0A-8AAE-927A39DE1F15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 22, 2013, at 19:46, Mark Felder wrote: >=20 > On Dec 19, 2013, at 2:41, Adrian Chadd wrote: >=20 >> Hm, try reverting just the em code to that from a 10.0-BETA? Just in >> case something changed there? >>=20 >=20 > finally found some free time today to try to look into this. I was = digging into the SVN changelogs of sys/dev/e1000 and couldn't see any = obvious changes that I should revert. Instead I went a different route = and jumped to HEAD/CURRENT. I'm not seeing the mbufs leaking yet. I'll = need another 24 hours to confirm. Hopefully this is a worthwhile clue. = I'm a bit surprised nobody else has reported this type of behavior... = maybe 10 isn't getting the amount of testing we expect? ...or maybe it's = just my lonely, haunted hardware :( Ok, I feel safe confirming that 10.0-RCs are not stable on my hardware. = The mbuf problem went away completely when I jumped to head/current. Can someone please suggest what patch I can attempt to back out to fix = this? I'd like to try to assist in fixing this before 10.0-RELEASE = happens or we're going to have some very angry users. --Apple-Mail=_B49F6881-C63B-4F0A-8AAE-927A39DE1F15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSubxJAAoJEJg7ZFAfE+JSOuIH/3vqHEbqTzwGNHDbV7xjvHm3 R0UGLjhI4x/ugT4fQTsbC9IF60fWC5Izm6CIFF8evQmvWXFi/z9Fg2rfv+PhN0WL mFinwT/44Zd92ZjLdI2rriCl6+jxWX5GPW5s1apyZ74xyfS6sQh453k2GBkA2Gpa yq587v0783brms5KwGB6vg0Re8Vv9w4jk24BXro2mEPUgy77gBiV3rKyXth8oBcn piXbSnhwwVVOLzf10iW26XQwvsTKaab7pYPXUjqAXxxKKngp7edvg6s/s99fX+s6 KMoNXx9RzBEUPxpfjh4bYHKFjRj0j0qUSI8MbhjrrgM/o5ksIICNHz7OmE52+cg= =DWmt -----END PGP SIGNATURE----- --Apple-Mail=_B49F6881-C63B-4F0A-8AAE-927A39DE1F15-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 24 19:16:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17E5998A; Tue, 24 Dec 2013 19:16:00 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C712718F9; Tue, 24 Dec 2013 19:15:59 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id vb8so6942742obc.35 for ; Tue, 24 Dec 2013 11:15:59 -0800 (PST) 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 :content-type; bh=RUJAitxP+tQ54kU+5sGTaSa4RYyzRJG2d7fsOfWxTIk=; b=xfbUFFEKiYYsJR5MjIUqbRxx3N4o2TIBYBI6azv7cBYGzbu2P555xo/4BZEIHKVBPs isjwfYlXmZ0cVMb6nNVkpwQaS8Z2nnORR98nKNqJ6XlFtesDOySW7PmjKqcE16K5YIIV +pTWavxpSewPKlaTEUeZLPej8nSBgQcAuddjNhA2ixQGSMU/dBr0kI0Wx4B6tbHfEf1P rrK1XbF0PkBqnn0JxJH9sD/SzyFIazAC0ZkgNU3nQ0LkYy/vtaxwm7LrP8+lTXt0Krom 58ov516yUqUlVfrHIpYFwzRZGFg/wPryfKwjgAbCpvKTgnRp3cxLYOV9OkVPNI8eZPW9 XKpg== MIME-Version: 1.0 X-Received: by 10.60.135.130 with SMTP id ps2mr2705264oeb.46.1387912559005; Tue, 24 Dec 2013 11:15:59 -0800 (PST) Received: by 10.76.20.82 with HTTP; Tue, 24 Dec 2013 11:15:58 -0800 (PST) In-Reply-To: <20131223194515.GS99167@funkthat.com> References: <20131221191552.GE99167@funkthat.com> <20131223194515.GS99167@funkthat.com> Date: Tue, 24 Dec 2013 21:15:58 +0200 Message-ID: Subject: Re: 10.0-RC1: net/mpd5 crashes in NgMkSockNode due to stack alignment on ARM EABI From: Guy Yur To: freebsd-arm@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 24 Dec 2013 19:16:00 -0000 On Mon, Dec 23, 2013 at 9:45 PM, John-Mark Gurney wrote: > Guy Yur wrote this message on Sun, Dec 22, 2013 at 00:46 +0200: >> On Sat, Dec 21, 2013 at 9:15 PM, John-Mark Gurney wrote: >> > Guy Yur wrote this message on Sat, Dec 21, 2013 at 19:24 +0200: >> >> Should I still file a PR? > > Yes, please. It provides a link from the mailing list to the commit and > provides historical reference... > arm/185165 > >> I only tested the new patch compiles for arm.armv6, haven't verified it. > > Can you please verify it? Even though I agree you didn't change anything > w/ the new patch, you'd be surprised what computers think. :) Tested the second patch on the BeagleBone Black, mpd5 is running without crashing. Also tested the changes in a VM running 9.2-RELEASE-p2 i386 with mpd5 running. From owner-freebsd-net@FreeBSD.ORG Wed Dec 25 11:59:48 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9499CB01; Wed, 25 Dec 2013 11:59:48 +0000 (UTC) Received: from golf.bouncedomains.com (golf.bouncedomains.com [103.18.252.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DC1C102C; Wed, 25 Dec 2013 11:59:47 +0000 (UTC) Received: from cpe-124-183-171-215.lns17.ken.bigpond.net.au ([124.183.171.215]:53747 helo=rmbp.bigpond) by golf.bouncedomains.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1VvmEc-0006B2-Pj; Wed, 25 Dec 2013 22:02:42 +1100 From: Mark van der Meulen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: vmstat buckets Message-Id: <4260012E-9911-47AB-88B9-FDCD6748E6EE@fivenynes.com> Date: Wed, 25 Dec 2013 22:02:42 +1100 To: "freebsd-net@freebsd.org" , freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - golf.bouncedomains.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - fivenynes.com X-Get-Message-Sender-Via: golf.bouncedomains.com: authenticated_id: mark@fivenynes.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 25 Dec 2013 11:59:48 -0000 Hi All, I have question about buckets in vmstat -z output which I haven=92t been = able to find an answer for online=85 I have 6 FreeBSD 9 boxes running as routers and they are seeing varying = results in vmstat -z. I=92m interested in understanding what the Buckets = represent/mean and how I can influence usage of them. Some of the routers show 0 free buckets under 64 or 128 Bucket and so I = did some research and haven=92t been able to find out what it means - = most people who have asked online have received an answer that it is = nothing to worry about, which is meaningless to me. It seems that the higher the usage of the router, especially when it is = also running userspace applications the less Bucket availability there = is. Also I found someone speculating it was related to free kernel = memory so that was updated on some routers however I saw little = difference(although not sure if adding it in /etc/sysctl.conf actually = does anything as some haven=92t had the vm.kmem_size value change at = all, despite reboots). Can anyone explain what the buckets (16,32,64,128) do and what they = represent? Also if you know anything about troubleshooting bucket = failures? There doesn=92t appear to be anything useful online despite = many searches. I am aware that it may not have anything to do with the problems I am = seeing, but I would still like to understand. Thanks, Mark = --------------------------------------------------------------------------= ----- Background: I have a number of FreeBSD 9 boxes running as routers in a testing = environment where I am seeing odd latency issues. Most of them have = different hardware and configurations now just to rule out configuration = or hardware issues. What I am seeing is occasional latency increases when routing traffic so = that on the =93client=94 end the experience is like the link has hung = for a split second - this happens for both L2TP/PPPoE clients and plain = ethernet connected clients. I haven=92t been able to identify anything = obvious like fragmentation, mtu issues, etc. The setup is: 3 x Dual Quad Core, 8GB RAM running as LAC & LNS w/ Quagga(BGP, OSPF), = MPD5, Netflow, IPFW Stateless(recently introduced and my problem existed = before filtering was introduced). 3 x Dual Quad Core, 8GB RAM running as Routers w/ Quagga(BGP, OSPF) Router 1 =3D=3D=3D=3D=3D=3D=3D=3D ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 16 Bucket: 152, 0, 198, 2, 198, 0, 0 32 Bucket: 280, 0, 291, 3, 291, 16, 0 64 Bucket: 536, 0, 221, 3, 221, 58, 0 128 Bucket: 1048, 0, 7993, 2, 7993, 505, 0 vm.kmem_size: 4127952896 Router 2(LNS) =3D=3D=3D=3D=3D=3D=3D=3D ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 16 Bucket: 152, 0, 199, 1, 199, 0, 0 32 Bucket: 280, 0, 329, 7, 333, 0, 0 64 Bucket: 536, 0, 241, 4, 248, 57, 0 128 Bucket: 1048, 0, 7960, 2, 9479,1002, 0 vm.kmem_size: 2147483648 Router 3(LNS) =3D=3D=3D=3D=3D=3D=3D=3D ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 16 Bucket: 152, 0, 194, 6, 194, 0, 0 32 Bucket: 280, 0, 325, 11, 325, 20, 0 64 Bucket: 536, 0, 278, 2, 278, 57, 0 128 Bucket: 1048, 0, 8031, 0, 8031, 955, 0 vm.kmem_size: 4127952896 Router 4(LNS) =3D=3D=3D=3D=3D=3D=3D=3D ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 16 Bucket: 152, 0, 197, 3, 197, 0, 0 32 Bucket: 280, 0, 265, 1, 265, 0, 0 64 Bucket: 536, 0, 227, 4, 227, 57, 0 128 Bucket: 1048, 0, 7824, 0, 7824, 721, 0 vm.kmem_size: 2147483648 Router 5 =3D=3D=3D=3D=3D=3D=3D=3D ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 16 Bucket: 152, 0, 204, 21, 204, 0, 0 32 Bucket: 280, 0, 313, 9, 313, 1, 0 64 Bucket: 536, 0, 268, 5, 268, 57, 0 128 Bucket: 1048, 0, 9204, 0, 9204,5723, 0 vm.kmem_size: 4127952896 Router 6 =3D=3D=3D=3D=3D=3D=3D=3D ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP 16 Bucket: 152, 0, 80, 20, 80, 0, 0 32 Bucket: 280, 0, 86, 12, 86, 0, 0 64 Bucket: 536, 0, 49, 0, 49, 57, 0 128 Bucket: 1048, 0, 8697, 0, 8697,5604, 0 vm.kmem_size: 3108118528 From owner-freebsd-net@FreeBSD.ORG Wed Dec 25 13:33:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC3F04E5; Wed, 25 Dec 2013 13:33:59 +0000 (UTC) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4E716A3; Wed, 25 Dec 2013 13:33:58 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id rBPDXvWE008291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Dec 2013 17:33:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id rBPDXuhb008290; Wed, 25 Dec 2013 17:33:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 25 Dec 2013 17:33:56 +0400 From: Gleb Smirnoff To: Mark Felder Subject: Re: 10.0-RC1: bad mbuf leak? Message-ID: <20131225133356.GL71033@FreeBSD.org> References: <1387204500.12061.60192349.19EAE1B4@webmail.messagingengine.com> <3A115E20-3ADB-49BA-885D-16189B97842B@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A115E20-3ADB-49BA-885D-16189B97842B@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Net , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 25 Dec 2013 13:33:59 -0000 Mark, On Tue, Dec 24, 2013 at 10:54:33AM -0600, Mark Felder wrote: M> > finally found some free time today to try to look into this. I was digging into the SVN changelogs of sys/dev/e1000 and couldn't see any obvious changes that I should revert. Instead I went a different route and jumped to HEAD/CURRENT. I'm not seeing the mbufs leaking yet. I'll need another 24 hours to confirm. Hopefully this is a worthwhile clue. I'm a bit surprised nobody else has reported this type of behavior... maybe 10 isn't getting the amount of testing we expect? ...or maybe it's just my lonely, haunted hardware :( M> M> Ok, I feel safe confirming that 10.0-RCs are not stable on my hardware. The mbuf problem went away completely when I jumped to head/current. M> M> Can someone please suggest what patch I can attempt to back out to fix this? I'd like to try to assist in fixing this before 10.0-RELEASE happens or we're going to have some very angry users. Is it possible for you to bisect head from the stable/10 branchpoint up to the current date and narrow down the revisions that introduced (and later fixed?) the leak? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 07:19:53 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58DE791C for ; Thu, 26 Dec 2013 07:19:53 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B7DFE1846 for ; Thu, 26 Dec 2013 07:19:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA19041 for ; Thu, 26 Dec 2013 09:19:44 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vw5EN-0004me-VK for freebsd-net@freebsd.org; Thu, 26 Dec 2013 09:19:44 +0200 Message-ID: <52BBD857.8040808@FreeBSD.org> Date: Thu, 26 Dec 2013 09:18:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: igb / buf_ring panic: buf already enqueue at X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 07:19:53 -0000 Unread portion of the kernel message buffer: panic: buf=0xfffffe0cfe9a0600 already enqueue at 1259 prod=1260 cons=1259 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:234 #1 0xffffffff808ea32a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0xffffffff808e9b43 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0xffffffff804c5268 in igb_mq_start (ifp=0xfffffe0021566000, m=0xfffffe0cfe9a0600) at buf_ring.h:86 #4 0xffffffff809b6dcd in ether_output_frame (ifp=0xfffffe0021566000, m=0xfffffe0cfe9a0600) at /usr/src/sys/net/if_ethersubr.c:447 #5 0xffffffff809b73ae in ether_output (ifp=0xfffffe0021566000, m=0xfffffe0cfe9a0600, dst=, ro=) at /usr/src/sys/net/if_ethersubr.c:418 #6 0xffffffff80a2726f in ip_output (m=0xfffffe0cfe9a0600, opt=, ro=0xffffff9de0aca700, flags=, imo=0x0, inp=0xfffffe006cb85498) at /usr/src/sys/netinet/ip_output.c:631 #7 0xffffffff80aa4603 in udp_send (so=, flags=, m=, addr=, control=, td=0xfffffe00322b1490) at /usr/src/sys/netinet/udp_usrreq.c:1243 #8 0xffffffff80963575 in sosend_dgram (so=0xfffffe064c9a2000, addr=0x0, uio=0xffffff9de0aca990, top=0xfffffe0cfe9a0600, control=0x0, flags=0, td=0xfffffe00322b1490) at /usr/src/sys/kern/uipc_socket.c:1175 #9 0xffffffff80960c2f in sosend (so=, addr=, uio=, top=, control=, flags=, td=0xfffffe00322b1490) at /usr/src/sys/kern/uipc_socket.c:1408 #10 0xffffffff809468f8 in soo_write (fp=, uio=0xffffff9de0aca990, active_cred=, flags=, td=) at /usr/src/sys/kern/sys_socket.c:102 #11 0xffffffff8093eefc in dofilewrite (td=0xfffffe00322b1490, fd=3, fp=0xfffffe03bec525a0, auio=0xffffff9de0aca990, offset=, flags=0) at file.h:295 #12 0xffffffff809407e4 in kern_writev (td=0xfffffe00322b1490, fd=3, auio=0xffffff9de0aca990) at /usr/src/sys/kern/sys_generic.c:459 #13 0xffffffff80940915 in sys_write (td=, uap=) at /usr/src/sys/kern/sys_generic.c:375 #14 0xffffffff80ce4d2a in amd64_syscall (td=0xfffffe00322b1490, traced=0) at subr_syscall.c:135 #15 0xffffffff80cceb67 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #16 0x0000000800b39bec in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 3 #3 0xffffffff804c5268 in igb_mq_start (ifp=0xfffffe0021566000, m=0xfffffe0cfe9a0600) at buf_ring.h:86 86 panic("buf=%p already enqueue at %d prod=%d cons=%d", (kgdb) list 81 #ifdef DEBUG_BUFRING 82 int i; 83 for (i = br->br_cons_head; i != br->br_prod_head; 84 i = ((i + 1) & br->br_cons_mask)) 85 if(br->br_ring[i] == buf) 86 panic("buf=%p already enqueue at %d prod=%d cons=%d", 87 buf, i, br->br_prod_tail, br->br_cons_tail); 88 #endif 89 critical_enter(); 90 do { (kgdb) p *buf $1 = {b_bufobj = 0x0, b_bcount = 4096, b_caller1 = 0x0, b_data = 0xffffff9c5c600000
, b_error = 0, b_iocmd = 2 '\002', b_ioflags = 2 '\002', b_iooffset = 196608, b_resid = 0, b_iodone = 0, b_blkno = 384, b_offset = 196608, b_bobufs = {tqe_next = 0x0, tqe_prev = 0xfffffe02e5976738}, b_left = 0x0, b_right = 0x0, b_vflags = 2147483648, b_freelist = {tqe_next = 0xffffff9c4d247b70, tqe_prev = 0xffffffff8178a580}, b_qindex = 4, b_flags = 8704, b_xflags = 0 '\0', b_lock = {lock_object = {lo_name = 0xffffffff80fa6026 "bufwait", lo_flags = 108199936, lo_data = 0, lo_witness = 0xffffff8ccd37a500}, lk_lock = 1, lk_exslpfail = 0, lk_timo = 0, lk_pri = 96}, b_bufsize = 0, b_runningbufspace = 0, b_kvabase = 0xffffff9c5c600000
, b_kvaalloc = 0x0, b_kvasize = 16384, b_lblkno = 384, b_vp = 0x0, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0xfffffe02b232b700, b_wcred = 0x0, b_saveaddr = 0xffffff9c5c600000, b_pager = {pg_reqpage = 0}, b_cluster = {cluster_head = {tqh_first = 0x0, tqh_last = 0x0}, cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, b_pages = {0x0 }, b_npages = 0, b_dep = {lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0} (kgdb) p i $2 = 0 (kgdb) p *txr->br $3 = {br_prod_head = 1260, br_prod_tail = 1260, br_prod_size = 4096, br_prod_mask = 4095, br_drops = 1888684, br_prod_bufs = 3286252, _pad0 = {0 }, br_cons_head = 1259, br_cons_tail = 1259, br_cons_size = 4096, br_cons_mask = 4095, _pad1 = {0 }, br_lock = 0xfffffe0011ca6810, br_ring = 0xffffff8ccd8cd100} This is stable/9 with INVARIANTS. Is this something known? If not, is anybody interested? I have the kernel and the vmcore for further investigation. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 07:25:53 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6285AA6; Thu, 26 Dec 2013 07:25:53 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AD92418C0; Thu, 26 Dec 2013 07:25:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA19186; Thu, 26 Dec 2013 09:25:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Vw5KI-0004mx-Dp; Thu, 26 Dec 2013 09:25:50 +0200 Message-ID: <52BBD9C6.5000706@FreeBSD.org> Date: Thu, 26 Dec 2013 09:24:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: Re: igb / buf_ring panic: buf already enqueue at References: <52BBD857.8040808@FreeBSD.org> In-Reply-To: <52BBD857.8040808@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 07:25:53 -0000 on 26/12/2013 09:18 Andriy Gapon said the following: > Unread portion of the kernel message buffer: > panic: buf=0xfffffe0cfe9a0600 already enqueue at 1259 prod=1260 cons=1259 BTW, it's very likely that the panic was triggered by stress2's UDP testing (udp.cfg). -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 07:39:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3A66CC9; Thu, 26 Dec 2013 07:39:09 +0000 (UTC) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54286197D; Thu, 26 Dec 2013 07:39:09 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id 1so7664552qee.38 for ; Wed, 25 Dec 2013 23:39:08 -0800 (PST) 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=5cmISiMwAblv1R/hern9WhbuhJuKORlBwTJa9RepYGQ=; b=xm4LvAmD1AzFQrICsMe4HojnlnUGQl3hy47kpGgzYVz3zEfiAimOS5UonO8HTMyGak Ub8CcaH4JcUKwBcmAl00WeYsPNnrP4hNm44TgnA5EgYfbnp5B7i2gzvA3r2SLSFXg6wZ K6HJ8pQg0oq9LwCcckqSdGmIyP8Cypvw3ZEtfCO1yTTymm7UQTXEzLowepTQtHygtOf5 l62x/44f49O8x9dhQPuB6px8+lrZ2Z9dYSTnLC0XSMPQNM0bkFXEheM8Hpiy/ZDjkhIK b1qnjS6UtTI9SViB3oPfvm7PaBAqI0OPxF0rlhFexsQgYcG4PE7OsqSn61MghLnfI60A AUEA== MIME-Version: 1.0 X-Received: by 10.49.76.66 with SMTP id i2mr70219071qew.35.1388043548523; Wed, 25 Dec 2013 23:39:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.53.200 with HTTP; Wed, 25 Dec 2013 23:39:08 -0800 (PST) In-Reply-To: <52BBD9C6.5000706@FreeBSD.org> References: <52BBD857.8040808@FreeBSD.org> <52BBD9C6.5000706@FreeBSD.org> Date: Wed, 25 Dec 2013 23:39:08 -0800 X-Google-Sender-Auth: RXVWVWskYPYDvzwU0rJO5cIknYY Message-ID: Subject: Re: igb / buf_ring panic: buf already enqueue at From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 07:39:09 -0000 i wonder if this is one of the mbuf leaks people report ... -a On 25 December 2013 23:24, Andriy Gapon wrote: > > on 26/12/2013 09:18 Andriy Gapon said the following: >> Unread portion of the kernel message buffer: >> panic: buf=0xfffffe0cfe9a0600 already enqueue at 1259 prod=1260 cons=1259 > > BTW, it's very likely that the panic was triggered by stress2's UDP testing > (udp.cfg). > > -- > Andriy Gapon > > _______________________________________________ > 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 Dec 26 07:48:20 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B78FE3A; Thu, 26 Dec 2013 07:48:20 +0000 (UTC) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91CC51A2A; Thu, 26 Dec 2013 07:48:19 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id r15so3576106ead.38 for ; Wed, 25 Dec 2013 23:48:18 -0800 (PST) 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=0PVkQjxMuvg4fvqCf6UUVqeVWETCKOqUCp8ESK0bPzU=; b=t1inoTd5jq+BgGkywPP89oqblGvjx/pD+UAqrjgbZpJKvBDrRJ6k1YVfK32Uud8Be4 oP0FdMGVwEdhHMejQ46nfDzfIJUgG/cKoykvyu1mrToJdvK+lKBdBLsPhcLn+QAuVdxC RRTyPsigWxq31rePk3E6Xm2Jx9lg2zITNUZ6qmQIARYT6tb8yaj5g/wkez+tLPx4rBg9 WX9796ZpswYz3rhz4awrSy/mdOs6NH4F0CqwAv/hANe8iuP5Ehx0/uPsNtO2q3CHKIxv Epxhsi/dSb2CRYvU5mUKjrjzcfpP4rjHw8sbYTjb9qOKEL9XUVb4VTD7tjDE4MXIIGXD r0Ww== MIME-Version: 1.0 X-Received: by 10.15.74.200 with SMTP id j48mr5357795eey.102.1388044097907; Wed, 25 Dec 2013 23:48:17 -0800 (PST) Received: by 10.14.2.66 with HTTP; Wed, 25 Dec 2013 23:48:17 -0800 (PST) In-Reply-To: <52BBD857.8040808@FreeBSD.org> References: <52BBD857.8040808@FreeBSD.org> Date: Wed, 25 Dec 2013 23:48:17 -0800 Message-ID: Subject: Re: igb / buf_ring panic: buf already enqueue at From: hiren panchasara To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 07:48:20 -0000 On Wed, Dec 25, 2013 at 11:18 PM, Andriy Gapon wrote: > Unread portion of the kernel message buffer: > panic: buf=0xfffffe0cfe9a0600 already enqueue at 1259 prod=1260 cons=1259 A similar report: http://freebsd.1045724.n5.nabble.com/igb-4-panic-already-enqueue-td5847439.html I think http://svnweb.freebsd.org/base?view=revision&revision=256200 has the fix. cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 11:05:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB65DD4B for ; Thu, 26 Dec 2013 11:05:30 +0000 (UTC) Received: from mail-ie0-x248.google.com (mail-ie0-x248.google.com [IPv6:2607:f8b0:4001:c03::248]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BCDE81647 for ; Thu, 26 Dec 2013 11:05:30 +0000 (UTC) Received: by mail-ie0-f200.google.com with SMTP id at1so36816698iec.3 for ; Thu, 26 Dec 2013 03:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=ZfkK74IalDYnnZU/aEcNz3xmeiIX1cSrkhhlRMZFkM4=; b=wZiLQcDumjbxI15LeZHHIE4aLO/nZ7R8/OcE4oLWB+iBELINHO2s9Se0OmZeEyLre/ oGprveoTek0hEK9fI2HppCWV6Ms3/XPB0FV7FjOs8wkW5ev496P2mL+VqAiHejuwYIUb 5b9BHH30mGldOCrTyupkbx6lN4WYdU6PkV8lFgQ5EH3tz9vHjMgA3u4rbYHRpJE/GopT RuNqUGuA45Qm6onD6rOV4x0uxQ5KUomCof0+k2vpL/aeup+I78bKKOuLlXpjykvee0Y7 Ze0wTYpMM8EzELAytbLFrDM/dLSEmF5lOmBxISL3R4bz26G1QSG8YLmOUW4XfdGK4kND BGBQ== MIME-Version: 1.0 X-Received: by 10.182.87.2 with SMTP id t2mr17284082obz.2.1388055930204; Thu, 26 Dec 2013 03:05:30 -0800 (PST) Message-ID: <089e01537236a5fd5404ee6df4c5@google.com> Date: Thu, 26 Dec 2013 11:05:30 +0000 Subject: Higher Organic traffic From: John Denny To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 11:05:31 -0000 PGRpdiBkaXI9Imx0ciI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzNCwz NCwzNCkiICANCmxhbmc9IkVOLUdCIj5EZWFyIFdlYnNpdGUgTWFuYWdlciw8L3NwYW4+PHNwYW4+ PC9zcGFuPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0KbGFu Zz0iRU4tR0IiPqA8L3NwYW4+PHNwYW4+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZTox MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJnYigzNCwzNCwzNCkiICANCmxhbmc9IkVOLUdCIj5JIGFtIGVtYWlsaW5nIHlvdQ0K dG9kYXkgYmVjYXVzZSBJIGJlbGlldmUgeW91IGFyZSB0aGUgZGVjaXNpb24gbWFrZXIgcmVnYXJk aW5nIHRoZSBidXNpbmVzcw0KcmVwcmVzZW50aW5nIHlvdXIgd2Vic2l0ZSB3aGljaCBJIGNhbWUg YWNyb3NzICANCnJlY2VudGx5Ljwvc3Bhbj48c3Bhbj48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiAgDQpzdHlsZT0iZm9u dC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0KbGFuZz0iRU4tR0IiPqA8L3NwYW4+PHNw YW4+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeSI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzNCwzNCwzNCki ICANCmxhbmc9IkVOLUdCIj5EbyB5b3UgaGF2ZSBhbnkNCmludGVyZXN0IHRvIGFkdmVydGlzZSBv ciBtYXJrZXQgeW91ciBidXNpbmVzcy93ZWJzaXRlIG92ZXIgdGhlIGludGVybmV0IGxpa2UNCnNl YXJjaCBlbmdpbmVzLCBzb2NpYWwgbWVkaWEsIG1vYmlsZXMgZm9yIG1hcmtldGluZyAgDQpwdXJw b3Nlcz88L3NwYW4+PHNwYW4+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OnJnYigzNCwzNCwzNCkiICANCmxhbmc9IkVOLUdCIj6gPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFu ICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1H QiI+SSBvZmZlciB5b3Ugb3VyDQpzZXJ2aWNlcyBpbjqgPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+ DQoNCjx1bCB0eXBlPSJkaXNjIj48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOnJn YigzNCwzNCwzNCkiPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VhcmNoICANCmVuZ2lu ZQ0KICAgICAgb3B0aW1pemF0aW9uLCBpLmUuIGZpbmRpbmcgdGhlIHJpZ2h0IGtleXdvcmQgZm9y IHlvdXIgYnVzaW5lc3MgYW5kDQogICAgICCgZ2V0dGluZyB5b3VyIHdlYnNpdGUgb24gdG9wIG9m IEdvb2dsZS48L3NwYW4+PHNwYW4+PC9zcGFuPjwvbGk+PC91bD4NCg0KPHVsIHR5cGU9ImRpc2Mi PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6cmdiKDM0LDM0LDM0KSI+PHNwYW4g IA0Kc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYWlkICANCmFkdmVydGlzaW5nLQ0KICAgICAgdGhyb3Vn aCBhZHdvcmRzLCBsaW5rZWRJbiAmYW1wOyBmYWNlYm9vayAgDQphZHMuPC9zcGFuPjxzcGFuPjwv c3Bhbj48L2xpPjwvdWw+DQoNCjx1bCB0eXBlPSJkaXNjIj48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOnJnYigzNCwzNCwzNCkiPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ U29jaWFsICANCk1lZGlhIG1hcmtldGluZw0KICAgICAgY2FtcGFpZ25zIGluIHNvY2lhbCBhbmQg cHJvZmVzc2lvbmFsIG5ldHdvcmtzIGxpa2UgZmFjZWJvb2ssIExpbmtlZEluLA0KICAgICAgdHdp dHRlcjwvc3Bhbj48c3Bhbj48L3NwYW4+PC9saT48L3VsPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MC41aW4iPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpyZ2IoMzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1HQiI+oDwvc3Bhbj48c3Bhbj48L3NwYW4+ PC9wPg0KDQo8dWwgdHlwZT0iZGlzYyI+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjpyZ2IoMzQsMzQsMzQpIj48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkN1c3RvbWl6ZWQg IA0Kb25saW5lDQogICAgICBtYXJrZXRpbmcgY2FtcGFpZ25zLCBpLmUuIGFuYWx5emluZyB5b3Vy IGJ1c2luZXNzIG1vZGVsLKBjcmVhdGluZw0KICAgICAgYaBwbGFuIG9mIHByb21vdGlvbiAoQjJC LCBCMkMpICZhbXA7IHN0YXJ0IGdldHRpbmcgeW91IG5ldyAgDQpjdXN0b21lcnMuPC9zcGFuPjxz cGFuPjwvc3Bhbj48L2xpPjwvdWw+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDowLjVpbiI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJnYigzNCwz NCwzNCkiICANCmxhbmc9IkVOLUdCIj6gPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+DQoNCjx1bCB0 eXBlPSJkaXNjIj48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOnJnYigzNCwzNCwz NCkiPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RW1haWwgIA0KTWFya2V0aW5nDQogICAg ICBjYW1wYWlnbnMgdG8gaW5mb3JtIGV4aXN0aW5nIGN1c3RvbWVycyBhYm91dCBuZXcgb2ZmZXJz IG9yIGNvbW11bmljYXRlDQogICAgICB5b3VyIG9mZmVyaW5ncyB0byBuZXcgcGVvcGxlPC9zcGFu PjxzcGFuPjwvc3Bhbj48L2xpPjwvdWw+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZ2Io MzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1HQiI+oDwvc3Bhbj48c3Bhbj48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiAgDQpz dHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0KbGFuZz0iRU4tR0IiPldl IGFyZSBhIGNvbXBsZXRlDQpkaWdpdGFsIG1hcmtldGluZyBmaXJtLiBUaHJvdWdoIGEgcGxhbm5l ZCBtaXggb2Ygd2ViIHByZXNlbmNlICZhbXA7IHdlYg0KcHJvbW90aW9ucywgd2UgY2FuIHNpZ25p ZmljYW50bHkgaW5jcmVhc2UgeW91ciBjdXN0b21lciByZWFjaCB3aXRoaW4gZmV3ICANCm1vbnRo cw0Kb2Ygb3VyIHdvcmsuPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuICANCnN0eWxlPSJmb250LXNp emU6MTBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpyZ2IoMzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1HQiI+oDwvc3Bhbj48c3Bhbj48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0K bGFuZz0iRU4tR0IiPklmIHlvdSBoYXZlDQpjb21tZXJjaWFsIGludGVyZXN0cyB3aXRooDwvc3Bh bj48Yj48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0K bGFuZz0iRU4tR0IiPnlvdXIgd2Vic2l0ZTwvc3Bhbj48L2I+PHNwYW4gIA0Kc3R5bGU9ImZvbnQt c2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOnJnYigzNCwzNCwzNCkiICANCmxhbmc9IkVOLUdCIj4gPC9zcGFuPjxzcGFu ICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1H QiI+b3IgYW55IG90aGVyIHdlYnNpdGUsIHRoZW4geW91IG1pZ2h0IHdhbnQgdG8NCmNvbnNpZGVy IG91ciBhYm92ZSBzZXJ2aWNlcy4gWW91ciBidXNpbmVzcyBvYmplY3RpdmVzIGNhbiBjZXJ0YWlu bHkgYmUNCnByZXNlbnRlZCBiZXR0ZXIgdGhyb3VnaCBnb29kIHdlYiBwcmVzZW5jZSAmYW1wOyBt YXJrZXRpbmcuIEFsc28sIGFzIHRoZSAgDQpudW1iZXINCm9mIG1vYmlsZSBpbnRlcm5ldCB1c2Vy cyBpcyBmYXN0IGluY3JlYXNpbmcsIHlvdXIgd2Vic2l0ZSBzaG91bGQgYmUgbW9iaWxlDQpjb21w bGlhbnQuPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuICANCnN0eWxlPSJmb250LXNpemU6MTBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZ2IoMzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1HQiI+oDwvc3Bhbj48c3Bhbj48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3Bh biAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0KbGFuZz0iRU4t R0IiPkkgY2FuIHNlbmQgeW91IGNhc2UNCnN0dWRpZXMgJmFtcDsgcmVmZXJlbmNlcyBvbiBob3cg d2UgaGF2ZSBkb25lIHRoZSBzYW1lIGZvciBtYW55IGJ1c2luZXNzZXMuDQpUaGVzZSBhcmUgc29t ZSBvZiB0aGUgYmFzaWMgdGhpbmdzIHdoaWNoIEkgb2ZmZXIgdG8gZG8uIEJ1dCBJIGNvdWxkIHNl bmQgIA0KeW91IGENCmRldGFpbGVkIHByb3Bvc2FsIG9uIGhvdyB3ZSBjYW4gaGVscCB5b3VyIGJ1 c2luZXNzIGluIHdlYiBtYXJrZXRpbmcgb3Zlcg0KaW50ZXJuZXQgY29tcGxpbWVudGluZyB5b3Vy IHJlYWwgbWFya2V0aW5nIGVmZm9ydHMuPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuICANCnN0eWxl PSJmb250LXNpemU6MTBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpyZ2IoMzQsMzQsMzQpIiAgDQpsYW5nPSJFTi1HQiI+oDwvc3Bh bj48c3Bhbj48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5Ij48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0 LDM0KSIgIA0KbGFuZz0iRU4tR0IiPkkgaGF2ZSBzZW50IHRoaXMNCm1haWwgZnJvbSBteSBwZXJz b25hbCBlLW1haWwuIFJlc3QgYXNzdXJlZCB0aGF0IHRoaXMgaXMgdGhlIGxhc3QgZS1tYWlsICAN CnlvdZJsbA0Kc2VlIGluIGNhc2UgeW91IHJlcGx5IHdpdGggeW91ciBkaXNpbnRlcmVzdCBvciBj aG9vc2Ugbm90IHRvIHJlcGx5IGF0IGFsbC4gIA0KSWYNCnlvdSBhcmUgaW50ZXJlc3RlZCwgSZJs bCBmdXJ0aGVyIGNvbW11bmljYXRlIHRocm91Z2ggbXkgYnVzaW5lc3MgZS1tYWlsLiBXZSAgDQpj YW4NCmFsc28gaGF2ZSBhIGNhbGwgYW55dGltZSB5b3UgcHJlZmVyLjwvc3Bhbj48c3Bhbj48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiAgDQpzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmdiKDM0LDM0LDM0KSIgIA0KbGFu Zz0iRU4tR0IiPqA8L3NwYW4+PHNwYW4+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZTox MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJnYigzNCwzNCwzNCkiICANCmxhbmc9IkVOLUdCIj5Mb29raW5nIGZvcndhcmQgdG8N CnlvdXIgcmVwbHkuIEJlIHdlbGwuPC9zcGFuPjxzcGFuPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuPqA8L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj6gPC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gIA0Kc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5CZXN0ICANClJlZ2FyZHMs PGJyPg0KSm9objxicj4NClNlbmlvciBTYWxlcyBFeGVjdXRpdmU8YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08V0JSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxXQlI+ LS0tLS0tLS0tLS0tPC9zcGFuPjxzcGFuPjxicj4NCjwvc3Bhbj48c3BhbiAgDQpzdHlsZT0iZm9u dC1zaXplOjEwcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPk5vdGU6ICANCjxicj4NClRoaXMgaXMgYSBvbmV0aW1lIGVtYWlsIGFuZCB5b3Ug bWF5IGFzayB1cyB0byAgDQqTUkVNT1ZFlC48L3NwYW4+PHNwYW4+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQo= From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 12:36:36 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7416A350 for ; Thu, 26 Dec 2013 12:36:36 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BDEE81CF6 for ; Thu, 26 Dec 2013 12:36:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23838; Thu, 26 Dec 2013 14:36:33 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VwAAz-000564-Bv; Thu, 26 Dec 2013 14:36:33 +0200 Message-ID: <52BC2299.6020608@FreeBSD.org> Date: Thu, 26 Dec 2013 14:35:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: hiren panchasara Subject: Re: igb / buf_ring panic: buf already enqueue at References: <52BBD857.8040808@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 12:36:36 -0000 on 26/12/2013 09:48 hiren panchasara said the following: > On Wed, Dec 25, 2013 at 11:18 PM, Andriy Gapon wrote: >> Unread portion of the kernel message buffer: >> panic: buf=0xfffffe0cfe9a0600 already enqueue at 1259 prod=1260 cons=1259 > > A similar report: > > http://freebsd.1045724.n5.nabble.com/igb-4-panic-already-enqueue-td5847439.html > > I think http://svnweb.freebsd.org/base?view=revision&revision=256200 > has the fix. Thank you very much for the information. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 16:38:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 170723BF; Thu, 26 Dec 2013 16:38:13 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2B831EFD; Thu, 26 Dec 2013 16:38:13 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ABF64B986; Thu, 26 Dec 2013 11:38:12 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: vmstat buckets Date: Thu, 26 Dec 2013 11:28:03 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <4260012E-9911-47AB-88B9-FDCD6748E6EE@fivenynes.com> In-Reply-To: <4260012E-9911-47AB-88B9-FDCD6748E6EE@fivenynes.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201312261128.03527.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 26 Dec 2013 11:38:12 -0500 (EST) Cc: "freebsd-net@freebsd.org" , Mark van der Meulen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 16:38:14 -0000 On Wednesday, December 25, 2013 6:02:42 am Mark van der Meulen wrote: > Hi All, >=20 > I have question about buckets in vmstat -z output which I haven=92t been = able=20 to find an answer for online=85 >=20 > I have 6 FreeBSD 9 boxes running as routers and they are seeing varying=20 results in vmstat -z. I=92m interested in understanding what the Buckets=20 represent/mean and how I can influence usage of them. >=20 > Some of the routers show 0 free buckets under 64 or 128 Bucket and so I d= id=20 some research and haven=92t been able to find out what it means - most peop= le=20 who have asked online have received an answer that it is nothing to worry=20 about, which is meaningless to me. >=20 > It seems that the higher the usage of the router, especially when it is a= lso=20 running userspace applications the less Bucket availability there is. Also = I=20 found someone speculating it was related to free kernel memory so that was= =20 updated on some routers however I saw little difference(although not sure i= f=20 adding it in /etc/sysctl.conf actually does anything as some haven=92t had = the=20 vm.kmem_size value change at all, despite reboots). >=20 > Can anyone explain what the buckets (16,32,64,128) do and what they=20 represent? Also if you know anything about troubleshooting bucket failures?= =20 There doesn=92t appear to be anything useful online despite many searches. >=20 > I am aware that it may not have anything to do with the problems I am=20 seeing, but I would still like to understand. They are used to back malloc(9). The in-kernel malloc(2) rounds allocations smaller than a page up to the next power of two and then allocates that from a UMA zone for that power of two. For example, the '128' bucket is used fo= r=20 all calls to malloc(9) for a size between 65 and 128. vmstat -m can give you a sense of which buckets each malloc type uses, but it doesn't give you a very detailed breakdown. However, if you compare snapshots of vmstat -m taken along with your vmstat -z snapshots, you might be able to infer which malloc buckets are seeing activity and use that to s= ee which malloc types correspond to the stats you care about from vmstat -z. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 17:49:16 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D5D79E1 for ; Thu, 26 Dec 2013 17:49:16 +0000 (UTC) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6688D13CD for ; Thu, 26 Dec 2013 17:49:16 +0000 (UTC) Received: by mail-pd0-f174.google.com with SMTP id x10so8260165pdj.33 for ; Thu, 26 Dec 2013 09:49:16 -0800 (PST) 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=skRpVNCq0/rOwV1JwVGtosLN+51feQb/0mrIU7+UjO0=; b=eANZ/uCXaYSPDm5SWp28gAXuMDM/pu8Sia3ShyjOZKQkE6RvdiZtLmOft2tt0/59D0 Nn8F6sBVWLDdbQg8bjZh+f1Ah1JrjUddqyjbl7ge1KIXzbzx8o40l2zwZrbvVw8cUN2U 3zxu+sloae6TDnVu8l6O6sLLKu8cvjLoQkWSpBEccJD6MtASpZTt4C1ronET5VBpzO6/ 7hj0RbCms+ls43WfB8E0/owqz5tKjqu3ZQaOpNg7FZMGfzsqUGj3wOzqXxc2htFHkX8N UgBCNWKcHHNhnq+MDrrnLflkYPFtm5oqdenrA+nFdWyhkURB7PlszJVnuDxzy4IclSp1 aElw== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr45460209pbc.5.1388080156051; Thu, 26 Dec 2013 09:49:16 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 26 Dec 2013 09:49:16 -0800 (PST) Date: Thu, 26 Dec 2013 09:49:16 -0800 Message-ID: Subject: Question about the "connected" UDP sockets From: Oleg Moskalenko To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 17:49:16 -0000 Hi I cannot find the information about the implementation details of the "connected" UDP sockets in FreeBSD. I know that in older Linux kernels all UDP sockets are stored in a hash table - and the remote IP:port are not used for the hash calculation, so the performance is awful when you have thousands "connected" UDP sockets on the same local IP:port address. So a UDP packet incoming to the local address has to go through the long list of sockets to find the proper destination. How it is done in the FreeBSD ? Are the UDP "connected" sockets using a hash table with key based upon 5-tuple (protocol, remote-ip, remote-port, local-ip, local-port} ? I'd like to use UDP for my server application in the same way as TCP is used: I'll accept a new incoming packet, determine whether the remote address is "new", and if it is new I'd create a new UDP socket bound to the same local address and connected to the remote address. I'll end up with thousands UDP sockets with the same local address and different remote addresses; and the sockets are distributed among several threads (one per CPU core). How efficiently this case is handled by FreeBSD kernel ? In the older Linuxes the performance is quickly degrading when the number of "connected" UDP sockets is growing. Will I'll be better with just a single-threaded application with a single unconnected UDP socket ? Thanks ! Oleg From owner-freebsd-net@FreeBSD.ORG Thu Dec 26 17:54:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34E1AB83 for ; Thu, 26 Dec 2013 17:54:19 +0000 (UTC) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD5B1487 for ; Thu, 26 Dec 2013 17:54:18 +0000 (UTC) Received: by lath.rinet.ru (Postfix, from userid 222) id A3F278098; Thu, 26 Dec 2013 21:54:10 +0400 (MSK) Date: Thu, 26 Dec 2013 21:54:10 +0400 From: Oleg Bulyzhin To: Ryan Stone Subject: Re: buf_ring in HEAD is racy Message-ID: <20131226175410.GA15332@lath.rinet.ru> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 26 Dec 2013 17:54:19 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Dec 14, 2013 at 12:04:57AM -0500, Ryan Stone wrote: > I am seeing spurious output packet drops that appear to be due to > insufficient memory barriers in buf_ring. I believe that this is the > scenario that I am seeing: > > 1) The buf_ring is empty, br_prod_head = br_cons_head = 0 > 2) Thread 1 attempts to enqueue an mbuf on the buf_ring. It fetches > br_prod_head (0) into a local variable called prod_head > 3) Thread 2 enqueues an mbuf on the buf_ring. The sequence of events > is essentially: > > Thread 2 claims an index in the ring and atomically sets br_prod_head (say to 1) > Thread 2 sets br_ring[1] = mbuf; > Thread 2 does a full memory barrier > Thread 2 updates br_prod_tail to 1 > > 4) Thread 2 dequeues the packet from the buf_ring using the > single-consumer interface. The sequence of events is essentialy: > > Thread 2 checks whether queue is empty (br_cons_head == br_prod_tail), > this is false > Thread 2 sets br_cons_head to 1 > Thread 2 grabs the mbuf from br_ring[1] > Thread 2 sets br_cons_tail to 1 > > 5) Thread 1, which is still attempting to enqueue an mbuf on the ring. > fetches br_cons_tail (1) into a local variable called cons_tail. It > sees cons_tail == 1 but prod_head == 0 and concludes that the ring is > full and drops the packet (incrementing br_drops unatomically, I might > add) > > > I can reproduce several drops per minute by configuring the ixgbe > driver to use only 1 queue and then sending traffic from concurrent 8 > iperf processes. (You will need this hacky patch to even see the > drops with netstat, though: > http://people.freebsd.org/~rstone/patches/ixgbe_br_drops.diff) > > I am investigating fixing buf_ring by using acquire/release semantics > rather than load/store barriers. However, I note that this will > apparently be the second attempt to fix buf_ring, and I'm seriously > questioning whether this is worth the effort compared to the > simplicity of using a mutex. I'm not even convinced that a correct > lockless implementation will even be a performance win, given the > number of memory barriers that will apparently be necessary. > _______________________________________________ > 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" I was able to reproduce this bug. I've used 2-headed intel 10g card with twinax loopback and 4-core amd phenom. Here some results: - netperf works better for me than iperf in bug exposing, i was able to see steady (~20packet per second) packet drop (running 4 netperf clients simultaniously (UDP_STREAM test)). - i think you are right about the reason of those drops: there is a path in buf_ring_enqueue() where packet can be dropped without proper synchronization with another instance of buf_ring_enqueue(). - i've looked through buf_ring.h and here is my opinion: race is possible between buf_ring_enqueue() and buf_ring_dequeue_mc() which can lead to memory corruption. (though i didn't find any buf_ring_dequeue_mc() users in kernel, and this race is not possible on x86/amd64 archs due to their memory model, but it should be possible on arm/powerpc). I've attached patch which should fix all these problems. If there is no objection i can commit it. Unfortunatly i have no non-x86 hardware to play with so i can't test enqueue()/dequeue_mc() race myself. With this patch output drops are rare: in 10 tests (4 netperfs running UDP_STREAM test for 60 seconds) 8 tests had no drops, one had 2 drops and another one had 39 drops. These drops happens (i guess) when buf_ring is _really_ full. Without this patch same test gives me about 20 drops _per second_. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ --vkogqOf2sHV7VnPd Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="buf_ring.h.diff" --- sys/sys/buf_ring.h.orig 2013-03-21 13:08:09.000000000 +0400 +++ sys/sys/buf_ring.h 2013-12-26 21:34:57.000000000 +0400 @@ -64,8 +64,7 @@ static __inline int buf_ring_enqueue(struct buf_ring *br, void *buf) { - uint32_t prod_head, prod_next; - uint32_t cons_tail; + uint32_t prod_head, prod_next, cons_tail; #ifdef DEBUG_BUFRING int i; for (i = br->br_cons_head; i != br->br_prod_head; @@ -77,16 +76,20 @@ critical_enter(); do { prod_head = br->br_prod_head; + prod_next = (prod_head + 1) & br->br_prod_mask; cons_tail = br->br_cons_tail; - prod_next = (prod_head + 1) & br->br_prod_mask; - if (prod_next == cons_tail) { - br->br_drops++; - critical_exit(); - return (ENOBUFS); + rmb(); + if (prod_head == br->br_prod_head && + cons_tail == br->br_cons_tail) { + br->br_drops++; + critical_exit(); + return (ENOBUFS); + } + continue; } - } while (!atomic_cmpset_int(&br->br_prod_head, prod_head, prod_next)); + } while (!atomic_cmpset_acq_int(&br->br_prod_head, prod_head, prod_next)); #ifdef DEBUG_BUFRING if (br->br_ring[prod_head] != NULL) panic("dangling value in enqueue"); @@ -94,19 +97,13 @@ br->br_ring[prod_head] = buf; /* - * The full memory barrier also avoids that br_prod_tail store - * is reordered before the br_ring[prod_head] is full setup. - */ - mb(); - - /* * If there are other enqueues in progress * that preceeded us, we need to wait for them * to complete */ while (br->br_prod_tail != prod_head) cpu_spinwait(); - br->br_prod_tail = prod_next; + atomic_store_rel_int(&br->br_prod_tail, prod_next); critical_exit(); return (0); } @@ -119,37 +116,23 @@ buf_ring_dequeue_mc(struct buf_ring *br) { uint32_t cons_head, cons_next; - uint32_t prod_tail; void *buf; - int success; critical_enter(); do { cons_head = br->br_cons_head; - prod_tail = br->br_prod_tail; - cons_next = (cons_head + 1) & br->br_cons_mask; - - if (cons_head == prod_tail) { + + if (cons_head == br->br_prod_tail) { critical_exit(); return (NULL); } - - success = atomic_cmpset_int(&br->br_cons_head, cons_head, - cons_next); - } while (success == 0); + } while (!atomic_cmpset_acq_int(&br->br_cons_head, cons_head, cons_next)); buf = br->br_ring[cons_head]; #ifdef DEBUG_BUFRING br->br_ring[cons_head] = NULL; #endif - - /* - * The full memory barrier also avoids that br_ring[cons_read] - * load is reordered after br_cons_tail is set. - */ - mb(); - /* * If there are other dequeues in progress * that preceeded us, we need to wait for them @@ -158,7 +141,7 @@ while (br->br_cons_tail != cons_head) cpu_spinwait(); - br->br_cons_tail = cons_next; + atomic_store_rel_int(&br->br_cons_tail, cons_next); critical_exit(); return (buf); --vkogqOf2sHV7VnPd-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 27 06:43:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A21E3CE6 for ; Fri, 27 Dec 2013 06:43:42 +0000 (UTC) Received: from mail.tcm.by (mail.tcm.by [84.201.224.251]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1FEEB153A for ; Fri, 27 Dec 2013 06:43:41 +0000 (UTC) Received: from skipped_antispam (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 14629FDE3 for ; Fri, 27 Dec 2013 09:34:15 +0300 (FET) Received: from mailhub (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 891D8FDD8 for ; Fri, 27 Dec 2013 09:34:14 +0300 (FET) Received: from dialup-dynamic-pool1-45.tcm.by (unknown [84.201.225.45]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcm.by (Postfix) with ESMTP id 3A9E9FDD2 for ; Fri, 27 Dec 2013 09:34:13 +0300 (FET) Date: Fri, 27 Dec 2013 09:34:16 +0300 From: "Denis V. Klimkov" Organization: Telecom Media Systems JLLC X-Priority: 3 (Normal) Message-ID: <21356442.20131227093416@tcm.by> To: freebsd-net@freebsd.org Subject: ipfw verrevpath performance broken in 9.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 06:43:42 -0000 Hello Freebsd-net, Recently upgraded router system from 9.0-RELEASE to 9.2-STABLE and got 100% CPU utilisation on all cores with interrupts under the same load that had about 25-30% CPU utilisation before. Of course that lead to high latency (about 400 ms and packet loss). Load reduced immediately after I removed all ipfw antispoofing rules with "verrevpath": 11010 3659429 430047150 deny ip from any to any not verrevpath in via vlan6 11020 719931 58619220 deny ip from any to any not verrevpath in via vlan7 11025 68141 5144481 deny ip from any to any not verrevpath in via vlan8 11030 202144 6785732 deny ip from any to any not verrevpath in via vlan9 11040 171291 56196945 deny ip from any to any not verrevpath in via vlan10 11045 291914032 39427773226 deny ip from any to any not verrevpath in via vlan11 11060 6102962 441745213 deny ip from any to any not verrevpath in via vlan15 11070 4832442 1259880158 deny ip from any to any not verrevpath in via vlan16 11080 814769 95745079 deny ip from any to any not verrevpath in via vlan17 11101 2901098 628552748 deny ip from any to any not verrevpath in via vlan26 11102 1264750 146468688 deny ip from any to any not verrevpath in via vlan27 11110 902441 294155831 deny ip from any to any not verrevpath in via vlan21 11120 628324 31060933 deny ip from any to any not verrevpath in via vlan23 11130 1381 83245 deny ip from any to any not verrevpath in via vlan24 11138 4258607 3389925416 deny ip from any to any not verrevpath in via vlan31 11150 56 2792 deny ip from any to any not verrevpath in via vlan40 Is there a way to fix verrevpath performance issue in 9.2 and futher? There is no problem to remove this rules on this system, but I also have 2 systems running MPD with about 2000 PPPoE ng interfaces with very handy ipfw rule "deny ip from any to any not verrevpath in via ng*". --- Denis V. Klimkov From owner-freebsd-net@FreeBSD.ORG Fri Dec 27 10:27:54 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C101E903 for ; Fri, 27 Dec 2013 10:27:54 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 840341345 for ; Fri, 27 Dec 2013 10:27:54 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VwQow-000KM5-CV; Fri, 27 Dec 2013 10:22:54 +0400 Message-ID: <52BD5598.9020100@FreeBSD.org> Date: Fri, 27 Dec 2013 14:25:28 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Denis V. Klimkov" , freebsd-net@freebsd.org Subject: Re: ipfw verrevpath performance broken in 9.2 References: <21356442.20131227093416@tcm.by> In-Reply-To: <21356442.20131227093416@tcm.by> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 10:27:54 -0000 On 27.12.2013 10:34, Denis V. Klimkov wrote: > Hello Freebsd-net, Hi! > > Recently upgraded router system from 9.0-RELEASE to 9.2-STABLE and > got 100% CPU utilisation on all cores with interrupts under the same > load that had about 25-30% CPU utilisation before. Of course that lead Looks interesting. Are you sure all other configs/data load are the same? I'm particularly interested in changes in: number of NIC queues, their bindings and firewall ruleset. Can you share your traffic rate (e.g. netstat -i -w1), cpu info and NIC info? What does system load (without verrevpath) looks like in comparison with 9.0 (in terms of CPU _and_ packets/sec) ? > to high latency (about 400 ms and packet loss). > Load reduced immediately after I removed all ipfw antispoofing rules with > "verrevpath": > 11010 3659429 430047150 deny ip from any to any not verrevpath in via vlan6 > 11020 719931 58619220 deny ip from any to any not verrevpath in via vlan7 > 11025 68141 5144481 deny ip from any to any not verrevpath in via vlan8 > 11030 202144 6785732 deny ip from any to any not verrevpath in via vlan9 > 11040 171291 56196945 deny ip from any to any not verrevpath in via vlan10 > 11045 291914032 39427773226 deny ip from any to any not verrevpath in via vlan11 > 11060 6102962 441745213 deny ip from any to any not verrevpath in via vlan15 > 11070 4832442 1259880158 deny ip from any to any not verrevpath in via vlan16 > 11080 814769 95745079 deny ip from any to any not verrevpath in via vlan17 > 11101 2901098 628552748 deny ip from any to any not verrevpath in via vlan26 > 11102 1264750 146468688 deny ip from any to any not verrevpath in via vlan27 > 11110 902441 294155831 deny ip from any to any not verrevpath in via vlan21 > 11120 628324 31060933 deny ip from any to any not verrevpath in via vlan23 > 11130 1381 83245 deny ip from any to any not verrevpath in via vlan24 > 11138 4258607 3389925416 deny ip from any to any not verrevpath in via vlan31 > 11150 56 2792 deny ip from any to any not verrevpath in via vlan40 > > Is there a way to fix verrevpath performance issue in 9.2 and futher? > There is no problem to remove this rules on this system, but I also > have 2 systems running MPD with about 2000 PPPoE ng interfaces with > very handy ipfw rule "deny ip from any to any not verrevpath in via There were no changes related to verrevpath directly, but there were some related to generic netgraph/lookup performance. I've got some idea about what can be happening here, but I need your numbers/other info first. > ng*". > > --- > Denis V. Klimkov > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Dec 27 11:16:45 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B99D351 for ; Fri, 27 Dec 2013 11:16:45 +0000 (UTC) Received: from mail.tcm.by (mail.tcm.by [84.201.224.251]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A2ED16B5 for ; Fri, 27 Dec 2013 11:16:43 +0000 (UTC) Received: from skipped_antispam (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 22F46FDB8 for ; Fri, 27 Dec 2013 14:16:41 +0300 (FET) Received: from mailhub (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5EB7DFDAF for ; Fri, 27 Dec 2013 14:16:40 +0300 (FET) Received: from dialup-dynamic-pool1-45.tcm.by (unknown [84.201.225.45]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tcm.by (Postfix) with ESMTP id B8CE7FDA8; Fri, 27 Dec 2013 14:16:39 +0300 (FET) Date: Fri, 27 Dec 2013 14:16:38 +0300 From: "Denis V. Klimkov" Organization: Telecom Media Systems JLLC X-Priority: 3 (Normal) Message-ID: <27299961.20131227141638@tcm.by> To: "Alexander V. Chernikov" Subject: Re: ipfw verrevpath performance broken in 9.2 In-Reply-To: <52BD5598.9020100@FreeBSD.org> References: <21356442.20131227093416@tcm.by> <52BD5598.9020100@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 11:16:45 -0000 Hello Alexander, Friday, December 27, 2013, 1:25:28 PM, you wrote: >> Recently upgraded router system from 9.0-RELEASE to 9.2-STABLE and >> got 100% CPU utilisation on all cores with interrupts under the same >> load that had about 25-30% CPU utilisation before. Of course that lead AVC> Looks interesting. AVC> Are you sure all other configs/data load are the same? Yes, everything was the same. Later changed NIC from 4 igbs to 1 ix. AVC> I'm particularly interested in changes in: number of NIC queues, their AVC> bindings and firewall ruleset. igb0: port 0x3020-0x303f mem 0xc6b20000-0xc6b3ffff,0xc6b44000-0xc6b47fff irq 40 at device 0.0 on pci1 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 00:15:17:b9:ef:dc igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb1: port 0x3000-0x301f mem 0xc6b00000-0xc6b1ffff,0xc6b40000-0xc6b43fff irq 28 at device 0.1 on pci1 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 00:15:17:b9:ef:dd igb1: Bound queue 0 to cpu 4 igb1: Bound queue 1 to cpu 5 igb1: Bound queue 2 to cpu 6 igb1: Bound queue 3 to cpu 7 pcib2: irq 24 at device 3.0 on pci0 pci2: on pcib2 pcib3: irq 26 at device 5.0 on pci0 pci3: on pcib3 igb2: port 0x2020-0x203f mem 0xc6420000-0xc643ffff,0xc6000000-0xc63fffff,0xc64c4000-0xc64c7fff irq 26 at device 0.0 on pci 3 igb2: Using MSIX interrupts with 5 vectors igb2: Ethernet address: 00:1b:21:4a:69:78 igb2: Bound queue 0 to cpu 8 igb2: Bound queue 1 to cpu 9 igb2: Bound queue 2 to cpu 10 igb2: Bound queue 3 to cpu 11 igb3: port 0x2000-0x201f mem 0xc6400000-0xc641ffff,0xc5c00000-0xc5ffffff,0xc64c0000-0xc64c3fff irq 25 at device 0.1 on pci 3 igb3: Using MSIX interrupts with 5 vectors igb3: Ethernet address: 00:1b:21:4a:69:79 igb3: Bound queue 0 to cpu 12 igb3: Bound queue 1 to cpu 13 igb3: Bound queue 2 to cpu 14 igb3: Bound queue 3 to cpu 15 09000 546827 20995102 deny ip from any to 224.0.0.0/8 09900 251418446 34849277439 fwd 127.0.0.1,3333 tcp from table(100) to not table(9) dst-port 80 09901 251226827 74150859375 allow tcp from any 80 to table(100) out 09999 324676485 22931487657 deny ip from not table(9) to table(100) 09999 93075888 5276322115 deny ip from table(100) to not table(9) 10000 234714177213 241730704799083 allow ip from table(5) to any 10005 245356169 18235355072 deny ip from any to any dst-port 135,137-139,445 out 10006 2929342953 182985124889 deny ip from table(104) to any 10020 688240709 620932403164 divert 8668 ip from any to 1.1.1.1 10400 682416642 620798165276 allow ip from any to any diverted 10770 73183544 9041870946 deny ip from table(2) to any out via vlan18 10772 11698 802274 deny ip from table(3) to any out via vlan4 10773 8807403 463870927 deny ip from any to table(2) out iptos reliability 10774 4923414 300617694 deny ip from any to table(3) out iptos reliability 10775 99485 4397077 deny ip from any to table(3) out iptos throughput 11010 3659429 430047150 deny ip from any to any not verrevpath in via vlan6 11020 719931 58619220 deny ip from any to any not verrevpath in via vlan7 11025 68141 5144481 deny ip from any to any not verrevpath in via vlan8 11030 202144 6785732 deny ip from any to any not verrevpath in via vlan9 11040 171291 56196945 deny ip from any to any not verrevpath in via vlan10 11045 291914032 39427773226 deny ip from any to any not verrevpath in via vlan11 11060 6102962 441745213 deny ip from any to any not verrevpath in via vlan15 11070 4832442 1259880158 deny ip from any to any not verrevpath in via vlan16 11080 814769 95745079 deny ip from any to any not verrevpath in via vlan17 11101 2901098 628552748 deny ip from any to any not verrevpath in via vlan26 11102 1264750 146468688 deny ip from any to any not verrevpath in via vlan27 11110 902441 294155831 deny ip from any to any not verrevpath in via vlan21 11120 628324 31060933 deny ip from any to any not verrevpath in via vlan23 11130 1381 83245 deny ip from any to any not verrevpath in via vlan24 11138 4258607 3389925416 deny ip from any to any not verrevpath in via vlan31 11150 56 2792 deny ip from any to any not verrevpath in via vlan40 15000 3363576 188412499 deny ip from not table(30) to table(31) out 19950 64832991 3461330324 deny tcp from table(25) to not table(8) dst-port 25 out 19960 693595 34424883 deny ip from table(101) to table(103) out 19970 466690 57539243 deny ip from not table(30) to me dst-port 161,162,21,3306 20000 35523656903 32569055261754 pipe tablearg ip from any to table(1) out iptos reliability 20010 36208900912 9635678183009 pipe tablearg ip from table(6) to any out via vlan18 20020 6963415930 5823875049163 pipe tablearg ip from any to table(10) out 20030 5370808609 1175572076679 pipe tablearg ip from table(11) to any out 60005 3749710 1625777707 deny udp from any to 2.2.2.100 dst-port 5060 60005 7940451 2910219814 deny udp from any to 2.2.2.1 dst-port 5060 60020 578206 71125954 divert 8668 ip from 192.168.0.0/16 to any out via vlan4 60020 120740 17363073 divert 8668 ip from 192.168.0.0/16 to any out via vlan5 60020 6485285 2421107818 divert 8668 ip from 192.168.0.0/16 to any out via vlan18 60020 22096 1876197 divert 8668 ip from 192.168.0.0/16 to any out via vlan11 60600 529456103 183816441399 allow ip from any to any diverted 62110 2482047796 207871928397 deny ip from not table(32) to any out via vlan18 62120 34184526 40243097237 allow ip from 3.3.3.0/24 to 3.3.3.0/24 via vlan4 62130 19323045 1282467423 deny ip from not table(32) to any out via vlan4 62140 21168902 1790816969 deny ip from any to not table(32) in via vlan4 64000 8160465887601 5338926261446363 allow ip from any to any 65000 1165747 214509370 allow ip from any to any 65535 5625 3645710 deny ip from any to any AVC> Can you share your traffic rate (e.g. netstat -i -w1), cpu info and NIC AVC> info? Now it's: # netstat -i -w1 input (Total) output packets errs idrops bytes packets errs bytes colls 312136 0 0 216478043 312375 0 216359751 0 311760 0 0 217559784 311654 0 217792531 0 295196 0 0 203318550 295319 0 211926680 0 300204 0 0 206880841 300219 0 206348483 0 297019 0 0 203171215 296930 0 207103301 0 308142 0 0 211553806 308294 0 207969407 0 320911 0 0 221584256 320955 0 218811245 0 CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.30-MHz 686-class CPU) AVC> What does system load (without verrevpath) looks like in comparison with AVC> 9.0 (in terms of CPU _and_ packets/sec) ? Sorry, cannot compare it. Old graphs are lost. AFAIR it was up to 30 LA in peak times when there was about 400+ kpss in and same out. I can try to add some rules with verrevpath now in 9.2 system. Without verrevpath rules top ISHP shows: last pid: 58440; load averages: 2.52, 2.52, 2.51 up 1+06:25:38 14:05:02 268 processes: 17 running, 177 sleeping, 74 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 28.2% interrupt, 71.8% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 38.0% interrupt, 62.0% idle CPU 2: 0.4% user, 0.0% nice, 0.8% system, 29.8% interrupt, 69.0% idle CPU 3: 0.0% user, 0.0% nice, 0.4% system, 26.7% interrupt, 72.9% idle CPU 4: 0.0% user, 0.0% nice, 0.8% system, 32.5% interrupt, 66.7% idle CPU 5: 0.0% user, 0.0% nice, 0.8% system, 31.4% interrupt, 67.8% idle CPU 6: 0.0% user, 0.0% nice, 0.0% system, 30.2% interrupt, 69.8% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 32.2% interrupt, 67.8% idle CPU 8: 0.0% user, 0.0% nice, 0.8% system, 0.0% interrupt, 99.2% idle CPU 9: 0.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.2% idle CPU 10: 0.4% user, 0.0% nice, 1.2% system, 0.0% interrupt, 98.4% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.8% interrupt, 99.2% idle CPU 12: 0.4% user, 0.0% nice, 0.0% system, 0.8% interrupt, 98.8% idle CPU 13: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle CPU 14: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 15: 0.0% user, 0.0% nice, 0.8% system, 0.0% interrupt, 99.2% idle netstat -iw 1 input (Total) output packets errs idrops bytes packets errs bytes colls 322k 0 0 219M 322k 0 220M 0 324k 0 0 224M 324k 0 222M 0 325k 0 0 227M 325k 0 227M 0 352k 0 0 247M 352k 0 242M 0 After adding verrevpath rules: last pid: 58471; load averages: 3.19, 2.82, 2.64 up 1+06:30:04 14:09:28 270 processes: 21 running, 179 sleeping, 70 waiting CPU 0: 0.0% user, 0.0% nice, 0.4% system, 51.4% interrupt, 48.2% idle CPU 1: 0.0% user, 0.0% nice, 0.4% system, 44.7% interrupt, 54.9% idle CPU 2: 0.0% user, 0.0% nice, 0.8% system, 37.6% interrupt, 61.6% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 38.8% interrupt, 61.2% idle CPU 4: 0.4% user, 0.0% nice, 0.0% system, 38.8% interrupt, 60.8% idle CPU 5: 0.0% user, 0.0% nice, 0.4% system, 41.2% interrupt, 58.4% idle CPU 6: 0.4% user, 0.0% nice, 0.4% system, 43.9% interrupt, 55.3% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 41.6% interrupt, 58.4% idle Looks like now this rules does not affect load such a way it was before. But now NICs configuration differs. There were ifconfig_lagg0="laggproto loadbalance laggport igb0 laggport igb1 laggport igb2 laggport igb3" and all vlans over lagg0. Now it is one ix0 without lagg and all vlans are over ix0. --- Denis V. Klimkov From owner-freebsd-net@FreeBSD.ORG Fri Dec 27 11:35:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E5477DA for ; Fri, 27 Dec 2013 11:35:44 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFB331812 for ; Fri, 27 Dec 2013 11:35:43 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1VwRsb-000KtQ-JA; Fri, 27 Dec 2013 11:30:45 +0400 Message-ID: <52BD657F.1010405@FreeBSD.org> Date: Fri, 27 Dec 2013 15:33:19 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Denis V. Klimkov" Subject: Re: ipfw verrevpath performance broken in 9.2 References: <21356442.20131227093416@tcm.by> <52BD5598.9020100@FreeBSD.org> <27299961.20131227141638@tcm.by> In-Reply-To: <27299961.20131227141638@tcm.by> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 11:35:44 -0000 On 27.12.2013 15:16, Denis V. Klimkov wrote: > Hello Alexander, > > Friday, December 27, 2013, 1:25:28 PM, you wrote: > >>> Recently upgraded router system from 9.0-RELEASE to 9.2-STABLE and >>> got 100% CPU utilisation on all cores with interrupts under the same >>> load that had about 25-30% CPU utilisation before. Of course that lead > AVC> Looks interesting. > AVC> Are you sure all other configs/data load are the same? > > Yes, everything was the same. Later changed NIC from 4 igbs to 1 ix. > > AVC> I'm particularly interested in changes in: number of NIC queues, their > AVC> bindings and firewall ruleset. > > igb0: port 0x3020-0x303f mem 0xc6b20000-0xc6b3ffff,0xc6b44000-0xc6b47fff irq 40 at device 0.0 on pci1 > igb0: Using MSIX interrupts with 5 vectors > igb0: Ethernet address: 00:15:17:b9:ef:dc > igb0: Bound queue 0 to cpu 0 > igb0: Bound queue 1 to cpu 1 > igb0: Bound queue 2 to cpu 2 > igb0: Bound queue 3 to cpu 3 > igb1: port 0x3000-0x301f mem 0xc6b00000-0xc6b1ffff,0xc6b40000-0xc6b43fff irq 28 at device 0.1 on pci1 > igb1: Using MSIX interrupts with 5 vectors > igb1: Ethernet address: 00:15:17:b9:ef:dd > igb1: Bound queue 0 to cpu 4 > igb1: Bound queue 1 to cpu 5 > igb1: Bound queue 2 to cpu 6 > igb1: Bound queue 3 to cpu 7 > pcib2: irq 24 at device 3.0 on pci0 > pci2: on pcib2 > pcib3: irq 26 at device 5.0 on pci0 > pci3: on pcib3 > igb2: port 0x2020-0x203f mem 0xc6420000-0xc643ffff,0xc6000000-0xc63fffff,0xc64c4000-0xc64c7fff irq 26 at device 0.0 on pci > 3 > igb2: Using MSIX interrupts with 5 vectors > igb2: Ethernet address: 00:1b:21:4a:69:78 > igb2: Bound queue 0 to cpu 8 > igb2: Bound queue 1 to cpu 9 > igb2: Bound queue 2 to cpu 10 > igb2: Bound queue 3 to cpu 11 > igb3: port 0x2000-0x201f mem 0xc6400000-0xc641ffff,0xc5c00000-0xc5ffffff,0xc64c0000-0xc64c3fff irq 25 at device 0.1 on pci > 3 > igb3: Using MSIX interrupts with 5 vectors > igb3: Ethernet address: 00:1b:21:4a:69:79 > igb3: Bound queue 0 to cpu 12 > igb3: Bound queue 1 to cpu 13 > igb3: Bound queue 2 to cpu 14 > igb3: Bound queue 3 to cpu 15 > > 09000 546827 20995102 deny ip from any to 224.0.0.0/8 > 09900 251418446 34849277439 fwd 127.0.0.1,3333 tcp from table(100) to not table(9) dst-port 80 > 09901 251226827 74150859375 allow tcp from any 80 to table(100) out > 09999 324676485 22931487657 deny ip from not table(9) to table(100) > 09999 93075888 5276322115 deny ip from table(100) to not table(9) > 10000 234714177213 241730704799083 allow ip from table(5) to any > 10005 245356169 18235355072 deny ip from any to any dst-port 135,137-139,445 out > 10006 2929342953 182985124889 deny ip from table(104) to any > 10020 688240709 620932403164 divert 8668 ip from any to 1.1.1.1 > 10400 682416642 620798165276 allow ip from any to any diverted > > 10770 73183544 9041870946 deny ip from table(2) to any out via vlan18 > 10772 11698 802274 deny ip from table(3) to any out via vlan4 > 10773 8807403 463870927 deny ip from any to table(2) out iptos reliability > 10774 4923414 300617694 deny ip from any to table(3) out iptos reliability > 10775 99485 4397077 deny ip from any to table(3) out iptos throughput It is probably worth doing something like putting all verrevpath before upper out rules, and write explicit 'skipto X ip from any to any out' ; and something like 'allow ip from any to any in' after all verrevpath rules to split in/out ruleset. > > 11010 3659429 430047150 deny ip from any to any not verrevpath in via vlan6 > 11020 719931 58619220 deny ip from any to any not verrevpath in via vlan7 > 11025 68141 5144481 deny ip from any to any not verrevpath in via vlan8 > 11030 202144 6785732 deny ip from any to any not verrevpath in via vlan9 > 11040 171291 56196945 deny ip from any to any not verrevpath in via vlan10 > 11045 291914032 39427773226 deny ip from any to any not verrevpath in via vlan11 > 11060 6102962 441745213 deny ip from any to any not verrevpath in via vlan15 > 11070 4832442 1259880158 deny ip from any to any not verrevpath in via vlan16 > 11080 814769 95745079 deny ip from any to any not verrevpath in via vlan17 > 11101 2901098 628552748 deny ip from any to any not verrevpath in via vlan26 > 11102 1264750 146468688 deny ip from any to any not verrevpath in via vlan27 > 11110 902441 294155831 deny ip from any to any not verrevpath in via vlan21 > 11120 628324 31060933 deny ip from any to any not verrevpath in via vlan23 > 11130 1381 83245 deny ip from any to any not verrevpath in via vlan24 > 11138 4258607 3389925416 deny ip from any to any not verrevpath in via vlan31 > 11150 56 2792 deny ip from any to any not verrevpath in via vlan40 (X) > 15000 3363576 188412499 deny ip from not table(30) to table(31) out > 19950 64832991 3461330324 deny tcp from table(25) to not table(8) dst-port 25 out > 19960 693595 34424883 deny ip from table(101) to table(103) out > 19970 466690 57539243 deny ip from not table(30) to me dst-port 161,162,21,3306 > 20000 35523656903 32569055261754 pipe tablearg ip from any to table(1) out iptos reliability > 20010 36208900912 9635678183009 pipe tablearg ip from table(6) to any out via vlan18 > 20020 6963415930 5823875049163 pipe tablearg ip from any to table(10) out > 20030 5370808609 1175572076679 pipe tablearg ip from table(11) to any out > 60005 3749710 1625777707 deny udp from any to 2.2.2.100 dst-port 5060 > 60005 7940451 2910219814 deny udp from any to 2.2.2.1 dst-port 5060 > 60020 578206 71125954 divert 8668 ip from 192.168.0.0/16 to any out via vlan4 > 60020 120740 17363073 divert 8668 ip from 192.168.0.0/16 to any out via vlan5 > 60020 6485285 2421107818 divert 8668 ip from 192.168.0.0/16 to any out via vlan18 > 60020 22096 1876197 divert 8668 ip from 192.168.0.0/16 to any out via vlan11 > 60600 529456103 183816441399 allow ip from any to any diverted > 62110 2482047796 207871928397 deny ip from not table(32) to any out via vlan18 > 62120 34184526 40243097237 allow ip from 3.3.3.0/24 to 3.3.3.0/24 via vlan4 > 62130 19323045 1282467423 deny ip from not table(32) to any out via vlan4 > 62140 21168902 1790816969 deny ip from any to not table(32) in via vlan4 > 64000 8160465887601 5338926261446363 allow ip from any to any > 65000 1165747 214509370 allow ip from any to any > 65535 5625 3645710 deny ip from any to any > > AVC> Can you share your traffic rate (e.g. netstat -i -w1), cpu info and NIC > AVC> info? > > Now it's: > # netstat -i -w1 > input (Total) output > packets errs idrops bytes packets errs bytes colls > 312136 0 0 216478043 312375 0 216359751 0 > 311760 0 0 217559784 311654 0 217792531 0 > 295196 0 0 203318550 295319 0 211926680 0 > 300204 0 0 206880841 300219 0 206348483 0 > 297019 0 0 203171215 296930 0 207103301 0 > 308142 0 0 211553806 308294 0 207969407 0 > 320911 0 0 221584256 320955 0 218811245 0 > > CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.30-MHz 686-class CPU) > > AVC> What does system load (without verrevpath) looks like in comparison with > AVC> 9.0 (in terms of CPU _and_ packets/sec) ? > > Sorry, cannot compare it. Old graphs are lost. AFAIR it was up to 30 LA > in peak times when there was about 400+ kpss in and same out. I can > try to add some rules with verrevpath now in 9.2 system. > > Without verrevpath rules top ISHP shows: > last pid: 58440; load averages: 2.52, 2.52, 2.51 up 1+06:25:38 14:05:02 > 268 processes: 17 running, 177 sleeping, 74 waiting > CPU 0: 0.0% user, 0.0% nice, 0.0% system, 28.2% interrupt, 71.8% idle > CPU 1: 0.0% user, 0.0% nice, 0.0% system, 38.0% interrupt, 62.0% idle > CPU 2: 0.4% user, 0.0% nice, 0.8% system, 29.8% interrupt, 69.0% idle > CPU 3: 0.0% user, 0.0% nice, 0.4% system, 26.7% interrupt, 72.9% idle > CPU 4: 0.0% user, 0.0% nice, 0.8% system, 32.5% interrupt, 66.7% idle > CPU 5: 0.0% user, 0.0% nice, 0.8% system, 31.4% interrupt, 67.8% idle > CPU 6: 0.0% user, 0.0% nice, 0.0% system, 30.2% interrupt, 69.8% idle > CPU 7: 0.0% user, 0.0% nice, 0.0% system, 32.2% interrupt, 67.8% idle > CPU 8: 0.0% user, 0.0% nice, 0.8% system, 0.0% interrupt, 99.2% idle > CPU 9: 0.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.2% idle > CPU 10: 0.4% user, 0.0% nice, 1.2% system, 0.0% interrupt, 98.4% idle > CPU 11: 0.0% user, 0.0% nice, 0.0% system, 0.8% interrupt, 99.2% idle > CPU 12: 0.4% user, 0.0% nice, 0.0% system, 0.8% interrupt, 98.8% idle > CPU 13: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle > CPU 14: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 15: 0.0% user, 0.0% nice, 0.8% system, 0.0% interrupt, 99.2% idle > > netstat -iw 1 > input (Total) output > packets errs idrops bytes packets errs bytes colls > 322k 0 0 219M 322k 0 220M 0 > 324k 0 0 224M 324k 0 222M 0 > 325k 0 0 227M 325k 0 227M 0 > 352k 0 0 247M 352k 0 242M 0 > > After adding verrevpath rules: > last pid: 58471; load averages: 3.19, 2.82, 2.64 up 1+06:30:04 14:09:28 > 270 processes: 21 running, 179 sleeping, 70 waiting > CPU 0: 0.0% user, 0.0% nice, 0.4% system, 51.4% interrupt, 48.2% idle > CPU 1: 0.0% user, 0.0% nice, 0.4% system, 44.7% interrupt, 54.9% idle > CPU 2: 0.0% user, 0.0% nice, 0.8% system, 37.6% interrupt, 61.6% idle > CPU 3: 0.0% user, 0.0% nice, 0.0% system, 38.8% interrupt, 61.2% idle > CPU 4: 0.4% user, 0.0% nice, 0.0% system, 38.8% interrupt, 60.8% idle > CPU 5: 0.0% user, 0.0% nice, 0.4% system, 41.2% interrupt, 58.4% idle > CPU 6: 0.4% user, 0.0% nice, 0.4% system, 43.9% interrupt, 55.3% idle > CPU 7: 0.0% user, 0.0% nice, 0.0% system, 41.6% interrupt, 58.4% idle > > Looks like now this rules does not affect load such a way it was > before. But now NICs configuration differs. There were > ifconfig_lagg0="laggproto loadbalance laggport igb0 laggport igb1 laggport igb2 laggport igb3" > and all vlans over lagg0. Now it is one ix0 without lagg and all vlans > are over ix0. Lagg (and queue bindings for multiple interfaces) is _very_ different story. Are you willing to test some patches related to verrevpath / general performance improvements? Btw, do you have fastforwarding turned on? > > --- > Denis V. Klimkov > > From owner-freebsd-net@FreeBSD.ORG Fri Dec 27 11:50:29 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40881D49 for ; Fri, 27 Dec 2013 11:50:29 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 23B7C191A for ; Fri, 27 Dec 2013 11:50:28 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1VwVvv-0000s7-Fk for freebsd-net@freebsd.org; Fri, 27 Dec 2013 03:50:27 -0800 Date: Fri, 27 Dec 2013 03:50:27 -0800 (PST) From: Beeblebrox To: freebsd-net@freebsd.org Message-ID: <1388145027430-5871834.post@n5.nabble.com> Subject: fib/setfib question MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 11:50:29 -0000 Hello. On my system I have Internal-Network, External-Network, lo0 and a cloned lo2 for Jails. Traffic from lo0 and the Internal Network for certain ports (like 80) will be diverted first to proxies running in jails and then to the outside (Ext-If). The other ports will forward requests to gateway directly. It was suggested I use multiple routing tables for this instead of redirects in pf. I have read a good amount of documentation and get the concepts, but I have minor points to clear up. 1. The lo2 clone can use the 192.168.2.96/28 IP address group yet each jail is to have one of 192.168.2.(97-105)/32 adress assignments. Do I setup one fib for the lo2 address group (preferable but seems unlikely) or do I set one-fib-per jail with "jail__fib=n" in jail.conf? 2. I assume I also need to assign one fib to the Int-If NIC? If yes, how is it done persistently in /etc/rc.conf? I came accross this code, but it does not seem very logical: setfib 1 route delete default setfib 1 route add default 192.168.2.1 (Int-If's IP) 3. Same question as above, but for the jail. I would assume that "jail__fib=n" would take care of the whole thing. 4. What (if any) should be the "defaultrouter=" setting in /etc/rc.conf? a) Nothing b) The fib-address c) The Ext-If address. It seems fib-address is the correct choice. I have not come across specific answers/examples for these questions. Thanks and Regards. ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/fib-setfib-question-tp5871834.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Fri Dec 27 14:13:45 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8ABA6130 for ; Fri, 27 Dec 2013 14:13:45 +0000 (UTC) Received: from mailgw1.riffle.be (mailgw1.riffle.be [89.106.240.139]) by mx1.freebsd.org (Postfix) with ESMTP id 53A4912A1 for ; Fri, 27 Dec 2013 14:13:44 +0000 (UTC) Received: from mailgw1.riffle.be (localhost [127.0.0.1]) by mailgw1.riffle.be (Postfix) with SMTP id 03C928D44CD; Fri, 27 Dec 2013 15:13:42 +0100 (CET) Date: Fri, 27 Dec 2013 15:13:41 +0100 From: "Alexander V. Chernikov" Sender: owner-freebsd-net@freebsd.org To: freebsd-net@freebsd.org, "Denis V. Klimkov" Subject: Re: ipfw verrevpath performance broken in 9.2 Message-ID: <52bd8b15.fW1EiGo7J0hceBZ5%melifaro@FreeBSD.org> User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 14:13:45 -0000 On 27.12.2013 10:34, Denis V. Klimkov wrote: > Hello Freebsd-net, Hi! > > Recently upgraded router system from 9.0-RELEASE to 9.2-STABLE and > got 100% CPU utilisation on all cores with interrupts under the same > load that had about 25-30% CPU utilisation before. Of course that lead Looks interesting. Are you sure all other configs/data load are the same? I'm particularly interested in changes in: number of NIC queues, their bindings and firewall ruleset. Can you share your traffic rate (e.g. netstat -i -w1), cpu info and NIC info? What does system load (without verrevpath) looks like in comparison with 9.0 (in terms of CPU _and_ packets/sec) ? > to high latency (about 400 ms and packet loss). > Load reduced immediately after I removed all ipfw antispoofing rules with > "verrevpath": > 11010 3659429 430047150 deny ip from any to any not verrevpath in via vlan6 > 11020 719931 58619220 deny ip from any to any not verrevpath in via vlan7 > 11025 68141 5144481 deny ip from any to any not verrevpath in via vlan8 > 11030 202144 6785732 deny ip from any to any not verrevpath in via vlan9 > 11040 171291 56196945 deny ip from any to any not verrevpath in via vlan10 > 11045 291914032 39427773226 deny ip from any to any not verrevpath in via vlan11 > 11060 6102962 441745213 deny ip from any to any not verrevpath in via vlan15 > 11070 4832442 1259880158 deny ip from any to any not verrevpath in via vlan16 > 11080 814769 95745079 deny ip from any to any not verrevpath in via vlan17 > 11101 2901098 628552748 deny ip from any to any not verrevpath in via vlan26 > 11102 1264750 146468688 deny ip from any to any not verrevpath in via vlan27 > 11110 902441 294155831 deny ip from any to any not verrevpath in via vlan21 > 11120 628324 31060933 deny ip from any to any not verrevpath in via vlan23 > 11130 1381 83245 deny ip from any to any not verrevpath in via vlan24 > 11138 4258607 3389925416 deny ip from any to any not verrevpath in via vlan31 > 11150 56 2792 deny ip from any to any not verrevpath in via vlan40 > > Is there a way to fix verrevpath performance issue in 9.2 and futher? > There is no problem to remove this rules on this system, but I also > have 2 systems running MPD with about 2000 PPPoE ng interfaces with > very handy ipfw rule "deny ip from any to any not verrevpath in via There were no changes related to verrevpath directly, but there were some related to generic netgraph/lookup performance. I've got some idea about what can be happening here, but I need your numbers/other info first. > ng*". > > --- > Denis V. Klimkov > > _______________________________________________ > 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 Fri Dec 27 14:15:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 972251DC for ; Fri, 27 Dec 2013 14:15:36 +0000 (UTC) Received: from mailgw1.riffle.be (mailgw1.riffle.be [89.106.240.139]) by mx1.freebsd.org (Postfix) with ESMTP id 2698B12B6 for ; Fri, 27 Dec 2013 14:15:35 +0000 (UTC) Received: from mailgw1.riffle.be (localhost [127.0.0.1]) by mailgw1.riffle.be (Postfix) with SMTP id 669928D41D7 for ; Fri, 27 Dec 2013 15:13:30 +0100 (CET) Date: Fri, 27 Dec 2013 15:13:30 +0100 From: "Denis V. Klimkov" Organization: Telecom Media Systems JLLC Sender: owner-freebsd-net@freebsd.org To: freebsd-net@freebsd.org Subject: ipfw verrevpath performance broken in 9.2 Message-ID: <52bd8b0a.QLWCVSs7HbGhDR9d%falcon@tcm.by> User-Agent: Heirloom mailx 12.5 6/20/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Dec 2013 14:15:36 -0000 Hello Freebsd-net, Recently upgraded router system from 9.0-RELEASE to 9.2-STABLE and got 100% CPU utilisation on all cores with interrupts under the same load that had about 25-30% CPU utilisation before. Of course that lead to high latency (about 400 ms and packet loss). Load reduced immediately after I removed all ipfw antispoofing rules with "verrevpath": 11010 3659429 430047150 deny ip from any to any not verrevpath in via vlan6 11020 719931 58619220 deny ip from any to any not verrevpath in via vlan7 11025 68141 5144481 deny ip from any to any not verrevpath in via vlan8 11030 202144 6785732 deny ip from any to any not verrevpath in via vlan9 11040 171291 56196945 deny ip from any to any not verrevpath in via vlan10 11045 291914032 39427773226 deny ip from any to any not verrevpath in via vlan11 11060 6102962 441745213 deny ip from any to any not verrevpath in via vlan15 11070 4832442 1259880158 deny ip from any to any not verrevpath in via vlan16 11080 814769 95745079 deny ip from any to any not verrevpath in via vlan17 11101 2901098 628552748 deny ip from any to any not verrevpath in via vlan26 11102 1264750 146468688 deny ip from any to any not verrevpath in via vlan27 11110 902441 294155831 deny ip from any to any not verrevpath in via vlan21 11120 628324 31060933 deny ip from any to any not verrevpath in via vlan23 11130 1381 83245 deny ip from any to any not verrevpath in via vlan24 11138 4258607 3389925416 deny ip from any to any not verrevpath in via vlan31 11150 56 2792 deny ip from any to any not verrevpath in via vlan40 Is there a way to fix verrevpath performance issue in 9.2 and futher? There is no problem to remove this rules on this system, but I also have 2 systems running MPD with about 2000 PPPoE ng interfaces with very handy ipfw rule "deny ip from any to any not verrevpath in via ng*". --- Denis V. Klimkov _______________________________________________ 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 Sat Dec 28 05:53:30 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AE4EC3E for ; Sat, 28 Dec 2013 05:53:30 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F129210B9 for ; Sat, 28 Dec 2013 05:53:29 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id c10so23495778igq.3 for ; Fri, 27 Dec 2013 21:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=SC/A030ObZuNv/cRYya0u9lIus+XkoKZCOcT6tOUvEk=; b=ceDGqgyM4bU8zJNRD99rmte/+fg9MQfbRjv9xhTiXy8YZzi2J/YwgaTFmY/b4CzBe/ Xd2dZA6OeNVVCw3vXvwvGiGhpkWIGLZY98awWOndiu0um690zHNyj740tVZ0UZY0m9v2 Pvdn2OPBHZebknrDkG6yKnXw94YGy2WRmVKtU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=SC/A030ObZuNv/cRYya0u9lIus+XkoKZCOcT6tOUvEk=; b=UhrLJRzXO1lr7Vr40mtPoISQkFYDLHct0LRIFOtT+fif0TjatsgjtznD/29sGupMGC eRMDU3a/u1uPx7ps4jFvddU6YX1ibmbxUJH0cfacWKfjc5HjpMFr1n7WepEJdbADcYyA yEEZ/6O314J+J8HRngaX29LEirOGBjKrPfeha72LfDqPDpd6FK8TXrsTAf47HjA3wfus pcdELxgnJn/RQJM8/l0MFauqZ7nTTM2URWRI6AYgVCaO5seqO0c+dXue14socC6L0Gnj anEFv5XS5azPgA1rDZrnkMU3PLcd6dJ2lnMQwzUNuNzjYO6EJc0N78yaZtGmUfs7VEA8 XGkw== X-Gm-Message-State: ALoCoQnDoY3gSsuWWuKyApanVehmmxemN8DpfM5NASsTIAVOGvBbyhqqcxZBdKA3ZgSB9/z3j5+T X-Received: by 10.50.120.71 with SMTP id la7mr138702igb.0.1388210009176; Fri, 27 Dec 2013 21:53:29 -0800 (PST) Received: from DataIX.local (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id w4sm48421123igb.5.2013.12.27.21.53.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 27 Dec 2013 21:53:28 -0800 (PST) Received: from DataIX.local (localhost [127.0.0.1]) by DataIX.local (8.14.7/8.14.7) with ESMTP id rBS5rO1v072792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Dec 2013 00:53:25 -0500 (EST) (envelope-from jh@DataIX.net) Received: (from jh@localhost) by DataIX.local (8.14.7/8.14.7/Submit) id rBS5rObN072791; Sat, 28 Dec 2013 00:53:24 -0500 (EST) (envelope-from jh) Date: Sat, 28 Dec 2013 00:53:24 -0500 From: jhellenthal@dataix.net To: net@freebsd.org, rc@freebsd.org Subject: network.subr _aliasN handling Message-ID: <20131228055324.GA72764@aim7400.DataIX.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 28 Dec 2013 05:53:30 -0000 Curious what everyone's opinion would be on modifying the handling of _aliasN functions or providing a wrapper around it to handle non-sequential ordering. My goal on this is simple and based around groupings similiar to that of the way user id(1)'s in passwd and group are handled or denoted for use on modern systems. I.e.: I would like to achieve this... *_alias[1-99] = System type addresses "Importand addresses or internal" *_alias[100-199] = Aliases for interface 1 *_alias[200-299] = Aliases for interface 2 etc... NOt looking to achieve some sort of prefered naming convention for the interface aliases, but loosen them so they may be defined by the user in whatever means neccesary to their benefit. In a scheme similiar to above I attempted to set an address on every other 4th alias leaving 3 space rule room for insertion of further addresses but was surprised when the processing of the aliases ceased at the first non-sequential space. So why not just grab every _aliasN no matter of what it is for the interface and shove them into an arrary to be processed by a "for" statement ? the order would still be kept without having to inspect every defintion of alias and incrementing prehistorically. As well this could provide early loading of the addresses into their respective arrays so they may be processed and provided to any other functions that may need to access them earlier on in script fallthrough. Looking at _alias'N' sequentialy feels like a neucense. From owner-freebsd-net@FreeBSD.ORG Sat Dec 28 22:05:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FFF5AF8 for ; Sat, 28 Dec 2013 22:05:57 +0000 (UTC) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9761E73 for ; Sat, 28 Dec 2013 22:05:57 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id c14so5555777vea.28 for ; Sat, 28 Dec 2013 14:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=WWwGmOrmNy04HFzIEI5JcQ3R7ZKegOaJC/0Dmz/MzyM=; b=oT0j6VTsVYgXpYerUphcOx2tpWxJODVPtuQCoiLjXHwS6dz/BEZT4ePoay7NK9cN/P WKk8Ko1c85wcLMJZrDCL8L+Fh2fnOjZAZpcncHNp2fFdtKZesPvm6Lbp1gz05i/MU4pp 4kdDxPDZ2DQTU9PFxrFF81UDsEokLyzO04fNu0spMRv/lYAG5chHa4y4qGaDSpSPRZSL Ql7Oq+0LA659/glPDJZ+0hdKwL66MrfjbPfHTR1z0phydpMuTesSJAVbw9PT7qoDWYwC KK9Rda2ksAt5hiTrvZ8y0aHRp+j3bAekGWhYH9h+Stz1LxLfFPuefeF+7nPGqCF9jihQ bNpg== X-Received: by 10.58.181.165 with SMTP id dx5mr128030vec.52.1388268356326; Sat, 28 Dec 2013 14:05:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.180.9 with HTTP; Sat, 28 Dec 2013 14:05:36 -0800 (PST) From: Andrew Klaus Date: Sat, 28 Dec 2013 15:05:36 -0700 Message-ID: Subject: Issues putting jails on their own subnet To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 28 Dec 2013 22:05:57 -0000 Hello, I'm trying to segregate some of my jails onto their own (DMZ) subnet. Internal subnet: 10.0.3.0/24 DMZ subnet: 10.0.4.0/24 Both of these subnets are on my FreeBSD host, but I'm using a second routing table for my DMZ jails as seen here: --------------- setfib 1 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.4.1 UGS 0 2393945 vlan4 10.0.3.0/24 link#12 U 0 0 vlan3 ---------------- The problem I'm facing, is when I try to connect to the DMZ'd jail from the 10.0.3.0 network, traffic comes in on vlan4 like it's supposed to, but replies back through on the vlan3 interface. I guess this makes sense, because of that second route entry (that I can't override). I've tried using PF to force the packets back through to 10.0.4.1, but it doesn't seem to want to work. Is the only other way to use the experimental vnet/vimage? Any ideas would be helpful. Thanks, Andrew