From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 12:20:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8BFB106566C for ; Sun, 23 Sep 2012 12:20:35 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 936178FC17 for ; Sun, 23 Sep 2012 12:20:35 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id q8NCKSHQ094236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Sep 2012 14:20:34 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id q8NCKSiK094235 for freebsd-net@freebsd.org; Sun, 23 Sep 2012 14:20:28 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Sun, 23 Sep 2012 14:20:28 +0200 From: Paul Schenkeveld To: freebsd-net@freebsd.org Message-ID: <20120923122028.GA41844@psconsult.nl> References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Sep 2012 12:20:36 -0000 On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote: > Actually, multiple routing tables is the correct solution. I documented it > here: > > http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ > > >From the post: "... But route-to and reply-to do not trump the default > routing table for traffic that originates or terminates on the router > itself. They are useful only for traffic passing through the router. pf can > only make routing decisions when a packet passes through an interface. It > can try and set the reply-to interface to be the second WAN connection when > an inbound SSH connection is made, but neither the SSH daemon nor the > routing table on the host know or care about the routing preferences of pf." FWIW, I've many dual-homed machined running perfectly by combining pf for filtering and ipfw for policy-based routing. Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first WAN connection and d.e.f.0/29 the second): 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 01001 allow carp from any to any 01002 allow pfsync from any to any 01100 allow ip from any to 10.0.0.0/8 01101 allow ip from any to 172.16.0.0/12 01102 allow ip from any to 192.168.0.0/16 01103 allow ip from any to 224.0.0.0/3 01110 allow ip from any to 01111 allow ip from any to ... 01200 fwd a.b.c.1 ip from a.b.c.0/29 to any 01201 fwd d.e.f.1 ip from d.e.f.0/29 to any 65535 allow ip from any to any Lines 1100 thru 1111 pass all traffic that should not go out over a WAN interface, they follow the normal routing table. I need the lines 011xx because I have multiple public IP address blocks on the inside and behind tunnels. Lines 1200 and 1201 forward packets to either WAN interface depending on the source address. I also have a default gateway set to my preferred WAN interface for connections originating from this host where the client does not explicitly select a source address. This works both for packets being routed and for packets originating from the dual homes host itself. I've been using this since FreeBSD 6 and never felt the need to switch to multiple routing tables because this fits the purpose and is quite clean IMO. It's also not necessary to run multiple server processes (like sshd, sendmail, httpd) for every routing domain. With kind regards, Paul Schenkeveld From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 15:35:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1AE1106566B for ; Sun, 23 Sep 2012 15:35:17 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 620638FC15 for ; Sun, 23 Sep 2012 15:35:16 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so7013027lbb.13 for ; Sun, 23 Sep 2012 08:35:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=rylUOdV8Z67bH3pKioSaZu+Un9FR4duF1k52CYLlNcA=; b=Wgv4hkZg/m6J3AbhP3gXVydVjVwtqz8A/eEuWOpEjabHD9fYg0nC4W2j9kXjWww3QG 6fNRl/rm0tKmLy9GGHAevyjjubsLTnufSHAoabqj4PTiG+QutEx2986pfzB1fc6rdaBd j4IGFf5vQX5LmJm6d9tnErF7de6W4N7I+iA4a8O3q0IUHvJuLtzfVedrDDeHA7C1mfDT 1mHlfQIzWmt8RTgSyl3SEKpsWpJ/MBJLFPLP7lN7pXcf7A5+V/HeiR5NgfW0hhB/uef2 Nqc2FN3lpNgfD1pX4Il+JL4F+oL99nI4jeyfS1DD4t1DhMkE1Y5fLRrFkS2DfMiMID+e 3Lxw== Received: by 10.152.110.9 with SMTP id hw9mr8517830lab.55.1348414515708; Sun, 23 Sep 2012 08:35:15 -0700 (PDT) Received: from zont-osx.local (ppp95-165-139-113.pppoe.spdop.ru. [95.165.139.113]) by mx.google.com with ESMTPS id d1sm3642952lbh.7.2012.09.23.08.35.13 (version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 08:35:14 -0700 (PDT) Sender: Andrey Zonov Message-ID: <505F2C2D.5050904@FreeBSD.org> Date: Sun, 23 Sep 2012 19:35:09 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <505AC500.6060903@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig820D10D9530C18AC3549AFD4" X-Gm-Message-State: ALoCoQlL6buVtEoSytnnxFo5nMuU7UhbOXgmnTTrCWM7vJgkdzHR2Rhh71kXO+Ys9XPvcxAPH+z1 Cc: "freebsd-net@freebsd.org" Subject: Re: [patch] sysctls for TCP timers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Sep 2012 15:35:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig820D10D9530C18AC3549AFD4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/20/12 11:35 AM, Eggert, Lars wrote: > Hi, >=20 > On Sep 20, 2012, at 9:25, Andrey Zonov wrote: >> Some of them may be read google's article about tuning TCP parameters >> [1]. I convert most of TCP timers to sysctls [2] and we are using thi= s >> patch for few months. We tuned net.inet.tcp.rtobase and >> net.inet.tcp.syncache.rexmttime and it gives good results (especially = in >> conjunction with cc_htcp(4)). >=20 > can you share some measurements that quantify the results? >=20 When we set net.inet.tcp.syncache.rexmttime=3D200 and net.inet.tcp.syncache.rexmtlimit=3D7 for our external web service, the number of duplicated SYN was reduced in four times. --=20 Andrey Zonov --------------enig820D10D9530C18AC3549AFD4 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.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQXywwAAoJEBWLemxX/CvTuoQH/1b0a2TTuiQ+t/c65FBBcRG1 oQvAEf9T+aT1yxB603+itGu9iS+Rf775E4TwpkNEBOOfPY2qjzsH/L2UB+by2HL8 JwvVizXMfZgqmHR7U0HoXWN8isiYng1aA7SVSCVZdZz7ZeLXehNdGA0BGHj8ZO3M XUiI6Pq9wnH1wSIYBSPHsFCOqBX06390/yxJUS55Twq4pICamaVu8xDcrOLSl9hu kQw4bErBHyDm0x96H/GLPy5Fh5YMUlFSuLi/eZRCb8ytqeWFLEyLvRFT4lGWhhi8 k5qq9tTTGaobHQOtOpd+pVYLu3ZlR1Y/zQW9/KAvbpsHFlIQaiIztw36X2srV+M= =4g0B -----END PGP SIGNATURE----- --------------enig820D10D9530C18AC3549AFD4-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 23 20:41:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75879106564A for ; Sun, 23 Sep 2012 20:41:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA618FC08 for ; Sun, 23 Sep 2012 20:41:34 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-8.hsd1.ca.comcast.net [50.143.149.8]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q8NKfVWf022174 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 23 Sep 2012 13:41:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <505F73FB.9060804@freebsd.org> Date: Sun, 23 Sep 2012 13:41:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Schenkeveld References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> <20120923122028.GA41844@psconsult.nl> In-Reply-To: <20120923122028.GA41844@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Sep 2012 20:41:34 -0000 On 9/23/12 5:20 AM, Paul Schenkeveld wrote: > On Thu, Sep 20, 2012 at 01:25:50PM -0400, Michael MacLeod wrote: >> Actually, multiple routing tables is the correct solution. I documented it >> here: >> >> http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ >> >> >From the post: "... But route-to and reply-to do not trump the default >> routing table for traffic that originates or terminates on the router >> itself. They are useful only for traffic passing through the router. pf can >> only make routing decisions when a packet passes through an interface. It >> can try and set the reply-to interface to be the second WAN connection when >> an inbound SSH connection is made, but neither the SSH daemon nor the >> routing table on the host know or care about the routing preferences of pf." > FWIW, I've many dual-homed machined running perfectly by combining pf > for filtering and ipfw for policy-based routing. > > Basically, ipfw is configured roughly as follows (a.b.c.0/29 is the first > WAN connection and d.e.f.0/29 the second): > > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > > 01001 allow carp from any to any > 01002 allow pfsync from any to any > > 01100 allow ip from any to 10.0.0.0/8 > 01101 allow ip from any to 172.16.0.0/12 > 01102 allow ip from any to 192.168.0.0/16 > 01103 allow ip from any to 224.0.0.0/3 > > 01110 allow ip from any to > 01111 allow ip from any to > ... > > 01200 fwd a.b.c.1 ip from a.b.c.0/29 to any > 01201 fwd d.e.f.1 ip from d.e.f.0/29 to any > > 65535 allow ip from any to any > > Lines 1100 thru 1111 pass all traffic that should not go out over a > WAN interface, they follow the normal routing table. I need the lines > 011xx because I have multiple public IP address blocks on the inside > and behind tunnels. Lines 1200 and 1201 forward packets to either WAN > interface depending on the source address. > > I also have a default gateway set to my preferred WAN interface for > connections originating from this host where the client does not > explicitly select a source address. > > This works both for packets being routed and for packets originating > from the dual homes host itself. > > I've been using this since FreeBSD 6 and never felt the need to switch > to multiple routing tables because this fits the purpose and is quite > clean IMO. It's also not necessary to run multiple server processes > (like sshd, sendmail, httpd) for every routing domain. Interesting but but seems to me that for this to work you need to make every host inside dual home, or at least assign each internal machine to one ISP or the other. > With kind regards, > > Paul Schenkeveld > _______________________________________________ > 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 Sep 24 11:07:28 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 522C3106566B for ; Mon, 24 Sep 2012 11:07:28 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0F58FC27 for ; Mon, 24 Sep 2012 11:07:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8OB7SpO086024 for ; Mon, 24 Sep 2012 11:07:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8OB7RWc086022 for freebsd-net@FreeBSD.org; Mon, 24 Sep 2012 11:07:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Sep 2012 11:07:27 GMT Message-Id: <201209241107.q8OB7RWc086022@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Sep 2012 11:07:28 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow o kern/171520 net [alc] alc network driver + tso + vlan does not work. s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170713 net [cxgb] Driver must be loaded after boot due to timing o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 420 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 17:00:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B95651065678 for ; Mon, 24 Sep 2012 17:00:08 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id C200F8FC16 for ; Mon, 24 Sep 2012 17:00:08 +0000 (UTC) Received: from invalid-dns.RFC1918.monkeybrains.net (199-116-74-151-v301.PUBLIC.monkeybrains.net [199.116.74.151]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8OGKYJQ094435 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 24 Sep 2012 09:20:34 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <5060884C.3050709@monkeybrains.net> Date: Mon, 24 Sep 2012 09:20:28 -0700 From: "Rudy (bulk)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Sep 2012 17:00:10 -0000 Sometimes when I try to ping a neighbor machine (plugged directly in with no switch involved), I get: ping: sendto: No buffer space available ping: sendto: No buffer space available If I reset the interface 'ifconfig em1 down; ifconfig em1 up' the problem goes away. The pings are: FreeBSD 8.3 em1 --> FreeBSD 9.0 em2 and I am seeing the issue on the FreeBSD 8.3 machine. The box has 6GB of free ram and is a quagga router. What do I need to tune? Thanks! Rudy # netstat -m 10236/8454/18690 mbufs in use (current/cache/total) 10234/5388/15622/262144 mbuf clusters in use (current/cache/total/max) 10234/5382 mbuf+clusters out of packet secondary zone in use (current/cache) 0/327/327/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/3070/3070/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 23027K/41827K/64854K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # ifconfig em1 em1: flags=8843 metric 0 mtu 1500 options=4219b ether 00:25:90:56:60:7f inet 10.1.1.1 netmask 0xfffffffc broadcast 10.1.1.3 media: Ethernet autoselect (1000baseT ) status: active FreeBSD 8.3 ### loader.conf: net.link.ifqmaxlen=1024 hw.em.rxd=1024 hw.em.txd=1024 ### sysctl.conf: kern.timecounter.hardware=HPET net.route.netisr_maxqlen=2048 net.inet.ip.intr_queue_maxlen=1024 kern.ipc.somaxconn=256 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.ethernet=0 net.inet.raw.maxdgram=16384 net.inet.raw.recvspace=16384 net.inet.icmp.icmplim=1000 net.inet.ip.fastforwarding=1 kern.ipc.nmbclusters=262144 net.inet.icmp.drop_redirect=1 dev.em.0.rx_processing_limit=200 dev.em.1.rx_processing_limit=200 dev.em.2.rx_processing_limit=200 dev.em.3.rx_processing_limit=200 net.link.ether.inet.max_age=300 hw.intr_storm_threshold=9000 # Security net.inet.ip.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.maskrepl=0 Not sure if it matters, but here are the tunings on the other box: FreeBSD 9.0 ### loader.conf: net.link.ifqmaxlen="512" ### sysctl.conf: net.inet.ip.fastforwarding=1 kern.ipc.nmbclusters=262144 kern.timecounter.hardware=HPET net.inet.ip.rtminexpire=2 net.inet.ip.rtmaxcache=1024 dev.igb.0.rx_processing_limit=480 dev.igb.1.rx_processing_limit=480 net.inet.icmp.icmplim=1000 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.ethernet=0 net.link.ether.inet.max_age=300 ##Sat Apr 21 00:06:48 PDT 2012 net.inet.ip.redirect=0 net.route.netisr_maxqlen=2048 From owner-freebsd-net@FreeBSD.ORG Mon Sep 24 17:33:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94E2C1065745 for ; Mon, 24 Sep 2012 17:33:35 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward20.mail.yandex.net (forward20.mail.yandex.net [IPv6:2a02:6b8:0:1402::5]) by mx1.freebsd.org (Postfix) with ESMTP id A73678FC0C for ; Mon, 24 Sep 2012 17:33:34 +0000 (UTC) Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward20.mail.yandex.net (Yandex) with ESMTP id 37F1E1041BE9; Mon, 24 Sep 2012 21:33:33 +0400 (MSK) Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id 13C546A06C9; Mon, 24 Sep 2012 21:33:33 +0400 (MSK) Received: from unknown (unknown [77.93.52.20]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTP id XW44Ruhj-XW44SBDI; Mon, 24 Sep 2012 21:33:32 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1348508013; bh=dwe28RxXyiSQ+43c/G6OSHQ8aVI2seg5oblAYE8zSk8=; h=Date:From:X-Mailer:Reply-To:Organization:X-Priority:Message-ID:To: CC:Subject:In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding; b=SuiX/fZrKfXE8T9qYW61JDXk0QP6k+VhLdvFw8qm/v3eQL2FJ0FL0NJNwT4pl4duI KXnoJuC6/nKDRIaL5LvfLpKo4S2ep5rUYDBTO6OO6BPrj93yc7KCbhcW2B/sbYCfyM Sr7ja8k022ueMzp6XvxwdbIJsJarmLpbP1z6vaRE= Date: Mon, 24 Sep 2012 20:33:31 +0300 From: Eugen Konkov X-Mailer: The Bat! (v4.0.24) Professional Organization: ISP FreeLine X-Priority: 3 (Normal) Message-ID: <1024127597.20120924203331@yandex.ru> To: "Rudy (bulk)" In-Reply-To: <5060884C.3050709@monkeybrains.net> References: <5060884C.3050709@monkeybrains.net> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugen Konkov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 17:33:35 -0000 Çäðàâñòâóéòå, Rudy. check routing table and show which IP you ping. Âû ïèñàëè 24 ñåíòÿáðÿ 2012 ã., 19:20:28: Rb> Sometimes when I try to ping a neighbor machine (plugged directly in Rb> with no switch involved), I get: Rb> ping: sendto: No buffer space available Rb> ping: sendto: No buffer space available Rb> If I reset the interface 'ifconfig em1 down; ifconfig em1 up' the Rb> problem goes away. Rb> The pings are: Rb> FreeBSD 8.3 em1 --> FreeBSD 9.0 em2 Rb> and I am seeing the issue on the FreeBSD 8.3 machine. The box has 6GB Rb> of free ram and is a quagga router. Rb> What do I need to tune? Rb> Thanks! Rb> Rudy Rb> # netstat -m Rb> 10236/8454/18690 mbufs in use (current/cache/total) Rb> 10234/5388/15622/262144 mbuf clusters in use (current/cache/total/max) Rb> 10234/5382 mbuf+clusters out of packet secondary zone in use (current/cache) Rb> 0/327/327/12800 4k (page size) jumbo clusters in use Rb> (current/cache/total/max) Rb> 0/3070/3070/6400 9k jumbo clusters in use (current/cache/total/max) Rb> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) Rb> 23027K/41827K/64854K bytes allocated to network (current/cache/total) Rb> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) Rb> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) Rb> 0/0/0 sfbufs in use (current/peak/max) Rb> 0 requests for sfbufs denied Rb> 0 requests for sfbufs delayed Rb> 0 requests for I/O initiated by sendfile Rb> 0 calls to protocol drain routines Rb> # ifconfig em1 Rb> em1: flags=8843 metric 0 mtu 1500 Rb> options=4219b Rb> ether 00:25:90:56:60:7f Rb> inet 10.1.1.1 netmask 0xfffffffc broadcast 10.1.1.3 Rb> media: Ethernet autoselect (1000baseT ) Rb> status: active Rb> FreeBSD 8.3 Rb> ### loader.conf: Rb> net.link.ifqmaxlen=1024 Rb> hw.em.rxd=1024 Rb> hw.em.txd=1024 Rb> ### sysctl.conf: Rb> kern.timecounter.hardware=HPET Rb> net.route.netisr_maxqlen=2048 Rb> net.inet.ip.intr_queue_maxlen=1024 Rb> kern.ipc.somaxconn=256 Rb> kern.random.sys.harvest.interrupt=0 Rb> kern.random.sys.harvest.ethernet=0 Rb> net.inet.raw.maxdgram=16384 Rb> net.inet.raw.recvspace=16384 Rb> net.inet.icmp.icmplim=1000 Rb> net.inet.ip.fastforwarding=1 Rb> kern.ipc.nmbclusters=262144 Rb> net.inet.icmp.drop_redirect=1 Rb> dev.em.0.rx_processing_limit=200 Rb> dev.em.1.rx_processing_limit=200 Rb> dev.em.2.rx_processing_limit=200 Rb> dev.em.3.rx_processing_limit=200 Rb> net.link.ether.inet.max_age=300 Rb> hw.intr_storm_threshold=9000 Rb> # Security Rb> net.inet.ip.redirect=0 Rb> net.inet.ip.sourceroute=0 Rb> net.inet.ip.accept_sourceroute=0 Rb> net.inet.icmp.maskrepl=0 Rb> Not sure if it matters, but here are the tunings on the other box: Rb> FreeBSD 9.0 Rb> ### loader.conf: Rb> net.link.ifqmaxlen="512" Rb> ### sysctl.conf: Rb> net.inet.ip.fastforwarding=1 Rb> kern.ipc.nmbclusters=262144 Rb> kern.timecounter.hardware=HPET Rb> net.inet.ip.rtminexpire=2 Rb> net.inet.ip.rtmaxcache=1024 Rb> dev.igb.0.rx_processing_limit=480 Rb> dev.igb.1.rx_processing_limit=480 Rb> net.inet.icmp.icmplim=1000 Rb> kern.random.sys.harvest.interrupt=0 Rb> kern.random.sys.harvest.ethernet=0 Rb> net.link.ether.inet.max_age=300 Rb> ##Sat Apr 21 00:06:48 PDT 2012 Rb> net.inet.ip.redirect=0 Rb> net.route.netisr_maxqlen=2048 Rb> _______________________________________________ Rb> freebsd-net@freebsd.org mailing list Rb> http://lists.freebsd.org/mailman/listinfo/freebsd-net Rb> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Ñ óâàæåíèåì, Eugen mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 00:01:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B18A1065672 for ; Tue, 25 Sep 2012 00:01:57 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B3A898FC15 for ; Tue, 25 Sep 2012 00:01:56 +0000 (UTC) Received: by vbmv11 with SMTP id v11so8568846vbm.13 for ; Mon, 24 Sep 2012 17:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=97hV/U5IUm4SSFteS+LOg7R2muCtwrqn8ej8UmHVjQM=; b=tB94oecBEB0SkhqDRMPwff+mfqAf397rVh1/JcoPcmq4WWNB1FqG9g41LEwQ0Isfg7 +f5fnKA87rsJraED4KSz2KOvKFSspF72QYLcYhIPfMRpKyCn+SiXVs/v0tBvg408N7Du sdB1w4ETwKkiQcyHnWWv19gIXxkSf2sMxlLgNn85G7J3fAQPgWYRF5SZaDfMdL/FAiwd 4CojentIjKJmTltyw+CcZkZJNIzG5VLRJuHwOkljvHyWS4gI7PDMDBAhIusOVAJV9Cig j9jWe5AcsrkjKclTHN2HCgyValAa67fOywloqBLlph3MvSRrSAaeYK4eL6npFvDrD+K8 W65g== MIME-Version: 1.0 Received: by 10.221.13.202 with SMTP id pn10mr8234301vcb.57.1348531309673; Mon, 24 Sep 2012 17:01:49 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Mon, 24 Sep 2012 17:01:49 -0700 (PDT) In-Reply-To: <5060884C.3050709@monkeybrains.net> References: <5060884C.3050709@monkeybrains.net> Date: Mon, 24 Sep 2012 20:01:49 -0400 Message-ID: From: Ryan Stone To: "Rudy (bulk)" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 00:01:57 -0000 Can you get the output of netstat -I emX -d? You don't need to run that when the problem is happening -- you just need to run it on the machine after it exhibits the issue without any reboots in the interim. I suspect that you are seeing the em TX queue fill up. If so you should see output drops reported by the em interface. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 03:06:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FF801065677 for ; Tue, 25 Sep 2012 03:06:31 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 20C9E8FC1B for ; Tue, 25 Sep 2012 03:06:30 +0000 (UTC) Received: from invalid-dns.RFC1918.monkeybrains.net (199-116-74-151-v301.PUBLIC.monkeybrains.net [199.116.74.151]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8P36Thh020410 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 24 Sep 2012 20:06:30 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <50611FAE.7060809@monkeybrains.net> Date: Mon, 24 Sep 2012 20:06:22 -0700 From: "Rudy (bulk)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ryan Stone References: <5060884C.3050709@monkeybrains.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 03:06:31 -0000 On 9/24/12 5:01 PM, Ryan Stone wrote: > Can you get the output of netstat -I emX -d? ... > > I suspect that you are seeing the em TX queue fill up. If so you > should see output drops reported by the em interface. > I do see 205 in the 'Drop' column. I ran the command twice two hours apart... I am seeing Ierrsincrement in a 2 hours window... #date && netstat -I em1 -d Mon Sep 24 17:47:14 PDT 2012 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em1 1500 00:25:90:26:62:01 110170687801 4738950 0 85411108876 0 0 205 em1 1500 X.X.X.X coconut.coconut-g 111858 - - 6536889 - - - em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - - - # date && netstat -I em1 -d Mon Sep 24 19:48:44 PDT 2012 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em1 1500 00:25:90:26:62:01 110723416486 4768451 0 85861866459 0 0 205 em1 1500 X.X.X.X coconut.coconut-g 119244 - - 6558411 - - - em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - - - Checking all the interfaces, there are a lot more drops/Ierrs on em2... The igb devices (PCIe card) seem a lot better than the Supermicro motherboard em devices. Is this an on-board vs mb thing, or em vs igb thing? # date && netstat -id Mon Sep 24 19:53:49 PDT 2012 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:26:62:00 6887931271 844 0 18966954063 0 0 0 em0 1500 X.X.X.X coconut 1804123 - - 1962796 - - - em0 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 1 - - - em1 1500 00:25:90:26:62:01 110745957108 4770615 0 85882005650 0 0 205 em1 1500 X.X.X.Xcoconut.coconut-g 119573 - - 6559700 - - - em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - - - igb0 1500 00:1b:21:af:54:4e 53194278790 1169 0 85861440371 0 0 0 igb0 1500 fe80::21b:21f fe80::21b:21ff:fe 0 - - 1 - - - igb1 1500 00:1b:21:af:54:4f 43905355772 0 0 24817874325 0 0 0 igb1 1500 fe80::21b:21f fe80::21b:21ff:fe 0 - - 1 - - - usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 usbus 0 0 0 0 0 0 0 0 em2 1500 00:25:90:26:62:02 2458414787 580252415422 0 1640052168 0 0 37284 em2 1500 X.X.X.Xcoconut.guava-coc 93119 - - 209407 - - - em2 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 2 - - - em3 1500 00:25:90:26:62:03 57160105 0 0 87941536 0 0 0 em3 1500 X.X.X.XAS32329.weed-mb.c 1014267 - - 1208726 - - - em3 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 1 - - - Rudy From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 03:49:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 959CA106566B for ; Tue, 25 Sep 2012 03:49:25 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 34BE78FC14 for ; Tue, 25 Sep 2012 03:49:25 +0000 (UTC) Received: from X220.ovitrap.com ([122.129.201.21]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q8P3nGBJ017998; Mon, 24 Sep 2012 21:49:17 -0600 Date: Tue, 25 Sep 2012 10:49:15 +0700 From: Erich Dollansky To: "Rudy (bulk)" Message-ID: <20120925104915.6aa98b88@X220.ovitrap.com> In-Reply-To: <50611FAE.7060809@monkeybrains.net> References: <5060884C.3050709@monkeybrains.net> <50611FAE.7060809@monkeybrains.net> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net , Ryan Stone Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 03:49:25 -0000 Hi, On Mon, 24 Sep 2012 20:06:22 -0700 "Rudy (bulk)" wrote: > Checking all the interfaces, there are a lot more drops/Ierrs on > em2... The igb devices (PCIe card) seem a lot better than the > Supermicro motherboard em devices. Is this an on-board vs mb thing, > or em vs igb thing? > I do not have any experience with this hardware. I only can speak for iwn, run and the em thing in my machine. I am travelling with this hardware most of the time I have bought it. I hardly notice drops on the em interface connection to locally connected machines. I see a drop range from 0 to 100% when iwn is connecting to the same AP while run ranges from 0 to 10% at the same moment of time. But when I connect via iwn to a different AP and stay within 10m the drop rate is 0 again. With other words, it can be a problem caused how the actual hardware pieces connect to each other. It could be in your case that the PCI card has simply a better layout. I do not believe that on-board hardware is generally bad. Can you change the hardware this machine is talking to? Erich From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 04:12:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F72106564A for ; Tue, 25 Sep 2012 04:12:29 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 52FD28FC0A for ; Tue, 25 Sep 2012 04:12:28 +0000 (UTC) Received: from invalid-dns.RFC1918.monkeybrains.net (199-116-74-151-v301.PUBLIC.monkeybrains.net [199.116.74.151]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8P4CS76026384 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 24 Sep 2012 21:12:29 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <50612F24.7020008@monkeybrains.net> Date: Mon, 24 Sep 2012 21:12:20 -0700 From: "Rudy (bulk)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-net References: <5060884C.3050709@monkeybrains.net> <50611FAE.7060809@monkeybrains.net> <20120925104915.6aa98b88@X220.ovitrap.com> In-Reply-To: <20120925104915.6aa98b88@X220.ovitrap.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Cc: Jack Vogel Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 04:12:29 -0000 On 9/24/12 8:49 PM, Erich Dollansky wrote: > Hi, > > On Mon, 24 Sep 2012 20:06:22 -0700 > "Rudy (bulk)" wrote: > >> Checking all the interfaces, there are a lot more drops/Ierrs on >> em2... The igb devices (PCIe card) seem a lot better than the >> Supermicro motherboard em devices. Is this an on-board vs mb thing, >> or em vs igb thing? >> > I hardly notice drops on the em interface connection to locally > connected machines. I ordered a replacement system with ix and igb on the motherboard. I'm pointing my finger at the motherboard em (and my inability to properly tune it). http://www.supermicro.com/products/system/1U/1026/SYS-1026T-6RF_.cfm Rudy From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 04:41:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59F90106566C for ; Tue, 25 Sep 2012 04:41:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1801C8FC0C for ; Tue, 25 Sep 2012 04:41:35 +0000 (UTC) Received: by oagm1 with SMTP id m1so7976593oag.13 for ; Mon, 24 Sep 2012 21:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hJSvLhznB5ERZoe1gC01+F+FbjsyiN1+4I/3GMVRzaU=; b=VTae2pyaKN/7dBpj6W0XyKYYjol4+DVzWS1i8wyJ6GK+ZxlKi/ZznlTqUrcA+s//EA +r3PyPz+kkXfj2Cj441K+VBgxIClsNNFso6Bps8NE6xBybvXHiHY3js6cMbFMOED6OqI S0xX79+8vUJEwUZxRXTbfDkl5AD3gXskcf1+yutl5/ycu/+l2LMGTm/IiQH4WKbjM25k rNKP378xZgwdU9IkDiJm7XG4K6qOroljcPDzWvV6TW9HEm6YRg6ePqIGGHLeJeVdzdMn 7+44hW72jnHOTZOs1E5Rp6Mzu3Y18FP8K6vELKUWA35wtSJnniXVjoLMeArx2VeCRP1e ahVA== MIME-Version: 1.0 Received: by 10.60.170.69 with SMTP id ak5mr1946419oec.69.1348548088905; Mon, 24 Sep 2012 21:41:28 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Mon, 24 Sep 2012 21:41:28 -0700 (PDT) In-Reply-To: <50611FAE.7060809@monkeybrains.net> References: <5060884C.3050709@monkeybrains.net> <50611FAE.7060809@monkeybrains.net> Date: Mon, 24 Sep 2012 21:41:28 -0700 Message-ID: From: Garrett Cooper To: "Rudy (bulk)" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net , Ryan Stone Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 04:41:36 -0000 On Mon, Sep 24, 2012 at 8:06 PM, Rudy (bulk) wrote: > On 9/24/12 5:01 PM, Ryan Stone wrote: >> >> Can you get the output of netstat -I emX -d? > > ... > >> >> I suspect that you are seeing the em TX queue fill up. If so you >> should see output drops reported by the em interface. >> > I do see 205 in the 'Drop' column. I ran the command twice two hours > apart... I am seeing Ierrsincrement in a 2 hours window... > > #date && netstat -I em1 -d > Mon Sep 24 17:47:14 PDT 2012 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts > Oerrs Coll Drop > em1 1500 00:25:90:26:62:01 110170687801 4738950 0 > 85411108876 0 0 205 > em1 1500 X.X.X.X coconut.coconut-g 111858 - - 6536889 > - - - > em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - > - - > > # date && netstat -I em1 -d > Mon Sep 24 19:48:44 PDT 2012 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts > Oerrs Coll Drop > em1 1500 00:25:90:26:62:01 110723416486 4768451 0 > 85861866459 0 0 205 > em1 1500 X.X.X.X coconut.coconut-g 119244 - - 6558411 - > - - > em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - > - - > > Checking all the interfaces, there are a lot more drops/Ierrs on em2... The > igb devices (PCIe card) seem a lot better than the Supermicro motherboard em > devices. Is this an on-board vs mb thing, or em vs igb thing? > > # date && netstat -id > Mon Sep 24 19:53:49 PDT 2012 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts > Oerrs Coll Drop > em0 1500 00:25:90:26:62:00 6887931271 844 0 18966954063 > 0 0 0 > em0 1500 X.X.X.X coconut 1804123 - - 1962796 > - - - > em0 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 1 - > - - > em1 1500 00:25:90:26:62:01 110745957108 4770615 0 > 85882005650 0 0 205 > em1 1500 X.X.X.Xcoconut.coconut-g 119573 - - 6559700 - > - - > em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 0 - > - - > igb0 1500 00:1b:21:af:54:4e 53194278790 1169 0 > 85861440371 0 0 0 > igb0 1500 fe80::21b:21f fe80::21b:21ff:fe 0 - - 1 - > - - > igb1 1500 00:1b:21:af:54:4f 43905355772 0 0 24817874325 > 0 0 0 > igb1 1500 fe80::21b:21f fe80::21b:21ff:fe 0 - - 1 - > - - > usbus 0 0 0 0 0 0 > 0 0 > usbus 0 0 0 0 0 0 > 0 0 > usbus 0 0 0 0 0 0 > 0 0 > usbus 0 0 0 0 0 0 > 0 0 > em2 1500 00:25:90:26:62:02 2458414787 580252415422 0 > 1640052168 0 0 37284 > em2 1500 X.X.X.Xcoconut.guava-coc 93119 - - 209407 - > - - > em2 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 2 - > - - > em3 1500 00:25:90:26:62:03 57160105 0 0 87941536 0 > 0 0 > em3 1500 X.X.X.XAS32329.weed-mb.c 1014267 - - 1208726 - > - - > em3 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 1 - > - - I saw similar issues (although maybe not tied to e1000 directly) when messing around with IPv6 interfaces (I have em and cxgb at my immediate disposal right now). Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 06:53:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A24B106564A for ; Tue, 25 Sep 2012 06:53:09 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE24A8FC08 for ; Tue, 25 Sep 2012 06:53:08 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so4683982pbb.13 for ; Mon, 24 Sep 2012 23:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=keG1noiku23XRAdW0MQ4BDa25pskgMt9QZPxDeLJ0sg=; b=MUD5FCo3bfXv8w32Xo0e5447D2dyPAYnk6udP7PU/p0zOF4CXaW/qvtJzsgxSPiSXq Qp9jVKznmnxZzN2GEq8D2bRCf36V1flF2N8BCcMwC6TbXeIda3WUPDb5f0Wmr1mwCtQL CPAuPaJHV5sYPS7i3fRAKFhxy349GO9DkAkJ+d5o3jsfWr14unQbgk2jZyVasoEgEZq3 enfP3F3QkhkjdZ+MKI7EnpY1deQvE7EOv543cc3FTDeQ7vDubXQkkRPRckc3SW6ta6Zj Qj0/dBlqrpJHtamIe20Zz5XFECblr0vonXzcnSAJSneNJa82gHCTRe4EN6jELjlyRXVA sLZg== Received: by 10.68.225.3 with SMTP id rg3mr39474558pbc.27.1348555988293; Mon, 24 Sep 2012 23:53:08 -0700 (PDT) Received: from [127.0.0.1] ([213.217.59.99]) by mx.google.com with ESMTPS id b9sm10018959pay.22.2012.09.24.23.53.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Sep 2012 23:53:07 -0700 (PDT) Message-ID: <506154DB.3050103@gmail.com> Date: Tue, 25 Sep 2012 10:23:15 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Rudy (bulk)" References: <5060884C.3050709@monkeybrains.net> In-Reply-To: <5060884C.3050709@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 06:53:09 -0000 On 9/24/2012 7:50 PM, Rudy (bulk) wrote: > > Sometimes when I try to ping a neighbor machine (plugged directly in with no switch involved), I get: > > ping: sendto: No buffer space available > ping: sendto: No buffer space available > > If I reset the interface 'ifconfig em1 down; ifconfig em1 up' the problem goes away. > > The pings are: > FreeBSD 8.3 em1 --> FreeBSD 9.0 em2 > and I am seeing the issue on the FreeBSD 8.3 machine. The box has 6GB of free ram and is a quagga router. > > What do I need to tune? > > Thanks! > > Rudy > > > > > # netstat -m > 10236/8454/18690 mbufs in use (current/cache/total) > 10234/5388/15622/262144 mbuf clusters in use (current/cache/total/max) > 10234/5382 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/327/327/12800 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/3070/3070/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 23027K/41827K/64854K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > # ifconfig em1 > em1: flags=8843 metric 0 mtu 1500 > options=4219b > ether 00:25:90:56:60:7f > inet 10.1.1.1 netmask 0xfffffffc broadcast 10.1.1.3 > media: Ethernet autoselect (1000baseT ) > status: active > > > > FreeBSD 8.3 > ### loader.conf: > net.link.ifqmaxlen=1024 > hw.em.rxd=1024 > hw.em.txd=1024 > > > ### sysctl.conf: > kern.timecounter.hardware=HPET > > net.route.netisr_maxqlen=2048 > net.inet.ip.intr_queue_maxlen=1024 > > kern.ipc.somaxconn=256 > kern.random.sys.harvest.interrupt=0 > kern.random.sys.harvest.ethernet=0 > > net.inet.raw.maxdgram=16384 > net.inet.raw.recvspace=16384 > > net.inet.icmp.icmplim=1000 > net.inet.ip.fastforwarding=1 > kern.ipc.nmbclusters=262144 > net.inet.icmp.drop_redirect=1 > > dev.em.0.rx_processing_limit=200 > dev.em.1.rx_processing_limit=200 > dev.em.2.rx_processing_limit=200 > dev.em.3.rx_processing_limit=200 > > net.link.ether.inet.max_age=300 > hw.intr_storm_threshold=9000 > > # Security > net.inet.ip.redirect=0 > net.inet.ip.sourceroute=0 > net.inet.ip.accept_sourceroute=0 > net.inet.icmp.maskrepl=0 > > > > > Not sure if it matters, but here are the tunings on the other box: > > FreeBSD 9.0 > ### loader.conf: > net.link.ifqmaxlen="512" > > ### sysctl.conf: > net.inet.ip.fastforwarding=1 > kern.ipc.nmbclusters=262144 > kern.timecounter.hardware=HPET > net.inet.ip.rtminexpire=2 > net.inet.ip.rtmaxcache=1024 > > > dev.igb.0.rx_processing_limit=480 > dev.igb.1.rx_processing_limit=480 > > net.inet.icmp.icmplim=1000 > kern.random.sys.harvest.interrupt=0 > kern.random.sys.harvest.ethernet=0 > > net.link.ether.inet.max_age=300 > > ##Sat Apr 21 00:06:48 PDT 2012 > net.inet.ip.redirect=0 > net.route.netisr_maxqlen=2048 > _______________________________________________ > 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" > The most likely cause is that the interface send queue has become full and stayed in that condition. What type of NIC is at the other end of link? can you post the output of: # sysctl dev.em.1 From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 07:38:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2899E106564A for ; Tue, 25 Sep 2012 07:38:25 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7B58FC12 for ; Tue, 25 Sep 2012 07:38:24 +0000 (UTC) Received: from invalid-dns.RFC1918.monkeybrains.net (199-116-74-151-v301.PUBLIC.monkeybrains.net [199.116.74.151]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8P7cNHt046830 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 00:38:24 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <50615F6F.1070105@monkeybrains.net> Date: Tue, 25 Sep 2012 00:38:23 -0700 From: "Rudy (bulk)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Hooman Fazaeli References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> In-Reply-To: <506154C7.3040209@sepehrs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 07:38:25 -0000 On 9/24/12 11:52 PM, Hooman Fazaeli wrote: > sysctl dev.em.1 From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012) # sysctl dev.em.1 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x0000 class=0x020000 dev.em.1.%parent: pci5 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.fc: 3 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 200 dev.em.1.eee_control: 0 dev.em.1.link_irq: 6379725883 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1477444168 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 188 dev.em.1.queue0.txd_tail: 188 dev.em.1.queue0.tx_irq: 760427663 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 300 dev.em.1.queue0.rxd_tail: 297 dev.em.1.queue0.rx_irq: 838300057 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 580251107926 dev.em.1.mac_stats.recv_no_buff: 895 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 809 dev.em.1.mac_stats.xon_txd: 684 dev.em.1.mac_stats.xoff_recvd: 580251112172 dev.em.1.mac_stats.xoff_txd: 580251108668 dev.em.1.mac_stats.total_pkts_recvd: 582154845658 dev.em.1.mac_stats.good_pkts_recvd: 1903732156 dev.em.1.mac_stats.bcast_pkts_recvd: 923 dev.em.1.mac_stats.mcast_pkts_recvd: 0 dev.em.1.mac_stats.rx_frames_64: 257128416 dev.em.1.mac_stats.rx_frames_65_127: 702676478 dev.em.1.mac_stats.rx_frames_128_255: 225331435 dev.em.1.mac_stats.rx_frames_256_511: 59888288 dev.em.1.mac_stats.rx_frames_512_1023: 47777176 dev.em.1.mac_stats.rx_frames_1024_1522: 610930363 dev.em.1.mac_stats.good_octets_recvd: 1057190106675 dev.em.1.mac_stats.good_octets_txd: 1502996801989 dev.em.1.mac_stats.total_pkts_txd: 582709483882 dev.em.1.mac_stats.good_pkts_txd: 2458374408 dev.em.1.mac_stats.bcast_pkts_txd: 73 dev.em.1.mac_stats.mcast_pkts_txd: 0 dev.em.1.mac_stats.tx_frames_64: 314613253 dev.em.1.mac_stats.tx_frames_65_127: 841961719 dev.em.1.mac_stats.tx_frames_128_255: 268669868 dev.em.1.mac_stats.tx_frames_256_511: 73341358 dev.em.1.mac_stats.tx_frames_512_1023: 62765737 dev.em.1.mac_stats.tx_frames_1024_1522: 897022473 dev.em.1.mac_stats.tso_txd: 1880 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 6331439142 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 74346455 And the the other end of the link (FreeBSD 9.0-STABLE Feb 1 2012) # sysctl dev.em.2 dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.2.%driver: em dev.em.2.%location: slot=0 function=0 dev.em.2.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.2.%parent: pci7 dev.em.2.nvm: -1 dev.em.2.debug: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 dev.em.2.flow_control: 3 dev.em.2.eee_control: 0 dev.em.2.link_irq: 6379294926 dev.em.2.mbuf_alloc_fail: 0 dev.em.2.cluster_alloc_fail: 0 dev.em.2.dropped: 0 dev.em.2.tx_dma_fail: 0 dev.em.2.rx_overruns: 0 dev.em.2.watchdog_timeouts: 0 dev.em.2.device_control: 1477444168 dev.em.2.rx_control: 67141634 dev.em.2.fc_high_water: 18432 dev.em.2.fc_low_water: 16932 dev.em.2.queue0.txd_head: 735 dev.em.2.queue0.txd_tail: 735 dev.em.2.queue0.tx_irq: 839960061 dev.em.2.queue0.no_desc_avail: 0 dev.em.2.queue0.rxd_head: 237 dev.em.2.queue0.rxd_tail: 236 dev.em.2.queue0.rx_irq: 762108556 dev.em.2.mac_stats.excess_coll: 0 dev.em.2.mac_stats.single_coll: 0 dev.em.2.mac_stats.multiple_coll: 0 dev.em.2.mac_stats.late_coll: 0 dev.em.2.mac_stats.collision_count: 0 dev.em.2.mac_stats.symbol_errors: 0 dev.em.2.mac_stats.sequence_errors: 0 dev.em.2.mac_stats.defer_count: 0 dev.em.2.mac_stats.missed_packets: 580252415422 dev.em.2.mac_stats.recv_no_buff: 3211 dev.em.2.mac_stats.recv_undersize: 0 dev.em.2.mac_stats.recv_fragmented: 0 dev.em.2.mac_stats.recv_oversize: 0 dev.em.2.mac_stats.recv_jabber: 0 dev.em.2.mac_stats.recv_errs: 0 dev.em.2.mac_stats.crc_errs: 0 dev.em.2.mac_stats.alignment_errs: 0 dev.em.2.mac_stats.coll_ext_errs: 0 dev.em.2.mac_stats.xon_recvd: 684 dev.em.2.mac_stats.xon_txd: 811 dev.em.2.mac_stats.xoff_recvd: 580252412652 dev.em.2.mac_stats.xoff_txd: 580252416163 dev.em.2.mac_stats.total_pkts_recvd: 582710830267 dev.em.2.mac_stats.good_pkts_recvd: 2458413107 dev.em.2.mac_stats.bcast_pkts_recvd: 162 dev.em.2.mac_stats.mcast_pkts_recvd: 0 dev.em.2.mac_stats.rx_frames_64: 314616449 dev.em.2.mac_stats.rx_frames_65_127: 841966916 dev.em.2.mac_stats.rx_frames_128_255: 268689241 dev.em.2.mac_stats.rx_frames_256_511: 73346849 dev.em.2.mac_stats.rx_frames_512_1023: 62768450 dev.em.2.mac_stats.rx_frames_1024_1522: 897025202 dev.em.2.mac_stats.good_octets_recvd: 1503009815756 dev.em.2.mac_stats.good_octets_txd: 1056695683673 dev.em.2.mac_stats.total_pkts_txd: 582155360950 dev.em.2.mac_stats.good_pkts_txd: 1902943976 dev.em.2.mac_stats.bcast_pkts_txd: 8862 dev.em.2.mac_stats.mcast_pkts_txd: 5 dev.em.2.mac_stats.tx_frames_64: 257064868 dev.em.2.mac_stats.tx_frames_65_127: 702386644 dev.em.2.mac_stats.tx_frames_128_255: 225240646 dev.em.2.mac_stats.tx_frames_256_511: 59862797 dev.em.2.mac_stats.tx_frames_512_1023: 47743269 dev.em.2.mac_stats.tx_frames_1024_1522: 610645752 dev.em.2.mac_stats.tso_txd: 12910 dev.em.2.mac_stats.tso_ctx_fail: 0 dev.em.2.interrupts.asserts: 6331624353 dev.em.2.interrupts.rx_pkt_timer: 1 dev.em.2.interrupts.rx_abs_timer: 0 dev.em.2.interrupts.tx_pkt_timer: 0 dev.em.2.interrupts.tx_abs_timer: 0 dev.em.2.interrupts.tx_queue_empty: 0 dev.em.2.interrupts.tx_queue_min_thresh: 0 dev.em.2.interrupts.rx_desc_min_thresh: 0 dev.em.2.interrupts.rx_overrun: 74250608 I should note that I had the two devices set to mtu of 9000 at first, I got the 'No buffer space available' error a week ago and set both to an mtu of 1500. Then the 'No buffer space available' came back until the link was reset with an 'ifconfig up/down'. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 08:20:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A053106566B for ; Tue, 25 Sep 2012 08:20:03 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC09D8FC08 for ; Tue, 25 Sep 2012 08:20:03 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so4822456pbb.13 for ; Tue, 25 Sep 2012 01:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=OJHGPHGys/ummV8hFd59LBf2uevBPeBdXeIWAui1ovo=; b=Yce20qFnLaRkjamnjjm8876nfbg1bRixnQeu4UWE8dW51Rha1V1AUKgeGXnarp8L4r irqBbAqFo5iPQIdLUxCuI3tsy3Bh2EJBVaJZ+5OazlQ2lvJfRwC6fONPY0DG/6Ma03lv 34Gxor8Yy+yy/SMj3PR63HjuaMHoV4tbZDkHluqofsQM1T0jWlvOb0gmIcABs3BWI52F jN5wmYm3Hfqu+cRLp4Vnp9L9IIEcrQyqL30J+iaZX3+sZkQkB/2jN9D4y2KTTTgtNqWB Yu1TZ7KTyDuGbKs/X/BMLCkfs1ZbTQ+7kMio+pEVIjZz64v+MDIuwzZ63BJNSWdOCNAe DvUA== Received: by 10.68.237.38 with SMTP id uz6mr44414249pbc.23.1348561202891; Tue, 25 Sep 2012 01:20:02 -0700 (PDT) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id oe5sm2215707pbb.8.2012.09.25.01.20.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 01:20:02 -0700 (PDT) References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> In-Reply-To: <50615F6F.1070105@monkeybrains.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <834A688D-CDFC-44A1-91BE-0A3E1CFE9207@gmail.com> X-Mailer: iPhone Mail (9B206) From: Garrett Cooper Date: Tue, 25 Sep 2012 01:20:00 -0700 To: "Rudy (bulk)" Cc: freebsd-net , Hooman Fazaeli Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 08:20:11 -0000 On Sep 25, 2012, at 12:38 AM, "Rudy (bulk)" wrote:= > On 9/24/12 11:52 PM, Hooman Fazaeli wrote: >> sysctl dev.em.1=20 >=20 > =46rom the side having the 'No buffer space available' (FreeBSD 8.3 Sep 1= 3 2012) >=20 > # sysctl dev.em.1 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 > dev.em.1.%driver: em > dev.em.1.%location: slot=3D0 function=3D0 > dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 subd= evice=3D0x0000 class=3D0x020000 > dev.em.1.%parent: pci5 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.fc: 3 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 200 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 6379725883 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1477444168 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 18432 > dev.em.1.fc_low_water: 16932 > dev.em.1.queue0.txd_head: 188 > dev.em.1.queue0.txd_tail: 188 > dev.em.1.queue0.tx_irq: 760427663 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 300 > dev.em.1.queue0.rxd_tail: 297 > dev.em.1.queue0.rx_irq: 838300057 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 580251107926 > dev.em.1.mac_stats.recv_no_buff: 895 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 809 > dev.em.1.mac_stats.xon_txd: 684 > dev.em.1.mac_stats.xoff_recvd: 580251112172 > dev.em.1.mac_stats.xoff_txd: 580251108668 > dev.em.1.mac_stats.total_pkts_recvd: 582154845658 > dev.em.1.mac_stats.good_pkts_recvd: 1903732156 > dev.em.1.mac_stats.bcast_pkts_recvd: 923 > dev.em.1.mac_stats.mcast_pkts_recvd: 0 > dev.em.1.mac_stats.rx_frames_64: 257128416 > dev.em.1.mac_stats.rx_frames_65_127: 702676478 > dev.em.1.mac_stats.rx_frames_128_255: 225331435 > dev.em.1.mac_stats.rx_frames_256_511: 59888288 > dev.em.1.mac_stats.rx_frames_512_1023: 47777176 > dev.em.1.mac_stats.rx_frames_1024_1522: 610930363 > dev.em.1.mac_stats.good_octets_recvd: 1057190106675 > dev.em.1.mac_stats.good_octets_txd: 1502996801989 > dev.em.1.mac_stats.total_pkts_txd: 582709483882 > dev.em.1.mac_stats.good_pkts_txd: 2458374408 > dev.em.1.mac_stats.bcast_pkts_txd: 73 > dev.em.1.mac_stats.mcast_pkts_txd: 0 > dev.em.1.mac_stats.tx_frames_64: 314613253 > dev.em.1.mac_stats.tx_frames_65_127: 841961719 > dev.em.1.mac_stats.tx_frames_128_255: 268669868 > dev.em.1.mac_stats.tx_frames_256_511: 73341358 > dev.em.1.mac_stats.tx_frames_512_1023: 62765737 > dev.em.1.mac_stats.tx_frames_1024_1522: 897022473 > dev.em.1.mac_stats.tso_txd: 1880 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 6331439142 > dev.em.1.interrupts.rx_pkt_timer: 0 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 74346455 >=20 >=20 > And the the other end of the link (FreeBSD 9.0-STABLE Feb 1 2012) >=20 > # sysctl dev.em.2 > dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.2.%driver: em > dev.em.2.%location: slot=3D0 function=3D0 > dev.em.2.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 subd= evice=3D0x10d3 class=3D0x020000 > dev.em.2.%parent: pci7 > dev.em.2.nvm: -1 > dev.em.2.debug: -1 > dev.em.2.rx_int_delay: 0 > dev.em.2.tx_int_delay: 66 > dev.em.2.rx_abs_int_delay: 66 > dev.em.2.tx_abs_int_delay: 66 > dev.em.2.rx_processing_limit: 100 > dev.em.2.flow_control: 3 > dev.em.2.eee_control: 0 > dev.em.2.link_irq: 6379294926 > dev.em.2.mbuf_alloc_fail: 0 > dev.em.2.cluster_alloc_fail: 0 > dev.em.2.dropped: 0 > dev.em.2.tx_dma_fail: 0 > dev.em.2.rx_overruns: 0 > dev.em.2.watchdog_timeouts: 0 > dev.em.2.device_control: 1477444168 > dev.em.2.rx_control: 67141634 > dev.em.2.fc_high_water: 18432 > dev.em.2.fc_low_water: 16932 > dev.em.2.queue0.txd_head: 735 > dev.em.2.queue0.txd_tail: 735 > dev.em.2.queue0.tx_irq: 839960061 > dev.em.2.queue0.no_desc_avail: 0 > dev.em.2.queue0.rxd_head: 237 > dev.em.2.queue0.rxd_tail: 236 > dev.em.2.queue0.rx_irq: 762108556 > dev.em.2.mac_stats.excess_coll: 0 > dev.em.2.mac_stats.single_coll: 0 > dev.em.2.mac_stats.multiple_coll: 0 > dev.em.2.mac_stats.late_coll: 0 > dev.em.2.mac_stats.collision_count: 0 > dev.em.2.mac_stats.symbol_errors: 0 > dev.em.2.mac_stats.sequence_errors: 0 > dev.em.2.mac_stats.defer_count: 0 > dev.em.2.mac_stats.missed_packets: 580252415422 > dev.em.2.mac_stats.recv_no_buff: 3211 > dev.em.2.mac_stats.recv_undersize: 0 > dev.em.2.mac_stats.recv_fragmented: 0 > dev.em.2.mac_stats.recv_oversize: 0 > dev.em.2.mac_stats.recv_jabber: 0 > dev.em.2.mac_stats.recv_errs: 0 > dev.em.2.mac_stats.crc_errs: 0 > dev.em.2.mac_stats.alignment_errs: 0 > dev.em.2.mac_stats.coll_ext_errs: 0 > dev.em.2.mac_stats.xon_recvd: 684 > dev.em.2.mac_stats.xon_txd: 811 > dev.em.2.mac_stats.xoff_recvd: 580252412652 > dev.em.2.mac_stats.xoff_txd: 580252416163 > dev.em.2.mac_stats.total_pkts_recvd: 582710830267 > dev.em.2.mac_stats.good_pkts_recvd: 2458413107 > dev.em.2.mac_stats.bcast_pkts_recvd: 162 > dev.em.2.mac_stats.mcast_pkts_recvd: 0 > dev.em.2.mac_stats.rx_frames_64: 314616449 > dev.em.2.mac_stats.rx_frames_65_127: 841966916 > dev.em.2.mac_stats.rx_frames_128_255: 268689241 > dev.em.2.mac_stats.rx_frames_256_511: 73346849 > dev.em.2.mac_stats.rx_frames_512_1023: 62768450 > dev.em.2.mac_stats.rx_frames_1024_1522: 897025202 > dev.em.2.mac_stats.good_octets_recvd: 1503009815756 > dev.em.2.mac_stats.good_octets_txd: 1056695683673 > dev.em.2.mac_stats.total_pkts_txd: 582155360950 > dev.em.2.mac_stats.good_pkts_txd: 1902943976 > dev.em.2.mac_stats.bcast_pkts_txd: 8862 > dev.em.2.mac_stats.mcast_pkts_txd: 5 > dev.em.2.mac_stats.tx_frames_64: 257064868 > dev.em.2.mac_stats.tx_frames_65_127: 702386644 > dev.em.2.mac_stats.tx_frames_128_255: 225240646 > dev.em.2.mac_stats.tx_frames_256_511: 59862797 > dev.em.2.mac_stats.tx_frames_512_1023: 47743269 > dev.em.2.mac_stats.tx_frames_1024_1522: 610645752 > dev.em.2.mac_stats.tso_txd: 12910 > dev.em.2.mac_stats.tso_ctx_fail: 0 > dev.em.2.interrupts.asserts: 6331624353 > dev.em.2.interrupts.rx_pkt_timer: 1 > dev.em.2.interrupts.rx_abs_timer: 0 > dev.em.2.interrupts.tx_pkt_timer: 0 > dev.em.2.interrupts.tx_abs_timer: 0 > dev.em.2.interrupts.tx_queue_empty: 0 > dev.em.2.interrupts.tx_queue_min_thresh: 0 > dev.em.2.interrupts.rx_desc_min_thresh: 0 > dev.em.2.interrupts.rx_overrun: 74250608 >=20 >=20 > I should note that I had the two devices set to mtu of 9000 at first, ... Good data point! I was using jumbo frames at the time (9k buffers). Differen= ce being that I raised my buffer sizes to ridiculous limits (250k iirc). Thanks! -Garrett= From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 08:28:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB2D106564A for ; Tue, 25 Sep 2012 08:28:16 +0000 (UTC) (envelope-from pagxir@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 592948FC14 for ; Tue, 25 Sep 2012 08:28:15 +0000 (UTC) Received: by wgi16 with SMTP id 16so5248633wgi.31 for ; Tue, 25 Sep 2012 01:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SqYlzoSctBeH/DUbHalrvYmvS/JH2CApiCnOgDPXWFg=; b=FR+kkdVRZOWAaxlc8GZxc4T7TnM/osxw3ZgAbN84IplxMLPbFlHgAjLC1zPeGrrsJc 5eFBidqetq7LlfRHCyt1QX9BggE/pqFaod1AYFm0pFp/tnPBnoejOkkePAxSkXoQFR6i 9ufuVQkfft0IkzEU638tDrb5tzvnMcicjX2YRZjtbmkDJnYhVBFXpaQOa3EshO6UOlId OxoaxCb/h3Fb8h34YpXD8CdV1SyDYdcxbBJeuenRNiu0ABfmRn49dKKP4aQqJiQqXy3l kZ1P9HBwycwIj355HbIcYWpYEuzGt1jDMu9wCOhd3JdAoi1DnEA1uWjq1K0bEsZ6AWMk F0xA== MIME-Version: 1.0 Received: by 10.180.109.199 with SMTP id hu7mr12057926wib.21.1348561250660; Tue, 25 Sep 2012 01:20:50 -0700 (PDT) Received: by 10.216.255.14 with HTTP; Tue, 25 Sep 2012 01:20:50 -0700 (PDT) Date: Tue, 25 Sep 2012 16:20:50 +0800 Message-ID: From: =?UTF-8?B?6KO05Zu95YW0?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: The FreeBSD-CURRENT TCP/IP Stack does not support D-SACK. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 08:28:16 -0000 I view the TCP stack code of FreeBSD-CURRENT recently. It seems that current TCP/IP stack does not support D-SACK. Does someone will add D-SACK support in the future. Windows 7 and linux have add D-SACK supported. The detail of D-SACK is described in RFC2883. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 08:36:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 449BE106566B for ; Tue, 25 Sep 2012 08:36:10 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12BB68FC0C for ; Tue, 25 Sep 2012 08:36:09 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so4853372pbb.13 for ; Tue, 25 Sep 2012 01:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TSLeiyGkIqiK+McCfv4tz/PZ3gIY7MOara9ZwWZvKnA=; b=JGRZw486KIfTY96RIEO4L/UR7iWpLuHdZmYRk7XRtGBWuVWokT7AbidJa0HAbxiVs8 NprRt5yM4cJCabiY5CSW1WLhOWwnfpWn0aW3HwDCkfsTpsqNfSgnTVJEkLGc44eKtVTf hNBGpBsrAnM942cA37f8S5Kb6B7gTIFkqrawyf6Fs+JNR3UepvEkVPcNG20p8HQg4WL9 4L6iFkEFsOefK4xr9ORvepzu+A4fm5iRvOPKqDm5tgi2z6sk6tHv11HU/whqkPs/Dp1d u1j2d3fDzB4E0bOZ8n4fMmF2RToYFWsG+Z2i/e2dnpauCXm8a8NOUdDuMmcgdzzB1PRt /c9Q== Received: by 10.66.77.193 with SMTP id u1mr38916143paw.52.1348562169792; Tue, 25 Sep 2012 01:36:09 -0700 (PDT) Received: from [127.0.0.1] ([213.217.59.99]) by mx.google.com with ESMTPS id s10sm10151205paz.11.2012.09.25.01.36.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 01:36:09 -0700 (PDT) Message-ID: <50616CF0.2000805@gmail.com> Date: Tue, 25 Sep 2012 12:06:00 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Rudy (bulk)" References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> In-Reply-To: <50615F6F.1070105@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 08:36:10 -0000 On 9/25/2012 11:08 AM, Rudy (bulk) wrote: > On 9/24/12 11:52 PM, Hooman Fazaeli wrote: >> sysctl dev.em.1 > > From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012) > > # sysctl dev.em.1 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x0000 class=0x020000 > dev.em.1.%parent: pci5 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.fc: 3 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 200 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 6379725883 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1477444168 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 18432 > dev.em.1.fc_low_water: 16932 > dev.em.1.queue0.txd_head: 188 > dev.em.1.queue0.txd_tail: 188 > dev.em.1.queue0.tx_irq: 760427663 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 300 > dev.em.1.queue0.rxd_tail: 297 > dev.em.1.queue0.rx_irq: 838300057 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 580251107926 > dev.em.1.mac_stats.recv_no_buff: 895 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 809 > dev.em.1.mac_stats.xon_txd: 684 > dev.em.1.mac_stats.xoff_recvd: 580251112172 > dev.em.1.mac_stats.xoff_txd: 580251108668 > dev.em.1.mac_stats.total_pkts_recvd: 582154845658 > dev.em.1.mac_stats.good_pkts_recvd: 1903732156 > dev.em.1.mac_stats.bcast_pkts_recvd: 923 > dev.em.1.mac_stats.mcast_pkts_recvd: 0 > dev.em.1.mac_stats.rx_frames_64: 257128416 > dev.em.1.mac_stats.rx_frames_65_127: 702676478 > dev.em.1.mac_stats.rx_frames_128_255: 225331435 > dev.em.1.mac_stats.rx_frames_256_511: 59888288 > dev.em.1.mac_stats.rx_frames_512_1023: 47777176 > dev.em.1.mac_stats.rx_frames_1024_1522: 610930363 > dev.em.1.mac_stats.good_octets_recvd: 1057190106675 > dev.em.1.mac_stats.good_octets_txd: 1502996801989 > dev.em.1.mac_stats.total_pkts_txd: 582709483882 > dev.em.1.mac_stats.good_pkts_txd: 2458374408 > dev.em.1.mac_stats.bcast_pkts_txd: 73 > dev.em.1.mac_stats.mcast_pkts_txd: 0 > dev.em.1.mac_stats.tx_frames_64: 314613253 > dev.em.1.mac_stats.tx_frames_65_127: 841961719 > dev.em.1.mac_stats.tx_frames_128_255: 268669868 > dev.em.1.mac_stats.tx_frames_256_511: 73341358 > dev.em.1.mac_stats.tx_frames_512_1023: 62765737 > dev.em.1.mac_stats.tx_frames_1024_1522: 897022473 > dev.em.1.mac_stats.tso_txd: 1880 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 6331439142 > dev.em.1.interrupts.rx_pkt_timer: 0 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 74346455 > > > And the the other end of the link (FreeBSD 9.0-STABLE Feb 1 2012) > > # sysctl dev.em.2 > dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.2.%driver: em > dev.em.2.%location: slot=0 function=0 > dev.em.2.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 > dev.em.2.%parent: pci7 > dev.em.2.nvm: -1 > dev.em.2.debug: -1 > dev.em.2.rx_int_delay: 0 > dev.em.2.tx_int_delay: 66 > dev.em.2.rx_abs_int_delay: 66 > dev.em.2.tx_abs_int_delay: 66 > dev.em.2.rx_processing_limit: 100 > dev.em.2.flow_control: 3 > dev.em.2.eee_control: 0 > dev.em.2.link_irq: 6379294926 > dev.em.2.mbuf_alloc_fail: 0 > dev.em.2.cluster_alloc_fail: 0 > dev.em.2.dropped: 0 > dev.em.2.tx_dma_fail: 0 > dev.em.2.rx_overruns: 0 > dev.em.2.watchdog_timeouts: 0 > dev.em.2.device_control: 1477444168 > dev.em.2.rx_control: 67141634 > dev.em.2.fc_high_water: 18432 > dev.em.2.fc_low_water: 16932 > dev.em.2.queue0.txd_head: 735 > dev.em.2.queue0.txd_tail: 735 > dev.em.2.queue0.tx_irq: 839960061 > dev.em.2.queue0.no_desc_avail: 0 > dev.em.2.queue0.rxd_head: 237 > dev.em.2.queue0.rxd_tail: 236 > dev.em.2.queue0.rx_irq: 762108556 > dev.em.2.mac_stats.excess_coll: 0 > dev.em.2.mac_stats.single_coll: 0 > dev.em.2.mac_stats.multiple_coll: 0 > dev.em.2.mac_stats.late_coll: 0 > dev.em.2.mac_stats.collision_count: 0 > dev.em.2.mac_stats.symbol_errors: 0 > dev.em.2.mac_stats.sequence_errors: 0 > dev.em.2.mac_stats.defer_count: 0 > dev.em.2.mac_stats.missed_packets: 580252415422 > dev.em.2.mac_stats.recv_no_buff: 3211 > dev.em.2.mac_stats.recv_undersize: 0 > dev.em.2.mac_stats.recv_fragmented: 0 > dev.em.2.mac_stats.recv_oversize: 0 > dev.em.2.mac_stats.recv_jabber: 0 > dev.em.2.mac_stats.recv_errs: 0 > dev.em.2.mac_stats.crc_errs: 0 > dev.em.2.mac_stats.alignment_errs: 0 > dev.em.2.mac_stats.coll_ext_errs: 0 > dev.em.2.mac_stats.xon_recvd: 684 > dev.em.2.mac_stats.xon_txd: 811 > dev.em.2.mac_stats.xoff_recvd: 580252412652 > dev.em.2.mac_stats.xoff_txd: 580252416163 > dev.em.2.mac_stats.total_pkts_recvd: 582710830267 > dev.em.2.mac_stats.good_pkts_recvd: 2458413107 > dev.em.2.mac_stats.bcast_pkts_recvd: 162 > dev.em.2.mac_stats.mcast_pkts_recvd: 0 > dev.em.2.mac_stats.rx_frames_64: 314616449 > dev.em.2.mac_stats.rx_frames_65_127: 841966916 > dev.em.2.mac_stats.rx_frames_128_255: 268689241 > dev.em.2.mac_stats.rx_frames_256_511: 73346849 > dev.em.2.mac_stats.rx_frames_512_1023: 62768450 > dev.em.2.mac_stats.rx_frames_1024_1522: 897025202 > dev.em.2.mac_stats.good_octets_recvd: 1503009815756 > dev.em.2.mac_stats.good_octets_txd: 1056695683673 > dev.em.2.mac_stats.total_pkts_txd: 582155360950 > dev.em.2.mac_stats.good_pkts_txd: 1902943976 > dev.em.2.mac_stats.bcast_pkts_txd: 8862 > dev.em.2.mac_stats.mcast_pkts_txd: 5 > dev.em.2.mac_stats.tx_frames_64: 257064868 > dev.em.2.mac_stats.tx_frames_65_127: 702386644 > dev.em.2.mac_stats.tx_frames_128_255: 225240646 > dev.em.2.mac_stats.tx_frames_256_511: 59862797 > dev.em.2.mac_stats.tx_frames_512_1023: 47743269 > dev.em.2.mac_stats.tx_frames_1024_1522: 610645752 > dev.em.2.mac_stats.tso_txd: 12910 > dev.em.2.mac_stats.tso_ctx_fail: 0 > dev.em.2.interrupts.asserts: 6331624353 > dev.em.2.interrupts.rx_pkt_timer: 1 > dev.em.2.interrupts.rx_abs_timer: 0 > dev.em.2.interrupts.tx_pkt_timer: 0 > dev.em.2.interrupts.tx_abs_timer: 0 > dev.em.2.interrupts.tx_queue_empty: 0 > dev.em.2.interrupts.tx_queue_min_thresh: 0 > dev.em.2.interrupts.rx_desc_min_thresh: 0 > dev.em.2.interrupts.rx_overrun: 74250608 > > > I should note that I had the two devices set to mtu of 9000 at first, I got the 'No buffer space available' error a week ago and set both to an mtu of 1500. Then the 'No buffer space available' > came back until the link was reset with an 'ifconfig up/down'. > > > Based on the strangely high value of dev.em.1.link_irq (which means too many link status changes: down -> up -> down -> ....), I guess the problem is the same as discussed in these threads: http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031648.html To confirm, you may run this test: 1. Start a ping flood: ping -f 2. Let it run for a few seconds. 3. Disconnect the cable. 4. After a while, you should see "no buffer space" error. 5. Stop ping flood. 6. Re-connect the cable and wait 10 seconds. 7. Start a normal ping. Error messages should show up again. To fix, upgrade to the latest e1000 driver from HEAD. The very high link_irq may be due to a loose connection. Replace the patch cord and see if it helps. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 08:37:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AD36106566C for ; Tue, 25 Sep 2012 08:37:57 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 050F78FC19 for ; Tue, 25 Sep 2012 08:37:56 +0000 (UTC) Received: by pbbrp8 with SMTP id rp8so4856875pbb.13 for ; Tue, 25 Sep 2012 01:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TSLeiyGkIqiK+McCfv4tz/PZ3gIY7MOara9ZwWZvKnA=; b=zoAapWd4OQzN4IZ/R1bgCaVrJdBRBr0Wj/u937eIuJ8554SWXIiAPMIuP3W88ltV6K tM/eRua8ndHiY3+EpEQaq7JNV1SS8dhgoefwXsRz4UY5OZWOyOkVsalTD/Hz9wiWBtEE x4b370+xl1ubLDqKlyQ5S3j9gbXSD0UwDs/X9aQRvnLeCyYoGV24vCS6AYqkKoFyvg82 ic+BNuYjzfz4cfBCEdRkF/zRURQZ/EQ5jKleRlGv8ACUxM6yJ6xlp4X1BdUOQ+y/m5k4 tPUCCWusorrLUtmqoWI92Ub2apr609TKogr0w4XOS9qmDqn4HECWcysIpDTSyJZ0fnh9 5lfw== Received: by 10.68.242.10 with SMTP id wm10mr43773587pbc.61.1348562276512; Tue, 25 Sep 2012 01:37:56 -0700 (PDT) Received: from [127.0.0.1] ([213.217.59.99]) by mx.google.com with ESMTPS id i2sm2459730pav.13.2012.09.25.01.37.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 01:37:56 -0700 (PDT) Message-ID: <50616D5C.705@gmail.com> Date: Tue, 25 Sep 2012 12:07:48 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Rudy (bulk)" References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> In-Reply-To: <50615F6F.1070105@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 08:37:57 -0000 On 9/25/2012 11:08 AM, Rudy (bulk) wrote: > On 9/24/12 11:52 PM, Hooman Fazaeli wrote: >> sysctl dev.em.1 > > From the side having the 'No buffer space available' (FreeBSD 8.3 Sep 13 2012) > > # sysctl dev.em.1 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x0000 class=0x020000 > dev.em.1.%parent: pci5 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > dev.em.1.fc: 3 > dev.em.1.rx_int_delay: 0 > dev.em.1.tx_int_delay: 66 > dev.em.1.rx_abs_int_delay: 66 > dev.em.1.tx_abs_int_delay: 66 > dev.em.1.rx_processing_limit: 200 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 6379725883 > dev.em.1.mbuf_alloc_fail: 0 > dev.em.1.cluster_alloc_fail: 0 > dev.em.1.dropped: 0 > dev.em.1.tx_dma_fail: 0 > dev.em.1.rx_overruns: 0 > dev.em.1.watchdog_timeouts: 0 > dev.em.1.device_control: 1477444168 > dev.em.1.rx_control: 67141634 > dev.em.1.fc_high_water: 18432 > dev.em.1.fc_low_water: 16932 > dev.em.1.queue0.txd_head: 188 > dev.em.1.queue0.txd_tail: 188 > dev.em.1.queue0.tx_irq: 760427663 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 300 > dev.em.1.queue0.rxd_tail: 297 > dev.em.1.queue0.rx_irq: 838300057 > dev.em.1.mac_stats.excess_coll: 0 > dev.em.1.mac_stats.single_coll: 0 > dev.em.1.mac_stats.multiple_coll: 0 > dev.em.1.mac_stats.late_coll: 0 > dev.em.1.mac_stats.collision_count: 0 > dev.em.1.mac_stats.symbol_errors: 0 > dev.em.1.mac_stats.sequence_errors: 0 > dev.em.1.mac_stats.defer_count: 0 > dev.em.1.mac_stats.missed_packets: 580251107926 > dev.em.1.mac_stats.recv_no_buff: 895 > dev.em.1.mac_stats.recv_undersize: 0 > dev.em.1.mac_stats.recv_fragmented: 0 > dev.em.1.mac_stats.recv_oversize: 0 > dev.em.1.mac_stats.recv_jabber: 0 > dev.em.1.mac_stats.recv_errs: 0 > dev.em.1.mac_stats.crc_errs: 0 > dev.em.1.mac_stats.alignment_errs: 0 > dev.em.1.mac_stats.coll_ext_errs: 0 > dev.em.1.mac_stats.xon_recvd: 809 > dev.em.1.mac_stats.xon_txd: 684 > dev.em.1.mac_stats.xoff_recvd: 580251112172 > dev.em.1.mac_stats.xoff_txd: 580251108668 > dev.em.1.mac_stats.total_pkts_recvd: 582154845658 > dev.em.1.mac_stats.good_pkts_recvd: 1903732156 > dev.em.1.mac_stats.bcast_pkts_recvd: 923 > dev.em.1.mac_stats.mcast_pkts_recvd: 0 > dev.em.1.mac_stats.rx_frames_64: 257128416 > dev.em.1.mac_stats.rx_frames_65_127: 702676478 > dev.em.1.mac_stats.rx_frames_128_255: 225331435 > dev.em.1.mac_stats.rx_frames_256_511: 59888288 > dev.em.1.mac_stats.rx_frames_512_1023: 47777176 > dev.em.1.mac_stats.rx_frames_1024_1522: 610930363 > dev.em.1.mac_stats.good_octets_recvd: 1057190106675 > dev.em.1.mac_stats.good_octets_txd: 1502996801989 > dev.em.1.mac_stats.total_pkts_txd: 582709483882 > dev.em.1.mac_stats.good_pkts_txd: 2458374408 > dev.em.1.mac_stats.bcast_pkts_txd: 73 > dev.em.1.mac_stats.mcast_pkts_txd: 0 > dev.em.1.mac_stats.tx_frames_64: 314613253 > dev.em.1.mac_stats.tx_frames_65_127: 841961719 > dev.em.1.mac_stats.tx_frames_128_255: 268669868 > dev.em.1.mac_stats.tx_frames_256_511: 73341358 > dev.em.1.mac_stats.tx_frames_512_1023: 62765737 > dev.em.1.mac_stats.tx_frames_1024_1522: 897022473 > dev.em.1.mac_stats.tso_txd: 1880 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 6331439142 > dev.em.1.interrupts.rx_pkt_timer: 0 > dev.em.1.interrupts.rx_abs_timer: 0 > dev.em.1.interrupts.tx_pkt_timer: 0 > dev.em.1.interrupts.tx_abs_timer: 0 > dev.em.1.interrupts.tx_queue_empty: 0 > dev.em.1.interrupts.tx_queue_min_thresh: 0 > dev.em.1.interrupts.rx_desc_min_thresh: 0 > dev.em.1.interrupts.rx_overrun: 74346455 > > > And the the other end of the link (FreeBSD 9.0-STABLE Feb 1 2012) > > # sysctl dev.em.2 > dev.em.2.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.2.%driver: em > dev.em.2.%location: slot=0 function=0 > dev.em.2.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 > dev.em.2.%parent: pci7 > dev.em.2.nvm: -1 > dev.em.2.debug: -1 > dev.em.2.rx_int_delay: 0 > dev.em.2.tx_int_delay: 66 > dev.em.2.rx_abs_int_delay: 66 > dev.em.2.tx_abs_int_delay: 66 > dev.em.2.rx_processing_limit: 100 > dev.em.2.flow_control: 3 > dev.em.2.eee_control: 0 > dev.em.2.link_irq: 6379294926 > dev.em.2.mbuf_alloc_fail: 0 > dev.em.2.cluster_alloc_fail: 0 > dev.em.2.dropped: 0 > dev.em.2.tx_dma_fail: 0 > dev.em.2.rx_overruns: 0 > dev.em.2.watchdog_timeouts: 0 > dev.em.2.device_control: 1477444168 > dev.em.2.rx_control: 67141634 > dev.em.2.fc_high_water: 18432 > dev.em.2.fc_low_water: 16932 > dev.em.2.queue0.txd_head: 735 > dev.em.2.queue0.txd_tail: 735 > dev.em.2.queue0.tx_irq: 839960061 > dev.em.2.queue0.no_desc_avail: 0 > dev.em.2.queue0.rxd_head: 237 > dev.em.2.queue0.rxd_tail: 236 > dev.em.2.queue0.rx_irq: 762108556 > dev.em.2.mac_stats.excess_coll: 0 > dev.em.2.mac_stats.single_coll: 0 > dev.em.2.mac_stats.multiple_coll: 0 > dev.em.2.mac_stats.late_coll: 0 > dev.em.2.mac_stats.collision_count: 0 > dev.em.2.mac_stats.symbol_errors: 0 > dev.em.2.mac_stats.sequence_errors: 0 > dev.em.2.mac_stats.defer_count: 0 > dev.em.2.mac_stats.missed_packets: 580252415422 > dev.em.2.mac_stats.recv_no_buff: 3211 > dev.em.2.mac_stats.recv_undersize: 0 > dev.em.2.mac_stats.recv_fragmented: 0 > dev.em.2.mac_stats.recv_oversize: 0 > dev.em.2.mac_stats.recv_jabber: 0 > dev.em.2.mac_stats.recv_errs: 0 > dev.em.2.mac_stats.crc_errs: 0 > dev.em.2.mac_stats.alignment_errs: 0 > dev.em.2.mac_stats.coll_ext_errs: 0 > dev.em.2.mac_stats.xon_recvd: 684 > dev.em.2.mac_stats.xon_txd: 811 > dev.em.2.mac_stats.xoff_recvd: 580252412652 > dev.em.2.mac_stats.xoff_txd: 580252416163 > dev.em.2.mac_stats.total_pkts_recvd: 582710830267 > dev.em.2.mac_stats.good_pkts_recvd: 2458413107 > dev.em.2.mac_stats.bcast_pkts_recvd: 162 > dev.em.2.mac_stats.mcast_pkts_recvd: 0 > dev.em.2.mac_stats.rx_frames_64: 314616449 > dev.em.2.mac_stats.rx_frames_65_127: 841966916 > dev.em.2.mac_stats.rx_frames_128_255: 268689241 > dev.em.2.mac_stats.rx_frames_256_511: 73346849 > dev.em.2.mac_stats.rx_frames_512_1023: 62768450 > dev.em.2.mac_stats.rx_frames_1024_1522: 897025202 > dev.em.2.mac_stats.good_octets_recvd: 1503009815756 > dev.em.2.mac_stats.good_octets_txd: 1056695683673 > dev.em.2.mac_stats.total_pkts_txd: 582155360950 > dev.em.2.mac_stats.good_pkts_txd: 1902943976 > dev.em.2.mac_stats.bcast_pkts_txd: 8862 > dev.em.2.mac_stats.mcast_pkts_txd: 5 > dev.em.2.mac_stats.tx_frames_64: 257064868 > dev.em.2.mac_stats.tx_frames_65_127: 702386644 > dev.em.2.mac_stats.tx_frames_128_255: 225240646 > dev.em.2.mac_stats.tx_frames_256_511: 59862797 > dev.em.2.mac_stats.tx_frames_512_1023: 47743269 > dev.em.2.mac_stats.tx_frames_1024_1522: 610645752 > dev.em.2.mac_stats.tso_txd: 12910 > dev.em.2.mac_stats.tso_ctx_fail: 0 > dev.em.2.interrupts.asserts: 6331624353 > dev.em.2.interrupts.rx_pkt_timer: 1 > dev.em.2.interrupts.rx_abs_timer: 0 > dev.em.2.interrupts.tx_pkt_timer: 0 > dev.em.2.interrupts.tx_abs_timer: 0 > dev.em.2.interrupts.tx_queue_empty: 0 > dev.em.2.interrupts.tx_queue_min_thresh: 0 > dev.em.2.interrupts.rx_desc_min_thresh: 0 > dev.em.2.interrupts.rx_overrun: 74250608 > > > I should note that I had the two devices set to mtu of 9000 at first, I got the 'No buffer space available' error a week ago and set both to an mtu of 1500. Then the 'No buffer space available' > came back until the link was reset with an 'ifconfig up/down'. > > > Based on the strangely high value of dev.em.1.link_irq (which means too many link status changes: down -> up -> down -> ....), I guess the problem is the same as discussed in these threads: http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031648.html To confirm, you may run this test: 1. Start a ping flood: ping -f 2. Let it run for a few seconds. 3. Disconnect the cable. 4. After a while, you should see "no buffer space" error. 5. Stop ping flood. 6. Re-connect the cable and wait 10 seconds. 7. Start a normal ping. Error messages should show up again. To fix, upgrade to the latest e1000 driver from HEAD. The very high link_irq may be due to a loose connection. Replace the patch cord and see if it helps. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 20:07:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 257CF106564A for ; Tue, 25 Sep 2012 20:07:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id CFCF18FC15 for ; Tue, 25 Sep 2012 20:07:22 +0000 (UTC) Received: by qafi29 with SMTP id i29so3952643qaf.13 for ; Tue, 25 Sep 2012 13:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f+t0sShP6epQamAwT8MT/38yYk9JKK9Ty25Ia4LdtvA=; b=OuFxt3GwB+UvtvxON4HYY81H3UXF42jGFDDDaWUtAiPZuOKDhICiaLdicCGCPtvWof r3witgASN6kmTEUpZVG+3KRYyJ9Ge1Sb+4ccgeFydeOiDju8ogaBwtXwkiQAsrurKHp4 BVAv/r5QyUgJdKfFdxpfQhVWCwo7aIKxYnR/z3UqrjRlpVAYAS6BC6dQHrsqcyi8tG6x KQZBj3pUDCkC2lV1Ee1AWyBBMUR2gYKqPX/rnxzHmn3MqGCweU3mijlyKwZFtDfGVj/L HnVzUgcGrXIzv/Xwl3zAKDlJ3TLlNgY/EHBktBTvYwu/L4dtf2WB1PE9dq+z1FEvzgr+ M5cg== MIME-Version: 1.0 Received: by 10.229.136.17 with SMTP id p17mr9082604qct.139.1348603641882; Tue, 25 Sep 2012 13:07:21 -0700 (PDT) Received: by 10.49.50.103 with HTTP; Tue, 25 Sep 2012 13:07:21 -0700 (PDT) Date: Tue, 25 Sep 2012 16:07:21 -0400 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: netgraph: item->depth not set properly for some queued items X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 20:07:23 -0000 When ng_snd_item tries to send an item, has to acquire a "lock" on the node that it's sending to (I put lock in quotes because this isn't a standard FreeBSD synchronization primitive like a rw_lock or anything; netgraph has rolled its own synchronization primitive using atomic ops). Netgraph's node locks are not blocking locks (presumably to prevent deadlocks from cyclic graphs), so if ng_acquire_read/ng_acquire_write fails to get a lock of the proper type, it queues the item for processing from one of the ngthreads. When it hits this code path, item->depth is not updated. This means that after the message has been delivered by ngthread calling ng_apply_item, the following code does not send the return value of the rcvmsg/rcvdata method to the apply callback (note that depth must be 1 for it to pass the error through): /* Apply callback. */ if (apply != NULL) { if (depth == 1 && error != 0) apply->error = error; if (refcount_release(&apply->refs)) (*apply->apply)(apply->context, apply->error); } In the case that I saw, ngctl sent a message to a node and the item got enqueued. The node's rcvmsg method returned an error, but the error didn't propagate back to ngctl because the depth wasn't set right. The following patch resolves this particular issue for me but I don't entirely buy that it's the correct fix. I don't really understand why the depth should be forced to 1 when the item is enqueued, but it does match what's already done in another code path in ng_snd_item where an item is queued: Index: ng_base.c =================================================================== --- ng_base.c (revision 240923) +++ ng_base.c (working copy) @@ -2008,6 +2008,7 @@ NGI_SET_WRITER(item); else NGI_SET_READER(item); + item->depth = 1; NG_QUEUE_LOCK(ngq); /* Set OP_PENDING flag and enqueue the item. */ @@ -2286,7 +2287,6 @@ } if (queue) { - item->depth = 1; /* Put it on the queue for that node*/ ng_queue_rw(node, item, rw); return ((flags & NG_PROGRESS) ? EINPROGRESS : 0); If any netgraph experts have thoughts on this please chime in as I'm really not that confident in my understanding of the subtleties in netgraph. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 20:19:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69DAF106564A; Tue, 25 Sep 2012 20:19:03 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id B28A18FC0A; Tue, 25 Sep 2012 20:19:02 +0000 (UTC) Received: by eaac10 with SMTP id c10so1175336eaa.13 for ; Tue, 25 Sep 2012 13:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rzFmSPgrXFIQT6Fm1V4hfApbPbCWAtRGpnSXNQ34c68=; b=pRYVdd0OdpphLWlyLscwY89moTwBjYbZOUKlzRiZzjcXF0VtCUs3mWWap0DmS1kg+u ZQfwT2r6R9u16K3YCWzb5OTkzUIN8uGGcIeSrJe6US7oZDoqiPjEKSTWwdrFEhUu/BQZ AkVjko11id95S9fqzVdDCSabbiWrD7UxgtTEkrHiQGlUMVnvO/DgvoCepuBCWuKFL+1k tCTuHFpr1T2AaHo+A8L4/rdzXHvefq3er2fTSqdL/YsjyemuF5GGpP28YK2zi5GnfKyY H19Hf++fxu838mXwDz9m6eCWozYXX4jRH93U0EiRPwshgbuhAboE5vJYC4f/3yEtJ4bs kSxw== MIME-Version: 1.0 Received: by 10.14.178.72 with SMTP id e48mr22522496eem.1.1348604341455; Tue, 25 Sep 2012 13:19:01 -0700 (PDT) Received: by 10.14.219.134 with HTTP; Tue, 25 Sep 2012 13:19:01 -0700 (PDT) In-Reply-To: <201208170941.54482.jhb@freebsd.org> References: <201208161736.47250.jhb@freebsd.org> <201208170941.54482.jhb@freebsd.org> Date: Tue, 25 Sep 2012 13:19:01 -0700 Message-ID: From: Vijay Singh To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 20:19:03 -0000 > Vijay, can you test this to see if it helps with your test case? > >> Jack John, apologies for the delay. I have some data to share now. With your patch, the transmit side lock contention is all gone. However I still see receive side contention. I have MSI/X enabled, with one hw queue per-port. debug.lock.prof.stats: lock held_at contested_from instances e1b:rx(0) ( sys/dev/ixgbe/ixgbe.c:4314) ( sys/dev/ixgbe/ixgbe.c:4249) 6814 e2b:rx(0) ( sys/dev/ixgbe/ixgbe.c:4314) ( sys/dev/ixgbe/ixgbe.c:4249) 6962 These are from: 4297 static bool 4298 ixgbe_rxeof(struct ix_queue *que, int count) 4299 { ..... 4314 IXGBE_RX_LOCK(rxr); and 4220 static __inline void 4221 ixgbe_rx_input(struct rx_ring *rxr, struct ifnet *ifp, struct mbuf *m, u32 ptype) 4222 { .... 4247 IXGBE_RX_UNLOCK(rxr); 4248 (*ifp->if_input)(ifp, m); 4249 IXGBE_RX_LOCK(rxr); So it seems like the interrupt handler is still contending with a taskqueue handler on the receive side. -vijay PS: The interface names are custom. From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 20:22:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D76231065674 for ; Tue, 25 Sep 2012 20:22:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B2CBF8FC0A for ; Tue, 25 Sep 2012 20:22:48 +0000 (UTC) Received: from JRE-MBP-2.local (c-98-210-232-37.hsd1.ca.comcast.net [98.210.232.37]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q8PKMfeL032481 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 13:22:42 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5062128C.9020507@freebsd.org> Date: Tue, 25 Sep 2012 13:22:36 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ryan Stone References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: netgraph: item->depth not set properly for some queued items X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 20:22:49 -0000 On 9/25/12 1:07 PM, Ryan Stone wrote: > When ng_snd_item tries to send an item, has to acquire a "lock" on the > node that it's sending to (I put lock in quotes because this isn't a > standard FreeBSD synchronization primitive like a rw_lock or anything; > netgraph has rolled its own synchronization primitive using atomic > ops). Netgraph's node locks are not blocking locks (presumably to > prevent deadlocks from cyclic graphs), so if > ng_acquire_read/ng_acquire_write fails to get a lock of the proper > type, it queues the item for processing from one of the ngthreads. > > When it hits this code path, item->depth is not updated. This means > that after the message has been delivered by ngthread calling > ng_apply_item, the following code does not send the return value of > the rcvmsg/rcvdata method to the apply callback (note that depth must > be 1 for it to pass the error through): > > /* Apply callback. */ > if (apply != NULL) { > if (depth == 1 && error != 0) > apply->error = error; > if (refcount_release(&apply->refs)) > (*apply->apply)(apply->context, apply->error); > } > > In the case that I saw, ngctl sent a message to a node and the item > got enqueued. The node's rcvmsg method returned an error, but the > error didn't propagate back to ngctl because the depth wasn't set > right. The following patch resolves this particular issue for me but > I don't entirely buy that it's the correct fix. I don't really > understand why the depth should be forced to 1 when the item is > enqueued, but it does match what's already done in another code path > in ng_snd_item where an item is queued: I believe (across much time) that the depth is a 'nested call depth' and is designed to stop recursive packet paths within netgraph from using up infinite stack.. imagine if you will a packet that routes from node a to node b to node c and then back to node a..... when you queue the packet you are in effect resetting the depth as you have returned from all calling frames and the new handler of hte packet is starting with a fresh stack. It's been a while since I was doing any netgraph work so I may be out of date with some details. I will try remember to read the code tonight to refresh my memory as to what is going on. As I say, several people have rewritten bits of this since I was in it. > > Index: ng_base.c > =================================================================== > --- ng_base.c (revision 240923) > +++ ng_base.c (working copy) > @@ -2008,6 +2008,7 @@ > NGI_SET_WRITER(item); > else > NGI_SET_READER(item); > + item->depth = 1; > > NG_QUEUE_LOCK(ngq); > /* Set OP_PENDING flag and enqueue the item. */ > @@ -2286,7 +2287,6 @@ > } > > if (queue) { > - item->depth = 1; > /* Put it on the queue for that node*/ > ng_queue_rw(node, item, rw); > return ((flags & NG_PROGRESS) ? EINPROGRESS : 0); > > > If any netgraph experts have thoughts on this please chime in as I'm > really not that confident in my understanding of the subtleties in > netgraph. > _______________________________________________ > 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 Sep 25 20:40:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F32110656B8; Tue, 25 Sep 2012 20:40:59 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 069358FC17; Tue, 25 Sep 2012 20:40:58 +0000 (UTC) Received: by qcsl39 with SMTP id l39so1915916qcs.13 for ; Tue, 25 Sep 2012 13:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bSP4+oPdI1Mz7gQO5mTlrY8RiS51xoi11z48b+zFnyw=; b=ZCoILS9ZLHn6pF6jXdqMhhJuhmvI6DgiyokTdduXa3UZKZQh2566NRqgBogxY3AqJI OP2c+KPbSKNw+j7JF1vZN9vILuI2rZBMya+OJBprKzzXw63cxdjjbiA1+tbSt5fPRDjk xXsxpYy1BSQYRCBlrZ5TQt+1Ru8TQCdIq0Y9Oac6r3rpQ0CDkRMGJE+Pj4cMc7gZ3+yu z/K/UszZxVKAT6cHrOx7D4HZwsCVk8IRBq+yccgu5ddHaTU+5owD3tlIh1ALqbT6uKYA um3HeCp2mpCfs/nj7X01AmcK+U+KeXLCqEyGRqdGTUXFz1iT3MvvpaIjNIOecVzLt23s iwEw== MIME-Version: 1.0 Received: by 10.224.58.134 with SMTP id g6mr31612093qah.40.1348605658193; Tue, 25 Sep 2012 13:40:58 -0700 (PDT) Received: by 10.49.108.193 with HTTP; Tue, 25 Sep 2012 13:40:58 -0700 (PDT) In-Reply-To: References: <201208161736.47250.jhb@freebsd.org> <201208170941.54482.jhb@freebsd.org> Date: Tue, 25 Sep 2012 13:40:58 -0700 Message-ID: From: Jack Vogel To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 20:40:59 -0000 Ah yes, at one time I was keeping the RX side lock when calling the stack, but then as I recall that had problems, so the code now releases and reaquires as you can see. It results in some contention but I'm not sure that's avoidable. I've seen some LRO related panics on the 1G driver that may be related to this lock release, or that's one theory I have.. Thanks for the testing Vijay! Jack On Tue, Sep 25, 2012 at 1:19 PM, Vijay Singh wrote: > > Vijay, can you test this to see if it helps with your test case? > > > >> Jack > > John, apologies for the delay. I have some data to share now. > > With your patch, the transmit side lock contention is all gone. > However I still see receive side contention. I have MSI/X enabled, > with one hw queue per-port. > > debug.lock.prof.stats: > lock held_at > contested_from instances > e1b:rx(0) ( sys/dev/ixgbe/ixgbe.c:4314) ( > sys/dev/ixgbe/ixgbe.c:4249) 6814 > e2b:rx(0) ( sys/dev/ixgbe/ixgbe.c:4314) ( > sys/dev/ixgbe/ixgbe.c:4249) 6962 > > These are from: > > 4297 static bool > 4298 ixgbe_rxeof(struct ix_queue *que, int count) > 4299 { > ..... > 4314 IXGBE_RX_LOCK(rxr); > > and > > 4220 static __inline void > 4221 ixgbe_rx_input(struct rx_ring *rxr, struct ifnet *ifp, struct > mbuf *m, u32 ptype) > 4222 { > .... > 4247 IXGBE_RX_UNLOCK(rxr); > 4248 (*ifp->if_input)(ifp, m); > 4249 IXGBE_RX_LOCK(rxr); > > So it seems like the interrupt handler is still contending with a > taskqueue handler on the receive side. > > -vijay > > PS: The interface names are custom. > From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 20:48:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02B17106564A; Tue, 25 Sep 2012 20:48:45 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEA08FC12; Tue, 25 Sep 2012 20:48:43 +0000 (UTC) Received: by eaac10 with SMTP id c10so1184888eaa.13 for ; Tue, 25 Sep 2012 13:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rYVQPbGmTEr8QdpFhbaMy/Qyt1bQbZ0iS1O3TjkBISY=; b=UfZhf8jTMW/PVX5hyLixw5KT9R6M6fXETbkEccUNQKD7LYUxxFGt7rTjpBbU0i+YvS oNFEcWiEMEhokqLMNkGOiXVtJFvYYPfvyXXHSF+DO7FKb1aUV7UFfv+Lc0T0kKiFli8w Eu1VHEy9hA5RK4wFntIM3Lbz5xM+xJ5v//gwGTnrR3RHzi/SKJ9Fg84tEqanFSXZcWlY b61slgvxOxk3vkhnid9m9xBf7EF99oWCYRWHlgHMPb39zBr3RUmCm/eePRPzTeyDN3oE TnBmIIKUDkKx/h7Jc/ffwz+2Sei1I4LKJigeJxij9k2nM3aepYz0STqbAWaHMLzWDjqG ofCQ== MIME-Version: 1.0 Received: by 10.14.203.73 with SMTP id e49mr22443723eeo.27.1348606123329; Tue, 25 Sep 2012 13:48:43 -0700 (PDT) Received: by 10.14.219.134 with HTTP; Tue, 25 Sep 2012 13:48:43 -0700 (PDT) In-Reply-To: References: <201208161736.47250.jhb@freebsd.org> <201208170941.54482.jhb@freebsd.org> Date: Tue, 25 Sep 2012 13:48:43 -0700 Message-ID: From: Vijay Singh To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 20:48:45 -0000 On Tue, Sep 25, 2012 at 1:40 PM, Jack Vogel wrote: > Ah yes, at one time I was keeping the RX side lock when calling the stack, > but then as I recall that had problems, so the code now releases and > reaquires > as you can see. It results in some contention but I'm not sure that's > avoidable. Jack, I am wondering if this could be avoided if we can avoid to enqueue the task OR re-enable interrupts if the other one is already scheduled. Is this possible? From owner-freebsd-net@FreeBSD.ORG Tue Sep 25 23:39:43 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB0E106566C; Tue, 25 Sep 2012 23:39:43 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 384AA8FC08; Tue, 25 Sep 2012 23:39:42 +0000 (UTC) Received: from mr17.lnh.mail.rcn.net ([207.172.157.37]) by smtp02.lnh.mail.rcn.net with ESMTP; 25 Sep 2012 19:39:36 -0400 Received: from smtp04.lnh.mail.rcn.net (smtp04.lnh.mail.rcn.net [207.172.157.104]) by mr17.lnh.mail.rcn.net (MOS 4.3.4-GA) with ESMTP id BRY21900; Tue, 25 Sep 2012 19:39:35 -0400 X-Auth-ID: anat Received: from 209-6-63-29.c3-0.sbo-ubr1.sbo.ma.cable.rcn.com (HELO utka.zajac) ([209.6.63.29]) by smtp04.lnh.mail.rcn.net with ESMTP; 25 Sep 2012 19:39:27 -0400 Message-ID: <506240A9.1010301@aldan.algebra.com> Date: Tue, 25 Sep 2012 19:39:21 -0400 From: "Mikhail T." User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120808 Thunderbird/14.0 MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rpaulo@FreeBSD.org, kensmith@FreeBSD.org, ra@iop.kiev.ua Subject: Should not libpcap be compiled with INET6 unconditionally? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Sep 2012 23:39:43 -0000 On my systems, where I rebuild "world" by hand, I usually disable INET6 (WITHOUT_INET6 is documented in src.conf(5)) -- because it is still a waste on today's Internet with most ISPs. Unfortunately, this effectively disables tools like nmap, which use an expression like: Packet capture filter (device lo0): dst host 127.0.0.1 and (icmp *or icmp6* or ((tcp or udp or sctp) and (src host 127.0.0.1))) for many (most?) scans. The problem is, libpcap simply refuses to recognize the INET6-related tokens (like the icmp6 above), unless INET6 is defined at compile time: Error compiling our pcap filter: *icmp6 not supported* In addition to disabling nmap, this also prevents a non-INET6 machine to be used to examine a network dump obtained from an INET6-using host -- by tcpdump or any other libpcap-using tool. Unlike other utilities, which expect INET6 support from libc, libpcap can be compiled with -DINET6 by itself. I'd say, it should be built this way -- unconditionally: --- Makefile (revision 240899) +++ Makefile (working copy) @@ -90,9 +90,7 @@ CFLAGS+=-DHAVE_CONFIG_H -Dyylval=pcapyylval -I${.CURDIR} -I. CFLAGS+=-D_U_="__attribute__((unused))" CFLAGS+=-DHAVE_SNPRINTF -DHAVE_VSNPRINTF -.if ${MK_INET6_SUPPORT} != "no" CFLAGS+=-DINET6 -.endif .if ${MK_PF} != "no" CFLAGS+=-DHAVE_NET_PFVAR_H .endif Yours, -mi From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 00:34:59 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83F41065670; Wed, 26 Sep 2012 00:34:59 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BADB98FC0C; Wed, 26 Sep 2012 00:34:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8Q0YxdT086206; Wed, 26 Sep 2012 00:34:59 GMT (envelope-from emaste@freefall.freebsd.org) Received: (from emaste@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8Q0YxIn086201; Wed, 26 Sep 2012 00:34:59 GMT (envelope-from emaste) Date: Wed, 26 Sep 2012 00:34:59 GMT Message-Id: <201209260034.q8Q0YxIn086201@freefall.freebsd.org> To: emilec@clarotech.co.za, emaste@FreeBSD.org, freebsd-net@FreeBSD.org From: emaste@FreeBSD.org Cc: Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 00:35:00 -0000 Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf State-Changed-From-To: open->feedback State-Changed-By: emaste State-Changed-When: Wed Sep 26 00:33:10 UTC 2012 State-Changed-Why: Does this problem persist on current releases? I have if_tap loaded via loader.conf on stable/9 and HEAD machines and do not experience any problem (although I am using tap consumers other than OpenVPN). http://www.freebsd.org/cgi/query-pr.cgi?pr=117271 From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 00:38:40 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 913C0106566C; Wed, 26 Sep 2012 00:38:40 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 650A38FC12; Wed, 26 Sep 2012 00:38:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8Q0ceBh087983; Wed, 26 Sep 2012 00:38:40 GMT (envelope-from emaste@freefall.freebsd.org) Received: (from emaste@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8Q0cejQ087979; Wed, 26 Sep 2012 00:38:40 GMT (envelope-from emaste) Date: Wed, 26 Sep 2012 00:38:40 GMT Message-Id: <201209260038.q8Q0cejQ087979@freefall.freebsd.org> To: emilec@clarotech.co.za, emaste@FreeBSD.org, freebsd-net@FreeBSD.org From: emaste@FreeBSD.org Cc: Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 00:38:40 -0000 Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf State-Changed-From-To: feedback->open State-Changed-By: emaste State-Changed-When: Wed Sep 26 00:37:49 UTC 2012 State-Changed-Why: Ahh, it's OpenVPN that consumed 100% CPU, so non-OpenVPN TAP consumers are likely not relevant. http://www.freebsd.org/cgi/query-pr.cgi?pr=117271 From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 00:55:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F32B106566C for ; Wed, 26 Sep 2012 00:55:50 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 042878FC15 for ; Wed, 26 Sep 2012 00:55:49 +0000 (UTC) Received: by eaac10 with SMTP id c10so13400eaa.13 for ; Tue, 25 Sep 2012 17:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YcTuG/0OSaUkJoE2kAu45SCm3iCj/9hkTtFgLO1fVdI=; b=a056r1wX1XRLYeb6yhNVPoyQBboouBYwuvsiQNWOm7T0pqtiPjVDK2D7QJGCqloI2K ywcBpI++krB4dPezkAgSTE2gbP1th8zgAaWbBJP/Mkty6OAszxb/sj/bK4CPp+11PSxz IyZ9T+Gfr05fK5oOGw+7OsvVM+D4J+4PFAt4AAcoN8S8ZGmiDhz2+1qe/0jdijPKohxi RAbcC9Zr5Pvhn6M26bJ5PM3S/1kQEBYkkc4J5Nbv9eCCTcF++HzWY5pn2BupbxODZcc6 udOP4fgSEGr4spiIxu6gRaI7nRC0B3xTOPVi1VlAksB65t+6Xcc2d0Ezmj6Gx8NgaRl0 W88A== MIME-Version: 1.0 Received: by 10.14.180.68 with SMTP id i44mr23053879eem.20.1348620948900; Tue, 25 Sep 2012 17:55:48 -0700 (PDT) Received: by 10.14.219.134 with HTTP; Tue, 25 Sep 2012 17:55:48 -0700 (PDT) Date: Tue, 25 Sep 2012 17:55:48 -0700 Message-ID: From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: M_TRAILINGSPACE() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 00:55:50 -0000 Folks, does the following patch make sense: server@[/u/vijay/bsd/CODE/cur/sys/sys]# svn diff mbuf.h Index: mbuf.h =================================================================== --- mbuf.h (revision 240548) +++ mbuf.h (working copy) @@ -832,6 +832,8 @@ ((m)->m_flags & M_EXT ? \ (M_WRITABLE(m) ? (m)->m_ext.ext_buf + (m)->m_ext.ext_size \ - ((m)->m_data + (m)->m_len) : 0) : \ + (m)->m_flags & M_PKTHDR ? \ + ((m)->m_pktdat[MHLEN] - ((m)->m_data + (m)->m_len)) : \ &(m)->m_dat[MLEN] - ((m)->m_data + (m)->m_len)) /* From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 07:14:24 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97EAD106566C; Wed, 26 Sep 2012 07:14:24 +0000 (UTC) (envelope-from EmileC@clarotech.co.za) Received: from GWAlpha.clarotech.co.za (proxy.clarotech.co.za [196.211.62.90]) by mx1.freebsd.org (Postfix) with ESMTP id BED0A8FC14; Wed, 26 Sep 2012 07:14:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at clarotech.co.za Received: from Constellation.clarotech.co.za (constellation.clarotech.co.za [192.168.250.28]) by GWAlpha.clarotech.co.za (8.14.5/8.14.5) with ESMTP id q8Q6oD7C076382; Wed, 26 Sep 2012 08:50:13 +0200 (SAST) (envelope-from EmileC@clarotech.co.za) Received: from CONSTELLATION.clarotech.co.za ([fe80::ac44:373d:ff23:122d]) by Constellation.clarotech.co.za ([fe80::ac44:373d:ff23:122d%10]) with mapi id 14.01.0355.002; Wed, 26 Sep 2012 08:50:13 +0200 From: Emile Coetzee To: "emaste@FreeBSD.org" , "freebsd-net@FreeBSD.org" Thread-Topic: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf Thread-Index: AQHNm39F8bMyhw86YES7q65xzpJgJ5ecLkxg Date: Wed, 26 Sep 2012 06:50:12 +0000 Message-ID: References: <201209260038.q8Q0cejQ087979@freefall.freebsd.org> In-Reply-To: <201209260038.q8Q0cejQ087979@freefall.freebsd.org> Accept-Language: en-ZA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 07:14:24 -0000 I have not tested stable/9 yet, but stable/8 seems to be fine. Given that FreeBSD 6 is no longer supported you can probably close this bug= . -----Original Message----- From: emaste@FreeBSD.org [mailto:emaste@FreeBSD.org]=20 Sent: 26 September 2012 02:39 AM To: Emile Coetzee; emaste@FreeBSD.org; freebsd-net@FreeBSD.org Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when i= f_tap is in /boot/loader.conf Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boo= t/loader.conf State-Changed-From-To: feedback->open State-Changed-By: emaste State-Changed-When: Wed Sep 26 00:37:49 UTC 2012 State-Changed-Why:=20 Ahh, it's OpenVPN that consumed 100% CPU, so non-OpenVPN TAP consumers are = likely not relevant. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D117271 From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 10:03:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68C6E106566B for ; Wed, 26 Sep 2012 10:03:29 +0000 (UTC) (envelope-from ded1@MyBSD.org.my) Received: from SAURON.KNOWLEDGEGRID.NET.MY (sauron.knowledgegrid.net.my [192.228.137.13]) by mx1.freebsd.org (Postfix) with ESMTP id 282CC8FC12 for ; Wed, 26 Sep 2012 10:03:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by SAURON.KNOWLEDGEGRID.NET.MY (Postfix) with ESMTP id 1B42D1BD262 for ; Wed, 26 Sep 2012 18:03:28 +0800 (MYT) Date: Wed, 26 Sep 2012 18:03:28 +0800 (MYT) From: "ded1@MyBSD.org.my" X-X-Sender: ded1@sauron.knowledgegrid.net.my To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 10:03:29 -0000 Hi, i'm installing isc-dhcp42-server and run in the network for like 1000 node. i have like 1000 mac address (servers, PC's, printers, phones, etc) which i put in the text file. FYI, Any mac address (which is in the text file) who plug into the network will get the ip address based on the vlan configured on the switch. Any mac address who's NOT in the text file, will not getting any IP and they will not authorize to be in our network. Is this possible to do with isc-dhcp ? I try to search around these topic but not much help. Anyone have any tips / shed me some light ? --- ded1 MyBSD Malaysia Project http://www.MyBSD.org.my From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 11:09:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E24941065673 for ; Wed, 26 Sep 2012 11:09:13 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5371C8FC15 for ; Wed, 26 Sep 2012 11:09:12 +0000 (UTC) Received: (qmail 18277 invoked from network); 26 Sep 2012 12:45:27 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Sep 2012 12:45:27 -0000 Message-ID: <5062E0BC.1010603@networx.ch> Date: Wed, 26 Sep 2012 13:02:20 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Vijay Singh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: M_TRAILINGSPACE() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 11:09:14 -0000 On 26.09.2012 02:55, Vijay Singh wrote: > Folks, does the following patch make sense: > > server@[/u/vijay/bsd/CODE/cur/sys/sys]# svn diff mbuf.h > Index: mbuf.h > =================================================================== > --- mbuf.h (revision 240548) > +++ mbuf.h (working copy) > @@ -832,6 +832,8 @@ > ((m)->m_flags & M_EXT ? \ > (M_WRITABLE(m) ? (m)->m_ext.ext_buf + (m)->m_ext.ext_size \ > - ((m)->m_data + (m)->m_len) : 0) : \ > + (m)->m_flags & M_PKTHDR ? \ > + ((m)->m_pktdat[MHLEN] - ((m)->m_data + (m)->m_len)) : \ > &(m)->m_dat[MLEN] - ((m)->m_data + (m)->m_len)) Isn't this the same result in both cases? And isn't there a '&' missing? -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 12:53:20 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6E3A106564A; Wed, 26 Sep 2012 12:53:20 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9458FC08; Wed, 26 Sep 2012 12:53:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8QCrKYG075189; Wed, 26 Sep 2012 12:53:20 GMT (envelope-from emaste@freefall.freebsd.org) Received: (from emaste@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8QCrJvp075185; Wed, 26 Sep 2012 12:53:19 GMT (envelope-from emaste) Date: Wed, 26 Sep 2012 12:53:19 GMT Message-Id: <201209261253.q8QCrJvp075185@freefall.freebsd.org> To: emilec@clarotech.co.za, emaste@FreeBSD.org, freebsd-net@FreeBSD.org From: emaste@FreeBSD.org Cc: Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 12:53:20 -0000 Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf State-Changed-From-To: open->closed State-Changed-By: emaste State-Changed-When: Wed Sep 26 12:52:36 UTC 2012 State-Changed-Why: Submitter reports this works on stable/8. http://www.freebsd.org/cgi/query-pr.cgi?pr=117271 From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 13:46:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B82BE106566B for ; Wed, 26 Sep 2012 13:46:25 +0000 (UTC) (envelope-from rafaelhfaria@cenadigital.com.br) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 822188FC0C for ; Wed, 26 Sep 2012 13:46:25 +0000 (UTC) Received: by padbi1 with SMTP id bi1so501969pad.13 for ; Wed, 26 Sep 2012 06:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cenadigital.com.br; s=mail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f+NoTmFFDKl6c3gGstfv/IS2nV9Op6ZNOhmUrOWRQfU=; b=Y2GFvm+0xfZdQrTcdeRvJ514AR9yv7GoxoUi7wpi+zjFYq2PIMwDP+rmymgPzOPb04 tZSkXPAX15Q/hm0AnRQTwFPTZAYKRY6Th9o+VfVvLeaYoo1KGEVJjGgKJLgxKxt8AdB4 M7glDu2cHgAKxQtQMQFZ+6pWXCkRTU2+d25s4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=f+NoTmFFDKl6c3gGstfv/IS2nV9Op6ZNOhmUrOWRQfU=; b=CS/bcws0TEm1BuvW1MaVdxr7XpL1qRH6NHNshCpEYiMXwaMjlvCSArf8XHvqV4Z9e/ osCZEeB9r0XtzgJtJTDzkRhK4N0lrIASA/5SeM734h/dNcKGgQrke93kVfRrQ2CQzEJm bXQ3d2utOQ75zHBHMRqoVa2cMDZHGf8ILrq0ukSwc/gpNP6uyu1S8bjyvUQGViwEIZ71 bXqQM/q8r3Qgd+XSZflIjvyesNSh72X9XghDXSfLOD1hOL5gUij6/DycZD2dwDRHj4ix Dv29w2iCx8vdf90ZBa6o6LNRzyUkRglJUO5TjY86KIkMixGaavgRd4cZ2dmBuRCNzElA 2NNw== Received: by 10.68.197.9 with SMTP id iq9mr2770832pbc.17.1348667184846; Wed, 26 Sep 2012 06:46:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.12.99 with HTTP; Wed, 26 Sep 2012 06:45:44 -0700 (PDT) In-Reply-To: References: From: Rafael Henrique Faria Date: Wed, 26 Sep 2012 10:45:44 -0300 Message-ID: To: "ded1@MyBSD.org.my" X-Gm-Message-State: ALoCoQlCgxSBTOczLm0tXyq14+CPvJfojP0SyVf+7v4wt0a/2qkh9Gvw/ChaC8Z1IM8yHk4ot2qy Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 13:46:25 -0000 On Wed, Sep 26, 2012 at 7:03 AM, ded1@MyBSD.org.my wrote: > Hi, > > i'm installing isc-dhcp42-server and run in the network for like 1000 > node. i have like 1000 mac address (servers, PC's, printers, phones, etc) > which i put in the text file. > > FYI, > > Any mac address (which is in the text file) who plug into the network will > get the ip address based on the vlan configured on the switch. Any mac > address who's NOT in the text file, will not getting any IP and they will > not authorize to be in our network. > > Is this possible to do with isc-dhcp ? I try to search around these topic > but not much help. > > Anyone have any tips / shed me some light ? > > > --- > ded1 > MyBSD Malaysia Project > http://www.MyBSD.org.my > ______________________________**_________________ > 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 > " > Sorry, but I think that this kind of control you want will be provided only by the 802.1x. Anyone can put a static ip address from your network range and use your network without having its MAC Address into the dhcpd conf file. With a layer-3 switch 802.1x cappable you can even specify a vlan to the authenticated user, so if 2 users uses the same machine, they can get different IP Numbers and different vLan. All based on the user authentication before any network connection. -- Rafael Henrique da Silva Faria From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 13:53:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9839106567D for ; Wed, 26 Sep 2012 13:53:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 77ED78FC30 for ; Wed, 26 Sep 2012 13:53:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A7476B978; Wed, 26 Sep 2012 09:53:31 -0400 (EDT) From: John Baldwin To: Vijay Singh Date: Wed, 26 Sep 2012 09:53:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201208170941.54482.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209260953.27806.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 26 Sep 2012 09:53:31 -0400 (EDT) Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 13:53:32 -0000 On Tuesday, September 25, 2012 4:19:01 pm Vijay Singh wrote: > > Vijay, can you test this to see if it helps with your test case? > > > >> Jack > > John, apologies for the delay. I have some data to share now. > > With your patch, the transmit side lock contention is all gone. > However I still see receive side contention. I have MSI/X enabled, > with one hw queue per-port. Well, that's progress at least. Jack, can you ok this patch? It is just the changes to adjust the deferred tx handling and doesn't include any watchdog changes. The igb fix is just a comestic nit: Index: dev/e1000/if_igb.h =================================================================== --- dev/e1000/if_igb.h (revision 240960) +++ dev/e1000/if_igb.h (working copy) @@ -299,9 +299,9 @@ struct igb_tx_buffer *tx_buffers; #if __FreeBSD_version >= 800000 struct buf_ring *br; + struct task txq_task; #endif bus_dma_tag_t txtag; - struct task txq_task; u32 bytes; u32 packets; Index: dev/ixgbe/ixgbe.c =================================================================== --- dev/ixgbe/ixgbe.c (revision 240960) +++ dev/ixgbe/ixgbe.c (working copy) @@ -104,13 +104,15 @@ static int ixgbe_attach(device_t); static int ixgbe_detach(device_t); static int ixgbe_shutdown(device_t); -static void ixgbe_start(struct ifnet *); -static void ixgbe_start_locked(struct tx_ring *, struct ifnet *); #if __FreeBSD_version >= 800000 static int ixgbe_mq_start(struct ifnet *, struct mbuf *); static int ixgbe_mq_start_locked(struct ifnet *, struct tx_ring *, struct mbuf *); static void ixgbe_qflush(struct ifnet *); +static void ixgbe_deferred_mq_start(void *, int); +#else +static void ixgbe_start(struct ifnet *); +static void ixgbe_start_locked(struct tx_ring *, struct ifnet *); #endif static int ixgbe_ioctl(struct ifnet *, u_long, caddr_t); static void ixgbe_init(void *); @@ -631,6 +633,7 @@ { struct adapter *adapter = device_get_softc(dev); struct ix_queue *que = adapter->queues; + struct tx_ring *txr = adapter->tx_rings; u32 ctrl_ext; INIT_DEBUGOUT("ixgbe_detach: begin"); @@ -645,8 +648,11 @@ ixgbe_stop(adapter); IXGBE_CORE_UNLOCK(adapter); - for (int i = 0; i < adapter->num_queues; i++, que++) { + for (int i = 0; i < adapter->num_queues; i++, que++, txr++) { if (que->tq) { +#if __FreeBSD_version >= 800000 + taskqueue_drain(que->tq, &txr->txq_task); +#endif taskqueue_drain(que->tq, &que->que_task); taskqueue_free(que->tq); } @@ -708,6 +714,7 @@ } +#if __FreeBSD_version < 800000 /********************************************************************* * Transmit entry point * @@ -779,7 +786,7 @@ return; } -#if __FreeBSD_version >= 800000 +#else /* ** Multiqueue Transmit driver ** @@ -807,7 +814,7 @@ IXGBE_TX_UNLOCK(txr); } else { err = drbr_enqueue(ifp, txr->br, m); - taskqueue_enqueue(que->tq, &que->que_task); + taskqueue_enqueue(que->tq, &txr->txq_task); } return (err); @@ -873,6 +880,22 @@ } /* + * Called from a taskqueue to drain queued transmit packets. + */ +static void +ixgbe_deferred_mq_start(void *arg, int pending) +{ + struct tx_ring *txr = arg; + struct adapter *adapter = txr->adapter; + struct ifnet *ifp = adapter->ifp; + + IXGBE_TX_LOCK(txr); + if (!drbr_empty(ifp, txr->br)) + ixgbe_mq_start_locked(ifp, txr, NULL); + IXGBE_TX_UNLOCK(txr); +} + +/* ** Flush all ring buffers */ static void @@ -2230,6 +2258,9 @@ { device_t dev = adapter->dev; struct ix_queue *que = adapter->queues; +#if __FreeBSD_version >= 800000 + struct tx_ring *txr = adapter->tx_rings; +#endif int error, rid = 0; /* MSI RID at 1 */ @@ -2249,6 +2280,9 @@ * Try allocating a fast interrupt and the associated deferred * processing contexts. */ +#if __FreeBSD_version >= 800000 + TASK_INIT(&txr->txq_task, 0, ixgbe_deferred_mq_start, txr); +#endif TASK_INIT(&que->que_task, 0, ixgbe_handle_que, que); que->tq = taskqueue_create_fast("ixgbe_que", M_NOWAIT, taskqueue_thread_enqueue, &que->tq); @@ -2295,9 +2329,10 @@ { device_t dev = adapter->dev; struct ix_queue *que = adapter->queues; + struct tx_ring *txr = adapter->tx_rings; int error, rid, vector = 0; - for (int i = 0; i < adapter->num_queues; i++, vector++, que++) { + for (int i = 0; i < adapter->num_queues; i++, vector++, que++, txr++) { rid = vector + 1; que->res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); @@ -2327,6 +2362,9 @@ if (adapter->num_queues > 1) bus_bind_intr(dev, que->res, i); +#if __FreeBSD_version >= 800000 + TASK_INIT(&txr->txq_task, 0, ixgbe_deferred_mq_start, txr); +#endif TASK_INIT(&que->que_task, 0, ixgbe_handle_que, que); que->tq = taskqueue_create_fast("ixgbe_que", M_NOWAIT, taskqueue_thread_enqueue, &que->tq); @@ -2570,12 +2608,13 @@ ifp->if_softc = adapter; ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = ixgbe_ioctl; - ifp->if_start = ixgbe_start; #if __FreeBSD_version >= 800000 ifp->if_transmit = ixgbe_mq_start; ifp->if_qflush = ixgbe_qflush; +#else + ifp->if_start = ixgbe_start; + IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 2); #endif - ifp->if_snd.ifq_maxlen = adapter->num_tx_desc - 2; ether_ifattach(ifp, adapter->hw.mac.addr); Index: dev/ixgbe/ixgbe.h =================================================================== --- dev/ixgbe/ixgbe.h (revision 240960) +++ dev/ixgbe/ixgbe.h (working copy) @@ -314,6 +314,7 @@ char mtx_name[16]; #if __FreeBSD_version >= 800000 struct buf_ring *br; + struct task txq_task; #endif #ifdef IXGBE_FDIR u16 atr_sample; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 14:14:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C17F10657C2 for ; Wed, 26 Sep 2012 14:14:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4218FC0A for ; Wed, 26 Sep 2012 14:14:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 678EDB911; Wed, 26 Sep 2012 10:14:35 -0400 (EDT) From: John Baldwin To: Jack Vogel Date: Wed, 26 Sep 2012 09:55:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201209260955.14417.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 26 Sep 2012 10:14:35 -0400 (EDT) Cc: freebsd-net@freebsd.org, Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 14:14:36 -0000 On Tuesday, September 25, 2012 4:40:58 pm Jack Vogel wrote: > Ah yes, at one time I was keeping the RX side lock when calling the stack, > but then as I recall that had problems, so the code now releases and > reaquires > as you can see. It results in some contention but I'm not sure that's > avoidable. > > I've seen some LRO related panics on the 1G driver that may be related to > this lock release, or that's one theory I have.. > > Thanks for the testing Vijay! You only have to drop the RX lock around if_input() if you use the same lock for both TX and RX (as if_transmit() / if_start() can be invoked while locks in the network stack are held). If WITNESS complains, the fix is to only use the MTX_NETWORK_LOCK "lock type name" for your transmit ring locks, not for RX. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 14:15:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 228081065687 for ; Wed, 26 Sep 2012 14:15:16 +0000 (UTC) (envelope-from igloo@ua.fm) Received: from st14.mi6.kiev.ua (st14.mi6.kiev.ua [91.198.36.66]) by mx1.freebsd.org (Postfix) with ESMTP id CC60B8FC16 for ; Wed, 26 Sep 2012 14:15:15 +0000 (UTC) Received: from web09.mi6 ([10.0.0.8] helo=web09.mi6.kiev.ua) by st14.mi6.kiev.ua with esmtp (Exim 4.76) (envelope-from ) id 1TGrPY-0004co-C8 for freebsd-net@freebsd.org; Wed, 26 Sep 2012 16:12:20 +0300 Received: from web by web09.mi6.kiev.ua with local (Exim 4.76) (envelope-from ) id 1TGrPX-0006Ww-OR for freebsd-net@freebsd.org; Wed, 26 Sep 2012 16:12:19 +0300 To: freebsd-net@freebsd.org Date: Wed, 26 Sep 2012 16:12:19 +0300 From: Vladimir Vladimir MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1 X-Sender-IP: 195.160.233.181 X-Server: web09.mi6.kiev.ua X-Mailer: I.UA Mail System Message-Id: Subject: FreeBSD 9.0-RELEASE Realtek 8168/81111 Driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 14:15:16 -0000 Hi all, =0A=0AI've got an issue with new mother board ASUS P8Z77-M PRO. =0A= =0AMy FreeBSD 9.0-RELEASE can't set up Network interface for integrated NIC= Realtek 8168/81111.=0A=0AI have tried FreeBSD-8.2, and FreeBSD-9.0=0AI' do= wnloaded new distributions from freebsd.org and tried boot from them but r= esult the same. FreeBSD couldn't setup re0 interface.=0A=0Ain the dmesg out= put :=0A=0Are0: por= t 0xd000-0xd0ff mem 0xdc104000-0xdc104fff,0xdc100000-0xdc103fff irq 17 at d= evice 0.0 on pci2=0Are0: Using 1 MSI-X message=0Are0: turning off MSI enabl= e bit.=0Are0: Chip rev. 0x2c800000=0Are0: MAC rev. 0x00000000=0A=0Aso looks= like FreeBSD detected NIC, but ifconfig shows loop interface only=0A=0Alo0= : flags=3D8049 metric 0 mtu 16384=0A=09optio= ns=3D3=0A=09inet6 ::1 prefixlen 128 =0A=09inet6 fe80::1%lo0 = prefixlen 64 scopeid 0xa =0A=09inet 127.0.0.1 netmask 0xff000000 =0A=09nd6 = options=3D21=0A=0Aif i try command=0A=0Aifconfig= re0 create=0Aifconfig: SIOCIFCREATE2: Invalid argument=0A=0Aat the same ti= me Ubuntu works perfect on this mother board, so there aren't any hardware = issues=0A=0AIn the official ASUS documentation for motherboard ASUS P8Z77-M= PRO it's got NIC Realtek=C2=AE 8111F, 1 x Gigabit LAN Controller(s)=0Aht= tp://www.asus.ua/Motherboards/Intel_Socket_1155/P8Z77M_PRO/#specifications= =0A=0AMay be re(4) driver not updated for this mother board yet?.=0Ahttp://= www.freebsd.org/cgi/man.cgi?query=3Dre&apropos=3D0&sektion=3D4&manpath=3DFr= eeBSD+9.0-stable&arch=3Ddefault&format=3Dhtml=0A=0AIf anybody faced of such= issue., let me know.=0A=0AThanks Vlad.=0A=0A=0A -- =D1=80=D0=B5=D0=BA=D0=BB=D0=B0=D0=BC=D0=B0 -----------------------------= ------------------------------ =D0=9A=D1=80=D1=83=D0=BF=D0=BD=D0=B5=D0=B9=D1=88=D0=B8=D0=B9 =D0=B2 =D0=A3= =D0=BA=D1=80=D0=B0=D0=B8=D0=BD=D0=B5 =D1=85=D0=BE=D1=81=D1=82=D0=B8=D0=BD= =D0=B3 http://www.ukraine.com.ua/hosting/ From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 16:15:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B925106566B; Wed, 26 Sep 2012 16:15:58 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id DCCBB8FC16; Wed, 26 Sep 2012 16:15:57 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1094626vbm.13 for ; Wed, 26 Sep 2012 09:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=33KR9Xi1p+VEynXxTZ7NNFnkvtWNA/a3tnHKUgwO0nQ=; b=ZmidY2+/UETevNTRorFaiXdfHZvnl8+Uwaw/EnR7SeX6oGco4xYWJv/pichGUtm72i umgY9cP3IZ4BS3QD/e7H+B8rJONYyiEOFjVOYUn/xeZBx7K+OlXUE6KOCT8GsWV7+UKy MemLKRHwelbbXhBTVY4qnMRbr8s/SVdZLeMfRE1rZ2WKlC9ydL8wCzebTX4bkTsHVmKQ d9Z125LjhqCu3RT+AKofpcNKANUFESE484iAkwFUMdWaiyq/CJynbkpx/LFvqY72JRIe sHP7YaURa4vCwZG7Y9fbFuRsYToiMkEnEP+rfRCBh6kJld3pjpBuPKuNJc2G1f04NKYz sqSQ== MIME-Version: 1.0 Received: by 10.58.64.103 with SMTP id n7mr553244ves.35.1348676157061; Wed, 26 Sep 2012 09:15:57 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Wed, 26 Sep 2012 09:15:56 -0700 (PDT) In-Reply-To: <201209260953.27806.jhb@freebsd.org> References: <201208170941.54482.jhb@freebsd.org> <201209260953.27806.jhb@freebsd.org> Date: Wed, 26 Sep 2012 09:15:56 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 16:15:58 -0000 On Wed, Sep 26, 2012 at 6:53 AM, John Baldwin wrote: > On Tuesday, September 25, 2012 4:19:01 pm Vijay Singh wrote: > > > Vijay, can you test this to see if it helps with your test case? > > > > > >> Jack > > > > John, apologies for the delay. I have some data to share now. > > > > With your patch, the transmit side lock contention is all gone. > > However I still see receive side contention. I have MSI/X enabled, > > with one hw queue per-port. > > Well, that's progress at least. Jack, can you ok this patch? It is just > the > changes to adjust the deferred tx handling and doesn't include any watchdog > changes. The igb fix is just a comestic nit: > Thanks for the changes John, I approve the commit. Jack > > Index: dev/e1000/if_igb.h > =================================================================== > --- dev/e1000/if_igb.h (revision 240960) > +++ dev/e1000/if_igb.h (working copy) > @@ -299,9 +299,9 @@ > struct igb_tx_buffer *tx_buffers; > #if __FreeBSD_version >= 800000 > struct buf_ring *br; > + struct task txq_task; > #endif > bus_dma_tag_t txtag; > - struct task txq_task; > > u32 bytes; > u32 packets; > Index: dev/ixgbe/ixgbe.c > =================================================================== > --- dev/ixgbe/ixgbe.c (revision 240960) > +++ dev/ixgbe/ixgbe.c (working copy) > @@ -104,13 +104,15 @@ > static int ixgbe_attach(device_t); > static int ixgbe_detach(device_t); > static int ixgbe_shutdown(device_t); > -static void ixgbe_start(struct ifnet *); > -static void ixgbe_start_locked(struct tx_ring *, struct ifnet *); > #if __FreeBSD_version >= 800000 > static int ixgbe_mq_start(struct ifnet *, struct mbuf *); > static int ixgbe_mq_start_locked(struct ifnet *, > struct tx_ring *, struct mbuf *); > static void ixgbe_qflush(struct ifnet *); > +static void ixgbe_deferred_mq_start(void *, int); > +#else > +static void ixgbe_start(struct ifnet *); > +static void ixgbe_start_locked(struct tx_ring *, struct ifnet *); > #endif > static int ixgbe_ioctl(struct ifnet *, u_long, caddr_t); > static void ixgbe_init(void *); > @@ -631,6 +633,7 @@ > { > struct adapter *adapter = device_get_softc(dev); > struct ix_queue *que = adapter->queues; > + struct tx_ring *txr = adapter->tx_rings; > u32 ctrl_ext; > > INIT_DEBUGOUT("ixgbe_detach: begin"); > @@ -645,8 +648,11 @@ > ixgbe_stop(adapter); > IXGBE_CORE_UNLOCK(adapter); > > - for (int i = 0; i < adapter->num_queues; i++, que++) { > + for (int i = 0; i < adapter->num_queues; i++, que++, txr++) { > if (que->tq) { > +#if __FreeBSD_version >= 800000 > + taskqueue_drain(que->tq, &txr->txq_task); > +#endif > taskqueue_drain(que->tq, &que->que_task); > taskqueue_free(que->tq); > } > @@ -708,6 +714,7 @@ > } > > > +#if __FreeBSD_version < 800000 > /********************************************************************* > * Transmit entry point > * > @@ -779,7 +786,7 @@ > return; > } > > -#if __FreeBSD_version >= 800000 > +#else > /* > ** Multiqueue Transmit driver > ** > @@ -807,7 +814,7 @@ > IXGBE_TX_UNLOCK(txr); > } else { > err = drbr_enqueue(ifp, txr->br, m); > - taskqueue_enqueue(que->tq, &que->que_task); > + taskqueue_enqueue(que->tq, &txr->txq_task); > } > > return (err); > @@ -873,6 +880,22 @@ > } > > /* > + * Called from a taskqueue to drain queued transmit packets. > + */ > +static void > +ixgbe_deferred_mq_start(void *arg, int pending) > +{ > + struct tx_ring *txr = arg; > + struct adapter *adapter = txr->adapter; > + struct ifnet *ifp = adapter->ifp; > + > + IXGBE_TX_LOCK(txr); > + if (!drbr_empty(ifp, txr->br)) > + ixgbe_mq_start_locked(ifp, txr, NULL); > + IXGBE_TX_UNLOCK(txr); > +} > + > +/* > ** Flush all ring buffers > */ > static void > @@ -2230,6 +2258,9 @@ > { > device_t dev = adapter->dev; > struct ix_queue *que = adapter->queues; > +#if __FreeBSD_version >= 800000 > + struct tx_ring *txr = adapter->tx_rings; > +#endif > int error, rid = 0; > > /* MSI RID at 1 */ > @@ -2249,6 +2280,9 @@ > * Try allocating a fast interrupt and the associated deferred > * processing contexts. > */ > +#if __FreeBSD_version >= 800000 > + TASK_INIT(&txr->txq_task, 0, ixgbe_deferred_mq_start, txr); > +#endif > TASK_INIT(&que->que_task, 0, ixgbe_handle_que, que); > que->tq = taskqueue_create_fast("ixgbe_que", M_NOWAIT, > taskqueue_thread_enqueue, &que->tq); > @@ -2295,9 +2329,10 @@ > { > device_t dev = adapter->dev; > struct ix_queue *que = adapter->queues; > + struct tx_ring *txr = adapter->tx_rings; > int error, rid, vector = 0; > > - for (int i = 0; i < adapter->num_queues; i++, vector++, que++) { > + for (int i = 0; i < adapter->num_queues; i++, vector++, que++, > txr++) { > rid = vector + 1; > que->res = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, > RF_SHAREABLE | RF_ACTIVE); > @@ -2327,6 +2362,9 @@ > if (adapter->num_queues > 1) > bus_bind_intr(dev, que->res, i); > > +#if __FreeBSD_version >= 800000 > + TASK_INIT(&txr->txq_task, 0, ixgbe_deferred_mq_start, txr); > +#endif > TASK_INIT(&que->que_task, 0, ixgbe_handle_que, que); > que->tq = taskqueue_create_fast("ixgbe_que", M_NOWAIT, > taskqueue_thread_enqueue, &que->tq); > @@ -2570,12 +2608,13 @@ > ifp->if_softc = adapter; > ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; > ifp->if_ioctl = ixgbe_ioctl; > - ifp->if_start = ixgbe_start; > #if __FreeBSD_version >= 800000 > ifp->if_transmit = ixgbe_mq_start; > ifp->if_qflush = ixgbe_qflush; > +#else > + ifp->if_start = ixgbe_start; > + IFQ_SET_MAXLEN(&ifp->if_snd, adapter->num_tx_desc - 2); > #endif > - ifp->if_snd.ifq_maxlen = adapter->num_tx_desc - 2; > > ether_ifattach(ifp, adapter->hw.mac.addr); > > Index: dev/ixgbe/ixgbe.h > =================================================================== > --- dev/ixgbe/ixgbe.h (revision 240960) > +++ dev/ixgbe/ixgbe.h (working copy) > @@ -314,6 +314,7 @@ > char mtx_name[16]; > #if __FreeBSD_version >= 800000 > struct buf_ring *br; > + struct task txq_task; > #endif > #ifdef IXGBE_FDIR > u16 atr_sample; > > -- > John Baldwin > From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 16:17:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA5CC106566B; Wed, 26 Sep 2012 16:17:15 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 444E08FC12; Wed, 26 Sep 2012 16:17:14 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1096893vbm.13 for ; Wed, 26 Sep 2012 09:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DmJrNoQ7lNW1rCahwpWk1E7ofFwWK9NDgsAMq2MSoK4=; b=ofymMTte6Aw6TXJZ5Vhg1/KHUc2yLhEeOwXrJm/NKmHhErVbd6W+Zx/NUd25YTuqrO zoebWWtp4dUITmCuJidodyKV2L6120QdpVzYLlCHLOud+L9QLDPDDGWMz5AAVkYxr81U 4aEpOX6uE+d12X5/WlG1PDoSvUWvZJ8L/DWm2fEzJiuhAQFMhXv7dCvEmH5IyREIyRGJ a9xc3/cib6GUVUaGX40pjNem4cfmzOymnWlepTRERjBHOUmZQ1oVMAFPgaye6zC3c1Ps Ep+x9jHknXSa4kOnM58FI7XKCsC/GOuU7zL0tLHbBCwbwfYQEyFqyJsAZTsb4Aa5A1ZP LScg== MIME-Version: 1.0 Received: by 10.58.207.39 with SMTP id lt7mr562178vec.40.1348676234345; Wed, 26 Sep 2012 09:17:14 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Wed, 26 Sep 2012 09:17:14 -0700 (PDT) In-Reply-To: <201209260955.14417.jhb@freebsd.org> References: <201209260955.14417.jhb@freebsd.org> Date: Wed, 26 Sep 2012 09:17:14 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 16:17:15 -0000 On Wed, Sep 26, 2012 at 6:55 AM, John Baldwin wrote: > On Tuesday, September 25, 2012 4:40:58 pm Jack Vogel wrote: > > Ah yes, at one time I was keeping the RX side lock when calling the > stack, > > but then as I recall that had problems, so the code now releases and > > reaquires > > as you can see. It results in some contention but I'm not sure that's > > avoidable. > > > > I've seen some LRO related panics on the 1G driver that may be related to > > this lock release, or that's one theory I have.. > > > > Thanks for the testing Vijay! > > You only have to drop the RX lock around if_input() if you use the same > lock > for both TX and RX (as if_transmit() / if_start() can be invoked while > locks > in the network stack are held). If WITNESS complains, the fix is to only > use > the MTX_NETWORK_LOCK "lock type name" for your transmit ring locks, not for > RX. > > -- > John Baldwin > Oh, hmmm, well I should do some further testing with this then. Thanks for the tip. Jack From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 18:22:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3AA4106564A for ; Wed, 26 Sep 2012 18:22:09 +0000 (UTC) (envelope-from ded1@MyBSD.org.my) Received: from SAURON.KNOWLEDGEGRID.NET.MY (sauron.knowledgegrid.net.my [192.228.137.13]) by mx1.freebsd.org (Postfix) with ESMTP id 742C08FC1E for ; Wed, 26 Sep 2012 18:22:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by SAURON.KNOWLEDGEGRID.NET.MY (Postfix) with ESMTP id 5E2C11BD261 for ; Wed, 26 Sep 2012 17:58:11 +0800 (MYT) Date: Wed, 26 Sep 2012 17:58:11 +0800 (MYT) From: "ded1@MyBSD.org.my" X-X-Sender: ded1@sauron.knowledgegrid.net.my To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 18:22:09 -0000 Hi, i'm installing isc-dhcp42-server and run in the network for like 1000 node. i have like 1000 mac address (servers, PC's, printers, phones, etc) which i put in the text file. FYI, Any mac address (which is in the text file) who plug into the network will get the ip address based on the vlan configured on the switch. Any mac address who's NOT in the text file, will not getting any IP and they will not authorize to be in our network. Is this possible to do with isc-dhcp ? I try to search around these topic but not much help. Anyone have any tips / shed me some light ? --- ded1 MyBSD Malaysia Project http://www.MyBSD.org.my From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 18:45:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E77D106568F for ; Wed, 26 Sep 2012 18:45:54 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 01AD08FC08 for ; Wed, 26 Sep 2012 18:45:53 +0000 (UTC) Received: by wgi16 with SMTP id 16so682571wgi.31 for ; Wed, 26 Sep 2012 11:45:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+F6n6KZPBX6+CjGdFVY7D5FjpMWY2Y5sI30I8mCQO8U=; b=NZijfQyqQsE6PbSSEh73aFNYgDLxf7efiXTRhQhMwtURxXA2IMLmQ5ks+DOLN97McR zGHqfETVDMxE2Qym8+wOxtskFS0VjkUxWqZi2aDHrqgNroRayvpd5jS8II0bwFK06ysu JaERBDeQbYY+qGZfQCzaIjTykY2r1J1zDvBhVsNWAvhebpdaTVIIN/BdhyDAUJbrNjZm WVSLqeeuugOeigJGpWqXT5fZci71n04llON8JOdL80/dpij+bFtgf0iWIoTeuKG2KboO ITEYmIa0PbTUX5YjKUCYSSIWyo7nfI23/FbuhMwjSWH7ljjuBCCatzqRjySgWUxk6hCj 3z7Q== MIME-Version: 1.0 Received: by 10.180.109.199 with SMTP id hu7mr23453700wib.21.1348685146898; Wed, 26 Sep 2012 11:45:46 -0700 (PDT) Received: by 10.223.129.3 with HTTP; Wed, 26 Sep 2012 11:45:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Sep 2012 11:45:46 -0700 Message-ID: From: Michael Sierchio To: "ded1@MyBSD.org.my" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn1lHnch1JLBWS3Nvfmgt2cP09N0aEEQXQMzVrnTgGnpMqDvuNY2sPZKp1C7/55e0DI7vf3 Cc: freebsd-net@freebsd.org Subject: Re: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 18:45:54 -0000 Yes, as I indicated above - but users could manually assign IP addresses, which means you can't really deny them access without switchport level control. - M On Wed, Sep 26, 2012 at 2:58 AM, ded1@MyBSD.org.my wrote: > Hi, > > > i'm installing isc-dhcp42-server and run in the network for like 1000 node. > i have like 1000 mac address (servers, PC's, printers, phones, etc) which i > put in the text file. > > FYI, > > > Any mac address (which is in the text file) who plug into the network will > get the ip address based on the vlan configured on the switch. Any mac > address who's NOT in the text file, will not getting any IP and they will > not authorize to be in our network. > > Is this possible to do with isc-dhcp ? I try to search around these topic > but not much help. > > Anyone have any tips / shed me some light ? > > > --- > ded1 > MyBSD Malaysia Project > http://www.MyBSD.org.my > _______________________________________________ > 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 Sep 26 18:52:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 967EE106566C for ; Wed, 26 Sep 2012 18:52:01 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ03.datapipe-corp.net (exfesmq03.datapipe.com [64.27.120.67]) by mx1.freebsd.org (Postfix) with ESMTP id 260B28FC18 for ; Wed, 26 Sep 2012 18:52:00 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ03.datapipe-corp.net (192.168.128.28) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 26 Sep 2012 14:50:51 -0400 Date: Wed, 26 Sep 2012 13:51:11 -0500 From: "Paul A. Procacci" To: "ded1@MyBSD.org.my" Message-ID: <20120926185110.GA2231@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 18:52:01 -0000 In dhcp.conf it describes ways to assign client's to classes. It further e= xplains how to `deny` or `allow` those clients assigned to those classes. Read the subsection from dhcpd.conf(5) called `SUBCLASSES`. It provides an example which almost answers your question in its entirety. ~Paul On Wed, Sep 26, 2012 at 05:58:11PM +0800, ded1@MyBSD.org.my wrote: > Hi, > > i'm installing isc-dhcp42-server and run in the network for like 1000 nod= e. i > have like 1000 mac address (servers, PC's, printers, phones, etc) which i= put > in the text file. > > FYI, > > Any mac address (which is in the text file) who plug into the network wil= l get > the ip address based on the vlan configured on the switch. Any mac addres= s > who's NOT in the text file, will not getting any IP and they will not aut= horize > to be in our network. > > Is this possible to do with isc-dhcp ? I try to search around these topic= but > not much help. > > Anyone have any tips / shed me some light ? > > > --- > ded1 > MyBSD Malaysia Project > http://www.MyBSD.org.my > _______________________________________________ > 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" ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 18:55:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB1101065670 for ; Wed, 26 Sep 2012 18:55:14 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9028FC18 for ; Wed, 26 Sep 2012 18:55:13 +0000 (UTC) Received: (qmail 20239 invoked from network); 26 Sep 2012 20:38:05 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Sep 2012 20:38:05 -0000 Message-ID: <50634F85.50901@networx.ch> Date: Wed, 26 Sep 2012 20:55:01 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrey Zonov References: <505AC500.6060903@FreeBSD.org> <505F2C2D.5050904@FreeBSD.org> In-Reply-To: <505F2C2D.5050904@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "Eggert, Lars" Subject: Re: [patch] sysctls for TCP timers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 18:55:14 -0000 On 23.09.2012 17:35, Andrey Zonov wrote: > On 9/20/12 11:35 AM, Eggert, Lars wrote: >> Hi, >> >> On Sep 20, 2012, at 9:25, Andrey Zonov wrote: >>> Some of them may be read google's article about tuning TCP parameters >>> [1]. I convert most of TCP timers to sysctls [2] and we are using this >>> patch for few months. We tuned net.inet.tcp.rtobase and >>> net.inet.tcp.syncache.rexmttime and it gives good results (especially in >>> conjunction with cc_htcp(4)). >> >> can you share some measurements that quantify the results? >> > > When we set net.inet.tcp.syncache.rexmttime=200 and > net.inet.tcp.syncache.rexmtlimit=7 for our external web service, the > number of duplicated SYN was reduced in four times. This isn't surprising. You're simply trading retransmits by the client with retransmits by the server. Whether this is within the overall packet conservation principle is not clear. On the timeline it may be an advantage. I'm not comfortable with the rather low retransmit time you've chosen here. Considering higher RTT's (e.g. Hawaii or JP/CN) and the bufferbloat problem this may be too low. When it is to be tuned, then something in the range of 500-1000ms may be more realistic to avoid spurious retransmits. When a SYN or SYN/ACK retransmit happens, the initial CWND should be reduced per the applicable RFC's as this indicates packet loss on the downstream. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:06:40 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8E01065677 for ; Wed, 26 Sep 2012 19:06:40 +0000 (UTC) (envelope-from noidmvp@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 604E08FC20 for ; Wed, 26 Sep 2012 19:06:40 +0000 (UTC) Received: by ieak10 with SMTP id k10so3297259iea.13 for ; Wed, 26 Sep 2012 12:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9yRkC42DXtuwhZGkhSvr9E6LS5SViBV0sAfafHasD/4=; b=I1162yKNTzIAEtE3r4r2+fqPsk7cA0OMft0TWuQlivLDZNrkeHtcSnmB12JcW2s6MB 6yEKvno3NIgqEPmmDK652A65J4419GsPNS9bDIVaSkg528cNmwqWuZaxXhrK8CKNJiOu ITF6EG64CdMB2AsixqFmpJPnvcxT0NTHD4X4xL1Rpi8VPGtXocPN847cBIZM6YjoyINv ir0oMgqoEGvkJGlLJSeO78xU20E7UHdJ/HfbGDZzJOuU7Z9+TF+sspTOekB8Mt9W8Sxe +jXk+Ow0aDSrdgAcSicFc+D243xlINx6P3SjrQmfbfGmiibQliX+9Ry8bm3rJ/ZmUZ1A mb/Q== MIME-Version: 1.0 Received: by 10.50.207.36 with SMTP id lt4mr11930046igc.66.1348686399749; Wed, 26 Sep 2012 12:06:39 -0700 (PDT) Received: by 10.231.231.147 with HTTP; Wed, 26 Sep 2012 12:06:39 -0700 (PDT) In-Reply-To: <61FE9B5E-CBAF-45C7-AC10-6BE0428795BC@MyBSD.org.my> References: <61FE9B5E-CBAF-45C7-AC10-6BE0428795BC@MyBSD.org.my> Date: Wed, 26 Sep 2012 16:06:39 -0300 Message-ID: From: marcos alves To: Ahmad Faisal Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@FreeBSD.org Subject: Re: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 19:06:40 -0000 To do what you want you will have to make a script to collect the mac addresses and insert into your dhcp.conf . Also check the dhcpd.conf(5) called `SUBCLASSES`. as Paul suggested. Marcos Alves 2012/9/26 Ahmad Faisal > *You wrote:* > *From:* marcos alves > *To:* "ded1@MyBSD.org.my" > *Sent:* Wednesday, September 26, 2012 6:20 PM > > *Subject:* Re: DHCP server with a group of mac address > > >I dont know if im following you correctly, but yes you can set up your > lish of mac address to be >the only ones allowed to get specified ip > addresses in your network trough isc-dhcp. so the >ones that are not > specified in the conf won't be able to get any configuration of DHCPD > server. > >If that's what you looking for, i think i have some information on how to > do it. > > > I don't really get what you mean, how do i include the text file with all > the mac address into the dhcpd.conf and declare on which dhcpd syntax ? Do > you have the sample of the dhcpd.conf ? > > > > --- > ded1 > MyBSD Malaysia Project > http://www.MyBSD.org.my > > > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:08:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229091065672; Wed, 26 Sep 2012 19:08:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B1EEC8FC18; Wed, 26 Sep 2012 19:08:23 +0000 (UTC) Received: by qcsl39 with SMTP id l39so941444qcs.13 for ; Wed, 26 Sep 2012 12:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yopeyFXc5t5o/vdXC9/VKUgFuot46TPsc5moXcImtPA=; b=H5V1r8M1pUl/A1zCHNM2YpDZDvR6oZkILY/cQNogz9+ptuV69jcMyk3wq9co9SNIQB Zb7E4fJyi7p+QRRRieKANR+y1uatFYnr068auMCC6ITml40swxazrIci8JCbNTMe4fvi 6r155qDjFEc5Kv7WstNf5We3M0BxJ5thLF/CHIQTj2TPaHloIVlijr3lZKMFzlUh6YQ+ QAtw2DIq/rQEPDgwOTEREDjeqVr1SMAQqxmh69djpOTYe7x5KDjMr/zeNHO9KuwZP1+Z J5HkJm58+ClkOsV6DGVPoi5FD6mdLPk2etqomIstM3p4E+qC/L3/tMp5n6f1ozGnvJOO janQ== MIME-Version: 1.0 Received: by 10.224.181.198 with SMTP id bz6mr3081574qab.97.1348686502688; Wed, 26 Sep 2012 12:08:22 -0700 (PDT) Received: by 10.49.50.103 with HTTP; Wed, 26 Sep 2012 12:08:22 -0700 (PDT) In-Reply-To: <201209260955.14417.jhb@freebsd.org> References: <201209260955.14417.jhb@freebsd.org> Date: Wed, 26 Sep 2012 15:08:22 -0400 Message-ID: From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Jack Vogel , Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 19:08:24 -0000 On Wed, Sep 26, 2012 at 9:55 AM, John Baldwin wrote: > You only have to drop the RX lock around if_input() if you use the same lock > for both TX and RX (as if_transmit() / if_start() can be invoked while locks > in the network stack are held). Last time I checked(FreeBSD 8.2), this is not true. The problematic (and convoluted) ordering is: ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx udp -> udpinp -> in_multi_mtx is defined in subr_witness.c. ix:core -> ix:rx is fairly obvious, and happens in places like ixgbe_init. ix:rx -> udp is also fairly obvious (here's one backtrace): lock order reversal:^M^M 1st 0xffffff800153c138 ix:rx (ix:rx) @ src/sys/dev/ixgbe/ixgbe.c:7113^M^M 2nd 0xffffffff80af9c48 udp (udp) @ src/sys/netinet/udp_usrreq.c:471^M^M KDB: stack backtrace:^M^M db_trace_self_wrapper() at 0xffffffff801dd5aa = db_trace_self_wrapper+0x2a^M^M _witness_debugger() at 0xffffffff8044411e = _witness_debugger+0x2e^M^M witness_checkorder() at 0xffffffff804453c7 = witness_checkorder+0x807^M^M _rw_rlock() at 0xffffffff803fb61a = _rw_rlock+0x7a^M^M udp_input() at 0xffffffff80517d1c = udp_input+0x1bc^M^M ip_input() at 0xffffffff804f6b32 = ip_input+0x1e2^M^M netisr_dispatch_src() at 0xffffffff804bfc38 = netisr_dispatch_src+0xb8^M^M ether_demux() at 0xffffffff804b0fca = ether_demux+0x1aa^M^M ether_input() at 0xffffffff804b141a = ether_input+0x1ca^M^M ixgbe_rxeof() at 0xffffffff802d8ba3 = ixgbe_rxeof+0x203^M^M ixgbe_msix_que() at 0xffffffff802e1790 = ixgbe_msix_que+0xf0^M^M intr_event_execute_handlers() at 0xffffffff803d4096 = intr_event_execute_handler s+0x66^M^M ithread_loop() at 0xffffffff803d4e12 = ithread_loop+0xb2^M^M fork_exit() at 0xffffffff803d1fba = fork_exit+0x12a^M^M fork_trampoline() at 0xffffffff805f582e = fork_trampoline+0xe^M^M --- trap 0, rip = 0, rsp = 0xffffff8000148d00, rbp = 0 ---^M^M in_multi_mtx -> ix:core comes from the following backtrace: lock order reversal: 1st 0xffffffff80ae2440 in_multi_mtx (in_multi_mtx) @ src/sys/netinet/in_mcast.c:1095 2nd 0xffffff8001539400 ixgbe0 (IXGBE Core Lock) @ src/sys/dev/ixgbe/ixgbe.c:1725 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801dd5aa = db_trace_self_wrapper+0x2a _witness_debugger() at 0xffffffff8044411e = _witness_debugger+0x2e witness_checkorder() at 0xffffffff804453c7 = witness_checkorder+0x807 _mtx_lock_flags() at 0xffffffff803ec3ba = _mtx_lock_flags+0x8a ixgbe_ioctl() at 0xffffffff802e07ae = ixgbe_ioctl+0x60e if_addmulti() at 0xffffffff804a9f7b = if_addmulti+0x19b in_joingroup_locked() at 0xffffffff804db8ec = in_joingroup_locked+0x1bc in_joingroup() at 0xffffffff804dd5a2 = in_joingroup+0x52 in_control() at 0xffffffff804d7a70 = in_control+0x1160 ifioctl() at 0xffffffff804adec6 = ifioctl+0x5b6 nfs_mountroot() at 0xffffffff80567244 = nfs_mountroot+0x94 nfs_mount() at 0xffffffff80567b7b = nfs_mount+0x4db vfs_donmount() at 0xffffffff8048919e = vfs_donmount+0xcde kernel_mount() at 0xffffffff80489a71 = kernel_mount+0xa1 vfs_mountroot_try() at 0xffffffff80489f9d = vfs_mountroot_try+0x17d vfs_mountroot() at 0xffffffff8048ab7d = vfs_mountroot+0x4fd start_init() at 0xffffffff803b2932 = start_init+0x62 fork_exit() at 0xffffffff803d1fba = fork_exit+0x12a fork_trampoline() at 0xffffffff805f582e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000042d00, rbp = 0 --- From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:15:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC2BF106566B for ; Wed, 26 Sep 2012 19:15:39 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe16.ukr.net (ffe16.ukr.net [195.214.192.51]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9D28FC18 for ; Wed, 26 Sep 2012 19:15:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=NAxvtLGe8K94G8RVuWXAEMd69k/WsxbWpINd37N6/uk=; b=JHXM+VUq/sud/T1a056fwqz5EKy7gaw2kiyBisCh4dX3pAG0ckdd1PL1R5gKGzH3849le1vHqfXAl6FSE6t1q463zMcEJJMnMP38ZVTSRJTKQ/HwxmJ8mP3RDeV77D4as4cGcWAYxWRBYAJyw2e9w3aEh/7xIQbJrz/WpRmoer0=; Received: from mail by ffe16.ukr.net with local ID 1TGwpI-000NUp-8H for freebsd-net@freebsd.org; Wed, 26 Sep 2012 21:59:16 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" In-Reply-To: References: To: freebsd-net@freebsd.org From: =?WINDOWS-1251?B?wuvg5Ojx6+DiIM/w7uTg7Q==?= X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [79.140.11.10] Message-Id: <89244.1348685956.1887024400859660288@ffe16.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1 Date: Wed, 26 Sep 2012 21:59:16 +0300 Subject: Re: DHCP server with a group of mac address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 19:15:39 -0000 --- Èñõîäíîå ñîîáùåíèå --- Îò êîãî: "ded1@MyBSD.org.my" Êîìó: freebsd-net@freebsd.org Äàòà: 26 ñåíòÿáðÿ 2012, 21:22:31 Òåìà: DHCP server with a group of mac address > Hi, > > i'm installing isc-dhcp42-server and run in the network for like 1000 node. i > have like 1000 mac address (servers, PC's, printers, phones, etc) which i put > in the text file. > > FYI, > > Any mac address (which is in the text file) who plug into the network will get > the ip address based on the vlan configured on the switch. Any mac address > who's NOT in the text file, will not getting any IP and they will not authorize > to be in our network. > > Is this possible to do with isc-dhcp ? I try to search around these topic but > not much help. > > Anyone have any tips / shed me some light ? > Reset the MAC Address table. Then read from a file line IP-MAC. All unoccupied IP score MAC address 00:00:00:00:00:00 Well, on the switch is enabled, if there is, the option "Port security" arp -d -a > /dev/null arp -f /etc/ethers > /dev/null echo 'Static ARP-table is loaded' $cat /etc/ethers 10.0.0.62 00:26:18:b8:d0:30 #Serg 10.0.0.64 D8:5D:4C:80:B1:4C #Valya ... 10.0.0.253 00:00:00:00:00:00 10.0.0.254 00:00:00:00:00:00 -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:38:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3D741065672 for ; Wed, 26 Sep 2012 19:38:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A78798FC14 for ; Wed, 26 Sep 2012 19:38:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 17131B922; Wed, 26 Sep 2012 15:38:34 -0400 (EDT) From: John Baldwin To: Ryan Stone Date: Wed, 26 Sep 2012 15:38:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201209260955.14417.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209261538.11588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 26 Sep 2012 15:38:34 -0400 (EDT) Cc: freebsd-net@freebsd.org, Jack Vogel , Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 19:38:34 -0000 On Wednesday, September 26, 2012 3:08:22 pm Ryan Stone wrote: > On Wed, Sep 26, 2012 at 9:55 AM, John Baldwin wrote: > > You only have to drop the RX lock around if_input() if you use the same lock > > for both TX and RX (as if_transmit() / if_start() can be invoked while locks > > in the network stack are held). > > Last time I checked(FreeBSD 8.2), this is not true. The problematic > (and convoluted) ordering is: > > ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx Hmm, I'm not sure where the 'in_multi_mtx -> ix:core' bit comes from. I think that is the broken part of this. The SIOCADDMULTI and SIOCDELMULTI ioctls are invoked without any stack locks held, so it shouldn't come from there. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 20:14:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E625E10656AD; Wed, 26 Sep 2012 20:14:18 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBAD8FC14; Wed, 26 Sep 2012 20:14:17 +0000 (UTC) Received: by eekc50 with SMTP id c50so608304eek.13 for ; Wed, 26 Sep 2012 13:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qB+NOGyXVP12hQgaIvRlzC8Vkk9Vb1XvFVQAVXv0iAg=; b=JaDMSr3vFTsmxRdPHvJNIteo5AuVoOBFdk9aeXa2+h/zDdzBQzBwA33hjBdG22uwDF D7mC2xzikg58nYRvJqB4QD0Ex/Tm5ybThkgmWO8bnFXTkcMbWXu8+N61la1OZ55V9c4k aoybxtPHUJdbC+ZsRUbZ++NcnL4FO1MClSS3c35xh2BiTxmNtgTg24k5jC08OxAfBZb9 MDe77YwTp1h2zurCF5B38SCh8t0QIMqF0ELQYkHJ16tuQqRGEH9NqXXdso4C4iHAwQKl p79wnnT3CBbF75W7V99HsdFvcGgGyvBY/6kZYEfUfu2Xwje8NJqCD6agMoC8i8Og1g16 Q0gg== MIME-Version: 1.0 Received: by 10.14.215.193 with SMTP id e41mr3023676eep.44.1348690457302; Wed, 26 Sep 2012 13:14:17 -0700 (PDT) Received: by 10.14.219.134 with HTTP; Wed, 26 Sep 2012 13:14:17 -0700 (PDT) In-Reply-To: References: <201208161736.47250.jhb@freebsd.org> <201208170941.54482.jhb@freebsd.org> Date: Wed, 26 Sep 2012 13:14:17 -0700 Message-ID: From: Vijay Singh To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 20:14:19 -0000 > Jack, I am wondering if this could be avoided if we can avoid to > enqueue the task OR re-enable interrupts if the other one is already > scheduled. Is this possible? It seems to me that ixgbe_handle_que() should only be doing ixgbe_rxeof(). When ever mq_start() is unable to send, it enqueues the new txq_task. Also, this is checked periodically from the timer function as well. I will try an experiment to evaluate only more_rx in ixgbe_msix_que() and change ixgbe_handle_que() to do rx processing only. I will report back findings. Meanwhile it its immediately obvious to anyone what this will break, please let me know. -vijay From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 20:21:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDF131065674; Wed, 26 Sep 2012 20:21:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF138FC0C; Wed, 26 Sep 2012 20:21:10 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so1562724vcb.13 for ; Wed, 26 Sep 2012 13:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Udu8wDM/HUQpbYfgqkwpmlm8DcXWG7Q3ynb21SsjK3A=; b=z8hmfxIqNwXOVk3+4a7SOHzH04pRBk9mbcg+7WKWaHz2CYThUzldtcobSUH6Gs37wB Dvu0rvTBbRQJrx+B4OgRkQniq9Okp61fPHwkRATZ+LaBqchz2iWmMA4wnwbXnclaiO48 cI02NxS/98vLCMmRRr1vn2nbKChH/7LkupOQDMf7S+RwTtAVoIAym8X4ZBHReX8yF6KJ zCv1d7pzfDSWvoJKzx5sf53BFA2XDheJkTlqymkSgSW9RYc4uoyuW5MrdBFB9gA9uYuR nPy0QkfKYlLmN1+2m7MNWWDF9UPYgqoKVihQXfvO3O4HBNpifXlxrETOCrWr13TnE2H5 ZzTA== MIME-Version: 1.0 Received: by 10.52.27.133 with SMTP id t5mr750614vdg.111.1348690869699; Wed, 26 Sep 2012 13:21:09 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Wed, 26 Sep 2012 13:21:09 -0700 (PDT) In-Reply-To: References: <201208161736.47250.jhb@freebsd.org> <201208170941.54482.jhb@freebsd.org> Date: Wed, 26 Sep 2012 13:21:09 -0700 Message-ID: From: Jack Vogel To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 20:21:11 -0000 On Wed, Sep 26, 2012 at 1:14 PM, Vijay Singh wrote: > > Jack, I am wondering if this could be avoided if we can avoid to > > enqueue the task OR re-enable interrupts if the other one is already > > scheduled. Is this possible? > > It seems to me that ixgbe_handle_que() should only be doing > ixgbe_rxeof(). When ever mq_start() is unable to send, it enqueues the > new txq_task. Also, this is checked periodically from the timer > function as well. I will try an experiment to evaluate only more_rx in > ixgbe_msix_que() and change ixgbe_handle_que() to do rx processing > only. I will report back findings. > > Meanwhile it its immediately obvious to anyone what this will break, > please let me know. > > -vijay > OK, will be interested in the results. Jack From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 21:28:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33E621065686; Wed, 26 Sep 2012 21:28:10 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C9A328FC18; Wed, 26 Sep 2012 21:28:09 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1564866vbm.13 for ; Wed, 26 Sep 2012 14:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R5kVv6axpEIqrg+Di42UAlAMzgvD0n9Zc+QLAFMTpgY=; b=lOVjUKTc++SIIAyY0VUcDL6kACftK96WMatVol7enciNeaJdU3opq2CuqaaUXz+vsn wh2Zo9bUh0tak52hNk5ZWVoGnVOIzzk7sa6hxosb08p3am7J1/Hbq6O/u71Y5tUJGPcq Znqc6uInnt3i7nggBB1GsJCwPz9XDSZFofyfK2TD1tW+51HnGpvpiJsZeg+T9DnO3VXi pq4eH1VxJrzd8l1KwIxSZ3LNGfWU44tv//9B8AA/rOEbcv0Nzr2UERu0TorrG61/P45m p48BclbIh7bv8bbqM4o4KwP2sv2Wy09Xe3bIkayyLaDy4fdjsLmm1ZGGeqKfoLJdhNYb +CVg== MIME-Version: 1.0 Received: by 10.52.69.242 with SMTP id h18mr847296vdu.54.1348694889160; Wed, 26 Sep 2012 14:28:09 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Wed, 26 Sep 2012 14:28:09 -0700 (PDT) In-Reply-To: <201209261538.11588.jhb@freebsd.org> References: <201209260955.14417.jhb@freebsd.org> <201209261538.11588.jhb@freebsd.org> Date: Wed, 26 Sep 2012 17:28:09 -0400 Message-ID: From: Ryan Stone To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Jack Vogel , Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 21:28:10 -0000 On Wed, Sep 26, 2012 at 3:38 PM, John Baldwin wrote: >> ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx > > Hmm, I'm not sure where the 'in_multi_mtx -> ix:core' bit comes from. > I think that is the broken part of this. The SIOCADDMULTI and SIOCDELMULTI > ioctls are invoked without any stack locks held, so it shouldn't come from > there. I gave the backtrace for this part. in_joingroup_locked is called with the in_multi_mtx held, which calls if_addmulti, which calls the ioctl handler. lock order reversal: 1st 0xffffffff80ae2440 in_multi_mtx (in_multi_mtx) @ src/sys/netinet/in_mcast.c:1095 2nd 0xffffff8001539400 ixgbe0 (IXGBE Core Lock) @ src/sys/dev/ixgbe/ixgbe.c:1725 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801dd5aa = db_trace_self_wrapper+0x2a _witness_debugger() at 0xffffffff8044411e = _witness_debugger+0x2e witness_checkorder() at 0xffffffff804453c7 = witness_checkorder+0x807 _mtx_lock_flags() at 0xffffffff803ec3ba = _mtx_lock_flags+0x8a ixgbe_ioctl() at 0xffffffff802e07ae = ixgbe_ioctl+0x60e if_addmulti() at 0xffffffff804a9f7b = if_addmulti+0x19b in_joingroup_locked() at 0xffffffff804db8ec = in_joingroup_locked+0x1bc in_joingroup() at 0xffffffff804dd5a2 = in_joingroup+0x52 in_control() at 0xffffffff804d7a70 = in_control+0x1160 ifioctl() at 0xffffffff804adec6 = ifioctl+0x5b6 nfs_mountroot() at 0xffffffff80567244 = nfs_mountroot+0x94 nfs_mount() at 0xffffffff80567b7b = nfs_mount+0x4db vfs_donmount() at 0xffffffff8048919e = vfs_donmount+0xcde kernel_mount() at 0xffffffff80489a71 = kernel_mount+0xa1 vfs_mountroot_try() at 0xffffffff80489f9d = vfs_mountroot_try+0x17d vfs_mountroot() at 0xffffffff8048ab7d = vfs_mountroot+0x4fd start_init() at 0xffffffff803b2932 = start_init+0x62 fork_exit() at 0xffffffff803d1fba = fork_exit+0x12a fork_trampoline() at 0xffffffff805f582e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000042d00, rbp = 0 --- From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 22:11:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F3D2106566B for ; Wed, 26 Sep 2012 22:11:08 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3901A8FC08 for ; Wed, 26 Sep 2012 22:11:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TGzp0-0000Za-E4 for freebsd-net@freebsd.org; Thu, 27 Sep 2012 00:11:10 +0200 Received: from l.saper.info ([91.121.203.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2012 00:11:10 +0200 Received: from saper by l.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2012 00:11:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Marcin Cieslak Followup-To: gmane.os.freebsd.devel.net Date: Wed, 26 Sep 2012 22:10:53 +0000 (UTC) Organization: http://saper.info Lines: 25 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: l.saper.info X-Face: "MPx|KfVwz7Gg!ayb)rH,hKiCBJXvLY7t+%r1s0Uiw; (%xWn-C-H38.2Oa4JL|4Cx}a"V ~a pL4%i"s20r0%z0yZew?2><1ZfOFF27cPqcAKp?wG+-c&%BgXeJVm[lylYKH?j User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 22:11:08 -0000 I have just updated by 9.0-something laptop to 10.0-CURRENT r240948 and it very quickly panics after enabling network with IPsec (I am using IPsec w/racoon for IPv4 over 802.11, also using tunelled IPv6). It looks like in this part of sys/netipsec/ipsec_output.c: 447 #ifdef DEV_ENC 448 encif->if_opackets++; 449 encif->if_obytes += m->m_pkthdr.len; 450 451 /* pass the mbuf to enc0 for bpf processing */ 452 ipsec_bpf(m, sav, AF_INET, ENC_OUT|ENC_BEFORE); 453 /* pass the mbuf to enc0 for packet filtering */ 454 if ((error = ipsec_filter(&m, PFIL_OUT, ENC_OUT|ENC_BEFORE)) != 0) 455 goto bad; 456 #endif "encif" is NULL in line 448 Removing "device enc" from the kernel configuration helps. Used to work in early 9.x kernels... //Marcin From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 22:33:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 062C71065670 for ; Wed, 26 Sep 2012 22:33:28 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 887DD8FC14 for ; Wed, 26 Sep 2012 22:33:27 +0000 (UTC) Received: by wibhq12 with SMTP id hq12so4290651wib.13 for ; Wed, 26 Sep 2012 15:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=YXl3mOiclHtrz8eetpi09oyyTUKhkmIRHCVQpe5vrWI=; b=nd1LCUTZWRf7+Rky10qHODUK8JY6qCGtVNSjPxgmNhLxZrYLeKwb1g/KxvO8qOhfgp /gXOjYN8tu1lcKYs1CYclV0T1lXznxaieo5tLJH6FR9GIisw2P1WXmVrtg1H9dOml9B5 SprDdT4q65ro08p8llHqK0jm/wFDv6BDm38609Zv+SUl3+S+l8PQJR9+17GuYTsB7Ydm lLPgUVL8+kt0SS+4sA6EQungn7lzCM3eL+c7R9b39PaR+udXyT4Fa2vqXFRU46T5hkbY 93LbpX9eAXFnq5XEMWVOxkBeZ7mDZrZqsonQAXwdXcCl0xlR0ievVjMPXCZmV3CJm+wd DydQ== Received: by 10.180.107.163 with SMTP id hd3mr4032089wib.19.1348698806065; Wed, 26 Sep 2012 15:33:26 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.223.157.200 with HTTP; Wed, 26 Sep 2012 15:33:05 -0700 (PDT) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Thu, 27 Sep 2012 00:33:05 +0200 X-Google-Sender-Auth: wF0BsiFiVyHeJSLZk1bQm3UmLVo Message-ID: To: Marcin Cieslak Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 22:33:28 -0000 On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak wrote: > I have just updated by 9.0-something laptop to 10.0-CURRENT r240948 > and it very quickly panics after enabling network with IPsec > (I am using IPsec w/racoon for IPv4 over 802.11, also using > tunelled IPv6). I don't know if it's related, but one of the first dmesg message displayd on my -current (rev 240921) is: module_register: module enc already exists! Module enc failed to register: 17 Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 22:42:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2F291065670 for ; Wed, 26 Sep 2012 22:42:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 813F68FC08 for ; Wed, 26 Sep 2012 22:42:19 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so206535obb.13 for ; Wed, 26 Sep 2012 15:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cLW9h+DQxMd6njoc2J9WurU8p3irDD66aC/YD5plEPo=; b=qheozjgJbQhzgCyIzWRlD5F67MW+VJot7LNK02o1wmVum9TUVdkBAg4cxH450Q5+zY 7fsN5Y5cMn1cADXHycLbUXgGjWDv4kK/YcSXDUqch3zKCy7fedUyvogu6/M6ve6jaq75 sUC2T/hLK721/Ta4skGPvzil8IFxpO53ndC58Otpa0IRgdju8VturZ+i3co/dfPbyuco /p/cKHrH3L3YTfpOo0gjS7ChIdISvA2/VYi/yKn3fgy8x/B0AhHjuOeVROIApyw/rl1V oWx7Ey28hs3syKyANgHto2PRe/+dVlWkuiql0uGe7590150Gl9pYmCmoCDT9fTl3sJbH poqA== MIME-Version: 1.0 Received: by 10.60.171.134 with SMTP id au6mr1652138oec.69.1348699339488; Wed, 26 Sep 2012 15:42:19 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Wed, 26 Sep 2012 15:42:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Sep 2012 15:42:19 -0700 Message-ID: From: Garrett Cooper To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Marcin Cieslak Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Sep 2012 22:42:20 -0000 On Wed, Sep 26, 2012 at 3:33 PM, Olivier Cochard-Labb=E9 wrote: > On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak wrote= : >> I have just updated by 9.0-something laptop to 10.0-CURRENT r240948 >> and it very quickly panics after enabling network with IPsec >> (I am using IPsec w/racoon for IPv4 over 802.11, also using >> tunelled IPv6). > > I don't know if it's related, but one of the first dmesg message > displayd on my -current (rev 240921) is: > > module_register: module enc already exists! > Module enc failed to register: 17 Not 100% sure, but DEV_ENC might need to be specified in your $KERNCONF. IPv6 also has IPSEC built in... does this issue occur when IPv6 is disabled/not built into your kernel? Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 01:29:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEFA5106576B for ; Thu, 27 Sep 2012 01:29:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAAB8FC0A for ; Thu, 27 Sep 2012 01:29:42 +0000 (UTC) Received: by padbi1 with SMTP id bi1so995609pad.13 for ; Wed, 26 Sep 2012 18:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=1cD+PIkrp5c6E1A+0JsLdrO0OgUTVvwSnQLgJXaZkZE=; b=0pjJ56Q6kvnv5pMo6BAD5z/skY0+C/w+9WZlxdEyBCLf563TVydn0kWtnw2xjSMoJA INyfycu5F/DMSGSF6Trb31KEkURCC/zKrsEAHQ5CWRz6rS0eXIHuVdF2BwqaZUvIyKIA Hurt8rJ8x6cfkC/Kcd9jAigAyHbXLXmBp5LlhbsTAeqjTC0mFxqM+QwoZ/hq8eo9BkFA mC348OujXLd8fS9mF5jUGPscGUomYJtqo+bgvLpRfOenMiGGbrJduYCUtFDdbTDIL1NL MeFwkhTXuVmBf932UOISX5i6Q6PMii8P4C29tViQjBSPQ5Ioks78uNrlRW7FaFDOY3h3 CuCA== Received: by 10.68.229.201 with SMTP id ss9mr7018802pbc.80.1348709381587; Wed, 26 Sep 2012 18:29:41 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id kp3sm2916362pbc.64.2012.09.26.18.29.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 18:29:39 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 27 Sep 2012 10:29:26 -0700 From: YongHyeon PYUN Date: Thu, 27 Sep 2012 10:29:26 -0700 To: Vladimir Vladimir Message-ID: <20120927172926.GA3268@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.0-RELEASE Realtek 8168/81111 Driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 01:29:42 -0000 On Wed, Sep 26, 2012 at 04:12:19PM +0300, Vladimir Vladimir wrote: > Hi all, > > I've got an issue with new mother board ASUS P8Z77-M PRO. > > My FreeBSD 9.0-RELEASE can't set up Network interface for integrated NIC Realtek 8168/81111. > > I have tried FreeBSD-8.2, and FreeBSD-9.0 > I' downloaded new distributions from freebsd.org and tried boot from them but result the same. FreeBSD couldn't setup re0 interface. > > in the dmesg output : > > re0: port 0xd000-0xd0ff mem 0xdc104000-0xdc104fff,0xdc100000-0xdc103fff irq 17 at device 0.0 on pci2 > re0: Using 1 MSI-X message > re0: turning off MSI enable bit. > re0: Chip rev. 0x2c800000 > re0: MAC rev. 0x00000000 > > so looks like FreeBSD detected NIC, but ifconfig shows loop interface only There had been lots of re(4) changes since 9.0-RELEASE. Try 8.3-RELEASE or 9.1-RC1. > > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xa > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > > if i try command > > ifconfig re0 create > ifconfig: SIOCIFCREATE2: Invalid argument > > at the same time Ubuntu works perfect on this mother board, so there aren't any hardware issues > > In the official ASUS documentation for motherboard ASUS P8Z77-M PRO it's got NIC Realtek® 8111F, 1 x Gigabit LAN Controller(s) > http://www.asus.ua/Motherboards/Intel_Socket_1155/P8Z77M_PRO/#specifications > > May be re(4) driver not updated for this mother board yet?. > http://www.freebsd.org/cgi/man.cgi?query=re&apropos=0&sektion=4&manpath=FreeBSD+9.0-stable&arch=default&format=html > > If anybody faced of such issue., let me know. > > Thanks Vlad. From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 12:53:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43F451065673 for ; Thu, 27 Sep 2012 12:53:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 186038FC22 for ; Thu, 27 Sep 2012 12:53:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5EB29B944; Thu, 27 Sep 2012 08:53:57 -0400 (EDT) From: John Baldwin To: Ryan Stone Date: Thu, 27 Sep 2012 07:58:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201209261538.11588.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209270758.43445.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 27 Sep 2012 08:53:57 -0400 (EDT) Cc: freebsd-net@freebsd.org, Jack Vogel , Vijay Singh Subject: Re: ixgbe rx & tx locks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 12:53:58 -0000 On Wednesday, September 26, 2012 5:28:09 pm Ryan Stone wrote: > On Wed, Sep 26, 2012 at 3:38 PM, John Baldwin wrote: > >> ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx > > > > Hmm, I'm not sure where the 'in_multi_mtx -> ix:core' bit comes from. > > I think that is the broken part of this. The SIOCADDMULTI and SIOCDELMULTI > > ioctls are invoked without any stack locks held, so it shouldn't come from > > there. > > I gave the backtrace for this part. in_joingroup_locked is called > with the in_multi_mtx held, which calls if_addmulti, which calls the > ioctl handler. My bad. Too many locks. :( We do drop the IF_ADDR_LOCK when calling if_ioctl from if_addmulti(), but you are correct, in_multi_mtx is held. Not sure how resolvable that is. Many drivers need to do a fair bit of work in SIOCADDMULTI/SIOCDELMUTLI (that is, reprogram the entire multicast table). One alternative might be to use a separate lock just for the MAC filters. That might break the in_multi_mtx -> ix:core order by letting you avoid grabbing ix:core for those ioctls. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 12:54:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A5C31065673 for ; Thu, 27 Sep 2012 12:54:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2538FC26 for ; Thu, 27 Sep 2012 12:54:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68523B978; Thu, 27 Sep 2012 08:53:59 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 27 Sep 2012 08:53:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201209270853.31318.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 27 Sep 2012 08:53:59 -0400 (EDT) Cc: Garrett Cooper , Olivier =?iso-8859-1?q?Cochard-Labb=E9?= , Marcin Cieslak Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 12:54:00 -0000 On Wednesday, September 26, 2012 6:42:19 pm Garrett Cooper wrote: > On Wed, Sep 26, 2012 at 3:33 PM, Olivier Cochard-Labb=E9 > wrote: > > On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak wro= te: > >> I have just updated by 9.0-something laptop to 10.0-CURRENT r240948 > >> and it very quickly panics after enabling network with IPsec > >> (I am using IPsec w/racoon for IPv4 over 802.11, also using > >> tunelled IPv6). > > > > I don't know if it's related, but one of the first dmesg message > > displayd on my -current (rev 240921) is: > > > > module_register: module enc already exists! > > Module enc failed to register: 17 I suspect this is the root cause and that the "wrong" global variable is be= ing=20 used in ipsec_output.c due to duplicate symbols. OTOH, have you created an enc0 device? I can't find anything that=20 automatically creates it. =20 > Not 100% sure, but DEV_ENC might need to be specified in your > $KERNCONF. IPv6 also has IPSEC built in... does this issue occur when > IPv6 is disabled/not built into your kernel? Just one point: you do not need DEV_ENC. If you have 'device foo', config(= 8)=20 automatically enables a corresponding DEV_FOO option if it is listed in=20 sys/conf/options*. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 13:03:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DCEE106566C for ; Thu, 27 Sep 2012 13:03:27 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 56EC28FC0C for ; Thu, 27 Sep 2012 13:03:26 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1THDkL-00016v-Ji for freebsd-net@freebsd.org; Thu, 27 Sep 2012 15:03:17 +0200 Received: from l.saper.info ([91.121.203.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2012 15:03:17 +0200 Received: from saper by l.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2012 15:03:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Marcin Cieslak Date: Thu, 27 Sep 2012 13:02:59 +0000 (UTC) Organization: http://saper.info Lines: 33 Message-ID: References: <201209270853.31318.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: l.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 13:03:27 -0000 >> John Baldwin wrote: > On Wednesday, September 26, 2012 6:42:19 pm Garrett Cooper wrote: >> On Wed, Sep 26, 2012 at 3:33 PM, Olivier Cochard-Labbé >> wrote: >> > On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak wrote: >> >> I have just updated by 9.0-something laptop to 10.0-CURRENT r240948 >> >> and it very quickly panics after enabling network with IPsec >> >> (I am using IPsec w/racoon for IPv4 over 802.11, also using >> >> tunelled IPv6). >> > >> > I don't know if it's related, but one of the first dmesg message >> > displayd on my -current (rev 240921) is: >> > >> > module_register: module enc already exists! >> > Module enc failed to register: 17 > > I suspect this is the root cause and that the "wrong" global variable is being > used in ipsec_output.c due to duplicate symbols. As the original poster: I don't have this "module enc already exists!" message. I have had "device enc" in the kernel config file and I didn't try to load if_enc as module. I have IPSEC permanently enabled in the kernel and it is initialized at boot with setkey and later with racoon. > OTOH, have you created an enc0 device? I can't find anything that > automatically creates it. No. Previously, in 9.x times, it was always present in the ifconfig output. I was also looking for anything that initializes enc0 but couldn't find it. //Marcin From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 13:23:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17602106566B for ; Thu, 27 Sep 2012 13:23:59 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id C45CC8FC14 for ; Thu, 27 Sep 2012 13:23:58 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1THE4L-0002T6-Pt for freebsd-net@freebsd.org; Thu, 27 Sep 2012 15:23:57 +0200 Received: from l.saper.info ([91.121.203.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2012 15:23:57 +0200 Received: from saper by l.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2012 15:23:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Marcin Cieslak Date: Thu, 27 Sep 2012 13:23:42 +0000 (UTC) Organization: http://saper.info Lines: 16 Message-ID: References: <201209270853.31318.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: l.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 13:23:59 -0000 >> John Baldwin wrote: > OTOH, have you created an enc0 device? I can't find anything that > automatically creates it. Now I'm wondering if it got initialized in FreeBSD 9.x, too. I used to have net.inet.ip.fw.default_to_accept=0 before (now it's net.inet.ip.fw.default_to_accept=1) so maybe no traffic was sent via the interfaces until everything was fully up? On the other hand the panic occurs quite late - it happened during startup of sixxs-aiccu IPv6 tunnel (which goes over IPv4+mandatory IPsec in my setup). With different configuration it panicked during startup of slpd, also very late in the userland booting process. //Marcin From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 18:02:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D41C71065670 for ; Thu, 27 Sep 2012 18:02:03 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id B8C968FC15 for ; Thu, 27 Sep 2012 18:02:02 +0000 (UTC) Received: from [10.6.35.123] (208-90-212-192.PUBLIC.monkeybrains.net [208.90.212.192]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8RI1uxO020307 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2012 11:01:56 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <50649457.4050701@monkeybrains.net> Date: Thu, 27 Sep 2012 11:00:55 -0700 From: Rudy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> <50616D5C.705@gmail.com> In-Reply-To: <50616D5C.705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 18:02:03 -0000 On 09/25/2012 01:37 AM, Hooman Fazaeli wrote: >> dev.em.1.link_irq: 6379725883 >> dev.em.2.link_irq: 6379294926 > Based on the strangely high value of dev.em.1.link_irq (which means too > many link > status changes: down -> up -> down -> ....), I guess the problem is the > same as > discussed in these threads: > > http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html > http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031648.html > > To confirm, you may run this test: > > 1. Start a ping flood: ping -f > 2. Let it run for a few seconds. > 3. Disconnect the cable. > 4. After a while, you should see "no buffer space" error. > 5. Stop ping flood. > 6. Re-connect the cable and wait 10 seconds. > 7. Start a normal ping. Error messages should show up again. > > To fix, upgrade to the latest e1000 driver from HEAD. > > The very high link_irq may be due to a loose connection. > Replace the patch cord and see if it helps. Thanks for the tips. I will test next time I am at the data center. For now, I rebooted after doubled the default nmbclusters and quadrupled the hw.em.rxd values in loader.conf. # loader.conf kern.ipc.nmbclusters=524288 hw.igb.rxd=4096 hw.igb.txd=4096 hw.em.rxd=4096 hw.em.txd=4096 Rebooting and/or the settings change seems to have stopped the errors. Here is a pretty little graph showing error rate on em1 for the past 3 days. http://www.monkeybrains.net/images/ErrorRate-em1.png Rudy From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 18:06:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD02E106564A for ; Thu, 27 Sep 2012 18:06:47 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 774BE8FC0A for ; Thu, 27 Sep 2012 18:06:46 +0000 (UTC) Received: from [10.6.35.123] (208-90-212-192.PUBLIC.monkeybrains.net [208.90.212.192]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8RI6leb021580 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2012 11:06:47 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <5064957A.6050709@monkeybrains.net> Date: Thu, 27 Sep 2012 11:05:46 -0700 From: Rudy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> <50616D5C.705@gmail.com> <50649457.4050701@monkeybrains.net> In-Reply-To: <50649457.4050701@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 18:06:47 -0000 On 09/27/2012 11:00 AM, Rudy wrote: > On 09/25/2012 01:37 AM, Hooman Fazaeli wrote: > >>> dev.em.1.link_irq: 6379725883 > >>> dev.em.2.link_irq: 6379294926 > > >> Based on the strangely high value of dev.em.1.link_irq (which means too >> many link >> status changes: down -> up -> down -> ....), I guess the problem is the >> same as >> discussed in these threads: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html >> http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031648.html >> >> To confirm, you may run this test: >> >> 1. Start a ping flood: ping -f >> 2. Let it run for a few seconds. >> 3. Disconnect the cable. >> 4. After a while, you should see "no buffer space" error. >> 5. Stop ping flood. >> 6. Re-connect the cable and wait 10 seconds. >> 7. Start a normal ping. Error messages should show up again. >> >> To fix, upgrade to the latest e1000 driver from HEAD. >> >> The very high link_irq may be due to a loose connection. >> Replace the patch cord and see if it helps. > > Thanks for the tips. I will test next time I am at the data center. For > now, I rebooted after doubled the default nmbclusters and quadrupled the > hw.em.rxd values in loader.conf. > > # loader.conf > kern.ipc.nmbclusters=524288 > hw.igb.rxd=4096 > hw.igb.txd=4096 > hw.em.rxd=4096 > hw.em.txd=4096 > > Rebooting and/or the settings change seems to have stopped the errors. > Here is a pretty little graph showing error rate on em1 for the past 3 > days. > > http://www.monkeybrains.net/images/ErrorRate-em1.png > > Rudy > _______________________________________________ > 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 Sep 27 18:09:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8508106564A for ; Thu, 27 Sep 2012 18:09:52 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2398FC0C for ; Thu, 27 Sep 2012 18:09:52 +0000 (UTC) Received: from [10.6.35.123] (208-90-212-192.PUBLIC.monkeybrains.net [208.90.212.192]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id q8RI9qp6022518 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2012 11:09:52 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <50649633.2090307@monkeybrains.net> Date: Thu, 27 Sep 2012 11:08:51 -0700 From: Rudy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> <50616D5C.705@gmail.com> <50649457.4050701@monkeybrains.net> In-Reply-To: <50649457.4050701@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 18:09:52 -0000 On 09/27/2012 11:00 AM, Rudy wrote: > Rebooting and/or the settings change seems to have stopped the errors. > Here is a pretty little graph showing error rate on em1 for the past 3 > days. > > http://www.monkeybrains.net/images/ErrorRate-em1.png > Interesting... if I zoom in on the graph, I see the errors were 'every other sample period' until I rebooted the box. http://www.monkeybrains.net/images/ErrorRate-em1-zoom.png Rudy From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 18:16:37 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7901065801; Thu, 27 Sep 2012 18:16:37 +0000 (UTC) (envelope-from fjoe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 382E18FC16; Thu, 27 Sep 2012 18:16:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8RIGb32097028; Thu, 27 Sep 2012 18:16:37 GMT (envelope-from fjoe@freefall.freebsd.org) Received: (from fjoe@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8RIGa90097023; Thu, 27 Sep 2012 18:16:36 GMT (envelope-from fjoe) Date: Thu, 27 Sep 2012 18:16:36 GMT Message-Id: <201209271816.q8RIGa90097023@freefall.freebsd.org> To: mala@hinterbergen.de, fjoe@FreeBSD.org, freebsd-net@FreeBSD.org From: fjoe@FreeBSD.org Cc: Subject: Re: kern/106438: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 18:16:37 -0000 Synopsis: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) State-Changed-From-To: open->patched State-Changed-By: fjoe State-Changed-When: Thu Sep 27 18:15:10 UTC 2012 State-Changed-Why: The fix is in upstream CVS (including v4-1-RELEASE branch): http://ipfilter.cvs.sourceforge.net/viewvc/ipfilter/ipfilter/ip_fil_freebsd.c?r1=1.1.3.1.2.24&r2=1.1.3.1.2.25&pathrev=v4-1-RELEASE Committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=106438 From owner-freebsd-net@FreeBSD.ORG Thu Sep 27 18:17:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F7BB1065700; Thu, 27 Sep 2012 18:17:04 +0000 (UTC) (envelope-from fjoe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02DBF8FC17; Thu, 27 Sep 2012 18:17:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8RIH3fv097139; Thu, 27 Sep 2012 18:17:03 GMT (envelope-from fjoe@freefall.freebsd.org) Received: (from fjoe@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8RIH32Y097135; Thu, 27 Sep 2012 18:17:03 GMT (envelope-from fjoe) Date: Thu, 27 Sep 2012 18:17:03 GMT Message-Id: <201209271817.q8RIH32Y097135@freefall.freebsd.org> To: fjoe@FreeBSD.org, freebsd-net@FreeBSD.org, fjoe@FreeBSD.org From: fjoe@FreeBSD.org Cc: Subject: Re: kern/106438: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Sep 2012 18:17:04 -0000 Synopsis: [ipf] ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) Responsible-Changed-From-To: freebsd-net->fjoe Responsible-Changed-By: fjoe Responsible-Changed-When: Thu Sep 27 18:16:48 UTC 2012 Responsible-Changed-Why: I take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=106438 From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 11:47:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 803C61065670 for ; Fri, 28 Sep 2012 11:47:01 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id E84D98FC17 for ; Fri, 28 Sep 2012 11:47:00 +0000 (UTC) Received: by lage12 with SMTP id e12so1230501lag.13 for ; Fri, 28 Sep 2012 04:46:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=BX2xiBYxvhaXmLkYRD6LeVvs/jl7jWwfRjfpFle2R+Y=; b=S6l/RV1YMFj/IqAIXSFq7tF+pVFIp8H0FWv0zVM/0iwF0sU4t38gTIrliwDISD1F1t nZn/u7DwUcDnysv5Dt6AwDNCC48wXxJvFe9/7K3H5wVenKY0wek/sUbm7WObLnPS3Hkw Dh0ewE+MLEvGJkVg6eSq2w/L8xiiJCJbFWSyIzDg8oM1vQ4nCb1+VRmmHUs80casRSVf m8AWtY32RmmQBqcU6XBR6KHpK9Ty1AnkLScT+u7jL6DeL7VnfGFal5Yz0rAhpmnoLLu4 dn35ILOKqZqzF0974lu3jnoLfKPJ/TFGg/jJFv6QQXe98tkRhyh0HzxAJ5qAQN8ydvV+ t9bA== Received: by 10.152.112.37 with SMTP id in5mr5598711lab.44.1348832819011; Fri, 28 Sep 2012 04:46:59 -0700 (PDT) Received: from dhcp170-82-red.yandex.net (dhcp170-82-red.yandex.net. [95.108.170.82]) by mx.google.com with ESMTPS id d1sm2433783lbh.7.2012.09.28.04.46.57 (version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 04:46:58 -0700 (PDT) Sender: Andrey Zonov Message-ID: <50658E2E.5010602@FreeBSD.org> Date: Fri, 28 Sep 2012 15:46:54 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andre Oppermann References: <505AC500.6060903@FreeBSD.org> <505F2C2D.5050904@FreeBSD.org> <50634F85.50901@networx.ch> In-Reply-To: <50634F85.50901@networx.ch> X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3043F80B35A7FB0F99E87D09" X-Gm-Message-State: ALoCoQmOaZyb1KnJ6rCLhUsA5Ai4AdmEO2+6+qZYun3C6pXR123/YpxW59u6W0X+cVXeEO84vSyR Cc: "freebsd-net@freebsd.org" , "Eggert, Lars" Subject: Re: [patch] sysctls for TCP timers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Sep 2012 11:47:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3043F80B35A7FB0F99E87D09 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/26/12 10:55 PM, Andre Oppermann wrote: > On 23.09.2012 17:35, Andrey Zonov wrote: >> On 9/20/12 11:35 AM, Eggert, Lars wrote: >>> Hi, >>> >>> On Sep 20, 2012, at 9:25, Andrey Zonov wrote: >>>> Some of them may be read google's article about tuning TCP parameter= s >>>> [1]. I convert most of TCP timers to sysctls [2] and we are using t= his >>>> patch for few months. We tuned net.inet.tcp.rtobase and >>>> net.inet.tcp.syncache.rexmttime and it gives good results >>>> (especially in >>>> conjunction with cc_htcp(4)). >>> >>> can you share some measurements that quantify the results? >>> >> >> When we set net.inet.tcp.syncache.rexmttime=3D200 and >> net.inet.tcp.syncache.rexmtlimit=3D7 for our external web service, the= >> number of duplicated SYN was reduced in four times. >=20 > This isn't surprising. You're simply trading retransmits by the client= > with retransmits by the server. Whether this is within the overall pac= ket > conservation principle is not clear. On the timeline it may be an > advantage. >=20 This is great improvement for us. 2% of our users don't wait for 3 seconds any more. > I'm not comfortable with the rather low retransmit time you've chosen > here. Considering higher RTT's (e.g. Hawaii or JP/CN) and the bufferbl= oat > problem this may be too low. When it is to be tuned, then something in= the > range of 500-1000ms may be more realistic to avoid spurious retransmits= =2E >=20 For example Linux some time ago set RTO to 1 sec. OSX for a long time has RTO 1 sec. > When a SYN or SYN/ACK retransmit happens, the initial CWND should be > reduced > per the applicable RFC's as this indicates packet loss on the downstrea= m. >=20 --=20 Andrey Zonov --------------enig3043F80B35A7FB0F99E87D09 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.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQZY4wAAoJEBWLemxX/CvTaIsIAIGxsw4aWCYF+1CuLXkNrIgP K5KPjeIKSo7Um+jJNUAz8hFxepbEf3Y4AFGY2Y98NQHCJKxHi+bUmNZrC3Svs6CV 1MdUEeDGjSp9k9Ef5zrZaWzKhmzQPlxZ+DtamksMOzM03OWD0cIqixP/2UNr2/C/ 9JlcEOJpER2AlRxyJ+8+6bWJH33RDBF7C4vZcCDSfxjsvBhwWOGScMhuqh69Xmef /ixU8uYRGOWZaw3T1tv6oItChBOaSjF+Wv8VBpkt82uFswccHLfRmvAor7Lu/IoZ ASg5/1l1TLAbttRw9zMiAQHWyPQtVbjI3xqwilK6QMvzTESoBtX35sO1PXe5tKo= =MT2u -----END PGP SIGNATURE----- --------------enig3043F80B35A7FB0F99E87D09-- From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 12:48:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C5A7106564A for ; Fri, 28 Sep 2012 12:48:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 616FE8FC12 for ; Fri, 28 Sep 2012 12:48:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AD845B949; Fri, 28 Sep 2012 08:48:36 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 28 Sep 2012 08:35:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <201209270853.31318.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201209280835.56684.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Sep 2012 08:48:36 -0400 (EDT) Cc: Marcin Cieslak Subject: Re: enc(4) uninitialized in -current? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Sep 2012 12:48:37 -0000 On Thursday, September 27, 2012 9:02:59 am Marcin Cieslak wrote: > >> John Baldwin wrote: > > On Wednesday, September 26, 2012 6:42:19 pm Garrett Cooper wrote: > >> On Wed, Sep 26, 2012 at 3:33 PM, Olivier Cochard-Labb=C3=A9 > >> wrote: > >> > On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak = wrote: > >> >> I have just updated by 9.0-something laptop to 10.0-CURRENT r240948 > >> >> and it very quickly panics after enabling network with IPsec > >> >> (I am using IPsec w/racoon for IPv4 over 802.11, also using > >> >> tunelled IPv6). > >> > > >> > I don't know if it's related, but one of the first dmesg message > >> > displayd on my -current (rev 240921) is: > >> > > >> > module_register: module enc already exists! > >> > Module enc failed to register: 17 > > > > I suspect this is the root cause and that the "wrong" global variable i= s being=20 > > used in ipsec_output.c due to duplicate symbols. >=20 > As the original poster: I don't have this "module enc already exists!" me= ssage. > I have had "device enc" in the kernel config file and I didn't try > to load if_enc as module. I have IPSEC permanently enabled > in the kernel and it is initialized at boot with setkey and later > with racoon.=20 >=20 > > OTOH, have you created an enc0 device? I can't find anything that=20 > > automatically creates it. >=20 > No. Previously, in 9.x times, it was always present in the ifconfig outpu= t. Ok, I think that is the root cause. HEAD should still be creating an enc0. The enc.c file creates an enc_clone= r: IFC_SIMPLE_DECLARE(enc, 1); static int enc_modevent(module_t mod, int type, void *data) { switch (type) { case MOD_LOAD: mtx_init(&enc_mtx, "enc mtx", NULL, MTX_DEF); if_clone_attach(&enc_cloner); break; That '1' is the minimum number of interfaces to create on attach in ifc_simple_attach(). I've no idea why enc0 isn't being created on boot, but it should be. =2D-=20 John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Sep 28 15:56:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F374D1065673 for ; Fri, 28 Sep 2012 15:56:56 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id BC10B8FC0C for ; Fri, 28 Sep 2012 15:56:56 +0000 (UTC) Received: from [10.10.1.32] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id q8SFum2m001632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 28 Sep 2012 11:56:49 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Sep 2012 09:56:50 -0600 References: <3A359B33-380C-4230-A62C-623765E9376A@jnielsen.net> To: freebsd-net@freebsd.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) X-Mailer: Apple Mail (2.1498) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1117; Body=1 Fuz1=1 Fuz2=1 X-Virus-Scanned: clamav-milter 0.97.5 at ns1.jnielsen.net X-Virus-Status: Clean Subject: Fwd: using ConnectX card as Ethernet (mlxen) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Sep 2012 15:56:57 -0000 No takers on -current, anyone on -net know how to do this? Begin forwarded message: > From: John Nielsen > Subject: using ConnectX card as Ethernet (mlxen) > Date: September 24, 2012 10:37:30 AM MDT > To: freebsd-current@freebsd.org >=20 > I have a machine running "FreeBSD 10.0-CURRENT #0 r240887" amd64 with = two ConnectX (InfiniBand) cards. Relevant bits of dmesg and pciconf -lv = below. The cards are connected directly to a 10GB Ethernet switch so I = need to run them in "eth" mode rather than "ib". Unfortunately they come = up in "ib" mode and I don't know how to change it. >=20 > The same hardware works fine under CentOS 6.3, though I need to = manually set the cards to 'eth' there as well (which I do using a = 'connectx_port_config script from Mellanox that twiddles the mlx4_port1 = entries under /sys (sysfs). Under FreeBSD I see these sysctls but I = can't set them to 'eth' either via /boot/loader.conf or by sysctl after = boot, with or without mlxen and/or mlx4ib loaded: > sys.device.mlx4_core0.mlx4_port1: ib > sys.device.mlx4_core1.mlx4_port1: ib >=20 > Assuming mlxen is actually supported, how do I configure the card so = it will attach? >=20 >=20 > mlx4_core0: mem = 0xdfa00000-0xdfafffff,0xdd800000-0xddffffff irq 32 at device 0.0 on pci4 > mlx4_core: Mellanox ConnectX core driver v1.0-ofed1.5.2 (August 4, = 2010) > mlx4_core: Initializing mlx4_core > mlx4_en: Mellanox ConnectX HCA Ethernet driver v1.5.2 (July 2010) > mlx4_en mlx4_core0: UDP RSS is not supported on this device. > mlx4_core1: mem = 0xdf900000-0xdf9fffff,0xdd000000-0xdd7fffff irq 42 at device 0.0 on pci7 > mlx4_core: Initializing mlx4_core >=20 > mlx4_core0@pci0:4:0:0: class=3D0x0c0600 card=3D0x002215b3 = chip=3D0x673c15b3 rev=3D0xb0 hdr=3D0x00 > vendor =3D 'Mellanox Technologies' > device =3D 'MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / = 10GigE]' > class =3D serial bus > mlx4_core1@pci0:7:0:0: class=3D0x028000 card=3D0x001715b3 = chip=3D0x100315b3 rev=3D0x00 hdr=3D0x00 > vendor =3D 'Mellanox Technologies' > device =3D 'MT27500 Family [ConnectX-3]' > class =3D network >=20 > Thanks, >=20 > JN From owner-freebsd-net@FreeBSD.ORG Sat Sep 29 06:02:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1900106566B for ; Sat, 29 Sep 2012 06:02:37 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65AB38FC12 for ; Sat, 29 Sep 2012 06:02:37 +0000 (UTC) Received: by bkcjf20 with SMTP id jf20so3208830bkc.13 for ; Fri, 28 Sep 2012 23:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=xu/NRTCx8X4uFJp3gmmr/VOwGWjqdtk1X7tAoK1x6u4=; b=l7VxeDPnPsXfGMFlXvoHXxvo7G0+IM4hi3vPF3qSP2bAkwdONErZlFgU/u+l3UQxI0 +jv66o/2+MKxMxtm5O8xLkV6kVMv3kis2lGW42dn30kql5CzIACOjf1KP5d2b4taL5s+ UvKvVQ6RuO8UBxna4NyQ23d0nHVt6ladZAvxPg1Tr9dw6Oyz26HoM/Y8F2PTzjrz5rKq /AmBQq9keTdYonphzmF222gjN8E4Ma16eboBJBqTyMqyz7NyWD9XhAQ+joIzU//KiH7I SL/fkUHHJKOqmubtWQWmZMtFssYHAwX26tbVfx3yPmV6qw6ObPd0wiDNRHBZBq79y+c8 U9cw== Received: by 10.204.10.74 with SMTP id o10mr4630381bko.9.1348898556081; Fri, 28 Sep 2012 23:02:36 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id e3sm6832016bks.7.2012.09.28.23.02.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Sep 2012 23:02:35 -0700 (PDT) Message-ID: <50668EEF.1070902@gmail.com> Date: Sat, 29 Sep 2012 09:32:23 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Rudy References: <5060884C.3050709@monkeybrains.net> <506154C7.3040209@sepehrs.com> <50615F6F.1070105@monkeybrains.net> <50616D5C.705@gmail.com> <50649457.4050701@monkeybrains.net> <50649633.2090307@monkeybrains.net> In-Reply-To: <50649633.2090307@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ping: sendto: No buffer space available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Sep 2012 06:02:38 -0000 On 9/27/2012 9:38 PM, Rudy wrote: > On 09/27/2012 11:00 AM, Rudy wrote: >> Rebooting and/or the settings change seems to have stopped the errors. >> Here is a pretty little graph showing error rate on em1 for the past 3 >> days. >> >> http://www.monkeybrains.net/images/ErrorRate-em1.png >> > > Interesting... if I zoom in on the graph, I see the errors were 'every other sample period' until I rebooted the box. > > http://www.monkeybrains.net/images/ErrorRate-em1-zoom.png > > > How much traffic (bytes/s and packets/s) and of what type is passing through this box?