From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 01:02:24 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1898E9C for ; Sun, 30 Nov 2014 01:02:24 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45438D47 for ; Sun, 30 Nov 2014 01:02:23 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id sAU12GPu060489; Sat, 29 Nov 2014 17:02:16 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id sAU12FfN060488; Sat, 29 Nov 2014 17:02:15 -0800 (PST) (envelope-from david) Date: Sat, 29 Nov 2014 17:02:15 -0800 From: David Wolfskill To: net@freebsd.org Subject: How do I use net-mgmt/unifi{2,3,4} for Ubiquity UAP-PRO? Message-ID: <20141130010215.GP1228@albert.catwhisker.org> Reply-To: net@freebsd.org, David Wolfskill MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uMNE0C2is0k/ADx7" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 01:02:24 -0000 --uMNE0C2is0k/ADx7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Reply-To set, as I'm not subscribed to -net@ -- dhw] I have just received a new Ubiquity UAP-PRO access point. I would like to be able to use it. I first tried ; that only has links for MacOS and MS Windows. I ran nmap, and found that 22/tcp seems to be open, but I was unable to guess a login & password combination. I wrote to and received a pointer to , which includes: | Download |=20 | UniFi Controller for Mac | UniFi Controller for Windows | UniFi.unix.zip (UniFi Zipped Package is also provide for DIYers. See | readme.txt for details.) The seeme dto require databases/mongodb, so I built & installed that (bringing in archivers/snappy and lang/v8 in the process). That done, I fixed the mongod symlink, then tried java -jar lib/ace.jar start That seemed to "do stuff" for a bit (quietly), then settle down to doing gettimeofday() calls (according to ktrace output). I failed to find this useful. A bit of poking around on the Net made me aware of net-mgmt/unifi{2,3,4}, so I looked at the pkg-descr files, and decided to try one of them. Given that this is a new device, I figured I'd try unifi4. It installed... but now what? It doesn't seem to have installed any executables. And (semi-)blindly hacking yields: g1-253(10.1-S)[22] cd /usr/local/share/java/unifi g1-253(10.1-S)[23] ls -lT bin/mongod=20 lrwxr-xr-x 1 root wheel 21 Nov 29 12:45:57 2014 bin/mongod -> /usr/local= /bin/mongod g1-253(10.1-S)[24] java -jar lib/ace.jar start log4j:ERROR setFile(null,true) call failed. java.io.FileNotFoundException: logs/server.log (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:142) at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender= =2Ejava:207) at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:= 165) at org.apache.log4j.config.PropertySetter.activate(PropertySetter.j= ava:307) at org.apache.log4j.config.PropertySetter.setProperties(PropertySet= ter.java:172) at org.apache.log4j.config.PropertySetter.setProperties(PropertySet= ter.java:104) at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConf= igurator.java:842) at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConf= igurator.java:768) at org.apache.log4j.PropertyConfigurator.configureRootCategory(Prop= ertyConfigurator.java:648) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfig= urator.java:514) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfig= urator.java:580) at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(Opti= onConverter.java:526) at org.apache.log4j.LogManager.(LogManager.java:127) at org.apache.log4j.Logger.getLogger(Logger.java:104) at com.ubnt.oOOO.D.OO0O.o00000(Unknown Source) at com.ubnt.oOOO.D.OO0O.(Unknown Source) at com.ubnt.ace.Launcher.(Unknown Source) Exception in thread "launcher" org.springframework.beans.factory.BeanCreati= onException: Error creating bean with name 'int' defined in class com.ubnt.= oOOO.new: Instantiation of bean failed; nested exception is org.springframe= work.beans.factory.BeanDefinitionStoreException: Factory method [public com= =2Eubnt.oOOO.D.D com.ubnt.oOOO.new.int()] threw exception; nested exception= is org.springframework.beans.factory.BeanCreationException: Error creating= bean with name 'class' defined in class com.ubnt.oOOO.new: Invocation of i= nit method failed; nested exception is java.io.FileNotFoundException: /comm= on/local/share/java/unifi/data/db/version (No such file or directory) at org.springframework.beans.factory.support.ConstructorResolver.in= stantiateUsingFactoryMethod(ConstructorResolver.java:597) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFacto= ry.java:1055) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:951) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) at org.springframework.beans.factory.support.AbstractBeanFactory$1.= getObject(AbstractBeanFactory.java:296) at org.springframework.beans.factory.support.DefaultSingletonBeanRe= gistry.getSingleton(DefaultSingletonBeanRegistry.java:223) at org.springframework.beans.factory.support.AbstractBeanFactory.do= GetBean(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.AbstractBeanFactory.ge= tBean(AbstractBeanFactory.java:194) at org.springframework.beans.factory.support.DefaultListableBeanFac= tory.preInstantiateSingletons(DefaultListableBeanFactory.java:628) at org.springframework.context.support.AbstractApplicationContext.f= inishBeanFactoryInitialization(AbstractApplicationContext.java:932) at org.springframework.context.support.AbstractApplicationContext.r= efresh(AbstractApplicationContext.java:479) at org.springframework.context.annotation.AnnotationConfigApplicati= onContext.(AnnotationConfigApplicationContext.java:73) at com.ubnt.oOOO.ooOO.?00000(Unknown Source) at com.ubnt.ace.Launcher.main(Unknown Source) Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: = Factory method [public com.ubnt.oOOO.D.D com.ubnt.oOOO.new.int()] threw exc= eption; nested exception is org.springframework.beans.factory.BeanCreationE= xception: Error creating bean with name 'class' defined in class com.ubnt.o= OOO.new: Invocation of init method failed; nested exception is java.io.File= NotFoundException: /common/local/share/java/unifi/data/db/version (No such = file or directory) at org.springframework.beans.factory.support.SimpleInstantiationStr= ategy.instantiate(SimpleInstantiationStrategy.java:181) at org.springframework.beans.factory.support.ConstructorResolver.in= stantiateUsingFactoryMethod(ConstructorResolver.java:586) ... 14 more Caused by: org.springframework.beans.factory.BeanCreationException: Error c= reating bean with name 'class' defined in class com.ubnt.oOOO.new: Invocati= on of init method failed; nested exception is java.io.FileNotFoundException= : /common/local/share/java/unifi/data/db/version (No such file or directory) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1512) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:521) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) at org.springframework.beans.factory.support.AbstractBeanFactory$1.= getObject(AbstractBeanFactory.java:296) at org.springframework.beans.factory.support.DefaultSingletonBeanRe= gistry.getSingleton(DefaultSingletonBeanRegistry.java:223) at org.springframework.beans.factory.support.AbstractBeanFactory.do= GetBean(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.AbstractBeanFactory.ge= tBean(AbstractBeanFactory.java:194) at org.springframework.context.annotation.ConfigurationClassEnhance= r$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:305) at com.ubnt.oOOO.new$$EnhancerBySpringCGLIB$$1ca218e1.class() at com.ubnt.oOOO.new.int(Unknown Source) at com.ubnt.oOOO.new$$EnhancerBySpringCGLIB$$1ca218e1.CGLIB$int$0(<= generated>) at com.ubnt.oOOO.new$$EnhancerBySpringCGLIB$$1ca218e1$$FastClassByS= pringCGLIB$$51338a2f.invoke() at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodPr= oxy.java:228) at org.springframework.context.annotation.ConfigurationClassEnhance= r$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:293) at com.ubnt.oOOO.new$$EnhancerBySpringCGLIB$$1ca218e1.int() at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessor= Impl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod= AccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.beans.factory.support.SimpleInstantiationStr= ategy.instantiate(SimpleInstantiationStrategy.java:160) ... 15 more Caused by: java.io.FileNotFoundException: /common/local/share/java/unifi/da= ta/db/version (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:171) at java.io.FileWriter.(FileWriter.java:90) at com.ubnt.oOOO.D.G.afterPropertiesSet(Unknown Source) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1571) at org.springframework.beans.factory.support.AbstractAutowireCapabl= eBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1509) ... 34 more g1-253(10.1-S)[25] uname -a FreeBSD g1-253.catwhisker.org 10.1-STABLE FreeBSD 10.1-STABLE #1402 r27523= 6M/275239:1001503: Sat Nov 29 04:53:06 PST 2014 root@g1-253.catwhisker.= org:/common/S1/obj/usr/src/sys/CANARY i386 g1-253(10.1-S)[26]=20 That doesn't seem particularly useful, either. So ... now what??!? Thanks.... Peace, david --=20 David H. Wolfskill david@catwhisker.org Actions have consequences ... as do inactions. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uMNE0C2is0k/ADx7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUemyXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7vIAP/As8Z4NgmV0UtQqW9FrlstXz VOfY9F1IjQIqxKL9821oNYTUit9fwj50zkzVAgk6YMpDwVvmZI7SwWrxfklzevJ6 qB6MdwDH4KzAMX87tVNSAlTPn/iyqhEDP7uTp3Jrsi3DOFV4wgoLflDzJy6N3XM9 SmbpLsKtIMjCe7s3y8PL9HWLlMEdFaxl1HJQplX5q3596UAtoqvKJVzrFN53U1ii 6yDVgBNzzf+1ntqCtjE8ylzl6B2tipW673/dBJXBrpG939uh/hQSJzEF7bFwmM/T eSqFtlMxmykXE9WXqjOdTs3NpQX0YpjzoEbClV8w06+b528Sfa6/92PQhKzXXcDm kbQe+d6xjEQNMYg486Ao0/4GyxUE8LT+LkVrQ4AWT37rzvIWyC64kwxXzowV6RE9 Rwu/W4MuNxKfLlLORKM3H58aVrBbHSsHJnT33Fa7AC9dPwNte4J1N/GWSb0F4Bw3 QUeKbOpQ1RrVgkudIzKBoF/EZMDXwZ4VGS2K0rJFLhUbzbzk0Wpn4gBN+UOkiuul wG6o60ZncYgum/XNMj9wzBVcTGGpLwWxCP5NhJ6lyYxGGJ22r8QQKOm6AV3JEGgr NfHgkRQ+vdRr+pdQGKmjpU6d2gcJ6bxbpvCsVIkeVlM1jm14GVWcgIsHKMSXtxAi PTg9R/2hQRO6cInmhZTd =UOrG -----END PGP SIGNATURE----- --uMNE0C2is0k/ADx7-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 10:04:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74A466A1; Sun, 30 Nov 2014 10:04:14 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48C32F68; Sun, 30 Nov 2014 10:04:13 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sAUA48Aa039770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 30 Nov 2014 02:04:11 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <547AEB93.3050600@freebsd.org> Date: Sun, 30 Nov 2014 18:04:03 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Craig Rodrigues Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 10:04:14 -0000 On 11/29/14, 5:28 PM, Craig Rodrigues wrote: > On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer > wrote: > > > > > > also look at the following: (a little dated) > > > > > http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22 > > > This is a useful document. I put it on the wiki: > https://wiki.freebsd.org/VIMAGE/porting-to-vimage Thanks.. wow, did I actually know ALL that only 5 years ago? Scary. probbaly worth having someone who is currently active and up to date look at it to see if it's all still correct.. especially the module load/unload stuff. > > -- > Craig From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 12:06:04 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4E36245 for ; Sun, 30 Nov 2014 12:06:04 +0000 (UTC) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "e-mailfilter01.sunet.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 50E9EBF8 for ; Sun, 30 Nov 2014 12:06:03 +0000 (UTC) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id sAUC5k9l028268 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Nov 2014 13:05:46 +0100 Received: from [IPv6:2001:6b0:1b:3:c00f:eb3e:8af5:4937] ([IPv6:2001:6b0:1b:3:c00f:eb3e:8af5:4937]) (authenticated bits=0) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id sAUC5fmP025722; Sun, 30 Nov 2014 13:05:44 +0100 (CET) VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1417349145; bh=uXNPDmgBonr4/+ylUBEs5VloMgFzDnZW1rknrmMqAlk=; h=Date:From:To:Subject:References:In-Reply-To; b=232Cs7PgHf1WfhVOMJWSjVDGE4TnhVioLrrbEeUtKssJMUJRRbF5/KkIRHwWZsQA8 o6CKV3Lua2jAlwXUnlDy6SvjttcQuObYZluKSD9aLMb1HZUWPCuxPVwts5ypaZ1hGV 495D4Q7k3ccY+R6EYjupHJETvVyZDRGDWlf6zRDs= Message-ID: <547B081C.3000300@sunet.se> Date: Sun, 30 Nov 2014 13:05:48 +0100 From: =?ISO-8859-1?Q?B=F6rje_Josefsson?= User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: net@freebsd.org, David Wolfskill Subject: Re: How do I use net-mgmt/unifi{2,3,4} for Ubiquity UAP-PRO? References: <20141130010215.GP1228@albert.catwhisker.org> In-Reply-To: <20141130010215.GP1228@albert.catwhisker.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-Spam-Score: -0.10 () [Tag at 5.00] T_RP_MATCHES_RCVD:-0.1,DKIM(pass:0) X-CanIt-Geo: ip=2001:6b0:1b:3:c00f:eb3e:8af5:4937; country=SE X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09NlM5K1K - 0c9eb8fcb45e - 20141130 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 12:06:04 -0000 David Wolfskill wrote: > > Given that this is a new device, I figured I'd try unifi4. It > installed... but now what? It doesn't seem to have installed any > executables. And (semi-)blindly hacking yields: Have you tried to launch a web browser towards 127.0.0.1:8443 (or the host you installed the stuff on) - that's how I am managing my UniFi:s running on MacOS. --BJ From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 15:47:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7262BEE0 for ; Sun, 30 Nov 2014 15:47:34 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C29FAF for ; Sun, 30 Nov 2014 15:47:33 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 8DD32139C8 for ; Sun, 30 Nov 2014 13:47:39 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1417362450; x=1418226451; bh=PI/t7IssCUfn sJqxhdSxGLRUDb2WjB7XLbsmO20F82o=; b=Vov+iyGfJ6aHbPQp8pIlaE7FL8Qj xOaHgpCyHvNoHrulTxO7HNHfSvGqt0qUfxtVdDrkkQj1NPJX3qdpRhvjyp0b6b0V 3QTdb7gki6wcTNZXGXduDYgjp/NpHcLalBmqNjXLzKsdS/ctXZX2RjkCCZqO2hLE pknW2fLw3PEUQ+s= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvk8FVgogvfQ for ; Sun, 30 Nov 2014 13:47:30 -0200 (BRST) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id A4A76139C4 for ; Sun, 30 Nov 2014 13:47:29 -0200 (BRST) Message-ID: <547B3BFB.5000503@bsdinfo.com.br> Date: Sun, 30 Nov 2014 13:47:07 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net >> FreeBSD Net" Subject: Problems with Intel X520-SR2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 15:47:34 -0000 Dear, Unfortunately I have more options to resolve this problem I'm having with Intel X520-SR2. Have we changed the X520, we exchange the optical cords, exchanged optical modules, we changed the entire server, we reduce the temperature inside the equipment, made some attempts to tunning the site calomel[1]. We spend a lot of money and do not solve the problem. What happens is that when there is a traffic above 1.2Gbps with PPS above 700kpps in sometimes almost daily there is a lock in two 10GbE ports the X520-SR interface. Where I am obliged to leave a script running in the background doing just that: ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up Made it back to the interface function normally. It's already so for months and have not tried the latest driver from Intel because I do not see anything related to this issue. These 2-port 10GbE are my backbone linking the four cities that attend to our main router. One is backup to other but when the problem occurs, the two ports stop working and at the moment I have a break in my Internet I can only conclude that the problem is one of the things below: 1 - Intel Interface X520-SR2 has a problem with certain types of traffic and then hangs. 2 - The ixgbe driver has a bug that is causing it. 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it would be a regression and the equipment is very far away from me if I need to move me. Honestly I'm almost going on a Juniper closed solution. I would not want to do this because I love FreeBSD and I can not believe that he does not support a 2.7Gbps traffic, which is my peak traffic without getting having these falls. My hardware today is this: hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz hw.ncpu: 12 hw.byteorder: 1234 hw.physmem: 17083641856 hw.usermem: 15741001728 Hardware all Intel with motherboard S2600COE [2] and with network interfaces offboard: 1x - X520-SR2 [3] 2x - I350-T2 [4] My loader.conf: loader_logo="beastie" if_lagg_load="YES" speaker_load="YES" aio_load="YES" autoboot_delay="5" net.fibs=1 My sysctl.conf: net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet6.ip6.forwarding=1 kern.ipc.somaxconn=4096 net.inet.tcp.syncookies=1 net.inet.ip.redirect=1 net.inet.ip.accept_sourceroute=0 net.inet.ip.sourceroute=0 net.inet.tcp.drop_synfin=1 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 security.bsd.see_other_uids=0 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_max=65536 hw.intr_storm_threshold=9000 net.inet.ip.dummynet.pipe_slot_limit=800 net.inet.icmp.icmplim=2000 # sysctl dev.ix. dev.ix.%parent: dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x7a11 class=0x020000 dev.ix.0.%parent: pci129 dev.ix.0.fc: 3 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.link_irq: 193783 dev.ix.0.queue0.interrupt_rate: 50000 dev.ix.0.queue0.irqs: 12029604413 dev.ix.0.queue0.txd_head: 1517 dev.ix.0.queue0.txd_tail: 1517 dev.ix.0.queue0.tso_tx: 85 dev.ix.0.queue0.no_tx_dma_setup: 0 dev.ix.0.queue0.no_desc_avail: 3322269 dev.ix.0.queue0.tx_packets: 15392658033 dev.ix.0.queue0.rxd_head: 709 dev.ix.0.queue0.rxd_tail: 707 dev.ix.0.queue0.rx_packets: 21762427837 dev.ix.0.queue0.rx_bytes: 56918345381 dev.ix.0.queue0.rx_copies: 124289013 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 500000 dev.ix.0.queue1.irqs: 11482146431 dev.ix.0.queue1.txd_head: 731 dev.ix.0.queue1.txd_tail: 731 dev.ix.0.queue1.tso_tx: 1442 dev.ix.0.queue1.no_tx_dma_setup: 0 dev.ix.0.queue1.no_desc_avail: 5254761 dev.ix.0.queue1.tx_packets: 15835062632 dev.ix.0.queue1.rxd_head: 685 dev.ix.0.queue1.rxd_tail: 681 dev.ix.0.queue1.rx_packets: 21220715209 dev.ix.0.queue1.rx_bytes: 54351679461 dev.ix.0.queue1.rx_copies: 120833356 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 5319 dev.ix.0.queue2.irqs: 11532560324 dev.ix.0.queue2.txd_head: 501 dev.ix.0.queue2.txd_tail: 501 dev.ix.0.queue2.tso_tx: 2474 dev.ix.0.queue2.no_tx_dma_setup: 0 dev.ix.0.queue2.no_desc_avail: 429244 dev.ix.0.queue2.tx_packets: 15772209238 dev.ix.0.queue2.rxd_head: 246 dev.ix.0.queue2.rxd_tail: 244 dev.ix.0.queue2.rx_packets: 21408648299 dev.ix.0.queue2.rx_bytes: 56862350194 dev.ix.0.queue2.rx_copies: 124973551 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 20833 dev.ix.0.queue3.irqs: 11557466322 dev.ix.0.queue3.txd_head: 773 dev.ix.0.queue3.txd_tail: 773 dev.ix.0.queue3.tso_tx: 40 dev.ix.0.queue3.no_tx_dma_setup: 0 dev.ix.0.queue3.no_desc_avail: 665620 dev.ix.0.queue3.tx_packets: 16479111658 dev.ix.0.queue3.rxd_head: 1858 dev.ix.0.queue3.rxd_tail: 1854 dev.ix.0.queue3.rx_packets: 21412821769 dev.ix.0.queue3.rx_bytes: 52796089467 dev.ix.0.queue3.rx_copies: 127385950 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 11363 dev.ix.0.queue4.irqs: 10824852635 dev.ix.0.queue4.txd_head: 1711 dev.ix.0.queue4.txd_tail: 1713 dev.ix.0.queue4.tso_tx: 581 dev.ix.0.queue4.no_tx_dma_setup: 0 dev.ix.0.queue4.no_desc_avail: 115346803 dev.ix.0.queue4.tx_packets: 16100396810 dev.ix.0.queue4.rxd_head: 244 dev.ix.0.queue4.rxd_tail: 243 dev.ix.0.queue4.rx_packets: 21240995210 dev.ix.0.queue4.rx_bytes: 58726730771 dev.ix.0.queue4.rx_copies: 124872141 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 500000 dev.ix.0.queue5.irqs: 10955464761 dev.ix.0.queue5.txd_head: 75 dev.ix.0.queue5.txd_tail: 77 dev.ix.0.queue5.tso_tx: 1758 dev.ix.0.queue5.no_tx_dma_setup: 0 dev.ix.0.queue5.no_desc_avail: 4759 dev.ix.0.queue5.tx_packets: 16267888038 dev.ix.0.queue5.rxd_head: 905 dev.ix.0.queue5.rxd_tail: 904 dev.ix.0.queue5.rx_packets: 21381144028 dev.ix.0.queue5.rx_bytes: 61800291690 dev.ix.0.queue5.rx_copies: 129684798 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 33333 dev.ix.0.queue6.irqs: 11081350674 dev.ix.0.queue6.txd_head: 1744 dev.ix.0.queue6.txd_tail: 1746 dev.ix.0.queue6.tso_tx: 38 dev.ix.0.queue6.no_tx_dma_setup: 0 dev.ix.0.queue6.no_desc_avail: 18381 dev.ix.0.queue6.tx_packets: 15376961749 dev.ix.0.queue6.rxd_head: 1783 dev.ix.0.queue6.rxd_tail: 1782 dev.ix.0.queue6.rx_packets: 21381814216 dev.ix.0.queue6.rx_bytes: 56828960117 dev.ix.0.queue6.rx_copies: 130194429 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 5319 dev.ix.0.queue7.irqs: 11014043865 dev.ix.0.queue7.txd_head: 1545 dev.ix.0.queue7.txd_tail: 1545 dev.ix.0.queue7.tso_tx: 59 dev.ix.0.queue7.no_tx_dma_setup: 0 dev.ix.0.queue7.no_desc_avail: 5497 dev.ix.0.queue7.tx_packets: 15283534142 dev.ix.0.queue7.rxd_head: 184 dev.ix.0.queue7.rxd_tail: 182 dev.ix.0.queue7.rx_packets: 21431994087 dev.ix.0.queue7.rx_bytes: 57942270182 dev.ix.0.queue7.rx_copies: 128363306 dev.ix.0.queue7.lro_queued: 0 dev.ix.0.queue7.lro_flushed: 0 dev.ix.0.mac_stats.crc_errs: 268 dev.ix.0.mac_stats.ill_errs: 33 dev.ix.0.mac_stats.byte_errs: 55 dev.ix.0.mac_stats.short_discards: 0 dev.ix.0.mac_stats.local_faults: 3484 dev.ix.0.mac_stats.remote_faults: 121 dev.ix.0.mac_stats.rec_len_errs: 0 dev.ix.0.mac_stats.xon_txd: 1602713563748 dev.ix.0.mac_stats.xon_recvd: 0 dev.ix.0.mac_stats.xoff_txd: 108342810167 dev.ix.0.mac_stats.xoff_recvd: 0 dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 dev.ix.0.mac_stats.rx_frames_64: 5356098 dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 dev.ix.0.mac_stats.recv_undersized: 0 dev.ix.0.mac_stats.recv_fragmented: 0 dev.ix.0.mac_stats.recv_oversized: 244078 dev.ix.0.mac_stats.recv_jabberd: 4 dev.ix.0.mac_stats.management_pkts_rcvd: 0 dev.ix.0.mac_stats.management_pkts_drpd: 0 dev.ix.0.mac_stats.checksum_errs: 897344641 dev.ix.0.mac_stats.good_octets_txd: 126768678455085 dev.ix.0.mac_stats.total_pkts_txd: 126508073823 dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 dev.ix.0.mac_stats.management_pkts_txd: 0 dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15 dev.ix.1.%driver: ix dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x7a11 class=0x020000 dev.ix.1.%parent: pci129 dev.ix.1.fc: 3 dev.ix.1.enable_aim: 1 dev.ix.1.advertise_speed: 0 dev.ix.1.dropped: 0 dev.ix.1.mbuf_defrag_failed: 0 dev.ix.1.watchdog_events: 0 dev.ix.1.link_irq: 127925 dev.ix.1.queue0.interrupt_rate: 11627 dev.ix.1.queue0.irqs: 6686088831 dev.ix.1.queue0.txd_head: 1618 dev.ix.1.queue0.txd_tail: 1620 dev.ix.1.queue0.tso_tx: 28 dev.ix.1.queue0.no_tx_dma_setup: 0 dev.ix.1.queue0.no_desc_avail: 0 dev.ix.1.queue0.tx_packets: 13527334563 dev.ix.1.queue0.rxd_head: 1715 dev.ix.1.queue0.rxd_tail: 1714 dev.ix.1.queue0.rx_packets: 1503775702 dev.ix.1.queue0.rx_bytes: 1069295301 dev.ix.1.queue0.rx_copies: 2983480 dev.ix.1.queue0.lro_queued: 0 dev.ix.1.queue0.lro_flushed: 0 dev.ix.1.queue1.interrupt_rate: 5319 dev.ix.1.queue1.irqs: 6546967336 dev.ix.1.queue1.txd_head: 1812 dev.ix.1.queue1.txd_tail: 1812 dev.ix.1.queue1.tso_tx: 6 dev.ix.1.queue1.no_tx_dma_setup: 0 dev.ix.1.queue1.no_desc_avail: 0 dev.ix.1.queue1.tx_packets: 13475453794 dev.ix.1.queue1.rxd_head: 1246 dev.ix.1.queue1.rxd_tail: 1245 dev.ix.1.queue1.rx_packets: 1506444917 dev.ix.1.queue1.rx_bytes: 783064190 dev.ix.1.queue1.rx_copies: 2881513 dev.ix.1.queue1.lro_queued: 0 dev.ix.1.queue1.lro_flushed: 0 dev.ix.1.queue2.interrupt_rate: 5319 dev.ix.1.queue2.irqs: 6574615190 dev.ix.1.queue2.txd_head: 1494 dev.ix.1.queue2.txd_tail: 1494 dev.ix.1.queue2.tso_tx: 33 dev.ix.1.queue2.no_tx_dma_setup: 0 dev.ix.1.queue2.no_desc_avail: 0 dev.ix.1.queue2.tx_packets: 13555495169 dev.ix.1.queue2.rxd_head: 438 dev.ix.1.queue2.rxd_tail: 437 dev.ix.1.queue2.rx_packets: 1501380848 dev.ix.1.queue2.rx_bytes: 1008544082 dev.ix.1.queue2.rx_copies: 2660960 dev.ix.1.queue2.lro_queued: 0 dev.ix.1.queue2.lro_flushed: 0 dev.ix.1.queue3.interrupt_rate: 5319 dev.ix.1.queue3.irqs: 6617964401 dev.ix.1.queue3.txd_head: 1853 dev.ix.1.queue3.txd_tail: 1855 dev.ix.1.queue3.tso_tx: 10 dev.ix.1.queue3.no_tx_dma_setup: 0 dev.ix.1.queue3.no_desc_avail: 0 dev.ix.1.queue3.tx_packets: 13561212942 dev.ix.1.queue3.rxd_head: 429 dev.ix.1.queue3.rxd_tail: 428 dev.ix.1.queue3.rx_packets: 1498117903 dev.ix.1.queue3.rx_bytes: 784881986 dev.ix.1.queue3.rx_copies: 2695475 dev.ix.1.queue3.lro_queued: 0 dev.ix.1.queue3.lro_flushed: 0 dev.ix.1.queue4.interrupt_rate: 5319 dev.ix.1.queue4.irqs: 6575752163 dev.ix.1.queue4.txd_head: 902 dev.ix.1.queue4.txd_tail: 902 dev.ix.1.queue4.tso_tx: 5 dev.ix.1.queue4.no_tx_dma_setup: 0 dev.ix.1.queue4.no_desc_avail: 0 dev.ix.1.queue4.tx_packets: 13478514009 dev.ix.1.queue4.rxd_head: 536 dev.ix.1.queue4.rxd_tail: 535 dev.ix.1.queue4.rx_packets: 1476720084 dev.ix.1.queue4.rx_bytes: 944967171 dev.ix.1.queue4.rx_copies: 2650672 dev.ix.1.queue4.lro_queued: 0 dev.ix.1.queue4.lro_flushed: 0 dev.ix.1.queue5.interrupt_rate: 10416 dev.ix.1.queue5.irqs: 6578099670 dev.ix.1.queue5.txd_head: 1996 dev.ix.1.queue5.txd_tail: 1996 dev.ix.1.queue5.tso_tx: 663 dev.ix.1.queue5.no_tx_dma_setup: 0 dev.ix.1.queue5.no_desc_avail: 0 dev.ix.1.queue5.tx_packets: 13516483196 dev.ix.1.queue5.rxd_head: 1296 dev.ix.1.queue5.rxd_tail: 1295 dev.ix.1.queue5.rx_packets: 1496584151 dev.ix.1.queue5.rx_bytes: 810434347 dev.ix.1.queue5.rx_copies: 2899315 dev.ix.1.queue5.lro_queued: 0 dev.ix.1.queue5.lro_flushed: 0 dev.ix.1.queue6.interrupt_rate: 5319 dev.ix.1.queue6.irqs: 6624395782 dev.ix.1.queue6.txd_head: 1058 dev.ix.1.queue6.txd_tail: 1058 dev.ix.1.queue6.tso_tx: 20 dev.ix.1.queue6.no_tx_dma_setup: 0 dev.ix.1.queue6.no_desc_avail: 0 dev.ix.1.queue6.tx_packets: 13491315217 dev.ix.1.queue6.rxd_head: 1550 dev.ix.1.queue6.rxd_tail: 1549 dev.ix.1.queue6.rx_packets: 1510907490 dev.ix.1.queue6.rx_bytes: 719914325 dev.ix.1.queue6.rx_copies: 2712955 dev.ix.1.queue6.lro_queued: 0 dev.ix.1.queue6.lro_flushed: 0 dev.ix.1.queue7.interrupt_rate: 29411 dev.ix.1.queue7.irqs: 6573304834 dev.ix.1.queue7.txd_head: 784 dev.ix.1.queue7.txd_tail: 786 dev.ix.1.queue7.tso_tx: 2 dev.ix.1.queue7.no_tx_dma_setup: 0 dev.ix.1.queue7.no_desc_avail: 0 dev.ix.1.queue7.tx_packets: 13587681458 dev.ix.1.queue7.rxd_head: 1489 dev.ix.1.queue7.rxd_tail: 1488 dev.ix.1.queue7.rx_packets: 1504712031 dev.ix.1.queue7.rx_bytes: 1216803328 dev.ix.1.queue7.rx_copies: 2976103 dev.ix.1.queue7.lro_queued: 0 dev.ix.1.queue7.lro_flushed: 0 dev.ix.1.mac_stats.crc_errs: 0 dev.ix.1.mac_stats.ill_errs: 0 dev.ix.1.mac_stats.byte_errs: 0 dev.ix.1.mac_stats.short_discards: 0 dev.ix.1.mac_stats.local_faults: 0 dev.ix.1.mac_stats.remote_faults: 12 dev.ix.1.mac_stats.rec_len_errs: 0 dev.ix.1.mac_stats.xon_txd: 1714791401322 dev.ix.1.mac_stats.xon_recvd: 0 dev.ix.1.mac_stats.xoff_txd: 41095995010 dev.ix.1.mac_stats.xoff_recvd: 0 dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 dev.ix.1.mac_stats.rx_frames_64: 73447 dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 dev.ix.1.mac_stats.rx_frames_128_255: 478134642 dev.ix.1.mac_stats.rx_frames_256_511: 232994605 dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 dev.ix.1.mac_stats.recv_undersized: 0 dev.ix.1.mac_stats.recv_fragmented: 0 dev.ix.1.mac_stats.recv_oversized: 0 dev.ix.1.mac_stats.recv_jabberd: 0 dev.ix.1.mac_stats.management_pkts_rcvd: 0 dev.ix.1.mac_stats.management_pkts_drpd: 0 dev.ix.1.mac_stats.checksum_errs: 85432477 dev.ix.1.mac_stats.good_octets_txd: 110334688606644 dev.ix.1.mac_stats.total_pkts_txd: 108193846110 dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 dev.ix.1.mac_stats.bcast_pkts_txd: 595976 dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 dev.ix.1.mac_stats.management_pkts_txd: 0 dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 # cat /var/run/dmesg.boot Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e Stepping = 4 Features=0xbfebfbff Features2=0x7fbee3ff AMD Features=0x2c100800 AMD Features2=0x1 Structured Extended Features=0x281 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16515358720 (15750 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 2 package(s) x 6 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 cpu4 (AP): APIC ID: 8 cpu5 (AP): APIC ID: 10 cpu6 (AP): APIC ID: 32 cpu7 (AP): APIC ID: 34 cpu8 (AP): APIC ID: 36 cpu9 (AP): APIC ID: 38 cpu10 (AP): APIC ID: 40 cpu11 (AP): APIC ID: 42 ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20130823/tbfadt-682) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 random: initialized cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, 9d000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 350 Event timer "HPET1" frequency 14318180 Hz quality 340 Event timer "HPET2" frequency 14318180 Hz quality 340 Event timer "HPET3" frequency 14318180 Hz quality 340 Event timer "HPET4" frequency 14318180 Hz quality 340 Event timer "HPET5" frequency 14318180 Hz quality 340 Event timer "HPET6" frequency 14318180 Hz quality 340 Event timer "HPET7" frequency 14318180 Hz quality 340 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 47 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 47 at device 1.1 on pci0 pci2: on pcib2 igb0: port 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 at device 0.0 on pci2 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:1e:67:9a:d5:88 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 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 igb1: port 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 at device 0.1 on pci2 igb1: Using MSIX interrupts with 9 vectors igb1: Ethernet address: 00:1e:67:9a:d5:89 igb1: Bound queue 0 to cpu 8 igb1: Bound queue 1 to cpu 9 igb1: Bound queue 2 to cpu 10 igb1: Bound queue 3 to cpu 11 igb1: Bound queue 4 to cpu 0 igb1: Bound queue 5 to cpu 1 igb1: Bound queue 6 to cpu 2 igb1: Bound queue 7 to cpu 3 igb2: port 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 at device 0.2 on pci2 igb2: Using MSIX interrupts with 9 vectors igb2: Ethernet address: 00:1e:67:9a:d5:8a igb2: Bound queue 0 to cpu 4 igb2: Bound queue 1 to cpu 5 igb2: Bound queue 2 to cpu 6 igb2: Bound queue 3 to cpu 7 igb2: Bound queue 4 to cpu 8 igb2: Bound queue 5 to cpu 9 igb2: Bound queue 6 to cpu 10 igb2: Bound queue 7 to cpu 11 igb3: port 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 at device 0.3 on pci2 igb3: Using MSIX interrupts with 9 vectors igb3: Ethernet address: 00:1e:67:9a:d5:8b igb3: Bound queue 0 to cpu 0 igb3: Bound queue 1 to cpu 1 igb3: Bound queue 2 to cpu 2 igb3: Bound queue 3 to cpu 3 igb3: Bound queue 4 to cpu 4 igb3: Bound queue 5 to cpu 5 igb3: Bound queue 6 to cpu 6 igb3: Bound queue 7 to cpu 7 pcib3: irq 47 at device 2.0 on pci0 pci4: on pcib3 igb4: mem 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 igb4: Using MSIX interrupts with 9 vectors igb4: Ethernet address: a0:36:9f:37:82:7e igb4: Bound queue 0 to cpu 8 igb4: Bound queue 1 to cpu 9 igb4: Bound queue 2 to cpu 10 igb4: Bound queue 3 to cpu 11 igb4: Bound queue 4 to cpu 0 igb4: Bound queue 5 to cpu 1 igb4: Bound queue 6 to cpu 2 igb4: Bound queue 7 to cpu 3 igb5: mem 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 igb5: Using MSIX interrupts with 9 vectors igb5: Ethernet address: a0:36:9f:37:82:7f igb5: Bound queue 0 to cpu 4 igb5: Bound queue 1 to cpu 5 igb5: Bound queue 2 to cpu 6 igb5: Bound queue 3 to cpu 7 igb5: Bound queue 4 to cpu 8 igb5: Bound queue 5 to cpu 9 igb5: Bound queue 6 to cpu 10 igb5: Bound queue 7 to cpu 11 pcib4: irq 16 at device 3.0 on pci0 pci6: on pcib4 igb6: mem 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 igb6: Using MSIX interrupts with 9 vectors igb6: Ethernet address: a0:36:9f:37:82:8a igb6: Bound queue 0 to cpu 0 igb6: Bound queue 1 to cpu 1 igb6: Bound queue 2 to cpu 2 igb6: Bound queue 3 to cpu 3 igb6: Bound queue 4 to cpu 4 igb6: Bound queue 5 to cpu 5 igb6: Bound queue 6 to cpu 6 igb6: Bound queue 7 to cpu 7 igb7: mem 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 igb7: Using MSIX interrupts with 9 vectors igb7: Ethernet address: a0:36:9f:37:82:8b igb7: Bound queue 0 to cpu 8 igb7: Bound queue 1 to cpu 9 igb7: Bound queue 2 to cpu 10 igb7: Bound queue 3 to cpu 11 igb7: Bound queue 4 to cpu 0 igb7: Bound queue 5 to cpu 1 igb7: Bound queue 6 to cpu 2 igb7: Bound queue 7 to cpu 3 pcib5: irq 16 at device 17.0 on pci0 pci8: on pcib5 pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) ehci0: mem 0xd1220000-0xd12203ff irq 22 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 pcib6: irq 16 at device 28.0 on pci0 pci9: on pcib6 pcib7: irq 17 at device 28.5 on pci0 pci10: on pcib7 pci10: at device 0.0 (no driver attached) pcib8: irq 19 at device 28.7 on pci0 pci11: on pcib8 vgapci0: mem 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq 19 at device 0.0 on pci11 vgapci0: Boot video device ehci1: mem 0xd1210000-0xd12103ff irq 20 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci1 pcib9: at device 30.0 on pci0 pci12: on pcib9 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f mem 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahciem0: on ahci0 pcib10: on acpi0 pci128: on pcib10 pcib11: irq 71 at device 1.0 on pci128 pci129: on pcib11 ix0: port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff irq 50 at device 0.0 on pci129 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 00:1b:21:89:25:32 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix1: port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff irq 52 at device 0.1 on pci129 ix1: Using MSIX interrupts with 9 vectors ix1: Ethernet address: 00:1b:21:89:25:33 ix1: PCI Express Bus: Speed 5.0GT/s Width x8 pcib12: irq 71 at device 2.0 on pci128 pci131: on pcib12 pcib13: irq 71 at device 3.0 on pci128 pci132: on pcib13 acpi_button0: on acpi0 pcib14: on acpi0 pci127: on pcib14 pcib15: on acpi0 pci255: on pcib15 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 est4: on cpu4 p4tcc4: on cpu4 est5: on cpu5 p4tcc5: on cpu5 est6: on cpu6 p4tcc6: on cpu6 est7: on cpu7 p4tcc7: on cpu7 est8: on cpu8 p4tcc8: on cpu8 est9: on cpu9 p4tcc9: on cpu9 est10: on cpu10 p4tcc10: on cpu10 est11: on cpu11 p4tcc11: on cpu11 random: unblocking device. usbus0: 480Mbps High Speed USB v2.0 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, logging disabled usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: Serial Number S1D5NSAF687077K ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) ada0: quirks=0x1<4K> ada0: Previously was known as ad4 ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 Root mount waiting for: usbus1 usbus0 uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen1.2: at usbus1 uhub2: on usbus1 ugen0.2: at usbus0 uhub3: on usbus0 Root mount waiting for: usbus1 usbus0 uhub3: 6 ports with 6 removable, self powered uhub2: 8 ports with 8 removable, self powered ugen1.3: at usbus1 ukbd0: on usbus1 kbd0 at ukbd0 Root mount waiting for: usbus1 ugen1.4: at usbus1 ukbd1: on usbus1 kbd2 at ukbd1 Trying to mount root from ufs:/dev/label/rootfs [rw]... lagg0: IPv6 addresses on igb6 have been removed before adding it as a member to prevent IPv6 address scope violation. lagg0: IPv6 addresses on igb7 have been removed before adding it as a member to prevent IPv6 address scope violation. ums0: on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 uhid0: on usbus1 # uname -a FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 [1] https://calomel.org/freebsd_network_tuning.html [2] http://ark.intel.com/products/63157 [3] http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 [4] http://ark.intel.com/products/59062/ Please I need a help! and sorry my english :) From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 16:05:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 688BD2DC for ; Sun, 30 Nov 2014 16:05:19 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4000236 for ; Sun, 30 Nov 2014 16:05:18 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xv2yQ-000NIp-DR; Sun, 30 Nov 2014 15:47:30 +0400 Message-ID: <547B4033.1060504@FreeBSD.org> Date: Sun, 30 Nov 2014 19:05:07 +0300 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Marcelo Gondim , "freebsd-net >> FreeBSD Net" Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> In-Reply-To: <547B3BFB.5000503@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 16:05:19 -0000 On 30.11.2014 18:47, Marcelo Gondim wrote: > Dear, > > Unfortunately I have more options to resolve this problem I'm having > with Intel X520-SR2. Have we changed the X520, we exchange the optical > cords, exchanged optical modules, we changed the entire server, we > reduce the temperature inside the equipment, made some attempts to > tunning the site calomel[1]. We spend a lot of money and do not solve > the problem. > > What happens is that when there is a traffic above 1.2Gbps with PPS > above 700kpps in sometimes almost daily there is a lock in two 10GbE > ports the X520-SR interface. Where I am obliged to leave a script > running in the background doing just that: What does this "lock" looks like? Do you using jumbo frames? Is this IPv4 or IPv4+IPv6 ? Can you share "netstat -m" output? Do you use ipfw dynamic states? Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? dev.ix.0.queue0.no_desc_avail: 3322269 dev.ix.0.queue1.no_desc_avail: 5254761 Looks suspicious. Either you're running out of mbufs due to total mbuf number is small, or system is very busy sometimes. What does you "top -HPSzs1" output look like? > > ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up > > Made it back to the interface function normally. It's already so for > months and have not tried the latest driver from Intel because I do > not see anything related to this issue. > > These 2-port 10GbE are my backbone linking the four cities that attend > to our main router. One is backup to other but when the problem > occurs, the two ports stop working and at the moment I have a break in > my Internet > > I can only conclude that the problem is one of the things below: > > 1 - Intel Interface X520-SR2 has a problem with certain types of > traffic and then hangs. > 2 - The ixgbe driver has a bug that is causing it. > 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it > would be a regression and the equipment is very far away from me if I > need to move me. > > Honestly I'm almost going on a Juniper closed solution. I would not > want to do this because I love FreeBSD and I can not believe that he > does not support a 2.7Gbps traffic, which is my peak traffic without > getting having these falls. My hardware today is this: > > hw.machine: amd64 > hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz > hw.ncpu: 12 > hw.byteorder: 1234 > hw.physmem: 17083641856 > hw.usermem: 15741001728 > > Hardware all Intel with motherboard S2600COE [2] and with network > interfaces offboard: > > 1x - X520-SR2 [3] > 2x - I350-T2 [4] > > My loader.conf: > > loader_logo="beastie" > if_lagg_load="YES" > speaker_load="YES" > aio_load="YES" > autoboot_delay="5" > net.fibs=1 > > My sysctl.conf: > > net.inet.ip.forwarding=1 > net.inet.ip.fastforwarding=1 > net.inet6.ip6.forwarding=1 > kern.ipc.somaxconn=4096 > net.inet.tcp.syncookies=1 > net.inet.ip.redirect=1 > net.inet.ip.accept_sourceroute=0 > net.inet.ip.sourceroute=0 > net.inet.tcp.drop_synfin=1 > net.inet.udp.blackhole=1 > net.inet.tcp.blackhole=2 > security.bsd.see_other_uids=0 > net.inet.ip.fw.dyn_buckets=65536 > net.inet.ip.fw.dyn_max=65536 > hw.intr_storm_threshold=9000 > net.inet.ip.dummynet.pipe_slot_limit=800 > net.inet.icmp.icmplim=2000 > > # sysctl dev.ix. > dev.ix.%parent: > dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version > - 2.5.15 > dev.ix.0.%driver: ix > dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 > dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > subdevice=0x7a11 class=0x020000 > dev.ix.0.%parent: pci129 > dev.ix.0.fc: 3 > dev.ix.0.enable_aim: 1 > dev.ix.0.advertise_speed: 0 > dev.ix.0.dropped: 0 > dev.ix.0.mbuf_defrag_failed: 0 > dev.ix.0.watchdog_events: 0 > dev.ix.0.link_irq: 193783 > dev.ix.0.queue0.interrupt_rate: 50000 > dev.ix.0.queue0.irqs: 12029604413 > dev.ix.0.queue0.txd_head: 1517 > dev.ix.0.queue0.txd_tail: 1517 > dev.ix.0.queue0.tso_tx: 85 > dev.ix.0.queue0.no_tx_dma_setup: 0 > dev.ix.0.queue0.no_desc_avail: 3322269 > dev.ix.0.queue0.tx_packets: 15392658033 > dev.ix.0.queue0.rxd_head: 709 > dev.ix.0.queue0.rxd_tail: 707 > dev.ix.0.queue0.rx_packets: 21762427837 > dev.ix.0.queue0.rx_bytes: 56918345381 > dev.ix.0.queue0.rx_copies: 124289013 > dev.ix.0.queue0.lro_queued: 0 > dev.ix.0.queue0.lro_flushed: 0 > dev.ix.0.queue1.interrupt_rate: 500000 > dev.ix.0.queue1.irqs: 11482146431 > dev.ix.0.queue1.txd_head: 731 > dev.ix.0.queue1.txd_tail: 731 > dev.ix.0.queue1.tso_tx: 1442 > dev.ix.0.queue1.no_tx_dma_setup: 0 > dev.ix.0.queue1.no_desc_avail: 5254761 > dev.ix.0.queue1.tx_packets: 15835062632 > dev.ix.0.queue1.rxd_head: 685 > dev.ix.0.queue1.rxd_tail: 681 > dev.ix.0.queue1.rx_packets: 21220715209 > dev.ix.0.queue1.rx_bytes: 54351679461 > dev.ix.0.queue1.rx_copies: 120833356 > dev.ix.0.queue1.lro_queued: 0 > dev.ix.0.queue1.lro_flushed: 0 > dev.ix.0.queue2.interrupt_rate: 5319 > dev.ix.0.queue2.irqs: 11532560324 > dev.ix.0.queue2.txd_head: 501 > dev.ix.0.queue2.txd_tail: 501 > dev.ix.0.queue2.tso_tx: 2474 > dev.ix.0.queue2.no_tx_dma_setup: 0 > dev.ix.0.queue2.no_desc_avail: 429244 > dev.ix.0.queue2.tx_packets: 15772209238 > dev.ix.0.queue2.rxd_head: 246 > dev.ix.0.queue2.rxd_tail: 244 > dev.ix.0.queue2.rx_packets: 21408648299 > dev.ix.0.queue2.rx_bytes: 56862350194 > dev.ix.0.queue2.rx_copies: 124973551 > dev.ix.0.queue2.lro_queued: 0 > dev.ix.0.queue2.lro_flushed: 0 > dev.ix.0.queue3.interrupt_rate: 20833 > dev.ix.0.queue3.irqs: 11557466322 > dev.ix.0.queue3.txd_head: 773 > dev.ix.0.queue3.txd_tail: 773 > dev.ix.0.queue3.tso_tx: 40 > dev.ix.0.queue3.no_tx_dma_setup: 0 > dev.ix.0.queue3.no_desc_avail: 665620 > dev.ix.0.queue3.tx_packets: 16479111658 > dev.ix.0.queue3.rxd_head: 1858 > dev.ix.0.queue3.rxd_tail: 1854 > dev.ix.0.queue3.rx_packets: 21412821769 > dev.ix.0.queue3.rx_bytes: 52796089467 > dev.ix.0.queue3.rx_copies: 127385950 > dev.ix.0.queue3.lro_queued: 0 > dev.ix.0.queue3.lro_flushed: 0 > dev.ix.0.queue4.interrupt_rate: 11363 > dev.ix.0.queue4.irqs: 10824852635 > dev.ix.0.queue4.txd_head: 1711 > dev.ix.0.queue4.txd_tail: 1713 > dev.ix.0.queue4.tso_tx: 581 > dev.ix.0.queue4.no_tx_dma_setup: 0 > dev.ix.0.queue4.no_desc_avail: 115346803 > dev.ix.0.queue4.tx_packets: 16100396810 > dev.ix.0.queue4.rxd_head: 244 > dev.ix.0.queue4.rxd_tail: 243 > dev.ix.0.queue4.rx_packets: 21240995210 > dev.ix.0.queue4.rx_bytes: 58726730771 > dev.ix.0.queue4.rx_copies: 124872141 > dev.ix.0.queue4.lro_queued: 0 > dev.ix.0.queue4.lro_flushed: 0 > dev.ix.0.queue5.interrupt_rate: 500000 > dev.ix.0.queue5.irqs: 10955464761 > dev.ix.0.queue5.txd_head: 75 > dev.ix.0.queue5.txd_tail: 77 > dev.ix.0.queue5.tso_tx: 1758 > dev.ix.0.queue5.no_tx_dma_setup: 0 > dev.ix.0.queue5.no_desc_avail: 4759 > dev.ix.0.queue5.tx_packets: 16267888038 > dev.ix.0.queue5.rxd_head: 905 > dev.ix.0.queue5.rxd_tail: 904 > dev.ix.0.queue5.rx_packets: 21381144028 > dev.ix.0.queue5.rx_bytes: 61800291690 > dev.ix.0.queue5.rx_copies: 129684798 > dev.ix.0.queue5.lro_queued: 0 > dev.ix.0.queue5.lro_flushed: 0 > dev.ix.0.queue6.interrupt_rate: 33333 > dev.ix.0.queue6.irqs: 11081350674 > dev.ix.0.queue6.txd_head: 1744 > dev.ix.0.queue6.txd_tail: 1746 > dev.ix.0.queue6.tso_tx: 38 > dev.ix.0.queue6.no_tx_dma_setup: 0 > dev.ix.0.queue6.no_desc_avail: 18381 > dev.ix.0.queue6.tx_packets: 15376961749 > dev.ix.0.queue6.rxd_head: 1783 > dev.ix.0.queue6.rxd_tail: 1782 > dev.ix.0.queue6.rx_packets: 21381814216 > dev.ix.0.queue6.rx_bytes: 56828960117 > dev.ix.0.queue6.rx_copies: 130194429 > dev.ix.0.queue6.lro_queued: 0 > dev.ix.0.queue6.lro_flushed: 0 > dev.ix.0.queue7.interrupt_rate: 5319 > dev.ix.0.queue7.irqs: 11014043865 > dev.ix.0.queue7.txd_head: 1545 > dev.ix.0.queue7.txd_tail: 1545 > dev.ix.0.queue7.tso_tx: 59 > dev.ix.0.queue7.no_tx_dma_setup: 0 > dev.ix.0.queue7.no_desc_avail: 5497 > dev.ix.0.queue7.tx_packets: 15283534142 > dev.ix.0.queue7.rxd_head: 184 > dev.ix.0.queue7.rxd_tail: 182 > dev.ix.0.queue7.rx_packets: 21431994087 > dev.ix.0.queue7.rx_bytes: 57942270182 > dev.ix.0.queue7.rx_copies: 128363306 > dev.ix.0.queue7.lro_queued: 0 > dev.ix.0.queue7.lro_flushed: 0 > dev.ix.0.mac_stats.crc_errs: 268 > dev.ix.0.mac_stats.ill_errs: 33 > dev.ix.0.mac_stats.byte_errs: 55 > dev.ix.0.mac_stats.short_discards: 0 > dev.ix.0.mac_stats.local_faults: 3484 > dev.ix.0.mac_stats.remote_faults: 121 > dev.ix.0.mac_stats.rec_len_errs: 0 > dev.ix.0.mac_stats.xon_txd: 1602713563748 > dev.ix.0.mac_stats.xon_recvd: 0 > dev.ix.0.mac_stats.xoff_txd: 108342810167 > dev.ix.0.mac_stats.xoff_recvd: 0 > dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 > dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 > dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 > dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 > dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 > dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 > dev.ix.0.mac_stats.rx_frames_64: 5356098 > dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 > dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 > dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 > dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 > dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 > dev.ix.0.mac_stats.recv_undersized: 0 > dev.ix.0.mac_stats.recv_fragmented: 0 > dev.ix.0.mac_stats.recv_oversized: 244078 > dev.ix.0.mac_stats.recv_jabberd: 4 > dev.ix.0.mac_stats.management_pkts_rcvd: 0 > dev.ix.0.mac_stats.management_pkts_drpd: 0 > dev.ix.0.mac_stats.checksum_errs: 897344641 > dev.ix.0.mac_stats.good_octets_txd: 126768678455085 > dev.ix.0.mac_stats.total_pkts_txd: 126508073823 > dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 > dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 > dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 > dev.ix.0.mac_stats.management_pkts_txd: 0 > dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 > dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 > dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 > dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 > dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 > dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 > dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version > - 2.5.15 > dev.ix.1.%driver: ix > dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 > dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > subdevice=0x7a11 class=0x020000 > dev.ix.1.%parent: pci129 > dev.ix.1.fc: 3 > dev.ix.1.enable_aim: 1 > dev.ix.1.advertise_speed: 0 > dev.ix.1.dropped: 0 > dev.ix.1.mbuf_defrag_failed: 0 > dev.ix.1.watchdog_events: 0 > dev.ix.1.link_irq: 127925 > dev.ix.1.queue0.interrupt_rate: 11627 > dev.ix.1.queue0.irqs: 6686088831 > dev.ix.1.queue0.txd_head: 1618 > dev.ix.1.queue0.txd_tail: 1620 > dev.ix.1.queue0.tso_tx: 28 > dev.ix.1.queue0.no_tx_dma_setup: 0 > dev.ix.1.queue0.no_desc_avail: 0 > dev.ix.1.queue0.tx_packets: 13527334563 > dev.ix.1.queue0.rxd_head: 1715 > dev.ix.1.queue0.rxd_tail: 1714 > dev.ix.1.queue0.rx_packets: 1503775702 > dev.ix.1.queue0.rx_bytes: 1069295301 > dev.ix.1.queue0.rx_copies: 2983480 > dev.ix.1.queue0.lro_queued: 0 > dev.ix.1.queue0.lro_flushed: 0 > dev.ix.1.queue1.interrupt_rate: 5319 > dev.ix.1.queue1.irqs: 6546967336 > dev.ix.1.queue1.txd_head: 1812 > dev.ix.1.queue1.txd_tail: 1812 > dev.ix.1.queue1.tso_tx: 6 > dev.ix.1.queue1.no_tx_dma_setup: 0 > dev.ix.1.queue1.no_desc_avail: 0 > dev.ix.1.queue1.tx_packets: 13475453794 > dev.ix.1.queue1.rxd_head: 1246 > dev.ix.1.queue1.rxd_tail: 1245 > dev.ix.1.queue1.rx_packets: 1506444917 > dev.ix.1.queue1.rx_bytes: 783064190 > dev.ix.1.queue1.rx_copies: 2881513 > dev.ix.1.queue1.lro_queued: 0 > dev.ix.1.queue1.lro_flushed: 0 > dev.ix.1.queue2.interrupt_rate: 5319 > dev.ix.1.queue2.irqs: 6574615190 > dev.ix.1.queue2.txd_head: 1494 > dev.ix.1.queue2.txd_tail: 1494 > dev.ix.1.queue2.tso_tx: 33 > dev.ix.1.queue2.no_tx_dma_setup: 0 > dev.ix.1.queue2.no_desc_avail: 0 > dev.ix.1.queue2.tx_packets: 13555495169 > dev.ix.1.queue2.rxd_head: 438 > dev.ix.1.queue2.rxd_tail: 437 > dev.ix.1.queue2.rx_packets: 1501380848 > dev.ix.1.queue2.rx_bytes: 1008544082 > dev.ix.1.queue2.rx_copies: 2660960 > dev.ix.1.queue2.lro_queued: 0 > dev.ix.1.queue2.lro_flushed: 0 > dev.ix.1.queue3.interrupt_rate: 5319 > dev.ix.1.queue3.irqs: 6617964401 > dev.ix.1.queue3.txd_head: 1853 > dev.ix.1.queue3.txd_tail: 1855 > dev.ix.1.queue3.tso_tx: 10 > dev.ix.1.queue3.no_tx_dma_setup: 0 > dev.ix.1.queue3.no_desc_avail: 0 > dev.ix.1.queue3.tx_packets: 13561212942 > dev.ix.1.queue3.rxd_head: 429 > dev.ix.1.queue3.rxd_tail: 428 > dev.ix.1.queue3.rx_packets: 1498117903 > dev.ix.1.queue3.rx_bytes: 784881986 > dev.ix.1.queue3.rx_copies: 2695475 > dev.ix.1.queue3.lro_queued: 0 > dev.ix.1.queue3.lro_flushed: 0 > dev.ix.1.queue4.interrupt_rate: 5319 > dev.ix.1.queue4.irqs: 6575752163 > dev.ix.1.queue4.txd_head: 902 > dev.ix.1.queue4.txd_tail: 902 > dev.ix.1.queue4.tso_tx: 5 > dev.ix.1.queue4.no_tx_dma_setup: 0 > dev.ix.1.queue4.no_desc_avail: 0 > dev.ix.1.queue4.tx_packets: 13478514009 > dev.ix.1.queue4.rxd_head: 536 > dev.ix.1.queue4.rxd_tail: 535 > dev.ix.1.queue4.rx_packets: 1476720084 > dev.ix.1.queue4.rx_bytes: 944967171 > dev.ix.1.queue4.rx_copies: 2650672 > dev.ix.1.queue4.lro_queued: 0 > dev.ix.1.queue4.lro_flushed: 0 > dev.ix.1.queue5.interrupt_rate: 10416 > dev.ix.1.queue5.irqs: 6578099670 > dev.ix.1.queue5.txd_head: 1996 > dev.ix.1.queue5.txd_tail: 1996 > dev.ix.1.queue5.tso_tx: 663 > dev.ix.1.queue5.no_tx_dma_setup: 0 > dev.ix.1.queue5.no_desc_avail: 0 > dev.ix.1.queue5.tx_packets: 13516483196 > dev.ix.1.queue5.rxd_head: 1296 > dev.ix.1.queue5.rxd_tail: 1295 > dev.ix.1.queue5.rx_packets: 1496584151 > dev.ix.1.queue5.rx_bytes: 810434347 > dev.ix.1.queue5.rx_copies: 2899315 > dev.ix.1.queue5.lro_queued: 0 > dev.ix.1.queue5.lro_flushed: 0 > dev.ix.1.queue6.interrupt_rate: 5319 > dev.ix.1.queue6.irqs: 6624395782 > dev.ix.1.queue6.txd_head: 1058 > dev.ix.1.queue6.txd_tail: 1058 > dev.ix.1.queue6.tso_tx: 20 > dev.ix.1.queue6.no_tx_dma_setup: 0 > dev.ix.1.queue6.no_desc_avail: 0 > dev.ix.1.queue6.tx_packets: 13491315217 > dev.ix.1.queue6.rxd_head: 1550 > dev.ix.1.queue6.rxd_tail: 1549 > dev.ix.1.queue6.rx_packets: 1510907490 > dev.ix.1.queue6.rx_bytes: 719914325 > dev.ix.1.queue6.rx_copies: 2712955 > dev.ix.1.queue6.lro_queued: 0 > dev.ix.1.queue6.lro_flushed: 0 > dev.ix.1.queue7.interrupt_rate: 29411 > dev.ix.1.queue7.irqs: 6573304834 > dev.ix.1.queue7.txd_head: 784 > dev.ix.1.queue7.txd_tail: 786 > dev.ix.1.queue7.tso_tx: 2 > dev.ix.1.queue7.no_tx_dma_setup: 0 > dev.ix.1.queue7.no_desc_avail: 0 > dev.ix.1.queue7.tx_packets: 13587681458 > dev.ix.1.queue7.rxd_head: 1489 > dev.ix.1.queue7.rxd_tail: 1488 > dev.ix.1.queue7.rx_packets: 1504712031 > dev.ix.1.queue7.rx_bytes: 1216803328 > dev.ix.1.queue7.rx_copies: 2976103 > dev.ix.1.queue7.lro_queued: 0 > dev.ix.1.queue7.lro_flushed: 0 > dev.ix.1.mac_stats.crc_errs: 0 > dev.ix.1.mac_stats.ill_errs: 0 > dev.ix.1.mac_stats.byte_errs: 0 > dev.ix.1.mac_stats.short_discards: 0 > dev.ix.1.mac_stats.local_faults: 0 > dev.ix.1.mac_stats.remote_faults: 12 > dev.ix.1.mac_stats.rec_len_errs: 0 > dev.ix.1.mac_stats.xon_txd: 1714791401322 > dev.ix.1.mac_stats.xon_recvd: 0 > dev.ix.1.mac_stats.xoff_txd: 41095995010 > dev.ix.1.mac_stats.xoff_recvd: 0 > dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 > dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 > dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 > dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 > dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 > dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 > dev.ix.1.mac_stats.rx_frames_64: 73447 > dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 > dev.ix.1.mac_stats.rx_frames_128_255: 478134642 > dev.ix.1.mac_stats.rx_frames_256_511: 232994605 > dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 > dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 > dev.ix.1.mac_stats.recv_undersized: 0 > dev.ix.1.mac_stats.recv_fragmented: 0 > dev.ix.1.mac_stats.recv_oversized: 0 > dev.ix.1.mac_stats.recv_jabberd: 0 > dev.ix.1.mac_stats.management_pkts_rcvd: 0 > dev.ix.1.mac_stats.management_pkts_drpd: 0 > dev.ix.1.mac_stats.checksum_errs: 85432477 > dev.ix.1.mac_stats.good_octets_txd: 110334688606644 > dev.ix.1.mac_stats.total_pkts_txd: 108193846110 > dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 > dev.ix.1.mac_stats.bcast_pkts_txd: 595976 > dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 > dev.ix.1.mac_stats.management_pkts_txd: 0 > dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 > dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 > dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 > dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 > dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 > dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 > > # cat /var/run/dmesg.boot > > Copyright (c) 1992-2014 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 > root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e > Stepping = 4 > Features=0xbfebfbff > > Features2=0x7fbee3ff > > AMD Features=0x2c100800 > AMD Features2=0x1 > Structured Extended Features=0x281 > VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > TSC: P-state invariant, performance statistics > real memory = 17179869184 (16384 MB) > avail memory = 16515358720 (15750 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs > FreeBSD/SMP: 2 package(s) x 6 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 6 > cpu4 (AP): APIC ID: 8 > cpu5 (AP): APIC ID: 10 > cpu6 (AP): APIC ID: 32 > cpu7 (AP): APIC ID: 34 > cpu8 (AP): APIC ID: 36 > cpu9 (AP): APIC ID: 38 > cpu10 (AP): APIC ID: 40 > cpu11 (AP): APIC ID: 42 > ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, > using default 16 (20130823/tbfadt-682) > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > ioapic2 irqs 48-71 on motherboard > kbd1 at kbdmux0 > random: initialized > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: reservation of 0, 9d000 (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > cpu4: on acpi0 > cpu5: on acpi0 > cpu6: on acpi0 > cpu7: on acpi0 > cpu8: on acpi0 > cpu9: on acpi0 > cpu10: on acpi0 > cpu11: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 350 > Event timer "HPET1" frequency 14318180 Hz quality 340 > Event timer "HPET2" frequency 14318180 Hz quality 340 > Event timer "HPET3" frequency 14318180 Hz quality 340 > Event timer "HPET4" frequency 14318180 Hz quality 340 > Event timer "HPET5" frequency 14318180 Hz quality 340 > Event timer "HPET6" frequency 14318180 Hz quality 340 > Event timer "HPET7" frequency 14318180 Hz quality 340 > atrtc0: port 0x70-0x77 irq 8 on acpi0 > atrtc0: Warning: Couldn't map I/O. > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 47 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: irq 47 at device 1.1 on pci0 > pci2: on pcib2 > igb0: port > 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 > at device 0.0 on pci2 > igb0: Using MSIX interrupts with 9 vectors > igb0: Ethernet address: 00:1e:67:9a:d5:88 > 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 > igb0: Bound queue 4 to cpu 4 > igb0: Bound queue 5 to cpu 5 > igb0: Bound queue 6 to cpu 6 > igb0: Bound queue 7 to cpu 7 > igb1: port > 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 > at device 0.1 on pci2 > igb1: Using MSIX interrupts with 9 vectors > igb1: Ethernet address: 00:1e:67:9a:d5:89 > igb1: Bound queue 0 to cpu 8 > igb1: Bound queue 1 to cpu 9 > igb1: Bound queue 2 to cpu 10 > igb1: Bound queue 3 to cpu 11 > igb1: Bound queue 4 to cpu 0 > igb1: Bound queue 5 to cpu 1 > igb1: Bound queue 6 to cpu 2 > igb1: Bound queue 7 to cpu 3 > igb2: port > 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 > at device 0.2 on pci2 > igb2: Using MSIX interrupts with 9 vectors > igb2: Ethernet address: 00:1e:67:9a:d5:8a > igb2: Bound queue 0 to cpu 4 > igb2: Bound queue 1 to cpu 5 > igb2: Bound queue 2 to cpu 6 > igb2: Bound queue 3 to cpu 7 > igb2: Bound queue 4 to cpu 8 > igb2: Bound queue 5 to cpu 9 > igb2: Bound queue 6 to cpu 10 > igb2: Bound queue 7 to cpu 11 > igb3: port > 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 > at device 0.3 on pci2 > igb3: Using MSIX interrupts with 9 vectors > igb3: Ethernet address: 00:1e:67:9a:d5:8b > igb3: Bound queue 0 to cpu 0 > igb3: Bound queue 1 to cpu 1 > igb3: Bound queue 2 to cpu 2 > igb3: Bound queue 3 to cpu 3 > igb3: Bound queue 4 to cpu 4 > igb3: Bound queue 5 to cpu 5 > igb3: Bound queue 6 to cpu 6 > igb3: Bound queue 7 to cpu 7 > pcib3: irq 47 at device 2.0 on pci0 > pci4: on pcib3 > igb4: mem > 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 > igb4: Using MSIX interrupts with 9 vectors > igb4: Ethernet address: a0:36:9f:37:82:7e > igb4: Bound queue 0 to cpu 8 > igb4: Bound queue 1 to cpu 9 > igb4: Bound queue 2 to cpu 10 > igb4: Bound queue 3 to cpu 11 > igb4: Bound queue 4 to cpu 0 > igb4: Bound queue 5 to cpu 1 > igb4: Bound queue 6 to cpu 2 > igb4: Bound queue 7 to cpu 3 > igb5: mem > 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 > igb5: Using MSIX interrupts with 9 vectors > igb5: Ethernet address: a0:36:9f:37:82:7f > igb5: Bound queue 0 to cpu 4 > igb5: Bound queue 1 to cpu 5 > igb5: Bound queue 2 to cpu 6 > igb5: Bound queue 3 to cpu 7 > igb5: Bound queue 4 to cpu 8 > igb5: Bound queue 5 to cpu 9 > igb5: Bound queue 6 to cpu 10 > igb5: Bound queue 7 to cpu 11 > pcib4: irq 16 at device 3.0 on pci0 > pci6: on pcib4 > igb6: mem > 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 > igb6: Using MSIX interrupts with 9 vectors > igb6: Ethernet address: a0:36:9f:37:82:8a > igb6: Bound queue 0 to cpu 0 > igb6: Bound queue 1 to cpu 1 > igb6: Bound queue 2 to cpu 2 > igb6: Bound queue 3 to cpu 3 > igb6: Bound queue 4 to cpu 4 > igb6: Bound queue 5 to cpu 5 > igb6: Bound queue 6 to cpu 6 > igb6: Bound queue 7 to cpu 7 > igb7: mem > 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 > igb7: Using MSIX interrupts with 9 vectors > igb7: Ethernet address: a0:36:9f:37:82:8b > igb7: Bound queue 0 to cpu 8 > igb7: Bound queue 1 to cpu 9 > igb7: Bound queue 2 to cpu 10 > igb7: Bound queue 3 to cpu 11 > igb7: Bound queue 4 to cpu 0 > igb7: Bound queue 5 to cpu 1 > igb7: Bound queue 6 to cpu 2 > igb7: Bound queue 7 to cpu 3 > pcib5: irq 16 at device 17.0 on pci0 > pci8: on pcib5 > pci0: at device 22.0 (no driver attached) > pci0: at device 22.1 (no driver attached) > ehci0: mem 0xd1220000-0xd12203ff > irq 22 at device 26.0 on pci0 > usbus0: EHCI version 1.0 > usbus0 on ehci0 > pcib6: irq 16 at device 28.0 on pci0 > pci9: on pcib6 > pcib7: irq 17 at device 28.5 on pci0 > pci10: on pcib7 > pci10: at device 0.0 (no driver attached) > pcib8: irq 19 at device 28.7 on pci0 > pci11: on pcib8 > vgapci0: mem > 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq > 19 at device 0.0 on pci11 > vgapci0: Boot video device > ehci1: mem 0xd1210000-0xd12103ff > irq 20 at device 29.0 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci1 > pcib9: at device 30.0 on pci0 > pci12: on pcib9 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f > mem 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > ahciem0: on ahci0 > pcib10: on acpi0 > pci128: on pcib10 > pcib11: irq 71 at device 1.0 on pci128 > pci129: on pcib11 > ix0: > port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff irq > 50 at device 0.0 on pci129 > ix0: Using MSIX interrupts with 9 vectors > ix0: Ethernet address: 00:1b:21:89:25:32 > ix0: PCI Express Bus: Speed 5.0GT/s Width x8 > ix1: > port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff irq > 52 at device 0.1 on pci129 > ix1: Using MSIX interrupts with 9 vectors > ix1: Ethernet address: 00:1b:21:89:25:33 > ix1: PCI Express Bus: Speed 5.0GT/s Width x8 > pcib12: irq 71 at device 2.0 on pci128 > pci131: on pcib12 > pcib13: irq 71 at device 3.0 on pci128 > pci132: on pcib13 > acpi_button0: on acpi0 > pcib14: on acpi0 > pci127: on pcib14 > pcib15: on acpi0 > pci255: on pcib15 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > orm0: at iomem > 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff > on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > est0: on cpu0 > p4tcc0: on cpu0 > est1: on cpu1 > p4tcc1: on cpu1 > est2: on cpu2 > p4tcc2: on cpu2 > est3: on cpu3 > p4tcc3: on cpu3 > est4: on cpu4 > p4tcc4: on cpu4 > est5: on cpu5 > p4tcc5: on cpu5 > est6: on cpu6 > p4tcc6: on cpu6 > est7: on cpu7 > p4tcc7: on cpu7 > est8: on cpu8 > p4tcc8: on cpu8 > est9: on cpu9 > p4tcc9: on cpu9 > est10: on cpu10 > p4tcc10: on cpu10 > est11: on cpu11 > p4tcc11: on cpu11 > random: unblocking device. > usbus0: 480Mbps High Speed USB v2.0 > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to > accept, logging disabled > usbus1: 480Mbps High Speed USB v2.0 > ugen1.1: at usbus1 > uhub0: on usbus1 > ugen0.1: at usbus0 > uhub1: on usbus0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-9 SATA 3.x device > ada0: Serial Number S1D5NSAF687077K > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) > ada0: quirks=0x1<4K> > ada0: Previously was known as ad4 > ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > SMP: AP CPU #6 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #11 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #9 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #10 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #8 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #7 Launched! > Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 > Root mount waiting for: usbus1 usbus0 > uhub1: 2 ports with 2 removable, self powered > uhub0: 2 ports with 2 removable, self powered > Root mount waiting for: usbus1 usbus0 > ugen1.2: at usbus1 > uhub2: 2> on usbus1 > ugen0.2: at usbus0 > uhub3: 2> on usbus0 > Root mount waiting for: usbus1 usbus0 > uhub3: 6 ports with 6 removable, self powered > uhub2: 8 ports with 8 removable, self powered > ugen1.3: at usbus1 > ukbd0: on usbus1 > kbd0 at ukbd0 > Root mount waiting for: usbus1 > ugen1.4: at usbus1 > ukbd1: on usbus1 > kbd2 at ukbd1 > Trying to mount root from ufs:/dev/label/rootfs [rw]... > lagg0: IPv6 addresses on igb6 have been removed before adding it as a > member to prevent IPv6 address scope violation. > lagg0: IPv6 addresses on igb7 have been removed before adding it as a > member to prevent IPv6 address scope violation. > ums0: on usbus1 > ums0: 3 buttons and [Z] coordinates ID=0 > uhid0: on usbus1 > > # uname -a > FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 > r274375: Tue Nov 11 10:24:44 BRST 2014 > root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 > > [1] https://calomel.org/freebsd_network_tuning.html > [2] http://ark.intel.com/products/63157 > [3] > http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 > [4] http://ark.intel.com/products/59062/ > > Please I need a help! and sorry my english :) > > _______________________________________________ > 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 Sun Nov 30 17:00:32 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B20580F for ; Sun, 30 Nov 2014 17:00:32 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48BD68D2 for ; Sun, 30 Nov 2014 17:00:31 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id sAUH0UoV001716; Sun, 30 Nov 2014 09:00:30 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id sAUH0T63001715; Sun, 30 Nov 2014 09:00:29 -0800 (PST) (envelope-from david) Date: Sun, 30 Nov 2014 09:00:29 -0800 From: David Wolfskill To: =?iso-8859-1?Q?B=F6rje?= Josefsson Subject: Re: How do I use net-mgmt/unifi{2,3,4} for Ubiquity UAP-PRO? Message-ID: <20141130170029.GB1056@albert.catwhisker.org> Reply-To: David Wolfskill , net@freebsd.org References: <20141130010215.GP1228@albert.catwhisker.org> <547B081C.3000300@sunet.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <547B081C.3000300@sunet.se> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 17:00:32 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 30, 2014 at 01:05:48PM +0100, B=F6rje Josefsson wrote: > David Wolfskill wrote: > >=20 > > Given that this is a new device, I figured I'd try unifi4. It > > installed... but now what? It doesn't seem to have installed any > > executables. And (semi-)blindly hacking yields: >=20 > Have you tried to launch a web browser towards 127.0.0.1:8443 (or the > host you installed the stuff on) - that's how I am managing my UniFi:s > running on MacOS. > ... Well... no; that hadn't occurred to me. :-} But given that hint, I tried the "java -jar lib/ace.jar start" thing again, gave it a few seconds to get running, and then a "sockstat -4l" showed: USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS = =20 =2E.. david mongod 3731 5 tcp4 127.0.0.1:27117 *:* david java 3699 70 tcp4 *:8080 *:* david java 3699 71 tcp4 *:8443 *:* david java 3699 72 tcp4 *:8880 *:* david java 3699 73 tcp4 *:8843 *:* david java 3699 78 udp4 172.17.1.253:31010 *:* david java 3699 79 udp4 *:10001 *:* david java 3699 80 udp4 *:3478 *:* =2E... (in addition to the services shown before I fired up the "java..." invocation). That done, directing a Web browser to caused a redirection to , and ... Things started Happening. I think this is progress: Thank you! Peace, david --=20 David H. Wolfskill david@catwhisker.org Actions have consequences ... as do inactions. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUe00sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7eCYP/j48Z9NxrS2tyKwZXrHPM4jb RjiE8wtCtmv8EF7D/WydXN6hLOrWMN6PjrgXQx0PI5mJ/vYww+YpJ7eiqJXCQaT/ KjdRYvE9qdffvYpfzsvul0ITH09yZPi9i4NGNn2XV8ARV/bUp6hxKmCq1jHU+EnY ZxbvKi1W3zQ+olRjY+TMF+6V4XM0Sw9ZHsEw6Qwp3FdsZg5BA1UPYdoc3TiYNxYQ VxvmBHBjPAFanvPCLMe6DIHeOgzul1ISF1obf8S4aYqx5OSMt8kfxORMAwLszvRa uG/uzcr8BzmLL31K1PCf+7BCogVI6GU2LS73qQTwxes6zV9HRMiH0mj/sXtxUiTT +yIi31jzJ2heabDc2W8DK45j39wotixPTUOZh/aKKEwWZ9ifNk9t9Mk0I8LCNYIb 1ggMostOJPwoAeX142kkfTn4fAjZGWTQaevX0iRZGiV2nbd09RtSI/tkFuHvc4sh OUQwKjjoF0jzCe/cIoMgaL+uk4uwfTQXa26y5c9QfH4ul9+IgMlyXIJky0SxkCrd d49cmpwBejTIy9pGQJtgryP0FokQo/AxxpH0p3MIQ7VBEZ67CpldkLBQHLA+QDoH rUkNHI27Buq+NXqRX05IGBlSnzbkNrrgwCB8C4m+ap+NROqIUdwLk+bhkMzmCAVD s3XIaS4/ZCWKmEoLRMyT =bOYy -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 18:01:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D948FA7; Sun, 30 Nov 2014 18:01:48 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72392EC6; Sun, 30 Nov 2014 18:01:47 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so15207802wiw.16 for ; Sun, 30 Nov 2014 10:01:45 -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=t6RH1pANm1c/BKJ5TaZ+H3hJ+r2dv2bxQuIttCU1EHY=; b=ZHmbPZVbH3zfJJl+Qn96UojYvtcQkw7bwWFJRooznmnLYg3ghxUqvOqVuIVx6pgWIb na/34PZJcihcRkD23NZpY3LENMFqKXVNOFg80hI5h3H+cjx7K7uOZFkAncmJmLrdpHrS NoLf7bxfKNhL5xrSyo9uSgimswnNAYgoJouYtlepCWX53T6euMAfgP0qyAfOcj47UiEi 7shBG97ZiXqJ34MUQi4x2gCdzwNulFu+V4AidLSRvsqqhFQBFf8mNaacfEzrg4moIdSu XMKIK/zALDAve+Sd9syQLVIysmhLMfZaUbjWaeYCu3S0UDpyvv8Mj4B6bgGb0vKnvfu4 Mi6Q== MIME-Version: 1.0 X-Received: by 10.194.24.103 with SMTP id t7mr67335696wjf.15.1417370505820; Sun, 30 Nov 2014 10:01:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Sun, 30 Nov 2014 10:01:45 -0800 (PST) In-Reply-To: <547B4033.1060504@FreeBSD.org> References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> Date: Sun, 30 Nov 2014 10:01:45 -0800 X-Google-Sender-Auth: NRfhoDfXHsjdCtJ9-xSl16P64Vg Message-ID: Subject: Re: Problems with Intel X520-SR2 From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net >> FreeBSD Net" , Marcelo Gondim X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 18:01:48 -0000 Your link_irq value is way too high. I think you're exposing some unhandled corner case in the driver (as I had this issue when I had some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe driver isn't getting link events. My test setup at home has link_irq=1 on both sides, and it runs full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for RSS testing for weeks at a time. I have no issues and no hiccups. So, I think there's two problems: * you're still seeing way too many link_irq events; and * i think there's some bad handling when it comes to link_irq events. I wonder if we're still clearing some of the interrupt register bits incorrectly in ixgbe_msix_link(). -adrian -adrian On 30 November 2014 at 08:05, Alexander V. Chernikov wrote: > On 30.11.2014 18:47, Marcelo Gondim wrote: >> >> Dear, >> >> Unfortunately I have more options to resolve this problem I'm having with >> Intel X520-SR2. Have we changed the X520, we exchange the optical cords, >> exchanged optical modules, we changed the entire server, we reduce the >> temperature inside the equipment, made some attempts to tunning the site >> calomel[1]. We spend a lot of money and do not solve the problem. >> >> What happens is that when there is a traffic above 1.2Gbps with PPS above >> 700kpps in sometimes almost daily there is a lock in two 10GbE ports the >> X520-SR interface. Where I am obliged to leave a script running in the >> background doing just that: > > What does this "lock" looks like? > Do you using jumbo frames? > Is this IPv4 or IPv4+IPv6 ? > Can you share "netstat -m" output? > Do you use ipfw dynamic states? > Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? > > dev.ix.0.queue0.no_desc_avail: 3322269 > dev.ix.0.queue1.no_desc_avail: 5254761 > > Looks suspicious. Either you're running out of mbufs due to total mbuf > number is small, or system is very busy sometimes. > What does you "top -HPSzs1" output look like? > > >> >> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up >> >> Made it back to the interface function normally. It's already so for >> months and have not tried the latest driver from Intel because I do not see >> anything related to this issue. >> >> These 2-port 10GbE are my backbone linking the four cities that attend to >> our main router. One is backup to other but when the problem occurs, the two >> ports stop working and at the moment I have a break in my Internet >> >> I can only conclude that the problem is one of the things below: >> >> 1 - Intel Interface X520-SR2 has a problem with certain types of traffic >> and then hangs. >> 2 - The ixgbe driver has a bug that is causing it. >> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >> would be a regression and the equipment is very far away from me if I need >> to move me. >> >> Honestly I'm almost going on a Juniper closed solution. I would not want >> to do this because I love FreeBSD and I can not believe that he does not >> support a 2.7Gbps traffic, which is my peak traffic without getting having >> these falls. My hardware today is this: >> >> hw.machine: amd64 >> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >> hw.ncpu: 12 >> hw.byteorder: 1234 >> hw.physmem: 17083641856 >> hw.usermem: 15741001728 >> >> Hardware all Intel with motherboard S2600COE [2] and with network >> interfaces offboard: >> >> 1x - X520-SR2 [3] >> 2x - I350-T2 [4] >> >> My loader.conf: >> >> loader_logo="beastie" >> if_lagg_load="YES" >> speaker_load="YES" >> aio_load="YES" >> autoboot_delay="5" >> net.fibs=1 >> >> My sysctl.conf: >> >> net.inet.ip.forwarding=1 >> net.inet.ip.fastforwarding=1 >> net.inet6.ip6.forwarding=1 >> kern.ipc.somaxconn=4096 >> net.inet.tcp.syncookies=1 >> net.inet.ip.redirect=1 >> net.inet.ip.accept_sourceroute=0 >> net.inet.ip.sourceroute=0 >> net.inet.tcp.drop_synfin=1 >> net.inet.udp.blackhole=1 >> net.inet.tcp.blackhole=2 >> security.bsd.see_other_uids=0 >> net.inet.ip.fw.dyn_buckets=65536 >> net.inet.ip.fw.dyn_max=65536 >> hw.intr_storm_threshold=9000 >> net.inet.ip.dummynet.pipe_slot_limit=800 >> net.inet.icmp.icmplim=2000 >> >> # sysctl dev.ix. >> dev.ix.%parent: >> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - >> 2.5.15 >> dev.ix.0.%driver: ix >> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >> subdevice=0x7a11 class=0x020000 >> dev.ix.0.%parent: pci129 >> dev.ix.0.fc: 3 >> dev.ix.0.enable_aim: 1 >> dev.ix.0.advertise_speed: 0 >> dev.ix.0.dropped: 0 >> dev.ix.0.mbuf_defrag_failed: 0 >> dev.ix.0.watchdog_events: 0 >> dev.ix.0.link_irq: 193783 >> dev.ix.0.queue0.interrupt_rate: 50000 >> dev.ix.0.queue0.irqs: 12029604413 >> dev.ix.0.queue0.txd_head: 1517 >> dev.ix.0.queue0.txd_tail: 1517 >> dev.ix.0.queue0.tso_tx: 85 >> dev.ix.0.queue0.no_tx_dma_setup: 0 >> dev.ix.0.queue0.no_desc_avail: 3322269 >> dev.ix.0.queue0.tx_packets: 15392658033 >> dev.ix.0.queue0.rxd_head: 709 >> dev.ix.0.queue0.rxd_tail: 707 >> dev.ix.0.queue0.rx_packets: 21762427837 >> dev.ix.0.queue0.rx_bytes: 56918345381 >> dev.ix.0.queue0.rx_copies: 124289013 >> dev.ix.0.queue0.lro_queued: 0 >> dev.ix.0.queue0.lro_flushed: 0 >> dev.ix.0.queue1.interrupt_rate: 500000 >> dev.ix.0.queue1.irqs: 11482146431 >> dev.ix.0.queue1.txd_head: 731 >> dev.ix.0.queue1.txd_tail: 731 >> dev.ix.0.queue1.tso_tx: 1442 >> dev.ix.0.queue1.no_tx_dma_setup: 0 >> dev.ix.0.queue1.no_desc_avail: 5254761 >> dev.ix.0.queue1.tx_packets: 15835062632 >> dev.ix.0.queue1.rxd_head: 685 >> dev.ix.0.queue1.rxd_tail: 681 >> dev.ix.0.queue1.rx_packets: 21220715209 >> dev.ix.0.queue1.rx_bytes: 54351679461 >> dev.ix.0.queue1.rx_copies: 120833356 >> dev.ix.0.queue1.lro_queued: 0 >> dev.ix.0.queue1.lro_flushed: 0 >> dev.ix.0.queue2.interrupt_rate: 5319 >> dev.ix.0.queue2.irqs: 11532560324 >> dev.ix.0.queue2.txd_head: 501 >> dev.ix.0.queue2.txd_tail: 501 >> dev.ix.0.queue2.tso_tx: 2474 >> dev.ix.0.queue2.no_tx_dma_setup: 0 >> dev.ix.0.queue2.no_desc_avail: 429244 >> dev.ix.0.queue2.tx_packets: 15772209238 >> dev.ix.0.queue2.rxd_head: 246 >> dev.ix.0.queue2.rxd_tail: 244 >> dev.ix.0.queue2.rx_packets: 21408648299 >> dev.ix.0.queue2.rx_bytes: 56862350194 >> dev.ix.0.queue2.rx_copies: 124973551 >> dev.ix.0.queue2.lro_queued: 0 >> dev.ix.0.queue2.lro_flushed: 0 >> dev.ix.0.queue3.interrupt_rate: 20833 >> dev.ix.0.queue3.irqs: 11557466322 >> dev.ix.0.queue3.txd_head: 773 >> dev.ix.0.queue3.txd_tail: 773 >> dev.ix.0.queue3.tso_tx: 40 >> dev.ix.0.queue3.no_tx_dma_setup: 0 >> dev.ix.0.queue3.no_desc_avail: 665620 >> dev.ix.0.queue3.tx_packets: 16479111658 >> dev.ix.0.queue3.rxd_head: 1858 >> dev.ix.0.queue3.rxd_tail: 1854 >> dev.ix.0.queue3.rx_packets: 21412821769 >> dev.ix.0.queue3.rx_bytes: 52796089467 >> dev.ix.0.queue3.rx_copies: 127385950 >> dev.ix.0.queue3.lro_queued: 0 >> dev.ix.0.queue3.lro_flushed: 0 >> dev.ix.0.queue4.interrupt_rate: 11363 >> dev.ix.0.queue4.irqs: 10824852635 >> dev.ix.0.queue4.txd_head: 1711 >> dev.ix.0.queue4.txd_tail: 1713 >> dev.ix.0.queue4.tso_tx: 581 >> dev.ix.0.queue4.no_tx_dma_setup: 0 >> dev.ix.0.queue4.no_desc_avail: 115346803 >> dev.ix.0.queue4.tx_packets: 16100396810 >> dev.ix.0.queue4.rxd_head: 244 >> dev.ix.0.queue4.rxd_tail: 243 >> dev.ix.0.queue4.rx_packets: 21240995210 >> dev.ix.0.queue4.rx_bytes: 58726730771 >> dev.ix.0.queue4.rx_copies: 124872141 >> dev.ix.0.queue4.lro_queued: 0 >> dev.ix.0.queue4.lro_flushed: 0 >> dev.ix.0.queue5.interrupt_rate: 500000 >> dev.ix.0.queue5.irqs: 10955464761 >> dev.ix.0.queue5.txd_head: 75 >> dev.ix.0.queue5.txd_tail: 77 >> dev.ix.0.queue5.tso_tx: 1758 >> dev.ix.0.queue5.no_tx_dma_setup: 0 >> dev.ix.0.queue5.no_desc_avail: 4759 >> dev.ix.0.queue5.tx_packets: 16267888038 >> dev.ix.0.queue5.rxd_head: 905 >> dev.ix.0.queue5.rxd_tail: 904 >> dev.ix.0.queue5.rx_packets: 21381144028 >> dev.ix.0.queue5.rx_bytes: 61800291690 >> dev.ix.0.queue5.rx_copies: 129684798 >> dev.ix.0.queue5.lro_queued: 0 >> dev.ix.0.queue5.lro_flushed: 0 >> dev.ix.0.queue6.interrupt_rate: 33333 >> dev.ix.0.queue6.irqs: 11081350674 >> dev.ix.0.queue6.txd_head: 1744 >> dev.ix.0.queue6.txd_tail: 1746 >> dev.ix.0.queue6.tso_tx: 38 >> dev.ix.0.queue6.no_tx_dma_setup: 0 >> dev.ix.0.queue6.no_desc_avail: 18381 >> dev.ix.0.queue6.tx_packets: 15376961749 >> dev.ix.0.queue6.rxd_head: 1783 >> dev.ix.0.queue6.rxd_tail: 1782 >> dev.ix.0.queue6.rx_packets: 21381814216 >> dev.ix.0.queue6.rx_bytes: 56828960117 >> dev.ix.0.queue6.rx_copies: 130194429 >> dev.ix.0.queue6.lro_queued: 0 >> dev.ix.0.queue6.lro_flushed: 0 >> dev.ix.0.queue7.interrupt_rate: 5319 >> dev.ix.0.queue7.irqs: 11014043865 >> dev.ix.0.queue7.txd_head: 1545 >> dev.ix.0.queue7.txd_tail: 1545 >> dev.ix.0.queue7.tso_tx: 59 >> dev.ix.0.queue7.no_tx_dma_setup: 0 >> dev.ix.0.queue7.no_desc_avail: 5497 >> dev.ix.0.queue7.tx_packets: 15283534142 >> dev.ix.0.queue7.rxd_head: 184 >> dev.ix.0.queue7.rxd_tail: 182 >> dev.ix.0.queue7.rx_packets: 21431994087 >> dev.ix.0.queue7.rx_bytes: 57942270182 >> dev.ix.0.queue7.rx_copies: 128363306 >> dev.ix.0.queue7.lro_queued: 0 >> dev.ix.0.queue7.lro_flushed: 0 >> dev.ix.0.mac_stats.crc_errs: 268 >> dev.ix.0.mac_stats.ill_errs: 33 >> dev.ix.0.mac_stats.byte_errs: 55 >> dev.ix.0.mac_stats.short_discards: 0 >> dev.ix.0.mac_stats.local_faults: 3484 >> dev.ix.0.mac_stats.remote_faults: 121 >> dev.ix.0.mac_stats.rec_len_errs: 0 >> dev.ix.0.mac_stats.xon_txd: 1602713563748 >> dev.ix.0.mac_stats.xon_recvd: 0 >> dev.ix.0.mac_stats.xoff_txd: 108342810167 >> dev.ix.0.mac_stats.xoff_recvd: 0 >> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >> dev.ix.0.mac_stats.rx_frames_64: 5356098 >> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >> dev.ix.0.mac_stats.recv_undersized: 0 >> dev.ix.0.mac_stats.recv_fragmented: 0 >> dev.ix.0.mac_stats.recv_oversized: 244078 >> dev.ix.0.mac_stats.recv_jabberd: 4 >> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >> dev.ix.0.mac_stats.management_pkts_drpd: 0 >> dev.ix.0.mac_stats.checksum_errs: 897344641 >> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >> dev.ix.0.mac_stats.management_pkts_txd: 0 >> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - >> 2.5.15 >> dev.ix.1.%driver: ix >> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >> subdevice=0x7a11 class=0x020000 >> dev.ix.1.%parent: pci129 >> dev.ix.1.fc: 3 >> dev.ix.1.enable_aim: 1 >> dev.ix.1.advertise_speed: 0 >> dev.ix.1.dropped: 0 >> dev.ix.1.mbuf_defrag_failed: 0 >> dev.ix.1.watchdog_events: 0 >> dev.ix.1.link_irq: 127925 >> dev.ix.1.queue0.interrupt_rate: 11627 >> dev.ix.1.queue0.irqs: 6686088831 >> dev.ix.1.queue0.txd_head: 1618 >> dev.ix.1.queue0.txd_tail: 1620 >> dev.ix.1.queue0.tso_tx: 28 >> dev.ix.1.queue0.no_tx_dma_setup: 0 >> dev.ix.1.queue0.no_desc_avail: 0 >> dev.ix.1.queue0.tx_packets: 13527334563 >> dev.ix.1.queue0.rxd_head: 1715 >> dev.ix.1.queue0.rxd_tail: 1714 >> dev.ix.1.queue0.rx_packets: 1503775702 >> dev.ix.1.queue0.rx_bytes: 1069295301 >> dev.ix.1.queue0.rx_copies: 2983480 >> dev.ix.1.queue0.lro_queued: 0 >> dev.ix.1.queue0.lro_flushed: 0 >> dev.ix.1.queue1.interrupt_rate: 5319 >> dev.ix.1.queue1.irqs: 6546967336 >> dev.ix.1.queue1.txd_head: 1812 >> dev.ix.1.queue1.txd_tail: 1812 >> dev.ix.1.queue1.tso_tx: 6 >> dev.ix.1.queue1.no_tx_dma_setup: 0 >> dev.ix.1.queue1.no_desc_avail: 0 >> dev.ix.1.queue1.tx_packets: 13475453794 >> dev.ix.1.queue1.rxd_head: 1246 >> dev.ix.1.queue1.rxd_tail: 1245 >> dev.ix.1.queue1.rx_packets: 1506444917 >> dev.ix.1.queue1.rx_bytes: 783064190 >> dev.ix.1.queue1.rx_copies: 2881513 >> dev.ix.1.queue1.lro_queued: 0 >> dev.ix.1.queue1.lro_flushed: 0 >> dev.ix.1.queue2.interrupt_rate: 5319 >> dev.ix.1.queue2.irqs: 6574615190 >> dev.ix.1.queue2.txd_head: 1494 >> dev.ix.1.queue2.txd_tail: 1494 >> dev.ix.1.queue2.tso_tx: 33 >> dev.ix.1.queue2.no_tx_dma_setup: 0 >> dev.ix.1.queue2.no_desc_avail: 0 >> dev.ix.1.queue2.tx_packets: 13555495169 >> dev.ix.1.queue2.rxd_head: 438 >> dev.ix.1.queue2.rxd_tail: 437 >> dev.ix.1.queue2.rx_packets: 1501380848 >> dev.ix.1.queue2.rx_bytes: 1008544082 >> dev.ix.1.queue2.rx_copies: 2660960 >> dev.ix.1.queue2.lro_queued: 0 >> dev.ix.1.queue2.lro_flushed: 0 >> dev.ix.1.queue3.interrupt_rate: 5319 >> dev.ix.1.queue3.irqs: 6617964401 >> dev.ix.1.queue3.txd_head: 1853 >> dev.ix.1.queue3.txd_tail: 1855 >> dev.ix.1.queue3.tso_tx: 10 >> dev.ix.1.queue3.no_tx_dma_setup: 0 >> dev.ix.1.queue3.no_desc_avail: 0 >> dev.ix.1.queue3.tx_packets: 13561212942 >> dev.ix.1.queue3.rxd_head: 429 >> dev.ix.1.queue3.rxd_tail: 428 >> dev.ix.1.queue3.rx_packets: 1498117903 >> dev.ix.1.queue3.rx_bytes: 784881986 >> dev.ix.1.queue3.rx_copies: 2695475 >> dev.ix.1.queue3.lro_queued: 0 >> dev.ix.1.queue3.lro_flushed: 0 >> dev.ix.1.queue4.interrupt_rate: 5319 >> dev.ix.1.queue4.irqs: 6575752163 >> dev.ix.1.queue4.txd_head: 902 >> dev.ix.1.queue4.txd_tail: 902 >> dev.ix.1.queue4.tso_tx: 5 >> dev.ix.1.queue4.no_tx_dma_setup: 0 >> dev.ix.1.queue4.no_desc_avail: 0 >> dev.ix.1.queue4.tx_packets: 13478514009 >> dev.ix.1.queue4.rxd_head: 536 >> dev.ix.1.queue4.rxd_tail: 535 >> dev.ix.1.queue4.rx_packets: 1476720084 >> dev.ix.1.queue4.rx_bytes: 944967171 >> dev.ix.1.queue4.rx_copies: 2650672 >> dev.ix.1.queue4.lro_queued: 0 >> dev.ix.1.queue4.lro_flushed: 0 >> dev.ix.1.queue5.interrupt_rate: 10416 >> dev.ix.1.queue5.irqs: 6578099670 >> dev.ix.1.queue5.txd_head: 1996 >> dev.ix.1.queue5.txd_tail: 1996 >> dev.ix.1.queue5.tso_tx: 663 >> dev.ix.1.queue5.no_tx_dma_setup: 0 >> dev.ix.1.queue5.no_desc_avail: 0 >> dev.ix.1.queue5.tx_packets: 13516483196 >> dev.ix.1.queue5.rxd_head: 1296 >> dev.ix.1.queue5.rxd_tail: 1295 >> dev.ix.1.queue5.rx_packets: 1496584151 >> dev.ix.1.queue5.rx_bytes: 810434347 >> dev.ix.1.queue5.rx_copies: 2899315 >> dev.ix.1.queue5.lro_queued: 0 >> dev.ix.1.queue5.lro_flushed: 0 >> dev.ix.1.queue6.interrupt_rate: 5319 >> dev.ix.1.queue6.irqs: 6624395782 >> dev.ix.1.queue6.txd_head: 1058 >> dev.ix.1.queue6.txd_tail: 1058 >> dev.ix.1.queue6.tso_tx: 20 >> dev.ix.1.queue6.no_tx_dma_setup: 0 >> dev.ix.1.queue6.no_desc_avail: 0 >> dev.ix.1.queue6.tx_packets: 13491315217 >> dev.ix.1.queue6.rxd_head: 1550 >> dev.ix.1.queue6.rxd_tail: 1549 >> dev.ix.1.queue6.rx_packets: 1510907490 >> dev.ix.1.queue6.rx_bytes: 719914325 >> dev.ix.1.queue6.rx_copies: 2712955 >> dev.ix.1.queue6.lro_queued: 0 >> dev.ix.1.queue6.lro_flushed: 0 >> dev.ix.1.queue7.interrupt_rate: 29411 >> dev.ix.1.queue7.irqs: 6573304834 >> dev.ix.1.queue7.txd_head: 784 >> dev.ix.1.queue7.txd_tail: 786 >> dev.ix.1.queue7.tso_tx: 2 >> dev.ix.1.queue7.no_tx_dma_setup: 0 >> dev.ix.1.queue7.no_desc_avail: 0 >> dev.ix.1.queue7.tx_packets: 13587681458 >> dev.ix.1.queue7.rxd_head: 1489 >> dev.ix.1.queue7.rxd_tail: 1488 >> dev.ix.1.queue7.rx_packets: 1504712031 >> dev.ix.1.queue7.rx_bytes: 1216803328 >> dev.ix.1.queue7.rx_copies: 2976103 >> dev.ix.1.queue7.lro_queued: 0 >> dev.ix.1.queue7.lro_flushed: 0 >> dev.ix.1.mac_stats.crc_errs: 0 >> dev.ix.1.mac_stats.ill_errs: 0 >> dev.ix.1.mac_stats.byte_errs: 0 >> dev.ix.1.mac_stats.short_discards: 0 >> dev.ix.1.mac_stats.local_faults: 0 >> dev.ix.1.mac_stats.remote_faults: 12 >> dev.ix.1.mac_stats.rec_len_errs: 0 >> dev.ix.1.mac_stats.xon_txd: 1714791401322 >> dev.ix.1.mac_stats.xon_recvd: 0 >> dev.ix.1.mac_stats.xoff_txd: 41095995010 >> dev.ix.1.mac_stats.xoff_recvd: 0 >> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >> dev.ix.1.mac_stats.rx_frames_64: 73447 >> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >> dev.ix.1.mac_stats.recv_undersized: 0 >> dev.ix.1.mac_stats.recv_fragmented: 0 >> dev.ix.1.mac_stats.recv_oversized: 0 >> dev.ix.1.mac_stats.recv_jabberd: 0 >> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >> dev.ix.1.mac_stats.management_pkts_drpd: 0 >> dev.ix.1.mac_stats.checksum_errs: 85432477 >> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >> dev.ix.1.mac_stats.management_pkts_txd: 0 >> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >> >> # cat /var/run/dmesg.boot >> >> Copyright (c) 1992-2014 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class CPU) >> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >> Stepping = 4 >> >> Features=0xbfebfbff >> >> Features2=0x7fbee3ff >> AMD Features=0x2c100800 >> AMD Features2=0x1 >> Structured Extended Features=0x281 >> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >> TSC: P-state invariant, performance statistics >> real memory = 17179869184 (16384 MB) >> avail memory = 16515358720 (15750 MB) >> Event timer "LAPIC" quality 600 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >> FreeBSD/SMP: 2 package(s) x 6 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 2 >> cpu2 (AP): APIC ID: 4 >> cpu3 (AP): APIC ID: 6 >> cpu4 (AP): APIC ID: 8 >> cpu5 (AP): APIC ID: 10 >> cpu6 (AP): APIC ID: 32 >> cpu7 (AP): APIC ID: 34 >> cpu8 (AP): APIC ID: 36 >> cpu9 (AP): APIC ID: 38 >> cpu10 (AP): APIC ID: 40 >> cpu11 (AP): APIC ID: 42 >> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, >> using default 16 (20130823/tbfadt-682) >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> ioapic2 irqs 48-71 on motherboard >> kbd1 at kbdmux0 >> random: initialized >> cryptosoft0: on motherboard >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, 9d000 (3) failed >> cpu0: on acpi0 >> cpu1: on acpi0 >> cpu2: on acpi0 >> cpu3: on acpi0 >> cpu4: on acpi0 >> cpu5: on acpi0 >> cpu6: on acpi0 >> cpu7: on acpi0 >> cpu8: on acpi0 >> cpu9: on acpi0 >> cpu10: on acpi0 >> cpu11: on acpi0 >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 950 >> Event timer "HPET" frequency 14318180 Hz quality 350 >> Event timer "HPET1" frequency 14318180 Hz quality 340 >> Event timer "HPET2" frequency 14318180 Hz quality 340 >> Event timer "HPET3" frequency 14318180 Hz quality 340 >> Event timer "HPET4" frequency 14318180 Hz quality 340 >> Event timer "HPET5" frequency 14318180 Hz quality 340 >> Event timer "HPET6" frequency 14318180 Hz quality 340 >> Event timer "HPET7" frequency 14318180 Hz quality 340 >> atrtc0: port 0x70-0x77 irq 8 on acpi0 >> atrtc0: Warning: Couldn't map I/O. >> Event timer "RTC" frequency 32768 Hz quality 0 >> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: irq 47 at device 1.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 47 at device 1.1 on pci0 >> pci2: on pcib2 >> igb0: port >> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 at >> device 0.0 on pci2 >> igb0: Using MSIX interrupts with 9 vectors >> igb0: Ethernet address: 00:1e:67:9a:d5:88 >> 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 >> igb0: Bound queue 4 to cpu 4 >> igb0: Bound queue 5 to cpu 5 >> igb0: Bound queue 6 to cpu 6 >> igb0: Bound queue 7 to cpu 7 >> igb1: port >> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 at >> device 0.1 on pci2 >> igb1: Using MSIX interrupts with 9 vectors >> igb1: Ethernet address: 00:1e:67:9a:d5:89 >> igb1: Bound queue 0 to cpu 8 >> igb1: Bound queue 1 to cpu 9 >> igb1: Bound queue 2 to cpu 10 >> igb1: Bound queue 3 to cpu 11 >> igb1: Bound queue 4 to cpu 0 >> igb1: Bound queue 5 to cpu 1 >> igb1: Bound queue 6 to cpu 2 >> igb1: Bound queue 7 to cpu 3 >> igb2: port >> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 at >> device 0.2 on pci2 >> igb2: Using MSIX interrupts with 9 vectors >> igb2: Ethernet address: 00:1e:67:9a:d5:8a >> igb2: Bound queue 0 to cpu 4 >> igb2: Bound queue 1 to cpu 5 >> igb2: Bound queue 2 to cpu 6 >> igb2: Bound queue 3 to cpu 7 >> igb2: Bound queue 4 to cpu 8 >> igb2: Bound queue 5 to cpu 9 >> igb2: Bound queue 6 to cpu 10 >> igb2: Bound queue 7 to cpu 11 >> igb3: port >> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 at >> device 0.3 on pci2 >> igb3: Using MSIX interrupts with 9 vectors >> igb3: Ethernet address: 00:1e:67:9a:d5:8b >> igb3: Bound queue 0 to cpu 0 >> igb3: Bound queue 1 to cpu 1 >> igb3: Bound queue 2 to cpu 2 >> igb3: Bound queue 3 to cpu 3 >> igb3: Bound queue 4 to cpu 4 >> igb3: Bound queue 5 to cpu 5 >> igb3: Bound queue 6 to cpu 6 >> igb3: Bound queue 7 to cpu 7 >> pcib3: irq 47 at device 2.0 on pci0 >> pci4: on pcib3 >> igb4: mem >> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 >> igb4: Using MSIX interrupts with 9 vectors >> igb4: Ethernet address: a0:36:9f:37:82:7e >> igb4: Bound queue 0 to cpu 8 >> igb4: Bound queue 1 to cpu 9 >> igb4: Bound queue 2 to cpu 10 >> igb4: Bound queue 3 to cpu 11 >> igb4: Bound queue 4 to cpu 0 >> igb4: Bound queue 5 to cpu 1 >> igb4: Bound queue 6 to cpu 2 >> igb4: Bound queue 7 to cpu 3 >> igb5: mem >> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 >> igb5: Using MSIX interrupts with 9 vectors >> igb5: Ethernet address: a0:36:9f:37:82:7f >> igb5: Bound queue 0 to cpu 4 >> igb5: Bound queue 1 to cpu 5 >> igb5: Bound queue 2 to cpu 6 >> igb5: Bound queue 3 to cpu 7 >> igb5: Bound queue 4 to cpu 8 >> igb5: Bound queue 5 to cpu 9 >> igb5: Bound queue 6 to cpu 10 >> igb5: Bound queue 7 to cpu 11 >> pcib4: irq 16 at device 3.0 on pci0 >> pci6: on pcib4 >> igb6: mem >> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 >> igb6: Using MSIX interrupts with 9 vectors >> igb6: Ethernet address: a0:36:9f:37:82:8a >> igb6: Bound queue 0 to cpu 0 >> igb6: Bound queue 1 to cpu 1 >> igb6: Bound queue 2 to cpu 2 >> igb6: Bound queue 3 to cpu 3 >> igb6: Bound queue 4 to cpu 4 >> igb6: Bound queue 5 to cpu 5 >> igb6: Bound queue 6 to cpu 6 >> igb6: Bound queue 7 to cpu 7 >> igb7: mem >> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 >> igb7: Using MSIX interrupts with 9 vectors >> igb7: Ethernet address: a0:36:9f:37:82:8b >> igb7: Bound queue 0 to cpu 8 >> igb7: Bound queue 1 to cpu 9 >> igb7: Bound queue 2 to cpu 10 >> igb7: Bound queue 3 to cpu 11 >> igb7: Bound queue 4 to cpu 0 >> igb7: Bound queue 5 to cpu 1 >> igb7: Bound queue 6 to cpu 2 >> igb7: Bound queue 7 to cpu 3 >> pcib5: irq 16 at device 17.0 on pci0 >> pci8: on pcib5 >> pci0: at device 22.0 (no driver attached) >> pci0: at device 22.1 (no driver attached) >> ehci0: mem 0xd1220000-0xd12203ff irq >> 22 at device 26.0 on pci0 >> usbus0: EHCI version 1.0 >> usbus0 on ehci0 >> pcib6: irq 16 at device 28.0 on pci0 >> pci9: on pcib6 >> pcib7: irq 17 at device 28.5 on pci0 >> pci10: on pcib7 >> pci10: at device 0.0 (no driver attached) >> pcib8: irq 19 at device 28.7 on pci0 >> pci11: on pcib8 >> vgapci0: mem >> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq 19 at >> device 0.0 on pci11 >> vgapci0: Boot video device >> ehci1: mem 0xd1210000-0xd12103ff irq >> 20 at device 29.0 on pci0 >> usbus1: EHCI version 1.0 >> usbus1 on ehci1 >> pcib9: at device 30.0 on pci0 >> pci12: on pcib9 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> ahci0: port >> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f mem >> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >> ahcich0: at channel 0 on ahci0 >> ahcich1: at channel 1 on ahci0 >> ahcich2: at channel 2 on ahci0 >> ahcich3: at channel 3 on ahci0 >> ahcich4: at channel 4 on ahci0 >> ahcich5: at channel 5 on ahci0 >> ahciem0: on ahci0 >> pcib10: on acpi0 >> pci128: on pcib10 >> pcib11: irq 71 at device 1.0 on pci128 >> pci129: on pcib11 >> ix0: >> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff irq 50 at >> device 0.0 on pci129 >> ix0: Using MSIX interrupts with 9 vectors >> ix0: Ethernet address: 00:1b:21:89:25:32 >> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >> ix1: >> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff irq 52 at >> device 0.1 on pci129 >> ix1: Using MSIX interrupts with 9 vectors >> ix1: Ethernet address: 00:1b:21:89:25:33 >> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >> pcib12: irq 71 at device 2.0 on pci128 >> pci131: on pcib12 >> pcib13: irq 71 at device 3.0 on pci128 >> pci132: on pcib13 >> acpi_button0: on acpi0 >> pcib14: on acpi0 >> pci127: on pcib14 >> pcib15: on acpi0 >> pci255: on pcib15 >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> orm0: at iomem >> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >> on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> est0: on cpu0 >> p4tcc0: on cpu0 >> est1: on cpu1 >> p4tcc1: on cpu1 >> est2: on cpu2 >> p4tcc2: on cpu2 >> est3: on cpu3 >> p4tcc3: on cpu3 >> est4: on cpu4 >> p4tcc4: on cpu4 >> est5: on cpu5 >> p4tcc5: on cpu5 >> est6: on cpu6 >> p4tcc6: on cpu6 >> est7: on cpu7 >> p4tcc7: on cpu7 >> est8: on cpu8 >> p4tcc8: on cpu8 >> est9: on cpu9 >> p4tcc9: on cpu9 >> est10: on cpu10 >> p4tcc10: on cpu10 >> est11: on cpu11 >> p4tcc11: on cpu11 >> random: unblocking device. >> usbus0: 480Mbps High Speed USB v2.0 >> Timecounters tick every 1.000 msec >> IPsec: Initialized Security Association Processing. >> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, >> logging disabled >> usbus1: 480Mbps High Speed USB v2.0 >> ugen1.1: at usbus1 >> uhub0: on usbus1 >> ugen0.1: at usbus0 >> uhub1: on usbus0 >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-9 SATA 3.x device >> ada0: Serial Number S1D5NSAF687077K >> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >> ada0: Command Queueing enabled >> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >> ada0: quirks=0x1<4K> >> ada0: Previously was known as ad4 >> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >> ses0: SEMB S-E-S 2.00 device >> ses0: SEMB SES Device >> SMP: AP CPU #6 Launched! >> SMP: AP CPU #3 Launched! >> SMP: AP CPU #11 Launched! >> SMP: AP CPU #5 Launched! >> SMP: AP CPU #9 Launched! >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #10 Launched! >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #8 Launched! >> SMP: AP CPU #4 Launched! >> SMP: AP CPU #7 Launched! >> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >> Root mount waiting for: usbus1 usbus0 >> uhub1: 2 ports with 2 removable, self powered >> uhub0: 2 ports with 2 removable, self powered >> Root mount waiting for: usbus1 usbus0 >> ugen1.2: at usbus1 >> uhub2: on >> usbus1 >> ugen0.2: at usbus0 >> uhub3: on >> usbus0 >> Root mount waiting for: usbus1 usbus0 >> uhub3: 6 ports with 6 removable, self powered >> uhub2: 8 ports with 8 removable, self powered >> ugen1.3: at usbus1 >> ukbd0: on usbus1 >> kbd0 at ukbd0 >> Root mount waiting for: usbus1 >> ugen1.4: at usbus1 >> ukbd1: on usbus1 >> kbd2 at ukbd1 >> Trying to mount root from ufs:/dev/label/rootfs [rw]... >> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >> member to prevent IPv6 address scope violation. >> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >> member to prevent IPv6 address scope violation. >> ums0: on usbus1 >> ums0: 3 buttons and [Z] coordinates ID=0 >> uhid0: on usbus1 >> >> # uname -a >> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 r274375: >> Tue Nov 11 10:24:44 BRST 2014 >> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >> >> [1] https://calomel.org/freebsd_network_tuning.html >> [2] http://ark.intel.com/products/63157 >> [3] >> http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 >> [4] http://ark.intel.com/products/59062/ >> >> Please I need a help! and sorry my english :) >> >> _______________________________________________ >> 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 Sun Nov 30 18:20:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40F583C4; Sun, 30 Nov 2014 18:20:37 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66C8460; Sun, 30 Nov 2014 18:20:36 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so12391241wgh.32 for ; Sun, 30 Nov 2014 10:20:34 -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=+ZZYuQeRndUFq4fXpsDSKJU20UsB8FVT8NR02NCJ7ow=; b=n17MDqGJe3/F1QTZfeccfhG4Bx6ST7+a/YTMclE2eL9w6BJn2PXcdNSClnRDxN3Dxo g99JV2YDIjKaVOBcF9fR/ID1YddAtHc4dMsje9PPsjdPQHVykRS8BIj8WPukrDzXzlaN R8MhcM98Fum8oqCiC/eXilkJcF+QQ3tv2zcdIu1uVlt8ZLtBlNRBObRhVW2hJviLwT/Y /ngmLSXdxv+TGbRX9V9tm+aJ9w9Osj5OI1WOL2D5smtb7lu8oOCb6AJHLeWgnWPAIez6 xkWJGh7anxf5klj6cB6ZriWTzmZFs6p2JDs+jxm2AylLuTsvtj/ohrkbVp1ugnNCqUvW VPdg== MIME-Version: 1.0 X-Received: by 10.194.95.196 with SMTP id dm4mr82264718wjb.41.1417371634801; Sun, 30 Nov 2014 10:20:34 -0800 (PST) Received: by 10.194.81.233 with HTTP; Sun, 30 Nov 2014 10:20:34 -0800 (PST) In-Reply-To: References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> Date: Sun, 30 Nov 2014 10:20:34 -0800 Message-ID: Subject: Re: Problems with Intel X520-SR2 From: Jack Vogel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net >> FreeBSD Net" , Marcelo Gondim , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 18:20:37 -0000 Good suggestions, do you ever see any 'interrupt throttled' messages? You might want to change the storm threshold to 0 and disable it. I too would like to know if there are any messages when the 'hang' happens. I don't know much about lagg, is it responsible for link events?? Its not a normal situation to be having so many :( Jack On Sun, Nov 30, 2014 at 10:01 AM, Adrian Chadd wrote: > Your link_irq value is way too high. I think you're exposing some > unhandled corner case in the driver (as I had this issue when I had > some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe > driver isn't getting link events. > > My test setup at home has link_irq=1 on both sides, and it runs > full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for > RSS testing for weeks at a time. I have no issues and no hiccups. > So, I think there's two problems: > > * you're still seeing way too many link_irq events; and > * i think there's some bad handling when it comes to link_irq events. > > I wonder if we're still clearing some of the interrupt register bits > incorrectly in ixgbe_msix_link(). > > > -adrian > > > > > -adrian > > > On 30 November 2014 at 08:05, Alexander V. Chernikov > wrote: > > On 30.11.2014 18:47, Marcelo Gondim wrote: > >> > >> Dear, > >> > >> Unfortunately I have more options to resolve this problem I'm having > with > >> Intel X520-SR2. Have we changed the X520, we exchange the optical cords, > >> exchanged optical modules, we changed the entire server, we reduce the > >> temperature inside the equipment, made some attempts to tunning the site > >> calomel[1]. We spend a lot of money and do not solve the problem. > >> > >> What happens is that when there is a traffic above 1.2Gbps with PPS > above > >> 700kpps in sometimes almost daily there is a lock in two 10GbE ports the > >> X520-SR interface. Where I am obliged to leave a script running in the > >> background doing just that: > > > > What does this "lock" looks like? > > Do you using jumbo frames? > > Is this IPv4 or IPv4+IPv6 ? > > Can you share "netstat -m" output? > > Do you use ipfw dynamic states? > > Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? > > > > dev.ix.0.queue0.no_desc_avail: 3322269 > > dev.ix.0.queue1.no_desc_avail: 5254761 > > > > Looks suspicious. Either you're running out of mbufs due to total mbuf > > number is small, or system is very busy sometimes. > > What does you "top -HPSzs1" output look like? > > > > > >> > >> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up > >> > >> Made it back to the interface function normally. It's already so for > >> months and have not tried the latest driver from Intel because I do not > see > >> anything related to this issue. > >> > >> These 2-port 10GbE are my backbone linking the four cities that attend > to > >> our main router. One is backup to other but when the problem occurs, > the two > >> ports stop working and at the moment I have a break in my Internet > >> > >> I can only conclude that the problem is one of the things below: > >> > >> 1 - Intel Interface X520-SR2 has a problem with certain types of traffic > >> and then hangs. > >> 2 - The ixgbe driver has a bug that is causing it. > >> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it > >> would be a regression and the equipment is very far away from me if I > need > >> to move me. > >> > >> Honestly I'm almost going on a Juniper closed solution. I would not want > >> to do this because I love FreeBSD and I can not believe that he does not > >> support a 2.7Gbps traffic, which is my peak traffic without getting > having > >> these falls. My hardware today is this: > >> > >> hw.machine: amd64 > >> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz > >> hw.ncpu: 12 > >> hw.byteorder: 1234 > >> hw.physmem: 17083641856 > >> hw.usermem: 15741001728 > >> > >> Hardware all Intel with motherboard S2600COE [2] and with network > >> interfaces offboard: > >> > >> 1x - X520-SR2 [3] > >> 2x - I350-T2 [4] > >> > >> My loader.conf: > >> > >> loader_logo="beastie" > >> if_lagg_load="YES" > >> speaker_load="YES" > >> aio_load="YES" > >> autoboot_delay="5" > >> net.fibs=1 > >> > >> My sysctl.conf: > >> > >> net.inet.ip.forwarding=1 > >> net.inet.ip.fastforwarding=1 > >> net.inet6.ip6.forwarding=1 > >> kern.ipc.somaxconn=4096 > >> net.inet.tcp.syncookies=1 > >> net.inet.ip.redirect=1 > >> net.inet.ip.accept_sourceroute=0 > >> net.inet.ip.sourceroute=0 > >> net.inet.tcp.drop_synfin=1 > >> net.inet.udp.blackhole=1 > >> net.inet.tcp.blackhole=2 > >> security.bsd.see_other_uids=0 > >> net.inet.ip.fw.dyn_buckets=65536 > >> net.inet.ip.fw.dyn_max=65536 > >> hw.intr_storm_threshold=9000 > >> net.inet.ip.dummynet.pipe_slot_limit=800 > >> net.inet.icmp.icmplim=2000 > >> > >> # sysctl dev.ix. > >> dev.ix.%parent: > >> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - > >> 2.5.15 > >> dev.ix.0.%driver: ix > >> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 > >> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > >> subdevice=0x7a11 class=0x020000 > >> dev.ix.0.%parent: pci129 > >> dev.ix.0.fc: 3 > >> dev.ix.0.enable_aim: 1 > >> dev.ix.0.advertise_speed: 0 > >> dev.ix.0.dropped: 0 > >> dev.ix.0.mbuf_defrag_failed: 0 > >> dev.ix.0.watchdog_events: 0 > >> dev.ix.0.link_irq: 193783 > >> dev.ix.0.queue0.interrupt_rate: 50000 > >> dev.ix.0.queue0.irqs: 12029604413 > >> dev.ix.0.queue0.txd_head: 1517 > >> dev.ix.0.queue0.txd_tail: 1517 > >> dev.ix.0.queue0.tso_tx: 85 > >> dev.ix.0.queue0.no_tx_dma_setup: 0 > >> dev.ix.0.queue0.no_desc_avail: 3322269 > >> dev.ix.0.queue0.tx_packets: 15392658033 > >> dev.ix.0.queue0.rxd_head: 709 > >> dev.ix.0.queue0.rxd_tail: 707 > >> dev.ix.0.queue0.rx_packets: 21762427837 > >> dev.ix.0.queue0.rx_bytes: 56918345381 > >> dev.ix.0.queue0.rx_copies: 124289013 > >> dev.ix.0.queue0.lro_queued: 0 > >> dev.ix.0.queue0.lro_flushed: 0 > >> dev.ix.0.queue1.interrupt_rate: 500000 > >> dev.ix.0.queue1.irqs: 11482146431 > >> dev.ix.0.queue1.txd_head: 731 > >> dev.ix.0.queue1.txd_tail: 731 > >> dev.ix.0.queue1.tso_tx: 1442 > >> dev.ix.0.queue1.no_tx_dma_setup: 0 > >> dev.ix.0.queue1.no_desc_avail: 5254761 > >> dev.ix.0.queue1.tx_packets: 15835062632 > >> dev.ix.0.queue1.rxd_head: 685 > >> dev.ix.0.queue1.rxd_tail: 681 > >> dev.ix.0.queue1.rx_packets: 21220715209 > >> dev.ix.0.queue1.rx_bytes: 54351679461 > >> dev.ix.0.queue1.rx_copies: 120833356 > >> dev.ix.0.queue1.lro_queued: 0 > >> dev.ix.0.queue1.lro_flushed: 0 > >> dev.ix.0.queue2.interrupt_rate: 5319 > >> dev.ix.0.queue2.irqs: 11532560324 > >> dev.ix.0.queue2.txd_head: 501 > >> dev.ix.0.queue2.txd_tail: 501 > >> dev.ix.0.queue2.tso_tx: 2474 > >> dev.ix.0.queue2.no_tx_dma_setup: 0 > >> dev.ix.0.queue2.no_desc_avail: 429244 > >> dev.ix.0.queue2.tx_packets: 15772209238 > >> dev.ix.0.queue2.rxd_head: 246 > >> dev.ix.0.queue2.rxd_tail: 244 > >> dev.ix.0.queue2.rx_packets: 21408648299 > >> dev.ix.0.queue2.rx_bytes: 56862350194 > >> dev.ix.0.queue2.rx_copies: 124973551 > >> dev.ix.0.queue2.lro_queued: 0 > >> dev.ix.0.queue2.lro_flushed: 0 > >> dev.ix.0.queue3.interrupt_rate: 20833 > >> dev.ix.0.queue3.irqs: 11557466322 > >> dev.ix.0.queue3.txd_head: 773 > >> dev.ix.0.queue3.txd_tail: 773 > >> dev.ix.0.queue3.tso_tx: 40 > >> dev.ix.0.queue3.no_tx_dma_setup: 0 > >> dev.ix.0.queue3.no_desc_avail: 665620 > >> dev.ix.0.queue3.tx_packets: 16479111658 > >> dev.ix.0.queue3.rxd_head: 1858 > >> dev.ix.0.queue3.rxd_tail: 1854 > >> dev.ix.0.queue3.rx_packets: 21412821769 > >> dev.ix.0.queue3.rx_bytes: 52796089467 > >> dev.ix.0.queue3.rx_copies: 127385950 > >> dev.ix.0.queue3.lro_queued: 0 > >> dev.ix.0.queue3.lro_flushed: 0 > >> dev.ix.0.queue4.interrupt_rate: 11363 > >> dev.ix.0.queue4.irqs: 10824852635 > >> dev.ix.0.queue4.txd_head: 1711 > >> dev.ix.0.queue4.txd_tail: 1713 > >> dev.ix.0.queue4.tso_tx: 581 > >> dev.ix.0.queue4.no_tx_dma_setup: 0 > >> dev.ix.0.queue4.no_desc_avail: 115346803 > >> dev.ix.0.queue4.tx_packets: 16100396810 > >> dev.ix.0.queue4.rxd_head: 244 > >> dev.ix.0.queue4.rxd_tail: 243 > >> dev.ix.0.queue4.rx_packets: 21240995210 > >> dev.ix.0.queue4.rx_bytes: 58726730771 > >> dev.ix.0.queue4.rx_copies: 124872141 > >> dev.ix.0.queue4.lro_queued: 0 > >> dev.ix.0.queue4.lro_flushed: 0 > >> dev.ix.0.queue5.interrupt_rate: 500000 > >> dev.ix.0.queue5.irqs: 10955464761 > >> dev.ix.0.queue5.txd_head: 75 > >> dev.ix.0.queue5.txd_tail: 77 > >> dev.ix.0.queue5.tso_tx: 1758 > >> dev.ix.0.queue5.no_tx_dma_setup: 0 > >> dev.ix.0.queue5.no_desc_avail: 4759 > >> dev.ix.0.queue5.tx_packets: 16267888038 > >> dev.ix.0.queue5.rxd_head: 905 > >> dev.ix.0.queue5.rxd_tail: 904 > >> dev.ix.0.queue5.rx_packets: 21381144028 > >> dev.ix.0.queue5.rx_bytes: 61800291690 > >> dev.ix.0.queue5.rx_copies: 129684798 > >> dev.ix.0.queue5.lro_queued: 0 > >> dev.ix.0.queue5.lro_flushed: 0 > >> dev.ix.0.queue6.interrupt_rate: 33333 > >> dev.ix.0.queue6.irqs: 11081350674 > >> dev.ix.0.queue6.txd_head: 1744 > >> dev.ix.0.queue6.txd_tail: 1746 > >> dev.ix.0.queue6.tso_tx: 38 > >> dev.ix.0.queue6.no_tx_dma_setup: 0 > >> dev.ix.0.queue6.no_desc_avail: 18381 > >> dev.ix.0.queue6.tx_packets: 15376961749 > >> dev.ix.0.queue6.rxd_head: 1783 > >> dev.ix.0.queue6.rxd_tail: 1782 > >> dev.ix.0.queue6.rx_packets: 21381814216 > >> dev.ix.0.queue6.rx_bytes: 56828960117 > >> dev.ix.0.queue6.rx_copies: 130194429 > >> dev.ix.0.queue6.lro_queued: 0 > >> dev.ix.0.queue6.lro_flushed: 0 > >> dev.ix.0.queue7.interrupt_rate: 5319 > >> dev.ix.0.queue7.irqs: 11014043865 > >> dev.ix.0.queue7.txd_head: 1545 > >> dev.ix.0.queue7.txd_tail: 1545 > >> dev.ix.0.queue7.tso_tx: 59 > >> dev.ix.0.queue7.no_tx_dma_setup: 0 > >> dev.ix.0.queue7.no_desc_avail: 5497 > >> dev.ix.0.queue7.tx_packets: 15283534142 > >> dev.ix.0.queue7.rxd_head: 184 > >> dev.ix.0.queue7.rxd_tail: 182 > >> dev.ix.0.queue7.rx_packets: 21431994087 > >> dev.ix.0.queue7.rx_bytes: 57942270182 > >> dev.ix.0.queue7.rx_copies: 128363306 > >> dev.ix.0.queue7.lro_queued: 0 > >> dev.ix.0.queue7.lro_flushed: 0 > >> dev.ix.0.mac_stats.crc_errs: 268 > >> dev.ix.0.mac_stats.ill_errs: 33 > >> dev.ix.0.mac_stats.byte_errs: 55 > >> dev.ix.0.mac_stats.short_discards: 0 > >> dev.ix.0.mac_stats.local_faults: 3484 > >> dev.ix.0.mac_stats.remote_faults: 121 > >> dev.ix.0.mac_stats.rec_len_errs: 0 > >> dev.ix.0.mac_stats.xon_txd: 1602713563748 > >> dev.ix.0.mac_stats.xon_recvd: 0 > >> dev.ix.0.mac_stats.xoff_txd: 108342810167 > >> dev.ix.0.mac_stats.xoff_recvd: 0 > >> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 > >> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 > >> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 > >> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 > >> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 > >> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 > >> dev.ix.0.mac_stats.rx_frames_64: 5356098 > >> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 > >> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 > >> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 > >> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 > >> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 > >> dev.ix.0.mac_stats.recv_undersized: 0 > >> dev.ix.0.mac_stats.recv_fragmented: 0 > >> dev.ix.0.mac_stats.recv_oversized: 244078 > >> dev.ix.0.mac_stats.recv_jabberd: 4 > >> dev.ix.0.mac_stats.management_pkts_rcvd: 0 > >> dev.ix.0.mac_stats.management_pkts_drpd: 0 > >> dev.ix.0.mac_stats.checksum_errs: 897344641 > >> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 > >> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 > >> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 > >> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 > >> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 > >> dev.ix.0.mac_stats.management_pkts_txd: 0 > >> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 > >> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 > >> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 > >> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 > >> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 > >> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 > >> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - > >> 2.5.15 > >> dev.ix.1.%driver: ix > >> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 > >> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > >> subdevice=0x7a11 class=0x020000 > >> dev.ix.1.%parent: pci129 > >> dev.ix.1.fc: 3 > >> dev.ix.1.enable_aim: 1 > >> dev.ix.1.advertise_speed: 0 > >> dev.ix.1.dropped: 0 > >> dev.ix.1.mbuf_defrag_failed: 0 > >> dev.ix.1.watchdog_events: 0 > >> dev.ix.1.link_irq: 127925 > >> dev.ix.1.queue0.interrupt_rate: 11627 > >> dev.ix.1.queue0.irqs: 6686088831 > >> dev.ix.1.queue0.txd_head: 1618 > >> dev.ix.1.queue0.txd_tail: 1620 > >> dev.ix.1.queue0.tso_tx: 28 > >> dev.ix.1.queue0.no_tx_dma_setup: 0 > >> dev.ix.1.queue0.no_desc_avail: 0 > >> dev.ix.1.queue0.tx_packets: 13527334563 > >> dev.ix.1.queue0.rxd_head: 1715 > >> dev.ix.1.queue0.rxd_tail: 1714 > >> dev.ix.1.queue0.rx_packets: 1503775702 > >> dev.ix.1.queue0.rx_bytes: 1069295301 > >> dev.ix.1.queue0.rx_copies: 2983480 > >> dev.ix.1.queue0.lro_queued: 0 > >> dev.ix.1.queue0.lro_flushed: 0 > >> dev.ix.1.queue1.interrupt_rate: 5319 > >> dev.ix.1.queue1.irqs: 6546967336 > >> dev.ix.1.queue1.txd_head: 1812 > >> dev.ix.1.queue1.txd_tail: 1812 > >> dev.ix.1.queue1.tso_tx: 6 > >> dev.ix.1.queue1.no_tx_dma_setup: 0 > >> dev.ix.1.queue1.no_desc_avail: 0 > >> dev.ix.1.queue1.tx_packets: 13475453794 > >> dev.ix.1.queue1.rxd_head: 1246 > >> dev.ix.1.queue1.rxd_tail: 1245 > >> dev.ix.1.queue1.rx_packets: 1506444917 > >> dev.ix.1.queue1.rx_bytes: 783064190 > >> dev.ix.1.queue1.rx_copies: 2881513 > >> dev.ix.1.queue1.lro_queued: 0 > >> dev.ix.1.queue1.lro_flushed: 0 > >> dev.ix.1.queue2.interrupt_rate: 5319 > >> dev.ix.1.queue2.irqs: 6574615190 > >> dev.ix.1.queue2.txd_head: 1494 > >> dev.ix.1.queue2.txd_tail: 1494 > >> dev.ix.1.queue2.tso_tx: 33 > >> dev.ix.1.queue2.no_tx_dma_setup: 0 > >> dev.ix.1.queue2.no_desc_avail: 0 > >> dev.ix.1.queue2.tx_packets: 13555495169 > >> dev.ix.1.queue2.rxd_head: 438 > >> dev.ix.1.queue2.rxd_tail: 437 > >> dev.ix.1.queue2.rx_packets: 1501380848 > >> dev.ix.1.queue2.rx_bytes: 1008544082 > >> dev.ix.1.queue2.rx_copies: 2660960 > >> dev.ix.1.queue2.lro_queued: 0 > >> dev.ix.1.queue2.lro_flushed: 0 > >> dev.ix.1.queue3.interrupt_rate: 5319 > >> dev.ix.1.queue3.irqs: 6617964401 > >> dev.ix.1.queue3.txd_head: 1853 > >> dev.ix.1.queue3.txd_tail: 1855 > >> dev.ix.1.queue3.tso_tx: 10 > >> dev.ix.1.queue3.no_tx_dma_setup: 0 > >> dev.ix.1.queue3.no_desc_avail: 0 > >> dev.ix.1.queue3.tx_packets: 13561212942 > >> dev.ix.1.queue3.rxd_head: 429 > >> dev.ix.1.queue3.rxd_tail: 428 > >> dev.ix.1.queue3.rx_packets: 1498117903 > >> dev.ix.1.queue3.rx_bytes: 784881986 > >> dev.ix.1.queue3.rx_copies: 2695475 > >> dev.ix.1.queue3.lro_queued: 0 > >> dev.ix.1.queue3.lro_flushed: 0 > >> dev.ix.1.queue4.interrupt_rate: 5319 > >> dev.ix.1.queue4.irqs: 6575752163 > >> dev.ix.1.queue4.txd_head: 902 > >> dev.ix.1.queue4.txd_tail: 902 > >> dev.ix.1.queue4.tso_tx: 5 > >> dev.ix.1.queue4.no_tx_dma_setup: 0 > >> dev.ix.1.queue4.no_desc_avail: 0 > >> dev.ix.1.queue4.tx_packets: 13478514009 > >> dev.ix.1.queue4.rxd_head: 536 > >> dev.ix.1.queue4.rxd_tail: 535 > >> dev.ix.1.queue4.rx_packets: 1476720084 > >> dev.ix.1.queue4.rx_bytes: 944967171 > >> dev.ix.1.queue4.rx_copies: 2650672 > >> dev.ix.1.queue4.lro_queued: 0 > >> dev.ix.1.queue4.lro_flushed: 0 > >> dev.ix.1.queue5.interrupt_rate: 10416 > >> dev.ix.1.queue5.irqs: 6578099670 > >> dev.ix.1.queue5.txd_head: 1996 > >> dev.ix.1.queue5.txd_tail: 1996 > >> dev.ix.1.queue5.tso_tx: 663 > >> dev.ix.1.queue5.no_tx_dma_setup: 0 > >> dev.ix.1.queue5.no_desc_avail: 0 > >> dev.ix.1.queue5.tx_packets: 13516483196 > >> dev.ix.1.queue5.rxd_head: 1296 > >> dev.ix.1.queue5.rxd_tail: 1295 > >> dev.ix.1.queue5.rx_packets: 1496584151 > >> dev.ix.1.queue5.rx_bytes: 810434347 > >> dev.ix.1.queue5.rx_copies: 2899315 > >> dev.ix.1.queue5.lro_queued: 0 > >> dev.ix.1.queue5.lro_flushed: 0 > >> dev.ix.1.queue6.interrupt_rate: 5319 > >> dev.ix.1.queue6.irqs: 6624395782 > >> dev.ix.1.queue6.txd_head: 1058 > >> dev.ix.1.queue6.txd_tail: 1058 > >> dev.ix.1.queue6.tso_tx: 20 > >> dev.ix.1.queue6.no_tx_dma_setup: 0 > >> dev.ix.1.queue6.no_desc_avail: 0 > >> dev.ix.1.queue6.tx_packets: 13491315217 > >> dev.ix.1.queue6.rxd_head: 1550 > >> dev.ix.1.queue6.rxd_tail: 1549 > >> dev.ix.1.queue6.rx_packets: 1510907490 > >> dev.ix.1.queue6.rx_bytes: 719914325 > >> dev.ix.1.queue6.rx_copies: 2712955 > >> dev.ix.1.queue6.lro_queued: 0 > >> dev.ix.1.queue6.lro_flushed: 0 > >> dev.ix.1.queue7.interrupt_rate: 29411 > >> dev.ix.1.queue7.irqs: 6573304834 > >> dev.ix.1.queue7.txd_head: 784 > >> dev.ix.1.queue7.txd_tail: 786 > >> dev.ix.1.queue7.tso_tx: 2 > >> dev.ix.1.queue7.no_tx_dma_setup: 0 > >> dev.ix.1.queue7.no_desc_avail: 0 > >> dev.ix.1.queue7.tx_packets: 13587681458 > >> dev.ix.1.queue7.rxd_head: 1489 > >> dev.ix.1.queue7.rxd_tail: 1488 > >> dev.ix.1.queue7.rx_packets: 1504712031 > >> dev.ix.1.queue7.rx_bytes: 1216803328 > >> dev.ix.1.queue7.rx_copies: 2976103 > >> dev.ix.1.queue7.lro_queued: 0 > >> dev.ix.1.queue7.lro_flushed: 0 > >> dev.ix.1.mac_stats.crc_errs: 0 > >> dev.ix.1.mac_stats.ill_errs: 0 > >> dev.ix.1.mac_stats.byte_errs: 0 > >> dev.ix.1.mac_stats.short_discards: 0 > >> dev.ix.1.mac_stats.local_faults: 0 > >> dev.ix.1.mac_stats.remote_faults: 12 > >> dev.ix.1.mac_stats.rec_len_errs: 0 > >> dev.ix.1.mac_stats.xon_txd: 1714791401322 > >> dev.ix.1.mac_stats.xon_recvd: 0 > >> dev.ix.1.mac_stats.xoff_txd: 41095995010 > >> dev.ix.1.mac_stats.xoff_recvd: 0 > >> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 > >> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 > >> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 > >> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 > >> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 > >> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 > >> dev.ix.1.mac_stats.rx_frames_64: 73447 > >> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 > >> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 > >> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 > >> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 > >> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 > >> dev.ix.1.mac_stats.recv_undersized: 0 > >> dev.ix.1.mac_stats.recv_fragmented: 0 > >> dev.ix.1.mac_stats.recv_oversized: 0 > >> dev.ix.1.mac_stats.recv_jabberd: 0 > >> dev.ix.1.mac_stats.management_pkts_rcvd: 0 > >> dev.ix.1.mac_stats.management_pkts_drpd: 0 > >> dev.ix.1.mac_stats.checksum_errs: 85432477 > >> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 > >> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 > >> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 > >> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 > >> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 > >> dev.ix.1.mac_stats.management_pkts_txd: 0 > >> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 > >> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 > >> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 > >> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 > >> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 > >> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 > >> > >> # cat /var/run/dmesg.boot > >> > >> Copyright (c) 1992-2014 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > >> The Regents of the University of California. All rights > reserved. > >> FreeBSD is a registered trademark of The FreeBSD Foundation. > >> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 > >> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 > >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > >> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class > CPU) > >> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e > >> Stepping = 4 > >> > >> > Features=0xbfebfbff > >> > >> > Features2=0x7fbee3ff > >> AMD Features=0x2c100800 > >> AMD Features2=0x1 > >> Structured Extended Features=0x281 > >> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr > >> TSC: P-state invariant, performance statistics > >> real memory = 17179869184 (16384 MB) > >> avail memory = 16515358720 (15750 MB) > >> Event timer "LAPIC" quality 600 > >> ACPI APIC Table: > >> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs > >> FreeBSD/SMP: 2 package(s) x 6 core(s) > >> cpu0 (BSP): APIC ID: 0 > >> cpu1 (AP): APIC ID: 2 > >> cpu2 (AP): APIC ID: 4 > >> cpu3 (AP): APIC ID: 6 > >> cpu4 (AP): APIC ID: 8 > >> cpu5 (AP): APIC ID: 10 > >> cpu6 (AP): APIC ID: 32 > >> cpu7 (AP): APIC ID: 34 > >> cpu8 (AP): APIC ID: 36 > >> cpu9 (AP): APIC ID: 38 > >> cpu10 (AP): APIC ID: 40 > >> cpu11 (AP): APIC ID: 42 > >> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, > >> using default 16 (20130823/tbfadt-682) > >> ioapic0 irqs 0-23 on motherboard > >> ioapic1 irqs 24-47 on motherboard > >> ioapic2 irqs 48-71 on motherboard > >> kbd1 at kbdmux0 > >> random: initialized > >> cryptosoft0: on motherboard > >> acpi0: on motherboard > >> acpi0: Power Button (fixed) > >> acpi0: reservation of 0, 9d000 (3) failed > >> cpu0: on acpi0 > >> cpu1: on acpi0 > >> cpu2: on acpi0 > >> cpu3: on acpi0 > >> cpu4: on acpi0 > >> cpu5: on acpi0 > >> cpu6: on acpi0 > >> cpu7: on acpi0 > >> cpu8: on acpi0 > >> cpu9: on acpi0 > >> cpu10: on acpi0 > >> cpu11: on acpi0 > >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > >> Timecounter "HPET" frequency 14318180 Hz quality 950 > >> Event timer "HPET" frequency 14318180 Hz quality 350 > >> Event timer "HPET1" frequency 14318180 Hz quality 340 > >> Event timer "HPET2" frequency 14318180 Hz quality 340 > >> Event timer "HPET3" frequency 14318180 Hz quality 340 > >> Event timer "HPET4" frequency 14318180 Hz quality 340 > >> Event timer "HPET5" frequency 14318180 Hz quality 340 > >> Event timer "HPET6" frequency 14318180 Hz quality 340 > >> Event timer "HPET7" frequency 14318180 Hz quality 340 > >> atrtc0: port 0x70-0x77 irq 8 on acpi0 > >> atrtc0: Warning: Couldn't map I/O. > >> Event timer "RTC" frequency 32768 Hz quality 0 > >> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > >> Timecounter "i8254" frequency 1193182 Hz quality 0 > >> Event timer "i8254" frequency 1193182 Hz quality 100 > >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > >> pcib0: port 0xcf8-0xcff on acpi0 > >> pci0: on pcib0 > >> pcib1: irq 47 at device 1.0 on pci0 > >> pci1: on pcib1 > >> pcib2: irq 47 at device 1.1 on pci0 > >> pci2: on pcib2 > >> igb0: port > >> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 at > >> device 0.0 on pci2 > >> igb0: Using MSIX interrupts with 9 vectors > >> igb0: Ethernet address: 00:1e:67:9a:d5:88 > >> 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 > >> igb0: Bound queue 4 to cpu 4 > >> igb0: Bound queue 5 to cpu 5 > >> igb0: Bound queue 6 to cpu 6 > >> igb0: Bound queue 7 to cpu 7 > >> igb1: port > >> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 at > >> device 0.1 on pci2 > >> igb1: Using MSIX interrupts with 9 vectors > >> igb1: Ethernet address: 00:1e:67:9a:d5:89 > >> igb1: Bound queue 0 to cpu 8 > >> igb1: Bound queue 1 to cpu 9 > >> igb1: Bound queue 2 to cpu 10 > >> igb1: Bound queue 3 to cpu 11 > >> igb1: Bound queue 4 to cpu 0 > >> igb1: Bound queue 5 to cpu 1 > >> igb1: Bound queue 6 to cpu 2 > >> igb1: Bound queue 7 to cpu 3 > >> igb2: port > >> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 at > >> device 0.2 on pci2 > >> igb2: Using MSIX interrupts with 9 vectors > >> igb2: Ethernet address: 00:1e:67:9a:d5:8a > >> igb2: Bound queue 0 to cpu 4 > >> igb2: Bound queue 1 to cpu 5 > >> igb2: Bound queue 2 to cpu 6 > >> igb2: Bound queue 3 to cpu 7 > >> igb2: Bound queue 4 to cpu 8 > >> igb2: Bound queue 5 to cpu 9 > >> igb2: Bound queue 6 to cpu 10 > >> igb2: Bound queue 7 to cpu 11 > >> igb3: port > >> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 at > >> device 0.3 on pci2 > >> igb3: Using MSIX interrupts with 9 vectors > >> igb3: Ethernet address: 00:1e:67:9a:d5:8b > >> igb3: Bound queue 0 to cpu 0 > >> igb3: Bound queue 1 to cpu 1 > >> igb3: Bound queue 2 to cpu 2 > >> igb3: Bound queue 3 to cpu 3 > >> igb3: Bound queue 4 to cpu 4 > >> igb3: Bound queue 5 to cpu 5 > >> igb3: Bound queue 6 to cpu 6 > >> igb3: Bound queue 7 to cpu 7 > >> pcib3: irq 47 at device 2.0 on pci0 > >> pci4: on pcib3 > >> igb4: mem > >> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 > >> igb4: Using MSIX interrupts with 9 vectors > >> igb4: Ethernet address: a0:36:9f:37:82:7e > >> igb4: Bound queue 0 to cpu 8 > >> igb4: Bound queue 1 to cpu 9 > >> igb4: Bound queue 2 to cpu 10 > >> igb4: Bound queue 3 to cpu 11 > >> igb4: Bound queue 4 to cpu 0 > >> igb4: Bound queue 5 to cpu 1 > >> igb4: Bound queue 6 to cpu 2 > >> igb4: Bound queue 7 to cpu 3 > >> igb5: mem > >> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 > >> igb5: Using MSIX interrupts with 9 vectors > >> igb5: Ethernet address: a0:36:9f:37:82:7f > >> igb5: Bound queue 0 to cpu 4 > >> igb5: Bound queue 1 to cpu 5 > >> igb5: Bound queue 2 to cpu 6 > >> igb5: Bound queue 3 to cpu 7 > >> igb5: Bound queue 4 to cpu 8 > >> igb5: Bound queue 5 to cpu 9 > >> igb5: Bound queue 6 to cpu 10 > >> igb5: Bound queue 7 to cpu 11 > >> pcib4: irq 16 at device 3.0 on pci0 > >> pci6: on pcib4 > >> igb6: mem > >> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 > >> igb6: Using MSIX interrupts with 9 vectors > >> igb6: Ethernet address: a0:36:9f:37:82:8a > >> igb6: Bound queue 0 to cpu 0 > >> igb6: Bound queue 1 to cpu 1 > >> igb6: Bound queue 2 to cpu 2 > >> igb6: Bound queue 3 to cpu 3 > >> igb6: Bound queue 4 to cpu 4 > >> igb6: Bound queue 5 to cpu 5 > >> igb6: Bound queue 6 to cpu 6 > >> igb6: Bound queue 7 to cpu 7 > >> igb7: mem > >> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 > >> igb7: Using MSIX interrupts with 9 vectors > >> igb7: Ethernet address: a0:36:9f:37:82:8b > >> igb7: Bound queue 0 to cpu 8 > >> igb7: Bound queue 1 to cpu 9 > >> igb7: Bound queue 2 to cpu 10 > >> igb7: Bound queue 3 to cpu 11 > >> igb7: Bound queue 4 to cpu 0 > >> igb7: Bound queue 5 to cpu 1 > >> igb7: Bound queue 6 to cpu 2 > >> igb7: Bound queue 7 to cpu 3 > >> pcib5: irq 16 at device 17.0 on pci0 > >> pci8: on pcib5 > >> pci0: at device 22.0 (no driver attached) > >> pci0: at device 22.1 (no driver attached) > >> ehci0: mem 0xd1220000-0xd12203ff irq > >> 22 at device 26.0 on pci0 > >> usbus0: EHCI version 1.0 > >> usbus0 on ehci0 > >> pcib6: irq 16 at device 28.0 on pci0 > >> pci9: on pcib6 > >> pcib7: irq 17 at device 28.5 on pci0 > >> pci10: on pcib7 > >> pci10: at device 0.0 (no driver attached) > >> pcib8: irq 19 at device 28.7 on pci0 > >> pci11: on pcib8 > >> vgapci0: mem > >> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq > 19 at > >> device 0.0 on pci11 > >> vgapci0: Boot video device > >> ehci1: mem 0xd1210000-0xd12103ff irq > >> 20 at device 29.0 on pci0 > >> usbus1: EHCI version 1.0 > >> usbus1 on ehci1 > >> pcib9: at device 30.0 on pci0 > >> pci12: on pcib9 > >> isab0: at device 31.0 on pci0 > >> isa0: on isab0 > >> ahci0: port > >> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f > mem > >> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 > >> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > >> ahcich0: at channel 0 on ahci0 > >> ahcich1: at channel 1 on ahci0 > >> ahcich2: at channel 2 on ahci0 > >> ahcich3: at channel 3 on ahci0 > >> ahcich4: at channel 4 on ahci0 > >> ahcich5: at channel 5 on ahci0 > >> ahciem0: on ahci0 > >> pcib10: on acpi0 > >> pci128: on pcib10 > >> pcib11: irq 71 at device 1.0 on pci128 > >> pci129: on pcib11 > >> ix0: > >> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff irq > 50 at > >> device 0.0 on pci129 > >> ix0: Using MSIX interrupts with 9 vectors > >> ix0: Ethernet address: 00:1b:21:89:25:32 > >> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 > >> ix1: > >> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff irq > 52 at > >> device 0.1 on pci129 > >> ix1: Using MSIX interrupts with 9 vectors > >> ix1: Ethernet address: 00:1b:21:89:25:33 > >> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 > >> pcib12: irq 71 at device 2.0 on pci128 > >> pci131: on pcib12 > >> pcib13: irq 71 at device 3.0 on pci128 > >> pci132: on pcib13 > >> acpi_button0: on acpi0 > >> pcib14: on acpi0 > >> pci127: on pcib14 > >> pcib15: on acpi0 > >> pci255: on pcib15 > >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > >> orm0: at iomem > >> > 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff > >> on isa0 > >> sc0: at flags 0x100 on isa0 > >> sc0: VGA <16 virtual consoles, flags=0x300> > >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > >> est0: on cpu0 > >> p4tcc0: on cpu0 > >> est1: on cpu1 > >> p4tcc1: on cpu1 > >> est2: on cpu2 > >> p4tcc2: on cpu2 > >> est3: on cpu3 > >> p4tcc3: on cpu3 > >> est4: on cpu4 > >> p4tcc4: on cpu4 > >> est5: on cpu5 > >> p4tcc5: on cpu5 > >> est6: on cpu6 > >> p4tcc6: on cpu6 > >> est7: on cpu7 > >> p4tcc7: on cpu7 > >> est8: on cpu8 > >> p4tcc8: on cpu8 > >> est9: on cpu9 > >> p4tcc9: on cpu9 > >> est10: on cpu10 > >> p4tcc10: on cpu10 > >> est11: on cpu11 > >> p4tcc11: on cpu11 > >> random: unblocking device. > >> usbus0: 480Mbps High Speed USB v2.0 > >> Timecounters tick every 1.000 msec > >> IPsec: Initialized Security Association Processing. > >> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to > accept, > >> logging disabled > >> usbus1: 480Mbps High Speed USB v2.0 > >> ugen1.1: at usbus1 > >> uhub0: on usbus1 > >> ugen0.1: at usbus0 > >> uhub1: on usbus0 > >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > >> ada0: ATA-9 SATA 3.x device > >> ada0: Serial Number S1D5NSAF687077K > >> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > >> ada0: Command Queueing enabled > >> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) > >> ada0: quirks=0x1<4K> > >> ada0: Previously was known as ad4 > >> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 > >> ses0: SEMB S-E-S 2.00 device > >> ses0: SEMB SES Device > >> SMP: AP CPU #6 Launched! > >> SMP: AP CPU #3 Launched! > >> SMP: AP CPU #11 Launched! > >> SMP: AP CPU #5 Launched! > >> SMP: AP CPU #9 Launched! > >> SMP: AP CPU #1 Launched! > >> SMP: AP CPU #10 Launched! > >> SMP: AP CPU #2 Launched! > >> SMP: AP CPU #8 Launched! > >> SMP: AP CPU #4 Launched! > >> SMP: AP CPU #7 Launched! > >> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 > >> Root mount waiting for: usbus1 usbus0 > >> uhub1: 2 ports with 2 removable, self powered > >> uhub0: 2 ports with 2 removable, self powered > >> Root mount waiting for: usbus1 usbus0 > >> ugen1.2: at usbus1 > >> uhub2: > on > >> usbus1 > >> ugen0.2: at usbus0 > >> uhub3: > on > >> usbus0 > >> Root mount waiting for: usbus1 usbus0 > >> uhub3: 6 ports with 6 removable, self powered > >> uhub2: 8 ports with 8 removable, self powered > >> ugen1.3: at usbus1 > >> ukbd0: on usbus1 > >> kbd0 at ukbd0 > >> Root mount waiting for: usbus1 > >> ugen1.4: at usbus1 > >> ukbd1: on usbus1 > >> kbd2 at ukbd1 > >> Trying to mount root from ufs:/dev/label/rootfs [rw]... > >> lagg0: IPv6 addresses on igb6 have been removed before adding it as a > >> member to prevent IPv6 address scope violation. > >> lagg0: IPv6 addresses on igb7 have been removed before adding it as a > >> member to prevent IPv6 address scope violation. > >> ums0: on usbus1 > >> ums0: 3 buttons and [Z] coordinates ID=0 > >> uhid0: on usbus1 > >> > >> # uname -a > >> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 r274375: > >> Tue Nov 11 10:24:44 BRST 2014 > >> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 > >> > >> [1] https://calomel.org/freebsd_network_tuning.html > >> [2] http://ark.intel.com/products/63157 > >> [3] > >> > http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 > >> [4] http://ark.intel.com/products/59062/ > >> > >> Please I need a help! and sorry my english :) > >> > >> _______________________________________________ > >> 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" > _______________________________________________ > 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 Sun Nov 30 23:46:22 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B177CFA for ; Sun, 30 Nov 2014 23:46:22 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CB8F388 for ; Sun, 30 Nov 2014 23:46:22 +0000 (UTC) Received: from [192.168.200.212] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 01EAD19422F for ; Sun, 30 Nov 2014 23:46:14 +0000 (UTC) Message-ID: <547BAC45.4050706@ignoranthack.me> Date: Sun, 30 Nov 2014 15:46:13 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: pf(4) changes recently? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 30 Nov 2014 23:46:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I use pf and jails on a host to redirect port 80 to the correct jail. I only use 1 routeable IP and have been running this configuration for over a year now. I run nginx in jailA (10.0.0.2) and have it capture port 80 requests and forward them to either jailB (10.0.0.3) or jailC(10.0.0.4) based on hostname in the http request. Recently(last 3 months), pf has started blocking the ability of jailA to send these requests to the other two jails and I don't know why. my nginx config and pf.conf are unchanged. When I enter jailA and attempt to telnet to jailB port 80, I get rejected. So, I assume something is wrong with my current pf implementation. pf.conf: - -------------------------------------------------------------------------= --------------------------- jailA_if =3D "lo1" JailAnet =3D $jailA_if:network jailB_if =3D "lo2" jailBnet =3D $jailB_if:network jailC_if =3D "lo3" jailCnet =3D $jailC_if:network jailA=3D"10.0.0.2" jailB=3D"10.0.0.3" jailC=3D"10.0.0.4" #NAT nat on $ext_if from $jailAnet to any -> ($ext_if) nat on $ext_if from $jailBnet to any -> ($ext_if) nat on $ext_if from $jailCnet to any -> ($ext_if) # Redirect 80 rdr pass on $ext_if inet proto tcp to port http -> $jailA port http - -------------------------------------------------------------------------= --------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUe6xAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJEBIB78oecn5k3wwIAJA/WHdR+1F9sgfpx+LkgIWf ghS+57DINlt3fuMR5TTZ6lP9yLtYAPt+bf/PaJzgBn10waVrw9RmmZucCGySf+cu 92HGPi9fchyALplpeyPR3qD5bne8lnx9xQhYhh/gNIpkX7K/+hW+j1xGG5AsNwjr uQwoFq2IMwitFRdx4fSpttERbUEWDX7q333/QYkcLTpGoiouADzmlM9kqtSLGuvG +oRXl+lI83A3q4G+ec4r7sSmRc4Ou7J1YMiiWlaSqAZCRlPWhcWnQTVwQCHhYGgC 5FX26CV7akFmGCy1OykZJBRvQjozZp4t7FL7Jv0mvavMTX8ZalST3LRqqV7aBBM=3D =3DXqEl -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 00:22:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED5AA348 for ; Mon, 1 Dec 2014 00:22:55 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1F6C916 for ; Mon, 1 Dec 2014 00:22:55 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 165F9139CB for ; Sun, 30 Nov 2014 22:23:07 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1417393382; x=1418257383; bh=2Tw4bm8iljgzXuYNv0/E34/dJbKXhOpgha+ eE3ZtBN4=; b=mtGFA783VR5QrUaGrp+0zHxvI8vN429R8vKnCxR38jxd6qyZzbo WZuRsjcsuY4eJL9bmt9R0FxbFIUsnqkHtBGgCNWxXgJFVX+YJlaSNWb9nRQPxZOY Co13NEtCmyuLoH77zuRP7Fy3rSTvipnccz0Cl3ayZCq62PSCp337eG/o= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6dYOyq4HPdd for ; Sun, 30 Nov 2014 22:23:02 -0200 (BRST) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id B4F24139CA for ; Sun, 30 Nov 2014 22:23:01 -0200 (BRST) Message-ID: <547BB4D0.9040400@bsdinfo.com.br> Date: Sun, 30 Nov 2014 22:22:40 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> In-Reply-To: <547B4033.1060504@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 00:22:56 -0000 Hi Alexander, On 30/11/2014 14:05, Alexander V. Chernikov wrote: > On 30.11.2014 18:47, Marcelo Gondim wrote: >> Dear, >> >> Unfortunately I have more options to resolve this problem I'm having >> with Intel X520-SR2. Have we changed the X520, we exchange the >> optical cords, exchanged optical modules, we changed the entire >> server, we reduce the temperature inside the equipment, made some >> attempts to tunning the site calomel[1]. We spend a lot of money and >> do not solve the problem. >> >> What happens is that when there is a traffic above 1.2Gbps with PPS >> above 700kpps in sometimes almost daily there is a lock in two 10GbE >> ports the X520-SR interface. Where I am obliged to leave a script >> running in the background doing just that: > What does this "lock" looks like? Traffic stops completely and I can not ping it. > Do you using jumbo frames? Nope > Is this IPv4 or IPv4+IPv6 ? IPv4 + IPv6 + vlan > Can you share "netstat -m" output? # netstat -m 90132/35613/125745 mbufs in use (current/cache/total) 90106/28702/118808/1014326 mbuf clusters in use (current/cache/total/max) 90106/28551 mbuf+clusters out of packet secondary zone in use (current/cache) 0/92/92/507162 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/150270 9k jumbo clusters in use (current/cache/total/max) 0/0/0/84527 16k jumbo clusters in use (current/cache/total/max) 202745K/66675K/269420K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile > Do you use ipfw dynamic states? > Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? # ipfw -d show|wc -l 205 > > dev.ix.0.queue0.no_desc_avail: 3322269 > dev.ix.0.queue1.no_desc_avail: 5254761 > > Looks suspicious. Either you're running out of mbufs due to total mbuf > number is small, or system is very busy sometimes. > What does you "top -HPSzs1" output look like? last pid: 40931; load averages: 19.96, 17.79, 17.86 up 15+01:04:17 22:10:30 279 processes: 31 running, 153 sleeping, 95 waiting CPU 0: 0.0% user, 0.0% nice, 0.0% system, 40.6% interrupt, 59.4% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 72.7% interrupt, 27.3% idle CPU 2: 0.0% user, 0.0% nice, 0.8% system, 56.3% interrupt, 43.0% idle CPU 3: 0.0% user, 0.0% nice, 0.0% system, 63.3% interrupt, 36.7% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 75.8% interrupt, 24.2% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 66.4% interrupt, 33.6% idle CPU 6: 0.0% user, 0.0% nice, 1.6% system, 59.4% interrupt, 39.1% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 66.4% interrupt, 33.6% idle CPU 8: 0.0% user, 0.0% nice, 0.0% system, 31.3% interrupt, 68.8% idle CPU 9: 0.0% user, 0.0% nice, 0.0% system, 46.1% interrupt, 53.9% idle CPU 10: 0.0% user, 0.0% nice, 0.0% system, 35.9% interrupt, 64.1% idle CPU 11: 0.0% user, 0.0% nice, 0.0% system, 43.0% interrupt, 57.0% idle Mem: 268M Active, 302M Inact, 1281M Wired, 1797M Buf, 14G Free Swap: 8192M Total, 8192M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root -92 - 0K 1808K WAIT 10 70.3H 41.16% intr{irq338: ix0:que } 11 root -92 - 0K 1808K WAIT 9 71.1H 38.77% intr{irq339: ix0:que } 11 root -92 - 0K 1808K RUN 7 68.8H 37.26% intr{irq344: ix0:que } 11 root -92 - 0K 1808K WAIT 11 70.4H 36.77% intr{irq337: ix0:que } 11 root -92 - 0K 1808K WAIT 8 69.7H 36.38% intr{irq340: ix0:que } 11 root -92 - 0K 1808K WAIT 7 68.6H 34.47% intr{irq341: ix0:que } 11 root -92 - 0K 1808K RUN 6 68.7H 33.98% intr{irq343: ix0:que } 11 root -92 - 0K 1808K CPU6 6 68.6H 33.69% intr{irq342: ix0:que } 11 root -92 - 0K 1808K WAIT 4 23.1H 12.79% intr{irq277: igb1:que} 11 root -92 - 0K 1808K RUN 2 23.4H 12.26% intr{irq279: igb1:que} 11 root -92 - 0K 1808K WAIT 3 23.4H 12.06% intr{irq278: igb1:que} 11 root -92 - 0K 1808K RUN 5 23.1H 11.08% intr{irq275: igb1:que} 11 root -92 - 0K 1808K WAIT 2 18.1H 10.99% intr{irq320: igb6:que} 11 root -92 - 0K 1808K WAIT 5 18.3H 10.89% intr{irq323: igb6:que} 11 root -92 - 0K 1808K WAIT 3 23.3H 10.69% intr{irq273: igb1:que} 11 root -92 - 0K 1808K CPU0 0 18.7H 10.69% intr{irq318: igb6:que} 11 root -92 - 0K 1808K RUN 1 20.2H 10.60% intr{irq328: igb7:que} 11 root -92 - 0K 1808K WAIT 0 20.0H 10.60% intr{irq330: igb7:que} 11 root -92 - 0K 1808K WAIT 5 23.1H 10.50% intr{irq276: igb1:que} 11 root -92 - 0K 1808K WAIT 1 23.2H 10.35% intr{irq280: igb1:que} 11 root -92 - 0K 1808K WAIT 4 23.1H 10.25% intr{irq274: igb1:que} 11 root -92 - 0K 1808K WAIT 5 18.4H 9.96% intr{irq324: igb6:que} 11 root -92 - 0K 1808K WAIT 2 20.2H 9.77% intr{irq327: igb7:que} 11 root -92 - 0K 1808K WAIT 4 22.4H 9.67% intr{irq310: igb5:que} 11 root -92 - 0K 1808K WAIT 0 20.1H 9.67% intr{irq329: igb7:que} 11 root -92 - 0K 1808K WAIT 2 20.0H 9.67% intr{irq332: igb7:que} # ifconfig igb0: flags=8c02 metric 0 mtu 1500 options=403bb ether 00:1e:67:9a:d5:88 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb1: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1e:67:9a:d5:89 inet 177.xxx.82.162 netmask 0xfffffffc broadcast 177.xxx.82.163 inet6 fe80::21e:67ff:fe9a:d589%igb1 prefixlen 64 scopeid 0x2 inet6 2804:xxxx:501:a::1a prefixlen 126 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb2: flags=8c02 metric 0 mtu 1500 options=403bb ether 00:1e:67:9a:d5:8a inet 191.xxx.120.189 netmask 0xfffffffc broadcast 191.xxx.120.191 inet6 fe80::21e:67ff:fe9a:d58a%igb2 prefixlen 64 scopeid 0x3 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active igb3: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1e:67:9a:d5:8b inet 186.xxx.1.150 netmask 0xfffffffc broadcast 186.xxx.1.151 inet6 fe80::21e:67ff:fe9a:d58b%igb3 prefixlen 64 scopeid 0x4 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb4: flags=8843 metric 0 mtu 1500 options=403bb ether a0:36:9f:37:82:7e inet 159.xxx.51.98 netmask 0xfffffffc broadcast 159.xxx.51.99 inet6 fe80::a236:9fff:fe37:827e%igb4 prefixlen 64 scopeid 0x5 inet6 2804:xxxx:ffff:ffd8::2 prefixlen 64 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb5: flags=8843 metric 0 mtu 1500 options=403bb ether a0:36:9f:37:82:7f inet 64.xxx.195.70 netmask 0xfffffffc broadcast 64.xxx.195.71 inet6 fe80::a236:9fff:fe37:827f%igb5 prefixlen 64 scopeid 0x6 inet6 2001:xxxx:2001:1001::96 prefixlen 126 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb6: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:98 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active igb7: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:98 inet6 fe80::21e:67ff:fe9a:d588%igb7 prefixlen 64 scopeid 0x8 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active ix0: flags=8843 metric 0 mtu 1500 options=8407bb ether 00:1b:21:89:25:32 inet6 fe80::21b:21ff:fe89:2532%ix0 prefixlen 64 scopeid 0x9 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active ix1: flags=8843 metric 0 mtu 1500 options=8407bb ether 00:1b:21:89:25:33 inet6 fe80::21b:21ff:fe89:2533%ix1 prefixlen 64 scopeid 0xa nd6 options=21 media: Ethernet autoselect (10Gbase-SR ) status: active pflog0: flags=0<> metric 0 mtu 33160 pfsync0: flags=0<> metric 0 mtu 1500 syncpeer: 0.0.0.0 maxupd: 128 defer: off lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xd inet 127.0.0.1 netmask 0xff000000 nd6 options=21 disc0: flags=8049 metric 0 mtu 65532 inet 127.0.0.254 netmask 0xff000000 nd6 options=21 vlan4: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:7b:ee:98 inet 187.xxx.219.28 netmask 0xfffff800 broadcast 187.xxx.223.255 inet6 fe80::21b:21ff:fe7b:ee98%vlan4 prefixlen 64 scopeid 0xf nd6 options=21 media: Ethernet autoselect status: active vlan: 1441 parent interface: lagg0 vlan9: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:7b:ee:98 inet6 2001:xxxx::219:28 prefixlen 64 inet6 fe80::21b:21ff:fe7b:ee98%vlan9 prefixlen 64 scopeid 0x10 nd6 options=21 media: Ethernet autoselect status: active vlan: 2833 parent interface: lagg0 lagg0: flags=8843 metric 0 mtu 1500 options=403bb ether 00:1b:21:7b:ee:98 inet6 fe80::a236:9fff:fe37:828a%lagg0 prefixlen 64 scopeid 0x11 nd6 options=21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb7 flags=1c laggport: igb6 flags=1c vlan0: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:32 inet 186.xxx.48.1 netmask 0xffffffe0 broadcast 186.xxx.48.31 inet6 fe80::21b:21ff:fe89:2532%vlan0 prefixlen 64 scopeid 0x12 inet6 2804:xxxx:dead::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active vlan: 3081 parent interface: ix0 vlan1: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:32 inet 177.xxx.240.254 netmask 0xffffffe0 broadcast 177.xxx.240.255 inet6 fe80::21b:21ff:fe89:2532%vlan1 prefixlen 64 scopeid 0x13 inet6 2804:xxxx:cafe::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active vlan: 3082 parent interface: ix0 vlan2: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:32 inet 186.xxx.54.1 netmask 0xffffffe0 broadcast 186.xxx.54.31 inet6 fe80::21b:21ff:fe89:2532%vlan2 prefixlen 64 scopeid 0x14 inet6 2804:xxxx:cade::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active vlan: 2126 parent interface: ix0 vlan3: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:32 inet 186.xxx.61.1 netmask 0xffffffe0 broadcast 186.xxx.61.31 inet6 fe80::21b:21ff:fe89:2532%vlan3 prefixlen 64 scopeid 0x15 inet6 2804:xxxx:bad::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-LR ) status: active vlan: 3088 parent interface: ix0 vlan5: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:33 inet 177.xxx.255.1 netmask 0xfffffff8 broadcast 177.xxx.255.7 inet6 fe80::21b:21ff:fe89:2533%vlan5 prefixlen 64 scopeid 0x16 inet6 2804:xxxx:cade:b1fe::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 3001 parent interface: ix1 vlan6: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:33 inet 177.xxx.255.41 netmask 0xfffffff8 broadcast 177.xxx.255.47 inet6 fe80::21b:21ff:fe89:2533%vlan6 prefixlen 64 scopeid 0x17 inet6 2804:xxxx:bad:b1fe::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 3005 parent interface: ix1 vlan7: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:33 inet 177.xxx.255.57 netmask 0xfffffff8 broadcast 177.xxx.255.63 inet6 fe80::21b:21ff:fe89:2533%vlan7 prefixlen 64 scopeid 0x18 inet6 2804:xxxx:cafe:b1fe::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 3007 parent interface: ix1 vlan8: flags=8843 metric 0 mtu 1500 options=303 ether 00:1b:21:89:25:33 inet 177.xxx.255.49 netmask 0xfffffff8 broadcast 177.xxx.255.55 inet6 fe80::21b:21ff:fe89:2533%vlan8 prefixlen 64 scopeid 0x19 inet6 2804:xxxx:dead:b1fe::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (10Gbase-SR ) status: active vlan: 3020 parent interface: ix1 Thanks for your help! :) > >> >> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up >> >> Made it back to the interface function normally. It's already so for >> months and have not tried the latest driver from Intel because I do >> not see anything related to this issue. >> >> These 2-port 10GbE are my backbone linking the four cities that >> attend to our main router. One is backup to other but when the >> problem occurs, the two ports stop working and at the moment I have a >> break in my Internet >> >> I can only conclude that the problem is one of the things below: >> >> 1 - Intel Interface X520-SR2 has a problem with certain types of >> traffic and then hangs. >> 2 - The ixgbe driver has a bug that is causing it. >> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >> would be a regression and the equipment is very far away from me if I >> need to move me. >> >> Honestly I'm almost going on a Juniper closed solution. I would not >> want to do this because I love FreeBSD and I can not believe that he >> does not support a 2.7Gbps traffic, which is my peak traffic without >> getting having these falls. My hardware today is this: >> >> hw.machine: amd64 >> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >> hw.ncpu: 12 >> hw.byteorder: 1234 >> hw.physmem: 17083641856 >> hw.usermem: 15741001728 >> >> Hardware all Intel with motherboard S2600COE [2] and with network >> interfaces offboard: >> >> 1x - X520-SR2 [3] >> 2x - I350-T2 [4] >> >> My loader.conf: >> >> loader_logo="beastie" >> if_lagg_load="YES" >> speaker_load="YES" >> aio_load="YES" >> autoboot_delay="5" >> net.fibs=1 >> >> My sysctl.conf: >> >> net.inet.ip.forwarding=1 >> net.inet.ip.fastforwarding=1 >> net.inet6.ip6.forwarding=1 >> kern.ipc.somaxconn=4096 >> net.inet.tcp.syncookies=1 >> net.inet.ip.redirect=1 >> net.inet.ip.accept_sourceroute=0 >> net.inet.ip.sourceroute=0 >> net.inet.tcp.drop_synfin=1 >> net.inet.udp.blackhole=1 >> net.inet.tcp.blackhole=2 >> security.bsd.see_other_uids=0 >> net.inet.ip.fw.dyn_buckets=65536 >> net.inet.ip.fw.dyn_max=65536 >> hw.intr_storm_threshold=9000 >> net.inet.ip.dummynet.pipe_slot_limit=800 >> net.inet.icmp.icmplim=2000 >> >> # sysctl dev.ix. >> dev.ix.%parent: >> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >> Version - 2.5.15 >> dev.ix.0.%driver: ix >> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >> subdevice=0x7a11 class=0x020000 >> dev.ix.0.%parent: pci129 >> dev.ix.0.fc: 3 >> dev.ix.0.enable_aim: 1 >> dev.ix.0.advertise_speed: 0 >> dev.ix.0.dropped: 0 >> dev.ix.0.mbuf_defrag_failed: 0 >> dev.ix.0.watchdog_events: 0 >> dev.ix.0.link_irq: 193783 >> dev.ix.0.queue0.interrupt_rate: 50000 >> dev.ix.0.queue0.irqs: 12029604413 >> dev.ix.0.queue0.txd_head: 1517 >> dev.ix.0.queue0.txd_tail: 1517 >> dev.ix.0.queue0.tso_tx: 85 >> dev.ix.0.queue0.no_tx_dma_setup: 0 >> dev.ix.0.queue0.no_desc_avail: 3322269 >> dev.ix.0.queue0.tx_packets: 15392658033 >> dev.ix.0.queue0.rxd_head: 709 >> dev.ix.0.queue0.rxd_tail: 707 >> dev.ix.0.queue0.rx_packets: 21762427837 >> dev.ix.0.queue0.rx_bytes: 56918345381 >> dev.ix.0.queue0.rx_copies: 124289013 >> dev.ix.0.queue0.lro_queued: 0 >> dev.ix.0.queue0.lro_flushed: 0 >> dev.ix.0.queue1.interrupt_rate: 500000 >> dev.ix.0.queue1.irqs: 11482146431 >> dev.ix.0.queue1.txd_head: 731 >> dev.ix.0.queue1.txd_tail: 731 >> dev.ix.0.queue1.tso_tx: 1442 >> dev.ix.0.queue1.no_tx_dma_setup: 0 >> dev.ix.0.queue1.no_desc_avail: 5254761 >> dev.ix.0.queue1.tx_packets: 15835062632 >> dev.ix.0.queue1.rxd_head: 685 >> dev.ix.0.queue1.rxd_tail: 681 >> dev.ix.0.queue1.rx_packets: 21220715209 >> dev.ix.0.queue1.rx_bytes: 54351679461 >> dev.ix.0.queue1.rx_copies: 120833356 >> dev.ix.0.queue1.lro_queued: 0 >> dev.ix.0.queue1.lro_flushed: 0 >> dev.ix.0.queue2.interrupt_rate: 5319 >> dev.ix.0.queue2.irqs: 11532560324 >> dev.ix.0.queue2.txd_head: 501 >> dev.ix.0.queue2.txd_tail: 501 >> dev.ix.0.queue2.tso_tx: 2474 >> dev.ix.0.queue2.no_tx_dma_setup: 0 >> dev.ix.0.queue2.no_desc_avail: 429244 >> dev.ix.0.queue2.tx_packets: 15772209238 >> dev.ix.0.queue2.rxd_head: 246 >> dev.ix.0.queue2.rxd_tail: 244 >> dev.ix.0.queue2.rx_packets: 21408648299 >> dev.ix.0.queue2.rx_bytes: 56862350194 >> dev.ix.0.queue2.rx_copies: 124973551 >> dev.ix.0.queue2.lro_queued: 0 >> dev.ix.0.queue2.lro_flushed: 0 >> dev.ix.0.queue3.interrupt_rate: 20833 >> dev.ix.0.queue3.irqs: 11557466322 >> dev.ix.0.queue3.txd_head: 773 >> dev.ix.0.queue3.txd_tail: 773 >> dev.ix.0.queue3.tso_tx: 40 >> dev.ix.0.queue3.no_tx_dma_setup: 0 >> dev.ix.0.queue3.no_desc_avail: 665620 >> dev.ix.0.queue3.tx_packets: 16479111658 >> dev.ix.0.queue3.rxd_head: 1858 >> dev.ix.0.queue3.rxd_tail: 1854 >> dev.ix.0.queue3.rx_packets: 21412821769 >> dev.ix.0.queue3.rx_bytes: 52796089467 >> dev.ix.0.queue3.rx_copies: 127385950 >> dev.ix.0.queue3.lro_queued: 0 >> dev.ix.0.queue3.lro_flushed: 0 >> dev.ix.0.queue4.interrupt_rate: 11363 >> dev.ix.0.queue4.irqs: 10824852635 >> dev.ix.0.queue4.txd_head: 1711 >> dev.ix.0.queue4.txd_tail: 1713 >> dev.ix.0.queue4.tso_tx: 581 >> dev.ix.0.queue4.no_tx_dma_setup: 0 >> dev.ix.0.queue4.no_desc_avail: 115346803 >> dev.ix.0.queue4.tx_packets: 16100396810 >> dev.ix.0.queue4.rxd_head: 244 >> dev.ix.0.queue4.rxd_tail: 243 >> dev.ix.0.queue4.rx_packets: 21240995210 >> dev.ix.0.queue4.rx_bytes: 58726730771 >> dev.ix.0.queue4.rx_copies: 124872141 >> dev.ix.0.queue4.lro_queued: 0 >> dev.ix.0.queue4.lro_flushed: 0 >> dev.ix.0.queue5.interrupt_rate: 500000 >> dev.ix.0.queue5.irqs: 10955464761 >> dev.ix.0.queue5.txd_head: 75 >> dev.ix.0.queue5.txd_tail: 77 >> dev.ix.0.queue5.tso_tx: 1758 >> dev.ix.0.queue5.no_tx_dma_setup: 0 >> dev.ix.0.queue5.no_desc_avail: 4759 >> dev.ix.0.queue5.tx_packets: 16267888038 >> dev.ix.0.queue5.rxd_head: 905 >> dev.ix.0.queue5.rxd_tail: 904 >> dev.ix.0.queue5.rx_packets: 21381144028 >> dev.ix.0.queue5.rx_bytes: 61800291690 >> dev.ix.0.queue5.rx_copies: 129684798 >> dev.ix.0.queue5.lro_queued: 0 >> dev.ix.0.queue5.lro_flushed: 0 >> dev.ix.0.queue6.interrupt_rate: 33333 >> dev.ix.0.queue6.irqs: 11081350674 >> dev.ix.0.queue6.txd_head: 1744 >> dev.ix.0.queue6.txd_tail: 1746 >> dev.ix.0.queue6.tso_tx: 38 >> dev.ix.0.queue6.no_tx_dma_setup: 0 >> dev.ix.0.queue6.no_desc_avail: 18381 >> dev.ix.0.queue6.tx_packets: 15376961749 >> dev.ix.0.queue6.rxd_head: 1783 >> dev.ix.0.queue6.rxd_tail: 1782 >> dev.ix.0.queue6.rx_packets: 21381814216 >> dev.ix.0.queue6.rx_bytes: 56828960117 >> dev.ix.0.queue6.rx_copies: 130194429 >> dev.ix.0.queue6.lro_queued: 0 >> dev.ix.0.queue6.lro_flushed: 0 >> dev.ix.0.queue7.interrupt_rate: 5319 >> dev.ix.0.queue7.irqs: 11014043865 >> dev.ix.0.queue7.txd_head: 1545 >> dev.ix.0.queue7.txd_tail: 1545 >> dev.ix.0.queue7.tso_tx: 59 >> dev.ix.0.queue7.no_tx_dma_setup: 0 >> dev.ix.0.queue7.no_desc_avail: 5497 >> dev.ix.0.queue7.tx_packets: 15283534142 >> dev.ix.0.queue7.rxd_head: 184 >> dev.ix.0.queue7.rxd_tail: 182 >> dev.ix.0.queue7.rx_packets: 21431994087 >> dev.ix.0.queue7.rx_bytes: 57942270182 >> dev.ix.0.queue7.rx_copies: 128363306 >> dev.ix.0.queue7.lro_queued: 0 >> dev.ix.0.queue7.lro_flushed: 0 >> dev.ix.0.mac_stats.crc_errs: 268 >> dev.ix.0.mac_stats.ill_errs: 33 >> dev.ix.0.mac_stats.byte_errs: 55 >> dev.ix.0.mac_stats.short_discards: 0 >> dev.ix.0.mac_stats.local_faults: 3484 >> dev.ix.0.mac_stats.remote_faults: 121 >> dev.ix.0.mac_stats.rec_len_errs: 0 >> dev.ix.0.mac_stats.xon_txd: 1602713563748 >> dev.ix.0.mac_stats.xon_recvd: 0 >> dev.ix.0.mac_stats.xoff_txd: 108342810167 >> dev.ix.0.mac_stats.xoff_recvd: 0 >> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >> dev.ix.0.mac_stats.rx_frames_64: 5356098 >> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >> dev.ix.0.mac_stats.recv_undersized: 0 >> dev.ix.0.mac_stats.recv_fragmented: 0 >> dev.ix.0.mac_stats.recv_oversized: 244078 >> dev.ix.0.mac_stats.recv_jabberd: 4 >> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >> dev.ix.0.mac_stats.management_pkts_drpd: 0 >> dev.ix.0.mac_stats.checksum_errs: 897344641 >> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >> dev.ix.0.mac_stats.management_pkts_txd: 0 >> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >> Version - 2.5.15 >> dev.ix.1.%driver: ix >> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >> subdevice=0x7a11 class=0x020000 >> dev.ix.1.%parent: pci129 >> dev.ix.1.fc: 3 >> dev.ix.1.enable_aim: 1 >> dev.ix.1.advertise_speed: 0 >> dev.ix.1.dropped: 0 >> dev.ix.1.mbuf_defrag_failed: 0 >> dev.ix.1.watchdog_events: 0 >> dev.ix.1.link_irq: 127925 >> dev.ix.1.queue0.interrupt_rate: 11627 >> dev.ix.1.queue0.irqs: 6686088831 >> dev.ix.1.queue0.txd_head: 1618 >> dev.ix.1.queue0.txd_tail: 1620 >> dev.ix.1.queue0.tso_tx: 28 >> dev.ix.1.queue0.no_tx_dma_setup: 0 >> dev.ix.1.queue0.no_desc_avail: 0 >> dev.ix.1.queue0.tx_packets: 13527334563 >> dev.ix.1.queue0.rxd_head: 1715 >> dev.ix.1.queue0.rxd_tail: 1714 >> dev.ix.1.queue0.rx_packets: 1503775702 >> dev.ix.1.queue0.rx_bytes: 1069295301 >> dev.ix.1.queue0.rx_copies: 2983480 >> dev.ix.1.queue0.lro_queued: 0 >> dev.ix.1.queue0.lro_flushed: 0 >> dev.ix.1.queue1.interrupt_rate: 5319 >> dev.ix.1.queue1.irqs: 6546967336 >> dev.ix.1.queue1.txd_head: 1812 >> dev.ix.1.queue1.txd_tail: 1812 >> dev.ix.1.queue1.tso_tx: 6 >> dev.ix.1.queue1.no_tx_dma_setup: 0 >> dev.ix.1.queue1.no_desc_avail: 0 >> dev.ix.1.queue1.tx_packets: 13475453794 >> dev.ix.1.queue1.rxd_head: 1246 >> dev.ix.1.queue1.rxd_tail: 1245 >> dev.ix.1.queue1.rx_packets: 1506444917 >> dev.ix.1.queue1.rx_bytes: 783064190 >> dev.ix.1.queue1.rx_copies: 2881513 >> dev.ix.1.queue1.lro_queued: 0 >> dev.ix.1.queue1.lro_flushed: 0 >> dev.ix.1.queue2.interrupt_rate: 5319 >> dev.ix.1.queue2.irqs: 6574615190 >> dev.ix.1.queue2.txd_head: 1494 >> dev.ix.1.queue2.txd_tail: 1494 >> dev.ix.1.queue2.tso_tx: 33 >> dev.ix.1.queue2.no_tx_dma_setup: 0 >> dev.ix.1.queue2.no_desc_avail: 0 >> dev.ix.1.queue2.tx_packets: 13555495169 >> dev.ix.1.queue2.rxd_head: 438 >> dev.ix.1.queue2.rxd_tail: 437 >> dev.ix.1.queue2.rx_packets: 1501380848 >> dev.ix.1.queue2.rx_bytes: 1008544082 >> dev.ix.1.queue2.rx_copies: 2660960 >> dev.ix.1.queue2.lro_queued: 0 >> dev.ix.1.queue2.lro_flushed: 0 >> dev.ix.1.queue3.interrupt_rate: 5319 >> dev.ix.1.queue3.irqs: 6617964401 >> dev.ix.1.queue3.txd_head: 1853 >> dev.ix.1.queue3.txd_tail: 1855 >> dev.ix.1.queue3.tso_tx: 10 >> dev.ix.1.queue3.no_tx_dma_setup: 0 >> dev.ix.1.queue3.no_desc_avail: 0 >> dev.ix.1.queue3.tx_packets: 13561212942 >> dev.ix.1.queue3.rxd_head: 429 >> dev.ix.1.queue3.rxd_tail: 428 >> dev.ix.1.queue3.rx_packets: 1498117903 >> dev.ix.1.queue3.rx_bytes: 784881986 >> dev.ix.1.queue3.rx_copies: 2695475 >> dev.ix.1.queue3.lro_queued: 0 >> dev.ix.1.queue3.lro_flushed: 0 >> dev.ix.1.queue4.interrupt_rate: 5319 >> dev.ix.1.queue4.irqs: 6575752163 >> dev.ix.1.queue4.txd_head: 902 >> dev.ix.1.queue4.txd_tail: 902 >> dev.ix.1.queue4.tso_tx: 5 >> dev.ix.1.queue4.no_tx_dma_setup: 0 >> dev.ix.1.queue4.no_desc_avail: 0 >> dev.ix.1.queue4.tx_packets: 13478514009 >> dev.ix.1.queue4.rxd_head: 536 >> dev.ix.1.queue4.rxd_tail: 535 >> dev.ix.1.queue4.rx_packets: 1476720084 >> dev.ix.1.queue4.rx_bytes: 944967171 >> dev.ix.1.queue4.rx_copies: 2650672 >> dev.ix.1.queue4.lro_queued: 0 >> dev.ix.1.queue4.lro_flushed: 0 >> dev.ix.1.queue5.interrupt_rate: 10416 >> dev.ix.1.queue5.irqs: 6578099670 >> dev.ix.1.queue5.txd_head: 1996 >> dev.ix.1.queue5.txd_tail: 1996 >> dev.ix.1.queue5.tso_tx: 663 >> dev.ix.1.queue5.no_tx_dma_setup: 0 >> dev.ix.1.queue5.no_desc_avail: 0 >> dev.ix.1.queue5.tx_packets: 13516483196 >> dev.ix.1.queue5.rxd_head: 1296 >> dev.ix.1.queue5.rxd_tail: 1295 >> dev.ix.1.queue5.rx_packets: 1496584151 >> dev.ix.1.queue5.rx_bytes: 810434347 >> dev.ix.1.queue5.rx_copies: 2899315 >> dev.ix.1.queue5.lro_queued: 0 >> dev.ix.1.queue5.lro_flushed: 0 >> dev.ix.1.queue6.interrupt_rate: 5319 >> dev.ix.1.queue6.irqs: 6624395782 >> dev.ix.1.queue6.txd_head: 1058 >> dev.ix.1.queue6.txd_tail: 1058 >> dev.ix.1.queue6.tso_tx: 20 >> dev.ix.1.queue6.no_tx_dma_setup: 0 >> dev.ix.1.queue6.no_desc_avail: 0 >> dev.ix.1.queue6.tx_packets: 13491315217 >> dev.ix.1.queue6.rxd_head: 1550 >> dev.ix.1.queue6.rxd_tail: 1549 >> dev.ix.1.queue6.rx_packets: 1510907490 >> dev.ix.1.queue6.rx_bytes: 719914325 >> dev.ix.1.queue6.rx_copies: 2712955 >> dev.ix.1.queue6.lro_queued: 0 >> dev.ix.1.queue6.lro_flushed: 0 >> dev.ix.1.queue7.interrupt_rate: 29411 >> dev.ix.1.queue7.irqs: 6573304834 >> dev.ix.1.queue7.txd_head: 784 >> dev.ix.1.queue7.txd_tail: 786 >> dev.ix.1.queue7.tso_tx: 2 >> dev.ix.1.queue7.no_tx_dma_setup: 0 >> dev.ix.1.queue7.no_desc_avail: 0 >> dev.ix.1.queue7.tx_packets: 13587681458 >> dev.ix.1.queue7.rxd_head: 1489 >> dev.ix.1.queue7.rxd_tail: 1488 >> dev.ix.1.queue7.rx_packets: 1504712031 >> dev.ix.1.queue7.rx_bytes: 1216803328 >> dev.ix.1.queue7.rx_copies: 2976103 >> dev.ix.1.queue7.lro_queued: 0 >> dev.ix.1.queue7.lro_flushed: 0 >> dev.ix.1.mac_stats.crc_errs: 0 >> dev.ix.1.mac_stats.ill_errs: 0 >> dev.ix.1.mac_stats.byte_errs: 0 >> dev.ix.1.mac_stats.short_discards: 0 >> dev.ix.1.mac_stats.local_faults: 0 >> dev.ix.1.mac_stats.remote_faults: 12 >> dev.ix.1.mac_stats.rec_len_errs: 0 >> dev.ix.1.mac_stats.xon_txd: 1714791401322 >> dev.ix.1.mac_stats.xon_recvd: 0 >> dev.ix.1.mac_stats.xoff_txd: 41095995010 >> dev.ix.1.mac_stats.xoff_recvd: 0 >> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >> dev.ix.1.mac_stats.rx_frames_64: 73447 >> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >> dev.ix.1.mac_stats.recv_undersized: 0 >> dev.ix.1.mac_stats.recv_fragmented: 0 >> dev.ix.1.mac_stats.recv_oversized: 0 >> dev.ix.1.mac_stats.recv_jabberd: 0 >> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >> dev.ix.1.mac_stats.management_pkts_drpd: 0 >> dev.ix.1.mac_stats.checksum_errs: 85432477 >> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >> dev.ix.1.mac_stats.management_pkts_txd: 0 >> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >> >> # cat /var/run/dmesg.boot >> >> Copyright (c) 1992-2014 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights >> reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >> Stepping = 4 >> Features=0xbfebfbff >> >> Features2=0x7fbee3ff >> >> AMD Features=0x2c100800 >> AMD Features2=0x1 >> Structured Extended Features=0x281 >> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >> TSC: P-state invariant, performance statistics >> real memory = 17179869184 (16384 MB) >> avail memory = 16515358720 (15750 MB) >> Event timer "LAPIC" quality 600 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >> FreeBSD/SMP: 2 package(s) x 6 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 2 >> cpu2 (AP): APIC ID: 4 >> cpu3 (AP): APIC ID: 6 >> cpu4 (AP): APIC ID: 8 >> cpu5 (AP): APIC ID: 10 >> cpu6 (AP): APIC ID: 32 >> cpu7 (AP): APIC ID: 34 >> cpu8 (AP): APIC ID: 36 >> cpu9 (AP): APIC ID: 38 >> cpu10 (AP): APIC ID: 40 >> cpu11 (AP): APIC ID: 42 >> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: >> 32, using default 16 (20130823/tbfadt-682) >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> ioapic2 irqs 48-71 on motherboard >> kbd1 at kbdmux0 >> random: initialized >> cryptosoft0: on motherboard >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, 9d000 (3) failed >> cpu0: on acpi0 >> cpu1: on acpi0 >> cpu2: on acpi0 >> cpu3: on acpi0 >> cpu4: on acpi0 >> cpu5: on acpi0 >> cpu6: on acpi0 >> cpu7: on acpi0 >> cpu8: on acpi0 >> cpu9: on acpi0 >> cpu10: on acpi0 >> cpu11: on acpi0 >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 950 >> Event timer "HPET" frequency 14318180 Hz quality 350 >> Event timer "HPET1" frequency 14318180 Hz quality 340 >> Event timer "HPET2" frequency 14318180 Hz quality 340 >> Event timer "HPET3" frequency 14318180 Hz quality 340 >> Event timer "HPET4" frequency 14318180 Hz quality 340 >> Event timer "HPET5" frequency 14318180 Hz quality 340 >> Event timer "HPET6" frequency 14318180 Hz quality 340 >> Event timer "HPET7" frequency 14318180 Hz quality 340 >> atrtc0: port 0x70-0x77 irq 8 on acpi0 >> atrtc0: Warning: Couldn't map I/O. >> Event timer "RTC" frequency 32768 Hz quality 0 >> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: irq 47 at device 1.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 47 at device 1.1 on pci0 >> pci2: on pcib2 >> igb0: port >> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 >> at device 0.0 on pci2 >> igb0: Using MSIX interrupts with 9 vectors >> igb0: Ethernet address: 00:1e:67:9a:d5:88 >> 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 >> igb0: Bound queue 4 to cpu 4 >> igb0: Bound queue 5 to cpu 5 >> igb0: Bound queue 6 to cpu 6 >> igb0: Bound queue 7 to cpu 7 >> igb1: port >> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 >> at device 0.1 on pci2 >> igb1: Using MSIX interrupts with 9 vectors >> igb1: Ethernet address: 00:1e:67:9a:d5:89 >> igb1: Bound queue 0 to cpu 8 >> igb1: Bound queue 1 to cpu 9 >> igb1: Bound queue 2 to cpu 10 >> igb1: Bound queue 3 to cpu 11 >> igb1: Bound queue 4 to cpu 0 >> igb1: Bound queue 5 to cpu 1 >> igb1: Bound queue 6 to cpu 2 >> igb1: Bound queue 7 to cpu 3 >> igb2: port >> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 >> at device 0.2 on pci2 >> igb2: Using MSIX interrupts with 9 vectors >> igb2: Ethernet address: 00:1e:67:9a:d5:8a >> igb2: Bound queue 0 to cpu 4 >> igb2: Bound queue 1 to cpu 5 >> igb2: Bound queue 2 to cpu 6 >> igb2: Bound queue 3 to cpu 7 >> igb2: Bound queue 4 to cpu 8 >> igb2: Bound queue 5 to cpu 9 >> igb2: Bound queue 6 to cpu 10 >> igb2: Bound queue 7 to cpu 11 >> igb3: port >> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 >> at device 0.3 on pci2 >> igb3: Using MSIX interrupts with 9 vectors >> igb3: Ethernet address: 00:1e:67:9a:d5:8b >> igb3: Bound queue 0 to cpu 0 >> igb3: Bound queue 1 to cpu 1 >> igb3: Bound queue 2 to cpu 2 >> igb3: Bound queue 3 to cpu 3 >> igb3: Bound queue 4 to cpu 4 >> igb3: Bound queue 5 to cpu 5 >> igb3: Bound queue 6 to cpu 6 >> igb3: Bound queue 7 to cpu 7 >> pcib3: irq 47 at device 2.0 on pci0 >> pci4: on pcib3 >> igb4: mem >> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 >> igb4: Using MSIX interrupts with 9 vectors >> igb4: Ethernet address: a0:36:9f:37:82:7e >> igb4: Bound queue 0 to cpu 8 >> igb4: Bound queue 1 to cpu 9 >> igb4: Bound queue 2 to cpu 10 >> igb4: Bound queue 3 to cpu 11 >> igb4: Bound queue 4 to cpu 0 >> igb4: Bound queue 5 to cpu 1 >> igb4: Bound queue 6 to cpu 2 >> igb4: Bound queue 7 to cpu 3 >> igb5: mem >> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 >> igb5: Using MSIX interrupts with 9 vectors >> igb5: Ethernet address: a0:36:9f:37:82:7f >> igb5: Bound queue 0 to cpu 4 >> igb5: Bound queue 1 to cpu 5 >> igb5: Bound queue 2 to cpu 6 >> igb5: Bound queue 3 to cpu 7 >> igb5: Bound queue 4 to cpu 8 >> igb5: Bound queue 5 to cpu 9 >> igb5: Bound queue 6 to cpu 10 >> igb5: Bound queue 7 to cpu 11 >> pcib4: irq 16 at device 3.0 on pci0 >> pci6: on pcib4 >> igb6: mem >> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 >> igb6: Using MSIX interrupts with 9 vectors >> igb6: Ethernet address: a0:36:9f:37:82:8a >> igb6: Bound queue 0 to cpu 0 >> igb6: Bound queue 1 to cpu 1 >> igb6: Bound queue 2 to cpu 2 >> igb6: Bound queue 3 to cpu 3 >> igb6: Bound queue 4 to cpu 4 >> igb6: Bound queue 5 to cpu 5 >> igb6: Bound queue 6 to cpu 6 >> igb6: Bound queue 7 to cpu 7 >> igb7: mem >> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 >> igb7: Using MSIX interrupts with 9 vectors >> igb7: Ethernet address: a0:36:9f:37:82:8b >> igb7: Bound queue 0 to cpu 8 >> igb7: Bound queue 1 to cpu 9 >> igb7: Bound queue 2 to cpu 10 >> igb7: Bound queue 3 to cpu 11 >> igb7: Bound queue 4 to cpu 0 >> igb7: Bound queue 5 to cpu 1 >> igb7: Bound queue 6 to cpu 2 >> igb7: Bound queue 7 to cpu 3 >> pcib5: irq 16 at device 17.0 on pci0 >> pci8: on pcib5 >> pci0: at device 22.0 (no driver attached) >> pci0: at device 22.1 (no driver attached) >> ehci0: mem 0xd1220000-0xd12203ff >> irq 22 at device 26.0 on pci0 >> usbus0: EHCI version 1.0 >> usbus0 on ehci0 >> pcib6: irq 16 at device 28.0 on pci0 >> pci9: on pcib6 >> pcib7: irq 17 at device 28.5 on pci0 >> pci10: on pcib7 >> pci10: at device 0.0 (no driver attached) >> pcib8: irq 19 at device 28.7 on pci0 >> pci11: on pcib8 >> vgapci0: mem >> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq >> 19 at device 0.0 on pci11 >> vgapci0: Boot video device >> ehci1: mem 0xd1210000-0xd12103ff >> irq 20 at device 29.0 on pci0 >> usbus1: EHCI version 1.0 >> usbus1 on ehci1 >> pcib9: at device 30.0 on pci0 >> pci12: on pcib9 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> ahci0: port >> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f >> mem 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >> ahcich0: at channel 0 on ahci0 >> ahcich1: at channel 1 on ahci0 >> ahcich2: at channel 2 on ahci0 >> ahcich3: at channel 3 on ahci0 >> ahcich4: at channel 4 on ahci0 >> ahcich5: at channel 5 on ahci0 >> ahciem0: on ahci0 >> pcib10: on acpi0 >> pci128: on pcib10 >> pcib11: irq 71 at device 1.0 on pci128 >> pci129: on pcib11 >> ix0: > 2.5.15> port 0xc020-0xc03f mem >> 0xec180000-0xec1fffff,0xec210000-0xec213fff irq 50 at device 0.0 on >> pci129 >> ix0: Using MSIX interrupts with 9 vectors >> ix0: Ethernet address: 00:1b:21:89:25:32 >> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >> ix1: > 2.5.15> port 0xc000-0xc01f mem >> 0xec080000-0xec0fffff,0xec200000-0xec203fff irq 52 at device 0.1 on >> pci129 >> ix1: Using MSIX interrupts with 9 vectors >> ix1: Ethernet address: 00:1b:21:89:25:33 >> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >> pcib12: irq 71 at device 2.0 on pci128 >> pci131: on pcib12 >> pcib13: irq 71 at device 3.0 on pci128 >> pci132: on pcib13 >> acpi_button0: on acpi0 >> pcib14: on acpi0 >> pci127: on pcib14 >> pcib15: on acpi0 >> pci255: on pcib15 >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> orm0: at iomem >> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >> on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >> isa0 >> est0: on cpu0 >> p4tcc0: on cpu0 >> est1: on cpu1 >> p4tcc1: on cpu1 >> est2: on cpu2 >> p4tcc2: on cpu2 >> est3: on cpu3 >> p4tcc3: on cpu3 >> est4: on cpu4 >> p4tcc4: on cpu4 >> est5: on cpu5 >> p4tcc5: on cpu5 >> est6: on cpu6 >> p4tcc6: on cpu6 >> est7: on cpu7 >> p4tcc7: on cpu7 >> est8: on cpu8 >> p4tcc8: on cpu8 >> est9: on cpu9 >> p4tcc9: on cpu9 >> est10: on cpu10 >> p4tcc10: on cpu10 >> est11: on cpu11 >> p4tcc11: on cpu11 >> random: unblocking device. >> usbus0: 480Mbps High Speed USB v2.0 >> Timecounters tick every 1.000 msec >> IPsec: Initialized Security Association Processing. >> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >> accept, logging disabled >> usbus1: 480Mbps High Speed USB v2.0 >> ugen1.1: at usbus1 >> uhub0: on usbus1 >> ugen0.1: at usbus0 >> uhub1: on usbus0 >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-9 SATA 3.x device >> ada0: Serial Number S1D5NSAF687077K >> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >> ada0: Command Queueing enabled >> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >> ada0: quirks=0x1<4K> >> ada0: Previously was known as ad4 >> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >> ses0: SEMB S-E-S 2.00 device >> ses0: SEMB SES Device >> SMP: AP CPU #6 Launched! >> SMP: AP CPU #3 Launched! >> SMP: AP CPU #11 Launched! >> SMP: AP CPU #5 Launched! >> SMP: AP CPU #9 Launched! >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #10 Launched! >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #8 Launched! >> SMP: AP CPU #4 Launched! >> SMP: AP CPU #7 Launched! >> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >> Root mount waiting for: usbus1 usbus0 >> uhub1: 2 ports with 2 removable, self powered >> uhub0: 2 ports with 2 removable, self powered >> Root mount waiting for: usbus1 usbus0 >> ugen1.2: at usbus1 >> uhub2: > 2> on usbus1 >> ugen0.2: at usbus0 >> uhub3: > 2> on usbus0 >> Root mount waiting for: usbus1 usbus0 >> uhub3: 6 ports with 6 removable, self powered >> uhub2: 8 ports with 8 removable, self powered >> ugen1.3: at usbus1 >> ukbd0: on usbus1 >> kbd0 at ukbd0 >> Root mount waiting for: usbus1 >> ugen1.4: at usbus1 >> ukbd1: on usbus1 >> kbd2 at ukbd1 >> Trying to mount root from ufs:/dev/label/rootfs [rw]... >> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >> member to prevent IPv6 address scope violation. >> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >> member to prevent IPv6 address scope violation. >> ums0: on usbus1 >> ums0: 3 buttons and [Z] coordinates ID=0 >> uhid0: on usbus1 >> >> # uname -a >> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 >> r274375: Tue Nov 11 10:24:44 BRST 2014 >> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >> >> [1] https://calomel.org/freebsd_network_tuning.html >> [2] http://ark.intel.com/products/63157 >> [3] >> http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 >> [4] http://ark.intel.com/products/59062/ >> >> Please I need a help! and sorry my english :) >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 00:31:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C440E5DF for ; Mon, 1 Dec 2014 00:31:35 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D5B79E4 for ; Mon, 1 Dec 2014 00:31:35 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 4975E139CB for ; Sun, 30 Nov 2014 22:31:48 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1417393903; x=1418257904; bh=i9xYs4JGKjh4Z+6qsZ1HjYuctnWZcdqOezM VJ3CrsGk=; b=IgNTrgAS5B4XjpwUxmFAU7ooSTNDlXjQ5+YejsnKQ0XG0dBEibo qvNn5yr6lso54FXMs87yIobhQ73cB3h26nBr4siTpBncoTjeWYgK82yf+/sRJg8F gFz2/NbHGCDorJQSADRnjaLcbxcxADE2u5Xpm4JSau20ElOGMhMJftMw= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me48Gmq1NJE1 for ; Sun, 30 Nov 2014 22:31:43 -0200 (BRST) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 25A92139CA for ; Sun, 30 Nov 2014 22:31:42 -0200 (BRST) Message-ID: <547BB6DA.2010703@bsdinfo.com.br> Date: Sun, 30 Nov 2014 22:31:22 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 00:31:36 -0000 On 30/11/2014 16:01, Adrian Chadd wrote: > Your link_irq value is way too high. I think you're exposing some > unhandled corner case in the driver (as I had this issue when I had > some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe > driver isn't getting link events. > > My test setup at home has link_irq=1 on both sides, and it runs > full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for > RSS testing for weeks at a time. I have no issues and no hiccups. > So, I think there's two problems: > > * you're still seeing way too many link_irq events; and > * i think there's some bad handling when it comes to link_irq events. > > I wonder if we're still clearing some of the interrupt register bits > incorrectly in ixgbe_msix_link(). > > > -adrian Hi Adrian, Thanks for answering. I've been trying to solve this problem for months. I no longer know what to do to tackle this problem. Even now thought to do this in my /etc/crontab: 0 */1 * * * root ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up > > > > > -adrian > > > On 30 November 2014 at 08:05, Alexander V. Chernikov > wrote: >> On 30.11.2014 18:47, Marcelo Gondim wrote: >>> Dear, >>> >>> Unfortunately I have more options to resolve this problem I'm having with >>> Intel X520-SR2. Have we changed the X520, we exchange the optical cords, >>> exchanged optical modules, we changed the entire server, we reduce the >>> temperature inside the equipment, made some attempts to tunning the site >>> calomel[1]. We spend a lot of money and do not solve the problem. >>> >>> What happens is that when there is a traffic above 1.2Gbps with PPS above >>> 700kpps in sometimes almost daily there is a lock in two 10GbE ports the >>> X520-SR interface. Where I am obliged to leave a script running in the >>> background doing just that: >> What does this "lock" looks like? >> Do you using jumbo frames? >> Is this IPv4 or IPv4+IPv6 ? >> Can you share "netstat -m" output? >> Do you use ipfw dynamic states? >> Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? >> >> dev.ix.0.queue0.no_desc_avail: 3322269 >> dev.ix.0.queue1.no_desc_avail: 5254761 >> >> Looks suspicious. Either you're running out of mbufs due to total mbuf >> number is small, or system is very busy sometimes. >> What does you "top -HPSzs1" output look like? >> >> >>> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up >>> >>> Made it back to the interface function normally. It's already so for >>> months and have not tried the latest driver from Intel because I do not see >>> anything related to this issue. >>> >>> These 2-port 10GbE are my backbone linking the four cities that attend to >>> our main router. One is backup to other but when the problem occurs, the two >>> ports stop working and at the moment I have a break in my Internet >>> >>> I can only conclude that the problem is one of the things below: >>> >>> 1 - Intel Interface X520-SR2 has a problem with certain types of traffic >>> and then hangs. >>> 2 - The ixgbe driver has a bug that is causing it. >>> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >>> would be a regression and the equipment is very far away from me if I need >>> to move me. >>> >>> Honestly I'm almost going on a Juniper closed solution. I would not want >>> to do this because I love FreeBSD and I can not believe that he does not >>> support a 2.7Gbps traffic, which is my peak traffic without getting having >>> these falls. My hardware today is this: >>> >>> hw.machine: amd64 >>> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>> hw.ncpu: 12 >>> hw.byteorder: 1234 >>> hw.physmem: 17083641856 >>> hw.usermem: 15741001728 >>> >>> Hardware all Intel with motherboard S2600COE [2] and with network >>> interfaces offboard: >>> >>> 1x - X520-SR2 [3] >>> 2x - I350-T2 [4] >>> >>> My loader.conf: >>> >>> loader_logo="beastie" >>> if_lagg_load="YES" >>> speaker_load="YES" >>> aio_load="YES" >>> autoboot_delay="5" >>> net.fibs=1 >>> >>> My sysctl.conf: >>> >>> net.inet.ip.forwarding=1 >>> net.inet.ip.fastforwarding=1 >>> net.inet6.ip6.forwarding=1 >>> kern.ipc.somaxconn=4096 >>> net.inet.tcp.syncookies=1 >>> net.inet.ip.redirect=1 >>> net.inet.ip.accept_sourceroute=0 >>> net.inet.ip.sourceroute=0 >>> net.inet.tcp.drop_synfin=1 >>> net.inet.udp.blackhole=1 >>> net.inet.tcp.blackhole=2 >>> security.bsd.see_other_uids=0 >>> net.inet.ip.fw.dyn_buckets=65536 >>> net.inet.ip.fw.dyn_max=65536 >>> hw.intr_storm_threshold=9000 >>> net.inet.ip.dummynet.pipe_slot_limit=800 >>> net.inet.icmp.icmplim=2000 >>> >>> # sysctl dev.ix. >>> dev.ix.%parent: >>> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - >>> 2.5.15 >>> dev.ix.0.%driver: ix >>> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >>> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>> subdevice=0x7a11 class=0x020000 >>> dev.ix.0.%parent: pci129 >>> dev.ix.0.fc: 3 >>> dev.ix.0.enable_aim: 1 >>> dev.ix.0.advertise_speed: 0 >>> dev.ix.0.dropped: 0 >>> dev.ix.0.mbuf_defrag_failed: 0 >>> dev.ix.0.watchdog_events: 0 >>> dev.ix.0.link_irq: 193783 >>> dev.ix.0.queue0.interrupt_rate: 50000 >>> dev.ix.0.queue0.irqs: 12029604413 >>> dev.ix.0.queue0.txd_head: 1517 >>> dev.ix.0.queue0.txd_tail: 1517 >>> dev.ix.0.queue0.tso_tx: 85 >>> dev.ix.0.queue0.no_tx_dma_setup: 0 >>> dev.ix.0.queue0.no_desc_avail: 3322269 >>> dev.ix.0.queue0.tx_packets: 15392658033 >>> dev.ix.0.queue0.rxd_head: 709 >>> dev.ix.0.queue0.rxd_tail: 707 >>> dev.ix.0.queue0.rx_packets: 21762427837 >>> dev.ix.0.queue0.rx_bytes: 56918345381 >>> dev.ix.0.queue0.rx_copies: 124289013 >>> dev.ix.0.queue0.lro_queued: 0 >>> dev.ix.0.queue0.lro_flushed: 0 >>> dev.ix.0.queue1.interrupt_rate: 500000 >>> dev.ix.0.queue1.irqs: 11482146431 >>> dev.ix.0.queue1.txd_head: 731 >>> dev.ix.0.queue1.txd_tail: 731 >>> dev.ix.0.queue1.tso_tx: 1442 >>> dev.ix.0.queue1.no_tx_dma_setup: 0 >>> dev.ix.0.queue1.no_desc_avail: 5254761 >>> dev.ix.0.queue1.tx_packets: 15835062632 >>> dev.ix.0.queue1.rxd_head: 685 >>> dev.ix.0.queue1.rxd_tail: 681 >>> dev.ix.0.queue1.rx_packets: 21220715209 >>> dev.ix.0.queue1.rx_bytes: 54351679461 >>> dev.ix.0.queue1.rx_copies: 120833356 >>> dev.ix.0.queue1.lro_queued: 0 >>> dev.ix.0.queue1.lro_flushed: 0 >>> dev.ix.0.queue2.interrupt_rate: 5319 >>> dev.ix.0.queue2.irqs: 11532560324 >>> dev.ix.0.queue2.txd_head: 501 >>> dev.ix.0.queue2.txd_tail: 501 >>> dev.ix.0.queue2.tso_tx: 2474 >>> dev.ix.0.queue2.no_tx_dma_setup: 0 >>> dev.ix.0.queue2.no_desc_avail: 429244 >>> dev.ix.0.queue2.tx_packets: 15772209238 >>> dev.ix.0.queue2.rxd_head: 246 >>> dev.ix.0.queue2.rxd_tail: 244 >>> dev.ix.0.queue2.rx_packets: 21408648299 >>> dev.ix.0.queue2.rx_bytes: 56862350194 >>> dev.ix.0.queue2.rx_copies: 124973551 >>> dev.ix.0.queue2.lro_queued: 0 >>> dev.ix.0.queue2.lro_flushed: 0 >>> dev.ix.0.queue3.interrupt_rate: 20833 >>> dev.ix.0.queue3.irqs: 11557466322 >>> dev.ix.0.queue3.txd_head: 773 >>> dev.ix.0.queue3.txd_tail: 773 >>> dev.ix.0.queue3.tso_tx: 40 >>> dev.ix.0.queue3.no_tx_dma_setup: 0 >>> dev.ix.0.queue3.no_desc_avail: 665620 >>> dev.ix.0.queue3.tx_packets: 16479111658 >>> dev.ix.0.queue3.rxd_head: 1858 >>> dev.ix.0.queue3.rxd_tail: 1854 >>> dev.ix.0.queue3.rx_packets: 21412821769 >>> dev.ix.0.queue3.rx_bytes: 52796089467 >>> dev.ix.0.queue3.rx_copies: 127385950 >>> dev.ix.0.queue3.lro_queued: 0 >>> dev.ix.0.queue3.lro_flushed: 0 >>> dev.ix.0.queue4.interrupt_rate: 11363 >>> dev.ix.0.queue4.irqs: 10824852635 >>> dev.ix.0.queue4.txd_head: 1711 >>> dev.ix.0.queue4.txd_tail: 1713 >>> dev.ix.0.queue4.tso_tx: 581 >>> dev.ix.0.queue4.no_tx_dma_setup: 0 >>> dev.ix.0.queue4.no_desc_avail: 115346803 >>> dev.ix.0.queue4.tx_packets: 16100396810 >>> dev.ix.0.queue4.rxd_head: 244 >>> dev.ix.0.queue4.rxd_tail: 243 >>> dev.ix.0.queue4.rx_packets: 21240995210 >>> dev.ix.0.queue4.rx_bytes: 58726730771 >>> dev.ix.0.queue4.rx_copies: 124872141 >>> dev.ix.0.queue4.lro_queued: 0 >>> dev.ix.0.queue4.lro_flushed: 0 >>> dev.ix.0.queue5.interrupt_rate: 500000 >>> dev.ix.0.queue5.irqs: 10955464761 >>> dev.ix.0.queue5.txd_head: 75 >>> dev.ix.0.queue5.txd_tail: 77 >>> dev.ix.0.queue5.tso_tx: 1758 >>> dev.ix.0.queue5.no_tx_dma_setup: 0 >>> dev.ix.0.queue5.no_desc_avail: 4759 >>> dev.ix.0.queue5.tx_packets: 16267888038 >>> dev.ix.0.queue5.rxd_head: 905 >>> dev.ix.0.queue5.rxd_tail: 904 >>> dev.ix.0.queue5.rx_packets: 21381144028 >>> dev.ix.0.queue5.rx_bytes: 61800291690 >>> dev.ix.0.queue5.rx_copies: 129684798 >>> dev.ix.0.queue5.lro_queued: 0 >>> dev.ix.0.queue5.lro_flushed: 0 >>> dev.ix.0.queue6.interrupt_rate: 33333 >>> dev.ix.0.queue6.irqs: 11081350674 >>> dev.ix.0.queue6.txd_head: 1744 >>> dev.ix.0.queue6.txd_tail: 1746 >>> dev.ix.0.queue6.tso_tx: 38 >>> dev.ix.0.queue6.no_tx_dma_setup: 0 >>> dev.ix.0.queue6.no_desc_avail: 18381 >>> dev.ix.0.queue6.tx_packets: 15376961749 >>> dev.ix.0.queue6.rxd_head: 1783 >>> dev.ix.0.queue6.rxd_tail: 1782 >>> dev.ix.0.queue6.rx_packets: 21381814216 >>> dev.ix.0.queue6.rx_bytes: 56828960117 >>> dev.ix.0.queue6.rx_copies: 130194429 >>> dev.ix.0.queue6.lro_queued: 0 >>> dev.ix.0.queue6.lro_flushed: 0 >>> dev.ix.0.queue7.interrupt_rate: 5319 >>> dev.ix.0.queue7.irqs: 11014043865 >>> dev.ix.0.queue7.txd_head: 1545 >>> dev.ix.0.queue7.txd_tail: 1545 >>> dev.ix.0.queue7.tso_tx: 59 >>> dev.ix.0.queue7.no_tx_dma_setup: 0 >>> dev.ix.0.queue7.no_desc_avail: 5497 >>> dev.ix.0.queue7.tx_packets: 15283534142 >>> dev.ix.0.queue7.rxd_head: 184 >>> dev.ix.0.queue7.rxd_tail: 182 >>> dev.ix.0.queue7.rx_packets: 21431994087 >>> dev.ix.0.queue7.rx_bytes: 57942270182 >>> dev.ix.0.queue7.rx_copies: 128363306 >>> dev.ix.0.queue7.lro_queued: 0 >>> dev.ix.0.queue7.lro_flushed: 0 >>> dev.ix.0.mac_stats.crc_errs: 268 >>> dev.ix.0.mac_stats.ill_errs: 33 >>> dev.ix.0.mac_stats.byte_errs: 55 >>> dev.ix.0.mac_stats.short_discards: 0 >>> dev.ix.0.mac_stats.local_faults: 3484 >>> dev.ix.0.mac_stats.remote_faults: 121 >>> dev.ix.0.mac_stats.rec_len_errs: 0 >>> dev.ix.0.mac_stats.xon_txd: 1602713563748 >>> dev.ix.0.mac_stats.xon_recvd: 0 >>> dev.ix.0.mac_stats.xoff_txd: 108342810167 >>> dev.ix.0.mac_stats.xoff_recvd: 0 >>> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >>> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >>> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >>> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >>> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >>> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >>> dev.ix.0.mac_stats.rx_frames_64: 5356098 >>> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >>> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >>> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >>> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >>> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >>> dev.ix.0.mac_stats.recv_undersized: 0 >>> dev.ix.0.mac_stats.recv_fragmented: 0 >>> dev.ix.0.mac_stats.recv_oversized: 244078 >>> dev.ix.0.mac_stats.recv_jabberd: 4 >>> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >>> dev.ix.0.mac_stats.management_pkts_drpd: 0 >>> dev.ix.0.mac_stats.checksum_errs: 897344641 >>> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >>> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >>> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >>> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >>> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >>> dev.ix.0.mac_stats.management_pkts_txd: 0 >>> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >>> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >>> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >>> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >>> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >>> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >>> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - >>> 2.5.15 >>> dev.ix.1.%driver: ix >>> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >>> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>> subdevice=0x7a11 class=0x020000 >>> dev.ix.1.%parent: pci129 >>> dev.ix.1.fc: 3 >>> dev.ix.1.enable_aim: 1 >>> dev.ix.1.advertise_speed: 0 >>> dev.ix.1.dropped: 0 >>> dev.ix.1.mbuf_defrag_failed: 0 >>> dev.ix.1.watchdog_events: 0 >>> dev.ix.1.link_irq: 127925 >>> dev.ix.1.queue0.interrupt_rate: 11627 >>> dev.ix.1.queue0.irqs: 6686088831 >>> dev.ix.1.queue0.txd_head: 1618 >>> dev.ix.1.queue0.txd_tail: 1620 >>> dev.ix.1.queue0.tso_tx: 28 >>> dev.ix.1.queue0.no_tx_dma_setup: 0 >>> dev.ix.1.queue0.no_desc_avail: 0 >>> dev.ix.1.queue0.tx_packets: 13527334563 >>> dev.ix.1.queue0.rxd_head: 1715 >>> dev.ix.1.queue0.rxd_tail: 1714 >>> dev.ix.1.queue0.rx_packets: 1503775702 >>> dev.ix.1.queue0.rx_bytes: 1069295301 >>> dev.ix.1.queue0.rx_copies: 2983480 >>> dev.ix.1.queue0.lro_queued: 0 >>> dev.ix.1.queue0.lro_flushed: 0 >>> dev.ix.1.queue1.interrupt_rate: 5319 >>> dev.ix.1.queue1.irqs: 6546967336 >>> dev.ix.1.queue1.txd_head: 1812 >>> dev.ix.1.queue1.txd_tail: 1812 >>> dev.ix.1.queue1.tso_tx: 6 >>> dev.ix.1.queue1.no_tx_dma_setup: 0 >>> dev.ix.1.queue1.no_desc_avail: 0 >>> dev.ix.1.queue1.tx_packets: 13475453794 >>> dev.ix.1.queue1.rxd_head: 1246 >>> dev.ix.1.queue1.rxd_tail: 1245 >>> dev.ix.1.queue1.rx_packets: 1506444917 >>> dev.ix.1.queue1.rx_bytes: 783064190 >>> dev.ix.1.queue1.rx_copies: 2881513 >>> dev.ix.1.queue1.lro_queued: 0 >>> dev.ix.1.queue1.lro_flushed: 0 >>> dev.ix.1.queue2.interrupt_rate: 5319 >>> dev.ix.1.queue2.irqs: 6574615190 >>> dev.ix.1.queue2.txd_head: 1494 >>> dev.ix.1.queue2.txd_tail: 1494 >>> dev.ix.1.queue2.tso_tx: 33 >>> dev.ix.1.queue2.no_tx_dma_setup: 0 >>> dev.ix.1.queue2.no_desc_avail: 0 >>> dev.ix.1.queue2.tx_packets: 13555495169 >>> dev.ix.1.queue2.rxd_head: 438 >>> dev.ix.1.queue2.rxd_tail: 437 >>> dev.ix.1.queue2.rx_packets: 1501380848 >>> dev.ix.1.queue2.rx_bytes: 1008544082 >>> dev.ix.1.queue2.rx_copies: 2660960 >>> dev.ix.1.queue2.lro_queued: 0 >>> dev.ix.1.queue2.lro_flushed: 0 >>> dev.ix.1.queue3.interrupt_rate: 5319 >>> dev.ix.1.queue3.irqs: 6617964401 >>> dev.ix.1.queue3.txd_head: 1853 >>> dev.ix.1.queue3.txd_tail: 1855 >>> dev.ix.1.queue3.tso_tx: 10 >>> dev.ix.1.queue3.no_tx_dma_setup: 0 >>> dev.ix.1.queue3.no_desc_avail: 0 >>> dev.ix.1.queue3.tx_packets: 13561212942 >>> dev.ix.1.queue3.rxd_head: 429 >>> dev.ix.1.queue3.rxd_tail: 428 >>> dev.ix.1.queue3.rx_packets: 1498117903 >>> dev.ix.1.queue3.rx_bytes: 784881986 >>> dev.ix.1.queue3.rx_copies: 2695475 >>> dev.ix.1.queue3.lro_queued: 0 >>> dev.ix.1.queue3.lro_flushed: 0 >>> dev.ix.1.queue4.interrupt_rate: 5319 >>> dev.ix.1.queue4.irqs: 6575752163 >>> dev.ix.1.queue4.txd_head: 902 >>> dev.ix.1.queue4.txd_tail: 902 >>> dev.ix.1.queue4.tso_tx: 5 >>> dev.ix.1.queue4.no_tx_dma_setup: 0 >>> dev.ix.1.queue4.no_desc_avail: 0 >>> dev.ix.1.queue4.tx_packets: 13478514009 >>> dev.ix.1.queue4.rxd_head: 536 >>> dev.ix.1.queue4.rxd_tail: 535 >>> dev.ix.1.queue4.rx_packets: 1476720084 >>> dev.ix.1.queue4.rx_bytes: 944967171 >>> dev.ix.1.queue4.rx_copies: 2650672 >>> dev.ix.1.queue4.lro_queued: 0 >>> dev.ix.1.queue4.lro_flushed: 0 >>> dev.ix.1.queue5.interrupt_rate: 10416 >>> dev.ix.1.queue5.irqs: 6578099670 >>> dev.ix.1.queue5.txd_head: 1996 >>> dev.ix.1.queue5.txd_tail: 1996 >>> dev.ix.1.queue5.tso_tx: 663 >>> dev.ix.1.queue5.no_tx_dma_setup: 0 >>> dev.ix.1.queue5.no_desc_avail: 0 >>> dev.ix.1.queue5.tx_packets: 13516483196 >>> dev.ix.1.queue5.rxd_head: 1296 >>> dev.ix.1.queue5.rxd_tail: 1295 >>> dev.ix.1.queue5.rx_packets: 1496584151 >>> dev.ix.1.queue5.rx_bytes: 810434347 >>> dev.ix.1.queue5.rx_copies: 2899315 >>> dev.ix.1.queue5.lro_queued: 0 >>> dev.ix.1.queue5.lro_flushed: 0 >>> dev.ix.1.queue6.interrupt_rate: 5319 >>> dev.ix.1.queue6.irqs: 6624395782 >>> dev.ix.1.queue6.txd_head: 1058 >>> dev.ix.1.queue6.txd_tail: 1058 >>> dev.ix.1.queue6.tso_tx: 20 >>> dev.ix.1.queue6.no_tx_dma_setup: 0 >>> dev.ix.1.queue6.no_desc_avail: 0 >>> dev.ix.1.queue6.tx_packets: 13491315217 >>> dev.ix.1.queue6.rxd_head: 1550 >>> dev.ix.1.queue6.rxd_tail: 1549 >>> dev.ix.1.queue6.rx_packets: 1510907490 >>> dev.ix.1.queue6.rx_bytes: 719914325 >>> dev.ix.1.queue6.rx_copies: 2712955 >>> dev.ix.1.queue6.lro_queued: 0 >>> dev.ix.1.queue6.lro_flushed: 0 >>> dev.ix.1.queue7.interrupt_rate: 29411 >>> dev.ix.1.queue7.irqs: 6573304834 >>> dev.ix.1.queue7.txd_head: 784 >>> dev.ix.1.queue7.txd_tail: 786 >>> dev.ix.1.queue7.tso_tx: 2 >>> dev.ix.1.queue7.no_tx_dma_setup: 0 >>> dev.ix.1.queue7.no_desc_avail: 0 >>> dev.ix.1.queue7.tx_packets: 13587681458 >>> dev.ix.1.queue7.rxd_head: 1489 >>> dev.ix.1.queue7.rxd_tail: 1488 >>> dev.ix.1.queue7.rx_packets: 1504712031 >>> dev.ix.1.queue7.rx_bytes: 1216803328 >>> dev.ix.1.queue7.rx_copies: 2976103 >>> dev.ix.1.queue7.lro_queued: 0 >>> dev.ix.1.queue7.lro_flushed: 0 >>> dev.ix.1.mac_stats.crc_errs: 0 >>> dev.ix.1.mac_stats.ill_errs: 0 >>> dev.ix.1.mac_stats.byte_errs: 0 >>> dev.ix.1.mac_stats.short_discards: 0 >>> dev.ix.1.mac_stats.local_faults: 0 >>> dev.ix.1.mac_stats.remote_faults: 12 >>> dev.ix.1.mac_stats.rec_len_errs: 0 >>> dev.ix.1.mac_stats.xon_txd: 1714791401322 >>> dev.ix.1.mac_stats.xon_recvd: 0 >>> dev.ix.1.mac_stats.xoff_txd: 41095995010 >>> dev.ix.1.mac_stats.xoff_recvd: 0 >>> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >>> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >>> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >>> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >>> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >>> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >>> dev.ix.1.mac_stats.rx_frames_64: 73447 >>> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >>> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >>> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >>> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >>> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >>> dev.ix.1.mac_stats.recv_undersized: 0 >>> dev.ix.1.mac_stats.recv_fragmented: 0 >>> dev.ix.1.mac_stats.recv_oversized: 0 >>> dev.ix.1.mac_stats.recv_jabberd: 0 >>> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >>> dev.ix.1.mac_stats.management_pkts_drpd: 0 >>> dev.ix.1.mac_stats.checksum_errs: 85432477 >>> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >>> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >>> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >>> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >>> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >>> dev.ix.1.mac_stats.management_pkts_txd: 0 >>> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >>> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >>> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >>> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >>> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >>> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >>> >>> # cat /var/run/dmesg.boot >>> >>> Copyright (c) 1992-2014 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >>> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >>> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class CPU) >>> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >>> Stepping = 4 >>> >>> Features=0xbfebfbff >>> >>> Features2=0x7fbee3ff >>> AMD Features=0x2c100800 >>> AMD Features2=0x1 >>> Structured Extended Features=0x281 >>> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >>> TSC: P-state invariant, performance statistics >>> real memory = 17179869184 (16384 MB) >>> avail memory = 16515358720 (15750 MB) >>> Event timer "LAPIC" quality 600 >>> ACPI APIC Table: >>> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >>> FreeBSD/SMP: 2 package(s) x 6 core(s) >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP): APIC ID: 2 >>> cpu2 (AP): APIC ID: 4 >>> cpu3 (AP): APIC ID: 6 >>> cpu4 (AP): APIC ID: 8 >>> cpu5 (AP): APIC ID: 10 >>> cpu6 (AP): APIC ID: 32 >>> cpu7 (AP): APIC ID: 34 >>> cpu8 (AP): APIC ID: 36 >>> cpu9 (AP): APIC ID: 38 >>> cpu10 (AP): APIC ID: 40 >>> cpu11 (AP): APIC ID: 42 >>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, >>> using default 16 (20130823/tbfadt-682) >>> ioapic0 irqs 0-23 on motherboard >>> ioapic1 irqs 24-47 on motherboard >>> ioapic2 irqs 48-71 on motherboard >>> kbd1 at kbdmux0 >>> random: initialized >>> cryptosoft0: on motherboard >>> acpi0: on motherboard >>> acpi0: Power Button (fixed) >>> acpi0: reservation of 0, 9d000 (3) failed >>> cpu0: on acpi0 >>> cpu1: on acpi0 >>> cpu2: on acpi0 >>> cpu3: on acpi0 >>> cpu4: on acpi0 >>> cpu5: on acpi0 >>> cpu6: on acpi0 >>> cpu7: on acpi0 >>> cpu8: on acpi0 >>> cpu9: on acpi0 >>> cpu10: on acpi0 >>> cpu11: on acpi0 >>> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>> Event timer "HPET" frequency 14318180 Hz quality 350 >>> Event timer "HPET1" frequency 14318180 Hz quality 340 >>> Event timer "HPET2" frequency 14318180 Hz quality 340 >>> Event timer "HPET3" frequency 14318180 Hz quality 340 >>> Event timer "HPET4" frequency 14318180 Hz quality 340 >>> Event timer "HPET5" frequency 14318180 Hz quality 340 >>> Event timer "HPET6" frequency 14318180 Hz quality 340 >>> Event timer "HPET7" frequency 14318180 Hz quality 340 >>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>> atrtc0: Warning: Couldn't map I/O. >>> Event timer "RTC" frequency 32768 Hz quality 0 >>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> Event timer "i8254" frequency 1193182 Hz quality 100 >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pcib1: irq 47 at device 1.0 on pci0 >>> pci1: on pcib1 >>> pcib2: irq 47 at device 1.1 on pci0 >>> pci2: on pcib2 >>> igb0: port >>> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 at >>> device 0.0 on pci2 >>> igb0: Using MSIX interrupts with 9 vectors >>> igb0: Ethernet address: 00:1e:67:9a:d5:88 >>> 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 >>> igb0: Bound queue 4 to cpu 4 >>> igb0: Bound queue 5 to cpu 5 >>> igb0: Bound queue 6 to cpu 6 >>> igb0: Bound queue 7 to cpu 7 >>> igb1: port >>> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 at >>> device 0.1 on pci2 >>> igb1: Using MSIX interrupts with 9 vectors >>> igb1: Ethernet address: 00:1e:67:9a:d5:89 >>> igb1: Bound queue 0 to cpu 8 >>> igb1: Bound queue 1 to cpu 9 >>> igb1: Bound queue 2 to cpu 10 >>> igb1: Bound queue 3 to cpu 11 >>> igb1: Bound queue 4 to cpu 0 >>> igb1: Bound queue 5 to cpu 1 >>> igb1: Bound queue 6 to cpu 2 >>> igb1: Bound queue 7 to cpu 3 >>> igb2: port >>> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 at >>> device 0.2 on pci2 >>> igb2: Using MSIX interrupts with 9 vectors >>> igb2: Ethernet address: 00:1e:67:9a:d5:8a >>> igb2: Bound queue 0 to cpu 4 >>> igb2: Bound queue 1 to cpu 5 >>> igb2: Bound queue 2 to cpu 6 >>> igb2: Bound queue 3 to cpu 7 >>> igb2: Bound queue 4 to cpu 8 >>> igb2: Bound queue 5 to cpu 9 >>> igb2: Bound queue 6 to cpu 10 >>> igb2: Bound queue 7 to cpu 11 >>> igb3: port >>> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 at >>> device 0.3 on pci2 >>> igb3: Using MSIX interrupts with 9 vectors >>> igb3: Ethernet address: 00:1e:67:9a:d5:8b >>> igb3: Bound queue 0 to cpu 0 >>> igb3: Bound queue 1 to cpu 1 >>> igb3: Bound queue 2 to cpu 2 >>> igb3: Bound queue 3 to cpu 3 >>> igb3: Bound queue 4 to cpu 4 >>> igb3: Bound queue 5 to cpu 5 >>> igb3: Bound queue 6 to cpu 6 >>> igb3: Bound queue 7 to cpu 7 >>> pcib3: irq 47 at device 2.0 on pci0 >>> pci4: on pcib3 >>> igb4: mem >>> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 >>> igb4: Using MSIX interrupts with 9 vectors >>> igb4: Ethernet address: a0:36:9f:37:82:7e >>> igb4: Bound queue 0 to cpu 8 >>> igb4: Bound queue 1 to cpu 9 >>> igb4: Bound queue 2 to cpu 10 >>> igb4: Bound queue 3 to cpu 11 >>> igb4: Bound queue 4 to cpu 0 >>> igb4: Bound queue 5 to cpu 1 >>> igb4: Bound queue 6 to cpu 2 >>> igb4: Bound queue 7 to cpu 3 >>> igb5: mem >>> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 >>> igb5: Using MSIX interrupts with 9 vectors >>> igb5: Ethernet address: a0:36:9f:37:82:7f >>> igb5: Bound queue 0 to cpu 4 >>> igb5: Bound queue 1 to cpu 5 >>> igb5: Bound queue 2 to cpu 6 >>> igb5: Bound queue 3 to cpu 7 >>> igb5: Bound queue 4 to cpu 8 >>> igb5: Bound queue 5 to cpu 9 >>> igb5: Bound queue 6 to cpu 10 >>> igb5: Bound queue 7 to cpu 11 >>> pcib4: irq 16 at device 3.0 on pci0 >>> pci6: on pcib4 >>> igb6: mem >>> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 >>> igb6: Using MSIX interrupts with 9 vectors >>> igb6: Ethernet address: a0:36:9f:37:82:8a >>> igb6: Bound queue 0 to cpu 0 >>> igb6: Bound queue 1 to cpu 1 >>> igb6: Bound queue 2 to cpu 2 >>> igb6: Bound queue 3 to cpu 3 >>> igb6: Bound queue 4 to cpu 4 >>> igb6: Bound queue 5 to cpu 5 >>> igb6: Bound queue 6 to cpu 6 >>> igb6: Bound queue 7 to cpu 7 >>> igb7: mem >>> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 >>> igb7: Using MSIX interrupts with 9 vectors >>> igb7: Ethernet address: a0:36:9f:37:82:8b >>> igb7: Bound queue 0 to cpu 8 >>> igb7: Bound queue 1 to cpu 9 >>> igb7: Bound queue 2 to cpu 10 >>> igb7: Bound queue 3 to cpu 11 >>> igb7: Bound queue 4 to cpu 0 >>> igb7: Bound queue 5 to cpu 1 >>> igb7: Bound queue 6 to cpu 2 >>> igb7: Bound queue 7 to cpu 3 >>> pcib5: irq 16 at device 17.0 on pci0 >>> pci8: on pcib5 >>> pci0: at device 22.0 (no driver attached) >>> pci0: at device 22.1 (no driver attached) >>> ehci0: mem 0xd1220000-0xd12203ff irq >>> 22 at device 26.0 on pci0 >>> usbus0: EHCI version 1.0 >>> usbus0 on ehci0 >>> pcib6: irq 16 at device 28.0 on pci0 >>> pci9: on pcib6 >>> pcib7: irq 17 at device 28.5 on pci0 >>> pci10: on pcib7 >>> pci10: at device 0.0 (no driver attached) >>> pcib8: irq 19 at device 28.7 on pci0 >>> pci11: on pcib8 >>> vgapci0: mem >>> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq 19 at >>> device 0.0 on pci11 >>> vgapci0: Boot video device >>> ehci1: mem 0xd1210000-0xd12103ff irq >>> 20 at device 29.0 on pci0 >>> usbus1: EHCI version 1.0 >>> usbus1 on ehci1 >>> pcib9: at device 30.0 on pci0 >>> pci12: on pcib9 >>> isab0: at device 31.0 on pci0 >>> isa0: on isab0 >>> ahci0: port >>> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f mem >>> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >>> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >>> ahcich0: at channel 0 on ahci0 >>> ahcich1: at channel 1 on ahci0 >>> ahcich2: at channel 2 on ahci0 >>> ahcich3: at channel 3 on ahci0 >>> ahcich4: at channel 4 on ahci0 >>> ahcich5: at channel 5 on ahci0 >>> ahciem0: on ahci0 >>> pcib10: on acpi0 >>> pci128: on pcib10 >>> pcib11: irq 71 at device 1.0 on pci128 >>> pci129: on pcib11 >>> ix0: >>> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff irq 50 at >>> device 0.0 on pci129 >>> ix0: Using MSIX interrupts with 9 vectors >>> ix0: Ethernet address: 00:1b:21:89:25:32 >>> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >>> ix1: >>> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff irq 52 at >>> device 0.1 on pci129 >>> ix1: Using MSIX interrupts with 9 vectors >>> ix1: Ethernet address: 00:1b:21:89:25:33 >>> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >>> pcib12: irq 71 at device 2.0 on pci128 >>> pci131: on pcib12 >>> pcib13: irq 71 at device 3.0 on pci128 >>> pci132: on pcib13 >>> acpi_button0: on acpi0 >>> pcib14: on acpi0 >>> pci127: on pcib14 >>> pcib15: on acpi0 >>> pci255: on pcib15 >>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>> orm0: at iomem >>> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >>> on isa0 >>> sc0: at flags 0x100 on isa0 >>> sc0: VGA <16 virtual consoles, flags=0x300> >>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >>> est0: on cpu0 >>> p4tcc0: on cpu0 >>> est1: on cpu1 >>> p4tcc1: on cpu1 >>> est2: on cpu2 >>> p4tcc2: on cpu2 >>> est3: on cpu3 >>> p4tcc3: on cpu3 >>> est4: on cpu4 >>> p4tcc4: on cpu4 >>> est5: on cpu5 >>> p4tcc5: on cpu5 >>> est6: on cpu6 >>> p4tcc6: on cpu6 >>> est7: on cpu7 >>> p4tcc7: on cpu7 >>> est8: on cpu8 >>> p4tcc8: on cpu8 >>> est9: on cpu9 >>> p4tcc9: on cpu9 >>> est10: on cpu10 >>> p4tcc10: on cpu10 >>> est11: on cpu11 >>> p4tcc11: on cpu11 >>> random: unblocking device. >>> usbus0: 480Mbps High Speed USB v2.0 >>> Timecounters tick every 1.000 msec >>> IPsec: Initialized Security Association Processing. >>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, >>> logging disabled >>> usbus1: 480Mbps High Speed USB v2.0 >>> ugen1.1: at usbus1 >>> uhub0: on usbus1 >>> ugen0.1: at usbus0 >>> uhub1: on usbus0 >>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-9 SATA 3.x device >>> ada0: Serial Number S1D5NSAF687077K >>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>> ada0: Command Queueing enabled >>> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >>> ada0: quirks=0x1<4K> >>> ada0: Previously was known as ad4 >>> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >>> ses0: SEMB S-E-S 2.00 device >>> ses0: SEMB SES Device >>> SMP: AP CPU #6 Launched! >>> SMP: AP CPU #3 Launched! >>> SMP: AP CPU #11 Launched! >>> SMP: AP CPU #5 Launched! >>> SMP: AP CPU #9 Launched! >>> SMP: AP CPU #1 Launched! >>> SMP: AP CPU #10 Launched! >>> SMP: AP CPU #2 Launched! >>> SMP: AP CPU #8 Launched! >>> SMP: AP CPU #4 Launched! >>> SMP: AP CPU #7 Launched! >>> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >>> Root mount waiting for: usbus1 usbus0 >>> uhub1: 2 ports with 2 removable, self powered >>> uhub0: 2 ports with 2 removable, self powered >>> Root mount waiting for: usbus1 usbus0 >>> ugen1.2: at usbus1 >>> uhub2: on >>> usbus1 >>> ugen0.2: at usbus0 >>> uhub3: on >>> usbus0 >>> Root mount waiting for: usbus1 usbus0 >>> uhub3: 6 ports with 6 removable, self powered >>> uhub2: 8 ports with 8 removable, self powered >>> ugen1.3: at usbus1 >>> ukbd0: on usbus1 >>> kbd0 at ukbd0 >>> Root mount waiting for: usbus1 >>> ugen1.4: at usbus1 >>> ukbd1: on usbus1 >>> kbd2 at ukbd1 >>> Trying to mount root from ufs:/dev/label/rootfs [rw]... >>> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >>> member to prevent IPv6 address scope violation. >>> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >>> member to prevent IPv6 address scope violation. >>> ums0: on usbus1 >>> ums0: 3 buttons and [Z] coordinates ID=0 >>> uhid0: on usbus1 >>> >>> # uname -a >>> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 r274375: >>> Tue Nov 11 10:24:44 BRST 2014 >>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>> >>> [1] https://calomel.org/freebsd_network_tuning.html >>> [2] http://ark.intel.com/products/63157 >>> [3] >>> http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 >>> [4] http://ark.intel.com/products/59062/ >>> >>> Please I need a help! and sorry my english :) From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 00:38:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 534B1861 for ; Mon, 1 Dec 2014 00:38:08 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA03A15 for ; Mon, 1 Dec 2014 00:38:07 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 243FA139CB for ; Sun, 30 Nov 2014 22:38:21 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1417394296; x=1418258297; bh=cGG71/cZzVABuxLEhi5C9v8WH4iaNm1UTS0 +BJj7xFY=; b=X5mKDkGiYGdV3CRdaG1uE21JDqAQjCjDv5tTv7PQBg8E9fXOABi OACzvZQ2f0xF23xj9e42ohndxPxJQvzqocawtdgWZFfgrpTgS2TQZ/Nrwqd3qIVq AnNrXe5y/oWxrntKLEFtNXrO/tNLuUiwbHiuBhzrv2p8v9Jj75RtvLYk= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6tYG_p3vP2y for ; Sun, 30 Nov 2014 22:38:16 -0200 (BRST) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 8BCC3139CA for ; Sun, 30 Nov 2014 22:38:15 -0200 (BRST) Message-ID: <547BB862.6080801@bsdinfo.com.br> Date: Sun, 30 Nov 2014 22:37:54 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 00:38:08 -0000 Hi Jack, On 30/11/2014 16:20, Jack Vogel wrote: > Good suggestions, do you ever see any 'interrupt throttled' messages? You > might > want to change the storm threshold to 0 and disable it. I can try this: sysctl hw.intr_storm_threshold=0 > > I too would like to know if there are any messages when the 'hang' happens. Nope. No message. :( > > I don't know much about lagg, is it responsible for link events?? Its not a > normal > situation to be having so many :( > > Jack > > > On Sun, Nov 30, 2014 at 10:01 AM, Adrian Chadd wrote: > >> Your link_irq value is way too high. I think you're exposing some >> unhandled corner case in the driver (as I had this issue when I had >> some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe >> driver isn't getting link events. >> >> My test setup at home has link_irq=1 on both sides, and it runs >> full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for >> RSS testing for weeks at a time. I have no issues and no hiccups. >> So, I think there's two problems: >> >> * you're still seeing way too many link_irq events; and >> * i think there's some bad handling when it comes to link_irq events. >> >> I wonder if we're still clearing some of the interrupt register bits >> incorrectly in ixgbe_msix_link(). >> >> >> -adrian >> >> >> >> >> -adrian >> >> >> On 30 November 2014 at 08:05, Alexander V. Chernikov >> wrote: >>> On 30.11.2014 18:47, Marcelo Gondim wrote: >>>> Dear, >>>> >>>> Unfortunately I have more options to resolve this problem I'm having >> with >>>> Intel X520-SR2. Have we changed the X520, we exchange the optical cords, >>>> exchanged optical modules, we changed the entire server, we reduce the >>>> temperature inside the equipment, made some attempts to tunning the site >>>> calomel[1]. We spend a lot of money and do not solve the problem. >>>> >>>> What happens is that when there is a traffic above 1.2Gbps with PPS >> above >>>> 700kpps in sometimes almost daily there is a lock in two 10GbE ports the >>>> X520-SR interface. Where I am obliged to leave a script running in the >>>> background doing just that: >>> What does this "lock" looks like? >>> Do you using jumbo frames? >>> Is this IPv4 or IPv4+IPv6 ? >>> Can you share "netstat -m" output? >>> Do you use ipfw dynamic states? >>> Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? >>> >>> dev.ix.0.queue0.no_desc_avail: 3322269 >>> dev.ix.0.queue1.no_desc_avail: 5254761 >>> >>> Looks suspicious. Either you're running out of mbufs due to total mbuf >>> number is small, or system is very busy sometimes. >>> What does you "top -HPSzs1" output look like? >>> >>> >>>> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig ix1 up >>>> >>>> Made it back to the interface function normally. It's already so for >>>> months and have not tried the latest driver from Intel because I do not >> see >>>> anything related to this issue. >>>> >>>> These 2-port 10GbE are my backbone linking the four cities that attend >> to >>>> our main router. One is backup to other but when the problem occurs, >> the two >>>> ports stop working and at the moment I have a break in my Internet >>>> >>>> I can only conclude that the problem is one of the things below: >>>> >>>> 1 - Intel Interface X520-SR2 has a problem with certain types of traffic >>>> and then hangs. >>>> 2 - The ixgbe driver has a bug that is causing it. >>>> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >>>> would be a regression and the equipment is very far away from me if I >> need >>>> to move me. >>>> >>>> Honestly I'm almost going on a Juniper closed solution. I would not want >>>> to do this because I love FreeBSD and I can not believe that he does not >>>> support a 2.7Gbps traffic, which is my peak traffic without getting >> having >>>> these falls. My hardware today is this: >>>> >>>> hw.machine: amd64 >>>> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>>> hw.ncpu: 12 >>>> hw.byteorder: 1234 >>>> hw.physmem: 17083641856 >>>> hw.usermem: 15741001728 >>>> >>>> Hardware all Intel with motherboard S2600COE [2] and with network >>>> interfaces offboard: >>>> >>>> 1x - X520-SR2 [3] >>>> 2x - I350-T2 [4] >>>> >>>> My loader.conf: >>>> >>>> loader_logo="beastie" >>>> if_lagg_load="YES" >>>> speaker_load="YES" >>>> aio_load="YES" >>>> autoboot_delay="5" >>>> net.fibs=1 >>>> >>>> My sysctl.conf: >>>> >>>> net.inet.ip.forwarding=1 >>>> net.inet.ip.fastforwarding=1 >>>> net.inet6.ip6.forwarding=1 >>>> kern.ipc.somaxconn=4096 >>>> net.inet.tcp.syncookies=1 >>>> net.inet.ip.redirect=1 >>>> net.inet.ip.accept_sourceroute=0 >>>> net.inet.ip.sourceroute=0 >>>> net.inet.tcp.drop_synfin=1 >>>> net.inet.udp.blackhole=1 >>>> net.inet.tcp.blackhole=2 >>>> security.bsd.see_other_uids=0 >>>> net.inet.ip.fw.dyn_buckets=65536 >>>> net.inet.ip.fw.dyn_max=65536 >>>> hw.intr_storm_threshold=9000 >>>> net.inet.ip.dummynet.pipe_slot_limit=800 >>>> net.inet.icmp.icmplim=2000 >>>> >>>> # sysctl dev.ix. >>>> dev.ix.%parent: >>>> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - >>>> 2.5.15 >>>> dev.ix.0.%driver: ix >>>> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >>>> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>> subdevice=0x7a11 class=0x020000 >>>> dev.ix.0.%parent: pci129 >>>> dev.ix.0.fc: 3 >>>> dev.ix.0.enable_aim: 1 >>>> dev.ix.0.advertise_speed: 0 >>>> dev.ix.0.dropped: 0 >>>> dev.ix.0.mbuf_defrag_failed: 0 >>>> dev.ix.0.watchdog_events: 0 >>>> dev.ix.0.link_irq: 193783 >>>> dev.ix.0.queue0.interrupt_rate: 50000 >>>> dev.ix.0.queue0.irqs: 12029604413 >>>> dev.ix.0.queue0.txd_head: 1517 >>>> dev.ix.0.queue0.txd_tail: 1517 >>>> dev.ix.0.queue0.tso_tx: 85 >>>> dev.ix.0.queue0.no_tx_dma_setup: 0 >>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>> dev.ix.0.queue0.tx_packets: 15392658033 >>>> dev.ix.0.queue0.rxd_head: 709 >>>> dev.ix.0.queue0.rxd_tail: 707 >>>> dev.ix.0.queue0.rx_packets: 21762427837 >>>> dev.ix.0.queue0.rx_bytes: 56918345381 >>>> dev.ix.0.queue0.rx_copies: 124289013 >>>> dev.ix.0.queue0.lro_queued: 0 >>>> dev.ix.0.queue0.lro_flushed: 0 >>>> dev.ix.0.queue1.interrupt_rate: 500000 >>>> dev.ix.0.queue1.irqs: 11482146431 >>>> dev.ix.0.queue1.txd_head: 731 >>>> dev.ix.0.queue1.txd_tail: 731 >>>> dev.ix.0.queue1.tso_tx: 1442 >>>> dev.ix.0.queue1.no_tx_dma_setup: 0 >>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>> dev.ix.0.queue1.tx_packets: 15835062632 >>>> dev.ix.0.queue1.rxd_head: 685 >>>> dev.ix.0.queue1.rxd_tail: 681 >>>> dev.ix.0.queue1.rx_packets: 21220715209 >>>> dev.ix.0.queue1.rx_bytes: 54351679461 >>>> dev.ix.0.queue1.rx_copies: 120833356 >>>> dev.ix.0.queue1.lro_queued: 0 >>>> dev.ix.0.queue1.lro_flushed: 0 >>>> dev.ix.0.queue2.interrupt_rate: 5319 >>>> dev.ix.0.queue2.irqs: 11532560324 >>>> dev.ix.0.queue2.txd_head: 501 >>>> dev.ix.0.queue2.txd_tail: 501 >>>> dev.ix.0.queue2.tso_tx: 2474 >>>> dev.ix.0.queue2.no_tx_dma_setup: 0 >>>> dev.ix.0.queue2.no_desc_avail: 429244 >>>> dev.ix.0.queue2.tx_packets: 15772209238 >>>> dev.ix.0.queue2.rxd_head: 246 >>>> dev.ix.0.queue2.rxd_tail: 244 >>>> dev.ix.0.queue2.rx_packets: 21408648299 >>>> dev.ix.0.queue2.rx_bytes: 56862350194 >>>> dev.ix.0.queue2.rx_copies: 124973551 >>>> dev.ix.0.queue2.lro_queued: 0 >>>> dev.ix.0.queue2.lro_flushed: 0 >>>> dev.ix.0.queue3.interrupt_rate: 20833 >>>> dev.ix.0.queue3.irqs: 11557466322 >>>> dev.ix.0.queue3.txd_head: 773 >>>> dev.ix.0.queue3.txd_tail: 773 >>>> dev.ix.0.queue3.tso_tx: 40 >>>> dev.ix.0.queue3.no_tx_dma_setup: 0 >>>> dev.ix.0.queue3.no_desc_avail: 665620 >>>> dev.ix.0.queue3.tx_packets: 16479111658 >>>> dev.ix.0.queue3.rxd_head: 1858 >>>> dev.ix.0.queue3.rxd_tail: 1854 >>>> dev.ix.0.queue3.rx_packets: 21412821769 >>>> dev.ix.0.queue3.rx_bytes: 52796089467 >>>> dev.ix.0.queue3.rx_copies: 127385950 >>>> dev.ix.0.queue3.lro_queued: 0 >>>> dev.ix.0.queue3.lro_flushed: 0 >>>> dev.ix.0.queue4.interrupt_rate: 11363 >>>> dev.ix.0.queue4.irqs: 10824852635 >>>> dev.ix.0.queue4.txd_head: 1711 >>>> dev.ix.0.queue4.txd_tail: 1713 >>>> dev.ix.0.queue4.tso_tx: 581 >>>> dev.ix.0.queue4.no_tx_dma_setup: 0 >>>> dev.ix.0.queue4.no_desc_avail: 115346803 >>>> dev.ix.0.queue4.tx_packets: 16100396810 >>>> dev.ix.0.queue4.rxd_head: 244 >>>> dev.ix.0.queue4.rxd_tail: 243 >>>> dev.ix.0.queue4.rx_packets: 21240995210 >>>> dev.ix.0.queue4.rx_bytes: 58726730771 >>>> dev.ix.0.queue4.rx_copies: 124872141 >>>> dev.ix.0.queue4.lro_queued: 0 >>>> dev.ix.0.queue4.lro_flushed: 0 >>>> dev.ix.0.queue5.interrupt_rate: 500000 >>>> dev.ix.0.queue5.irqs: 10955464761 >>>> dev.ix.0.queue5.txd_head: 75 >>>> dev.ix.0.queue5.txd_tail: 77 >>>> dev.ix.0.queue5.tso_tx: 1758 >>>> dev.ix.0.queue5.no_tx_dma_setup: 0 >>>> dev.ix.0.queue5.no_desc_avail: 4759 >>>> dev.ix.0.queue5.tx_packets: 16267888038 >>>> dev.ix.0.queue5.rxd_head: 905 >>>> dev.ix.0.queue5.rxd_tail: 904 >>>> dev.ix.0.queue5.rx_packets: 21381144028 >>>> dev.ix.0.queue5.rx_bytes: 61800291690 >>>> dev.ix.0.queue5.rx_copies: 129684798 >>>> dev.ix.0.queue5.lro_queued: 0 >>>> dev.ix.0.queue5.lro_flushed: 0 >>>> dev.ix.0.queue6.interrupt_rate: 33333 >>>> dev.ix.0.queue6.irqs: 11081350674 >>>> dev.ix.0.queue6.txd_head: 1744 >>>> dev.ix.0.queue6.txd_tail: 1746 >>>> dev.ix.0.queue6.tso_tx: 38 >>>> dev.ix.0.queue6.no_tx_dma_setup: 0 >>>> dev.ix.0.queue6.no_desc_avail: 18381 >>>> dev.ix.0.queue6.tx_packets: 15376961749 >>>> dev.ix.0.queue6.rxd_head: 1783 >>>> dev.ix.0.queue6.rxd_tail: 1782 >>>> dev.ix.0.queue6.rx_packets: 21381814216 >>>> dev.ix.0.queue6.rx_bytes: 56828960117 >>>> dev.ix.0.queue6.rx_copies: 130194429 >>>> dev.ix.0.queue6.lro_queued: 0 >>>> dev.ix.0.queue6.lro_flushed: 0 >>>> dev.ix.0.queue7.interrupt_rate: 5319 >>>> dev.ix.0.queue7.irqs: 11014043865 >>>> dev.ix.0.queue7.txd_head: 1545 >>>> dev.ix.0.queue7.txd_tail: 1545 >>>> dev.ix.0.queue7.tso_tx: 59 >>>> dev.ix.0.queue7.no_tx_dma_setup: 0 >>>> dev.ix.0.queue7.no_desc_avail: 5497 >>>> dev.ix.0.queue7.tx_packets: 15283534142 >>>> dev.ix.0.queue7.rxd_head: 184 >>>> dev.ix.0.queue7.rxd_tail: 182 >>>> dev.ix.0.queue7.rx_packets: 21431994087 >>>> dev.ix.0.queue7.rx_bytes: 57942270182 >>>> dev.ix.0.queue7.rx_copies: 128363306 >>>> dev.ix.0.queue7.lro_queued: 0 >>>> dev.ix.0.queue7.lro_flushed: 0 >>>> dev.ix.0.mac_stats.crc_errs: 268 >>>> dev.ix.0.mac_stats.ill_errs: 33 >>>> dev.ix.0.mac_stats.byte_errs: 55 >>>> dev.ix.0.mac_stats.short_discards: 0 >>>> dev.ix.0.mac_stats.local_faults: 3484 >>>> dev.ix.0.mac_stats.remote_faults: 121 >>>> dev.ix.0.mac_stats.rec_len_errs: 0 >>>> dev.ix.0.mac_stats.xon_txd: 1602713563748 >>>> dev.ix.0.mac_stats.xon_recvd: 0 >>>> dev.ix.0.mac_stats.xoff_txd: 108342810167 >>>> dev.ix.0.mac_stats.xoff_recvd: 0 >>>> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >>>> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >>>> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >>>> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >>>> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >>>> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >>>> dev.ix.0.mac_stats.rx_frames_64: 5356098 >>>> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >>>> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >>>> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >>>> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >>>> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >>>> dev.ix.0.mac_stats.recv_undersized: 0 >>>> dev.ix.0.mac_stats.recv_fragmented: 0 >>>> dev.ix.0.mac_stats.recv_oversized: 244078 >>>> dev.ix.0.mac_stats.recv_jabberd: 4 >>>> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >>>> dev.ix.0.mac_stats.management_pkts_drpd: 0 >>>> dev.ix.0.mac_stats.checksum_errs: 897344641 >>>> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >>>> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >>>> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >>>> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >>>> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >>>> dev.ix.0.mac_stats.management_pkts_txd: 0 >>>> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >>>> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >>>> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >>>> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >>>> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >>>> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >>>> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - >>>> 2.5.15 >>>> dev.ix.1.%driver: ix >>>> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >>>> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>> subdevice=0x7a11 class=0x020000 >>>> dev.ix.1.%parent: pci129 >>>> dev.ix.1.fc: 3 >>>> dev.ix.1.enable_aim: 1 >>>> dev.ix.1.advertise_speed: 0 >>>> dev.ix.1.dropped: 0 >>>> dev.ix.1.mbuf_defrag_failed: 0 >>>> dev.ix.1.watchdog_events: 0 >>>> dev.ix.1.link_irq: 127925 >>>> dev.ix.1.queue0.interrupt_rate: 11627 >>>> dev.ix.1.queue0.irqs: 6686088831 >>>> dev.ix.1.queue0.txd_head: 1618 >>>> dev.ix.1.queue0.txd_tail: 1620 >>>> dev.ix.1.queue0.tso_tx: 28 >>>> dev.ix.1.queue0.no_tx_dma_setup: 0 >>>> dev.ix.1.queue0.no_desc_avail: 0 >>>> dev.ix.1.queue0.tx_packets: 13527334563 >>>> dev.ix.1.queue0.rxd_head: 1715 >>>> dev.ix.1.queue0.rxd_tail: 1714 >>>> dev.ix.1.queue0.rx_packets: 1503775702 >>>> dev.ix.1.queue0.rx_bytes: 1069295301 >>>> dev.ix.1.queue0.rx_copies: 2983480 >>>> dev.ix.1.queue0.lro_queued: 0 >>>> dev.ix.1.queue0.lro_flushed: 0 >>>> dev.ix.1.queue1.interrupt_rate: 5319 >>>> dev.ix.1.queue1.irqs: 6546967336 >>>> dev.ix.1.queue1.txd_head: 1812 >>>> dev.ix.1.queue1.txd_tail: 1812 >>>> dev.ix.1.queue1.tso_tx: 6 >>>> dev.ix.1.queue1.no_tx_dma_setup: 0 >>>> dev.ix.1.queue1.no_desc_avail: 0 >>>> dev.ix.1.queue1.tx_packets: 13475453794 >>>> dev.ix.1.queue1.rxd_head: 1246 >>>> dev.ix.1.queue1.rxd_tail: 1245 >>>> dev.ix.1.queue1.rx_packets: 1506444917 >>>> dev.ix.1.queue1.rx_bytes: 783064190 >>>> dev.ix.1.queue1.rx_copies: 2881513 >>>> dev.ix.1.queue1.lro_queued: 0 >>>> dev.ix.1.queue1.lro_flushed: 0 >>>> dev.ix.1.queue2.interrupt_rate: 5319 >>>> dev.ix.1.queue2.irqs: 6574615190 >>>> dev.ix.1.queue2.txd_head: 1494 >>>> dev.ix.1.queue2.txd_tail: 1494 >>>> dev.ix.1.queue2.tso_tx: 33 >>>> dev.ix.1.queue2.no_tx_dma_setup: 0 >>>> dev.ix.1.queue2.no_desc_avail: 0 >>>> dev.ix.1.queue2.tx_packets: 13555495169 >>>> dev.ix.1.queue2.rxd_head: 438 >>>> dev.ix.1.queue2.rxd_tail: 437 >>>> dev.ix.1.queue2.rx_packets: 1501380848 >>>> dev.ix.1.queue2.rx_bytes: 1008544082 >>>> dev.ix.1.queue2.rx_copies: 2660960 >>>> dev.ix.1.queue2.lro_queued: 0 >>>> dev.ix.1.queue2.lro_flushed: 0 >>>> dev.ix.1.queue3.interrupt_rate: 5319 >>>> dev.ix.1.queue3.irqs: 6617964401 >>>> dev.ix.1.queue3.txd_head: 1853 >>>> dev.ix.1.queue3.txd_tail: 1855 >>>> dev.ix.1.queue3.tso_tx: 10 >>>> dev.ix.1.queue3.no_tx_dma_setup: 0 >>>> dev.ix.1.queue3.no_desc_avail: 0 >>>> dev.ix.1.queue3.tx_packets: 13561212942 >>>> dev.ix.1.queue3.rxd_head: 429 >>>> dev.ix.1.queue3.rxd_tail: 428 >>>> dev.ix.1.queue3.rx_packets: 1498117903 >>>> dev.ix.1.queue3.rx_bytes: 784881986 >>>> dev.ix.1.queue3.rx_copies: 2695475 >>>> dev.ix.1.queue3.lro_queued: 0 >>>> dev.ix.1.queue3.lro_flushed: 0 >>>> dev.ix.1.queue4.interrupt_rate: 5319 >>>> dev.ix.1.queue4.irqs: 6575752163 >>>> dev.ix.1.queue4.txd_head: 902 >>>> dev.ix.1.queue4.txd_tail: 902 >>>> dev.ix.1.queue4.tso_tx: 5 >>>> dev.ix.1.queue4.no_tx_dma_setup: 0 >>>> dev.ix.1.queue4.no_desc_avail: 0 >>>> dev.ix.1.queue4.tx_packets: 13478514009 >>>> dev.ix.1.queue4.rxd_head: 536 >>>> dev.ix.1.queue4.rxd_tail: 535 >>>> dev.ix.1.queue4.rx_packets: 1476720084 >>>> dev.ix.1.queue4.rx_bytes: 944967171 >>>> dev.ix.1.queue4.rx_copies: 2650672 >>>> dev.ix.1.queue4.lro_queued: 0 >>>> dev.ix.1.queue4.lro_flushed: 0 >>>> dev.ix.1.queue5.interrupt_rate: 10416 >>>> dev.ix.1.queue5.irqs: 6578099670 >>>> dev.ix.1.queue5.txd_head: 1996 >>>> dev.ix.1.queue5.txd_tail: 1996 >>>> dev.ix.1.queue5.tso_tx: 663 >>>> dev.ix.1.queue5.no_tx_dma_setup: 0 >>>> dev.ix.1.queue5.no_desc_avail: 0 >>>> dev.ix.1.queue5.tx_packets: 13516483196 >>>> dev.ix.1.queue5.rxd_head: 1296 >>>> dev.ix.1.queue5.rxd_tail: 1295 >>>> dev.ix.1.queue5.rx_packets: 1496584151 >>>> dev.ix.1.queue5.rx_bytes: 810434347 >>>> dev.ix.1.queue5.rx_copies: 2899315 >>>> dev.ix.1.queue5.lro_queued: 0 >>>> dev.ix.1.queue5.lro_flushed: 0 >>>> dev.ix.1.queue6.interrupt_rate: 5319 >>>> dev.ix.1.queue6.irqs: 6624395782 >>>> dev.ix.1.queue6.txd_head: 1058 >>>> dev.ix.1.queue6.txd_tail: 1058 >>>> dev.ix.1.queue6.tso_tx: 20 >>>> dev.ix.1.queue6.no_tx_dma_setup: 0 >>>> dev.ix.1.queue6.no_desc_avail: 0 >>>> dev.ix.1.queue6.tx_packets: 13491315217 >>>> dev.ix.1.queue6.rxd_head: 1550 >>>> dev.ix.1.queue6.rxd_tail: 1549 >>>> dev.ix.1.queue6.rx_packets: 1510907490 >>>> dev.ix.1.queue6.rx_bytes: 719914325 >>>> dev.ix.1.queue6.rx_copies: 2712955 >>>> dev.ix.1.queue6.lro_queued: 0 >>>> dev.ix.1.queue6.lro_flushed: 0 >>>> dev.ix.1.queue7.interrupt_rate: 29411 >>>> dev.ix.1.queue7.irqs: 6573304834 >>>> dev.ix.1.queue7.txd_head: 784 >>>> dev.ix.1.queue7.txd_tail: 786 >>>> dev.ix.1.queue7.tso_tx: 2 >>>> dev.ix.1.queue7.no_tx_dma_setup: 0 >>>> dev.ix.1.queue7.no_desc_avail: 0 >>>> dev.ix.1.queue7.tx_packets: 13587681458 >>>> dev.ix.1.queue7.rxd_head: 1489 >>>> dev.ix.1.queue7.rxd_tail: 1488 >>>> dev.ix.1.queue7.rx_packets: 1504712031 >>>> dev.ix.1.queue7.rx_bytes: 1216803328 >>>> dev.ix.1.queue7.rx_copies: 2976103 >>>> dev.ix.1.queue7.lro_queued: 0 >>>> dev.ix.1.queue7.lro_flushed: 0 >>>> dev.ix.1.mac_stats.crc_errs: 0 >>>> dev.ix.1.mac_stats.ill_errs: 0 >>>> dev.ix.1.mac_stats.byte_errs: 0 >>>> dev.ix.1.mac_stats.short_discards: 0 >>>> dev.ix.1.mac_stats.local_faults: 0 >>>> dev.ix.1.mac_stats.remote_faults: 12 >>>> dev.ix.1.mac_stats.rec_len_errs: 0 >>>> dev.ix.1.mac_stats.xon_txd: 1714791401322 >>>> dev.ix.1.mac_stats.xon_recvd: 0 >>>> dev.ix.1.mac_stats.xoff_txd: 41095995010 >>>> dev.ix.1.mac_stats.xoff_recvd: 0 >>>> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >>>> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >>>> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >>>> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >>>> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >>>> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >>>> dev.ix.1.mac_stats.rx_frames_64: 73447 >>>> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >>>> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >>>> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >>>> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >>>> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >>>> dev.ix.1.mac_stats.recv_undersized: 0 >>>> dev.ix.1.mac_stats.recv_fragmented: 0 >>>> dev.ix.1.mac_stats.recv_oversized: 0 >>>> dev.ix.1.mac_stats.recv_jabberd: 0 >>>> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >>>> dev.ix.1.mac_stats.management_pkts_drpd: 0 >>>> dev.ix.1.mac_stats.checksum_errs: 85432477 >>>> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >>>> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >>>> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >>>> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >>>> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >>>> dev.ix.1.mac_stats.management_pkts_txd: 0 >>>> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >>>> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >>>> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >>>> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >>>> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >>>> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >>>> >>>> # cat /var/run/dmesg.boot >>>> >>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>>> The Regents of the University of California. All rights >> reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >>>> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 >>>> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class >> CPU) >>>> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >>>> Stepping = 4 >>>> >>>> >> Features=0xbfebfbff >>>> >> Features2=0x7fbee3ff >>>> AMD Features=0x2c100800 >>>> AMD Features2=0x1 >>>> Structured Extended Features=0x281 >>>> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >>>> TSC: P-state invariant, performance statistics >>>> real memory = 17179869184 (16384 MB) >>>> avail memory = 16515358720 (15750 MB) >>>> Event timer "LAPIC" quality 600 >>>> ACPI APIC Table: >>>> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >>>> FreeBSD/SMP: 2 package(s) x 6 core(s) >>>> cpu0 (BSP): APIC ID: 0 >>>> cpu1 (AP): APIC ID: 2 >>>> cpu2 (AP): APIC ID: 4 >>>> cpu3 (AP): APIC ID: 6 >>>> cpu4 (AP): APIC ID: 8 >>>> cpu5 (AP): APIC ID: 10 >>>> cpu6 (AP): APIC ID: 32 >>>> cpu7 (AP): APIC ID: 34 >>>> cpu8 (AP): APIC ID: 36 >>>> cpu9 (AP): APIC ID: 38 >>>> cpu10 (AP): APIC ID: 40 >>>> cpu11 (AP): APIC ID: 42 >>>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, >>>> using default 16 (20130823/tbfadt-682) >>>> ioapic0 irqs 0-23 on motherboard >>>> ioapic1 irqs 24-47 on motherboard >>>> ioapic2 irqs 48-71 on motherboard >>>> kbd1 at kbdmux0 >>>> random: initialized >>>> cryptosoft0: on motherboard >>>> acpi0: on motherboard >>>> acpi0: Power Button (fixed) >>>> acpi0: reservation of 0, 9d000 (3) failed >>>> cpu0: on acpi0 >>>> cpu1: on acpi0 >>>> cpu2: on acpi0 >>>> cpu3: on acpi0 >>>> cpu4: on acpi0 >>>> cpu5: on acpi0 >>>> cpu6: on acpi0 >>>> cpu7: on acpi0 >>>> cpu8: on acpi0 >>>> cpu9: on acpi0 >>>> cpu10: on acpi0 >>>> cpu11: on acpi0 >>>> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >>>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>>> Event timer "HPET" frequency 14318180 Hz quality 350 >>>> Event timer "HPET1" frequency 14318180 Hz quality 340 >>>> Event timer "HPET2" frequency 14318180 Hz quality 340 >>>> Event timer "HPET3" frequency 14318180 Hz quality 340 >>>> Event timer "HPET4" frequency 14318180 Hz quality 340 >>>> Event timer "HPET5" frequency 14318180 Hz quality 340 >>>> Event timer "HPET6" frequency 14318180 Hz quality 340 >>>> Event timer "HPET7" frequency 14318180 Hz quality 340 >>>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>>> atrtc0: Warning: Couldn't map I/O. >>>> Event timer "RTC" frequency 32768 Hz quality 0 >>>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> Event timer "i8254" frequency 1193182 Hz quality 100 >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> pcib1: irq 47 at device 1.0 on pci0 >>>> pci1: on pcib1 >>>> pcib2: irq 47 at device 1.1 on pci0 >>>> pci2: on pcib2 >>>> igb0: port >>>> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq 27 at >>>> device 0.0 on pci2 >>>> igb0: Using MSIX interrupts with 9 vectors >>>> igb0: Ethernet address: 00:1e:67:9a:d5:88 >>>> 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 >>>> igb0: Bound queue 4 to cpu 4 >>>> igb0: Bound queue 5 to cpu 5 >>>> igb0: Bound queue 6 to cpu 6 >>>> igb0: Bound queue 7 to cpu 7 >>>> igb1: port >>>> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq 30 at >>>> device 0.1 on pci2 >>>> igb1: Using MSIX interrupts with 9 vectors >>>> igb1: Ethernet address: 00:1e:67:9a:d5:89 >>>> igb1: Bound queue 0 to cpu 8 >>>> igb1: Bound queue 1 to cpu 9 >>>> igb1: Bound queue 2 to cpu 10 >>>> igb1: Bound queue 3 to cpu 11 >>>> igb1: Bound queue 4 to cpu 0 >>>> igb1: Bound queue 5 to cpu 1 >>>> igb1: Bound queue 6 to cpu 2 >>>> igb1: Bound queue 7 to cpu 3 >>>> igb2: port >>>> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq 28 at >>>> device 0.2 on pci2 >>>> igb2: Using MSIX interrupts with 9 vectors >>>> igb2: Ethernet address: 00:1e:67:9a:d5:8a >>>> igb2: Bound queue 0 to cpu 4 >>>> igb2: Bound queue 1 to cpu 5 >>>> igb2: Bound queue 2 to cpu 6 >>>> igb2: Bound queue 3 to cpu 7 >>>> igb2: Bound queue 4 to cpu 8 >>>> igb2: Bound queue 5 to cpu 9 >>>> igb2: Bound queue 6 to cpu 10 >>>> igb2: Bound queue 7 to cpu 11 >>>> igb3: port >>>> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq 29 at >>>> device 0.3 on pci2 >>>> igb3: Using MSIX interrupts with 9 vectors >>>> igb3: Ethernet address: 00:1e:67:9a:d5:8b >>>> igb3: Bound queue 0 to cpu 0 >>>> igb3: Bound queue 1 to cpu 1 >>>> igb3: Bound queue 2 to cpu 2 >>>> igb3: Bound queue 3 to cpu 3 >>>> igb3: Bound queue 4 to cpu 4 >>>> igb3: Bound queue 5 to cpu 5 >>>> igb3: Bound queue 6 to cpu 6 >>>> igb3: Bound queue 7 to cpu 7 >>>> pcib3: irq 47 at device 2.0 on pci0 >>>> pci4: on pcib3 >>>> igb4: mem >>>> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 on pci4 >>>> igb4: Using MSIX interrupts with 9 vectors >>>> igb4: Ethernet address: a0:36:9f:37:82:7e >>>> igb4: Bound queue 0 to cpu 8 >>>> igb4: Bound queue 1 to cpu 9 >>>> igb4: Bound queue 2 to cpu 10 >>>> igb4: Bound queue 3 to cpu 11 >>>> igb4: Bound queue 4 to cpu 0 >>>> igb4: Bound queue 5 to cpu 1 >>>> igb4: Bound queue 6 to cpu 2 >>>> igb4: Bound queue 7 to cpu 3 >>>> igb5: mem >>>> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 on pci4 >>>> igb5: Using MSIX interrupts with 9 vectors >>>> igb5: Ethernet address: a0:36:9f:37:82:7f >>>> igb5: Bound queue 0 to cpu 4 >>>> igb5: Bound queue 1 to cpu 5 >>>> igb5: Bound queue 2 to cpu 6 >>>> igb5: Bound queue 3 to cpu 7 >>>> igb5: Bound queue 4 to cpu 8 >>>> igb5: Bound queue 5 to cpu 9 >>>> igb5: Bound queue 6 to cpu 10 >>>> igb5: Bound queue 7 to cpu 11 >>>> pcib4: irq 16 at device 3.0 on pci0 >>>> pci6: on pcib4 >>>> igb6: mem >>>> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 on pci6 >>>> igb6: Using MSIX interrupts with 9 vectors >>>> igb6: Ethernet address: a0:36:9f:37:82:8a >>>> igb6: Bound queue 0 to cpu 0 >>>> igb6: Bound queue 1 to cpu 1 >>>> igb6: Bound queue 2 to cpu 2 >>>> igb6: Bound queue 3 to cpu 3 >>>> igb6: Bound queue 4 to cpu 4 >>>> igb6: Bound queue 5 to cpu 5 >>>> igb6: Bound queue 6 to cpu 6 >>>> igb6: Bound queue 7 to cpu 7 >>>> igb7: mem >>>> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 on pci6 >>>> igb7: Using MSIX interrupts with 9 vectors >>>> igb7: Ethernet address: a0:36:9f:37:82:8b >>>> igb7: Bound queue 0 to cpu 8 >>>> igb7: Bound queue 1 to cpu 9 >>>> igb7: Bound queue 2 to cpu 10 >>>> igb7: Bound queue 3 to cpu 11 >>>> igb7: Bound queue 4 to cpu 0 >>>> igb7: Bound queue 5 to cpu 1 >>>> igb7: Bound queue 6 to cpu 2 >>>> igb7: Bound queue 7 to cpu 3 >>>> pcib5: irq 16 at device 17.0 on pci0 >>>> pci8: on pcib5 >>>> pci0: at device 22.0 (no driver attached) >>>> pci0: at device 22.1 (no driver attached) >>>> ehci0: mem 0xd1220000-0xd12203ff irq >>>> 22 at device 26.0 on pci0 >>>> usbus0: EHCI version 1.0 >>>> usbus0 on ehci0 >>>> pcib6: irq 16 at device 28.0 on pci0 >>>> pci9: on pcib6 >>>> pcib7: irq 17 at device 28.5 on pci0 >>>> pci10: on pcib7 >>>> pci10: at device 0.0 (no driver attached) >>>> pcib8: irq 19 at device 28.7 on pci0 >>>> pci11: on pcib8 >>>> vgapci0: mem >>>> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq >> 19 at >>>> device 0.0 on pci11 >>>> vgapci0: Boot video device >>>> ehci1: mem 0xd1210000-0xd12103ff irq >>>> 20 at device 29.0 on pci0 >>>> usbus1: EHCI version 1.0 >>>> usbus1 on ehci1 >>>> pcib9: at device 30.0 on pci0 >>>> pci12: on pcib9 >>>> isab0: at device 31.0 on pci0 >>>> isa0: on isab0 >>>> ahci0: port >>>> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f >> mem >>>> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >>>> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >>>> ahcich0: at channel 0 on ahci0 >>>> ahcich1: at channel 1 on ahci0 >>>> ahcich2: at channel 2 on ahci0 >>>> ahcich3: at channel 3 on ahci0 >>>> ahcich4: at channel 4 on ahci0 >>>> ahcich5: at channel 5 on ahci0 >>>> ahciem0: on ahci0 >>>> pcib10: on acpi0 >>>> pci128: on pcib10 >>>> pcib11: irq 71 at device 1.0 on pci128 >>>> pci129: on pcib11 >>>> ix0: >>>> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff irq >> 50 at >>>> device 0.0 on pci129 >>>> ix0: Using MSIX interrupts with 9 vectors >>>> ix0: Ethernet address: 00:1b:21:89:25:32 >>>> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >>>> ix1: >>>> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff irq >> 52 at >>>> device 0.1 on pci129 >>>> ix1: Using MSIX interrupts with 9 vectors >>>> ix1: Ethernet address: 00:1b:21:89:25:33 >>>> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >>>> pcib12: irq 71 at device 2.0 on pci128 >>>> pci131: on pcib12 >>>> pcib13: irq 71 at device 3.0 on pci128 >>>> pci132: on pcib13 >>>> acpi_button0: on acpi0 >>>> pcib14: on acpi0 >>>> pci127: on pcib14 >>>> pcib15: on acpi0 >>>> pci255: on pcib15 >>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>>> orm0: at iomem >>>> >> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >>>> on isa0 >>>> sc0: at flags 0x100 on isa0 >>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >> isa0 >>>> est0: on cpu0 >>>> p4tcc0: on cpu0 >>>> est1: on cpu1 >>>> p4tcc1: on cpu1 >>>> est2: on cpu2 >>>> p4tcc2: on cpu2 >>>> est3: on cpu3 >>>> p4tcc3: on cpu3 >>>> est4: on cpu4 >>>> p4tcc4: on cpu4 >>>> est5: on cpu5 >>>> p4tcc5: on cpu5 >>>> est6: on cpu6 >>>> p4tcc6: on cpu6 >>>> est7: on cpu7 >>>> p4tcc7: on cpu7 >>>> est8: on cpu8 >>>> p4tcc8: on cpu8 >>>> est9: on cpu9 >>>> p4tcc9: on cpu9 >>>> est10: on cpu10 >>>> p4tcc10: on cpu10 >>>> est11: on cpu11 >>>> p4tcc11: on cpu11 >>>> random: unblocking device. >>>> usbus0: 480Mbps High Speed USB v2.0 >>>> Timecounters tick every 1.000 msec >>>> IPsec: Initialized Security Association Processing. >>>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >> accept, >>>> logging disabled >>>> usbus1: 480Mbps High Speed USB v2.0 >>>> ugen1.1: at usbus1 >>>> uhub0: on usbus1 >>>> ugen0.1: at usbus0 >>>> uhub1: on usbus0 >>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>> ada0: ATA-9 SATA 3.x device >>>> ada0: Serial Number S1D5NSAF687077K >>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>> ada0: Command Queueing enabled >>>> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >>>> ada0: quirks=0x1<4K> >>>> ada0: Previously was known as ad4 >>>> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >>>> ses0: SEMB S-E-S 2.00 device >>>> ses0: SEMB SES Device >>>> SMP: AP CPU #6 Launched! >>>> SMP: AP CPU #3 Launched! >>>> SMP: AP CPU #11 Launched! >>>> SMP: AP CPU #5 Launched! >>>> SMP: AP CPU #9 Launched! >>>> SMP: AP CPU #1 Launched! >>>> SMP: AP CPU #10 Launched! >>>> SMP: AP CPU #2 Launched! >>>> SMP: AP CPU #8 Launched! >>>> SMP: AP CPU #4 Launched! >>>> SMP: AP CPU #7 Launched! >>>> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >>>> Root mount waiting for: usbus1 usbus0 >>>> uhub1: 2 ports with 2 removable, self powered >>>> uhub0: 2 ports with 2 removable, self powered >>>> Root mount waiting for: usbus1 usbus0 >>>> ugen1.2: at usbus1 >>>> uhub2: >> on >>>> usbus1 >>>> ugen0.2: at usbus0 >>>> uhub3: >> on >>>> usbus0 >>>> Root mount waiting for: usbus1 usbus0 >>>> uhub3: 6 ports with 6 removable, self powered >>>> uhub2: 8 ports with 8 removable, self powered >>>> ugen1.3: at usbus1 >>>> ukbd0: on usbus1 >>>> kbd0 at ukbd0 >>>> Root mount waiting for: usbus1 >>>> ugen1.4: at usbus1 >>>> ukbd1: on usbus1 >>>> kbd2 at ukbd1 >>>> Trying to mount root from ufs:/dev/label/rootfs [rw]... >>>> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >>>> member to prevent IPv6 address scope violation. >>>> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >>>> member to prevent IPv6 address scope violation. >>>> ums0: on usbus1 >>>> ums0: 3 buttons and [Z] coordinates ID=0 >>>> uhid0: on usbus1 >>>> >>>> # uname -a >>>> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 r274375: >>>> Tue Nov 11 10:24:44 BRST 2014 >>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>> >>>> [1] https://calomel.org/freebsd_network_tuning.html >>>> [2] http://ark.intel.com/products/63157 >>>> [3] >>>> >> http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 >>>> [4] http://ark.intel.com/products/59062/ >>>> >>>> Please I need a help! and sorry my english :) >>>> From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 12:23:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82558751 for ; Mon, 1 Dec 2014 12:23:56 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6D84A7B7 for ; Mon, 1 Dec 2014 12:23:55 +0000 (UTC) Received: from eagle.yuri.org (c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id sB1CNm6H089752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2014 04:23:49 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245] claimed to be eagle.yuri.org Message-ID: <547C5DD3.90604@rawbw.com> Date: Mon, 01 Dec 2014 04:23:47 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Can multiple apps listen for TCP on the same port? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 12:23:56 -0000 I have a simple 'nc' based TCP server with shell script serving http protocol. But when I run the second instance, it never gets any connections and never fails. 'nc -l PORT' first calls listen with backlog=1 and socket option SO_REUSEADDR, and then calls accept. Once client is accepted, it closes the listening socket and only works with this connection. Why the second nc instance still never accepts any connections, once the first connection is accepted, and first listening socket is closed? When one listening socket is closed, shouldn't other listening sockets on the same port be accepting connections? It looks like the whole port is blocked without even having the listening socket on it by one alive connection (which after it was accepted doesn't have much to do with the original port). Yuri From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:14:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 025C9B34 for ; Mon, 1 Dec 2014 15:14:09 +0000 (UTC) Received: from a0i241.smtpcorp.com (a0i241.smtpcorp.com [216.22.15.73]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFC38B8D for ; Mon, 1 Dec 2014 15:14:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0_1; h=Feedback-ID:X-Smtpcorp-Track:Message-ID:Subject:To:From:Date; bh=A5a3nLMOKlF1AuXwoBSEj2ABxaJAqLjkqMDclFrx/sw=; b=JskrTzPw/8/KsyJ9RqHUw2kBDQz5k3AIhFRwSc/+adoYh6m+i+G+/+7yzAjxdZaZi3NX5exXP36LlGd+sw6tYrnIPrQyBBaC+6MDgwwq080lgulCwNa8c4uGncIieh5H1rEBGKSGduAGJ3ZdQK6/h7MwrPMQKL02FznklzpeYYc=; Date: Mon, 1 Dec 2014 07:02:25 -0800 From: Daniel Corbe To: Yuri Subject: Re: Can multiple apps listen for TCP on the same port? Message-ID: <20141201150225.GB64370@apollo.corbe.net> References: <547C5DD3.90604@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547C5DD3.90604@rawbw.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Smtpcorp-Track: 1bvSld4gfFdSL3.fmuUa5TuF Feedback-ID: 10661m:10661aegzayD:10661sTV54kKSiK:SMTPCORP Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 15:14:09 -0000 Generally the answer to your question is no. Two applications cannot occupy the same port on the same protocol at the same time. To expand on this answer and to hopefully shed some light on why the behavior you're observing with your application is absolutely correct; the calling application (in this case, nc) has to explicitly call bind(2) before it can begin accepting connections. If that port is already in use then the call to bind(2) will fail. And in your case I suspect nc is simply choosing to silently fail. -Daniel On Mon, Dec 01, 2014 at 04:23:47AM -0800, Yuri wrote: > I have a simple 'nc' based TCP server with shell script serving http > protocol. But when I run the second instance, it never gets any > connections and never fails. > > 'nc -l PORT' first calls listen with backlog=1 and socket option > SO_REUSEADDR, and then calls accept. Once client is accepted, it closes > the listening socket and only works with this connection. > > Why the second nc instance still never accepts any connections, once the > first connection is accepted, and first listening socket is closed? > > When one listening socket is closed, shouldn't other listening sockets > on the same port be accepting connections? It looks like the whole port > is blocked without even having the listening socket on it by one alive > connection (which after it was accepted doesn't have much to do with the > original port). > > Yuri > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:26:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7FD947E for ; Mon, 1 Dec 2014 15:26:42 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id C1A23CC9 for ; Mon, 1 Dec 2014 15:26:42 +0000 (UTC) Received: from eagle.yuri.org (c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id sB1FQccJ092547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Dec 2014 07:26:39 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245] claimed to be eagle.yuri.org Message-ID: <547C88AD.40407@rawbw.com> Date: Mon, 01 Dec 2014 07:26:37 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Daniel Corbe Subject: Re: Can multiple apps listen for TCP on the same port? References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> In-Reply-To: <20141201150225.GB64370@apollo.corbe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 15:26:42 -0000 On 12/01/2014 07:02, Daniel Corbe wrote: > Generally the answer to your question is no. Two applications cannot > occupy the same port on the same protocol at the same time. > > To expand on this answer and to hopefully shed some light on why the > behavior you're observing with your application is absolutely correct; > the calling application (in this case, nc) has to explicitly call bind(2) > before it can begin accepting connections. If that port is already in > use then the call to bind(2) will fail. And in your case I suspect nc > is simply choosing to silently fail. Here the question is what does it mean "occupy the port"? The first instance isn't listening any more. The listening socket was closed. Why the presence of the socket that was accepted from (now closed) listening socket in the first instance is considered "occupying it"? Actually no system call in the second instance ever fails. Yuri From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:57:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 660A29DC for ; Mon, 1 Dec 2014 15:57:29 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 01F2472 for ; Mon, 1 Dec 2014 15:57:28 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id sB1FbAHi000630 for ; Mon, 1 Dec 2014 09:37:15 -0600 (CST) (envelope-from karl@denninger.net) Received: from [127.0.0.1] (TLS/SSL) [208.54.85.211] by Spamblock-sys (LOCAL/AUTH); Mon Dec 1 09:37:15 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.1.1154) Message-ID: <20141201153712.4304976.24709.1746@denninger.net> Date: Mon, 01 Dec 2014 10:37:12 -0500 Subject: Re: Can multiple apps listen for TCP on the same port? From: Karl Denninger In-Reply-To: <547C88AD.40407@rawbw.com> References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> To: Yuri , Daniel Corbe Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 15:57:29 -0000 The second bind() call does fail but if the application ignores the return = code...=E2=80=8E. Are you sure all the associated system call return codes = are being checked? The right way to do this Imho =C2=A0is to have a parent process that calls = bind and listen, gets the notification of an incoming connection via select= () (allowing detection of exceptions as well) and then calls accept() and, = now having a connected file handle, fork()s and executes whatever is to han= dle the connection with the parent closing the handle so as to not orphan t= he handle when the child exits. =E2=80=8E --=C2=A0Karl (On=C2=A0Passport=C2=A0PDA)=E2=80=8E =C2=A0 Original Message =C2=A0 From: Yuri=E2=80=8E Sent: Monday, December 1, 2014 10:26 To: Daniel Corbe Cc: freebsd-net@freebsd.org Subject: Re: Can multiple apps listen for TCP on the same port? On 12/01/2014 07:02, Daniel Corbe wrote: > Generally the answer to your question is no. Two applications cannot > occupy the same port on the same protocol at the same time. > > To expand on this answer and to hopefully shed some light on why the > behavior you're observing with your application is absolutely correct; > the calling application (in this case, nc) has to explicitly call bind(2) > before it can begin accepting connections. If that port is already in > use then the call to bind(2) will fail. And in your case I suspect nc > is simply choosing to silently fail. Here the question is what does it mean "occupy the port"? The first=20 instance isn't listening any more. The listening socket was closed. Why=20 the presence of the socket that was accepted from (now closed) listening=20 socket in the first instance is considered "occupying it"? Actually no system call in the second instance ever fails. Yuri _______________________________________________ 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" %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 16:14:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20A4D451 for ; Mon, 1 Dec 2014 16:14:59 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94AA42BF for ; Mon, 1 Dec 2014 16:14:58 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so17915995wiv.7 for ; Mon, 01 Dec 2014 08:14:57 -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=hIv9+XpW6D9xu/V6XOT46GbZt0nSp/ykfcoM32Q7wgQ=; b=qsqQ4wHa+aS4izBGywuToNqvpLXMfSwFxPqzh/Uw2j9hCK5N0L+GttIwzM237de9GS OR7+8OpWu6x8M+bMTwVsMhjbJAY/sVzZajxkvtcgTtN/ocd79nnnOj88cJ8AqaE765u2 Y9KmynOvMtFMJuts6VBlD4IumVN9T3xKZclCeMKDHhjZQGf85CTKSbB9eKxGDUQR6mHT 9DNj2X3mpaRVO++qrqvfernWwrqne9jQq//viHwgvc+KNM3ujZJC//Eo7yMZ5hWx9O+I Eyv6BW2O3EnQ+1zoOU7xkxWfF6v5lacE+ganvjNAvIgjYbxm7a618bi/C0kW/MFIdgkR awnQ== MIME-Version: 1.0 X-Received: by 10.180.76.211 with SMTP id m19mr30041937wiw.73.1417450497008; Mon, 01 Dec 2014 08:14:57 -0800 (PST) Received: by 10.27.130.68 with HTTP; Mon, 1 Dec 2014 08:14:56 -0800 (PST) In-Reply-To: <20141201153712.4304976.24709.1746@denninger.net> References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> <20141201153712.4304976.24709.1746@denninger.net> Date: Mon, 1 Dec 2014 21:44:56 +0530 Message-ID: Subject: Re: Can multiple apps listen for TCP on the same port? From: Someone Somewhere To: Karl Denninger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Daniel Corbe , Yuri , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 16:14:59 -0000 @Yuri , are you sure that the second instance of nc does not accept any connection? I did a simple test : -> #: nc -l 12345 (shell 1) #: nc localhost 12345 (shell2) at this point netstat shows that there is no one listening on 12345. This means any process should not be able to bind over port 12345(over TCP). # nc -l 12345 (shell 3, shell 1 , 2 still active) this instance of nc starts listening which I could verify via netstat cmd. # nc localhost 12345 (shell 4) this nc instance connected to the nc started in previous step over shell 3. Test ran on Fedora 20. [will try this on freeBSD VM if you confirm that this is what you are trying] Could you verify if your second nc(server) instance is listening on the same socket number? -Kunal. On 1 December 2014 at 21:07, Karl Denninger wrote: > The second bind() call does fail but if the application ignores the retur= n > code...=E2=80=8E. Are you sure all the associated system call return code= s are > being checked? > > The right way to do this Imho is to have a parent process that calls bin= d > and listen, gets the notification of an incoming connection via select() > (allowing detection of exceptions as well) and then calls accept() and, n= ow > having a connected file handle, fork()s and executes whatever is to handl= e > the connection with the parent closing the handle so as to not orphan the > handle when the child exits. > =E2=80=8E > -- Karl > (On Passport PDA)=E2=80=8E > > > Original Message > From: Yuri=E2=80=8E > Sent: Monday, December 1, 2014 10:26 > To: Daniel Corbe > Cc: freebsd-net@freebsd.org > Subject: Re: Can multiple apps listen for TCP on the same port? > > On 12/01/2014 07:02, Daniel Corbe wrote: > > Generally the answer to your question is no. Two applications cannot > > occupy the same port on the same protocol at the same time. > > > > To expand on this answer and to hopefully shed some light on why the > > behavior you're observing with your application is absolutely correct; > > the calling application (in this case, nc) has to explicitly call bind(= 2) > > before it can begin accepting connections. If that port is already in > > use then the call to bind(2) will fail. And in your case I suspect nc > > is simply choosing to silently fail. > > Here the question is what does it mean "occupy the port"? The first > instance isn't listening any more. The listening socket was closed. Why > the presence of the socket that was accepted from (now closed) listening > socket in the first instance is considered "occupying it"? > > Actually no system call in the second instance ever fails. > > Yuri > _______________________________________________ > 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" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 16:21:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09217670 for ; Mon, 1 Dec 2014 16:21:54 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99647331 for ; Mon, 1 Dec 2014 16:21:53 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so25151962wiv.6 for ; Mon, 01 Dec 2014 08:21:52 -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:content-transfer-encoding; bh=Nw1NYEzfBAKLmJ8xkQFVw7LbBsD93j6lTQYZwJLdvek=; b=CCGAOfbMyVqpCTr87OV2b1KhDBkMCCVwDAXbpyAZsHFmDeJf5Bp4Hpq8uMAkRwPS3D vbAq5KD9VAKLxGEjmNzhWtkn1PDE+KJpEvVieyvvv83y5pujivhXm/NHNnTGAPVMzSZH n0orU7AfkFZdsJscW67ATQh9gO8NSfnFJkQ4JXmtYGORQH4Nth7HVgsdU0VnNq6ITom1 mE74LWgmcqLvUoIFfblg4+bBkKqoc/G9hChLd3wK8yMbNIZz2e+/lrR+10zimcr6RDOV caPEtyPxwFGLdGhwhq333DKXVMPW5/NK2PP0mEWQpNPqS77oNpF9+X2UYXv6QA7Y2kVI 59fw== MIME-Version: 1.0 X-Received: by 10.180.108.35 with SMTP id hh3mr84007308wib.59.1417450911818; Mon, 01 Dec 2014 08:21:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Mon, 1 Dec 2014 08:21:51 -0800 (PST) In-Reply-To: References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> <20141201153712.4304976.24709.1746@denninger.net> Date: Mon, 1 Dec 2014 08:21:51 -0800 X-Google-Sender-Auth: SpePoiGB5sSCnKs9WAO1p8n_o7U Message-ID: Subject: Re: Can multiple apps listen for TCP on the same port? From: Adrian Chadd To: Someone Somewhere Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Daniel Corbe , Yuri , Karl Denninger , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 16:21:54 -0000 Hi, I introduced a socket option in -HEAD that lets you bind multiple things to the same listen ports. They're only load balanced if you're using RSS and set up RSS socket options as well; otherwise only one gets the incoming requests. IP_BINDMULTI and IP6_BINDMULTI. -a On 1 December 2014 at 08:14, Someone Somewhere wrote: > @Yuri , are you sure that the second instance of nc does not accept any > connection? > I did a simple test : -> > #: nc -l 12345 (shell 1) > #: nc localhost 12345 (shell2) > at this point netstat shows that there is no one listening on 12345. This > means any process should not be able to bind over port 12345(over TCP). > # nc -l 12345 (shell 3, shell 1 , 2 still active) > this instance of nc starts listening which I could verify via netstat cmd= . > # nc localhost 12345 (shell 4) > this nc instance connected to the nc started in previous step over shell = 3. > > Test ran on Fedora 20. > [will try this on freeBSD VM if you confirm that this is what you are > trying] > > > Could you verify if your second nc(server) instance is listening on the > same socket number? > > > -Kunal. > > > > On 1 December 2014 at 21:07, Karl Denninger wrote: > >> The second bind() call does fail but if the application ignores the retu= rn >> code...=E2=80=8E. Are you sure all the associated system call return cod= es are >> being checked? >> >> The right way to do this Imho is to have a parent process that calls bi= nd >> and listen, gets the notification of an incoming connection via select() >> (allowing detection of exceptions as well) and then calls accept() and, = now >> having a connected file handle, fork()s and executes whatever is to hand= le >> the connection with the parent closing the handle so as to not orphan th= e >> handle when the child exits. >> =E2=80=8E >> -- Karl >> (On Passport PDA)=E2=80=8E >> >> >> Original Message >> From: Yuri=E2=80=8E >> Sent: Monday, December 1, 2014 10:26 >> To: Daniel Corbe >> Cc: freebsd-net@freebsd.org >> Subject: Re: Can multiple apps listen for TCP on the same port? >> >> On 12/01/2014 07:02, Daniel Corbe wrote: >> > Generally the answer to your question is no. Two applications cannot >> > occupy the same port on the same protocol at the same time. >> > >> > To expand on this answer and to hopefully shed some light on why the >> > behavior you're observing with your application is absolutely correct; >> > the calling application (in this case, nc) has to explicitly call bind= (2) >> > before it can begin accepting connections. If that port is already in >> > use then the call to bind(2) will fail. And in your case I suspect nc >> > is simply choosing to silently fail. >> >> Here the question is what does it mean "occupy the port"? The first >> instance isn't listening any more. The listening socket was closed. Why >> the presence of the socket that was accepted from (now closed) listening >> socket in the first instance is considered "occupying it"? >> >> Actually no system call in the second instance ever fails. >> >> Yuri >> _______________________________________________ >> 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" >> >> >> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok >> >> >> _______________________________________________ >> 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 Mon Dec 1 17:12:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C108F854 for ; Mon, 1 Dec 2014 17:12:36 +0000 (UTC) Received: from mail.as41113.net (mail.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 83067B50 for ; Mon, 1 Dec 2014 17:12:36 +0000 (UTC) Received: from [172.21.87.41] (193.98.9.212.in-addr.arpa [212.9.98.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.as41113.net (Postfix) with ESMTPSA id 3jrt7w3wYLz1N2P7 for ; Mon, 1 Dec 2014 17:03:56 +0000 (GMT) Message-ID: <547C9F7A.5000803@rewt.org.uk> Date: Mon, 01 Dec 2014 17:03:54 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Can multiple apps listen for TCP on the same port? References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> <20141201153712.4304976.24709.1746@denninger.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 17:12:36 -0000 Was there a specific reason why we couldn't just extend REUSEADDR/PORT to do this a la Linux? Just a simple round robin would make those useful perhaps On 01/12/2014 16:21, Adrian Chadd wrote: > Hi, > > I introduced a socket option in -HEAD that lets you bind multiple > things to the same listen ports. > > They're only load balanced if you're using RSS and set up RSS socket > options as well; otherwise only one gets the incoming requests. > > IP_BINDMULTI and IP6_BINDMULTI. > > > -a > > > On 1 December 2014 at 08:14, Someone Somewhere > wrote: >> @Yuri , are you sure that the second instance of nc does not accept any >> connection? >> I did a simple test : -> >> #: nc -l 12345 (shell 1) >> #: nc localhost 12345 (shell2) >> at this point netstat shows that there is no one listening on 12345. This >> means any process should not be able to bind over port 12345(over TCP). >> # nc -l 12345 (shell 3, shell 1 , 2 still active) >> this instance of nc starts listening which I could verify via netstat cmd. >> # nc localhost 12345 (shell 4) >> this nc instance connected to the nc started in previous step over shell 3. >> >> Test ran on Fedora 20. >> [will try this on freeBSD VM if you confirm that this is what you are >> trying] >> >> >> Could you verify if your second nc(server) instance is listening on the >> same socket number? >> >> >> -Kunal. >> >> >> >> On 1 December 2014 at 21:07, Karl Denninger wrote: >> >>> The second bind() call does fail but if the application ignores the return >>> code...‎. Are you sure all the associated system call return codes are >>> being checked? >>> >>> The right way to do this Imho is to have a parent process that calls bind >>> and listen, gets the notification of an incoming connection via select() >>> (allowing detection of exceptions as well) and then calls accept() and, now >>> having a connected file handle, fork()s and executes whatever is to handle >>> the connection with the parent closing the handle so as to not orphan the >>> handle when the child exits. >>> ‎ >>> -- Karl >>> (On Passport PDA)‎ >>> >>> >>> Original Message >>> From: Yuri‎ >>> Sent: Monday, December 1, 2014 10:26 >>> To: Daniel Corbe >>> Cc: freebsd-net@freebsd.org >>> Subject: Re: Can multiple apps listen for TCP on the same port? >>> >>> On 12/01/2014 07:02, Daniel Corbe wrote: >>>> Generally the answer to your question is no. Two applications cannot >>>> occupy the same port on the same protocol at the same time. >>>> >>>> To expand on this answer and to hopefully shed some light on why the >>>> behavior you're observing with your application is absolutely correct; >>>> the calling application (in this case, nc) has to explicitly call bind(2) >>>> before it can begin accepting connections. If that port is already in >>>> use then the call to bind(2) will fail. And in your case I suspect nc >>>> is simply choosing to silently fail. >>> >>> Here the question is what does it mean "occupy the port"? The first >>> instance isn't listening any more. The listening socket was closed. Why >>> the presence of the socket that was accepted from (now closed) listening >>> socket in the first instance is considered "occupying it"? >>> >>> Actually no system call in the second instance ever fails. >>> >>> Yuri >>> _______________________________________________ >>> 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" >>> >>> >>> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok >>> >>> >>> _______________________________________________ >>> 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" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 19:37:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7C384A3 for ; Mon, 1 Dec 2014 19:37:25 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7BF7ACA4 for ; Mon, 1 Dec 2014 19:37:25 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 186AA139CB for ; Mon, 1 Dec 2014 17:37:32 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1417462645; x=1418326646; bh=kk3HmZdQIwDSXHptG588LcxfxhpR5DNyxB7 mxhT0sVs=; b=fqVw4avu8JmiHyFDuGsRJYuhAkDG4Da9yds+LVYuz2Yxs+qFWBM ihdJI7r14OONKNhIEYDh4NLwmPF9y/sI+IsZ9RNQaszAFIZOvmb4sjdC6NzwrFkL 4UDvR82T2YkhUWYd+4Lbr1TiRiwvUYStuV2c73WXt3+vyGeealQPBKBw= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGnFx4gKTjtj for ; Mon, 1 Dec 2014 17:37:25 -0200 (BRST) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 52C4D139CA for ; Mon, 1 Dec 2014 17:37:21 -0200 (BRST) Message-ID: <547CC35A.1080108@bsdinfo.com.br> Date: Mon, 01 Dec 2014 17:36:58 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> <547BB862.6080801@bsdinfo.com.br> In-Reply-To: <547BB862.6080801@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 19:37:25 -0000 On 30/11/2014 22:37, Marcelo Gondim wrote: > Hi Jack, > > On 30/11/2014 16:20, Jack Vogel wrote: >> Good suggestions, do you ever see any 'interrupt throttled' messages? >> You >> might >> want to change the storm threshold to 0 and disable it. > I can try this: > > sysctl hw.intr_storm_threshold=0 Hi Jack, Same problem with hw.intr_storm_threshold=0 I still think it might be something in my traffic that the driver is not dealing properly. # netstat -idn . . . ix0 1500 00:1b:21:89:25:32 18446739080975184057 268 5876340155018 18446742570019979938 0 0 0 ix0 - fe80::21b:21f fe80::21b:21ff:fe 0 - - 1 - - - ix1 1500 00:1b:21:89:25:33 18446730999135967066 0 13653533351669 18446742457148273271 0 0 0 ix1 - fe80::21b:21f fe80::21b:21ff:fe 0 - - 0 - - - . . . Are 5876340155018 dropped packets in ix0 and 13653533351669 dropped packets in ix1 # w -n 5:35PM up 15 days, 20:29, 2 users, load averages: 8.96, 9.03, 8.84 USER TTY FROM LOGIN@ IDLE WHAT gondim pts/1 186.xxx.48.8 5:22PM - w -n > >> >> I too would like to know if there are any messages when the 'hang' >> happens. > Nope. No message. :( > >> >> I don't know much about lagg, is it responsible for link events?? Its >> not a >> normal >> situation to be having so many :( >> >> Jack >> >> >> On Sun, Nov 30, 2014 at 10:01 AM, Adrian Chadd >> wrote: >> >>> Your link_irq value is way too high. I think you're exposing some >>> unhandled corner case in the driver (as I had this issue when I had >>> some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe >>> driver isn't getting link events. >>> >>> My test setup at home has link_irq=1 on both sides, and it runs >>> full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for >>> RSS testing for weeks at a time. I have no issues and no hiccups. >>> So, I think there's two problems: >>> >>> * you're still seeing way too many link_irq events; and >>> * i think there's some bad handling when it comes to link_irq events. >>> >>> I wonder if we're still clearing some of the interrupt register bits >>> incorrectly in ixgbe_msix_link(). >>> >>> >>> -adrian >>> >>> >>> >>> >>> -adrian >>> >>> >>> On 30 November 2014 at 08:05, Alexander V. Chernikov >>> wrote: >>>> On 30.11.2014 18:47, Marcelo Gondim wrote: >>>>> Dear, >>>>> >>>>> Unfortunately I have more options to resolve this problem I'm having >>> with >>>>> Intel X520-SR2. Have we changed the X520, we exchange the optical >>>>> cords, >>>>> exchanged optical modules, we changed the entire server, we reduce >>>>> the >>>>> temperature inside the equipment, made some attempts to tunning >>>>> the site >>>>> calomel[1]. We spend a lot of money and do not solve the problem. >>>>> >>>>> What happens is that when there is a traffic above 1.2Gbps with PPS >>> above >>>>> 700kpps in sometimes almost daily there is a lock in two 10GbE >>>>> ports the >>>>> X520-SR interface. Where I am obliged to leave a script running in >>>>> the >>>>> background doing just that: >>>> What does this "lock" looks like? >>>> Do you using jumbo frames? >>>> Is this IPv4 or IPv4+IPv6 ? >>>> Can you share "netstat -m" output? >>>> Do you use ipfw dynamic states? >>>> Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? >>>> >>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>> >>>> Looks suspicious. Either you're running out of mbufs due to total mbuf >>>> number is small, or system is very busy sometimes. >>>> What does you "top -HPSzs1" output look like? >>>> >>>> >>>>> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig >>>>> ix1 up >>>>> >>>>> Made it back to the interface function normally. It's already so for >>>>> months and have not tried the latest driver from Intel because I >>>>> do not >>> see >>>>> anything related to this issue. >>>>> >>>>> These 2-port 10GbE are my backbone linking the four cities that >>>>> attend >>> to >>>>> our main router. One is backup to other but when the problem occurs, >>> the two >>>>> ports stop working and at the moment I have a break in my Internet >>>>> >>>>> I can only conclude that the problem is one of the things below: >>>>> >>>>> 1 - Intel Interface X520-SR2 has a problem with certain types of >>>>> traffic >>>>> and then hangs. >>>>> 2 - The ixgbe driver has a bug that is causing it. >>>>> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >>>>> would be a regression and the equipment is very far away from me if I >>> need >>>>> to move me. >>>>> >>>>> Honestly I'm almost going on a Juniper closed solution. I would >>>>> not want >>>>> to do this because I love FreeBSD and I can not believe that he >>>>> does not >>>>> support a 2.7Gbps traffic, which is my peak traffic without getting >>> having >>>>> these falls. My hardware today is this: >>>>> >>>>> hw.machine: amd64 >>>>> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>>>> hw.ncpu: 12 >>>>> hw.byteorder: 1234 >>>>> hw.physmem: 17083641856 >>>>> hw.usermem: 15741001728 >>>>> >>>>> Hardware all Intel with motherboard S2600COE [2] and with network >>>>> interfaces offboard: >>>>> >>>>> 1x - X520-SR2 [3] >>>>> 2x - I350-T2 [4] >>>>> >>>>> My loader.conf: >>>>> >>>>> loader_logo="beastie" >>>>> if_lagg_load="YES" >>>>> speaker_load="YES" >>>>> aio_load="YES" >>>>> autoboot_delay="5" >>>>> net.fibs=1 >>>>> >>>>> My sysctl.conf: >>>>> >>>>> net.inet.ip.forwarding=1 >>>>> net.inet.ip.fastforwarding=1 >>>>> net.inet6.ip6.forwarding=1 >>>>> kern.ipc.somaxconn=4096 >>>>> net.inet.tcp.syncookies=1 >>>>> net.inet.ip.redirect=1 >>>>> net.inet.ip.accept_sourceroute=0 >>>>> net.inet.ip.sourceroute=0 >>>>> net.inet.tcp.drop_synfin=1 >>>>> net.inet.udp.blackhole=1 >>>>> net.inet.tcp.blackhole=2 >>>>> security.bsd.see_other_uids=0 >>>>> net.inet.ip.fw.dyn_buckets=65536 >>>>> net.inet.ip.fw.dyn_max=65536 >>>>> hw.intr_storm_threshold=9000 >>>>> net.inet.ip.dummynet.pipe_slot_limit=800 >>>>> net.inet.icmp.icmplim=2000 >>>>> >>>>> # sysctl dev.ix. >>>>> dev.ix.%parent: >>>>> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >>>>> Version - >>>>> 2.5.15 >>>>> dev.ix.0.%driver: ix >>>>> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >>>>> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>>> subdevice=0x7a11 class=0x020000 >>>>> dev.ix.0.%parent: pci129 >>>>> dev.ix.0.fc: 3 >>>>> dev.ix.0.enable_aim: 1 >>>>> dev.ix.0.advertise_speed: 0 >>>>> dev.ix.0.dropped: 0 >>>>> dev.ix.0.mbuf_defrag_failed: 0 >>>>> dev.ix.0.watchdog_events: 0 >>>>> dev.ix.0.link_irq: 193783 >>>>> dev.ix.0.queue0.interrupt_rate: 50000 >>>>> dev.ix.0.queue0.irqs: 12029604413 >>>>> dev.ix.0.queue0.txd_head: 1517 >>>>> dev.ix.0.queue0.txd_tail: 1517 >>>>> dev.ix.0.queue0.tso_tx: 85 >>>>> dev.ix.0.queue0.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>>> dev.ix.0.queue0.tx_packets: 15392658033 >>>>> dev.ix.0.queue0.rxd_head: 709 >>>>> dev.ix.0.queue0.rxd_tail: 707 >>>>> dev.ix.0.queue0.rx_packets: 21762427837 >>>>> dev.ix.0.queue0.rx_bytes: 56918345381 >>>>> dev.ix.0.queue0.rx_copies: 124289013 >>>>> dev.ix.0.queue0.lro_queued: 0 >>>>> dev.ix.0.queue0.lro_flushed: 0 >>>>> dev.ix.0.queue1.interrupt_rate: 500000 >>>>> dev.ix.0.queue1.irqs: 11482146431 >>>>> dev.ix.0.queue1.txd_head: 731 >>>>> dev.ix.0.queue1.txd_tail: 731 >>>>> dev.ix.0.queue1.tso_tx: 1442 >>>>> dev.ix.0.queue1.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>>> dev.ix.0.queue1.tx_packets: 15835062632 >>>>> dev.ix.0.queue1.rxd_head: 685 >>>>> dev.ix.0.queue1.rxd_tail: 681 >>>>> dev.ix.0.queue1.rx_packets: 21220715209 >>>>> dev.ix.0.queue1.rx_bytes: 54351679461 >>>>> dev.ix.0.queue1.rx_copies: 120833356 >>>>> dev.ix.0.queue1.lro_queued: 0 >>>>> dev.ix.0.queue1.lro_flushed: 0 >>>>> dev.ix.0.queue2.interrupt_rate: 5319 >>>>> dev.ix.0.queue2.irqs: 11532560324 >>>>> dev.ix.0.queue2.txd_head: 501 >>>>> dev.ix.0.queue2.txd_tail: 501 >>>>> dev.ix.0.queue2.tso_tx: 2474 >>>>> dev.ix.0.queue2.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue2.no_desc_avail: 429244 >>>>> dev.ix.0.queue2.tx_packets: 15772209238 >>>>> dev.ix.0.queue2.rxd_head: 246 >>>>> dev.ix.0.queue2.rxd_tail: 244 >>>>> dev.ix.0.queue2.rx_packets: 21408648299 >>>>> dev.ix.0.queue2.rx_bytes: 56862350194 >>>>> dev.ix.0.queue2.rx_copies: 124973551 >>>>> dev.ix.0.queue2.lro_queued: 0 >>>>> dev.ix.0.queue2.lro_flushed: 0 >>>>> dev.ix.0.queue3.interrupt_rate: 20833 >>>>> dev.ix.0.queue3.irqs: 11557466322 >>>>> dev.ix.0.queue3.txd_head: 773 >>>>> dev.ix.0.queue3.txd_tail: 773 >>>>> dev.ix.0.queue3.tso_tx: 40 >>>>> dev.ix.0.queue3.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue3.no_desc_avail: 665620 >>>>> dev.ix.0.queue3.tx_packets: 16479111658 >>>>> dev.ix.0.queue3.rxd_head: 1858 >>>>> dev.ix.0.queue3.rxd_tail: 1854 >>>>> dev.ix.0.queue3.rx_packets: 21412821769 >>>>> dev.ix.0.queue3.rx_bytes: 52796089467 >>>>> dev.ix.0.queue3.rx_copies: 127385950 >>>>> dev.ix.0.queue3.lro_queued: 0 >>>>> dev.ix.0.queue3.lro_flushed: 0 >>>>> dev.ix.0.queue4.interrupt_rate: 11363 >>>>> dev.ix.0.queue4.irqs: 10824852635 >>>>> dev.ix.0.queue4.txd_head: 1711 >>>>> dev.ix.0.queue4.txd_tail: 1713 >>>>> dev.ix.0.queue4.tso_tx: 581 >>>>> dev.ix.0.queue4.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue4.no_desc_avail: 115346803 >>>>> dev.ix.0.queue4.tx_packets: 16100396810 >>>>> dev.ix.0.queue4.rxd_head: 244 >>>>> dev.ix.0.queue4.rxd_tail: 243 >>>>> dev.ix.0.queue4.rx_packets: 21240995210 >>>>> dev.ix.0.queue4.rx_bytes: 58726730771 >>>>> dev.ix.0.queue4.rx_copies: 124872141 >>>>> dev.ix.0.queue4.lro_queued: 0 >>>>> dev.ix.0.queue4.lro_flushed: 0 >>>>> dev.ix.0.queue5.interrupt_rate: 500000 >>>>> dev.ix.0.queue5.irqs: 10955464761 >>>>> dev.ix.0.queue5.txd_head: 75 >>>>> dev.ix.0.queue5.txd_tail: 77 >>>>> dev.ix.0.queue5.tso_tx: 1758 >>>>> dev.ix.0.queue5.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue5.no_desc_avail: 4759 >>>>> dev.ix.0.queue5.tx_packets: 16267888038 >>>>> dev.ix.0.queue5.rxd_head: 905 >>>>> dev.ix.0.queue5.rxd_tail: 904 >>>>> dev.ix.0.queue5.rx_packets: 21381144028 >>>>> dev.ix.0.queue5.rx_bytes: 61800291690 >>>>> dev.ix.0.queue5.rx_copies: 129684798 >>>>> dev.ix.0.queue5.lro_queued: 0 >>>>> dev.ix.0.queue5.lro_flushed: 0 >>>>> dev.ix.0.queue6.interrupt_rate: 33333 >>>>> dev.ix.0.queue6.irqs: 11081350674 >>>>> dev.ix.0.queue6.txd_head: 1744 >>>>> dev.ix.0.queue6.txd_tail: 1746 >>>>> dev.ix.0.queue6.tso_tx: 38 >>>>> dev.ix.0.queue6.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue6.no_desc_avail: 18381 >>>>> dev.ix.0.queue6.tx_packets: 15376961749 >>>>> dev.ix.0.queue6.rxd_head: 1783 >>>>> dev.ix.0.queue6.rxd_tail: 1782 >>>>> dev.ix.0.queue6.rx_packets: 21381814216 >>>>> dev.ix.0.queue6.rx_bytes: 56828960117 >>>>> dev.ix.0.queue6.rx_copies: 130194429 >>>>> dev.ix.0.queue6.lro_queued: 0 >>>>> dev.ix.0.queue6.lro_flushed: 0 >>>>> dev.ix.0.queue7.interrupt_rate: 5319 >>>>> dev.ix.0.queue7.irqs: 11014043865 >>>>> dev.ix.0.queue7.txd_head: 1545 >>>>> dev.ix.0.queue7.txd_tail: 1545 >>>>> dev.ix.0.queue7.tso_tx: 59 >>>>> dev.ix.0.queue7.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue7.no_desc_avail: 5497 >>>>> dev.ix.0.queue7.tx_packets: 15283534142 >>>>> dev.ix.0.queue7.rxd_head: 184 >>>>> dev.ix.0.queue7.rxd_tail: 182 >>>>> dev.ix.0.queue7.rx_packets: 21431994087 >>>>> dev.ix.0.queue7.rx_bytes: 57942270182 >>>>> dev.ix.0.queue7.rx_copies: 128363306 >>>>> dev.ix.0.queue7.lro_queued: 0 >>>>> dev.ix.0.queue7.lro_flushed: 0 >>>>> dev.ix.0.mac_stats.crc_errs: 268 >>>>> dev.ix.0.mac_stats.ill_errs: 33 >>>>> dev.ix.0.mac_stats.byte_errs: 55 >>>>> dev.ix.0.mac_stats.short_discards: 0 >>>>> dev.ix.0.mac_stats.local_faults: 3484 >>>>> dev.ix.0.mac_stats.remote_faults: 121 >>>>> dev.ix.0.mac_stats.rec_len_errs: 0 >>>>> dev.ix.0.mac_stats.xon_txd: 1602713563748 >>>>> dev.ix.0.mac_stats.xon_recvd: 0 >>>>> dev.ix.0.mac_stats.xoff_txd: 108342810167 >>>>> dev.ix.0.mac_stats.xoff_recvd: 0 >>>>> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >>>>> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >>>>> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >>>>> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >>>>> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >>>>> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >>>>> dev.ix.0.mac_stats.rx_frames_64: 5356098 >>>>> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >>>>> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >>>>> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >>>>> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >>>>> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >>>>> dev.ix.0.mac_stats.recv_undersized: 0 >>>>> dev.ix.0.mac_stats.recv_fragmented: 0 >>>>> dev.ix.0.mac_stats.recv_oversized: 244078 >>>>> dev.ix.0.mac_stats.recv_jabberd: 4 >>>>> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >>>>> dev.ix.0.mac_stats.management_pkts_drpd: 0 >>>>> dev.ix.0.mac_stats.checksum_errs: 897344641 >>>>> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >>>>> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >>>>> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >>>>> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >>>>> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >>>>> dev.ix.0.mac_stats.management_pkts_txd: 0 >>>>> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >>>>> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >>>>> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >>>>> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >>>>> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >>>>> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >>>>> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >>>>> Version - >>>>> 2.5.15 >>>>> dev.ix.1.%driver: ix >>>>> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >>>>> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>>> subdevice=0x7a11 class=0x020000 >>>>> dev.ix.1.%parent: pci129 >>>>> dev.ix.1.fc: 3 >>>>> dev.ix.1.enable_aim: 1 >>>>> dev.ix.1.advertise_speed: 0 >>>>> dev.ix.1.dropped: 0 >>>>> dev.ix.1.mbuf_defrag_failed: 0 >>>>> dev.ix.1.watchdog_events: 0 >>>>> dev.ix.1.link_irq: 127925 >>>>> dev.ix.1.queue0.interrupt_rate: 11627 >>>>> dev.ix.1.queue0.irqs: 6686088831 >>>>> dev.ix.1.queue0.txd_head: 1618 >>>>> dev.ix.1.queue0.txd_tail: 1620 >>>>> dev.ix.1.queue0.tso_tx: 28 >>>>> dev.ix.1.queue0.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue0.no_desc_avail: 0 >>>>> dev.ix.1.queue0.tx_packets: 13527334563 >>>>> dev.ix.1.queue0.rxd_head: 1715 >>>>> dev.ix.1.queue0.rxd_tail: 1714 >>>>> dev.ix.1.queue0.rx_packets: 1503775702 >>>>> dev.ix.1.queue0.rx_bytes: 1069295301 >>>>> dev.ix.1.queue0.rx_copies: 2983480 >>>>> dev.ix.1.queue0.lro_queued: 0 >>>>> dev.ix.1.queue0.lro_flushed: 0 >>>>> dev.ix.1.queue1.interrupt_rate: 5319 >>>>> dev.ix.1.queue1.irqs: 6546967336 >>>>> dev.ix.1.queue1.txd_head: 1812 >>>>> dev.ix.1.queue1.txd_tail: 1812 >>>>> dev.ix.1.queue1.tso_tx: 6 >>>>> dev.ix.1.queue1.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue1.no_desc_avail: 0 >>>>> dev.ix.1.queue1.tx_packets: 13475453794 >>>>> dev.ix.1.queue1.rxd_head: 1246 >>>>> dev.ix.1.queue1.rxd_tail: 1245 >>>>> dev.ix.1.queue1.rx_packets: 1506444917 >>>>> dev.ix.1.queue1.rx_bytes: 783064190 >>>>> dev.ix.1.queue1.rx_copies: 2881513 >>>>> dev.ix.1.queue1.lro_queued: 0 >>>>> dev.ix.1.queue1.lro_flushed: 0 >>>>> dev.ix.1.queue2.interrupt_rate: 5319 >>>>> dev.ix.1.queue2.irqs: 6574615190 >>>>> dev.ix.1.queue2.txd_head: 1494 >>>>> dev.ix.1.queue2.txd_tail: 1494 >>>>> dev.ix.1.queue2.tso_tx: 33 >>>>> dev.ix.1.queue2.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue2.no_desc_avail: 0 >>>>> dev.ix.1.queue2.tx_packets: 13555495169 >>>>> dev.ix.1.queue2.rxd_head: 438 >>>>> dev.ix.1.queue2.rxd_tail: 437 >>>>> dev.ix.1.queue2.rx_packets: 1501380848 >>>>> dev.ix.1.queue2.rx_bytes: 1008544082 >>>>> dev.ix.1.queue2.rx_copies: 2660960 >>>>> dev.ix.1.queue2.lro_queued: 0 >>>>> dev.ix.1.queue2.lro_flushed: 0 >>>>> dev.ix.1.queue3.interrupt_rate: 5319 >>>>> dev.ix.1.queue3.irqs: 6617964401 >>>>> dev.ix.1.queue3.txd_head: 1853 >>>>> dev.ix.1.queue3.txd_tail: 1855 >>>>> dev.ix.1.queue3.tso_tx: 10 >>>>> dev.ix.1.queue3.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue3.no_desc_avail: 0 >>>>> dev.ix.1.queue3.tx_packets: 13561212942 >>>>> dev.ix.1.queue3.rxd_head: 429 >>>>> dev.ix.1.queue3.rxd_tail: 428 >>>>> dev.ix.1.queue3.rx_packets: 1498117903 >>>>> dev.ix.1.queue3.rx_bytes: 784881986 >>>>> dev.ix.1.queue3.rx_copies: 2695475 >>>>> dev.ix.1.queue3.lro_queued: 0 >>>>> dev.ix.1.queue3.lro_flushed: 0 >>>>> dev.ix.1.queue4.interrupt_rate: 5319 >>>>> dev.ix.1.queue4.irqs: 6575752163 >>>>> dev.ix.1.queue4.txd_head: 902 >>>>> dev.ix.1.queue4.txd_tail: 902 >>>>> dev.ix.1.queue4.tso_tx: 5 >>>>> dev.ix.1.queue4.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue4.no_desc_avail: 0 >>>>> dev.ix.1.queue4.tx_packets: 13478514009 >>>>> dev.ix.1.queue4.rxd_head: 536 >>>>> dev.ix.1.queue4.rxd_tail: 535 >>>>> dev.ix.1.queue4.rx_packets: 1476720084 >>>>> dev.ix.1.queue4.rx_bytes: 944967171 >>>>> dev.ix.1.queue4.rx_copies: 2650672 >>>>> dev.ix.1.queue4.lro_queued: 0 >>>>> dev.ix.1.queue4.lro_flushed: 0 >>>>> dev.ix.1.queue5.interrupt_rate: 10416 >>>>> dev.ix.1.queue5.irqs: 6578099670 >>>>> dev.ix.1.queue5.txd_head: 1996 >>>>> dev.ix.1.queue5.txd_tail: 1996 >>>>> dev.ix.1.queue5.tso_tx: 663 >>>>> dev.ix.1.queue5.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue5.no_desc_avail: 0 >>>>> dev.ix.1.queue5.tx_packets: 13516483196 >>>>> dev.ix.1.queue5.rxd_head: 1296 >>>>> dev.ix.1.queue5.rxd_tail: 1295 >>>>> dev.ix.1.queue5.rx_packets: 1496584151 >>>>> dev.ix.1.queue5.rx_bytes: 810434347 >>>>> dev.ix.1.queue5.rx_copies: 2899315 >>>>> dev.ix.1.queue5.lro_queued: 0 >>>>> dev.ix.1.queue5.lro_flushed: 0 >>>>> dev.ix.1.queue6.interrupt_rate: 5319 >>>>> dev.ix.1.queue6.irqs: 6624395782 >>>>> dev.ix.1.queue6.txd_head: 1058 >>>>> dev.ix.1.queue6.txd_tail: 1058 >>>>> dev.ix.1.queue6.tso_tx: 20 >>>>> dev.ix.1.queue6.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue6.no_desc_avail: 0 >>>>> dev.ix.1.queue6.tx_packets: 13491315217 >>>>> dev.ix.1.queue6.rxd_head: 1550 >>>>> dev.ix.1.queue6.rxd_tail: 1549 >>>>> dev.ix.1.queue6.rx_packets: 1510907490 >>>>> dev.ix.1.queue6.rx_bytes: 719914325 >>>>> dev.ix.1.queue6.rx_copies: 2712955 >>>>> dev.ix.1.queue6.lro_queued: 0 >>>>> dev.ix.1.queue6.lro_flushed: 0 >>>>> dev.ix.1.queue7.interrupt_rate: 29411 >>>>> dev.ix.1.queue7.irqs: 6573304834 >>>>> dev.ix.1.queue7.txd_head: 784 >>>>> dev.ix.1.queue7.txd_tail: 786 >>>>> dev.ix.1.queue7.tso_tx: 2 >>>>> dev.ix.1.queue7.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue7.no_desc_avail: 0 >>>>> dev.ix.1.queue7.tx_packets: 13587681458 >>>>> dev.ix.1.queue7.rxd_head: 1489 >>>>> dev.ix.1.queue7.rxd_tail: 1488 >>>>> dev.ix.1.queue7.rx_packets: 1504712031 >>>>> dev.ix.1.queue7.rx_bytes: 1216803328 >>>>> dev.ix.1.queue7.rx_copies: 2976103 >>>>> dev.ix.1.queue7.lro_queued: 0 >>>>> dev.ix.1.queue7.lro_flushed: 0 >>>>> dev.ix.1.mac_stats.crc_errs: 0 >>>>> dev.ix.1.mac_stats.ill_errs: 0 >>>>> dev.ix.1.mac_stats.byte_errs: 0 >>>>> dev.ix.1.mac_stats.short_discards: 0 >>>>> dev.ix.1.mac_stats.local_faults: 0 >>>>> dev.ix.1.mac_stats.remote_faults: 12 >>>>> dev.ix.1.mac_stats.rec_len_errs: 0 >>>>> dev.ix.1.mac_stats.xon_txd: 1714791401322 >>>>> dev.ix.1.mac_stats.xon_recvd: 0 >>>>> dev.ix.1.mac_stats.xoff_txd: 41095995010 >>>>> dev.ix.1.mac_stats.xoff_recvd: 0 >>>>> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >>>>> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >>>>> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >>>>> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >>>>> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >>>>> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >>>>> dev.ix.1.mac_stats.rx_frames_64: 73447 >>>>> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >>>>> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >>>>> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >>>>> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >>>>> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >>>>> dev.ix.1.mac_stats.recv_undersized: 0 >>>>> dev.ix.1.mac_stats.recv_fragmented: 0 >>>>> dev.ix.1.mac_stats.recv_oversized: 0 >>>>> dev.ix.1.mac_stats.recv_jabberd: 0 >>>>> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >>>>> dev.ix.1.mac_stats.management_pkts_drpd: 0 >>>>> dev.ix.1.mac_stats.checksum_errs: 85432477 >>>>> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >>>>> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >>>>> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >>>>> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >>>>> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >>>>> dev.ix.1.mac_stats.management_pkts_txd: 0 >>>>> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >>>>> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >>>>> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >>>>> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >>>>> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >>>>> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >>>>> >>>>> # cat /var/run/dmesg.boot >>>>> >>>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, >>>>> 1993, 1994 >>>>> The Regents of the University of California. All rights >>> reserved. >>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >>>>> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >>>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) >>>>> 20140512 >>>>> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class >>> CPU) >>>>> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >>>>> Stepping = 4 >>>>> >>>>> >>> Features=0xbfebfbff >>> >>>>> >>> Features2=0x7fbee3ff >>> >>>>> AMD Features=0x2c100800 >>>>> AMD Features2=0x1 >>>>> Structured Extended Features=0x281 >>>>> VT-x: (disabled in BIOS) >>>>> PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >>>>> TSC: P-state invariant, performance statistics >>>>> real memory = 17179869184 (16384 MB) >>>>> avail memory = 16515358720 (15750 MB) >>>>> Event timer "LAPIC" quality 600 >>>>> ACPI APIC Table: >>>>> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >>>>> FreeBSD/SMP: 2 package(s) x 6 core(s) >>>>> cpu0 (BSP): APIC ID: 0 >>>>> cpu1 (AP): APIC ID: 2 >>>>> cpu2 (AP): APIC ID: 4 >>>>> cpu3 (AP): APIC ID: 6 >>>>> cpu4 (AP): APIC ID: 8 >>>>> cpu5 (AP): APIC ID: 10 >>>>> cpu6 (AP): APIC ID: 32 >>>>> cpu7 (AP): APIC ID: 34 >>>>> cpu8 (AP): APIC ID: 36 >>>>> cpu9 (AP): APIC ID: 38 >>>>> cpu10 (AP): APIC ID: 40 >>>>> cpu11 (AP): APIC ID: 42 >>>>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: >>>>> 32, >>>>> using default 16 (20130823/tbfadt-682) >>>>> ioapic0 irqs 0-23 on motherboard >>>>> ioapic1 irqs 24-47 on motherboard >>>>> ioapic2 irqs 48-71 on motherboard >>>>> kbd1 at kbdmux0 >>>>> random: initialized >>>>> cryptosoft0: on motherboard >>>>> acpi0: on motherboard >>>>> acpi0: Power Button (fixed) >>>>> acpi0: reservation of 0, 9d000 (3) failed >>>>> cpu0: on acpi0 >>>>> cpu1: on acpi0 >>>>> cpu2: on acpi0 >>>>> cpu3: on acpi0 >>>>> cpu4: on acpi0 >>>>> cpu5: on acpi0 >>>>> cpu6: on acpi0 >>>>> cpu7: on acpi0 >>>>> cpu8: on acpi0 >>>>> cpu9: on acpi0 >>>>> cpu10: on acpi0 >>>>> cpu11: on acpi0 >>>>> hpet0: iomem 0xfed00000-0xfed003ff on >>>>> acpi0 >>>>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>>>> Event timer "HPET" frequency 14318180 Hz quality 350 >>>>> Event timer "HPET1" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET2" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET3" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET4" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET5" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET6" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET7" frequency 14318180 Hz quality 340 >>>>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>>>> atrtc0: Warning: Couldn't map I/O. >>>>> Event timer "RTC" frequency 32768 Hz quality 0 >>>>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>> Event timer "i8254" frequency 1193182 Hz quality 100 >>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>> pci0: on pcib0 >>>>> pcib1: irq 47 at device 1.0 on pci0 >>>>> pci1: on pcib1 >>>>> pcib2: irq 47 at device 1.1 on pci0 >>>>> pci2: on pcib2 >>>>> igb0: port >>>>> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq >>>>> 27 at >>>>> device 0.0 on pci2 >>>>> igb0: Using MSIX interrupts with 9 vectors >>>>> igb0: Ethernet address: 00:1e:67:9a:d5:88 >>>>> 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 >>>>> igb0: Bound queue 4 to cpu 4 >>>>> igb0: Bound queue 5 to cpu 5 >>>>> igb0: Bound queue 6 to cpu 6 >>>>> igb0: Bound queue 7 to cpu 7 >>>>> igb1: port >>>>> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq >>>>> 30 at >>>>> device 0.1 on pci2 >>>>> igb1: Using MSIX interrupts with 9 vectors >>>>> igb1: Ethernet address: 00:1e:67:9a:d5:89 >>>>> igb1: Bound queue 0 to cpu 8 >>>>> igb1: Bound queue 1 to cpu 9 >>>>> igb1: Bound queue 2 to cpu 10 >>>>> igb1: Bound queue 3 to cpu 11 >>>>> igb1: Bound queue 4 to cpu 0 >>>>> igb1: Bound queue 5 to cpu 1 >>>>> igb1: Bound queue 6 to cpu 2 >>>>> igb1: Bound queue 7 to cpu 3 >>>>> igb2: port >>>>> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq >>>>> 28 at >>>>> device 0.2 on pci2 >>>>> igb2: Using MSIX interrupts with 9 vectors >>>>> igb2: Ethernet address: 00:1e:67:9a:d5:8a >>>>> igb2: Bound queue 0 to cpu 4 >>>>> igb2: Bound queue 1 to cpu 5 >>>>> igb2: Bound queue 2 to cpu 6 >>>>> igb2: Bound queue 3 to cpu 7 >>>>> igb2: Bound queue 4 to cpu 8 >>>>> igb2: Bound queue 5 to cpu 9 >>>>> igb2: Bound queue 6 to cpu 10 >>>>> igb2: Bound queue 7 to cpu 11 >>>>> igb3: port >>>>> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq >>>>> 29 at >>>>> device 0.3 on pci2 >>>>> igb3: Using MSIX interrupts with 9 vectors >>>>> igb3: Ethernet address: 00:1e:67:9a:d5:8b >>>>> igb3: Bound queue 0 to cpu 0 >>>>> igb3: Bound queue 1 to cpu 1 >>>>> igb3: Bound queue 2 to cpu 2 >>>>> igb3: Bound queue 3 to cpu 3 >>>>> igb3: Bound queue 4 to cpu 4 >>>>> igb3: Bound queue 5 to cpu 5 >>>>> igb3: Bound queue 6 to cpu 6 >>>>> igb3: Bound queue 7 to cpu 7 >>>>> pcib3: irq 47 at device 2.0 on pci0 >>>>> pci4: on pcib3 >>>>> igb4: mem >>>>> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 >>>>> on pci4 >>>>> igb4: Using MSIX interrupts with 9 vectors >>>>> igb4: Ethernet address: a0:36:9f:37:82:7e >>>>> igb4: Bound queue 0 to cpu 8 >>>>> igb4: Bound queue 1 to cpu 9 >>>>> igb4: Bound queue 2 to cpu 10 >>>>> igb4: Bound queue 3 to cpu 11 >>>>> igb4: Bound queue 4 to cpu 0 >>>>> igb4: Bound queue 5 to cpu 1 >>>>> igb4: Bound queue 6 to cpu 2 >>>>> igb4: Bound queue 7 to cpu 3 >>>>> igb5: mem >>>>> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 >>>>> on pci4 >>>>> igb5: Using MSIX interrupts with 9 vectors >>>>> igb5: Ethernet address: a0:36:9f:37:82:7f >>>>> igb5: Bound queue 0 to cpu 4 >>>>> igb5: Bound queue 1 to cpu 5 >>>>> igb5: Bound queue 2 to cpu 6 >>>>> igb5: Bound queue 3 to cpu 7 >>>>> igb5: Bound queue 4 to cpu 8 >>>>> igb5: Bound queue 5 to cpu 9 >>>>> igb5: Bound queue 6 to cpu 10 >>>>> igb5: Bound queue 7 to cpu 11 >>>>> pcib4: irq 16 at device 3.0 on pci0 >>>>> pci6: on pcib4 >>>>> igb6: mem >>>>> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 >>>>> on pci6 >>>>> igb6: Using MSIX interrupts with 9 vectors >>>>> igb6: Ethernet address: a0:36:9f:37:82:8a >>>>> igb6: Bound queue 0 to cpu 0 >>>>> igb6: Bound queue 1 to cpu 1 >>>>> igb6: Bound queue 2 to cpu 2 >>>>> igb6: Bound queue 3 to cpu 3 >>>>> igb6: Bound queue 4 to cpu 4 >>>>> igb6: Bound queue 5 to cpu 5 >>>>> igb6: Bound queue 6 to cpu 6 >>>>> igb6: Bound queue 7 to cpu 7 >>>>> igb7: mem >>>>> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 >>>>> on pci6 >>>>> igb7: Using MSIX interrupts with 9 vectors >>>>> igb7: Ethernet address: a0:36:9f:37:82:8b >>>>> igb7: Bound queue 0 to cpu 8 >>>>> igb7: Bound queue 1 to cpu 9 >>>>> igb7: Bound queue 2 to cpu 10 >>>>> igb7: Bound queue 3 to cpu 11 >>>>> igb7: Bound queue 4 to cpu 0 >>>>> igb7: Bound queue 5 to cpu 1 >>>>> igb7: Bound queue 6 to cpu 2 >>>>> igb7: Bound queue 7 to cpu 3 >>>>> pcib5: irq 16 at device 17.0 on pci0 >>>>> pci8: on pcib5 >>>>> pci0: at device 22.0 (no driver attached) >>>>> pci0: at device 22.1 (no driver attached) >>>>> ehci0: mem >>>>> 0xd1220000-0xd12203ff irq >>>>> 22 at device 26.0 on pci0 >>>>> usbus0: EHCI version 1.0 >>>>> usbus0 on ehci0 >>>>> pcib6: irq 16 at device 28.0 on pci0 >>>>> pci9: on pcib6 >>>>> pcib7: irq 17 at device 28.5 on pci0 >>>>> pci10: on pcib7 >>>>> pci10: at device 0.0 (no driver attached) >>>>> pcib8: irq 19 at device 28.7 on pci0 >>>>> pci11: on pcib8 >>>>> vgapci0: mem >>>>> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq >>> 19 at >>>>> device 0.0 on pci11 >>>>> vgapci0: Boot video device >>>>> ehci1: mem >>>>> 0xd1210000-0xd12103ff irq >>>>> 20 at device 29.0 on pci0 >>>>> usbus1: EHCI version 1.0 >>>>> usbus1 on ehci1 >>>>> pcib9: at device 30.0 on pci0 >>>>> pci12: on pcib9 >>>>> isab0: at device 31.0 on pci0 >>>>> isa0: on isab0 >>>>> ahci0: port >>>>> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f >>> mem >>>>> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >>>>> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >>>>> ahcich0: at channel 0 on ahci0 >>>>> ahcich1: at channel 1 on ahci0 >>>>> ahcich2: at channel 2 on ahci0 >>>>> ahcich3: at channel 3 on ahci0 >>>>> ahcich4: at channel 4 on ahci0 >>>>> ahcich5: at channel 5 on ahci0 >>>>> ahciem0: on ahci0 >>>>> pcib10: on acpi0 >>>>> pci128: on pcib10 >>>>> pcib11: irq 71 at device 1.0 on pci128 >>>>> pci129: on pcib11 >>>>> ix0: >>>> 2.5.15> >>>>> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff >>>>> irq >>> 50 at >>>>> device 0.0 on pci129 >>>>> ix0: Using MSIX interrupts with 9 vectors >>>>> ix0: Ethernet address: 00:1b:21:89:25:32 >>>>> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>> ix1: >>>> 2.5.15> >>>>> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff >>>>> irq >>> 52 at >>>>> device 0.1 on pci129 >>>>> ix1: Using MSIX interrupts with 9 vectors >>>>> ix1: Ethernet address: 00:1b:21:89:25:33 >>>>> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>> pcib12: irq 71 at device 2.0 on pci128 >>>>> pci131: on pcib12 >>>>> pcib13: irq 71 at device 3.0 on pci128 >>>>> pci132: on pcib13 >>>>> acpi_button0: on acpi0 >>>>> pcib14: on acpi0 >>>>> pci127: on pcib14 >>>>> pcib15: on acpi0 >>>>> pci255: on pcib15 >>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on >>>>> acpi0 >>>>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>>>> orm0: at iomem >>>>> >>> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >>> >>>>> on isa0 >>>>> sc0: at flags 0x100 on isa0 >>>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>> isa0 >>>>> est0: on cpu0 >>>>> p4tcc0: on cpu0 >>>>> est1: on cpu1 >>>>> p4tcc1: on cpu1 >>>>> est2: on cpu2 >>>>> p4tcc2: on cpu2 >>>>> est3: on cpu3 >>>>> p4tcc3: on cpu3 >>>>> est4: on cpu4 >>>>> p4tcc4: on cpu4 >>>>> est5: on cpu5 >>>>> p4tcc5: on cpu5 >>>>> est6: on cpu6 >>>>> p4tcc6: on cpu6 >>>>> est7: on cpu7 >>>>> p4tcc7: on cpu7 >>>>> est8: on cpu8 >>>>> p4tcc8: on cpu8 >>>>> est9: on cpu9 >>>>> p4tcc9: on cpu9 >>>>> est10: on cpu10 >>>>> p4tcc10: on cpu10 >>>>> est11: on cpu11 >>>>> p4tcc11: on cpu11 >>>>> random: unblocking device. >>>>> usbus0: 480Mbps High Speed USB v2.0 >>>>> Timecounters tick every 1.000 msec >>>>> IPsec: Initialized Security Association Processing. >>>>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >>> accept, >>>>> logging disabled >>>>> usbus1: 480Mbps High Speed USB v2.0 >>>>> ugen1.1: at usbus1 >>>>> uhub0: on >>>>> usbus1 >>>>> ugen0.1: at usbus0 >>>>> uhub1: on >>>>> usbus0 >>>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>>> ada0: ATA-9 SATA 3.x device >>>>> ada0: Serial Number S1D5NSAF687077K >>>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>>> ada0: Command Queueing enabled >>>>> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >>>>> ada0: quirks=0x1<4K> >>>>> ada0: Previously was known as ad4 >>>>> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >>>>> ses0: SEMB S-E-S 2.00 device >>>>> ses0: SEMB SES Device >>>>> SMP: AP CPU #6 Launched! >>>>> SMP: AP CPU #3 Launched! >>>>> SMP: AP CPU #11 Launched! >>>>> SMP: AP CPU #5 Launched! >>>>> SMP: AP CPU #9 Launched! >>>>> SMP: AP CPU #1 Launched! >>>>> SMP: AP CPU #10 Launched! >>>>> SMP: AP CPU #2 Launched! >>>>> SMP: AP CPU #8 Launched! >>>>> SMP: AP CPU #4 Launched! >>>>> SMP: AP CPU #7 Launched! >>>>> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >>>>> Root mount waiting for: usbus1 usbus0 >>>>> uhub1: 2 ports with 2 removable, self powered >>>>> uhub0: 2 ports with 2 removable, self powered >>>>> Root mount waiting for: usbus1 usbus0 >>>>> ugen1.2: at usbus1 >>>>> uhub2: >>>> addr 2> >>> on >>>>> usbus1 >>>>> ugen0.2: at usbus0 >>>>> uhub3: >>>> addr 2> >>> on >>>>> usbus0 >>>>> Root mount waiting for: usbus1 usbus0 >>>>> uhub3: 6 ports with 6 removable, self powered >>>>> uhub2: 8 ports with 8 removable, self powered >>>>> ugen1.3: at usbus1 >>>>> ukbd0: on usbus1 >>>>> kbd0 at ukbd0 >>>>> Root mount waiting for: usbus1 >>>>> ugen1.4: at usbus1 >>>>> ukbd1: on usbus1 >>>>> kbd2 at ukbd1 >>>>> Trying to mount root from ufs:/dev/label/rootfs [rw]... >>>>> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >>>>> member to prevent IPv6 address scope violation. >>>>> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >>>>> member to prevent IPv6 address scope violation. >>>>> ums0: on usbus1 >>>>> ums0: 3 buttons and [Z] coordinates ID=0 >>>>> uhid0: on usbus1 >>>>> >>>>> # uname -a >>>>> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 >>>>> r274375: >>>>> Tue Nov 11 10:24:44 BRST 2014 >>>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>>> >>>>> [1] https://calomel.org/freebsd_network_tuning.html >>>>> [2] http://ark.intel.com/products/63157 >>>>> [3] >>>>> >>> http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Network-Adapter-X520-SR2 >>> >>>>> [4] http://ark.intel.com/products/59062/ >>>>> >>>>> Please I need a help! and sorry my english :) >>>>> From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 19:40:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68AEB6D6 for ; Mon, 1 Dec 2014 19:40:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4EAB2D58 for ; Mon, 1 Dec 2014 19:40:40 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB1JeeBI037033 for ; Mon, 1 Dec 2014 19:40:40 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB1JeeUa037032; Mon, 1 Dec 2014 19:40:40 GMT (envelope-from root) Date: Mon, 1 Dec 2014 19:40:40 +0000 To: freebsd-net@freebsd.org From: "rpaulo (Rui Paulo)" Subject: [Differential] [Request, 2 lines] D1251: Test, please ignore. Message-ID: X-Priority: 3 Thread-Topic: D1251: Test, please ignore. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZmE0N2M2OTU2Y2U5N2QwNTVmMGRlMzNjYjQ4 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 19:40:40 -0000 rpaulo created this revision. rpaulo added a subscriber: freebsd-net. REVISION SUMMARY Test. BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1251 AFFECTED FILES COPYRIGHT To: rpaulo Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 19:42:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D8DF7A7 for ; Mon, 1 Dec 2014 19:42:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37F77D80 for ; Mon, 1 Dec 2014 19:42:20 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB1JgIMQ040293 for ; Mon, 1 Dec 2014 19:42:18 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB1JgIr7040292; Mon, 1 Dec 2014 19:42:18 GMT (envelope-from root) Date: Mon, 1 Dec 2014 19:42:18 +0000 To: freebsd-net@freebsd.org From: "rpaulo (Rui Paulo)" Subject: [Differential] [Abandoned] D1251: Test, please ignore. Message-ID: <8787ff57a3a8d45209dfe4cd6acf73af@localhost.localdomain> X-Priority: 3 Thread-Topic: D1251: Test, please ignore. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZmE0N2M2OTU2Y2U5N2QwNTVmMGRlMzNjYjQ4IFR8xJo= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 19:42:20 -0000 rpaulo abandoned this revision. REVISION DETAIL https://reviews.freebsd.org/D1251 To: rpaulo Cc: freebsd-net From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 21:31:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C51056B for ; Mon, 1 Dec 2014 21:31:04 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id B5738BB7 for ; Mon, 1 Dec 2014 21:31:01 +0000 (UTC) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 01 Dec 2014 13:29:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="423715159" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 01 Dec 2014 13:19:44 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.11.104]) by ORSMSX103.amr.corp.intel.com ([169.254.2.65]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 13:29:52 -0800 From: "Pieper, Jeffrey E" To: Marcelo Gondim , "freebsd-net@freebsd.org" Subject: RE: Problems with Intel X520-SR2 Thread-Topic: Problems with Intel X520-SR2 Thread-Index: AQHQDZ7ZVbOlnoY7akyZRvzOi+fEQJx7P13w Date: Mon, 1 Dec 2014 21:29:52 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65687E987C2A@ORSMSX111.amr.corp.intel.com> References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> <547BB862.6080801@bsdinfo.com.br> <547CC35A.1080108@bsdinfo.com.br> In-Reply-To: <547CC35A.1080108@bsdinfo.com.br> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 01 Dec 2014 21:31:04 -0000 Hi Marcelo, A couple of questions - you are using 1310nm fiber on ix0, correct? The dif= ference seems to be that ix0 is LR and ix1 is SR. Also, is there a reason t= hat the interrupt rate is set higher for ix0? dev.ix.0.queue0.interrupt_rate: 50000 dev.ix.1.queue0.interrupt_rate: 11627 Jeff -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Marcelo Gondim Sent: Monday, December 01, 2014 11:37 AM To: freebsd-net@freebsd.org Subject: Re: Problems with Intel X520-SR2 On 30/11/2014 22:37, Marcelo Gondim wrote: > Hi Jack, > > On 30/11/2014 16:20, Jack Vogel wrote: >> Good suggestions, do you ever see any 'interrupt throttled' messages?=20 >> You >> might >> want to change the storm threshold to 0 and disable it. > I can try this: > > sysctl hw.intr_storm_threshold=3D0 Hi Jack, Same problem with hw.intr_storm_threshold=3D0 I still think it might be something in my traffic that the driver is not=20 dealing properly. # netstat -idn . . . ix0 1500 00:1b:21:89:25:32 18446739080975184057 268=20 5876340155018 18446742570019979938 0 0 0 ix0 - fe80::21b:21f fe80::21b:21ff:fe 0 - - =20 1 - - - ix1 1500 00:1b:21:89:25:33 18446730999135967066 0=20 13653533351669 18446742457148273271 0 0 0 ix1 - fe80::21b:21f fe80::21b:21ff:fe 0 - - =20 0 - - - . . . Are 5876340155018 dropped packets in ix0 and 13653533351669 dropped=20 packets in ix1 # w -n 5:35PM up 15 days, 20:29, 2 users, load averages: 8.96, 9.03, 8.84 USER TTY FROM LOGIN@ IDLE WHAT gondim pts/1 186.xxx.48.8 5:22PM - w -n > >> >> I too would like to know if there are any messages when the 'hang'=20 >> happens. > Nope. No message. :( > >> >> I don't know much about lagg, is it responsible for link events?? Its=20 >> not a >> normal >> situation to be having so many :( >> >> Jack >> >> >> On Sun, Nov 30, 2014 at 10:01 AM, Adrian Chadd =20 >> wrote: >> >>> Your link_irq value is way too high. I think you're exposing some >>> unhandled corner case in the driver (as I had this issue when I had >>> some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe >>> driver isn't getting link events. >>> >>> My test setup at home has link_irq=3D1 on both sides, and it runs >>> full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for >>> RSS testing for weeks at a time. I have no issues and no hiccups. >>> So, I think there's two problems: >>> >>> * you're still seeing way too many link_irq events; and >>> * i think there's some bad handling when it comes to link_irq events. >>> >>> I wonder if we're still clearing some of the interrupt register bits >>> incorrectly in ixgbe_msix_link(). >>> >>> >>> -adrian >>> >>> >>> >>> >>> -adrian >>> >>> >>> On 30 November 2014 at 08:05, Alexander V. Chernikov >>> wrote: >>>> On 30.11.2014 18:47, Marcelo Gondim wrote: >>>>> Dear, >>>>> >>>>> Unfortunately I have more options to resolve this problem I'm having >>> with >>>>> Intel X520-SR2. Have we changed the X520, we exchange the optical=20 >>>>> cords, >>>>> exchanged optical modules, we changed the entire server, we reduce=20 >>>>> the >>>>> temperature inside the equipment, made some attempts to tunning=20 >>>>> the site >>>>> calomel[1]. We spend a lot of money and do not solve the problem. >>>>> >>>>> What happens is that when there is a traffic above 1.2Gbps with PPS >>> above >>>>> 700kpps in sometimes almost daily there is a lock in two 10GbE=20 >>>>> ports the >>>>> X520-SR interface. Where I am obliged to leave a script running in=20 >>>>> the >>>>> background doing just that: >>>> What does this "lock" looks like? >>>> Do you using jumbo frames? >>>> Is this IPv4 or IPv4+IPv6 ? >>>> Can you share "netstat -m" output? >>>> Do you use ipfw dynamic states? >>>> Are sure you're not hitting "net.inet.ip.fw.dyn_max=3D65536" ? >>>> >>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>> >>>> Looks suspicious. Either you're running out of mbufs due to total mbuf >>>> number is small, or system is very busy sometimes. >>>> What does you "top -HPSzs1" output look like? >>>> >>>> >>>>> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig=20 >>>>> ix1 up >>>>> >>>>> Made it back to the interface function normally. It's already so for >>>>> months and have not tried the latest driver from Intel because I=20 >>>>> do not >>> see >>>>> anything related to this issue. >>>>> >>>>> These 2-port 10GbE are my backbone linking the four cities that=20 >>>>> attend >>> to >>>>> our main router. One is backup to other but when the problem occurs, >>> the two >>>>> ports stop working and at the moment I have a break in my Internet >>>>> >>>>> I can only conclude that the problem is one of the things below: >>>>> >>>>> 1 - Intel Interface X520-SR2 has a problem with certain types of=20 >>>>> traffic >>>>> and then hangs. >>>>> 2 - The ixgbe driver has a bug that is causing it. >>>>> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >>>>> would be a regression and the equipment is very far away from me if I >>> need >>>>> to move me. >>>>> >>>>> Honestly I'm almost going on a Juniper closed solution. I would=20 >>>>> not want >>>>> to do this because I love FreeBSD and I can not believe that he=20 >>>>> does not >>>>> support a 2.7Gbps traffic, which is my peak traffic without getting >>> having >>>>> these falls. My hardware today is this: >>>>> >>>>> hw.machine: amd64 >>>>> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>>>> hw.ncpu: 12 >>>>> hw.byteorder: 1234 >>>>> hw.physmem: 17083641856 >>>>> hw.usermem: 15741001728 >>>>> >>>>> Hardware all Intel with motherboard S2600COE [2] and with network >>>>> interfaces offboard: >>>>> >>>>> 1x - X520-SR2 [3] >>>>> 2x - I350-T2 [4] >>>>> >>>>> My loader.conf: >>>>> >>>>> loader_logo=3D"beastie" >>>>> if_lagg_load=3D"YES" >>>>> speaker_load=3D"YES" >>>>> aio_load=3D"YES" >>>>> autoboot_delay=3D"5" >>>>> net.fibs=3D1 >>>>> >>>>> My sysctl.conf: >>>>> >>>>> net.inet.ip.forwarding=3D1 >>>>> net.inet.ip.fastforwarding=3D1 >>>>> net.inet6.ip6.forwarding=3D1 >>>>> kern.ipc.somaxconn=3D4096 >>>>> net.inet.tcp.syncookies=3D1 >>>>> net.inet.ip.redirect=3D1 >>>>> net.inet.ip.accept_sourceroute=3D0 >>>>> net.inet.ip.sourceroute=3D0 >>>>> net.inet.tcp.drop_synfin=3D1 >>>>> net.inet.udp.blackhole=3D1 >>>>> net.inet.tcp.blackhole=3D2 >>>>> security.bsd.see_other_uids=3D0 >>>>> net.inet.ip.fw.dyn_buckets=3D65536 >>>>> net.inet.ip.fw.dyn_max=3D65536 >>>>> hw.intr_storm_threshold=3D9000 >>>>> net.inet.ip.dummynet.pipe_slot_limit=3D800 >>>>> net.inet.icmp.icmplim=3D2000 >>>>> >>>>> # sysctl dev.ix. >>>>> dev.ix.%parent: >>>>> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver,=20 >>>>> Version - >>>>> 2.5.15 >>>>> dev.ix.0.%driver: ix >>>>> dev.ix.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI1.BR42.S4= F0 >>>>> dev.ix.0.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 >>>>> subdevice=3D0x7a11 class=3D0x020000 >>>>> dev.ix.0.%parent: pci129 >>>>> dev.ix.0.fc: 3 >>>>> dev.ix.0.enable_aim: 1 >>>>> dev.ix.0.advertise_speed: 0 >>>>> dev.ix.0.dropped: 0 >>>>> dev.ix.0.mbuf_defrag_failed: 0 >>>>> dev.ix.0.watchdog_events: 0 >>>>> dev.ix.0.link_irq: 193783 >>>>> dev.ix.0.queue0.interrupt_rate: 50000 >>>>> dev.ix.0.queue0.irqs: 12029604413 >>>>> dev.ix.0.queue0.txd_head: 1517 >>>>> dev.ix.0.queue0.txd_tail: 1517 >>>>> dev.ix.0.queue0.tso_tx: 85 >>>>> dev.ix.0.queue0.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>>> dev.ix.0.queue0.tx_packets: 15392658033 >>>>> dev.ix.0.queue0.rxd_head: 709 >>>>> dev.ix.0.queue0.rxd_tail: 707 >>>>> dev.ix.0.queue0.rx_packets: 21762427837 >>>>> dev.ix.0.queue0.rx_bytes: 56918345381 >>>>> dev.ix.0.queue0.rx_copies: 124289013 >>>>> dev.ix.0.queue0.lro_queued: 0 >>>>> dev.ix.0.queue0.lro_flushed: 0 >>>>> dev.ix.0.queue1.interrupt_rate: 500000 >>>>> dev.ix.0.queue1.irqs: 11482146431 >>>>> dev.ix.0.queue1.txd_head: 731 >>>>> dev.ix.0.queue1.txd_tail: 731 >>>>> dev.ix.0.queue1.tso_tx: 1442 >>>>> dev.ix.0.queue1.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>>> dev.ix.0.queue1.tx_packets: 15835062632 >>>>> dev.ix.0.queue1.rxd_head: 685 >>>>> dev.ix.0.queue1.rxd_tail: 681 >>>>> dev.ix.0.queue1.rx_packets: 21220715209 >>>>> dev.ix.0.queue1.rx_bytes: 54351679461 >>>>> dev.ix.0.queue1.rx_copies: 120833356 >>>>> dev.ix.0.queue1.lro_queued: 0 >>>>> dev.ix.0.queue1.lro_flushed: 0 >>>>> dev.ix.0.queue2.interrupt_rate: 5319 >>>>> dev.ix.0.queue2.irqs: 11532560324 >>>>> dev.ix.0.queue2.txd_head: 501 >>>>> dev.ix.0.queue2.txd_tail: 501 >>>>> dev.ix.0.queue2.tso_tx: 2474 >>>>> dev.ix.0.queue2.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue2.no_desc_avail: 429244 >>>>> dev.ix.0.queue2.tx_packets: 15772209238 >>>>> dev.ix.0.queue2.rxd_head: 246 >>>>> dev.ix.0.queue2.rxd_tail: 244 >>>>> dev.ix.0.queue2.rx_packets: 21408648299 >>>>> dev.ix.0.queue2.rx_bytes: 56862350194 >>>>> dev.ix.0.queue2.rx_copies: 124973551 >>>>> dev.ix.0.queue2.lro_queued: 0 >>>>> dev.ix.0.queue2.lro_flushed: 0 >>>>> dev.ix.0.queue3.interrupt_rate: 20833 >>>>> dev.ix.0.queue3.irqs: 11557466322 >>>>> dev.ix.0.queue3.txd_head: 773 >>>>> dev.ix.0.queue3.txd_tail: 773 >>>>> dev.ix.0.queue3.tso_tx: 40 >>>>> dev.ix.0.queue3.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue3.no_desc_avail: 665620 >>>>> dev.ix.0.queue3.tx_packets: 16479111658 >>>>> dev.ix.0.queue3.rxd_head: 1858 >>>>> dev.ix.0.queue3.rxd_tail: 1854 >>>>> dev.ix.0.queue3.rx_packets: 21412821769 >>>>> dev.ix.0.queue3.rx_bytes: 52796089467 >>>>> dev.ix.0.queue3.rx_copies: 127385950 >>>>> dev.ix.0.queue3.lro_queued: 0 >>>>> dev.ix.0.queue3.lro_flushed: 0 >>>>> dev.ix.0.queue4.interrupt_rate: 11363 >>>>> dev.ix.0.queue4.irqs: 10824852635 >>>>> dev.ix.0.queue4.txd_head: 1711 >>>>> dev.ix.0.queue4.txd_tail: 1713 >>>>> dev.ix.0.queue4.tso_tx: 581 >>>>> dev.ix.0.queue4.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue4.no_desc_avail: 115346803 >>>>> dev.ix.0.queue4.tx_packets: 16100396810 >>>>> dev.ix.0.queue4.rxd_head: 244 >>>>> dev.ix.0.queue4.rxd_tail: 243 >>>>> dev.ix.0.queue4.rx_packets: 21240995210 >>>>> dev.ix.0.queue4.rx_bytes: 58726730771 >>>>> dev.ix.0.queue4.rx_copies: 124872141 >>>>> dev.ix.0.queue4.lro_queued: 0 >>>>> dev.ix.0.queue4.lro_flushed: 0 >>>>> dev.ix.0.queue5.interrupt_rate: 500000 >>>>> dev.ix.0.queue5.irqs: 10955464761 >>>>> dev.ix.0.queue5.txd_head: 75 >>>>> dev.ix.0.queue5.txd_tail: 77 >>>>> dev.ix.0.queue5.tso_tx: 1758 >>>>> dev.ix.0.queue5.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue5.no_desc_avail: 4759 >>>>> dev.ix.0.queue5.tx_packets: 16267888038 >>>>> dev.ix.0.queue5.rxd_head: 905 >>>>> dev.ix.0.queue5.rxd_tail: 904 >>>>> dev.ix.0.queue5.rx_packets: 21381144028 >>>>> dev.ix.0.queue5.rx_bytes: 61800291690 >>>>> dev.ix.0.queue5.rx_copies: 129684798 >>>>> dev.ix.0.queue5.lro_queued: 0 >>>>> dev.ix.0.queue5.lro_flushed: 0 >>>>> dev.ix.0.queue6.interrupt_rate: 33333 >>>>> dev.ix.0.queue6.irqs: 11081350674 >>>>> dev.ix.0.queue6.txd_head: 1744 >>>>> dev.ix.0.queue6.txd_tail: 1746 >>>>> dev.ix.0.queue6.tso_tx: 38 >>>>> dev.ix.0.queue6.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue6.no_desc_avail: 18381 >>>>> dev.ix.0.queue6.tx_packets: 15376961749 >>>>> dev.ix.0.queue6.rxd_head: 1783 >>>>> dev.ix.0.queue6.rxd_tail: 1782 >>>>> dev.ix.0.queue6.rx_packets: 21381814216 >>>>> dev.ix.0.queue6.rx_bytes: 56828960117 >>>>> dev.ix.0.queue6.rx_copies: 130194429 >>>>> dev.ix.0.queue6.lro_queued: 0 >>>>> dev.ix.0.queue6.lro_flushed: 0 >>>>> dev.ix.0.queue7.interrupt_rate: 5319 >>>>> dev.ix.0.queue7.irqs: 11014043865 >>>>> dev.ix.0.queue7.txd_head: 1545 >>>>> dev.ix.0.queue7.txd_tail: 1545 >>>>> dev.ix.0.queue7.tso_tx: 59 >>>>> dev.ix.0.queue7.no_tx_dma_setup: 0 >>>>> dev.ix.0.queue7.no_desc_avail: 5497 >>>>> dev.ix.0.queue7.tx_packets: 15283534142 >>>>> dev.ix.0.queue7.rxd_head: 184 >>>>> dev.ix.0.queue7.rxd_tail: 182 >>>>> dev.ix.0.queue7.rx_packets: 21431994087 >>>>> dev.ix.0.queue7.rx_bytes: 57942270182 >>>>> dev.ix.0.queue7.rx_copies: 128363306 >>>>> dev.ix.0.queue7.lro_queued: 0 >>>>> dev.ix.0.queue7.lro_flushed: 0 >>>>> dev.ix.0.mac_stats.crc_errs: 268 >>>>> dev.ix.0.mac_stats.ill_errs: 33 >>>>> dev.ix.0.mac_stats.byte_errs: 55 >>>>> dev.ix.0.mac_stats.short_discards: 0 >>>>> dev.ix.0.mac_stats.local_faults: 3484 >>>>> dev.ix.0.mac_stats.remote_faults: 121 >>>>> dev.ix.0.mac_stats.rec_len_errs: 0 >>>>> dev.ix.0.mac_stats.xon_txd: 1602713563748 >>>>> dev.ix.0.mac_stats.xon_recvd: 0 >>>>> dev.ix.0.mac_stats.xoff_txd: 108342810167 >>>>> dev.ix.0.mac_stats.xoff_recvd: 0 >>>>> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >>>>> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >>>>> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >>>>> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >>>>> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >>>>> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >>>>> dev.ix.0.mac_stats.rx_frames_64: 5356098 >>>>> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >>>>> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >>>>> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >>>>> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >>>>> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >>>>> dev.ix.0.mac_stats.recv_undersized: 0 >>>>> dev.ix.0.mac_stats.recv_fragmented: 0 >>>>> dev.ix.0.mac_stats.recv_oversized: 244078 >>>>> dev.ix.0.mac_stats.recv_jabberd: 4 >>>>> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >>>>> dev.ix.0.mac_stats.management_pkts_drpd: 0 >>>>> dev.ix.0.mac_stats.checksum_errs: 897344641 >>>>> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >>>>> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >>>>> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >>>>> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >>>>> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >>>>> dev.ix.0.mac_stats.management_pkts_txd: 0 >>>>> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >>>>> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >>>>> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >>>>> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >>>>> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >>>>> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >>>>> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver,=20 >>>>> Version - >>>>> 2.5.15 >>>>> dev.ix.1.%driver: ix >>>>> dev.ix.1.%location: slot=3D0 function=3D1 handle=3D\_SB_.PCI1.BR42.S4= F1 >>>>> dev.ix.1.%pnpinfo: vendor=3D0x8086 device=3D0x10fb subvendor=3D0x8086 >>>>> subdevice=3D0x7a11 class=3D0x020000 >>>>> dev.ix.1.%parent: pci129 >>>>> dev.ix.1.fc: 3 >>>>> dev.ix.1.enable_aim: 1 >>>>> dev.ix.1.advertise_speed: 0 >>>>> dev.ix.1.dropped: 0 >>>>> dev.ix.1.mbuf_defrag_failed: 0 >>>>> dev.ix.1.watchdog_events: 0 >>>>> dev.ix.1.link_irq: 127925 >>>>> dev.ix.1.queue0.interrupt_rate: 11627 >>>>> dev.ix.1.queue0.irqs: 6686088831 >>>>> dev.ix.1.queue0.txd_head: 1618 >>>>> dev.ix.1.queue0.txd_tail: 1620 >>>>> dev.ix.1.queue0.tso_tx: 28 >>>>> dev.ix.1.queue0.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue0.no_desc_avail: 0 >>>>> dev.ix.1.queue0.tx_packets: 13527334563 >>>>> dev.ix.1.queue0.rxd_head: 1715 >>>>> dev.ix.1.queue0.rxd_tail: 1714 >>>>> dev.ix.1.queue0.rx_packets: 1503775702 >>>>> dev.ix.1.queue0.rx_bytes: 1069295301 >>>>> dev.ix.1.queue0.rx_copies: 2983480 >>>>> dev.ix.1.queue0.lro_queued: 0 >>>>> dev.ix.1.queue0.lro_flushed: 0 >>>>> dev.ix.1.queue1.interrupt_rate: 5319 >>>>> dev.ix.1.queue1.irqs: 6546967336 >>>>> dev.ix.1.queue1.txd_head: 1812 >>>>> dev.ix.1.queue1.txd_tail: 1812 >>>>> dev.ix.1.queue1.tso_tx: 6 >>>>> dev.ix.1.queue1.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue1.no_desc_avail: 0 >>>>> dev.ix.1.queue1.tx_packets: 13475453794 >>>>> dev.ix.1.queue1.rxd_head: 1246 >>>>> dev.ix.1.queue1.rxd_tail: 1245 >>>>> dev.ix.1.queue1.rx_packets: 1506444917 >>>>> dev.ix.1.queue1.rx_bytes: 783064190 >>>>> dev.ix.1.queue1.rx_copies: 2881513 >>>>> dev.ix.1.queue1.lro_queued: 0 >>>>> dev.ix.1.queue1.lro_flushed: 0 >>>>> dev.ix.1.queue2.interrupt_rate: 5319 >>>>> dev.ix.1.queue2.irqs: 6574615190 >>>>> dev.ix.1.queue2.txd_head: 1494 >>>>> dev.ix.1.queue2.txd_tail: 1494 >>>>> dev.ix.1.queue2.tso_tx: 33 >>>>> dev.ix.1.queue2.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue2.no_desc_avail: 0 >>>>> dev.ix.1.queue2.tx_packets: 13555495169 >>>>> dev.ix.1.queue2.rxd_head: 438 >>>>> dev.ix.1.queue2.rxd_tail: 437 >>>>> dev.ix.1.queue2.rx_packets: 1501380848 >>>>> dev.ix.1.queue2.rx_bytes: 1008544082 >>>>> dev.ix.1.queue2.rx_copies: 2660960 >>>>> dev.ix.1.queue2.lro_queued: 0 >>>>> dev.ix.1.queue2.lro_flushed: 0 >>>>> dev.ix.1.queue3.interrupt_rate: 5319 >>>>> dev.ix.1.queue3.irqs: 6617964401 >>>>> dev.ix.1.queue3.txd_head: 1853 >>>>> dev.ix.1.queue3.txd_tail: 1855 >>>>> dev.ix.1.queue3.tso_tx: 10 >>>>> dev.ix.1.queue3.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue3.no_desc_avail: 0 >>>>> dev.ix.1.queue3.tx_packets: 13561212942 >>>>> dev.ix.1.queue3.rxd_head: 429 >>>>> dev.ix.1.queue3.rxd_tail: 428 >>>>> dev.ix.1.queue3.rx_packets: 1498117903 >>>>> dev.ix.1.queue3.rx_bytes: 784881986 >>>>> dev.ix.1.queue3.rx_copies: 2695475 >>>>> dev.ix.1.queue3.lro_queued: 0 >>>>> dev.ix.1.queue3.lro_flushed: 0 >>>>> dev.ix.1.queue4.interrupt_rate: 5319 >>>>> dev.ix.1.queue4.irqs: 6575752163 >>>>> dev.ix.1.queue4.txd_head: 902 >>>>> dev.ix.1.queue4.txd_tail: 902 >>>>> dev.ix.1.queue4.tso_tx: 5 >>>>> dev.ix.1.queue4.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue4.no_desc_avail: 0 >>>>> dev.ix.1.queue4.tx_packets: 13478514009 >>>>> dev.ix.1.queue4.rxd_head: 536 >>>>> dev.ix.1.queue4.rxd_tail: 535 >>>>> dev.ix.1.queue4.rx_packets: 1476720084 >>>>> dev.ix.1.queue4.rx_bytes: 944967171 >>>>> dev.ix.1.queue4.rx_copies: 2650672 >>>>> dev.ix.1.queue4.lro_queued: 0 >>>>> dev.ix.1.queue4.lro_flushed: 0 >>>>> dev.ix.1.queue5.interrupt_rate: 10416 >>>>> dev.ix.1.queue5.irqs: 6578099670 >>>>> dev.ix.1.queue5.txd_head: 1996 >>>>> dev.ix.1.queue5.txd_tail: 1996 >>>>> dev.ix.1.queue5.tso_tx: 663 >>>>> dev.ix.1.queue5.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue5.no_desc_avail: 0 >>>>> dev.ix.1.queue5.tx_packets: 13516483196 >>>>> dev.ix.1.queue5.rxd_head: 1296 >>>>> dev.ix.1.queue5.rxd_tail: 1295 >>>>> dev.ix.1.queue5.rx_packets: 1496584151 >>>>> dev.ix.1.queue5.rx_bytes: 810434347 >>>>> dev.ix.1.queue5.rx_copies: 2899315 >>>>> dev.ix.1.queue5.lro_queued: 0 >>>>> dev.ix.1.queue5.lro_flushed: 0 >>>>> dev.ix.1.queue6.interrupt_rate: 5319 >>>>> dev.ix.1.queue6.irqs: 6624395782 >>>>> dev.ix.1.queue6.txd_head: 1058 >>>>> dev.ix.1.queue6.txd_tail: 1058 >>>>> dev.ix.1.queue6.tso_tx: 20 >>>>> dev.ix.1.queue6.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue6.no_desc_avail: 0 >>>>> dev.ix.1.queue6.tx_packets: 13491315217 >>>>> dev.ix.1.queue6.rxd_head: 1550 >>>>> dev.ix.1.queue6.rxd_tail: 1549 >>>>> dev.ix.1.queue6.rx_packets: 1510907490 >>>>> dev.ix.1.queue6.rx_bytes: 719914325 >>>>> dev.ix.1.queue6.rx_copies: 2712955 >>>>> dev.ix.1.queue6.lro_queued: 0 >>>>> dev.ix.1.queue6.lro_flushed: 0 >>>>> dev.ix.1.queue7.interrupt_rate: 29411 >>>>> dev.ix.1.queue7.irqs: 6573304834 >>>>> dev.ix.1.queue7.txd_head: 784 >>>>> dev.ix.1.queue7.txd_tail: 786 >>>>> dev.ix.1.queue7.tso_tx: 2 >>>>> dev.ix.1.queue7.no_tx_dma_setup: 0 >>>>> dev.ix.1.queue7.no_desc_avail: 0 >>>>> dev.ix.1.queue7.tx_packets: 13587681458 >>>>> dev.ix.1.queue7.rxd_head: 1489 >>>>> dev.ix.1.queue7.rxd_tail: 1488 >>>>> dev.ix.1.queue7.rx_packets: 1504712031 >>>>> dev.ix.1.queue7.rx_bytes: 1216803328 >>>>> dev.ix.1.queue7.rx_copies: 2976103 >>>>> dev.ix.1.queue7.lro_queued: 0 >>>>> dev.ix.1.queue7.lro_flushed: 0 >>>>> dev.ix.1.mac_stats.crc_errs: 0 >>>>> dev.ix.1.mac_stats.ill_errs: 0 >>>>> dev.ix.1.mac_stats.byte_errs: 0 >>>>> dev.ix.1.mac_stats.short_discards: 0 >>>>> dev.ix.1.mac_stats.local_faults: 0 >>>>> dev.ix.1.mac_stats.remote_faults: 12 >>>>> dev.ix.1.mac_stats.rec_len_errs: 0 >>>>> dev.ix.1.mac_stats.xon_txd: 1714791401322 >>>>> dev.ix.1.mac_stats.xon_recvd: 0 >>>>> dev.ix.1.mac_stats.xoff_txd: 41095995010 >>>>> dev.ix.1.mac_stats.xoff_recvd: 0 >>>>> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >>>>> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >>>>> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >>>>> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >>>>> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >>>>> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >>>>> dev.ix.1.mac_stats.rx_frames_64: 73447 >>>>> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >>>>> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >>>>> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >>>>> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >>>>> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >>>>> dev.ix.1.mac_stats.recv_undersized: 0 >>>>> dev.ix.1.mac_stats.recv_fragmented: 0 >>>>> dev.ix.1.mac_stats.recv_oversized: 0 >>>>> dev.ix.1.mac_stats.recv_jabberd: 0 >>>>> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >>>>> dev.ix.1.mac_stats.management_pkts_drpd: 0 >>>>> dev.ix.1.mac_stats.checksum_errs: 85432477 >>>>> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >>>>> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >>>>> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >>>>> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >>>>> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >>>>> dev.ix.1.mac_stats.management_pkts_txd: 0 >>>>> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >>>>> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >>>>> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >>>>> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >>>>> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >>>>> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >>>>> >>>>> # cat /var/run/dmesg.boot >>>>> >>>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992,=20 >>>>> 1993, 1994 >>>>> The Regents of the University of California. All rights >>> reserved. >>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >>>>> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >>>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)=20 >>>>> 20140512 >>>>> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class >>> CPU) >>>>> Origin =3D "GenuineIntel" Id =3D 0x306e4 Family =3D 0x6 Model = =3D 0x3e >>>>> Stepping =3D 4 >>>>> >>>>> >>> Features=3D0xbfebfbff=20 >>> >>>>> >>> Features2=3D0x7fbee3ff=20 >>> >>>>> AMD Features=3D0x2c100800 >>>>> AMD Features2=3D0x1 >>>>> Structured Extended Features=3D0x281 >>>>> VT-x: (disabled in BIOS)=20 >>>>> PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >>>>> TSC: P-state invariant, performance statistics >>>>> real memory =3D 17179869184 (16384 MB) >>>>> avail memory =3D 16515358720 (15750 MB) >>>>> Event timer "LAPIC" quality 600 >>>>> ACPI APIC Table: >>>>> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >>>>> FreeBSD/SMP: 2 package(s) x 6 core(s) >>>>> cpu0 (BSP): APIC ID: 0 >>>>> cpu1 (AP): APIC ID: 2 >>>>> cpu2 (AP): APIC ID: 4 >>>>> cpu3 (AP): APIC ID: 6 >>>>> cpu4 (AP): APIC ID: 8 >>>>> cpu5 (AP): APIC ID: 10 >>>>> cpu6 (AP): APIC ID: 32 >>>>> cpu7 (AP): APIC ID: 34 >>>>> cpu8 (AP): APIC ID: 36 >>>>> cpu9 (AP): APIC ID: 38 >>>>> cpu10 (AP): APIC ID: 40 >>>>> cpu11 (AP): APIC ID: 42 >>>>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock:=20 >>>>> 32, >>>>> using default 16 (20130823/tbfadt-682) >>>>> ioapic0 irqs 0-23 on motherboard >>>>> ioapic1 irqs 24-47 on motherboard >>>>> ioapic2 irqs 48-71 on motherboard >>>>> kbd1 at kbdmux0 >>>>> random: initialized >>>>> cryptosoft0: on motherboard >>>>> acpi0: on motherboard >>>>> acpi0: Power Button (fixed) >>>>> acpi0: reservation of 0, 9d000 (3) failed >>>>> cpu0: on acpi0 >>>>> cpu1: on acpi0 >>>>> cpu2: on acpi0 >>>>> cpu3: on acpi0 >>>>> cpu4: on acpi0 >>>>> cpu5: on acpi0 >>>>> cpu6: on acpi0 >>>>> cpu7: on acpi0 >>>>> cpu8: on acpi0 >>>>> cpu9: on acpi0 >>>>> cpu10: on acpi0 >>>>> cpu11: on acpi0 >>>>> hpet0: iomem 0xfed00000-0xfed003ff on=20 >>>>> acpi0 >>>>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>>>> Event timer "HPET" frequency 14318180 Hz quality 350 >>>>> Event timer "HPET1" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET2" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET3" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET4" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET5" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET6" frequency 14318180 Hz quality 340 >>>>> Event timer "HPET7" frequency 14318180 Hz quality 340 >>>>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>>>> atrtc0: Warning: Couldn't map I/O. >>>>> Event timer "RTC" frequency 32768 Hz quality 0 >>>>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>> Event timer "i8254" frequency 1193182 Hz quality 100 >>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>> pci0: on pcib0 >>>>> pcib1: irq 47 at device 1.0 on pci0 >>>>> pci1: on pcib1 >>>>> pcib2: irq 47 at device 1.1 on pci0 >>>>> pci2: on pcib2 >>>>> igb0: port >>>>> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq=20 >>>>> 27 at >>>>> device 0.0 on pci2 >>>>> igb0: Using MSIX interrupts with 9 vectors >>>>> igb0: Ethernet address: 00:1e:67:9a:d5:88 >>>>> 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 >>>>> igb0: Bound queue 4 to cpu 4 >>>>> igb0: Bound queue 5 to cpu 5 >>>>> igb0: Bound queue 6 to cpu 6 >>>>> igb0: Bound queue 7 to cpu 7 >>>>> igb1: port >>>>> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq=20 >>>>> 30 at >>>>> device 0.1 on pci2 >>>>> igb1: Using MSIX interrupts with 9 vectors >>>>> igb1: Ethernet address: 00:1e:67:9a:d5:89 >>>>> igb1: Bound queue 0 to cpu 8 >>>>> igb1: Bound queue 1 to cpu 9 >>>>> igb1: Bound queue 2 to cpu 10 >>>>> igb1: Bound queue 3 to cpu 11 >>>>> igb1: Bound queue 4 to cpu 0 >>>>> igb1: Bound queue 5 to cpu 1 >>>>> igb1: Bound queue 6 to cpu 2 >>>>> igb1: Bound queue 7 to cpu 3 >>>>> igb2: port >>>>> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq=20 >>>>> 28 at >>>>> device 0.2 on pci2 >>>>> igb2: Using MSIX interrupts with 9 vectors >>>>> igb2: Ethernet address: 00:1e:67:9a:d5:8a >>>>> igb2: Bound queue 0 to cpu 4 >>>>> igb2: Bound queue 1 to cpu 5 >>>>> igb2: Bound queue 2 to cpu 6 >>>>> igb2: Bound queue 3 to cpu 7 >>>>> igb2: Bound queue 4 to cpu 8 >>>>> igb2: Bound queue 5 to cpu 9 >>>>> igb2: Bound queue 6 to cpu 10 >>>>> igb2: Bound queue 7 to cpu 11 >>>>> igb3: port >>>>> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq=20 >>>>> 29 at >>>>> device 0.3 on pci2 >>>>> igb3: Using MSIX interrupts with 9 vectors >>>>> igb3: Ethernet address: 00:1e:67:9a:d5:8b >>>>> igb3: Bound queue 0 to cpu 0 >>>>> igb3: Bound queue 1 to cpu 1 >>>>> igb3: Bound queue 2 to cpu 2 >>>>> igb3: Bound queue 3 to cpu 3 >>>>> igb3: Bound queue 4 to cpu 4 >>>>> igb3: Bound queue 5 to cpu 5 >>>>> igb3: Bound queue 6 to cpu 6 >>>>> igb3: Bound queue 7 to cpu 7 >>>>> pcib3: irq 47 at device 2.0 on pci0 >>>>> pci4: on pcib3 >>>>> igb4: mem >>>>> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0=20 >>>>> on pci4 >>>>> igb4: Using MSIX interrupts with 9 vectors >>>>> igb4: Ethernet address: a0:36:9f:37:82:7e >>>>> igb4: Bound queue 0 to cpu 8 >>>>> igb4: Bound queue 1 to cpu 9 >>>>> igb4: Bound queue 2 to cpu 10 >>>>> igb4: Bound queue 3 to cpu 11 >>>>> igb4: Bound queue 4 to cpu 0 >>>>> igb4: Bound queue 5 to cpu 1 >>>>> igb4: Bound queue 6 to cpu 2 >>>>> igb4: Bound queue 7 to cpu 3 >>>>> igb5: mem >>>>> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1=20 >>>>> on pci4 >>>>> igb5: Using MSIX interrupts with 9 vectors >>>>> igb5: Ethernet address: a0:36:9f:37:82:7f >>>>> igb5: Bound queue 0 to cpu 4 >>>>> igb5: Bound queue 1 to cpu 5 >>>>> igb5: Bound queue 2 to cpu 6 >>>>> igb5: Bound queue 3 to cpu 7 >>>>> igb5: Bound queue 4 to cpu 8 >>>>> igb5: Bound queue 5 to cpu 9 >>>>> igb5: Bound queue 6 to cpu 10 >>>>> igb5: Bound queue 7 to cpu 11 >>>>> pcib4: irq 16 at device 3.0 on pci0 >>>>> pci6: on pcib4 >>>>> igb6: mem >>>>> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0=20 >>>>> on pci6 >>>>> igb6: Using MSIX interrupts with 9 vectors >>>>> igb6: Ethernet address: a0:36:9f:37:82:8a >>>>> igb6: Bound queue 0 to cpu 0 >>>>> igb6: Bound queue 1 to cpu 1 >>>>> igb6: Bound queue 2 to cpu 2 >>>>> igb6: Bound queue 3 to cpu 3 >>>>> igb6: Bound queue 4 to cpu 4 >>>>> igb6: Bound queue 5 to cpu 5 >>>>> igb6: Bound queue 6 to cpu 6 >>>>> igb6: Bound queue 7 to cpu 7 >>>>> igb7: mem >>>>> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1=20 >>>>> on pci6 >>>>> igb7: Using MSIX interrupts with 9 vectors >>>>> igb7: Ethernet address: a0:36:9f:37:82:8b >>>>> igb7: Bound queue 0 to cpu 8 >>>>> igb7: Bound queue 1 to cpu 9 >>>>> igb7: Bound queue 2 to cpu 10 >>>>> igb7: Bound queue 3 to cpu 11 >>>>> igb7: Bound queue 4 to cpu 0 >>>>> igb7: Bound queue 5 to cpu 1 >>>>> igb7: Bound queue 6 to cpu 2 >>>>> igb7: Bound queue 7 to cpu 3 >>>>> pcib5: irq 16 at device 17.0 on pci0 >>>>> pci8: on pcib5 >>>>> pci0: at device 22.0 (no driver attached) >>>>> pci0: at device 22.1 (no driver attached) >>>>> ehci0: mem=20 >>>>> 0xd1220000-0xd12203ff irq >>>>> 22 at device 26.0 on pci0 >>>>> usbus0: EHCI version 1.0 >>>>> usbus0 on ehci0 >>>>> pcib6: irq 16 at device 28.0 on pci0 >>>>> pci9: on pcib6 >>>>> pcib7: irq 17 at device 28.5 on pci0 >>>>> pci10: on pcib7 >>>>> pci10: at device 0.0 (no driver attached) >>>>> pcib8: irq 19 at device 28.7 on pci0 >>>>> pci11: on pcib8 >>>>> vgapci0: mem >>>>> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq >>> 19 at >>>>> device 0.0 on pci11 >>>>> vgapci0: Boot video device >>>>> ehci1: mem=20 >>>>> 0xd1210000-0xd12103ff irq >>>>> 20 at device 29.0 on pci0 >>>>> usbus1: EHCI version 1.0 >>>>> usbus1 on ehci1 >>>>> pcib9: at device 30.0 on pci0 >>>>> pci12: on pcib9 >>>>> isab0: at device 31.0 on pci0 >>>>> isa0: on isab0 >>>>> ahci0: port >>>>> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f >>> mem >>>>> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >>>>> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >>>>> ahcich0: at channel 0 on ahci0 >>>>> ahcich1: at channel 1 on ahci0 >>>>> ahcich2: at channel 2 on ahci0 >>>>> ahcich3: at channel 3 on ahci0 >>>>> ahcich4: at channel 4 on ahci0 >>>>> ahcich5: at channel 5 on ahci0 >>>>> ahciem0: on ahci0 >>>>> pcib10: on acpi0 >>>>> pci128: on pcib10 >>>>> pcib11: irq 71 at device 1.0 on pci128 >>>>> pci129: on pcib11 >>>>> ix0: >>>> 2.5.15> >>>>> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff=20 >>>>> irq >>> 50 at >>>>> device 0.0 on pci129 >>>>> ix0: Using MSIX interrupts with 9 vectors >>>>> ix0: Ethernet address: 00:1b:21:89:25:32 >>>>> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>> ix1: >>>> 2.5.15> >>>>> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff=20 >>>>> irq >>> 52 at >>>>> device 0.1 on pci129 >>>>> ix1: Using MSIX interrupts with 9 vectors >>>>> ix1: Ethernet address: 00:1b:21:89:25:33 >>>>> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>> pcib12: irq 71 at device 2.0 on pci128 >>>>> pci131: on pcib12 >>>>> pcib13: irq 71 at device 3.0 on pci128 >>>>> pci132: on pcib13 >>>>> acpi_button0: on acpi0 >>>>> pcib14: on acpi0 >>>>> pci127: on pcib14 >>>>> pcib15: on acpi0 >>>>> pci255: on pcib15 >>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on=20 >>>>> acpi0 >>>>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>>>> orm0: at iomem >>>>> >>> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000= -0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff=20 >>> >>>>> on isa0 >>>>> sc0: at flags 0x100 on isa0 >>>>> sc0: VGA <16 virtual consoles, flags=3D0x300> >>>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>> isa0 >>>>> est0: on cpu0 >>>>> p4tcc0: on cpu0 >>>>> est1: on cpu1 >>>>> p4tcc1: on cpu1 >>>>> est2: on cpu2 >>>>> p4tcc2: on cpu2 >>>>> est3: on cpu3 >>>>> p4tcc3: on cpu3 >>>>> est4: on cpu4 >>>>> p4tcc4: on cpu4 >>>>> est5: on cpu5 >>>>> p4tcc5: on cpu5 >>>>> est6: on cpu6 >>>>> p4tcc6: on cpu6 >>>>> est7: on cpu7 >>>>> p4tcc7: on cpu7 >>>>> est8: on cpu8 >>>>> p4tcc8: on cpu8 >>>>> est9: on cpu9 >>>>> p4tcc9: on cpu9 >>>>> est10: on cpu10 >>>>> p4tcc10: on cpu10 >>>>> est11: on cpu11 >>>>> p4tcc11: on cpu11 >>>>> random: unblocking device. >>>>> usbus0: 480Mbps High Speed USB v2.0 >>>>> Timecounters tick every 1.000 msec >>>>> IPsec: Initialized Security Association Processing. >>>>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >>> accept, >>>>> logging disabled >>>>> usbus1: 480Mbps High Speed USB v2.0 >>>>> ugen1.1: at usbus1 >>>>> uhub0: on=20 >>>>> usbus1 >>>>> ugen0.1: at usbus0 >>>>> uhub1: on=20 >>>>> usbus0 >>>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>>> ada0: ATA-9 SATA 3.x device >>>>> ada0: Serial Number S1D5NSAF687077K >>>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>>> ada0: Command Queueing enabled >>>>> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >>>>> ada0: quirks=3D0x1<4K> >>>>> ada0: Previously was known as ad4 >>>>> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >>>>> ses0: SEMB S-E-S 2.00 device >>>>> ses0: SEMB SES Device >>>>> SMP: AP CPU #6 Launched! >>>>> SMP: AP CPU #3 Launched! >>>>> SMP: AP CPU #11 Launched! >>>>> SMP: AP CPU #5 Launched! >>>>> SMP: AP CPU #9 Launched! >>>>> SMP: AP CPU #1 Launched! >>>>> SMP: AP CPU #10 Launched! >>>>> SMP: AP CPU #2 Launched! >>>>> SMP: AP CPU #8 Launched! >>>>> SMP: AP CPU #4 Launched! >>>>> SMP: AP CPU #7 Launched! >>>>> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >>>>> Root mount waiting for: usbus1 usbus0 >>>>> uhub1: 2 ports with 2 removable, self powered >>>>> uhub0: 2 ports with 2 removable, self powered >>>>> Root mount waiting for: usbus1 usbus0 >>>>> ugen1.2: at usbus1 >>>>> uhub2: >>>> addr 2> >>> on >>>>> usbus1 >>>>> ugen0.2: at usbus0 >>>>> uhub3: >>>> addr 2> >>> on >>>>> usbus0 >>>>> Root mount waiting for: usbus1 usbus0 >>>>> uhub3: 6 ports with 6 removable, self powered >>>>> uhub2: 8 ports with 8 removable, self powered >>>>> ugen1.3: at usbus1 >>>>> ukbd0: on usbus1 >>>>> kbd0 at ukbd0 >>>>> Root mount waiting for: usbus1 >>>>> ugen1.4: at usbus1 >>>>> ukbd1: on usbus1 >>>>> kbd2 at ukbd1 >>>>> Trying to mount root from ufs:/dev/label/rootfs [rw]... >>>>> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >>>>> member to prevent IPv6 address scope violation. >>>>> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >>>>> member to prevent IPv6 address scope violation. >>>>> ums0: on usbus1 >>>>> ums0: 3 buttons and [Z] coordinates ID=3D0 >>>>> uhid0: on usbus1 >>>>> >>>>> # uname -a >>>>> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2=20 >>>>> r274375: >>>>> Tue Nov 11 10:24:44 BRST 2014 >>>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>>> >>>>> [1] https://calomel.org/freebsd_network_tuning.html >>>>> [2] http://ark.intel.com/products/63157 >>>>> [3] >>>>> >>> http://ark.intel.com/pt-br/products/39774/Intel-Ethernet-Converged-Netw= ork-Adapter-X520-SR2=20 >>> >>>>> [4] http://ark.intel.com/products/59062/ >>>>> >>>>> Please I need a help! and sorry my english :) >>>>> _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 00:09:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B500EB4 for ; Tue, 2 Dec 2014 00:09:33 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D7CADB3 for ; Tue, 2 Dec 2014 00:09:32 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so15700505wgh.39 for ; Mon, 01 Dec 2014 16:09:31 -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:content-transfer-encoding; bh=p5mMDrpRm5GNF61GWmqDGU+ad7Kk/5I7y8CkPyAFKGA=; b=YeECxCbewNIBN1fujN7FeTlbMny1/5vmo20uO821Fk/oDzgHYbXLmrC3r/6KqtOPk9 vQx73+cWSW6oBpsdAs8xM+p0AMTdPvimqHJ0pOMzmh+y7ev9IB3T9dTSoMV/D6SMR/rA 5Aug6hfwLR3KXSLrPE4349IDHCQ/zomz3QQze8QkaaTYICn1tWaxAo4RLY+gg7qQSnrS x5EJnsIMMwS0Z9a2YdZkfdwF8S1n63opJDVYE/45UB1RFr/3/s/qSjfYiZVtn6FWY3B3 gRUC69/2SH/yjdFRAdGx7f69hreHDzh1s1775IfD164sYt4H6u5KkIBxETy+5Qh9GlvF 0pew== MIME-Version: 1.0 X-Received: by 10.180.240.201 with SMTP id wc9mr527739wic.59.1417478971135; Mon, 01 Dec 2014 16:09:31 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Mon, 1 Dec 2014 16:09:31 -0800 (PST) In-Reply-To: <547C9F7A.5000803@rewt.org.uk> References: <547C5DD3.90604@rawbw.com> <20141201150225.GB64370@apollo.corbe.net> <547C88AD.40407@rawbw.com> <20141201153712.4304976.24709.1746@denninger.net> <547C9F7A.5000803@rewt.org.uk> Date: Mon, 1 Dec 2014 16:09:31 -0800 X-Google-Sender-Auth: uFpB4W7beVNnX3OcPNBEZ8lCoFM Message-ID: Subject: Re: Can multiple apps listen for TCP on the same port? From: Adrian Chadd To: Joe Holden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 00:09:33 -0000 On 1 December 2014 at 09:03, Joe Holden wrote: > Was there a specific reason why we couldn't just extend REUSEADDR/PORT to= do > this a la Linux? Just a simple round robin would make those useful perhap= s Because REUSEADDR/REUSEPORT have different meanings, doubly so if you're using multicast. I created a new socket option so we wouldn't have to try and untangle that mess of "what was it supposed to do in this context" which may have broken applications that rely on the existing behaviour. -adrian > > On 01/12/2014 16:21, Adrian Chadd wrote: >> >> Hi, >> >> I introduced a socket option in -HEAD that lets you bind multiple >> things to the same listen ports. >> >> They're only load balanced if you're using RSS and set up RSS socket >> options as well; otherwise only one gets the incoming requests. >> >> IP_BINDMULTI and IP6_BINDMULTI. >> >> >> -a >> >> >> On 1 December 2014 at 08:14, Someone Somewhere >> wrote: >>> >>> @Yuri , are you sure that the second instance of nc does not accept any >>> connection? >>> I did a simple test : -> >>> #: nc -l 12345 (shell 1) >>> #: nc localhost 12345 (shell2) >>> at this point netstat shows that there is no one listening on 12345. Th= is >>> means any process should not be able to bind over port 12345(over TCP). >>> # nc -l 12345 (shell 3, shell 1 , 2 still active) >>> this instance of nc starts listening which I could verify via netstat >>> cmd. >>> # nc localhost 12345 (shell 4) >>> this nc instance connected to the nc started in previous step over shel= l >>> 3. >>> >>> Test ran on Fedora 20. >>> [will try this on freeBSD VM if you confirm that this is what you are >>> trying] >>> >>> >>> Could you verify if your second nc(server) instance is listening on the >>> same socket number? >>> >>> >>> -Kunal. >>> >>> >>> >>> On 1 December 2014 at 21:07, Karl Denninger wrote: >>> >>>> The second bind() call does fail but if the application ignores the >>>> return >>>> code...=E2=80=8E. Are you sure all the associated system call return c= odes are >>>> being checked? >>>> >>>> The right way to do this Imho is to have a parent process that calls >>>> bind >>>> and listen, gets the notification of an incoming connection via select= () >>>> (allowing detection of exceptions as well) and then calls accept() and= , >>>> now >>>> having a connected file handle, fork()s and executes whatever is to >>>> handle >>>> the connection with the parent closing the handle so as to not orphan >>>> the >>>> handle when the child exits. >>>> =E2=80=8E >>>> -- Karl >>>> (On Passport PDA)=E2=80=8E >>>> >>>> >>>> Original Message >>>> From: Yuri=E2=80=8E >>>> Sent: Monday, December 1, 2014 10:26 >>>> To: Daniel Corbe >>>> Cc: freebsd-net@freebsd.org >>>> Subject: Re: Can multiple apps listen for TCP on the same port? >>>> >>>> On 12/01/2014 07:02, Daniel Corbe wrote: >>>>> >>>>> Generally the answer to your question is no. Two applications cannot >>>>> occupy the same port on the same protocol at the same time. >>>>> >>>>> To expand on this answer and to hopefully shed some light on why the >>>>> behavior you're observing with your application is absolutely correct= ; >>>>> the calling application (in this case, nc) has to explicitly call >>>>> bind(2) >>>>> before it can begin accepting connections. If that port is already in >>>>> use then the call to bind(2) will fail. And in your case I suspect nc >>>>> is simply choosing to silently fail. >>>> >>>> >>>> Here the question is what does it mean "occupy the port"? The first >>>> instance isn't listening any more. The listening socket was closed. Wh= y >>>> the presence of the socket that was accepted from (now closed) listeni= ng >>>> socket in the first instance is considered "occupying it"? >>>> >>>> Actually no system call in the second instance ever fails. >>>> >>>> Yuri >>>> _______________________________________________ >>>> 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" >>>> >>>> >>>> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok >>>> >>>> >>>> _______________________________________________ >>>> 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" >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 01:32:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0601DB1 for ; Tue, 2 Dec 2014 01:32:57 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A15DA907 for ; Tue, 2 Dec 2014 01:32:57 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C871C20C58 for ; Mon, 1 Dec 2014 20:26:01 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute2.internal (MEProxy); Mon, 01 Dec 2014 20:26:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:x-sasl-enc:from:to :mime-version:content-transfer-encoding:content-type:in-reply-to :references:subject:date; s=smtpout; bh=dS15zMPDzy3xHLXYmI/44z7s fnQ=; b=JGJu7Khhwcf5JssxHz1Ehq8pcs0aSPObrQqEcR1KbS4eR2kCvEt3EtGA k2A94fgCjTqaE9YKc/nceHSMkKo9cdoo3jGwvRct6RmcHa948eZ1ZJogFQ5df8YB mQs1MSq4m7/1olfi4w81vsdMshsE9tkjBur+D8LXephltEP+yXQ= Received: by web3.nyi.internal (Postfix, from userid 99) id A81BA11C169; Mon, 1 Dec 2014 20:26:01 -0500 (EST) Message-Id: <1417483561.1888990.197595249.00741CC9@webmail.messagingengine.com> X-Sasl-Enc: 9E6QXzuatO6waLq/uuwWnpaxFOa2MJgXyOSiP56MWUKS 1417483561 From: Mark Felder To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-53201334 In-Reply-To: <20141130170029.GB1056@albert.catwhisker.org> References: <20141130010215.GP1228@albert.catwhisker.org> <547B081C.3000300@sunet.se> <20141130170029.GB1056@albert.catwhisker.org> Subject: Re: How do I use net-mgmt/unifi{2,3,4} for Ubiquity UAP-PRO? Date: Mon, 01 Dec 2014 19:26:01 -0600 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 01:32:57 -0000 Hi David, The port installs an rc script so you can automate launching the service. I've seen on some systems that it takes a very long time (15 minutes!) for the web interface to become accessible because java is stuck in some weird "gettimeofday()" loop. I haven't seen it with recent openjdk/unifi releases, though. Keep in mind that anything Ubiquiti claims to be stable is actually beta, beta is alpha, and alpha is likely to eat your children. I'd recommend sticking with Unifi 3.x for the time being. Good luck! From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 01:54:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C368A1F9 for ; Tue, 2 Dec 2014 01:54:52 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 759FAAF4 for ; Tue, 2 Dec 2014 01:54:52 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 6FBBA139CB for ; Mon, 1 Dec 2014 23:55:05 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1417485296; x=1418349297; bh=OjYUYL48N9cRrKoPiZXOkxIWYB+tyFpK+2j 7w4n7D9Y=; b=cTP5yNb5cAjhaYhjpj2PKEjLkG9H2jo5R9FauwVSG9bdmhRKNWh WC4TkkfQEpr5/MuN9bR/biOo1JlOFA3x0IE+WTqnpmtJGg2p0TjEsSryNfBfA07H thiC54T38gDcw9B1bojsStOfEwXpmEY9ASxyc3rZAyvoDYNxcBWPcmLM= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy7DXjzKjp0Q for ; Mon, 1 Dec 2014 23:54:56 -0200 (BRST) Received: from [192.168.10.208] (unknown [186.193.54.69]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 77CCA139CA for ; Mon, 1 Dec 2014 23:54:55 -0200 (BRST) Message-ID: <547D1BD7.90502@bsdinfo.com.br> Date: Mon, 01 Dec 2014 23:54:31 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> <547BB862.6080801@bsdinfo.com.br> <547CC35A.1080108@bsdinfo.com.br> <2A35EA60C3C77D438915767F458D65687E987C2A@ORSMSX111.amr.corp.intel.com> In-Reply-To: <2A35EA60C3C77D438915767F458D65687E987C2A@ORSMSX111.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 01:54:53 -0000 Hi Jeffrey, On 01/12/2014 19:29, Pieper, Jeffrey E wrote: > Hi Marcelo, > > A couple of questions - you are using 1310nm fiber on ix0, correct? The difference seems to be that ix0 is LR and ix1 is SR. Also, is there a reason that the interrupt rate is set higher for ix0? > > dev.ix.0.queue0.interrupt_rate: 50000 > dev.ix.1.queue0.interrupt_rate: 11627 Yep ix0 is LR because it is connected with a distant Operator and ix1 with another Operator in same room. I have two clear channels one in each 10GbE port. I try to do a manual balancing with BGP but still traffic on ix0 is slightly larger than the ix1. Maybe that's why this difference in dev.ix.0.queue0.interrupt_rate and dev.ix.1.queue0.interrupt_rate. My consumption of current band is 2.7Gbpsand I have 3Gbps downstream/upstream. > > Jeff > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Marcelo Gondim > Sent: Monday, December 01, 2014 11:37 AM > To: freebsd-net@freebsd.org > Subject: Re: Problems with Intel X520-SR2 > > On 30/11/2014 22:37, Marcelo Gondim wrote: >> Hi Jack, >> >> On 30/11/2014 16:20, Jack Vogel wrote: >>> Good suggestions, do you ever see any 'interrupt throttled' messages? >>> You >>> might >>> want to change the storm threshold to 0 and disable it. >> I can try this: >> >> sysctl hw.intr_storm_threshold=0 > Hi Jack, > > Same problem with hw.intr_storm_threshold=0 > I still think it might be something in my traffic that the driver is not > dealing properly. > > # netstat -idn > . > . > . > ix0 1500 00:1b:21:89:25:32 18446739080975184057 268 > 5876340155018 18446742570019979938 0 0 0 > ix0 - fe80::21b:21f fe80::21b:21ff:fe 0 - - > 1 - - - > ix1 1500 00:1b:21:89:25:33 18446730999135967066 0 > 13653533351669 18446742457148273271 0 0 0 > ix1 - fe80::21b:21f fe80::21b:21ff:fe 0 - - > 0 - - - > . > . > . > > Are 5876340155018 dropped packets in ix0 and 13653533351669 dropped > packets in ix1 > > # w -n > 5:35PM up 15 days, 20:29, 2 users, load averages: 8.96, 9.03, 8.84 > USER TTY FROM LOGIN@ IDLE WHAT > gondim pts/1 186.xxx.48.8 5:22PM - w -n > > >>> I too would like to know if there are any messages when the 'hang' >>> happens. >> Nope. No message. :( >> >>> I don't know much about lagg, is it responsible for link events?? Its >>> not a >>> normal >>> situation to be having so many :( >>> >>> Jack >>> >>> >>> On Sun, Nov 30, 2014 at 10:01 AM, Adrian Chadd >>> wrote: >>> >>>> Your link_irq value is way too high. I think you're exposing some >>>> unhandled corner case in the driver (as I had this issue when I had >>>> some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe >>>> driver isn't getting link events. >>>> >>>> My test setup at home has link_irq=1 on both sides, and it runs >>>> full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for >>>> RSS testing for weeks at a time. I have no issues and no hiccups. >>>> So, I think there's two problems: >>>> >>>> * you're still seeing way too many link_irq events; and >>>> * i think there's some bad handling when it comes to link_irq events. >>>> >>>> I wonder if we're still clearing some of the interrupt register bits >>>> incorrectly in ixgbe_msix_link(). >>>> >>>> >>>> -adrian >>>> >>>> >>>> >>>> >>>> -adrian >>>> >>>> >>>> On 30 November 2014 at 08:05, Alexander V. Chernikov >>>> wrote: >>>>> On 30.11.2014 18:47, Marcelo Gondim wrote: >>>>>> Dear, >>>>>> >>>>>> Unfortunately I have more options to resolve this problem I'm having >>>> with >>>>>> Intel X520-SR2. Have we changed the X520, we exchange the optical >>>>>> cords, >>>>>> exchanged optical modules, we changed the entire server, we reduce >>>>>> the >>>>>> temperature inside the equipment, made some attempts to tunning >>>>>> the site >>>>>> calomel[1]. We spend a lot of money and do not solve the problem. >>>>>> >>>>>> What happens is that when there is a traffic above 1.2Gbps with PPS >>>> above >>>>>> 700kpps in sometimes almost daily there is a lock in two 10GbE >>>>>> ports the >>>>>> X520-SR interface. Where I am obliged to leave a script running in >>>>>> the >>>>>> background doing just that: >>>>> What does this "lock" looks like? >>>>> Do you using jumbo frames? >>>>> Is this IPv4 or IPv4+IPv6 ? >>>>> Can you share "netstat -m" output? >>>>> Do you use ipfw dynamic states? >>>>> Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? >>>>> >>>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>>> >>>>> Looks suspicious. Either you're running out of mbufs due to total mbuf >>>>> number is small, or system is very busy sometimes. >>>>> What does you "top -HPSzs1" output look like? >>>>> >>>>> >>>>>> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig >>>>>> ix1 up >>>>>> >>>>>> Made it back to the interface function normally. It's already so for >>>>>> months and have not tried the latest driver from Intel because I >>>>>> do not >>>> see >>>>>> anything related to this issue. >>>>>> >>>>>> These 2-port 10GbE are my backbone linking the four cities that >>>>>> attend >>>> to >>>>>> our main router. One is backup to other but when the problem occurs, >>>> the two >>>>>> ports stop working and at the moment I have a break in my Internet >>>>>> >>>>>> I can only conclude that the problem is one of the things below: >>>>>> >>>>>> 1 - Intel Interface X520-SR2 has a problem with certain types of >>>>>> traffic >>>>>> and then hangs. >>>>>> 2 - The ixgbe driver has a bug that is causing it. >>>>>> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >>>>>> would be a regression and the equipment is very far away from me if I >>>> need >>>>>> to move me. >>>>>> >>>>>> Honestly I'm almost going on a Juniper closed solution. I would >>>>>> not want >>>>>> to do this because I love FreeBSD and I can not believe that he >>>>>> does not >>>>>> support a 2.7Gbps traffic, which is my peak traffic without getting >>>> having >>>>>> these falls. My hardware today is this: >>>>>> >>>>>> hw.machine: amd64 >>>>>> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>>>>> hw.ncpu: 12 >>>>>> hw.byteorder: 1234 >>>>>> hw.physmem: 17083641856 >>>>>> hw.usermem: 15741001728 >>>>>> >>>>>> Hardware all Intel with motherboard S2600COE [2] and with network >>>>>> interfaces offboard: >>>>>> >>>>>> 1x - X520-SR2 [3] >>>>>> 2x - I350-T2 [4] >>>>>> >>>>>> My loader.conf: >>>>>> >>>>>> loader_logo="beastie" >>>>>> if_lagg_load="YES" >>>>>> speaker_load="YES" >>>>>> aio_load="YES" >>>>>> autoboot_delay="5" >>>>>> net.fibs=1 >>>>>> >>>>>> My sysctl.conf: >>>>>> >>>>>> net.inet.ip.forwarding=1 >>>>>> net.inet.ip.fastforwarding=1 >>>>>> net.inet6.ip6.forwarding=1 >>>>>> kern.ipc.somaxconn=4096 >>>>>> net.inet.tcp.syncookies=1 >>>>>> net.inet.ip.redirect=1 >>>>>> net.inet.ip.accept_sourceroute=0 >>>>>> net.inet.ip.sourceroute=0 >>>>>> net.inet.tcp.drop_synfin=1 >>>>>> net.inet.udp.blackhole=1 >>>>>> net.inet.tcp.blackhole=2 >>>>>> security.bsd.see_other_uids=0 >>>>>> net.inet.ip.fw.dyn_buckets=65536 >>>>>> net.inet.ip.fw.dyn_max=65536 >>>>>> hw.intr_storm_threshold=9000 >>>>>> net.inet.ip.dummynet.pipe_slot_limit=800 >>>>>> net.inet.icmp.icmplim=2000 >>>>>> >>>>>> # sysctl dev.ix. >>>>>> dev.ix.%parent: >>>>>> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >>>>>> Version - >>>>>> 2.5.15 >>>>>> dev.ix.0.%driver: ix >>>>>> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >>>>>> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>>>> subdevice=0x7a11 class=0x020000 >>>>>> dev.ix.0.%parent: pci129 >>>>>> dev.ix.0.fc: 3 >>>>>> dev.ix.0.enable_aim: 1 >>>>>> dev.ix.0.advertise_speed: 0 >>>>>> dev.ix.0.dropped: 0 >>>>>> dev.ix.0.mbuf_defrag_failed: 0 >>>>>> dev.ix.0.watchdog_events: 0 >>>>>> dev.ix.0.link_irq: 193783 >>>>>> dev.ix.0.queue0.interrupt_rate: 50000 >>>>>> dev.ix.0.queue0.irqs: 12029604413 >>>>>> dev.ix.0.queue0.txd_head: 1517 >>>>>> dev.ix.0.queue0.txd_tail: 1517 >>>>>> dev.ix.0.queue0.tso_tx: 85 >>>>>> dev.ix.0.queue0.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>>>> dev.ix.0.queue0.tx_packets: 15392658033 >>>>>> dev.ix.0.queue0.rxd_head: 709 >>>>>> dev.ix.0.queue0.rxd_tail: 707 >>>>>> dev.ix.0.queue0.rx_packets: 21762427837 >>>>>> dev.ix.0.queue0.rx_bytes: 56918345381 >>>>>> dev.ix.0.queue0.rx_copies: 124289013 >>>>>> dev.ix.0.queue0.lro_queued: 0 >>>>>> dev.ix.0.queue0.lro_flushed: 0 >>>>>> dev.ix.0.queue1.interrupt_rate: 500000 >>>>>> dev.ix.0.queue1.irqs: 11482146431 >>>>>> dev.ix.0.queue1.txd_head: 731 >>>>>> dev.ix.0.queue1.txd_tail: 731 >>>>>> dev.ix.0.queue1.tso_tx: 1442 >>>>>> dev.ix.0.queue1.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>>>> dev.ix.0.queue1.tx_packets: 15835062632 >>>>>> dev.ix.0.queue1.rxd_head: 685 >>>>>> dev.ix.0.queue1.rxd_tail: 681 >>>>>> dev.ix.0.queue1.rx_packets: 21220715209 >>>>>> dev.ix.0.queue1.rx_bytes: 54351679461 >>>>>> dev.ix.0.queue1.rx_copies: 120833356 >>>>>> dev.ix.0.queue1.lro_queued: 0 >>>>>> dev.ix.0.queue1.lro_flushed: 0 >>>>>> dev.ix.0.queue2.interrupt_rate: 5319 >>>>>> dev.ix.0.queue2.irqs: 11532560324 >>>>>> dev.ix.0.queue2.txd_head: 501 >>>>>> dev.ix.0.queue2.txd_tail: 501 >>>>>> dev.ix.0.queue2.tso_tx: 2474 >>>>>> dev.ix.0.queue2.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue2.no_desc_avail: 429244 >>>>>> dev.ix.0.queue2.tx_packets: 15772209238 >>>>>> dev.ix.0.queue2.rxd_head: 246 >>>>>> dev.ix.0.queue2.rxd_tail: 244 >>>>>> dev.ix.0.queue2.rx_packets: 21408648299 >>>>>> dev.ix.0.queue2.rx_bytes: 56862350194 >>>>>> dev.ix.0.queue2.rx_copies: 124973551 >>>>>> dev.ix.0.queue2.lro_queued: 0 >>>>>> dev.ix.0.queue2.lro_flushed: 0 >>>>>> dev.ix.0.queue3.interrupt_rate: 20833 >>>>>> dev.ix.0.queue3.irqs: 11557466322 >>>>>> dev.ix.0.queue3.txd_head: 773 >>>>>> dev.ix.0.queue3.txd_tail: 773 >>>>>> dev.ix.0.queue3.tso_tx: 40 >>>>>> dev.ix.0.queue3.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue3.no_desc_avail: 665620 >>>>>> dev.ix.0.queue3.tx_packets: 16479111658 >>>>>> dev.ix.0.queue3.rxd_head: 1858 >>>>>> dev.ix.0.queue3.rxd_tail: 1854 >>>>>> dev.ix.0.queue3.rx_packets: 21412821769 >>>>>> dev.ix.0.queue3.rx_bytes: 52796089467 >>>>>> dev.ix.0.queue3.rx_copies: 127385950 >>>>>> dev.ix.0.queue3.lro_queued: 0 >>>>>> dev.ix.0.queue3.lro_flushed: 0 >>>>>> dev.ix.0.queue4.interrupt_rate: 11363 >>>>>> dev.ix.0.queue4.irqs: 10824852635 >>>>>> dev.ix.0.queue4.txd_head: 1711 >>>>>> dev.ix.0.queue4.txd_tail: 1713 >>>>>> dev.ix.0.queue4.tso_tx: 581 >>>>>> dev.ix.0.queue4.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue4.no_desc_avail: 115346803 >>>>>> dev.ix.0.queue4.tx_packets: 16100396810 >>>>>> dev.ix.0.queue4.rxd_head: 244 >>>>>> dev.ix.0.queue4.rxd_tail: 243 >>>>>> dev.ix.0.queue4.rx_packets: 21240995210 >>>>>> dev.ix.0.queue4.rx_bytes: 58726730771 >>>>>> dev.ix.0.queue4.rx_copies: 124872141 >>>>>> dev.ix.0.queue4.lro_queued: 0 >>>>>> dev.ix.0.queue4.lro_flushed: 0 >>>>>> dev.ix.0.queue5.interrupt_rate: 500000 >>>>>> dev.ix.0.queue5.irqs: 10955464761 >>>>>> dev.ix.0.queue5.txd_head: 75 >>>>>> dev.ix.0.queue5.txd_tail: 77 >>>>>> dev.ix.0.queue5.tso_tx: 1758 >>>>>> dev.ix.0.queue5.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue5.no_desc_avail: 4759 >>>>>> dev.ix.0.queue5.tx_packets: 16267888038 >>>>>> dev.ix.0.queue5.rxd_head: 905 >>>>>> dev.ix.0.queue5.rxd_tail: 904 >>>>>> dev.ix.0.queue5.rx_packets: 21381144028 >>>>>> dev.ix.0.queue5.rx_bytes: 61800291690 >>>>>> dev.ix.0.queue5.rx_copies: 129684798 >>>>>> dev.ix.0.queue5.lro_queued: 0 >>>>>> dev.ix.0.queue5.lro_flushed: 0 >>>>>> dev.ix.0.queue6.interrupt_rate: 33333 >>>>>> dev.ix.0.queue6.irqs: 11081350674 >>>>>> dev.ix.0.queue6.txd_head: 1744 >>>>>> dev.ix.0.queue6.txd_tail: 1746 >>>>>> dev.ix.0.queue6.tso_tx: 38 >>>>>> dev.ix.0.queue6.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue6.no_desc_avail: 18381 >>>>>> dev.ix.0.queue6.tx_packets: 15376961749 >>>>>> dev.ix.0.queue6.rxd_head: 1783 >>>>>> dev.ix.0.queue6.rxd_tail: 1782 >>>>>> dev.ix.0.queue6.rx_packets: 21381814216 >>>>>> dev.ix.0.queue6.rx_bytes: 56828960117 >>>>>> dev.ix.0.queue6.rx_copies: 130194429 >>>>>> dev.ix.0.queue6.lro_queued: 0 >>>>>> dev.ix.0.queue6.lro_flushed: 0 >>>>>> dev.ix.0.queue7.interrupt_rate: 5319 >>>>>> dev.ix.0.queue7.irqs: 11014043865 >>>>>> dev.ix.0.queue7.txd_head: 1545 >>>>>> dev.ix.0.queue7.txd_tail: 1545 >>>>>> dev.ix.0.queue7.tso_tx: 59 >>>>>> dev.ix.0.queue7.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue7.no_desc_avail: 5497 >>>>>> dev.ix.0.queue7.tx_packets: 15283534142 >>>>>> dev.ix.0.queue7.rxd_head: 184 >>>>>> dev.ix.0.queue7.rxd_tail: 182 >>>>>> dev.ix.0.queue7.rx_packets: 21431994087 >>>>>> dev.ix.0.queue7.rx_bytes: 57942270182 >>>>>> dev.ix.0.queue7.rx_copies: 128363306 >>>>>> dev.ix.0.queue7.lro_queued: 0 >>>>>> dev.ix.0.queue7.lro_flushed: 0 >>>>>> dev.ix.0.mac_stats.crc_errs: 268 >>>>>> dev.ix.0.mac_stats.ill_errs: 33 >>>>>> dev.ix.0.mac_stats.byte_errs: 55 >>>>>> dev.ix.0.mac_stats.short_discards: 0 >>>>>> dev.ix.0.mac_stats.local_faults: 3484 >>>>>> dev.ix.0.mac_stats.remote_faults: 121 >>>>>> dev.ix.0.mac_stats.rec_len_errs: 0 >>>>>> dev.ix.0.mac_stats.xon_txd: 1602713563748 >>>>>> dev.ix.0.mac_stats.xon_recvd: 0 >>>>>> dev.ix.0.mac_stats.xoff_txd: 108342810167 >>>>>> dev.ix.0.mac_stats.xoff_recvd: 0 >>>>>> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >>>>>> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >>>>>> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >>>>>> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >>>>>> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >>>>>> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >>>>>> dev.ix.0.mac_stats.rx_frames_64: 5356098 >>>>>> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >>>>>> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >>>>>> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >>>>>> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >>>>>> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >>>>>> dev.ix.0.mac_stats.recv_undersized: 0 >>>>>> dev.ix.0.mac_stats.recv_fragmented: 0 >>>>>> dev.ix.0.mac_stats.recv_oversized: 244078 >>>>>> dev.ix.0.mac_stats.recv_jabberd: 4 >>>>>> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >>>>>> dev.ix.0.mac_stats.management_pkts_drpd: 0 >>>>>> dev.ix.0.mac_stats.checksum_errs: 897344641 >>>>>> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >>>>>> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >>>>>> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >>>>>> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >>>>>> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >>>>>> dev.ix.0.mac_stats.management_pkts_txd: 0 >>>>>> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >>>>>> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >>>>>> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >>>>>> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >>>>>> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >>>>>> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >>>>>> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >>>>>> Version - >>>>>> 2.5.15 >>>>>> dev.ix.1.%driver: ix >>>>>> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >>>>>> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>>>> subdevice=0x7a11 class=0x020000 >>>>>> dev.ix.1.%parent: pci129 >>>>>> dev.ix.1.fc: 3 >>>>>> dev.ix.1.enable_aim: 1 >>>>>> dev.ix.1.advertise_speed: 0 >>>>>> dev.ix.1.dropped: 0 >>>>>> dev.ix.1.mbuf_defrag_failed: 0 >>>>>> dev.ix.1.watchdog_events: 0 >>>>>> dev.ix.1.link_irq: 127925 >>>>>> dev.ix.1.queue0.interrupt_rate: 11627 >>>>>> dev.ix.1.queue0.irqs: 6686088831 >>>>>> dev.ix.1.queue0.txd_head: 1618 >>>>>> dev.ix.1.queue0.txd_tail: 1620 >>>>>> dev.ix.1.queue0.tso_tx: 28 >>>>>> dev.ix.1.queue0.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue0.no_desc_avail: 0 >>>>>> dev.ix.1.queue0.tx_packets: 13527334563 >>>>>> dev.ix.1.queue0.rxd_head: 1715 >>>>>> dev.ix.1.queue0.rxd_tail: 1714 >>>>>> dev.ix.1.queue0.rx_packets: 1503775702 >>>>>> dev.ix.1.queue0.rx_bytes: 1069295301 >>>>>> dev.ix.1.queue0.rx_copies: 2983480 >>>>>> dev.ix.1.queue0.lro_queued: 0 >>>>>> dev.ix.1.queue0.lro_flushed: 0 >>>>>> dev.ix.1.queue1.interrupt_rate: 5319 >>>>>> dev.ix.1.queue1.irqs: 6546967336 >>>>>> dev.ix.1.queue1.txd_head: 1812 >>>>>> dev.ix.1.queue1.txd_tail: 1812 >>>>>> dev.ix.1.queue1.tso_tx: 6 >>>>>> dev.ix.1.queue1.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue1.no_desc_avail: 0 >>>>>> dev.ix.1.queue1.tx_packets: 13475453794 >>>>>> dev.ix.1.queue1.rxd_head: 1246 >>>>>> dev.ix.1.queue1.rxd_tail: 1245 >>>>>> dev.ix.1.queue1.rx_packets: 1506444917 >>>>>> dev.ix.1.queue1.rx_bytes: 783064190 >>>>>> dev.ix.1.queue1.rx_copies: 2881513 >>>>>> dev.ix.1.queue1.lro_queued: 0 >>>>>> dev.ix.1.queue1.lro_flushed: 0 >>>>>> dev.ix.1.queue2.interrupt_rate: 5319 >>>>>> dev.ix.1.queue2.irqs: 6574615190 >>>>>> dev.ix.1.queue2.txd_head: 1494 >>>>>> dev.ix.1.queue2.txd_tail: 1494 >>>>>> dev.ix.1.queue2.tso_tx: 33 >>>>>> dev.ix.1.queue2.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue2.no_desc_avail: 0 >>>>>> dev.ix.1.queue2.tx_packets: 13555495169 >>>>>> dev.ix.1.queue2.rxd_head: 438 >>>>>> dev.ix.1.queue2.rxd_tail: 437 >>>>>> dev.ix.1.queue2.rx_packets: 1501380848 >>>>>> dev.ix.1.queue2.rx_bytes: 1008544082 >>>>>> dev.ix.1.queue2.rx_copies: 2660960 >>>>>> dev.ix.1.queue2.lro_queued: 0 >>>>>> dev.ix.1.queue2.lro_flushed: 0 >>>>>> dev.ix.1.queue3.interrupt_rate: 5319 >>>>>> dev.ix.1.queue3.irqs: 6617964401 >>>>>> dev.ix.1.queue3.txd_head: 1853 >>>>>> dev.ix.1.queue3.txd_tail: 1855 >>>>>> dev.ix.1.queue3.tso_tx: 10 >>>>>> dev.ix.1.queue3.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue3.no_desc_avail: 0 >>>>>> dev.ix.1.queue3.tx_packets: 13561212942 >>>>>> dev.ix.1.queue3.rxd_head: 429 >>>>>> dev.ix.1.queue3.rxd_tail: 428 >>>>>> dev.ix.1.queue3.rx_packets: 1498117903 >>>>>> dev.ix.1.queue3.rx_bytes: 784881986 >>>>>> dev.ix.1.queue3.rx_copies: 2695475 >>>>>> dev.ix.1.queue3.lro_queued: 0 >>>>>> dev.ix.1.queue3.lro_flushed: 0 >>>>>> dev.ix.1.queue4.interrupt_rate: 5319 >>>>>> dev.ix.1.queue4.irqs: 6575752163 >>>>>> dev.ix.1.queue4.txd_head: 902 >>>>>> dev.ix.1.queue4.txd_tail: 902 >>>>>> dev.ix.1.queue4.tso_tx: 5 >>>>>> dev.ix.1.queue4.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue4.no_desc_avail: 0 >>>>>> dev.ix.1.queue4.tx_packets: 13478514009 >>>>>> dev.ix.1.queue4.rxd_head: 536 >>>>>> dev.ix.1.queue4.rxd_tail: 535 >>>>>> dev.ix.1.queue4.rx_packets: 1476720084 >>>>>> dev.ix.1.queue4.rx_bytes: 944967171 >>>>>> dev.ix.1.queue4.rx_copies: 2650672 >>>>>> dev.ix.1.queue4.lro_queued: 0 >>>>>> dev.ix.1.queue4.lro_flushed: 0 >>>>>> dev.ix.1.queue5.interrupt_rate: 10416 >>>>>> dev.ix.1.queue5.irqs: 6578099670 >>>>>> dev.ix.1.queue5.txd_head: 1996 >>>>>> dev.ix.1.queue5.txd_tail: 1996 >>>>>> dev.ix.1.queue5.tso_tx: 663 >>>>>> dev.ix.1.queue5.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue5.no_desc_avail: 0 >>>>>> dev.ix.1.queue5.tx_packets: 13516483196 >>>>>> dev.ix.1.queue5.rxd_head: 1296 >>>>>> dev.ix.1.queue5.rxd_tail: 1295 >>>>>> dev.ix.1.queue5.rx_packets: 1496584151 >>>>>> dev.ix.1.queue5.rx_bytes: 810434347 >>>>>> dev.ix.1.queue5.rx_copies: 2899315 >>>>>> dev.ix.1.queue5.lro_queued: 0 >>>>>> dev.ix.1.queue5.lro_flushed: 0 >>>>>> dev.ix.1.queue6.interrupt_rate: 5319 >>>>>> dev.ix.1.queue6.irqs: 6624395782 >>>>>> dev.ix.1.queue6.txd_head: 1058 >>>>>> dev.ix.1.queue6.txd_tail: 1058 >>>>>> dev.ix.1.queue6.tso_tx: 20 >>>>>> dev.ix.1.queue6.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue6.no_desc_avail: 0 >>>>>> dev.ix.1.queue6.tx_packets: 13491315217 >>>>>> dev.ix.1.queue6.rxd_head: 1550 >>>>>> dev.ix.1.queue6.rxd_tail: 1549 >>>>>> dev.ix.1.queue6.rx_packets: 1510907490 >>>>>> dev.ix.1.queue6.rx_bytes: 719914325 >>>>>> dev.ix.1.queue6.rx_copies: 2712955 >>>>>> dev.ix.1.queue6.lro_queued: 0 >>>>>> dev.ix.1.queue6.lro_flushed: 0 >>>>>> dev.ix.1.queue7.interrupt_rate: 29411 >>>>>> dev.ix.1.queue7.irqs: 6573304834 >>>>>> dev.ix.1.queue7.txd_head: 784 >>>>>> dev.ix.1.queue7.txd_tail: 786 >>>>>> dev.ix.1.queue7.tso_tx: 2 >>>>>> dev.ix.1.queue7.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue7.no_desc_avail: 0 >>>>>> dev.ix.1.queue7.tx_packets: 13587681458 >>>>>> dev.ix.1.queue7.rxd_head: 1489 >>>>>> dev.ix.1.queue7.rxd_tail: 1488 >>>>>> dev.ix.1.queue7.rx_packets: 1504712031 >>>>>> dev.ix.1.queue7.rx_bytes: 1216803328 >>>>>> dev.ix.1.queue7.rx_copies: 2976103 >>>>>> dev.ix.1.queue7.lro_queued: 0 >>>>>> dev.ix.1.queue7.lro_flushed: 0 >>>>>> dev.ix.1.mac_stats.crc_errs: 0 >>>>>> dev.ix.1.mac_stats.ill_errs: 0 >>>>>> dev.ix.1.mac_stats.byte_errs: 0 >>>>>> dev.ix.1.mac_stats.short_discards: 0 >>>>>> dev.ix.1.mac_stats.local_faults: 0 >>>>>> dev.ix.1.mac_stats.remote_faults: 12 >>>>>> dev.ix.1.mac_stats.rec_len_errs: 0 >>>>>> dev.ix.1.mac_stats.xon_txd: 1714791401322 >>>>>> dev.ix.1.mac_stats.xon_recvd: 0 >>>>>> dev.ix.1.mac_stats.xoff_txd: 41095995010 >>>>>> dev.ix.1.mac_stats.xoff_recvd: 0 >>>>>> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >>>>>> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >>>>>> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >>>>>> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >>>>>> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >>>>>> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >>>>>> dev.ix.1.mac_stats.rx_frames_64: 73447 >>>>>> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >>>>>> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >>>>>> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >>>>>> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >>>>>> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >>>>>> dev.ix.1.mac_stats.recv_undersized: 0 >>>>>> dev.ix.1.mac_stats.recv_fragmented: 0 >>>>>> dev.ix.1.mac_stats.recv_oversized: 0 >>>>>> dev.ix.1.mac_stats.recv_jabberd: 0 >>>>>> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >>>>>> dev.ix.1.mac_stats.management_pkts_drpd: 0 >>>>>> dev.ix.1.mac_stats.checksum_errs: 85432477 >>>>>> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >>>>>> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >>>>>> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >>>>>> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >>>>>> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >>>>>> dev.ix.1.mac_stats.management_pkts_txd: 0 >>>>>> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >>>>>> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >>>>>> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >>>>>> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >>>>>> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >>>>>> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >>>>>> >>>>>> # cat /var/run/dmesg.boot >>>>>> >>>>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, >>>>>> 1993, 1994 >>>>>> The Regents of the University of California. All rights >>>> reserved. >>>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>>> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >>>>>> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >>>>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) >>>>>> 20140512 >>>>>> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class >>>> CPU) >>>>>> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >>>>>> Stepping = 4 >>>>>> >>>>>> >>>> Features=0xbfebfbff >>>> >>>> Features2=0x7fbee3ff >>>> >>>>>> AMD Features=0x2c100800 >>>>>> AMD Features2=0x1 >>>>>> Structured Extended Features=0x281 >>>>>> VT-x: (disabled in BIOS) >>>>>> PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >>>>>> TSC: P-state invariant, performance statistics >>>>>> real memory = 17179869184 (16384 MB) >>>>>> avail memory = 16515358720 (15750 MB) >>>>>> Event timer "LAPIC" quality 600 >>>>>> ACPI APIC Table: >>>>>> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >>>>>> FreeBSD/SMP: 2 package(s) x 6 core(s) >>>>>> cpu0 (BSP): APIC ID: 0 >>>>>> cpu1 (AP): APIC ID: 2 >>>>>> cpu2 (AP): APIC ID: 4 >>>>>> cpu3 (AP): APIC ID: 6 >>>>>> cpu4 (AP): APIC ID: 8 >>>>>> cpu5 (AP): APIC ID: 10 >>>>>> cpu6 (AP): APIC ID: 32 >>>>>> cpu7 (AP): APIC ID: 34 >>>>>> cpu8 (AP): APIC ID: 36 >>>>>> cpu9 (AP): APIC ID: 38 >>>>>> cpu10 (AP): APIC ID: 40 >>>>>> cpu11 (AP): APIC ID: 42 >>>>>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: >>>>>> 32, >>>>>> using default 16 (20130823/tbfadt-682) >>>>>> ioapic0 irqs 0-23 on motherboard >>>>>> ioapic1 irqs 24-47 on motherboard >>>>>> ioapic2 irqs 48-71 on motherboard >>>>>> kbd1 at kbdmux0 >>>>>> random: initialized >>>>>> cryptosoft0: on motherboard >>>>>> acpi0: on motherboard >>>>>> acpi0: Power Button (fixed) >>>>>> acpi0: reservation of 0, 9d000 (3) failed >>>>>> cpu0: on acpi0 >>>>>> cpu1: on acpi0 >>>>>> cpu2: on acpi0 >>>>>> cpu3: on acpi0 >>>>>> cpu4: on acpi0 >>>>>> cpu5: on acpi0 >>>>>> cpu6: on acpi0 >>>>>> cpu7: on acpi0 >>>>>> cpu8: on acpi0 >>>>>> cpu9: on acpi0 >>>>>> cpu10: on acpi0 >>>>>> cpu11: on acpi0 >>>>>> hpet0: iomem 0xfed00000-0xfed003ff on >>>>>> acpi0 >>>>>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>>>>> Event timer "HPET" frequency 14318180 Hz quality 350 >>>>>> Event timer "HPET1" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET2" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET3" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET4" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET5" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET6" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET7" frequency 14318180 Hz quality 340 >>>>>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>>>>> atrtc0: Warning: Couldn't map I/O. >>>>>> Event timer "RTC" frequency 32768 Hz quality 0 >>>>>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>>> Event timer "i8254" frequency 1193182 Hz quality 100 >>>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>>>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>>> pci0: on pcib0 >>>>>> pcib1: irq 47 at device 1.0 on pci0 >>>>>> pci1: on pcib1 >>>>>> pcib2: irq 47 at device 1.1 on pci0 >>>>>> pci2: on pcib2 >>>>>> igb0: port >>>>>> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq >>>>>> 27 at >>>>>> device 0.0 on pci2 >>>>>> igb0: Using MSIX interrupts with 9 vectors >>>>>> igb0: Ethernet address: 00:1e:67:9a:d5:88 >>>>>> 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 >>>>>> igb0: Bound queue 4 to cpu 4 >>>>>> igb0: Bound queue 5 to cpu 5 >>>>>> igb0: Bound queue 6 to cpu 6 >>>>>> igb0: Bound queue 7 to cpu 7 >>>>>> igb1: port >>>>>> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq >>>>>> 30 at >>>>>> device 0.1 on pci2 >>>>>> igb1: Using MSIX interrupts with 9 vectors >>>>>> igb1: Ethernet address: 00:1e:67:9a:d5:89 >>>>>> igb1: Bound queue 0 to cpu 8 >>>>>> igb1: Bound queue 1 to cpu 9 >>>>>> igb1: Bound queue 2 to cpu 10 >>>>>> igb1: Bound queue 3 to cpu 11 >>>>>> igb1: Bound queue 4 to cpu 0 >>>>>> igb1: Bound queue 5 to cpu 1 >>>>>> igb1: Bound queue 6 to cpu 2 >>>>>> igb1: Bound queue 7 to cpu 3 >>>>>> igb2: port >>>>>> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq >>>>>> 28 at >>>>>> device 0.2 on pci2 >>>>>> igb2: Using MSIX interrupts with 9 vectors >>>>>> igb2: Ethernet address: 00:1e:67:9a:d5:8a >>>>>> igb2: Bound queue 0 to cpu 4 >>>>>> igb2: Bound queue 1 to cpu 5 >>>>>> igb2: Bound queue 2 to cpu 6 >>>>>> igb2: Bound queue 3 to cpu 7 >>>>>> igb2: Bound queue 4 to cpu 8 >>>>>> igb2: Bound queue 5 to cpu 9 >>>>>> igb2: Bound queue 6 to cpu 10 >>>>>> igb2: Bound queue 7 to cpu 11 >>>>>> igb3: port >>>>>> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq >>>>>> 29 at >>>>>> device 0.3 on pci2 >>>>>> igb3: Using MSIX interrupts with 9 vectors >>>>>> igb3: Ethernet address: 00:1e:67:9a:d5:8b >>>>>> igb3: Bound queue 0 to cpu 0 >>>>>> igb3: Bound queue 1 to cpu 1 >>>>>> igb3: Bound queue 2 to cpu 2 >>>>>> igb3: Bound queue 3 to cpu 3 >>>>>> igb3: Bound queue 4 to cpu 4 >>>>>> igb3: Bound queue 5 to cpu 5 >>>>>> igb3: Bound queue 6 to cpu 6 >>>>>> igb3: Bound queue 7 to cpu 7 >>>>>> pcib3: irq 47 at device 2.0 on pci0 >>>>>> pci4: on pcib3 >>>>>> igb4: mem >>>>>> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 >>>>>> on pci4 >>>>>> igb4: Using MSIX interrupts with 9 vectors >>>>>> igb4: Ethernet address: a0:36:9f:37:82:7e >>>>>> igb4: Bound queue 0 to cpu 8 >>>>>> igb4: Bound queue 1 to cpu 9 >>>>>> igb4: Bound queue 2 to cpu 10 >>>>>> igb4: Bound queue 3 to cpu 11 >>>>>> igb4: Bound queue 4 to cpu 0 >>>>>> igb4: Bound queue 5 to cpu 1 >>>>>> igb4: Bound queue 6 to cpu 2 >>>>>> igb4: Bound queue 7 to cpu 3 >>>>>> igb5: mem >>>>>> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 >>>>>> on pci4 >>>>>> igb5: Using MSIX interrupts with 9 vectors >>>>>> igb5: Ethernet address: a0:36:9f:37:82:7f >>>>>> igb5: Bound queue 0 to cpu 4 >>>>>> igb5: Bound queue 1 to cpu 5 >>>>>> igb5: Bound queue 2 to cpu 6 >>>>>> igb5: Bound queue 3 to cpu 7 >>>>>> igb5: Bound queue 4 to cpu 8 >>>>>> igb5: Bound queue 5 to cpu 9 >>>>>> igb5: Bound queue 6 to cpu 10 >>>>>> igb5: Bound queue 7 to cpu 11 >>>>>> pcib4: irq 16 at device 3.0 on pci0 >>>>>> pci6: on pcib4 >>>>>> igb6: mem >>>>>> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 >>>>>> on pci6 >>>>>> igb6: Using MSIX interrupts with 9 vectors >>>>>> igb6: Ethernet address: a0:36:9f:37:82:8a >>>>>> igb6: Bound queue 0 to cpu 0 >>>>>> igb6: Bound queue 1 to cpu 1 >>>>>> igb6: Bound queue 2 to cpu 2 >>>>>> igb6: Bound queue 3 to cpu 3 >>>>>> igb6: Bound queue 4 to cpu 4 >>>>>> igb6: Bound queue 5 to cpu 5 >>>>>> igb6: Bound queue 6 to cpu 6 >>>>>> igb6: Bound queue 7 to cpu 7 >>>>>> igb7: mem >>>>>> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 >>>>>> on pci6 >>>>>> igb7: Using MSIX interrupts with 9 vectors >>>>>> igb7: Ethernet address: a0:36:9f:37:82:8b >>>>>> igb7: Bound queue 0 to cpu 8 >>>>>> igb7: Bound queue 1 to cpu 9 >>>>>> igb7: Bound queue 2 to cpu 10 >>>>>> igb7: Bound queue 3 to cpu 11 >>>>>> igb7: Bound queue 4 to cpu 0 >>>>>> igb7: Bound queue 5 to cpu 1 >>>>>> igb7: Bound queue 6 to cpu 2 >>>>>> igb7: Bound queue 7 to cpu 3 >>>>>> pcib5: irq 16 at device 17.0 on pci0 >>>>>> pci8: on pcib5 >>>>>> pci0: at device 22.0 (no driver attached) >>>>>> pci0: at device 22.1 (no driver attached) >>>>>> ehci0: mem >>>>>> 0xd1220000-0xd12203ff irq >>>>>> 22 at device 26.0 on pci0 >>>>>> usbus0: EHCI version 1.0 >>>>>> usbus0 on ehci0 >>>>>> pcib6: irq 16 at device 28.0 on pci0 >>>>>> pci9: on pcib6 >>>>>> pcib7: irq 17 at device 28.5 on pci0 >>>>>> pci10: on pcib7 >>>>>> pci10: at device 0.0 (no driver attached) >>>>>> pcib8: irq 19 at device 28.7 on pci0 >>>>>> pci11: on pcib8 >>>>>> vgapci0: mem >>>>>> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq >>>> 19 at >>>>>> device 0.0 on pci11 >>>>>> vgapci0: Boot video device >>>>>> ehci1: mem >>>>>> 0xd1210000-0xd12103ff irq >>>>>> 20 at device 29.0 on pci0 >>>>>> usbus1: EHCI version 1.0 >>>>>> usbus1 on ehci1 >>>>>> pcib9: at device 30.0 on pci0 >>>>>> pci12: on pcib9 >>>>>> isab0: at device 31.0 on pci0 >>>>>> isa0: on isab0 >>>>>> ahci0: port >>>>>> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f >>>> mem >>>>>> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >>>>>> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >>>>>> ahcich0: at channel 0 on ahci0 >>>>>> ahcich1: at channel 1 on ahci0 >>>>>> ahcich2: at channel 2 on ahci0 >>>>>> ahcich3: at channel 3 on ahci0 >>>>>> ahcich4: at channel 4 on ahci0 >>>>>> ahcich5: at channel 5 on ahci0 >>>>>> ahciem0: on ahci0 >>>>>> pcib10: on acpi0 >>>>>> pci128: on pcib10 >>>>>> pcib11: irq 71 at device 1.0 on pci128 >>>>>> pci129: on pcib11 >>>>>> ix0: >>>>> 2.5.15> >>>>>> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff >>>>>> irq >>>> 50 at >>>>>> device 0.0 on pci129 >>>>>> ix0: Using MSIX interrupts with 9 vectors >>>>>> ix0: Ethernet address: 00:1b:21:89:25:32 >>>>>> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>>> ix1: >>>>> 2.5.15> >>>>>> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff >>>>>> irq >>>> 52 at >>>>>> device 0.1 on pci129 >>>>>> ix1: Using MSIX interrupts with 9 vectors >>>>>> ix1: Ethernet address: 00:1b:21:89:25:33 >>>>>> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>>> pcib12: irq 71 at device 2.0 on pci128 >>>>>> pci131: on pcib12 >>>>>> pcib13: irq 71 at device 3.0 on pci128 >>>>>> pci132: on pcib13 >>>>>> acpi_button0: on acpi0 >>>>>> pcib14: on acpi0 >>>>>> pci127: on pcib14 >>>>>> pcib15: on acpi0 >>>>>> pci255: on pcib15 >>>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on >>>>>> acpi0 >>>>>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>>>>> orm0: at iomem >>>>>> >>>> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >>>> >>>>>> on isa0 >>>>>> sc0: at flags 0x100 on isa0 >>>>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>>> isa0 >>>>>> est0: on cpu0 >>>>>> p4tcc0: on cpu0 >>>>>> est1: on cpu1 >>>>>> p4tcc1: on cpu1 >>>>>> est2: on cpu2 >>>>>> p4tcc2: on cpu2 >>>>>> est3: on cpu3 >>>>>> p4tcc3: on cpu3 >>>>>> est4: on cpu4 >>>>>> p4tcc4: on cpu4 >>>>>> est5: on cpu5 >>>>>> p4tcc5: on cpu5 >>>>>> est6: on cpu6 >>>>>> p4tcc6: on cpu6 >>>>>> est7: on cpu7 >>>>>> p4tcc7: on cpu7 >>>>>> est8: on cpu8 >>>>>> p4tcc8: on cpu8 >>>>>> est9: on cpu9 >>>>>> p4tcc9: on cpu9 >>>>>> est10: on cpu10 >>>>>> p4tcc10: on cpu10 >>>>>> est11: on cpu11 >>>>>> p4tcc11: on cpu11 >>>>>> random: unblocking device. >>>>>> usbus0: 480Mbps High Speed USB v2.0 >>>>>> Timecounters tick every 1.000 msec >>>>>> IPsec: Initialized Security Association Processing. >>>>>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >>>> accept, >>>>>> logging disabled >>>>>> usbus1: 480Mbps High Speed USB v2.0 >>>>>> ugen1.1: at usbus1 >>>>>> uhub0: on >>>>>> usbus1 >>>>>> ugen0.1: at usbus0 >>>>>> uhub1: on >>>>>> usbus0 >>>>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>>>> ada0: ATA-9 SATA 3.x device >>>>>> ada0: Serial Number S1D5NSAF687077K >>>>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) >>>>>> ada0: Command Queueing enabled >>>>>> ada0: 114473MB (234441648 512 byte sectors: 16H 63S/T 16383C) >>>>>> ada0: quirks=0x1<4K> >>>>>> ada0: Previously was known as ad4 >>>>>> ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 >>>>>> ses0: SEMB S-E-S 2.00 device >>>>>> ses0: SEMB SES Device >>>>>> SMP: AP CPU #6 Launched! >>>>>> SMP: AP CPU #3 Launched! >>>>>> SMP: AP CPU #11 Launched! >>>>>> SMP: AP CPU #5 Launched! >>>>>> SMP: AP CPU #9 Launched! >>>>>> SMP: AP CPU #1 Launched! >>>>>> SMP: AP CPU #10 Launched! >>>>>> SMP: AP CPU #2 Launched! >>>>>> SMP: AP CPU #8 Launched! >>>>>> SMP: AP CPU #4 Launched! >>>>>> SMP: AP CPU #7 Launched! >>>>>> Timecounter "TSC-low" frequency 1296902002 Hz quality 1000 >>>>>> Root mount waiting for: usbus1 usbus0 >>>>>> uhub1: 2 ports with 2 removable, self powered >>>>>> uhub0: 2 ports with 2 removable, self powered >>>>>> Root mount waiting for: usbus1 usbus0 >>>>>> ugen1.2: at usbus1 >>>>>> uhub2: >>>>> addr 2> >>>> on >>>>>> usbus1 >>>>>> ugen0.2: at usbus0 >>>>>> uhub3: >>>>> addr 2> >>>> on >>>>>> usbus0 >>>>>> Root mount waiting for: usbus1 usbus0 >>>>>> uhub3: 6 ports with 6 removable, self powered >>>>>> uhub2: 8 ports with 8 removable, self powered >>>>>> ugen1.3: at usbus1 >>>>>> ukbd0: on usbus1 >>>>>> kbd0 at ukbd0 >>>>>> Root mount waiting for: usbus1 >>>>>> ugen1.4: at usbus1 >>>>>> ukbd1: on usbus1 >>>>>> kbd2 at ukbd1 >>>>>> Trying to mount root from ufs:/dev/label/rootfs [rw]... >>>>>> lagg0: IPv6 addresses on igb6 have been removed before adding it as a >>>>>> member to prevent IPv6 address scope violation. >>>>>> lagg0: IPv6 addresses on igb7 have been removed before adding it as a >>>>>> member to prevent IPv6 address scope violation. >>>>>> ums0: on usbus1 >>>>>> ums0: 3 buttons and [Z] coordinates ID=0 >>>>>> uhid0: on usbus1 >>>>>> >>>>>> # uname -a >>>>>> FreeBSD rt01.xxxxx.com.br 10.1-RELEASE FreeBSD 10.1-RELEASE #2 >>>>>> r274375: >>>>>> Tue Nov 11 10:24:44 BRST 2014 >>>>>> root@rt01.xxxxx.com.br:/usr/obj/usr/src/sys/GONDIM10 amd64 >>>>>> >>>>>> [1] https://calomel.org/freebsd_network_tuning.html >>>>>> [2] http://ark.intel.com/products/63157 >>>>>> [3] >>>>>> From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 02:02:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50D58305 for ; Tue, 2 Dec 2014 02:02:49 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD0EBC3 for ; Tue, 2 Dec 2014 02:02:48 +0000 (UTC) Received: from eagle.yuri.org (c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id sB222mQZ005393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 1 Dec 2014 18:02:48 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245] claimed to be eagle.yuri.org Message-ID: <547D1DC6.8030408@rawbw.com> Date: Mon, 01 Dec 2014 18:02:46 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Can multiple apps listen for TCP on the same port? References: <547C5DD3.90604@rawbw.com> In-Reply-To: <547C5DD3.90604@rawbw.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 02:02:49 -0000 I figured it out. This is 'nc' from the base, imported from OpenBSD 5.6. nc has two flaws in its code: it listens with backlog=5 (not 1), and it doesn't close the listening socket after accept, only after client is done communicating. Fixing these two problems makes my app work. I first confused it with net/netcat from ports, which is totally different codebase, and isn't duplex. Looking into their code confused me into making original wrong assumptions. Thanks! Yuri From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 04:07:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A00E726; Tue, 2 Dec 2014 04:07:38 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE172980; Tue, 2 Dec 2014 04:07:37 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:57887 helo=[172.27.111.3]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XvekQ-0006ZE-Ts; Mon, 01 Dec 2014 23:07:35 -0500 From: "George Neville-Neil" To: "Julian Elischer" Subject: Re: Enabling VIMAGE in GENERIC Date: Mon, 01 Dec 2014 23:07:34 -0500 Message-ID: In-Reply-To: <547AEB93.3050600@freebsd.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> <547AEB93.3050600@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.8r4576) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 04:07:38 -0000 On 30 Nov 2014, at 5:04, Julian Elischer wrote: > On 11/29/14, 5:28 PM, Craig Rodrigues wrote: >> On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer > > wrote: >> > >> > >> > also look at the following: (a little dated) >> > >> > = >> http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/vimage/&cdf=3D/= /depot/projects/vimage/porting_to_vimage.txt&c=3DtO0@//depot/projects/vim= age/porting_to_vimage.txt?ac=3D22 >> >> >> This is a useful document. I put it on the wiki: = >> https://wiki.freebsd.org/VIMAGE/porting-to-vimage > > Thanks.. wow, did I actually know ALL that only 5 years ago? > Scary. probbaly worth having someone who is currently active and up = > to date look at it to see if it's all still correct.. > especially the module load/unload stuff. > >> >> -- >> Craig > On a slight tangent. I ran VIMAGE kernels vs. non VIMAGE kernels for = both a VANILLA kernel and a PF kernel (PF on but no rules) as a quick smoke test today. The = raw forwarding performance was unchanged between kernels with and without VIMAGE on a 10G based = system in the Sentex lab (lion1). I will be doing a bit more work in this area and will then put = up some results in my netperf github repo. The tests are easy enough to run if you have 3 systems, and Conductor = installed. The source, sink and dut config files are all there to be updated and tried. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 04:13:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B3828E2; Tue, 2 Dec 2014 04:13:00 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF8F9A41; Tue, 2 Dec 2014 04:12:59 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-246-72.lns20.per2.internode.on.net [121.45.246.72]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sB24CliN048450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Dec 2014 20:12:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <547D3C3A.5030408@freebsd.org> Date: Tue, 02 Dec 2014 12:12:42 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: George Neville-Neil Subject: Re: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> <547AEB93.3050600@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 04:13:00 -0000 On 12/2/14, 12:07 PM, George Neville-Neil wrote: > On 30 Nov 2014, at 5:04, Julian Elischer wrote: > >> On 11/29/14, 5:28 PM, Craig Rodrigues wrote: >>> On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer >>> > wrote: >>> > >>> > >>> > also look at the following: (a little dated) >>> > >>> > >>> http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22 >>> >>> >>> This is a useful document. I put it on the wiki: >>> https://wiki.freebsd.org/VIMAGE/porting-to-vimage >> >> Thanks.. wow, did I actually know ALL that only 5 years ago? >> Scary. probbaly worth having someone who is currently active and >> up to date look at it to see if it's all still correct.. >> especially the module load/unload stuff. >> >>> >>> -- >>> Craig >> > > > On a slight tangent. I ran VIMAGE kernels vs. non VIMAGE kernels > for both a VANILLA kernel > and a PF kernel (PF on but no rules) as a quick smoke test today. > The raw forwarding performance > was unchanged between kernels with and without VIMAGE on a 10G based > system in the Sentex lab > (lion1). I will be doing a bit more work in this area and will then > put up some results in my > netperf github repo. > > The tests are easy enough to run if you have 3 systems, and > Conductor installed. The source, sink > and dut config files are all there to be updated and tried. > > Best, > George > > the interesting benchmarks are if you have multiple sessions and spread them across multiple vimage jails, and compare that with the same number of sessions crowded onto a single machine.. lock contention goes down of course so things can actually get faster. From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 04:22:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1309A571 for ; Tue, 2 Dec 2014 04:22:14 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9971AB57 for ; Tue, 2 Dec 2014 04:22:13 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id bs8so26721638wib.16 for ; Mon, 01 Dec 2014 20:22:12 -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=iqaCO6cGyZwxrfCXsu6u/Xr4WerN+VNT6XcqAgJDEr4=; b=EYnRIghw+RQjJV0YCM5qH+XEy9s3SrJcpoe/QnOC8al9nVEEOgBaJL4LP2hx78E1GK KTGF+F3qriXeKg7gp+8NK1sH5BGjEga2KM7tj3b2ArTT8OtI0xuEbxvRmY0lGp8avPP8 b99MeUfz3238H4SoqYWXGG76xVgXNHvaeQcQnY9mijrDABCU3Hj8b0u1d+JZwJLb7VSE ETCBCvutKMRUcPgiH3IGBKr5/Y+T97wvwdB1Qr6cbJ5P0I9UPxD9BZmJohK5GIEroM8y MnhgVhhk+pKeG+oQjP6XTKLWRmzdmonxU6lHWdn6cbvj7XqSgS7z0rcueoF45zH2wmTv GAOQ== MIME-Version: 1.0 X-Received: by 10.180.211.84 with SMTP id na20mr1740804wic.41.1417494132099; Mon, 01 Dec 2014 20:22:12 -0800 (PST) Received: by 10.27.130.68 with HTTP; Mon, 1 Dec 2014 20:22:12 -0800 (PST) In-Reply-To: <547D1DC6.8030408@rawbw.com> References: <547C5DD3.90604@rawbw.com> <547D1DC6.8030408@rawbw.com> Date: Tue, 2 Dec 2014 09:52:12 +0530 Message-ID: Subject: Re: Can multiple apps listen for TCP on the same port? From: Someone Somewhere To: Yuri Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 04:22:14 -0000 I think backlog value has no direct implication here. What matters is if the listening socket has been closed after accepting the client connection or not. -Kunal. On 2 December 2014 at 07:32, Yuri wrote: > I figured it out. This is 'nc' from the base, imported from OpenBSD 5.6. > > nc has two flaws in its code: it listens with backlog=5 (not 1), and it > doesn't close the listening socket after accept, only after client is done > communicating. > Fixing these two problems makes my app work. > > I first confused it with net/netcat from ports, which is totally different > codebase, and isn't duplex. Looking into their code confused me into making > original wrong assumptions. > > Thanks! > > Yuri > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 05:00:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24E6B88D; Tue, 2 Dec 2014 05:00:00 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E651FDD8; Tue, 2 Dec 2014 04:59:59 +0000 (UTC) Received: from pool-96-250-5-187.nycmny.fios.verizon.net ([96.250.5.187]:58967 helo=[172.27.111.3]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XvfZ7-0003nJ-KW; Mon, 01 Dec 2014 23:59:57 -0500 From: "George Neville-Neil" To: "Julian Elischer" Subject: Re: Enabling VIMAGE in GENERIC Date: Mon, 01 Dec 2014 23:59:56 -0500 Message-ID: <84B51B87-22E2-4A8D-BB31-DFB1ADBAD05E@neville-neil.com> In-Reply-To: <547D3C3A.5030408@freebsd.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> <547AEB93.3050600@freebsd.org> <547D3C3A.5030408@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.8r4576) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 05:00:00 -0000 On 1 Dec 2014, at 23:12, Julian Elischer wrote: > On 12/2/14, 12:07 PM, George Neville-Neil wrote: >> On 30 Nov 2014, at 5:04, Julian Elischer wrote: >> >>> On 11/29/14, 5:28 PM, Craig Rodrigues wrote: >>>> On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer = >>>> > wrote: >>>> > >>>> > >>>> > also look at the following: (a little dated) >>>> > >>>> > = >>>> http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/vimage/&cdf=3D= //depot/projects/vimage/porting_to_vimage.txt&c=3DtO0@//depot/projects/vi= mage/porting_to_vimage.txt?ac=3D22 >>>> >>>> >>>> This is a useful document. I put it on the wiki: = >>>> https://wiki.freebsd.org/VIMAGE/porting-to-vimage >>> >>> Thanks.. wow, did I actually know ALL that only 5 years ago? >>> Scary. probbaly worth having someone who is currently active and up = >>> to date look at it to see if it's all still correct.. >>> especially the module load/unload stuff. >>> >>>> >>>> -- = >>>> Craig >>> >> >> >> On a slight tangent. I ran VIMAGE kernels vs. non VIMAGE kernels for = >> both a VANILLA kernel >> and a PF kernel (PF on but no rules) as a quick smoke test today. The = >> raw forwarding performance >> was unchanged between kernels with and without VIMAGE on a 10G based = >> system in the Sentex lab >> (lion1). I will be doing a bit more work in this area and will then = >> put up some results in my >> netperf github repo. >> >> The tests are easy enough to run if you have 3 systems, and Conductor = >> installed. The source, sink >> and dut config files are all there to be updated and tried. >> >> Best, >> George >> >> > the interesting benchmarks are if you have multiple sessions and = > spread them across multiple vimage jails, and compare that with the = > same number of sessions crowded onto a single machine.. > > lock contention goes down of course so things can actually get faster. All in good time. Best, George From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 05:56:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F107069A for ; Tue, 2 Dec 2014 05:56:37 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id D9ECE392 for ; Tue, 2 Dec 2014 05:56:37 +0000 (UTC) Received: from eagle.yuri.org (c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id sB25uasT017496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Dec 2014 21:56:36 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-162-232-245.hsd1.ca.comcast.net [73.162.232.245] claimed to be eagle.yuri.org Message-ID: <547D5493.3020407@rawbw.com> Date: Mon, 01 Dec 2014 21:56:35 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Someone Somewhere Subject: Re: Can multiple apps listen for TCP on the same port? References: <547C5DD3.90604@rawbw.com> <547D1DC6.8030408@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 05:56:38 -0000 On 12/01/2014 20:22, Someone Somewhere wrote: > I think backlog value has no direct implication here. > What matters is if the listening socket has been closed after accepting the > client connection or not. > -Kunal. I think backlog >1 in one-user one-connect app (as nc) might catch other connections and later drop them. I might be wrong. Yuri From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 07:19:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 954A36E8 for ; Tue, 2 Dec 2014 07:19:37 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27598D0E for ; Tue, 2 Dec 2014 07:19:37 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so19926504wiv.1 for ; Mon, 01 Dec 2014 23:19:35 -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=CHp55owzqs2kRhv6PYSLlkgl77OWDcAegmCc1ZiZ3G8=; b=riI1JPKxMd9z/YUlk2P1obJdyMbSpltQkHSKi495vbzYw0rE07cMd0woDKgAufcOu1 9r87brjwj4djymqKN0/YPHTDuJSl/bWOVR2SPMbREWkFg9bd+WoQNGQC7mW4tjSkRVOn etoMvW1cpZ6IBLol09ePDXwzw5DlJ1EMxfd/GutziZioJRC2Mv07BLrwTCh+7LxOVVFh 9EpBELXGjkLWRYJLhkLqSd95Q0SclXiXDeYPpRZZTL7jVXxqBjqKfBxiuE9wyMqWGtk6 Rud9zOELymFZMYq6DHWXxD3bspK/sprI00AvyJwiuCzBKt4T0PyxBm4yS//e+DSAjbBt 1bpQ== MIME-Version: 1.0 X-Received: by 10.194.110.161 with SMTP id ib1mr103596032wjb.78.1417504775581; Mon, 01 Dec 2014 23:19:35 -0800 (PST) Received: by 10.27.130.68 with HTTP; Mon, 1 Dec 2014 23:19:35 -0800 (PST) In-Reply-To: <547D5493.3020407@rawbw.com> References: <547C5DD3.90604@rawbw.com> <547D1DC6.8030408@rawbw.com> <547D5493.3020407@rawbw.com> Date: Tue, 2 Dec 2014 12:49:35 +0530 Message-ID: Subject: Re: Can multiple apps listen for TCP on the same port? From: Someone Somewhere To: Yuri Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 07:19:37 -0000 backlog is more than one since nc can wait for multiple connections via -k option(and also because backlog value is hard coded). https://www.freebsd.org/cgi/man.cgi?query=nc&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html On 2 December 2014 at 11:26, Yuri wrote: > On 12/01/2014 20:22, Someone Somewhere wrote: > >> I think backlog value has no direct implication here. >> What matters is if the listening socket has been closed after accepting >> the >> client connection or not. >> -Kunal. >> > > I think backlog >1 in one-user one-connect app (as nc) might catch other > connections and later drop them. I might be wrong. > > Yuri > From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 11:31:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5017160C; Tue, 2 Dec 2014 11:31:43 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3D40BBB; Tue, 2 Dec 2014 11:31:42 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 94C5D25D388C; Tue, 2 Dec 2014 11:31:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id BFE3FC77070; Tue, 2 Dec 2014 11:31:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id RCyHi4c-dWrR; Tue, 2 Dec 2014 11:31:37 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2B412C7706C; Tue, 2 Dec 2014 11:31:35 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: RFC: Enabling VIMAGE in GENERIC From: "Bjoern A. Zeeb" In-Reply-To: <547AEB93.3050600@freebsd.org> Date: Tue, 2 Dec 2014 11:31:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> <547AEB93.3050600@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 11:31:43 -0000 On 30 Nov 2014, at 10:04 , Julian Elischer wrote: > On 11/29/14, 5:28 PM, Craig Rodrigues wrote: >> On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer > wrote: >> > >> > >> > also look at the following: (a little dated) >> > >> > = http://p4web.freebsd.org/@md=3Dd&cd=3D//depot/projects/vimage/&cdf=3D//dep= ot/projects/vimage/porting_to_vimage.txt&c=3DtO0@//depot/projects/vimage/p= orting_to_vimage.txt?ac=3D22 >>=20 >>=20 >> This is a useful document. I put it on the wiki: = https://wiki.freebsd.org/VIMAGE/porting-to-vimage >=20 > Thanks.. wow, did I actually know ALL that only 5 years ago? > Scary. probbaly worth having someone who is currently active and up = to date look at it to see if it's all still correct.. > especially the module load/unload stuff. Yeah I popped it up in a browser window to read through it once I have a = short break to do that. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 12:28:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEE757D1 for ; Tue, 2 Dec 2014 12:28:56 +0000 (UTC) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82E07127 for ; Tue, 2 Dec 2014 12:28:56 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id bs8so27809193wib.16 for ; Tue, 02 Dec 2014 04:28:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=6jB8mYFbZs7+zmqiZRuFL/Z8uT4MFzHtJCHLrrouRhY=; b=KkG5tCkR0Ca2c4HlU1TzrqsiiT1xbY2GLS/PVZt+vGrSCWQmwtTL1EWL6JJhJWWxUn rWNsaztOyMrUPUq0yoI4lD9nktfm5w4VNWiGZD6sIvQSZbbx+42xTTNti+FGu6s7e/Ay mutlCABl8+v/76ebvoy7v55P62gcsCIEQIUt/W/zrIqi7o58obfl1Wfq79o9zyKz3GMT IEdOx7rXRux/AdTjgoTeRQJkFZhbBUNh8y2tAMc0nHo+2QkqoqHMluEn6RlIlNFedQ+s SmYG+f10X+7qYe0k0DEJl7rYyrxLf5fQiD0jN5A15SQVTQFBGbW3CdsS5z8QVixZ55KI R03Q== X-Gm-Message-State: ALoCoQkUWK1tAVkA4sj89sYgcExrz4ziNDQkXHI8BgI+ow1LnABck+DocF9m79PFSO6DyZj3yj0b X-Received: by 10.180.90.133 with SMTP id bw5mr4950202wib.50.1417523329100; Tue, 02 Dec 2014 04:28:49 -0800 (PST) Received: from FRI2JCHARBON-M1.local ([217.30.88.7]) by mx.google.com with ESMTPSA id n8sm31737990wjx.0.2014.12.02.04.28.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 04:28:48 -0800 (PST) Message-ID: <547DB078.4020404@freebsd.org> Date: Tue, 02 Dec 2014 13:28:40 +0100 From: Julien Charbon User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP stack lock contention with short-lived connections References: <537F39DF.1090900@verisign.com> <542EA1C9.6080907@freebsd.org> <5457832D.6070709@freebsd.org> In-Reply-To: <5457832D.6070709@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HM5iDcgwu0J8PSRGkV39WWAvEqpVKCGsf" Cc: k simon X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 12:28:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HM5iDcgwu0J8PSRGkV39WWAvEqpVKCGsf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 03/11/14 14:29, Julien Charbon wrote: > On 03/10/14 15:16, Julien Charbon wrote: >> On 23/05/14 14:06, Julien Charbon wrote: >>> On 27/02/14 11:32, Julien Charbon wrote: >>>> On 07/11/13 14:55, Julien Charbon wrote: >>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>>>> wrote: >>>>>> kern/183659: TCP stack lock contention with short-lived connection= s >>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D183659 >>>>>> >>>>>> We are currently working on this performance improvement effort;= it >>>>>> will impact only the TCP locking strategy not the TCP stack logic >>>>>> itself. > As usual, a follow-up the TCP short-lived connections performance > improvement progress: > [...] > - Second, a race condition fix with a code clean-up: >=20 > Fix a race condition in TCP timewait between tcp_tw_2msl_reuse() and > tcp_tw_2msl_scan() > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D273850 >=20 > It means that the whole set of tcp_tw_2msl_scan()-related changes coul= d > now be MFC-ed in 10-STABLE as the KBI stability can be kept now: >=20 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264321 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264342 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264351 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D264356 > https://svnweb.freebsd.org/base?view=3Drevision&revision=3D273850 The related 10-STABLE MFC commit is now here: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D275402 And just for interested persons below two TCP short-lived connection improvements changes only in HEAD (No plan for MFC so far): Decrease lock contention in TCP accept https://svnweb.freebsd.org/base?view=3Drevision&revision=3D261242 Decrease lock contention in TCP SYN input: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D271119 -- Julien --HM5iDcgwu0J8PSRGkV39WWAvEqpVKCGsf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUfbB+AAoJEKVlQ5Je6dhxtocH/jHmn1ZyNSZLXe/FpiIOFNcu Ac7mMWMvburpaIIyNji4rskMsYXTiZ0bvZ3JAGZ+B/QurMgTmp7x91VI8mQul59K APUJn/DvsvVB1e/A6kKYXaINmCpiHMHfO/hcKNpHRnzn6s6sDdy6ACRSgQStXAIZ 5IHCgdAsUv2mvjcD1FEmOq7zlGx/P5Ft9hDJDYHNxIGR02xbrFHDoCrpWMWh2OMe WStFFK2WWwGbTfTGLZMH8vOW1P+oTn1y8njSISImmWFAZxN7u0xrQGRo+qbwk7TO 1SpRMoEuE/t4mtWLVQfrPDrX9a7oNBr/p9j/HW3fMPF5LCLvlnnqNMwt0ZV6FwU= =Ar9P -----END PGP SIGNATURE----- --HM5iDcgwu0J8PSRGkV39WWAvEqpVKCGsf-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 15:14:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44DCE7BD; Tue, 2 Dec 2014 15:14:39 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EA01752; Tue, 2 Dec 2014 15:14:38 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-246-72.lns20.per2.internode.on.net [121.45.246.72]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id sB2FEWpa050896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Dec 2014 07:14:35 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <547DD753.1060105@freebsd.org> Date: Tue, 02 Dec 2014 23:14:27 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: RFC: Enabling VIMAGE in GENERIC References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> <547AEB93.3050600@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 15:14:39 -0000 On 12/2/14, 7:31 PM, Bjoern A. Zeeb wrote: > On 30 Nov 2014, at 10:04 , Julian Elischer wrote: > >> On 11/29/14, 5:28 PM, Craig Rodrigues wrote: >>> On Mon, Nov 24, 2014 at 9:03 AM, Julian Elischer > wrote: >>>> >>>> also look at the following: (a little dated) >>>> >>>> http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=tO0@//depot/projects/vimage/porting_to_vimage.txt?ac=22 >>> >>> This is a useful document. I put it on the wiki: https://wiki.freebsd.org/VIMAGE/porting-to-vimage >> Thanks.. wow, did I actually know ALL that only 5 years ago? >> Scary. probbaly worth having someone who is currently active and up to date look at it to see if it's all still correct.. >> especially the module load/unload stuff. > Yeah I popped it up in a browser window to read through it once I have a short break to do that. thanks.. I remember learning most of that stuff the hard way. but kids and work have pretty much made me forget it again and it may have gotten out of date. > > — > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 > > > > From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 16:02:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 008D860B for ; Tue, 2 Dec 2014 16:02:13 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEA80C61 for ; Tue, 2 Dec 2014 16:02:13 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB2G2DnZ004625 for ; Tue, 2 Dec 2014 16:02:13 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB2G2DDa004624; Tue, 2 Dec 2014 16:02:13 GMT (envelope-from root) Date: Tue, 2 Dec 2014 16:02:13 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Updated] D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. Message-ID: X-Priority: 3 Thread-Topic: D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MTgwYzEyNmI0NDMyNDcyOWUzYmZmMDUyYzA0IFR94oU= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 16:02:14 -0000 rodrigc retitled this revision from " Allow UMA allocated memory to be freed when VNET jails are torn down." to "Allow UMA allocated memory to be freed when VNET jails are torn down.". rodrigc added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1201 To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: freebsd-net, emaste, gnn, rwatson From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 17:53:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C584B63E for ; Tue, 2 Dec 2014 17:53:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F7AFB05 for ; Tue, 2 Dec 2014 17:53:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB2Hrp5W019430 for ; Tue, 2 Dec 2014 17:53:51 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB2Hrp0J019429; Tue, 2 Dec 2014 17:53:51 GMT (envelope-from root) Date: Tue, 2 Dec 2014 17:53:51 +0000 To: freebsd-net@freebsd.org From: "rwatson (Robert Watson)" Subject: [Differential] [Commented On] D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. Message-ID: <979a62655a04dc58dd75e9070a133eb0@localhost.localdomain> X-Priority: 3 Thread-Topic: D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MTgwYzEyNmI0NDMyNDcyOWUzYmZmMDUyYzA0IFR9/K8= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 17:53:51 -0000 rwatson added a comment. This patch is probably safe if limited to UDP. REVISION DETAIL https://reviews.freebsd.org/D1201 To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: freebsd-net, emaste, gnn, rwatson From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 17:59:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43DD8850 for ; Tue, 2 Dec 2014 17:59:16 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D8BFB60 for ; Tue, 2 Dec 2014 17:59:16 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB2HxFC2023613 for ; Tue, 2 Dec 2014 17:59:15 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB2HxFcD023612; Tue, 2 Dec 2014 17:59:15 GMT (envelope-from root) Date: Tue, 2 Dec 2014 17:59:15 +0000 To: freebsd-net@freebsd.org From: "gnn (George Neville-Neil)" Subject: [Differential] [Commented On] D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. Message-ID: <1157be6a53b9a8cd4c8d714d878e07dd@localhost.localdomain> X-Priority: 3 Thread-Topic: D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MTgwYzEyNmI0NDMyNDcyOWUzYmZmMDUyYzA0IFR9/fM= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 02 Dec 2014 17:59:16 -0000 gnn added a comment. No objection from me. REVISION DETAIL https://reviews.freebsd.org/D1201 To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: freebsd-net, emaste, gnn, rwatson From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 13:07:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80F4666F for ; Wed, 3 Dec 2014 13:07:33 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A50D2AD for ; Wed, 3 Dec 2014 13:07:32 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 1A9EE139CA for ; Wed, 3 Dec 2014 11:07:41 -0200 (BRST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-transfer-encoding:content-type:content-type :in-reply-to:references:subject:subject:to:mime-version :user-agent:from:from:date:date:message-id; s=dkim; t= 1417612055; x=1418476056; bh=nKEWJF9xFdbYh7w/OY2cNn59RsyH4B2PGNP /Sl77I3U=; b=XUwYgCdp98ZXQ2ik/LHl7AS0yPJOEaJGMGTYNFSHR1HQOnSEQhP /zSvqQw2uR1suei4IMDzHlrqbt5FeTJzz57Ia5BVNzQEaDNaRb39HL1yTNTmzsCf vMOuSCCaYqcgjGfY2MGc//87Ksn3zIHDIZdyh2DXOSFPNP4lHrFm//MQ= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKapJ-26b6Ti for ; Wed, 3 Dec 2014 11:07:35 -0200 (BRST) Received: from [192.168.88.15] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 5EA50139C4 for ; Wed, 3 Dec 2014 11:07:34 -0200 (BRST) Message-ID: <547F0AFE.3070605@bsdinfo.com.br> Date: Wed, 03 Dec 2014 11:07:10 -0200 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: Re: Problems with Intel X520-SR2 References: <547B3BFB.5000503@bsdinfo.com.br> <547B4033.1060504@FreeBSD.org> <547BB862.6080801@bsdinfo.com.br> <547CC35A.1080108@bsdinfo.com.br> <2A35EA60C3C77D438915767F458D65687E987C2A@ORSMSX111.amr.corp.intel.com> In-Reply-To: <2A35EA60C3C77D438915767F458D65687E987C2A@ORSMSX111.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 13:07:33 -0000 Hi all, This review could be the solution to my problem? http://svnweb.freebsd.org/base?view=revision&revision=273736 Best regards, On 01/12/2014 19:29, Pieper, Jeffrey E wrote: > Hi Marcelo, > > A couple of questions - you are using 1310nm fiber on ix0, correct? The difference seems to be that ix0 is LR and ix1 is SR. Also, is there a reason that the interrupt rate is set higher for ix0? > > dev.ix.0.queue0.interrupt_rate: 50000 > dev.ix.1.queue0.interrupt_rate: 11627 > > Jeff > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Marcelo Gondim > Sent: Monday, December 01, 2014 11:37 AM > To: freebsd-net@freebsd.org > Subject: Re: Problems with Intel X520-SR2 > > On 30/11/2014 22:37, Marcelo Gondim wrote: >> Hi Jack, >> >> On 30/11/2014 16:20, Jack Vogel wrote: >>> Good suggestions, do you ever see any 'interrupt throttled' messages? >>> You >>> might >>> want to change the storm threshold to 0 and disable it. >> I can try this: >> >> sysctl hw.intr_storm_threshold=0 > Hi Jack, > > Same problem with hw.intr_storm_threshold=0 > I still think it might be something in my traffic that the driver is not > dealing properly. > > # netstat -idn > . > . > . > ix0 1500 00:1b:21:89:25:32 18446739080975184057 268 > 5876340155018 18446742570019979938 0 0 0 > ix0 - fe80::21b:21f fe80::21b:21ff:fe 0 - - > 1 - - - > ix1 1500 00:1b:21:89:25:33 18446730999135967066 0 > 13653533351669 18446742457148273271 0 0 0 > ix1 - fe80::21b:21f fe80::21b:21ff:fe 0 - - > 0 - - - > . > . > . > > Are 5876340155018 dropped packets in ix0 and 13653533351669 dropped > packets in ix1 > > # w -n > 5:35PM up 15 days, 20:29, 2 users, load averages: 8.96, 9.03, 8.84 > USER TTY FROM LOGIN@ IDLE WHAT > gondim pts/1 186.xxx.48.8 5:22PM - w -n > > >>> I too would like to know if there are any messages when the 'hang' >>> happens. >> Nope. No message. :( >> >>> I don't know much about lagg, is it responsible for link events?? Its >>> not a >>> normal >>> situation to be having so many :( >>> >>> Jack >>> >>> >>> On Sun, Nov 30, 2014 at 10:01 AM, Adrian Chadd >>> wrote: >>> >>>> Your link_irq value is way too high. I think you're exposing some >>>> unhandled corner case in the driver (as I had this issue when I had >>>> some badly cabled up ixgbe NICs) but it doesn't happen when the ixgbe >>>> driver isn't getting link events. >>>> >>>> My test setup at home has link_irq=1 on both sides, and it runs >>>> full-duplex 10GE (1 mil pps transmit/receive on each NIC) traffic for >>>> RSS testing for weeks at a time. I have no issues and no hiccups. >>>> So, I think there's two problems: >>>> >>>> * you're still seeing way too many link_irq events; and >>>> * i think there's some bad handling when it comes to link_irq events. >>>> >>>> I wonder if we're still clearing some of the interrupt register bits >>>> incorrectly in ixgbe_msix_link(). >>>> >>>> >>>> -adrian >>>> >>>> >>>> >>>> >>>> -adrian >>>> >>>> >>>> On 30 November 2014 at 08:05, Alexander V. Chernikov >>>> wrote: >>>>> On 30.11.2014 18:47, Marcelo Gondim wrote: >>>>>> Dear, >>>>>> >>>>>> Unfortunately I have more options to resolve this problem I'm having >>>> with >>>>>> Intel X520-SR2. Have we changed the X520, we exchange the optical >>>>>> cords, >>>>>> exchanged optical modules, we changed the entire server, we reduce >>>>>> the >>>>>> temperature inside the equipment, made some attempts to tunning >>>>>> the site >>>>>> calomel[1]. We spend a lot of money and do not solve the problem. >>>>>> >>>>>> What happens is that when there is a traffic above 1.2Gbps with PPS >>>> above >>>>>> 700kpps in sometimes almost daily there is a lock in two 10GbE >>>>>> ports the >>>>>> X520-SR interface. Where I am obliged to leave a script running in >>>>>> the >>>>>> background doing just that: >>>>> What does this "lock" looks like? >>>>> Do you using jumbo frames? >>>>> Is this IPv4 or IPv4+IPv6 ? >>>>> Can you share "netstat -m" output? >>>>> Do you use ipfw dynamic states? >>>>> Are sure you're not hitting "net.inet.ip.fw.dyn_max=65536" ? >>>>> >>>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>>> >>>>> Looks suspicious. Either you're running out of mbufs due to total mbuf >>>>> number is small, or system is very busy sometimes. >>>>> What does you "top -HPSzs1" output look like? >>>>> >>>>> >>>>>> ifconfig ix0 down; ifconfig ix0 up; ifconfig ix1 down; ifconfig >>>>>> ix1 up >>>>>> >>>>>> Made it back to the interface function normally. It's already so for >>>>>> months and have not tried the latest driver from Intel because I >>>>>> do not >>>> see >>>>>> anything related to this issue. >>>>>> >>>>>> These 2-port 10GbE are my backbone linking the four cities that >>>>>> attend >>>> to >>>>>> our main router. One is backup to other but when the problem occurs, >>>> the two >>>>>> ports stop working and at the moment I have a break in my Internet >>>>>> >>>>>> I can only conclude that the problem is one of the things below: >>>>>> >>>>>> 1 - Intel Interface X520-SR2 has a problem with certain types of >>>>>> traffic >>>>>> and then hangs. >>>>>> 2 - The ixgbe driver has a bug that is causing it. >>>>>> 3 - Problem with FreeBSD 10.x. Not tested with FreeBSD 9.3 because it >>>>>> would be a regression and the equipment is very far away from me if I >>>> need >>>>>> to move me. >>>>>> >>>>>> Honestly I'm almost going on a Juniper closed solution. I would >>>>>> not want >>>>>> to do this because I love FreeBSD and I can not believe that he >>>>>> does not >>>>>> support a 2.7Gbps traffic, which is my peak traffic without getting >>>> having >>>>>> these falls. My hardware today is this: >>>>>> >>>>>> hw.machine: amd64 >>>>>> hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz >>>>>> hw.ncpu: 12 >>>>>> hw.byteorder: 1234 >>>>>> hw.physmem: 17083641856 >>>>>> hw.usermem: 15741001728 >>>>>> >>>>>> Hardware all Intel with motherboard S2600COE [2] and with network >>>>>> interfaces offboard: >>>>>> >>>>>> 1x - X520-SR2 [3] >>>>>> 2x - I350-T2 [4] >>>>>> >>>>>> My loader.conf: >>>>>> >>>>>> loader_logo="beastie" >>>>>> if_lagg_load="YES" >>>>>> speaker_load="YES" >>>>>> aio_load="YES" >>>>>> autoboot_delay="5" >>>>>> net.fibs=1 >>>>>> >>>>>> My sysctl.conf: >>>>>> >>>>>> net.inet.ip.forwarding=1 >>>>>> net.inet.ip.fastforwarding=1 >>>>>> net.inet6.ip6.forwarding=1 >>>>>> kern.ipc.somaxconn=4096 >>>>>> net.inet.tcp.syncookies=1 >>>>>> net.inet.ip.redirect=1 >>>>>> net.inet.ip.accept_sourceroute=0 >>>>>> net.inet.ip.sourceroute=0 >>>>>> net.inet.tcp.drop_synfin=1 >>>>>> net.inet.udp.blackhole=1 >>>>>> net.inet.tcp.blackhole=2 >>>>>> security.bsd.see_other_uids=0 >>>>>> net.inet.ip.fw.dyn_buckets=65536 >>>>>> net.inet.ip.fw.dyn_max=65536 >>>>>> hw.intr_storm_threshold=9000 >>>>>> net.inet.ip.dummynet.pipe_slot_limit=800 >>>>>> net.inet.icmp.icmplim=2000 >>>>>> >>>>>> # sysctl dev.ix. >>>>>> dev.ix.%parent: >>>>>> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >>>>>> Version - >>>>>> 2.5.15 >>>>>> dev.ix.0.%driver: ix >>>>>> dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI1.BR42.S4F0 >>>>>> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>>>> subdevice=0x7a11 class=0x020000 >>>>>> dev.ix.0.%parent: pci129 >>>>>> dev.ix.0.fc: 3 >>>>>> dev.ix.0.enable_aim: 1 >>>>>> dev.ix.0.advertise_speed: 0 >>>>>> dev.ix.0.dropped: 0 >>>>>> dev.ix.0.mbuf_defrag_failed: 0 >>>>>> dev.ix.0.watchdog_events: 0 >>>>>> dev.ix.0.link_irq: 193783 >>>>>> dev.ix.0.queue0.interrupt_rate: 50000 >>>>>> dev.ix.0.queue0.irqs: 12029604413 >>>>>> dev.ix.0.queue0.txd_head: 1517 >>>>>> dev.ix.0.queue0.txd_tail: 1517 >>>>>> dev.ix.0.queue0.tso_tx: 85 >>>>>> dev.ix.0.queue0.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue0.no_desc_avail: 3322269 >>>>>> dev.ix.0.queue0.tx_packets: 15392658033 >>>>>> dev.ix.0.queue0.rxd_head: 709 >>>>>> dev.ix.0.queue0.rxd_tail: 707 >>>>>> dev.ix.0.queue0.rx_packets: 21762427837 >>>>>> dev.ix.0.queue0.rx_bytes: 56918345381 >>>>>> dev.ix.0.queue0.rx_copies: 124289013 >>>>>> dev.ix.0.queue0.lro_queued: 0 >>>>>> dev.ix.0.queue0.lro_flushed: 0 >>>>>> dev.ix.0.queue1.interrupt_rate: 500000 >>>>>> dev.ix.0.queue1.irqs: 11482146431 >>>>>> dev.ix.0.queue1.txd_head: 731 >>>>>> dev.ix.0.queue1.txd_tail: 731 >>>>>> dev.ix.0.queue1.tso_tx: 1442 >>>>>> dev.ix.0.queue1.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue1.no_desc_avail: 5254761 >>>>>> dev.ix.0.queue1.tx_packets: 15835062632 >>>>>> dev.ix.0.queue1.rxd_head: 685 >>>>>> dev.ix.0.queue1.rxd_tail: 681 >>>>>> dev.ix.0.queue1.rx_packets: 21220715209 >>>>>> dev.ix.0.queue1.rx_bytes: 54351679461 >>>>>> dev.ix.0.queue1.rx_copies: 120833356 >>>>>> dev.ix.0.queue1.lro_queued: 0 >>>>>> dev.ix.0.queue1.lro_flushed: 0 >>>>>> dev.ix.0.queue2.interrupt_rate: 5319 >>>>>> dev.ix.0.queue2.irqs: 11532560324 >>>>>> dev.ix.0.queue2.txd_head: 501 >>>>>> dev.ix.0.queue2.txd_tail: 501 >>>>>> dev.ix.0.queue2.tso_tx: 2474 >>>>>> dev.ix.0.queue2.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue2.no_desc_avail: 429244 >>>>>> dev.ix.0.queue2.tx_packets: 15772209238 >>>>>> dev.ix.0.queue2.rxd_head: 246 >>>>>> dev.ix.0.queue2.rxd_tail: 244 >>>>>> dev.ix.0.queue2.rx_packets: 21408648299 >>>>>> dev.ix.0.queue2.rx_bytes: 56862350194 >>>>>> dev.ix.0.queue2.rx_copies: 124973551 >>>>>> dev.ix.0.queue2.lro_queued: 0 >>>>>> dev.ix.0.queue2.lro_flushed: 0 >>>>>> dev.ix.0.queue3.interrupt_rate: 20833 >>>>>> dev.ix.0.queue3.irqs: 11557466322 >>>>>> dev.ix.0.queue3.txd_head: 773 >>>>>> dev.ix.0.queue3.txd_tail: 773 >>>>>> dev.ix.0.queue3.tso_tx: 40 >>>>>> dev.ix.0.queue3.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue3.no_desc_avail: 665620 >>>>>> dev.ix.0.queue3.tx_packets: 16479111658 >>>>>> dev.ix.0.queue3.rxd_head: 1858 >>>>>> dev.ix.0.queue3.rxd_tail: 1854 >>>>>> dev.ix.0.queue3.rx_packets: 21412821769 >>>>>> dev.ix.0.queue3.rx_bytes: 52796089467 >>>>>> dev.ix.0.queue3.rx_copies: 127385950 >>>>>> dev.ix.0.queue3.lro_queued: 0 >>>>>> dev.ix.0.queue3.lro_flushed: 0 >>>>>> dev.ix.0.queue4.interrupt_rate: 11363 >>>>>> dev.ix.0.queue4.irqs: 10824852635 >>>>>> dev.ix.0.queue4.txd_head: 1711 >>>>>> dev.ix.0.queue4.txd_tail: 1713 >>>>>> dev.ix.0.queue4.tso_tx: 581 >>>>>> dev.ix.0.queue4.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue4.no_desc_avail: 115346803 >>>>>> dev.ix.0.queue4.tx_packets: 16100396810 >>>>>> dev.ix.0.queue4.rxd_head: 244 >>>>>> dev.ix.0.queue4.rxd_tail: 243 >>>>>> dev.ix.0.queue4.rx_packets: 21240995210 >>>>>> dev.ix.0.queue4.rx_bytes: 58726730771 >>>>>> dev.ix.0.queue4.rx_copies: 124872141 >>>>>> dev.ix.0.queue4.lro_queued: 0 >>>>>> dev.ix.0.queue4.lro_flushed: 0 >>>>>> dev.ix.0.queue5.interrupt_rate: 500000 >>>>>> dev.ix.0.queue5.irqs: 10955464761 >>>>>> dev.ix.0.queue5.txd_head: 75 >>>>>> dev.ix.0.queue5.txd_tail: 77 >>>>>> dev.ix.0.queue5.tso_tx: 1758 >>>>>> dev.ix.0.queue5.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue5.no_desc_avail: 4759 >>>>>> dev.ix.0.queue5.tx_packets: 16267888038 >>>>>> dev.ix.0.queue5.rxd_head: 905 >>>>>> dev.ix.0.queue5.rxd_tail: 904 >>>>>> dev.ix.0.queue5.rx_packets: 21381144028 >>>>>> dev.ix.0.queue5.rx_bytes: 61800291690 >>>>>> dev.ix.0.queue5.rx_copies: 129684798 >>>>>> dev.ix.0.queue5.lro_queued: 0 >>>>>> dev.ix.0.queue5.lro_flushed: 0 >>>>>> dev.ix.0.queue6.interrupt_rate: 33333 >>>>>> dev.ix.0.queue6.irqs: 11081350674 >>>>>> dev.ix.0.queue6.txd_head: 1744 >>>>>> dev.ix.0.queue6.txd_tail: 1746 >>>>>> dev.ix.0.queue6.tso_tx: 38 >>>>>> dev.ix.0.queue6.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue6.no_desc_avail: 18381 >>>>>> dev.ix.0.queue6.tx_packets: 15376961749 >>>>>> dev.ix.0.queue6.rxd_head: 1783 >>>>>> dev.ix.0.queue6.rxd_tail: 1782 >>>>>> dev.ix.0.queue6.rx_packets: 21381814216 >>>>>> dev.ix.0.queue6.rx_bytes: 56828960117 >>>>>> dev.ix.0.queue6.rx_copies: 130194429 >>>>>> dev.ix.0.queue6.lro_queued: 0 >>>>>> dev.ix.0.queue6.lro_flushed: 0 >>>>>> dev.ix.0.queue7.interrupt_rate: 5319 >>>>>> dev.ix.0.queue7.irqs: 11014043865 >>>>>> dev.ix.0.queue7.txd_head: 1545 >>>>>> dev.ix.0.queue7.txd_tail: 1545 >>>>>> dev.ix.0.queue7.tso_tx: 59 >>>>>> dev.ix.0.queue7.no_tx_dma_setup: 0 >>>>>> dev.ix.0.queue7.no_desc_avail: 5497 >>>>>> dev.ix.0.queue7.tx_packets: 15283534142 >>>>>> dev.ix.0.queue7.rxd_head: 184 >>>>>> dev.ix.0.queue7.rxd_tail: 182 >>>>>> dev.ix.0.queue7.rx_packets: 21431994087 >>>>>> dev.ix.0.queue7.rx_bytes: 57942270182 >>>>>> dev.ix.0.queue7.rx_copies: 128363306 >>>>>> dev.ix.0.queue7.lro_queued: 0 >>>>>> dev.ix.0.queue7.lro_flushed: 0 >>>>>> dev.ix.0.mac_stats.crc_errs: 268 >>>>>> dev.ix.0.mac_stats.ill_errs: 33 >>>>>> dev.ix.0.mac_stats.byte_errs: 55 >>>>>> dev.ix.0.mac_stats.short_discards: 0 >>>>>> dev.ix.0.mac_stats.local_faults: 3484 >>>>>> dev.ix.0.mac_stats.remote_faults: 121 >>>>>> dev.ix.0.mac_stats.rec_len_errs: 0 >>>>>> dev.ix.0.mac_stats.xon_txd: 1602713563748 >>>>>> dev.ix.0.mac_stats.xon_recvd: 0 >>>>>> dev.ix.0.mac_stats.xoff_txd: 108342810167 >>>>>> dev.ix.0.mac_stats.xoff_recvd: 0 >>>>>> dev.ix.0.mac_stats.total_octets_rcvd: 63648882812602 >>>>>> dev.ix.0.mac_stats.good_octets_rcvd: 63546482402023 >>>>>> dev.ix.0.mac_stats.total_pkts_rcvd: 171545277533 >>>>>> dev.ix.0.mac_stats.good_pkts_rcvd: 18446739236268246350 >>>>>> dev.ix.0.mac_stats.mcast_pkts_rcvd: 3724952 >>>>>> dev.ix.0.mac_stats.bcast_pkts_rcvd: 467054852 >>>>>> dev.ix.0.mac_stats.rx_frames_64: 5356098 >>>>>> dev.ix.0.mac_stats.rx_frames_65_127: 122019038388 >>>>>> dev.ix.0.mac_stats.rx_frames_128_255: 7578829973 >>>>>> dev.ix.0.mac_stats.rx_frames_256_511: 3450564281 >>>>>> dev.ix.0.mac_stats.rx_frames_512_1023: 5011796430 >>>>>> dev.ix.0.mac_stats.rx_frames_1024_1522: 33195848924 >>>>>> dev.ix.0.mac_stats.recv_undersized: 0 >>>>>> dev.ix.0.mac_stats.recv_fragmented: 0 >>>>>> dev.ix.0.mac_stats.recv_oversized: 244078 >>>>>> dev.ix.0.mac_stats.recv_jabberd: 4 >>>>>> dev.ix.0.mac_stats.management_pkts_rcvd: 0 >>>>>> dev.ix.0.mac_stats.management_pkts_drpd: 0 >>>>>> dev.ix.0.mac_stats.checksum_errs: 897344641 >>>>>> dev.ix.0.mac_stats.good_octets_txd: 126768678455085 >>>>>> dev.ix.0.mac_stats.total_pkts_txd: 126508073823 >>>>>> dev.ix.0.mac_stats.good_pkts_txd: 18446742557880728233 >>>>>> dev.ix.0.mac_stats.bcast_pkts_txd: 1828364 >>>>>> dev.ix.0.mac_stats.mcast_pkts_txd: 18446742431373346680 >>>>>> dev.ix.0.mac_stats.management_pkts_txd: 0 >>>>>> dev.ix.0.mac_stats.tx_frames_64: 18446742440306683787 >>>>>> dev.ix.0.mac_stats.tx_frames_65_127: 24188318255 >>>>>> dev.ix.0.mac_stats.tx_frames_128_255: 5808482194 >>>>>> dev.ix.0.mac_stats.tx_frames_256_511: 2729252777 >>>>>> dev.ix.0.mac_stats.tx_frames_512_1023: 3029688617 >>>>>> dev.ix.0.mac_stats.tx_frames_1024_1522: 81818302620 >>>>>> dev.ix.1.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, >>>>>> Version - >>>>>> 2.5.15 >>>>>> dev.ix.1.%driver: ix >>>>>> dev.ix.1.%location: slot=0 function=1 handle=\_SB_.PCI1.BR42.S4F1 >>>>>> dev.ix.1.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 >>>>>> subdevice=0x7a11 class=0x020000 >>>>>> dev.ix.1.%parent: pci129 >>>>>> dev.ix.1.fc: 3 >>>>>> dev.ix.1.enable_aim: 1 >>>>>> dev.ix.1.advertise_speed: 0 >>>>>> dev.ix.1.dropped: 0 >>>>>> dev.ix.1.mbuf_defrag_failed: 0 >>>>>> dev.ix.1.watchdog_events: 0 >>>>>> dev.ix.1.link_irq: 127925 >>>>>> dev.ix.1.queue0.interrupt_rate: 11627 >>>>>> dev.ix.1.queue0.irqs: 6686088831 >>>>>> dev.ix.1.queue0.txd_head: 1618 >>>>>> dev.ix.1.queue0.txd_tail: 1620 >>>>>> dev.ix.1.queue0.tso_tx: 28 >>>>>> dev.ix.1.queue0.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue0.no_desc_avail: 0 >>>>>> dev.ix.1.queue0.tx_packets: 13527334563 >>>>>> dev.ix.1.queue0.rxd_head: 1715 >>>>>> dev.ix.1.queue0.rxd_tail: 1714 >>>>>> dev.ix.1.queue0.rx_packets: 1503775702 >>>>>> dev.ix.1.queue0.rx_bytes: 1069295301 >>>>>> dev.ix.1.queue0.rx_copies: 2983480 >>>>>> dev.ix.1.queue0.lro_queued: 0 >>>>>> dev.ix.1.queue0.lro_flushed: 0 >>>>>> dev.ix.1.queue1.interrupt_rate: 5319 >>>>>> dev.ix.1.queue1.irqs: 6546967336 >>>>>> dev.ix.1.queue1.txd_head: 1812 >>>>>> dev.ix.1.queue1.txd_tail: 1812 >>>>>> dev.ix.1.queue1.tso_tx: 6 >>>>>> dev.ix.1.queue1.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue1.no_desc_avail: 0 >>>>>> dev.ix.1.queue1.tx_packets: 13475453794 >>>>>> dev.ix.1.queue1.rxd_head: 1246 >>>>>> dev.ix.1.queue1.rxd_tail: 1245 >>>>>> dev.ix.1.queue1.rx_packets: 1506444917 >>>>>> dev.ix.1.queue1.rx_bytes: 783064190 >>>>>> dev.ix.1.queue1.rx_copies: 2881513 >>>>>> dev.ix.1.queue1.lro_queued: 0 >>>>>> dev.ix.1.queue1.lro_flushed: 0 >>>>>> dev.ix.1.queue2.interrupt_rate: 5319 >>>>>> dev.ix.1.queue2.irqs: 6574615190 >>>>>> dev.ix.1.queue2.txd_head: 1494 >>>>>> dev.ix.1.queue2.txd_tail: 1494 >>>>>> dev.ix.1.queue2.tso_tx: 33 >>>>>> dev.ix.1.queue2.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue2.no_desc_avail: 0 >>>>>> dev.ix.1.queue2.tx_packets: 13555495169 >>>>>> dev.ix.1.queue2.rxd_head: 438 >>>>>> dev.ix.1.queue2.rxd_tail: 437 >>>>>> dev.ix.1.queue2.rx_packets: 1501380848 >>>>>> dev.ix.1.queue2.rx_bytes: 1008544082 >>>>>> dev.ix.1.queue2.rx_copies: 2660960 >>>>>> dev.ix.1.queue2.lro_queued: 0 >>>>>> dev.ix.1.queue2.lro_flushed: 0 >>>>>> dev.ix.1.queue3.interrupt_rate: 5319 >>>>>> dev.ix.1.queue3.irqs: 6617964401 >>>>>> dev.ix.1.queue3.txd_head: 1853 >>>>>> dev.ix.1.queue3.txd_tail: 1855 >>>>>> dev.ix.1.queue3.tso_tx: 10 >>>>>> dev.ix.1.queue3.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue3.no_desc_avail: 0 >>>>>> dev.ix.1.queue3.tx_packets: 13561212942 >>>>>> dev.ix.1.queue3.rxd_head: 429 >>>>>> dev.ix.1.queue3.rxd_tail: 428 >>>>>> dev.ix.1.queue3.rx_packets: 1498117903 >>>>>> dev.ix.1.queue3.rx_bytes: 784881986 >>>>>> dev.ix.1.queue3.rx_copies: 2695475 >>>>>> dev.ix.1.queue3.lro_queued: 0 >>>>>> dev.ix.1.queue3.lro_flushed: 0 >>>>>> dev.ix.1.queue4.interrupt_rate: 5319 >>>>>> dev.ix.1.queue4.irqs: 6575752163 >>>>>> dev.ix.1.queue4.txd_head: 902 >>>>>> dev.ix.1.queue4.txd_tail: 902 >>>>>> dev.ix.1.queue4.tso_tx: 5 >>>>>> dev.ix.1.queue4.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue4.no_desc_avail: 0 >>>>>> dev.ix.1.queue4.tx_packets: 13478514009 >>>>>> dev.ix.1.queue4.rxd_head: 536 >>>>>> dev.ix.1.queue4.rxd_tail: 535 >>>>>> dev.ix.1.queue4.rx_packets: 1476720084 >>>>>> dev.ix.1.queue4.rx_bytes: 944967171 >>>>>> dev.ix.1.queue4.rx_copies: 2650672 >>>>>> dev.ix.1.queue4.lro_queued: 0 >>>>>> dev.ix.1.queue4.lro_flushed: 0 >>>>>> dev.ix.1.queue5.interrupt_rate: 10416 >>>>>> dev.ix.1.queue5.irqs: 6578099670 >>>>>> dev.ix.1.queue5.txd_head: 1996 >>>>>> dev.ix.1.queue5.txd_tail: 1996 >>>>>> dev.ix.1.queue5.tso_tx: 663 >>>>>> dev.ix.1.queue5.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue5.no_desc_avail: 0 >>>>>> dev.ix.1.queue5.tx_packets: 13516483196 >>>>>> dev.ix.1.queue5.rxd_head: 1296 >>>>>> dev.ix.1.queue5.rxd_tail: 1295 >>>>>> dev.ix.1.queue5.rx_packets: 1496584151 >>>>>> dev.ix.1.queue5.rx_bytes: 810434347 >>>>>> dev.ix.1.queue5.rx_copies: 2899315 >>>>>> dev.ix.1.queue5.lro_queued: 0 >>>>>> dev.ix.1.queue5.lro_flushed: 0 >>>>>> dev.ix.1.queue6.interrupt_rate: 5319 >>>>>> dev.ix.1.queue6.irqs: 6624395782 >>>>>> dev.ix.1.queue6.txd_head: 1058 >>>>>> dev.ix.1.queue6.txd_tail: 1058 >>>>>> dev.ix.1.queue6.tso_tx: 20 >>>>>> dev.ix.1.queue6.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue6.no_desc_avail: 0 >>>>>> dev.ix.1.queue6.tx_packets: 13491315217 >>>>>> dev.ix.1.queue6.rxd_head: 1550 >>>>>> dev.ix.1.queue6.rxd_tail: 1549 >>>>>> dev.ix.1.queue6.rx_packets: 1510907490 >>>>>> dev.ix.1.queue6.rx_bytes: 719914325 >>>>>> dev.ix.1.queue6.rx_copies: 2712955 >>>>>> dev.ix.1.queue6.lro_queued: 0 >>>>>> dev.ix.1.queue6.lro_flushed: 0 >>>>>> dev.ix.1.queue7.interrupt_rate: 29411 >>>>>> dev.ix.1.queue7.irqs: 6573304834 >>>>>> dev.ix.1.queue7.txd_head: 784 >>>>>> dev.ix.1.queue7.txd_tail: 786 >>>>>> dev.ix.1.queue7.tso_tx: 2 >>>>>> dev.ix.1.queue7.no_tx_dma_setup: 0 >>>>>> dev.ix.1.queue7.no_desc_avail: 0 >>>>>> dev.ix.1.queue7.tx_packets: 13587681458 >>>>>> dev.ix.1.queue7.rxd_head: 1489 >>>>>> dev.ix.1.queue7.rxd_tail: 1488 >>>>>> dev.ix.1.queue7.rx_packets: 1504712031 >>>>>> dev.ix.1.queue7.rx_bytes: 1216803328 >>>>>> dev.ix.1.queue7.rx_copies: 2976103 >>>>>> dev.ix.1.queue7.lro_queued: 0 >>>>>> dev.ix.1.queue7.lro_flushed: 0 >>>>>> dev.ix.1.mac_stats.crc_errs: 0 >>>>>> dev.ix.1.mac_stats.ill_errs: 0 >>>>>> dev.ix.1.mac_stats.byte_errs: 0 >>>>>> dev.ix.1.mac_stats.short_discards: 0 >>>>>> dev.ix.1.mac_stats.local_faults: 0 >>>>>> dev.ix.1.mac_stats.remote_faults: 12 >>>>>> dev.ix.1.mac_stats.rec_len_errs: 0 >>>>>> dev.ix.1.mac_stats.xon_txd: 1714791401322 >>>>>> dev.ix.1.mac_stats.xon_recvd: 0 >>>>>> dev.ix.1.mac_stats.xoff_txd: 41095995010 >>>>>> dev.ix.1.mac_stats.xoff_recvd: 0 >>>>>> dev.ix.1.mac_stats.total_octets_rcvd: 4335824523464 >>>>>> dev.ix.1.mac_stats.good_octets_rcvd: 4335686239235 >>>>>> dev.ix.1.mac_stats.total_pkts_rcvd: 12020354631 >>>>>> dev.ix.1.mac_stats.good_pkts_rcvd: 18446730999130315370 >>>>>> dev.ix.1.mac_stats.mcast_pkts_rcvd: 737 >>>>>> dev.ix.1.mac_stats.bcast_pkts_rcvd: 295580 >>>>>> dev.ix.1.mac_stats.rx_frames_64: 73447 >>>>>> dev.ix.1.mac_stats.rx_frames_65_127: 8714296833 >>>>>> dev.ix.1.mac_stats.rx_frames_128_255: 478134642 >>>>>> dev.ix.1.mac_stats.rx_frames_256_511: 232994605 >>>>>> dev.ix.1.mac_stats.rx_frames_512_1023: 341753974 >>>>>> dev.ix.1.mac_stats.rx_frames_1024_1522: 2251178850 >>>>>> dev.ix.1.mac_stats.recv_undersized: 0 >>>>>> dev.ix.1.mac_stats.recv_fragmented: 0 >>>>>> dev.ix.1.mac_stats.recv_oversized: 0 >>>>>> dev.ix.1.mac_stats.recv_jabberd: 0 >>>>>> dev.ix.1.mac_stats.management_pkts_rcvd: 0 >>>>>> dev.ix.1.mac_stats.management_pkts_drpd: 0 >>>>>> dev.ix.1.mac_stats.checksum_errs: 85432477 >>>>>> dev.ix.1.mac_stats.good_octets_txd: 110334688606644 >>>>>> dev.ix.1.mac_stats.total_pkts_txd: 108193846110 >>>>>> dev.ix.1.mac_stats.good_pkts_txd: 18446742447490837867 >>>>>> dev.ix.1.mac_stats.bcast_pkts_txd: 595976 >>>>>> dev.ix.1.mac_stats.mcast_pkts_txd: 18446742339297559869 >>>>>> dev.ix.1.mac_stats.management_pkts_txd: 0 >>>>>> dev.ix.1.mac_stats.tx_frames_64: 18446742346194685024 >>>>>> dev.ix.1.mac_stats.tx_frames_65_127: 19859540709 >>>>>> dev.ix.1.mac_stats.tx_frames_128_255: 5129619113 >>>>>> dev.ix.1.mac_stats.tx_frames_256_511: 2384651426 >>>>>> dev.ix.1.mac_stats.tx_frames_512_1023: 2651547352 >>>>>> dev.ix.1.mac_stats.tx_frames_1024_1522: 71270794251 >>>>>> >>>>>> # cat /var/run/dmesg.boot >>>>>> >>>>>> Copyright (c) 1992-2014 The FreeBSD Project. >>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, >>>>>> 1993, 1994 >>>>>> The Regents of the University of California. All rights >>>> reserved. >>>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>>> FreeBSD 10.1-RELEASE #2 r274375: Tue Nov 11 10:24:44 BRST 2014 >>>>>> root@rt01.intnet.com.br:/usr/obj/usr/src/sys/INTNET10 amd64 >>>>>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) >>>>>> 20140512 >>>>>> CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2593.80-MHz K8-class >>>> CPU) >>>>>> Origin = "GenuineIntel" Id = 0x306e4 Family = 0x6 Model = 0x3e >>>>>> Stepping = 4 >>>>>> >>>>>> >>>> Features=0xbfebfbff >>>> >>>> Features2=0x7fbee3ff >>>> >>>>>> AMD Features=0x2c100800 >>>>>> AMD Features2=0x1 >>>>>> Structured Extended Features=0x281 >>>>>> VT-x: (disabled in BIOS) >>>>>> PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr >>>>>> TSC: P-state invariant, performance statistics >>>>>> real memory = 17179869184 (16384 MB) >>>>>> avail memory = 16515358720 (15750 MB) >>>>>> Event timer "LAPIC" quality 600 >>>>>> ACPI APIC Table: >>>>>> FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs >>>>>> FreeBSD/SMP: 2 package(s) x 6 core(s) >>>>>> cpu0 (BSP): APIC ID: 0 >>>>>> cpu1 (AP): APIC ID: 2 >>>>>> cpu2 (AP): APIC ID: 4 >>>>>> cpu3 (AP): APIC ID: 6 >>>>>> cpu4 (AP): APIC ID: 8 >>>>>> cpu5 (AP): APIC ID: 10 >>>>>> cpu6 (AP): APIC ID: 32 >>>>>> cpu7 (AP): APIC ID: 34 >>>>>> cpu8 (AP): APIC ID: 36 >>>>>> cpu9 (AP): APIC ID: 38 >>>>>> cpu10 (AP): APIC ID: 40 >>>>>> cpu11 (AP): APIC ID: 42 >>>>>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: >>>>>> 32, >>>>>> using default 16 (20130823/tbfadt-682) >>>>>> ioapic0 irqs 0-23 on motherboard >>>>>> ioapic1 irqs 24-47 on motherboard >>>>>> ioapic2 irqs 48-71 on motherboard >>>>>> kbd1 at kbdmux0 >>>>>> random: initialized >>>>>> cryptosoft0: on motherboard >>>>>> acpi0: on motherboard >>>>>> acpi0: Power Button (fixed) >>>>>> acpi0: reservation of 0, 9d000 (3) failed >>>>>> cpu0: on acpi0 >>>>>> cpu1: on acpi0 >>>>>> cpu2: on acpi0 >>>>>> cpu3: on acpi0 >>>>>> cpu4: on acpi0 >>>>>> cpu5: on acpi0 >>>>>> cpu6: on acpi0 >>>>>> cpu7: on acpi0 >>>>>> cpu8: on acpi0 >>>>>> cpu9: on acpi0 >>>>>> cpu10: on acpi0 >>>>>> cpu11: on acpi0 >>>>>> hpet0: iomem 0xfed00000-0xfed003ff on >>>>>> acpi0 >>>>>> Timecounter "HPET" frequency 14318180 Hz quality 950 >>>>>> Event timer "HPET" frequency 14318180 Hz quality 350 >>>>>> Event timer "HPET1" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET2" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET3" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET4" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET5" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET6" frequency 14318180 Hz quality 340 >>>>>> Event timer "HPET7" frequency 14318180 Hz quality 340 >>>>>> atrtc0: port 0x70-0x77 irq 8 on acpi0 >>>>>> atrtc0: Warning: Couldn't map I/O. >>>>>> Event timer "RTC" frequency 32768 Hz quality 0 >>>>>> attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 >>>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>>> Event timer "i8254" frequency 1193182 Hz quality 100 >>>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >>>>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>>> pci0: on pcib0 >>>>>> pcib1: irq 47 at device 1.0 on pci0 >>>>>> pci1: on pcib1 >>>>>> pcib2: irq 47 at device 1.1 on pci0 >>>>>> pci2: on pcib2 >>>>>> igb0: port >>>>>> 0x1060-0x107f mem 0xd0f60000-0xd0f7ffff,0xd0fb0000-0xd0fb3fff irq >>>>>> 27 at >>>>>> device 0.0 on pci2 >>>>>> igb0: Using MSIX interrupts with 9 vectors >>>>>> igb0: Ethernet address: 00:1e:67:9a:d5:88 >>>>>> 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 >>>>>> igb0: Bound queue 4 to cpu 4 >>>>>> igb0: Bound queue 5 to cpu 5 >>>>>> igb0: Bound queue 6 to cpu 6 >>>>>> igb0: Bound queue 7 to cpu 7 >>>>>> igb1: port >>>>>> 0x1040-0x105f mem 0xd0f40000-0xd0f5ffff,0xd0fa0000-0xd0fa3fff irq >>>>>> 30 at >>>>>> device 0.1 on pci2 >>>>>> igb1: Using MSIX interrupts with 9 vectors >>>>>> igb1: Ethernet address: 00:1e:67:9a:d5:89 >>>>>> igb1: Bound queue 0 to cpu 8 >>>>>> igb1: Bound queue 1 to cpu 9 >>>>>> igb1: Bound queue 2 to cpu 10 >>>>>> igb1: Bound queue 3 to cpu 11 >>>>>> igb1: Bound queue 4 to cpu 0 >>>>>> igb1: Bound queue 5 to cpu 1 >>>>>> igb1: Bound queue 6 to cpu 2 >>>>>> igb1: Bound queue 7 to cpu 3 >>>>>> igb2: port >>>>>> 0x1020-0x103f mem 0xd0f20000-0xd0f3ffff,0xd0f90000-0xd0f93fff irq >>>>>> 28 at >>>>>> device 0.2 on pci2 >>>>>> igb2: Using MSIX interrupts with 9 vectors >>>>>> igb2: Ethernet address: 00:1e:67:9a:d5:8a >>>>>> igb2: Bound queue 0 to cpu 4 >>>>>> igb2: Bound queue 1 to cpu 5 >>>>>> igb2: Bound queue 2 to cpu 6 >>>>>> igb2: Bound queue 3 to cpu 7 >>>>>> igb2: Bound queue 4 to cpu 8 >>>>>> igb2: Bound queue 5 to cpu 9 >>>>>> igb2: Bound queue 6 to cpu 10 >>>>>> igb2: Bound queue 7 to cpu 11 >>>>>> igb3: port >>>>>> 0x1000-0x101f mem 0xd0f00000-0xd0f1ffff,0xd0f80000-0xd0f83fff irq >>>>>> 29 at >>>>>> device 0.3 on pci2 >>>>>> igb3: Using MSIX interrupts with 9 vectors >>>>>> igb3: Ethernet address: 00:1e:67:9a:d5:8b >>>>>> igb3: Bound queue 0 to cpu 0 >>>>>> igb3: Bound queue 1 to cpu 1 >>>>>> igb3: Bound queue 2 to cpu 2 >>>>>> igb3: Bound queue 3 to cpu 3 >>>>>> igb3: Bound queue 4 to cpu 4 >>>>>> igb3: Bound queue 5 to cpu 5 >>>>>> igb3: Bound queue 6 to cpu 6 >>>>>> igb3: Bound queue 7 to cpu 7 >>>>>> pcib3: irq 47 at device 2.0 on pci0 >>>>>> pci4: on pcib3 >>>>>> igb4: mem >>>>>> 0xd0d00000-0xd0dfffff,0xd0e10000-0xd0e13fff irq 32 at device 0.0 >>>>>> on pci4 >>>>>> igb4: Using MSIX interrupts with 9 vectors >>>>>> igb4: Ethernet address: a0:36:9f:37:82:7e >>>>>> igb4: Bound queue 0 to cpu 8 >>>>>> igb4: Bound queue 1 to cpu 9 >>>>>> igb4: Bound queue 2 to cpu 10 >>>>>> igb4: Bound queue 3 to cpu 11 >>>>>> igb4: Bound queue 4 to cpu 0 >>>>>> igb4: Bound queue 5 to cpu 1 >>>>>> igb4: Bound queue 6 to cpu 2 >>>>>> igb4: Bound queue 7 to cpu 3 >>>>>> igb5: mem >>>>>> 0xd0c00000-0xd0cfffff,0xd0e00000-0xd0e03fff irq 36 at device 0.1 >>>>>> on pci4 >>>>>> igb5: Using MSIX interrupts with 9 vectors >>>>>> igb5: Ethernet address: a0:36:9f:37:82:7f >>>>>> igb5: Bound queue 0 to cpu 4 >>>>>> igb5: Bound queue 1 to cpu 5 >>>>>> igb5: Bound queue 2 to cpu 6 >>>>>> igb5: Bound queue 3 to cpu 7 >>>>>> igb5: Bound queue 4 to cpu 8 >>>>>> igb5: Bound queue 5 to cpu 9 >>>>>> igb5: Bound queue 6 to cpu 10 >>>>>> igb5: Bound queue 7 to cpu 11 >>>>>> pcib4: irq 16 at device 3.0 on pci0 >>>>>> pci6: on pcib4 >>>>>> igb6: mem >>>>>> 0xd0a00000-0xd0afffff,0xd0b10000-0xd0b13fff irq 40 at device 0.0 >>>>>> on pci6 >>>>>> igb6: Using MSIX interrupts with 9 vectors >>>>>> igb6: Ethernet address: a0:36:9f:37:82:8a >>>>>> igb6: Bound queue 0 to cpu 0 >>>>>> igb6: Bound queue 1 to cpu 1 >>>>>> igb6: Bound queue 2 to cpu 2 >>>>>> igb6: Bound queue 3 to cpu 3 >>>>>> igb6: Bound queue 4 to cpu 4 >>>>>> igb6: Bound queue 5 to cpu 5 >>>>>> igb6: Bound queue 6 to cpu 6 >>>>>> igb6: Bound queue 7 to cpu 7 >>>>>> igb7: mem >>>>>> 0xd0900000-0xd09fffff,0xd0b00000-0xd0b03fff irq 44 at device 0.1 >>>>>> on pci6 >>>>>> igb7: Using MSIX interrupts with 9 vectors >>>>>> igb7: Ethernet address: a0:36:9f:37:82:8b >>>>>> igb7: Bound queue 0 to cpu 8 >>>>>> igb7: Bound queue 1 to cpu 9 >>>>>> igb7: Bound queue 2 to cpu 10 >>>>>> igb7: Bound queue 3 to cpu 11 >>>>>> igb7: Bound queue 4 to cpu 0 >>>>>> igb7: Bound queue 5 to cpu 1 >>>>>> igb7: Bound queue 6 to cpu 2 >>>>>> igb7: Bound queue 7 to cpu 3 >>>>>> pcib5: irq 16 at device 17.0 on pci0 >>>>>> pci8: on pcib5 >>>>>> pci0: at device 22.0 (no driver attached) >>>>>> pci0: at device 22.1 (no driver attached) >>>>>> ehci0: mem >>>>>> 0xd1220000-0xd12203ff irq >>>>>> 22 at device 26.0 on pci0 >>>>>> usbus0: EHCI version 1.0 >>>>>> usbus0 on ehci0 >>>>>> pcib6: irq 16 at device 28.0 on pci0 >>>>>> pci9: on pcib6 >>>>>> pcib7: irq 17 at device 28.5 on pci0 >>>>>> pci10: on pcib7 >>>>>> pci10: at device 0.0 (no driver attached) >>>>>> pcib8: irq 19 at device 28.7 on pci0 >>>>>> pci11: on pcib8 >>>>>> vgapci0: mem >>>>>> 0xea000000-0xeaffffff,0xd0810000-0xd0813fff,0xd0000000-0xd07fffff irq >>>> 19 at >>>>>> device 0.0 on pci11 >>>>>> vgapci0: Boot video device >>>>>> ehci1: mem >>>>>> 0xd1210000-0xd12103ff irq >>>>>> 20 at device 29.0 on pci0 >>>>>> usbus1: EHCI version 1.0 >>>>>> usbus1 on ehci1 >>>>>> pcib9: at device 30.0 on pci0 >>>>>> pci12: on pcib9 >>>>>> isab0: at device 31.0 on pci0 >>>>>> isa0: on isab0 >>>>>> ahci0: port >>>>>> 0x2070-0x2077,0x2060-0x2063,0x2050-0x2057,0x2040-0x2043,0x2020-0x203f >>>> mem >>>>>> 0xd1200000-0xd12007ff irq 21 at device 31.2 on pci0 >>>>>> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported >>>>>> ahcich0: at channel 0 on ahci0 >>>>>> ahcich1: at channel 1 on ahci0 >>>>>> ahcich2: at channel 2 on ahci0 >>>>>> ahcich3: at channel 3 on ahci0 >>>>>> ahcich4: at channel 4 on ahci0 >>>>>> ahcich5: at channel 5 on ahci0 >>>>>> ahciem0: on ahci0 >>>>>> pcib10: on acpi0 >>>>>> pci128: on pcib10 >>>>>> pcib11: irq 71 at device 1.0 on pci128 >>>>>> pci129: on pcib11 >>>>>> ix0: >>>>> 2.5.15> >>>>>> port 0xc020-0xc03f mem 0xec180000-0xec1fffff,0xec210000-0xec213fff >>>>>> irq >>>> 50 at >>>>>> device 0.0 on pci129 >>>>>> ix0: Using MSIX interrupts with 9 vectors >>>>>> ix0: Ethernet address: 00:1b:21:89:25:32 >>>>>> ix0: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>>> ix1: >>>>> 2.5.15> >>>>>> port 0xc000-0xc01f mem 0xec080000-0xec0fffff,0xec200000-0xec203fff >>>>>> irq >>>> 52 at >>>>>> device 0.1 on pci129 >>>>>> ix1: Using MSIX interrupts with 9 vectors >>>>>> ix1: Ethernet address: 00:1b:21:89:25:33 >>>>>> ix1: PCI Express Bus: Speed 5.0GT/s Width x8 >>>>>> pcib12: irq 71 at device 2.0 on pci128 >>>>>> pci131: on pcib12 >>>>>> pcib13: irq 71 at device 3.0 on pci128 >>>>>> pci132: on pcib13 >>>>>> acpi_button0: on acpi0 >>>>>> pcib14: on acpi0 >>>>>> pci127: on pcib14 >>>>>> pcib15: on acpi0 >>>>>> pci255: on pcib15 >>>>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on >>>>>> acpi0 >>>>>> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >>>>>> orm0: at iomem >>>>>> >>>> 0xc0000-0xc7fff,0xc8000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff >>>> >>>>>> on isa0 >>>>>> sc0: at flags 0x100 on isa0 >>>>>> sc0: VGA <16 virtual consoles, flags=0x300> >>>>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on >>>> isa0 >>>> From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 15:53:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29B906AB for ; Wed, 3 Dec 2014 15:53:30 +0000 (UTC) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "patpro.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B41A9CF8 for ; Wed, 3 Dec 2014 15:53:29 +0000 (UTC) Received: from patpro.univ-lyon2.fr (patpro.univ-lyon2.fr [159.84.113.250]) by rack.patpro.net (Postfix) with ESMTPSA id 51A1A9DC for ; Wed, 3 Dec 2014 16:46:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=patpro.net; s=patpro; t=1417621576; bh=tc+03Jp1F8h028TRSpg4xFiaIxCZEnzcrXPaJHkGGsU=; h=From:Subject:Date:To; b=FEWcEF2QMtWISOYOYP28ErrPrub0nVBD1QR2OxV6MGH49UptSggm6wzrC+49n2+vR RJkSlpJi+mDrUCWsYVGlJcRrVsfwGukRgeTgR3HDv+QO0Z4fWbjJ6JFMomaK+4yVWX GyrgV2K2T2hu0lruw77T8QxY1H0wZWaS1pckJE8g= From: Patrick Proniewski Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Horrendous upload network performance with VLAN (download seems OK) Message-Id: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> Date: Wed, 3 Dec 2014 16:46:15 +0100 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 15:53:30 -0000 Hello, I'm running FreeBSD 9.3-RELEASE up-to-date, on two HP Proliant G6 server = blades in the same enclosure. One with VLANs in the uplink, the other = without VLANs. They use bxe driver. bxe0: mem 0xfb000000-0xfb7fffff,0xfa800000-0xfaffffff irq 28 at = device 0.0 on pci2 bxe0: PCI BAR0 [10] memory allocated: 0xfb000000-0xfb7fffff = (8388608) -> 0xfffffe00fb000000 bxe0: PCI BAR2 [18] memory allocated: 0xfa800000-0xfaffffff = (8388608) -> 0xfffffe00fa800000 bxe0: Found 10GBase-CX4 media. bxe0: Ethernet address: 00:17:a4:77:04:10 bxe0: MSI-X vectors Requested 5 and Allocated 5 ../.. (and so on up to bxe7) Blade A is configured to access the network through a connection without = VLANs (the link provided by Network team comes with no VLAN tagging). = Its transfer rate is perfect, both up and down. ifconfig_bxe0=3D"inet x.y.z.141/24" defaultrouter=3D"x.y.z.1" # ifconfig bxe0 bxe0: flags=3D8843 = metric 0 mtu 1500 = options=3D507bb ether 00:17:a4:77:04:00 inet x.y.z.141 netmask 0xffffff00 broadcast x.y.z.255 nd6 options=3D29 media: Ethernet autoselect (10Gbase-CX4 ) status: active Blade B is configured to access the network through a link sporting = multiple VLANs, so I've created a network interface that uses one of = these VLANs. Ping is OK, I can ssh to this server, transfer rate to the = server (down) is not fantastic but OK, enough to perform pkg = installation or FreeBSD update. Transfer rate from the server to the = rest of the world is abysmal, often stalling after few 100's KB. ifconfig_bxe0=3D"UP" vlans_bxe0=3D"161" ifconfig_bxe0_161=3D"inet x.y.z.142/24" defaultrouter=3D"x.y.z.1" # ifconfig bxe0 bxe0: flags=3D8843 = metric 0 mtu 1500 = options=3D507bb ether 00:17:a4:77:04:10 nd6 options=3D29 media: Ethernet autoselect (10Gbase-CX4 ) status: active # ifconfig bxe0.161 bxe0.161: flags=3D8843 = metric 0 mtu 1500 options=3D303 ether 00:17:a4:77:04:10 inet x.y.z.142 netmask 0xffffff00 broadcast x.y.z.255 inet6 fe80::217:a4ff:fe77:410%bxe0.161 prefixlen 64 scopeid = 0x10 nd6 options=3D29 media: Ethernet autoselect (10Gbase-CX4 ) status: active vlan: 161 parent interface: bxe0 The same switch is used by those two blade servers running FreeBSD, and = by about 14 other blade servers running VMware ESXi 5.x. ESXi blades use multiple VLANs and work perfectly. A blade running = FreeBSD with no VLAN in its uplink (i.e. not sharing the same uplink as = ESXi blades) has very good network performances. The only blade with = problem is the one running FreeBSD and sharing the uplink of ESXi = blades. scp of a 347MB file from an ESXi blade server to FreeBSD blade (same = switch, same blade chassis, same uplink): # scp esxi11.domain.tld:/tardisks/FILE /dev/null Password: FILE 100% 347MB 38.6MB/s = 00:09 =20 scp of a 347MB file from an FreeBSD blade to ESXi blade (same switch, = same blade chassis, same uplink): # scp FILE esxi11.domain.tld:/dev/null Password: FILE 0% 400KB 172.2KB/s - = stalled - traceroute from FreeBSD blade to ESXi blade: # traceroute esxi11.domain.tld traceroute to esxi11.domain.tld (x.y.z.151), 64 hops max, 52 = byte packets 1 * * * 2 * * * ^C traceroute from ESXi blade to FreeBSD blade: # traceroute freebsdB.domain.tld traceroute to freebsdB.domain.tld (x.y.z.142), 30 hops max, 40 = byte packets 1 freebsdB (x.y.z.142) 0.123 ms 0.090 ms 0.078 ms I'm quite lost here. Any idea that would explain the problem, and help me resolve it? Original thread posted on = Patrick From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 15:57:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 580F984E for ; Wed, 3 Dec 2014 15:57:25 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E05D4D50 for ; Wed, 3 Dec 2014 15:57:24 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id r20so24904133wiv.14 for ; Wed, 03 Dec 2014 07:57:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aLQT1o+S1lw48U9AJpP+BbevuDIm9KzXdvFTz7XG/Do=; b=IK0BasGjxIStPSoOHaXLkpjRMyMTd5CFWgsrf7ALq87Xg/vyXbgPnDpolYds2Wr29u n7rn6Qz5IUwnduT9FGHXwHk/oSZMZbu6tul3uufEo6P7eFz4Gc+XwL7mHSOv3ys9htnq MQqLw7E0AP2sLW/QWgqHSfdQoWpbla7TUSYNFxEguz243upvTujjXAOTu36OCLe1jCXX jfhA4UYegVngWZXLyOKEjpjcHQhIc6lbm0EnnCmPQSAv8ZokaXCOCZR03IdR4Bj4k30i AO7HazFkQzx+VgymqoF1U6OgQNrbQmew8yMqEBijLjwAmMBCsLHNfJ5C8CZ7SxQBhH7T 6rZA== X-Gm-Message-State: ALoCoQmVLFf980AjmdJIHVPWnNjQ/r0oddjtAOW8d5/+3qF2k+XfOGUeZr0qUPCYo4O2YyprGX7o X-Received: by 10.180.211.84 with SMTP id na20mr14570950wic.41.1417622237134; Wed, 03 Dec 2014 07:57:17 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ec2sm37638016wib.23.2014.12.03.07.57.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Dec 2014 07:57:16 -0800 (PST) Message-ID: <547F3352.3040101@multiplay.co.uk> Date: Wed, 03 Dec 2014 15:59:14 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Horrendous upload network performance with VLAN (download seems OK) References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> In-Reply-To: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 15:57:25 -0000 Have you tried disabling all the various flags VLAN flags on the NIC? On 03/12/2014 15:46, Patrick Proniewski wrote: > Hello, > > I'm running FreeBSD 9.3-RELEASE up-to-date, on two HP Proliant G6 server blades in the same enclosure. One with VLANs in the uplink, the other without VLANs. They use bxe driver. > > bxe0: > mem 0xfb000000-0xfb7fffff,0xfa800000-0xfaffffff irq 28 at device 0.0 on pci2 > bxe0: PCI BAR0 [10] memory allocated: 0xfb000000-0xfb7fffff (8388608) -> 0xfffffe00fb000000 > bxe0: PCI BAR2 [18] memory allocated: 0xfa800000-0xfaffffff (8388608) -> 0xfffffe00fa800000 > bxe0: Found 10GBase-CX4 media. > bxe0: Ethernet address: 00:17:a4:77:04:10 > bxe0: MSI-X vectors Requested 5 and Allocated 5 > ../.. > (and so on up to bxe7) > > Blade A is configured to access the network through a connection without VLANs (the link provided by Network team comes with no VLAN tagging). Its transfer rate is perfect, both up and down. > > ifconfig_bxe0="inet x.y.z.141/24" > defaultrouter="x.y.z.1" > > # ifconfig bxe0 > bxe0: flags=8843 metric 0 mtu 1500 > options=507bb > ether 00:17:a4:77:04:00 > inet x.y.z.141 netmask 0xffffff00 broadcast x.y.z.255 > nd6 options=29 > media: Ethernet autoselect (10Gbase-CX4 ) > status: active > > > Blade B is configured to access the network through a link sporting multiple VLANs, so I've created a network interface that uses one of these VLANs. Ping is OK, I can ssh to this server, transfer rate to the server (down) is not fantastic but OK, enough to perform pkg installation or FreeBSD update. Transfer rate from the server to the rest of the world is abysmal, often stalling after few 100's KB. > > ifconfig_bxe0="UP" > vlans_bxe0="161" > ifconfig_bxe0_161="inet x.y.z.142/24" > defaultrouter="x.y.z.1" > > # ifconfig bxe0 > bxe0: flags=8843 metric 0 mtu 1500 > options=507bb > ether 00:17:a4:77:04:10 > nd6 options=29 > media: Ethernet autoselect (10Gbase-CX4 ) > status: active > > # ifconfig bxe0.161 > bxe0.161: flags=8843 metric 0 mtu 1500 > options=303 > ether 00:17:a4:77:04:10 > inet x.y.z.142 netmask 0xffffff00 broadcast x.y.z.255 > inet6 fe80::217:a4ff:fe77:410%bxe0.161 prefixlen 64 scopeid 0x10 > nd6 options=29 > media: Ethernet autoselect (10Gbase-CX4 ) > status: active > vlan: 161 parent interface: bxe0 > > > The same switch is used by those two blade servers running FreeBSD, and by about 14 other blade servers running VMware ESXi 5.x. > ESXi blades use multiple VLANs and work perfectly. A blade running FreeBSD with no VLAN in its uplink (i.e. not sharing the same uplink as ESXi blades) has very good network performances. The only blade with problem is the one running FreeBSD and sharing the uplink of ESXi blades. > > scp of a 347MB file from an ESXi blade server to FreeBSD blade (same switch, same blade chassis, same uplink): > > # scp esxi11.domain.tld:/tardisks/FILE /dev/null > Password: > FILE 100% 347MB 38.6MB/s 00:09 > > scp of a 347MB file from an FreeBSD blade to ESXi blade (same switch, same blade chassis, same uplink): > > # scp FILE esxi11.domain.tld:/dev/null > Password: > FILE 0% 400KB 172.2KB/s - stalled - > > traceroute from FreeBSD blade to ESXi blade: > > # traceroute esxi11.domain.tld > traceroute to esxi11.domain.tld (x.y.z.151), 64 hops max, 52 byte packets > 1 * * * > 2 * * * > ^C > > traceroute from ESXi blade to FreeBSD blade: > > # traceroute freebsdB.domain.tld > traceroute to freebsdB.domain.tld (x.y.z.142), 30 hops max, 40 byte packets > 1 freebsdB (x.y.z.142) 0.123 ms 0.090 ms 0.078 ms > > I'm quite lost here. > Any idea that would explain the problem, and help me resolve it? > > Original thread posted on > > Patrick > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:06:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02F61D85 for ; Wed, 3 Dec 2014 16:06:00 +0000 (UTC) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "patpro.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA7A6E9F for ; Wed, 3 Dec 2014 16:05:59 +0000 (UTC) Received: from patpro.univ-lyon2.fr (patpro.univ-lyon2.fr [159.84.113.250]) by rack.patpro.net (Postfix) with ESMTPSA id C6EA5A23; Wed, 3 Dec 2014 17:05:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=patpro.net; s=patpro; t=1417622758; bh=1L66i8+VAd1oAJjqmy5pLZgbK7E6uJjm9WvKPJcNaLI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gUiF9ks+EnvdQ39zAkreF6u7iQ9AyMMpyZ9H9JEjH27Qa2E0bQgXLYM/fLU3rAzKX ScsCN1oZRDAWHj5jjblDH/kvu2mfxP+Kq7rkF20DFsd9ALcZme6DxcUzyOcEkMCbUm ezUaLPqs5ffeuV4RPxN16XwPlIeMCj2WDumYyFxw= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Horrendous upload network performance with VLAN (download seems OK) From: Patrick Proniewski In-Reply-To: <547F3352.3040101@multiplay.co.uk> Date: Wed, 3 Dec 2014 17:05:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1510) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:06:00 -0000 I did and it failed, but maybe I've not used the right syntax: # ifconfig bxe0 -vlanmtu ifconfig: -vlanmtu: Invalid argument man bxe makes me think that this driver won't allow this kind of = changes. On 3 d=E9c. 2014, at 16:59, Steven Hartland = wrote: > Have you tried disabling all the various flags VLAN flags on the NIC? >=20 > On 03/12/2014 15:46, Patrick Proniewski wrote: >>=20 >> Blade B is configured to access the network through a link sporting = multiple VLANs, so I've created a network interface that uses one of = these VLANs. Ping is OK, I can ssh to this server, transfer rate to the = server (down) is not fantastic but OK, enough to perform pkg = installation or FreeBSD update. Transfer rate from the server to the = rest of the world is abysmal, often stalling after few 100's KB. >>=20 >> ifconfig_bxe0=3D"UP" >> vlans_bxe0=3D"161" >> ifconfig_bxe0_161=3D"inet x.y.z.142/24" >> defaultrouter=3D"x.y.z.1" >>=20 >> # ifconfig bxe0 >> bxe0: flags=3D8843 = metric 0 mtu 1500 >> = options=3D507bb >> ether 00:17:a4:77:04:10 >> nd6 options=3D29 >> media: Ethernet autoselect (10Gbase-CX4 ) >> status: active >>=20 >> # ifconfig bxe0.161 >> bxe0.161: flags=3D8843 = metric 0 mtu 1500 >> options=3D303 >> ether 00:17:a4:77:04:10 >> inet x.y.z.142 netmask 0xffffff00 broadcast x.y.z.255 >> inet6 fe80::217:a4ff:fe77:410%bxe0.161 prefixlen 64 scopeid = 0x10 >> nd6 options=3D29 >> media: Ethernet autoselect (10Gbase-CX4 ) >> status: active >> vlan: 161 parent interface: bxe0 From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:15:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BCEA372 for ; Wed, 3 Dec 2014 16:15:53 +0000 (UTC) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC99861 for ; Wed, 3 Dec 2014 16:15:52 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop04.sare.net (Postfix) with ESMTPSA id E86249DE716; Wed, 3 Dec 2014 17:09:25 +0100 (CET) Subject: Re: Horrendous upload network performance with VLAN (download seems OK) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Borja Marcos In-Reply-To: <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> Date: Wed, 3 Dec 2014 17:09:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> To: Patrick Proniewski X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org, Steven Hartland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:15:53 -0000 On Dec 3, 2014, at 5:05 PM, Patrick Proniewski wrote: > I did and it failed, but maybe I've not used the right syntax: >=20 > # ifconfig bxe0 -vlanmtu > ifconfig: -vlanmtu: Invalid argument >=20 > man bxe makes me think that this driver won't allow this kind of = changes. Although there's no guarantee it will solve your issues, try disabling = LRO and TSO. I've found situations in which they do more harm than good, = depending on the particular card and driver. Anyway it's a cheap experiment :) Borja. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:21:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18FFA816 for ; Wed, 3 Dec 2014 16:21:48 +0000 (UTC) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "patpro.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF1011C8 for ; Wed, 3 Dec 2014 16:21:47 +0000 (UTC) Received: from patpro.univ-lyon2.fr (patpro.univ-lyon2.fr [159.84.113.250]) by rack.patpro.net (Postfix) with ESMTPSA id AD9E0A77; Wed, 3 Dec 2014 17:21:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=patpro.net; s=patpro; t=1417623706; bh=cfhpG7iIwwkkmXkJCdGrJmzeGKgGn4TqHbBzkLQZSvE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=XURXoK0bzpS+zSXlVwmyFRCHtbtoO1j7D5Zocd6I/GvJ59MQ0bR2Y6BuZpIuo5msg ZWvkjp4crdJzBapMSZ2nRodgmXruIxZNDls0qJOzvYV8Psvcy3UIpWv9j03AWTLerQ tFVeZLpgwMn/IVX87UOuJglcevV1XQDwrGWzfoOM= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Horrendous upload network performance with VLAN (download seems OK) From: Patrick Proniewski In-Reply-To: Date: Wed, 3 Dec 2014 17:21:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> To: Borja Marcos X-Mailer: Apple Mail (2.1510) Cc: freebsd-net@freebsd.org, Steven Hartland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:21:48 -0000 On 3 d=E9c. 2014, at 17:09, Borja Marcos wrote: > On Dec 3, 2014, at 5:05 PM, Patrick Proniewski wrote: >=20 >> I did and it failed, but maybe I've not used the right syntax: >>=20 >> # ifconfig bxe0 -vlanmtu >> ifconfig: -vlanmtu: Invalid argument >>=20 >> man bxe makes me think that this driver won't allow this kind of = changes. >=20 > Although there's no guarantee it will solve your issues, try disabling = LRO and TSO. I've found situations in which they do more harm than good, = depending on the particular card and driver. >=20 > Anyway it's a cheap experiment :) Sure.=20 Same result unfortunately. I've made few tcpdump experiments during my scp upload tests. One on = bxe0 that shows a lot of packets for the LLC protocol, and one on = bxe0.161 that shows many "suspected TCP retransmissions", and very few = LLC packet (6 in about 350 packets of this capture). Patrick= From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:25:42 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3302A88 for ; Wed, 3 Dec 2014 16:25:42 +0000 (UTC) Received: from cu01176a.smtpx.saremail.com (cu01176a.smtpx.saremail.com [195.16.150.151]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F73922F for ; Wed, 3 Dec 2014 16:25:42 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 2924B9DE5FC; Wed, 3 Dec 2014 17:25:33 +0100 (CET) Subject: Re: Horrendous upload network performance with VLAN (download seems OK) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Borja Marcos In-Reply-To: Date: Wed, 3 Dec 2014 17:25:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> To: Patrick Proniewski X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org, Steven Hartland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:25:42 -0000 On Dec 3, 2014, at 5:21 PM, Patrick Proniewski wrote: > On 3 d=E9c. 2014, at 17:09, Borja Marcos wrote: >=20 >> On Dec 3, 2014, at 5:05 PM, Patrick Proniewski wrote: >>=20 >>> I did and it failed, but maybe I've not used the right syntax: >>>=20 >>> # ifconfig bxe0 -vlanmtu >>> ifconfig: -vlanmtu: Invalid argument >>>=20 >>> man bxe makes me think that this driver won't allow this kind of = changes. >>=20 >> Although there's no guarantee it will solve your issues, try = disabling LRO and TSO. I've found situations in which they do more harm = than good, depending on the particular card and driver. >>=20 >> Anyway it's a cheap experiment :) >=20 > Sure.=20 > Same result unfortunately. >=20 > I've made few tcpdump experiments during my scp upload tests. One on = bxe0 that shows a lot of packets for the LLC protocol, and one on = bxe0.161 that shows many "suspected TCP retransmissions", and very few = LLC packet (6 in about 350 packets of this capture). I forgot, sorry. Sometimes you need to set the interface to down and up = again to make sure changes to flags such as LRO and TSO have been = applied :/ TSO can be disabled in a global way using a sysctl variable: = net.inet.tcp.tso Borja. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:27:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2525B86 for ; Wed, 3 Dec 2014 16:27:10 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FC4925F for ; Wed, 3 Dec 2014 16:27:10 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so20083372wgh.24 for ; Wed, 03 Dec 2014 08:27:09 -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:content-transfer-encoding; bh=SsgVtYYRU1ZQsNAI20+OvNil/8PNrhLKQwXTViZuf5o=; b=ubcD5cqLk11QRdlwOWJlhP0JBhJgRZC31m/17uJmgpAetFie9A52/DR2VEDbE1Mooi JYK6Sz78wdrfUSGoaDVVxHG+RlmF2ge61DdOhcS8ZPP1gaL8q59Xe9brTVBkF/JbOcYY LuSjdTlvmqbppMlNEatXKyQ0QfX7EAaey9lQxLTsoXkxB9sn7JRHuCAaI8Z28D4C4mhO F7Hlxs5J9GEHiWj8kodlyFZhrJ2E6v1SMU9etU9eWVu5erlwxOeoU3Bnv0setEvTnt2o wIYHSACnGPVmzlij3UWS6ZcZ1pyab6XlwSX5aoEqcwnnwbDLsH+x9Lv4UmjswsxbikAK 3BaQ== MIME-Version: 1.0 X-Received: by 10.180.240.201 with SMTP id wc9mr14386847wic.59.1417624028946; Wed, 03 Dec 2014 08:27:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 3 Dec 2014 08:27:08 -0800 (PST) In-Reply-To: References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> Date: Wed, 3 Dec 2014 08:27:08 -0800 X-Google-Sender-Auth: LIxFoLExPka_UWNJSj0w1q2eOrE Message-ID: Subject: Re: Horrendous upload network performance with VLAN (download seems OK) From: Adrian Chadd To: Borja Marcos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Steven Hartland , Patrick Proniewski X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:27:11 -0000 hi, try dropping the MSS of the connection down. I wonder if you're hitting some frame size cap when transmitting - adding a VLAN header adds a few bytes to the size of the frame. If the NIC is enforcing some maximum frame transmit size then it may be failing to transmit things. -adrian On 3 December 2014 at 08:25, Borja Marcos wrote: > > On Dec 3, 2014, at 5:21 PM, Patrick Proniewski wrote: > >> On 3 d=C3=A9c. 2014, at 17:09, Borja Marcos wrote: >> >>> On Dec 3, 2014, at 5:05 PM, Patrick Proniewski wrote: >>> >>>> I did and it failed, but maybe I've not used the right syntax: >>>> >>>> # ifconfig bxe0 -vlanmtu >>>> ifconfig: -vlanmtu: Invalid argument >>>> >>>> man bxe makes me think that this driver won't allow this kind of chang= es. >>> >>> Although there's no guarantee it will solve your issues, try disabling = LRO and TSO. I've found situations in which they do more harm than good, de= pending on the particular card and driver. >>> >>> Anyway it's a cheap experiment :) >> >> Sure. >> Same result unfortunately. >> >> I've made few tcpdump experiments during my scp upload tests. One on bxe= 0 that shows a lot of packets for the LLC protocol, and one on bxe0.161 tha= t shows many "suspected TCP retransmissions", and very few LLC packet (6 in= about 350 packets of this capture). > > I forgot, sorry. Sometimes you need to set the interface to down and up a= gain to make sure changes to flags such as LRO and TSO have been applied :/ > > TSO can be disabled in a global way using a sysctl variable: net.inet.tcp= .tso > > > > > > Borja. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:31:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7013BE48 for ; Wed, 3 Dec 2014 16:31:01 +0000 (UTC) Received: from forward20.mail.yandex.net (forward20.mail.yandex.net [IPv6:2a02:6b8:0:1402::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2670B623 for ; Wed, 3 Dec 2014 16:31:01 +0000 (UTC) Received: from web23g.yandex.ru (web23g.yandex.ru [95.108.253.232]) by forward20.mail.yandex.net (Yandex) with ESMTP id CCD63104126E for ; Wed, 3 Dec 2014 19:30:47 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web23g.yandex.ru (Yandex) with ESMTP id 5CDB932010C1; Wed, 3 Dec 2014 19:30:47 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417624247; bh=djKmER3z8UTKgf0wMq4EBg3ECaO9Sd9qOkwhD+v8Mk4=; h=From:To:Subject:Date; b=G/Vg7Pk7zQ1LBXiVJSdAe4ZEhKq+1aYv6STanYWGjCQA9uvA1s6FqWB/Cn6E+rxWF ba1AWqkSLtf2d+HO/2NifPStATMWF6fnRHFdldFO8FWjDgDt+O7GG+SbSJLrCR0Uoc CmFtVeiKwqbzvUM69SWHhAXceE0IDl7OD60sGM6U= Received: from 92b91f64.rdns.100tb.com (92b91f64.rdns.100tb.com [146.185.31.100]) by web23g.yandex.ru with HTTP; Wed, 03 Dec 2014 19:30:47 +0300 From: Martin Hanson To: freebsd-net@freebsd.org Subject: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <1511041417624247@web23g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 03 Dec 2014 17:30:47 +0100 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:31:01 -0000 Hi I got a small Intel Atom N280 box I wanted to use as a PF firewall. It has one Intel NIC that gets registered as "bge0", then it has three USB->NIC dongles with the ASIX AX88179 chipset which gets registered as "ue0", "ue1" and "ue2". I have set each device to a static IP during boot. The problem is however that upon boot the devices gets switched. So first boot: | USB DONGLE 1 | UE0 | 192.168.1.1 | | USB DONGLE 2 | UE1 | 192.168.2.1 | | USB DONGLE 3 | UE2 | 192.168.3.1 | Next boot: | USB DONGLE 1 | UE1 | 192.168.2.1 | | USB DONGLE 2 | UE2 | 192.168.3.1 | | USB DONGLE 3 | UE0 | 192.168.1.1 | Upon each boot the order changed, there is no fixed pattern. This is a major problem as the device *still* has the right name and the right IP, but it is as though it has been physically removed from the slot and changed place. Is it somehow possible to deal with this problem? pciconf doesn't display those devices. Kind regards Martin From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 16:32:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 141C3148 for ; Wed, 3 Dec 2014 16:32:15 +0000 (UTC) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D02D79E for ; Wed, 3 Dec 2014 16:32:14 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id h11so24969194wiw.9 for ; Wed, 03 Dec 2014 08:32:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fgpMQYcmFrSf3SZw3CcjwzD2XpntKzNje8ov4cI37xg=; b=KPLv5ecjMMZuBXwYL0Ara8QwjYP0d1jViKgkWR05v8BbITnn4wGNyjo7kYNCY3FwWz pMY/Ek7eAvGkwYE2NvgvV6GOzu8aQTAGlNA3Bz+cFXhQtIMpNMp/rdQumm3GN6qyKRIa w5ijSOrzEhkcdOSCcDyv+28lfREVRPYuSU5hCvVHox17XdW4w14UHmgoVcRTB50JJfOK zrd6IePv+s46BbbCqZYXa+HZdNAiTZY2oj8Q+oPXvsXqen5l+q9xotv20+azOaPE5FLw rSU5/grsAqG0RNpe6tgE8nhXMsnD40rB1F8lhxwi9tzrRKI7fPZOPIBQmD28iDdnOnsU 3eXg== X-Gm-Message-State: ALoCoQnNgu7/J6iXqwJPsskJTeER/93D0GB6LXgB3nlMZBg45DBQ8jVV9GwpOxfDqw5VMg1tPfEH X-Received: by 10.180.96.227 with SMTP id dv3mr22576454wib.50.1417624326956; Wed, 03 Dec 2014 08:32:06 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id g16sm36931339wjq.20.2014.12.03.08.32.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Dec 2014 08:32:06 -0800 (PST) Message-ID: <547F3B7C.8020309@multiplay.co.uk> Date: Wed, 03 Dec 2014 16:34:04 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Patrick Proniewski Subject: Re: Horrendous upload network performance with VLAN (download seems OK) References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> In-Reply-To: <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 16:32:15 -0000 Looks like bxe does support setting vlanhwtso so might want to try disabling that one just in case. On 03/12/2014 16:05, Patrick Proniewski wrote: > I did and it failed, but maybe I've not used the right syntax: > > # ifconfig bxe0 -vlanmtu > ifconfig: -vlanmtu: Invalid argument > > man bxe makes me think that this driver won't allow this kind of changes. > > From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 17:32:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FA2CD66 for ; Wed, 3 Dec 2014 17:32:19 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43832FC4 for ; Wed, 3 Dec 2014 17:32:18 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sB3HWGQJ035980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Dec 2014 10:32:17 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sB3HWGNp035977; Wed, 3 Dec 2014 10:32:16 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 3 Dec 2014 10:32:16 -0700 (MST) From: Warren Block To: Martin Hanson Subject: Re: NICs devices switches "pshycial" place on each boot In-Reply-To: <1511041417624247@web23g.yandex.ru> Message-ID: References: <1511041417624247@web23g.yandex.ru> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 03 Dec 2014 10:32:17 -0700 (MST) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 17:32:19 -0000 On Wed, 3 Dec 2014, Martin Hanson wrote: > I got a small Intel Atom N280 box I wanted to use as a PF firewall. > > It has one Intel NIC that gets registered as "bge0", That would be Broadcom. > then it has three > USB->NIC dongles with the ASIX AX88179 chipset which gets registered > as "ue0", "ue1" and "ue2". > > I have set each device to a static IP during boot. > > The problem is however that upon boot the devices gets switched. > > So first boot: > > | USB DONGLE 1 | UE0 | 192.168.1.1 | > | USB DONGLE 2 | UE1 | 192.168.2.1 | > | USB DONGLE 3 | UE2 | 192.168.3.1 | > > Next boot: > > | USB DONGLE 1 | UE1 | 192.168.2.1 | > | USB DONGLE 2 | UE2 | 192.168.3.1 | > | USB DONGLE 3 | UE0 | 192.168.1.1 | > > Upon each boot the order changed, there is no fixed pattern. Right, USB devices are detected dynamically, and the order is not guaranteed. > This is a major problem as the device *still* has the right name and the > right IP, but it is as though it has been physically removed from the > slot and changed place. > > Is it somehow possible to deal with this problem? > > pciconf doesn't display those devices. usbconfig will show the USB devices, 'usbconfig -d 0.3 dump_device_desc' shows output from device 0.3. It might be possible to assign a unique name to each with 'ifconfig name' when they are detected by devd. That would depend on some unique ID for each that can be detected by devd. If they are all the same brand and model, vendor and product ID will not help. Serial number is often not set on USB devices. MAC address would work, if that is passed to devd. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 18:37:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF925209 for ; Wed, 3 Dec 2014 18:37:45 +0000 (UTC) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "patpro.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 701029FB for ; Wed, 3 Dec 2014 18:37:45 +0000 (UTC) Received: from [192.168.0.2] (boleskine.patpro.net [82.230.142.222]) by rack.patpro.net (Postfix) with ESMTPSA id BE7E5B2A; Wed, 3 Dec 2014 19:37:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=patpro.net; s=patpro; t=1417631860; bh=IICVcgt4a04V7CW4dj67GgbWHduoNc2bBAjqu1uSE3Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=aOcvrdVOjod7EPu3oPWYJpQY+5tz6IeGpJVHloo2pvd4ksVhbVV/p8fEBxemPe0EL tdPaLUS63lXPBOA3IJZy2hTVMIhObbqb77FapbNBRwMx9SIbeliXfruY061IajJLd9 IneQZaiJ0cKD8HxZLsgeHnZZhvwJR1y9Lu1UlhVA= Subject: Re: Horrendous upload network performance with VLAN (download seems OK) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Patrick Proniewski In-Reply-To: Date: Wed, 3 Dec 2014 19:37:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <270646ED-17A4-4811-A269-3C813016015C@patpro.net> References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> To: Borja Marcos X-Mailer: Apple Mail (2.1085) Cc: freebsd-net@freebsd.org, Steven Hartland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 18:37:45 -0000 On 03 d=E9c. 2014, at 17:25, Borja Marcos wrote: > I forgot, sorry. Sometimes you need to set the interface to down and = up again to make sure changes to flags such as LRO and TSO have been = applied :/ >=20 > TSO can be disabled in a global way using a sysctl variable: = net.inet.tcp.tso what is the proper syntax in rc.conf to disable tso and lro at boot = time? Will try with vlanhwtso too, as Steven mentioned. Currently I use: ifconfig_bxe0=3D"UP" vlans_bxe0=3D"161" ifconfig_bxe0_161=3D"inet x.y.z.142/24" defaultrouter=3D"x.y.z.1" ifconfig_bxe0=3D"UP" triggers an error at boot time, "ifconfig: UP: bad = value", but if I put no value, bxe0 stays down and bxe0.161 won't come = up. I work remotely, so having a functioning network after boot is more = comfortable. Patrick= From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 19:21:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CF3EE8B for ; Wed, 3 Dec 2014 19:21:12 +0000 (UTC) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53B41F25 for ; Wed, 3 Dec 2014 19:21:12 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fb1so16468592pad.27 for ; Wed, 03 Dec 2014 11:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=from:content-type:subject:message-id:date:to:mime-version; bh=Jj5YR6rEsO3NUFMkJAxoeamYT+ndMluO5Gqa3Ko65gE=; b=Wx7Y7tOs7Na9CcB/VdjXiFoaQ+D1jg+paEdnaWcf2x8EG4D2Kf3hBmtlXqSjeQolXR Ls3q0BxKk+W8gS9qXp3b9SjKS3ug0D84bsLipoN6GkorG6n4BWtPsdMCr3aGTLOIqpOS 8QdGOxuFLwxLlJF2hSF+Sy8f5OakHlCb9Njpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=Jj5YR6rEsO3NUFMkJAxoeamYT+ndMluO5Gqa3Ko65gE=; b=WsPWm4NdNrHecwTorDKgSmAiZLrF2GT3lYOPLwHsBIbA5yS/rN7pY45/eAwJDxXkTO /r7Fq5mHi1Pgt1XLQgHQmpmFc6y25wmH+tghA9Wft9y3HFvCu4Pk/WxjL9Mdn4yFIk9e OK4DuMoq9xAHBlctmIq3lGJ+c3aiUhmF3GRTDiFetRcn4ZGbHhfQDxWXkPBa7ty5rjG1 KcxciS5VSNX6rfYsxjhLbWMjFE6C87W0g0W8G6mMEmPCkPOghO4ONiFV+SKrh9eN1LEv lIruwYie1s+Kbuq4fglsS31KBCuQLYxVgIkUROQh7vb7QXwTAuzlW9wTYym0X0I1GtRN 15Mw== X-Gm-Message-State: ALoCoQlKjT6oK6rWeY6mOiQw8SvhQKJw0zIgap+GnmEhJ1Ra9071AmdYd5R9bbSnyFSi46MjygxG X-Received: by 10.66.246.130 with SMTP id xw2mr11331018pac.55.1417634471536; Wed, 03 Dec 2014 11:21:11 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id r3sm23852838pds.57.2014.12.03.11.21.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 11:21:10 -0800 (PST) From: "David P. Discher" Content-Type: multipart/signed; boundary="Apple-Mail=_62604F9E-4BAF-4036-B6EC-96248FA92ACE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working Message-Id: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> Date: Wed, 3 Dec 2014 11:21:20 -0800 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 19:21:12 -0000 --Apple-Mail=_62604F9E-4BAF-4036-B6EC-96248FA92ACE Content-Type: multipart/mixed; boundary="Apple-Mail=_49EE7AB1-E37F-4593-A717-DADC68002AB9" --Apple-Mail=_49EE7AB1-E37F-4593-A717-DADC68002AB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey Net - In probably a poor, cheap choice, I picked up a TP-Link TL-SG2008 = Desktop Smart Switch, which supports LACP/802.3ad. I=92m currently = running 10.1-STABLE r274577 on the machine I=92m testing with. I=92m = testing right now with just 1 port (two ports didn=92t work either.).=20 Hardware is Supermicro X7DB8. em1: port 0x2020-0x203f mem = 0xd8260000-0xd827ffff,0xd8240000-0xd825ffff irq 19 at device 0.1 on pci6 em1@pci0:6:0:1: class=3D0x020000 card=3D0x109615d9 chip=3D0x10968086 = rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '80003ES2LAN Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet > ifconfig lagg0 lagg0: flags=3D8843 metric 0 mtu = 1500 = options=3D4219b ether 00:30:48:35:cc:25 inet 10.1.10.150 netmask 0xffffff00 broadcast 10.1.10.255 nd6 options=3D29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: em1 flags=3D0<> Setting net.link.lagg.lacp.debug=3D2, here is the output from the the = host trying to negotiate :=20 em1: lacp_sm_rx_update_default_selected em1: lacp_sm_rx_update_selected_from_peerinfo em1: lacp_sm_rx_record_default em1: lacp_sm_mux: state=3D 0x1, selected=3D 0x0, p_sync=3D 0x0, = p_collecting=3D 0x0 em1: lacpdu transmit actor=3D(8000,00-30-48-35-CC-25,008B,8000,0002) actor.state=3D45 partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) partner.state=3D0 maxdelay=3D0 em1: lacp_sm_mux: state=3D 0x0, selected=3D 0x2, p_sync=3D 0x0, = p_collecting=3D 0x0 em1: lacp_sm_mux: state=3D 0x1, selected=3D 0x2, p_sync=3D 0x0, = p_collecting=3D 0x0 em1: lacp_sm_mux: state=3D 0x1, selected=3D 0x2, p_sync=3D 0x0, = p_collecting=3D 0x0 em1: lacpdu transmit actor=3D(8000,00-30-48-35-CC-25,008B,8000,0002) actor.state=3D4d partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) partner.state=3D0 maxdelay=3D0 em1: lacp_sm_mux: state=3D 0x2, selected=3D 0x2, p_sync=3D 0x0, = p_collecting=3D 0x0 em1: lacp_sm_mux: state=3D 0x2, selected=3D 0x2, p_sync=3D 0x0, = p_collecting=3D 0x0 em1: lacp_sm_mux: state=3D 0x2, selected=3D 0x2, p_sync=3D 0x0, = p_collecting=3D 0x0 [...] Not sure if the attachment will work to the list, but here is a pcap = attached em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the = lagg0 with tcpdump, filters out the freebsd=92s LACP packets, but still = sees the TP-Link=92s packets.=20 - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 --Apple-Mail=_49EE7AB1-E37F-4593-A717-DADC68002AB9 Content-Disposition: attachment; filename=lacp.pcap Content-Type: application/octet-stream; name="lacp.pcap" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAo3t+VLiMAwCAAAAAgAAAAAGAwgAAAujeJ/2aqYgJAQEB FIAA6N4n/ZqpBqCAAAAFxQAAAAIUgAAAMEg1zCUAi4AAAAJHAAAAAxAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAMWCso3t+ VBigCwB8AAAAfAAAAAGAwgAAAgAwSDXMJYgJAQEBFIAAADBINcwlAIuAAAACRQAAAAIU//8AAAAA AAAAAP//AAAAAAAAAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACje35U0aQLAIAAAACAAAAAAYDCAAAC6N4n/ZqpiAkBAQEU gADo3if9mqkGoIAAAAUFAAAAAhSAAAAwSDXMJQCLgAAAAkUAAAADEAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZCke35U sHkEAIAAAACAAAAAAYDCAAAC6N4n/ZqpiAkBAQEUgADo3if9mqkGoIAAAAUFAAAAAhSAAAAwSDXM JQCLgAAAAkUAAAADEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAxYdSke35UqhQMAHwAAAB8AAAAAYDCAAACADBINcwliAkB AQEUgAAAMEg1zCUAi4AAAAJFAAAAAhT//wAAAAAAAAAA//8AAAAAAAADEAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKR7flRF GQwAgAAAAIAAAAABgMIAAALo3if9mqmICQEBARSAAOjeJ/2aqQaggAAABQUAAAACFIAAADBINcwl AIuAAAACRQAAAAMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkKV7flTsjAwAfAAAAHwAAAABgMIAAAIAMEg1zCWICQEB ARSAAAAwSDXMJQCLgAAAAk0AAAACFP//AAAAAAAAAAD//wAAAAAAAAMQAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApXt+VCOR DACAAAAAgAAAAAGAwgAAAujeJ/2aqYgJAQEBFIAA6N4n/ZqpBqCAAAAFBQAAAAIUgAAAMEg1zCUA i4AAAAJFAAAAAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQwnt+VBh6BACAAAAAgAAAAAGAwgAAAujeJ/2aqYgJAQEB FIAA6N4n/ZqpBqCAAAAFBQAAAAIUgAAAMEg1zCUAi4AAAAJFAAAAAxAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAMWHUw3t+ VFUuAQB8AAAAfAAAAAGAwgAAAgAwSDXMJYgJAQEBFIAAADBINcwlAIuAAAACTQAAAAIU//8AAAAA AAAAAP//AAAAAAAAAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDe35UiTIBAIAAAACAAAAAAYDCAAAC6N4n/ZqpiAkBAQEU gADo3if9mqkGoIAAAAUFAAAAAhSAAAAwSDXMJQCLgAAAAkUAAAADEAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZA= --Apple-Mail=_49EE7AB1-E37F-4593-A717-DADC68002AB9 Content-Disposition: attachment; filename=lacp-lagg0.pcap Content-Type: application/octet-stream; name="lacp-lagg0.pcap" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAP//AAABAAAA8Ht+VFTkCACAAAAAgAAAAAGAwgAAAujeJ/2aqYgJAQEB FIAA6N4n/ZqpC2CAAAAFxQAAAAIUgAAAMEg1zCUAi4AAAAJHAAAAAxAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAl/HE8Xt+ VFNfAwCAAAAAgAAAAAGAwgAAAujeJ/2aqYgJAQEBFIAA6N4n/ZqpC2CAAAAFBQAAAAIUgAAAMEg1 zCUAi4AAAAJFAAAAAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQ8Xt+VBUOCQCAAAAAgAAAAAGAwgAAAujeJ/2aqYgJ AQEBFIAA6N4n/ZqpC2CAAAAFBQAAAAIUgAAAMEg1zCUAi4AAAAJFAAAAAxAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAMWHU 83t+VL71AwCAAAAAgAAAAAGAwgAAAujeJ/2aqYgJAQEBFIAA6N4n/ZqpC2CAAAAFBQAAAAIUgAAA MEg1zCUAi4AAAAJFAAAAAxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGQAHx+VKXlBQCAAAAAgAAAAAGAwgAAAujeJ/2a qYgJAQEBFIAA6N4n/ZqpC2CAAAAFBQAAAAIUgAAAMEg1zCUAi4AAAAJFAAAAAxAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAGQ --Apple-Mail=_49EE7AB1-E37F-4593-A717-DADC68002AB9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_49EE7AB1-E37F-4593-A717-DADC68002AB9-- --Apple-Mail=_62604F9E-4BAF-4036-B6EC-96248FA92ACE 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 iQEcBAEBCgAGBQJUf2KxAAoJEEmwU6XuhYWOxDsH/1TjtTRgeWi4Hk7LIXgvTLqF JqXmRHXLLbYvFNvVZl1/IQMNF06TQEyR0stODlxbdMtEJHLeg2MitIBVwCpotPuG XFyTHS3CIu5t0+Z+ZWMdvUGUiOeog9xiFB21FOP9dFZg+3lK+6Sai5opLcsNerjm V6OfELCtxX56MbGwXGUobYeh6gq0Zs3/5CChYy1+UFDiPunItAeGLjf1yQs8vsMa hgz1lT+mRaiXD5BCbDHYKEdyAFt6TXxb8sAT70jSX94jExbpfPonzasPFfj3Ktzi ogm8dXYTrBYmzh85Zkywxzmv0E0GyKTC/pw1XcXFewG7wwe5zTNeVjyk6uQg/BM= =7Czn -----END PGP SIGNATURE----- --Apple-Mail=_62604F9E-4BAF-4036-B6EC-96248FA92ACE-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 20:12:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 167D1E14 for ; Wed, 3 Dec 2014 20:12:14 +0000 (UTC) Received: from forward4m.mail.yandex.net (forward4m.mail.yandex.net [IPv6:2a02:6b8:0:2519::3:13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD5FF77E for ; Wed, 3 Dec 2014 20:12:13 +0000 (UTC) Received: from web10m.yandex.ru (web10m.yandex.ru [37.140.138.101]) by forward4m.mail.yandex.net (Yandex) with ESMTP id CA5DF2320CEC; Wed, 3 Dec 2014 23:12:09 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web10m.yandex.ru (Yandex) with ESMTP id 2323D24A0EA3; Wed, 3 Dec 2014 23:12:09 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417637529; bh=8ssQMakBpkjOCp2OBkoXrfIBDdFFtvxmTyNyb2C+8UQ=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=HeyYUQ48cg4yTTz6TCSjJmlANWYCvgtG7ZvhnXi7OtlqNGgSn69TPi8awi4XjX8g0 ZLNzt0XCQiIcwfGK6R8Fb/rqUOpcb0fZ5w+NvHxQrhPVRtNG293OVqeReHpLp45qnh dqWfJWV9GodjV9T3V/6ToDsOiXMy9CAFodoSpOKo= Received: from 108.61.122.153.choopa.net (108.61.122.153.choopa.net [108.61.122.153]) by web10m.yandex.ru with HTTP; Wed, 03 Dec 2014 23:12:08 +0300 From: Martin Hanson To: Warren Block In-Reply-To: References: <1511041417624247@web23g.yandex.ru> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <322331417637528@web10m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 03 Dec 2014 21:12:08 +0100 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 20:12:14 -0000 >> šThis is a major problem as the device *still* has the right name and the >> šright IP, but it is as though it has been physically removed from the >> šslot and changed place. >> >> šIs it somehow possible to deal with this problem? >> >> špciconf doesn't display those devices. > > usbconfig will show the USB devices, 'usbconfig -d 0.3 dump_device_desc' > shows output from device 0.3. šIt might be possible to assign a unique > name to each with 'ifconfig name' when they are detected by devd. šThat > would depend on some unique ID for each that can be detected by devd. > If they are all the same brand and model, vendor and product ID will not > help. šSerial number is often not set on USB devices. šMAC address would > work, if that is passed to devd. Thank you very much, brought me so much closer to a solution. I don't think MAC address is passed to devd, but each device does have a unique serial number, but I am unable to determine how exactly to go about fixing a device name to a specific serial number. Kind regards. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 21:29:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78505C6E for ; Wed, 3 Dec 2014 21:29:40 +0000 (UTC) Received: from forward1h.mail.yandex.net (forward1h.mail.yandex.net [IPv6:2a02:6b8:0:f05::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BB70ED0 for ; Wed, 3 Dec 2014 21:29:39 +0000 (UTC) Received: from web20h.yandex.ru (web20h.yandex.ru [84.201.186.49]) by forward1h.mail.yandex.net (Yandex) with ESMTP id 584C89E21AB for ; Thu, 4 Dec 2014 00:28:55 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web20h.yandex.ru (Yandex) with ESMTP id C4F701320B28; Thu, 4 Dec 2014 00:28:54 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417642134; bh=bq1vE0qFaqBM9Ng276xjvYYFD/nFXPc7YGKoPboA8zs=; h=From:Cc:In-Reply-To:References:Subject:Date; b=MzMPsI5RZWz7GyvmxfjzTjtOUQMdsyJP2Rrrge3ONAeTp798qt1F00UPQuT3R1qRM hZk3i7sHK8frcAkKWAd8EpBZoxogs+rVV7ljvXQV6f4O8pO/c9fBNKLQ/i30P42/PW uCI7wcY/gI0iT3socRwtkKp0y9JhRGuiUn0GjVc0= Received: from 108.61.122.153.choopa.net (108.61.122.153.choopa.net [108.61.122.153]) by web20h.yandex.ru with HTTP; Thu, 04 Dec 2014 00:28:54 +0300 From: Martin Hanson Cc: "freebsd-net@freebsd.org" In-Reply-To: References: <1511041417624247@web23g.yandex.ru> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <212351417642134@web20h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 03 Dec 2014 22:28:54 +0100 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 21:29:40 -0000 I have tried setting this up in /usr/local/etc/devd/devd.conf and used "devd -d" to re-read rules. attach 100 { device-name "ue0"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249b0de00c"; action "ifconfig $device-name inet 192.168.1.1 netmask 255.255.255.0"; } I have also tried with a notify and changing the value to 0, but the device doesn't get the IP set when plugged in. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 22:20:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96598D27 for ; Wed, 3 Dec 2014 22:20:02 +0000 (UTC) Received: from rack.patpro.net (rack.patpro.net [193.30.227.216]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "patpro.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56934685 for ; Wed, 3 Dec 2014 22:20:02 +0000 (UTC) Received: from [192.168.0.2] (boleskine.patpro.net [82.230.142.222]) by rack.patpro.net (Postfix) with ESMTPSA id EC840C3D; Wed, 3 Dec 2014 23:19:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=patpro.net; s=patpro; t=1417645199; bh=PUitY7DYmW5AdODI/m6AzGkwK4b9xJDIWGUKJ3TK+4w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=V1Ch/FwYYErQkxuVYJkH7d1aMzjF5j66+tH+SBojePxWwSoRtN2Qu9/mqFToXmy4J cO/j08gvar7YgS33iXPZGCDrOyUYXySlO5qdjrDWWyabXwRTXYJVGCt2dMLpS9eNZs 5Sup5UwuiILH3dAvZtm4bRiTFXRqxGvKFA2jEJWw= Subject: Re: Horrendous upload network performance with VLAN (download seems OK) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Patrick Proniewski In-Reply-To: Date: Wed, 3 Dec 2014 23:19:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <998EBE7C-A619-41AA-9561-7276CDFF24A9@patpro.net> References: <727AB395-CF83-4D13-A2C3-50969C2969B0@patpro.net> <547F3352.3040101@multiplay.co.uk> <43C2162E-2B9F-437F-B4CF-E792CEC5DA7B@patpro.net> To: Borja Marcos X-Mailer: Apple Mail (2.1085) Cc: freebsd-net@freebsd.org, Steven Hartland X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 22:20:02 -0000 On 03 d=E9c. 2014, at 17:25, Borja Marcos wrote: > TSO can be disabled in a global way using a sysctl variable: = net.inet.tcp.tso That's it! I've set net.inet.tcp.tso to 0 in /etc/sysctl.conf, rebooted = -> Problem solved: # sysctl net.inet.tcp.tso net.inet.tcp.tso: 0 # scp FILE esxi11.domain.tld:/dev/null Password:=20 FILE 100% 347MB 19.3MB/s = 00:18 Thanks a lot for your help. Patrick= From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 23:03:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8697549B for ; Wed, 3 Dec 2014 23:03:15 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E310B7D for ; Wed, 3 Dec 2014 23:03:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sB3N3CEx017743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Dec 2014 16:03:12 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sB3N3CGP017667; Wed, 3 Dec 2014 16:03:12 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 3 Dec 2014 16:03:12 -0700 (MST) From: Warren Block To: Martin Hanson Subject: Re: NICs devices switches "pshycial" place on each boot In-Reply-To: <212351417642134@web20h.yandex.ru> Message-ID: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 03 Dec 2014 16:03:12 -0700 (MST) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 03 Dec 2014 23:03:15 -0000 On Wed, 3 Dec 2014, Martin Hanson wrote: > I have tried setting this up in /usr/local/etc/devd/devd.conf and used "devd -d" to re-read rules. > > attach 100 { > device-name "ue0"; > match "vendor" "0x0b95"; > match "product" "0x1790"; > match "sernum" "0000249b0de00c"; > action "ifconfig $device-name inet 192.168.1.1 netmask 255.255.255.0"; > } > > I have also tried with a notify and changing the value to 0, but the device doesn't get the IP set when plugged in. It might need a delay before the device is ready. Running devd in the foreground like that will show all the detected events. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 03:51:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0F477A8 for ; Thu, 4 Dec 2014 03:51:44 +0000 (UTC) Received: from forward4m.mail.yandex.net (forward4m.mail.yandex.net [IPv6:2a02:6b8:0:2519::3:13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 631C7DE9 for ; Thu, 4 Dec 2014 03:51:44 +0000 (UTC) Received: from web17m.yandex.ru (web17m.yandex.ru [37.140.138.108]) by forward4m.mail.yandex.net (Yandex) with ESMTP id 2A7BC2321286; Thu, 4 Dec 2014 06:51:41 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web17m.yandex.ru (Yandex) with ESMTP id 7D6E937A175C; Thu, 4 Dec 2014 06:51:40 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417665100; bh=x3y95iSwx5330TmkVJh5ILY+jRH738EINFRAK7qf57Y=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=ISgLYErrpG7RRA2ZOxATP3tx3TtjkeoTj+Q67p4T1EljMr+D6AqjaM/MLlaXjuygA uzuDbNk5KPZC/hkLyeeY8NP7StqgWugxSEwiLh25XuNJIl9knyggcXUQNe2/kIcCZl GztYHAU06zl5woH6P6soUB3SxpuEuaEK3GpbHYEw= Received: from 108.61.122.70.choopa.net (108.61.122.70.choopa.net [108.61.122.70]) by web17m.yandex.ru with HTTP; Thu, 04 Dec 2014 06:51:40 +0300 From: Martin Hanson To: Warren Block In-Reply-To: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <2659291417665100@web17m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 04:51:40 +0100 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 03:51:44 -0000 > It might need a delay before the device is ready. šRunning devd in the > foreground like that will show all the detected events. Indeed that helped. This is what I got with the output of messages. I don't know how to either give the device another unique name or somehow intercept what is happening so that I can set the device name. notify 1000 { match "system" "USB"; match "subsystem" "INTERFACE"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; match "type" "ATTACH"; action "logger I HAVE ATTACHED A DEVICE!"; }; Dec 4 04:47:00 gateway1 kernel: ugen3.2: at usbus3 Dec 4 04:47:00 gateway1 kernel: axge0: on usbus3 Dec 4 04:47:00 gateway1 devd: Executing 'logger FOO HAS ATTECHED A DEVICE!' Dec 4 04:47:00 gateway1 martin: I HAVE ATTACHED A DEVICE! Dec 4 04:47:00 gateway1 kernel: miibus1: on axge0 Dec 4 04:47:00 gateway1 kernel: rgephy0: PHY 3 on miibus1 Dec 4 04:47:00 gateway1 kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Dec 4 04:47:00 gateway1 kernel: ue0: on axge0 Dec 4 04:47:00 gateway1 kernel: ue0: Ethernet address: 00:24:9b:0d:e0:0c Dec 4 04:47:00 gateway1 devd: Executing '/etc/pccard_ether ue0 start' Dec 4 04:47:00 gateway1 kernel: ue0: link state changed to DOWN From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 04:27:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16781CAA for ; Thu, 4 Dec 2014 04:27:29 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B63281A0 for ; Thu, 4 Dec 2014 04:27:28 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sB44RQmn097624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Dec 2014 21:27:26 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sB44RQeh097621; Wed, 3 Dec 2014 21:27:26 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 3 Dec 2014 21:27:26 -0700 (MST) From: Warren Block To: Martin Hanson Subject: Re: NICs devices switches "pshycial" place on each boot In-Reply-To: <2659291417665100@web17m.yandex.ru> Message-ID: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Wed, 03 Dec 2014 21:27:26 -0700 (MST) Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 04:27:29 -0000 On Thu, 4 Dec 2014, Martin Hanson wrote: >> It might need a delay before the device is ready. šRunning devd in the >> foreground like that will show all the detected events. > > Indeed that helped. > > This is what I got with the output of messages. I don't know how to either give the device another unique name or somehow intercept what is happening so that I can set the device name. > > notify 1000 { > match "system" "USB"; > match "subsystem" "INTERFACE"; > match "vendor" "0x0b95"; > match "product" "0x1790"; > match "sernum" "0000249B0DE00C"; > match "type" "ATTACH"; > action "logger I HAVE ATTACHED A DEVICE!"; > }; I would use three of these sections, one with the serial number of each interface. So: action "ifconfig $device-name name wan inet ..." action "ifconfig $device-name name dmz inet ..." action "ifconfig $device-name name lan inet ..." Then the interface names can be easily used in firewall settings. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 04:45:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1C10FFE for ; Thu, 4 Dec 2014 04:45:12 +0000 (UTC) Received: from forward18.mail.yandex.net (forward18.mail.yandex.net [IPv6:2a02:6b8:0:1402::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8166E395 for ; Thu, 4 Dec 2014 04:45:12 +0000 (UTC) Received: from web20g.yandex.ru (web20g.yandex.ru [95.108.253.229]) by forward18.mail.yandex.net (Yandex) with ESMTP id 7758717812D1; Thu, 4 Dec 2014 07:45:00 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web20g.yandex.ru (Yandex) with ESMTP id ED6A06AC0839; Thu, 4 Dec 2014 07:44:59 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417668300; bh=s6AHQKPHa3IvD8x2fBQ5JkRcT0i3Yi0E8kVvp2F/eBI=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=Q9/J1UBPizq+dbzWljtFWujqsLdBOYzus+R0On8I1icbXV8lzb5SQc4t5G4ylPV6Z 5q92SGkw9rzdpHo1/HgGHZmLCKNooyD3Arwn48VBg5j+wF2Qv/fuHQAQXO8UeaRESq XAmPiwA1NXuHTuDJMl4YjBMr7ha5OAyccmjvV/3E= Received: from 108.61.122.70.choopa.net (108.61.122.70.choopa.net [108.61.122.70]) by web20g.yandex.ru with HTTP; Thu, 04 Dec 2014 07:44:59 +0300 From: Martin Hanson To: Warren Block In-Reply-To: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <1032301417668299@web20g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 05:44:59 +0100 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 04:45:13 -0000 >> šThis is what I got with the output of messages. I don't know how to either give the device another unique name or somehow intercept what is happening so that I can set the device name. >> >> šnotify 1000 { >> ššššmatch "system" "USB"; >> ššššmatch "subsystem" "INTERFACE"; >> ššššmatch "vendor" "0x0b95"; >> ššššmatch "product" "0x1790"; >> ššššmatch "sernum" "0000249B0DE00C"; >> ššššmatch "type" "ATTACH"; >> ššššaction "logger I HAVE ATTACHED A DEVICE!"; >> š}; > > I would use three of these sections, one with the serial number of each > interface. šSo: > > action "ifconfig $device-name name wan inet ..." > action "ifconfig $device-name name dmz inet ..." > action "ifconfig $device-name name lan inet ..." > > Then the interface names can be easily used in firewall settings. I tried that as well, but $device-name is empty. If I do this: notify 1000 { match "system" "USB"; match "subsystem" "INTERFACE"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; match "type" "ATTACH"; action "logger DEVICE NAME IS: $device-name."; }; I get: Dec 4 05:44:14 gateway1 kernel: ugen7.2: at usbus7 Dec 4 05:44:14 gateway1 kernel: axge0: on usbus7 Dec 4 05:44:14 gateway1 devd: Executing 'logger DEVICE NAME IS: .!' Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .! Dec 4 05:44:15 gateway1 kernel: miibus1: on axge0 Dec 4 05:44:15 gateway1 kernel: rgephy0: PHY 3 on miibus1 Dec 4 05:44:15 gateway1 kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Dec 4 05:44:15 gateway1 kernel: ue0: on axge0 Dec 4 05:44:15 gateway1 kernel: ue0: Ethernet address: 00:24:9b:0d:e0:0c Dec 4 05:44:15 gateway1 devd: Executing '/etc/pccard_ether ue0 start' Dec 4 05:44:15 gateway1 kernel: ue0: link state changed to DOWN Notice the "Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .!" part. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 05:01:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18D0E4B5 for ; Thu, 4 Dec 2014 05:01:12 +0000 (UTC) Received: from forward2m.mail.yandex.net (forward2m.mail.yandex.net [IPv6:2a02:6b8:0:2519::3:11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCC856B6 for ; Thu, 4 Dec 2014 05:01:11 +0000 (UTC) Received: from web25m.yandex.ru (web25m.yandex.ru [37.140.138.116]) by forward2m.mail.yandex.net (Yandex) with ESMTP id C50675CA0C0A; Thu, 4 Dec 2014 08:01:07 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web25m.yandex.ru (Yandex) with ESMTP id EFDC020E1107; Thu, 4 Dec 2014 08:01:06 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417669267; bh=/AfKrMwoxrw18nPI2cmBQ9oz2yCdYsxdme/nyz1IDdM=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=J7ib+8X4FJexJrj8kZ2HyAUY9KRKo1RM0lgc5vwkoHYR7tk/v7v4JupGmxcLflj8f rY1RnowLnwKHMDFjzbSXrgOxTcf4vbqLaDD74lnjbYIay2VX0Zxar+bAvX+0EMqiO4 9PCBRLxkcjSqmLjB6WmVLQhf46lnHkrozevDhTUw= Received: from 108.61.122.70.choopa.net (108.61.122.70.choopa.net [108.61.122.70]) by web25m.yandex.ru with HTTP; Thu, 04 Dec 2014 08:01:06 +0300 From: Martin Hanson To: Warren Block In-Reply-To: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <2704971417669266@web25m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 06:01:06 +0100 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 05:01:12 -0000 > > I would use three of these sections, one with the serial number of each > interface. šSo: > > action "ifconfig $device-name name wan inet ..." > action "ifconfig $device-name name dmz inet ..." > action "ifconfig $device-name name lan inet ..." > > Then the interface names can be easily used in firewall settings. I tried that as well, but $device-name is empty. If I do this: notify 1000 { match "system" "USB"; match "subsystem" "INTERFACE"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; match "type" "ATTACH"; action "logger DEVICE NAME IS: $device-name."; }; I get: Dec 4 05:44:14 gateway1 kernel: ugen7.2: at usbus7 Dec 4 05:44:14 gateway1 kernel: axge0: on usbus7 Dec 4 05:44:14 gateway1 devd: Executing 'logger DEVICE NAME IS: .!' Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .! Dec 4 05:44:15 gateway1 kernel: miibus1: on axge0 Dec 4 05:44:15 gateway1 kernel: rgephy0: PHY 3 on miibus1 Dec 4 05:44:15 gateway1 kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Dec 4 05:44:15 gateway1 kernel: ue0: on axge0 Dec 4 05:44:15 gateway1 kernel: ue0: Ethernet address: 00:24:9b:0d:e0:0c Dec 4 05:44:15 gateway1 devd: Executing '/etc/pccard_ether ue0 start' Dec 4 05:44:15 gateway1 kernel: ue0: link state changed to DOWN Notice the "Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .!" part. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 05:56:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CAF9BD6 for ; Thu, 4 Dec 2014 05:56:25 +0000 (UTC) Received: from forward1m.mail.yandex.net (forward1m.mail.yandex.net [IPv6:2a02:6b8:0:2519::3:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DD19C39 for ; Thu, 4 Dec 2014 05:56:25 +0000 (UTC) Received: from web4m.yandex.ru (web4m.yandex.ru [37.140.138.95]) by forward1m.mail.yandex.net (Yandex) with ESMTP id E7392122246A; Thu, 4 Dec 2014 08:56:21 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web4m.yandex.ru (Yandex) with ESMTP id 466A131617B4; Thu, 4 Dec 2014 08:56:21 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417672581; bh=pf5OgE10DRpFkeSiNxj7vdtsi/DuI+N3pBCZedLGHy0=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=QGD26ARWJEk4trhcgTxWSswPuyd2nAW5vYVVW+Vg6wcaWA2xJUHRqa1TY2VpR5iMK en8wI7Xkmv/+jweKL7xa76uEyy6FSK34GktT/mkDW67R5YBZt2KzZO3TaiLVLa507S /0c5ytFK78/LFsCM9qOjcrlNEGsZYqlTk5BlqLLk= Received: from 108.61.122.70.choopa.net (108.61.122.70.choopa.net [108.61.122.70]) by web4m.yandex.ru with HTTP; Thu, 04 Dec 2014 08:56:21 +0300 From: Martin Hanson To: Warren Block In-Reply-To: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <1915491417672581@web4m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 06:56:21 +0100 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 05:56:25 -0000 I am actually one step closer. With the following I can get the device-name "axge0", but I don't know how to create a usable NIC interface name for that. attach 1000 { device-name "axge[0-9]+"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; action "logger DEVICE NAME IS: $device-name"; }; Dec 4 06:41:39 gateway1 devd: Executing 'logger DEVICE NAME IS: axge0' Dec 4 06:41:39 gateway1 martin: DEVICE NAME IS: axge0 What action would I then take to create a usable device for ifconfig? Doing this doesn't work: # ifconfig axge0 name lan1 inet 192.168.1.1 netmask 255.255.255.0 ifconfig: interface axge0 does not exist What can I do from here? Kind regards. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 07:09:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21D11362 for ; Thu, 4 Dec 2014 07:09:56 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B87E2F7 for ; Thu, 4 Dec 2014 07:09:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sB479gp1009879; Thu, 4 Dec 2014 18:09:42 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 4 Dec 2014 18:09:42 +1100 (EST) From: Ian Smith To: Martin Hanson Subject: Re: NICs devices switches "pshycial" place on each boot In-Reply-To: <2704971417669266@web25m.yandex.ru> Message-ID: <20141204180007.Q85722@sola.nimnet.asn.au> References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> <2704971417669266@web25m.yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Warren Block , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 07:09:56 -0000 On Thu, 4 Dec 2014 06:01:06 +0100, Martin Hanson wrote: (Warren Block wrote:) > I would use three of these sections, one with the serial number of each > interface.  So: > > action "ifconfig $device-name name wan inet ..." > action "ifconfig $device-name name dmz inet ..." > action "ifconfig $device-name name lan inet ..." > > Then the interface names can be easily used in firewall settings. Hmm, pine doesn't quote your message properly, I'll try something else: ======= I tried that as well, but $device-name is empty. If I do this: notify 1000 { match "system" "USB"; match "subsystem" "INTERFACE"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; match "type" "ATTACH"; action "logger DEVICE NAME IS: $device-name."; }; ======= Maybe devd does'nt parse quite the same as sh(1), in that your trailing '.' might be seen as part of the name to match? Tried leaving it off? ======== I get: Dec 4 05:44:14 gateway1 kernel: ugen7.2: at usbus7 Dec 4 05:44:14 gateway1 kernel: axge0: on usbus7 Dec 4 05:44:14 gateway1 devd: Executing 'logger DEVICE NAME IS: .!' Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .! Dec 4 05:44:15 gateway1 kernel: miibus1: on axge0 Dec 4 05:44:15 gateway1 kernel: rgephy0: PHY 3 on miibus1 Dec 4 05:44:15 gateway1 kernel: rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow Dec 4 05:44:15 gateway1 kernel: ue0: on axge0 Dec 4 05:44:15 gateway1 kernel: ue0: Ethernet address: 00:24:9b:0d:e0:0c Dec 4 05:44:15 gateway1 devd: Executing '/etc/pccard_ether ue0 start' Dec 4 05:44:15 gateway1 kernel: ue0: link state changed to DOWN Notice the "Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .!" part. ======= See above maybe, but then, where did that trailing '!' come from? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 10:50:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B367FF99 for ; Thu, 4 Dec 2014 10:50:49 +0000 (UTC) Received: from relay1.speechpro.com (relay1.speechpro.com [79.134.214.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B166ED0 for ; Thu, 4 Dec 2014 10:50:48 +0000 (UTC) Received: from mail.stc ([192.168.8.64] helo=spb2.speechpro.com) by relay1.speechpro.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1XwTza-000JcP-BV for freebsd-net@freebsd.org; Thu, 04 Dec 2014 13:50:38 +0300 Received: from [192.168.6.123] by mail.stc with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1XwTzR-000DC0-PC for freebsd-net@freebsd.org; Thu, 04 Dec 2014 13:50:29 +0300 Message-ID: <54803C75.2020300@speechpro.com> Date: Thu, 04 Dec 2014 13:50:29 +0300 From: Yuriy Tabolin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: problem with 9k jumbo clusters Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Archived: Yes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 10:50:49 -0000 Hi All. I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. Server works like NFS, samba-server and iSCSI target. Both NICs aggregated into lagg device and set MTU 9014 to them. There are some tuning sysctl.conf: kern.maxfiles=6289601 kern.maxfilesperproc=5660640 kern.maxvnodes=3339565 kern.ipc.nmbclusters=12255588 kern.ipc.nmbjumbop=6127794 kern.ipc.nmbufs=78435780 kern.ipc.maxsockbuf=16777216 kern.ipc.maxsockets=6289600 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 After some days of working, the errors are appearing: ix1: Interface stopped DISTRIBUTING, possible flapping ix0: Interface stopped DISTRIBUTING, possible flapping ix0: Could not setup receive structures ix1: Could not setup receive structures After that errors the NICs stoped working. netstat -m shows: 32881/33854/66735 mbufs in use (current/cache/total) 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max) 16370/4807 mbuf+clusters out of packet secondary zone in use (current/cache) 0/873/873/6127794 4k (page size) jumbo clusters in use (current/cache/total/max) 16383/21517/37900/1815641 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) 188407K/222004K/410411K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 9k jumbo clusters max is too big, but looks like system cannot allocate them. There are huge number of "9k requests for jumbo clusters denied". ifconfig ix down/up don't helped, reboot is needed. Thanks for any help! -- Best regards, Tabolin Yuriy System administrator Speech Technology Center From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 14:58:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50439F3F; Thu, 4 Dec 2014 14:58:00 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 22B98F6A; Thu, 4 Dec 2014 14:58:00 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 4DCAE46B2C; Thu, 4 Dec 2014 09:57:59 -0500 (EST) Date: Thu, 4 Dec 2014 14:57:59 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: George Neville-Neil Subject: Re: Enabling VIMAGE in GENERIC In-Reply-To: Message-ID: References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> <20141119195923.GS24601@funkthat.com> <69A8C06F-A7F6-49EC-8601-91AC4CDBFB13@FreeBSD.org> <547364EB.7090505@freebsd.org> <547AEB93.3050600@freebsd.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 14:58:00 -0000 On Mon, 1 Dec 2014, George Neville-Neil wrote: > On a slight tangent. I ran VIMAGE kernels vs. non VIMAGE kernels for both a > VANILLA kernel and a PF kernel (PF on but no rules) as a quick smoke test > today. The raw forwarding performance was unchanged between kernels with > and without VIMAGE on a 10G based system in the Sentex lab (lion1). I will > be doing a bit more work in this area and will then put up some results in > my netperf github repo. Was this a CPU-bound or network-bound workload? In general, I'd expect VIMAGE to have a modest overhead for most measurable workloads .. unless you are CPU-bound, in which case per-packet processing overheads might become (potentially) quite visible. They will also be more visible on simpler pipelines and with less cache-rich designs -- e.g., SoCs of various sorts. Doing a bit of CPU-bound networking on a modest ARM core might show off the effects better. Robert From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 19:00:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EF4669A for ; Thu, 4 Dec 2014 19:00:26 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1329630C for ; Thu, 4 Dec 2014 19:00:26 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XwbdW-000IE4-Dd; Thu, 04 Dec 2014 23:00:22 +0400 Message-ID: <5480AF38.3070100@FreeBSD.org> Date: Thu, 04 Dec 2014 22:00:08 +0300 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yuriy Tabolin , freebsd-net@freebsd.org Subject: Re: problem with 9k jumbo clusters References: <54803C75.2020300@speechpro.com> In-Reply-To: <54803C75.2020300@speechpro.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 19:00:26 -0000 On 04.12.2014 13:50, Yuriy Tabolin wrote: > Hi All. > I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. > Server works like NFS, samba-server and iSCSI target. Both NICs > aggregated into lagg device and set MTU 9014 to them. There are some > tuning sysctl.conf: > kern.maxfiles=6289601 > kern.maxfilesperproc=5660640 > kern.maxvnodes=3339565 > kern.ipc.nmbclusters=12255588 > kern.ipc.nmbjumbop=6127794 > kern.ipc.nmbufs=78435780 > kern.ipc.maxsockbuf=16777216 > kern.ipc.maxsockets=6289600 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendspace=65536 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=65536 > > After some days of working, the errors are appearing: > ix1: Interface stopped DISTRIBUTING, possible flapping > ix0: Interface stopped DISTRIBUTING, possible flapping > ix0: Could not setup receive structures > ix1: Could not setup receive structures Hello. It looks like https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038630.html is relevant here. > > After that errors the NICs stoped working. netstat -m shows: > 32881/33854/66735 mbufs in use (current/cache/total) > 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max) > 16370/4807 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/873/873/6127794 4k (page size) jumbo clusters in use > (current/cache/total/max) > 16383/21517/37900/1815641 9k jumbo clusters in use > (current/cache/total/max) > 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) > 188407K/222004K/410411K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > 9k jumbo clusters max is too big, but looks like system cannot > allocate them. There are huge number of "9k requests for jumbo > clusters denied". ifconfig ix down/up don't helped, reboot is needed. > Thanks for any help! > > > -- > Best regards, > Tabolin Yuriy > System administrator > Speech Technology Center > _______________________________________________ > 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 4 20:42:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B024B6 for ; Thu, 4 Dec 2014 20:42:49 +0000 (UTC) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F00A7169 for ; Thu, 4 Dec 2014 20:42:48 +0000 (UTC) Received: from web27h.yandex.ru (web27h.yandex.ru [84.201.187.161]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 26A26D002EA; Thu, 4 Dec 2014 23:42:31 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web27h.yandex.ru (Yandex) with ESMTP id 52D1D6220242; Thu, 4 Dec 2014 23:42:31 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417725751; bh=m2tH53M1oa5LtJu1b6eC2ZCrWM261u+tNDqmRJw1aPY=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=cCLSTH68+ZUrOVE5+UnRnxAPhTYfH4qA3brhnwWTNOEz++rcLuGcpTni7vJ6rBs1m +DxDtcyJZBnzsgq0DdU1x6ViAQZif/XraQwdv3mYdRxYfl3EPirnmfPsbXmyPRT/98 xvi/AUYuRuHW2QrD/DGkqGxZhCbzPoXI7BbiihYo= Received: from 108.61.122.215.choopa.net (108.61.122.215.choopa.net [108.61.122.215]) by web27h.yandex.ru with HTTP; Thu, 04 Dec 2014 23:42:30 +0300 From: Martin Hanson To: Ian Smith In-Reply-To: <20141204180007.Q85722@sola.nimnet.asn.au> References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> <2704971417669266@web25m.yandex.ru> <20141204180007.Q85722@sola.nimnet.asn.au> Subject: Re: NICs devices switches "pshycial" place on each boot MIME-Version: 1.0 Message-Id: <114611417725750@web27h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 21:42:30 +0100 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: Warren Block , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 20:42:49 -0000 > ======= > I tried that as well, but $device-name is empty. > > If I do this: > > notify 1000 { > šššššmatch "system" "USB"; > šššššmatch "subsystem" "INTERFACE"; > šššššmatch "vendor" "0x0b95"; > šššššmatch "product" "0x1790"; > šššššmatch "sernum" "0000249B0DE00C"; > šššššmatch "type" "ATTACH"; > šššššaction "logger DEVICE NAME IS: $device-name."; > }; > ======= > > Maybe devd does'nt parse quite the same as sh(1), in that your trailing > '.' might be seen as part of the name to match? šTried leaving it off? Yes, I have remove the trailing '.', but $device-name is empty. > Notice the "Dec š4 05:44:14 gateway1 martin: DEVICE NAME IS: .!" part. > ======= > > See above maybe, but then, where did that trailing '!' come from? That was me making a mistake in the email. With the following I can get the device-name "axge0", but I don't know how to create a usable NIC interface name for that. attach 1000 { device-name "axge[0-9]+"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; action "logger DEVICE NAME IS: $device-name"; }; Dec 4 06:41:39 gateway1 devd: Executing 'logger DEVICE NAME IS: axge0' Dec 4 06:41:39 gateway1 martin: DEVICE NAME IS: axge0 What action would I then take to create a usable device for ifconfig? Doing this doesn't work: # ifconfig axge0 name lan1 inet 192.168.1.1 netmask 255.255.255.0 ifconfig: interface axge0 does not exist Kind regards. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 20:50:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA1D3216 for ; Thu, 4 Dec 2014 20:50:51 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49C50257 for ; Thu, 4 Dec 2014 20:50:51 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ex7so29281836wid.6 for ; Thu, 04 Dec 2014 12:50:49 -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:content-transfer-encoding; bh=Qn2yARyZYjOU/DNK5zRO3NO69lIQq/O/gR3q5skZ4qc=; b=UEgIopdA6e+FKNwKjyWzfsrZoXKnZH1K18ebnq/GAj/uV3fOI+2CiQQLAP7coSqtue xlzW+uMY7N3SDy10T5pjmCdTWihjHNcQV/pIqkwGu6FxkrxtOWf56JdtPfUXXE8ZI2nu 9fRLkIlcoSK5kf3c7nRUMMfUbaYwfsvxBzcJZ6Wwp6e+P6PGM6nhNCi/8l/NJx9caE43 e95taVWAinXhUnZsSHYoEhADaoPDnUMrL66s37Z6Hj81aHUk/uEamPrDjoh54BvcOGsp ATtmx7WAfnkv+Tm0eBDLN2s53FtkXvJssk8sy5x4MK2mjRTz0VtJAUzHn8s60i8MWjyS 7txQ== MIME-Version: 1.0 X-Received: by 10.194.60.45 with SMTP id e13mr18914645wjr.109.1417726249608; Thu, 04 Dec 2014 12:50:49 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.17.129 with HTTP; Thu, 4 Dec 2014 12:50:49 -0800 (PST) In-Reply-To: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> Date: Thu, 4 Dec 2014 13:50:49 -0700 X-Google-Sender-Auth: FgusgvxB27xCWAwyP_XZ15cTKpM Message-ID: Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: Alan Somers To: "David P. Discher" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 20:50:51 -0000 On Wed, Dec 3, 2014 at 12:21 PM, David P. Discher wrote: > Hey Net - > > In probably a poor, cheap choice, I picked up a TP-Link TL-SG2008 Desktop= Smart Switch, which supports LACP/802.3ad. I=E2=80=99m currently running = 10.1-STABLE r274577 on the machine I=E2=80=99m testing with. I=E2=80=99m t= esting right now with just 1 port (two ports didn=E2=80=99t work either.). > > Hardware is Supermicro X7DB8. > > > em1: port 0x2020-0x203f mem = 0xd8260000-0xd827ffff,0xd8240000-0xd825ffff irq 19 at device 0.1 on pci6 > > em1@pci0:6:0:1: class=3D0x020000 card=3D0x109615d9 chip=3D0x10968086 rev= =3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '80003ES2LAN Gigabit Ethernet Controller (Copper)' > class =3D network > subclass =3D ethernet > > >> ifconfig lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D4219b > ether 00:30:48:35:cc:25 > inet 10.1.10.150 netmask 0xffffff00 broadcast 10.1.10.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: em1 flags=3D0<> > > > Setting net.link.lagg.lacp.debug=3D2, here is the output from the the hos= t trying to negotiate : > > > em1: lacp_sm_rx_update_default_selected > em1: lacp_sm_rx_update_selected_from_peerinfo > em1: lacp_sm_rx_record_default > em1: lacp_sm_mux: state=3D 0x1, selected=3D 0x0, p_sync=3D 0x0, p= _collecting=3D 0x0 > em1: lacpdu transmit > actor=3D(8000,00-30-48-35-CC-25,008B,8000,0002) > actor.state=3D45 > partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) > partner.state=3D0 > maxdelay=3D0 > em1: lacp_sm_mux: state=3D 0x0, selected=3D 0x2, p_sync=3D 0x0, p= _collecting=3D 0x0 > em1: lacp_sm_mux: state=3D 0x1, selected=3D 0x2, p_sync=3D 0x0, p= _collecting=3D 0x0 > em1: lacp_sm_mux: state=3D 0x1, selected=3D 0x2, p_sync=3D 0x0, p= _collecting=3D 0x0 > em1: lacpdu transmit > actor=3D(8000,00-30-48-35-CC-25,008B,8000,0002) > actor.state=3D4d > partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) > partner.state=3D0 > maxdelay=3D0 > em1: lacp_sm_mux: state=3D 0x2, selected=3D 0x2, p_sync=3D 0x0, p= _collecting=3D 0x0 > em1: lacp_sm_mux: state=3D 0x2, selected=3D 0x2, p_sync=3D 0x0, p= _collecting=3D 0x0 > em1: lacp_sm_mux: state=3D 0x2, selected=3D 0x2, p_sync=3D 0x0, p= _collecting=3D 0x0 > [...] > > Not sure if the attachment will work to the list, but here is a pcap atta= ched em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the lagg0 w= ith tcpdump, filters out the freebsd=E2=80=99s LACP packets, but still sees= the TP-Link=E2=80=99s packets. Did you remember to configure the switch to use LACP on those ports? It isn't automatic. And did you remember to manually up em1? Those are the two commonest LACP configuration mistakes. -Alan From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 21:10:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10C5C792 for ; Thu, 4 Dec 2014 21:10:48 +0000 (UTC) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3C82637 for ; Thu, 4 Dec 2014 21:10:47 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id v10so13195072pde.40 for ; Thu, 04 Dec 2014 13:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fPPJ7WfQxcZzZU5FCVM09ylXpu22i0W0zA+JWotWJ4w=; b=VnXjT4/Ar3Am6iYFc7V8s3E3c4dgKY4yDRdB7u6lrPEKyH+Obgj13bl9PcjouQ17s+ fbBMHrZi/iCaME+MgLAQbK8R3fViNxMeABDh2vz8pGI93TNAD1gwGa5OuoWWwr3oPQjm 5yOfZQxCXm6ZbYmD8aVa+lLNyeKPucEm5vwfg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=fPPJ7WfQxcZzZU5FCVM09ylXpu22i0W0zA+JWotWJ4w=; b=G0DDvhAwqcM8HQr7EGVEbebG8jl0MSCSjAWU3rTvuXdldH6D4iHdYkMkY9mdRgRjXZ R+KLFS2KQRBFh0gFEj3nqgidd9mmdmgGm3fDzxK4icdsc32cGHfUpvE8KgHA4jk8O5Ss 3CNeZeXnttBW2ffmBq5S3SlMgos3iq/t4c/dMz/ReThnja0m8zFKgjaqNY8of0SbDiy7 4jUXVQXrw03WgmxyCZ5eKxTQCqS5JyeutiaTUTG5BaJIEqcBc1/3TtMsl7tzwplyWSR3 YdKpP4EIq/BzJSUItDV+VvQBPtE9wQrNVDUq7gH6mT/JkKwkOujnCBCzPZ2gwaQfSTh1 xixA== X-Gm-Message-State: ALoCoQm5sw536m9rzDpE+k3zaTEJzSCznCYB1jmRo52gsDmehVIN8vBYfdzunSBczrw5peJfoxPu X-Received: by 10.70.136.202 with SMTP id qc10mr21977801pdb.152.1417727447391; Thu, 04 Dec 2014 13:10:47 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id w1sm9946582pdf.38.2014.12.04.13.10.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 13:10:46 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3AE43373-3AAC-42D5-8BEE-0F93BCFA1EDE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: Date: Thu, 4 Dec 2014 13:10:45 -0800 Message-Id: <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> To: Alan Somers X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 21:10:48 -0000 --Apple-Mail=_3AE43373-3AAC-42D5-8BEE-0F93BCFA1EDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 4, 2014, at 12:50 PM, Alan Somers wrote: >> Not sure if the attachment will work to the list, but here is a pcap = attached em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the = lagg0 with tcpdump, filters out the freebsd=92s LACP packets, but still = sees the TP-Link=92s packets. >=20 > Did you remember to configure the switch to use LACP on those ports? > It isn't automatic. And did you remember to manually up em1? Those > are the two commonest LACP configuration mistakes. >=20 > -Alan 99% sure the switch is configured correctly. I=92ve actually tried all = the different combination of the switch supports, and can=92t seem to = get them to sync up. =46rom the pcaps, both the host and switch are = sending the LACP packets =85 but it seems that the freebsd is just = passing them through/up =85 almost like FreeBSD doesn=92t recognized = them as LACP packets.=20 In looking a bit deeper on the pcaps in wireshark - the TP-Link=92s = packet correctly labels the =93partner=94 systems to the super = micro/freebsd box by port and mac address, however the FreeBSD response = has all zeros for the partner systems mac and port. So without looking = at the logs on the switch, my guess is the switch correctly sees the = FreeBSD box, however the FreeBSD box is not correctly recognizing the = packets from the switch as LACP.=20 Feels like a single bit or flag in the switches packets that is not = matching what FreeBSD is expecting.=20 I was hoping someone would have some insight before I start looking at = each bit of the packets what=92s not aligned. - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 --Apple-Mail=_3AE43373-3AAC-42D5-8BEE-0F93BCFA1EDE 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 iQEcBAEBCgAGBQJUgM3VAAoJEEmwU6XuhYWOmDAH/2VpBGNYhLTvSPk3n4zd5UTj KxfiJvBG1JOldYs3PCjqeb+Eq/L+pdNACxS5SThQyxsqcjLmNLUtxrmBCBOcXh7P VpCDEq7U/n0XD0ANOt6uBBQOaiI6FaNutZ5iWF5HF4fTTbsAr5r7tN3ORRJpCIpo YzU479bH5oitO+cf31GNnis9MymoifKCzXtNIMzAplIfUNGoVQiSTKWQ5B22Z+KS Ab+LqXKgueVzdWaoWu9dejRXd7oUvUGYUL5olVl1vnJO3TK0LPnzOapEq7s4My/L i42ZoFNcBuzkDw7DaZ1mLi9CBivJ6j+2nsQPqRR9Bxo5j2E9PKwXGyIYLJiaRbc= =s63r -----END PGP SIGNATURE----- --Apple-Mail=_3AE43373-3AAC-42D5-8BEE-0F93BCFA1EDE-- From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 21:49:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E8521CC; Thu, 4 Dec 2014 21:49:37 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA36DABE; Thu, 4 Dec 2014 21:49:36 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id l15so29416662wiw.16 for ; Thu, 04 Dec 2014 13:49:35 -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=pRsp0DV9ons8UKz0d4C/LlqkOxqbcpB8lHoEOiEcPBs=; b=p0uDVthCbgbtgBy1MT2LQxCSNr0U69HQK6YJCAYKLXv4xK6eHjNBCYZ2XOAw2kfpqe 3Jfft5vZBDoBL7i6nGgTcfJWnEJw72WKE37G+Gd4V0AYU1xQzK2fBRT7b1PprAxKKe5J Gx8758hHQ3nfqaA35r508b4iXG1mVRrtj1BHcjwp+xzG9YVaWJSTtfPSYAHkVGyUr2OX wP6dlluOd9fY5FuqdDSSZWGz8gHOxUrDc8uSuELLeXM3pO1Hn1jYj+6qNcJXdybbtl7a 5dXGKhz/82uVbwGvP4UTtLhoG3PQKynEAKP0tnhJ31b9RDtZs0IGUU4x1hGdSQC8/W9g NSWA== MIME-Version: 1.0 X-Received: by 10.180.75.199 with SMTP id e7mr377300wiw.21.1417729775421; Thu, 04 Dec 2014 13:49:35 -0800 (PST) Received: by 10.194.81.233 with HTTP; Thu, 4 Dec 2014 13:49:35 -0800 (PST) In-Reply-To: <5480AF38.3070100@FreeBSD.org> References: <54803C75.2020300@speechpro.com> <5480AF38.3070100@FreeBSD.org> Date: Thu, 4 Dec 2014 13:49:35 -0800 Message-ID: Subject: Re: problem with 9k jumbo clusters From: Jack Vogel To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net , Yuriy Tabolin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 21:49:37 -0000 I had wanted to remove the larger cluster sizes from the driver a while back, but for reasons I don't remember that code change didn't happen. The new 40G ixl driver does this, it only uses standard clusters for anything under 2K, and above that everything uses 4K. I would be curious to see if this change would resolve your problem, would you like a patch, or are you able to hack the code yourself to do this? Jack On Thu, Dec 4, 2014 at 11:00 AM, Alexander V. Chernikov < melifaro@freebsd.org> wrote: > On 04.12.2014 13:50, Yuriy Tabolin wrote: > >> Hi All. >> I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. >> Server works like NFS, samba-server and iSCSI target. Both NICs aggregated >> into lagg device and set MTU 9014 to them. There are some tuning >> sysctl.conf: >> kern.maxfiles=6289601 >> kern.maxfilesperproc=5660640 >> kern.maxvnodes=3339565 >> kern.ipc.nmbclusters=12255588 >> kern.ipc.nmbjumbop=6127794 >> kern.ipc.nmbufs=78435780 >> kern.ipc.maxsockbuf=16777216 >> kern.ipc.maxsockets=6289600 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.sendspace=65536 >> net.inet.tcp.recvbuf_max=16777216 >> net.inet.tcp.recvspace=65536 >> >> After some days of working, the errors are appearing: >> ix1: Interface stopped DISTRIBUTING, possible flapping >> ix0: Interface stopped DISTRIBUTING, possible flapping >> ix0: Could not setup receive structures >> ix1: Could not setup receive structures >> > Hello. It looks like > https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038630.html > is relevant here. > > >> After that errors the NICs stoped working. netstat -m shows: >> 32881/33854/66735 mbufs in use (current/cache/total) >> 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max) >> 16370/4807 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 0/873/873/6127794 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 16383/21517/37900/1815641 9k jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) >> 188407K/222004K/410411K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> >> 9k jumbo clusters max is too big, but looks like system cannot allocate >> them. There are huge number of "9k requests for jumbo clusters denied". >> ifconfig ix down/up don't helped, reboot is needed. Thanks for any help! >> >> >> -- >> Best regards, >> Tabolin Yuriy >> System administrator >> Speech Technology Center >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 22:04:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B3F5564 for ; Thu, 4 Dec 2014 22:04:54 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id C3632C97 for ; Thu, 4 Dec 2014 22:04:52 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 9F962191F2 for ; Thu, 4 Dec 2014 16:58:07 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78BNVAdmC3g2 for ; Thu, 4 Dec 2014 16:58:07 -0500 (EST) Received: from EGR authenticated sender Message-ID: <5480D8EF.9000804@egr.msu.edu> Date: Thu, 04 Dec 2014 16:58:07 -0500 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> In-Reply-To: <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 22:04:54 -0000 On 12/04/2014 16:10, David P. Discher wrote: > > On Dec 4, 2014, at 12:50 PM, Alan Somers wrote: > >>> Not sure if the attachment will work to the list, but here is a pcap attached em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the lagg0 with tcpdump, filters out the freebsd’s LACP packets, but still sees the TP-Link’s packets. >> >> Did you remember to configure the switch to use LACP on those ports? >> It isn't automatic. And did you remember to manually up em1? Those >> are the two commonest LACP configuration mistakes. >> >> -Alan > > > > 99% sure the switch is configured correctly. I’ve actually tried all the different combination of the switch supports, and can’t seem to get them to sync up. From the pcaps, both the host and switch are sending the LACP packets … but it seems that the freebsd is just passing them through/up … almost like FreeBSD doesn’t recognized them as LACP packets. > > In looking a bit deeper on the pcaps in wireshark - the TP-Link’s packet correctly labels the “partner” systems to the super micro/freebsd box by port and mac address, however the FreeBSD response has all zeros for the partner systems mac and port. So without looking at the logs on the switch, my guess is the switch correctly sees the FreeBSD box, however the FreeBSD box is not correctly recognizing the packets from the switch as LACP. > > Feels like a single bit or flag in the switches packets that is not matching what FreeBSD is expecting. > > I was hoping someone would have some insight before I start looking at each bit of the packets what’s not aligned. > > > > - > David P. Discher > http://davidpdischer.com/ > AIM: DavidDPD | Y!M: daviddpdz > Is the switch side set to "active" for the lacp mode (instead of passive)? Also, try: sysctl net.link.lagg.0.lacp.lacp_strict_mode=0 If either of those work, I'll explain more, don't have time to dig for old email right this minute. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 22:21:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36719B1B for ; Thu, 4 Dec 2014 22:21:21 +0000 (UTC) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6A90E90 for ; Thu, 4 Dec 2014 22:21:20 +0000 (UTC) Received: from web18h.yandex.ru (web18h.yandex.ru [84.201.186.47]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 77DB11361EF7; Fri, 5 Dec 2014 01:21:16 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web18h.yandex.ru (Yandex) with ESMTP id BD8624F603C7; Fri, 5 Dec 2014 01:21:15 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417731676; bh=fffh3c5x5a+l9mAFEF5LypgunV00TOnVIzLnvOex8+4=; h=From:To:Cc:In-Reply-To:References:Subject:Date; b=VEBgU+VgexatYZW9H9jsmMOD8nmQQQPwf4RVjo1rVP9Fgj5ItGA0x5DC8H+CVDXRx ZYiLvuxbjCKt/ISfxKyaD2VOcNqe/VgkMehRWzFJuM2iF/Fv/FK6eaw/EQdSgTihis HeuEZIwkAmQkcXkMeIbXYtp52mw3CKnHVIlm5F3k= Received: from 108.61.122.225.choopa.net (108.61.122.225.choopa.net [108.61.122.225]) by web18h.yandex.ru with HTTP; Fri, 05 Dec 2014 01:21:15 +0300 From: Martin Hanson To: Ian Smith In-Reply-To: <20141204180007.Q85722@sola.nimnet.asn.au> References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> <2704971417669266@web25m.yandex.ru> <20141204180007.Q85722@sola.nimnet.asn.au> Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED) MIME-Version: 1.0 Message-Id: <151421417731675@web18h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 23:21:15 +0100 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: Warren Block , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 22:21:21 -0000 I managed to get this working. It is a dirty hack and I REALLY wish FreeBSD would make documentation as high a priority as the guys at OpenBSD. It is difficult to locate correct and updated documentation, especially about devd. Yes, the man page has information about devd, and devd.conf even come with examples, but those examples are too sparsome to be of any real use when things get just a little bit complicated. It is extremely frustration to spend hour of hours of wasted time getting something to work, not because it doesn't work, but simply because you're "throwing stones in the dark" in the hopes of hitting the right target - because the correct and comprehensive documentation is lacking. A quality product HAS to have correct, updated and comprehensive documentation. This is one point that really makes the OpenBSD guys stand out deserving laud applause. Now, the driver on OpenBSD didn't work, so I had to use FreeBSD because that driver works, otherwise I would never had ventured into this incredible time consuming task. Warren Block, thank you a billion times for helping me with correct and relevant information! This is what I did to make it work. Like I said, it is a hack, but hey it works. attach 100 { device-name "axge[0-9]+"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; # We need to wait a little for the interface to get up. action "sleep 3"; # We don't know what number the interface has been assigned, but we know it is from axgeX, # so we get the X, use it in "ueX" and then rename the interface which is then bound to the # serialnumber, so the correct card will always get the right interface, ie. our own, not ueX. action "ifconfig ue`echo $device-name | tr -dc '[0-9]'` name olan"; action "ifconfig olan inet 192.168.1.1 netmask 255.255.255.0"; }; I hope someone else might find this useful or perhaps even provide a cleaner approach. Kind regards. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 22:24:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D811CCDA for ; Thu, 4 Dec 2014 22:24:21 +0000 (UTC) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B92BEBB for ; Thu, 4 Dec 2014 22:24:21 +0000 (UTC) Received: from web18h.yandex.ru (web18h.yandex.ru [84.201.186.47]) by forward3h.mail.yandex.net (Yandex) with ESMTP id A24BB1361C24 for ; Fri, 5 Dec 2014 01:24:19 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web18h.yandex.ru (Yandex) with ESMTP id 309224F603B2; Fri, 5 Dec 2014 01:24:19 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1417731859; bh=s5YpmzqZQicpqGwXCGTqamawerguAvmKjv3k15Pixlw=; h=From:To:Subject:Date; b=hgGKnCG8pW3xz6KLFu9TRS0P72S6qK4NFq2fwhkFcVxXox7wExErTWYgUPoUjI8iS nJ/EmrgLalsRnP4nFBvb2rbViBS7HSV6bunzqIfky3f1i1ps1iwwiwqw1RuHuzosjI mMPGv94nN1xSgRXZeB2cQ7WnIc+G2TLZNodhN1JI= Received: from 108.61.122.225.choopa.net (108.61.122.225.choopa.net [108.61.122.225]) by web18h.yandex.ru with HTTP; Fri, 05 Dec 2014 01:24:18 +0300 From: Martin Hanson To: freebsd-net@freebsd.org Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED) MIME-Version: 1.0 Message-Id: <154421417731858@web18h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Dec 2014 23:24:18 +0100 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 22:24:21 -0000 It is worth mentioning that the ONLY reason why this worked is because the vendor has provided a serial number. Most vendors don't and it would not have worked then. devd NEEDS to be able to see device MAC addresses! From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 22:41:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B406C19D for ; Thu, 4 Dec 2014 22:41:13 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 469A913A for ; Thu, 4 Dec 2014 22:41:13 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id l15so36416205wiw.8 for ; Thu, 04 Dec 2014 14:41:11 -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=0osW1YgsjN1Hy5ZMb4eiQxOEgwEVGkuyd1uLsAPp64M=; b=EA3gqCJMIjbY3v/kJIgeCjJOzriiLvXBA6a80NSNrchkq10ACQuXFLWA2S6uiI6MmR +IVa1aKotOQFWtXY88OGUm5PpRg9It7Wrrw7JePnftwT92aOr9erlShfVxJucNDEsxmi 1J4sfDifBdFjR7BGG//GxJ3qLoLtXUtGHued/oURKbMskfmJorvPU76d12/TmaSTrzvp lBawtR4gPc3y6q0FzJuF/WGl+I/qNGhqHDdhfTcNmPonqn2ziiHuUbmTBli/+6skWWea jZ3y1YuucQbEUF3q/eoOnT+sDpideGFSpvTmOIN+0clNAscTd7elup8mro1apgJ5+2w1 Ed+g== MIME-Version: 1.0 X-Received: by 10.180.92.169 with SMTP id cn9mr24928280wib.26.1417732871720; Thu, 04 Dec 2014 14:41:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Thu, 4 Dec 2014 14:41:11 -0800 (PST) In-Reply-To: <154421417731858@web18h.yandex.ru> References: <154421417731858@web18h.yandex.ru> Date: Thu, 4 Dec 2014 14:41:11 -0800 X-Google-Sender-Auth: eQmvCM4jRf7I8l9gEdrK3fbxutk Message-ID: Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED) From: Adrian Chadd To: Martin Hanson Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 22:41:13 -0000 On 4 December 2014 at 14:24, Martin Hanson wrote: > It is worth mentioning that the ONLY reason why this worked is because > the vendor has provided a serial number. Most vendors don't and it > would not have worked then. > > devd NEEDS to be able to see device MAC addresses! I'm surprised it doesn't! Would you mind filing a PR so we do expose that particular bit of data? -a From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 23:36:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2E4A67E for ; Thu, 4 Dec 2014 23:36:32 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98E7F95B for ; Thu, 4 Dec 2014 23:36:32 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id sB4NaNiN096507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Dec 2014 16:36:23 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id sB4NaNjR096504; Thu, 4 Dec 2014 16:36:23 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 4 Dec 2014 16:36:23 -0700 (MST) From: Warren Block To: Martin Hanson Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED) In-Reply-To: <151421417731675@web18h.yandex.ru> Message-ID: References: <1511041417624247@web23g.yandex.ru> <212351417642134@web20h.yandex.ru> <2659291417665100@web17m.yandex.ru> <2704971417669266@web25m.yandex.ru> <20141204180007.Q85722@sola.nimnet.asn.au> <151421417731675@web18h.yandex.ru> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 04 Dec 2014 16:36:23 -0700 (MST) Cc: "freebsd-net@freebsd.org" , Ian Smith X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 04 Dec 2014 23:36:33 -0000 On Thu, 4 Dec 2014, Martin Hanson wrote: > I managed to get this working. > > It is a dirty hack and I REALLY wish FreeBSD would make documentation > as high a priority as the guys at OpenBSD. > > It is difficult to locate correct and updated documentation, especially > about devd. Yes, the man page has information about devd, and devd.conf > even come with examples, but those examples are too sparsome to be of > any real use when things get just a little bit complicated. > > It is extremely frustration to spend hour of hours of wasted time > getting something to work, not because it doesn't work, but simply > because you're "throwing stones in the dark" in the hopes of hitting > the right target - because the correct and comprehensive documentation > is lacking. > > A quality product HAS to have correct, updated and comprehensive > documentation. This is one point that really makes the OpenBSD guys > stand out deserving laud applause. We work at it, but it is difficult to cover everything. It would be nice to have a section in the Handbook on devd. If you would like to submit or work on something like that, I can help (I'm a doc committer). > attach 100 { > device-name "axge[0-9]+"; > match "vendor" "0x0b95"; > match "product" "0x1790"; > match "sernum" "0000249B0DE00C"; > # We need to wait a little for the interface to get up. > action "sleep 3"; > # We don't know what number the interface has been assigned, but we know it is from axgeX, > # so we get the X, use it in "ueX" and then rename the interface which is then bound to the > # serialnumber, so the correct card will always get the right interface, ie. our own, not ueX. > action "ifconfig ue`echo $device-name | tr -dc '[0-9]'` name olan"; > action "ifconfig olan inet 192.168.1.1 netmask 255.255.255.0"; > }; > > I hope someone else might find this useful or perhaps even provide a cleaner approach. There are several similar ways to deal with the device name. For example: action "ifconfig `echo $device-name | sed -e 's/axge/ue/'` name olan inet 192.168.1.1/24"; action "ifconfig ue${device-name##axge} name olan inet 192.168.1.1/24"; (Untested, and sorry about wrapping.) Both examples use the shorter CIDR notation for the netmask, and set the name and IP address at the same time... which ought to work, but I did not test. From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 00:05:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C5FCC4C; Fri, 5 Dec 2014 00:05:06 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 65D6CC60; Fri, 5 Dec 2014 00:05:06 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 16D611A1EC; Thu, 4 Dec 2014 16:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1417737906; x=1417752306; bh=KaxfFvjS7sO3yOlmaggSMEObK2o5pdp5C4VoB2PP258=; h=Date:From:Reply-To:To:Subject; b=ODZnKGJGoI4+IePn/891MEjxpe8l+726xNfqN6QFpLF8Boilz5ni7jZOG2P2z6Cl6 b98MG8TyudDbyCvtIR/3ohiC+b7qUUZCasFw7AwgcJaXo3TmyNJ1htwwDguuJKCxXy sC9QC7FMmQNJV9IJgCQh7vUeJI58V9h3u/EIhW2Q= Message-ID: <5480F6B1.8070802@delphij.net> Date: Thu, 04 Dec 2014 16:05:05 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , Adrian Chadd Subject: Panic after iwn0 controller panic Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Dec 2014 00:05:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I have seen this in the morning when I had an overnight replication from my laptop to my storage system which transfers a lot of data. Before the panic there was some message like: iwn0: iwn_panicked: controller panicked, iv_state = 5; resetting... iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_tx_data: m=0xfffff8001d780300: seqno (61735) (39) != ring index (0) ! Then the panic with fault virtual address (0x1f, which seems to be mbuf->mflags). Call trace was: ithread_loop -> intr_event_execute_handlers -> iwn_intr -> iwn_notif_intr -> iwn_ampdu_tx_done@3717 -> ieee80211_tx_complete@3417 So looks like 'm' was NULL in ieee80211_tx_complete. I don't have INVARIANTS enabled or the panic should be earlier as there is an assertion in iwn(4) right before calling ieee80211_tx_complete: KASSERT(m != NULL, ("no mbuf")); I haven't looked at the issue further yet as I haven't idea how to provoke the issue again. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0 (FreeBSD) iQIcBAEBCgAGBQJUgPauAAoJEJW2GBstM+nsYHcP/187em+bzP6QW7jw6H+cGwI/ NMi2862SL2NfV+0eQt2zPtUd2MmQZzraT13KumAW5uZ3jOBvRxzjnxJq5Ljv6xP/ T+IwLJ/Tu1Yc+oEcWB0CucDU3Xmsbln1iOo5Wwez/Hs0nllvg+jiwMlUgd6zanxN rxldI9xRgEKKLplCWhhIRODC7JFD4kyftPPMafxEVPXVBtgTtr5Yt0uk/1Nr5aii Quct6QbdpT2epa9wpb2Z5VUgLfafOJ43XWpTdI0xXPxkjqQcBf6E4SoVsxoNQ6IM 33BRye/G0RBkSvWSGaSw6DlqYtSU/NG8Wx4JeEjH71Bm6wE2kk9AU3mvcE/cYGdh INKNw4gpP4EDM1v8mhJjRQIOHON2WEaRH535+zJ16v+KERRKmA9BjDPZh/TSC8CF zBRsHrO1SiS0A1tjccOBBOhSKBBvWwH+fVGtsYLRlmkVF/qzGZqYDnvdDskMKPF9 hAJr3ZU8lC6aja44+qKR3z6m5XxnTGqO1kgIrisQHNBydH3HW5MZLbv9Muf/PWqo caJ04rtC1AQfE9N50l3fYsqvAyAncraCaEiaeQQ2oSNO5ruAm0OjjUQBcAq9xGw8 qEjkFHAbxrOV15y5qXSKkSV80rE5/ve1JEbQqGxhhplMc8DPrc4ZS5AIuujOeJvd oaIMRMYo83HUraRy54SN =0TDK -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 00:31:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9517A2F6; Fri, 5 Dec 2014 00:31:44 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69C6FF59; Fri, 5 Dec 2014 00:31:44 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sB50W3nt068842; Thu, 4 Dec 2014 16:32:04 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Martin Hanson , Adrian Chadd In-Reply-To: References: <154421417731858@web18h.yandex.ru>, From: "Chris H" Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED) Date: Thu, 04 Dec 2014 16:32:04 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <495f1468403f248719eb032d83f19002@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Dec 2014 00:31:44 -0000 On Thu, 4 Dec 2014 14:41:11 -0800 Adrian Chadd wrote > On 4 December 2014 at 14:24, Martin Hanson > wrote: > It is worth mentioning that the ONLY reason why this worked is > because > the vendor has provided a serial number. Most vendors don't and it > > would not have worked then. > > > > devd NEEDS to be able to see device MAC addresses! > > I'm surprised it doesn't! Really? I ran into a situation ~2yrs ago trying to manage a dongle based IF, in an effort get it to work with the upstream, that required MAC based authentication. It's in the list archives, somewhere. :) > Would you mind filing a PR so we do expose > that particular bit of data? I'll be happy to do it, myself, now. I'm going to building a wireless switch, and will be doing *quite* a bit of work in this area. So will likely be making contributions, and would like to be kept in the loop. :) @Martin, Thank you very much for your diligence, and for sharing your experience, and *especially* your solution. @Warren; Thanks for your continued dedication! --Chris > > > > -a > _______________________________________________ > 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 5 00:41:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 763F87DF; Fri, 5 Dec 2014 00:41:32 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21B34D2; Fri, 5 Dec 2014 00:41:32 +0000 (UTC) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id sB50frr8070223; Thu, 4 Dec 2014 16:41:53 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Martin Hanson , Adrian Chadd In-Reply-To: <495f1468403f248719eb032d83f19002@ultimatedns.net> References: <154421417731858@web18h.yandex.ru>, , <495f1468403f248719eb032d83f19002@ultimatedns.net> From: "Chris H" Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED) Date: Thu, 04 Dec 2014 16:41:53 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <4a5bfea95654a6e4f561ea17d4c8ac0c@ultimatedns.net> Content-Transfer-Encoding: 8bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Dec 2014 00:41:32 -0000 On Thu, 04 Dec 2014 16:32:04 -0800 "Chris H" wrote > On Thu, 4 Dec 2014 14:41:11 -0800 Adrian Chadd wrote > > > On 4 December 2014 at 14:24, Martin Hanson > > wrote: > It is worth mentioning that the ONLY reason why this worked is > > because > the vendor has provided a serial number. Most vendors don't and > > it > would not have worked then. > > > > > > devd NEEDS to be able to see device MAC addresses! > > > > I'm surprised it doesn't! > Really? I ran into a situation ~2yrs ago trying to manage > a dongle based IF, in an effort get it to work with the > upstream, that required MAC based authentication. It's > in the list archives, somewhere. :) > > > Would you mind filing a PR so we do expose > > that particular bit of data? > I'll be happy to do it, myself, now. Ahh looks like Martin got the jump on me: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195692 > I'm going to building > a wireless switch, and will be doing *quite* a bit of work in > this area. So will likely be making contributions, and would > like to be kept in the loop. :) > > @Martin, Thank you very much for your diligence, and for > sharing your experience, and *especially* your solution. > > @Warren; Thanks for your continued dedication! > > --Chris > --Chris > > > > > > > > -a > > _______________________________________________ > > 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 5 04:41:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3257F938 for ; Fri, 5 Dec 2014 04:41:38 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED915CF4 for ; Fri, 5 Dec 2014 04:41:37 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id ey11so19549621pad.10 for ; Thu, 04 Dec 2014 20:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dpdtech.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uZWkUsOG6SqMzPJKkdIrA3PFQcHWm1a4fUF7I4KjEOU=; b=F83NuST/KDytfGXTUukM0YjQHIUsqo4Y4Sz1o3HMA3nReD4AShQ4O2hTcgoDKzRJUJ zN+SGnej08rHgQ1KfkjBdw9ihmXAD2IoCUVXEAQCJEJwIjQRI61jxZe2M7YsdLLwI5V5 Sgmtl4K/LplKI4Bg6tFf94QMV3ViOl42QNMdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uZWkUsOG6SqMzPJKkdIrA3PFQcHWm1a4fUF7I4KjEOU=; b=RO/LY/RxeuZ2yV+hrUUPuom6syMFC32tP0fsljaWJzBwYSkTiCtWuoxmgbY02SWFrH KM05FBjHwRQQnMbWf8gtaxwvvI2rAS/RtYPDoFWxq8AyclSIIkKLpPIhCtO+7sjo+nHu pjvm3/JawcHvy8XZJhoPBqcdDly/5ymFjosJUFjofA8JeCTJI9oH9/KrMGYczvKrdCIF 36AQtVA8kU+LXgsuuzzNOcfSwDYyy2VFP5wRDiWlgToRagketzJt4JtnjlLxPOZcmhue 8nyv8onvU/zR86VEwbEuoMw/Wo200ADj7k+CSMQ/MEgiswfSbyc1Ezo6LM7wWT9BzIZQ akbQ== X-Gm-Message-State: ALoCoQmuWgWzqY/pTUrAzUvxJFxygcbkDGi1OzJv3qgNt3WQZaj+sxcZgtL6ksPrCpmQ0BuJ8o7b X-Received: by 10.66.138.72 with SMTP id qo8mr25199822pab.84.1417754497329; Thu, 04 Dec 2014 20:41:37 -0800 (PST) Received: from 173-13-188-41-sfba.hfc.comcastbusiness.net (173-13-188-41-sfba.hfc.comcastbusiness.net. [173.13.188.41]) by mx.google.com with ESMTPSA id oy7sm6341066pbc.88.2014.12.04.20.41.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 20:41:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E271A989-FA5B-4C6B-9CEA-657E06CA4527"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working From: "David P. Discher" In-Reply-To: <5480D8EF.9000804@egr.msu.edu> Date: Thu, 4 Dec 2014 20:41:37 -0800 Message-Id: <3D993418-E632-44BA-8FE2-2F3F34188F20@dpdtech.com> References: <1A44709E-7D0C-4932-8A28-383EAC3F340B@dpdtech.com> <9AE69175-92D9-49FA-A651-119C7046A1FA@dpdtech.com> <5480D8EF.9000804@egr.msu.edu> To: Adam McDougall X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Dec 2014 04:41:38 -0000 --Apple-Mail=_E271A989-FA5B-4C6B-9CEA-657E06CA4527 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Adam - On Dec 4, 2014, at 1:58 PM, Adam McDougall wrote: >=20 > Is the switch side set to "active" for the lacp mode (instead of > passive)? Also, try: > sysctl net.link.lagg.0.lacp.lacp_strict_mode=3D0 >=20 > If either of those work, I'll explain more, don't have time to dig for > old email right this minute. Yes, the switch was in active mode. Turn strict mode off (which I = thought I did before, but of course this sysctl clears when destroying = the interface). So, the LACP did finally negotiated, at least in = ifconfig : lagg0: flags=3D8843 metric 0 mtu = 1500 = options=3D4219b ether 00:30:48:35:cc:25 inet 192.168.0.50 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::230:48ff:fe35:cc25%lagg0 prefixlen 64 scopeid 0x4 nd6 options=3D21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: em1 flags=3D1c lacp debug shows good info - though the partner info from the freebsd = host is still zeros.=20 em1: lacpdu transmit actor=3D(8000,00-30-48-35-CC-25,008B,8000,0002) = actor.state=3D7d partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,0000) partner.state=3D3c maxdelay=3D0 But it=92s not passing any traffic. The switch however does not see the = mac address via lagg0. Turning lagg0 off, and just running em1, with = the same ip, it works. Got ssh going on the switch: TL-SG2008#show mac address-table interface gigabitEthernet 1/0/5 =09 MAC vlan-id port type aging --- ------- ---- ---- ----- =09 =09 TL-SG2008# TL-SG2008#show lacp internal Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in active mode P - Device is = in passive mode =09 Channel group 4 LACP = port Admin Oper Port Port Port Flags State Priority Key Key = Number State Gi1/0/5 SA Up 32768 0x4 0x270 0x5 = 0x5 =09 Channel group 5 LACP = port Admin Oper Port Port Port Flags State Priority Key Key = Number State Gi1/0/8 SA Up 32768 0x5 0x35f 0x8 = 0x7d Doing another pcap on the lagg0 and em1 =85 the arp is being sent on the = lagg =85 however it is not being past down to em1.=20 What even makes less sense, as typing this email =85 the ping to my = MacBook (with has staticly assigned 192.168.0.2) wakes up, but the ping = from my macbook to the NAS-lagg (192.168.0.50) doesn=92t do anything. = PCAP of em1 while this is was happening, shows nothing.=20 =09 [ pts/0 nas.dpdtech.com:~ ] = =20 [ dpd ]> ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=3D13 ttl=3D64 time=3D1.127 = ms 64 bytes from 192.168.0.2: icmp_seq=3D14 ttl=3D64 time=3D0.987 = ms 64 bytes from 192.168.0.2: icmp_seq=3D15 ttl=3D64 time=3D95.997 = ms 64 bytes from 192.168.0.2: icmp_seq=3D16 ttl=3D64 time=3D108.118 = ms 64 bytes from 192.168.0.2: icmp_seq=3D17 ttl=3D64 time=3D1.033 = ms =09 64 bytes from 192.168.0.2: icmp_seq=3D62 ttl=3D64 time=3D0.975 = ms 64 bytes from 192.168.0.2: icmp_seq=3D63 ttl=3D64 time=3D1.050 = ms 64 bytes from 192.168.0.2: icmp_seq=3D64 ttl=3D64 time=3D1.002 = ms 64 bytes from 192.168.0.2: icmp_seq=3D65 ttl=3D64 time=3D1.029 = ms 64 bytes from 192.168.0.2: icmp_seq=3D66 ttl=3D64 time=3D1.079 = ms 64 bytes from 192.168.0.2: icmp_seq=3D70 ttl=3D64 time=3D0.957 = ms =09 64 bytes from 192.168.0.2: icmp_seq=3D90 ttl=3D64 time=3D0.987 = ms 64 bytes from 192.168.0.2: icmp_seq=3D92 ttl=3D64 time=3D0.988 = ms 64 bytes from 192.168.0.2: icmp_seq=3D93 ttl=3D64 time=3D1.050 = ms 64 bytes from 192.168.0.2: icmp_seq=3D94 ttl=3D64 time=3D88.678 = ms 64 bytes from 192.168.0.2: icmp_seq=3D95 ttl=3D64 time=3D1.059 = ms =09 64 bytes from 192.168.0.2: icmp_seq=3D120 ttl=3D64 time=3D1.118 = ms 64 bytes from 192.168.0.2: icmp_seq=3D121 ttl=3D64 time=3D1.276 = ms 64 bytes from 192.168.0.2: icmp_seq=3D144 ttl=3D64 time=3D53.300 = ms =09 64 bytes from 192.168.0.2: icmp_seq=3D191 ttl=3D64 time=3D93.479 = ms 64 bytes from 192.168.0.2: icmp_seq=3D192 ttl=3D64 time=3D68.839 = ms 64 bytes from 192.168.0.2: icmp_seq=3D193 ttl=3D64 time=3D1.019 = ms 64 bytes from 192.168.0.2: icmp_seq=3D194 ttl=3D64 time=3D1.096 = ms 64 bytes from 192.168.0.2: icmp_seq=3D195 ttl=3D64 time=3D1.031 = ms 64 bytes from 192.168.0.2: icmp_seq=3D241 ttl=3D64 time=3D0.993 = ms 64 bytes from 192.168.0.2: icmp_seq=3D242 ttl=3D64 time=3D1.095 = ms 64 bytes from 192.168.0.2: icmp_seq=3D243 ttl=3D64 time=3D1.482 = ms Feels like some there is some glue missing. - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz=20 --Apple-Mail=_E271A989-FA5B-4C6B-9CEA-657E06CA4527 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 iQEcBAEBCgAGBQJUgTeCAAoJEEmwU6XuhYWOX5gH/3wWp8sxlAho+Q9GScLvsCIw mGq9H5o53DQN/9s6c3iQJXJQtSKWsw8OQ++cEp4k/uK6NN5iF43326If52Eowx8q LWA3J4QZEtYm03Q4IRzH0e6J8agx78SmrVR/0tTrTjz6FkAVgTV+ZnTZfb3o9s6t 7t9PxFh1t752UqsRlnGX9ZI4498H7wxs7pIpOD2Aq7O7fAjPoR/WhPFWziuLbOOl DXv65FdYRf7wgNlSFXPMEd2/ywY0bcAePluOzdh1+nJJXj0+RL9hXrDvIDjEBAjh R9GgRy/nBwIcCrDpqjVJrPgMUkBqM3ZkHQ5ltlykfQaFzo5wGHp/W6FtQArO3kE= =E4Hp -----END PGP SIGNATURE----- --Apple-Mail=_E271A989-FA5B-4C6B-9CEA-657E06CA4527-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 12:38:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36D0C4A0; Fri, 5 Dec 2014 12:38:59 +0000 (UTC) Received: from relay1.speechpro.com (relay1.speechpro.com [79.134.214.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8003363C; Fri, 5 Dec 2014 12:38:58 +0000 (UTC) Received: from mail.stc ([192.168.8.64] helo=spb2.speechpro.com) by relay1.speechpro.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Xws9n-000NmJ-Cr; Fri, 05 Dec 2014 15:38:47 +0300 Received: from [192.168.6.123] by mail.stc with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Xws9m-000B5v-PL; Fri, 05 Dec 2014 15:38:46 +0300 Message-ID: <5481A756.3090000@speechpro.com> Date: Fri, 05 Dec 2014 15:38:46 +0300 From: Yuriy Tabolin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jack Vogel , "Alexander V. Chernikov" Subject: Re: problem with 9k jumbo clusters References: <54803C75.2020300@speechpro.com> <5480AF38.3070100@FreeBSD.org> In-Reply-To: X-Archived: Yes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Dec 2014 12:38:59 -0000 I would be grateful if you could make patch. 05.12.2014 00:49, Jack Vogel пишет: > I had wanted to remove the larger cluster sizes from the driver a > while back, but for reasons > I don't remember that code change didn't happen. The new 40G ixl > driver does this, it only > uses standard clusters for anything under 2K, and above that > everything uses 4K. > > I would be curious to see if this change would resolve your problem, > would you like a patch, > or are you able to hack the code yourself to do this? > > Jack > > > On Thu, Dec 4, 2014 at 11:00 AM, Alexander V. Chernikov > > wrote: > > On 04.12.2014 13:50, Yuriy Tabolin wrote: > > Hi All. > I have a server with two Intel 10G NIC. OS FreeBSD > 10.1-Release amd64. Server works like NFS, samba-server and > iSCSI target. Both NICs aggregated into lagg device and set > MTU 9014 to them. There are some tuning sysctl.conf: > kern.maxfiles=6289601 > kern.maxfilesperproc=5660640 > kern.maxvnodes=3339565 > kern.ipc.nmbclusters=12255588 > kern.ipc.nmbjumbop=6127794 > kern.ipc.nmbufs=78435780 > kern.ipc.maxsockbuf=16777216 > kern.ipc.maxsockets=6289600 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.sendspace=65536 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.recvspace=65536 > > After some days of working, the errors are appearing: > ix1: Interface stopped DISTRIBUTING, possible flapping > ix0: Interface stopped DISTRIBUTING, possible flapping > ix0: Could not setup receive structures > ix1: Could not setup receive structures > > Hello. It looks like > https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038630.html > is relevant here. > > > After that errors the NICs stoped working. netstat -m shows: > 32881/33854/66735 mbufs in use (current/cache/total) > 16370/8198/24568/12255588 mbuf clusters in use > (current/cache/total/max) > 16370/4807 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/873/873/6127794 4k (page size) jumbo clusters in use > (current/cache/total/max) > 16383/21517/37900/1815641 9k jumbo clusters in use > (current/cache/total/max) > 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) > 188407K/222004K/410411K bytes allocated to network > (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) > 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > > 9k jumbo clusters max is too big, but looks like system cannot > allocate them. There are huge number of "9k requests for jumbo > clusters denied". ifconfig ix down/up don't helped, reboot is > needed. Thanks for any help! > > > -- > Best regards, > Tabolin Yuriy > System administrator > Speech Technology Center > _______________________________________________ > 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 > " > > -- Best regards, Tabolin Yuriy System administrator Speech Technology Center From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 17:26:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0239D8B for ; Fri, 5 Dec 2014 17:26:33 +0000 (UTC) Received: from mail1.traduceridinengleza.me (mail1.traduceridinengleza.me [141.105.71.55]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE06AC8 for ; Fri, 5 Dec 2014 17:26:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim; d=traduceridinengleza.me; h=To:Subject:Message-ID:Date:From:Reply-To:MIME-Version:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; i=marjorie.murdock@traduceridinengleza.me; bh=FBG+PJAQ89ht6JjoQaWaLARDPyI=; b=txxKPbMVw1KUPSHiB7Bf4FdTAatvjnx6//dVD84Ze6WzGAmUFgCkkcX5zT6YGEZRqJVmNDPXNYau A+DRE1V1+wJOYJbA7wCKRyRLUOstfsrm10L3nf7eTfITdCk0WEmt0q0fEAQClbKGjmRh26tnfEC/ VCo5uDSJg3f3OSydmlw= Received: from mail1.traduceridinengleza.me (141.105.71.10) by mail1.traduceridinengleza.me for ; Fri, 5 Dec 2014 19:14:09 +0200 (envelope-from ) To: freebsd-net@freebsd.org Subject: Why your ears keep ringing (and what you can do about it) Message-ID: <3cb486af93b735296d8436c203fffd89@mail1.traduceridinengleza.me> Date: Fri, 05 Dec 2014 20:10:58 +0300 From: "Marjorie Murdock" Reply-To: marjorie.murdock@traduceridinengleza.me MIME-Version: 1.0 X-Mailer-LID: 1 X-Mailer-RecptId: 8910 X-Mailer-SID: 2 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Dec 2014 17:26:34 -0000 Click here to stop receiving these emails: http://mail1.traduceridinengleza.me/unsubscribe.php?M=8910&C=41dc70a4c3bc1a9b1eabaaa447bded29&L=1&N=2 Hello, Last week, I came across this incredible holistic Tinnitus program written by a nutritionist and a health consultant. This guy has the incredible ability to cut through all the BS and hype that surrounds overcoming Tinnitus and getting rid of the ringing in your ears naturally. Click here to read more about this guy`s methods: http://mail1.traduceridinengleza.me/link.php?M=8910&N=2&L=1&F=T He starts from square one and teaches you everything you need to know. Doesn`t matter what type of Tinnitus you have and regardless of your age or lifestyle, you WILL learn something from his materials. Click here to find out more: http://mail1.traduceridinengleza.me/link.php?M=8910&N=2&L=1&F=T sincerely, Marjorie Murdock From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 18:12:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5665AE0A for ; Fri, 5 Dec 2014 18:12:31 +0000 (UTC) Received: from mailout-warwickshire.gigahost.dk (mailout-warwickshire.gigahost.dk [77.74.192.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1E49685 for ; Fri, 5 Dec 2014 18:12:30 +0000 (UTC) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-warwickshire.gigahost.dk (Postfix) with ESMTP id CE6D9F61BA0; Fri, 5 Dec 2014 18:03:58 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.107]) by mailout.gigahost.dk (Postfix) with ESMTP id A3CFB25E102B; Fri, 5 Dec 2014 18:03:58 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 95F1E466063B; Fri, 5 Dec 2014 18:03:58 +0000 (UTC) X-Screener-Id: 2bfb0ba3b22e70c1e23704465ce0c16e022de43a Received: from easynote (80-71-133-54.u.parknet.dk [80.71.133.54]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 710D3466010F; Fri, 5 Dec 2014 18:03:58 +0000 (UTC) Date: Fri, 5 Dec 2014 19:02:55 +0100 From: To: freebsd-net@freebsd.org Subject: Re: NICs devices switches "pshycial" place on each boot (NOT SOLVED) Message-ID: <20141205190255.5f81982d@easynote> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) 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.18-1 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, 05 Dec 2014 18:12:31 -0000 Hi, The solution provided by, Martin before he started his travels, insn't working reliably. devd does not match axgeX with ueX in any fixed manner. So sometimes this will happen: ue0: on axge1 ue0: Ethernet address: 00:24:9b:0d:e0:0c ue1: on axge0 ue1 Ethernet address: 00:24:9b:0f:9d:3f ue2: on axge2 ue2: Ethernet address: 00:24:9b:0e:23:8e "axge1" has been given the "ue0" device name! So when we do a: attach 100 { device-name "axge[0-9]+"; match "vendor" "0x0b95"; match "product" "0x1790"; match "sernum" "0000249B0DE00C"; action "sleep 3"; action "ifconfig ue`echo $device-name | tr -dc '[0-9]'` name olan"; action "ifconfig olan inet 192.168.1.1 netmask 255.255.255.0"; }; }; .. because we're dealing with "axge1", yet it is had been given the "ue0" device name, the above match will rename the "ue1" device instead of the "ue0" device. So the hack is useless. The reason why this is not working (to my understanding) has to do with the assignment of irq numbers on each USB bus. Monitoring devd while attaching devices shows that some stuff are random - leading to the assignment of driver number (axgeX). devd performs the assignment of a device driver (axge) in one attach event and then performs the naming (ueX) in another attach event. The problem is with the second event because it does *not* contain the serial number or any other unique information at all. Currently it is not possible to get both in one go. What needs to be done IMHO is to figure out how devd assigns device names and then completely override that in the first match event. If not possible then another really ugly hack would be to probe ifconfig for device names, MAC addresses and IP numbers and then use that to rename and change things. But I would not want to rely on that! Cheers, Kim From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 18:14:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 182EE9A for ; Fri, 5 Dec 2014 18:14:23 +0000 (UTC) Received: from mailout-warwickshire.gigahost.dk (mailout-warwickshire.gigahost.dk [77.74.192.84]) by mx1.freebsd.org (Postfix) with ESMTP id CC25BAE for ; Fri, 5 Dec 2014 18:14:22 +0000 (UTC) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-warwickshire.gigahost.dk (Postfix) with ESMTP id E1D7BF620AC; Fri, 5 Dec 2014 18:14:21 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.107]) by mailout.gigahost.dk (Postfix) with ESMTP id B28CB25E102B; Fri, 5 Dec 2014 18:14:21 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id A52FE466063C; Fri, 5 Dec 2014 18:14:21 +0000 (UTC) X-Screener-Id: 2bfb0ba3b22e70c1e23704465ce0c16e022de43a Received: from easynote (80-71-133-54.u.parknet.dk [80.71.133.54]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 7815046602C2; Fri, 5 Dec 2014 18:14:21 +0000 (UTC) Date: Fri, 5 Dec 2014 19:14:19 +0100 From: To: freebsd-net@freebsd.org Subject: Re: NICs devices switches "pshycial" place on each boot - another solution Message-ID: <20141205191419.36462c2a@easynote> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) 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.18-1 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, 05 Dec 2014 18:14:23 -0000 > If not possible then another really ugly hack would be to probe > ifconfig for device names, MAC addresses and IP numbers and then use > that to rename and change things. But I would not want to rely on > that! Seems like that wasn't such a bad idea after all :) It just had to be done right :) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195692#c2 Much better approach. Cheers, Kim From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 19:39:02 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07498FC1 for ; Fri, 5 Dec 2014 19:39:02 +0000 (UTC) Received: from mailout-warwickshire.gigahost.dk (mailout-warwickshire.gigahost.dk [77.74.192.84]) by mx1.freebsd.org (Postfix) with ESMTP id C474BC57 for ; Fri, 5 Dec 2014 19:39:01 +0000 (UTC) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-warwickshire.gigahost.dk (Postfix) with ESMTP id 0DDEAF621BD; Fri, 5 Dec 2014 19:39:00 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.107]) by mailout.gigahost.dk (Postfix) with ESMTP id D4E6625E102B; Fri, 5 Dec 2014 19:38:59 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id CA22446606D6; Fri, 5 Dec 2014 19:38:59 +0000 (UTC) X-Screener-Id: 2bfb0ba3b22e70c1e23704465ce0c16e022de43a Received: from easynote (80-71-133-54.u.parknet.dk [80.71.133.54]) by smtp.gigahost.dk (Postfix) with ESMTPSA id A89FE466063B; Fri, 5 Dec 2014 19:38:59 +0000 (UTC) Date: Fri, 5 Dec 2014 20:38:56 +0100 From: To: freebsd-net@freebsd.org Subject: Re: NICs devices switches "pshycial" place on each boot (SOLVED - FOR REAL) Message-ID: <20141205203856.10384916@easynote> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) 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.18-1 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, 05 Dec 2014 19:39:02 -0000 This is what I got working correctly via the solution provided by Warner Losh in Martins bug report about devd. I had some problems getting PF to read its rule set due to it not having all the cards ready before that. I solved that by simply having PF flush and reload its rule set on each device renaming. So.. # cat /usr/local/etc/mac-names-map.txt 00:24:9b:0d:e0:0c olan 192.168.1.1 00:24:9b:0e:23:8e clan 192.168.2.1 00:24:9b:0f:9d:3f plan 192.168.3.1 Remember to make fix-mac-name executable. # cat /usr/local/sbin/fix-mac-name #!/bin/sh # Script to fix a custom device name for the USB->NIC adapters. # This script is being invoked by devd using an attach event that # catches the device name (ueX). dev=$1 mac=$(ifconfig $dev | grep ether | awk '{print $2;}') name=$(grep ^$mac /usr/local/etc/mac-names-map.txt | awk '{print $2;}') IP=$(grep ^$mac /usr/local/etc/mac-names-map.txt | awk '{print $3;}') if [ -n $name ]; then ifconfig $dev name $name ifconfig $name inet $IP netmask 255.255.255.0 # Make sure PF is started correctly again. pfctl -F all -f /etc/pf.conf fi # cat /usr/local/etc/devd/devd.conf notify 100 { match "system" "IFNET"; match "type" "ATTACH"; action "/usr/local/sbin/fix-mac-name $subsystem"; }; That's it. Cheers, Kim From owner-freebsd-net@FreeBSD.ORG Sat Dec 6 03:06:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE7AC5EA for ; Sat, 6 Dec 2014 03:06:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94EAA1B1 for ; Sat, 6 Dec 2014 03:06:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB636m2u098070 for ; Sat, 6 Dec 2014 03:06:48 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB636m52098069; Sat, 6 Dec 2014 03:06:48 GMT (envelope-from root) Date: Sat, 6 Dec 2014 03:06:48 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Accepted] D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. Message-ID: X-Priority: 3 Thread-Topic: D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MTgwYzEyNmI0NDMyNDcyOWUzYmZmMDUyYzA0IFSCcsg= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Dec 2014 03:06:48 -0000 rodrigc accepted this revision. rodrigc added a reviewer: rodrigc. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1201 To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: freebsd-net, emaste, gnn, rwatson From owner-freebsd-net@FreeBSD.ORG Sat Dec 6 03:20:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7209AE7 for ; Sat, 6 Dec 2014 03:20:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B12D1383 for ; Sat, 6 Dec 2014 03:20:48 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id sB63Kmii014884 for ; Sat, 6 Dec 2014 03:20:48 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id sB63Km6L014883; Sat, 6 Dec 2014 03:20:48 GMT (envelope-from root) Date: Sat, 6 Dec 2014 03:20:48 +0000 To: freebsd-net@freebsd.org From: "rodrigc (Craig Rodrigues)" Subject: [Differential] [Closed] D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. Message-ID: <4fc459cfc2c26df158fd34cc277b410b@localhost.localdomain> X-Priority: 3 Thread-Topic: D1201: Allow UMA allocated memory to be freed when VNET jails are torn down. X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: MTgwYzEyNmI0NDMyNDcyOWUzYmZmMDUyYzA0IFSCdhA= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Dec 2014 03:20:48 -0000 rodrigc closed this revision. rodrigc added a comment. Committed in S275555 REVISION DETAIL https://reviews.freebsd.org/D1201 To: rodrigc, alfredperlstein, melifaro, glebius, hrs, wollman, bryanv, rpaulo, adrian, bz, gnn, hiren, rwatson Cc: freebsd-net, emaste, gnn, rwatson