From owner-freebsd-net@FreeBSD.ORG Sun Nov 6 12:02:06 2011 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 C7F47106568E for ; Sun, 6 Nov 2011 12:02:06 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4DC8FC2C for ; Sun, 6 Nov 2011 12:02:05 +0000 (UTC) Received: (qmail 14066 invoked from network); 6 Nov 2011 13:02:04 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Nov 2011 13:02:04 +0100 Message-ID: <1320580923.19667.65.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: Rick Macklem Date: Sun, 06 Nov 2011 13:02:03 +0100 In-Reply-To: <1893638131.1215459.1320505430915.JavaMail.root@erie.cs.uoguelph.ca> References: <1893638131.1215459.1320505430915.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 12:02:06 -0000 Hi! Am Samstag, den 05.11.2011, 11:03 -0400 schrieb Rick Macklem: > try typing: > # sysctl dev.re.0.stats=1 > - this will dump out the stats on the chip > if the "Rx missed frames" count is non-zero, you're probably snookered, > to put it technically:-) > - That's what I get for a re chip is this laptop and I haven't found > a way around it. I just live with flakey net performance. Rx missed frames is >0 indeed. Every time I see those drops in speed the number of missed frames increases by approx. 20-50. When searching for this problem I found your old thread on freebsd-current[1]. It seems that the problem is way less severe here. Some transfers even don't cause any problems. Others however spend more time at 0kbit/s than actually transferring data... It also seems like transfers are stabilizing after some seconds but that is not always the case. In good times the rate of missed frames is below 0.01%. I think the Dup ACKs are just a result of these lost packages. I do not see them always when these problems occur. Was there any progress after your last mail on 8th of Nov.? Greetings, Michael [1]: http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020793.html http://lists.freebsd.org/pipermail/freebsd-current/2010-November/020797.html From owner-freebsd-net@FreeBSD.ORG Sun Nov 6 15:08:36 2011 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 7EEC7106566C for ; Sun, 6 Nov 2011 15:08:36 +0000 (UTC) (envelope-from crest@informatik.uni-bremen.de) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by mx1.freebsd.org (Postfix) with ESMTP id 0E41E8FC12 for ; Sun, 6 Nov 2011 15:08:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pA4CCbYb019432 for ; Fri, 4 Nov 2011 13:12:40 +0100 (CET) Received: from t420.crest.dn42 (unknown [134.102.49.124]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6A4EE278 for ; Fri, 4 Nov 2011 13:12:37 +0100 (CET) Message-ID: <4EB3D6B5.4090608@informatik.uni-bremen.de> Date: Fri, 04 Nov 2011 13:12:37 +0100 From: Crest User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111011 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 9-RC1, openbgpd, tcp md5 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, 06 Nov 2011 15:08:36 -0000 On 04.11.2011 11:13, Borja Marcos wrote: > Hi > > I'm testing a set up for OpenBGPd with FreeBSD 9-RC1 (amd64). For now I'm trying on two virtual machines. Using the stock GENERIC kernel it works, although of course it doesn't have TCP MD5 support, which I require. > > I've compiled new kernels with the TCP MD5 support (options IPSEC, device crypto and options TCP_SIGNATURE), and after installing it on both machines OpenBGPd no longer works. No matter if I try to configure the bgp sessions with TCP-MD5 or not, the sessions won't work. > > Any ideas? As far as I know, this shoud work. The daemon is complaning that there's no kernel support for pf_key. > > > FreeBSD pruebazfs3 9.0-RC1 FreeBSD 9.0-RC1 #10: Fri Nov 4 10:32:41 UTC 2011 borjam@pruebazfs1:/usr/obj/rpool/newsrc/src/sys/GENERIC amd64 Afaik you have to set the TCP-MD5 key with setkey (from security/ipsec-tools) on FreeBSD. Try removing your TCP-MD5 parameters from bgpd.conf. From owner-freebsd-net@FreeBSD.ORG Sun Nov 6 15:49:58 2011 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 D5405106566C for ; Sun, 6 Nov 2011 15:49:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 92EA68FC13 for ; Sun, 6 Nov 2011 15:49:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkGAASstk6DaFvO/2dsb2JhbABChHqVa5A2gXIBAQEBAwEBASArIAsbGAICDRkCKQEJJg4CBQQBHASHaaJ2kHiBMIZlgRYEiAuJeYIdkgo X-IronPort-AV: E=Sophos;i="4.69,464,1315195200"; d="scan'208";a="144387754" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 06 Nov 2011 10:49:57 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A4D17B3F8F; Sun, 6 Nov 2011 10:49:57 -0500 (EST) Date: Sun, 6 Nov 2011 10:49:57 -0500 (EST) From: Rick Macklem To: bevan@bi-co.net Message-ID: <1699972836.1240239.1320594597659.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1320580923.19667.65.camel@bevan-pc.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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, 06 Nov 2011 15:49:59 -0000 Michael wrote: > Hi! > > Am Samstag, den 05.11.2011, 11:03 -0400 schrieb Rick Macklem: > > try typing: > > # sysctl dev.re.0.stats=1 > > - this will dump out the stats on the chip > > if the "Rx missed frames" count is non-zero, you're probably > > snookered, > > to put it technically:-) > > - That's what I get for a re chip is this laptop and I haven't > > found > > a way around it. I just live with flakey net performance. > > Rx missed frames is >0 indeed. Every time I see those drops in speed > the > number of missed frames increases by approx. 20-50. > > When searching for this problem I found your old thread on > freebsd-current[1]. It seems that the problem is way less severe here. > Some transfers even don't cause any problems. Others however spend > more > time at 0kbit/s than actually transferring data... > It also seems like transfers are stabilizing after some seconds but > that > is not always the case. > In good times the rate of missed frames is below 0.01%. > > I think the Dup ACKs are just a result of these lost packages. I do > not > see them always when these problems occur. > > Was there any progress after your last mail on 8th of Nov.? > Nope. For my case, when Rx frames are missed, there is a Fifo overflow reported. I'm no hardware guy, but my understanding is that, sometimes, the dma engine transferring data to the receive buffers doesn't keep up and the fifo fills up. I did try assorted hacks on the driver, but none of them got rid of the problem. For my case the combination of these two things did reduce the # of Rx packets missed, but not down to 0. - disable msi interrupts (there's an option in the driver) - comment out the few lines of code that disabled/re-enabled interrupts (I don't think this code is broken, but for some reason, leaving the interrupts enabled reduced the # of Rx missed for this laptop. Maybe the dma engine stops running when interrupts are being switched on/off? Just pure conjecture, of course.) Also, only both of the above together made a difference. Each one individually didn't help. I heard that there was a driver for BSD out there somewhere that puts all the Realtek chips in 8139 compatible mode and drives them that way, but I never even gotten as far as searching for this driver. Good luck with it, rick > Greetings, > Michael > > [1]: > http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020793.html > http://lists.freebsd.org/pipermail/freebsd-current/2010-November/020797.html > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Nov 6 17:30:04 2011 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 0A7C11065672 for ; Sun, 6 Nov 2011 17:30:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B24658FC0C for ; Sun, 6 Nov 2011 17:30:03 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so3566718vcb.13 for ; Sun, 06 Nov 2011 09:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XkeyrlbKmDeWFtI6lrcCPG8oDIXGkQHRSD9kWtK3q4E=; b=EtjnZbyjT55a6xorfKAnfnjwtQjSeLdPmMABQORrXtSgSlWHqWoI8IiMD2HNrD3X/D 6lzbq+O6W7WxSWxN221Ykq355WnV4vV7tcVC7z9n/FLlkqF8Xs4GZza/vDK0gs0jUZHL tJBnliWJcswbjfpl70e+BT6y79SXXsfN79Wt8= MIME-Version: 1.0 Received: by 10.52.24.102 with SMTP id t6mr23047323vdf.106.1320600602819; Sun, 06 Nov 2011 09:30:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Sun, 6 Nov 2011 09:30:02 -0800 (PST) In-Reply-To: <1699972836.1240239.1320594597659.JavaMail.root@erie.cs.uoguelph.ca> References: <1320580923.19667.65.camel@bevan-pc.fritz.box> <1699972836.1240239.1320594597659.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 6 Nov 2011 09:30:02 -0800 X-Google-Sender-Auth: iNK55c96gaBHMbZ9mRV4L4u33rA Message-ID: From: Adrian Chadd To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, bevan@bi-co.net Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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, 06 Nov 2011 17:30:04 -0000 Hi, You've triggered off a little memory cell deep in my ath(4) 11n hacking. I saw similar issues with TX/RX interrupt handling and fifo underrun/overrun/timeouts. It turns out there were bugs in the interrupt handling code. :-) Someone who can read the driver and/or has access to the datasheets should check to make sure that interrupt disable/enable: * Doesn't clear the RX interrupt condition. Ie, if you disable interrupts and an RX interrupt status occurs, then when you re-enable it, it should _immediately_ trigger another interrupt rather then waiting for the next interrupt to occur; * Whether MSI is doing the same thing. This has me a little concerned. Ie, given the trouble people have with e1000 and MSI, I wonder if there's either a bug in the interrupt handling in both cases, or whether we're doing something "wrong" with MSI interrupts that show up under network load. I'm CC'ing jhb@ so he may provide some helpful hints on how legacy/MSI interrupts are expected to work in this instance. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Nov 6 23:43:02 2011 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 60175106566C for ; Sun, 6 Nov 2011 23:43:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D8128FC0A for ; Sun, 6 Nov 2011 23:43:01 +0000 (UTC) Received: by gyd5 with SMTP id 5so4936818gyd.13 for ; Sun, 06 Nov 2011 15:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=sSCv0ITWIen+S4hymIbp59NAezYdb0AHlshu5Bw4bQU=; b=TboVBB6vsJB2nBaN8r3p2RKKLyMO6hlemfzTAuECh1ve+I2so+nx04LfN9g5+RA2fV nFkqt5pmTGoQi6yv7/y4DWsUX/yAGp+es5D7lRFBK+3QN2yR4AD06g/H9YF863J4ryqk UPWJHcJDpwxiVrSXrdh7az06qKW2nMHeHVGds= Received: by 10.50.169.99 with SMTP id ad3mr37737432igc.6.1320622981318; Sun, 06 Nov 2011 15:43:01 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p10sm30728701pbd.15.2011.11.06.15.42.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 15:43:00 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 06 Nov 2011 15:40:54 -0800 From: YongHyeon PYUN Date: Sun, 6 Nov 2011 15:40:54 -0800 To: Michael =?iso-8859-1?B?TGHf?= Message-ID: <20111106234054.GB1906@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1320494003.19667.41.camel@bevan-pc.fritz.box> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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: Sun, 06 Nov 2011 23:43:02 -0000 On Sat, Nov 05, 2011 at 12:53:23PM +0100, Michael La?? wrote: > Hi! > > I've got a small NAS with Intel D525MW (Atom) board inside using FreeBSD > 9.0-RC1 as operating system. It has an onboard Realtek 8111E ethernet > adapter. I'm experiencing heavy performance problems when transfering > files from a specific PC in my network to that NAS. I did the following > tests by transfering large amount of data between the diferrent machines > (using dd and nc): > > NAS -> Linux1: ~ 400Mbit/s > NAS -> Linux2: ~ 400Mbit/s > Linux1 -> NAS: heavy fluctuation, between 700Mbit/s and 0bit/s > Linux2 -> NAS: ~ 400Mbit/s > Linux1 -> Linux2: ~ 400Mbit/s > Linux2 -> Linux1: ~ 400Mbit/s > > As you can see everythink works fine except for transfering data from > Linux1 to that NAS box. The following graph shows the problem: > http://dl.dropbox.com/u/25455527/network-problems.png > > While the transfer rate drops to zero the NAS also has a very bad ping > up to one second. Ping of Linux1 is perfectly fine during these outages. > > I also had a quick look on the data stream with wireshark on Linux1 and > it shows a lot of TCP Dup ACK (up to 263 Dup ACKs created by NAS for one > frame). > > What can be eliminated as a cause is: > - Switch (I tried connecting Linux1 and NAS directly) > - Cable (I changed that a few times) > - Harddisk I/O (I'm only writing from /dev/zero to /dev/null) > > The sevirity of that problem varies from one minute to another but can > always be reproduced with a few tries. > > When limiting either NAS or Linux1 to 100Mbit I'm getting a steady > transfer rate of about 90Mbit/s. Some revisions of RealTek controller have FIFO overrun issue but I'm not sure whether you're seeing the issue. Try enabling flow control and see whether that makes any difference. You can enable it by issuing 'ifconfig re0 media flow'. > When decreasing the MTU on NAS to 1200 the problem seems to disappear, > getting a transfer rate of about 160Mbit/s. > > ifconfig re0: > > re0: flags=8843 metric 0 mtu 1500 > > options=388b > > ether 38:60:77:3e:af:a5 > > inet 192.168.178.54 netmask 0xffffff00 broadcast 192.168.178.255 > > nd6 options=29 > > media: Ethernet autoselect (1000baseT ) > > status: active > > pciconf -lv: > > re0@pci0:1:0:0: class=0x020000 card=0xd6258086 chip=0x816810ec rev=0x06 hdr=0x00 > > vendor = 'Realtek Semiconductor Co., Ltd.' > > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > > class = network > > subclass = ethernet > Show me the dmesg output. RealTek uses the same device PCI ids so it's impossible to know which controller you have from the pciconf(8) output. > Because Linux1 seems to be involved in that problem: It's running Linux > 3.0 and it has an "Atheros Communications AR8121/AR8113/AR8114" onboard. > > Does anyone have an idea what could be the problem here? Decreasing the > MTU is some kind of solution but the performance is still not optimal > and a MTU of 1500 should be no problem. > > Greetings, > Michael Laß From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 10:04:37 2011 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 9B41C106566B for ; Mon, 7 Nov 2011 10:04:37 +0000 (UTC) (envelope-from przemyslaw@frasunek.com) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 22BC68FC0A for ; Mon, 7 Nov 2011 10:04:37 +0000 (UTC) Received: from [IPv6:2a02:2928:a:ffff:d179:25c5:30fe:e6e2] (unknown [IPv6:2a02:2928:a:ffff:d179:25c5:30fe:e6e2]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id C66DE239453 for ; Mon, 7 Nov 2011 11:04:32 +0100 (CET) Message-ID: <4EB7AD2A.5050002@frasunek.com> Date: Mon, 07 Nov 2011 11:04:26 +0100 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: dummynet damages ICMPv6 packets 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, 07 Nov 2011 10:04:37 -0000 Hello, we are experiencing interesing behaviour of dummynet enabled on IPv6 interfaces. When the following rules are added: add pipe 24 ip from any to any in recv vlan1 add pipe 25 ip from any to any out xmit vlan1 all ICMPv6 packets passing on vlan1 are being damaged: 10:55:53.180801 IP6 fe80::215:17ff:feae:4d99 > ff02::1: ip-proto-64 16 0x0000: 6000 0000 0010 403a fe80 0000 0000 0000 `.....@:........ 0x0010: 0215 17ff feae 4d99 ff02 0000 0000 0000 ......M......... 0x0020: 0000 0000 0000 0001 8000 2dc9 31f2 002e ..........-.1... 0x0030: 4eb7 ab29 0002 c207 N..).... Please note invalid protocol shown by tcpdump and shifted bytes at offset 7 and 8 (it reads 0x403a but should be 0x3a40). After changing dummynet rule to: add pipe 24 ip4 from any to any in recv vlan1 add pipe 25 ip4 from any to any out xmit vlan1 packets are no longer malformed: 11:01:49.934348 IP6 fe80::215:17ff:feae:4d99 > ff02::1: ICMP6, echo request, seq 0, length 16 0x0000: 6000 0000 0010 3a40 fe80 0000 0000 0000 `.....:@........ 0x0010: 0215 17ff feae 4d99 ff02 0000 0000 0000 ......M......... 0x0020: 0000 0000 0000 0001 8000 ab9a 3341 0000 ............3A.. 0x0030: 4eb7 ac8d 000e 41a5 N.....A. The above problem affects 8.2-STABLE compiled on 3rd May 2011. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 11:07:16 2011 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 2C1731065678 for ; Mon, 7 Nov 2011 11:07:16 +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 1A0758FC15 for ; Mon, 7 Nov 2011 11:07:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA7B7G91078749 for ; Mon, 7 Nov 2011 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA7B7Ful078747 for freebsd-net@FreeBSD.org; Mon, 7 Nov 2011 11:07:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Nov 2011 11:07:15 GMT Message-Id: <201111071107.pA7B7Ful078747@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, 07 Nov 2011 11:07:16 -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/162201 net [ip] [patch] multicast forwarding cache hash always al 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/161908 net [netgraph] [patch] ng_vlan update for QinQ support o kern/161899 net [route] ntpd(8): Repeating RTM_MISS packets causing hi 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/160420 net [msk] phy write timeout on HP 5310m 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/159795 net [tcp] excessive duplicate ACKs and TCP session freezes 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/157429 net [re] Realtek RTL8169 doesn't work with re(4) 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/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/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/155004 net [bce] [panic] kernel panic in bce0 driver 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 o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u 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 bin/145934 net [patch] add count option to netstat(1) 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 o kern/144572 net [carp] CARP preemption mode traffic partially goes to 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 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/138620 net [lagg] [patch] lagg port bpf-writes blocked 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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/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 s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if 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 s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress 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 o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 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 s 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 380 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 06:34:41 2011 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 1C306106564A for ; Mon, 7 Nov 2011 06:34:41 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f284.mail.ru (f284.mail.ru [217.69.138.184]) by mx1.freebsd.org (Postfix) with ESMTP id 6C2F18FC12 for ; Mon, 7 Nov 2011 06:34:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=gFv8upI8Eylh+VlgfgHzg9HKUfnWuw8chQP74jbUA8k=; b=oowBgW1FtVzijd8DuheSXdV5UOgjBFEX+uO0MVxQEX00n9R9uzBlz8DDOXg/7DMQB8kdfMFp/Z8FXDAwn3eWU486twdmW/eHKwVyjJKXOQfAc5rdOC8JMxV1lFuaJJry; Received: from mail by f284.mail.ru with local id 1RNImz-0001RG-00; Mon, 07 Nov 2011 10:34:37 +0400 Received: from [77.45.132.116] by e.mail.ru with HTTP; Mon, 07 Nov 2011 10:34:37 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: =?UTF-8?B?QW5kcmV5IFpvbm92?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [77.45.132.116] Date: Mon, 07 Nov 2011 10:34:37 +0400 References: <201111021700.pA2H0MND043499@freefall.freebsd.org> In-Reply-To: <201111021700.pA2H0MND043499@freefall.freebsd.org> X-Priority: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Mon, 07 Nov 2011 12:22:51 +0000 Cc: freebsd-net@FreeBSD.org Subject: Re[2]: kern/155585: [tcp] [panic] tcp_output tcp_mtudisc loop until kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 06:34:41 -0000 SGkuIEkgdXBkYXRlZCBzeXN0ZW0gdG8gcjIyNzE0MToyMjcxNDJNIGFuZCB0cmllZCBwYXRjaC4g NiBob3VycyB1cHRpbWUgcmlnaHQgbm93LiBCdWcgbG9va3MgZml4ZWQuCgoKMDIg0L3QvtGP0LHR gNGPIDIwMTEsIDIxOjAxINC+0YIgQW5kcmV5IFpvbm92IDxhbmRyZXlAem9ub3Yub3JnPjoKPiBU aGUgZm9sbG93aW5nIHJlcGx5IHdhcyBtYWRlIHRvIFBSIGtlcm4vMTU1NTg1OyBpdCBoYXMgYmVl biBub3RlZCBieSBHTkFUUy4KPiAKPiBGcm9tOiBBbmRyZXkgWm9ub3YgPGFuZHJleUB6b25vdi5v cmc+Cj4gVG86IGJ1Zy1mb2xsb3d1cEBGcmVlQlNELm9yZywgc2Ftc3BlZWRAbWFpbC5ydQo+IENj Ogo+IFN1YmplY3Q6IFJlOiBrZXJuLzE1NTU4NTogW3RjcF0gW3BhbmljXSB0Y3Bfb3V0cHV0IHRj cF9tdHVkaXNjIGxvb3AgdW50aWwKPiAga2VybmVsIHBhbmljCj4gRGF0ZTogV2VkLCAwMiBOb3Yg MjAxMSAyMDo1NDoxNSArMDQwMAo+IAo+ICBUaGlzIGlzIGEgbXVsdGktcGFydCBtZXNzYWdlIGlu IE1JTUUgZm9ybWF0Lgo+ICAtLS0tLS0tLS0tLS0tLTA0MDUwMTA5MDkwNTA2MDYwNjAxMDcwOAo+ ICBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTg7IGZvcm1hdD1mbG93ZWQK PiAgQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAo+IAo+ICBIaSBBbmRyZXksCj4gCj4g IFBsZWFzZSB0cnkgYXR0YWNoZWQgcGF0Y2guCj4gCj4gIEkgdGhpbmsgdGhlIHNhbWUgcHJvYmxl bSB3YXMgcmVzb2x2ZWQgaGVyZSBbMV0uCj4gCj4gIFsxXSBodHRwOi8vc3Zud2ViLmZyZWVic2Qu b3JnL2Jhc2U/dmlldz1yZXZpc2lvbiZyZXZpc2lvbj0xNzgwMjkKPiAKPiAgLS0KPiAgQW5kcmV5 IFpvbm92Cj4gCj4gIC0tLS0tLS0tLS0tLS0tMDQwNTAxMDkwOTA1MDYwNjA2MDEwNzA4Cj4gIENv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsKPiAgIG5hbWU9InBhdGNoLXRjcF9vdXRwdXQuYy50eHQi Cj4gIENvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NAo+ICBDb250ZW50LURpc3Bvc2l0 aW9uOiBhdHRhY2htZW50Owo+ICAgZmlsZW5hbWU9InBhdGNoLXRjcF9vdXRwdXQuYy50eHQiCj4g Cj4gIFNXNWtaWGc2SUhONWN5OXVaWFJwYm1WMEwzUmpjRjl2ZFhSd2RYUXVZd285UFQwOVBUMDlQ VDA5UFQwOVBUMDlQVDA5UFQwOQo+ICBQVDA5UFQwOVBUMDlQVDA5UFQwOVBUMDlQVDA5UFQwOVBU MDlQVDA5UFQwOVBUMDlQVDA5UFQwOVBUMDlDaTB0TFNCemVYTXYKPiAgYm1WMGFXNWxkQzkwWTNC ZmIzVjBjSFYwTG1NSktISmxkbWx6YVc5dUlESXlOekF5TUNrS0t5c3JJSE41Y3k5dVpYUnBibVYw Cj4gIEwzUmpjRjl2ZFhSd2RYUXVZd2tvZDI5eWEybHVaeUJqYjNCNUtRcEFRQ0F0TVRjM0xEZ2dL ekUzTnl3NUlFQkFDaUFKYVc1MAo+ICBJR2xrYkdVc0lITmxibVJoYkc5ME93b2dDV2x1ZENCellX TnJYM0o0YldsMExDQnpZV05yWDJKNWRHVnpYM0o0YlhRN0NpQUoKPiAgYzNSeWRXTjBJSE5oWTJ0 b2IyeGxJQ3B3T3dvdENXbHVkQ0IwYzI4N0Npc0phVzUwSUhSemJ5d2diWFIxTENCdlptWmxjanNL Cj4gIElBbHpkSEoxWTNRZ2RHTndiM0IwSUhSdk93b3JDWE4wY25WamRDQnliM1YwWlNCeWJ6c0tJ Q05wWmlBd0NpQUphVzUwSUcxaAo+ICBlR0oxY25OMElEMGdWRU5RWDAxQldFSlZVbE5VT3dvZ0ky VnVaR2xtQ2tCQUlDMHlNVGdzTmlBck1qRTVMRGNnUUVBS0lBa0oKPiAgZEdOd1gzTmhZMnRmWVdS cWRYTjBLSFJ3S1RzS0lBbHpaVzVrWVd4dmRDQTlJREE3Q2lBSmRITnZJRDBnTURzS0t3bHRkSFVn Cj4gIFBTQXdPd29nQ1c5bVppQTlJSFJ3TFQ1emJtUmZibmgwSUMwZ2RIQXRQbk51WkY5MWJtRTdD aUFKYzJWdVpIZHBiaUE5SUcxcAo+ICBiaWgwY0MwK2MyNWtYM2R1WkN3Z2RIQXRQbk51WkY5amQy NWtLVHNLSUFwQVFDQXRNVEl6TVN3NUlDc3hNak16TERFMklFQkEKPiAgQ2lBSmFXWWdLRlpmY0dG MGFGOXRkSFZmWkdselkyOTJaWEo1SUNZbUlIUndMVDUwWDIxaGVHOXdaQ0ErSUZaZmRHTndYMjFw Cj4gIGJtMXpjeWtLSUFrSmFYQXRQbWx3WDI5bVppQjhQU0JKVUY5RVJqc0tJQW90Q1dWeWNtOXlJ RDBnYVhCZmIzVjBjSFYwS0cwcwo+ICBJSFJ3TFQ1MFgybHVjR05pTFQ1cGJuQmZiM0IwYVc5dWN5 d2dUbFZNVEN3S0t3bGllbVZ5YnlnbWNtOHNJSE5wZW1WdlppaHkKPiAgYnlrcE93b3JDaXNKWlhK eWIzSWdQU0JwY0Y5dmRYUndkWFFvYlN3Z2RIQXRQblJmYVc1d1kySXRQbWx1Y0Y5dmNIUnBiMjV6 Cj4gIExDQW1jbThzQ2lBSklDQWdJQ2dvYzI4dFBuTnZYMjl3ZEdsdmJuTWdKaUJUVDE5RVQwNVVV azlWVkVVcElEOGdTVkJmVWs5Vgo+ICBWRVZVVDBsR0lEb2dNQ2tzSURBc0NpQUpJQ0FnSUhSd0xU NTBYMmx1Y0dOaUtUc0tLd29yQ1dsbUlDaGxjbkp2Y2lBOVBTQkYKPiAgVFZOSFUwbGFSU0FtSmlC eWJ5NXliMTl5ZENrS0t3a0piWFIxSUQwZ2NtOHVjbTlmY25RdFBuSjBYM0p0ZUM1eWJYaGZiWFIx Cj4gIE93b3JDV2xtSUNoeWJ5NXliMTl5ZENrS0t3a0pVbFJHVWtWRktISnZMbkp2WDNKMEtUc0tJ Q0FnSUNCOUNpQWpaVzVrYVdZZwo+ICBMeW9nU1U1RlZDQXFMd29nQ1dsbUlDaGxjbkp2Y2lrZ2V3 cEFRQ0F0TVRJM09Td3lNaUFyTVRJNE9Dd3lNQ0JBUUFvZ0NRa0oKPiAgTHlvS0lBa0pDU0FxSUVa dmNpQnpiMjFsSUhKbFlYTnZiaUIwYUdVZ2FXNTBaWEptWVdObElIZGxJSFZ6WldRZ2FXNXBkR2xo Cj4gIGJHeDVDaUFKQ1FrZ0tpQjBieUJ6Wlc1a0lITmxaMjFsYm5SeklHTm9ZVzVuWldRZ2RHOGdZ VzV2ZEdobGNpQnZjaUJzYjNkbAo+ICBjbVZrQ2kwSkNRa2dLaUJwZEhNZ1RWUlZMZ290Q1FrSklD b0tMUWtKQ1NBcUlIUmpjRjl0ZEhWa2FYTmpLQ2tnZDJsc2JDQm0KPiAgYVc1a0lHOTFkQ0IwYUdV Z2JtVjNJRTFVVlNCaGJtUWdZWE1LTFFrSkNTQXFJR2wwY3lCc1lYTjBJR0ZqZEdsdmJpd2dhVzVw Cj4gIGRHbGhkR1VnY21WMGNtRnVjMjFwYzNOcGIyNHNJSE52SUdsMENpMEpDUWtnS2lCcGN5QnBi WEJ2Y25SaGJuUWdkRzhnYm05MAo+ICBJR1J2SUhOdklHaGxjbVV1Q2kwSkNRa2dLZ290Q1FrSklD b2dTV1lnVkZOUElIZGhjeUJoWTNScGRtVWdkMlVnWldsMGFHVnkKPiAgSUdkdmRDQmhiaUJwYm5S bGNtWmhZMlVLTFFrSkNTQXFJSGRwZEdodmRYUWdWRk5QSUdOaGNHRmlhV3hwZEhNZ2IzSWdWRk5Q Cj4gIElIZGhjeUIwZFhKdVpXUWdiMlptTGdvdENRa0pJQ29nUkdsellXSnNaU0JwZENCbWIzSWdk R2hwY3lCamIyNXVaV04wYVc5dQo+ICBJR0Z6SUhSdmJ5QmhibVFLTFFrSkNTQXFJR2x0YldWa2FX RjBiSGtnY21WMGNua2dkMmwwYUNCTlUxTWdjMmw2WldRZ2MyVm4KPiAgYldWdWRITWdaMlZ1WlhK aGRHVmtDaTBKQ1FrZ0tpQmllU0IwYUdseklHWjFibU4wYVc5dUxnb3JDUWtKSUNvZ2FYUnpJRTFV Cj4gIFZTNGdWWEJrWVhSbElIUmZiV0Y0YjNCa0lHRnVaQ0IwWDIxaGVITmxaeUIwYUhKdmRXZG9D aXNKQ1FrZ0tpQjBZM0JmYlhOego+ICBYM1Z3WkdGMFpTZ3BJR0Z1WkNCMGNua2dkRzhnYzJWdVpD QmtZWFJoSUdGbllXbHVMZ29nQ1FrSklDb3ZDaTBKQ1FscFppQW8KPiAgZEhOdktRb3RDUWtKQ1hS d0xUNTBYMlpzWVdkeklDWTlJSDVVUmw5VVUwODdDaTBKQ1FsMFkzQmZiWFIxWkdsell5aDBjQzAr Cj4gIGRGOXBibkJqWWl3Z01DazdDaTBKQ1FseVpYUjFjbTRnS0RBcE93b3JDUWtKYVdZZ0tHMTBk U0FoUFNBd0tTQjdDaXNKQ1FrSgo+ICBiMlptWlhJZ1BTQnRkSFVnTFNCb1pISnNaVzQ3Q2lzSkNR a0phV1lnS0NoMGNDMCtkRjltYkdGbmN5QW1JRlJHWDFKRFZrUmYKPiAgVkZOVVRWQXBJRDA5SUZS R1gxSkRWa1JmVkZOVVRWQXBDaXNKQ1FrSkNXOW1abVZ5SUNzOUlGUkRVRTlNUlU1ZlZGTlVRVTFR Cj4gIFgwRlFVRUU3Q2lzSkNRa0pkR053WDIxemMxOTFjR1JoZEdVb2RIQXNJRzltWm1WeUxDQk9W VXhNTENCT1ZVeE1LVHNLS3drSgo+ICBDUWxuYjNSdklHRm5ZV2x1T3dvckNRa0pmUW9yQ1FrSkx5 b0tLd2tKQ1NBcUlGUm9hWE1nYVhNZ2RHaGxJR0psYzNRZ2QyVWcKPiAgWTJGdUlHUnZJR2hsY21V dUNpc0pDUWtnS2k4S0t3a0pDWEpsZEhWeWJpQW9aWEp5YjNJcE93b2dDUWxqWVhObElFVklUMU5V Cj4gIFJFOVhUam9LSUFrSlkyRnpaU0JGU0U5VFZGVk9Va1ZCUTBnNkNpQUpDV05oYzJVZ1JVNUZW RVJQVjA0NkNnPT0KPiAgLS0tLS0tLS0tLS0tLS0wNDA1MDEwOTA5MDUwNjA2MDYwMTA3MDgtLQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gZnJlZWJz ZC1uZXRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0Cj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3Jn L21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1uZXQKPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkg bWFpbCB0byAiZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciCj4g From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 08:30:48 2011 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 D9064106564A for ; Mon, 7 Nov 2011 08:30:48 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from f299.mail.ru (f299.mail.ru [217.69.129.81]) by mx1.freebsd.org (Postfix) with ESMTP id 54E598FC12 for ; Mon, 7 Nov 2011 08:30:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail; h=Message-Id:Content-Transfer-Encoding:Content-Type:Reply-To:In-Reply-To:References:Date:Mime-Version:Subject:Cc:To:From; bh=VgZBEufLolYzT2i/Fzq8ao9xZZYrd0RfdkLgJrbU7Qk=; b=2gtlY2Kg6iicEKT94y3vzgYHlBAnh7JGFRp1P95loN6c2eXqc4sAqNFscTUqN3rZy+EGwp6RqwP/X7bcsDqOz5pY/XEUzEI7uuRAiNI+gZeKk9snAIwznolMp/0gRRVN; Received: from mail by f299.mail.ru with local id 1RNKbN-0001LU-00; Mon, 07 Nov 2011 12:30:45 +0400 Received: from [77.45.132.116] by e.mail.ru with HTTP; Mon, 07 Nov 2011 12:30:45 +0400 From: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= To: =?UTF-8?B?WW9uZ0h5ZW9uIFBZVU4=?= Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [77.45.132.116] Date: Mon, 07 Nov 2011 12:30:45 +0400 References: <20111101180135.GD6914@michelle.cdnetworks.com> <20111102020532.GF6914@michelle.cdnetworks.com> In-Reply-To: <20111102020532.GF6914@michelle.cdnetworks.com> X-Priority: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Mon, 07 Nov 2011 12:23:16 +0000 Cc: freebsd-net@freebsd.org Subject: Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?B?QW5kcmV5IFNtYWdpbg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 08:30:48 -0000 CjAyINC90L7Rj9Cx0YDRjyAyMDExLCAwNjowNyDQvtGCIFlvbmdIeWVvbiBQWVVOIDxweXVueWhA Z21haWwuY29tPjoKPiBJZiB0aGVyZSBpcyBubyBjYWJsaW5nIGlzc3VlIHRoZXJlLCBwbGVhc2Ug dHJ5IGF0dGFjaGVkIHBhdGNoIGFuZAo+IGxldCBtZSBrbm93IHdoZXRoZXIgdGhlIHBhdGNoIG1h a2VzIGFueSBkaWZmZXJlbmNlIG9uIHlvdS4KPiAKPiBUaGFua3MuCj4KCkkgdHJpZWQgcGF0Y2gu IE5vdyBhdXRvbWF0aWMgY29ubmVjdGlvbiBjYW4ndCBlc3RhYmxpc2hlZC4gCkluIGRtZXNnIAp2 Z2UwOiBNSUkgcmVhZCB0aW1lZCBvdXQKLi4uLg== From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 12:54:38 2011 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 E45B41065675 for ; Mon, 7 Nov 2011 12:54:38 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 806158FC1B for ; Mon, 7 Nov 2011 12:54:38 +0000 (UTC) Received: by faar19 with SMTP id r19so7218784faa.13 for ; Mon, 07 Nov 2011 04:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=P/MI/VesfE8e5ew89slhxeikbnk8GUMQLWqjvXwaB3E=; b=Eebgk5R4fLXltdqqKwFxqsnrJ1FZINF33Ezn1T+IO28ttq7Pd6tWpZllPHlZfKYBO3 iuwe0IvuTGnHqpdmsqnMqM7afafgRmVA/edaOXUWOXwmQO3dtuVlfzot93QfORRsO18M Mv6OW3KKPFiXCRZKMTSKiQDc5dxAXgdzEmrdk= MIME-Version: 1.0 Received: by 10.152.144.73 with SMTP id sk9mr6281145lab.34.1320668786163; Mon, 07 Nov 2011 04:26:26 -0800 (PST) Received: by 10.152.9.10 with HTTP; Mon, 7 Nov 2011 04:26:26 -0800 (PST) Date: Mon, 7 Nov 2011 16:26:26 +0400 Message-ID: From: Pavel Timofeev To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Possible MROUTING regression in 9.0 RC1 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, 07 Nov 2011 12:54:39 -0000 Hello! I have problems with ip_mroute (loaded as module) - kernel multicast packet forwarder. I have 2 disk: freebsd 8.2 release amd64 on first and freebsd 9.0 rc1 on second. I use net/igmpproxy to watch IPTV on my home atom-based router. On FreeBSD 8.2 it works good. But when I try to use FreeBSD 9.0 RC-1 in same role (with same configs, of cource) I have messages like: Nov 7 16:16:46 timp igmpproxy[35495]: received packet from 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) Nov 7 16:16:47 timp igmpproxy[35495]: received packet from 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) Nov 7 16:17:28 timp igmpproxy[35495]: received packet from 10.85.13.5 shorter (28 bytes) than hdr+data length (20+28) And IPTV doesn't work =( Any ideas? Do you need configs? From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 13:31:17 2011 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 E83D6106564A; Mon, 7 Nov 2011 13:31:17 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 6B90D8FC13; Mon, 7 Nov 2011 13:31:17 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pA7DVG1T013156; Mon, 7 Nov 2011 17:31:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pA7DVGJ6013155; Mon, 7 Nov 2011 17:31:16 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2011 17:31:16 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20111107133116.GI71907@FreeBSD.org> References: <4EAF842D.3080909@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4EAF842D.3080909@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Arnaud Lacombe Subject: Re: Undocumented netgraph `cmd' flags ? 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, 07 Nov 2011 13:31:18 -0000 On Mon, Oct 31, 2011 at 10:31:25PM -0700, Julian Elischer wrote: J> NGM_HASREPLY is not used that I can see in the kernel. It may be a J> historical artifact or J> maybe only used in the library as a hint. I introduced NGM_HASREPLY. Yes, it is used in library, to make repliable messages synchronous, as they were in RELENG_4. Applications like mpd rely on that fact. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 14:23:21 2011 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 C4894106567C for ; Mon, 7 Nov 2011 14:23:21 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 439EB8FC23 for ; Mon, 7 Nov 2011 14:23:21 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pA7ENKsw013542; Mon, 7 Nov 2011 18:23:20 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pA7ENJu1013541; Mon, 7 Nov 2011 18:23:19 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 7 Nov 2011 18:23:19 +0400 From: Gleb Smirnoff To: Kristof Provost Message-ID: <20111107142319.GK71907@FreeBSD.org> References: <20111103120752.GG9553@thebe.jupiter.sigsegv.be> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111103120752.GG9553@thebe.jupiter.sigsegv.be> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, prabhakar lakhera Subject: Re: mbuf leak in icmp6 code?? 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, 07 Nov 2011 14:23:21 -0000 Kristof, On Thu, Nov 03, 2011 at 01:07:52PM +0100, Kristof Provost wrote: K> > For example: K> > K> > icmp6_input calls icmp6_redirect_input and right after it returns it K> > makes m=NULL. Inside icmp6_redirect_input there are checks for ifp and K> > for the message being short (which probably don't get exercised that K> > often (or at all?)) and for these checks simply return. Looks to be K> > mbuf leak. In other icmp6 functions also we have similar instances. K> K> The checks for m and ifp should probably be asserts, rather than just K> returns. I think they are always supposed to be true. I've checked all callers, and it looks like m and m->pkthdr.rcvif can be safely asserted. I've committed that change. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 16:46:04 2011 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 4C9E0106566B; Mon, 7 Nov 2011 16:46:04 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id A7F9F8FC0A; Mon, 7 Nov 2011 16:46:01 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNRu4-000GNl-TG; Mon, 07 Nov 2011 08:18:34 -0800 Message-ID: <4EB804D2.2090101@FreeBSD.org> Date: Mon, 07 Nov 2011 08:18:26 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , freebsd-net@FreeBSD.ORG Content-Type: multipart/mixed; boundary="------------010709080200050001090900" Sender: sobomax@sippysoft.com X-ssp-trusted: yes X-Mailman-Approved-At: Mon, 07 Nov 2011 17:09:20 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Panic in the udp_input() under heavy load 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, 07 Nov 2011 16:46:04 -0000 This is a multi-part message in MIME format. --------------010709080200050001090900 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Hi Gang, We are seeing repeatable panics under high PPS load on our production systems. It happens when the traffic gets into the range or 200MBps and 150-200K PPS. We have been managed to track it down to the following piece of code: (gdb) l *udp_input+0x5d2 0xffffffff806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628). 623 if (inp->inp_ip_minttl && inp->inp_ip_minttl > ip->ip_ttl) { 624 INP_RUNLOCK(inp); 625 goto badunlocked; 626 } 627 up = intoudpcb(inp); 628 if (up->u_tun_func == NULL) { 629 udp_append(inp, ip, m, iphlen + sizeof(struct udphdr), &udp_in); 630 } else { 631 /* 632 * Engage the tunneling protocol. The faulty line appears to be 628, with up value is being NULL, attempt to deference it causes NULL pointer exception. I believe this particular piece of code has been introduced here: --- Author: bz Date: Thu Aug 13 15:16:30 2009 New Revision: 196192 URL: http://svn.freebsd.org/changeset/base/196192 Log: MFC: r192649 Implement UDP control block support. Add udpcb support with own fields and flags for UDP instead of further sticking things into in_pcb and flags fields. Attach the udpcb to the inp_ppcb in the kernel. Note: the udp tunneling parts are not (yet) existing in 7 and thus were not merged. Reviewed by: rwatson --- The screenshot of the panic message is attached. This is pretty recent 8.2-STABLE. Any help is greatly appreciated. This particular bug has haunted us for at least 4-5 months now. Thanks! -Maxim --------------010709080200050001090900-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 17:13:59 2011 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 4A967106566B for ; Mon, 7 Nov 2011 17:13:59 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop03.sare.net (proxypop03.sare.net [194.30.0.207]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB568FC13 for ; Mon, 7 Nov 2011 17:13:58 +0000 (UTC) Received: from [172.16.2.2] (izaro.sarenet.es [192.148.167.11]) by proxypop03.sare.net (Postfix) with ESMTPSA id 7CEA19DC512; Mon, 7 Nov 2011 18:13:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Borja Marcos In-Reply-To: <20111104134139.0836f380@mr12941> Date: Mon, 7 Nov 2011 18:13:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3194E12A-1675-4369-BBB3-9B62BB1CB52E@sarenet.es> References: <20111104134139.0836f380@mr12941> To: Patrick Lamaiziere X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Patrick Lamaiziere Subject: Re: FreeBSD 9-RC1, openbgpd, tcp md5 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, 07 Nov 2011 17:13:59 -0000 =09 On Nov 4, 2011, at 1:41 PM, Patrick Lamaiziere wrote: > Isn't a new option to build openbgpd with tcp-md5 (and without = pf_key)? >=20 > I've used TCP-MD5 signature for bgp between a FreeBSD 8.x and OpenBSD, > using setkey(8) to enforce the signature between the peers. That > worked (of course, then you shouldn't use tcp-md5 in openbgd). >=20 > setkey(8): > add -4 peer1 peer2 tcp 0x1000 -A tcp-md5 "PASSWORD"; > add -4 peer2 peer1 tcp 0x1000 -A tcp-md5 "PASSWORD"; Ouch! Silly me, I assumed there was some setsockopt() option to set an = MD5 for a TCP socket. Thank you very much, working now both with both bird and openbgpd. :) = Turns out you have to delete the md5 option from the openbgpd config = file, but you need to put it (even with a bogus key) in the bird config = file. add 10.0.0.1 10.0.0.2 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; add 10.0.1.1 10.0.1.2 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; add 10.0.0.2 10.0.0.1 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; add 10.0.1.2 10.0.1.1 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; Borja. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 17:22:40 2011 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 5CDCE1065672; Mon, 7 Nov 2011 17:22:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 34F9E8FC0A; Mon, 7 Nov 2011 17:22:40 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNSu6-000Ga2-Uj; Mon, 07 Nov 2011 09:22:39 -0800 Message-ID: <4EB813D8.7020002@FreeBSD.org> Date: Mon, 07 Nov 2011 09:22:32 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , freebsd-net@FreeBSD.ORG, Jack Vogel References: <4EB804D2.2090101@FreeBSD.org> In-Reply-To: <4EB804D2.2090101@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 17:22:40 -0000 Panic screenshot is here: http://sobomax.sippysoft.com/ScreenShot859.png -Maxim From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 17:54:33 2011 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 1DF0F106564A for ; Mon, 7 Nov 2011 17:54:33 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 946C38FC13 for ; Mon, 7 Nov 2011 17:54:32 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1664207bkb.13 for ; Mon, 07 Nov 2011 09:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6WCjyQyQrgBzTqbX4Ds3xZ5TOICPHPi7MmstU1G8UF8=; b=T36Gn+kG2K1R5kItfcZeDMRnSpKWYmHTbeoBSctfIm1wiok+lhmvsR+O3BPQ66r3sh XIkCOyoQcF/SG2wWzNtHKErKUIi8U7LbKI6nESchKaFOePPN6vT2kQKrwpYBq5daFILI Olc8DJOFUA+6f3KoOmfsrPUh5uwXgXvse5s60= MIME-Version: 1.0 Received: by 10.182.227.99 with SMTP id rz3mr9463068obc.4.1320688470480; Mon, 07 Nov 2011 09:54:30 -0800 (PST) Received: by 10.182.30.164 with HTTP; Mon, 7 Nov 2011 09:54:30 -0800 (PST) In-Reply-To: <4EAE58A2.9040803@gmail.com> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> Date: Mon, 7 Nov 2011 10:54:30 -0700 Message-ID: From: Jason Wolfe To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 07 Nov 2011 17:54:33 -0000 On Mon, Oct 31, 2011 at 1:13 AM, Hooman Fazaeli wrote: > > Attached is a patch for if_em.c. It flushes interface queue when it is > full > and link is not active. Please note that when this happens, drops are > increasing > on interface and this will trigger your scripts as before. You need to > change > a little the scripts as follows: > > check interface TX status > if (interface TX seems hung) { > sleep 5 > check interface TX status > if (interface TX seems hung) { > reset the interface. > } > } > > For MULTIQUEUE, it just disables the check for link status (which is not > good). > so pls. test in non-MULTIQUEUE mode. > > The patch also contains some minor fixups to compile on 7 plus > a fix from r1.69 which addressed RX hang problem (the fix was > later removed in r1.70). I included it for Emil to give it a > try. > > Pls. let me know if you have any problems with patch. > > Hooman, Unfortunately one of the server just had a wedge event a couple hours ago with this patch. To confirm your changes should cause a recovery within the time I'm allowing, here is the current format: check interface TX status if (interface TX seems hung) { sleep 3 check packets out sleep 2 check packets out if (packets not incrementing) { reset the interface } } I bounced em0 because dropped packets incremented 1749543 to 1749708 and the interface is not incrementing packets out. 4:10AM up 6 days, 15:23, 0 users, load averages: 0.02, 0.12, 0.14 em0: flags=8843 metric 0 mtu 1500 options=219b ether X inet6 X%em0 prefixlen 64 scopeid 0x1 nd6 options=1 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=219b ether X inet6 X%em1 prefixlen 64 scopeid 0x2 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff nd6 options=3 lagg0: flags=8843 metric 0 mtu 1500 options=219b ether X inet X.X.X.X netmask 0xffffff00 broadcast X.X.X.X inet6 X%lagg0 prefixlen 64 scopeid 0x5 inet6 X prefixlen 64 autoconf nd6 options=3 media: Ethernet autoselect status: active laggproto loadbalance laggport: em0 flags=4 laggport: em1 flags=4 interrupt total rate irq3: uart1 3810 0 cpu0: timer 1147568087 2000 irq256: em0:rx 0 59779710 104 irq257: em0:tx 0 2771888652 4831 irq258: em0:link 1 0 irq259: em1:rx 0 3736828886 6512 irq260: em1:tx 0 2790566376 4863 irq261: em1:link 27286 0 irq262: mps0 395687386 689 cpu1: timer 1147559894 2000 cpu2: timer 1147559901 2000 cpu3: timer 1147559902 2000 Total 14345029891 25001 13466/4144/17610 mbufs in use (current/cache/total) 2567/2635/5202/5853720 mbuf clusters in use (current/cache/total/max) 2567/633 mbuf+clusters out of packet secondary zone in use (current/cache) 6798/554/7352/2926859 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 35692K/8522K/44214K 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 Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:2b:e5:75 60747643 0 0 11246408092 0 0 1750763 em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 4 - - - em1 1500 00:25:90:2b:e5:75 11237195776 123950 0 11344722383 0 0 545682 em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 1 - - - lagg0 1500 00:25:90:2b:e5:75 11297850142 0 0 22588666102 2296445 0 0 lagg0 1500 69.164.38.0/2 69.164.38.83 10189108030 - - 22592881776 - - - lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 24 - - 28 - - - lagg0 1500 2607:f4e8:310 2607:f4e8:310:12: 19578 - - 19591 - - - kern.msgbuf: Nov 7 04:10:06 cds1033 kernel: Interface is RUNNING and INACTIVE Nov 7 04:10:06 cds1033 kernel: em0: hw tdh = 558, hw tdt = 558 Nov 7 04:10:06 cds1033 kernel: em0: hw rdh = 889, hw rdt = 888 Nov 7 04:10:06 cds1033 kernel: em0: Tx Queue Status = 0 Nov 7 04:10:06 cds1033 kernel: em0: TX descriptors avail = 1024 Nov 7 04:10:06 cds1033 kernel: em0: Tx Descriptors avail failure = 0 Nov 7 04:10:06 cds1033 kernel: em0: RX discarded packets = 0 Nov 7 04:10:06 cds1033 kernel: em0: RX Next to Check = 889 Nov 7 04:10:06 cds1033 kernel: em0: RX Next to Refresh = 888 Nov 7 04:10:06 cds1033 kernel: em0: Link state: active Nov 7 04:10:06 cds1033 kernel: Interface is RUNNING and INACTIVE Nov 7 04:10:06 cds1033 kernel: em1: hw tdh = 837, hw tdt = 837 Nov 7 04:10:06 cds1033 kernel: em1: hw rdh = 198, hw rdt = 189 Nov 7 04:10:06 cds1033 kernel: em1: Tx Queue Status = 0 Nov 7 04:10:06 cds1033 kernel: em1: TX descriptors avail = 1021 Nov 7 04:10:06 cds1033 kernel: em1: Tx Descriptors avail failure = 0 Nov 7 04:10:06 cds1033 kernel: em1: RX discarded packets = 0 Nov 7 04:10:06 cds1033 kernel: em1: RX Next to Check = 303 Nov 7 04:10:06 cds1033 kernel: em1: RX Next to Refresh = 302 Nov 7 04:10:06 cds1033 kernel: em1: Link state: active net.inet.ip.intr_queue_maxlen: 512 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 0 dev.em.0.eee_control: 0 dev.em.0.link_irq: 1 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.link_toggles: 3 dev.em.0.device_control: 1074790984 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 558 dev.em.0.queue0.txd_tail: 558 dev.em.0.queue0.tx_irq: 2771888613 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 102 dev.em.0.queue0.rxd_tail: 101 dev.em.0.queue0.rx_irq: 59779941 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 60768005 dev.em.0.mac_stats.good_pkts_recvd: 60768005 dev.em.0.mac_stats.bcast_pkts_recvd: 60744833 dev.em.0.mac_stats.mcast_pkts_recvd: 2948 dev.em.0.mac_stats.rx_frames_64: 60744822 dev.em.0.mac_stats.rx_frames_65_127: 3491 dev.em.0.mac_stats.rx_frames_128_255: 19293 dev.em.0.mac_stats.rx_frames_256_511: 364 dev.em.0.mac_stats.rx_frames_512_1023: 35 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 3890774076 dev.em.0.mac_stats.good_octets_txd: 15295538422911 dev.em.0.mac_stats.total_pkts_txd: 11246435226 dev.em.0.mac_stats.good_pkts_txd: 11246435226 dev.em.0.mac_stats.bcast_pkts_txd: 4 dev.em.0.mac_stats.mcast_pkts_txd: 3830 dev.em.0.mac_stats.tx_frames_64: 60338532 dev.em.0.mac_stats.tx_frames_65_127: 897135811 dev.em.0.mac_stats.tx_frames_128_255: 13933787 dev.em.0.mac_stats.tx_frames_256_511: 22107540 dev.em.0.mac_stats.tx_frames_512_1023: 116374045 dev.em.0.mac_stats.tx_frames_1024_1522: 10136545511 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 3 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 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: 100 dev.em.1.flow_control: 0 dev.em.1.eee_control: 0 dev.em.1.link_irq: 27207 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.link_toggles: 3 dev.em.1.device_control: 1074790984 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: 804 dev.em.1.queue0.txd_tail: 804 dev.em.1.queue0.tx_irq: 2790571888 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 686 dev.em.1.queue0.rxd_tail: 686 dev.em.1.queue0.rx_irq: 3729597000 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: 123950 dev.em.1.mac_stats.recv_no_buff: 7063 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: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 11237327404 dev.em.1.mac_stats.good_pkts_recvd: 11237203454 dev.em.1.mac_stats.bcast_pkts_recvd: 60741559 dev.em.1.mac_stats.mcast_pkts_recvd: 2935 dev.em.1.mac_stats.rx_frames_64: 4479481614 dev.em.1.mac_stats.rx_frames_65_127: 5124633522 dev.em.1.mac_stats.rx_frames_128_255: 13228214 dev.em.1.mac_stats.rx_frames_256_511: 23321029 dev.em.1.mac_stats.rx_frames_512_1023: 74960116 dev.em.1.mac_stats.rx_frames_1024_1522: 1521578959 dev.em.1.mac_stats.good_octets_recvd: 3024997755633 dev.em.1.mac_stats.good_octets_txd: 15349574964083 dev.em.1.mac_stats.total_pkts_txd: 11344737635 dev.em.1.mac_stats.good_pkts_txd: 11344737635 dev.em.1.mac_stats.bcast_pkts_txd: 2501 dev.em.1.mac_stats.mcast_pkts_txd: 8 dev.em.1.mac_stats.tx_frames_64: 62839963 dev.em.1.mac_stats.tx_frames_65_127: 962219224 dev.em.1.mac_stats.tx_frames_128_255: 14620849 dev.em.1.mac_stats.tx_frames_256_511: 20410906 dev.em.1.mac_stats.tx_frames_512_1023: 117272600 dev.em.1.mac_stats.tx_frames_1024_1522: 10167374093 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 19749 dev.em.1.interrupts.rx_pkt_timer: 1 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: 18 hw.em.rx_hang_fixup: 0 hw.em.eee_setting: 0 hw.em.fc_setting: 0 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 Jason From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 18:02:01 2011 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 D051A1065672 for ; Mon, 7 Nov 2011 18:02:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8CA4F8FC21 for ; Mon, 7 Nov 2011 18:02:01 +0000 (UTC) Received: by qyc1 with SMTP id 1so3315196qyc.13 for ; Mon, 07 Nov 2011 10:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=MT8SutIpGnxaanPUZ727MEGoiJn4DrSQOrczU6/Lx04=; b=BNr1eVGAoox0ic1lbRF8XwbZTF27EZOq6Hbywyuqr8ci/I9aMglqOwWXD3hxyURZuz Zs8YbpCqOuHMDLjxLt8nS8xl5zITPsOP3SpaBlM7ikBa/14q55B65BezBJTwKT1DxiOp pZwd9rZT9PLGDFvCacLGBi+V9305Mn56rehjQ= Received: by 10.68.36.166 with SMTP id r6mr872670pbj.77.1320688920146; Mon, 07 Nov 2011 10:02:00 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c3sm38076460pbt.12.2011.11.07.10.01.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 10:01:58 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 07 Nov 2011 09:59:53 -0800 From: YongHyeon PYUN Date: Mon, 7 Nov 2011 09:59:53 -0800 To: Michael =?iso-8859-1?B?TGHf?= Message-ID: <20111107175953.GA1646@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20111106234054.GB1906@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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: Mon, 07 Nov 2011 18:02:02 -0000 On Sun, Nov 06, 2011 at 03:40:54PM -0800, YongHyeon PYUN wrote: > On Sat, Nov 05, 2011 at 12:53:23PM +0100, Michael La?? wrote: > > Hi! > > > > I've got a small NAS with Intel D525MW (Atom) board inside using FreeBSD > > 9.0-RC1 as operating system. It has an onboard Realtek 8111E ethernet > > adapter. I'm experiencing heavy performance problems when transfering > > files from a specific PC in my network to that NAS. I did the following > > tests by transfering large amount of data between the diferrent machines > > (using dd and nc): > > > > NAS -> Linux1: ~ 400Mbit/s > > NAS -> Linux2: ~ 400Mbit/s > > Linux1 -> NAS: heavy fluctuation, between 700Mbit/s and 0bit/s > > Linux2 -> NAS: ~ 400Mbit/s > > Linux1 -> Linux2: ~ 400Mbit/s > > Linux2 -> Linux1: ~ 400Mbit/s > > > > As you can see everythink works fine except for transfering data from > > Linux1 to that NAS box. The following graph shows the problem: > > http://dl.dropbox.com/u/25455527/network-problems.png > > > > While the transfer rate drops to zero the NAS also has a very bad ping > > up to one second. Ping of Linux1 is perfectly fine during these outages. > > > > I also had a quick look on the data stream with wireshark on Linux1 and > > it shows a lot of TCP Dup ACK (up to 263 Dup ACKs created by NAS for one > > frame). > > > > What can be eliminated as a cause is: > > - Switch (I tried connecting Linux1 and NAS directly) > > - Cable (I changed that a few times) > > - Harddisk I/O (I'm only writing from /dev/zero to /dev/null) > > > > The sevirity of that problem varies from one minute to another but can > > always be reproduced with a few tries. > > > > When limiting either NAS or Linux1 to 100Mbit I'm getting a steady > > transfer rate of about 90Mbit/s. > > Some revisions of RealTek controller have FIFO overrun issue but > I'm not sure whether you're seeing the issue. Try enabling flow > control and see whether that makes any difference. You can enable > it by issuing 'ifconfig re0 media flow'. This should be read as 'ifconfig re0 mediaopt flow'. > > > When decreasing the MTU on NAS to 1200 the problem seems to disappear, > > getting a transfer rate of about 160Mbit/s. > > > > ifconfig re0: > > > re0: flags=8843 metric 0 mtu 1500 > > > options=388b > > > ether 38:60:77:3e:af:a5 > > > inet 192.168.178.54 netmask 0xffffff00 broadcast 192.168.178.255 > > > nd6 options=29 > > > media: Ethernet autoselect (1000baseT ) > > > status: active > > > > pciconf -lv: > > > re0@pci0:1:0:0: class=0x020000 card=0xd6258086 chip=0x816810ec rev=0x06 hdr=0x00 > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > > > class = network > > > subclass = ethernet > > > > Show me the dmesg output. RealTek uses the same device PCI ids so it's > impossible to know which controller you have from the pciconf(8) > output. > > > Because Linux1 seems to be involved in that problem: It's running Linux > > 3.0 and it has an "Atheros Communications AR8121/AR8113/AR8114" onboard. > > > > Does anyone have an idea what could be the problem here? Decreasing the > > MTU is some kind of solution but the performance is still not optimal > > and a MTU of 1500 should be no problem. > > > > Greetings, > > Michael Laß From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 18:42:07 2011 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 1D621106566B; Mon, 7 Nov 2011 18:42:07 +0000 (UTC) (envelope-from bz@FreeBSD.ORG) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id C11798FC14; Mon, 7 Nov 2011 18:42:06 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id B640525D3893; Mon, 7 Nov 2011 18:24:16 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id DA056BD465E; Mon, 7 Nov 2011 18:24:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dcCsXAtP3PFX; Mon, 7 Nov 2011 18:24:14 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9C035BD4660; Mon, 7 Nov 2011 18:24:14 +0000 (UTC) Date: Mon, 7 Nov 2011 18:24:14 +0000 (UTC) From: "Bjoern A. Zeeb" To: Maxim Sobolev In-Reply-To: <4EB804D2.2090101@FreeBSD.org> Message-ID: References: <4EB804D2.2090101@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.ORG, Robert Watson , "current@freebsd.org" Subject: Re: Panic in the udp_input() under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 18:42:07 -0000 On Mon, 7 Nov 2011, Maxim Sobolev wrote: > Hi Gang, > > We are seeing repeatable panics under high PPS load on our production > systems. It happens when the traffic gets into the range or 200MBps and > 150-200K PPS. We have been managed to track it down to the following piece of > code: > > (gdb) l *udp_input+0x5d2 > 0xffffffff806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628). > 623 if (inp->inp_ip_minttl && inp->inp_ip_minttl > ip->ip_ttl) { > 624 INP_RUNLOCK(inp); > 625 goto badunlocked; > 626 } > 627 up = intoudpcb(inp); > 628 if (up->u_tun_func == NULL) { > 629 udp_append(inp, ip, m, iphlen + sizeof(struct > udphdr), &udp_in); > 630 } else { > 631 /* > 632 * Engage the tunneling protocol. > > The faulty line appears to be 628, with up value is being NULL, attempt to > deference it causes NULL pointer exception. I believe this particular piece > of code has been introduced here: Unlikely; the inp is properly locked there and the udp info attach better still be valid there; your problem is most likely elsewhere; try to see if you have other threads and see what they do at the same time, etc. You would need to race with udp_detach(); you also want to make sure that the inp still looks sane from either ddb or a dump and we are not talking about random memory corruption here. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 21:20:49 2011 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 17BE81065670; Mon, 7 Nov 2011 21:20:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E473D8FC13; Mon, 7 Nov 2011 21:20:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA7LKmDH051479; Mon, 7 Nov 2011 21:20:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA7LKmPl051468; Mon, 7 Nov 2011 21:20:48 GMT (envelope-from linimon) Date: Mon, 7 Nov 2011 21:20:48 GMT Message-Id: <201111072120.pA7LKmPl051468@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/162352: [patch] Enhancement: add SO_PROTO to socket.h 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, 07 Nov 2011 21:20:49 -0000 Old Synopsis: Enhancement: New Synopsis: [patch] Enhancement: add SO_PROTO to socket.h Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 7 21:18:58 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=162352 From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 21:38:54 2011 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 864AC106566B for ; Mon, 7 Nov 2011 21:38:54 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3EF8FC08 for ; Mon, 7 Nov 2011 21:38:54 +0000 (UTC) Received: by qyc1 with SMTP id 1so3606554qyc.13 for ; Mon, 07 Nov 2011 13:38:53 -0800 (PST) Received: by 10.229.236.145 with SMTP id kk17mr1695517qcb.168.1320700191154; Mon, 07 Nov 2011 13:09:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.26.143 with HTTP; Mon, 7 Nov 2011 13:09:11 -0800 (PST) In-Reply-To: References: <2AB05A3E-BDC3-427D-B4A7-ABDDFA98D194@dudu.ro> <0BB87D28-3094-422D-8262-5FA0E40BFC7C@dudu.ro> <567B01DF-7D52-4C5C-8F69-96CDB20FAC92@neville-neil.com> From: Takuya ASADA Date: Tue, 8 Nov 2011 06:09:11 +0900 Message-ID: To: George Neville-Neil , Vlad Galu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Multiqueue support for bpf 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, 07 Nov 2011 21:38:54 -0000 Hi, Probably my previous mail had been skipped or forgot replying, so I'd like to try notice again. # This is original post of this thread, if you don't remember what is this: http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.htm= l George said "I think we should try to integrate this work and then tune it up more. in previous mail, then I want to merge this now. Is there any additional work required to merge, or just fine? 2011/9/22 Takuya ASADA : > Sorry for late replying, > >> One comment, one question. >> >> First, I think we should try to integrate this work and then tune it up = more. =C2=A0The API >> is, I think, fine, and performance tuning takes a bit of work. > > Is there good way(I mean tools or something) to find the bottleneck? > >> Second, what are the parameters set on buffers for the drivers? =C2=A0I.= e. how many slots >> do they have in their queues etc.? =C2=A0If they defaults are too small,= and often they are, >> then that's going to hurt your performance. > > It does equals to number of descriptors per queue, right? > If I'm correct, it's 2048 descriptors per queue by default, and I used > default parameter when I perform benchmarks. > > It's on line 290 of > http://p4db.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2011/mq= _bpf/src/sys/dev/ixgbe/ixgbe.c&REV=3D2 > > and line 105 of > http://p4db.freebsd.org/fileViewer.cgi?FSPC=3D//depot/projects/soc2011/mq= _bpf/src/sys/dev/ixgbe/ixgbe.h&REV=3D2 > From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 22:58:06 2011 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 E6AF51065677; Mon, 7 Nov 2011 22:58:06 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id BCD298FC0C; Mon, 7 Nov 2011 22:58:06 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNY8j-000HLp-DG; Mon, 07 Nov 2011 14:58:05 -0800 Message-ID: <4EB86276.6080801@sippysoft.com> Date: Mon, 07 Nov 2011 14:57:58 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EB804D2.2090101@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes Cc: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 22:58:07 -0000 On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: > Unlikely; the inp is properly locked there and the udp info attach > better still be valid there; your problem is most likely elsewhere; > try to see if you have other threads and see what they do at the same > time, etc. You would need to race with udp_detach(); you also want > to make sure that the inp still looks sane from either ddb or a dump > and we are not talking about random memory corruption here. Well, as you can see from the trace it points pretty strongly to that piece of code. And as I said this panic is completely reproducible, we've seen it at least 5 times to date in exactly this location. Unfortunately the trace is rather long so we could not capture it in full before, until we've switched to the 80x50 mode. If it was a memory corruption it would be just random fault, while here we have it failing in this point reliably. Unfortunately the panic happens in the driver thread context (I believe), so the KDB/dump is not working. After panicing the machine just hangs there. Keyboard is not working and I need to do a hard reset. Is there any other explanation that you can think of? Is it possible for some other portion of the code (i.e. network driver, DMA engine etc) to trash this structure by writing something off bound? Or something along the lines? Thanks! Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 23:23:24 2011 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 40D82106564A; Mon, 7 Nov 2011 23:23:24 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6668FC1A; Mon, 7 Nov 2011 23:23:23 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNYXC-000HQ8-Oc; Mon, 07 Nov 2011 15:23:22 -0800 Message-ID: <4EB86866.9060102@sippysoft.com> Date: Mon, 07 Nov 2011 15:23:18 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> In-Reply-To: <4EB86276.6080801@sippysoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes Cc: "Bjoern A. Zeeb" , Robert Watson , "current@freebsd.org" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 23:23:24 -0000 On 11/7/2011 2:57 PM, Maxim Sobolev wrote: > On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: >> Unlikely; the inp is properly locked there and the udp info attach >> better still be valid there; your problem is most likely elsewhere; >> try to see if you have other threads and see what they do at the same >> time, etc. You would need to race with udp_detach(); you also want >> to make sure that the inp still looks sane from either ddb or a dump >> and we are not talking about random memory corruption here. > > Well, as you can see from the trace it points pretty strongly to that > piece of code. And as I said this panic is completely reproducible, > we've seen it at least 5 times to date in exactly this location. > Unfortunately the trace is rather long so we could not capture it in > full before, until we've switched to the 80x50 mode. > > If it was a memory corruption it would be just random fault, while here > we have it failing in this point reliably. > > Unfortunately the panic happens in the driver thread context (I > believe), so the KDB/dump is not working. After panicing the machine > just hangs there. Keyboard is not working and I need to do a hard reset. > > Is there any other explanation that you can think of? Is it possible for > some other portion of the code (i.e. network driver, DMA engine etc) to > trash this structure by writing something off bound? Or something along > the lines? OK, I've put the following catch to prove the case: up = intoudpcb(inp); if (up == NULL) { printf("BZZT! Something is terribly wrong, up == NULL!\n"); INP_RUNLOCK(inp); goto badunlocked; } if (up->u_tun_func == NULL) { I am going to give it a spin on two busiest boxes and see if I can log anything. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 23:26:08 2011 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 76F2D106566C; Mon, 7 Nov 2011 23:26:08 +0000 (UTC) (envelope-from bz@FreeBSD.ORG) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 28C818FC1C; Mon, 7 Nov 2011 23:26:07 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C587F25D385D; Mon, 7 Nov 2011 23:25:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id ED602BD469C; Mon, 7 Nov 2011 23:25:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ody5jEqJnMWZ; Mon, 7 Nov 2011 23:25:34 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 7EBE0BD4699; Mon, 7 Nov 2011 23:25:34 +0000 (UTC) Date: Mon, 7 Nov 2011 23:25:34 +0000 (UTC) From: "Bjoern A. Zeeb" To: Maxim Sobolev In-Reply-To: <4EB86866.9060102@sippysoft.com> Message-ID: References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Robert Watson , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 23:26:08 -0000 On Mon, 7 Nov 2011, Maxim Sobolev wrote: > On 11/7/2011 2:57 PM, Maxim Sobolev wrote: >> On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: >>> Unlikely; the inp is properly locked there and the udp info attach >>> better still be valid there; your problem is most likely elsewhere; >>> try to see if you have other threads and see what they do at the same >>> time, etc. You would need to race with udp_detach(); you also want >>> to make sure that the inp still looks sane from either ddb or a dump >>> and we are not talking about random memory corruption here. >> >> Well, as you can see from the trace it points pretty strongly to that >> piece of code. And as I said this panic is completely reproducible, >> we've seen it at least 5 times to date in exactly this location. >> Unfortunately the trace is rather long so we could not capture it in >> full before, until we've switched to the 80x50 mode. >> >> If it was a memory corruption it would be just random fault, while here >> we have it failing in this point reliably. >> >> Unfortunately the panic happens in the driver thread context (I >> believe), so the KDB/dump is not working. After panicing the machine >> just hangs there. Keyboard is not working and I need to do a hard reset. >> >> Is there any other explanation that you can think of? Is it possible for >> some other portion of the code (i.e. network driver, DMA engine etc) to >> trash this structure by writing something off bound? Or something along >> the lines? > > OK, I've put the following catch to prove the case: > > up = intoudpcb(inp); > if (up == NULL) { > printf("BZZT! Something is terribly wrong, up == NULL!\n"); > INP_RUNLOCK(inp); > goto badunlocked; > } > if (up->u_tun_func == NULL) { > > I am going to give it a spin on two busiest boxes and see if I can log > anything. Now if you are clever you'd also log the inp there as the above will only prove the case that something is wrong but still not help us in anything to figure out what. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Mon Nov 7 23:55:02 2011 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 6C95D1065678; Mon, 7 Nov 2011 23:55:02 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 438AC8FC17; Mon, 7 Nov 2011 23:55:02 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RNZ1o-000HTH-W8; Mon, 07 Nov 2011 15:55:01 -0800 Message-ID: <4EB86FCF.3050306@FreeBSD.org> Date: Mon, 07 Nov 2011 15:54:55 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: freebsd-net@freebsd.org, Robert Watson , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 07 Nov 2011 23:55:02 -0000 On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote: > Now if you are clever you'd also log the inp there as the above will > only prove the case that something is wrong but still not help us in > anything to figure out what. Good point, thank you Sir. Would that be good enough? printf("BZZT! Something is terribly wrong, up == NULL! inp = %p\n", inp); Do you think of any other useful piece of information that I can log at this point? -Maxim From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 02:41:01 2011 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 24CD5106564A; Tue, 8 Nov 2011 02:41:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F2CCD8FC13; Tue, 8 Nov 2011 02:41:00 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 695F846B09; Mon, 7 Nov 2011 21:41:00 -0500 (EST) Date: Tue, 8 Nov 2011 02:41:00 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <4EB86FCF.3050306@FreeBSD.org> Message-ID: References: <4EB804D2.2090101@FreeBSD.org> <4EB86276.6080801@sippysoft.com> <4EB86866.9060102@sippysoft.com> <4EB86FCF.3050306@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" , Jack Vogel Subject: Re: Panic in the udp_input() under heavy load 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, 08 Nov 2011 02:41:01 -0000 On Mon, 7 Nov 2011, Maxim Sobolev wrote: > On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote: >> Now if you are clever you'd also log the inp there as the above will only >> prove the case that something is wrong but still not help us in anything to >> figure out what. > > Good point, thank you Sir. > > Would that be good enough? > > printf("BZZT! Something is terribly wrong, up == NULL! inp = %p\n", inp); > > Do you think of any other useful piece of information that I can log at this > point? Hi Maxim: There was recently a commit to fix a race condition in 10-CURRENT which I think is not slated to be merged for 9.0. You might check the commit logs there and see if that fixes the problems you have -- if so, we might want to reconsider the plan not to merge for 9.0. (It relates to a race condition on closing sockets..) Robert From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 08:33:04 2011 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 4D8D91065675; Tue, 8 Nov 2011 08:33:04 +0000 (UTC) (envelope-from slonoman2011@yandex.ru) Received: from forward2.mail.yandex.net (forward2.mail.yandex.net [IPv6:2a02:6b8:0:602::2]) by mx1.freebsd.org (Postfix) with ESMTP id BEF268FC16; Tue, 8 Nov 2011 08:33:03 +0000 (UTC) Received: from web49.yandex.ru (web49.yandex.ru [77.88.47.155]) by forward2.mail.yandex.net (Yandex) with ESMTP id CF01012A479F; Tue, 8 Nov 2011 12:33:01 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1320741181; bh=8UpZB9m/E/gcNxIStOeszx9snocvLAxrotk1f9SXhuo=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=vdLlzc5WB5r8icWAhjYexfwao/cmczPG7JGGEfAXsHSEynJYCvoV5UtB7T9QTESPg sHZEBcSpSse/J2hiGCtDtAmr6r6x1EtorHsHU2flYIrVLeiAodUsYNN/7ELJhYcVSA CugMcO31yvp4LQ1FxusdHCgBgJksRR6q3VEK9i8Q= Received: from localhost (localhost.localdomain [127.0.0.1]) by web49.yandex.ru (Yandex) with ESMTP id 922194E806C; Tue, 8 Nov 2011 12:33:01 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1320741181; bh=8UpZB9m/E/gcNxIStOeszx9snocvLAxrotk1f9SXhuo=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=vdLlzc5WB5r8icWAhjYexfwao/cmczPG7JGGEfAXsHSEynJYCvoV5UtB7T9QTESPg sHZEBcSpSse/J2hiGCtDtAmr6r6x1EtorHsHU2flYIrVLeiAodUsYNN/7ELJhYcVSA CugMcO31yvp4LQ1FxusdHCgBgJksRR6q3VEK9i8Q= X-Yandex-Spam: 1 Received: from c5509-m58.cmk.ru (c5509-m58.cmk.ru [195.182.128.54]) by web49.yandex.ru with HTTP; Tue, 08 Nov 2011 12:32:46 +0400 From: Slono Slono To: "Li, Qing" In-Reply-To: References: <85301320352980@web142.yandex.ru> MIME-Version: 1.0 Message-Id: <125061320741181@web49.yandex.ru> Date: Tue, 08 Nov 2011 12:32:46 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Cc: freebsd-net@freebsd.org, qingli@freebsd.org Subject: Re: arp code broken after BETA3 9.0 ? 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, 08 Nov 2011 08:33:04 -0000 04.11.2011, 01:25, "Li, Qing" : > Could you please apply this patch > > šššhttp://svnweb.freebsd.org/base?view=revision&revision=227002 > > and let me know how it works out for you ? > > Thanks, Hi, Yes, revision 227002+ solves a kernel panic problem, thanks you. From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 09:21:04 2011 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 94F5A1065673 for ; Tue, 8 Nov 2011 09:21:04 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7CF8FC1F for ; Tue, 8 Nov 2011 09:21:03 +0000 (UTC) Received: by faar19 with SMTP id r19so422043faa.13 for ; Tue, 08 Nov 2011 01:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=V3Wmu7XP2mjMTfdLhGFQERIEpPN/g+ptcJnE+qLKTpc=; b=OPuxJKZxp2Ttqf+6BHTpGV5lo7h8bqey00bxcZ9Z6q1d7bm23/uL0Tfb6Dg0cNGEjl aSYEDiy3oQwJwBH0tSyJT3P7FkYD4VOAwWz5wx0x6fZgtcgWJ8Vb8A/ahHiTgQQA3hCg rMMocdwm0kBxzKD73+BDvLAtLRJgUBhAiSegs= MIME-Version: 1.0 Received: by 10.152.122.34 with SMTP id lp2mr2168978lab.20.1320744062975; Tue, 08 Nov 2011 01:21:02 -0800 (PST) Received: by 10.152.9.10 with HTTP; Tue, 8 Nov 2011 01:21:02 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 13:21:02 +0400 Message-ID: From: Pavel Timofeev To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Possible MROUTING regression in 9.0 RC1 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, 08 Nov 2011 09:21:04 -0000 And sometimes igmpproxy's shutdown lead to crash of my system. Without any panics, it just reboots. oO 2011/11/7 Pavel Timofeev : > Hello! I have problems with ip_mroute (loaded as module) - kernel > multicast packet forwarder. > I have 2 disk: freebsd 8.2 release amd64 on first and freebsd 9.0 rc1 on = second. > I use net/igmpproxy to watch IPTV on my home atom-based router. > > On FreeBSD 8.2 it works good. > > But when I try to use FreeBSD 9.0 RC-1 in same role (with same > configs, of cource) I have messages like: > Nov =C2=A07 16:16:46 timp igmpproxy[35495]: received packet from > 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) > Nov =C2=A07 16:16:47 timp igmpproxy[35495]: received packet from > 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) > Nov =C2=A07 16:17:28 timp igmpproxy[35495]: received packet from 10.85.13= .5 > shorter (28 bytes) than hdr+data length (20+28) > And IPTV doesn't work =3D( > > Any ideas? > Do you need configs? > From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 12:40:11 2011 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 DCC8E106566B for ; Tue, 8 Nov 2011 12:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B35EE8FC1D for ; Tue, 8 Nov 2011 12:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA8CeBif034515 for ; Tue, 8 Nov 2011 12:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA8CeBH5034514; Tue, 8 Nov 2011 12:40:11 GMT (envelope-from gnats) Date: Tue, 8 Nov 2011 12:40:11 GMT Message-Id: <201111081240.pA8CeBH5034514@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Jukka A. Ukkonen" Cc: Subject: Re: kern/162352: [patch] Enhancement: add SO_PROTO to socket.h X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jukka A. Ukkonen" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 12:40:11 -0000 The following reply was made to PR kern/162352; it has been noted by GNATS. From: "Jukka A. Ukkonen" To: bug-followup@FreeBSD.org, jau@iki.fi Cc: Subject: Re: kern/162352: [patch] Enhancement: add SO_PROTO to socket.h Date: Tue, 08 Nov 2011 12:51:07 +0200 On SunOS/Solaris the socket option with similar semantics seems to be called SO_PROTOTYPE. Does anyone have some HP-UX or AIX systems or some other alternative OS environments to check their naming for similar options, assuming they have similar options at all? --jau From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 17:21:31 2011 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 8103A106566B for ; Tue, 8 Nov 2011 17:21:31 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CFB178FC13 for ; Tue, 8 Nov 2011 17:21:30 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so854454bkb.13 for ; Tue, 08 Nov 2011 09:21:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=6VLOHIUAni7G/xc05I+A/KG6Y9ACNr0GhitFJ1sEo3Q=; b=uIGUqkkFn98RMIsdNMTa7HmszvGY1Tv8UAxFyRwLpXIDuqaRZLetDeb3blIHgaOa3k KJmWH6WTrG7ddo2XqzD0FQfINISJivEC3qOM/fhD109J7ugjacYUuQLaWGYdNHNQZBEs NG8gaYF/LWCJzziuuKc83kUiT5d0zubyAQy2Q= Received: by 10.205.114.65 with SMTP id ez1mr23107458bkc.99.1320772889725; Tue, 08 Nov 2011 09:21:29 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id fu17sm2199712bkc.9.2011.11.08.09.21.24 (version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 09:21:28 -0800 (PST) Message-ID: <4EB96511.50701@gmail.com> Date: Tue, 08 Nov 2011 20:51:21 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Jason Wolfe References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 08 Nov 2011 17:21:31 -0000 On 11/7/2011 9:24 PM, Jason Wolfe wrote: > On Mon, Oct 31, 2011 at 1:13 AM, Hooman Fazaeli > wrote: > > > Attached is a patch for if_em.c. It flushes interface queue when it is full > and link is not active. Please note that when this happens, drops are increasing > on interface and this will trigger your scripts as before. You need to change > a little the scripts as follows: > > check interface TX status > if (interface TX seems hung) { > sleep 5 > check interface TX status > if (interface TX seems hung) { > reset the interface. > } > } > > For MULTIQUEUE, it just disables the check for link status (which is not good). > so pls. test in non-MULTIQUEUE mode. > > The patch also contains some minor fixups to compile on 7 plus > a fix from r1.69 which addressed RX hang problem (the fix was > later removed in r1.70). I included it for Emil to give it a > try. > > Pls. let me know if you have any problems with patch. > > > Hooman, > > Unfortunately one of the server just had a wedge event a couple hours ago with this patch. To confirm your changes should cause a recovery within the time I'm allowing, here is the current format: > > check interface TX status > if (interface TX seems hung) { > sleep 3 > check packets out > sleep 2 > check packets out > if (packets not incrementing) { > reset the interface > } > } > > I bounced em0 because dropped packets incremented 1749543 to 1749708 and the interface is not incrementing packets out. > > 4:10AM up 6 days, 15:23, 0 users, load averages: 0.02, 0.12, 0.14 > > em0: flags=8843 metric 0 mtu 1500 > options=219b > ether X > inet6 X%em0 prefixlen 64 scopeid 0x1 > nd6 options=1 > media: Ethernet autoselect (1000baseT ) > status: active > > em1: flags=8843 metric 0 mtu 1500 > options=219b > ether X > inet6 X%em1 prefixlen 64 scopeid 0x2 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > > ipfw0: flags=8801 metric 0 mtu 65536 > > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > inet X.X.X.X netmask 0xffffffff > nd6 options=3 > > lagg0: flags=8843 metric 0 mtu 1500 > options=219b > ether X > inet X.X.X.X netmask 0xffffff00 broadcast X.X.X.X > inet6 X%lagg0 prefixlen 64 scopeid 0x5 > inet6 X prefixlen 64 autoconf > nd6 options=3 > media: Ethernet autoselect > status: active > laggproto loadbalance > laggport: em0 flags=4 > laggport: em1 flags=4 > > interrupt total rate > irq3: uart1 3810 0 > cpu0: timer 1147568087 2000 > irq256: em0:rx 0 59779710 104 > irq257: em0:tx 0 2771888652 4831 > irq258: em0:link 1 0 > irq259: em1:rx 0 3736828886 6512 > irq260: em1:tx 0 2790566376 4863 > irq261: em1:link 27286 0 > irq262: mps0 395687386 689 > cpu1: timer 1147559894 2000 > cpu2: timer 1147559901 2000 > cpu3: timer 1147559902 2000 > Total 14345029891 25001 > > 13466/4144/17610 mbufs in use (current/cache/total) > 2567/2635/5202/5853720 mbuf clusters in use (current/cache/total/max) > 2567/633 mbuf+clusters out of packet secondary zone in use (current/cache) > 6798/554/7352/2926859 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 35692K/8522K/44214K 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 > > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop > em0 1500 00:25:90:2b:e5:75 60747643 0 0 11246408092 0 0 1750763 > em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 4 - - - > em1 1500 00:25:90:2b:e5:75 11237195776 123950 0 11344722383 0 0 545682 > em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 1 - - - > lagg0 1500 00:25:90:2b:e5:75 11297850142 0 0 22588666102 2296445 0 0 > lagg0 1500 69.164.38.0/2 69.164.38.83 10189108030 - - 22592881776 - - - > lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 24 - - 28 - - - > lagg0 1500 2607:f4e8:310 2607:f4e8:310:12: 19578 - - 19591 - - - > > kern.msgbuf: > > Nov 7 04:10:06 cds1033 kernel: Interface is RUNNING and INACTIVE > Nov 7 04:10:06 cds1033 kernel: em0: hw tdh = 558, hw tdt = 558 > Nov 7 04:10:06 cds1033 kernel: em0: hw rdh = 889, hw rdt = 888 > Nov 7 04:10:06 cds1033 kernel: em0: Tx Queue Status = 0 > Nov 7 04:10:06 cds1033 kernel: em0: TX descriptors avail = 1024 > Nov 7 04:10:06 cds1033 kernel: em0: Tx Descriptors avail failure = 0 > Nov 7 04:10:06 cds1033 kernel: em0: RX discarded packets = 0 > Nov 7 04:10:06 cds1033 kernel: em0: RX Next to Check = 889 > Nov 7 04:10:06 cds1033 kernel: em0: RX Next to Refresh = 888 > Nov 7 04:10:06 cds1033 kernel: em0: Link state: active > Nov 7 04:10:06 cds1033 kernel: Interface is RUNNING and INACTIVE > Nov 7 04:10:06 cds1033 kernel: em1: hw tdh = 837, hw tdt = 837 > Nov 7 04:10:06 cds1033 kernel: em1: hw rdh = 198, hw rdt = 189 > Nov 7 04:10:06 cds1033 kernel: em1: Tx Queue Status = 0 > Nov 7 04:10:06 cds1033 kernel: em1: TX descriptors avail = 1021 > Nov 7 04:10:06 cds1033 kernel: em1: Tx Descriptors avail failure = 0 > Nov 7 04:10:06 cds1033 kernel: em1: RX discarded packets = 0 > Nov 7 04:10:06 cds1033 kernel: em1: RX Next to Check = 303 > Nov 7 04:10:06 cds1033 kernel: em1: RX Next to Refresh = 302 > Nov 7 04:10:06 cds1033 kernel: em1: Link state: active > > net.inet.ip.intr_queue_maxlen: 512 > net.inet.ip.intr_queue_drops: 0 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 > dev.em.0.%parent: pci1 > dev.em.0.nvm: -1 > dev.em.0.debug: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.flow_control: 0 > dev.em.0.eee_control: 0 > dev.em.0.link_irq: 1 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.link_toggles: 3 > dev.em.0.device_control: 1074790984 > dev.em.0.rx_control: 67141634 > dev.em.0.fc_high_water: 18432 > dev.em.0.fc_low_water: 16932 > dev.em.0.queue0.txd_head: 558 > dev.em.0.queue0.txd_tail: 558 > dev.em.0.queue0.tx_irq: 2771888613 > dev.em.0.queue0.no_desc_avail: 0 > dev.em.0.queue0.rxd_head: 102 > dev.em.0.queue0.rxd_tail: 101 > dev.em.0.queue0.rx_irq: 59779941 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 0 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 60768005 > dev.em.0.mac_stats.good_pkts_recvd: 60768005 > dev.em.0.mac_stats.bcast_pkts_recvd: 60744833 > dev.em.0.mac_stats.mcast_pkts_recvd: 2948 > dev.em.0.mac_stats.rx_frames_64: 60744822 > dev.em.0.mac_stats.rx_frames_65_127: 3491 > dev.em.0.mac_stats.rx_frames_128_255: 19293 > dev.em.0.mac_stats.rx_frames_256_511: 364 > dev.em.0.mac_stats.rx_frames_512_1023: 35 > dev.em.0.mac_stats.rx_frames_1024_1522: 0 > dev.em.0.mac_stats.good_octets_recvd: 3890774076 > dev.em.0.mac_stats.good_octets_txd: 15295538422911 > dev.em.0.mac_stats.total_pkts_txd: 11246435226 > dev.em.0.mac_stats.good_pkts_txd: 11246435226 > dev.em.0.mac_stats.bcast_pkts_txd: 4 > dev.em.0.mac_stats.mcast_pkts_txd: 3830 > dev.em.0.mac_stats.tx_frames_64: 60338532 > dev.em.0.mac_stats.tx_frames_65_127: 897135811 > dev.em.0.mac_stats.tx_frames_128_255: 13933787 > dev.em.0.mac_stats.tx_frames_256_511: 22107540 > dev.em.0.mac_stats.tx_frames_512_1023: 116374045 > dev.em.0.mac_stats.tx_frames_1024_1522: 10136545511 > dev.em.0.mac_stats.tso_txd: 0 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.interrupts.asserts: 3 > dev.em.0.interrupts.rx_pkt_timer: 0 > dev.em.0.interrupts.rx_abs_timer: 0 > dev.em.0.interrupts.tx_pkt_timer: 0 > dev.em.0.interrupts.tx_abs_timer: 0 > dev.em.0.interrupts.tx_queue_empty: 0 > dev.em.0.interrupts.tx_queue_min_thresh: 0 > dev.em.0.interrupts.rx_desc_min_thresh: 0 > dev.em.0.interrupts.rx_overrun: 0 > dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 > dev.em.1.%driver: em > dev.em.1.%location: slot=0 function=0 > dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 > dev.em.1.%parent: pci2 > dev.em.1.nvm: -1 > dev.em.1.debug: -1 > 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: 100 > dev.em.1.flow_control: 0 > dev.em.1.eee_control: 0 > dev.em.1.link_irq: 27207 > 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.link_toggles: 3 > dev.em.1.device_control: 1074790984 > 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: 804 > dev.em.1.queue0.txd_tail: 804 > dev.em.1.queue0.tx_irq: 2790571888 > dev.em.1.queue0.no_desc_avail: 0 > dev.em.1.queue0.rxd_head: 686 > dev.em.1.queue0.rxd_tail: 686 > dev.em.1.queue0.rx_irq: 3729597000 > 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: 123950 > dev.em.1.mac_stats.recv_no_buff: 7063 > 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: 0 > dev.em.1.mac_stats.xon_txd: 0 > dev.em.1.mac_stats.xoff_recvd: 0 > dev.em.1.mac_stats.xoff_txd: 0 > dev.em.1.mac_stats.total_pkts_recvd: 11237327404 > dev.em.1.mac_stats.good_pkts_recvd: 11237203454 > dev.em.1.mac_stats.bcast_pkts_recvd: 60741559 > dev.em.1.mac_stats.mcast_pkts_recvd: 2935 > dev.em.1.mac_stats.rx_frames_64: 4479481614 > dev.em.1.mac_stats.rx_frames_65_127: 5124633522 > dev.em.1.mac_stats.rx_frames_128_255: 13228214 > dev.em.1.mac_stats.rx_frames_256_511: 23321029 > dev.em.1.mac_stats.rx_frames_512_1023: 74960116 > dev.em.1.mac_stats.rx_frames_1024_1522: 1521578959 > dev.em.1.mac_stats.good_octets_recvd: 3024997755633 > dev.em.1.mac_stats.good_octets_txd: 15349574964083 > dev.em.1.mac_stats.total_pkts_txd: 11344737635 > dev.em.1.mac_stats.good_pkts_txd: 11344737635 > dev.em.1.mac_stats.bcast_pkts_txd: 2501 > dev.em.1.mac_stats.mcast_pkts_txd: 8 > dev.em.1.mac_stats.tx_frames_64: 62839963 > dev.em.1.mac_stats.tx_frames_65_127: 962219224 > dev.em.1.mac_stats.tx_frames_128_255: 14620849 > dev.em.1.mac_stats.tx_frames_256_511: 20410906 > dev.em.1.mac_stats.tx_frames_512_1023: 117272600 > dev.em.1.mac_stats.tx_frames_1024_1522: 10167374093 > dev.em.1.mac_stats.tso_txd: 0 > dev.em.1.mac_stats.tso_ctx_fail: 0 > dev.em.1.interrupts.asserts: 19749 > dev.em.1.interrupts.rx_pkt_timer: 1 > 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: 18 > hw.em.rx_hang_fixup: 0 > hw.em.eee_setting: 0 > hw.em.fc_setting: 0 > hw.em.rx_process_limit: 100 > hw.em.enable_msix: 1 > hw.em.sbp: 0 > hw.em.smart_pwr_down: 0 > hw.em.txd: 1024 > hw.em.rxd: 1024 > hw.em.rx_abs_int_delay: 66 > hw.em.tx_abs_int_delay: 66 > hw.em.rx_int_delay: 0 > hw.em.tx_int_delay: 66 > > Jason I have allocated more time to the problem and guess I can explain what your problem is. With MSIX disabled, the driver uses fast interrupt handler (em_irq_fast) which calls rx/tx task and then checks for link status change. This implies that rx/tx task is executed with every link state change. This is not efficient, as it is a waste of time to start transmission when link is down. However, it has the effect that after a temporary link loss (active->inactive->active), _start is executed and transmission continues normally. The value of link_toggles (3) clearly indicates that you had such a transition when the problem occured. With MSIX enabled, the link task (em_handle_link) does _not_ triggers _start when the link changes state from inactive to active (which it should). If if_snd quickly fills up during a temporary link loss, transmission is stopped forever and the driver never recovers from that state. The last patch should have reduced the frequency of the problem but it assumes every IFQ_ENQUEUE is followed by a if_start which is not a true assumption. If you are willing to test, I can prepare another patch for you to fix the issue in a different and more reliable way. From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 18:53:58 2011 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 2E78B106566C for ; Tue, 8 Nov 2011 18:53:58 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A496E8FC15 for ; Tue, 8 Nov 2011 18:53:57 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so980272bkb.13 for ; Tue, 08 Nov 2011 10:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zKPOz4Dp0bDLMcd8/6Fmpa3Euez/R7kDd0qF57Tt0vA=; b=XocLTqYbJiv/HgG5Dck1QjbS0cZM640ctlzCi5+fqZJmMR85ruFIpHur9V+kY5pKxv VPD9UfkAaKqI69/HlylYojAwhr49aJZv1VTys0T2lGT6H3PRlfNI+islCsTeQ4tri0Vw v39UcmMo+VvZ9uxBgXJ7JUNiRTaC0A28v5VEk= MIME-Version: 1.0 Received: by 10.182.13.1 with SMTP id d1mr10380396obc.74.1320778436019; Tue, 08 Nov 2011 10:53:56 -0800 (PST) Received: by 10.182.30.164 with HTTP; Tue, 8 Nov 2011 10:53:55 -0800 (PST) In-Reply-To: <4EB96511.50701@gmail.com> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> Date: Tue, 8 Nov 2011 11:53:55 -0700 Message-ID: From: Jason Wolfe To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 08 Nov 2011 18:53:58 -0000 On Tue, Nov 8, 2011 at 10:21 AM, Hooman Fazaeli wrote: > I have allocated more time to the problem and guess I can explain what > your problem is. > > With MSIX disabled, the driver uses fast interrupt handler (em_irq_fast) > which calls rx/tx task and then checks for link status change. This > implies that rx/tx task is executed with every link state change. This is > not efficient, as it is a waste of time to start transmission when link is > down. > However, it has the effect that after a temporary link loss > (active->inactive->active), > _start is executed and transmission continues normally. The value of > link_toggles (3) > clearly indicates that you had such a transition when the problem occured. > > With MSIX enabled, the link task (em_handle_link) does _not_ triggers > _start when the link changes state from inactive to active (which it > should). > If if_snd quickly fills up during a temporary link loss, transmission is > stopped forever and the driver never recovers from that state. > > The last patch should have reduced the frequency of the problem > but it assumes every IFQ_ENQUEUE is followed by a if_start which > is not a true assumption. > > If you are willing to test, I can prepare another patch for you to fix > the issue in a different and more reliable way. > > Hooman, Thanks again for the assist, it sounds like this may also be why we see a bit higher latency with MSI-X disabled on this chipset. I'm happy to test any patches as I have a handful of boxes set aside to 'research' this issue. Hopefully the testing here helps along any patches to the tree for others benefit also. Jason From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 19:30:31 2011 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 5DF1B106566B for ; Tue, 8 Nov 2011 19:30:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 06C828FC0A for ; Tue, 8 Nov 2011 19:30:30 +0000 (UTC) Received: by vws11 with SMTP id 11so1120052vws.13 for ; Tue, 08 Nov 2011 11:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tyl8UeiJCF/uL1XeQnsUJSLnQl17j4+QDjQtIRfxKu8=; b=xtKsHaGkgHDqAh+UebI0wAMCPoQHk9cP7rRLxIt+MkhI6JHQw5PAcH5zhEO7C+KYg0 FnnTN7v4eltdmi7Z8QIaJfcQwyvPswzpkneyXhnG9STrRkgwJOBV9IiUIKEWb1NFosLc r2FTs9qwOSHuuSe4ZdV+c4qtMyPXongsWtza4= MIME-Version: 1.0 Received: by 10.52.95.164 with SMTP id dl4mr33705782vdb.72.1320780629820; Tue, 08 Nov 2011 11:30:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Tue, 8 Nov 2011 11:30:29 -0800 (PST) In-Reply-To: <4EB96511.50701@gmail.com> References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> Date: Tue, 8 Nov 2011 11:30:29 -0800 X-Google-Sender-Auth: DQRCafmHfMCV-X8ct89I0tBj1yw Message-ID: From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Emil Muratov , Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 08 Nov 2011 19:30:31 -0000 On 8 November 2011 09:21, Hooman Fazaeli wrote: > With MSIX enabled, the link task (em_handle_link) does _not_ triggers > _start when the link changes state from inactive to active (which it > should). > If if_snd quickly fills up during a temporary link loss, transmission is > stopped forever and the driver never recovers from that state. > > The last patch should have reduced the frequency of the problem > but it assumes every IFQ_ENQUEUE is followed by a if_start which > is not a true assumption. FWIW, I saw something very similar with the if_arge code port from Linux. If the TX queue filled up and wasn't serviced before it hit completely full, it was never drained. It may be worthwhile auditing some of the other NIC drivers to ensure this kind of situation isn't occuring. Especially if they came from Linux. :-) That's a great catch, I hope it finally fixes the if_em issues with MSIX. :-) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 22:40:17 2011 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 DA200106564A for ; Tue, 8 Nov 2011 22:40:17 +0000 (UTC) (envelope-from wittigal@msu.edu) Received: from sys01.mail.msu.edu (sys01.mail.msu.edu [35.9.75.101]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9F88FC0A for ; Tue, 8 Nov 2011 22:40:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=msu.edu; s=mail; h=Mime-Version:To:Message-Id:Date:Subject:Content-Transfer-Encoding:Content-Type:From; bh=yRB9ioENag9mf3ZkYOrKX9avDEtV9JlmdFQNOcC5d3s=; b=cPhv8Cn2lJgaeF4sK7adwRyu0CWpYe1WTIG7EMSprowSr9xoU9uaX8qtOJKKulBh8Qr6DwqxCFQUF2MbByazrNByIvFjkiRHRWF0FtJQE9qWc/KqSvpyTOHsDzJdvpfvWViVoqxOW+wAvhpRM5WH8y55ZHn55G/xRrIi6JLPmHE=; Received: from prokofiev.bt.pa.msu.edu ([35.9.70.209] helo=[192.168.0.154]) Authenticated ID: wittigal by sys01.mail.msu.edu with esmtpsa (Exim 4.75 #3) (TLSv1:AES128-SHA:128) id 1RNtwM-000283-HT for freebsd-net@freebsd.org; Tue, 08 Nov 2011 17:14:46 -0500 From: Alexander Wittig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Nov 2011 17:14:45 -0500 Message-Id: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Virus: None found by Clam AV Subject: FreeBSD 9 and ARP multicast source address error messages 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, 08 Nov 2011 22:40:17 -0000 Hello I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD = bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011 = root@bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX i386), and ever since = that upgrade the kernel keeps flooding my log files with messages like = these: Nov 7 16:40:01 bt kernel: in_arp: source hardware address is = multicast.in_arp: source hardware address is multicast. Nov 7 16:42:02 bt kernel: in_arp: source hardware address is = multicast.in_arp: source hardware address is multicast. A Google search for these didn't reveal any useful results as to why = this happens or how to fix it. So I did a tcpdump and matched the time = stamps with packets, and I found the ones causing problems (the only = ones with a multicast bit set) to be like this: 16:40:01.099823 02:02:23:09:44:3c > 03:bf:23:09:44:87, ethertype ARP = (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 35.9.68.228 = is-at 03:bf:23:09:44:e4, length 46 0x0000: 03bf 2309 4487 0202 2309 443c 0806 0001 0x0010: 0800 0604 0002 03bf 2309 44e4 2309 44e4 0x0020: 02bf 2309 443c 2309 4487 0000 0000 0000 0x0030: 0000 0000 0000 0000 0000 0000 It appears the broadcast MAC 03:bf:23:09:44:87 is part of Microsoft's = network load balancing mechanism, with the 03:bf indicating that much = and the 23:09:44:87 containing the IP address of the load balance = cluster (35.9.68.228). These types of MACs seem to be commonly used in = their load balancing implementation. To prevent these messages from producing thousands of lines of logs each = day, I added the following two IPFW rules and enabled ethernet package = filtering (sysctl net.link.ether.ipfw=3D1): deny ip from any to any MAC 03:bf:00:00:00:00/16 any layer2 allow ip from any to any layer2 This effectively blocks those packages and the resulting error messages. = But I'm wondering if the newly added(?) ARP code in FBSD 9 is a bit too = fussy about these, or if MS is abusing the ARP protocol here. Either = way, this was never a problem with FBSD 7 or 8. Cheers, Alexander Please CC me on replies as I'm not subscribed to the freebsd-net list.= From owner-freebsd-net@FreeBSD.ORG Tue Nov 8 23:36:41 2011 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 5643E1065677; Tue, 8 Nov 2011 23:36:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C019B8FC13; Tue, 8 Nov 2011 23:36:40 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so1386138vcb.13 for ; Tue, 08 Nov 2011 15:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=RMsMliM6DY5IOy62EWI0L4EpCrSNnnzqgP/5zFEODzA=; b=DSt3+5BP4a48/lC4+qL8o5qmWhT/otdSVp3YwILpeglpKW45t1BmVTtrh+eaLIiyMq pr3vfw4OuaHLUiyG8lKc2GzOr8i7H4TMlVUJkd3ZdfwV7iKPpRCFUrxYsf7T1z+hlhqz TToMSSJ8bBRhPHIVY2fMBid5PuIQKkMSIb9iM= MIME-Version: 1.0 Received: by 10.52.177.3 with SMTP id cm3mr34659472vdc.89.1320795399970; Tue, 08 Nov 2011 15:36:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Tue, 8 Nov 2011 15:36:39 -0800 (PST) Date: Tue, 8 Nov 2011 15:36:39 -0800 X-Google-Sender-Auth: Y2O0f1ETVyi8jh9GZrRWPjktwLQ Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, freebsd-mobile@freebsd.org Subject: ath 11n tx work is now in head 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, 08 Nov 2011 23:36:41 -0000 Hi, I've merged in the bulk of my 11n TX work in a series of commits, culminating in a (still) overly large patch which added software TX aggregation and TX queue support. It's absolutely possible this has completely broken the ath driver. I'm going to spend the next few days throwing it against the hardware I have with me just to see if I broke anything during the merge. If you feel brave, throw on ATH_ENABLE_11N in your kernel config file and give it a go. If you're using legacy (non-11n) NICs, or you're not using 11N at home, please enable it too. It affects the non-11n TX path as well and I'd like to make absolutely sure this is still (mostly) working. Finally, if you -are- going to be testing this, I won't accept any error reports unless you've been running it with the -current debugging flags. That is, lock/witness debugging, asserts, and the memory allocator debugging. There's just too much that could be going wrong and I'd like to make sure that I have all of the relevant information from testers. Thanks again! Adrian From owner-freebsd-net@FreeBSD.ORG Wed Nov 9 06:01:18 2011 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 5364F106566B for ; Wed, 9 Nov 2011 06:01:18 +0000 (UTC) (envelope-from crest@informatik.uni-bremen.de) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by mx1.freebsd.org (Postfix) with ESMTP id BDD648FC28 for ; Wed, 9 Nov 2011 06:01:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pA7CRnSb010232 for ; Mon, 7 Nov 2011 13:27:49 +0100 (CET) Received: from t420.crest.dn42 (unknown [134.102.48.143]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C04F9A02 for ; Mon, 7 Nov 2011 11:49:26 +0100 (CET) Message-ID: <4EB7B7B7.2060805@informatik.uni-bremen.de> Date: Mon, 07 Nov 2011 11:49:27 +0100 From: Crest User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111011 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4EB7AD2A.5050002@frasunek.com> In-Reply-To: <4EB7AD2A.5050002@frasunek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: dummynet damages ICMPv6 packets 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, 09 Nov 2011 06:01:18 -0000 On 07.11.2011 11:04, Przemyslaw Frasunek wrote: > Hello, > > we are experiencing interesing behaviour of dummynet enabled on IPv6 interfaces. > When the following rules are added: > > add pipe 24 ip from any to any in recv vlan1 > add pipe 25 ip from any to any out xmit vlan1 > > all ICMPv6 packets passing on vlan1 are being damaged: > > 10:55:53.180801 IP6 fe80::215:17ff:feae:4d99> ff02::1: ip-proto-64 16 > 0x0000: 6000 0000 0010 403a fe80 0000 0000 0000 `.....@:........ > 0x0010: 0215 17ff feae 4d99 ff02 0000 0000 0000 ......M......... > 0x0020: 0000 0000 0000 0001 8000 2dc9 31f2 002e ..........-.1... > 0x0030: 4eb7 ab29 0002 c207 N..).... > > Please note invalid protocol shown by tcpdump and shifted bytes at offset 7 and > 8 (it reads 0x403a but should be 0x3a40). > > After changing dummynet rule to: > > add pipe 24 ip4 from any to any in recv vlan1 > add pipe 25 ip4 from any to any out xmit vlan1 > > packets are no longer malformed: > > 11:01:49.934348 IP6 fe80::215:17ff:feae:4d99> ff02::1: ICMP6, echo request, seq > 0, length 16 > 0x0000: 6000 0000 0010 3a40 fe80 0000 0000 0000 `.....:@........ > 0x0010: 0215 17ff feae 4d99 ff02 0000 0000 0000 ......M......... > 0x0020: 0000 0000 0000 0001 8000 ab9a 3341 0000 ............3A.. > 0x0030: 4eb7 ac8d 000e 41a5 N.....A. > > The above problem affects 8.2-STABLE compiled on 3rd May 2011. > Looks like you ran into kern/157239. From owner-freebsd-net@FreeBSD.ORG Wed Nov 9 08:51:56 2011 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 0488C106566B for ; Wed, 9 Nov 2011 08:51:56 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7265E8FC15 for ; Wed, 9 Nov 2011 08:51:54 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1583666bkb.13 for ; Wed, 09 Nov 2011 00:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OuT/KNioE51jFMIPJ09icQKCPKSDard8FMAD4D8NlQ8=; b=Ar/86XYhUJ4dab3pXXLdn+sQsHwiO64ty2a/+6x2nHXSDN4O3XyPyfWaOTeiNurUDw QqG8jxZXrMIWVTczzCEJEob3mB22xi4nbp6mLxdltEMKCvRpZa1vswlOaMDFGHiQ3PAq xhk31Q1C1NhifAOrn+zFIChlM6RG8SqUfVFI0= Received: by 10.204.16.67 with SMTP id n3mr995329bka.6.1320828713993; Wed, 09 Nov 2011 00:51:53 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id fu17sm4050614bkc.9.2011.11.09.00.51.50 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 00:51:53 -0800 (PST) Message-ID: <4EBA3F22.2060204@gmail.com> Date: Wed, 09 Nov 2011 12:21:46 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Adrian Chadd References: <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Emil Muratov , Jack Vogel , Jason Wolfe Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 09 Nov 2011 08:51:56 -0000 On 11/8/2011 11:00 PM, Adrian Chadd wrote: > On 8 November 2011 09:21, Hooman Fazaeli wrote: > >> With MSIX enabled, the link task (em_handle_link) does _not_ triggers >> _start when the link changes state from inactive to active (which it >> should). >> If if_snd quickly fills up during a temporary link loss, transmission is >> stopped forever and the driver never recovers from that state. >> >> The last patch should have reduced the frequency of the problem >> but it assumes every IFQ_ENQUEUE is followed by a if_start which >> is not a true assumption. > > FWIW, I saw something very similar with the if_arge code port from > Linux. If the TX queue filled up and wasn't serviced before it hit > completely full, it was never drained. > > It may be worthwhile auditing some of the other NIC drivers to ensure > this kind of situation isn't occuring. Especially if they came from > Linux. :-) > > That's a great catch, I hope it finally fixes the if_em issues with MSIX. :-) > > > Adrian Just for the record, I should inform you that igb, ixgb and ixbge have the same issue. I have not checked other drivers. And there is another subtle problem with all these drivers: if transmit (xxx_xmit) fails for a temporary memory shortage (i.e., DMA failure for ENOMEM), the driver may enter the OACTIVE state and _never_ recovers! The scenario is somehow as before: - if_start is executed. - xxx_xmit fails with ENOMEM. - xxx_start_locked sets OACTIVE. Note that this is different from a low TX descriptor condition which also sets OACTIVE. - stack enqueues packets in if_snd but does not call if_start since driver is OACTIVE. - stack enqueues more packets until if_snd fills up and packets start to drop. - Since there is nowhere in the driver's code to re-try transmission when memory becomes available again (xxx_local_timer is a candidate), the driver remains OACTIVE forever until it is re-initialized. I am working on patches for em/igb/ixgb/ixgbe to fix these issues and would be happy to share them with anyone who is interested. since these are really severe problems, I hope gurus apply official fixes ASAP. From owner-freebsd-net@FreeBSD.ORG Wed Nov 9 08:55:08 2011 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 7A658106566C for ; Wed, 9 Nov 2011 08:55:08 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E53808FC23 for ; Wed, 9 Nov 2011 08:55:07 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1586079bkb.13 for ; Wed, 09 Nov 2011 00:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=HdifiK+eyWmIviM/hLOKVuk/Ep2V2O2wYOS1RitFKp4=; b=seqEDZjexXjCgx+LHAt1NIZ8q8BQm34OohiQtLR/LwzEuqlAWx4jagvup/LEvZMQEO bTYaM9ULghyuGHNAYFbhpKUSyZigRUq8nfWlyuUa2x6Z70FFkh5v0zcYSHHfclWc9iJy QYlCZ6+WlBiytxFjxWTEp1pIfnn6wbfRlskvw= Received: by 10.204.156.133 with SMTP id x5mr963597bkw.87.1320828906814; Wed, 09 Nov 2011 00:55:06 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id q6sm4072437bka.6.2011.11.09.00.55.03 (version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 00:55:06 -0800 (PST) Message-ID: <4EBA3FE4.3050106@gmail.com> Date: Wed, 09 Nov 2011 12:25:00 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Jason Wolfe References: <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 09 Nov 2011 08:55:08 -0000 On 11/8/2011 10:23 PM, Jason Wolfe wrote: > On Tue, Nov 8, 2011 at 10:21 AM, Hooman Fazaeli > wrote: > > I have allocated more time to the problem and guess I can explain what > your problem is. > > With MSIX disabled, the driver uses fast interrupt handler (em_irq_fast) > which calls rx/tx task and then checks for link status change. This > implies that rx/tx task is executed with every link state change. This is > not efficient, as it is a waste of time to start transmission when link is down. > However, it has the effect that after a temporary link loss (active->inactive->active), > _start is executed and transmission continues normally. The value of link_toggles (3) > clearly indicates that you had such a transition when the problem occured. > > With MSIX enabled, the link task (em_handle_link) does _not_ triggers > _start when the link changes state from inactive to active (which it should). > If if_snd quickly fills up during a temporary link loss, transmission is > stopped forever and the driver never recovers from that state. > > The last patch should have reduced the frequency of the problem > but it assumes every IFQ_ENQUEUE is followed by a if_start which > is not a true assumption. > > If you are willing to test, I can prepare another patch for you to fix > the issue in a different and more reliable way. > > > Hooman, > > Thanks again for the assist, it sounds like this may also be why we see a bit higher latency with MSI-X disabled on this chipset. > > I'm happy to test any patches as I have a handful of boxes set aside to 'research' this issue. Hopefully the testing here helps along any patches to the tree for others benefit also. > > Jason Latency may or may not be related. I am doing more tests and will post my findings soon. From owner-freebsd-net@FreeBSD.ORG Wed Nov 9 12:49:06 2011 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 25E80106564A for ; Wed, 9 Nov 2011 12:49:06 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8A808FC19 for ; Wed, 9 Nov 2011 12:49:05 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so1798976bkb.13 for ; Wed, 09 Nov 2011 04:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=6fks+xN3KkGoFxwPoIh5rZWBT8QttjAH4ZkLjkdKXZU=; b=hP4ScrqU8ffF7LZJbklN2GPUhLcRB0fg3zYb08zoz/c9DA/IhOBxQ51EW8/sLYCTkr 3FmayI0IeJMyCqovR84w7Ba/arCYXZolHAUBwLTkLNc9lvA9gXQYsRtVbmPHbMPr1ZWq 1BIlx72y6DxHDXuV9QRs6ByRFLG77Yj6AQ8iE= MIME-Version: 1.0 Received: by 10.152.106.115 with SMTP id gt19mr1449909lab.27.1320842944410; Wed, 09 Nov 2011 04:49:04 -0800 (PST) Received: by 10.152.9.10 with HTTP; Wed, 9 Nov 2011 04:49:04 -0800 (PST) In-Reply-To: References: Date: Wed, 9 Nov 2011 16:49:04 +0400 Message-ID: From: Pavel Timofeev To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Possible MROUTING regression in 9.0 RC1 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, 09 Nov 2011 12:49:06 -0000 Crashes is often, even on different hardware (another server) [root@timp ~]# /usr/local/sbin/igmpproxy -dvv /usr/local/etc/igmpproxy.conf Searching for config file at '/usr/local/etc/igmpproxy.conf' Config: Quick leave mode enabled. Config: Got a phyint token. Config: IF: Config for interface re0. Config: IF: Got upstream token. Config: IF: Got ratelimit token '0'. Config: IF: Got threshold token '1'. Config: IF: Got altnet token 172.31.242.0/24. Config: IF: Altnet: Parsed altnet to 172.31.242/24. IF name : re0 Next ptr : 0 Ratelimit : 0 Threshold : 1 State : 1 Allowednet ptr : c71040 Config: Got a phyint token. Config: IF: Config for interface bridge0. Config: IF: Got downstream token. Config: IF: Got ratelimit token '0'. Config: IF: Got threshold token '1'. IF name : bridge0 Next ptr : 0 Ratelimit : 0 Threshold : 1 State : 2 Allowednet ptr : 0 Config: Got a phyint token. Config: IF: Config for interface lo0. Config: IF: Got disabled token. IF name : lo0 Next ptr : 0 Ratelimit : 0 Threshold : 1 State : 0 Allowednet ptr : 0 Config: Got a phyint token. Config: IF: Config for interface plip0. Config: IF: Got disabled token. IF name : plip0 Next ptr : 0 Ratelimit : 0 Threshold : 1 State : 0 Allowednet ptr : 0 buildIfVc: Interface re0 Addr: 10.85.13.39, Flags: 0xffff8843, Network: 10.85.13/24 buildIfVc: Interface lo0 Addr: 127.0.0.1, Flags: 0xffff8049, Network: 127/8 buildIfVc: Interface bridge0 Addr: 172.16.254.1, Flags: 0xffff8843, Network: 172.16.254/24 Found config for re0 Found config for bridge0 adding VIF, Ix 0 Fl 0x0 IP 0x270d550a re0, Threshold: 1, Ratelimit: 0 Network for [re0] : 10.85.13/24 Network for [re0] : 172.31.242/24 adding VIF, Ix 1 Fl 0x0 IP 0x01fe10ac bridge0, Threshold: 1, Ratelimit: 0 Network for [bridge0] : 172.16.254/24 Got 262144 byte buffer size in 0 iterations Joining all-routers group 224.0.0.2 on vif 172.16.254.1 joinMcGroup: 224.0.0.2 on bridge0 SENT Membership query from 172.16.254.1 to 224.0.0.1 Sent membership query from 172.16.254.1 to 224.0.0.1. Delay: 10 Created timeout 1 (#0) - delay 10 secs (Id:1, Time:10) Created timeout 2 (#1) - delay 21 secs (Id:1, Time:10) (Id:2, Time:21) received packet from 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) received packet from 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) About to call timeout 1 (#0) Aging routes in table. Current routing table (Age active routes): ----------------------------------------------------- No routes in table... ----------------------------------------------------- received packet from 10.85.13.5 shorter (28 bytes) than hdr+data length (20= +28) ^Cselect() failure; Errno(4): Interrupted system call Got a interupt signal. Exiting. clean handler called All routes removed. Routing table is empty. Shutdown complete.... 2011/11/8 Pavel Timofeev : > And sometimes igmpproxy's shutdown lead to crash of my system. > Without any panics, it just reboots. oO > > 2011/11/7 Pavel Timofeev : >> Hello! I have problems with ip_mroute (loaded as module) - kernel >> multicast packet forwarder. >> I have 2 disk: freebsd 8.2 release amd64 on first and freebsd 9.0 rc1 on= second. >> I use net/igmpproxy to watch IPTV on my home atom-based router. >> >> On FreeBSD 8.2 it works good. >> >> But when I try to use FreeBSD 9.0 RC-1 in same role (with same >> configs, of cource) I have messages like: >> Nov =C2=A07 16:16:46 timp igmpproxy[35495]: received packet from >> 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) >> Nov =C2=A07 16:16:47 timp igmpproxy[35495]: received packet from >> 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) >> Nov =C2=A07 16:17:28 timp igmpproxy[35495]: received packet from 10.85.1= 3.5 >> shorter (28 bytes) than hdr+data length (20+28) >> And IPTV doesn't work =3D( >> >> Any ideas? >> Do you need configs? >> > From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 00:09:59 2011 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 909BB106566B for ; Thu, 10 Nov 2011 00:09:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EBDA8FC19 for ; Thu, 10 Nov 2011 00:09:59 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so2783564vcb.13 for ; Wed, 09 Nov 2011 16:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1vLD6ijuFmuiGGfS5wFpJEhTlHRSWrSSID6kTp9TUSo=; b=FgfWfVmgKG/e+LITxe4AEeqj4kSoc+3jPlukstFTkirrXI5oScgT+91thZn5gjZ9yz p83SuimT5WZyb+tFNsAJw5cbuc2gd98jGYMGJ+BjcNb5hqvoE+G3QASP27QXhMnX19Za HGLLGmCP0ibg5EaA/JZpT8rH9QEwh4ncW65yA= MIME-Version: 1.0 Received: by 10.52.24.210 with SMTP id w18mr8659384vdf.21.1320883798563; Wed, 09 Nov 2011 16:09:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Wed, 9 Nov 2011 16:09:58 -0800 (PST) In-Reply-To: <4EBA3F22.2060204@gmail.com> References: <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> Date: Wed, 9 Nov 2011 16:09:58 -0800 X-Google-Sender-Auth: yDvqth2XD3R98JCSesCWvb6EFsA Message-ID: From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 00:09:59 -0000 There's no locking around the OACTIVE flag set/clear, right? Is it possible that multiple TX threads are fiddling with OACTIVE and then it's not being properly cleared and tx kicked? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 01:50:45 2011 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 1B28A106566B for ; Thu, 10 Nov 2011 01:50:45 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E37E18FC0C for ; Thu, 10 Nov 2011 01:50:44 +0000 (UTC) Received: by iakl21 with SMTP id l21so1009526iak.13 for ; Wed, 09 Nov 2011 17:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LSdiCj36VmrXHg6jI9z9zp5qpAdaIHDRFHv697qWlaw=; b=vHC1UBG3EXdRAbIS/eCOKkW1mcIH3Wpr9JL5Lt3/bKAxKZU/JDbv/sdMc8GMG7zUrb bkpp1ObZsz7YSPmBUxsU9asFGyyXNBdxrXqi7tGApjynRsSyNsZSSzp0v+NNmUkQXNzj t1O6SH61WNqFJOntMBoRhn2iDO6HcUvb13tGQ= MIME-Version: 1.0 Received: by 10.50.12.227 with SMTP id b3mr5649696igc.24.1320888264631; Wed, 09 Nov 2011 17:24:24 -0800 (PST) Received: by 10.231.14.68 with HTTP; Wed, 9 Nov 2011 17:24:24 -0800 (PST) Date: Wed, 9 Nov 2011 17:24:24 -0800 Message-ID: From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ipf(8) for TCP rate limiting 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, 10 Nov 2011 01:50:45 -0000 Hi. My machine has some ipf(8) rules and I see that when there is a TCP connection storm to the http port the filer sends out TCP resets. I wanted to know if its possible to configure the pps limit for TCP connections before the RSTs kick in using ipf. regards, vijay From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 05:00:25 2011 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 45D611065675 for ; Thu, 10 Nov 2011 05:00:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3AC8FC08 for ; Thu, 10 Nov 2011 05:00:16 +0000 (UTC) Received: by wwg14 with SMTP id 14so1193369wwg.31 for ; Wed, 09 Nov 2011 21:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LkbnL1EZ0ObTkNdKgkoalz+o91ciHFpCNRFFgyqdzI8=; b=WeXpJyy/ZmVfry5VpUb5oiH5Syj+rDuqXie6b//VCKqtZn7bvJupYyjt+BM4Bd8AjN gfxQ674T5OBKRQWbOw8iJ7uvgOXJqPJ+Tu+Bsd8Sgyt2+PcRHn1wHAMvpqIDxf5ALyVI oZoJ11a/8Q4lV4bnjSS0oRfmfe3ypoSd/lU3E= MIME-Version: 1.0 Received: by 10.180.90.6 with SMTP id bs6mr6625829wib.63.1320901216130; Wed, 09 Nov 2011 21:00:16 -0800 (PST) Received: by 10.180.95.229 with HTTP; Wed, 9 Nov 2011 21:00:16 -0800 (PST) In-Reply-To: References: <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> Date: Wed, 9 Nov 2011 21:00:16 -0800 Message-ID: From: Jack Vogel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Emil Muratov , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 05:00:25 -0000 Hmmm, that's an interesting point Adrian, I'll look at that more closely. Jack On Wed, Nov 9, 2011 at 4:09 PM, Adrian Chadd wrote: > There's no locking around the OACTIVE flag set/clear, right? > Is it possible that multiple TX threads are fiddling with OACTIVE and > then it's not being properly cleared and tx kicked? > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 05:04:17 2011 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 5ACE21065672 for ; Thu, 10 Nov 2011 05:04:17 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D00448FC0C for ; Thu, 10 Nov 2011 05:04:16 +0000 (UTC) Received: by wyf23 with SMTP id 23so92118wyf.13 for ; Wed, 09 Nov 2011 21:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+54yI/OiXFWn1TcFjd/IOZzwtHLHjCZZSA95gcoK/Fk=; b=kucwUFVWHWCS2ohvlfQuQUrtQ/HulqoHEXe8lg3k50FXvDGOG2ubrKzJeUibaNETgk FbKM/yTgky2oHjW+MfUQBWARlU9vaqHCPVQYRsJLqKpTLr5JnU37e35S4D+KPfKZfvqd WOVgWeck7hmREC/gNLvHOdxnEpDoqnrQjlJJE= MIME-Version: 1.0 Received: by 10.180.93.168 with SMTP id cv8mr6714396wib.36.1320901455668; Wed, 09 Nov 2011 21:04:15 -0800 (PST) Received: by 10.180.95.229 with HTTP; Wed, 9 Nov 2011 21:04:15 -0800 (PST) In-Reply-To: References: <4E8F51D4.1060509@sentex.net> <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> Date: Wed, 9 Nov 2011 21:04:15 -0800 Message-ID: From: Jack Vogel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Emil Muratov , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 05:04:17 -0000 BTW, the new delta on the driver is coming, I just ran into some issues with the validation testing done in house and I've had to iron a few things out. I am going to implement Hooman's idea of a TX clean from local_timer, that seems like a good idea. The other thing I'm doing right now is reenabling the MULTIQUEUE define and looking at 82574 performance, once I did that I found certain pieces that needed tweaking. The jury is still out on whether or not this is worth doing, but I'm making it possible for people to try for themselves. Anyone that really wants to try this driver early might want to send me some directed email. Jack On Wed, Nov 9, 2011 at 9:00 PM, Jack Vogel wrote: > Hmmm, that's an interesting point Adrian, I'll look at that more closely. > > Jack > > > > On Wed, Nov 9, 2011 at 4:09 PM, Adrian Chadd wrote: > >> There's no locking around the OACTIVE flag set/clear, right? >> Is it possible that multiple TX threads are fiddling with OACTIVE and >> then it's not being properly cleared and tx kicked? >> >> >> Adrian >> > > From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 06:51:37 2011 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 4369F106564A for ; Thu, 10 Nov 2011 06:51:37 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 807798FC0C for ; Thu, 10 Nov 2011 06:51:36 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pAA6pZ0U040473; Thu, 10 Nov 2011 10:51:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pAA6pZWI040472; Thu, 10 Nov 2011 10:51:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 10 Nov 2011 10:51:35 +0400 From: Gleb Smirnoff To: Alexander Wittig Message-ID: <20111110065135.GS71907@FreeBSD.org> References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline In-Reply-To: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD 9 and ARP multicast source address error messages 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, 10 Nov 2011 06:51:37 -0000 --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Alexander, On Tue, Nov 08, 2011 at 05:14:45PM -0500, Alexander Wittig wrote: A> I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011 root@bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX i386), and ever since that upgrade the kernel keeps flooding my log files with messages like these: A> Nov 7 16:40:01 bt kernel: in_arp: source hardware address is multicast.in_arp: source hardware address is multicast. A> Nov 7 16:42:02 bt kernel: in_arp: source hardware address is multicast.in_arp: source hardware address is multicast. A> A> A Google search for these didn't reveal any useful results as to why this happens or how to fix it. So I did a tcpdump and matched the time stamps with packets, and I found the ones causing problems (the only ones with a multicast bit set) to be like this: A> 16:40:01.099823 02:02:23:09:44:3c > 03:bf:23:09:44:87, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 35.9.68.228 is-at 03:bf:23:09:44:e4, length 46 A> 0x0000: 03bf 2309 4487 0202 2309 443c 0806 0001 A> 0x0010: 0800 0604 0002 03bf 2309 44e4 2309 44e4 A> 0x0020: 02bf 2309 443c 2309 4487 0000 0000 0000 A> 0x0030: 0000 0000 0000 0000 0000 0000 A> A> It appears the broadcast MAC 03:bf:23:09:44:87 is part of Microsoft's network load balancing mechanism, with the 03:bf indicating that much and the 23:09:44:87 containing the IP address of the load balance cluster (35.9.68.228). These types of MACs seem to be commonly used in their load balancing implementation. A> A> To prevent these messages from producing thousands of lines of logs each day, I added the following two IPFW rules and enabled ethernet package filtering (sysctl net.link.ether.ipfw=1): A> deny ip from any to any MAC 03:bf:00:00:00:00/16 any layer2 A> allow ip from any to any layer2 A> A> This effectively blocks those packages and the resulting error messages. But I'm wondering if the newly added(?) ARP code in FBSD 9 is a bit too fussy about these, or if MS is abusing the ARP protocol here. Either way, this was never a problem with FBSD 7 or 8. Can you try attached patch. It reduces severity level of all ARP messages, that can be triggered by packet on network, with expection to "using my IP address". With default syslog.conf, now ARP errors won't get to console. Also, the multicast message lacked "\n" newline character, that's why, I suppose, syslogd failed to coalesce a number of messages into a single entry "last message repeated X times". -- Totus tuus, Glebius. --uZ3hkaAS1mZxFaxD Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_ether.c.diff" Index: if_ether.c =================================================================== --- if_ether.c (revision 227416) +++ if_ether.c (working copy) @@ -433,7 +433,7 @@ if (m->m_len < sizeof(struct arphdr) && ((m = m_pullup(m, sizeof(struct arphdr))) == NULL)) { - log(LOG_ERR, "arp: runt packet -- m_pullup failed\n"); + log(LOG_NOTICE, "arp: runt packet -- m_pullup failed\n"); return; } ar = mtod(m, struct arphdr *); @@ -443,7 +443,7 @@ ntohs(ar->ar_hrd) != ARPHRD_ARCNET && ntohs(ar->ar_hrd) != ARPHRD_IEEE1394 && ntohs(ar->ar_hrd) != ARPHRD_INFINIBAND) { - log(LOG_ERR, "arp: unknown hardware address format (0x%2D)\n", + log(LOG_NOTICE, "arp: unknown hardware address format (0x%2D)\n", (unsigned char *)&ar->ar_hrd, ""); m_freem(m); return; @@ -451,7 +451,7 @@ if (m->m_len < arphdr_len(ar)) { if ((m = m_pullup(m, arphdr_len(ar))) == NULL) { - log(LOG_ERR, "arp: runt packet\n"); + log(LOG_NOTICE, "arp: runt packet\n"); m_freem(m); return; } @@ -527,7 +527,7 @@ req_len = arphdr_len2(ifp->if_addrlen, sizeof(struct in_addr)); if (m->m_len < req_len && (m = m_pullup(m, req_len)) == NULL) { - log(LOG_ERR, "in_arp: runt packet -- m_pullup failed\n"); + log(LOG_NOTICE, "in_arp: runt packet -- m_pullup failed\n"); return; } @@ -537,13 +537,14 @@ * a protocol length not equal to an IPv4 address. */ if (ah->ar_pln != sizeof(struct in_addr)) { - log(LOG_ERR, "in_arp: requested protocol length != %zu\n", + log(LOG_NOTICE, "in_arp: requested protocol length != %zu\n", sizeof(struct in_addr)); return; } if (ETHER_IS_MULTICAST(ar_sha(ah))) { - log(LOG_ERR, "in_arp: source hardware address is multicast."); + log(LOG_NOTICE, "in_arp: %*D is multicast\n", + ifp->if_addrlen, (u_char *)ar_sha(ah), ":"); return; } @@ -645,7 +646,7 @@ if (!bcmp(ar_sha(ah), enaddr, ifp->if_addrlen)) goto drop; /* it's from me, ignore it. */ if (!bcmp(ar_sha(ah), ifp->if_broadcastaddr, ifp->if_addrlen)) { - log(LOG_ERR, + log(LOG_NOTICE, "arp: link address is broadcast for IP address %s!\n", inet_ntoa(isaddr)); goto drop; @@ -681,7 +682,7 @@ /* the following is not an error when doing bridging */ if (!bridged && la->lle_tbl->llt_ifp != ifp && !carp_match) { if (log_arp_wrong_iface) - log(LOG_ERR, "arp: %s is on %s " + log(LOG_WARNING, "arp: %s is on %s " "but got reply from %*D on %s\n", inet_ntoa(isaddr), la->lle_tbl->llt_ifp->if_xname, @@ -716,10 +717,10 @@ if (ifp->if_addrlen != ah->ar_hln) { LLE_WUNLOCK(la); - log(LOG_WARNING, - "arp from %*D: addr len: new %d, i/f %d (ignored)", - ifp->if_addrlen, (u_char *) ar_sha(ah), ":", - ah->ar_hln, ifp->if_addrlen); + log(LOG_WARNING, "arp from %*D: addr len: new %d, " + "i/f %d (ignored)\n", ifp->if_addrlen, + (u_char *) ar_sha(ah), ":", ah->ar_hln, + ifp->if_addrlen); goto drop; } (void)memcpy(&la->ll_addr, ar_sha(ah), ifp->if_addrlen); --uZ3hkaAS1mZxFaxD-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 08:10:59 2011 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 60EE71065672 for ; Thu, 10 Nov 2011 08:10:59 +0000 (UTC) (envelope-from gpm@hotplug.ru) Received: from gate.pikinvest.ru (gate.pikinvest.ru [87.245.155.170]) by mx1.freebsd.org (Postfix) with ESMTP id 144CE8FC14 for ; Thu, 10 Nov 2011 08:10:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailgate.pik.ru (Postfix) with ESMTP id 2DA031C086E; Thu, 10 Nov 2011 11:10:56 +0300 (MSK) Received: from EX03PIK.PICompany.ru (unknown [192.168.156.51]) by mailgate.pik.ru (Postfix) with ESMTP id 2BABA1C0845; Thu, 10 Nov 2011 11:10:56 +0300 (MSK) Received: from EX21PIK.PICompany.ru ([192.168.156.131]) by EX03PIK.PICompany.ru with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 12:10:40 +0400 Received: from [192.168.148.9] (192.168.148.9) by EX21PIK.PICompany.ru (192.168.156.131) with Microsoft SMTP Server id 14.1.218.12; Thu, 10 Nov 2011 12:10:40 +0400 Message-ID: <4EBB86E8.6030206@hotplug.ru> Date: Thu, 10 Nov 2011 12:10:16 +0400 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Pavel Timofeev References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2011 08:10:40.0978 (UTC) FILETIME=[3CB13B20:01CC9F80] Cc: freebsd-net@freebsd.org Subject: Re: Possible MROUTING regression in 9.0 RC1 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, 10 Nov 2011 08:10:59 -0000 igmpproxy is an ugly hack. It was more or less working on 7.x, but very unstable. igmpproxy project is frozen, no updates since 2009. You can try udpxy as an alternative. > And sometimes igmpproxy's shutdown lead to crash of my system. > Without any panics, it just reboots. oO > > 2011/11/7 Pavel Timofeev: >> Hello! I have problems with ip_mroute (loaded as module) - kernel >> multicast packet forwarder. >> I have 2 disk: freebsd 8.2 release amd64 on first and freebsd 9.0 rc1 on second. >> I use net/igmpproxy to watch IPTV on my home atom-based router. >> >> On FreeBSD 8.2 it works good. >> >> But when I try to use FreeBSD 9.0 RC-1 in same role (with same >> configs, of cource) I have messages like: >> Nov 7 16:16:46 timp igmpproxy[35495]: received packet from >> 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) >> Nov 7 16:16:47 timp igmpproxy[35495]: received packet from >> 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) >> Nov 7 16:17:28 timp igmpproxy[35495]: received packet from 10.85.13.5 >> shorter (28 bytes) than hdr+data length (20+28) >> And IPTV doesn't work =( >> >> Any ideas? >> Do you need configs? >> > _______________________________________________ > 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 Nov 10 08:12:52 2011 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 101B31065672 for ; Thu, 10 Nov 2011 08:12:52 +0000 (UTC) (envelope-from kang.chen@nsn.com) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8A38FC17 for ; Thu, 10 Nov 2011 08:12:50 +0000 (UTC) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAA7kXDn020469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Nov 2011 08:46:33 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAA7kXVC016518 for ; Thu, 10 Nov 2011 08:46:33 +0100 Received: from CNBEEXC006.nsn-intra.net ([10.159.192.11]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 08:46:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 x-cr-hashedpuzzle: AREa BNZl BwYj B0u5 B+uP CC95 Cd31 C89F DzCg FwZk Fyz6 G9Ld HU51 ID2p Jr/x L3Ke; 1; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnAA==; Sosha1_v1; 7; {E5FE30EA-1104-44AA-84BA-7D80B42C81EF}; awBhAG4AZwAuAGMAaABlAG4AQABuAHMAbgAuAGMAbwBtAA==; Thu, 10 Nov 2011 07:45:11 GMT; UAByAG8AYgBsAGUAbQAgAHcAaQB0AGgAIABzAGIAZAByAG8AcAAgAHAAYQBuAGkAYwA= x-cr-puzzleid: {E5FE30EA-1104-44AA-84BA-7D80B42C81EF} Content-class: urn:content-classes:message Date: Thu, 10 Nov 2011 15:45:11 +0800 Message-ID: <4E06CB69D1F4FE48911C9CAB689E2B0101FCE3A6@CNBEEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem with sbdrop panic Thread-Index: AcyffK0vjxRfl2ylTGSpyxfvsxm7TA== From: "Chen, Kang (NSN - CN/Hangzhou)" To: X-OriginalArrivalTime: 10 Nov 2011 07:46:32.0829 (UTC) FILETIME=[DD873AD0:01CC9F7C] Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with sbdrop panic 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, 10 Nov 2011 08:12:52 -0000 Hi, freebsd expert I'm using freebsd 6.2 version and I encounter a sbdrop panic problem. I establish several sctp association between client and server, after I restart the client, then the server also restart caused by sbdrop panic. Hopefully can get your help with this problem. Best Regards, Chen Kang 2011-11-10 From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 08:15:13 2011 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 0C07F106564A for ; Thu, 10 Nov 2011 08:15:13 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9577F8FC1B for ; Thu, 10 Nov 2011 08:15:12 +0000 (UTC) Received: by faar19 with SMTP id r19so3558674faa.13 for ; Thu, 10 Nov 2011 00:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hyJC+BWxxUIBwVGyCOyLzTX0h3MeZduZAxy697WdIrE=; b=vUjMoi5VL+vBhDLrijeaISiuSeBqHbYaMBu6OdwNP6gnowlmrhJ9ME1/eM2dOvAY4a u0IuoO40wYyl/tVGuqVO9aFSJsSq9svs2q//A9SjMtuZZiigguhBBdRO5RlwEGA8cjLs mpAJ7WmM+/BGF/IjN8aCxn7aryFFzOwGeDIdw= MIME-Version: 1.0 Received: by 10.152.144.73 with SMTP id sk9mr3857852lab.34.1320912911384; Thu, 10 Nov 2011 00:15:11 -0800 (PST) Received: by 10.152.9.10 with HTTP; Thu, 10 Nov 2011 00:15:11 -0800 (PST) In-Reply-To: <4EBB86E8.6030206@hotplug.ru> References: <4EBB86E8.6030206@hotplug.ru> Date: Thu, 10 Nov 2011 12:15:11 +0400 Message-ID: From: Pavel Timofeev To: Emil Muratov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Possible MROUTING regression in 9.0 RC1 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, 10 Nov 2011 08:15:13 -0000 Thank you! I'll try! I'm going crazy. Now I can crash even FreeBSD 8.2 RELEASE with igmpproxy in some coincidence= . I can get kernel dump on 8.2, and can try to get dump on 9.0-RC1. Is it interesting? 2011/11/10 Emil Muratov : > > igmpproxy is an ugly hack. It was more or less working on 7.x, but very > unstable. igmpproxy project is frozen, no updates since 2009. > You can try udpxy as an alternative. > >> And sometimes igmpproxy's shutdown lead to crash of my system. >> Without any panics, it just reboots. oO >> >> 2011/11/7 Pavel Timofeev: >>> >>> Hello! I have problems with ip_mroute (loaded as module) - kernel >>> multicast packet forwarder. >>> I have 2 disk: freebsd 8.2 release amd64 on first and freebsd 9.0 rc1 o= n >>> second. >>> I use net/igmpproxy to watch IPTV on my home atom-based router. >>> >>> On FreeBSD 8.2 it works good. >>> >>> But when I try to use FreeBSD 9.0 RC-1 in same role (with same >>> configs, of cource) I have messages like: >>> Nov =C2=A07 16:16:46 timp igmpproxy[35495]: received packet from >>> 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) >>> Nov =C2=A07 16:16:47 timp igmpproxy[35495]: received packet from >>> 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) >>> Nov =C2=A07 16:17:28 timp igmpproxy[35495]: received packet from 10.85.= 13.5 >>> shorter (28 bytes) than hdr+data length (20+28) >>> And IPTV doesn't work =3D( >>> >>> Any ideas? >>> Do you need configs? >>> >> _______________________________________________ >> 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 Nov 10 09:31:44 2011 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 0CE17106566B for ; Thu, 10 Nov 2011 09:31:44 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (mail-n.franken.de [193.175.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id C69348FC1B for ; Thu, 10 Nov 2011 09:31:43 +0000 (UTC) Received: from [192.168.1.200] (p508FCCA5.dip.t-dialin.net [80.143.204.165]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BE1D21C0B461B; Thu, 10 Nov 2011 10:07:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4E06CB69D1F4FE48911C9CAB689E2B0101FCE3A6@CNBEEXC006.nsn-intra.net> Date: Thu, 10 Nov 2011 10:07:46 +0100 Content-Transfer-Encoding: 7bit Message-Id: <13D67AA2-80A6-4854-AC03-CF4B76424BFB@lurchi.franken.de> References: <4E06CB69D1F4FE48911C9CAB689E2B0101FCE3A6@CNBEEXC006.nsn-intra.net> To: "Chen, Kang (NSN - CN/Hangzhou)" X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-net@freebsd.org Subject: Re: Problem with sbdrop panic 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, 10 Nov 2011 09:31:44 -0000 On Nov 10, 2011, at 8:45 AM, Chen, Kang (NSN - CN/Hangzhou) wrote: > Hi, freebsd expert > > I'm using freebsd 6.2 version and I encounter a sbdrop panic problem. Are you really using 6.2? This version is very old? Can you upgrade to one of the 9.0 release candidates and see if the problem persists? > I establish several sctp association between client and server, after I > restart the client, then the server also restart caused by sbdrop panic. > Hopefully can get your help with this problem. What you you mean by "restart the client"? Best regards Michael > > > Best Regards, > Chen Kang > 2011-11-10 > _______________________________________________ > 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 Nov 10 09:44:10 2011 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 D0EA21065672; Thu, 10 Nov 2011 09:44:10 +0000 (UTC) (envelope-from hoomanfazaeli@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 24C958FC0C; Thu, 10 Nov 2011 09:44:09 +0000 (UTC) Received: by eyd10 with SMTP id 10so2799102eyd.13 for ; Thu, 10 Nov 2011 01:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AcdJgqSe6Rvs52VZI6aGzXRI49D8bbEeHUfMjqZ1/2c=; b=pssM/gtvQKuvTYe76sqszZ7eyX7nVg7jo3mjqBSkPgip7QOBZygQa6YHm1UVyH/vsH y1BWbsH+jFSviPxwMbMiZ7mP3wGrXIzOJ2oQ3vGIome5jANBgurZphCEKztjdXFZbFRm WN/KlL+dumleBwshWQGHO+FGFC/LM9RILIPuo= Received: by 10.213.4.142 with SMTP id 14mr525907ebr.63.1320918249060; Thu, 10 Nov 2011 01:44:09 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id v3sm20965991eej.7.2011.11.10.01.44.04 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 01:44:08 -0800 (PST) Message-ID: <4EBB9CDF.9090300@gmail.com> Date: Thu, 10 Nov 2011 13:13:59 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Adrian Chadd References: <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 09:44:11 -0000 On 11/10/2011 3:39 AM, Adrian Chadd wrote: > There's no locking around the OACTIVE flag set/clear, right? > Is it possible that multiple TX threads are fiddling with OACTIVE and > then it's not being properly cleared and tx kicked? > > > Adrian If we check for OACTIVE periodically (for instance, in local_timer) and under transient resource shortage, the driver will finally end up with OACTIVE cleared. Under frequent resource shortages, the driver may remain OACTIVE longer than it is ~OACTIVE or it may constantly toggles but there is not much the driver can do about this and a simple locking around OACTIVE set/clear does not change the situation. The problem _is_ low resources and the only fix is to increase it. The problems we should focus on here are two things: 1- The driver _must_ be able to recover from OACTIVE after transient resource shortages. 2- It is desirable to do this as fast as possible. Doing recovery in local_timer accommodates the first need but it is very far from from the second. One possible solution for 2 would be to defer setting OACTIVE until N consecutive transmissions fail (i.e., N == 75% (if_snd.ifq_maxlen - if_snd.ifq_len)). The overhead is a little wasted cpu time in longer OACTIVE states. We still need local_timer to recover from these states. From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 09:46:59 2011 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 9CDB31065674; Thu, 10 Nov 2011 09:46:59 +0000 (UTC) (envelope-from hoomanfazaeli@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 ECA458FC19; Thu, 10 Nov 2011 09:46:57 +0000 (UTC) Received: by eyd10 with SMTP id 10so2800881eyd.13 for ; Thu, 10 Nov 2011 01:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aqAQdJ5Yv6MTr6P+KhQCzks6D6lWsdAn6DoGUZ1X00c=; b=qvYZgSNKIaPCfuB2HNknfFAvII3lZQ0jd8HREImsgCvvnuYz+uKwCFrAzn1grUW1Yo OjpBwq3ETPzkcVb44ruiTSvVLTsCBj8eJG93pOnnTMC9TF3rC9KFT30mUZGpxAC11pJG +n7k07eyYzApwzxFNQ/BTwcLv5Kiy8nP2peW8= Received: by 10.14.7.78 with SMTP id 54mr457724eeo.164.1320918417262; Thu, 10 Nov 2011 01:46:57 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id z58sm21017284eea.3.2011.11.10.01.46.53 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 01:46:56 -0800 (PST) Message-ID: <4EBB9D88.4030304@gmail.com> Date: Thu, 10 Nov 2011 13:16:48 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: Adrian Chadd References: <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 09:46:59 -0000 On 11/10/2011 3:39 AM, Adrian Chadd wrote: > There's no locking around the OACTIVE flag set/clear, right? > Is it possible that multiple TX threads are fiddling with OACTIVE and > then it's not being properly cleared and tx kicked? > > > Adrian sorry! I forgot to cleanup the the last message ... here is the correct one: If we check for OACTIVE periodically (for instance, in local_timer) and under transient resource shortage, the driver will finally end up with OACTIVE cleared. Under frequent resource shortages, the driver may remain OACTIVE longer than it is ~OACTIVE or it may constantly toggles but there is not much the driver can do about this and a simple locking around OACTIVE set/clear does not change the situation. The problem _is_ low resources and the only fix is to increase it. The problems we should focus on here are two things: 1- The driver _must_ be able to recover from OACTIVE after transient resource shortages. 2- It is desirable to do this as fast as possible. Doing recovery in local_timer accommodates the first need but it is very far from from the second. One possible solution for 2 would be to defer setting OACTIVE until N consecutive transmissions fail (i.e., N == 75% (if_snd.ifq_maxlen - if_snd.ifq_len)). The overhead is a little wasted cpu time consumed in longer OACTIVE states. We still need local_timer to recover from these states. From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 09:52:44 2011 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 86AF71065672 for ; Thu, 10 Nov 2011 09:52:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 042E28FC13 for ; Thu, 10 Nov 2011 09:52:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pAA9qgJJ071964; Thu, 10 Nov 2011 13:52:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pAA9qgc2071963; Thu, 10 Nov 2011 13:52:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 10 Nov 2011 13:52:42 +0400 From: Gleb Smirnoff To: Pavel Timofeev Message-ID: <20111110095242.GC41786@FreeBSD.org> References: <4EBB86E8.6030206@hotplug.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Emil Muratov Subject: Re: Possible MROUTING regression in 9.0 RC1 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, 10 Nov 2011 09:52:44 -0000 On Thu, Nov 10, 2011 at 12:15:11PM +0400, Pavel Timofeev wrote: P> Thank you! I'll try! P> I'm going crazy. P> Now I can crash even FreeBSD 8.2 RELEASE with igmpproxy in some coincidence. P> P> I can get kernel dump on 8.2, and can try to get dump on 9.0-RC1. Is P> it interesting? Backtrace and dump for 9.0 may get some interest from this list subscribers. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 09:45:03 2011 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 7D0CE106566C for ; Thu, 10 Nov 2011 09:45:03 +0000 (UTC) (envelope-from yakimenko.alexey@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 479CC8FC15 for ; Thu, 10 Nov 2011 09:45:02 +0000 (UTC) Received: by iakl21 with SMTP id l21so1596089iak.13 for ; Thu, 10 Nov 2011 01:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=25H5XkyhhT4Vah6x4XEQ7x9vCZ3IijDD/6F+JHpmxi8=; b=WUc1TnnzCZNb7NM5xhjyyBF+iVPy0xHzRq+fuLODr9E4TybFB0VNQyq/CCiYbQr/xf a0Up68jw0T0UQmegjfcbclwdYIveApX2fcJJ0DYalU2eUil2oXlhuiTocKkezn8YjSFj KnJMcdBmBYuncFDl7Oca75oi+Hyq2TzmfF7DM= MIME-Version: 1.0 Received: by 10.42.151.196 with SMTP id f4mr6503534icw.17.1320916693977; Thu, 10 Nov 2011 01:18:13 -0800 (PST) Received: by 10.42.169.65 with HTTP; Thu, 10 Nov 2011 01:18:13 -0800 (PST) Date: Thu, 10 Nov 2011 12:18:13 +0300 Message-ID: From: =?KOI8-R?B?4czFy9PFyiDxy8nNxc7Lzw==?= To: freebsd-net@freebsd.org X-Mailman-Approved-At: Thu, 10 Nov 2011 12:19:56 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Netgraph multithreading 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, 10 Nov 2011 09:45:03 -0000 Hello! Can you help me please? Is Netgraph supports multithreading in FreeBSD 8.1 ? I found that in the function "ngb_mod_event" (ng_base.c, line 3114) multiple threads runs function "ngthread" (ng_base.c, line 3315). What does this function? Or another question. Where is the parallelization of handling the traffic: in driver of network adapter or Netgraph? Thank you! -- Alexey. From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 17:42:19 2011 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 01BDC106566B for ; Thu, 10 Nov 2011 17:42:19 +0000 (UTC) (envelope-from wittigal@msu.edu) Received: from sys53.mail.msu.edu (sys53.mail.msu.edu [35.9.75.233]) by mx1.freebsd.org (Postfix) with ESMTP id B64138FC16 for ; Thu, 10 Nov 2011 17:42:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=msu.edu; s=mail; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=kiSMv3XAPtRqMHQCwdFFQOBJi84pZCZBMQLL5D51FI0=; b=RlZK8XJqTAxY9hScAOo3khriOxBqpsV7CSWGIQkOhypRHDlnFqxF3e90GgfsADSuvQBXepef7uOe6fqT8insaZ4fnPIHeMR1L+Pg2jQQRICqZKNn+TVT39QMlQV2ZesvLfnCcGALASdfYbZXlDlnQZKEy3QrKBDk1fCpdg4DoVs=; Received: from prokofiev.bt.pa.msu.edu ([35.9.70.209] helo=[192.168.0.154]) Authenticated ID: wittigal by sys53.mail.msu.edu with esmtpsa (Exim 4.75 #3) (TLSv1:AES128-SHA:128) id 1ROYdl-000209-My; Thu, 10 Nov 2011 12:42:17 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alexander Wittig In-Reply-To: <20111110065135.GS71907@FreeBSD.org> Date: Thu, 10 Nov 2011 12:42:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> <20111110065135.GS71907@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1084) X-Virus: None found by Clam AV Cc: freebsd-net@FreeBSD.org Subject: Re: FreeBSD 9 and ARP multicast source address error messages 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, 10 Nov 2011 17:42:19 -0000 Gleb, Am 10.11.2011 um 01:51 schrieb Gleb Smirnoff: > On Tue, Nov 08, 2011 at 05:14:45PM -0500, Alexander Wittig wrote: > A> I upgraded one of my machines from FreeBSD 8 to 9.0-RC1 (FreeBSD = bt.pa.msu.edu 9.0-RC1 FreeBSD 9.0-RC1 #3: Fri Oct 28 16:45:28 EDT 2011 = root@bt.pa.msu.edu:/usr/obj/usr/src/sys/ALEX i386), and ever since = that upgrade the kernel keeps flooding my log files with messages like = these: > A> Nov 7 16:40:01 bt kernel: in_arp: source hardware address is = multicast.in_arp: source hardware address is multicast. > A> Nov 7 16:42:02 bt kernel: in_arp: source hardware address is = multicast.in_arp: source hardware address is multicast. > A>=20 > A> A Google search for these didn't reveal any useful results as to = why this happens or how to fix it. So I did a tcpdump and matched the = time stamps with packets, and I found the ones causing problems (the = only ones with a multicast bit set) to be like this: > A> 16:40:01.099823 02:02:23:09:44:3c > 03:bf:23:09:44:87, ethertype = ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply = 35.9.68.228 is-at 03:bf:23:09:44:e4, length 46 > A> 0x0000: 03bf 2309 4487 0202 2309 443c 0806 0001 > A> 0x0010: 0800 0604 0002 03bf 2309 44e4 2309 44e4 > A> 0x0020: 02bf 2309 443c 2309 4487 0000 0000 0000 > A> 0x0030: 0000 0000 0000 0000 0000 0000 > A>=20 > A> It appears the broadcast MAC 03:bf:23:09:44:87 is part of = Microsoft's network load balancing mechanism, with the 03:bf indicating = that much and the 23:09:44:87 containing the IP address of the load = balance cluster (35.9.68.228). These types of MACs seem to be commonly = used in their load balancing implementation. > A>=20 > A> To prevent these messages from producing thousands of lines of logs = each day, I added the following two IPFW rules and enabled ethernet = package filtering (sysctl net.link.ether.ipfw=3D1): > A> deny ip from any to any MAC 03:bf:00:00:00:00/16 any layer2 > A> allow ip from any to any layer2 > A>=20 > A> This effectively blocks those packages and the resulting error = messages. But I'm wondering if the newly added(?) ARP code in FBSD 9 is = a bit too fussy about these, or if MS is abusing the ARP protocol here. = Either way, this was never a problem with FBSD 7 or 8. >=20 > Can you try attached patch. It reduces severity level of all ARP > messages, that can be triggered by packet on network, with expection = to > "using my IP address". >=20 > With default syslog.conf, now ARP errors won't get to console. >=20 > Also, the multicast message lacked "\n" newline character, that's why, > I suppose, syslogd failed to coalesce a number of messages into a = single > entry "last message repeated X times". Thank you very much for the patch, and for making this particular = message a bit more helpful by including the MAC address. I tried it and indeed it stops the messages from going to the console. = But the default syslog.conf still logs each one in /var/log/messages and = they also show up in dmsg output. These happen quite frequently, so even = on a not so busy network they will drown out almost everything else = going on in dmsg or /var/log/messages. Unfortunately, having two (or = more) different machines use these will prevent syslogd from combining = messages into "last message repeated X times": /var/log/messages: [...] Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast Nov 10 12:23:44 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast [...] I'm not an expert on networking, but is this condition of ignoring such = an ARP packet really a noteworthy event? I.e. is this something that = should not occur in "normal" operation according to the ARP = specifications? If this is mostly for kernel developers, maybe it should = only be enabled in debug kernel builds? Alex From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 18:27:04 2011 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 3493A106564A for ; Thu, 10 Nov 2011 18:27:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D4C058FC17 for ; Thu, 10 Nov 2011 18:27:03 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so3911482vcb.13 for ; Thu, 10 Nov 2011 10:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IySwW8a7ts3INzlBAXF88C6K4W44xbs4Wb0vXCnGCBo=; b=GFNwNDlbq02uJOJxCkddrJjnENuuA7wJE9aild1IBw4w/owlLMO6xM9YEw1BvPy5zn hWPrP0l3Mf2kk/TKPV30Aq3j7rrjIsdSRs3KIVGpC/EDGWU/597SSV37tcEknM2mlvee DAEMdi74fuG+tftA4z5d+AbamevbW9UgkXoDQ= MIME-Version: 1.0 Received: by 10.52.24.102 with SMTP id t6mr14511212vdf.106.1320949623085; Thu, 10 Nov 2011 10:27:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 10:27:03 -0800 (PST) In-Reply-To: <4EBB9CDF.9090300@gmail.com> References: <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> <4EBB9CDF.9090300@gmail.com> Date: Thu, 10 Nov 2011 10:27:03 -0800 X-Google-Sender-Auth: 5qItl_T8VtrqtkBAU33PCnBgP4c Message-ID: From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Jack Vogel , Emil Muratov Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 18:27:04 -0000 Wait, but low resources which are stopping _what_ ? The whole point behind OACTIVE is to say "oi, give me time to flush my TX queue." I'll tell you when I'm ready. So when you clear OACTIVE after a TX completion handler, you would then call _start (or _start_locked) to reschedule some more frames. There shouldn't be a resource shortage here - ie, once you run out of tx descriptor slots, you'd set OACTIVE, then you will call the TX completion handler (on interrupt) until you've handled the pending entries in the TX descriptor ring/list. Once you've handled at least -one- TXed frame, that slot is now available and you can free OACTIVE + call _start/_start_locked. The problem is whether this is working right for drivers that implement _transmit, do multiqueue, etc. Ie, there's now multiple places where OACTIVE is being set/cleared, and from my experience with a few other > 100mbit ethernet/wifi drivers, I've seen situations where the TX queue stalled because the right mix of "clear OACTIVE to tell the stack they can start firing off more frames" and "call _start / _start_locked once there are actually TX buffers/descriptors available" didn't happen correctly. At this point, if you never call _start() and OACTIVE is set, TX stalls. It doesn't matter if you _clear_ OACTIVE at this point. The queue is full and thus nothing will happen. Some drivers even work around this silliness by calling the tx start routine from the end of the RX completion routine. :-) I don't think that's strictly needed if your hardware is posting interrupt notifications sensibly and your interrupt handler isn't buggy, but hey, maybe it isn't (eg, you disable interrupts, you do your TX/RX work, in the meantime some more TX completion has occured, then you restore interrupts and clear the bits you were working on - there's stuff in the TX completion queue, but now that the queue is full you won't _get_ another interrupt for it.) So the magic is: * is OACTIVE being set/cleared sensibly; * are there calls to _start or _start_locked at the right spots (ie, after TX completion has occured); * what's going on with the _transmit stuff; * how's the descriptor aggregation stuff for _transmit working and are you hitting concurrency issues where that queue/queue gets stalled because you never call the TX completion function and then _start or _transmit to drain that queue? * Check the interrupt handling and see if when you disable/enable interrupts, you're clearing the status bits wrong (if the hardware even lets you do the sensible thing.) Eg, don't clear the TX completion bits _after_ you handle TX completion but before you re-enable interrupts, as the hardware may have completed some more frames and filled the TX descriptor queue/ring. At this point if you're lucky you'll get a "yo, TX queue FULL!" interrupt/error, but if you're even _more_ unlucky, you've just handled a TX completion + TX queue full event and whilst handling that full queue, you fill the queue up again. Then you won't get a subsequent interrupt for the now filled queue. Now, I've not got any em hardware (legacy or shiny) so I'm simply offering observations from having had to debug this stuff in the recent past. I just think you've hit the same issue. :) Adrian From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 19:40:09 2011 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 1C4141065670 for ; Thu, 10 Nov 2011 19:40:09 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id C761E8FC12 for ; Thu, 10 Nov 2011 19:40:08 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id D445EB0380BE for ; Thu, 10 Nov 2011 14:40:07 -0500 (EST) thread-index: Acyf4I0BA+Tu7rX+Sc6HbV3aqx+2Uw== Received: from hometx-733b1p1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 14:40:06 -0500 Received: by hometx-733b1p1.corp.verio.net (sSMTP sendmail emulation); Thu, 10 Nov 2011 13:40:05 -0600 Date: Thu, 10 Nov 2011 13:40:05 -0600 Content-Transfer-Encoding: 7bit From: "David DeSimone" To: Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 Message-ID: <20111110194004.GB7844@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <96A5211A-398B-4773-8C6A-2D772D241CF0@msu.edu> <20111110065135.GS71907@FreeBSD.org> <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-reply-to: <6A964045-2ADF-42EC-8AC4-00179FDBE4D9@msu.edu> Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 10 Nov 2011 19:40:06.0217 (UTC) FILETIME=[8C4BCB90:01CC9FE0] Subject: Re: FreeBSD 9 and ARP multicast source address error messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 19:40:09 -0000 Alexander Wittig wrote: > > Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:e4 is multicast > Nov 10 12:25:45 bt kernel: in_arp: 03:bf:23:09:44:87 is multicast > [...] > > I'm not an expert on networking, but is this condition of ignoring > such an ARP packet really a noteworthy event? I.e. is this something > that should not occur in "normal" operation according to the ARP > specifications? If this is mostly for kernel developers, maybe it > should only be enabled in debug kernel builds? I found this tread enlightening on the subject: http://fixunix.com/tcp-ip/66685-arp-reply-containing-multicast-mac-ok.html In particular the reference to RFC 1812 which states: A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address. This requirement is the reason why multicast ARP replies are problematic, and why Microsoft's NLB implementation often causes heartburn within the network. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 19:40:10 2011 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 32D9C106564A; Thu, 10 Nov 2011 19:40:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9508FC14; Thu, 10 Nov 2011 19:40:09 +0000 (UTC) Received: by wwg14 with SMTP id 14so2342087wwg.31 for ; Thu, 10 Nov 2011 11:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D9G2tC8mEKESf1CEksEpRhVhnIc1sY0ucYObEuwQ+Gk=; b=ZWz9HjAmB4sg0rGLCN1HxrOMrcoCkHwe4u7XssuOyQubJeEE6fpOT4N6CFP8OttCMz FOVSp0FNp75kv9Dp89beU4Qlp/2yp3H3KSmQUlakeugryp8j8JF8O99bArxxO00MeIlE vmUAyuEc3y5tCpQIOeT7+7P2qPldgSSXxKjAM= MIME-Version: 1.0 Received: by 10.180.3.33 with SMTP id 1mr10595201wiz.54.1320954008418; Thu, 10 Nov 2011 11:40:08 -0800 (PST) Received: by 10.180.95.229 with HTTP; Thu, 10 Nov 2011 11:40:07 -0800 (PST) In-Reply-To: References: <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> <4EBB9CDF.9090300@gmail.com> Date: Thu, 10 Nov 2011 11:40:07 -0800 Message-ID: From: Jack Vogel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Emil Muratov , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 19:40:10 -0000 I'm testing something right now, what I've done is take all the OACTIVE manipulation and centralized it to the start routines (multiqueue or single), and I now keep a queue specific drained variable that gets set when you run to minimum descriptors, and then cleared in txeof. In start, particularly the multiqueue variant, when you want to send it will try the prefered queue first, but if that is drained, will try the others. If it turns out ALL queues are drained, only THEN will it actually set the interface OACTIVE. Not sure if this is gonna work, have a stress test running on it now. Jack On Thu, Nov 10, 2011 at 10:27 AM, Adrian Chadd wrote: > Wait, but low resources which are stopping _what_ ? > > The whole point behind OACTIVE is to say "oi, give me time to flush my > TX queue." I'll tell you when I'm ready. > > So when you clear OACTIVE after a TX completion handler, you would > then call _start (or _start_locked) to reschedule some more frames. > > There shouldn't be a resource shortage here - ie, once you run out of > tx descriptor slots, you'd set OACTIVE, then you will call the TX > completion handler (on interrupt) until you've handled the pending > entries in the TX descriptor ring/list. Once you've handled at least > -one- TXed frame, that slot is now available and you can free OACTIVE > + call _start/_start_locked. > > The problem is whether this is working right for drivers that > implement _transmit, do multiqueue, etc. Ie, there's now multiple > places where OACTIVE is being set/cleared, and from my experience with > a few other > 100mbit ethernet/wifi drivers, I've seen situations > where the TX queue stalled because the right mix of "clear OACTIVE to > tell the stack they can start firing off more frames" and "call _start > / _start_locked once there are actually TX buffers/descriptors > available" didn't happen correctly. At this point, if you never call > _start() and OACTIVE is set, TX stalls. It doesn't matter if you > _clear_ OACTIVE at this point. The queue is full and thus nothing will > happen. > > Some drivers even work around this silliness by calling the tx start > routine from the end of the RX completion routine. :-) I don't think > that's strictly needed if your hardware is posting interrupt > notifications sensibly and your interrupt handler isn't buggy, but > hey, maybe it isn't (eg, you disable interrupts, you do your TX/RX > work, in the meantime some more TX completion has occured, then you > restore interrupts and clear the bits you were working on - there's > stuff in the TX completion queue, but now that the queue is full you > won't _get_ another interrupt for it.) > > So the magic is: > > * is OACTIVE being set/cleared sensibly; > * are there calls to _start or _start_locked at the right spots (ie, > after TX completion has occured); > * what's going on with the _transmit stuff; > * how's the descriptor aggregation stuff for _transmit working and are > you hitting concurrency issues where that queue/queue gets stalled > because you never call the TX completion function and then _start or > _transmit to drain that queue? > * Check the interrupt handling and see if when you disable/enable > interrupts, you're clearing the status bits wrong (if the hardware > even lets you do the sensible thing.) Eg, don't clear the TX > completion bits _after_ you handle TX completion but before you > re-enable interrupts, as the hardware may have completed some more > frames and filled the TX descriptor queue/ring. At this point if > you're lucky you'll get a "yo, TX queue FULL!" interrupt/error, but if > you're even _more_ unlucky, you've just handled a TX completion + TX > queue full event and whilst handling that full queue, you fill the > queue up again. Then you won't get a subsequent interrupt for the now > filled queue. > > Now, I've not got any em hardware (legacy or shiny) so I'm simply > offering observations from having had to debug this stuff in the > recent past. I just think you've hit the same issue. :) > > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Thu Nov 10 23:40:37 2011 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 BF1AA106566C for ; Thu, 10 Nov 2011 23:40:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 65A898FC17 for ; Thu, 10 Nov 2011 23:40:37 +0000 (UTC) Received: by vws11 with SMTP id 11so4291141vws.13 for ; Thu, 10 Nov 2011 15:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AwKkgCem7GMrqrTGiGH0+zdjgL50s7AxRw9+m2ikAGQ=; b=XGqg2UJDtsqF+iMtFSujUctxCK49e5Xe+mle/FqJ+gfJeuly1SUCnQmcWRu/TS2c/k d7shJpzm2NtF/Z5RK/iPtMvCM7v92SrU6i/+rQTCDG9awu/hzdqDsJlUmpqu3GCwAA4Q kHVfHOt3VQ4vaRa2CS5C4//nbgGywu33OoDuQ= MIME-Version: 1.0 Received: by 10.52.72.104 with SMTP id c8mr16384928vdv.105.1320968436498; Thu, 10 Nov 2011 15:40:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.29.198 with HTTP; Thu, 10 Nov 2011 15:40:36 -0800 (PST) In-Reply-To: References: <4EA7E203.3020306@sepehrs.com> <4EA80818.3030504@sentex.net> <4EA80F88.4000400@hotplug.ru> <4EA82715.2000404@gmail.com> <4EA8FA40.7010504@hotplug.ru> <4EA91836.2040508@gmail.com> <4EA959EE.2070806@hotplug.ru> <4EAD116A.8090006@gmail.com> <4EAE58A2.9040803@gmail.com> <4EB96511.50701@gmail.com> <4EBA3F22.2060204@gmail.com> <4EBB9CDF.9090300@gmail.com> Date: Thu, 10 Nov 2011 15:40:36 -0800 X-Google-Sender-Auth: HR0rhuVeHXHTk9N-f3eZAAdhegg Message-ID: From: Adrian Chadd To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Jason Wolfe , Emil Muratov , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 10 Nov 2011 23:40:37 -0000 In the case of multi-threaded OACTIVE, why not just do this: upon queue completion: * lock; * do queue completion; * if any frames were completed, clear queue busy; * if (queue busy == clear && OACTIVE) clear OACTIVE; * run queue completion; * unlock. upon queue transmit: * lock; * queue frame; * if (fail) - mark queue as busy; * if (all busy) - set OACTIVE. * unlock The stack will stop sending you frames whilst OACTIVE Is set, but will continue sending them when you clear it. If you just clear OACTIVE when _a_ queue is clear then you'll get frames queued via start/transmit when queues are busy, but what you won't do is starve them all until all queues have free slots. Ie, you don't mind clearing it, then getting a frame and immediately finding you're busy. Once you've done that, any further issues are likely either concurrency with accessing the tx/rx descriptor rings (per-queue), or the interrupt handling races. Ie, you disable interrupts, handle the tx queue completion, -then- re-enable interrupts and clear masks. Maybe that logic in igb_enable_intr() is to blame? Ie, que_mask / link_mask, is that before or after the queue has been handled? If it's called after the queue is handled, and que_mask / link_mask is 0, but the queue is full, you'll never pick up the next interrupt as there won't be one? 2c, Adrian From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 01:03:03 2011 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 939551065674 for ; Fri, 11 Nov 2011 01:03:03 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 524248FC16 for ; Fri, 11 Nov 2011 01:03:03 +0000 (UTC) Received: by vws11 with SMTP id 11so4364699vws.13 for ; Thu, 10 Nov 2011 17:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LSdiCj36VmrXHg6jI9z9zp5qpAdaIHDRFHv697qWlaw=; b=dmtuKfuQEXdWRq08NHVi+FQA11QP8fo653tPMP/cfWz+/KODtBnKHBtKCJjPZHUy3o 0m6ymQEH8bIytWJ5wQwd+J7jfFUN9NohyKTWiSaijoPlKl2G0b8LZQ8I8dmoa/J4tP5X ktJnLM8x4pLwrDbYW4CewuUDaN5YkYH3NvPn0= MIME-Version: 1.0 Received: by 10.52.20.207 with SMTP id p15mr16732791vde.87.1320971736783; Thu, 10 Nov 2011 16:35:36 -0800 (PST) Received: by 10.220.191.130 with HTTP; Thu, 10 Nov 2011 16:35:36 -0800 (PST) Date: Thu, 10 Nov 2011 16:35:36 -0800 Message-ID: From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ipf(8) for TCP connection rate limiting 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, 11 Nov 2011 01:03:03 -0000 Hi. My machine has some ipf(8) rules and I see that when there is a TCP connection storm to the http port the filer sends out TCP resets. I wanted to know if its possible to configure the pps limit for TCP connections before the RSTs kick in using ipf. regards, vijay From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 06:39:30 2011 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 493961065672; Fri, 11 Nov 2011 06:39:30 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A676B8FC0C; Fri, 11 Nov 2011 06:39:29 +0000 (UTC) Received: by faar19 with SMTP id r19so5208480faa.13 for ; Thu, 10 Nov 2011 22:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NGlKR4J/30jKmIoFy4FM1ytzR/F2APvpDzw4WEaXPvI=; b=ZhMJ17LxWlcexzZvSzkQgJ8fqmDOmKnXNGOKwCeNP5DdTkB80lnqYrPTUUVpm1Crhc HdlXd7sST44FQoEd/VoRRltfYdciRxd2XJ5cFAJxEWCpM5Y4ltbeT2sCEpH+TngxpHW2 im+AgrNaIet4H5/Adq/LYdDB5emCw0EeFDjAk= MIME-Version: 1.0 Received: by 10.152.106.115 with SMTP id gt19mr6120707lab.27.1320993568373; Thu, 10 Nov 2011 22:39:28 -0800 (PST) Received: by 10.152.9.10 with HTTP; Thu, 10 Nov 2011 22:39:28 -0800 (PST) In-Reply-To: <20111110095242.GC41786@FreeBSD.org> References: <4EBB86E8.6030206@hotplug.ru> <20111110095242.GC41786@FreeBSD.org> Date: Fri, 11 Nov 2011 10:39:28 +0400 Message-ID: From: Pavel Timofeev To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Emil Muratov Subject: Re: Possible MROUTING regression in 9.0 RC1 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, 11 Nov 2011 06:39:30 -0000 Hmm. I just CSUPed and rebuilt my kernel&world. (r227207?) It seems the problems are gone! 10 =D0=BD=D0=BE=D1=8F=D0=B1=D1=80=D1=8F 2011=C2=A0=D0=B3. 13:52 =D0=BF=D0= =BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Gleb Smirno= ff =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > On Thu, Nov 10, 2011 at 12:15:11PM +0400, Pavel Timofeev wrote: > P> Thank you! I'll try! > P> I'm going crazy. > P> Now I can crash even FreeBSD 8.2 RELEASE with igmpproxy in some coinci= dence. > P> > P> I can get kernel dump on 8.2, and can try to get dump on 9.0-RC1. Is > P> it interesting? > > Backtrace and dump for 9.0 may get some interest from this list subscribe= rs. > > -- > Totus tuus, Glebius. > From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 20:45:27 2011 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 D47B2106566B for ; Fri, 11 Nov 2011 20:45:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F7ED8FC12 for ; Fri, 11 Nov 2011 20:45:27 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5091904bkb.13 for ; Fri, 11 Nov 2011 12:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=CJ2/1MvjMfUk8Lhpr8vp+2/AhejN1ThI/zEVitQ7rV4=; b=EDiDSTJWj5IAAmjOw5E7OrDmTI2aEtGTwuRGi6Qc1Gn6uxi28OP5w7uozN+xZQsap0 4bWwkdwGpS31EOTRbK8harqv/MUQc/nAXo2AxBEILWuwGl45Ln0La17nxTZr1nbzJPdu +HWorYqkvRbrIJE9CY+rJjttyqA8ZwVje1hgM= Received: by 10.205.118.18 with SMTP id fo18mr6557699bkc.33.1321042495723; Fri, 11 Nov 2011 12:14:55 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id j9sm12947856bkd.2.2011.11.11.12.14.54 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 12:14:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4EBD822F.6000509@FreeBSD.org> Date: Fri, 11 Nov 2011 22:14:39 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-net , yakimenko.alexey@gmail.com X-Enigmail-Version: undefined Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Re: Netgraph multithreading 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, 11 Nov 2011 20:45:27 -0000 Hi. > Is Netgraph supports multithreading in FreeBSD 8.1? Generally yes, but there are many different cases. Netgraph uses direct function calls to handle traffic. It means that when it is possible it runs directly in network card interrupt threads contexts, or if net.isr.direct sysctl set to 0 (default) in network software interrupts threads context. How many first you have depends on hardware and NIC drivers. Number of second depends on hardware and OS version. Also when function call depth is too big or there are other reasons preventing direct calls, netgraph queues packets, and then, when possible, handles them using multiple dedicated threads. Unluckily, after packets queued for some node, all packets for it will be handled only by one thread to prevent reordering. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 21:21:18 2011 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 25ED91065672 for ; Fri, 11 Nov 2011 21:21:18 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2FBA78FC0A for ; Fri, 11 Nov 2011 21:21:16 +0000 (UTC) Received: (qmail 8131 invoked from network); 11 Nov 2011 22:21:15 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Nov 2011 22:21:15 +0100 Message-ID: <1321046480.8512.3.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: pyunyh@gmail.com Date: Fri, 11 Nov 2011 22:21:20 +0100 In-Reply-To: <20111107175953.GA1646@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> Content-Type: multipart/mixed; boundary="=-7QtFRTJmmcWcU9Q+YJFj" X-Mailer: Evolution 3.2.1 Mime-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 21:21:18 -0000 --=-7QtFRTJmmcWcU9Q+YJFj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi! Sorry for my late response. Am Montag, den 07.11.2011, 09:59 -0800 schrieb YongHyeon PYUN: > > > > Some revisions of RealTek controller have FIFO overrun issue but > > I'm not sure whether you're seeing the issue. Try enabling flow > > control and see whether that makes any difference. You can enable > > it by issuing 'ifconfig re0 media flow'. > > This should be read as 'ifconfig re0 mediaopt flow'. It may be that enabling flow control helps a bit but it definately does not solve the problem. There are still hundreds of packets missed in just one or two minutes. Maybe there is no difference at all. > > Show me the dmesg output. RealTek uses the same device PCI ids so it's > > impossible to know which controller you have from the pciconf(8) > > output. I think the relevant part is this one: > re0: port 0x1000-0x10ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci1 > re0: Using 1 MSI-X message > re0: Chip rev. 0x2c000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 38:60:77:3e:af:a5 Full dmesg output is also attached. Greetings, Michael PS: In my first mail I wrote that I can reproduce the problem only with one of two connected hosts. I think the reason is that the other host only produces a maximum of 250Mbit/s while the problematic transfers go up to 550Mbit/s. --=-7QtFRTJmmcWcU9Q+YJFj-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 21:36:00 2011 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 B368C1065670 for ; Fri, 11 Nov 2011 21:36:00 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 13D488FC17 for ; Fri, 11 Nov 2011 21:35:59 +0000 (UTC) Received: (qmail 9691 invoked from network); 11 Nov 2011 22:35:58 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Nov 2011 22:35:58 +0100 Message-ID: <1321047363.8512.7.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: pyunyh@gmail.com Date: Fri, 11 Nov 2011 22:36:03 +0100 In-Reply-To: <1321046480.8512.3.camel@bevan-pc.fritz.box> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 21:36:00 -0000 Attachment has been removed. So this is another try: http://pastebin.com/PArR9D8N Am Freitag, den 11.11.2011, 22:21 +0100 schrieb Michael Laß: > Hi! > > Sorry for my late response. > > Am Montag, den 07.11.2011, 09:59 -0800 schrieb YongHyeon PYUN: > > > > > > Some revisions of RealTek controller have FIFO overrun issue but > > > I'm not sure whether you're seeing the issue. Try enabling flow > > > control and see whether that makes any difference. You can enable > > > it by issuing 'ifconfig re0 media flow'. > > > > This should be read as 'ifconfig re0 mediaopt flow'. > > It may be that enabling flow control helps a bit but it definately does > not solve the problem. There are still hundreds of packets missed in > just one or two minutes. Maybe there is no difference at all. > > > > Show me the dmesg output. RealTek uses the same device PCI ids so it's > > > impossible to know which controller you have from the pciconf(8) > > > output. > > I think the relevant part is this one: > > re0: port 0x1000-0x10ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci1 > > re0: Using 1 MSI-X message > > re0: Chip rev. 0x2c000000 > > re0: MAC rev. 0x00000000 > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > re0: Ethernet address: 38:60:77:3e:af:a5 > > Full dmesg output is also attached. > > Greetings, > Michael > > PS: In my first mail I wrote that I can reproduce the problem only with > one of two connected hosts. I think the reason is that the other host > only produces a maximum of 250Mbit/s while the problematic transfers go > up to 550Mbit/s. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 22:41:56 2011 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 2FAA5106564A; Fri, 11 Nov 2011 22:41:56 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 79C988FC08; Fri, 11 Nov 2011 22:41:55 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5202985bkb.13 for ; Fri, 11 Nov 2011 14:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=v0jcWUz6xPjEYqvX4bteaT7izUfWiHpCLjFxf9sSqiU=; b=jrMTFQXB1/fFr+dTihIYj0K95wk0UXEfR70ltjGTfC1cTqk71qMKRIIW7ScFkh4pTX f6LsjWrCVS7MGAAhKYsXOSOLtWkv/M/DDwEZYehRVXlBg4oFd+vc0MqlIi04+Tr0YO5K IZYrhI0c+dRh5yMR4QmnLuGtTQb9YmmCJcTc0= Received: by 10.204.156.141 with SMTP id x13mr9932147bkw.54.1321051314125; Fri, 11 Nov 2011 14:41:54 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id j9sm13723854bkd.2.2011.11.11.14.41.52 (version=SSLv3 cipher=OTHER); Fri, 11 Nov 2011 14:41:53 -0800 (PST) Sender: Alexander Motin Message-ID: <4EBDA4B2.6030602@FreeBSD.org> Date: Sat, 12 Nov 2011 00:41:54 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-net X-Enigmail-Version: undefined Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: David Hooton , Gleb Smirnoff Subject: Re: MPD LAC Scaling 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, 11 Nov 2011 22:41:56 -0000 Hi. > I'm currently evaluating MPD as a potential LAC solution for a > project I'm working on. I'm looking to try and handle at least 4Gbit > and 20,000 sessions worth of PPPoE -> L2TP LAC traffic per server. > The reading I've done from the archives so far seems to indicate that > this has not yet been done. I also haven't heard about so big cases, but also can't say it is theoretically impossible after some tuning and development work. At this point I have neither production/test environment nor much time to actively work on it, but I want to express some experience and ideas in case somebody wants to take that. First, as Julian said, it is not necessary should be one server to handle all load. Cluster of smaller machines should be preferable from many points. PPPoE allows you to have several servers and load-balance them. At this moment MPD can't balance load dynamically, but you can do it manually, limiting number of sessions per one server. As some example point of hardware from personal experience I can say that three years ago mpd5 on 1U servers with single Core2Duo CPUs, 1GB of RAM and two 1Gb NICs (less then $1K that time) handled in production about 2000 PPPoE sessions and 600Mbps of traffic per server, including Netflow generation, per-customer typed traffic shaping and accounting. Modern and more powerful hardware is able to do more. Getting higher numbers there can mostly be split in two questions: getting more traffic and getting more sessions, as limitations are different. - Getting more traffic mostly means scaling kernel Netgraph and networking code to more CPU cores. As soon as Netgraph uses direct function calls when possible, it depends on number of network interrupt threads in system. Three years ago there was only one net SWI thread and setting net.isr.direct=1 while having several NICs in system allowed to distribute load between CPUs. Modern high-level NICs with several MSI-X interrupts should give the same effect. Now it is also possible to have several net SWI threads, but I haven't tested it. - Getting more sessions also means tuning and optimizing user-level mpd daemon. Three years ago on Pentium4-level test machine I've reached about 5K PPPoE sessions with RADIUS auth/acct. Main limiting factor was user-level daemon performance. The more sessions connected, the more overhead daemon had in face of LCP echo requests and event timeouts to handle, number of netgraph kernel sockets to listen, etc. At some point daemon is just unable to handle all new incoming events in time and resending requests by clients causes cumulative effect. So the main limiting factor is not just number of users, but also number of events. If users connect one by one, number of sessions can be quite high. But if due to some accident you have all users dropped and reconnecting, that may cause overload sooner. In that case it is important even what LCP echo timeout set on the server and clients, or how many logs are enabled. My best tuning result that time on Pentium4-level machine was about 100 connections per second. It allowed to setup 5000 simultaneous sessions within 50 seconds. Higher numbers were problematic. At this moment user-level MPD's main state machine is single-threaded, except authorization and accounting (like RADIUS), that are done in separate threads, but require synchronized completion to return the data. Splitting main FPM on several threads is difficult, because it would require to somehow to group links and bundles within different threads with different locks, that is difficult, because of multilink support and because until user is authorized, it is impossible to say which bundle it should join. If there is need to handle several PPPoE services with different names or several LAN segments, it theoretically may be effective to have several MPD daemon instances running, one for each service/segment. Generally I've spent less time on profiling and optimizing MPD daemon itself then kernel code, so there still should be a lot of space for improvement. Some possible optimization points I still remember are: - rework pevent() engine used by MPD state machine to use kqueue() instead of poll() to reduce event overhead overhead; - optimize locking of paction() functions used for thread creation and completion for MPD-specific case; Idea was that by the cost of functionality it could be simplified to reduce number of context switches; - rewrite RADIUS auth/acct support to run within main mpd thread or fixed number of external threads; since existing threaded approach was implemented, libradius got support for asynchronous operation; that should reduce overhead for thread creation/destruction; - optimize ng_ksocket node when work with large number of hooks, using some optimized search, and/or make MPD to create another sockets for each next number of links to balance kernel and user-level search overheads; initially MPD created separate set of sockets for every link, but it was found too expensive for user-level FSM and was rewritten into present state with almost minimal number of sockets and most multiplexing tone in kernel. I have no personal production experience with PPPoE-L2TP LAC case. It is used much less often and I had only several reports from people actively using it and no much numbers. I think LAC case should have smaller overhead and CPU load and so better scalability then usual traffic termination: there is no IPCP layer in PPP to negotiate, there is no interfaces to create and configure, no Netflow, no shapes, no periodic accounting, etc. If you don't need to authenticate users, but only to forward connections, and so server doesn't need to handle LCP protocol, task simplifies even much more. If you can setup test environment to stress-test the LAC stuffs, it would be interesting to see the numbers. On my test lab I used several machines with mpd configured for thousands of PPPoE client sessions each to generate simultaneous connections. For testing LAC you also should have some fast enough L2TP terminator. If you have no such hardware for test, you may try use several systems with mpd L2TP servers spreading load between them in one of ways to avoid bottleneck there, while system load in such case may potentially slightly differ. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 23:57:32 2011 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 0FE94106566B for ; Fri, 11 Nov 2011 23:57:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC85E8FC0C for ; Fri, 11 Nov 2011 23:57:31 +0000 (UTC) Received: by ggnk3 with SMTP id k3so6697578ggn.13 for ; Fri, 11 Nov 2011 15:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=u2liqGa7uA4no5WQRcxAgCp/0mKNjVL+4MTLyL4nUvM=; b=K1vEW7rF6AKsmTXnW5SiNkly/1AoQ3wh+CyETwIYcgKFJdBfW1MPaA/iqywkkp30YP GRtMQeX4vED43Zm7+FhjEaGamO9loq0wq9Zf9yO8hYAkmstmLcvHX5z750aV2GZpeufn RFAyWaAqF/zHXD1lC+MVAHEKJLoP88qBUbvG0= Received: by 10.68.4.200 with SMTP id m8mr28141754pbm.50.1321055850699; Fri, 11 Nov 2011 15:57:30 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id lk8sm33926390pbb.4.2011.11.11.15.57.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 15:57:29 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 11 Nov 2011 15:55:26 -0800 From: YongHyeon PYUN Date: Fri, 11 Nov 2011 15:55:26 -0800 To: Michael =?iso-8859-1?B?TGHf?= Message-ID: <20111111235526.GC17792@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <1321046480.8512.3.camel@bevan-pc.fritz.box> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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: Fri, 11 Nov 2011 23:57:32 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 11, 2011 at 10:21:20PM +0100, Michael La?? wrote: > Hi! > > Sorry for my late response. > > Am Montag, den 07.11.2011, 09:59 -0800 schrieb YongHyeon PYUN: > > > > > > Some revisions of RealTek controller have FIFO overrun issue but > > > I'm not sure whether you're seeing the issue. Try enabling flow > > > control and see whether that makes any difference. You can enable > > > it by issuing 'ifconfig re0 media flow'. > > > > This should be read as 'ifconfig re0 mediaopt flow'. > > It may be that enabling flow control helps a bit but it definately does > not solve the problem. There are still hundreds of packets missed in > just one or two minutes. Maybe there is no difference at all. > Ok, try attached patch and let me know how it works. > > > Show me the dmesg output. RealTek uses the same device PCI ids so it's > > > impossible to know which controller you have from the pciconf(8) > > > output. > > I think the relevant part is this one: > > re0: port 0x1000-0x10ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci1 > > re0: Using 1 MSI-X message > > re0: Chip rev. 0x2c000000 > > re0: MAC rev. 0x00000000 > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > re0: Ethernet address: 38:60:77:3e:af:a5 > Your controller is RTL8168E. > Full dmesg output is also attached. > > Greetings, > Michael > > PS: In my first mail I wrote that I can reproduce the problem only with > one of two connected hosts. I think the reason is that the other host > only produces a maximum of 250Mbit/s while the problematic transfers go > up to 550Mbit/s. --vtzGhvizbBRQ85DL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.oflow.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 227451) +++ sys/dev/re/if_re.c (working copy) @@ -2524,6 +2524,8 @@ intrs = RL_INTRS_CPLUS; status = CSR_READ_2(sc, RL_ISR); + if ((status & RL_ISR_FIFO_OFLOW) != 0) + status |= RL_ISR_RX_OVERRUN; CSR_WRITE_2(sc, RL_ISR, status); if (sc->rl_int_rx_act > 0) { intrs &= ~(RL_ISR_RX_OK | RL_ISR_RX_ERR | RL_ISR_FIFO_OFLOW | --vtzGhvizbBRQ85DL-- From owner-freebsd-net@FreeBSD.ORG Sat Nov 12 12:44:31 2011 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 1E6AD106566B for ; Sat, 12 Nov 2011 12:44:31 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 58DF98FC16 for ; Sat, 12 Nov 2011 12:44:29 +0000 (UTC) Received: (qmail 13850 invoked from network); 12 Nov 2011 13:44:28 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Nov 2011 13:44:28 +0100 Message-ID: <1321101868.8512.11.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: pyunyh@gmail.com Date: Sat, 12 Nov 2011 13:44:28 +0100 In-Reply-To: <20111111235526.GC17792@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> <20111111235526.GC17792@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 12:44:31 -0000 Hi! Am Freitag, den 11.11.2011, 15:55 -0800 schrieb YongHyeon PYUN: > > Ok, try attached patch and let me know how it works. Unfortunately it does not make any difference at all. > Your controller is RTL8168E. So I should not trust that Intel data sheet... ;) Greetings, Michael From owner-freebsd-net@FreeBSD.ORG Sat Nov 12 14:04:10 2011 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 DFF731065670 for ; Sat, 12 Nov 2011 14:04:10 +0000 (UTC) (envelope-from bevan@bi-co.net) Received: from tomahna.bi-co.net (tomahna.bi-co.net [178.77.99.158]) by mx1.freebsd.org (Postfix) with ESMTP id 208C28FC08 for ; Sat, 12 Nov 2011 14:04:09 +0000 (UTC) Received: (qmail 19682 invoked from network); 12 Nov 2011 15:04:08 +0100 Received: from ip-109-91-30-235.unitymediagroup.de (HELO ?192.168.178.21?) (109.91.30.235) by tomahna.bi-co.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Nov 2011 15:04:08 +0100 Message-ID: <1321106653.4734.4.camel@bevan-pc.fritz.box> From: Michael =?ISO-8859-1?Q?La=DF?= To: pyunyh@gmail.com Date: Sat, 12 Nov 2011 15:04:13 +0100 In-Reply-To: <1321101868.8512.11.camel@bevan-pc.fritz.box> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> <20111111235526.GC17792@michelle.cdnetworks.com> <1321101868.8512.11.camel@bevan-pc.fritz.box> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.1 Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bevan@bi-co.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 14:04:11 -0000 I should have tried this earlier: When using Windows instead of Linux on the other host I don't have any problems. I'm getting a constant transfer rate of over 500Mbit/s without a single frame missed on the freebsd-machine. So maybe this problem is more related to the ATL1E driver in the linux kernel. Greetings, Michael Am Samstag, den 12.11.2011, 13:44 +0100 schrieb Michael Laß: > Hi! > > Am Freitag, den 11.11.2011, 15:55 -0800 schrieb YongHyeon PYUN: > > > > Ok, try attached patch and let me know how it works. > > Unfortunately it does not make any difference at all. > > > Your controller is RTL8168E. > > So I should not trust that Intel data sheet... ;) > > Greetings, > Michael > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Nov 12 19:31:04 2011 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 D3EC61065670 for ; Sat, 12 Nov 2011 19:31:04 +0000 (UTC) (envelope-from weiler@soe.ucsc.edu) Received: from mail-01.cse.ucsc.edu (mail-01.cse.ucsc.edu [128.114.48.32]) by mx1.freebsd.org (Postfix) with ESMTP id C48C38FC1B for ; Sat, 12 Nov 2011 19:31:04 +0000 (UTC) Received: from erich-weilers-macbook-pro.local (fw01.cghub.ucsc.edu [192.35.223.10]) by mail-01.cse.ucsc.edu (Postfix) with ESMTPSA id E24891009C41 for ; Sat, 12 Nov 2011 11:12:12 -0800 (PST) Message-ID: <4EBEC50C.7020004@soe.ucsc.edu> Date: Sat, 12 Nov 2011 11:12:12 -0800 From: Erich Weiler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: net.isr.maxthreads tunable? 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, 12 Nov 2011 19:31:04 -0000 Greetings! I was looking at this page on BSD firewalling at: https://calomel.org/network_performance.html and got pretty far in it for tuning some pf stuff but am having a couple tuning issues... I'm using FreeBSD 8.1 amd64. I was able to set most the the loader.conf stuff, but "net.isr.maxthreads" seems to always be set to "1" even if I try to set it higher in loader.conf excplicitly (or loader.conf.local). I did some digging and it seems like it is set on boot and is based on the number of CPU cores you have available. Which is weird, because I see 8 cores: # dmesg | grep maxthreads netisr_init: forcing maxthreads to 1 and bindthreads to 0 for device polling # dmesg | grep CPU CPU: Intel(R) Xeon(R) CPU X5677 @ 3.47GHz (3458.02-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc4: on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc6: on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. p4tcc7: on cpu7 SMP: AP CPU #1 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! Seems like netisr_init is overriding my preferences at boot time... Do you know a way around this? It almost seems like netisr_init thinks I have one CPU, if I am reading this right... I can't set net.isr.maxthreads manually either: # sysctl net.isr.maxthreads=3 sysctl: oid 'net.isr.maxthreads' is read only I have a feeling that particular tunable will help a lot if I can get it working. Any assistance appreciated! cheers, erich From owner-freebsd-net@FreeBSD.ORG Sat Nov 12 19:55:37 2011 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 F0065106564A for ; Sat, 12 Nov 2011 19:55:37 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1E78FC08 for ; Sat, 12 Nov 2011 19:55:37 +0000 (UTC) Received: by wwg14 with SMTP id 14so4737406wwg.31 for ; Sat, 12 Nov 2011 11:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OHsP+r1hw14LJqRuz3UG/+dWCrTyt7fr3vLpOAYRQbU=; b=JaHyshNSap6Z+4ebNrK2/Owfyl07fR8oJFe0kIkEwgkiU+SQfcuGsY88dP79UyvdzM cCcJ84j5ALo2nfmpxyoZ2bLHJSz09EExXtxuGEBR0Pn5ceRUBw4g8QaQ1h9fnvCdJR72 rXpfaEEzYUr9XRz7yqm8YWLey8pfFbSo+MgJE= MIME-Version: 1.0 Received: by 10.180.19.9 with SMTP id a9mr19044638wie.32.1321127736425; Sat, 12 Nov 2011 11:55:36 -0800 (PST) Received: by 10.180.95.104 with HTTP; Sat, 12 Nov 2011 11:55:36 -0800 (PST) In-Reply-To: <4EBEC50C.7020004@soe.ucsc.edu> References: <4EBEC50C.7020004@soe.ucsc.edu> Date: Sat, 12 Nov 2011 14:55:36 -0500 Message-ID: From: Ryan Stone To: Erich Weiler Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: net.isr.maxthreads tunable? 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, 12 Nov 2011 19:55:38 -0000 Currently you have to disable DEVICE_POLLING in your kernel config in order to use multiple netisr threads. Back in the spring I was working on a patch to fix this limitation, but at the time I was having trouble getting access to equipment to test it out on. I should be able to get some systems to play with now, so I'll try to resurrect that work.