From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 00:39:11 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 5428E106566B for ; Sun, 20 Feb 2011 00:39:11 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 125F38FC18 for ; Sun, 20 Feb 2011 00:39:11 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PqxKQ-000Nhi-9Q for freebsd-net@freebsd.org; Sun, 20 Feb 2011 01:39:10 +0100 Date: Sun, 20 Feb 2011 01:39:00 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <410175608.20110220013900@nitronet.pl> To: Jack Vogel , Brandon Gooch , Luigi Rizzo , , MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 00:39:11 -0000 Hi guys, lists, It's me, the bi-weekly panic guy. Guess what, it crashed today. As an act of desperation I disabled the pipe dumping script after previous crash, which today turned out to be merely a coincidence and didn't prevent panics. (I thought it to be a longshot anyway, but it was the only change I could associate with beginning of this). The only fix I could come up with, that's very wrong on so many levels, is... 30 1 * * 7 /sbin/shutdown -r +210m "Scheduled weekly reboot." :( ...but it solves it all: panics, inability to dump (which leads to freeze and requires manual intervention to bring system back up). Oh well. Since nobody came up with any interest in having this properly investigated, then I suppose I'm the only one that uses dummynet for some larger-scale traffic shaping - maybe that's my mistake? What others are using? Other tools, Linux, proprietary traffic shapers? I really have trouble writing another sentence in a way that won't make me look like an arrogant schmuck that feels entitled to free support, so I'll stop here. Any more ideas/hints what to do next/pointers how to debug this properly are of course still welcome. From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 02:16: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 CB758106564A; Sun, 20 Feb 2011 02:16:09 +0000 (UTC) (envelope-from jamesbrandongooch@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 397AC8FC0A; Sun, 20 Feb 2011 02:16:09 +0000 (UTC) Received: by wyb32 with SMTP id 32so778680wyb.13 for ; Sat, 19 Feb 2011 18:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pUjBeBuXNG+Cpy4EH8113mhlvhl74esZ6CcNcmrDn3w=; b=scnPmIi4fMoQ8QUeeVUGYjRcMEodUTpw7bao2Ab44oW5ZfweSYIT8gWaKuog3DKoj7 pSSWSQKRbipQTN/mu/v3Cv6BHp47m7ahlFvElWD1TwcPTXdGkAcFKZsPIoxt+rsG3xh0 Ho7cGMZSXf3LZ1xZDwkZGfDoiemf61QgwDq8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uYCsrxKsGdhMkNhc3xuJbAAjN6thI3vaK4fVORExtkj9oBM25TgPrXub0HRZr5GBJu u0W4yn9HssXZHUdIRHi+QStF9srThGeOde6GYDIBac6KbRv7Fakqkie4dWXNWKAOdxEU 4WkAZ6lBx1jG9N7CB/YEG2P3Cpdl+yZPcdJiA= MIME-Version: 1.0 Received: by 10.216.150.129 with SMTP id z1mr1910577wej.113.1298168168046; Sat, 19 Feb 2011 18:16:08 -0800 (PST) Received: by 10.216.244.130 with HTTP; Sat, 19 Feb 2011 18:16:08 -0800 (PST) In-Reply-To: <410175608.20110220013900@nitronet.pl> References: <410175608.20110220013900@nitronet.pl> Date: Sat, 19 Feb 2011 20:16:08 -0600 Message-ID: From: Brandon Gooch To: Pawel Tyll Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 02:16:09 -0000 2011/2/19 Pawel Tyll : > Hi guys, lists, > > It's me, the bi-weekly panic guy. Guess what, it crashed today. As an > act of desperation I disabled the pipe dumping script after previous > crash, which today turned out to be merely a coincidence and didn't > prevent panics. (I thought it to be a longshot anyway, but it was the > only change I could associate with beginning of this). The only fix I > could come up with, that's very wrong on so many levels, is... > > 30 1 * * 7 /sbin/shutdown -r +210m "Scheduled weekly reboot." > > :( > > ...but it solves it all: panics, inability to dump (which leads to > freeze and requires manual intervention to bring system back up). Oh > well. > > Since nobody came up with any interest in having this properly > investigated, then I suppose I'm the only one that uses dummynet for > some larger-scale traffic shaping - maybe that's my mistake? What > others are using? Other tools, Linux, proprietary traffic shapers? I > really have trouble writing another sentence in a way that won't make > me look like an arrogant schmuck that feels entitled to free support, > so I'll stop here. Any more ideas/hints what to do next/pointers how > to debug this properly are of course still welcome. Same backtrace as reported here? http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 What revision of the em(4) driver code are you using? I know Jack has been working out certain quirky issues lately, and there have been updates to the code since last you posted an update to your problem. STABLE: http://svn.freebsd.org/viewvc/base?view=revision&revision=217711 RELENG: http://svn.freebsd.org/viewvc/base?view=revision&revision=217865 Maybe Jack could shed some light on the whether the updates could somehow work out to be a fix for your problem -- or whether or not your issue is even related to the em(4) driver. -Brandon From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 02: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 D9FE9106564A; Sun, 20 Feb 2011 02:40:09 +0000 (UTC) (envelope-from jfvogel@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 78BEB8FC08; Sun, 20 Feb 2011 02:40:09 +0000 (UTC) Received: by vxa40 with SMTP id 40so2805907vxa.13 for ; Sat, 19 Feb 2011 18:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3LwggtY88fi/XzOy000iC9l5qKGTjuw7dEDUk2DzSG0=; b=DMrBhZizShYrWav5qGW3JL6Wv2N0Mq/tg6JLAMcxOQvxnkn5YwtOagag8EOveYTlKq CvNEkLEVFlFeY86xPcFyJcRV8MlIyjebAivAdU2OTTeLBGvyYFUV8U/O31HHI1ExadzY FiIpn6HA3tEB0BKqV2KtnkCEAzxwWAk3PD1zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UDnUA/ho1RACWn71+4YqwWmzosfjSZv6d6XXGCxHHIhsHiq7833ARa8kFaurbE3M1f TWeRbGzoBRo4olltQyUJQEkBDnWzrHwKlhvwApCjvB9zX8Fwz2k09zgWwZys3sjFcTAF 00CtuLY0JCvcwkxAq6lp9Y3C8x2tedRgTMLbM= MIME-Version: 1.0 Received: by 10.52.165.136 with SMTP id yy8mr3951665vdb.68.1298169608385; Sat, 19 Feb 2011 18:40:08 -0800 (PST) Received: by 10.52.160.5 with HTTP; Sat, 19 Feb 2011 18:40:08 -0800 (PST) In-Reply-To: References: <410175608.20110220013900@nitronet.pl> Date: Sat, 19 Feb 2011 18:40:08 -0800 Message-ID: From: Jack Vogel To: Brandon Gooch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Tyll , freebsd-net@freebsd.org, Luigi Rizzo , freebsd-ipfw@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 02:40:09 -0000 I've never seen a trace like this, and no absolutely nothing about dummynet, sorry. If it is in some way em's fault, then making sure you have the latest code would be a good idea. I have a test driver that is under selective test, it does effect the code path that you seem to be in, so it might be worth a try. If you want to try it early just pipe up and I'll send it. Jack On Sat, Feb 19, 2011 at 6:16 PM, Brandon Gooch wrote: > 2011/2/19 Pawel Tyll : > > Hi guys, lists, > > > > It's me, the bi-weekly panic guy. Guess what, it crashed today. As an > > act of desperation I disabled the pipe dumping script after previous > > crash, which today turned out to be merely a coincidence and didn't > > prevent panics. (I thought it to be a longshot anyway, but it was the > > only change I could associate with beginning of this). The only fix I > > could come up with, that's very wrong on so many levels, is... > > > > 30 1 * * 7 /sbin/shutdown -r +210m "Scheduled weekly reboot." > > > > :( > > > > ...but it solves it all: panics, inability to dump (which leads to > > freeze and requires manual intervention to bring system back up). Oh > > well. > > > > Since nobody came up with any interest in having this properly > > investigated, then I suppose I'm the only one that uses dummynet for > > some larger-scale traffic shaping - maybe that's my mistake? What > > others are using? Other tools, Linux, proprietary traffic shapers? I > > really have trouble writing another sentence in a way that won't make > > me look like an arrogant schmuck that feels entitled to free support, > > so I'll stop here. Any more ideas/hints what to do next/pointers how > > to debug this properly are of course still welcome. > > Same backtrace as reported here? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 > > What revision of the em(4) driver code are you using? I know Jack has > been working out certain quirky issues lately, and there have been > updates to the code since last you posted an update to your problem. > > STABLE: > http://svn.freebsd.org/viewvc/base?view=revision&revision=217711 > > RELENG: > http://svn.freebsd.org/viewvc/base?view=revision&revision=217865 > > Maybe Jack could shed some light on the whether the updates could > somehow work out to be a fix for your problem -- or whether or not > your issue is even related to the em(4) driver. > > -Brandon > From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 02:52:14 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 E12D9106566B; Sun, 20 Feb 2011 02:52:14 +0000 (UTC) (envelope-from jamesbrandongooch@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 4DFFD8FC1B; Sun, 20 Feb 2011 02:52:13 +0000 (UTC) Received: by wyb32 with SMTP id 32so790341wyb.13 for ; Sat, 19 Feb 2011 18:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R332/FWu8irzFwewWsezD1xO59NXaxdDG2VfMSE2cqk=; b=GLgQM20k2fdTbthl2B+AGfIP6b6M8rSTBVQrBg/DjACDrTHP+S/ptOynKuZhCysfF2 mvKrf+YEf51Lit+RxaUgClnZ/PJhSvggjddnsqua+fdY+NksquMt1MVYCBNCy4B0VcDq GbJORMxQ+ZU87ZoCEbE5n3Xv8OOm+OKUz5R/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cvqFHeyngiqB6lvdOQpIChi93rHycutNamicqIOiJiRvlBssz9p2bJHdeVQZgGxFBv CCDiMovJT7X04VKA/TUaiz+zXywwHg3MvPYCKvzfEXgWLyO+SuZRF6pcvlj+zWlI1P+B 0nPExMAV5c8fCovvE2uf9llcZDG16DRp+9wlI= MIME-Version: 1.0 Received: by 10.216.19.133 with SMTP id n5mr838430wen.83.1298170332959; Sat, 19 Feb 2011 18:52:12 -0800 (PST) Received: by 10.216.244.130 with HTTP; Sat, 19 Feb 2011 18:52:12 -0800 (PST) In-Reply-To: References: <410175608.20110220013900@nitronet.pl> Date: Sat, 19 Feb 2011 20:52:12 -0600 Message-ID: From: Brandon Gooch To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Pawel Tyll , freebsd-net@freebsd.org, Luigi Rizzo , freebsd-ipfw@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 02:52:15 -0000 On Sat, Feb 19, 2011 at 8:40 PM, Jack Vogel wrote: > I've never seen a trace like this, and no absolutely nothing about dummynet, > sorry. > If it is in some way em's fault, then making sure you have the latest code > would be > a good idea. I have a test driver that is under selective test, it does > effect the code > path that you seem to be in, so it might be worth a try. If you want to try > it early > just pipe up and I'll send it. > > Jack I was actually going to suggest Pawl try a different network device if possible. I'm using dummynet on a network gateway equipped with on-board bge(4). I haven't had any crashes, but then again, I'm not seeing that many packets either. -Brandon From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 03:25: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 EA0861065674 for ; Sun, 20 Feb 2011 03:25:03 +0000 (UTC) (envelope-from mail@miketm.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C46D98FC25 for ; Sun, 20 Feb 2011 03:25:03 +0000 (UTC) Received: by pxi20 with SMTP id 20so111538pxi.13 for ; Sat, 19 Feb 2011 19:25:03 -0800 (PST) Received: by 10.142.178.6 with SMTP id a6mr1914023wff.196.1298170847091; Sat, 19 Feb 2011 19:00:47 -0800 (PST) Received: from [172.16.4.6] (sandbox.bentdata.com [123.243.191.201]) by mx.google.com with ESMTPS id n4sm4752983wfl.14.2011.02.19.19.00.44 (version=SSLv3 cipher=OTHER); Sat, 19 Feb 2011 19:00:46 -0800 (PST) Message-ID: <4D6083AA.6010201@miketm.com> Date: Sun, 20 Feb 2011 12:59:54 +1000 From: Mike M User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ARP issue post DDoS 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, 20 Feb 2011 03:25:04 -0000 Hi, After receiving a DDoS recently (likely SYN related on ports with legitimate services), I was unable to contact my primary interface gateway (immediate switch it's connected to). When I looked at the ARP table I saw an 'incomplete' entry for this gateway. I deleted it manually then watched the ARP traffic on the interface and saw the who-has requests, but saw no replies. NOC suggested that something looked messed up in the TCP/IP stack of the OS and suggested I reboot the machine. When I rebooted, everything came right again. Any ideas what caused this, or moreso how to prevent it from happening in the future? I'm concerned it will happen again and obviously don't want to have to keep rebooting the machine. The box is running FreeBSD 8.1-RELEASE-p2 Intel Xeon 2.4GHz w/4GB RAM 2 x NetXtreme Gigabit Ethernet PCI Express (BCM5721) No idea if the below helps or not. Note the netstat statistics were not captured at the time this happened, I just grabbed them now. # pfctl -s memory states hard limit 10000000 src-nodes hard limit 10000 frags hard limit 5000 tables hard limit 1000 table-entries hard limit 100000 # netstat -m 1027/11393/12420 mbufs in use (current/cache/total) 1025/4215/5240/65000 mbuf clusters in use (current/cache/total/max) 1024/3456 mbuf+clusters out of packet secondary zone in use (current/cache) 0/199/199/12800 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) 2306K/12074K/14381K 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 Any help would be much appreciated. Regards, - Mike From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 03:39: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 7B4C31065694 for ; Sun, 20 Feb 2011 03:39:09 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 374D28FC2E for ; Sun, 20 Feb 2011 03:39:09 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pr08a-000AJV-EY for freebsd-net@freebsd.org; Sun, 20 Feb 2011 04:39:08 +0100 Date: Sun, 20 Feb 2011 04:38:02 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1385625194.20110220043802@nitronet.pl> To: Brandon Gooch In-Reply-To: References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 03:39:09 -0000 > Same backtrace as reported here? I'm unable to get the new backtrace, but judging from what I can see on the console pre-reboot, it's exactly the same deal since 8.0-RELEASE - panic with dummynet as main star. > What revision of the em(4) driver code are you using? I know Jack has > been working out certain quirky issues lately, and there have been > updates to the code since last you posted an update to your problem. em0: port 0x2040-0x205f mem 0x= b1a00000-0xb1a1ffff,0xb1a25000-0xb1a25fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:... em1: port 0x1000-0x101f mem 0x= b1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci2 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:.. > Maybe Jack could shed some light on the whether the updates could > somehow work out to be a fix for your problem -- or whether or not > your issue is even related to the em(4) driver. I'm not sure anymore that em is at fault here. Anyway, currently I'm running FreeBSD 8.2-PRERELEASE #1: Fri Jan 7 17:19:28. If something happened since then that could fix this, I'll gladly update. From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 03:45: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 1BB3B106566B for ; Sun, 20 Feb 2011 03:45:36 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 915B68FC08 for ; Sun, 20 Feb 2011 03:45:35 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pr0Eo-000AYY-QR for freebsd-net@freebsd.org; Sun, 20 Feb 2011 04:45:34 +0100 Date: Sun, 20 Feb 2011 04:44:27 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1163871443.20110220044427@nitronet.pl> To: Brandon Gooch In-Reply-To: References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 03:45:36 -0000 > I was actually going to suggest Pawl try a different network device if > possible. I'm using dummynet on a network gateway equipped with > on-board bge(4). I haven't had any crashes, but then again, I'm not > seeing that many packets either. It seems to be closely related to amount of processed packets. We've connected some new customers recently, which obviously translated to more traffic and more pipes: # Uptime | System Bo= ot up ----------------------------+----------------------------------------------= ----- 1 15 days, 05:42:23 | FreeBSD 8.2-PRERELEASE Wed Dec 22 16:19:55= 2010 2 14 days, 22:31:42 | FreeBSD 8.2-PRERELEASE Sun Jan 9 03:07:59= 2011 3 14 days, 05:25:46 | FreeBSD 8.2-PRERELEASE Mon Jan 24 01:55:34= 2011 4 12 days, 15:42:45 | FreeBSD 8.2-PRERELEASE Mon Feb 7 07:30:07= 2011 In general, our traffic increases, which apparently translates to crashing sooner. When all this started I remember seeing crashes closer to three weeks, but now it surprised me by crashing two days "early". As to trying different device, these are on-board interfaces on Intel mainboard. I don't have any experience with external pci express adapters other than Intel's, could you recommend something stable? From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 03:55:46 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 6CAB3106566B for ; Sun, 20 Feb 2011 03:55:46 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 265C38FC0A for ; Sun, 20 Feb 2011 03:55:45 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pr0Of-000AuN-72 for freebsd-net@freebsd.org; Sun, 20 Feb 2011 04:55:45 +0100 Date: Sun, 20 Feb 2011 04:54:34 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1145317277.20110220045434@nitronet.pl> To: Jack Vogel In-Reply-To: References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Luigi Rizzo , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 20 Feb 2011 03:55:46 -0000 > I've never seen a trace like this, and no absolutely nothing about dummyn= et, sorry. > If it is in some way em's fault, then making sure you have the latest cod= e would be > a good idea. I have a test driver that is under selective test, it does e= ffect the code > path that you seem to be in, so it might be worth a try. If you want to t= ry it early > just pipe up and I'll send it. I'm less and less sure that it has anything to do with em. I'd like to hear Luigi's take on all this. That being said, I'll gladly try the new driver -- if I'm right, I'll drop under 7 day reboot threshold later into the year anyway, so I really need a permanent solution of some kind. Apparently next crash always comes sooner that previous one, which coincides with growing traffic. From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 05:03: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 957CF106566B for ; Sun, 20 Feb 2011 05:03:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52BBF8FC0A for ; Sun, 20 Feb 2011 05:03:58 +0000 (UTC) Received: by iwn39 with SMTP id 39so5084554iwn.13 for ; Sat, 19 Feb 2011 21:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TS55hGKCra4ZO8Se7kZNyMBDvW2IYOeOpLylukY1ELk=; b=IIi59TbSfmOZVptZ35hvXxJWi9H8CUhfegPHOOw658asb7ECESnw9pBHNhGPLlSvp/ gf0TZX0Tx7tYnKJh7k+5Rcv7NObr6+qOYO+bDl+OhH8BLSv0mLaeGBn2sXwG9DFDImAr dfbWGX2sxD2LXd7Qujd9AtgF5xepbMM1idDNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cHRooYji2wlK75l3Pu64DLKCdfJOn80jiN4/22HtOAcAyVO3lEzzd0DH1I0ANHPvHP 21CqTVCWKKP/jyQEAd5J2Qldv08/4Px21DpZ6vKiDX5AR/Z0+aENRf8Zs7vml51iGWJK tDapeWrrTZRFat0plq/Cwuj+WKq+nq6lQQIto= MIME-Version: 1.0 Received: by 10.42.169.133 with SMTP id b5mr45679icz.189.1298178237526; Sat, 19 Feb 2011 21:03:57 -0800 (PST) Received: by 10.42.154.8 with HTTP; Sat, 19 Feb 2011 21:03:57 -0800 (PST) In-Reply-To: References: <12838373-FE96-443E-8979-AF5408705BF0@freebsd.org> Date: Sun, 20 Feb 2011 00:03:57 -0500 Message-ID: From: Arnaud Lacombe To: Karim Fodil-Lemelin , Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: igb driver RX (was TX) hangs when out of mbuf clusters 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, 20 Feb 2011 05:03:58 -0000 Hi Jack, It would seem I've just been encountering this issue on an `em' interface as well (chip ID 0x10d38086). The system has been up for a bit more than a day. netstat(1) list about 2500 clusters allocation denial. The mentioned interface was unable to receive traffic, however, it continued to transmit ARP request. Comparing the output of sysctl's statistics showed an increase of "missed packets": Over a 10s time frame: -dev.em.5.mac_stats.missed_packets: 288412 +dev.em.5.mac_stats.missed_packets: 288423 TX accounting and INTR count got up as I'd expect. Doing an `ifconfig down && ifconfig up' restored the connectivity. - Arnaud On Fri, Feb 11, 2011 at 2:53 PM, Karim Fodil-Lemelin wrote: > Hi, > > I see a commit was made in current (r218530 | jfv | 2011-02-10 20:00:26 > -0500 (Thu, 10 Feb 2011)). Is that commit done to address this issue? > > And if so Is there any MFC planned for 7.4 for this? > > Thanks, > > Karim. > > 2011/2/9 Michael Tuexen > >> On Feb 9, 2011, at 6:35 PM, Jack Vogel wrote: >> >> > OK, but the question is why does the ring get totally consumed this wa= y, >> the >> > ring has 1024 descriptors, it seems unintuitive that that whole quanti= ty >> can be >> > used without some being recharged. Do you see the system mbuf pool bei= ng >> > depleted at the same time? >> That was the test case I created: I set up a server accepting connection= s >> but not reading anything. So the driver passes the mbufs to the transpor= t >> stack and they are not consumed. Then the problem occurs. Then I kill th= e >> server. Now there are mbufs available again, but the driver doesn't know= . >> >> I had the impression that these were the circumstances in which the prob= lem >> showed up (mbuf allocations failing). >> > >> > Since you can reproduce it, do me a favor, in rxeof, =A0change the >> processed >> > value from 8 to 4 and then 1, effectively call refresh every descripto= r, >> see if >> > that eliminates the issue. >> I will do. Need to see if I can do it remotely, since I'm not in my lab >> right now. Can do it tomorrow for sure. >> >> But I do not think that this solves the problem, since I did the things >> very slowly and you call it at least when you are leaving rxeof. >> >> Best regards >> Michael >> > >> > Thanks for your help, >> > >> > Jack >> > >> > >> > On Wed, Feb 9, 2011 at 2:36 AM, Michael Tuexen >> wrote: >> > Hi Jack, >> > >> > I could recreate the problem. When the problem occurs, we see >> > >> > rx_nxt_check =3D n >> > rx_nxt_refresh =3D n + 1 >> > >> > (This was also reported in a mail from Karim) >> > >> > This means that the *whole* receive ring has no buffers anymore. This = can >> > occur if, for some amount of time, no clusters are available. >> > >> > Now outside of the driver, at some point of time, clusters are freed. >> > I don't think that igb_refresh_mbufs() gets called, since it only gets >> > called from igb_rxeof(), which gets called when a packet has been >> received, >> > which can not happen since the receive ring is empty. So how can the >> driver >> > know? I have no idea. Maybe we can periodically check for such an even= t >> > and call igb_refresh_mbufs(). >> > >> > Does this make sense to you? >> > >> > Best regards >> > Michael >> > >> > >> > On Feb 9, 2011, at 8:32 AM, Jack Vogel wrote: >> > >> > > Hmmm, well so much for that theory :) >> > > >> > > Jack >> > > >> > > >> > > On Tue, Feb 8, 2011 at 4:06 PM, Karim Fodil-Lemelin < >> fodillemlinkarim@gmail.com> wrote: >> > > >> > > >> > > 2011/2/8 Jack Vogel >> > > >> > > >> > > I have been following this, and thinking about it. I still am workin= g >> from a theoretical >> > > standpoint, but based on a patch I got quite a long time back and ne= ver >> quite groked, >> > > I believe now that I might have a solution. >> > > >> > > The original PR and patch was kern/150516 from Beezar Liu, =A0I was = never >> quite comfortable >> > > with the code changes, nor convinced that it was a real issue and no= t a >> misunderstanding. >> > > However I think now that this very report might be behind what we ar= e >> seeing today. I have >> > > a slightly different approach to solving it, of course it remains to= be >> seen if it handles it >> > > properly. >> > > >> > > Please try the patch I've attached, I'm open to further correction o= r >> polishing of the >> > > changes. And thanks to Beezar for his original report and changes, t= his >> is not for em, >> > > but if this eliminates the problem its clearly needed in all drivers= . >> > > >> > > Jack >> > > >> > > >> > > Hi Jack, >> > > >> > > Thanks for your help. I tried your patch and it didn't work so I add= ed >> a couple of printf to see if the added code was getting hit: >> > > >> > > --- a/freebsd/sys/dev/e1000/if_igb.c >> > > --More--(byte 1253)+++ b/freebsd/sys/dev/e1000/if_igb.c >> > > @@ -612,7 +612,7 @@ igb_attach(device_t dev) >> > > =A0 =A0 =A0 =A0 =A0 =A0 device_get_nameunit(dev)); >> > > >> > > =A0 =A0 =A0 =A0 INIT_DEBUGOUT("igb_attach: end"); >> > > - >> > > + =A0 =A0 =A0 printf("this driver has a patch from Jack Vogel\n"); >> > > =A0 =A0 =A0 =A0 return (0); >> > > >> > > =A0err_late: >> > > @@ -4131,6 +4131,7 @@ igb_rxeof(struct igb_queue *que, int count, in= t >> *done) >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct mbuf =A0 =A0 =A0 =A0 =A0 =A0 = *sendmp, *mh, *mp; >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct igb_rx_buf =A0 =A0 =A0 *rxbuf= ; >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 u16 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 hlen, plen, hdr, vtag; >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 commit; >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bool =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0eop =3D FALSE; >> > > >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cur =3D &rxr->rx_base[i]; >> > > @@ -4255,10 +4256,23 @@ next_desc: >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bus_dmamap_sync(rxr->rxdma.dma_tag, = rxr->rxdma.dma_map, >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 BUS_DMASYNC_PREREAD | BUS_DM= ASYNC_PREWRITE); >> > > >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 commit =3D i; =A0 =A0 /* capture the o= ld index */ >> > > + >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Advance our pointers to the next = descriptor. */ >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (++i =3D=3D adapter->num_rx_desc) >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i =3D 0; >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ** Sanity test for ring full, if this >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ** happens we need to refresh immediat= ely >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ** or refresh may deadlock. >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (i =3D=3D rxr->next_to_refresh) { >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_refresh_mbufs(rxr,= commit); >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("igb_refresh_mb= ufs called with commit >> %d\n", commit); >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 processed =3D 0; >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >> > > + >> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ** Send to the stack or LRO >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */ >> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (sendmp !=3D NULL) { >> > > >> > > Here is the results: >> > > >> > > # dmesg | grep Vogel >> > > this driver has a patch from Jack Vogel >> > > this driver has a patch from Jack Vogel >> > > >> > > # netstat -m >> > > 60453/52707/113160 mbufs in use (current/cache/total) >> > > 48416/51584/100000/100000 mbuf clusters in use >> (current/cache/total/max) >> > > 2894/690 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> > > 11946/854/12800/12800 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) >> > > 164834K/119760K/284595K bytes allocated to network >> (current/cache/total) >> > > 0/339/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> > > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> > > 0/4/6656 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 >> > > # dmesg | grep commit >> > > >> > > At this point RX has hung. >> > > >> > > Somehow the check (i =3D=3D rxr->next_to_refresh) is never true in t= his >> case. Also, I did read kern/150516 and couldn't wrap my head around the >> patch for the em driver that Beezar Liu suggested. >> > > >> > > Regards, >> > > >> > > Karim. >> > > >> > > >> > >> > >> >> > _______________________________________________ > 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 Feb 20 10:51: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 1E4B1106564A for ; Sun, 20 Feb 2011 10:51:31 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 81AF48FC08 for ; Sun, 20 Feb 2011 10:51:30 +0000 (UTC) Received: (qmail invoked by alias); 20 Feb 2011 10:51:29 -0000 Received: from adsl-124.91.140.30.tellas.gr (EHLO [192.168.73.192]) [91.140.30.124] by mail.gmx.com (mp-eu005) with SMTP; 20 Feb 2011 11:51:29 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX19YSI1vhGBYUHt/O4JG2AradHLp92z82PG8DZZx5S MyJvGKDHS17PeG Message-ID: <4D60F1E9.8020707@gmx.com> Date: Sun, 20 Feb 2011 12:50:17 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Tom Judge References: <000c01cbcf94$35e76e20$a1b64a60$@com> <4D5FAC16.7080207@gmx.com> <00a201cbd03f$2bdc3540$83949fc0$@com> <4D5FD91F.20704@gmx.com> <4D5FDCF1.6050909@gmx.com> <00a501cbd04f$2276b5b0$67642110$@com> <4D5FFE9C.30005@tomjudge.com> In-Reply-To: <4D5FFE9C.30005@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org, kevin Subject: Re: Bridging + VLANS + RSTP / MSTP 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, 20 Feb 2011 10:51:31 -0000 On 2/19/2011 7:32 PM, Tom Judge wrote: > In this setup it does not matter where the root bridge is, each of the > firewalls will always have on port in disguarding state as both ports > lead back to the same peer bridge. With states such as: > > fw 1 - 1: forwarding > fw 2 - 1: forwarding > fw 1 - 2: disguarding - backup > fw 2 - 2: disguarding - backup > If I got the topology correctly, it is supposed to be like this: (Broadcast domain 1) | | | | | | (fw1) (fw2) | | | | | | (Broadcast domain 2) If fw1 is the root bridge, then it'll look like this: (Broadcast domain 1) | | | | D R (fw1) (fw2) D B | | | | (Broadcast domain 2) fw2 will have one root port and one backup, and the fw1 will have two designated ports. Since the switch will not take part in the STP, there is no single bridge. If I get the topology correctly... > > There is a also the caveat: The switch will probably _not_ forward the > STP BPDU's from one port to another. This is because if the switch is a > properly compliant bridge it will not forwards the frames as they are > marked as link local ethernet multicast frame which is not allowed to > forwarded by a bridge per the ethernet spec. If this is indeed the case > you will make an instant forwarding loop in your network when you try to > make it work. Yes this is true, but when a port is not running STP it is not considered to be part of a compliant bridge so there should be mechanism to allow forwarding BPDUs to the other bridges that run STP. Like when one combines simple unmanaged switches(with no STP functionality) with managed ones. The unmanaged ones simply forward everything they receive and the STP ones can detect and break the loops. Nikos From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 14:05: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 2CE1F106566B for ; Sun, 20 Feb 2011 14:05:08 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id AF4CF8FC08 for ; Sun, 20 Feb 2011 14:05:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B573B73098; Sun, 20 Feb 2011 14:58:55 +0100 (CET) Date: Sun, 20 Feb 2011 14:58:55 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20110220135855.GA4794@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145317277.20110220045434@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) 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, 20 Feb 2011 14:05:08 -0000 On Sun, Feb 20, 2011 at 04:54:34AM +0100, Pawel Tyll wrote: > > I've never seen a trace like this, and no absolutely nothing about dummynet, sorry. > > If it is in some way em's fault, then making sure you have the latest code would be > > a good idea. I have a test driver that is under selective test, it does effect the code > > path that you seem to be in, so it might be worth a try. If you want to try it early > > just pipe up and I'll send it. > I'm less and less sure that it has anything to do with em. I'd like to > hear Luigi's take on all this. That being said, I'll gladly try the > new driver -- if I'm right, I'll drop under 7 day reboot threshold > later into the year anyway, so I really need a permanent solution of > some kind. Apparently next crash always comes sooner that previous > one, which coincides with growing traffic. > i fully welcome pawel's (or everyone else's) bug reports, and consider them as his contribution to improve the system and not as a way to get free consulting, so no need for him to apolgize. In fact, i even welcome direct emails if people feel i missed some reports which i should read. At the same time, everyone should understand that some bugs are hard and time-consuming to track down, and so when the presentation suggests that the problem falls in this category, even developers with deep knowledge of the subsystems involved may step back because of lack of time (and this would not be fixable even if monetary incentives were involved). Conversely, there are cases where somehow one can quickly identify a problem and a fix, and you see it coming out either as a commit to the source tree, or as a patch by email. I have done this myself many times, and have seen the same for many other developers. The way a problem is presented has a big impact on how it gets handled: in this specific case the poster is pointing out a possible culprit (which may be helpful or misleading), and gives no hint on other things that may be relevant: number of interfaces, vlans, tunnels, taps, bpf etc ? any significant other activity on the machine such as interfaces going up or down, routing deamons etc ? amount of traffic ? Without furter details, I can only trust the statements in the report, and this determines how i classify the bug and decide whether i have time or ideas to pursue it. The bug in this case seems to fall in the 'hard, irreproducible' category: panics *always* need many many days to happen on machines under heavy load, no panics on similar machines under lighter load. With a description like this, i am afraid, i can't even start looking at the problem becaue i have no chance to reproduce it. Now let's forget what is in the bug report and dig into the backtrace at http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 assuming that the information there is reliable (which we cannot tell for sure, as the stack could be corrupt). Note that this is some analysis that I would expect the poster to make, because it does not require a huge amount of time and is part of the "fair" sharing of responsibilities to get a bug fixed in a cooperative enviroment. The panic seems to occur in at /usr/src/sys/amd64/amd64/exception.S:223 #7 0xffffffff80698abf in in_localaddr (in=Variable "in" is not available. ) at /usr/src/sys/netinet/in.c:115 which is a piece of code that scans the list of interfaces. The argument to in_localaddr() is an ipv4 addr passed by value, so it is certainly not guilty even if we had a bogus argument. This seems to suggest that the problem is elsewhere -- perhaps some piece of code is manipulating the IN_IFADDR list without locking, causing it to become corrupt ? cheers luigi -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 22:50:50 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 AB74D106564A for ; Sun, 20 Feb 2011 22:50:50 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 65F7F8FC08 for ; Sun, 20 Feb 2011 22:50:50 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrI77-000DLA-M3 for freebsd-net@freebsd.org; Sun, 20 Feb 2011 23:50:49 +0100 Date: Sun, 20 Feb 2011 23:50:28 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <288793167.20110220235028@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20110220135855.GA4794@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) 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, 20 Feb 2011 22:50:50 -0000 > The way a problem is presented has a big impact on how it gets handled: > in this specific case the poster is pointing out a possible culprit > (which may be helpful or misleading), and gives no hint on other > things that may be relevant: number of interfaces, vlans, tunnels, taps, > bpf etc ? any significant other activity on the machine such as interfaces > going up or down, routing deamons etc ? amount of traffic ? > Without furter details, I can only trust the statements in the report, > and this determines how i classify the bug and decide whether i have time > or ideas to pursue it. > The bug in this case seems to fall in the 'hard, irreproducible' category: > panics *always* need many many days to happen on machines under heavy loa= d, > no panics on similar machines under lighter load. > With a description like this, i am afraid, i can't even start looking > at the problem becaue i have no chance to reproduce it. This machine is only doing dummynet traffic shaping from significant things (otherwise it runs a dhcpd, ntpd and named). It's pretty straight-forward routing, packets come in, packets come out via static routes - there are currently no routing daemons involved. As to the interfaces, there are two physical ifaces, em0 and em1, only em1 is currently used. There are 49 vlan interfaces connected to em1, and they are pretty much static, no IP address changes, no interfaces going up or down, sometimes new one is being added, but there is no automation here, and panics do not coincide with anything significant in logs, or being done manually. Traffic oscillates between 20k pps at night and close to 35-40k pps daytime, slightly more on weekends. There are currently 2556 pipes defined and traffic shaping is done with two rules: 30000 pipe tablearg ip from table(100) to any in 30001 pipe tablearg ip from any to table(101) out Currently running FreeBSD 8.2-PRERELEASE #1: Fri Jan 7 17:19:28 CET 2011, but problem persists since 8.0-RELEASE net.inet.flowtable.enable=3D0 net.inet.ip.fw.one_pass=3D0 net.inet.tcp.blackhole=3D2 net.inet.udp.blackhole=3D1 net.inet.ip.random_id=3D1 net.inet.ip.forwarding=3D1 kern.ipc.maxsockbuf=3D8388608 net.inet.tcp.sendspace=3D4194304 net.inet.tcp.recvspace=3D4194304 net.inet.udp.recvspace=3D1048576 net.inet.udp.maxdgram=3D65536 net.inet.ip.fw.dyn_buckets=3D16384 net.inet.ip.fw.dyn_max=3D65536 hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz hw.ncpu: 8 hw.byteorder: 1234 hw.physmem: 4240433152 hw.usermem: 2734768128 Base Board Information Manufacturer: Intel Corporation Product Name: S3420GP em1: port 0x1000-0x101f mem 0x= b1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci2 em1: Using MSIX interrupts with 3 vectors If I missed anything here, then just tell me what more I can do, my intentions were never to make this harder to debug or hide anything relevant. From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 23:04: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 4247E106566B; Sun, 20 Feb 2011 23:04:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 00CB58FC15; Sun, 20 Feb 2011 23:04:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CAEB473098; Mon, 21 Feb 2011 00:18:25 +0100 (CET) Date: Mon, 21 Feb 2011 00:18:25 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20110220231825.GA10566@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> <288793167.20110220235028@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <288793167.20110220235028@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) 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, 20 Feb 2011 23:04:56 -0000 On Sun, Feb 20, 2011 at 11:50:28PM +0100, Pawel Tyll wrote: ... > This machine is only doing dummynet traffic shaping from significant > things (otherwise it runs a dhcpd, ntpd and named). It's pretty > straight-forward routing, packets come in, packets come out via static > routes - there are currently no routing daemons involved. As to the > interfaces, there are two physical ifaces, em0 and em1, only em1 is > currently used. There are 49 vlan interfaces connected to em1, and > they are pretty much static, no IP address changes, no interfaces > going up or down, sometimes new one is being added, but there is no > automation here, and panics do not coincide with anything significant > in logs, or being done manually. Traffic oscillates between 20k pps at > night and close to 35-40k pps daytime, slightly more on weekends. > There are currently 2556 pipes defined and traffic shaping is done > with two rules: > > 30000 pipe tablearg ip from table(100) to any in > 30001 pipe tablearg ip from any to table(101) out > ... > If I missed anything here, then just tell me what more I can do, my > intentions were never to make this harder to debug or hide anything > relevant. understood. I am just saying that for instance the vlan presence and changes is quite significant in this context. You say vlans are "pretty much static" but can you tell us who adds/remove them, assign addresses ? Also the ruleset must have something more than those two rules. >From the stack trace, the panic seems to occur in a call to the "antispoof" option which presumably is somewhere in your ruleset. If not, then the stack is corrupt. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 23:13: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 7FD691065672 for ; Sun, 20 Feb 2011 23:13:41 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 399AA8FC13 for ; Sun, 20 Feb 2011 23:13:41 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrITE-000F1W-Fk for freebsd-net@freebsd.org; Mon, 21 Feb 2011 00:13:40 +0100 Date: Mon, 21 Feb 2011 00:13:12 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1167743969.20110221001312@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20110220231825.GA10566@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> <288793167.20110220235028@nitronet.pl> <20110220231825.GA10566@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) 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, 20 Feb 2011 23:13:41 -0000 > understood. I am just saying that for instance the vlan presence and > changes is quite significant in this context. > You say vlans are "pretty much static" but can you tell us who adds/remove > them, assign addresses ? It's not that much work and changes are simple and far between. I do that personally. IP addresses don't change, however I sometimes (rarely) destroy and recreate vlans. Panics don't happen immediately after this operation, or while it happens, and there were times from panic to panic that I didn't touch a thing. > Also the ruleset must have something more than those two rules. > From the stack trace, the panic seems to occur in a call to the > "antispoof" option which presumably is somewhere in your ruleset. > If not, then the stack is corrupt. Full ruleset with IP addresses removed: 00010 1691 128516 deny ip from any to any not antispoof in 00020 87440010 6826835332 fwd [removed] ip from table(60) to table(61) 00050 3246 156244 allow tcp from any to [removed] dst-port 53 = // DNS Rules 50-59 00051 2463493 260607132 allow udp from any to [removed] // DNS Rules= 50-59 00059 23891 1091822 deny ip from any to [removed] // DNS Rules 5= 0-59 00100 32 2176 allow ip from any to any via lo0 00100 929493 48342523 deny ip from any to table(10) dst-port 131-1= 39,445 00102 56574 2779124 fwd [removed] tcp from table(1) to not table= (5) dst-port 80 00103 0 0 fwd [removed] tcp from table(2) to not table= (5) dst-port 80 00104 427 17244 fwd [removed] tcp from table(3) to not table= (5) 00105 6 808 deny ip from table(3) to not table(5) 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from any to ::1 00500 0 0 deny ip from ::1 to any 00600 0 0 allow ipv6-icmp from :: to ff02::/16 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6typ= es 1 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6typ= es 2,135,136 30000 462392089 204487140826 pipe tablearg ip from table(100) to any in 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out 34900 11650783 1216622001 skipto 35001 ip from table(10) to table(10) 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not = 192.168.0.0/16 65534 1595697378 1254723485778 allow ip from any to any 65535 0 0 allow ip from any to any 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 Should IP addresses be required, I'll gladly send "uncensored" ruleset to you privately. From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 23:18:29 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 510171065670 for ; Sun, 20 Feb 2011 23:18:29 +0000 (UTC) (envelope-from kungfujesus06@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 D93538FC17 for ; Sun, 20 Feb 2011 23:18:28 +0000 (UTC) Received: by fxm19 with SMTP id 19so2041439fxm.13 for ; Sun, 20 Feb 2011 15:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=YAkF7JCmW73RuLJQwraaL8/uBmVCFMDPcr+Pc7Uypkc=; b=UFmgRGfTNFrE2wkq1rCRAILne/juxS52DdVO0ImlIQBbm2kweCGByAZGkxkdb2A6Rp KZ2r+37R8vsM/Ig/qkrFXhKMFU3oN9glj/KChEL6S9srGCuA87NR7PA9ugTV4edTW8DH r0D+RPwNnl3YrrzSZdqDGtSwB4K0xojM1dcV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RvprfHJ/vIbmgPt8ldZ6gKC+1+rCtPh6q28siJzi+yyYBSLOfjVCIWbFqFmrCTOTh3 GmavthCMmyW9a79QR9or/3k90dajGqX83bbr1KPmhTjHia7YvKd77qBuAhRyZZS+sM52 KSbeYdywELqNjcVNaYdG/QupJzc3KVx5WDhvc= MIME-Version: 1.0 Received: by 10.223.104.147 with SMTP id p19mr1002417fao.6.1298242591110; Sun, 20 Feb 2011 14:56:31 -0800 (PST) Received: by 10.223.67.133 with HTTP; Sun, 20 Feb 2011 14:56:31 -0800 (PST) Date: Sun, 20 Feb 2011 17:56:31 -0500 Message-ID: From: Adam Stylinski To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Radiotap, BPF, and related system calls 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, 20 Feb 2011 23:18:29 -0000 Hello, I'm somewhat of a novice C programmer endeavoring in a project to write my own protocol which will sit on top of the 1480 byte 802.3 frames (which are on top of 802.11 frames) to accomplish remote file transmission. The communication will be one way, but one roadblock I'm running into is discovering the exact system calls I have to make to send raw frames. I want to work on the higher level API as opposed to the kernel level (for one I'd like the 802.11 layer to auto fragment the 802.3 frames for me). The exact protocol will require two cards in monitor mode so that raw injection and blind reception can occur. Control signals will be transmitted over a TCP socket via the internet. I've found documentation that points to the system independent radiotap specification, and from there I've seen documentation which talks about initializing the ioctl through a BPF clone to be utilized by userland applications. I'm sure that wireshark and other wireless utilities use this, but there is a boat load of code I've been looking through to find the precise call which opens up the device ioctl, initiates the the tap, and gives me simple functions to construct and transmit my simple frames. I've found in the headers many references to the structs themselves, but I'm not sure where to start to initiate communication through the device. Any 802.11 experts on this list that could perhaps give me some specific instruction or point me to a man page / example code which does this? Thanks in advance for whatever you can offer me. From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 23:42: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 A200D1065670; Sun, 20 Feb 2011 23:42:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 47E298FC12; Sun, 20 Feb 2011 23:42:10 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C7FAA73098; Mon, 21 Feb 2011 00:55:40 +0100 (CET) Date: Mon, 21 Feb 2011 00:55:40 +0100 From: Luigi Rizzo To: Pawel Tyll Message-ID: <20110220235540.GA10655@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> <288793167.20110220235028@nitronet.pl> <20110220231825.GA10566@onelab2.iet.unipi.it> <1167743969.20110221001312@nitronet.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1167743969.20110221001312@nitronet.pl> User-Agent: Mutt/1.4.2.3i Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) 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, 20 Feb 2011 23:42:10 -0000 On Mon, Feb 21, 2011 at 12:13:12AM +0100, Pawel Tyll wrote: > > understood. I am just saying that for instance the vlan presence and > > changes is quite significant in this context. > > You say vlans are "pretty much static" but can you tell us who adds/remove > > them, assign addresses ? > It's not that much work and changes are simple and far between. I do > that personally. IP addresses don't change, however I sometimes > (rarely) destroy and recreate vlans. Panics don't happen immediately > after this operation, or while it happens, and there were times from > panic to panic that I didn't touch a thing. > > > Also the ruleset must have something more than those two rules. > > From the stack trace, the panic seems to occur in a call to the > > "antispoof" option which presumably is somewhere in your ruleset. > > If not, then the stack is corrupt. > Full ruleset with IP addresses removed: > 00010 1691 128516 deny ip from any to any not antispoof in > 00020 87440010 6826835332 fwd [removed] ip from table(60) to table(61) > 00050 3246 156244 allow tcp from any to [removed] dst-port 53 // DNS Rules 50-59 > 00051 2463493 260607132 allow udp from any to [removed] // DNS Rules 50-59 > 00059 23891 1091822 deny ip from any to [removed] // DNS Rules 50-59 > 00100 32 2176 allow ip from any to any via lo0 > 00100 929493 48342523 deny ip from any to table(10) dst-port 131-139,445 > 00102 56574 2779124 fwd [removed] tcp from table(1) to not table(5) dst-port 80 > 00103 0 0 fwd [removed] tcp from table(2) to not table(5) dst-port 80 > 00104 427 17244 fwd [removed] tcp from table(3) to not table(5) > 00105 6 808 deny ip from table(3) to not table(5) > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 0 0 deny ip from any to ::1 > 00500 0 0 deny ip from ::1 to any > 00600 0 0 allow ipv6-icmp from :: to ff02::/16 > 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types 1 > 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 > 30000 462392089 204487140826 pipe tablearg ip from table(100) to any in > 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out > 34900 11650783 1216622001 skipto 35001 ip from table(10) to table(10) > 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not 192.168.0.0/16 > 65534 1595697378 1254723485778 allow ip from any to any > 65535 0 0 allow ip from any to any > > 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 > > Should IP addresses be required, I'll gladly send "uncensored" ruleset > to you privately. addresses not needed, thanks. From what i saw in the backtrace, the panic occurred on an incoming packet on the 'antispoof' option. The ruleset confirms the backtrace, but since 'antispoof' happens to be run on every packet given it is on the first rule, it apparently has nothing to do with dummynet because even if you reinjected the packets, they go to rule 34900. So, i'd still focus the attention on a corrupt interface list. Sure, that memory can be corrupt by anything including dummynet, but there is no reason to believe that dummynet is more likely than other subsystems to cause the breakage. Unfortunately i don't think I can be of more help. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Feb 20 23:51:29 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 29D7710656D8 for ; Sun, 20 Feb 2011 23:51:29 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id D6D158FC17 for ; Sun, 20 Feb 2011 23:51:28 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PrJ3o-000Gqd-5a for freebsd-net@freebsd.org; Mon, 21 Feb 2011 00:51:28 +0100 Date: Mon, 21 Feb 2011 00:50:50 +0100 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <455301788.20110221005050@nitronet.pl> To: Luigi Rizzo In-Reply-To: <20110220235540.GA10655@onelab2.iet.unipi.it> References: <410175608.20110220013900@nitronet.pl> <1145317277.20110220045434@nitronet.pl> <20110220135855.GA4794@onelab2.iet.unipi.it> <288793167.20110220235028@nitronet.pl> <20110220231825.GA10566@onelab2.iet.unipi.it> <1167743969.20110221001312@nitronet.pl> <20110220235540.GA10655@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Jack Vogel , freebsd-net@freebsd.org Subject: Re: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) 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, 20 Feb 2011 23:51:29 -0000 > addresses not needed, thanks. From what i saw in the backtrace, the panic > occurred on an incoming packet on the 'antispoof' option. > The ruleset confirms the backtrace, but since > 'antispoof' happens > to be run on every packet given it is on the first rule, > it apparently has nothing to do with dummynet because even if > you reinjected the packets, they go to rule 34900. > So, i'd still focus the attention on a corrupt interface list. > Sure, that memory can be corrupt by anything including dummynet, > but there is no reason to believe that dummynet is more likely > than other subsystems to cause the breakage. > Unfortunately i don't think I can be of more help. Actually that's a lot of help: new thing to try. I've removed the antispoof rule and automatic reboot. Lets see what comes out of it. From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 06:16: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 1359C106564A for ; Mon, 21 Feb 2011 06:16:32 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4898FC0C for ; Mon, 21 Feb 2011 06:16:31 +0000 (UTC) Received: by bwz13 with SMTP id 13so2010168bwz.17 for ; Sun, 20 Feb 2011 22:16:30 -0800 (PST) Received: by 10.204.61.73 with SMTP id s9mr921541bkh.185.1298268989548; Sun, 20 Feb 2011 22:16:29 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-067-192-041.pools.arcor-ip.net [88.67.192.41]) by mx.google.com with ESMTPS id x38sm3466185bkj.1.2011.02.20.22.16.27 (version=SSLv3 cipher=OTHER); Sun, 20 Feb 2011 22:16:28 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Mon, 21 Feb 2011 07:12:41 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201102210712.41124.bschmidt@freebsd.org> Cc: Adam Stylinski Subject: Re: Radiotap, BPF, and related system calls 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, 21 Feb 2011 06:16:32 -0000 On Sunday 20 February 2011 23:56:31 Adam Stylinski wrote: > Hello, > > I'm somewhat of a novice C programmer endeavoring in a project to > write my own protocol which will sit on top of the 1480 byte 802.3 > frames (which are on top of 802.11 frames) to accomplish remote file > transmission. The communication will be one way, but one roadblock > I'm running into is discovering the exact system calls I have to > make to send raw frames. I want to work on the higher level API as > opposed to the kernel level (for one I'd like the 802.11 layer to > auto fragment the 802.3 frames for me). The exact protocol will > require two cards in monitor mode so that raw injection and blind > reception can occur. Control signals will be transmitted over a TCP > socket via the internet. I've found documentation that points to > the system independent radiotap specification, and from there I've > seen documentation which talks about initializing the ioctl through > a BPF clone to be utilized by userland applications. I'm sure that > wireshark and other wireless utilities use this, but there is a boat > load of code I've been looking through to find the precise call > which opens up the device ioctl, initiates the the tap, and gives me > simple functions to construct and transmit my simple frames. I've > found in the headers many references to the structs themselves, but > I'm not sure where to start to initiate communication through the > device. Any 802.11 experts on this list that could perhaps give me > some specific instruction or point me to a man page / example code > which does this? > > Thanks in advance for whatever you can offer me. You might want to have a look at tools/tools/net80211/wlaninject, the code there is supposed to inject raw frames into any 802.11 VAP. On a side note, you want to use ahdemo mode for packet injection, not monitor mode. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 07:25: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 20AB3106564A for ; Mon, 21 Feb 2011 07:25:24 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id E29C58FC12 for ; Mon, 21 Feb 2011 07:25:23 +0000 (UTC) Received: (qmail 14647 invoked from network); 21 Feb 2011 06:58:42 -0000 Received: from cpe-75-83-150-233.socal.res.rr.com (HELO embla.bn.dev) (ask@mail.dev@75.83.150.233) by smtp.develooper.com with ESMTPA; 21 Feb 2011 06:58:42 -0000 From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Feb 2011 22:58:41 -0800 Message-Id: <3EB7CB61-E270-41AA-B745-18714BB31FD3@develooper.com> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: IPv6 carp trouble 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, 21 Feb 2011 07:25:24 -0000 Hi everyone, I've been setting up IPv6 on the various networks I look after over the = last weeks. Today the turn came to a system that's running two FreeBSD = boxes with carp etc. I added an inet6 address to the ethernet interface and then the 'carp = address' to carp0. The carp address is used by our upstream provider. = Things appear to work except I can't ping the carp address -- even from = localhost! carp0: flags=3D49 metric 0 mtu 1500 inet 207.171.2.194 netmask 0xfffffff8=20 inet6 2607:f238:0:11::2 prefixlen 125=20 carp: MASTER vhid 110 advbase 1 advskew 100 If I from the box itself ping this ::2 address, 'tcpdump -nn -i lo0' = says: 06:57:47.606443 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time = exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606472 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time = exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606502 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time = exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606531 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time = exceeded in-transit for 2607:f238:0:11::2, length 64 06:57:47.606560 IP6 2607:f238:0:11::2 > 2607:f238:0:11::2: ICMP6, time = exceeded in-transit for 2607:f238:0:11::2, length 64 If I ping the ::2 address from another box, the relevant interface shows = the same response. Any ideas? - ask= From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 07:35:50 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 BA8C3106564A; Mon, 21 Feb 2011 07:35:50 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 25FC48FC14; Mon, 21 Feb 2011 07:35:48 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1L6LRFn012282; Mon, 21 Feb 2011 17:21:27 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p1L6LJmQ010223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 17:21:22 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p1L6LETZ083259; Mon, 21 Feb 2011 17:21:15 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p1L6LDAD083258; Mon, 21 Feb 2011 17:21:13 +1100 (EST) (envelope-from peter) Date: Mon, 21 Feb 2011 17:21:13 +1100 From: Peter Jeremy To: Pawel Tyll Message-ID: <20110221062113.GA83219@server.vk2pj.dyndns.org> References: <410175608.20110220013900@nitronet.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <410175608.20110220013900@nitronet.pl> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-ipfw@freebsd.org, Luigi Rizzo , freebsd-net@freebsd.org Subject: Re: [Panic] Dummynet/IPFW related recurring crash. 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, 21 Feb 2011 07:35:50 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Feb-20 01:39:00 +0100, Pawel Tyll wrote: >Since nobody came up with any interest in having this properly >investigated, then I suppose I'm the only one that uses dummynet for >some larger-scale traffic shaping - maybe that's my mistake? I'm using dummpnet+pf (not ipfw) on (roughly) FreeBSD 7.2 quite extensively for traffic shaping. I have about 20 pipes varying from 600kbps to 100Mbps all with ~9msec delay. There's a background load of at least 10Mbps with peaks to several times that (and several 2Mbps pipes are virtually permanently saturated). The system has nearly 80 VLANs and uses CARP and lagg/LACP (1 bge and 1 em NIC) for redundancy. The system has an uptime of several months. I haven't responded before because I can't offer any solutions. All I can say is that I've been successfully using dummynet with ipfw or pf for about a decade without any stability issues. --=20 Peter Jeremy --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAk1iBFkACgkQ/opHv/APuIe8FgCgwLaCw6x/lVQE+huwihvGlcpb ED8AoLV9lXQhR69nr5EWgqilDfiAjokm =3fE5 -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 10:05: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 03756106564A for ; Mon, 21 Feb 2011 10:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 874138FC17 for ; Mon, 21 Feb 2011 10:05:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8866E41C705; Mon, 21 Feb 2011 11:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id g6yhRSM7YDb3; Mon, 21 Feb 2011 11:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id AE28541C6BB; Mon, 21 Feb 2011 11:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 8C7C14448F3; Mon, 21 Feb 2011 10:03:03 +0000 (UTC) Date: Mon, 21 Feb 2011 10:03:03 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: <3EB7CB61-E270-41AA-B745-18714BB31FD3@develooper.com> Message-ID: <20110221095708.C13400@maildrop.int.zabbadoz.net> References: <3EB7CB61-E270-41AA-B745-18714BB31FD3@develooper.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2014351562-1298282583=:13400" Cc: freebsd-net@freebsd.org Subject: Re: IPv6 carp trouble 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, 21 Feb 2011 10:05:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2014351562-1298282583=:13400 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 20 Feb 2011, Ask Bj=F8rn Hansen wrote: Hey, > I've been setting up IPv6 on the various networks I look after over the l= ast weeks. Today the turn came to a system that's running two FreeBSD boxe= s with carp etc. > > I added an inet6 address to the ethernet interface and then the 'carp add= ress' to carp0. The carp address is used by our upstream provider. Thing= s appear to work except I can't ping the carp address -- even from localhos= t! I got fairly unstable results as well while debugging kern/153848 - as in the problem changed depending on test/fix/... which puzzled me. I am not all quite sure why that was and I am sure I was just staring at the thing not seeing it. I should go back and stare more;-) /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. --0-2014351562-1298282583=:13400-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 10:10:14 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 025351065675 for ; Mon, 21 Feb 2011 10:10:14 +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 CA9B98FC17 for ; Mon, 21 Feb 2011 10:10:13 +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 p1LAADZY009612 for ; Mon, 21 Feb 2011 10:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1LAADnK009611; Mon, 21 Feb 2011 10:10:13 GMT (envelope-from gnats) Date: Mon, 21 Feb 2011 10:10:13 GMT Message-Id: <201102211010.p1LAADnK009611@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 10:10:14 -0000 The following reply was made to PR kern/150247; it has been noted by GNATS. From: Bruce Cran To: bug-followup@freebsd.org, aboyer@averesystems.com Cc: Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems Date: Mon, 21 Feb 2011 10:05:27 +0000 We don't support building drivers from -CURRENT within the environment for an older release. I think the ixgbe driver would need to be backported to 7- STABLE. -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 10:37:50 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 830FB106566C; Mon, 21 Feb 2011 10:37:50 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4F73F8FC16; Mon, 21 Feb 2011 10:37:50 +0000 (UTC) Received: by pwj8 with SMTP id 8so507111pwj.13 for ; Mon, 21 Feb 2011 02:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=62zUwSmHwFh1QcDryXZgZU95kdw1gsYwDFPiOYhjvik=; b=Prv174vDXfzLFT6P7to0daBRsGHT9U6vLPilAKm5vJS5yK8yHOVmYOadPty7I5T4SY 5mo6wmcL4+8b/mcOR6q9ZpcnpXmWycpvZbIMYd0iibW+SBfjEsVF08Mju5vdD4WHQZAH xwNr55NCLe1t/RBmctz5Lyr07eMDSg1x+qGTM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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 :content-transfer-encoding; b=odwjhsGFkVMyqlKhk8MfSP01RhS102zGwFX79GwqNIrIYCYBs73qMp346n9BLO+yio zmGpDkIx+yWCUg/kA30b2634/mIg42CGwJQWa6Bd62kyKlmrA1rtoFe+Bqf8XHtWHxyD EgougG3bsWg0wyi+ucrhr7BX4EQAhH2f2yn2c= MIME-Version: 1.0 Received: by 10.142.217.14 with SMTP id p14mr1072796wfg.56.1298284670025; Mon, 21 Feb 2011 02:37:50 -0800 (PST) Sender: pluknet@gmail.com Received: by 10.142.217.5 with HTTP; Mon, 21 Feb 2011 02:37:50 -0800 (PST) In-Reply-To: <201102161543.p1GFhZmm074991@svn.freebsd.org> References: <201102161543.p1GFhZmm074991@svn.freebsd.org> Date: Mon, 21 Feb 2011 13:37:50 +0300 X-Google-Sender-Auth: hHxy_ONudWLD0moebdfXd1a7qkE Message-ID: From: Sergey Kandaurov To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Luigi Rizzo Subject: Re: svn commit: r218741 - head/sys/netinet/ipfw 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, 21 Feb 2011 10:37:50 -0000 On 16 February 2011 18:43, Sergey Kandaurov wrote: > Author: pluknet > Date: Wed Feb 16 15:43:35 2011 > New Revision: 218741 > URL: http://svn.freebsd.org/changeset/base/218741 > > Log: > =A0Bump dummynet module version to meet dummynet schedulers' requirements= , > =A0and thus unbreak loading dummynet.ko via /boot/loader.conf. Hi there. Just a brief note that I'm going to merge it to stable/8. What scares me is that it may cause some disruption due to the change of module version on a stable branch. On the order side, nothing depends on it in the base. luigi@ cc:'ed as I'd like to know his opinion. > > =A0Reported by: =A0rihad on freebsd-net > =A0Approved by: =A0kib (mentor) > > Modified: > =A0head/sys/netinet/ipfw/ip_dummynet.c > > Modified: head/sys/netinet/ipfw/ip_dummynet.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/sys/netinet/ipfw/ip_dummynet.c Wed Feb 16 15:27:54 2011 =A0 =A0 = =A0 =A0(r218740) > +++ head/sys/netinet/ipfw/ip_dummynet.c Wed Feb 16 15:43:35 2011 =A0 =A0 = =A0 =A0(r218741) > @@ -2294,7 +2294,7 @@ static moduledata_t dummynet_mod =3D { > =A0#define =A0 =A0 =A0 =A0DN_MODEV_ORD =A0 =A0(SI_ORDER_ANY - 128) /* aft= er ipfw */ > =A0DECLARE_MODULE(dummynet, dummynet_mod, DN_SI_SUB, DN_MODEV_ORD); > =A0MODULE_DEPEND(dummynet, ipfw, 2, 2, 2); > -MODULE_VERSION(dummynet, 1); > +MODULE_VERSION(dummynet, 3); > > =A0/* > =A0* Starting up. Done in order after dummynet_modevent() has been called= . > --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 11:07: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 7E5CC106564A for ; Mon, 21 Feb 2011 11:07:04 +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 6B3888FC23 for ; Mon, 21 Feb 2011 11:07:04 +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 p1LB74we075770 for ; Mon, 21 Feb 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1LB73vn075768 for freebsd-net@FreeBSD.org; Mon, 21 Feb 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Feb 2011 11:07:03 GMT Message-Id: <201102211107.p1LB73vn075768@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, 21 Feb 2011 11:07:04 -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 -------------------------------------------------------------------------------- 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/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154676 net [netgraph] [panic] HEAD, 8.1-RELEASE panic after some o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154567 net [ath] ath(4) lot of bad series(0) 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/154284 net [ath] Modern ath wifi cards (such as AR9285) have miss 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/154006 net [tcp] [patch] tcp "window probe" bug on 64bit o kern/153938 net [run] [panic] [patch] Workaround for use-after-free pa 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/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em 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/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h 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/152360 net [dummynet] [panic] Crash related to dummynet. 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/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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets 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 kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x 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/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall 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/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning 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 o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho 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/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using 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/144642 net [rum] [panic] Enabling rum interface causes panic 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/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout 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 conf/143079 net hostapd(8) startup missing multi wlan functionality 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/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault 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/140245 net [ath] [panic] Kernel panic during network activity on 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 o 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 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o 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 kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e 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/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re 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/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver 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 o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze 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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I 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/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless 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/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o 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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation 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 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/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro 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/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card 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/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde 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/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 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/122697 net [ath] Atheros card is not well supported 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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS 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 kern/120130 net [carp] [panic] carp causes kernel panics in any conste 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 s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] 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 kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 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/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! 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] f kern/105348 net [ath] ath device stopps TX 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/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate 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 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r 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/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 o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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/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 o conf/23063 net [arp] [patch] for static ARP tables in rc.network 380 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 13:25:15 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 B97DC106566B; Mon, 21 Feb 2011 13:25:15 +0000 (UTC) (envelope-from samspeed@mail.ru) Received: from fallback3.mail.ru (fallback3.mail.ru [94.100.176.58]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7238FC16; Mon, 21 Feb 2011 13:25:14 +0000 (UTC) Received: from f119.mail.ru (f119.mail.ru [217.69.129.112]) by fallback3.mail.ru (mPOP.Fallback_MX) with ESMTP id 61E495A7721A; Mon, 21 Feb 2011 16:08:30 +0300 (MSK) 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=OgcrlTn/vkFWFLekYw2Jl3iX+dWFbR4YhhzGOVgrVmE=; b=GxN7l1sxZRnHjk+9/Rldz4dfrAums1h97J2659gooKLciKraDPPlXHxZds39kN5VSLs/jCnPdTzlfTDLeyEFlKjebm2cBKVcujrmr7LkwhSBLN/tfYNZDTWdIiOrT9mw; Received: from mail by f119.mail.ru with local id 1PrVUT-0006Fh-00; Mon, 21 Feb 2011 16:07:49 +0300 Received: from [77.45.152.48] by e.mail.ru with HTTP; Mon, 21 Feb 2011 16:07:49 +0300 From: Andrey Smagin To: Pawel Tyll Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [77.45.152.48] Date: Mon, 21 Feb 2011 16:07:49 +0300 References: <20110220231825.GA10566@onelab2.iet.unipi.it> <410175608.20110220013900@nitronet.pl> <1167743969.20110221001312@nitronet.pl> In-Reply-To: <1167743969.20110221001312@nitronet.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok Cc: Brandon Gooch , freebsd-ipfw@freebsd.org, Luigi Rizzo , Jack Vogel , freebsd-net@freebsd.org Subject: Re[2]: problem analysys (Re: [Panic] Dummynet/IPFW related recurring crash.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Smagin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:25:15 -0000 I think problem may be like there http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025156.html what type of IFace for your FWD rules ? I have crash only for ng IF. over gif fwd work without problem. But it only for my case. Mon, 21 Feb 2011 00:13:12 +0100 письмо от Pawel Tyll : > > understood. I am just saying that for instance the vlan presence and > > changes is quite significant in this context. > > You say vlans are "pretty much static" but can you tell us who adds/remove > > them, assign addresses ? > It's not that much work and changes are simple and far between. I do > that personally. IP addresses don't change, however I sometimes > (rarely) destroy and recreate vlans. Panics don't happen immediately > after this operation, or while it happens, and there were times from > panic to panic that I didn't touch a thing. > > > Also the ruleset must have something more than those two rules. > > From the stack trace, the panic seems to occur in a call to the > > "antispoof" option which presumably is somewhere in your ruleset. > > If not, then the stack is corrupt. > Full ruleset with IP addresses removed: > 00010 1691 128516 deny ip from any to any not antispoof in > 00020 87440010 6826835332 fwd [removed] ip from table(60) to table(61) > 00050 3246 156244 allow tcp from any to [removed] dst-port 53 // > DNS Rules 50-59 > 00051 2463493 260607132 allow udp from any to [removed] // DNS Rules > 50-59 > 00059 23891 1091822 deny ip from any to [removed] // DNS Rules > 50-59 > 00100 32 2176 allow ip from any to any via lo0 > 00100 929493 48342523 deny ip from any to table(10) dst-port > 131-139,445 > 00102 56574 2779124 fwd [removed] tcp from table(1) to not table(5) > dst-port 80 > 00103 0 0 fwd [removed] tcp from table(2) to not table(5) > dst-port 80 > 00104 427 17244 fwd [removed] tcp from table(3) to not table(5) > 00105 6 808 deny ip from table(3) to not table(5) > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 0 0 deny ip from any to ::1 > 00500 0 0 deny ip from ::1 to any > 00600 0 0 allow ipv6-icmp from :: to ff02::/16 > 00700 0 0 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 0 0 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 0 0 allow ipv6-icmp from any to any ip6 icmp6types > 1 > 01000 0 0 allow ipv6-icmp from any to any ip6 icmp6types > 2,135,136 > 30000 462392089 204487140826 pipe tablearg ip from table(100) to any in > 30001 535282183 461888428313 pipe tablearg ip from any to table(101) out > 34900 11650783 1216622001 skipto 35001 ip from table(10) to table(10) > 35000 597825867 244960831012 fwd [removed] ip from 192.168.0.0/16 to not > 192.168.0.0/16 > 65534 1595697378 1254723485778 allow ip from any to any > 65535 0 0 allow ip from any to any > > 12:07AM up 1 day, 21 mins, 1 user, load averages: 0.08, 0.06, 0.01 > > Should IP addresses be required, I'll gladly send "uncensored" ruleset > to you privately. > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Feb 21 18:05:46 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 03FE2106564A for ; Mon, 21 Feb 2011 18:05:46 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id C38648FC0C for ; Mon, 21 Feb 2011 18:05:45 +0000 (UTC) Received: (qmail 2468 invoked from network); 21 Feb 2011 18:05:45 -0000 Received: from vpn-gw.solfo.com (HELO ask.vpn.sol) (ask@mail.dev@64.235.248.99) by smtp.develooper.com with ESMTPA; 21 Feb 2011 18:05:45 -0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: <20110221095708.C13400@maildrop.int.zabbadoz.net> Date: Mon, 21 Feb 2011 10:05:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3EB7CB61-E270-41AA-B745-18714BB31FD3@develooper.com> <20110221095708.C13400@maildrop.int.zabbadoz.net> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@freebsd.org Subject: Re: IPv6 carp trouble 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, 21 Feb 2011 18:05:46 -0000 On Feb 21, 2011, at 2:03, Bjoern A. Zeeb wrote: >> I've been setting up IPv6 on the various networks I look after over = the last weeks. Today the turn came to a system that's running two = FreeBSD boxes with carp etc. >>=20 >> I added an inet6 address to the ethernet interface and then the 'carp = address' to carp0. The carp address is used by our upstream provider. = Things appear to work except I can't ping the carp address -- even from = localhost! >=20 > I got fairly unstable results as well while debugging kern/153848 - as > in the problem changed depending on test/fix/... which puzzled me. I > am not all quite sure why that was and I am sure I was just staring at > the thing not seeing it. I should go back and stare more;-) Ah, that's encouraging. I was staring at my rc.conf and pf.conf until = my eyes nearly gave out trying to figure out what I was doing wrong = until I realized that it was similarly broken on lo0. :-) FWIW, I am running 7.4-PRE as of about a week ago. (On Soekris and Alix = boards and not too keen on upgrading to 8 just yet). - ask= From owner-freebsd-net@FreeBSD.ORG Tue Feb 22 03:31:14 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 59897106566B; Tue, 22 Feb 2011 03:31:14 +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 2E3118FC17; Tue, 22 Feb 2011 03:31:14 +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 p1M3VEY3032611; Tue, 22 Feb 2011 03:31:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1M3VEkT032604; Tue, 22 Feb 2011 03:31:14 GMT (envelope-from linimon) Date: Tue, 22 Feb 2011 03:31:14 GMT Message-Id: <201102220331.p1M3VEkT032604@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154943: [gif] ifconfig gifX create on existing gifX clears IP 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, 22 Feb 2011 03:31:14 -0000 Old Synopsis: ifconfig gifX create on existing gifX clears IP New Synopsis: [gif] ifconfig gifX create on existing gifX clears IP Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 22 03:30:43 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=154943 From owner-freebsd-net@FreeBSD.ORG Tue Feb 22 12:20:47 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 583E81065679 for ; Tue, 22 Feb 2011 12:20:47 +0000 (UTC) (envelope-from k@kevinkevin.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 265988FC08 for ; Tue, 22 Feb 2011 12:20:46 +0000 (UTC) Received: by iyj12 with SMTP id 12so1850570iyj.13 for ; Tue, 22 Feb 2011 04:20:46 -0800 (PST) Received: by 10.42.217.132 with SMTP id hm4mr1271245icb.93.1298377246394; Tue, 22 Feb 2011 04:20:46 -0800 (PST) Received: from kkPC (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id d21sm6204308ibg.15.2011.02.22.04.20.41 (version=SSLv3 cipher=OTHER); Tue, 22 Feb 2011 04:20:42 -0800 (PST) From: "kevin" To: "'Tom Judge'" References: <000c01cbcf94$35e76e20$a1b64a60$@com> <4D5FAC16.7080207@gmx.com> <00a201cbd03f$2bdc3540$83949fc0$@com> <4D5FD91F.20704@gmx.com> <4D5FDCF1.6050909@gmx.com> <00a501cbd04f$2276b5b0$67642110$@com> <4D5FFE9C.30005@tomjudge.com> In-Reply-To: <4D5FFE9C.30005@tomjudge.com> Date: Tue, 22 Feb 2011 07:20:36 -0500 Message-ID: <003f01cbd28a$ea03d2b0$be0b7810$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AcvQWvebJ/t04wk6Qr+mKJ8/6bZOlgCLzM0g Cc: freebsd-net@freebsd.org, 'Nikos Vassiliadis' Subject: RE: Bridging + VLANS + RSTP / MSTP 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, 22 Feb 2011 12:20:47 -0000 >There is a also the caveat: The switch will probably _not_ forward the STP BPDU's from one port to another. You were correct -- my initial testing confirmed this. Would the same issue arise if I employed a gateway IP on the /bridge/ instead, and used CARP as a failover mechanism? The firewall no longer becomes transparent pass through/firewall. I have not done carp with bridges and I'm not 100% certain the same STP forwarding problems wouldn't arise, even with an IP assigned. Such as : [switch 1 (vlan 1)] | | [fw1 gw1] -- CARP -- [fw2 gw1] | | [switch 1 (vlan 2)] Thanks, Kevin From owner-freebsd-net@FreeBSD.ORG Tue Feb 22 21:02: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 6F8C0106564A for ; Tue, 22 Feb 2011 21:02:16 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from mailgate.jr-hosting.nl (mailgate.jr-hosting.nl [IPv6:2a01:4f8:63:1281::3]) by mx1.freebsd.org (Postfix) with ESMTP id 087978FC13 for ; Tue, 22 Feb 2011 21:02:16 +0000 (UTC) Received: from [10.0.2.10] (caelis.elvandar.org [83.163.38.147]) by mailgate.jr-hosting.nl (Postfix) with ESMTPSA id EE6E11CC4A; Tue, 22 Feb 2011 22:02:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Remko Lodder In-Reply-To: <003f01cbd28a$ea03d2b0$be0b7810$@com> Date: Tue, 22 Feb 2011 22:02:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000c01cbcf94$35e76e20$a1b64a60$@com> <4D5FAC16.7080207@gmx.com> <00a201cbd03f$2bdc3540$83949fc0$@com> <4D5FD91F.20704@gmx.com> <4D5FDCF1.6050909@gmx.com> <00a501cbd04f$2276b5b0$67642110$@com> <4D5FFE9C.30005@tomjudge.com> <003f01cbd28a$ea03d2b0$be0b7810$@com> To: kevin X-Mailer: Apple Mail (2.1082) Cc: 'Tom Judge' , freebsd-net@freebsd.org, 'Nikos Vassiliadis' Subject: Re: Bridging + VLANS + RSTP / MSTP 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, 22 Feb 2011 21:02:16 -0000 On Feb 22, 2011, at 1:20 PM, kevin wrote: >> There is a also the caveat: The switch will probably _not_ forward = the STP > BPDU's from one port to another.=20 >=20 > You were correct -- my initial testing confirmed this. Would the same = issue > arise if I employed a gateway IP on the /bridge/ instead, and used = CARP as a > failover mechanism? The firewall no longer becomes transparent pass > through/firewall. I have not done carp with bridges and I'm not 100% = certain > the same STP forwarding problems wouldn't arise, even with an IP = assigned. >=20 > Such as : >=20 > [switch 1 (vlan 1)] > | | > [fw1 gw1] -- CARP -- [fw2 gw1] > | | > [switch 1 (vlan 2)] >=20 >=20 > Thanks, >=20 > Kevin >=20 >=20 Carp is a failover mechanism like HSRP and VRRP, I have difficulties to = understand that it works on a bridge. (Only the device in between talks CARP , it = cannot broadcast an IP on the bridge, because thenit would become L3 instead of L2). You could ofcourse use HSRP/VRRP related things and have the gateway = address(es) move when a failure is detected. A lot of companies use those kind of = setups, but personally I havent seen one of them having multiple providers with different IP = space to get to the internet. What is the problem in setting up such a lab to test whether that works = as you would want to? (Why are they bridges in the first place and not active firewalls? It's = not that strange to have an active firewall between the evil internet and the internal network..) --=20 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | X http://www.evilcoder.org/ | Quis custodiet ipsos custodes / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 09:00:35 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 91D42106564A; Wed, 23 Feb 2011 09:00:35 +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 68FEF8FC14; Wed, 23 Feb 2011 09:00:35 +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 p1N90ZKT094018; Wed, 23 Feb 2011 09:00:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1N90ZQr094010; Wed, 23 Feb 2011 09:00:35 GMT (envelope-from linimon) Date: Wed, 23 Feb 2011 09:00:35 GMT Message-Id: <201102230900.p1N90ZQr094010@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154959: [age] "Bad packet length xxxxx, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled) 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, 23 Feb 2011 09:00:35 -0000 Old Synopsis: age: "Bad packet length xxxxx, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled) New Synopsis: [age] "Bad packet length xxxxx, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 23 09:00:19 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=154959 From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 09:16: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 227C9106566B for ; Wed, 23 Feb 2011 09:16:44 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 77CEE8FC13 for ; Wed, 23 Feb 2011 09:16:43 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 2A22F13DF46; Wed, 23 Feb 2011 12:16:41 +0300 (MSK) Date: Wed, 23 Feb 2011 12:16:37 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1975926365.20110223121637@serebryakov.spb.ru> To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------11DA019414A12A07" Cc: =?utf-8?Q?Michael_T=C3=BCxen?= , Jack Vogel Subject: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 23 Feb 2011 09:16:44 -0000 ------------11DA019414A12A07 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello, Freebsd-net. It's me again, as problem is not solved and no "clear" answer was received. em0 NIC on my storage server hangs every several (2-3) days. Symptoms are simple: no packets can be send, mbufs are overfilled, "No buf space to send" error for any program. Configuration now is VERY BASIC: no polling, no sysctls or loader.conf tunables AT ALL. No jumbo frames. nic doesn't show any "Watchdog timeout" / "resetting" messages. Driver from "em driver, 82574L chip, and possibly ASPM" thread doesn't help, really: it seems, that it decrease frequincy of hangs, but doesn't eliminate them, but I can not say for sure, may be frequency change is only illusion, as it random process. I've added diagnostic patch from Michael Tuxen. System is cvsupped and built Mon Feb 21, it is FreeBSD 8-STABLE (RELENG_8). Hardware is: em0@pci0:0:25:0: class=3D0x020000 card=3D0x82681043 chip=3D0x10bd808= 6 rev=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xfeb40000, size 131072, ena= bled bar [14] =3D type Memory, range 32, base 0xfeb7a000, size 4096, enabl= ed bar [18] =3D type I/O Port, range 32, base 0xe880, size 32, enabled cap 01[c8] =3D powerspec 2 supports D0 D3 current D0 cap 05[d0] =3D MSI supports 1 message, 64 bit cap 09[e0] =3D vendor (length 6) Intel cap 2 version 0 Output of ifconfig, vmstat -m, netstat -m, top -Snd 1, sysctl dev.em.0 is attached. Interesting part of diagnostic sysctls: dev.em.0.queue0.rxd_head: 896 dev.em.0.queue0.rxd_tail: 895 dev.em.0.queue0.rx_irq: 0 dev.em.0.queue0.rx_nxt_refresh: 896 dev.em.0.queue0.rx_nxt_check: 896 --=20 // Black Lion AKA Lev Serebryakov ------------11DA019414A12A07 Content-Type: application/octet-stream; name="em0.log" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="em0.log" Pj4+IGlmY29uZmlnIGVtMAplbTA6IGZsYWdzPThjNDM8VVAsQlJPQURDQVNULFJVTk5JTkcs T0FDVElWRSxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKCW9wdGlvbnM9 MjE5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLFZMQU5fSFdDU1VN LFRTTzQsV09MX01BR0lDPgoJZXRoZXIgMDA6MWU6OGM6NzU6MDM6MGQKCWluZXQgMC4wLjAu MCBuZXRtYXNrIDB4ZmYwMDAwMDAgYnJvYWRjYXN0IDI1NS4yNTUuMjU1LjI1NQoJbWVkaWE6 IEV0aGVybmV0IDEwMDBiYXNlVCA8ZnVsbC1kdXBsZXg+CglzdGF0dXM6IGFjdGl2ZQo8PDwg aWZjb25maWcgZW0wCj4+PiB2bXN0YXQgLW0KICAgICAgICAgVHlwZSBJblVzZSBNZW1Vc2Ug SGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgbW9kdWxlICAgMTUyICAgIDE5SyAg ICAgICAtICAgICAgMTUyICAxMjgKICAgICAgICAgIFVTQiAgICA3NiAgICA2NksgICAgICAg LSAgICAgICA4MCAgMTYsMzIsNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgogICAgIG10eF9w b29sICAgICAyICAgIDE2SyAgICAgICAtICAgICAgICAyICAKICAgQ0FNIHBlcmlwaCAgICAy MiAgICAgNksgICAgICAgLSAgICAgICA0NCAgMTYsMzIsNjQsMjU2CiAgICAgcGNpX2xpbmsg ICAgMTYgICAgIDJLICAgICAgIC0gICAgICAgMTYgIDY0LDEyOAogICAgICBhY3Bpc2VtICAg IDE5ICAgICAzSyAgICAgICAtICAgICAgIDE5ICAxMjgKICAgICAgc3VicHJvYyAgIDM3NCAg IDM1NUsgICAgICAgLSAgICA1Mzg0NyAgNTEyLDQwOTYKICAgICAgICAgcHJvYyAgICAgMiAg ICAxNksgICAgICAgLSAgICAgICAgMiAgCiAgICAgIHNlc3Npb24gICAgMjMgICAgIDNLICAg ICAgIC0gICAgICA5MDYgIDEyOAogICAgICAgICBwZ3JwICAgIDI1ICAgICA0SyAgICAgICAt ICAgICAgOTQ4ICAxMjgKICAgICAgICAgY3JlZCAgICA1OCAgICAxMEsgICAgICAgLSAgIDU4 OTQwNiAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAgIDggICAgIDNLICAgICAgIC0gICAgNjU1 NjIgIDEyOCwyMDQ4CiAgICAgICBwbGltaXQgICAgMTAgICAgIDNLICAgICAgIC0gICAgMTE5 OTIgIDI1NgogICAgICBDQU0gWFBUICAgMjgzICAgNDA1SyAgICAgICAtICAgICAgNDA0ICAx NiwzMiw2NCwxMjgsMjU2LDEwMjQsMjA0OAogICAgICAgREVWRlMxICAgMTQyICAgIDcxSyAg ICAgICAtICAgICAgMTUxICA1MTIKICAgIHN5c2N0bHRtcCAgICAgMCAgICAgMEsgICAgICAg LSAgICAgMzM5OCAgMTYsMzIsNjQsMTI4CiAgICBzeXNjdGxvaWQgIDMyNTYgICAxNjFLICAg ICAgIC0gICAgIDMzOTAgIDE2LDMyLDY0LDEyOAogICAgICAgc3lzY3RsICAgICAwICAgICAw SyAgICAgICAtICAgIDQyNjU5ICAxNiwzMiw2NAogICAgICBjYWxsb3V0ICAgICAxICAgNTEy SyAgICAgICAtICAgICAgICAxICAKICAgICAgICAgdW10eCAgIDQwMiAgICA1MUsgICAgICAg LSAgICAgIDQwMiAgMTI4CiAgICAgcDEwMDMuMWIgICAgIDEgICAgIDFLICAgICAgIC0gICAg ICAgIDEgIDE2CiAgICAgICAgIFNXQVAgICAgIDIgICA1NDlLICAgICAgIC0gICAgICAgIDIg IDY0CiAgICAgICBERVZGUzMgICAxNjggICAgNDJLICAgICAgIC0gICAgICAxNzggIDI1Ngog ICAgICAgYnVzLXNjICAgIDYzICAgMzczSyAgICAgICAtICAgICAxMTkyICAxNiwzMiw2NCwx MjgsMjU2LDUxMiwyMDQ4LDQwOTYKICAgICAgICAgIGJ1cyAgIDYwOSAgICA2MksgICAgICAg LSAgICAgMzQ4MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNAogICAgICBkZXZzdGF0ICAg IDE0ICAgIDI5SyAgICAgICAtICAgICAgIDE0ICAzMiw0MDk2CiBldmVudGhhbmRsZXIgICAg NjcgICAgIDZLICAgICAgIC0gICAgICAgNjcgIDY0LDEyOAogICAgICAgICBrb2JqICAgIDkz ICAgMzcySyAgICAgICAtICAgICAgMTE1ICA0MDk2CiAgICAgIFBlci1jcHUgICAgIDEgICAg IDFLICAgICAgIC0gICAgICAgIDEgIDMyCiAgICAgICAgREVWRlMgICAgMjAgICAgIDFLICAg ICAgIC0gICAgICAgMjEgIDE2LDEyOAogICAgICAgICBybWFuICAgMTc3ICAgIDIySyAgICAg ICAtICAgICAgNjAxICAxNiwzMiwxMjgKICAgICAgIERFVkZTUCAgICAgMSAgICAgMUsgICAg ICAgLSAgICAgICAgMSAgNjQKICAgICAgICAgc2J1ZiAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgMTIzOCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgIHBmc19u b2RlcyAgICAyMSAgICAgNksgICAgICAgLSAgICAgICAyMSAgMjU2CiAgICAgICAgc3RhY2sg ICAgIDAgICAgIDBLICAgICAgIC0gICAgICAgIDIgIDI1NgogICAgdGFza3F1ZXVlICAgIDE1 ICAgICAySyAgICAgICAtICAgICAgIDE1ICAxNiwzMiwxMjgKICAgICAgIFVuaXRubyAgICAx MCAgICAgMUsgICAgICAgLSAgICAgICA3MCAgMzIsNjQKICAgICAgICAgIGlvdiAgICAgMCAg ICAgMEsgICAgICAgLSAgICAzMzQyNiAgMTYsMzIsNjQsMTI4LDI1Niw1MTIKICAgICAgIHNl bGVjdCAgICA3NSAgICAxMEsgICAgICAgLSAyODEzNzQzNzQyICAxMjgsNTEyLDEwMjQKICAg ICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSA1MTYzMTExMyAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAgIG1zZyAgICAgNCAgICAzMEsgICAg ICAgLSAgICAgICAgNCAgMjA0OCw0MDk2CiAgICAgICAgICBzZW0gICAgIDQgICAgMTFLICAg ICAgIC0gICAgICAgIDQgIDUxMiwxMDI0CiAgICAgICAgICBzaG0gICAgIDEgICAgMjBLICAg ICAgIC0gICAgICAgIDEgIAogICAgICAgICAgdHR5ICAgIDIwICAgIDIwSyAgICAgICAtICAg ICAgIDI1ICAxMDI0LDIwNDgKICAgICAgICAgIHB0cyAgICAgMCAgICAgMEsgICAgICAgLSAg ICAgICAgMyAgMjU2CiAgICAgbWJ1Zl90YWcgICAgIDAgICAgIDBLICAgICAgIC0gICAgMzY1 MzggIDMyCiAgICAgICAgc2htZmQgICAgIDEgICAgIDhLICAgICAgIC0gICAgICAgIDEgIAog ICAgICAgICBHRU9NICAgMTc1ICAgIDM4SyAgICAgICAtICAgICAgNzQxICAxNiwzMiw2NCwx MjgsMjU2LDUxMiwxMDI0CiAgICAgICAgICBwY2IgICAgMzEgICAgMTNLICAgICAgIC0gIDEz MDEwNzIgIDE2LDMyLDEwMjQsMjA0OCw0MDk2CiAgICAgICBzb25hbWUgICAgIDYgICAgIDFL ICAgICAgIC0gIDQ4NzE3OTYgIDE2LDMyLDEyOAogICAgICAgICAgYWNsICAgICAwICAgICAw SyAgICAgICAtICAgICAyODIzICA0MDk2CiAgICAgICBiaW9idWYgICAgIDAgICAgIDBLICAg ICAgIC0gICAgICA2ODcgIDIwNDgKICAgICB2ZnNjYWNoZSAgICAgMSAgMTAyNEsgICAgICAg LSAgICAgICAgMSAgCiAgIGNsX3NhdmVidWYgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTA0 NjMgIDY0LDEyOAogIGV4cG9ydF9ob3N0ICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAy ICAyNTYKICAgICB2ZnNfaGFzaCAgICAgMSAgIDUxMksgICAgICAgLSAgICAgICAgMSAgCiAg ICAgICB2bm9kZXMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogIHZub2Rl bWFya2VyICAgICAwICAgICAwSyAgICAgICAtICAgIDU1OTU2ICA1MTIKICAgICAgICBtb3Vu dCAgIDEwNCAgICAgNksgICAgICAgLSAgICAgIDMwNCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIK ICAgICAgICAgIEJQRiAgICAgNyAgICAgOUsgICAgICAgLSAgICAgICAgNyAgMTI4LDUxMiw0 MDk2CiAgZXRoZXJfbXVsdGkgICAgMTIgICAgIDFLICAgICAgIC0gICAgICAgMjYgIDE2LDY0 CiAgICAgICBpZmFkZHIgICAgMTQgICAgIDdLICAgICAgIC0gICAgICAgMTYgIDMyLDUxMiw0 MDk2CiAgICAgICAgaWZuZXQgICAgIDMgICAgIDVLICAgICAgIC0gICAgICAgIDMgIDEyOCwy MDQ4CiAgICAgICAgY2xvbmUgICAgIDIgICAgIDhLICAgICAgIC0gICAgICAgIDIgIDQwOTYK ICAgICAgIGFycGNvbSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAg bGx0YWJsZSAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgOSAgMjU2LDUxMgogICAgICBz Y3NpX2RhICAgICAwICAgICAwSyAgICAgICAtICAgICAgIDE2ICAxNgogICAgICAga2JkbXV4 ICAgICA2ICAgIDEwSyAgICAgICAtICAgICAgICA2ICAxNiw1MTIsMTAyNCwyMDQ4LDQwOTYK ICAgICAgICAgIExFRCAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTI4CiAgICAg ICBpc2FkZXYgICAgIDYgICAgIDFLICAgICAgIC0gICAgICAgIDYgIDEyOAogICAgIHJvdXRl dGJsICAgIDEyICAgICA0SyAgICAgICAtICAgIDM2MTg5ICAzMiw2NCwxMjgsMjU2LDUxMgog ICAgICAgICBpZ21wICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICAyNTYKQ0FNIGRl diBxdWV1ZSAgICAgOCAgICAgMUsgICAgICAgLSAgICAgICAgOCAgMTI4CiAgICBDQU0gcXVl dWUgICAgNDMgICAgIDNLICAgICAgIC0gICAgICAxNDggIDE2LDMyLDY0LDI1NgogICAgICBD QU0gU0lNICAgICA4ICAgICAySyAgICAgICAtICAgICAgICA4ICAyNTYKICBpcF9tb3B0aW9u cyAgICAgNCAgICAgMUsgICAgICAgLSAgICAgICAgNCAgNjQsMjU2CiAgICAgaW5fbXVsdGkg ICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDUgIDI1NgogICBpbl9tZmlsdGVyICAgICAy ICAgICAySyAgICAgICAtICAgICAgICAyICAxMDI0CiAgICBob3N0Y2FjaGUgICAgIDEgICAg MjhLICAgICAgIC0gICAgICAgIDEgIAogICAgIHN5bmNhY2hlICAgICAxICAgIDk2SyAgICAg ICAtICAgICAgICAxICAKICAgICAgTkZTIEZIQSAgICAgMSAgICAgMksgICAgICAgLSAgICAg IDE0MyAgNjQsMjA0OAogICAgICAgICAgcnBjICAgMTUyICAgIDgxSyAgICAgICAtICAgICAg NDYyICAzMiw2NCwxMjgsMjU2LDUxMiwyMDQ4CmF1ZGl0X2V2Y2xhc3MgICAxNzIgICAgIDZL ICAgICAgIC0gICAgICAyMTEgIDMyCiAgICAgc2F2ZWRpbm8gICAgIDAgICAgIDBLICAgICAg IC0gICAgMTE2MzcgIDI1NgogICAgbmV3ZGlyYmxrICAgICAwICAgICAwSyAgICAgICAtICAg ICAgMTUzICA2NAogICAgICAgZGlycmVtICAgICAwICAgICAwSyAgICAgICAtICAgIDY1MTg2 ICA2NAogICAgICAgIG1rZGlyICAgICAwICAgICAwSyAgICAgICAtICAgICAxMzY2ICA2NAog ICAgICAgZGlyYWRkICAgICAzICAgICAxSyAgICAgICAtICAgIDU3MTM2ICA2NAogICAgIGZy ZWVmaWxlICAgICAxICAgICAxSyAgICAgICAtICAgIDQ0MzkwICA2NAogICAgIGZyZWVibGtz ICAgICAxICAgICAxSyAgICAgICAtICAgIDQzODI4ICAyNTYKICAgICBmcmVlZnJhZyAgICAg MCAgICAgMEsgICAgICAgLSAgICA0MDE1MyAgNjQKICAgYWxsb2NpbmRpciAgICAgMCAgICAg MEsgICAgICAgLSAgICA1MTY2MiAgMTI4CiAgICAgaW5kaXJkZXAgICAgIDEgICAgIDFLICAg ICAgIC0gICAgICA3MDkgIDY0CiAgYWxsb2NkaXJlY3QgICAgIDMgICAgIDFLICAgICAgIC0g ICAxMDgzMDkgIDI1NgogICAgYm1zYWZlbWFwICAgICAyICAgICAxSyAgICAgICAtICAgIDE5 MjMyICAxMjgKICAgICAgIG5ld2JsayAgICAgMSAgICAgMUsgICAgICAgLSAgIDE1OTk3MiAg NjQsNTEyCiAgICAgaW5vZGVkZXAgICAgIDYgICA1MTRLICAgICAgIC0gICAgNzkxOTQgIDI1 NgogICAgICBwYWdlZGVwICAgICA0ICAgMTI5SyAgICAgICAtICAgICA4MDg1ICAxMjgKICB1 ZnNfZGlyaGFzaCAgMTY1MiAgIDU0NksgICAgICAgLSAgICA5Mjk4OCAgMTYsMzIsNjQsMTI4 LDI1Niw1MTIsMTAyNAogICAgdWZzX21vdW50ICAgIDE1ICAgMTI3SyAgICAgICAtICAgICAg IDE1ICA1MTIsMjA0OCw0MDk2CiAgICAgIFVNQUhhc2ggICAgIDMgICAgIDdLICAgICAgIC0g ICAgICAgIDkgIDUxMiwxMDI0LDIwNDgsNDA5NgogIGRkYl9jYXB0dXJlICAgICAxICAgIDQ4 SyAgICAgICAtICAgICAgICAxICAKICAgICAgIGFjcGljYSAgMzc3MCAgIDM4NksgICAgICAg LSAgICA4MjAzNyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4CiAgICAgICAgIGNk ZXYgICAgIDggICAgIDJLICAgICAgIC0gICAgICAgIDggIDI1NgogICAgdm1fcGdkYXRhICAg ICAyICAgMTI5SyAgICAgICAtICAgICAgICAyICAxMjgKICAgICAgYWNwaWRldiAgICA3OCAg ICAgNUsgICAgICAgLSAgICAgICA3OCAgNjQKICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsg ICAgICAgLSAgICAgICAgMSAgNjQKICAgICBmaWxlZGVzYyAgICA2MCAgICA3N0sgICAgICAg LSAgICA2MTE1NyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAg ICAga2VudiAgICA3NiAgICAxMUsgICAgICAgLSAgICAgICA4MCAgMTYsMzIsNjQsMTI4CiAg ICAgIGlvX2FwaWMgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKICAgICAg IGtxdWV1ZSAgICAgMiAgICAxM0sgICAgICAgLSAgICA1Nzg4MiAgMjU2LDIwNDgsNDA5Ngog ICAgICBtZW1kZXNjICAgICAxICAgICA0SyAgICAgICAtICAgICAgICAxICA0MDk2CiAgICAg YWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAgIC0gICAgICAgIDEgIDIwNDgKICAgIHByb2Mt YXJncyAgICAyNyAgICAgMksgICAgICAgLSAgICA3MTYyMCAgMTYsMzIsNjQsMTI4LDI1Ngog ICAgIGF0a2JkZGV2ICAgICAyICAgICAxSyAgICAgICAtICAgICAgICAyICA2NAogICAgICBp dGhyZWFkICAgIDcyICAgIDEySyAgICAgICAtICAgICAgIDcyICAzMiwxMjgsMjU2CiAgICAg IGVudHJvcHkgIDEwMjQgICAgNjRLICAgICAgIC0gICAgIDEwMjQgIDY0CiAgICAgICAgIFVB UlQgICAgIDMgICAgIDJLICAgICAgIC0gICAgICAgIDMgIDE2LDUxMiwxMDI0CiAgICAgICBL VFJBQ0UgICAxMDAgICAgMTNLICAgICAgIC0gICAgICAxMDAgIDEyOAogICAgICAgbGlua2Vy ICAgIDU3ICAgICA2SyAgICAgICAtICAgICAgIDYzICAxNiwzMiw2NCwxMjgsNTEyCiAgICAg ICAgbG9ja2YgICAgNTMgICAgIDZLICAgICAgIC0gIDExMjM5NDggIDY0LDEyOAogICAgICAg ICB0ZW1wICAgIDIwICAgNDAxSyAgICAgICAtICAgMTM3MDcyICAxNiwzMiw2NCwxMjgsMjU2 LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgZGV2YnVmIDE5OTk5IDM0ODc3SyAgICAgICAt ICAgIDIwMDk3ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAg VVNCZGV2ICAgIDQ3ICAgIDEySyAgICAgICAtICAgICAgIDQ3ICA2NCwxMjgsMTAyNAogICAg IG5leHVzZGV2ICAgICAzICAgICAxSyAgICAgICAtICAgICAgICAzICAxNgogICByYWlkNV9k YXRhICAgIDE5ICA3NTQ1SyAgICAgICAtIDQxMTIwNDU1ICAxNiw2NCw1MTIsNDA5Ngo8PDwg dm1zdGF0IC1tCj4+PiBuZXRzdGF0IC1tCjM0MDQvNjU3MS85OTc1IG1idWZzIGluIHVzZSAo Y3VycmVudC9jYWNoZS90b3RhbCkKMTIxMS8yMjA5LzM0MjAvMjA0ODAwIG1idWYgY2x1c3Rl cnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKMTIwMC80NDkgbWJ1ZitjbHVz dGVycyBvdXQgb2YgcGFja2V0IHNlY29uZGFyeSB6b25lIGluIHVzZSAoY3VycmVudC9jYWNo ZSkKMC8yMTcvMjE3LzE5MjAwMCA0ayAocGFnZSBzaXplKSBqdW1ibyBjbHVzdGVycyBpbiB1 c2UgKGN1cnJlbnQvY2FjaGUvdG90YWwvbWF4KQowLzAvMC82NDAwIDlrIGp1bWJvIGNsdXN0 ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAvMC8wLzMyMDAgMTZrIGp1 bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjMyNzNLLzY5 MjhLLzEwMjAxSyBieXRlcyBhbGxvY2F0ZWQgdG8gbmV0d29yayAoY3VycmVudC9jYWNoZS90 b3RhbCkKMC8wLzAgcmVxdWVzdHMgZm9yIG1idWZzIGRlbmllZCAobWJ1ZnMvY2x1c3RlcnMv bWJ1ZitjbHVzdGVycykKMC8wLzAgcmVxdWVzdHMgZm9yIGp1bWJvIGNsdXN0ZXJzIGRlbmll ZCAoNGsvOWsvMTZrKQowLzAvMCBzZmJ1ZnMgaW4gdXNlIChjdXJyZW50L3BlYWsvbWF4KQow IHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVuaWVkCjAgcmVxdWVzdHMgZm9yIHNmYnVmcyBkZWxh eWVkCjAgcmVxdWVzdHMgZm9yIEkvTyBpbml0aWF0ZWQgYnkgc2VuZGZpbGUKMCBjYWxscyB0 byBwcm90b2NvbCBkcmFpbiByb3V0aW5lcwo8PDwgbmV0c3RhdCAtbQo+Pj4gdG9wIC1TbmQg MQpsYXN0IHBpZDogNTM1MjE7ICBsb2FkIGF2ZXJhZ2VzOiAgMC4wMCwgIDAuMDAsICAwLjAw ICB1cCAxKzIwOjA5OjAyICAgIDExOjUzOjQ3CjExMSBwcm9jZXNzZXM6IDMgcnVubmluZywg OTEgc2xlZXBpbmcsIDE3IHdhaXRpbmcKCk1lbTogODFNIEFjdGl2ZSwgMTQxM00gSW5hY3Qs IDI5Mk0gV2lyZWQsIDU2TSBDYWNoZSwgMjEzTSBCdWYsIDEzM00gRnJlZQpTd2FwOiA0MDk2 TSBUb3RhbCwgMTE2SyBVc2VkLCA0MDk2TSBGcmVlCgoKICBQSUQgVVNFUk5BTUUgICAgICBU SFIgUFJJIE5JQ0UgICBTSVpFICAgIFJFUyBTVEFURSAgIEMgICBUSU1FICAgV0NQVSBDT01N QU5ECiAgIDExIHJvb3QgICAgICAgICAgICAyIDE3MSBraTMxICAgICAwSyAgICAzMksgQ1BV MCAgICAwICA2MS42SCAyMDAuMDAlIGlkbGUKICAgMTIgcm9vdCAgICAgICAgICAgMTcgLTYw ICAgIC0gICAgIDBLICAgMjcySyBXQUlUICAgIDAgIDQ0OjIzICAwLjEwJSBpbnRyCiA1OTEx IHJ0b3JyZW50ICAgICAgICAzICA0NCAgICAwIDg1NzUySyA2MzQ0NEsgc2VsZWN0ICAxICAy NS4ySCAgMC4wMCUgdHJhbnNtaXNzaW9uLWRhZW1vbgogICAgMCByb290ICAgICAgICAgICAg OSAtNjggICAgMCAgICAgMEsgICAxMjhLIC0gICAgICAgMCAgMTI6MjEgIDAuMDAlIGtlcm5l bAogICAxNCByb290ICAgICAgICAgICAzMyAtNDAgICAgLSAgICAgMEsgICA1MjhLIC0gICAg ICAgMSAgIDU6MTEgIDAuMDAlIHVzYgogICAxOSByb290ICAgICAgICAgICAgMiAgLTggICAg LSAgICAgMEsgICAgMzJLIGdyNWRvICAgMSAgIDQ6MzEgIDAuMDAlIGdfcmFpZDUKICAgIDQg cm9vdCAgICAgICAgICAgIDEgIC04ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDAgICAz OjU3ICAwLjAwJSBnX2Rvd24KICAgMTcgcm9vdCAgICAgICAgICAgIDEgIDIwICAgIC0gICAg IDBLICAgIDE2SyBzeW5jZXIgIDEgICAzOjE1ICAwLjAwJSBzeW5jZXIKICAgIDMgcm9vdCAg ICAgICAgICAgIDEgIC04ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDAgICAzOjAxICAw LjAwJSBnX3VwCiAgIDEzIHJvb3QgICAgICAgICAgICAxIC0xNiAgICAtICAgICAwSyAgICAx NksgLSAgICAgICAwICAgMTo1MiAgMC4wMCUgeWFycm93CiAgICA2IHJvb3QgICAgICAgICAg ICAxIC0xNiAgICAtICAgICAwSyAgICAxNksgcHNsZWVwICAxICAgMTowMiAgMC4wMCUgcGFn ZWRhZW1vbgogIDkxMyB1dWNwICAgICAgICAgICAgMSAgNDQgICAgMCAgNjkxNksgIDEzNTZL IHNlbGVjdCAgMSAgIDA6MTIgIDAuMDAlIG1lZ2F0ZWMKICA3ODggcm9vdCAgICAgICAgICAg IDEgIDQ0ICAgIDAgMjEwNTJLICAyODA4SyBzZWxlY3QgIDEgICAwOjA2ICAwLjAwJSBubWJk CiAgOTE1IHV1Y3AgICAgICAgICAgICAxICA0NCAgICAwIDEwOTI4SyAgMjE4OEsgc2VsZWN0 ICAwICAgMDowNSAgMC4wMCUgdXBzZAogIDg2MCByb290ICAgICAgICAgICAgMSAgNDQgICAg MCAxMTc4OEsgIDIwMjhLIHNlbGVjdCAgMSAgIDA6MDUgIDAuMDAlIG50cGQKICAgIDIgcm9v dCAgICAgICAgICAgIDEgIC04ICAgIC0gICAgIDBLICAgIDE2SyAtICAgICAgIDEgICAwOjA1 ICAwLjAwJSBnX2V2ZW50CiAgIDE2IHJvb3QgICAgICAgICAgICAxICA0NCAgICAtICAgICAw SyAgICAxNksgdmxydXd0ICAxICAgMDowNCAgMC4wMCUgdm5scnUKICAgMTggcm9vdCAgICAg ICAgICAgIDEgIDQ0ICAgIC0gICAgIDBLICAgIDE2SyBzZGZsdXMgIDEgICAwOjAyICAwLjAw JSBzb2Z0ZGVwZmx1c2gKCjw8PCB0b3AgLVNuZCAxCj4+PiBzeXNjdGwgZGV2LmVtLjAKZGV2 LmVtLjAuJWRlc2M6IEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA3LjEu OQpkZXYuZW0uMC4lZHJpdmVyOiBlbQpkZXYuZW0uMC4lbG9jYXRpb246IHNsb3Q9MjUgZnVu Y3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5HQkVDCmRldi5lbS4wLiVwbnBpbmZvOiB2ZW5k b3I9MHg4MDg2IGRldmljZT0weDEwYmQgc3VidmVuZG9yPTB4MTA0MyBzdWJkZXZpY2U9MHg4 MjY4IGNsYXNzPTB4MDIwMDAwCmRldi5lbS4wLiVwYXJlbnQ6IHBjaTAKZGV2LmVtLjAubnZt OiAtMQpkZXYuZW0uMC5kZWJ1ZzogLTEKZGV2LmVtLjAucnhfaW50X2RlbGF5OiAwCmRldi5l bS4wLnR4X2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfYWJzX2ludF9kZWxheTogNjYKZGV2 LmVtLjAudHhfYWJzX2ludF9kZWxheTogNjYKZGV2LmVtLjAucnhfcHJvY2Vzc2luZ19saW1p dDogMTAwCmRldi5lbS4wLmZsb3dfY29udHJvbDogMwpkZXYuZW0uMC5saW5rX2lycTogMApk ZXYuZW0uMC5tYnVmX2FsbG9jX2ZhaWw6IDAKZGV2LmVtLjAuY2x1c3Rlcl9hbGxvY19mYWls OiAwCmRldi5lbS4wLmRyb3BwZWQ6IDAKZGV2LmVtLjAudHhfZG1hX2ZhaWw6IDAKZGV2LmVt LjAucnhfb3ZlcnJ1bnM6IDEKZGV2LmVtLjAud2F0Y2hkb2dfdGltZW91dHM6IDAKZGV2LmVt LjAuZGV2aWNlX2NvbnRyb2w6IDE0Nzc0NDQxNjAKZGV2LmVtLjAucnhfY29udHJvbDogNjcx NDE2MzQKZGV2LmVtLjAuZmNfaGlnaF93YXRlcjogODE5MgpkZXYuZW0uMC5mY19sb3dfd2F0 ZXI6IDY2OTIKZGV2LmVtLjAucXVldWUwLnR4ZF9oZWFkOiAxNDQKZGV2LmVtLjAucXVldWUw LnR4ZF90YWlsOiAxMDgKZGV2LmVtLjAucXVldWUwLnR4X2lycTogMApkZXYuZW0uMC5xdWV1 ZTAubm9fZGVzY19hdmFpbDogMApkZXYuZW0uMC5xdWV1ZTAucnhkX2hlYWQ6IDg5NgpkZXYu ZW0uMC5xdWV1ZTAucnhkX3RhaWw6IDg5NQpkZXYuZW0uMC5xdWV1ZTAucnhfaXJxOiAwCmRl di5lbS4wLnF1ZXVlMC5yeF9ueHRfcmVmcmVzaDogODk2CmRldi5lbS4wLnF1ZXVlMC5yeF9u eHRfY2hlY2s6IDg5NgpkZXYuZW0uMC5tYWNfc3RhdHMuZXhjZXNzX2NvbGw6IDAKZGV2LmVt LjAubWFjX3N0YXRzLnNpbmdsZV9jb2xsOiAwCmRldi5lbS4wLm1hY19zdGF0cy5tdWx0aXBs ZV9jb2xsOiAwCmRldi5lbS4wLm1hY19zdGF0cy5sYXRlX2NvbGw6IDAKZGV2LmVtLjAubWFj X3N0YXRzLmNvbGxpc2lvbl9jb3VudDogMApkZXYuZW0uMC5tYWNfc3RhdHMuc3ltYm9sX2Vy cm9yczogMApkZXYuZW0uMC5tYWNfc3RhdHMuc2VxdWVuY2VfZXJyb3JzOiAwCmRldi5lbS4w Lm1hY19zdGF0cy5kZWZlcl9jb3VudDogNjgzCmRldi5lbS4wLm1hY19zdGF0cy5taXNzZWRf cGFja2V0czogMTExNjYKZGV2LmVtLjAubWFjX3N0YXRzLnJlY3Zfbm9fYnVmZjogMApkZXYu ZW0uMC5tYWNfc3RhdHMucmVjdl91bmRlcnNpemU6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJl Y3ZfZnJhZ21lbnRlZDogOQpkZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9vdmVyc2l6ZTogMApk ZXYuZW0uMC5tYWNfc3RhdHMucmVjdl9qYWJiZXI6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJl Y3ZfZXJyczogNjE5CmRldi5lbS4wLm1hY19zdGF0cy5jcmNfZXJyczogNjQ1CmRldi5lbS4w Lm1hY19zdGF0cy5hbGlnbm1lbnRfZXJyczogMApkZXYuZW0uMC5tYWNfc3RhdHMuY29sbF9l eHRfZXJyczogMApkZXYuZW0uMC5tYWNfc3RhdHMueG9uX3JlY3ZkOiA2OTQKZGV2LmVtLjAu bWFjX3N0YXRzLnhvbl90eGQ6IDE3NDUKZGV2LmVtLjAubWFjX3N0YXRzLnhvZmZfcmVjdmQ6 IDE5OTgKZGV2LmVtLjAubWFjX3N0YXRzLnhvZmZfdHhkOiAxNzQ0CmRldi5lbS4wLm1hY19z dGF0cy50b3RhbF9wa3RzX3JlY3ZkOiAxOTEwMzc5NzgKZGV2LmVtLjAubWFjX3N0YXRzLmdv b2RfcGt0c19yZWN2ZDogMTkxMDIzNDYyCmRldi5lbS4wLm1hY19zdGF0cy5iY2FzdF9wa3Rz X3JlY3ZkOiAzMTE4CmRldi5lbS4wLm1hY19zdGF0cy5tY2FzdF9wa3RzX3JlY3ZkOiAwCmRl di5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfNjQ6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJ4 X2ZyYW1lc182NV8xMjc6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnJ4X2ZyYW1lc18xMjhfMjU1 OiAwCmRldi5lbS4wLm1hY19zdGF0cy5yeF9mcmFtZXNfMjU2XzUxMTogMApkZXYuZW0uMC5t YWNfc3RhdHMucnhfZnJhbWVzXzUxMl8xMDIzOiAwCmRldi5lbS4wLm1hY19zdGF0cy5yeF9m cmFtZXNfMTAyNF8xNTIyOiAwCmRldi5lbS4wLm1hY19zdGF0cy5nb29kX29jdGV0c19yZWN2 ZDogMTQ3NzU2OTUxMDUyCmRldi5lbS4wLm1hY19zdGF0cy5nb29kX29jdGV0c190eGQ6IDI1 ODAzNzUxMTI5NwpkZXYuZW0uMC5tYWNfc3RhdHMudG90YWxfcGt0c190eGQ6IDI0Mjc0NjA5 MApkZXYuZW0uMC5tYWNfc3RhdHMuZ29vZF9wa3RzX3R4ZDogMjQyNzQyNjAxCmRldi5lbS4w Lm1hY19zdGF0cy5iY2FzdF9wa3RzX3R4ZDogNjgyCmRldi5lbS4wLm1hY19zdGF0cy5tY2Fz dF9wa3RzX3R4ZDogMzgwNQpkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzY0OiAwCmRl di5lbS4wLm1hY19zdGF0cy50eF9mcmFtZXNfNjVfMTI3OiAwCmRldi5lbS4wLm1hY19zdGF0 cy50eF9mcmFtZXNfMTI4XzI1NTogMApkZXYuZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzI1 Nl81MTE6IDAKZGV2LmVtLjAubWFjX3N0YXRzLnR4X2ZyYW1lc181MTJfMTAyMzogMApkZXYu ZW0uMC5tYWNfc3RhdHMudHhfZnJhbWVzXzEwMjRfMTUyMjogMApkZXYuZW0uMC5tYWNfc3Rh dHMudHNvX3R4ZDogNjE4OTUwMzAKZGV2LmVtLjAubWFjX3N0YXRzLnRzb19jdHhfZmFpbDog MApkZXYuZW0uMC5pbnRlcnJ1cHRzLmFzc2VydHM6IDE0NzA0ODI0NgpkZXYuZW0uMC5pbnRl cnJ1cHRzLnJ4X3BrdF90aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnJ4X2Fic190aW1l cjogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnR4X3BrdF90aW1lcjogMApkZXYuZW0uMC5pbnRl cnJ1cHRzLnR4X2Fic190aW1lcjogMApkZXYuZW0uMC5pbnRlcnJ1cHRzLnR4X3F1ZXVlX2Vt cHR5OiAwCmRldi5lbS4wLmludGVycnVwdHMudHhfcXVldWVfbWluX3RocmVzaDogMApkZXYu ZW0uMC5pbnRlcnJ1cHRzLnJ4X2Rlc2NfbWluX3RocmVzaDogMApkZXYuZW0uMC5pbnRlcnJ1 cHRzLnJ4X292ZXJydW46IDAKZGV2LmVtLjAud2FrZTogMAo8PDwgc3lzY3RsIGRldi5lbS4w Cg== ------------11DA019414A12A07-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 11:16: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 F2DCA1065695; Wed, 23 Feb 2011 11:16:38 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id ABCDC8FC0C; Wed, 23 Feb 2011 11:16:38 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:68ff:b8ee:849:710f] ([IPv6:2607:f3e0:0:4:68ff:b8ee:849:710f]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p1NBGYs1039969 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Feb 2011 06:16:36 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D64EC8C.2080007@sentex.net> Date: Wed, 23 Feb 2011 06:16:28 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Lev Serebryakov References: <1975926365.20110223121637@serebryakov.spb.ru> In-Reply-To: <1975926365.20110223121637@serebryakov.spb.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org, Jack Vogel , freebsd-stable@freebsd.org, =?UTF-8?B?TWljaGE=?=, =?UTF-8?B?ZWwgVMO8eGVu?= Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 23 Feb 2011 11:16:39 -0000 On 2/23/2011 4:16 AM, Lev Serebryakov wrote: > Driver from "em driver, 82574L chip, and possibly ASPM" thread > doesn't help, really: it seems, that it decrease frequincy of hangs, Looking at your sysctl output, you are not using the test drivers posted in that thread. >>> sysctl dev.em.0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%driver: em It should show dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.9-test If you want to try 7.1.9-test, you can download it at http://www.tancsa.com/if_em-8.c for releng_8. However, there is a newer one Jack has, 7.2.2 which seems to work for me as well so far and has additional fixes that the 7.1.9-test cvsup to RELENG_8, then copy if_em-8.c to /usr/src/sys/dev/e1000/if_em.c ---Mike From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 11:36:12 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 F2E5B106566C; Wed, 23 Feb 2011 11:36:12 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF2218FC14; Wed, 23 Feb 2011 11:36:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 5CEF613DF46; Wed, 23 Feb 2011 14:36:11 +0300 (MSK) Date: Wed, 23 Feb 2011 14:36:07 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1004451940.20110223143607@serebryakov.spb.ru> To: Mike Tancsa In-Reply-To: <4D64EC8C.2080007@sentex.net> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , =?utf-8?Q?Michael_T=C3=BCxen?= Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 23 Feb 2011 11:36:13 -0000 Hello, Mike. You wrote 23 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2011 =D0=B3., 14:16= :28: >> Driver from "em driver, 82574L chip, and possibly ASPM" thread >> doesn't help, really: it seems, that it decrease frequincy of hangs, > Looking at your sysctl output, you are not using the test drivers posted > in that thread. Yes, as it doesn't help, I've reverted to "stock" one. > If you want to try 7.1.9-test, you can download it at > http://www.tancsa.com/if_em-8.c for releng_8. I've tried it. It has worked without hangs for 7-8 days, and after that hangs 2 times in 3 days with "7.1.9-test" :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 12:16:35 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 E53F3106566B; Wed, 23 Feb 2011 12:16:35 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4518FC14; Wed, 23 Feb 2011 12:16:35 +0000 (UTC) Received: by qwj8 with SMTP id 8so1669892qwj.13 for ; Wed, 23 Feb 2011 04:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y1ayjbx7clxlr6T+7iGQbmBAn4SrlifIdhSbSPwPnYc=; b=DU7IxdE6nW39D4hyCiWXnz39hHEJN6Tkh9xT3Wl6ZMgqMori0rlRU5+qVQxKAk76Q8 cJqjHmruZM7bN/yJcy9uKnDxysYXjeu5dJrC/ituLGwz9+4E7pxNLLSDNHf82XUYf1D0 brH5HrwkgBomvPynkiB4t1ajz2Nc5L8WtYvPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aaPYmiRK2ztSCCoKxB3Qdc6JWLYlOtuDOOO8KuDkeFx3qldzaUMIL4Wjuq77hbtJGG Oxq1jXgltaJ0Y23j549SSaQWqPZY0MYhraWsUpKqHwVbbJXOsRJtmG1TxoDALvKyqAh9 SF7MlzOmioyKfhL44smFFPi7yLoxOYBzKbExw= MIME-Version: 1.0 Received: by 10.229.247.68 with SMTP id mb4mr2892754qcb.294.1298461532074; Wed, 23 Feb 2011 03:45:32 -0800 (PST) Received: by 10.229.10.13 with HTTP; Wed, 23 Feb 2011 03:45:32 -0800 (PST) In-Reply-To: <1004451940.20110223143607@serebryakov.spb.ru> References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> Date: Wed, 23 Feb 2011 13:45:32 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: Lev Serebryakov Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel , Mike Tancsa Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 23 Feb 2011 12:16:36 -0000 Hi, How can we get 7.2.2. version of if_em driver ? I wanna test it. I can help you for testing changes to em drivers. Regards, Ozkan KIRIK On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov w= rote: > Hello, Mike. > You wrote 23 =C6=C5=D7=D2=C1=CC=D1 2011 =C7., 14:16:28: > >>> =9A Driver from "em driver, 82574L chip, and possibly ASPM" thread >>> =9Adoesn't help, really: it seems, that it decrease frequincy of hangs, >> Looking at your sysctl output, you are not using the test drivers posted >> in that thread. > =9AYes, as it doesn't help, I've reverted to "stock" one. > >> If you want to try 7.1.9-test, you can download it at >> http://www.tancsa.com/if_em-8.c for releng_8. > =9AI've tried it. It has worked without hangs for 7-8 days, and after > that hangs 2 times in 3 days with "7.1.9-test" =9A:( > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 14:00:27 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 38CD4106567A for ; Wed, 23 Feb 2011 14:00:27 +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 0C9FC8FC19 for ; Wed, 23 Feb 2011 14:00:27 +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 p1NE0QJJ016102 for ; Wed, 23 Feb 2011 14:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1NE0QfS016078; Wed, 23 Feb 2011 14:00:26 GMT (envelope-from gnats) Date: Wed, 23 Feb 2011 14:00:26 GMT Message-Id: <201102231400.p1NE0QfS016078@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: elof2@sentor.se Cc: Subject: Re: kern/139268: [if_bridge] [patch] allow if_bridge to forward just VLAN-tagged (or untagged) packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: elof2@sentor.se List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:00:27 -0000 The following reply was made to PR kern/139268; it has been noted by GNATS. From: elof2@sentor.se To: bug-followup@FreeBSD.org, pak@cns.utoronto.ca Cc: Subject: Re: kern/139268: [if_bridge] [patch] allow if_bridge to forward just VLAN-tagged (or untagged) packets Date: Wed, 23 Feb 2011 14:57:46 +0100 (CET) I'm attaching my semi-related feature request to P Kern's request from 2009. Allow if_bridge to "normalise" frames before sending them to bpf, to simplify (and sometimes correctify) traffic sniffing and network debugging. Question: How do I get in touch with a developer that can make this feature find its way into FreeBSD base? What would it cost me and how soon could it be added? Scenario: I create a bridge0 interface using (one or) multiple parent NICs. Then I sniff the traffic on this cloned NIC, 'tcpdump -nli bridge0 port 80'. Benefit: Multiple NICs are bonded together and can easily be sniffed on ONE interface with ONE sniffer process. Drawback: If the sniffer use a bpf filter like "port 80", and the incoming mirrored traffic consist of a mix of untagged and vlan tagged (802.1q) packets, only the untagged packets will match. To see if there are any www-traffic in the mirrored vlans, one need to change the filter to "vlan and port 80", but then you loose the untagged lan. ...a catch 22. :-( The file sys/net/if_bridge.c prior to revision 186365 (http://svn.freebsd.org/viewvc/base?view=revision&revision=186365) used the function call BPF_MTAP to send a copy of a packet to bpf. Since this gave a stripped packet to the sniffer rather than the full and correct frame, this bug was corrected in revision 186365 using ETHER_BPF_MTAP. My request is simply to have the possibility to override the defaults and do it the "buggy" way again, since this proved to be a great feature rather than a bug. :-) Having a function that simply strips off any vlan tag from tagged packets is wonderful when it comes to sniffing. Especially since switches from all brands behave differently when it comes to SPAN and vlan tags (a SYN packet could be mirrorred untagged while the corresponding SYN+ACK is mirrored with a vlan tag set). It is also quite common that net admins configure uplink ports with multiple vlans AND an untagged lan. When you SPAN this uplink you get both tagged and untagged traffic in a mix, making it hard to work with one bpf filter on the full scope of the received traffic. By normalising the mirrored traffic sent to bpf, a network technician can more easily perform his network debugging. Also, there are less risk of human mistakes due to the lack of insight that he need to use the 'vlan' keyword in his tcpdump/tshark/ngrep/whatever to match the traffic. Also state-keeping tools like snort and argus benefit from normalised traffic since they fail to build a correct state table if the SYN and SYN+ACK belong to two different vlans. My request is that if a sysctl variable (like net.link.bridge.bpf.strip_header) is true, then if_bridge will pass stripped packets to bpf. By default it should naturally pass the full frame. PS. There are only four places in if_bridge.c that need to be updated to something like this, so the actual work to do is pretty simple: if (net.link.bridge.bpf.strip_header == 1) BPF_MTAP(bifp, m); else ETHER_BPF_MTAP(bifp, m); /Elof From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 14: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 42765106564A for ; Wed, 23 Feb 2011 14: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 315BE8FC16 for ; Wed, 23 Feb 2011 14: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 p1NEeBgQ058371 for ; Wed, 23 Feb 2011 14: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 p1NEeBUW058369; Wed, 23 Feb 2011 14:40:11 GMT (envelope-from gnats) Date: Wed, 23 Feb 2011 14:40:11 GMT Message-Id: <201102231440.p1NEeBUW058369@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Piotr KUCHARSKI Cc: Subject: Re: misc/154943: ifconfig gifX create on existing gifX clears IP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Piotr KUCHARSKI List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:40:11 -0000 The following reply was made to PR kern/154943; it has been noted by GNATS. From: Piotr KUCHARSKI To: bug-followup@freebsd.org Cc: Subject: Re: misc/154943: ifconfig gifX create on existing gifX clears IP Date: Wed, 23 Feb 2011 15:34:27 +0100 I also found why 'getent hosts create' was resolving: my resolv.conf had no "search" option set, and manual says: search Search list for host-name lookup. The search list is nor‐ mally determined from the local domain name; by default, it contains only the local domain name. My hostname is 42.pl, same as domain name, but I guess some code simply chops off first component and domain name was automatically set to "pl" and getent found "create.pl". How about not chopping off first component in such a case? :) In addition to not resolving ifconfig command names? :) From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 16:31:16 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 206791065673; Wed, 23 Feb 2011 16:31:16 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EB1768FC27; Wed, 23 Feb 2011 16:31:15 +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 p1NGVFHF081823; Wed, 23 Feb 2011 16:31:15 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1NGVFFK081814; Wed, 23 Feb 2011 16:31:15 GMT (envelope-from brucec) Date: Wed, 23 Feb 2011 16:31:15 GMT Message-Id: <201102231631.p1NGVFFK081814@freefall.freebsd.org> To: aboyer@averesystems.com, brucec@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems 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, 23 Feb 2011 16:31:16 -0000 Synopsis: [patch] [ixgbe] Version in -current won't build on 7.x systems State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Wed Feb 23 16:30:32 UTC 2011 State-Changed-Why: Fixed with r217129, r217131 and r217132. http://www.freebsd.org/cgi/query-pr.cgi?pr=150247 From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 16:36:49 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 C3777106566B for ; Wed, 23 Feb 2011 16:36:49 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 95E998FC1F for ; Wed, 23 Feb 2011 16:36:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id C1CEE446002; Wed, 23 Feb 2011 11:17:50 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5UIZblcJuxq; Wed, 23 Feb 2011 11:17:49 -0500 (EST) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id B7759446001; Wed, 23 Feb 2011 11:17:49 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <201102211010.p1LAADnK009611@freefall.freebsd.org> Date: Wed, 23 Feb 2011 11:18:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1ABBD190-D011-4E0D-9CCB-CB521045E3B2@averesystems.com> References: <201102211010.p1LAADnK009611@freefall.freebsd.org> To: Bruce Cran X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@FreeBSD.org Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems 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, 23 Feb 2011 16:36:49 -0000 While I understand that's generally the case, it's how Intel supports = older releases. The code in -current does support building within older = releases (at least 7.X and 8.X), except for the flaws I pointed out. Jack Vogel submitted r217129, r217131, and r217132 to fix this PR, but = didn't mark it closed. -Andrew On Feb 21, 2011, at 5:10 AM, Bruce Cran wrote: > The following reply was made to PR kern/150247; it has been noted by = GNATS. >=20 > From: Bruce Cran > To: bug-followup@freebsd.org, > aboyer@averesystems.com > Cc: =20 > Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't = build on 7.x systems > Date: Mon, 21 Feb 2011 10:05:27 +0000 >=20 > We don't support building drivers from -CURRENT within the environment = for an=20 > older release. I think the ixgbe driver would need to be backported to = 7- > STABLE. >=20 > --=20 > Bruce Cran > _______________________________________________ > 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" -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 17:45:15 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 BA1E8106564A for ; Wed, 23 Feb 2011 17:45:15 +0000 (UTC) (envelope-from rysto32@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 4F2EA8FC18 for ; Wed, 23 Feb 2011 17:45:14 +0000 (UTC) Received: by eyg7 with SMTP id 7so1609186eyg.13 for ; Wed, 23 Feb 2011 09:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sSlnDJofTAX2+lz0LLFKCFdHHCKM1LX1taiCpgyJ1SU=; b=oX/uwLj7GO6dcMTh3V2/tm0ZqPI4v3JwM+/RdziEJ/gBj4H7voWCmHIyC+KLHkF61N 18zz8i5eEG98YiN/rCthHzK3/xMuaoRQMjeNM3MpAofCbFu96tSgA1QIut96p+67rzck be/8jacQZIXWM+G6mF8qgAw8WqXjXunKEQwtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DzX2mSZwkeV7nFetcqhN72q/HtojhWoXpWLFB0tBwLtiJ+Tm+3hAYtIpLvT5FpNpnQ bXEYaZxIha9mYrQSkdVYghBXFN6qxKyLyCmzuXRtrshT2shHf39vxEWIxxmmYYKrr+GJ NMZJP2usru/I0AUB6dZvUQlILO4aLIcz/GCuM= MIME-Version: 1.0 Received: by 10.213.7.67 with SMTP id c3mr295813ebc.68.1298482743768; Wed, 23 Feb 2011 09:39:03 -0800 (PST) Received: by 10.213.20.135 with HTTP; Wed, 23 Feb 2011 09:39:03 -0800 (PST) In-Reply-To: References: Date: Wed, 23 Feb 2011 12:39:03 -0500 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: New device_polling algorithm 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, 23 Feb 2011 17:45:15 -0000 A couple of things that I forgot: - Note that DEVICE_POLLING is not included in GENERIC. You'll have to add the following to your kernel config to get polling support: options DEVICE_POLLING - you can enable polling on a interface with ifconfig(provided the driver supports polling) ifconfig polling - Thanks to attilio@ and emaste@ for reviewing the patch Ryan From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 17:57: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 0C3BE106566C; Wed, 23 Feb 2011 17:57:07 +0000 (UTC) (envelope-from jfvogel@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 99FF68FC13; Wed, 23 Feb 2011 17:57:06 +0000 (UTC) Received: by vws16 with SMTP id 16so3165509vws.13 for ; Wed, 23 Feb 2011 09:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ehLZlHZuPH2nfhH659nKgG0L3QMjDSRcNj6poEIxv8I=; b=jxtrZSrlhIYVFnnMGllArtV0YvApocVptf/TbEuusw0khs9gt6pJQfucP2S1WtwB9w svyx2wuzLPtBmP7DVjcGbc53/D2E5sERlWtps9dcexPJtUg9eglrTliSoK+h8TUftVF8 awJMtVkeVEfmvRlgAs74IDVOgSPItzO+MVdjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X4kCke7j8lNzRWjJ/gAelJA9qR1mdsbgrf7F1d3R9U7odunxtBEhWNKLHk+sfvIcjV b/HWKlnqcJBr0s/oV080QCw/QNr9w1PWmrjOPTusAKiCbm49kO6vXM3U6JDoYigheuSH YrsN1e4lAoCtH47Ka2X0Fd60wcI/X21HqDIDY= MIME-Version: 1.0 Received: by 10.52.169.161 with SMTP id af1mr6647210vdc.225.1298483741981; Wed, 23 Feb 2011 09:55:41 -0800 (PST) Received: by 10.52.166.163 with HTTP; Wed, 23 Feb 2011 09:55:41 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> Date: Wed, 23 Feb 2011 09:55:41 -0800 Message-ID: From: Jack Vogel To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , freebsd-net@freebsd.org, Lev Serebryakov , freebsd-stable@freebsd.org, Mike Tancsa Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 23 Feb 2011 17:57:07 -0000 Anyone in net and stable that wants it, limits blocked it, so send me personal email and I'll send to you. Jack On Wed, Feb 23, 2011 at 9:47 AM, Jack Vogel wrote: > Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put = it > > into your kernel source tree, it will break that. What you must do is > config the > em driver OUT of your kernel, then untar this, build it standalone, and > then > load it. > > This is just a temporary thing, once I have data to decide on this change > vs > the earlier one it will get integrated. > > Jack > > > 2011/2/23 =C3=96zkan KIRIK > > Hi, >> >> How can we get 7.2.2. version of if_em driver ? >> I wanna test it. >> >> I can help you for testing changes to em drivers. >> >> >> Regards, >> Ozkan KIRIK >> >> On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov >> wrote: >> > Hello, Mike. >> > You wrote 23 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2011 =D0=B3., = 14:16:28: >> > >> >>> Driver from "em driver, 82574L chip, and possibly ASPM" thread >> >>> doesn't help, really: it seems, that it decrease frequincy of hangs= , >> >> Looking at your sysctl output, you are not using the test drivers >> posted >> >> in that thread. >> > Yes, as it doesn't help, I've reverted to "stock" one. >> > >> >> If you want to try 7.1.9-test, you can download it at >> >> http://www.tancsa.com/if_em-8.c for releng_8. >> > I've tried it. It has worked without hangs for 7-8 days, and after >> > that hangs 2 times in 3 days with "7.1.9-test" :( >> > >> > -- >> > // Black Lion AKA Lev Serebryakov >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscribe@freebsd.org" >> > >> > > From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 17:59: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 67A601065697 for ; Wed, 23 Feb 2011 17:59:24 +0000 (UTC) (envelope-from rysto32@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 01A318FC27 for ; Wed, 23 Feb 2011 17:59:23 +0000 (UTC) Received: by eyg7 with SMTP id 7so1616368eyg.13 for ; Wed, 23 Feb 2011 09:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=cuHomfhddH+dJpGVDx5e5iA70XohZOyl+G+SWKH/g8I=; b=shd6ycUcXQ961b2oiCT8k3syy1NmNsSmtA+gT1jH2y+Zmc3dlNHtEii4h2HArJrPII dukfv64MFY94PRCZOm2z3IWtNv0IgqLw7QRF/Cr7hfYhaG6iU3KjhrjsO+wFi0B2ZPpN WF/n7uoEi7sryIu34Fp5wPbCwE9hDW62NDGxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mRFnJucdlG7H6pBApjIhlowaf4OHQA+95PLhRmOyTrBFx0Bzz5A7VvlMO8/rtfLfLh +i2Z3rk6+tkfnxCi6PKBzHbxtzuPYxwzKvWKUpHeXEsTNP/104i4lYANCN0DbqkfoIXZ 8aAFK/n+Ulnnagp3ZyI4gBtuA7Gn4oX1gmVcg= MIME-Version: 1.0 Received: by 10.213.26.20 with SMTP id b20mr833974ebc.55.1298482479171; Wed, 23 Feb 2011 09:34:39 -0800 (PST) Received: by 10.213.20.135 with HTTP; Wed, 23 Feb 2011 09:34:39 -0800 (PST) Date: Wed, 23 Feb 2011 12:34:39 -0500 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: New device_polling algorithm 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, 23 Feb 2011 17:59:24 -0000 I've put together a patch against HEAD that replaces the device_polling algorithm(it should apply cleanly to stable/8 as well -- nothing has changed with polling in some time). The patch can be found here: http://people.freebsd.org/~rstone/kern_poll.diff The new algorithm makes use of the feedback that is already provided by pollers(but the current algorithm ignores it). Each poller returns a value indicating how much "work" the polling handler performed in this call(typically this is the number of packets handled). The new algorithm tries to spend (100 - user_frac)% of CPU time handling packets in the netisr thread. This includes time in the pollers as well as time spent on other netisr tasks. It uses the feedback from the pollers in two ways in order to achieve this: - The feedback is used to decide whether it's worthwhile to do another iteration of polling in this tick. If no poller handles more than count/2 packets in the current iteration, the algorithm concludes that there isn't enough outstanding work to continue polling and another iteration won't be scheduled until the next tick. Note that this means that polling iterations can be rescheduled again and again in a tick if there are a lot of packets waiting, which is a new feature. - The feedback is used to estimate how much time it will take to do another iteration of polling. The algorithm dynamically adjusts the count parameter passed to each driver to try and ensure that it only uses as much CPU time as it has been allotted with user_frac. This is necessary to prevent the poller from rescheduling itself too often and starving other threads, especially on single-core machines. If you're on a multicore machine it might be a good idea to decrease the sysctl kern.polling.user_frac. This sysctl restricts how much CPU time the poller is allowed to use on a single CPU. Smaller values mean less time for other tasks and more time for the poller. The poller won't necessarily use (100 - user_frac)% of a CPU. That's the maximum amount of time it's allowed to use, but if the pollers are lightly loaded the poller will use significantly less time. The default is 50, which is reasonable for a uniprocessor system. On a multicore machine you might find this overly restrictive as you could set this all the way down to 0 on a dual-core machine and get the same 50-50 split of CPU time between the poller and everything else. I've put SDT probes in various strategic places. I have a simple dtrace script that logs the data from the probes here: http://people.freebsd.org/~rstone/device_polling.d The script is just a replacement for some KTRs that we had at the same places in our internal branch, so it currently doesn't do anything fancy. I've found the KTRs invaluable for debugging polling problems in the past, though, so I think that it's worth sharing. You might notice that the SDT probes log a "poller index", but it's currently always 0. I would like to extend the poller further to take advantage of multiple netisrs so I've made sure that the probes are ready for this, but I'll talk about my multi-polling ideas later on in another thread. Any comments and testing would be welcome. We mostly only run our code on machines with lem/em/ixgbe devices, so testing against other drivers would be especially welcome. Ryan From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 17:50: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 7D180106566B; Wed, 23 Feb 2011 17:50:48 +0000 (UTC) (envelope-from jfvogel@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 9B8A28FC0C; Wed, 23 Feb 2011 17:50:47 +0000 (UTC) Received: by vws16 with SMTP id 16so3158819vws.13 for ; Wed, 23 Feb 2011 09:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/fRdfgLMgxu5zcXzjA9Zo2+i7wEyc6V3mAnSu62ZbIM=; b=Q4vaQo2E1HpBTxfZCrUJCmEfOgSADewd/0SX7yeOTtMpOxUMtsPYlEvF/J5oe1SAo9 wDZ1cg1c5v82XiFBk/ig1ByBjJFJgNUppi8p3llngM1uAWomvGccL3DRrfQSaEivOot1 AO8dOMudjx6TvjAFzz4Qss2qqDW/rMhLaVIh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xEbK01GAELQTr2A9gUVpoUmBD75mrsPUQB5ZhXwk3d6gdmcIImVCAL+WacXcmHgXWP PjoUGZaGVo/H193YY89bVdYfoU0xsuxKNN9YuB1CFUbjuiaXEs2pLGUX+L3Q8MtVv10t Lj53/gnj0cpF5Fll/aH6OLElDwmliSronYIEE= MIME-Version: 1.0 Received: by 10.52.157.74 with SMTP id wk10mr6691787vdb.25.1298483269638; Wed, 23 Feb 2011 09:47:49 -0800 (PST) Received: by 10.52.166.163 with HTTP; Wed, 23 Feb 2011 09:47:49 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> Date: Wed, 23 Feb 2011 09:47:49 -0800 Message-ID: From: Jack Vogel To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= Content-Type: multipart/mixed; boundary=bcaec53f8f6308b298049cf6b2e8 X-Mailman-Approved-At: Wed, 23 Feb 2011 18:09:25 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , freebsd-net@freebsd.org, Lev Serebryakov , freebsd-stable@freebsd.org, Mike Tancsa Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 23 Feb 2011 17:50:48 -0000 --bcaec53f8f6308b298049cf6b2e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it into your kernel source tree, it will break that. What you must do is confi= g the em driver OUT of your kernel, then untar this, build it standalone, and the= n load it. This is just a temporary thing, once I have data to decide on this change v= s the earlier one it will get integrated. Jack 2011/2/23 =C3=96zkan KIRIK > Hi, > > How can we get 7.2.2. version of if_em driver ? > I wanna test it. > > I can help you for testing changes to em drivers. > > > Regards, > Ozkan KIRIK > > On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov > wrote: > > Hello, Mike. > > You wrote 23 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2011 =D0=B3., 1= 4:16:28: > > > >>> Driver from "em driver, 82574L chip, and possibly ASPM" thread > >>> doesn't help, really: it seems, that it decrease frequincy of hangs, > >> Looking at your sysctl output, you are not using the test drivers post= ed > >> in that thread. > > Yes, as it doesn't help, I've reverted to "stock" one. > > > >> If you want to try 7.1.9-test, you can download it at > >> http://www.tancsa.com/if_em-8.c for releng_8. > > I've tried it. It has worked without hangs for 7-8 days, and after > > that hangs 2 times in 3 days with "7.1.9-test" :( > > > > -- > > // Black Lion AKA Lev Serebryakov > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g > " > > > --bcaec53f8f6308b298049cf6b2e8-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 22:39: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 F0830106566C for ; Wed, 23 Feb 2011 22:39:21 +0000 (UTC) (envelope-from bjmccann@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 B0C298FC0C for ; Wed, 23 Feb 2011 22:39:21 +0000 (UTC) Received: by vxc34 with SMTP id 34so2775552vxc.13 for ; Wed, 23 Feb 2011 14:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=qsKvOl77Sm5HOMgw2MkADfCQ99OiNl17oWmcLSdq2Jo=; b=lXdwFfjpuUhQn38KX8XAVnxEgMrNDTxGGhuDLFzBvgiGvn/4vwcmkUlRVsNiKKt8hI jsQO7TdGgh/EAQUXi9zYaJMEL1dd/IqOJY+xMA72xpk03PWqhsu9LjeIzAcCHHNSZkMe 6M2GS0LevLArIiq+lQ93evMv/PT7bPZk52nTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pwrCJUDcUsH+JIEoYbOiA7K9XeTESzKnFnNEEcYfF7bx2mCX7VSx6qPz0G3u4j+9LZ dLPXiFR8Dj1CQqn+2HJv87VKiVdnR+oy22mUTflwjAn3ImAIivjSQ8vTxBRS1WTDfz45 n3hxVPpc570GU4Y/30sslOSVqAzE1D9oIxg9E= MIME-Version: 1.0 Received: by 10.52.156.233 with SMTP id wh9mr93188vdb.180.1298499284592; Wed, 23 Feb 2011 14:14:44 -0800 (PST) Received: by 10.220.182.76 with HTTP; Wed, 23 Feb 2011 14:14:19 -0800 (PST) Date: Wed, 23 Feb 2011 17:14:19 -0500 Message-ID: From: Brian McCann To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: gif & bridge / ip over ip bridging tunnel 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, 23 Feb 2011 22:39:22 -0000 Hi all. I've been trying to make this work and keep failing. I'm hoping someone smarter then me has some ideas. My end goal is to bridge (not route) a few remote networks to a main site. For example 10.0.0.0/24 ---> FreeBSD box ---> Internet <--- FreeBSD box <---10.0.0.0/24 ^ | FreeBSD (main site) | 10.0.0.0/24 Eventually there's going to be multiple subnets i'd like to "share", for example have 10.0.0.0/24 and 10.1.0.0/24 at all three "sites". Right now I'm trying just between two boxes on my desk. I got a gif tunnel between the two boxes up and running and can ping between the IPs on the gif interfaces, but when I add gif0 to bridge0, pinging doesn't work anymore. tcpdump sees packets flowing on the gre interface (of the ping target), but the packets aren't detected as ICMP so they are getting mangled somehow. I tried gre initially, but discovered I cannot put a gre interface into a bridge. (ps, I'm trying to bridge to a vlan interface) Anyone have any ideas? Thanks! --Brian From owner-freebsd-net@FreeBSD.ORG Wed Feb 23 22:45: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 903AF106566B for ; Wed, 23 Feb 2011 22:45:13 +0000 (UTC) (envelope-from bjmccann@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 474B98FC0A for ; Wed, 23 Feb 2011 22:45:13 +0000 (UTC) Received: by qwj8 with SMTP id 8so2209279qwj.13 for ; Wed, 23 Feb 2011 14:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=qsKvOl77Sm5HOMgw2MkADfCQ99OiNl17oWmcLSdq2Jo=; b=Hc+0aSumqO3hDtEC7JgARNCPGLhII1iuDHSSwRv7agLGwT81kPpf0LYPhVaufkDETc EgO5tf/vA36PHWUpuFMaQUZDm160hQfhsdpfpEifNQRV/AzX4b9YyRHLn4qi0mf+qec8 8KwqGxlVwXf4QTs4diGm2tTiiodblt31CQDS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Vo5Lj4d+307R+Y8HXtI7/UUchkWTt6v5+fEpI2JirCAKuX8E6rofCxA1tII8NWuXCu AdFEHhstggm4aUO+9MfAKxdbCNA6TC84q7OPKoiOZjtC0NmQqNz886j5WSOwK7sV0jgl oy5LPlaJIvYgCAqTO7d4NmcWfVOEKbfBAvb1A= MIME-Version: 1.0 Received: by 10.229.88.67 with SMTP id z3mr960616qcl.138.1298499289140; Wed, 23 Feb 2011 14:14:49 -0800 (PST) Received: by 10.229.34.137 with HTTP; Wed, 23 Feb 2011 14:14:48 -0800 (PST) Date: Wed, 23 Feb 2011 17:14:48 -0500 Message-ID: From: Brian McCann To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: gif & bridge / ip over ip bridging tunnel 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, 23 Feb 2011 22:45:13 -0000 Hi all. I've been trying to make this work and keep failing. I'm hoping someone smarter then me has some ideas. My end goal is to bridge (not route) a few remote networks to a main site. For example 10.0.0.0/24 ---> FreeBSD box ---> Internet <--- FreeBSD box <---10.0.0.0/24 ^ | FreeBSD (main site) | 10.0.0.0/24 Eventually there's going to be multiple subnets i'd like to "share", for example have 10.0.0.0/24 and 10.1.0.0/24 at all three "sites". Right now I'm trying just between two boxes on my desk. I got a gif tunnel between the two boxes up and running and can ping between the IPs on the gif interfaces, but when I add gif0 to bridge0, pinging doesn't work anymore. tcpdump sees packets flowing on the gre interface (of the ping target), but the packets aren't detected as ICMP so they are getting mangled somehow. I tried gre initially, but discovered I cannot put a gre interface into a bridge. (ps, I'm trying to bridge to a vlan interface) Anyone have any ideas? Thanks! --Brian From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 02:36:39 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 9F6BB1065675 for ; Thu, 24 Feb 2011 02:36:39 +0000 (UTC) (envelope-from huangdenghui@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 291138FC12 for ; Thu, 24 Feb 2011 02:36:38 +0000 (UTC) Received: by fxm19 with SMTP id 19so123936fxm.13 for ; Wed, 23 Feb 2011 18:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=XzYzosSySB5LdISI9ItZ3sF9n11DgGgu+H697aGGlc4=; b=sPIbleTGz+0NhVnJvinFVqklKv/WN6sRvmqEn5AMRpTwok7ttYhV9gqwpdPXQdNlg8 EDYaYUH5inWlV8rHCe5tekgY9vusNDGIHE1FcCt5kNhXwZvWHcz5B0PPzrFu2z8i26DH m3L8STzM7LXa5ozokHS3nh1q8dO76X9SC/yvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LVzQdy8pbP5V2FB02MIZNeENRsqpFFSwUt3IFLDVKn+oOFc5N0jCgcUJ5FvRiI8jfn osi9DM1L/AHt2LWt2c9qTN9dwDwayfKYprAZuHc//pMBq6zIHzVh/Ff2ndjB42IhaxQk 2Tp5Y8SGEfpTPDDeY/kJowwrvOoB94ResHo98= MIME-Version: 1.0 Received: by 10.223.111.137 with SMTP id s9mr244953fap.98.1298513396721; Wed, 23 Feb 2011 18:09:56 -0800 (PST) Received: by 10.223.102.135 with HTTP; Wed, 23 Feb 2011 18:09:56 -0800 (PST) Date: Thu, 24 Feb 2011 10:09:56 +0800 Message-ID: From: =?GB2312?B?u8a1x7vU?= To: freebsd-net@freebsd.org X-Mailman-Approved-At: Thu, 24 Feb 2011 04:03:55 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: question about freebsd sctp sctp_asconf_iterator_stcb function. 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, 24 Feb 2011 02:36:39 -0000 Hi I have a little about the following code section of sctp_asconf_iterator_stcb function. if (type == SCTP_ADD_IP_ADDRESS) { /* prevent this address from being used as a source */ sctp_add_local_addr_restricted(stcb, ifa); } else if (type == SCTP_DEL_IP_ADDRESS) { struct sctp_nets *net; TAILQ_FOREACH(net, &stcb->asoc.nets, sctp_next) { sctp_rtentry_t *rt; /* delete this address if cached */ if (net->ro._s_addr == ifa) { sctp_free_ifa(net->ro._s_addr); net->ro._s_addr = NULL; net->src_addr_selected = 0; rt = net->ro.ro_rt; if (rt) { RTFREE(rt); net->ro.ro_rt = NULL; } /* * Now we deleted our src address, * should we not also now reset the * cwnd/rto to start as if its a new * address? */ stcb->asoc.cc_functions.sctp_set_initial_cc_param(stcb, net); net->RTO = 0; } } } else if (type == SCTP_SET_PRIM_ADDR) { if ((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_BOUNDALL) == 0) { /* must validate the ifa is in the ep */ if (sctp_is_addr_in_ep(stcb->sctp_ep, ifa) == 0) { continue; } } else { /* Need to check scopes for this guy */ if (sctp_is_address_in_scope(ifa, stcb->asoc.ipv4_addr_legal, stcb->asoc.ipv6_addr_legal, stcb->asoc.loopback_scope, stcb->asoc.ipv4_local_scope, stcb->asoc.local_scope, stcb->asoc.site_scope, 0) == 0) { continue; } } } /* queue an asconf for this address add/delete */ if (sctp_is_feature_on(inp, SCTP_PCB_FLAGS_DO_ASCONF) && stcb->asoc.peer_supports_asconf) { /* queue an asconf for this addr */ status = sctp_asconf_queue_add(stcb, ifa, type); /* * if queued ok, and in the open state, update the * count of queued params. If in the non-open * state, these get sent when the assoc goes open. */ if (SCTP_GET_STATE(&stcb->asoc) == SCTP_STATE_OPEN) { if (status >= 0) { num_queued++; } } } should change like this: if (sctp_is_feature_on(inp, SCTP_PCB_FLAGS_DO_ASCONF) && stcb->asoc.peer_supports_asconf) { if (type == SCTP_ADD_IP_ADDRESS) { /* prevent this address from being used as a source */ sctp_add_local_addr_restricted(stcb, ifa); } else if (type == SCTP_DEL_IP_ADDRESS) { struct sctp_nets *net; TAILQ_FOREACH(net, &stcb->asoc.nets, sctp_next) { sctp_rtentry_t *rt; /* delete this address if cached */ if (net->ro._s_addr == ifa) { sctp_free_ifa(net->ro._s_addr); net->ro._s_addr = NULL; net->src_addr_selected = 0; rt = net->ro.ro_rt; if (rt) { RTFREE(rt); net->ro.ro_rt = NULL; } /* * Now we deleted our src address, * should we not also now reset the * cwnd/rto to start as if its a new * address? */ stcb->asoc.cc_functions.sctp_set_initial_cc_param(stcb, net); net->RTO = 0; } } } else if (type == SCTP_SET_PRIM_ADDR) { if ((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_BOUNDALL) == 0) { /* must validate the ifa is in the ep */ if (sctp_is_addr_in_ep(stcb->sctp_ep, ifa) == 0) { continue; } } else { /* Need to check scopes for this guy */ if (sctp_is_address_in_scope(ifa, stcb->asoc.ipv4_addr_legal, stcb->asoc.ipv6_addr_legal, stcb->asoc.loopback_scope, stcb->asoc.ipv4_local_scope, stcb->asoc.local_scope, stcb->asoc.site_scope, 0) == 0) { continue; } } } /* queue an asconf for this address add/delete */ /* queue an asconf for this addr */ status = sctp_asconf_queue_add(stcb, ifa, type); /* * if queued ok, and in the open state, update the * count of queued params. If in the non-open * state, these get sent when the assoc goes open. */ if (SCTP_GET_STATE(&stcb->asoc) == SCTP_STATE_OPEN) { if (status >= 0) { num_queued++; } } } because i think put some address into restricted address list is used to dynamic address configuration. So first we need to make sure this feature SCTP_PCB_FLAGS_DO_ASCONF is on and peer endpoint also support this feature. If i am wrong, experts please give some comments. From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 05:56: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 70A96106564A for ; Thu, 24 Feb 2011 05:56:08 +0000 (UTC) (envelope-from peter.lei@ieee.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 4A51C8FC23 for ; Thu, 24 Feb 2011 05:56:08 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta07.emeryville.ca.mail.comcast.net with comcast id Bhii1g00216AWCUA7hiwof; Thu, 24 Feb 2011 05:42:56 +0000 Received: from mbpro5.local ([98.228.214.213]) by omta06.emeryville.ca.mail.comcast.net with comcast id Bhij1g00J4cpPwJ8ShivPl; Thu, 24 Feb 2011 05:42:56 +0000 Message-ID: <4D65EFD2.3020400@ieee.org> Date: Wed, 23 Feb 2011 23:42:42 -0600 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: =?UTF-8?B?6buE55m76L6J?= References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: question about freebsd sctp sctp_asconf_iterator_stcb function. 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, 24 Feb 2011 05:56:08 -0000 Hi, No, the original code looks correct. The address management code needs to run regardless of whether SCTP_PCB_FLAGS_DO_ASCONF is enabled (or whether the peer supports ASCONF or not). The newly added address is put onto the restricted list to prevent the stack from using the new address as a source address for any existing associations. Similarly, any addresses that have been locally removed should no longer be used. The endpoint's SCTP_PCB_FLAGS_DO_ASCONF flag and the association's peer_supports_asconf flag are then checked to determine whether to send an ASCONF(ADD/DELETE) chunk to the peers. If an ASCONF is sent for an address addition, upon getting an ASCONF-ACK indicating success, the address will be moved off the restricted list and onto the local address list as a usable as a source address. If ASCONF is disabled or the peer doesn't support ASCONF, or the peer rejects the addition, then that address would stay on the restricted list, and not be used by the local stack as a possible source address. Hope that clarifies... --peter On 2/23/11 8:09 PM, 黄登辉 wrote: > Hi > > I have a little about the following code section of > sctp_asconf_iterator_stcb function. > > if (type == SCTP_ADD_IP_ADDRESS) { > /* prevent this address from being used as a source */ > sctp_add_local_addr_restricted(stcb, ifa); > } else if (type == SCTP_DEL_IP_ADDRESS) { > struct sctp_nets *net; > > TAILQ_FOREACH(net, &stcb->asoc.nets, sctp_next) { > sctp_rtentry_t *rt; > > /* delete this address if cached */ > if (net->ro._s_addr == ifa) { > sctp_free_ifa(net->ro._s_addr); > net->ro._s_addr = NULL; > net->src_addr_selected = 0; > rt = net->ro.ro_rt; > if (rt) { > RTFREE(rt); > net->ro.ro_rt = NULL; > } > /* > * Now we deleted our src address, > * should we not also now reset the > * cwnd/rto to start as if its a new > * address? > */ > stcb->asoc.cc_functions.sctp_set_initial_cc_param(stcb, > net); > net->RTO = 0; > > } > } > } else if (type == SCTP_SET_PRIM_ADDR) { > if ((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_BOUNDALL) == 0) > { > /* must validate the ifa is in the ep */ > if (sctp_is_addr_in_ep(stcb->sctp_ep, ifa) == 0) { > continue; > } > } else { > /* Need to check scopes for this guy */ > if (sctp_is_address_in_scope(ifa, > stcb->asoc.ipv4_addr_legal, > stcb->asoc.ipv6_addr_legal, > stcb->asoc.loopback_scope, > stcb->asoc.ipv4_local_scope, > stcb->asoc.local_scope, > stcb->asoc.site_scope, 0) == 0) { > continue; > } > } > } > /* queue an asconf for this address add/delete */ > if (sctp_is_feature_on(inp, SCTP_PCB_FLAGS_DO_ASCONF) && > stcb->asoc.peer_supports_asconf) { > /* queue an asconf for this addr */ > status = sctp_asconf_queue_add(stcb, ifa, type); > /* > * if queued ok, and in the open state, update the > * count of queued params. If in the non-open > * state, these get sent when the assoc goes open. > */ > if (SCTP_GET_STATE(&stcb->asoc) == SCTP_STATE_OPEN) { > if (status >= 0) { > num_queued++; > } > } > } > > > should change like this: > > if (sctp_is_feature_on(inp, SCTP_PCB_FLAGS_DO_ASCONF) && > stcb->asoc.peer_supports_asconf) { > if (type == SCTP_ADD_IP_ADDRESS) { > /* prevent this address from being used as a source */ > sctp_add_local_addr_restricted(stcb, ifa); > } else if (type == SCTP_DEL_IP_ADDRESS) { > struct sctp_nets *net; > > TAILQ_FOREACH(net, &stcb->asoc.nets, sctp_next) { > sctp_rtentry_t *rt; > > /* delete this address if cached */ > if (net->ro._s_addr == ifa) { > sctp_free_ifa(net->ro._s_addr); > net->ro._s_addr = NULL; > net->src_addr_selected = 0; > rt = net->ro.ro_rt; > if (rt) { > RTFREE(rt); > net->ro.ro_rt = NULL; > } > /* > * Now we deleted our src address, > * should we not also now reset the > * cwnd/rto to start as if its a new > * address? > */ > > stcb->asoc.cc_functions.sctp_set_initial_cc_param(stcb, net); > net->RTO = 0; > > } > } > } else if (type == SCTP_SET_PRIM_ADDR) { > if ((stcb->sctp_ep->sctp_flags & SCTP_PCB_FLAGS_BOUNDALL) == > 0) { > /* must validate the ifa is in the ep */ > if (sctp_is_addr_in_ep(stcb->sctp_ep, ifa) == 0) { > continue; > } > } else { > /* Need to check scopes for this guy */ > if (sctp_is_address_in_scope(ifa, > stcb->asoc.ipv4_addr_legal, > stcb->asoc.ipv6_addr_legal, > stcb->asoc.loopback_scope, > stcb->asoc.ipv4_local_scope, > stcb->asoc.local_scope, > stcb->asoc.site_scope, 0) == 0) { > continue; > } > } > } > /* queue an asconf for this address add/delete */ > > /* queue an asconf for this addr */ > status = sctp_asconf_queue_add(stcb, ifa, type); > /* > * if queued ok, and in the open state, update the > * count of queued params. If in the non-open > * state, these get sent when the assoc goes open. > */ > if (SCTP_GET_STATE(&stcb->asoc) == SCTP_STATE_OPEN) { > if (status >= 0) { > num_queued++; > } > } > } > > > because i think put some address into restricted address list is used to > dynamic address configuration. > So first we need to make sure this feature SCTP_PCB_FLAGS_DO_ASCONF is on > and peer endpoint also support this feature. > If i am wrong, experts please give some comments. > _______________________________________________ > 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 Feb 24 08:03: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 2AED4106566C; Thu, 24 Feb 2011 08:03:06 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id C31218FC19; Thu, 24 Feb 2011 08:03:05 +0000 (UTC) Received: by qwj8 with SMTP id 8so234850qwj.13 for ; Thu, 24 Feb 2011 00:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0ckXjqQozZnWwHDF6gK+iVUgvONObKLH1wLPY73O29g=; b=pQRKzMbQS4FTG/dfOr97SeWYLpMiS8VW+RDFOaRkspCJ+i/eBmP6xB4on8UjsrP31t um2t/kgQDu8TEUqtwy3xQ2ObUox3hjUsn/4WIK9PWEutVVl5TE1DiOA92alOPg+bM6LG D+QYJXmHcbjcITV1Pq4NbuM/V9WevrsmH913s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=I9y9ZhKi8RSsltx/KhZ44YZzrFXzyUoU/ONgsyuNGBt31JiYEWLXI2w115uNzlSc4y RIOg2Ia/qFqL9xcNT8LCE2wx10YNDio73To5Hk1KGhn8SvZF6r4mehdXagQCdBwafjsG fFjcqgogjxW5TpLQWJjfl4EqGGcdKrK99h8GI= MIME-Version: 1.0 Received: by 10.229.70.130 with SMTP id d2mr343508qcj.218.1298534583771; Thu, 24 Feb 2011 00:03:03 -0800 (PST) Received: by 10.229.10.13 with HTTP; Thu, 24 Feb 2011 00:03:03 -0800 (PST) In-Reply-To: References: <1975926365.20110223121637@serebryakov.spb.ru> <4D64EC8C.2080007@sentex.net> <1004451940.20110223143607@serebryakov.spb.ru> Date: Thu, 24 Feb 2011 10:03:03 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Michael_T=FCxen?= , freebsd-net@freebsd.org, Lev Serebryakov , freebsd-stable@freebsd.org, Mike Tancsa Subject: Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!) 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, 24 Feb 2011 08:03:06 -0000 Thank you. I'll test and share my experiences with you. On Wed, Feb 23, 2011 at 7:47 PM, Jack Vogel wrote: > Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put = it > into your kernel source tree, it will break that. What you must do is con= fig > the > em driver OUT of your kernel, then untar this, build it standalone, and t= hen > load it. > > This is just a temporary thing, once I have data to decide on this change= vs > the earlier one it will get integrated. > > Jack > > > 2011/2/23 =C3=96zkan KIRIK >> >> Hi, >> >> How can we get 7.2.2. version of if_em driver ? >> I wanna test it. >> >> I can help you for testing changes to em drivers. >> >> >> Regards, >> Ozkan KIRIK >> >> On Wed, Feb 23, 2011 at 1:36 PM, Lev Serebryakov >> wrote: >> > Hello, Mike. >> > You wrote 23 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2011 =D0=B3., = 14:16:28: >> > >> >>> =C2=A0 Driver from "em driver, 82574L chip, and possibly ASPM" threa= d >> >>> =C2=A0doesn't help, really: it seems, that it decrease frequincy of = hangs, >> >> Looking at your sysctl output, you are not using the test drivers >> >> posted >> >> in that thread. >> > =C2=A0Yes, as it doesn't help, I've reverted to "stock" one. >> > >> >> If you want to try 7.1.9-test, you can download it at >> >> http://www.tancsa.com/if_em-8.c for releng_8. >> > =C2=A0I've tried it. It has worked without hangs for 7-8 days, and aft= er >> > that hangs 2 times in 3 days with "7.1.9-test" =C2=A0:( >> > >> > -- >> > // Black Lion AKA Lev Serebryakov >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to >> > "freebsd-stable-unsubscribe@freebsd.org" >> > > > From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 10:00: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 376E4106566B for ; Thu, 24 Feb 2011 10:00:09 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 096138FC15 for ; Thu, 24 Feb 2011 10:00:08 +0000 (UTC) Received: from [10.17.45.101] (adsl-76-192-129-143.dsl.pltn13.sbcglobal.net [76.192.129.143]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id p1O9egOE083536 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 24 Feb 2011 01:40:42 -0800 (PST) (envelope-from crapsh@monkeybrains.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=monkeybrains.net; s=monkey; t=1298540443; bh=0B2xYv5VZaNaHOfnzy/WVMeLPfFOotNk5IUxB5RjwUw=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=ZPtn7ZHWVp7fuIDwNzw6Q6ptt4DbVuXdjsDXZPLntgH5QsCIq683rSwwXT8txgrSq t6tCboA2/Jw34k8GgInTbWuF2LQFlHMuonNg7s6dfB6c/wopQSgVJSJReV4LAwkUGJ uPUDJRPb8CnkZKuL4EUDhhwPhcRBAkNvon6Hk6qw= Message-ID: <4D66279F.1000205@monkeybrains.net> Date: Thu, 24 Feb 2011 01:40:47 -0800 From: Rudy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11pre) Gecko/20100928 Shredder/3.1.5pre MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at lavash.monkeybrains.net X-Virus-Status: Clean Subject: bridges with vlan member -- unicast? 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, 24 Feb 2011 10:00:09 -0000 Is anyone bridging a bunch (20+) vlans onto one bridge0? My goal is to do what the HandBook says I can do: The customers are completely isolated from each other, the full /24 address range can be allocated without subnetting. http://www.freebsd.org/doc/handbook/network-bridging.html#AEN40688 Last time I tried this (8.1) I got a bunch of unicast flooding and it busted my network. I'd like to see a 'nounicast' flag for bridge members... Say, I've never looked into it, but do unicast floods go to a broadcast mac address (eg FF:FF:FF:FF:FF:FF) that I could block via layer2? more on Unicast Flooding: http://packetlife.net/blog/2010/jun/4/blocking-unknown-unicast-flooding/ Rudy From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 10:28:42 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 723871065672 for ; Thu, 24 Feb 2011 10:28:42 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9908FC18 for ; Thu, 24 Feb 2011 10:28:41 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 49C3F740021 for ; Thu, 24 Feb 2011 11:11:36 +0100 (CET) From: Fabien Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Feb 2011 11:12:58 +0100 Message-Id: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> To: FreeBSD Net Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: Polling with multiqueue support 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, 24 Feb 2011 10:28:42 -0000 Ryan post on new polling modification remembered me to post a quick note = about polling with multiqueue support i've done some month ago. The code is more intrusive and add a new handler for the queue.=20 The handling of the network is nearly the same as deferred taskqueue in = the drivers. There is now two pass one for the receive and one for transmit (to flush = pending transmit when all receive pass done). The main gain is for packet forwarding with more than one interface. The CPU can be easily reserved for application by binding a specific = number of core to the network. Performance is on par with interrupt on 10Gb or 1Gb interface and = latency can be reduced by using higher HZ. Most of the time using less core achieve higher global efficiency of the = system by freeing CPU cycle and reducing contention. Ex setup: 6 cores CPU, 2 ixgbe with 3 queue, 4 igb with 3 queue with 3 cores for polling: CPU0 will handle ixgbe0 queue 0, ixgbe1 queue 0, igb0 queue0, ... CPU1 will handle ixgbe0 queue 1, ... ... For those interested a test branch can be found here based on 8.x with = ixgbe / igb and em modification: = http://www.gitorious.org/~fabient/freebsd/fabient-sandbox/commits/work/pol= lng_mq_stable_8 Extracted patchset here: http://people.freebsd.org/~fabient/patch-poll_mq-20110202-stable_8 http://people.freebsd.org/~fabient/kern_poll.c-20110202 -> put to = kern/kern_poll.c -- Fabien Thomas From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 15:39: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 2E17C106564A for ; Thu, 24 Feb 2011 15:39:06 +0000 (UTC) (envelope-from rysto32@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 B68238FC13 for ; Thu, 24 Feb 2011 15:39:05 +0000 (UTC) Received: by eyg7 with SMTP id 7so240826eyg.13 for ; Thu, 24 Feb 2011 07:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+eNUMIQAK+3pOpeshEkwIT4VWpOYmTpXdUC1ab/U4GU=; b=MM8q92+z2ocf5eBUC4fIOPAD+OWSPTzttyu9l1nLVYoaX9OsI+Q48NcsF5yHFnAiwE ka3jk06Dmin10AELcjllb7HHisQIB2MNxOayigJ4V/zcAmkF1jOvzmT2KkWZCJc06de0 oIC6EjYGQ1+otjssInLZlLKNERJ+CRC4teMyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DLZBRmD0xgVqdiBVeD5v1xKS0hwoUB0qWTLPqWEfdroqIA5b30xPdGcSvZjVeRL9T6 049QmO1+gIpzhIDRljNXIyAiZsB5smN1b31PAaHfctjoFtVCp00zUQ60ySJyP5SBgOP6 6/x8AZpJlA4QzXyO3goBV4PXDJZ67f95GxVlU= MIME-Version: 1.0 Received: by 10.213.23.5 with SMTP id p5mr1384728ebb.81.1298561944531; Thu, 24 Feb 2011 07:39:04 -0800 (PST) Received: by 10.213.20.135 with HTTP; Thu, 24 Feb 2011 07:39:04 -0800 (PST) In-Reply-To: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> References: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> Date: Thu, 24 Feb 2011 10:39:04 -0500 Message-ID: From: Ryan Stone To: Fabien Thomas Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Re: Polling with multiqueue support 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, 24 Feb 2011 15:39:06 -0000 Ah, you've anticipated me. This is just the kind of thing that I had in mind. I have some comments: - Why allocate the poll_if_t in ether_poll_register_? If you let the driver allocate it you don't have to worry about failure. And the driver can embed it in its rx_ring so it doesn't have to worry about malloc'ing it anyway. We can also put one it struct ifnet to preserve the traditional ether_poll_register interface. - I'd personally prefer it if ether_poll_register_mq didn't require a struct ifnet to be passed in. Nothing seems to use the ifnet anymore and here at $(WORK) we have some non-ifnets that actually register a polling handler. Currently they just allocate a struct ifnet to make the polling code happy but I don't see any reason to require one. - Also, I don't quite understand why the separate TX step is necessary now. From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 16:27:39 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 46A4F106564A for ; Thu, 24 Feb 2011 16:27:39 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA068FC0A for ; Thu, 24 Feb 2011 16:27:38 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id AA444740004; Thu, 24 Feb 2011 17:26:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: Date: Thu, 24 Feb 2011 17:27:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18E4F606-C361-4F10-8E58-915F28D71E42@netasq.com> References: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> To: Ryan Stone X-Mailer: Apple Mail (2.1082) Cc: FreeBSD Net Subject: Re: Polling with multiqueue support 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, 24 Feb 2011 16:27:39 -0000 On Feb 24, 2011, at 4:39 PM, Ryan Stone wrote: > Ah, you've anticipated me. This is just the kind of thing that I had > in mind. I have some comments: Thanks for your feedback. You pushed me from my laziness to explain the patchset on the ml. :) >=20 > - Why allocate the poll_if_t in ether_poll_register_? If you let the > driver allocate it you don't have to worry about failure. And the > driver can embed it in its rx_ring so it doesn't have to worry about > malloc'ing it anyway. We can also put one it struct ifnet to preserve > the traditional ether_poll_register interface. Good point. I take it to my TODO list >=20 > - I'd personally prefer it if ether_poll_register_mq didn't require a > struct ifnet to be passed in. Nothing seems to use the ifnet anymore > and here at $(WORK) we have some non-ifnets that actually register a > polling handler. Currently they just allocate a struct ifnet to make > the polling code happy but I don't see any reason to require one. To be sure to understand using context + queue id only as identifier for = the mq part=20 and grab the ifp from the context in the driver ? That seems ok to me if it block case where you dont have ifp. >=20 > - Also, I don't quite understand why the separate TX step is necessary = now. It helps because TX is done only when every interface (on this = taskqueue,=20 cross taskqueue will require sync point) have processed packets to = completion. It can also help for the fairness between interface on the same = taskqueue to rotate faster to the next if. This is not required and can be used or not driver per driver (if not = used everything can be done on RX). There is also one fix pending for the compatibility interface: the = packet per round need to be increased because there is no feedback loop = on the old API. Fabien From owner-freebsd-net@FreeBSD.ORG Thu Feb 24 17:25:20 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 C46AB106564A for ; Thu, 24 Feb 2011 17:25:19 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 874E38FC13 for ; Thu, 24 Feb 2011 17:25:19 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 832D7740004 for ; Thu, 24 Feb 2011 18:23:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Fabien Thomas In-Reply-To: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> Date: Thu, 24 Feb 2011 18:25:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6201CFE3-2611-48F1-A650-43AB7461F2D2@netasq.com> References: <0B0B1ACC-C57B-4F74-85D5-DD2C7F2DAEA5@netasq.com> To: FreeBSD Net X-Mailer: Apple Mail (2.1082) Subject: Re: Polling with multiqueue support 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, 24 Feb 2011 17:25:21 -0000 Just an update to point to another old patch that enable flowtable on = the forwarding path to increase performance (reduce contention) to be on = par with Linux: http://people.freebsd.org/~fabient/FreeBSDvsLinux10GB.png (forwarding = 256B packets, % to line rate on 2x10Gb 82599 interface with 1xXeon = W3680) http://people.freebsd.org/~fabient/patch-flowtable-forward Coupled with the polling code it perform quite well. Last things a latency / polling overhead test result: http://people.freebsd.org/~fabient/polllatency.png User app is the time it take to run a CPU related benchmark (lower is = better), net load is fixed as high but let some CPU available. Freq is the HZ for polling or the measured intr frequency for that load. = Latency is measured by Spirent STC. Fabien From owner-freebsd-net@FreeBSD.ORG Fri Feb 25 02:17:44 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 0945E106566C; Fri, 25 Feb 2011 02:17:44 +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 D413D8FC08; Fri, 25 Feb 2011 02:17:43 +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 p1P2HheO089090; Fri, 25 Feb 2011 02:17:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1P2Hhq6089086; Fri, 25 Feb 2011 02:17:43 GMT (envelope-from linimon) Date: Fri, 25 Feb 2011 02:17:43 GMT Message-Id: <201102250217.p1P2Hhq6089086@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155004: [bce] [panic] kernel panic in bce0 driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 02:17:44 -0000 Old Synopsis: kernel panic in bce0 driver New Synopsis: [bce] [panic] kernel panic in bce0 driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 25 02:17:28 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155004 From owner-freebsd-net@FreeBSD.ORG Fri Feb 25 07:59:45 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 427B5106566B for ; Fri, 25 Feb 2011 07:59:45 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D479F8FC0A for ; Fri, 25 Feb 2011 07:59:44 +0000 (UTC) Received: by pvg11 with SMTP id 11so260311pvg.13 for ; Thu, 24 Feb 2011 23:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=DzHT4hBBSuJ9B1TECDbhmLEFfs74umDRtkmt0yjb7rg=; b=lcs3fJbb+jLSdjZ0z2M/bDfi6HGT+miG+zrf263jQ9XZVfxPsNlUfd+yAjQGvw/R5x Lgxa26xzcbvT68AAPTACHZCRFbM7F4iD8ARciJ6Y7am1OECfBifTIhkgIFsbuqtEWUL5 xUQztZIcDegBVOtcsfIvbLwp+DT6X22K15uo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hK5B7foaYDHucEGhxluPqFaiGMOxg8YbNh94ItKvG9BnzftHpizbeCPbGTglZxw+rb nuhbG8yrEopVJi7Nm3aOEsl8SGder4xMbvIvPChyJ9HlmbWrcIm8sXXBVBJ8vpjAKYL6 tXrOYyuJffZuvs/zwvQ51SJEe8eAIO8DkeiQ8= MIME-Version: 1.0 Received: by 10.142.133.4 with SMTP id g4mr1443448wfd.188.1298618969416; Thu, 24 Feb 2011 23:29:29 -0800 (PST) Received: by 10.142.50.16 with HTTP; Thu, 24 Feb 2011 23:29:29 -0800 (PST) Date: Fri, 25 Feb 2011 10:29:29 +0300 Message-ID: From: c0re To: FreeBSD , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Strange behavior of MTU on loopback interfaces. 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, 25 Feb 2011 07:59:45 -0000 Hello all! I'm testing setting lower MTU on loopback interfaces to avoid some MTU problems with IPSEC in a path of traffic. ifconfig lo1 create ifconfig lo1 mtu 1300 ifconfig lo1 5.5.5.5/32 # ifconfig lo1 lo1: flags=8049 metric 0 mtu 1300 inet 5.5.5.5 netmask 0xffffffff #ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 12:ac:29:7c:fa:39 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseTX ) status: active And I set only one "Listen 5.5.5.5:80" in http.conf in apache 2.2 # sockstat -4 | grep 80 www httpd 96843 3 tcp4 5.5.5.5:80 *:* www httpd 96838 3 tcp4 5.5.5.5:80 *:* www httpd 96837 3 tcp4 5.5.5.5:80 *:* www httpd 96836 3 tcp4 5.5.5.5:80 *:* www httpd 96835 3 tcp4 5.5.5.5:80 *:* www httpd 96834 3 tcp4 5.5.5.5:80 *:* root httpd 96833 3 tcp4 5.5.5.5:80 *:* I run tcpdump -ni em0 port 80. And made telnet 5.5.5.5 80 from other host and saw something wrong. 10:26:01.640866 IP 10.0.0.2.57553 > 5.5.5.5.80: S 1049284626:1049284626(0) win 65535 10:26:01.640902 IP 5.5.5.5.80 > 10.0.0.2.57553: S 2144222949:2144222949(0) ack 1049284627 win 65535 10:26:01.642632 IP 10.0.0.2.57553 > 5.5.5.5.80: . ack 1 win 65535 5.5.5.5:80 said that it has got tcp mss 1460. Why? I was waiting for something like 1260. From owner-freebsd-net@FreeBSD.ORG Fri Feb 25 23:52:53 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 C3D55106566C; Fri, 25 Feb 2011 23:52:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBA78FC08; Fri, 25 Feb 2011 23:52:53 +0000 (UTC) Received: by qwj8 with SMTP id 8so1806821qwj.13 for ; Fri, 25 Feb 2011 15:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LXfzQgrDRPA7jqOFMuDcuzyzMSV2/htWS6M/UFznBw4=; b=aksgrOQkXuQ/JYMlrQFQ2Zx75FWU4woXHvcypyB+LL6z/84jUVM9EPdhUx1BidtV/D C7cPsp/jDNZIQgTgn3l+U9E6iAcA5yaTU9QbWznGc5Ne+q1UA2c97dG9DVCziHDnFCoA wNoIbDMUD/X7IZkONATz2KpiQ9snmE9JG6GIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ay3fZpaxtOR5Pou4xozkYr5hiOi35UhRiAN/pdLLy6P8V3t/NLEYC8pLkE4KLYUNCM UqJ+jIe6BUWKv9JW4Mf0foQdYXNzSOa+yhn1jNNENl5UMGKrEgl09hhrcJgG1njC7p9u m7I549SYWgh8lTUvnwvACVTUcJQAyfk3XuO3g= MIME-Version: 1.0 Received: by 10.229.245.1 with SMTP id ls1mr2389607qcb.13.1298677972600; Fri, 25 Feb 2011 15:52:52 -0800 (PST) Received: by 10.229.127.105 with HTTP; Fri, 25 Feb 2011 15:52:52 -0800 (PST) In-Reply-To: References: <201102231218136253955@yahoo.com.cn> <201102231404144686577@yahoo.com.cn> Date: Fri, 25 Feb 2011 18:52:52 -0500 Message-ID: From: Arnaud Lacombe To: beezarliu Content-Type: multipart/mixed; boundary=0016363b8b883c06cd049d24078f Cc: freebsd-net@freebsd.org, Jack Vogel , "bug-followup@FreeBSD.org" Subject: Re: Re: Re: kern/150516: [em] e1000 receive queue handling problem 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, 25 Feb 2011 23:52:53 -0000 --0016363b8b883c06cd049d24078f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, What is the point to invent a complex logic to detected a situation the chip warn you about ? The attached patch has currently survived longer than anything I've been ever tested, without dirty hack, like raising `nmbclusters'. Thanks in advance, - Arnaud ps: this is a temporary patch, for my 82754 based system, I am aware there is other user of IMS_ENABLE_MASK. On Wed, Feb 23, 2011 at 2:52 AM, Arnaud Lacombe wrote: > Hi, > > 2011/2/23 beezarliu : >> I think you can replace sys/dev/e1000/* =A0with the files in stable/8, >> and then uses this patch. It's much simpler. >> :) >> > agree. I switched to the driver of 8-STABLE, applied your patch > (without any conflict), fixed a bad version check (see [0]), built the > kernel, rebooted, ran the test... and hung em(4) RX again. 141k missed > packets (growing) and about 3k cluster allocations denied (constant) > currently. TX is fine, but the NIC is unable to process ARP and ICMP > reply sent back by the machine on the LAN. > > I did not test igb(4) as I do not have any on the path I directly > control, but the fix in trunk survived a few day of similar testing. > > =A0- Arnaud > > [0]: > diff --git a/sys/dev/e1000/if_igb.h b/sys/dev/e1000/if_igb.h > index 4388e07..adef0af 100644 > --- a/sys/dev/e1000/if_igb.h > +++ b/sys/dev/e1000/if_igb.h > @@ -508,7 +508,7 @@ struct igb_rx_buf { > =A0 =A0 =A0 =A0cur |=3D new; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 \ > =A0} > > -#if __FreeBSD_version < 800504 > +#if __FreeBSD_version >=3D 800000 && __FreeBSD_version < 800504 > =A0static __inline int > =A0drbr_needs_enqueue(struct ifnet *ifp, struct buf_ring *br) > =A0{ > --0016363b8b883c06cd049d24078f Content-Type: text/x-patch; charset=US-ASCII; name="0001-if_em-handle-RX-overrun.patch" Content-Disposition: attachment; filename="0001-if_em-handle-RX-overrun.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gklr8w9u0 RnJvbSAyNjU3NDc1NjFhMjA2MDQ2OWZlMGMyMTA5NGU3N2Q0NGIyYzBhMzlhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcm5hdWQgTGFjb21iZSA8bGFjb21iYXJAZ21haWwuY29tPgpE YXRlOiBGcmksIDI1IEZlYiAyMDExIDE4OjQ3OjQ4IC0wNTAwClN1YmplY3Q6IFtQQVRDSF0gaWZf ZW06IGhhbmRsZSBSWCBvdmVycnVuCgotLS0KIHN5cy9kZXYvZTEwMDAvZTEwMDBfZGVmaW5lcy5o IHwgICAgMSArCiBzeXMvZGV2L2UxMDAwL2lmX2VtLmMgICAgICAgICB8ICAgMjEgKysrKysrKysr KysrKysrKysrKystCiAyIGZpbGVzIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyksIDEgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9lMTAwMC9lMTAwMF9kZWZpbmVzLmggYi9zeXMv ZGV2L2UxMDAwL2UxMDAwX2RlZmluZXMuaAppbmRleCA1ZDA5YWQ5Li5lMGY1MWM0IDEwMDY0NAot LS0gYS9zeXMvZGV2L2UxMDAwL2UxMDAwX2RlZmluZXMuaAorKysgYi9zeXMvZGV2L2UxMDAwL2Ux MDAwX2RlZmluZXMuaApAQCAtODY1LDYgKzg2NSw3IEBACiAjZGVmaW5lIElNU19FTkFCTEVfTUFT SyAoIFwKICAgICBFMTAwMF9JTVNfUlhUMCAgIHwgICAgXAogICAgIEUxMDAwX0lNU19UWERXICAg fCAgICBcCisgICAgRTEwMDBfSU1TX1JYTyAgICB8ICAgIFwKICAgICBFMTAwMF9JTVNfUlhETVQw IHwgICAgXAogICAgIEUxMDAwX0lNU19SWFNFUSAgfCAgICBcCiAgICAgRTEwMDBfSU1TX0xTQykK ZGlmZiAtLWdpdCBhL3N5cy9kZXYvZTEwMDAvaWZfZW0uYyBiL3N5cy9kZXYvZTEwMDAvaWZfZW0u YwppbmRleCBlMDA0Y2M3Li5kNWUxMThhIDEwMDY0NAotLS0gYS9zeXMvZGV2L2UxMDAwL2lmX2Vt LmMKKysrIGIvc3lzL2Rldi9lMTAwMC9pZl9lbS5jCkBAIC0yODMsNiArMjgzLDcgQEAgc3RhdGlj IHZvaWQJZW1fbXNpeF9saW5rKHZvaWQgKik7CiBzdGF0aWMgdm9pZAllbV9oYW5kbGVfdHgodm9p ZCAqY29udGV4dCwgaW50IHBlbmRpbmcpOwogc3RhdGljIHZvaWQJZW1faGFuZGxlX3J4KHZvaWQg KmNvbnRleHQsIGludCBwZW5kaW5nKTsKIHN0YXRpYyB2b2lkCWVtX2hhbmRsZV9saW5rKHZvaWQg KmNvbnRleHQsIGludCBwZW5kaW5nKTsKK3N0YXRpYyB2b2lkCWVtX2hhbmRsZV9yeF9vdmVycnVu KHZvaWQgKmNvbnRleHQpOwogCiBzdGF0aWMgdm9pZAllbV9hZGRfcnhfcHJvY2Vzc19saW1pdChz dHJ1Y3QgYWRhcHRlciAqLCBjb25zdCBjaGFyICosCiAJCSAgICBjb25zdCBjaGFyICosIGludCAq LCBpbnQpOwpAQCAtMTU2Nyw5ICsxNTY4LDEyIEBAIGVtX21zaXhfbGluayh2b2lkICphcmcpCiAJ aWYgKHJlZ19pY3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwgRTEwMDBfSUNSX0xTQykpIHsKIAkJYWRh cHRlci0+aHcubWFjLmdldF9saW5rX3N0YXR1cyA9IDE7CiAJCWVtX2hhbmRsZV9saW5rKGFkYXB0 ZXIsIDApOworCX0gZWxzZSBpZiAocmVnX2ljciAmIEUxMDAwX0lDUl9SWE8pIHsKKwkJYWRhcHRl ci0+cnhfb3ZlcnJ1bnMrKzsKKwkJZW1faGFuZGxlX3J4X292ZXJydW4oYWRhcHRlcik7CiAJfSBl bHNlCiAJCUUxMDAwX1dSSVRFX1JFRygmYWRhcHRlci0+aHcsIEUxMDAwX0lNUywKLQkJICAgIEVN X01TSVhfTElOSyB8IEUxMDAwX0lNU19MU0MpOworCQkgICAgRU1fTVNJWF9MSU5LIHwgRTEwMDBf SU1TX0xTQyB8IEUxMDAwX0lNU19SWE8pOwogCXJldHVybjsKIH0KIApAQCAtMTYyNyw2ICsxNjMx LDIxIEBAIGVtX2hhbmRsZV9saW5rKHZvaWQgKmNvbnRleHQsIGludCBwZW5kaW5nKQogCUVNX0NP UkVfVU5MT0NLKGFkYXB0ZXIpOwogfQogCitzdGF0aWMgdm9pZAorZW1faGFuZGxlX3J4X292ZXJy dW4odm9pZCAqY29udGV4dCkKK3sKKwlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGNvbnRleHQ7 CisJc3RydWN0IGlmbmV0ICppZnAgPSBhZGFwdGVyLT5pZnA7CisJc3RydWN0IHJ4X3JpbmcgKnJ4 ciA9IGFkYXB0ZXItPnJ4X3JpbmdzOworCisJaWYgKCEoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZf RFJWX1JVTk5JTkcpKQorCQlyZXR1cm47CisKKwlFTV9DT1JFX0xPQ0soYWRhcHRlcik7CisJZW1f cmVmcmVzaF9tYnVmcyhyeHIsIHJ4ci0+bmV4dF90b19jaGVjayk7CisJRTEwMDBfV1JJVEVfUkVH KCZhZGFwdGVyLT5odywgRTEwMDBfSU1TLCBFMTAwMF9JTVNfUlhPKTsKKwlFTV9DT1JFX1VOTE9D SyhhZGFwdGVyKTsKK30KIAogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogICoKLS0gCjEuNy4zLjMuNDE4Lmc3MDRm Ni5kaXJ0eQoK --0016363b8b883c06cd049d24078f-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 26 04:12:35 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 5BFC11065714 for ; Sat, 26 Feb 2011 04:12:35 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from nm30-vm0.bullet.mail.ac4.yahoo.com (nm30-vm0.bullet.mail.ac4.yahoo.com [98.139.52.250]) by mx1.freebsd.org (Postfix) with SMTP id 8BFEC8FC0A for ; Sat, 26 Feb 2011 04:12:34 +0000 (UTC) Received: from [98.139.52.195] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 03:59:28 -0000 Received: from [74.6.228.39] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 03:59:28 -0000 Received: from [127.0.0.1] by smtp108.mail.ac4.yahoo.com with NNFMP; 26 Feb 2011 03:59:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1298692768; bh=I1Vb9Tu4hkKF+c8M3gz6GH4G6orsc+l0yduqUeIqm00=; h=X-Yahoo-Newman-Id:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Cc:References:Subject:Message-ID:X-mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; b=IC4xm2bQFFHdaJXJxNzWCkzclWAcYPKxW0sdejSn/fLAG5xRyxlNTmN91tPgXcSwebL9P7PQq3aZaxmn8q1LvOfhZlFrjo16qg/cq0EX3K1Sn/KFVH51S3Da/gUdVnCNd3dyXRUOYtlzkSum2dE0idVPuGPW1a1rpf+GlsEppNM= X-Yahoo-Newman-Id: 887265.68418.bm@smtp108.mail.ac4.yahoo.com Received: from china (beezarliu@221.137.121.170 with login) by smtp108.mail.ac4.yahoo.com with SMTP; 25 Feb 2011 19:59:28 -0800 PST X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: NFCGwakVM1knCbYnavroo78sfAXWMaApD7I1Ej5b_4nyGdJ oytU3PHe5p21evi6FDXt0DihXK4ygOt_jWA5sfwX7iejmtMYbzemS1uWrlkK zCPMFKqe8wJFdL7KQ0TY0tYYPfAT_Fk6X3KCFNIAMWZhBi02Mgovdk0QhX.J BiXMu3FBS9nNZteZ9ySubMoDSYJ5x2a0nZ2G_N6EQIWUAjVvrBISP4WUfCYe pNv8MeJc5VKxpAKRpYBxaPxt6BZkXho8tO232P9cc2MwxgYAq3alsE8tqe18 sbEsTF.yGq12deJzbiEk6NnVCA4zNT1OGZemclCmnuY0VuhJfQmU- X-Yahoo-Newman-Property: ymail-3 Date: Sat, 26 Feb 2011 11:59:26 +0800 From: "beezarliu" To: "Arnaud Lacombe" References: , <201102231218136253955@yahoo.com.cn>, , <201102231404144686577@yahoo.com.cn>, , Message-ID: <201102261159157631491@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Jack Vogel , "bug-followup@FreeBSD.org" Subject: Re: Re: Re: kern/150516: [em] e1000 receive queue handling problem 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, 26 Feb 2011 04:12:35 -0000 On 2011-02-26 07:52:54, Arnaud Lacombe wrote: >Hi, > >What is the point to invent a complex logic to detected a situation >the chip warn you about ? > >The attached patch has currently survived longer than anything I've >been ever tested, without dirty hack, like raising `nmbclusters'. Sorry, I didn't 'invent' the logic, it's just what rx ring queue works in hardware. You provided another way to detect the hang, which doesn't mean others are meaningless. Raising nmbcluster is not best way, but it can ease the memory shortage, and allcate more for network, which also improve system performance. Beezar From owner-freebsd-net@FreeBSD.ORG Sat Feb 26 07:14: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 D3857106566B; Sat, 26 Feb 2011 07:14:27 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8974C8FC15; Sat, 26 Feb 2011 07:14:27 +0000 (UTC) Received: by iwn33 with SMTP id 33so1927711iwn.13 for ; Fri, 25 Feb 2011 23:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vG5k4jkfEBDNFl+wpzBs4i5Q5LhAwzRI/qrNiAZydik=; b=Ziauh82kCorRaTsRibuPT2y5I++uxbhTFocRaotUPWnYie1E1BcqY6/81x3a8maVZ7 uNhOx3uGlNX/rRh0/3fhIi1hYtvqYLw9QRMCsM2dwCUIZItp+EnQe/kmJ/aT53JdtckE f8oEr7JzkJ49XMmCnCiMPFgCE5ZCBAkdFMrro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IZiKU/PJPA3xsiqOc/18tp/B2oAhNV1asdRXNbMoB80g6VaFNXHbQIBVaX2R75dxIm u+r6uE9ekZvV3EYE+0zQh1oX0LfbLuqGeXhoTVPuEfC46nQKewdDUQpvumoGCB7gV/wZ MMov7GFGNb0u8oSDiAcSmrVuVz4R5HdRPHli8= MIME-Version: 1.0 Received: by 10.42.176.1 with SMTP id bc1mr1869365icb.323.1298704466443; Fri, 25 Feb 2011 23:14:26 -0800 (PST) Received: by 10.42.165.135 with HTTP; Fri, 25 Feb 2011 23:14:26 -0800 (PST) In-Reply-To: <201102261159157631491@yahoo.com.cn> References: <201102231218136253955@yahoo.com.cn> <201102231404144686577@yahoo.com.cn> <201102261159157631491@yahoo.com.cn> Date: Sat, 26 Feb 2011 02:14:26 -0500 Message-ID: From: Arnaud Lacombe To: beezarliu Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Jack Vogel , "bug-followup@FreeBSD.org" Subject: Re: Re: Re: kern/150516: [em] e1000 receive queue handling problem 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, 26 Feb 2011 07:14:27 -0000 Hi, 2011/2/25 beezarliu : > Raising nmbcluster is not best way, but it can ease the memory shortage, > and allcate more for network, which also improve system performance. > sure, but the driver should still be able to deals with such condition without stalling. :) - Arnaud From owner-freebsd-net@FreeBSD.ORG Sat Feb 26 09:17:03 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 2CBB3106564A; Sat, 26 Feb 2011 09:17:03 +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 02FEF8FC0C; Sat, 26 Feb 2011 09:17:03 +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 p1Q9H2EH066594; Sat, 26 Feb 2011 09:17:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1Q9H2AB066590; Sat, 26 Feb 2011 09:17:02 GMT (envelope-from linimon) Date: Sat, 26 Feb 2011 09:17:02 GMT Message-Id: <201102260917.p1Q9H2AB066590@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-fs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155010: [msk] ntfs-3g via iscsi using msk driver cause kernel 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: Sat, 26 Feb 2011 09:17:03 -0000 Old Synopsis: [ntfs] ntfs-3g via iscsi using msk driver cause kernel panic New Synopsis: [msk] ntfs-3g via iscsi using msk driver cause kernel panic Responsible-Changed-From-To: freebsd-fs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 26 09:16:34 UTC 2011 Responsible-Changed-Why: reclassify per jhb. http://www.freebsd.org/cgi/query-pr.cgi?pr=155010 From owner-freebsd-net@FreeBSD.ORG Sat Feb 26 09:17:29 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 8E76A106566B; Sat, 26 Feb 2011 09:17:29 +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 64E838FC14; Sat, 26 Feb 2011 09:17:29 +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 p1Q9HTBq066701; Sat, 26 Feb 2011 09:17:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1Q9HT7V066697; Sat, 26 Feb 2011 09:17:29 GMT (envelope-from linimon) Date: Sat, 26 Feb 2011 09:17:29 GMT Message-Id: <201102260917.p1Q9HT7V066697@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155030: [igb] igb(4) DEVICE_POLLING does not work with carp(4) 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, 26 Feb 2011 09:17:29 -0000 Old Synopsis: igb(4) DEVICE_POLLING does not work with carp(4) New Synopsis: [igb] igb(4) DEVICE_POLLING does not work with carp(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Feb 26 09:17:18 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155030