From owner-freebsd-net@FreeBSD.ORG Sun Sep 4 02:15: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 4E4AD1065672; Sun, 4 Sep 2011 02:15:47 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE818FC0A; Sun, 4 Sep 2011 02:15:46 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 0551D7E824; Sun, 4 Sep 2011 12:15:29 +1000 (EST) Message-ID: <4E62DF40.4020001@freebsd.org> Date: Sun, 04 Sep 2011 12:15:28 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.1) Gecko/20110903 Thunderbird/6.0.1 MIME-Version: 1.0 To: Andre Oppermann References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk><4E37C0F2.4080004@freebsd.org><2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk><4E3AA66A.6060605@freebsd.org><20229216858044E4881642284F245750@multiplay.co.uk> <4E432CB2.3030700@freebsd.org> <177917182AAD46A3962139F22B835B37@multiplay.co.uk> <4E5AD893.7010708@freebsd.org> <4E5B785D.6000009@freebsd.org> In-Reply-To: <4E5B785D.6000009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 04 Sep 2011 02:15:47 -0000 Sorry for the delay in responding. On 08/29/11 21:30, Andre Oppermann wrote: > On 29.08.2011 02:08, Lawrence Stewart wrote: >> On 08/14/11 23:53, Steven Hartland wrote: >>> ----- Original Message ----- From: "Lawrence Stewart" >>> >>>> >>>> Here's my tweaked version of Andre's patch: >>>> http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass.c-logdebug%2bmissingsegment-20110811-lstewart.diff >>>> >>>> >>>> >>> >>> Still testing this and just noticed that the patch fails to >>> compile when INVARIANTS is enabled. The KASSERT calls need >>> ()'s around the split strings. >> >> oops, sorry. Compile tested on 8-STABLE without INVARIANTS enabled :/ >> >> Any further feedback with respect to the patch? Plan to submit it to >> re@ later this week for >> inclusion in 9.0. > > I'm not sure these excessive KASSERT's are really necessary. Probably one > covering those cases at the start of the function is sufficient. I don't see how the logic currently captured in the KASSERTs I've added could be easily captured in a single KASSERT at the top of the function. I also think KASSERTs are most usefully placed next to the code which is making the assumption you wish to sanity check. Could you please give me a few pointers as to what you had in mind? > I was about to send the original patch to re@ for approval as well now > that I'm back from vacation and fully available again. Don't mind if > you do it if you've got the time. I didn't realise you'd gone on holidays and planned to deal with this on your return so I already started a dialogue with re@ and might as well follow it through now. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Sun Sep 4 06:25: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 98EC61065674; Sun, 4 Sep 2011 06:25: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 714BC8FC0A; Sun, 4 Sep 2011 06:25: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 p846PEYI008167; Sun, 4 Sep 2011 06:25:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p846PE3j008163; Sun, 4 Sep 2011 06:25:14 GMT (envelope-from linimon) Date: Sun, 4 Sep 2011 06:25:14 GMT Message-Id: <201109040625.p846PE3j008163@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/160420: [msk] phy write timeout on HP 5310m 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, 04 Sep 2011 06:25:14 -0000 Old Synopsis: msk0: phy write timeout on HP 5310m New Synopsis: [msk] phy write timeout on HP 5310m Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 4 06:25:04 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=160420 From owner-freebsd-net@FreeBSD.ORG Sun Sep 4 06:27:34 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 2EDE91065673; Sun, 4 Sep 2011 06:27:34 +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 069C98FC0C; Sun, 4 Sep 2011 06:27:34 +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 p846RXTk008426; Sun, 4 Sep 2011 06:27:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p846RXg8008422; Sun, 4 Sep 2011 06:27:33 GMT (envelope-from linimon) Date: Sun, 4 Sep 2011 06:27:33 GMT Message-Id: <201109040627.p846RXg8008422@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/160442: [vlan] Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish. 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, 04 Sep 2011 06:27:34 -0000 Old Synopsis: Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish. New Synopsis: [vlan] Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 4 06:27:20 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=160442 From owner-freebsd-net@FreeBSD.ORG Sun Sep 4 09:30:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A5F6106564A; Sun, 4 Sep 2011 09:30:59 +0000 (UTC) (envelope-from to.my.trociny@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 289C88FC16; Sun, 4 Sep 2011 09:30:57 +0000 (UTC) Received: by fxe4 with SMTP id 4so3643034fxe.13 for ; Sun, 04 Sep 2011 02:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:sender:date:message-id:user-agent:mime-version :content-type; bh=ThHx+V52/7cqw0fRDjWZST0p6tWL0tpr+5853OB2cjk=; b=egJ2dLWcp70Zz6O8lXNOx4zmd6d3R2LuGZe8cdk5M6dhO/M9jQpXD+GjJxfRWppOqe VmMs0+uGdreG9B6ln3qqOaQbN1sBFr4dK10XxIdbb+7WnEkDbyEFtuPEDh4mOTnhea9O LTOQU0acVUZf02pNO1fT4h1htP/pJ1zjEYsAU= Received: by 10.223.29.82 with SMTP id p18mr5306359fac.44.1315128657089; Sun, 04 Sep 2011 02:30:57 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id l20sm2673805fad.12.2011.09.04.02.30.54 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Sep 2011 02:30:55 -0700 (PDT) From: Mikolaj Golub To: freebsd-net@freebsd.org Sender: Mikolaj Golub Date: Sun, 04 Sep 2011 12:30:53 +0300 Message-ID: <86ehzwwt6a.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Kostik Belousov , Pawel Jakub Dawidek , Andre Oppermann Subject: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL 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, 04 Sep 2011 09:30:59 -0000 --=-=-= Hi, Apparently soreceive_stream() has an issue if it is called to receive data as a mbuf chain (by supplying an non zero mbuf **mp0) and with MSG_WAITALL set. I ran into this issue with smbfs, which uses soreceive() exactly in this way (see netsmb/smb_trantcp.c:nbssn_recv()). If MSG_WAITALL is set and not all data is received it loops again but on the next run mb0 is set to sb->sb_mb again loosing all previously received mbufs. It looks like it should be set to the end of mb0 chain instead. See the attached path. Also, in the "copy the remainder" block we reduce uio_resid by m->m_len (the length of the last mbuf in the chain), but it looks like for the MSG_PEEK case the remainder may have more than one mbuf in the chain and we have to reduce by len (the length of the copied chain). I don't have a test case to check MSG_PEEK issue, but the patch fixes the issue with smbfs for me. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=uipc_socket.c.soreceive_stream.patch Index: sys/kern/uipc_socket.c =================================================================== --- sys/kern/uipc_socket.c (revision 225368) +++ sys/kern/uipc_socket.c (working copy) @@ -2030,7 +2030,11 @@ deliver: if (mp0 != NULL) { /* Dequeue as many mbufs as possible. */ if (!(flags & MSG_PEEK) && len >= sb->sb_mb->m_len) { - for (*mp0 = m = sb->sb_mb; + if (*mp0 == NULL) + *mp0 = sb->sb_mb; + else + n->m_next = sb->sb_mb; + for (m = sb->sb_mb; m != NULL && m->m_len <= len; m = m->m_next) { len -= m->m_len; @@ -2052,7 +2056,7 @@ deliver: if (m == NULL) len = 0; /* Don't flush data from sockbuf. */ else - uio->uio_resid -= m->m_len; + uio->uio_resid -= len; if (*mp0 != NULL) n->m_next = m; else @@ -2061,6 +2065,9 @@ deliver: error = ENOBUFS; goto out; } + /* Update n to point to the last mbuf. */ + for (; m != NULL; m = m->m_next) + n = m; } } else { /* NB: Must unlock socket buffer as uiomove may sleep. */ --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 4 13:20:08 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 B81D3106568D for ; Sun, 4 Sep 2011 13:20:08 +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 99EEE8FC14 for ; Sun, 4 Sep 2011 13:20:08 +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 p84DK8jF023104 for ; Sun, 4 Sep 2011 13:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p84DK8xC023103; Sun, 4 Sep 2011 13:20:08 GMT (envelope-from gnats) Date: Sun, 4 Sep 2011 13:20:08 GMT Message-Id: <201109041320.p84DK8xC023103@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: brahmann Cc: Subject: kern/155642: [request] Add driver for Realtek RTL8191SE/RTL8192SE WiFi chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: brahmann List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2011 13:20:08 -0000 The following reply was made to PR kern/155642; it has been noted by GNATS. From: brahmann To: bug-followup@FreeBSD.org, fbsd@opal.com Cc: Subject: kern/155642: [request] Add driver for Realtek RTL8191SE/RTL8192SE WiFi chipset Date: Sun, 04 Sep 2011 15:48:49 +0300 Hi, have laptop Lenovo ThinkPad SL410, with thinkpad 11b/g/n - chipset Realtek 8191SE (wifi) Wifi doesn`t work too :( i saw http://www.freebsd.org/cgi/query-pr.cgi?pr=155642 this request and want to ask - somebody developing it already? need wifi :( my pciconf none5@pci0:4:0:0: class=0x028000 card=0xe02010ec chip=0x817210ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Realtek RTL8191SE wireless LAN 802.11N PCI-E NIC (RTL8191SE ?)' class = network bar [10] = type I/O Port, range 32, base 0x2000, size 256, enabled bar [14] = type Memory, range 32, base 0xf2200000, size 16384, enabled cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(256) link x1(x1) Thank you for any answer. -- wbr, brahmann From owner-freebsd-net@FreeBSD.ORG Sun Sep 4 22:13:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 659B2106566C; Sun, 4 Sep 2011 22:13:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0FF998FC0A; Sun, 4 Sep 2011 22:13:39 +0000 (UTC) Received: by gxk28 with SMTP id 28so3645771gxk.13 for ; Sun, 04 Sep 2011 15:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Uri75OlvNuSgHiBCfQTTuC1m3H+ZaAt3a+m7VAObjqU=; b=WE1OKE9McgFDZptocpgZFP0RuIIKhU5RoAxxxzb9bv8avpPPXw5et52z28WiZz/h2k CfFczgJRuCwahE/AmMPezf1tUs/n3IAMpuRWXHxuwELvBLRNKjAYFr8T8aakcR0BHJWl CdkrkOcLU9WpGP1VN4KQpuCIixktIxxmVPM9I= MIME-Version: 1.0 Received: by 10.236.176.226 with SMTP id b62mr14807246yhm.78.1315174419444; Sun, 04 Sep 2011 15:13:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.103.6 with HTTP; Sun, 4 Sep 2011 15:13:39 -0700 (PDT) In-Reply-To: <4E6050F0.2040203@mgwigglesworth.net> References: <4E5D5422.9040609@mgwigglesworth.net> <4E5EE805.5010905@mgwigglesworth.net> <4E6050F0.2040203@mgwigglesworth.net> Date: Mon, 5 Sep 2011 06:13:39 +0800 X-Google-Sender-Auth: B-O4xHmCsmchvSiwheySmwUTsRU Message-ID: From: Adrian Chadd To: mailinglistmember@mgwigglesworth.net Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org Subject: Re: [Solved] Re:Commands for AR5212 cause system to hang using 8.2-STABLE 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, 04 Sep 2011 22:13:40 -0000 On 2 September 2011 11:43, Martes G Wigglesworth wrote: > > However, all works perfectly, if I simply assign the intended ip address to > the wlan0 device. > > Any input on this? I don't have anything useful to add; but then I don't use hostap mode with an IP address on the wlan interface. I tend to dump the hostap wlan interfaces into a bridge group. You'll likely have to go digging into the network scripts a bit. Also, you likely shouldn't have " "'s around the ssid. Adrian From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 06:59: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 0812E10656D2 for ; Mon, 5 Sep 2011 06:59:53 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id C70258FC1C for ; Mon, 5 Sep 2011 06:59:52 +0000 (UTC) Received: by pzk33 with SMTP id 33so14214034pzk.18 for ; Sun, 04 Sep 2011 23:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=kS3winUxiANfN0zdLqyVLX7b1bRI0Xk3BL2QQ1iLrzA=; b=b/KmhDPyp6GA7bqn+jiFpg16ivdoP3U07Kglz46oJOoi+dXZ7/JjnDQ6wlg1ZtjBxQ 3xVPRRoGS2NvBluOVlMfLw/rtAvi0rj5gxwe6zs6TGgv8fkCDcC945iliSyYLYioTfI+ u5NcFG6V/sKLAWu1MzLfXElhBkz9Ybhf72BHw= MIME-Version: 1.0 Received: by 10.68.17.67 with SMTP id m3mr7184060pbd.329.1315205992468; Sun, 04 Sep 2011 23:59:52 -0700 (PDT) Received: by 10.142.131.15 with HTTP; Sun, 4 Sep 2011 23:59:52 -0700 (PDT) Date: Mon, 5 Sep 2011 02:59:52 -0400 Message-ID: From: Arnaud Lacombe To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=bcaec51f8e8bfcd05f04ac2c4177 Cc: Jack Vogel Subject: FreeBSD 7-STABLE mbuf corruption 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, 05 Sep 2011 06:59:53 -0000 --bcaec51f8e8bfcd05f04ac2c4177 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We have been trying to track down a bad mbuf management for about two weeks on a customized 7.1 base. I have finally been able to reproduce it with a stock FreeBSD 7-STABLE (kernel from r225276, userland from 7.4). With the help of the attached patches, I have just been able to trigger the following panic: panic: Corrupted unused flags, expected 0xffffffff00000000, got 0x0, flags 0x3 cpuid = 1 Uptime: 3d10h5m3s Cannot dump. No dump device defined The patches taints high order 32bits of m_flags (extended to 64bits; those are thus unused) right before the mbuf is referenced in the TX ring of the igb(4) driver, I expect this value to never change until right before the mbuf is freed igb_txeof(). [About this, Jack, am I correct expecting the mbuf's flags not to be touched between igb_xmit() and igb_txeof() ?] I have strong suspicions that this is the cause of PR/155597, eventually a few others PR. My current assumption about the root cause of this behavior is that the same mbuf ends up being queued for TX twice. After the first TX, it gets released, eventually reused in socket's buffer, but ends up being freed again after the second TX, screwing the chains at the same time, leading to crashes of the box. On the crashes happens in multiple locations. We have seen crashes (both clean panic() and NULL-pointer dereference) in various places over the last weeks, first an almost daily panic() in sbdrop() or sbsndptr(), and NULL-pointer dereferences in hfsc_dequeue(), m_ext_free(), m_copym, and the list goes on. On the driver p.o.v, crashes happened with igb(4) end of last year. At the time, dropping the number of queue to 1 mitigated the problem... so far. Now, the daily crashes happens with em(4) (single queue by default on 7). We also have records of crashes in sbsndptr() on vr(4)-based devices. Crashes seen on em(4) configuration are almost always preceded by one or many: emX: discard frame w/o packet header which we agree, should not happen. On the traffic p.o.v., crashes happens on a 24h basis with a box handling about 30Mbps over a couple of thousands TCP connections. I have been able to get consistent crashes in about 1h with ALTQ enabled, proxying about 200 TCP connection over 200Mbps of traffic (unidirectional, sub-ms RTT). Crashes becomes a lot faster with ALTQ disabled, down to a reliable crash within 5min. The box is running a few hundreds ipfw rules. Without any ipfw rules loaded, crashes happens within 30min. Now, the FreeBSD 7-STABLE machine has been able to handle about 900Mbps of traffic, over 2*500 TCP connections (500 receiving, 500 sending), over 24h without crashing. It crashed almost instantly when I restarted the test today. The kernel has been built with INVARIANTS and INVARIANT_SUPPORT. Hardware enumerate as follow: CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x40ce3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 3757834240 (3583 MB) avail memory = 3678064640 (3507 MB) ACPI APIC Table: <100509 APIC1714> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu (AP): APIC ID: 4 (disabled) cpu (AP): APIC ID: 5 (disabled) cpu (AP): APIC ID: 6 (disabled) cpu (AP): APIC ID: 7 (disabled) [...] igb0: port 0xec00-0xec1f mem 0xfdf60000-0xfdf7ffff,0xfdf40000-0xfdf5ffff,0xfdfb8000-0xfdfbbfff irq 16 at device 0.0 on pci7 igb0: Using MSIX interrupts with 5 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:15:b2:xx:xx:xx igb1: port 0xec80-0xec9f mem 0xfdfe0000-0xfdffffff,0xfdfc0000-0xfdfdffff,0xfdfbc000-0xfdfbffff irq 17 at device 0.1 on pci7 igb1: Using MSIX interrupts with 5 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:15:b2:xx:xx:xx em(4) and igb(4) are a direct backport from HEAD, plus the build fix I posted a few days ago. Custom mbuf debugging is attached, as well as the config of the kernel. The goal of the changes was first to enforce mbuf trashing, then locate the bogus m_freem()[0], thus modifying the mbuf free path to taint the mbuf not with the static 0xdeadc0de, but with the IP of the call-site. Then add some consistency check. At this point, any help is appreciated! Thanks in advance, - Arnaud [0]: the reason behind that is that I first got tons of crashes related 0xdeadc0de, in particular, an mbuf being tagged M_PROMISC, while the interface was not in promiscuous mode crashing on an unwanted call to m_freem() in ether_demub() --bcaec51f8e8bfcd05f04ac2c4177 Content-Type: application/octet-stream; name=GENERIC Content-Disposition: attachment; filename=GENERIC Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs737y7j0 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJl YWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoK IwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9o YW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBoYW5kYm9vayBpcyBhbHNv IGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rCiMgaWYgeW91J3Zl IGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUgdGhl CiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIgKGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcv KSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9uLgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9m IG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBs aW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZp bGVzLgojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5 IG9mIGEgbGluZSwgY2hlY2sgZmlyc3QKIyBpbiBOT1RFUy4KIwojICRGcmVlQlNEJAoKI2NwdQkJ STQ4Nl9DUFUKI2NwdQkJSTU4Nl9DUFUKY3B1CQlJNjg2X0NQVQppZGVudAkJR0VORVJJQwoKIyBU byBzdGF0aWNhbGx5IGNvbXBpbGUgaW4gZGV2aWNlIHdpcmluZyBpbnN0ZWFkIG9mIC9ib290L2Rl dmljZS5oaW50cwojaGludHMJCSJHRU5FUklDLmhpbnRzIgkJIyBEZWZhdWx0IHBsYWNlcyB0byBs b29rIGZvciBkZXZpY2VzLgoKbWFrZW9wdGlvbnMJREVCVUc9LWcJCSMgQnVpbGQga2VybmVsIHdp dGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMKCm9wdGlvbnMgCVNDSEVEX1VMRQkJIyBVTEUgc2NoZWR1 bGVyCm9wdGlvbnMgCVBSRUVNUFRJT04JCSMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlv bgpvcHRpb25zIAlJTkVUCQkJIyBJbnRlck5FVHdvcmtpbmcKb3B0aW9ucyAJSU5FVDYJCQkjIElQ djYgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzCiNvcHRpb25zIAlTQ1RQCQkJIyBTdHJlYW0gQ29u dHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wKb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0 IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFURVMJCSMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0 ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nlc3MgY29udHJv bCBsaXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJp ZyBkaXJlY3RvcmllcwpvcHRpb25zIAlVRlNfR0pPVVJOQUwJCSMgRW5hYmxlIGdqb3VybmFsLWJh c2VkIFVGUyBqb3VybmFsaW5nCm9wdGlvbnMgCU1EX1JPT1QJCQkjIE1EIGlzIGEgcG90ZW50aWFs IHJvb3QgZGV2aWNlCiNvcHRpb25zIAlORlNDTElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENs aWVudAojb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXIKI29w dGlvbnMgCU5GU0xPQ0tECQkjIE5ldHdvcmsgTG9jayBNYW5hZ2VyCiNvcHRpb25zIAlORlNfUk9P VAkJIyBORlMgdXNhYmxlIGFzIC8sIHJlcXVpcmVzIE5GU0NMSUVOVAojb3B0aW9ucyAJTVNET1NG UwkJCSMgTVNET1MgRmlsZXN5c3RlbQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVz eXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZTCQkJIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBT RVVET0ZTKQpvcHRpb25zIAlQU0VVRE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsK b3B0aW9ucyAJR0VPTV9QQVJUX0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMg CUdFT01fTEFCRUwJCSMgUHJvdmlkZXMgbGFiZWxpemF0aW9uCm9wdGlvbnMgCUNPTVBBVF80M1RU WQkJIyBCU0QgNC4zIFRUWSBjb21wYXQgW0tFRVAgVEhJUyFdCiNvcHRpb25zIAlDT01QQVRfRlJF RUJTRDQJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0CiNvcHRpb25zIAlDT01QQVRfRlJFRUJT RDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q1CiNvcHRpb25zIAlDT01QQVRfRlJFRUJTRDYJ CSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2CiNvcHRpb25zIAlTQ1NJX0RFTEFZPTUwMDAJCSMg RGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMgCUtUUkFDRQkJCSMga3Ry YWNlKDEpIHN1cHBvcnQKb3B0aW9ucyAJU1RBQ0sJCQkjIHN0YWNrKDkpIHN1cHBvcnQKb3B0aW9u cyAJU1lTVlNITQkJCSMgU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5Cm9wdGlvbnMgCVNZU1ZNU0cJ CQkjIFNZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9ucyAJU1lTVlNFTQkJCSMgU1lTVi1z dHlsZSBzZW1hcGhvcmVzCm9wdGlvbnMgCVAxMDAzXzFCX1NFTUFQSE9SRVMJIyBQT1NJWC1zdHls ZSBzZW1hcGhvcmVzCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAjIFBPU0lY IFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJ IyBpbnN0YWxsIGEgQ0RFViBlbnRyeSBpbiAvZGV2Cm9wdGlvbnMgCUFEQVBUSVZFX0dJQU5UCQkj IEdpYW50IG11dGV4IGlzIGFkYXB0aXZlLgpvcHRpb25zIAlTVE9QX05NSQkJIyBTdG9wIENQVVMg dXNpbmcgTk1JIGluc3RlYWQgb2YgSVBJCm9wdGlvbnMgCUFVRElUCQkJIyBTZWN1cml0eSBldmVu dCBhdWRpdGluZwojb3B0aW9ucyAJS0RUUkFDRV9IT09LUwkJIyBLZXJuZWwgRFRyYWNlIGhvb2tz Cm9wdGlvbnMgCUlOQ0xVREVfQ09ORklHX0ZJTEUgICAgICMgSW5jbHVkZSB0aGlzIGZpbGUgaW4g a2VybmVsCgojIFRvIG1ha2UgYW4gU01QIGtlcm5lbCwgdGhlIG5leHQgdHdvIGxpbmVzIGFyZSBu ZWVkZWQKb3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsCmRl dmljZQkJYXBpYwkJCSMgSS9PIEFQSUMKCiMgQ1BVIGZyZXF1ZW5jeSBjb250cm9sCmRldmljZQkJ Y3B1ZnJlcQoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlCQllaXNhCmRldmljZQkJcGNpCgojIEZsb3Bw eSBkcml2ZXMKI2RldmljZQkJZmRjCgojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcwpkZXZpY2UJCWF0 YQpkZXZpY2UJCWF0YWRpc2sJCSMgQVRBIGRpc2sgZHJpdmVzCmRldmljZQkJYXRhcmFpZAkJIyBB VEEgUkFJRCBkcml2ZXMKI2RldmljZQkJYXRhcGljZAkJIyBBVEFQSSBDRFJPTSBkcml2ZXMKI2Rl dmljZQkJYXRhcGlmZAkJIyBBVEFQSSBmbG9wcHkgZHJpdmVzCiNkZXZpY2UJCWF0YXBpc3QJCSMg QVRBUEkgdGFwZSBkcml2ZXMKb3B0aW9ucyAJQVRBX1NUQVRJQ19JRAkjIFN0YXRpYyBkZXZpY2Ug bnVtYmVyaW5nCgojIFNDU0kgQ29udHJvbGxlcnMKI2RldmljZQkJYWhiCQkjIEVJU0EgQUhBMTc0 MiBmYW1pbHkKI2RldmljZQkJYWhjCQkjIEFIQTI5NDAgYW5kIG9uYm9hcmQgQUlDN3h4eCBkZXZp Y2VzCiNvcHRpb25zIAlBSENfUkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZp ZWxkcyBpbiBkZWJ1ZwoJCQkJCSMgb3V0cHV0LiAgQWRkcyB+MTI4ayB0byBkcml2ZXIuCiNkZXZp Y2UJCWFoZAkJIyBBSEEzOTMyMC8yOTMyMCBhbmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMKI29w dGlvbnMgCUFIRF9SRUdfUFJFVFRZX1BSSU5UCSMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGlu IGRlYnVnCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4yMTVrIHRvIGRyaXZlci4KI2RldmljZQkJYW1k CQkjIEFNRCA1M0M5NzQgKFRla3JhbSBEQy0zOTAoVCkpCiNkZXZpY2UJCWhwdGlvcAkJIyBIaWdo cG9pbnQgUm9ja2V0UmFpZCAzeHh4IHNlcmllcwojZGV2aWNlCQlpc3AJCSMgUWxvZ2ljIGZhbWls eQojZGV2aWNlIAlpc3BmdwkJIyBGaXJtd2FyZSBmb3IgUUxvZ2ljIEhCQXMtIG5vcm1hbGx5IGEg bW9kdWxlCiNkZXZpY2UJCW1wdAkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbgojZGV2aWNlCQluY3IJ CSMgTkNSL1N5bWJpb3MgTG9naWMKI2RldmljZQkJc3ltCQkjIE5DUi9TeW1iaW9zIExvZ2ljIChu ZXdlciBjaGlwc2V0cyArIHRob3NlIG9mIGBuY3InKQojZGV2aWNlCQl0cm0JCSMgVGVrcmFtIERD Mzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycwoKI2RldmljZQkJYWR2CQkjIEFkdmFuc3lzIFNDU0kg YWRhcHRlcnMKI2RldmljZQkJYWR3CQkjIEFkdmFuc3lzIHdpZGUgU0NTSSBhZGFwdGVycwojZGV2 aWNlCQlhaGEJCSMgQWRhcHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMKI2RldmljZQkJYWljCQkjIEFk YXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlDLTZbMjNdNjAuCiNkZXZpY2UJCWJ0CQkj IEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kgYWRhcHRlcnMKCiNkZXZpY2UJCW5jdgkJ IyBOQ1IgNTNDNTAwCiNkZXZpY2UJCW5zcAkJIyBXb3JrYml0IE5pbmphIFNDU0ktMwojZGV2aWNl CQlzdGcJCSMgVE1DIDE4QzMwLzE4QzUwCgojIFNDU0kgcGVyaXBoZXJhbHMKZGV2aWNlCQlzY2J1 cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpCmRldmljZQkJY2gJCSMgU0NTSSBtZWRp YSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQojZGV2aWNlCQlz YQkJIyBTZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpCiNkZXZpY2UJCWNkCQkjIENECmRldmlj ZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2VzcykKZGV2aWNl CQlzZXMJCSMgU0NTSSBFbnZpcm9ubWVudGFsIFNlcnZpY2VzIChhbmQgU0FGLVRFKQoKIyBSQUlE IGNvbnRyb2xsZXJzIGludGVyZmFjZWQgdG8gdGhlIFNDU0kgc3Vic3lzdGVtCiNkZXZpY2UJCWFt cgkJIyBBTUkgTWVnYVJBSUQKI2RldmljZQkJYXJjbXNyCQkjIEFyZWNhIFNBVEEgSUkgUkFJRAoj ZGV2aWNlCQlhc3IJCSMgRFBUIFNtYXJ0UkFJRCBWLCBWSSBhbmQgQWRhcHRlYyBTQ1NJIFJBSUQK I2RldmljZQkJY2lzcwkJIyBDb21wYXEgU21hcnQgUkFJRCA1KgojZGV2aWNlCQlkcHQJCSMgRFBU IFNtYXJ0Y2FjaGUgSUlJLCBJViAtIFNlZSBOT1RFUyBmb3Igb3B0aW9ucwojZGV2aWNlCQlocHRt dgkJIyBIaWdocG9pbnQgUm9ja2V0UkFJRCAxODJ4CiNkZXZpY2UJCWhwdHJyCQkjIEhpZ2hwb2lu dCBSb2NrZXRSQUlEIDE3eHgsIDIyeHgsIDIzeHgsIDI1eHgKI2RldmljZQkJaWlyCQkjIEludGVs IEludGVncmF0ZWQgUkFJRAojZGV2aWNlCQlpcHMJCSMgSUJNIChBZGFwdGVjKSBTZXJ2ZVJBSUQK I2RldmljZQkJbWx5CQkjIE15bGV4IEFjY2VsZVJBSUQvZVh0cmVtZVJBSUQKI2RldmljZQkJdHdh CQkjIDN3YXJlIDkwMDAgc2VyaWVzIFBBVEEvU0FUQSBSQUlECgojIFJBSUQgY29udHJvbGxlcnMK I2RldmljZQkJYWFjCQkjIEFkYXB0ZWMgRlNBIFJBSUQKI2RldmljZQkJYWFjcAkJIyBTQ1NJIHBh c3N0aHJvdWdoIGZvciBhYWMgKHJlcXVpcmVzIENBTSkKI2RldmljZQkJaWRhCQkjIENvbXBhcSBT bWFydCBSQUlECiNkZXZpY2UJCW1maQkJIyBMU0kgTWVnYVJBSUQgU0FTCiNkZXZpY2UJCW1seAkJ IyBNeWxleCBEQUM5NjAgZmFtaWx5CiNkZXZpY2UJCXBzdAkJIyBQcm9taXNlIFN1cGVydHJhayBT WDYwMDAKI2RldmljZQkJdHdlCQkjIDN3YXJlIEFUQSBSQUlECgojIGF0a2JkYzAgY29udHJvbHMg Ym90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlCmRldmljZQkJYXRrYmRjCQkjIEFU IGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2aWNlCQlhdGtiZAkJIyBBVCBrZXlib2FyZApkZXZpY2UJ CXBzbQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJCWtiZG11eAkJIyBrZXlib2FyZCBtdWx0aXBsZXhl cgoKZGV2aWNlCQl2Z2EJCSMgVkdBIHZpZGVvIGNhcmQgZHJpdmVyCgojZGV2aWNlCQlzcGxhc2gJ CSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQKCiMgc3lzY29ucyBpcyB0 aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBTQ08gY29uc29sZQpkZXZp Y2UJCXNjCgpkZXZpY2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIFBv d2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAoc2VlIE5PVEVTIGZvciBtb3JlIG9wdGlvbnMpCiNkZXZp Y2UJCWFwbQojIEFkZCBzdXNwZW5kL3Jlc3VtZSBzdXBwb3J0IGZvciB0aGUgaTgyNTQuCmRldmlj ZQkJcG10aW1lcgoKIyBQQ0NBUkQgKFBDTUNJQSkgc3VwcG9ydAojIFBDTUNJQSBhbmQgY2FyZGJ1 cyBicmlkZ2Ugc3VwcG9ydAojZGV2aWNlCQljYmIJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRnZQoj ZGV2aWNlCQlwY2NhcmQJCSMgUEMgQ2FyZCAoMTYtYml0KSBidXMKI2RldmljZQkJY2FyZGJ1cwkJ IyBDYXJkQnVzICgzMi1iaXQpIGJ1cwoKIyBTZXJpYWwgKENPTSkgcG9ydHMKZGV2aWNlCQlzaW8J CSMgODI1MCwgMTZbNDVdNTAgYmFzZWQgc2VyaWFsIHBvcnRzCmRldmljZQkJdWFydAkJIyBHZW5l cmljIFVBUlQgZHJpdmVyCgojIFBhcmFsbGVsIHBvcnQKI2RldmljZQkJcHBjCiNkZXZpY2UJCXBw YnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKI2RldmljZQkJbHB0CQkjIFByaW50 ZXIKI2RldmljZQkJcGxpcAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbAojZGV2aWNlCQlwcGkJCSMg UGFyYWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlCiNkZXZpY2UJCXZwbwkJIyBSZXF1aXJlcyBz Y2J1cyBhbmQgZGEKCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFyYWxsZWwg UENJIGNhcmQgdGhhdCBpcwojIHN1cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJpdmVyLCB1 bmNvbW1lbnQgdGhlIGZvbGxvd2luZwojIGxpbmUgdG8gZW5hYmxlIGl0IChjb25uZWN0cyB0byBz aW8sIHVhcnQgYW5kL29yIHBwYyBkcml2ZXJzKToKI2RldmljZQkJcHVjCgojIFBDSSBFdGhlcm5l dCBOSUNzLgojZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBUdWxpcCcnKQpkZXZp Y2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIEdpZ2FiaXQgRXRoZXJuZXQgRmFtaWx5CmRldmljZQkJ aWdiCQkjIEludGVsIFBSTy8xMDAwIFBDSUUgU2VydmVyIEdpZ2FiaXQgRmFtaWx5CiNkZXZpY2UJ CWl4Z2IJCSMgSW50ZWwgUFJPLzEwR2JFIEV0aGVybmV0IENhcmQKI2RldmljZQkJbGUJCSMgQU1E IEFtNzkwMCBMQU5DRSBhbmQgQW03OUM5eHggUENuZXQKI2RldmljZQkJdHhwCQkjIDNDb20gM2NS OTkwIChgYFR5cGhvb24nJykKI2RldmljZQkJdngJCSMgM0NvbSAzYzU5MCwgM2M1OTUgKGBgVm9y dGV4JycpCgojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBjb21tb24gTUlJIGJ1cyBj b250cm9sbGVyIGNvZGUuCiMgTk9URTogQmUgc3VyZSB0byBrZWVwIHRoZSAnZGV2aWNlIG1paWJ1 cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyEKZGV2aWNlCQltaWlidXMJCSMgTUlJ IGJ1cyBzdXBwb3J0CiNkZXZpY2UJCWFnZQkJIyBBdHRhbnNpYy9BdGhlcm9zIEwxIEdpZ2FiaXQg RXRoZXJuZXQKI2RldmljZQkJYWxjCQkjIEF0aGVyb3MgQVI4MTMxL0FSODEzMiBFdGhlcm5ldAoj ZGV2aWNlCQlhbGUJCSMgQXRoZXJvcyBBUjgxMjEvQVI4MTEzL0FSODExNCBFdGhlcm5ldAojZGV2 aWNlCQliY2UJCSMgQnJvYWRjb20gQkNNNTcwNi9CQ001NzA4IEdpZ2FiaXQgRXRoZXJuZXQKI2Rl dmljZQkJYmZlCQkjIEJyb2FkY29tIEJDTTQ0MHggMTAvMTAwIEV0aGVybmV0CiNkZXZpY2UJCWJn ZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCWRjCQkjIERF Qy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxpa2VzCiNkZXZpY2UJCWV0CQkjIEFnZXJl IEVUMTMxMCAxMC8xMDAvR2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQlmeHAJCSMgSW50ZWwgRXRo ZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1NTgpCiNkZXZpY2UJCWptZQkJIyBKTWljcm9u IEpNQzI1MCBHaWdhYml0L0pNQzI2MCBGYXN0IEV0aGVybmV0CiNkZXZpY2UJCWxnZQkJIyBMZXZl bCAxIExYVDEwMDEgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQltc2sJCSMgTWFydmVsbC9TeXNL b25uZWN0IFl1a29uIElJIEdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJbmZlCQkjIG5WaWRpYSBu Rm9yY2UgTUNQIG9uLWJvYXJkIEV0aGVybmV0CiNkZXZpY2UJCW5nZQkJIyBOYXRTZW1pIERQODM4 MjAgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQludmUJCSMgblZpZGlhIG5Gb3JjZSBNQ1Agb24t Ym9hcmQgRXRoZXJuZXQgTmV0d29ya2luZwojZGV2aWNlCQlwY24JCSMgQU1EIEFtNzlDOTd4IFBD SSAxMC8xMDAgKHByZWNlZGVuY2Ugb3ZlciAnbGUnKQojZGV2aWNlCQlyZQkJIyBSZWFsVGVrIDgx MzlDKy84MTY5LzgxNjlTLzgxMTBTCiNkZXZpY2UJCXJsCQkjIFJlYWxUZWsgODEyOS84MTM5CiNk ZXZpY2UJCXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3RhcmZpcmUnJykKI2RldmljZQkJc2dl CQkjIFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFNpUzE5MC8xOTEKI2RldmljZQkJc2lzCQkj IFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFNpUyA5MDAvU2lTIDcwMTYKI2RldmljZQkJc2sJ CSMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBnaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJ CXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBUWCkKI2RldmljZQkJc3RnZQkJ IyBTdW5kYW5jZS9UYW1hcmFjayBUQzkwMjEgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQl0aQkJ IyBBbHRlb24gTmV0d29ya3MgVGlnb24gSS9JSSBnaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCXRs CQkjIFRleGFzIEluc3RydW1lbnRzIFRodW5kZXJMQU4KI2RldmljZQkJdHgJCSMgU01DIEV0aGVy UG93ZXIgSUkgKDgzYzE3MCBgYEVQSUMnJykKI2RldmljZQkJdmdlCQkjIFZJQSBWVDYxMnggZ2ln YWJpdCBFdGhlcm5ldAojZGV2aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJoaW5lIElJCiNkZXZpY2UJ CXZ0ZQkJIyBETSZQIFZvcnRleDg2IFJEQyBSNjA0MCBGYXN0IEV0aGVybmV0CiNkZXZpY2UJCXdi CQkjIFdpbmJvbmQgVzg5Qzg0MEYKI2RldmljZQkJeGwJCSMgM0NvbSAzYzkweCAoYGBCb29tZXJh bmcnJywgYGBDeWNsb25lJycpCgojIElTQSBFdGhlcm5ldCBOSUNzLiAgcGNjYXJkIE5JQ3MgaW5j bHVkZWQuCiNkZXZpY2UJCWNzCQkjIENyeXN0YWwgU2VtaWNvbmR1Y3RvciBDUzg5eDAgTklDCiMg J2RldmljZSBlZCcgcmVxdWlyZXMgJ2RldmljZSBtaWlidXMnCiNkZXZpY2UJCWVkCQkjIE5FWzEy XTAwMCwgU01DIFVsdHJhLCAzYzUwMywgRFM4MzkwIGNhcmRzCiNkZXZpY2UJCWV4CQkjIEludGVs IEV0aGVyRXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsKI2RldmljZQkJZXAJCSMgRXRoZXJsaW5r IElJSSBiYXNlZCBjYXJkcwojZGV2aWNlCQlmZQkJIyBGdWppdHN1IE1CODY5NnggYmFzZWQgY2Fy ZHMKI2RldmljZQkJaWUJCSMgRXRoZXJFeHByZXNzIDgvMTYsIDNDNTA3LCBTdGFyTEFOIDEwIGV0 Yy4KI2RldmljZQkJc24JCSMgU01DJ3MgOTAwMCBzZXJpZXMgb2YgRXRoZXJuZXQgY2hpcHMKI2Rl dmljZQkJeGUJCSMgWGlyY29tIHBjY2FyZCBFdGhlcm5ldAoKIyBXaXJlbGVzcyBOSUMgY2FyZHMK I2RldmljZQkJd2xhbgkJIyA4MDIuMTEgc3VwcG9ydAojZGV2aWNlCQl3bGFuX3dlcAkjIDgwMi4x MSBXRVAgc3VwcG9ydAojZGV2aWNlCQl3bGFuX2NjbXAJIyA4MDIuMTEgQ0NNUCBzdXBwb3J0CiNk ZXZpY2UJCXdsYW5fdGtpcAkjIDgwMi4xMSBUS0lQIHN1cHBvcnQKI2RldmljZQkJd2xhbl9hbXJy CSMgQU1SUiB0cmFuc21pdCByYXRlIGNvbnRyb2wgYWxnb3JpdGhtCiNkZXZpY2UJCXdsYW5fc2Nh bl9hcAkjIDgwMi4xMSBBUCBtb2RlIHNjYW5uaW5nCiNkZXZpY2UJCXdsYW5fc2Nhbl9zdGEJIyA4 MDIuMTEgU1RBIG1vZGUgc2Nhbm5pbmcKI2RldmljZQkJYW4JCSMgQWlyb25ldCA0NTAwLzQ4MDAg ODAyLjExIHdpcmVsZXNzIE5JQ3MuCiNkZXZpY2UJCWF0aAkJIyBBdGhlcm9zIHBjaS9jYXJkYnVz IE5JQydzCiNkZXZpY2UJCWF0aF9oYWwJCSMgQXRoZXJvcyBIQUwgKEhhcmR3YXJlIEFjY2VzcyBM YXllcikKI29wdGlvbnMJCUFIX1NVUFBPUlRfQVI1NDE2CSMgZW5hYmxlIEFSNTQxNiB0eC9yeCBk ZXNjcmlwdG9ycwojZGV2aWNlCQlhdGhfcmF0ZV9zYW1wbGUJIyBTYW1wbGVSYXRlIHR4IHJhdGUg Y29udHJvbCBmb3IgYXRoCiNkZXZpY2UJCWF3aQkJIyBCYXlTdGFjayA2NjAgYW5kIG90aGVycwoj ZGV2aWNlCQlyYWwJCSMgUmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwIHdpcmVsZXNzIE5JQ3MuCiNk ZXZpY2UJCXdpCQkjIFdhdmVMQU4vSW50ZXJzaWwvU3ltYm9sIDgwMi4xMSB3aXJlbGVzcyBOSUNz LgojZGV2aWNlCQl3bAkJIyBPbGRlciBub24gODAyLjExIFdhdmVsYW4gd2lyZWxlc3MgTklDLgoK IyBQc2V1ZG8gZGV2aWNlcy4KZGV2aWNlCQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNl CQlyYW5kb20JCSMgRW50cm9weSBkZXZpY2UKZGV2aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBw b3J0CmRldmljZQkJdmxhbgkJIyA4MDIuMVEgVkxBTiBzdXBwb3J0CmRldmljZQkJc2wJCSMgS2Vy bmVsIFNMSVAKZGV2aWNlCQlwcHAJCSMgS2VybmVsIFBQUApkZXZpY2UJCXR1bgkJIyBQYWNrZXQg dHVubmVsLgpkZXZpY2UJCXB0eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykKZGV2aWNlCQlt ZAkJIyBNZW1vcnkgImRpc2tzIgpkZXZpY2UJCWdpZgkJIyBJUHY2IGFuZCBJUHY0IHR1bm5lbGlu ZwpkZXZpY2UJCWZhaXRoCQkjIElQdjYtdG8tSVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pCmRl dmljZQkJZmlybXdhcmUJIyBmaXJtd2FyZSBhc3Npc3QgbW9kdWxlCgojIFRoZSBgYnBmJyBkZXZp Y2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4KIyBCZSBhd2FyZSBvZiB0aGUg YWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVuYWJsaW5nIHRoaXMhCiMgTm90ZSB0aGF0 ICdicGYnIGlzIHJlcXVpcmVkIGZvciBESENQLgpkZXZpY2UJCWJwZgkJIyBCZXJrZWxleSBwYWNr ZXQgZmlsdGVyCgojCm9wdGlvbnMJCUlOVkFSSUFOVFMKb3B0aW9ucwkJSU5WQVJJQU5UX1NVUFBP UlQKCiMKb3B0aW9ucwkJSVBGSVJFV0FMTAoKb3B0aW9ucwkJSVBGSVJFV0FMTF9ERUZBVUxUX1RP X0FDQ0VQVApvcHRpb25zCQlJUEZJUkVXQUxMX0ZPUldBUkQKb3B0aW9ucwkJSVBGSVJFV0FMTF9W RVJCT1NFCgojCmRldmljZQkJcGYJCSMKCiMKb3B0aW9ucwkJQUxUUQpvcHRpb25zCQlBTFRRX0NC USAgICAgICAgIyBDbGFzcyBCYXNlZCBRdWV1ZWluZwpvcHRpb25zCQlBTFRRX1JFRCAgICAgICAg IyBSYW5kb20gRWFybHkgRGV0ZWN0aW9uCm9wdGlvbnMJCUFMVFFfUklPICAgICAgICAjIFJFRCBJ bi9PdXQKb3B0aW9ucwkJQUxUUV9IRlNDICAgICAgICMgSGllcmFyY2hpY2FsIFBhY2tldCBTY2hl ZHVsZXIKb3B0aW9ucwkJQUxUUV9DRE5SICAgICAgICMgVHJhZmZpYyBjb25kaXRpb25lcgpvcHRp b25zCQlBTFRRX1BSSVEgICAgICAgIyBQcmlvcml0eSBRdWV1ZWluZwpvcHRpb25zCQlBTFRRX05P UENDICAgICAgIyBSZXF1aXJlZCBpZiB0aGUgVFNDIGlzIHVudXNhYmxlCgojIFVTQiBzdXBwb3J0 CiNkZXZpY2UJCXVoY2kJCSMgVUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UKI2RldmljZQkJb2hjaQkJ IyBPSENJIFBDSS0+VVNCIGludGVyZmFjZQojZGV2aWNlCQllaGNpCQkjIEVIQ0kgUENJLT5VU0Ig aW50ZXJmYWNlIChVU0IgMi4wKQojZGV2aWNlCQl1c2IJCSMgVVNCIEJ1cyAocmVxdWlyZWQpCiNk ZXZpY2UJCXVkYnAJCSMgVVNCIERvdWJsZSBCdWxrIFBpcGUgZGV2aWNlcwojZGV2aWNlCQl1Z2Vu CQkjIEdlbmVyaWMKI2RldmljZQkJdWhpZAkJIyAiSHVtYW4gSW50ZXJmYWNlIERldmljZXMiCiNk ZXZpY2UJCXVrYmQJCSMgS2V5Ym9hcmQKI2RldmljZQkJdWxwdAkJIyBQcmludGVyCiNkZXZpY2UJ CXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQojZGV2 aWNlCQl1bXMJCSMgTW91c2UKI2RldmljZQkJdXJpbwkJIyBEaWFtb25kIFJpbyA1MDAgTVAzIHBs YXllcgojZGV2aWNlCQl1c2Nhbm5lcgkjIFNjYW5uZXJzCiMgVVNCIFNlcmlhbCBkZXZpY2VzCiNk ZXZpY2UJCXVjb20JCSMgR2VuZXJpYyBjb20gdHR5cwojZGV2aWNlCQl1YXJrCQkjIFRlY2hub2xv Z2llcyBBUkszMTE2IGJhc2VkIHNlcmlhbCBhZGFwdGVycwojZGV2aWNlCQl1YnNhCQkjIEJlbGtp biBGNVUxMDMgYW5kIGNvbXBhdGlibGUgc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJCXVic2VyCQkj IEJXQ1QgY29uc29sZSBzZXJpYWwgYWRhcHRlcnMKI2RldmljZQkJdWZ0ZGkJCSMgRm9yIEZUREkg dXNiIHNlcmlhbCBhZGFwdGVycwojZGV2aWNlCQl1aXBhcQkJIyBTb21lIFdpbkNFIGJhc2VkIGRl dmljZXMKI2RldmljZQkJdXBsY29tCQkjIFByb2xpZmljIFBMLTIzMDMgc2VyaWFsIGFkYXB0ZXJz CiNkZXZpY2UJCXVzbGNvbQkJIyBTSSBMYWJzIENQMjEwMS9DUDIxMDIgc2VyaWFsIGFkYXB0ZXJz CiNkZXZpY2UJCXV2aXNvcgkJIyBWaXNvciBhbmQgUGFsbSBkZXZpY2VzCiNkZXZpY2UJCXV2c2Nv bQkJIyBVU0Igc2VyaWFsIHN1cHBvcnQgZm9yIERESSBwb2NrZXQncyBQSFMKIyBVU0IgRXRoZXJu ZXQsIHJlcXVpcmVzIG1paWJ1cwojZGV2aWNlCQlhdWUJCSMgQURNdGVrIFVTQiBFdGhlcm5ldAoj ZGV2aWNlCQlheGUJCSMgQVNJWCBFbGVjdHJvbmljcyBVU0IgRXRoZXJuZXQKI2RldmljZQkJY2Rj ZQkJIyBHZW5lcmljIFVTQiBvdmVyIEV0aGVybmV0CiNkZXZpY2UJCWN1ZQkJIyBDQVRDIFVTQiBF dGhlcm5ldAojZGV2aWNlCQlrdWUJCSMgS2F3YXNha2kgTFNJIFVTQiBFdGhlcm5ldAojZGV2aWNl CQlydWUJCSMgUmVhbFRlayBSVEw4MTUwIFVTQiBFdGhlcm5ldAojIFVTQiBXaXJlbGVzcwojZGV2 aWNlCQlydW0JCSMgUmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAxVVNCIHdpcmVsZXNzIE5JQ3MKI2Rl dmljZQkJdXJhbAkJIyBSYWxpbmsgVGVjaG5vbG9neSBSVDI1MDBVU0Igd2lyZWxlc3MgTklDcwoK IyBGaXJlV2lyZSBzdXBwb3J0CiNkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdpcmUgYnVzIGNvZGUK I2RldmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2lyZSAoUmVxdWlyZXMgc2NidXMgYW5kIGRh KQojZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJlV2lyZSAobm9uLXN0YW5kYXJkISkK I2RldmljZQkJZndpcAkJIyBJUCBvdmVyIEZpcmVXaXJlIChSRkMgMjczNCwzMTQ2KQojZGV2aWNl CQlkY29ucwkJIyBEdW1iIGNvbnNvbGUgZHJpdmVyCiNkZXZpY2UJCWRjb25zX2Nyb20JIyBDb25m aWd1cmF0aW9uIFJPTSBmb3IgZGNvbnMK --bcaec51f8e8bfcd05f04ac2c4177 Content-Type: text/x-patch; charset=US-ASCII; name="0001-inlinize-m_freem.patch" Content-Disposition: attachment; filename="0001-inlinize-m_freem.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs73885t1 RnJvbSA1MjIxNTE5ZmM3ZDRjMzFiNmMxZWEyYzc1ODFiZDk5OGI3NTA1ZTY1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcm5hdWQgTGFjb21iZSA8bGFjb21iYXJAZ21haWwuY29tPgpE YXRlOiBUdWUsIDMwIEF1ZyAyMDExIDIxOjU1OjQ3IC0wNDAwClN1YmplY3Q6IFtQQVRDSCAxLzRd IGlubGluaXplIG1fZnJlZW0oKQoKLS0tCiBzeXMva2Vybi91aXBjX21idWYuYyB8ICAgMTIgLS0t LS0tLS0tLS0tCiBzeXMvc3lzL21idWYuaCAgICAgICB8ICAgMTQgKysrKysrKysrKysrKy0KIDIg ZmlsZXMgY2hhbmdlZCwgMTMgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRpb25zKC0pCgpkaWZmIC0t Z2l0IGEvc3lzL2tlcm4vdWlwY19tYnVmLmMgYi9zeXMva2Vybi91aXBjX21idWYuYwppbmRleCBm ODIzZTI2Li45ZjkyODhmIDEwMDY0NAotLS0gYS9zeXMva2Vybi91aXBjX21idWYuYworKysgYi9z eXMva2Vybi91aXBjX21idWYuYwpAQCAtMTUxLDE4ICsxNTEsNiBAQCBtX2dldG0yKHN0cnVjdCBt YnVmICptLCBpbnQgbGVuLCBpbnQgaG93LCBzaG9ydCB0eXBlLCBpbnQgZmxhZ3MpCiAJcmV0dXJu IChtKTsKIH0KIAotLyoKLSAqIEZyZWUgYW4gZW50aXJlIGNoYWluIG9mIG1idWZzIGFuZCBhc3Nv Y2lhdGVkIGV4dGVybmFsIGJ1ZmZlcnMsIGlmCi0gKiBhcHBsaWNhYmxlLgotICovCi12b2lkCi1t X2ZyZWVtKHN0cnVjdCBtYnVmICptYikKLXsKLQotCXdoaWxlIChtYiAhPSBOVUxMKQotCQltYiA9 IG1fZnJlZShtYik7Ci19Ci0KIC8qLQogICogQ29uZmlndXJlIGEgcHJvdmlkZWQgbWJ1ZiB0byBy ZWZlciB0byB0aGUgcHJvdmlkZWQgZXh0ZXJuYWwgc3RvcmFnZQogICogYnVmZmVyIGFuZCBzZXR1 cCBhIHJlZmVyZW5jZSBjb3VudCBmb3Igc2FpZCBidWZmZXIuICBJZiB0aGUgc2V0dGluZwpkaWZm IC0tZ2l0IGEvc3lzL3N5cy9tYnVmLmggYi9zeXMvc3lzL21idWYuaAppbmRleCA4NTI5Y2NhLi5m M2Y5OGIwIDEwMDY0NAotLS0gYS9zeXMvc3lzL21idWYuaAorKysgYi9zeXMvc3lzL21idWYuaApA QCAtMzU4LDYgKzM1OCw3IEBAIHN0YXRpYyBfX2lubGluZSBzdHJ1Y3QgbWJ1ZgkqbV9nZXRqY2wo aW50IGhvdywgc2hvcnQgdHlwZSwgaW50IGZsYWdzLAogCQkJCSAgICBpbnQgc2l6ZSk7CiBzdGF0 aWMgX19pbmxpbmUgc3RydWN0IG1idWYJKm1fZ2V0Y2xyKGludCBob3csIHNob3J0IHR5cGUpOwkv KiBYWFggKi8KIHN0YXRpYyBfX2lubGluZSBzdHJ1Y3QgbWJ1ZgkqbV9mcmVlKHN0cnVjdCBtYnVm ICptKTsKK3N0YXRpYyBfX2lubGluZSB2b2lkCQltX2ZyZWVtKHN0cnVjdCBtYnVmICptKTsKIHN0 YXRpYyBfX2lubGluZSB2b2lkCQkgbV9jbGdldChzdHJ1Y3QgbWJ1ZiAqbSwgaW50IGhvdyk7CiBz dGF0aWMgX19pbmxpbmUgdm9pZAkJKm1fY2xqZ2V0KHN0cnVjdCBtYnVmICptLCBpbnQgaG93LCBp bnQgc2l6ZSk7CiBzdGF0aWMgX19pbmxpbmUgdm9pZAkJIG1fY2h0eXBlKHN0cnVjdCBtYnVmICpt LCBzaG9ydCBuZXdfdHlwZSk7CkBAIC01MjAsNiArNTIxLDE4IEBAIG1fZnJlZShzdHJ1Y3QgbWJ1 ZiAqbSkKIAlyZXR1cm4gKG4pOwogfQogCisvKgorICogRnJlZSBhbiBlbnRpcmUgY2hhaW4gb2Yg bWJ1ZnMgYW5kIGFzc29jaWF0ZWQgZXh0ZXJuYWwgYnVmZmVycywgaWYKKyAqIGFwcGxpY2FibGUu CisgKi8KK3N0YXRpYyBfX2lubGluZSB2b2lkCittX2ZyZWVtKHN0cnVjdCBtYnVmICptKQorewor CisJd2hpbGUgKG0gIT0gTlVMTCkKKwkJbSA9IG1fZnJlZShtKTsKK30KKwogc3RhdGljIF9faW5s aW5lIHZvaWQKIG1fY2xnZXQoc3RydWN0IG1idWYgKm0sIGludCBob3cpCiB7CkBAIC03NjcsNyAr NzgwLDYgQEAgc3RydWN0IG1idWYJKm1fZHVwKHN0cnVjdCBtYnVmICosIGludCk7CiBpbnQJCSBt X2R1cF9wa3RoZHIoc3RydWN0IG1idWYgKiwgc3RydWN0IG1idWYgKiwgaW50KTsKIHVfaW50CQkg bV9maXhoZHIoc3RydWN0IG1idWYgKik7CiBzdHJ1Y3QgbWJ1ZgkqbV9mcmFnbWVudChzdHJ1Y3Qg bWJ1ZiAqLCBpbnQsIGludCk7Ci12b2lkCQkgbV9mcmVlbShzdHJ1Y3QgbWJ1ZiAqKTsKIHN0cnVj dCBtYnVmCSptX2dldG0yKHN0cnVjdCBtYnVmICosIGludCwgaW50LCBzaG9ydCwgaW50KTsKIHN0 cnVjdCBtYnVmCSptX2dldHB0cihzdHJ1Y3QgbWJ1ZiAqLCBpbnQsIGludCAqKTsKIHVfaW50CQkg bV9sZW5ndGgoc3RydWN0IG1idWYgKiwgc3RydWN0IG1idWYgKiopOwotLSAKMS43LjYuMTUzLmc3 ODQzMgoK --bcaec51f8e8bfcd05f04ac2c4177 Content-Type: text/x-patch; charset=US-ASCII; name="0002-mbuf-use-after-free-marking.patch" Content-Disposition: attachment; filename="0002-mbuf-use-after-free-marking.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs738bs12 RnJvbSAwZjJhZGE3YTg1YzllNjY1YmUyM2Y0ODAxZTE3MjJlNzc2NDkyZmRjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcm5hdWQgTGFjb21iZSA8bGFjb21iYXJAZ21haWwuY29tPgpE YXRlOiBXZWQsIDMxIEF1ZyAyMDExIDEyOjE2OjU4IC0wNDAwClN1YmplY3Q6IFtQQVRDSCAyLzRd IG1idWYgdXNlLWFmdGVyLWZyZWUgbWFya2luZwoKLS0tCiBzeXMva2Vybi91aXBjX21idWYuYyB8 ICAgIDQgKystLQogc3lzL3N5cy9tYnVmLmggICAgICAgfCAgIDM3ICsrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrLS0tLS0KIHN5cy92bS91bWFfZGJnLmMgICAgIHwgICAgNiArKysrLS0K IDMgZmlsZXMgY2hhbmdlZCwgMzggaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkKCmRpZmYg LS1naXQgYS9zeXMva2Vybi91aXBjX21idWYuYyBiL3N5cy9rZXJuL3VpcGNfbWJ1Zi5jCmluZGV4 IDlmOTI4OGYuLjliOTJmYjAgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3VpcGNfbWJ1Zi5jCisrKyBi L3N5cy9rZXJuL3VpcGNfbWJ1Zi5jCkBAIC0xOTcsNyArMTk3LDcgQEAgbV9leHRhZGQoc3RydWN0 IG1idWYgKm1iLCBjYWRkcl90IGJ1ZiwgdV9pbnQgc2l6ZSwKICAqIHN0b3JhZ2UgYXR0YWNoZWQg dG8gdGhlbSBpZiB0aGUgcmVmZXJlbmNlIGNvdW50IGhpdHMgMS4KICAqLwogdm9pZAotbWJfZnJl ZV9leHQoc3RydWN0IG1idWYgKm0pCittYl9mcmVlX2V4dChzdHJ1Y3QgbWJ1ZiAqbSwgdm9pZCAq YXJnKQogewogCWludCBza2lwbWJ1ZjsKIAkKQEAgLTI2NCw3ICsyNjQsNyBAQCBtYl9mcmVlX2V4 dChzdHJ1Y3QgbWJ1ZiAqbSkKIAltLT5tX2V4dC5leHRfc2l6ZSA9IDA7CiAJbS0+bV9leHQuZXh0 X3R5cGUgPSAwOwogCW0tPm1fZmxhZ3MgJj0gfk1fRVhUOwotCXVtYV96ZnJlZSh6b25lX21idWYs IG0pOworCXVtYV96ZnJlZV9hcmcoem9uZV9tYnVmLCBtLCBhcmcpOwogfQogCiAvKgpkaWZmIC0t Z2l0IGEvc3lzL3N5cy9tYnVmLmggYi9zeXMvc3lzL21idWYuaAppbmRleCBmM2Y5OGIwLi4xOWVh NWU4IDEwMDY0NAotLS0gYS9zeXMvc3lzL21idWYuaAorKysgYi9zeXMvc3lzL21idWYuaApAQCAt MzYyLDcgKzM2Miw3IEBAIHN0YXRpYyBfX2lubGluZSB2b2lkCQltX2ZyZWVtKHN0cnVjdCBtYnVm ICptKTsKIHN0YXRpYyBfX2lubGluZSB2b2lkCQkgbV9jbGdldChzdHJ1Y3QgbWJ1ZiAqbSwgaW50 IGhvdyk7CiBzdGF0aWMgX19pbmxpbmUgdm9pZAkJKm1fY2xqZ2V0KHN0cnVjdCBtYnVmICptLCBp bnQgaG93LCBpbnQgc2l6ZSk7CiBzdGF0aWMgX19pbmxpbmUgdm9pZAkJIG1fY2h0eXBlKHN0cnVj dCBtYnVmICptLCBzaG9ydCBuZXdfdHlwZSk7Ci12b2lkCQkJCSBtYl9mcmVlX2V4dChzdHJ1Y3Qg bWJ1ZiAqKTsKK3ZvaWQJCQkJIG1iX2ZyZWVfZXh0KHN0cnVjdCBtYnVmICosIHZvaWQgKik7CiBz dGF0aWMgX19pbmxpbmUgc3RydWN0IG1idWYJKm1fbGFzdChzdHJ1Y3QgbWJ1ZiAqbSk7CiAKIHN0 YXRpYyBfX2lubGluZSBpbnQKQEAgLTUwNiwyMSArNTA2LDM5IEBAIG1fZnJlZV9mYXN0KHN0cnVj dCBtYnVmICptKQogewogCUtBU1NFUlQoU0xJU1RfRU1QVFkoJm0tPm1fcGt0aGRyLnRhZ3MpLCAo ImRvaW5nIGZhc3QgZnJlZSBvZiBtYnVmIHdpdGggdGFncyIpKTsKIAorI2lmZGVmIElOVkFSSUFO VFMKKwl1bWFfemZyZWVfYXJnKHpvbmVfbWJ1ZiwgbSwgKHZvaWQgKikoMHhmMDBmMDAwMCB8IE1C X05PVEFHUykpOworI2Vsc2UKIAl1bWFfemZyZWVfYXJnKHpvbmVfbWJ1ZiwgbSwgKHZvaWQgKilN Ql9OT1RBR1MpOworI2VuZGlmCiB9CiAKIHN0YXRpYyBfX2lubGluZSBzdHJ1Y3QgbWJ1ZiAqCi1t X2ZyZWUoc3RydWN0IG1idWYgKm0pCittX2ZyZWVfYXJnKHN0cnVjdCBtYnVmICptLCB2b2lkICph cmcpCiB7CiAJc3RydWN0IG1idWYgKm4gPSBtLT5tX25leHQ7CiAKIAlpZiAobS0+bV9mbGFncyAm IE1fRVhUKQotCQltYl9mcmVlX2V4dChtKTsKKwkJbWJfZnJlZV9leHQobSwgYXJnKTsKIAllbHNl IGlmICgobS0+bV9mbGFncyAmIE1fTk9GUkVFKSA9PSAwKQotCQl1bWFfemZyZWUoem9uZV9tYnVm LCBtKTsKKwkJdW1hX3pmcmVlX2FyZyh6b25lX21idWYsIG0sIGFyZyk7CisKIAlyZXR1cm4gKG4p OwogfQogCitzdGF0aWMgX19pbmxpbmUgc3RydWN0IG1idWYgKgorbV9mcmVlKHN0cnVjdCBtYnVm ICptKQoreworCisJcmV0dXJuIG1fZnJlZV9hcmcobSwgMCk7Cit9CisKKyNpZmRlZiBJTlZBUklB TlRTCisjZGVmaW5lIF9USElTX0lQXyAgKHsgX19sYWJlbF9fIF9faGVyZTsgX19oZXJlOiAodW5z aWduZWQgbG9uZykmJl9faGVyZTsgfSkKKyNlbHNlCisjZGVmaW5lIF9USElTX0lQXyAwCisjZW5k aWYKKwogLyoKICAqIEZyZWUgYW4gZW50aXJlIGNoYWluIG9mIG1idWZzIGFuZCBhc3NvY2lhdGVk IGV4dGVybmFsIGJ1ZmZlcnMsIGlmCiAgKiBhcHBsaWNhYmxlLgpAQCAtNTI4LDkgKzU0NiwxOCBA QCBtX2ZyZWUoc3RydWN0IG1idWYgKm0pCiBzdGF0aWMgX19pbmxpbmUgdm9pZAogbV9mcmVlbShz dHJ1Y3QgbWJ1ZiAqbSkKIHsKKwl1bnNpZ25lZCBsb25nIHRoaXNfaXAgPSAoX1RISVNfSVBfICYg MHgwMGZmZmYwMCkgfCAoX1RISVNfSVBfICYgMHhmZikgPDwgMjQ7CisKKwl3aGlsZSAobSAhPSBO VUxMKQorCQltID0gbV9mcmVlX2FyZyhtLCAodm9pZCAqKXRoaXNfaXApOworfQorCitzdGF0aWMg X19pbmxpbmUgdm9pZAorbV9mcmVlbV9hcmcoc3RydWN0IG1idWYgKm0sIHZvaWQgKmFyZykKK3sK IAogCXdoaWxlIChtICE9IE5VTEwpCi0JCW0gPSBtX2ZyZWUobSk7CisJCW0gPSBtX2ZyZWVfYXJn KG0sIGFyZyk7CiB9CiAKIHN0YXRpYyBfX2lubGluZSB2b2lkCmRpZmYgLS1naXQgYS9zeXMvdm0v dW1hX2RiZy5jIGIvc3lzL3ZtL3VtYV9kYmcuYwppbmRleCA5MDc1YmY5Li42NjliMWY1IDEwMDY0 NAotLS0gYS9zeXMvdm0vdW1hX2RiZy5jCisrKyBiL3N5cy92bS91bWFfZGJnLmMKQEAgLTYxLDYg KzYxLDcgQEAgc3RhdGljIGNvbnN0IHVfaW50MzJfdCB1bWFfanVuayA9IDB4ZGVhZGMwZGU7CiBp bnQKIHRyYXNoX2N0b3Iodm9pZCAqbWVtLCBpbnQgc2l6ZSwgdm9pZCAqYXJnLCBpbnQgZmxhZ3Mp CiB7CisjaWYgMAogCWludCBjbnQ7CiAJdV9pbnQzMl90ICpwOwogCkBAIC03Miw2ICs3Myw3IEBA IHRyYXNoX2N0b3Iodm9pZCAqbWVtLCBpbnQgc2l6ZSwgdm9pZCAqYXJnLCBpbnQgZmxhZ3MpCiAJ CQkgICAgbWVtLCBzaXplLCAqcCwgcCk7CiAJCQlyZXR1cm4gKDApOwogCQl9CisjZW5kaWYKIAly ZXR1cm4gKDApOwogfQogCkBAIC05MCw3ICs5Miw3IEBAIHRyYXNoX2R0b3Iodm9pZCAqbWVtLCBp bnQgc2l6ZSwgdm9pZCAqYXJnKQogCWNudCA9IHNpemUgLyBzaXplb2YodW1hX2p1bmspOwogCiAJ Zm9yIChwID0gbWVtOyBjbnQgPiAwOyBjbnQtLSwgcCsrKQotCQkqcCA9IHVtYV9qdW5rOworCQkq cCA9ICh1bnNpZ25lZCBsb25nKWFyZzsKIH0KIAogLyoKQEAgLTEwMiw3ICsxMDQsNyBAQCB0cmFz aF9kdG9yKHZvaWQgKm1lbSwgaW50IHNpemUsIHZvaWQgKmFyZykKIGludAogdHJhc2hfaW5pdCh2 b2lkICptZW0sIGludCBzaXplLCBpbnQgZmxhZ3MpCiB7Ci0JdHJhc2hfZHRvcihtZW0sIHNpemUs IE5VTEwpOworCXRyYXNoX2R0b3IobWVtLCBzaXplLCAodm9pZCAqKXVtYV9qdW5rKTsKIAlyZXR1 cm4gKDApOwogfQogCi0tIAoxLjcuNi4xNTMuZzc4NDMyCgo= --bcaec51f8e8bfcd05f04ac2c4177 Content-Type: text/x-patch; charset=US-ASCII; name="0003-64bits-mbuf-flags.patch" Content-Disposition: attachment; filename="0003-64bits-mbuf-flags.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs738e613 RnJvbSBjNThlODcyOGU0ZGQ3NWI1NDJmYTg3MGJmYzc0MjBhM2M1NTVkMmNhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcm5hdWQgTGFjb21iZSA8bGFjb21iYXJAZ21haWwuY29tPgpE YXRlOiBXZWQsIDMxIEF1ZyAyMDExIDIyOjA4OjA0IC0wNDAwClN1YmplY3Q6IFtQQVRDSCAzLzRd IDY0Yml0cyBtYnVmIGZsYWdzCgotLS0KIHN5cy9rZXJuL3VpcGNfbWJ1Zi5jIHwgICAgNiArKysr Ky0KIHN5cy9zeXMvbWJ1Zi5oICAgICAgIHwgICA0NiArKysrKysrKysrKysrKysrKysrKysrKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAyIGZpbGVzIGNoYW5nZWQsIDI4IGluc2VydGlvbnMoKyks IDI0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3VpcGNfbWJ1Zi5jIGIvc3lz L2tlcm4vdWlwY19tYnVmLmMKaW5kZXggOWI5MmZiMC4uMjRmOWVjOCAxMDA2NDQKLS0tIGEvc3lz L2tlcm4vdWlwY19tYnVmLmMKKysrIGIvc3lzL2tlcm4vdWlwY19tYnVmLmMKQEAgLTUwLDYgKzUw LDggQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8c2VjdXJpdHkvbWFjL21h Y19mcmFtZXdvcmsuaD4KIAorI2luY2x1ZGUgPG1hY2hpbmUvX2ludHR5cGVzLmg+CisKIGludAlt YXhfbGlua2hkcjsKIGludAltYXhfcHJvdG9oZHI7CiBpbnQJbWF4X2hkcjsKQEAgLTE0MDUsMTAg KzE0MDcsMTIgQEAgbV9wcmludChjb25zdCBzdHJ1Y3QgbWJ1ZiAqbSwgaW50IG1heGxlbikKIAkJ cGRhdGEgPSBtMi0+bV9sZW47CiAJCWlmIChtYXhsZW4gIT0gLTEgJiYgcGRhdGEgPiBtYXhsZW4p CiAJCQlwZGF0YSA9IG1heGxlbjsKKyNpZiAwCiAJCXByaW50ZigibWJ1ZjogJXAgbGVuOiAlZCwg bmV4dDogJXAsICViJXMiLCBtMiwgbTItPm1fbGVuLAogCQkgICAgbTItPm1fbmV4dCwgbTItPm1f ZmxhZ3MsICJcMjBcMjBmcmVlbGlzdFwxN3NraXBmdyIKIAkJICAgICJcMTFwcm90bzVcMTBwcm90 bzRcN3Byb3RvM1w2cHJvdG8yXDVwcm90bzFcNHJkb25seSIKIAkJICAgICJcM2VvclwycGt0aGRy XDFleHQiLCBwZGF0YSA/ICIiIDogIlxuIik7CisjZW5kaWYKIAkJaWYgKHBkYXRhKQogCQkJcHJp bnRmKCIsICUqRFxuIiwgcGRhdGEsICh1X2NoYXIgKiltMi0+bV9kYXRhLCAiLSIpOwogCQlpZiAo bGVuICE9IC0xKQpAQCAtMTgzNSw3ICsxODM5LDcgQEAgbV91bnNoYXJlKHN0cnVjdCBtYnVmICpt MCwgaW50IGhvdykKIAkJICogaXQgYW55d2F5LCB3ZSB0cnkgdG8gcmVkdWNlIHRoZSBudW1iZXIg b2YgbWJ1ZnMgYW5kCiAJCSAqIGNsdXN0ZXJzIHNvIHRoYXQgZnV0dXJlIHdvcmsgaXMgZWFzaWVy KS4KIAkJICovCi0JCUtBU1NFUlQobS0+bV9mbGFncyAmIE1fRVhULCAoIm1fZmxhZ3MgMHgleCIs IG0tPm1fZmxhZ3MpKTsKKwkJS0FTU0VSVChtLT5tX2ZsYWdzICYgTV9FWFQsICgibV9mbGFncyAw eCUiIFBSSXg2NCwgbS0+bV9mbGFncykpOwogCQkvKiBOQjogd2Ugb25seSBjb2FsZXNjZSBpbnRv IGEgY2x1c3RlciBvciBsYXJnZXIgKi8KIAkJaWYgKG1wcmV2ICE9IE5VTEwgJiYgKG1wcmV2LT5t X2ZsYWdzICYgTV9FWFQpICYmCiAJCSAgICBtLT5tX2xlbiA8PSBNX1RSQUlMSU5HU1BBQ0UobXBy ZXYpKSB7CmRpZmYgLS1naXQgYS9zeXMvc3lzL21idWYuaCBiL3N5cy9zeXMvbWJ1Zi5oCmluZGV4 IDE5ZWE1ZTguLjhhZDA5YmIgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvbWJ1Zi5oCisrKyBiL3N5cy9z eXMvbWJ1Zi5oCkBAIC05MSw3ICs5MSw3IEBAIHN0cnVjdCBtX2hkciB7CiAJc3RydWN0IG1idWYJ Km1oX25leHRwa3Q7CS8qIG5leHQgY2hhaW4gaW4gcXVldWUvcmVjb3JkICovCiAJY2FkZHJfdAkJ IG1oX2RhdGE7CS8qIGxvY2F0aW9uIG9mIGRhdGEgKi8KIAlpbnQJCSBtaF9sZW47CS8qIGFtb3Vu dCBvZiBkYXRhIGluIHRoaXMgbWJ1ZiAqLwotCWludAkJIG1oX2ZsYWdzOwkvKiBmbGFnczsgc2Vl IGJlbG93ICovCisJdWludDY0X3QJIG1oX2ZsYWdzOwkvKiBmbGFnczsgc2VlIGJlbG93ICovCiAJ c2hvcnQJCSBtaF90eXBlOwkvKiB0eXBlIG9mIGRhdGEgaW4gdGhpcyBtYnVmICovCiAJdWludDhf dCAgICAgICAgICBwYWRbTV9IRFJfUEFEXTsvKiB3b3JkIGFsaWduICAgICAgICAgICAgICAgICAg Ki8KIH07CkBAIC0xNjksMjggKzE2OSwyOCBAQCBzdHJ1Y3QgbWJ1ZiB7CiAvKgogICogbWJ1ZiBm bGFncy4KICAqLwotI2RlZmluZQlNX0VYVAkJMHgwMDAwMDAwMSAvKiBoYXMgYXNzb2NpYXRlZCBl eHRlcm5hbCBzdG9yYWdlICovCi0jZGVmaW5lCU1fUEtUSERSCTB4MDAwMDAwMDIgLyogc3RhcnQg b2YgcmVjb3JkICovCi0jZGVmaW5lCU1fRU9SCQkweDAwMDAwMDA0IC8qIGVuZCBvZiByZWNvcmQg Ki8KLSNkZWZpbmUJTV9SRE9OTFkJMHgwMDAwMDAwOCAvKiBhc3NvY2lhdGVkIGRhdGEgaXMgbWFy a2VkIHJlYWQtb25seSAqLwotI2RlZmluZQlNX1BST1RPMQkweDAwMDAwMDEwIC8qIHByb3RvY29s LXNwZWNpZmljICovCi0jZGVmaW5lCU1fUFJPVE8yCTB4MDAwMDAwMjAgLyogcHJvdG9jb2wtc3Bl Y2lmaWMgKi8KLSNkZWZpbmUJTV9QUk9UTzMJMHgwMDAwMDA0MCAvKiBwcm90b2NvbC1zcGVjaWZp YyAqLwotI2RlZmluZQlNX1BST1RPNAkweDAwMDAwMDgwIC8qIHByb3RvY29sLXNwZWNpZmljICov Ci0jZGVmaW5lCU1fUFJPVE81CTB4MDAwMDAxMDAgLyogcHJvdG9jb2wtc3BlY2lmaWMgKi8KLSNk ZWZpbmUJTV9CQ0FTVAkJMHgwMDAwMDIwMCAvKiBzZW5kL3JlY2VpdmVkIGFzIGxpbmstbGV2ZWwg YnJvYWRjYXN0ICovCi0jZGVmaW5lCU1fTUNBU1QJCTB4MDAwMDA0MDAgLyogc2VuZC9yZWNlaXZl ZCBhcyBsaW5rLWxldmVsIG11bHRpY2FzdCAqLwotI2RlZmluZQlNX0ZSQUcJCTB4MDAwMDA4MDAg LyogcGFja2V0IGlzIGEgZnJhZ21lbnQgb2YgYSBsYXJnZXIgcGFja2V0ICovCi0jZGVmaW5lCU1f RklSU1RGUkFHCTB4MDAwMDEwMDAgLyogcGFja2V0IGlzIGZpcnN0IGZyYWdtZW50ICovCi0jZGVm aW5lCU1fTEFTVEZSQUcJMHgwMDAwMjAwMCAvKiBwYWNrZXQgaXMgbGFzdCBmcmFnbWVudCAqLwot I2RlZmluZQlNX1NLSVBfRklSRVdBTEwJMHgwMDAwNDAwMCAvKiBza2lwIGZpcmV3YWxsIHByb2Nl c3NpbmcgKi8KLSNkZWZpbmUJTV9GUkVFTElTVAkweDAwMDA4MDAwIC8qIG1idWYgaXMgb24gdGhl IGZyZWUgbGlzdCAqLwotI2RlZmluZQlNX1ZMQU5UQUcJMHgwMDAxMDAwMCAvKiBldGhlcl92dGFn IGlzIHZhbGlkICovCi0jZGVmaW5lCU1fUFJPTUlTQwkweDAwMDIwMDAwIC8qIHBhY2tldCB3YXMg bm90IGZvciB1cyAqLwotI2RlZmluZQlNX05PRlJFRQkweDAwMDQwMDAwIC8qIGRvIG5vdCBmcmVl IG1idWYsIGVtYmVkZGVkIGluIGNsdXN0ZXIgKi8KLSNkZWZpbmUJTV9QUk9UTzYJMHgwMDA4MDAw MCAvKiBwcm90b2NvbC1zcGVjaWZpYyAqLwotI2RlZmluZQlNX1BST1RPNwkweDAwMTAwMDAwIC8q IHByb3RvY29sLXNwZWNpZmljICovCi0jZGVmaW5lCU1fUFJPVE84CTB4MDAyMDAwMDAgLyogcHJv dG9jb2wtc3BlY2lmaWMgKi8KKyNkZWZpbmUJTV9FWFQJCTB4MDAwMDAwMDFVTEwgLyogaGFzIGFz c29jaWF0ZWQgZXh0ZXJuYWwgc3RvcmFnZSAqLworI2RlZmluZQlNX1BLVEhEUgkweDAwMDAwMDAy VUxMIC8qIHN0YXJ0IG9mIHJlY29yZCAqLworI2RlZmluZQlNX0VPUgkJMHgwMDAwMDAwNFVMTCAv KiBlbmQgb2YgcmVjb3JkICovCisjZGVmaW5lCU1fUkRPTkxZCTB4MDAwMDAwMDhVTEwgLyogYXNz b2NpYXRlZCBkYXRhIGlzIG1hcmtlZCByZWFkLW9ubHkgKi8KKyNkZWZpbmUJTV9QUk9UTzEJMHgw MDAwMDAxMFVMTCAvKiBwcm90b2NvbC1zcGVjaWZpYyAqLworI2RlZmluZQlNX1BST1RPMgkweDAw MDAwMDIwVUxMIC8qIHByb3RvY29sLXNwZWNpZmljICovCisjZGVmaW5lCU1fUFJPVE8zCTB4MDAw MDAwNDBVTEwgLyogcHJvdG9jb2wtc3BlY2lmaWMgKi8KKyNkZWZpbmUJTV9QUk9UTzQJMHgwMDAw MDA4MFVMTCAvKiBwcm90b2NvbC1zcGVjaWZpYyAqLworI2RlZmluZQlNX1BST1RPNQkweDAwMDAw MTAwVUxMIC8qIHByb3RvY29sLXNwZWNpZmljICovCisjZGVmaW5lCU1fQkNBU1QJCTB4MDAwMDAy MDBVTEwgLyogc2VuZC9yZWNlaXZlZCBhcyBsaW5rLWxldmVsIGJyb2FkY2FzdCAqLworI2RlZmlu ZQlNX01DQVNUCQkweDAwMDAwNDAwVUxMIC8qIHNlbmQvcmVjZWl2ZWQgYXMgbGluay1sZXZlbCBt dWx0aWNhc3QgKi8KKyNkZWZpbmUJTV9GUkFHCQkweDAwMDAwODAwVUxMIC8qIHBhY2tldCBpcyBh IGZyYWdtZW50IG9mIGEgbGFyZ2VyIHBhY2tldCAqLworI2RlZmluZQlNX0ZJUlNURlJBRwkweDAw MDAxMDAwVUxMIC8qIHBhY2tldCBpcyBmaXJzdCBmcmFnbWVudCAqLworI2RlZmluZQlNX0xBU1RG UkFHCTB4MDAwMDIwMDBVTEwgLyogcGFja2V0IGlzIGxhc3QgZnJhZ21lbnQgKi8KKyNkZWZpbmUJ TV9TS0lQX0ZJUkVXQUxMCTB4MDAwMDQwMDBVTEwgLyogc2tpcCBmaXJld2FsbCBwcm9jZXNzaW5n ICovCisjZGVmaW5lCU1fRlJFRUxJU1QJMHgwMDAwODAwMFVMTCAvKiBtYnVmIGlzIG9uIHRoZSBm cmVlIGxpc3QgKi8KKyNkZWZpbmUJTV9WTEFOVEFHCTB4MDAwMTAwMDBVTEwgLyogZXRoZXJfdnRh ZyBpcyB2YWxpZCAqLworI2RlZmluZQlNX1BST01JU0MJMHgwMDAyMDAwMFVMTCAvKiBwYWNrZXQg d2FzIG5vdCBmb3IgdXMgKi8KKyNkZWZpbmUJTV9OT0ZSRUUJMHgwMDA0MDAwMFVMTCAvKiBkbyBu b3QgZnJlZSBtYnVmLCBlbWJlZGRlZCBpbiBjbHVzdGVyICovCisjZGVmaW5lCU1fUFJPVE82CTB4 MDAwODAwMDBVTEwgLyogcHJvdG9jb2wtc3BlY2lmaWMgKi8KKyNkZWZpbmUJTV9QUk9UTzcJMHgw MDEwMDAwMFVMTCAvKiBwcm90b2NvbC1zcGVjaWZpYyAqLworI2RlZmluZQlNX1BST1RPOAkweDAw MjAwMDAwVUxMIC8qIHByb3RvY29sLXNwZWNpZmljICovCiAvKgogICogRm9yIFJFTEVOR197Niw3 fSBzdGVhbCB0aGVzZSBmbGFncyBmb3IgbGltaXRlZCBtdWx0aXBsZSByb3V0aW5nIHRhYmxlCiAg KiBzdXBwb3J0LiBJbiBSRUxFTkdfOCBhbmQgYmV5b25kLCB1c2UganVzdCBvbmUgZmxhZyBhbmQg YSB0YWcuCi0tIAoxLjcuNi4xNTMuZzc4NDMyCgo= --bcaec51f8e8bfcd05f04ac2c4177 Content-Type: text/x-patch; charset=US-ASCII; name="0004-verify-mbuf-s-flags-consistency-after-tx.patch" Content-Disposition: attachment; filename="0004-verify-mbuf-s-flags-consistency-after-tx.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs738g954 RnJvbSBkMDUzMDg2N2E0NGU4MDI5YTRlNjRlNjljYWNkY2FhOTk4YTdlNzZmIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBcm5hdWQgTGFjb21iZSA8bGFjb21iYXJAZ21haWwuY29tPgpE YXRlOiBXZWQsIDMxIEF1ZyAyMDExIDIyOjEwOjU2IC0wNDAwClN1YmplY3Q6IFtQQVRDSCA0LzRd IHZlcmlmeSBtYnVmJ3MgZmxhZ3MgY29uc2lzdGVuY3kgYWZ0ZXIgdHgKCi0tLQogc3lzL2Rldi9l MTAwMC9pZl9lbS5jICB8ICAgMTQgKysrKysrKysrKysrKy0KIHN5cy9kZXYvZTEwMDAvaWZfaWdi LmMgfCAgIDE0ICsrKysrKysrKysrKystCiBzeXMvc3lzL21idWYuaCAgICAgICAgIHwgICAgMyAr KysKIDMgZmlsZXMgY2hhbmdlZCwgMjkgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRp ZmYgLS1naXQgYS9zeXMvZGV2L2UxMDAwL2lmX2VtLmMgYi9zeXMvZGV2L2UxMDAwL2lmX2VtLmMK aW5kZXggYzVlOTM2ZC4uY2ExNjQ3ZSAxMDA2NDQKLS0tIGEvc3lzL2Rldi9lMTAwMC9pZl9lbS5j CisrKyBiL3N5cy9kZXYvZTEwMDAvaWZfZW0uYwpAQCAtNzQsNiArNzQsNyBAQAogI2luY2x1ZGUg PG5ldGluZXQvdWRwLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2luX2Nrc3VtLmg+CisjaW5jbHVk ZSA8bWFjaGluZS9faW50dHlwZXMuaD4KICNpbmNsdWRlIDxkZXYvbGVkL2xlZC5oPgogI2luY2x1 ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KQEAgLTE5 MDcsNiArMTkwOCw4IEBAIGVtX3htaXQoc3RydWN0IHR4X3JpbmcgKnR4ciwgc3RydWN0IG1idWYg KiptX2hlYWRwKQogICAgICAgICAgICAgICAgIGN0eGQtPmxvd2VyLmRhdGEgfD0gaHRvbGUzMihF MTAwMF9UWERfQ01EX1ZMRSk7CiAgICAgICAgIH0KIAorCW1faGVhZC0+bV9mbGFncyB8PSBNX1VO VVNFRDsKKwogICAgICAgICB0eF9idWZmZXItPm1faGVhZCA9IG1faGVhZDsKIAl0eF9idWZmZXJf bWFwcGVkLT5tYXAgPSB0eF9idWZmZXItPm1hcDsKIAl0eF9idWZmZXItPm1hcCA9IG1hcDsKQEAg LTM1MzUsNyArMzUzOCwxNiBAQCBlbV90eGVvZihzdHJ1Y3QgdHhfcmluZyAqdHhyKQogCQkJCSAg ICBCVVNfRE1BU1lOQ19QT1NUV1JJVEUpOwogCQkJCWJ1c19kbWFtYXBfdW5sb2FkKHR4ci0+dHh0 YWcsCiAJCQkJICAgIHR4X2J1ZmZlci0+bWFwKTsKLSAgICAgICAgICAgICAgICAgICAgICAgIAlt X2ZyZWVtKHR4X2J1ZmZlci0+bV9oZWFkKTsKKwkJCQl7CisJCQkJCUtBU1NFUlQoKHR4X2J1ZmZl ci0+bV9oZWFkLT5tX2ZsYWdzICYgTV9VTlVTRUQpID09IE1fVU5VU0VELAorCQkJCQkgICAgKCJD b3JydXB0ZWQgdW51c2VkIGZsYWdzLCBleHBlY3RlZCAweCUiIFBSSXg2NCAiLCBnb3QgMHglIiBQ Ukl4NjQgIiwgZmxhZ3MgMHglIiBQUkl4NjQsCisJCQkJCSAgICAgICAgTV9VTlVTRUQsIHR4X2J1 ZmZlci0+bV9oZWFkLT5tX2ZsYWdzICYgTV9VTlVTRUQsCisJCQkJCSAgICAgICAgdHhfYnVmZmVy LT5tX2hlYWQtPm1fZmxhZ3MpKTsKKwkJCQkJdHhfYnVmZmVyLT5tX2hlYWQtPm1fZmxhZ3MgJj0g fk1fVU5VU0VEOworCisJCQkJCW1fZnJlZW1fYXJnKHR4X2J1ZmZlci0+bV9oZWFkLCAodm9pZCAq KTB4MDBiYWJlMDApOworCQkJCX0KKwogICAgICAgICAgICAgICAgICAgICAgICAgCXR4X2J1ZmZl ci0+bV9oZWFkID0gTlVMTDsKICAgICAgICAgICAgICAgICAJfQogCQkJdHhfYnVmZmVyLT5uZXh0 X2VvcCA9IC0xOwpkaWZmIC0tZ2l0IGEvc3lzL2Rldi9lMTAwMC9pZl9pZ2IuYyBiL3N5cy9kZXYv ZTEwMDAvaWZfaWdiLmMKaW5kZXggNDcwMDgyOS4uOWFkNjE2YyAxMDA2NDQKLS0tIGEvc3lzL2Rl di9lMTAwMC9pZl9pZ2IuYworKysgYi9zeXMvZGV2L2UxMDAwL2lmX2lnYi5jCkBAIC04MCw2ICs4 MCw3IEBACiAjaW5jbHVkZSA8bmV0aW5ldC91ZHAuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvaW5f Y2tzdW0uaD4KKyNpbmNsdWRlIDxtYWNoaW5lL19pbnR0eXBlcy5oPgogI2luY2x1ZGUgPGRldi9s ZWQvbGVkLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KICNpbmNsdWRlIDxkZXYvcGNp L3BjaXJlZy5oPgpAQCAtMTY1NSw2ICsxNjU2LDggQEAgaWdiX3htaXQoc3RydWN0IHR4X3Jpbmcg KnR4ciwgc3RydWN0IG1idWYgKiptX2hlYWRwKQogCXR4ci0+bmV4dF9hdmFpbF9kZXNjID0gaTsK IAl0eHItPnR4X2F2YWlsIC09IG5zZWdzOwogCisJbV9oZWFkLT5tX2ZsYWdzIHw9IE1fVU5VU0VE OworCiAgICAgICAgIHR4X2J1ZmZlci0+bV9oZWFkID0gbV9oZWFkOwogCXR4X2J1ZmZlcl9tYXBw ZWQtPm1hcCA9IHR4X2J1ZmZlci0+bWFwOwogCXR4X2J1ZmZlci0+bWFwID0gbWFwOwpAQCAtMzM3 NCw3ICszMzc3LDE2IEBAIGlnYl90eGVvZihzdHJ1Y3QgdHhfcmluZyAqdHhyKQogCQkJCWJ1c19k bWFtYXBfdW5sb2FkKHR4ci0+dHh0YWcsCiAJCQkJICAgIHR4X2J1ZmZlci0+bWFwKTsKIAotICAg ICAgICAgICAgICAgICAgICAgICAgCW1fZnJlZW0odHhfYnVmZmVyLT5tX2hlYWQpOworCQkJCXsK KwkJCQkJS0FTU0VSVCgodHhfYnVmZmVyLT5tX2hlYWQtPm1fZmxhZ3MgJiBNX1VOVVNFRCkgPT0g TV9VTlVTRUQsCisJCQkJCSAgICAoIkNvcnJ1cHRlZCB1bnVzZWQgZmxhZ3MsIGV4cGVjdGVkIDB4 JSIgUFJJeDY0ICIsIGdvdCAweCUiIFBSSXg2NCAiLCBmbGFncyAweCUiIFBSSXg2NCwKKwkJCQkJ ICAgICAgICBNX1VOVVNFRCwgdHhfYnVmZmVyLT5tX2hlYWQtPm1fZmxhZ3MgJiBNX1VOVVNFRCwK KwkJCQkJICAgICAgICB0eF9idWZmZXItPm1faGVhZC0+bV9mbGFncykpOworCQkJCQl0eF9idWZm ZXItPm1faGVhZC0+bV9mbGFncyAmPSB+TV9VTlVTRUQ7CisKKwkJCQkJbV9mcmVlbV9hcmcodHhf YnVmZmVyLT5tX2hlYWQsICh2b2lkICopMHgwMGJhYmUwMCk7CisJCQkJfQorCiAgICAgICAgICAg ICAgICAgICAgICAgICAJdHhfYnVmZmVyLT5tX2hlYWQgPSBOVUxMOwogICAgICAgICAgICAgICAg IAl9CiAJCQl0eF9idWZmZXItPm5leHRfZW9wID0gLTE7CmRpZmYgLS1naXQgYS9zeXMvc3lzL21i dWYuaCBiL3N5cy9zeXMvbWJ1Zi5oCmluZGV4IDhhZDA5YmIuLjI5OWU2OTEgMTAwNjQ0Ci0tLSBh L3N5cy9zeXMvbWJ1Zi5oCisrKyBiL3N5cy9zeXMvbWJ1Zi5oCkBAIC0xOTEsNiArMTkxLDkgQEAg c3RydWN0IG1idWYgewogI2RlZmluZQlNX1BST1RPNgkweDAwMDgwMDAwVUxMIC8qIHByb3RvY29s LXNwZWNpZmljICovCiAjZGVmaW5lCU1fUFJPVE83CTB4MDAxMDAwMDBVTEwgLyogcHJvdG9jb2wt c3BlY2lmaWMgKi8KICNkZWZpbmUJTV9QUk9UTzgJMHgwMDIwMDAwMFVMTCAvKiBwcm90b2NvbC1z cGVjaWZpYyAqLworCisjZGVmaW5lIE1fVU5VU0VECSh+KDB4ZmZmZmZmZmZVTEwpKQorCiAvKgog ICogRm9yIFJFTEVOR197Niw3fSBzdGVhbCB0aGVzZSBmbGFncyBmb3IgbGltaXRlZCBtdWx0aXBs ZSByb3V0aW5nIHRhYmxlCiAgKiBzdXBwb3J0LiBJbiBSRUxFTkdfOCBhbmQgYmV5b25kLCB1c2Ug anVzdCBvbmUgZmxhZyBhbmQgYSB0YWcuCi0tIAoxLjcuNi4xNTMuZzc4NDMyCgo= --bcaec51f8e8bfcd05f04ac2c4177-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 07:21:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 468AC1065676; Mon, 5 Sep 2011 07:21:04 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id CBA0C8FC15; Mon, 5 Sep 2011 07:21:03 +0000 (UTC) Received: by qyk4 with SMTP id 4so1881763qyk.13 for ; Mon, 05 Sep 2011 00:21:03 -0700 (PDT) Received: by 10.229.38.34 with SMTP id z34mr2573636qcd.234.1315205532129; Sun, 04 Sep 2011 23:52:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.103 with HTTP; Sun, 4 Sep 2011 23:51:32 -0700 (PDT) From: Takuya ASADA Date: Mon, 5 Sep 2011 15:51:32 +0900 Message-ID: To: jfv@freebsd.org, freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=0016e6d266028c9aa204ac2c26c4 Cc: Subject: Adding Flow Director sysctls to ixgbe(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: Mon, 05 Sep 2011 07:21:04 -0000 --0016e6d266028c9aa204ac2c26c4 Content-Type: text/plain; charset=UTF-8 Hi, I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: - Adding removing signature filter On linux version of ixgbe driver, it has ability to set/remove perfect filter from userland using ethtool command. I implemented similar feature, but on sysctl, and not perfect filter but signature filter(which means hash collision may occurs). Following command adds a signature filter on ix0 for 10.0.0.2:47390/tcp -> 10.0.0.1:22/tcp, queueing Rx queue 10. $ sysctl dev.ix.0.set_fdir_signature="tcpv4 10.0.0.2:47390 10.0.0.1:22 10" Clearing a filter takes similar values but not includes queue number: $ sysctl dev.ix.0.clear_fdir_signature="tcpv4 10.0.0.2:47390 10.0.0.1:22" - Statistics of Flow Director These sysctls poll fdir statistics register: dev.ix.*.mac_stats.fdirfree_free dev.ix.*.mac_stats.fdirfree_coll dev.ix.*.mac_stats.fdirustat_add dev.ix.*.mac_stats.fdirustat_remove dev.ix.*.mac_stats.fdirfstat_fadd dev.ix.*.mac_stats.fdirfstat_fremove dev.ix.*.mac_stats.fdirmatch dev.ix.*.mac_stats.fdirmiss And I divided "#ifdef IXGBE_FDIR" to "#ifdef IXGBE_FDIR" and "#ifdef IXGBE_FDIR_ATR". If only IXGBE_FDIR is defined, only set_fdir_signature sysctl sets signature filters. If IXGBE_FDIR and IXGBE_FDIR_ATR are defined, ixgbe_atr also sets signature filters automatically. Which means even if you set a filter with specific queue number via sysctl, ixgbe_atr will override the queue number. --0016e6d266028c9aa204ac2c26c4 Content-Type: text/x-patch; charset=US-ASCII; name="ixgbe-head-signature.diff" Content-Disposition: attachment; filename="ixgbe-head-signature.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gs71oy620 SW5kZXg6IGl4Z2JlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaXhnYmUuYwkocmV2aXNpb24gMjI1MDEzKQor KysgaXhnYmUuYwkod29ya2luZyBjb3B5KQpAQCAtMzcsNiArMzcsMTEgQEAKICNpbmNsdWRlICJv cHRfaW5ldDYuaCIKICNlbmRpZgogCisvKgorI2RlZmluZSBJWEdCRV9GRElSIDEKKyNkZWZpbmUg SVhHQkVfRkRJUl9BVFIgMQorKi8KKwogI2luY2x1ZGUgIml4Z2JlLmgiCiAKIC8qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioKQEAgLTE1Myw2ICsxNTgsOCBAQAogc3RhdGljIGludCAgICAgIGl4Z2JlX3htaXQoc3RydWN0 IHR4X3JpbmcgKiwgc3RydWN0IG1idWYgKiopOwogc3RhdGljIGludAlpeGdiZV9zZXRfZmxvd2Nu dGwoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0aWMgaW50CWl4Z2JlX3NldF9hZHZlcnRpc2Uo U1lTQ1RMX0hBTkRMRVJfQVJHUyk7CitzdGF0aWMgaW50CWl4Z2JlX3NldF9mZGlyX3NpZ25hdHVy ZShTWVNDVExfSEFORExFUl9BUkdTKTsKK3N0YXRpYyBpbnQJaXhnYmVfY2xlYXJfZmRpcl9zaWdu YXR1cmUoU1lTQ1RMX0hBTkRMRVJfQVJHUyk7CiBzdGF0aWMgaW50CWl4Z2JlX2RtYV9tYWxsb2Mo c3RydWN0IGFkYXB0ZXIgKiwgYnVzX3NpemVfdCwKIAkJICAgIHN0cnVjdCBpeGdiZV9kbWFfYWxs b2MgKiwgaW50KTsKIHN0YXRpYyB2b2lkICAgICBpeGdiZV9kbWFfZnJlZShzdHJ1Y3QgYWRhcHRl ciAqLCBzdHJ1Y3QgaXhnYmVfZG1hX2FsbG9jICopOwpAQCAtMTkxLDggKzE5OCwxMCBAQAogc3Rh dGljIHZvaWQJaXhnYmVfaGFuZGxlX21zZih2b2lkICosIGludCk7CiBzdGF0aWMgdm9pZAlpeGdi ZV9oYW5kbGVfbW9kKHZvaWQgKiwgaW50KTsKIAorI2lmZGVmIElYR0JFX0ZESVJfQVRSCitzdGF0 aWMgdm9pZAlpeGdiZV9hdHIoc3RydWN0IHR4X3JpbmcgKiwgc3RydWN0IG1idWYgKik7CisjZW5k aWYKICNpZmRlZiBJWEdCRV9GRElSCi1zdGF0aWMgdm9pZAlpeGdiZV9hdHIoc3RydWN0IHR4X3Jp bmcgKiwgc3RydWN0IG1idWYgKik7CiBzdGF0aWMgdm9pZAlpeGdiZV9yZWluaXRfZmRpcih2b2lk ICosIGludCk7CiAjZW5kaWYKIApAQCAtMjkyLDcgKzMwMSw3IEBACiAvKiBLZWVwIHJ1bm5pbmcg dGFiIG9uIHRoZW0gZm9yIHNhbml0eSBjaGVjayAqLwogc3RhdGljIGludCBpeGdiZV90b3RhbF9w b3J0czsKIAotI2lmZGVmIElYR0JFX0ZESVIKKyNpZmRlZiBJWEdCRV9GRElSX0FUUgogLyoKICoq IEZvciBGbG93IERpcmVjdG9yOiB0aGlzIGlzIHRoZQogKiogbnVtYmVyIG9mIFRYIHBhY2tldHMg d2Ugc2FtcGxlCkBAIC0zMDMsNiArMzEyLDggQEAKICoqIHNldHRpbmcgdGhpcyB0byAwLgogKi8K IHN0YXRpYyBpbnQgYXRyX3NhbXBsZV9yYXRlID0gMjA7CisjZW5kaWYKKyNpZmRlZiBJWEdCRV9G RElSCiAvKiAKICoqIEZsb3cgRGlyZWN0b3IgYWN0dWFsbHkgJ3N0ZWFscycKICoqIHBhcnQgb2Yg dGhlIHBhY2tldCBidWZmZXIgYXMgaXRzCkBAIC00MTYsNiArNDI3LDE2IEBACiAJCQlPSURfQVVU TywgImVuYWJsZV9haW0iLCBDVExUWVBFX0lOVHxDVExGTEFHX1JXLAogCQkJJml4Z2JlX2VuYWJs ZV9haW0sIDEsICJJbnRlcnJ1cHQgTW9kZXJhdGlvbiIpOwogCisJU1lTQ1RMX0FERF9QUk9DKGRl dmljZV9nZXRfc3lzY3RsX2N0eChkZXYpLAorCQkJU1lTQ1RMX0NISUxEUkVOKGRldmljZV9nZXRf c3lzY3RsX3RyZWUoZGV2KSksCisJCQlPSURfQVVUTywgInNldF9mZGlyX3NpZ25hdHVyZSIsIENU TFRZUEVfU1RSSU5HIHwgQ1RMRkxBR19XUiwKKwkJCWFkYXB0ZXIsIDAsIGl4Z2JlX3NldF9mZGly X3NpZ25hdHVyZSwgIkEiLCAiU2V0IEZsb3cgRGlyZWN0b3IgU2lnbmF0dXJlIik7CisKKwlTWVND VExfQUREX1BST0MoZGV2aWNlX2dldF9zeXNjdGxfY3R4KGRldiksCisJCQlTWVNDVExfQ0hJTERS RU4oZGV2aWNlX2dldF9zeXNjdGxfdHJlZShkZXYpKSwKKwkJCU9JRF9BVVRPLCAiY2xlYXJfZmRp cl9zaWduYXR1cmUiLCBDVExUWVBFX1NUUklORyB8IENUTEZMQUdfV1IsCisJCQlhZGFwdGVyLCAw LCBpeGdiZV9jbGVhcl9mZGlyX3NpZ25hdHVyZSwgIkEiLCAiQ2xlYXIgRmxvdyBEaXJlY3RvciBT aWduYXR1cmUiKTsKKwogCS8qIFNldCB1cCB0aGUgdGltZXIgY2FsbG91dCAqLwogCWNhbGxvdXRf aW5pdF9tdHgoJmFkYXB0ZXItPnRpbWVyLCAmYWRhcHRlci0+Y29yZV9tdHgsIDApOwogCkBAIC0x Njg1LDcgKzE3MDYsNyBAQAogICAgICAgICAgICAgICAgIGNtZF90eXBlX2xlbiB8PSBJWEdCRV9B RFZUWERfTUFDX1RTVEFNUDsKICNlbmRpZgogCi0jaWZkZWYgSVhHQkVfRkRJUgorI2lmZGVmIElY R0JFX0ZESVJfQVRSCiAJLyogRG8gdGhlIGZsb3cgZGlyZWN0b3IgbWFnaWMgKi8KIAlpZiAoKHR4 ci0+YXRyX3NhbXBsZSkgJiYgKCFhZGFwdGVyLT5mZGlyX3JlaW5pdCkpIHsKIAkJKyt0eHItPmF0 cl9jb3VudDsKQEAgLTI4MzYsNyArMjg1Nyw3IEBACiAJCXR4YnVmLT5lb3BfaW5kZXggPSAtMTsK ICAgICAgICAgfQogCi0jaWZkZWYgSVhHQkVfRkRJUgorI2lmZGVmIElYR0JFX0ZESVJfQVRSCiAJ LyogU2V0IHRoZSByYXRlIGF0IHdoaWNoIHdlIHNhbXBsZSBwYWNrZXRzICovCiAJaWYgKGFkYXB0 ZXItPmh3Lm1hYy50eXBlICE9IGl4Z2JlX21hY184MjU5OEVCKQogCQl0eHItPmF0cl9zYW1wbGUg PSBhdHJfc2FtcGxlX3JhdGU7CkBAIC0zMjE2LDcgKzMyMzcsNyBAQAogCXJldHVybiBUUlVFOwog fQogCi0jaWZkZWYgSVhHQkVfRkRJUgorI2lmZGVmIElYR0JFX0ZESVJfQVRSCiAvKgogKiogVGhp cyByb3V0aW5lIHBhcnNlcyBwYWNrZXQgaGVhZGVycyBzbyB0aGF0IEZsb3cKICoqIERpcmVjdG9y IGNhbiBtYWtlIGEgaGFzaGVkIGZpbHRlciB0YWJsZSBlbnRyeSAKQEAgLTQxNTEsNyArNDE3Miw3 IEBACiAJCXUzMgkJcnNjLCBwdHlwZTsKIAkJdTE2CQlobGVuLCBwbGVuLCBoZHIsIHZ0YWc7CiAJ CWJvb2wJCWVvcDsKLSAKKwogCQkvKiBTeW5jIHRoZSByaW5nLiAqLwogCQlidXNfZG1hbWFwX3N5 bmMocnhyLT5yeGRtYS5kbWFfdGFnLCByeHItPnJ4ZG1hLmRtYV9tYXAsCiAJCSAgICBCVVNfRE1B U1lOQ19QT1NUUkVBRCB8IEJVU19ETUFTWU5DX1BPU1RXUklURSk7CkBAIC00OTMzLDYgKzQ5NTQs MzAgQEAKIAkJYWRhcHRlci0+c3RhdHMuZmNvZWR3dGMgKz0gSVhHQkVfUkVBRF9SRUcoaHcsIElY R0JFX0ZDT0VEV1RDKTsKIAl9CiAKKwkvKiBPbmx5IHJlYWQgZmRpciBvbiA4MjU5OSAqLworCWlm IChody0+bWFjLnR5cGUgIT0gaXhnYmVfbWFjXzgyNTk4RUIpIHsKKwkJYWRhcHRlci0+c3RhdHMu ZmRpcmZyZWVfZnJlZSA9CisJCQkoSVhHQkVfUkVBRF9SRUcoaHcsIElYR0JFX0ZESVJGUkVFKSAm IElYR0JFX0ZESVJGUkVFX0ZSRUVfTUFTSykKKwkJCT4+IElYR0JFX0ZESVJGUkVFX0ZSRUVfU0hJ RlQ7CisJCWFkYXB0ZXItPnN0YXRzLmZkaXJmcmVlX2NvbGwgPQorCQkJKElYR0JFX1JFQURfUkVH KGh3LCBJWEdCRV9GRElSRlJFRSkgJiBJWEdCRV9GRElSRlJFRV9DT0xMX01BU0spCisJCQk+PiBJ WEdCRV9GRElSRlJFRV9DT0xMX1NISUZUOworCQlhZGFwdGVyLT5zdGF0cy5mZGlydXN0YXRfYWRk ICs9CisJCQkoSVhHQkVfUkVBRF9SRUcoaHcsIElYR0JFX0ZESVJVU1RBVCkgJiBJWEdCRV9GRElS VVNUQVRfQUREX01BU0spCisJCQk+PiBJWEdCRV9GRElSVVNUQVRfQUREX1NISUZUOworCQlhZGFw dGVyLT5zdGF0cy5mZGlydXN0YXRfcmVtb3ZlICs9CisJCQkoSVhHQkVfUkVBRF9SRUcoaHcsIElY R0JFX0ZESVJVU1RBVCkgJiBJWEdCRV9GRElSVVNUQVRfUkVNT1ZFX01BU0spCisJCQk+PiBJWEdC RV9GRElSVVNUQVRfUkVNT1ZFX1NISUZUOworCQlhZGFwdGVyLT5zdGF0cy5mZGlyZnN0YXRfZmFk ZCArPQorCQkJKElYR0JFX1JFQURfUkVHKGh3LCBJWEdCRV9GRElSRlNUQVQpICYgSVhHQkVfRkRJ UkZTVEFUX0ZBRERfTUFTSykKKwkJCT4+IElYR0JFX0ZESVJGU1RBVF9GQUREX1NISUZUOworCQlh ZGFwdGVyLT5zdGF0cy5mZGlyZnN0YXRfZnJlbW92ZSArPQorCQkJKElYR0JFX1JFQURfUkVHKGh3 LCBJWEdCRV9GRElSRlNUQVQpICYgSVhHQkVfRkRJUkZTVEFUX0ZSRU1PVkVfTUFTSykKKwkJCT4+ IElYR0JFX0ZESVJGU1RBVF9GUkVNT1ZFX1NISUZUOworCQlhZGFwdGVyLT5zdGF0cy5mZGlybWF0 Y2ggKz0gSVhHQkVfUkVBRF9SRUcoaHcsIElYR0JFX0ZESVJNQVRDSCk7CisJCWFkYXB0ZXItPnN0 YXRzLmZkaXJtaXNzICs9IElYR0JFX1JFQURfUkVHKGh3LCBJWEdCRV9GRElSTUlTUyk7CisJfQor CiAJLyogRmlsbCBvdXQgdGhlIE9TIHN0YXRpc3RpY3Mgc3RydWN0dXJlICovCiAJaWZwLT5pZl9p cGFja2V0cyA9IGFkYXB0ZXItPnN0YXRzLmdwcmM7CiAJaWZwLT5pZl9vcGFja2V0cyA9IGFkYXB0 ZXItPnN0YXRzLmdwdGM7CkBAIC01MzAxLDYgKzUzNDYsMzIgQEAKIAlTWVNDVExfQUREX1VRVUFE KGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgImZjX2R3b3JkX3R4ZCIsCiAJCUNUTEZMQUdfUkQs ICZzdGF0cy0+ZmNvZWR3dGMsCiAJCSJGQ29FIERXb3JkcyBUcmFuc21pdHRlZCIpOworCisJLyog ZmRpciBzdGF0cyAqLworCVNZU0NUTF9BRERfVVFVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRP LCAiZmRpcmZyZWVfZnJlZSIsCisJCUNUTEZMQUdfUkQsICZzdGF0cy0+ZmRpcmZyZWVfZnJlZSwK KwkJIiIpOworCVNZU0NUTF9BRERfVVFVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZmRp cmZyZWVfY29sbCIsCisJCUNUTEZMQUdfUkQsICZzdGF0cy0+ZmRpcmZyZWVfY29sbCwKKwkJIiIp OworCVNZU0NUTF9BRERfVVFVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZmRpcnVzdGF0 X2FkZCIsCisJCUNUTEZMQUdfUkQsICZzdGF0cy0+ZmRpcnVzdGF0X2FkZCwKKwkJIiIpOworCVNZ U0NUTF9BRERfVVFVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZmRpcnVzdGF0X3JlbW92 ZSIsCisJCUNUTEZMQUdfUkQsICZzdGF0cy0+ZmRpcnVzdGF0X3JlbW92ZSwKKwkJIiIpOworCVNZ U0NUTF9BRERfVVFVQUQoY3R4LCBzdGF0X2xpc3QsIE9JRF9BVVRPLCAiZmRpcmZzdGF0X2ZhZGQi LAorCQlDVExGTEFHX1JELCAmc3RhdHMtPmZkaXJmc3RhdF9mYWRkLAorCQkiIik7CisJU1lTQ1RM X0FERF9VUVVBRChjdHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJmZGlyZnN0YXRfZnJlbW92ZSIs CisJCUNUTEZMQUdfUkQsICZzdGF0cy0+ZmRpcmZzdGF0X2ZyZW1vdmUsCisJCSIiKTsKKwlTWVND VExfQUREX1VRVUFEKGN0eCwgc3RhdF9saXN0LCBPSURfQVVUTywgImZkaXJtYXRjaCIsCisJCUNU TEZMQUdfUkQsICZzdGF0cy0+ZmRpcm1hdGNoLAorCQkiIik7CisJU1lTQ1RMX0FERF9VUVVBRChj dHgsIHN0YXRfbGlzdCwgT0lEX0FVVE8sICJmZGlybWlzcyIsCisJCUNUTEZMQUdfUkQsICZzdGF0 cy0+ZmRpcm1pc3MsCisJCSIiKTsKIH0KIAogLyoKQEAgLTUzOTIsMyArNTQ2MywxMzMgQEAKIAog CXJldHVybiAoZXJyb3IpOwogfQorCitzdGF0aWMgaW50CitpeGdiZV9mZGlyX3BhcnNlX2FkZHJl c3MoY2hhciAqc3RyaW5nLCBzdHJ1Y3QgaW5fYWRkciAqaXAsIGludCAqcG9ydCkKK3sKKwljaGFy ICp0b2tlbjsKKwlpbnQgZXJyb3I7CisKKwl0b2tlbiA9IHN0cnNlcCgmc3RyaW5nLCAiOiIpOwor CWlmICghdG9rZW4pCisJCXJldHVybiAoRUlOVkFMKTsKKworCWVycm9yID0gaW5ldF9hdG9uKHRv a2VuLCBpcCk7CisJaWYgKGVycm9yICE9IDEpCisJCXJldHVybiAoZXJyb3IpOworCisJdG9rZW4g PSBzdHJzZXAoJnN0cmluZywgIjoiKTsKKwlpZiAoIXRva2VuKQorCQlyZXR1cm4gKEVJTlZBTCk7 CisKKwkqcG9ydCA9IHN0cnRvbCh0b2tlbiwgTlVMTCwgMCk7CisJaWYgKCpwb3J0IDw9IDApCisJ CXJldHVybiAoRUlOVkFMKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyBpbnQKK2l4Z2Jl X2ZkaXJfcGFyc2Vfc3lzY3RsKGNoYXIgKnN0cmluZywgdW5pb24gaXhnYmVfYXRyX2hhc2hfZHdv cmQgKmlucHV0LCAKKwl1bmlvbiBpeGdiZV9hdHJfaGFzaF9kd29yZCAqY29tbW9uLCBpbnQgKnF1 ZV9pbmRleCkKK3sKKwljaGFyICp0b2tlbjsKKwlzdHJ1Y3QgaW5fYWRkciBzcmNfaXAsIGRzdF9p cDsKKwlpbnQgc3JjX3BvcnQgPSAwLCBkc3RfcG9ydCA9IDA7CisJaW50IGVycm9yOworCisJdG9r ZW4gPSBzdHJzZXAoJnN0cmluZywgIiAiKTsKKwlpZiAoIXRva2VuKQorCQlyZXR1cm4gKEVJTlZB TCk7CisKKwlpZiAoIXN0cmNtcCh0b2tlbiwgInRjcHY0IikpCisJCWlucHV0LT5mb3JtYXR0ZWQu Zmxvd190eXBlIF49IElYR0JFX0FUUl9GTE9XX1RZUEVfVENQVjQ7CisJZWxzZSBpZiAoIXN0cmNt cCh0b2tlbiwgInVkcHY0IikpCisJCWlucHV0LT5mb3JtYXR0ZWQuZmxvd190eXBlIF49IElYR0JF X0FUUl9GTE9XX1RZUEVfVURQVjQ7CisJZWxzZQorCQlyZXR1cm4gKEVJTlZBTCk7CisKKwl0b2tl biA9IHN0cnNlcCgmc3RyaW5nLCAiICIpOworCWlmICghdG9rZW4pCisJCXJldHVybiAoRUlOVkFM KTsKKworCWVycm9yID0gaXhnYmVfZmRpcl9wYXJzZV9hZGRyZXNzKHRva2VuLCAmc3JjX2lwLCAm c3JjX3BvcnQpOworCWlmIChlcnJvcikKKwkJcmV0dXJuIChlcnJvcik7CisKKwljb21tb24tPnBv cnQuc3JjIF49IGh0b25zKHNyY19wb3J0KTsKKworCXRva2VuID0gc3Ryc2VwKCZzdHJpbmcsICIg Iik7CisJaWYgKCF0b2tlbikKKwkJcmV0dXJuIChFSU5WQUwpOworCisJZXJyb3IgPSBpeGdiZV9m ZGlyX3BhcnNlX2FkZHJlc3ModG9rZW4sICZkc3RfaXAsICZkc3RfcG9ydCk7CisJaWYgKGVycm9y KQorCQlyZXR1cm4gKGVycm9yKTsKKworCWNvbW1vbi0+cG9ydC5kc3QgXj0gaHRvbnMoZHN0X3Bv cnQpOworCWNvbW1vbi0+ZmxleF9ieXRlcyBePSBodG9ucyhFVEhFUlRZUEVfSVApOworCWNvbW1v bi0+aXAgXj0gc3JjX2lwLnNfYWRkciBeIGRzdF9pcC5zX2FkZHI7CisKKwlpZiAocXVlX2luZGV4 ICE9IE5VTEwpIHsKKwkJdG9rZW4gPSBzdHJzZXAoJnN0cmluZywgIiAiKTsKKwkJaWYgKCF0b2tl bikKKwkJCXJldHVybiAoRUlOVkFMKTsKKwkJKnF1ZV9pbmRleCA9IHN0cnRvbCh0b2tlbiwgTlVM TCwgMCk7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAoraXhnYmVfc2V0X2Zk aXJfc2lnbmF0dXJlKFNZU0NUTF9IQU5ETEVSX0FSR1MpCit7CisJY2hhciBidWZbMTAyNF0gPSB7 MCx9OworCXN0cnVjdCBhZGFwdGVyICphZGFwdGVyOworCXVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3 b3JkIGlucHV0ID0gey5kd29yZCA9IDB9OworCXVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3JkIGNv bW1vbiA9IHsuZHdvcmQgPSAwfTsKKwlpbnQgcXVlX2luZGV4OworCWludCBlcnJvcjsKKworCWFk YXB0ZXIgPSAoc3RydWN0IGFkYXB0ZXIgKikgYXJnMTsKKwllcnJvciA9IHN5c2N0bF9oYW5kbGVf c3RyaW5nKG9pZHAsIGJ1Ziwgc2l6ZW9mKGJ1ZiksIHJlcSk7CisJaWYgKGVycm9yKQorCQlyZXR1 cm4gKGVycm9yKTsKKwlpZiAoYnVmWzBdID09ICdcMCcpCisJCXJldHVybiAoMCk7CisKKwllcnJv ciA9IGl4Z2JlX2ZkaXJfcGFyc2Vfc3lzY3RsKGJ1ZiwgJmlucHV0LCAmY29tbW9uLCAmcXVlX2lu ZGV4KTsKKwlpZiAoZXJyb3IpCisJCXJldHVybiAoZXJyb3IpOworCisJaXhnYmVfZmRpcl9hZGRf c2lnbmF0dXJlX2ZpbHRlcl84MjU5OSgmYWRhcHRlci0+aHcsCisJICAgIGlucHV0LCBjb21tb24s IHF1ZV9pbmRleCk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitpeGdiZV9jbGVh cl9mZGlyX3NpZ25hdHVyZShTWVNDVExfSEFORExFUl9BUkdTKQoreworCWNoYXIgYnVmWzEwMjRd ID0gezAsfTsKKwlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcjsKKwl1bmlvbiBpeGdiZV9hdHJfaGFz aF9kd29yZCBpbnB1dCA9IHsuZHdvcmQgPSAwfTsKKwl1bmlvbiBpeGdiZV9hdHJfaGFzaF9kd29y ZCBjb21tb24gPSB7LmR3b3JkID0gMH07CisJaW50IGVycm9yOworCisJYWRhcHRlciA9IChzdHJ1 Y3QgYWRhcHRlciAqKSBhcmcxOworCWVycm9yID0gc3lzY3RsX2hhbmRsZV9zdHJpbmcob2lkcCwg YnVmLCBzaXplb2YoYnVmKSwgcmVxKTsKKwlpZiAoZXJyb3IpCisJCXJldHVybiAoZXJyb3IpOwor CWlmIChidWZbMF0gPT0gJ1wwJykKKwkJcmV0dXJuICgwKTsKKworCWVycm9yID0gaXhnYmVfZmRp cl9wYXJzZV9zeXNjdGwoYnVmLCAmaW5wdXQsICZjb21tb24sIE5VTEwpOworCWlmIChlcnJvcikK KwkJcmV0dXJuIChlcnJvcik7CisKKwlpeGdiZV9mZGlyX2NsZWFyX3NpZ25hdHVyZV9maWx0ZXJf ODI1OTkoJmFkYXB0ZXItPmh3LAorCSAgICBpbnB1dCwgY29tbW9uKTsKKworCXJldHVybiAoMCk7 Cit9CkluZGV4OiBpeGdiZV90eXBlLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaXhnYmVfdHlwZS5oCShyZXZp c2lvbiAyMjUwMTMpCisrKyBpeGdiZV90eXBlLmgJKHdvcmtpbmcgY29weSkKQEAgLTI1ODgsNiAr MjU4OCw4IEBACiAJdTY0IHFidGNbMTZdOwogCXU2NCBxcHJkY1sxNl07CiAJdTY0IHB4b24yb2Zm Y1s4XTsKKwl1NjQgZmRpcmZyZWVfZnJlZTsKKwl1NjQgZmRpcmZyZWVfY29sbDsKIAl1NjQgZmRp cnVzdGF0X2FkZDsKIAl1NjQgZmRpcnVzdGF0X3JlbW92ZTsKIAl1NjQgZmRpcmZzdGF0X2ZhZGQ7 CkluZGV4OiBpeGdiZV84MjU5OS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGl4Z2JlXzgyNTk5LmMJKHJldmlz aW9uIDIyNTAxMykKKysrIGl4Z2JlXzgyNTk5LmMJKHdvcmtpbmcgY29weSkKQEAgLTEyNDIsNiAr MTI0Miw3IEBACiAJLyogTW92ZSB0aGUgZmxleGlibGUgYnl0ZXMgdG8gdXNlIHRoZSBldGhlcnR5 cGUgLSBzaGlmdCA2IHdvcmRzICovCiAJZmRpcmN0cmwgfD0gKDB4NiA8PCBJWEdCRV9GRElSQ1RS TF9GTEVYX1NISUZUKTsKIAorCWZkaXJjdHJsIHw9IElYR0JFX0ZESVJDVFJMX1JFUE9SVF9TVEFU VVM7CiAKIAkvKiBQcmltZSB0aGUga2V5cyBmb3IgaGFzaGluZyAqLwogCUlYR0JFX1dSSVRFX1JF RyhodywgSVhHQkVfRkRJUkhLRVksIElYR0JFX0FUUl9CVUNLRVRfSEFTSF9LRVkpOwpAQCAtMTU1 Miw3ICsxNTUzLDcgQEAKIH0KIAogLyoqCi0gKiAgaXhnYmVfYXRyX2FkZF9zaWduYXR1cmVfZmls dGVyXzgyNTk5IC0gQWRkcyBhIHNpZ25hdHVyZSBoYXNoIGZpbHRlcgorICogIGl4Z2JlX2ZkaXJf YWRkX3NpZ25hdHVyZV9maWx0ZXJfODI1OTkgLSBBZGRzIGEgc2lnbmF0dXJlIGhhc2ggZmlsdGVy CiAgKiAgQGh3OiBwb2ludGVyIHRvIGhhcmR3YXJlIHN0cnVjdHVyZQogICogIEBzdHJlYW06IGlu cHV0IGJpdHN0cmVhbQogICogIEBxdWV1ZTogcXVldWUgaW5kZXggdG8gZGlyZWN0IHRyYWZmaWMg dG8KQEAgLTE2MDQsNiArMTYwNSw1NiBAQAogfQogCiAvKioKKyAqICBpeGdiZV9mZGlyX2NsZWFy X3NpZ25hdHVyZV9maWx0ZXJfODI1OTkgLSBBZGRzIGEgc2lnbmF0dXJlIGhhc2ggZmlsdGVyCisg KiAgQGh3OiBwb2ludGVyIHRvIGhhcmR3YXJlIHN0cnVjdHVyZQorICogIEBzdHJlYW06IGlucHV0 IGJpdHN0cmVhbQorICogIEBxdWV1ZTogcXVldWUgaW5kZXggdG8gZGlyZWN0IHRyYWZmaWMgdG8K KyAqKi8KK3MzMiBpeGdiZV9mZGlyX2NsZWFyX3NpZ25hdHVyZV9maWx0ZXJfODI1OTkoc3RydWN0 IGl4Z2JlX2h3ICpodywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3JkIGlucHV0LAorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdW5pb24gaXhnYmVfYXRyX2hhc2hfZHdvcmQgY29tbW9uKQor eworCXU2NCAgZmRpcmhhc2hjbWQ7CisJdTMyICBmZGlyY21kOworCisJREVCVUdGVU5DKCJpeGdi ZV9mZGlyX2NsZWFyX3NpZ25hdHVyZV9maWx0ZXJfODI1OTkiKTsKKworCS8qCisJICogR2V0IHRo ZSBmbG93X3R5cGUgaW4gb3JkZXIgdG8gcHJvZ3JhbSBGRElSQ01EIHByb3Blcmx5CisJICogbG93 ZXN0IDIgYml0cyBhcmUgRkRJUkNNRC5MNFRZUEUsIHRoaXJkIGxvd2VzdCBiaXQgaXMgRkRJUkNN RC5JUFY2CisJICovCisJc3dpdGNoIChpbnB1dC5mb3JtYXR0ZWQuZmxvd190eXBlKSB7CisJY2Fz ZSBJWEdCRV9BVFJfRkxPV19UWVBFX1RDUFY0OgorCWNhc2UgSVhHQkVfQVRSX0ZMT1dfVFlQRV9V RFBWNDoKKwljYXNlIElYR0JFX0FUUl9GTE9XX1RZUEVfU0NUUFY0OgorCWNhc2UgSVhHQkVfQVRS X0ZMT1dfVFlQRV9UQ1BWNjoKKwljYXNlIElYR0JFX0FUUl9GTE9XX1RZUEVfVURQVjY6CisJY2Fz ZSBJWEdCRV9BVFJfRkxPV19UWVBFX1NDVFBWNjoKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJREVC VUdPVVQoIiBFcnJvciBvbiBmbG93IHR5cGUgaW5wdXRcbiIpOworCQlyZXR1cm4gSVhHQkVfRVJS X0NPTkZJRzsKKwl9CisKKwkvKiBjb25maWd1cmUgRkRJUkNNRCByZWdpc3RlciAqLworCWZkaXJj bWQgPSBJWEdCRV9GRElSQ01EX0NNRF9SRU1PVkVfRkxPVyB8IAorCSAgICAgICAgICBJWEdCRV9G RElSQ01EX0xBU1QgfCBJWEdCRV9GRElSQ01EX1FVRVVFX0VOOworCWZkaXJjbWQgfD0gaW5wdXQu Zm9ybWF0dGVkLmZsb3dfdHlwZSA8PCBJWEdCRV9GRElSQ01EX0ZMT1dfVFlQRV9TSElGVDsKKwor CS8qCisJICogVGhlIGxvd2VyIDMyLWJpdHMgb2YgZmRpcmhhc2hjbWQgaXMgZm9yIEZESVJIQVNI LCB0aGUgdXBwZXIgMzItYml0cworCSAqIGlzIGZvciBGRElSQ01ELiAgVGhlbiBkbyBhIDY0LWJp dCByZWdpc3RlciB3cml0ZSBmcm9tIEZESVJIQVNILgorCSAqLworCWZkaXJoYXNoY21kID0gKHU2 NClmZGlyY21kIDw8IDMyOworCWZkaXJoYXNoY21kIHw9IGl4Z2JlX2F0cl9jb21wdXRlX3NpZ19o YXNoXzgyNTk5KGlucHV0LCBjb21tb24pOworCUlYR0JFX1dSSVRFX1JFRzY0KGh3LCBJWEdCRV9G RElSSEFTSCwgZmRpcmhhc2hjbWQpOworCisJREVCVUdPVVQxKCJUeCBoYXNoPSV4XG4iLCAodTMy KWZkaXJoYXNoY21kKTsKKworCXJldHVybiBJWEdCRV9TVUNDRVNTOworfQorCisvKioKICAqICBp eGdiZV9nZXRfZmRpcnRjcG1fODI1OTkgLSBnZW5lcmF0ZSBhIHRjcCBwb3J0IGZyb20gYXRyX2lu cHV0X21hc2tzCiAgKiAgQGlucHV0X21hc2s6IG1hc2sgdG8gYmUgYml0IHN3YXBwZWQKICAqCkBA IC0yMTY0LDUgKzIyMTUsMyBAQAogb3V0OgogCXJldHVybiBsZXNtX2VuYWJsZWQ7CiB9Ci0KLQpJ bmRleDogaXhnYmVfYXBpLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaXhnYmVfYXBpLmgJKHJldmlzaW9uIDIy NTAxMykKKysrIGl4Z2JlX2FwaS5oCSh3b3JraW5nIGNvcHkpCkBAIC0xMjcsNiArMTI3LDkgQEAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuaW9uIGl4Z2JlX2F0 cl9oYXNoX2R3b3JkIGlucHV0LAogCQkJCQkgIHVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3JkIGNv bW1vbiwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHU4IHF1ZXVl KTsKK3MzMiBpeGdiZV9mZGlyX2NsZWFyX3NpZ25hdHVyZV9maWx0ZXJfODI1OTkoc3RydWN0IGl4 Z2JlX2h3ICpodywKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVu aW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3JkIGlucHV0LAorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdW5pb24gaXhnYmVfYXRyX2hhc2hfZHdvcmQgY29tbW9uKTsKIHMz MiBpeGdiZV9mZGlyX2FkZF9wZXJmZWN0X2ZpbHRlcl84MjU5OShzdHJ1Y3QgaXhnYmVfaHcgKmh3 LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuaW9uIGl4Z2JlX2F0 cl9pbnB1dCAqaW5wdXQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3RydWN0IGl4Z2JlX2F0cl9pbnB1dF9tYXNrcyAqbWFza3MsCg== --0016e6d266028c9aa204ac2c26c4-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 11:07: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 35469106566C for ; Mon, 5 Sep 2011 11:07:14 +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 220F08FC17 for ; Mon, 5 Sep 2011 11:07: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 p85B7EB4065949 for ; Mon, 5 Sep 2011 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p85B7DQA065947 for freebsd-net@FreeBSD.org; Mon, 5 Sep 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Sep 2011 11:07:13 GMT Message-Id: <201109051107.p85B7DQA065947@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, 05 Sep 2011 11:07:14 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/160442 net [vlan] Packets transmitted on vlan(4) interfaces with o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159602 net [netinet] [patch] arp_ifscrub() is called even if IFF_ o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159353 net [netinet] [patch] conditional call of ifa_del_loopback o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o 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/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre 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/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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow 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 bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/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/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o 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 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 bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 387 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 11:21:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8CF106566B for ; Mon, 5 Sep 2011 11:21:18 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 75B1E8FC0A for ; Mon, 5 Sep 2011 11:21:18 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 04:21:17 -0700 From: Ben Hutchings To: Takuya ASADA Date: Mon, 05 Sep 2011 12:21:12 +0100 In-Reply-To: References: Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2- Content-Transfer-Encoding: 7bit Message-ID: <1315221674.3092.282.camel@deadeye> Mime-Version: 1.0 X-OriginalArrivalTime: 05 Sep 2011 11:21:17.0649 (UTC) FILETIME=[EE373C10:01CC6BBD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18366.005 X-TM-AS-Result: No--8.619500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: jfv@freebsd.org, freebsd-net@freebsd.org Subject: Re: Adding Flow Director sysctls to ixgbe(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: Mon, 05 Sep 2011 11:21:18 -0000 On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > Hi, > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > - Adding removing signature filter > On linux version of ixgbe driver, it has ability to set/remove perfect > filter from userland using ethtool command. > I implemented similar feature, but on sysctl, and not perfect filter > but signature filter(which means hash collision may occurs). [...] Linux also has a generic interface to RX filtering and hashing (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD to support something like that? Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 12:52: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 005E9106564A for ; Mon, 5 Sep 2011 12:52:31 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B28DB8FC26 for ; Mon, 5 Sep 2011 12:52:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R0YQX-0005jM-Nn for freebsd-net@freebsd.org; Mon, 05 Sep 2011 14:37:25 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Sep 2011 14:37:25 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Sep 2011 14:37:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Mon, 05 Sep 2011 14:37:08 +0200 Lines: 45 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 X-Enigmail-Version: 1.1.2 Subject: ipfw and ipv6: "me" 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, 05 Sep 2011 12:52:31 -0000 Hello, I think the ipfw(8) man page is a bit ambiguous in this area: does the "me" pseudo-address (as in "allow tcp from any to me 80") also include ipv6? Here's what the man page says on 8-stable: """ src and dst: {addr | { addr or ... }} [[not] ports] An address (or a list, see below) optionally followed by ports specifiers. The second format (or-block with multiple addresses) is provided for convenience only and its use is discouraged. ip | all any matches any IP address. me matches any IP address configured on an interface in the system. me6 matches any IPv6 address configured on an interface in the system. The address list is evaluated at the time the packet is analysed. table(number[,value]) Matches any IPv4 address for which an entry exists in the lookup table number. If an optional 32-bit unsigned value is also specified, an entry will match only if it has this value. See the LOOKUP TABLES section below for more information on lookup tables. """ There is no symmetrical "me4" option which leads me to think that "me" matches only ipv4 and "me6" only ipv6. Is this right? Any ideas? From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 14:18: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 E058F106564A; Mon, 5 Sep 2011 14:18:58 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id B89468FC17; Mon, 5 Sep 2011 14:18:58 +0000 (UTC) Received: from draco.over-yonder.net (c-174-50-4-38.hsd1.ms.comcast.net [174.50.4.38]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 6C56537B4B2; Mon, 5 Sep 2011 09:01:22 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id A5E3D177D5; Mon, 5 Sep 2011 09:01:21 -0500 (CDT) Date: Mon, 5 Sep 2011 09:01:21 -0500 From: "Matthew D. Fuller" To: Ivan Voras Message-ID: <20110905140121.GA2135@over-yonder.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: ipfw and ipv6: "me" 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, 05 Sep 2011 14:18:59 -0000 On Mon, Sep 05, 2011 at 02:37:08PM +0200 I heard the voice of Ivan Voras, and lo! it spake thus: > > There is no symmetrical "me4" option which leads me to think that > "me" matches only ipv4 and "me6" only ipv6. I can't answer for the code, but as far as I could tell as a user that's the case. (and so my firewall script is piled up with "{ me or me6 }"'s... sigh) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 14:57:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FE031065676 for ; Mon, 5 Sep 2011 14:57:52 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 211DB8FC0A for ; Mon, 5 Sep 2011 14:57:51 +0000 (UTC) Received: by gxk28 with SMTP id 28so4032002gxk.13 for ; Mon, 05 Sep 2011 07:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=WfSey6fTgw0UNftyYMWpsa2jAUuuvTYLt/UW3JvzXTM=; b=eYYNIRQ/qMqGWv8fmMsm3vZer9wipCdHHDk7fNfdyo8yrbkeAmHx9K9hpGCqreNPo2 f9Ib3qcGB8POhR/eZgjjpbEz++hRPVyG3wO4YN/ygfIW5pbhySQ7gwj8THWe8Kskfhnt UYDOtlV5f6bHbN3+SCtnjaEjLg6A1zlbn1bHo= Received: by 10.101.5.21 with SMTP id h21mr2723172ani.123.1315233346089; Mon, 05 Sep 2011 07:35:46 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.134.4 with HTTP; Mon, 5 Sep 2011 07:35:06 -0700 (PDT) In-Reply-To: <20110905140121.GA2135@over-yonder.net> References: <20110905140121.GA2135@over-yonder.net> From: Ivan Voras Date: Mon, 5 Sep 2011 16:35:06 +0200 X-Google-Sender-Auth: sTj1oDTu8OVWHhZ5VVD5Giq6gVo Message-ID: To: "Matthew D. Fuller" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: ipfw and ipv6: "me" 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, 05 Sep 2011 14:57:52 -0000 On 5 September 2011 16:01, Matthew D. Fuller wrote: > On Mon, Sep 05, 2011 at 02:37:08PM +0200 I heard the voice of > Ivan Voras, and lo! it spake thus: >> >> There is no symmetrical "me4" option which leads me to think that >> "me" matches only ipv4 and "me6" only ipv6. > > I can't answer for the code, but as far as I could tell as a user > that's the case. > > (and so my firewall script is piled up with "{ me or me6 }"'s... > sigh) I thought so too, and AFAIK it used to work like that, but it might be that something has changed. I have pretty conclusive evidence that the handling has either been extended to (ipv4 or ipv6) or at least is inconsistent. I've verified this by having these two rules: 02999 17 1360 skipto 3000 log tcp from me to any setup keep-state 03000 66661 52129939 allow tcp from me to any setup keep-state and the logs have this: Sep 5 14:29:19 element kernel: ipfw: 2999 SkipTo 3000 TCP [2001:xxxx:xxxx:xxxx:xxxx:56ff:fe99:3327]:43389 [2001:4f8:fff6::22]:80 out via em0 Sep 5 14:29:19 element kernel: ipfw: 2999 SkipTo 3000 TCP [2001:4f8:fff6::22]:80 [2001:xxxx:xxxx:xxxx:xxxx:56ff:fe99:3327]:43389 in via em0 Sep 5 14:31:53 element kernel: ipfw: 2999 SkipTo 3000 TCP 69.147.83.34:80 xxx.xxx.xxx.xxx:38991 in via em0 So "tcp from me to any..." appears to match both... which would be fine, but then how do we match ipv4 only? From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 15:52: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 4F0DD106566C; Mon, 5 Sep 2011 15:52:35 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 09FAB8FC14; Mon, 5 Sep 2011 15:52:34 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id p85FqNn6078740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 00:52:28 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 06 Sep 2011 00:52:22 +0900 Message-ID: From: Hajimu UMEMOTO To: Ivan Voras In-Reply-To: References: User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 06 Sep 2011 00:52:28 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org Subject: Re: ipfw and ipv6: "me" 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, 05 Sep 2011 15:52:35 -0000 Hi, >>>>> On Mon, 05 Sep 2011 14:37:08 +0200 >>>>> Ivan Voras said: ivoras> There is no symmetrical "me4" option which leads me to think that "me" ivoras> matches only ipv4 and "me6" only ipv6. There is `me6' for rather backward compatibility. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 15:57:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF1121065673; Mon, 5 Sep 2011 15:57:00 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 470928FC13; Mon, 5 Sep 2011 15:57:00 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3B0F3153434; Mon, 5 Sep 2011 17:56:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fky3CTthGAqn; Mon, 5 Sep 2011 17:56:54 +0200 (CEST) Received: from [10.20.7.13] (seven.iphion.nl [217.149.136.129]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id ED3B5153433; Mon, 5 Sep 2011 17:56:53 +0200 (CEST) Message-ID: <4E64F155.2090704@digiware.nl> Date: Mon, 05 Sep 2011 17:57:09 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ivan Voras References: <20110905140121.GA2135@over-yonder.net> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Matthew D. Fuller" Subject: Re: ipfw and ipv6: "me" 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, 05 Sep 2011 15:57:00 -0000 On 5-9-2011 16:35, Ivan Voras wrote: > On 5 September 2011 16:01, Matthew D. Fuller wrote: >> On Mon, Sep 05, 2011 at 02:37:08PM +0200 I heard the voice of >> Ivan Voras, and lo! it spake thus: >>> >>> There is no symmetrical "me4" option which leads me to think that >>> "me" matches only ipv4 and "me6" only ipv6. >> >> I can't answer for the code, but as far as I could tell as a user >> that's the case. >> >> (and so my firewall script is piled up with "{ me or me6 }"'s... >> sigh) > > I thought so too, and AFAIK it used to work like that, but it might be that > something has changed. I have pretty conclusive evidence that the handling > has either been extended to (ipv4 or ipv6) or at least is inconsistent. > > I've verified this by having these two rules: > > 02999 17 1360 skipto 3000 log tcp from me to any setup keep-state > 03000 66661 52129939 allow tcp from me to any setup keep-state > > and the logs have this: > > Sep 5 14:29:19 element kernel: ipfw: 2999 SkipTo 3000 TCP > [2001:xxxx:xxxx:xxxx:xxxx:56ff:fe99:3327]:43389 [2001:4f8:fff6::22]:80 out > via em0 > Sep 5 14:29:19 element kernel: ipfw: 2999 SkipTo 3000 TCP > [2001:4f8:fff6::22]:80 [2001:xxxx:xxxx:xxxx:xxxx:56ff:fe99:3327]:43389 in > via em0 > Sep 5 14:31:53 element kernel: ipfw: 2999 SkipTo 3000 TCP > 69.147.83.34:80 xxx.xxx.xxx.xxx:38991 in via em0 > > So "tcp from me to any..." appears to match both... which would be > fine, but then how do we match ipv4 only? I'm seriously living with the fact that 'me' is ipv4 AND ipv6. Never got to fixing my firewall, but this seems to indicate that me matches ipv6 also on 8.2.... 08890 18210 1069880 allow tcp from any to me dst-port 22 setup 08990 0 0 allow tcp from any to me6 dst-port 22 setup 09090 18846 1088324 allow tcp from any to me dst-port 25 setup 09190 0 0 allow tcp from any to me6 dst-port 25 setup 09290 34 2160 allow tcp from any to me dst-port 26 setup 09390 0 0 allow tcp from any to me6 dst-port 26 setup 09490 3 180 allow tcp from any to me dst-port 53 setup 09590 0 0 allow tcp from any to me6 dst-port 53 setup 09690 623 37764 allow tcp from any to me dst-port 80 setup 09790 0 0 allow tcp from any to me6 dst-port 80 setup 09890 290 18680 allow tcp from any to me dst-port 993 setup 09990 0 0 allow tcp from any to me6 dst-port 993 setup And note that I have ipv6 running between work and home. So atleast some ssh port 22 stuff should otherwise have matched the second rule. Same goes for mail, Freebsd.org does deliver over ipv6. postfix/smtpd[93760]: disconnect from mx2.freebsd.org[2001:4f8:fff6::35] --WjW From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 16:06: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 9884F106564A; Mon, 5 Sep 2011 16:06:13 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3207F8FC13; Mon, 5 Sep 2011 16:06:13 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id p85G672Q009172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 01:06:07 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 06 Sep 2011 01:06:07 +0900 Message-ID: From: Hajimu UMEMOTO To: Ivan Voras In-Reply-To: References: <20110905140121.GA2135@over-yonder.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 06 Sep 2011 01:06:08 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, "Matthew D. Fuller" Subject: Re: ipfw and ipv6: "me" 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, 05 Sep 2011 16:06:13 -0000 Hi, >>>>> On Mon, 5 Sep 2011 16:35:06 +0200 >>>>> Ivan Voras said: ivoras> So "tcp from me to any..." appears to match both... which would be ivoras> fine, but then how do we match ipv4 only? `ip4 from me to any proto tcp' should do the job. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 18:31: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 A49AE106566B for ; Mon, 5 Sep 2011 18:31:08 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 84A028FC17 for ; Mon, 5 Sep 2011 18:31:08 +0000 (UTC) Received: by pzk33 with SMTP id 33so15081413pzk.18 for ; Mon, 05 Sep 2011 11:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=5bGUlyT/7ea8uhefrUrDQf90a8qBOCiPl/jyLc6T3Ic=; b=eRix2KA2WGovbkmbfRzPqr49c17Cwtfl1d/ro4BfyTs6X99U+++myci5rz3RPjy209 spxS7NAegxCN4Y55ptFIeGnbi6IcXXrnSUIFbE/oNjsQu3x8fdgpa1UM7sSvO2LWMJ2i l8ietqC2vc7yHt+Y6yw2ac5fQp3zv14bPxeTE= MIME-Version: 1.0 Received: by 10.68.13.169 with SMTP id i9mr8278834pbc.195.1315247468022; Mon, 05 Sep 2011 11:31:08 -0700 (PDT) Received: by 10.142.131.15 with HTTP; Mon, 5 Sep 2011 11:31:08 -0700 (PDT) Date: Mon, 5 Sep 2011 14:31:08 -0400 Message-ID: From: Arnaud Lacombe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: No IPFW binary compat across versions ? 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, 05 Sep 2011 18:31:08 -0000 Hi, It would seem that the ipfw binary from a 7.4 install is not compatible with the in-kernel implementation of ipfw from 8-STABLE. The following command returns junk: # uname -a FreeBSD 8.2-STABLE FreeBSD 8.2-STABLE #0: Mon Sep 5 13:26:22 EDT 2011 # ipfw show 65535 79609572473438209 9528064790723821568 count ip from any to any # ipfw show 65535 80229898894966785 10211949650127093760 skipto 20069 ip from any to any # ipfw show 65535 81461570961408001 11566216593050435584 divert 20069 ip from any to any # ipfw show 65535 81826462792941569 11967688918742073344 tee 20069 ip from any to any # ipfw show 65535 85659197118611457 16196106284901072896 altq ?<301> ip from any to any # ipfw show 65535 86531998897668097 17160025365645623296 ** unrecognized action 64 len 19 ip from any to any # ipfw show 65535 127737816351244289 7272335601653776384 ** unrecognized action 158 len 19 ip from any to any However as the 8-STABLE kernel have COMPAT_FREEBSD7 enabled, I would not expect this to happen... Thanks, - Arnaud From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 19:45: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 8AF05106566B for ; Mon, 5 Sep 2011 19:45:09 +0000 (UTC) (envelope-from kmacybsd@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 4AC448FC16 for ; Mon, 5 Sep 2011 19:45:08 +0000 (UTC) Received: by vws18 with SMTP id 18so5375309vws.13 for ; Mon, 05 Sep 2011 12:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1+yfnIY5kib3R8/BQXro5THDXtakvUIyMyWzTfqFXz0=; b=WawzvEbps1NlzqcHpwYn25Cmril6+sLOLszHEo3nKRaflbg5GYMAnFZ/6+us9QE79R QkEOAiuUPLUH9pBMFeOpfCHtL9HxW/OHANnn1miHnllvkLivz9q9KvWqiVVUo+HjCvvO mAQVg+BitWjKRBKThjH8PmRvC1JUZC1pX5co0= MIME-Version: 1.0 Received: by 10.52.95.229 with SMTP id dn5mr3726518vdb.431.1315250074290; Mon, 05 Sep 2011 12:14:34 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.187.231 with HTTP; Mon, 5 Sep 2011 12:14:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Sep 2011 21:14:34 +0200 X-Google-Sender-Auth: 3lISZCGj5ySlGsU6lW8ubEX4cPY Message-ID: From: "K. Macy" To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: No IPFW binary compat across versions ? 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, 05 Sep 2011 19:45:09 -0000 -STABLE only implies that the ABI does not change during that release line. It makes no guarantees when moving from one branch to the next. On Mon, Sep 5, 2011 at 8:31 PM, Arnaud Lacombe wrote: > Hi, > > It would seem that the ipfw binary from a 7.4 install is not > compatible with the in-kernel implementation of ipfw from 8-STABLE. > The following command returns junk: > > # uname -a > FreeBSD =A08.2-STABLE FreeBSD 8.2-STABLE #0: Mon Sep =A05 13:26:22 EDT 20= 11 > > # ipfw show > 65535 79609572473438209 9528064790723821568 count ip from any to any > # ipfw show > 65535 80229898894966785 10211949650127093760 skipto 20069 ip from any to = any > # ipfw show > 65535 81461570961408001 11566216593050435584 divert 20069 ip from any to = any > # ipfw show > 65535 81826462792941569 11967688918742073344 tee 20069 ip from any to any > # ipfw show > 65535 85659197118611457 16196106284901072896 =A0altq ?<301> ip from any t= o any > # ipfw show > 65535 86531998897668097 17160025365645623296 ** unrecognized action 64 > len 19 =A0ip from any to any > # ipfw show > 65535 127737816351244289 7272335601653776384 ** unrecognized action > 158 len 19 =A0ip from any to any > > However as the 8-STABLE kernel have COMPAT_FREEBSD7 enabled, I would > not expect this to happen... > > Thanks, > =A0- Arnaud > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 19:58: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 B8A6C1065690; Mon, 5 Sep 2011 19:58:56 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA0898FC08; Mon, 5 Sep 2011 19:58:55 +0000 (UTC) Received: by bkat8 with SMTP id t8so6190958bka.13 for ; Mon, 05 Sep 2011 12:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=LZfQ8rcGZ0LubR8wOwxTmxnQCaXqNTXpDKwfLtLRWCg=; b=pGIIBGwhA4Izq/XCwJ+mpdU1AF2sPB+xDcPl0k9vjA0ymQFVND+2W7oPgWjrMhwO/E IVGo/G/RMJb7ZBBHE0+O7ZiDeiT+yZesj1R46GQs4HWb5+eXwn3dxSGBe6AyhORpQp/g EIHK6cr0VIxSvwNggPlZAy8KClLqjKoKy+Cuo= Received: by 10.204.141.215 with SMTP id n23mr2376304bku.364.1315252734742; Mon, 05 Sep 2011 12:58:54 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id r4sm4409645bki.0.2011.09.05.12.58.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Sep 2011 12:58:52 -0700 (PDT) From: Mikolaj Golub To: Andre Oppermann References: <86ehzwwt6a.fsf@kopusha.home.net> X-Comment-To: Mikolaj Golub Sender: Mikolaj Golub Date: Mon, 05 Sep 2011 22:58:49 +0300 In-Reply-To: <86ehzwwt6a.fsf@kopusha.home.net> (Mikolaj Golub's message of "Sun, 04 Sep 2011 12:30:53 +0300") Message-ID: <86r53uhibq.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Kostik Belousov , freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL 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, 05 Sep 2011 19:58:56 -0000 --=-=-= On Sun, 04 Sep 2011 12:30:53 +0300 Mikolaj Golub wrote: MG> Apparently soreceive_stream() has an issue if it is called to receive data as a MG> mbuf chain (by supplying an non zero mbuf **mp0) and with MSG_WAITALL set. MG> I ran into this issue with smbfs, which uses soreceive() exactly in this way MG> (see netsmb/smb_trantcp.c:nbssn_recv()). Stressing smbfs a little I also observed the following soreceive_stream() related panic: #9 0x80a28c80 in panic (fmt=0x80f4b4a4 "sbappendstream 1") at /usr/src/sys/kern/kern_shutdown.c:606 #10 0x80a9746b in sbappendstream_locked (sb=0x8bff1874, m=0x8885a600) at /usr/src/sys/kern/uipc_sockbuf.c:527 #11 0x80bcef62 in tcp_do_segment (m=0x8885a600, th=0x8885a674, so=0x8bff1820, tp=0x8bb4f560, drop_hdrlen=52, tlen=51, iptos=0 '\0', ti_locked=1) at /usr/src/sys/netinet/tcp_input.c:2854 #12 0x80bd091d in tcp_input (m=0x8885a600, off0=20) at /usr/src/sys/netinet/tcp_input.c:1382 #13 0x80b5b4fe in ip_input (m=0x8885a600) at /usr/src/sys/netinet/ip_input.c:765 #14 0x80af504b in swi_net (arg=0x81825880) at /usr/src/sys/net/netisr.c:806 #15 0x809fd535 in intr_event_execute_handlers (p=0x86ddc588, ie=0x86d37200) at /usr/src/sys/kern/kern_intr.c:1257 #16 0x809fe419 in ithread_loop (arg=0x86d39bb0) at /usr/src/sys/kern/kern_intr.c:1270 #17 0x809fa7a8 in fork_exit (callout=0x809fe370 , arg=0x86d39bb0, frame=0x86926d28) at /usr/src/sys/kern/kern_fork.c:1029 #18 0x80d68914 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) fr 10 #10 0x80a9746b in sbappendstream_locked (sb=0x8bff1874, m=0x8885a600) at /usr/src/sys/kern/uipc_sockbuf.c:527 527 KASSERT(sb->sb_mb == sb->sb_lastrecord,("sbappendstream 1")); (kgdb) l 522 sbappendstream_locked(struct sockbuf *sb, struct mbuf *m) 523 { 524 SOCKBUF_LOCK_ASSERT(sb); 525 526 KASSERT(m->m_nextpkt == NULL,("sbappendstream 0")); 527 KASSERT(sb->sb_mb == sb->sb_lastrecord,("sbappendstream 1")); 528 529 SBLASTMBUFCHK(sb); 530 531 sbcompress(sb, m, sb->sb_mbtail); (kgdb) p m $1 = (struct mbuf *) 0x8885a600 (kgdb) p m->m_hdr.mh_next $2 = (struct mbuf *) 0x0 (kgdb) p sb->sb_mb $3 = (struct mbuf *) 0x93965e00 (kgdb) p sb->sb_lastrecord $4 = (struct mbuf *) 0x88cb0200 (kgdb) p sb $5 = (struct sockbuf *) 0x8bff1874 This sb belonged to smb_iod_thread which at that time was in soreceive_stream(), notifying the protocol that buffer had been drained: #1 0x80d74cb7 in ipi_nmi_handler () at /usr/src/sys/i386/i386/mp_machdep.c:1478 #2 0x80d7f383 in trap (frame=0xdc33ea58) at /usr/src/sys/i386/i386/trap.c:219 #3 0x80d6886c in calltrap () at /usr/src/sys/i386/i386/exception.s:168 #4 0x80a26955 in _rw_wlock_hard (rw=0x8d18fac0, tid=2285360576, file=0x80f68ceb "/usr/src/sys/netinet/tcp_usrreq.c", line=732) at cpufunc.h:294 #5 0x80a274d6 in _rw_wlock (rw=0x8d18fac0, file=0x80f68ceb "/usr/src/sys/netinet/tcp_usrreq.c", line=732) at /usr/src/sys/kern/kern_rwlock.c:240 #6 0x80bdf585 in tcp_usr_rcvd (so=0x8bff1820, flags=64) at /usr/src/sys/netinet/tcp_usrreq.c:732 #7 0x80a9cf63 in soreceive_stream (so=0x8bff1820, psa=0x0, uio=0xdc33ec10, mp0=0xdc33ec44, controlp=0x0, flagsp=0xdc33ec40) at /usr/src/sys/kern/uipc_socket.c:2097 #8 0x80a9a6c9 in soreceive (so=0x8bff1820, psa=0x0, uio=0xdc33ec10, mp0=0xdc33ec44, controlp=0x0, flagsp=0xdc33ec40) at /usr/src/sys/kern/uipc_socket.c:2309 #9 0x91165e14 in nbssn_recv (nbp=0x874a49c0, mpp=0xdc33ec98, lenp=0xdc33ec64, rpcodep=0xdc33ec6b "", td=0x8837d5c0) at /usr/src/sys/modules/smbfs/../../netsmb/smb_trantcp.c:378 #10 0x91165fee in smb_nbst_recv (vcp=0x8961ae00, mpp=0xdc33ec98, td=0x8837d5c0) at /usr/src/sys/modules/smbfs/../../netsmb/smb_trantcp.c:598 #11 0x9116bda1 in smb_iod_recvall (iod=0x88c64980) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:305 #12 0x9116c82c in smb_iod_thread (arg=0x88c64980) at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:645 #13 0x809fa7a8 in fork_exit (callout=0x9116c600 , arg=0x88c64980, frame=0xdc33ed28) at /usr/src/sys/kern/kern_fork.c:1029 #14 0x80d68914 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 (kgdb) fr 7 #7 0x80a9cf63 in soreceive_stream (so=0x8bff1820, psa=0x0, uio=0xdc33ec10, mp0=0xdc33ec44, controlp=0x0, flagsp=0xdc33ec40) at /usr/src/sys/kern/uipc_socket.c:2097 2097 (*so->so_proto->pr_usrreqs->pru_rcvd)(so, flags); (kgdb) l 2092 if ((so->so_proto->pr_flags & PR_WANTRCVD) && 2093 (((flags & MSG_WAITALL) && uio->uio_resid > 0) || 2094 !(flags & MSG_SOCALLBCK))) { 2095 SOCKBUF_UNLOCK(sb); 2096 VNET_SO_ASSERT(so); 2097 (*so->so_proto->pr_usrreqs->pru_rcvd)(so, flags); 2098 SOCKBUF_LOCK(sb); 2099 } 2100 } 2101 (kgdb) p sb $6 = (struct sockbuf *) 0x8bff1874 (kgdb) p uio->uio_resid $7 = 0 I think that after draining mbufs in the "Dequeue as many mbufs as possible" part, and if there is still data in the socket buffer, we have to update sb_lastrecord (as it is done in soreceive_generic). See the attached patch. -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=uipc_socket.c.soreceive_stream.2.patch Index: sys/kern/uipc_socket.c =================================================================== --- sys/kern/uipc_socket.c (revision 225405) +++ sys/kern/uipc_socket.c (working copy) @@ -2041,6 +2041,8 @@ sb->sb_mb = m; if (sb->sb_mb == NULL) SB_EMPTY_FIXUP(sb); + else if (sb->sb_mb->m_nextpkt == NULL) + sb->sb_lastrecord = sb->sb_mb; n->m_next = NULL; } /* Copy the remainder. */ --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 20:18:28 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 B4F78106566B for ; Mon, 5 Sep 2011 20:18:28 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8ED938FC15 for ; Mon, 5 Sep 2011 20:18:28 +0000 (UTC) Received: by pzk33 with SMTP id 33so15207096pzk.18 for ; Mon, 05 Sep 2011 13:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GDGZWpDkb4LtfKaEEnTCrcq+V/7p6QLJoS5/FRteZuY=; b=eCa/umDuE8pMJMLA64SMcxo0cDXN2XKdp8ouHGxqf2WC613W4wPWAVCbQgT6F8eAku /dhN+d3dp1DAcfuy9xpY5OgTf6wAbWxxYCkWPOmYEhKUwvQZoSSqUGu88UmAxz2liq1w 7J9+Jq+x07T5OmyZqRpRz1+scgWGN78JEI6T8= MIME-Version: 1.0 Received: by 10.68.13.169 with SMTP id i9mr8437708pbc.195.1315253907734; Mon, 05 Sep 2011 13:18:27 -0700 (PDT) Received: by 10.142.131.15 with HTTP; Mon, 5 Sep 2011 13:18:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Sep 2011 16:18:27 -0400 Message-ID: From: Arnaud Lacombe To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: No IPFW binary compat across versions ? 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, 05 Sep 2011 20:18:28 -0000 Hi, On Mon, Sep 5, 2011 at 3:14 PM, K. Macy wrote: > -STABLE only implies that the ABI does not change during that release > line. It makes no guarantees when moving from one branch to the next. > IIUC, FreeBSD does not provide binary backward compatibility between version at all, is that it ? Thanks, - Arnaud > On Mon, Sep 5, 2011 at 8:31 PM, Arnaud Lacombe wrote= : >> Hi, >> >> It would seem that the ipfw binary from a 7.4 install is not >> compatible with the in-kernel implementation of ipfw from 8-STABLE. >> The following command returns junk: >> >> # uname -a >> FreeBSD =A08.2-STABLE FreeBSD 8.2-STABLE #0: Mon Sep =A05 13:26:22 EDT 2= 011 >> >> # ipfw show >> 65535 79609572473438209 9528064790723821568 count ip from any to any >> # ipfw show >> 65535 80229898894966785 10211949650127093760 skipto 20069 ip from any to= any >> # ipfw show >> 65535 81461570961408001 11566216593050435584 divert 20069 ip from any to= any >> # ipfw show >> 65535 81826462792941569 11967688918742073344 tee 20069 ip from any to an= y >> # ipfw show >> 65535 85659197118611457 16196106284901072896 =A0altq ?<301> ip from any = to any >> # ipfw show >> 65535 86531998897668097 17160025365645623296 ** unrecognized action 64 >> len 19 =A0ip from any to any >> # ipfw show >> 65535 127737816351244289 7272335601653776384 ** unrecognized action >> 158 len 19 =A0ip from any to any >> >> However as the 8-STABLE kernel have COMPAT_FREEBSD7 enabled, I would >> not expect this to happen... >> >> Thanks, >> =A0- Arnaud >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 21:44: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 346B4106566B; Mon, 5 Sep 2011 21:44:49 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0724B8FC0C; Mon, 5 Sep 2011 21:44:48 +0000 (UTC) Received: by pzk33 with SMTP id 33so15308311pzk.18 for ; Mon, 05 Sep 2011 14:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rjWeUQEqqKb7EeoRBIYetGr95qwuDuoKKQ1B176HbN4=; b=PbkzhuI9FfYooeZ/lvMS49LcCx0Wt2pLXBmuOlU3nwmKAGOUPL9m9nVYEiEMgF8Zh9 7/H1SkzNAXSqigzH69CY1QIlJWnLbdFCBzvaeSznVgjht8ZWH2V/9Y8ljLapsyKr9TaA XyTng59T/ChRoymWmLrOOtt4T4JM8KElD5jaU= MIME-Version: 1.0 Received: by 10.68.46.67 with SMTP id t3mr1229258pbm.61.1315259088498; Mon, 05 Sep 2011 14:44:48 -0700 (PDT) Received: by 10.142.131.15 with HTTP; Mon, 5 Sep 2011 14:44:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Sep 2011 17:44:48 -0400 Message-ID: From: Arnaud Lacombe To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: No IPFW binary compat across versions ? 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, 05 Sep 2011 21:44:49 -0000 Hi, On Mon, Sep 5, 2011 at 4:18 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 3:14 PM, K. Macy wrote: >> -STABLE only implies that the ABI does not change during that release >> line. It makes no guarantees when moving from one branch to the next. >> > IIUC, FreeBSD does not provide binary backward compatibility between > version at all, is that it ? > I guess the answer is "NO", on the same system: # netstat -m netstat: memstat_mtl_find: zone mbuf_jumbo_pagesize not found It would seem that COMPAT_FREEBSD7 is just as useful as is eyes powder on a scare-crow... - Arnaud > Thanks, > =A0- Arnaud > >> On Mon, Sep 5, 2011 at 8:31 PM, Arnaud Lacombe wrot= e: >>> Hi, >>> >>> It would seem that the ipfw binary from a 7.4 install is not >>> compatible with the in-kernel implementation of ipfw from 8-STABLE. >>> The following command returns junk: >>> >>> # uname -a >>> FreeBSD =A08.2-STABLE FreeBSD 8.2-STABLE #0: Mon Sep =A05 13:26:22 EDT = 2011 >>> >>> # ipfw show >>> 65535 79609572473438209 9528064790723821568 count ip from any to any >>> # ipfw show >>> 65535 80229898894966785 10211949650127093760 skipto 20069 ip from any t= o any >>> # ipfw show >>> 65535 81461570961408001 11566216593050435584 divert 20069 ip from any t= o any >>> # ipfw show >>> 65535 81826462792941569 11967688918742073344 tee 20069 ip from any to a= ny >>> # ipfw show >>> 65535 85659197118611457 16196106284901072896 =A0altq ?<301> ip from any= to any >>> # ipfw show >>> 65535 86531998897668097 17160025365645623296 ** unrecognized action 64 >>> len 19 =A0ip from any to any >>> # ipfw show >>> 65535 127737816351244289 7272335601653776384 ** unrecognized action >>> 158 len 19 =A0ip from any to any >>> >>> However as the 8-STABLE kernel have COMPAT_FREEBSD7 enabled, I would >>> not expect this to happen... >>> >>> Thanks, >>> =A0- Arnaud >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> > From owner-freebsd-net@FreeBSD.ORG Mon Sep 5 23:50:28 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 EECC41065675; Mon, 5 Sep 2011 23:50:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 938AF8FC08; Mon, 5 Sep 2011 23:50:28 +0000 (UTC) Received: by vxh11 with SMTP id 11so5355224vxh.13 for ; Mon, 05 Sep 2011 16:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=46re5k1r49eGBPn6PWSCIByFPOdoGAtW1ZsMvFlc4YI=; b=druuwjnuCSWi1mWZL9fHgwVELBV+AZps7F3U1IMWJvX5QxbIcuHI3lQmfQKFrCt30p /nfDd243EGm5pVWs6uOonzcjU90RBjtpEAijw4dXiVJhaxkH957lVn/zw/Ew9Z6oFsdn jijyOxeU1KMm3oehu5xz9rL+IRQSzOEDB0hew= MIME-Version: 1.0 Received: by 10.52.72.16 with SMTP id z16mr4127730vdu.395.1315266627697; Mon, 05 Sep 2011 16:50:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.52.33.49 with HTTP; Mon, 5 Sep 2011 16:50:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Sep 2011 07:50:27 +0800 X-Google-Sender-Auth: xaLP7YZKx7j2kPixns-QyLlifB0 Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, "K. Macy" Subject: Re: No IPFW binary compat across versions ? 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, 05 Sep 2011 23:50:29 -0000 That's not what the COMPAT_* hooks are for. They're for backwards compatibility of normal userland binaries, not binaries which use a FreeBSD-specific kernel ABI. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 00:18: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 493DF106564A; Tue, 6 Sep 2011 00:18:31 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 12D3E8FC18; Tue, 6 Sep 2011 00:18:31 +0000 (UTC) Received: by pzk33 with SMTP id 33so15483891pzk.18 for ; Mon, 05 Sep 2011 17:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AfrK2qLdnC1lgCRznwld5SL26l57GKyHj95yYRaIvAg=; b=YByr4aVrOXVvdRbjCVoR+4cGWAVuKF12E75lHpr6RKOZvaLfyWVMKS/HD4TXvVFEvC UV0SOsJ1OhSzulp7AJ9ecjaan+386V3vpfND9M0KmzDMJ8lg8z1UuBl9mzWu1MD4+If2 VtPiuVUvuQUWrsiYD9jm69T3yOsGw3m7uOc6A= MIME-Version: 1.0 Received: by 10.68.66.161 with SMTP id g1mr8716436pbt.396.1315268310777; Mon, 05 Sep 2011 17:18:30 -0700 (PDT) Received: by 10.142.131.15 with HTTP; Mon, 5 Sep 2011 17:18:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Sep 2011 20:18:30 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, "K. Macy" Subject: Re: No IPFW binary compat across versions ? 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, 06 Sep 2011 00:18:31 -0000 Hi, On Mon, Sep 5, 2011 at 7:50 PM, Adrian Chadd wrote: > That's not what the COMPAT_* hooks are for. > > They're for backwards compatibility of normal userland binaries, not > binaries which use a FreeBSD-specific kernel ABI. > What do you define as "normal" and where do you draw the line ? >From my point of view, I should be able to run a FreeBSD 9.0 kernel (when released) on top of a FreeBSD 5 userland without such issues. That's what backward compatibility is. _Every_ piece of the ABI exposed by the kernel[0] should be kept compatible, even funky behavior userland might ends up relying on. However, if as you say, you (the committers folks) willingly break the exposed ABI, well, sorry, but that can no longer be called "backward compatible"... That said, this has turned out of context. Now, to come back to my original issue, how am I supposed to track down cross-release issue ? swap storage ? [sic...] Regards, - Arnaud [0]: ... with very few exception, such are security issue when there is no other choices available. From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 00:44:04 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 9F8271065672; Tue, 6 Sep 2011 00:44:04 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF988FC12; Tue, 6 Sep 2011 00:44: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 p860i44k028054; Tue, 6 Sep 2011 00:44:04 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p860i4rH028050; Tue, 6 Sep 2011 00:44:04 GMT (envelope-from yongari) Date: Tue, 6 Sep 2011 00:44:04 GMT Message-Id: <201109060044.p860i4rH028050@freefall.freebsd.org> To: yoitsmeremember@gmail.com, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/160442: [vlan] Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish. 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, 06 Sep 2011 00:44:04 -0000 Synopsis: [vlan] Packets transmitted on vlan(4) interfaces with a parent vge(4) vanish. State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Sep 6 00:43:02 UTC 2011 State-Changed-Why: It seems parent interface vge(4) thinks it does not have established link. vge(4) actively keeps track of current link state and it does not try to send packets when it lost link. Unlike other drivers, vge(4) relies on its PHY hardware generates an interrupt on link status change. If the PHY failed to generate interrupt for link establishment, parent device may not see the update link status. To experiment this, try unplug the UTP cable and replug it and see whether that makes any difference for you. I'd also like to know your PHY hardware and controller revision so post dmesg and "pciconf -lcbv" output. I failed to reproduce the issue on my VIA VT6130 PCIe controller though. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Sep 6 00:43:02 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=160442 From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 00:45:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CD162106564A; Tue, 6 Sep 2011 00:45:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id DBAA614DD8D; Tue, 6 Sep 2011 00:45:37 +0000 (UTC) Message-ID: <4E656D30.3040905@FreeBSD.org> Date: Mon, 05 Sep 2011 17:45:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.1) Gecko/20110901 Thunderbird/6.0.1 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: No IPFW binary compat across versions ? 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, 06 Sep 2011 00:45:38 -0000 On 09/05/2011 17:18, Arnaud Lacombe wrote: > From my point of view, I should be able to run a FreeBSD 9.0 kernel > (when released) on top of a FreeBSD 5 userland without such issues. Unfortunately your expectation is completely unrealistic. We do our best to maintain backward compatibility but sometimes improvements require breaking the KBI/ABI. Also, we have never supported running a kernel from RELENG_N on anything older than the latest version of RELENG_{N-1}. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 03:07: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 B85FE106566C for ; Tue, 6 Sep 2011 03:07:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2F13F8FC0A for ; Tue, 6 Sep 2011 03:07:22 +0000 (UTC) Received: from c122-106-165-191.carlnfd1.nsw.optusnet.com.au (c122-106-165-191.carlnfd1.nsw.optusnet.com.au [122.106.165.191]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p8637Kes004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 13:07:21 +1000 Date: Tue, 6 Sep 2011 13:07:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Arnaud Lacombe In-Reply-To: Message-ID: <20110906121821.I3398@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Adrian Chadd , "K. Macy" Subject: Re: No IPFW binary compat across versions ? 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, 06 Sep 2011 03:07:29 -0000 On Mon, 5 Sep 2011, Arnaud Lacombe wrote: > On Mon, Sep 5, 2011 at 7:50 PM, Adrian Chadd wrote: >> That's not what the COMPAT_* hooks are for. >> >> They're for backwards compatibility of normal userland binaries, not >> binaries which use a FreeBSD-specific kernel ABI. >> > What do you define as "normal" and where do you draw the line ? It's hard to say, and probably undocumented, but system-y programs should be the only unnormal ones. Until about 10 years ago, anything using kinfo broke every other day with a binary change to struct kinfo_proc, but this was mostly fixed so kinfo only breaks every couple of major releases. Using sysctls instead of kmem significantly increased the portability of statistics utilities like systat and netstat, so they only break across every 1 and a half major releases (new features don't work of course). I run kernels between FreeBSD-4 and FreeBSD-9-current-6-months ago under a FreeBSD-5 userland with only the following changes: - hack signal handling for FreeBSD-4 compatibility in otherwise FreeBSD-5 userland. - static linkage throughout (except in ports, which are mostly not not even installed except under FreeBSD-5 (FreeBSD-4 ports)). No dll hell. - scripts to select a working binary. E.g., for ps: % #!/bin/sh % % case "$(uname -m)-$(uname -r)" in % amd64-8.*-*) p=/c/tmp/rela/;; % i386-9.*-*) p=/c/tmp/rel9/;; % i386-8.*-*) p=/c/tmp/relc/;; % i386-[6-7].*-*) p=/c/tmp/rel6/;; % *) p=/;; % esac % exec "$p"bin/ps "$@" I only need a few binaries to work on all kernels, and add a script like the above, or lines to an old script as necessary. The above shows the FreeBSD-6 ps working for FreeBSD-5 and FreeBSD-7 on i386 and ps only needed under FreeBSD-8 for amd64. My list of system-scripts is: % atacontrol % bsdtar # not really system-y; minor portability problems % fdisk % fstat % ifconfig % kdump % killall % mdconfig % mount # mostly not needed, and also not used for mounting root % mount_msdosfs # all mount utils mostly not needed, and never should be % mount_ntfs % netstat # this breaks too often % nfsstat % pmccontrol # FreeBSD-5 doesn't even have pmc % pmcstat # but pmc changed within major releases and I only have old vers % ps % pstat % rpc.lockd % systat # surprisingly binary-compatible (same binaries for 6-7 and 8-9) % top # as binary-compatible as systat % vmstat # even more binary-compatible (6 binary for i386 works on 6-9) % w >> From my point of view, I should be able to run a FreeBSD 9.0 kernel > (when released) on top of a FreeBSD 5 userland without such issues. > That's what backward compatibility is. _Every_ piece of the ABI > exposed by the kernel[0] should be kept compatible, even funky > behavior userland might ends up relying on. Keeping the ABI compatible is not easy, and mostly wasn't attempted except for simple syscalls in FreeBSD until about 10 years ago. /etc/rc.d stuff tends to be a bit broken. No new features anyway. I mostly use FreeBSD >5 in my amd64 laptop which could use some new features, but I avoid some problems by not using any special power saving kernel or userland features on it at all. This laptop mostly gets used for benchmarking new kernels and libm. It nfs-mounts /c from an i386 FreeBSD-5 system, and gets some amd64 binaries from there. (I should use i386 binaries nfs/mounted from the FreeBSD-5 system more, but haven't investigated this. Only much the same system-y binaries should have a machine-dependence that stops the i386 version from working.) > [0]: ... with very few exception, such are security issue when there > is no other choices available. My old userland must have many security problems. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 04:24:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4FD106564A for ; Tue, 6 Sep 2011 04:24:37 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2A25F8FC12 for ; Tue, 6 Sep 2011 04:24:36 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p8642KXB092808 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Sep 2011 21:02:21 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E659B67.6070203@freebsd.org> Date: Mon, 05 Sep 2011 21:02:47 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "K. Macy" Subject: Re: No IPFW binary compat across versions ? 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, 06 Sep 2011 04:24:37 -0000 On 9/5/11 2:44 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 4:18 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 5, 2011 at 3:14 PM, K. Macy wrote: >>> -STABLE only implies that the ABI does not change during that release >>> line. It makes no guarantees when moving from one branch to the next. >>> >> IIUC, FreeBSD does not provide binary backward compatibility between >> version at all, is that it ? >> > I guess the answer is "NO", on the same system: > > # netstat -m > netstat: memstat_mtl_find: zone mbuf_jumbo_pagesize not found > > It would seem that COMPAT_FREEBSD7 is just as useful as is eyes powder > on a scare-crow... > > - Arnaud > That is not quite correct. WE do not guarantee interfaces that are used for system configuration etc. Interfaces used in normal data processing applications we try very hard to keep stable, It is assumed that applications that use the system administration interfaces will come with the system. for example I can run a "make world" in a chroot populated with freebsd 1.1 and it actually works (after a few minor tweeks) (actually I last tested this at 8.1 ).. required a change of PID_MAX in the kernel config file and a.out compatibility From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 10:07:43 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 02F861065670 for ; Tue, 6 Sep 2011 10:07:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id B984B8FC12 for ; Tue, 6 Sep 2011 10:07:42 +0000 (UTC) Received: by yib19 with SMTP id 19so4561664yib.13 for ; Tue, 06 Sep 2011 03:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=43SbXz+VTFAAlZ81dcU8xLAtgM94qBm33tCzkecOhek=; b=PFpPNYYxB5A7N+rzQ4BqWBQqPeX6Z6nD7bNuIDmWFXc7RUe7A17X1CPeBpyUxl8jX3 g/z7645rRXzV9jPkSgXLLXzgbzA96BJ/H6Oj6vAJ/5ruPL/apWrGYD6dCxdWMqBNXRoo mNeVBJ3Pufo+jCOn7qoW9RWe6H+Bi7ddkfOFE= MIME-Version: 1.0 Received: by 10.236.187.2 with SMTP id x2mr22262216yhm.95.1315303661957; Tue, 06 Sep 2011 03:07:41 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.103.6 with HTTP; Tue, 6 Sep 2011 03:07:41 -0700 (PDT) In-Reply-To: <201109021954.p82Jsiap056591@freefall.freebsd.org> References: <201109021954.p82Jsiap056591@freefall.freebsd.org> Date: Tue, 6 Sep 2011 18:07:41 +0800 X-Google-Sender-Auth: I3p5GKuHgapdi1K6PrOcLQBsQng Message-ID: From: Adrian Chadd To: Edgar Martinez Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/160391: [ieee80211] [patch] Panic in mesh mode 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, 06 Sep 2011 10:07:43 -0000 Hi Edgar, Can you please provide; * A dmesg, just so we can see what/how many radios; * what do you mean by "create two mesh nodes" - do you mean two mesh nodes on the same board, one on each radio? Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 10:54: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 E67AF106566B for ; Tue, 6 Sep 2011 10:54:06 +0000 (UTC) (envelope-from kmacybsd@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 A3D6A8FC08 for ; Tue, 6 Sep 2011 10:54:06 +0000 (UTC) Received: by vxh11 with SMTP id 11so5744872vxh.13 for ; Tue, 06 Sep 2011 03:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Qm7Eh3VZww3FwEU/xwy7NIm/TRs133G4bz1jETMo9FI=; b=vOq3Mbcsm0EQ2EQD3YDKd+ygqVtrCNY4meuNGdKYxaQXChbOiblgDEN32JQ87oQVLG 16l8PB7L1gGX8Malr/mp4URSD90BvoDgG/WHXsk4h44Hl7b54YJeXJpOifWhjS67J06t kkVp6TSpNDYgr6s2AaG0UUx1Cc+GyknQZvNJc= MIME-Version: 1.0 Received: by 10.52.184.10 with SMTP id eq10mr1708975vdc.96.1315306445998; Tue, 06 Sep 2011 03:54:05 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.169 with HTTP; Tue, 6 Sep 2011 03:54:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Sep 2011 12:54:05 +0200 X-Google-Sender-Auth: seRnzMmCHWFPu49ukPkyaToGBKQ Message-ID: From: "K. Macy" To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: No IPFW binary compat across versions ? 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, 06 Sep 2011 10:54:07 -0000 On Mon, Sep 5, 2011 at 11:44 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 4:18 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 5, 2011 at 3:14 PM, K. Macy wrote: >>> -STABLE only implies that the ABI does not change during that release >>> line. It makes no guarantees when moving from one branch to the next. >>> >> IIUC, FreeBSD does not provide binary backward compatibility between >> version at all, is that it ? >> > I guess the answer is "NO", on the same system: > Netstat depends on specific structures in kernel memory, ipfw depends on specific ioctls whose arguments may vary. Netstat in particular breaks on head on a quasi daily basis because of changes to networking structures. STABLE implies STABLE for things that depend on libc and are not dependent on obscure kernel interfaces. There is some work going on (off and on) to decouple netstat from kvm which would fix that. N-1 compatibility for ipfw is probably possible, anything more than that is probably infeasible from an interface tracking standpoint. From owner-freebsd-net@FreeBSD.ORG Tue Sep 6 15:55:05 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 195201065670; Tue, 6 Sep 2011 15:55:05 +0000 (UTC) (envelope-from emartinez@kbcnetworks.com) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by mx1.freebsd.org (Postfix) with ESMTP id B3C548FC12; Tue, 6 Sep 2011 15:55:04 +0000 (UTC) Received: from mail183-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Sep 2011 15:40:02 +0000 Received: from mail183-ch1 (localhost.localdomain [127.0.0.1]) by mail183-ch1-R.bigfish.com (Postfix) with ESMTP id 97BD8410109; Tue, 6 Sep 2011 15:40:02 +0000 (UTC) X-SpamScore: -12 X-BigFish: VPS-12(zz9371K542M4015Lzz1202hzz8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:65.55.171.153; KIP:(null); UIP:(null); IPVD:NLI; H:va3diahub021.RED001.local; RD:smtp801.microsoftonline.com; EFVD:NLI Received-SPF: pass (mail183-ch1: domain of kbcnetworks.com designates 65.55.171.153 as permitted sender) client-ip=65.55.171.153; envelope-from=emartinez@kbcnetworks.com; helo=va3diahub021.RED001.local ; RED001.local ; Received: from mail183-ch1 (localhost.localdomain [127.0.0.1]) by mail183-ch1 (MessageSwitch) id 1315323600351131_16832; Tue, 6 Sep 2011 15:40:00 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail183-ch1.bigfish.com (Postfix) with ESMTP id 4FCD7570051; Tue, 6 Sep 2011 15:40:00 +0000 (UTC) Received: from va3diahub021.RED001.local (65.55.171.153) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 6 Sep 2011 15:39:58 +0000 Received: from VA3DIAXVS881.RED001.local ([10.8.235.7]) by va3diahub021.RED001.local ([10.32.21.21]) with mapi; Tue, 6 Sep 2011 08:39:59 -0700 From: Edgar Martinez To: Adrian Chadd Date: Tue, 6 Sep 2011 08:39:56 -0700 Thread-Topic: kern/160391: [ieee80211] [patch] Panic in mesh mode Thread-Index: AcxsfNKhgcuy1EpyTZmSL73Gak7CzwALTmEQ Message-ID: <957EB052144AA64AB39F7AB26878320101217C54A9@VA3DIAXVS881.RED001.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: kbcnetworks.com X-Mailman-Approved-At: Tue, 06 Sep 2011 16:03:45 +0000 Cc: "freebsd-net@freebsd.org" , "freebsd-bugs@freebsd.org" Subject: RE: kern/160391: [ieee80211] [patch] Panic in mesh mode 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, 06 Sep 2011 15:55:05 -0000 V2lsbCBwcm92aWRlIGR1bXBzIHNvb24uDQoNCkJ1dCB5ZXMsIGVmZmVjdGl2ZWx5LCB0d28gcGh5 c2ljYWwgcmFkaW9zIG9uIGEgc2luZ2xlIGJvYXJkLg0KDQpFYWNoIGNvbmZpZ3VyZWQgaW4gbWVz aCBtb2RlLiANCg0KV2hlbiB0aGV5IGFyZSBib3RoIGNvbmZpZ3VyZWQgdGhlIHNhbWUgKGNoYW5u ZWwvbWVzaGlkL2V0YyksIGFuZCBzZWUgZWFjaCBvdGhlciwgYmFkIHRoaW5ncyBoYXBwZW4uIC0g RWFzeSBmaXggaXMgdG8gTUFDIGZpbHRlci4NCg0KV2hlbiB0aGV5IGFyZSBib3RoIGNvbmZpZ3Vy ZWQgZGlmZmVyZW50bHkgKGNoYW5uZWwvbWVzaGlkL2V0YyksIGFuZCBzZWUgZWFjaCBvdGhlciwg dmlhIHRoZSBuZXR3b3JrLCBiYWQgdGhpbmdzIGhhcHBlbi4gLSBFYXN5IGZpeCBpcyB0byBNQUMg ZmlsdGVyLg0KDQpJbnRlcmVzdGluZyBwaGVub21lbmEgSSBhbSB0cmFja2luZyBkb3duLi4uc29t ZXRpbWVzIHRoZSBsb2NhbCBhbmQgcGVlciBhZGRyZXNzZXMgYXJlIHRocmVlIGNoYXJhY3RlcnMg dnMgZm91ci4uLmFuZCB0aGVuIG9mIGNvdXJzZSBpdHMgYjBya2VELi4uYSByZWJvb3Qgc29tZXRp bWVzIGNsZWFucyBpdCByaWdodCB1cCwgYW5kIHRoaW5ncyBydW4uLi4NCg0KRmluYWxseSwgdGhl cmUncyBubyBtZWNoYW5pc20gdG8gbWFudWFsbHkgZmx1c2ggb3V0IHRoZSBtZXNoIGluZm8sIHll dCwgc28gSSBhbHNvIG5vdGljZWQgdGhhdCBpdCBhcHBlYXJzIHRoZSByb3V0ZXMganVzdCBzdG9w IHVwZGF0aW5nLi4uDQoNCkkndmUgYmVlbiB0b28gYnVzeSB0byByb290IGNhdXNlIG1hbnkgaXNz dWVzLCBhbmQgaGF2ZSBvbmx5IGZvY3VzZWQgb24gdGhlIHNob3ctc3RvcHBlcnMuLi5idXQgSSBy ZWFsbHkgbmVlZCB0by4uLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBh ZHJpYW4uY2hhZGRAZ21haWwuY29tIFttYWlsdG86YWRyaWFuLmNoYWRkQGdtYWlsLmNvbV0gT24g QmVoYWxmIE9mIEFkcmlhbiBDaGFkZA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA2LCAyMDEx IDM6MDggQU0NClRvOiBFZGdhciBNYXJ0aW5leg0KQ2M6IGZyZWVic2QtYnVnc0BmcmVlYnNkLm9y ZzsgZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcNClN1YmplY3Q6IFJlOiBrZXJuLzE2MDM5MTogW2ll ZWU4MDIxMV0gW3BhdGNoXSBQYW5pYyBpbiBtZXNoIG1vZGUNCg0KSGkgRWRnYXIsDQoNCkNhbiB5 b3UgcGxlYXNlIHByb3ZpZGU7DQoNCiogQSBkbWVzZywganVzdCBzbyB3ZSBjYW4gc2VlIHdoYXQv aG93IG1hbnkgcmFkaW9zOw0KKiB3aGF0IGRvIHlvdSBtZWFuIGJ5ICJjcmVhdGUgdHdvIG1lc2gg bm9kZXMiIC0gZG8geW91IG1lYW4gdHdvIG1lc2gNCm5vZGVzIG9uIHRoZSBzYW1lIGJvYXJkLCBv bmUgb24gZWFjaCByYWRpbz8NCg0KVGhhbmtzLA0KDQoNCkFkcmlhbg0KDQo= From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 04:16:23 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 B82F51065672; Wed, 7 Sep 2011 04:16:23 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5F74B8FC23; Wed, 7 Sep 2011 04:16:23 +0000 (UTC) Received: by ywa17 with SMTP id 17so1210251ywa.13 for ; Tue, 06 Sep 2011 21:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9GyG8vrqcSzlNRNx/80pkXsXDv6IM4EPLZRKIXVNhn0=; b=AltqxnLbInZD+O62iJu5ADHkVJdWx0aIzRVOVN/CAOwjtlGFHOAzIXmczXTNCa8XTg 0A4APgxrMBj2xVQVAU744q2daK2fKdXTmQAv+ngxuDoDDgagtd0PDRNLVz53tlCe8iM5 k19FRMNBHnzIn95sTgVPUn54w9vSSV17/CZRM= MIME-Version: 1.0 Received: by 10.68.21.197 with SMTP id x5mr9634823pbe.42.1315368982260; Tue, 06 Sep 2011 21:16:22 -0700 (PDT) Received: by 10.142.232.15 with HTTP; Tue, 6 Sep 2011 21:16:22 -0700 (PDT) In-Reply-To: <4E656D30.3040905@FreeBSD.org> References: <4E656D30.3040905@FreeBSD.org> Date: Wed, 7 Sep 2011 00:16:22 -0400 Message-ID: From: Arnaud Lacombe To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: No IPFW binary compat across versions ? 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, 07 Sep 2011 04:16:23 -0000 Hi, On Mon, Sep 5, 2011 at 8:45 PM, Doug Barton wrote: > On 09/05/2011 17:18, Arnaud Lacombe wrote: >> From my point of view, I should be able to run a FreeBSD 9.0 kernel >> (when released) on top of a FreeBSD 5 userland without such issues. > > Unfortunately your expectation is completely unrealistic. > Completely unrealistic ? Seriously, you've got to be kidding me ? I just downloaded a 4 (_four_) years old OpenWRT image, built the latest Linux kernel in development and it worked just fine. netstat(8) works just fine, I can pick a random iptables tutorial on the net, and it still works fine. Those binaries are 4 years old and still work, oh and I can go back at will to the original 2.6.19 without issue. Now, let's see FreeBSD. Beside the issues included in that thread, the latest development are the following: if you boot a FreeBSD 8-STABLE kernel, with a 7.4 userland, then reboot on a 7-STABLE kernel, the system will no longer boot, even in single user. Why ? because fsck_ufs(8) crashes on a SIGFPE. I'll avoid commenting further. Anyway, now I'll be obliged to re-install (well, find the motivation first) if I want to be able to track down the mbuf corruption in FreeBSD 7-STABLE I already reported. Happy bikeshed coloring, - Arnaud > We do our best > to maintain backward compatibility but sometimes improvements require > breaking the KBI/ABI. > > Also, we have never supported running a kernel from RELENG_N on anything > older than the latest version of RELENG_{N-1}. > > > hth, > > Doug > > -- > > =A0 =A0 =A0 =A0Nothin' ever doesn't change, but nothin' changes much. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- OK Go > > =A0 =A0 =A0 =A0Breadth of IT experience, and depth of knowledge in the DN= S. > =A0 =A0 =A0 =A0Yours for the right price. =A0:) =A0http://SupersetSolutio= ns.com/ > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 05:05: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 24A071065678; Wed, 7 Sep 2011 05:05:44 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8678FC19; Wed, 7 Sep 2011 05:05:42 +0000 (UTC) Received: by vws14 with SMTP id 14so6596936vws.37 for ; Tue, 06 Sep 2011 22:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ckw4V7TVdUwysDlTBKr5n8CF3zuHVxXJAM0UWiF2foE=; b=uN+Ns0yQXIuObl+r5dadUkZUfzWGjmwBTKuv1+9J5AOP1nYlyrNiAliHVeJF4zpGG6 nBRvgryT0rz4zM0X4tRyLtnfZFYKoCgCuL8f0PlYhoaEysHZ6SOva+GUdYZu48IIYcvu GY2aKzrUBzPgSwJhRbbSzaZ6sIlKE3/MKR5tM= MIME-Version: 1.0 Received: by 10.52.20.228 with SMTP id q4mr5529538vde.498.1315371942393; Tue, 06 Sep 2011 22:05:42 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.169 with HTTP; Tue, 6 Sep 2011 22:05:42 -0700 (PDT) In-Reply-To: References: <4E656D30.3040905@FreeBSD.org> Date: Wed, 7 Sep 2011 07:05:42 +0200 X-Google-Sender-Auth: _1xgBUaKKknwCr8qWRh17pyzUBo Message-ID: From: "K. Macy" To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd , Doug Barton Subject: Re: No IPFW binary compat across versions ? 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, 07 Sep 2011 05:05:44 -0000 On Wed, Sep 7, 2011 at 6:16 AM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 8:45 PM, Doug Barton wrote: >> On 09/05/2011 17:18, Arnaud Lacombe wrote: >>> From my point of view, I should be able to run a FreeBSD 9.0 kernel >>> (when released) on top of a FreeBSD 5 userland without such issues. >> >> Unfortunately your expectation is completely unrealistic. >> > Completely unrealistic ? Seriously, you've got to be kidding me ? > > I just downloaded a 4 (_four_) years old OpenWRT image, built the > latest Linux kernel in development and it worked just fine. netstat(8) > works just fine, I can pick a random iptables tutorial on the net, and > it still works fine. Those binaries are 4 years old and still work, oh > and I can go back at will to the original 2.6.19 without issue. > Interesting. I remember binaries routinely breaking with minor glibc changes, such that in the linux community it was accepted that dynamic linking was "a bad thing". However, it is entirely possible that they've grown up in the mean time while we've stood still. From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 05:56:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EE8106564A; Wed, 7 Sep 2011 05:56:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 73AE38FC14; Wed, 7 Sep 2011 05:56:52 +0000 (UTC) Received: by ywa17 with SMTP id 17so1265402ywa.13 for ; Tue, 06 Sep 2011 22:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1p2TRFosYThpTaluJFhlWLz3J9glbNl5/DTsdxlu+ew=; b=S8aJLc2IpmWxDQr+JlPjO0YIzYwY78dlRF72bH33A9bvuGkqpOOXHKV20g/oEdMgCU yaxTGn5vGY95YBz+t8INMYkdd0uLEqQ8tJF/MHGRBIKPtVGX6zp0OhQ5tyA7yG5h3wsk BeBQEyF6DZNEIZngGvM1fubfilLmRyjde+XtE= MIME-Version: 1.0 Received: by 10.236.200.137 with SMTP id z9mr29442953yhn.27.1315375011695; Tue, 06 Sep 2011 22:56:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.103.6 with HTTP; Tue, 6 Sep 2011 22:56:51 -0700 (PDT) In-Reply-To: References: <4E656D30.3040905@FreeBSD.org> Date: Wed, 7 Sep 2011 13:56:51 +0800 X-Google-Sender-Auth: 9qz2gD09r2PnxqCHv_6u4F2Xu7I Message-ID: From: Adrian Chadd To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Doug Barton , Arnaud Lacombe Subject: Re: No IPFW binary compat across versions ? 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, 07 Sep 2011 05:56:53 -0000 Try running an updated udev on an older kernel, because you're using PVM virtualisation but don't want to deal with the latest kernels. Useless, but all the current distributions use the latest udev, so require up to date kernels. A bunch of linux stuff "works" across large swaths of time because a bunch of those things are text files in /proc. FreeBSD could do this for a variety of things, but: * someone has to do the legwork (define a public API and versioning scheme for it), then write the code, then convert the utilities, then handle backwards compatibility (eg by providing read-only methods for earlier API versions, defining what the default behaviour should be for older versions that are missing the newer features) * someone has to champion getting it into the tree * someone has to keep it up to date Just please keep in mind the current method (hi KVM access) allows for things like reading the current routing table from a crashdump using the same tools you're using on a live system. You'd likely have to come up with a unified API for accessing both live data and crashed kernel data. That's not out of the question, it'll just take some time.) If you'd like to do it, I bet everyone will cheer you on. Honest :) Adrian From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 07:17:28 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 D7CA2106566B; Wed, 7 Sep 2011 07:17:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A691B8FC16; Wed, 7 Sep 2011 07:17:28 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p877HMWC098605 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 00:17:25 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E671A9D.2030902@freebsd.org> Date: Wed, 07 Sep 2011 00:17:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Vlad Galu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "Bjoern A. Zeeb" , Hiroki Sato , "Alexander V. Chernikov" , freebsd-net@freebsd.org Subject: Re: FIB separation 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, 07 Sep 2011 07:17:28 -0000 On 7/16/11 5:43 AM, Vlad Galu wrote: > Hello, > > A couple of years ago, Stef Walter proposed a patch[1] that enforced the scope of routing messages. The general consesus was that the best approach would be the OpenBSD way - transporting the FIB number in the message and letting the user applications filter out unwanted messages. > > Are there any plans to tackle this before 9.0? I haven't really been following this unfortunately but I see at least part got done. (ifconfig) is there anything we need to do before 9.0 that is small but would make a big difference? (i.e. fixes, tweaks) Julian One thing that I haven't done and I only recently remembered, was the ability to have a socket inherit it's fib from the incoming connection SYN instead of from the socket opening process. (at least I am pretty sure I never got that done. (must go check)). > Thanks, > Vlad > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931_______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 08:40:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5E3F106564A; Wed, 7 Sep 2011 08:40:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f49.google.com (mail-gw0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF6E8FC16; Wed, 7 Sep 2011 08:40:00 +0000 (UTC) Received: by gwb1 with SMTP id 1so4624184gwb.36 for ; Wed, 07 Sep 2011 01:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=wN0vbdh+HxPEjKGZ9oNhHxOrLHO7l8h+x2/4xGGI4zg=; b=TOZRmm1LFsQQTX8DNE5pX+wJxePr9GzBpHd7D6LvHjvW84zzEfsU7Gum+38CooMq9M AcYoo5OBicepvXlS3jdxuJvmyXSAms6ZFy1Ze2U7lEh7TkZEubLFl90hglnREBg3mR91 2yVpCew6qi1yvRbyTdYzxi4hvXhmERRjx4/Ks= MIME-Version: 1.0 Received: by 10.236.191.101 with SMTP id f65mr30543592yhn.61.1315384800447; Wed, 07 Sep 2011 01:40:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.103.6 with HTTP; Wed, 7 Sep 2011 01:40:00 -0700 (PDT) Date: Wed, 7 Sep 2011 16:40:00 +0800 X-Google-Sender-Auth: X6X2JDqAzdAK5nMovcPSpXOoYC4 Message-ID: From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-current , freebsd-mobile@freebsd.org Subject: [ANNOUNCE] 802.11n TX aggregation support for Atheros 11n NICs 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, 07 Sep 2011 08:40:01 -0000 Hi all, I apologise up front for the cross-posting. Please redirect all future queries about this to freebsd-wireless@freebsd.org. I guess the cat is out of the bag (and it hasn't killed anyone yet.) For the last 6 or so months, the if_ath driver and net80211 802.11n support has been updated to (hopefully) be usable, both in station and hostap modes. Users could use ath(4) in -HEAD as an 11n station or hostap by just disabling ampdutx. I've been doing that successfully for a few months now at home, with respectable (> 200mbit UDP, ~ 100mbit TCP) throughput in the receive direction (as AMPDU RX now works well.) Through the gracious sponsorship of Hobnob, Inc., (and the completion of my bachelors degree in something completely unrelated to all of this!) I've dived in head-first into the 802.11n TX aggregation support. As I type this, I have an EEEPC 701 w/ an AR9280 currently spitting out a 130mbit/sec TCP stream to a Ubiquiti Routerstation Pro MIPS board w/ an AR9160 (5ghz HT/40/shortgi mode.) They're both running FreeBSD. A user asked about the state of this code on the -wireless list a couple days ago and has reported that his AR5416 based NIC is happily performing much the same way. So, since it's passed my "works for someone who isn't me!" test, I've decided to make a wider announcement. There's still a -lot- to do. Specifically (this isn't an exhaustive list): * There are locking issues with ath/net80211 which need to be resolved before this is merged back into -HEAD. * There's currently no support for HT RTS/CTS frame protection. I can add it easily enough, but I first have to add the AR5416 workarounds (8k limitation on RTS protected frames) before I can do that. * The AMPDU code is currently not sending BAR frames. This requires a little more fore-thought and net80211 reorganisation before they can be queued and sent. * Don't try to do a UDP iperf test before you establish AMPDU, or you'll fill the hardware TX queue with UDP frames and then end up with no frames available to send the ADDBA management frames. Oops! :) * The rate control module (sample) supports 11n and some basic TX aggregation stuff, but it isn't optimal. It's only "good enough" for me to not have to care about rate control causing large issues. Something needs to be done before it's merged into -HEAD - either a replacement needs to be written, or minstrel_ht needs to be ported. * There's no hardware power saving support in place at the moment. This means it'll draw a lot of power in station mode. * There's no MIMO PS support. Same caveat as the above. * adhoc, ahdemo, TDMA and IBSS modes likely won't work just yet. I'm not likely to begin looking at those until all the net80211 and ath driver changes are in place and tested. * I haven't yet added "filtered frames" support, so there's going to be a lot of packet loss in hostap mode when a station decides to go into power-saving or off-channel mode (eg to do a scan). * There are still (very) occasional TX-side hangs which I'm seeing. I'm trying to get to the bottom of this. * I've not tested this -at all- on multi-CPU/multi-core setups, primarily because I don't run freebsd+wifi on anything like that just yet. * net80211 AMPDU TX is based on QoS/WME Access Category (AC) numbers, rather than the full set of available TIDs. This is likely going to need to change (and the ieee80211 superg support tested/updated) before this can be merged into -HEAD as I've been told it's quite valid to expect multiple aggregation sessions in the same AC. What does work (what have I tested): * HT/20 and HT/40 support; * 2 and 5ghz support; * station and and hostap modes; * AR5416/AR5418, AR9160, AR9280 chipsets. I haven't tested AR9285 or AR9287 yet; * HT/20 and HT/40 interoperability support - ie, a HT/40 AP can have HT/20 and HT/40 nodes associated. 11a/11bg nodes can also associate but the current lack of HT frame protection is likely to cause significant interference; * ADDBA negotiation (with the above caveat that buffer management needs to be tidied up in my codebase, or you could end up with no TX buffers..) * ath_rate_sample knows enough about 11n and aggregation to make decent enough rate choices, but it isn't optimal by any means. * Software retransmission of aggregate frames, including doing new rate lookups so frames aren't simply retried at a bad rate. What I'm currently working on: * verifying that AR5212 series NICs haven't been broken by this. If someone has AR5210/AR5211 series PCMCIA hardware that they'd be able to send to me I'll also give them a test and verify I haven't broken them; * fixing TX side hangs; * HT protection support, w/ the AR5416 workarounds as needed; * Filtered-frame support; * More debugging and better behaviour during channel scan / off channel behaviour and during an interface reset. All of that said, it's working for me and it's working for someone else, so if you're interested in trying it out, I'm happy to take bug reports and feedback. But since I'm still actively developing it, please understand if I'm unable to provide you with a lot of personal hand-holding. If you're up for picking some area of the driver (eg porting minstrel_ht rate control, for example) then I'll be very happy to work with you to get it tested and integrated. I'll write up a Wiki page with the current state of the project and some instructions on how to do things like enable debugging, get statistics using athstats/wlanstats, TODO/issue lists and such. If you'd like to try it out, you'll need to grab it from svn://svn.freebsd.org/base/user/adrian/if_ath_tx/ . You'll have to add a few options to your kernel config: options ATH_ENABLE_11N options ATH_DEBUG options AH_DEBUG options ATH_DIAGAPI options IEEE80211_DEBUG .. the latter four are so you can actually use the debug tools. To preempt some questions - no, I have no plans to get this into 9.0-RELEASE. And no, I have no current plans to backport this to 9.X when it's stable and working: * I don't (yet) want to try and maintain two branches - 9.x and -HEAD - during active development (and this is still under active development); * There are some intrusive net80211 changes which need to occur which will break kernel ABIs and I'd to only break the ABI -once- in 9.X. That said, I do my current testing on an older -HEAD install (on the EEEPC) but compile up net80211 + ath + ath_pci as modules. This also requires you to compile up copies of athstats and wlanstats from the if_ath_tx branch in order to get debugging information. I'll post some instructions on how I achieve this as it's quite tricky to get all the correct environment variables setup so things are built correctly. Finally! I'd like to thank Hobnob, Inc. for their generous sponsorship to date! None of this would have happened without their continuing support. I'd also like to thank the ath9k/openwrt developers who have been very helpful in answering questions about how all of this holds together (including Felix Fietkau who I've been pestering incessantly with chipset, 11n and rate control questions - and we've discovered a few bugs in ath9k along the way.) Last and not least! I'd like to thank Atheros/Qualcomm and the dedicated team of (software, hardware) engineers who have been very helpful in providing me with chip documentation and reference driver source code. They've also answered questions about their hardware and helping me trace down bugs. (Yes: I did say "Atheros", "Documentation" and "Reference Driver Source." No, this isn't 2005 any longer. People still seem to think FreeBSD's ath(4) support uses a binary HAL. Go figure.) Enjoy! Adrian From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 13:22:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F16DC1065670 for ; Wed, 7 Sep 2011 13:22:37 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8C58FC16 for ; Wed, 7 Sep 2011 13:22:37 +0000 (UTC) Received: by eye4 with SMTP id 4so4523868eye.31 for ; Wed, 07 Sep 2011 06:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=+lXy+a4RqQQ9ZQqXIe4ZA2dneo0jQ8wMDMPfKWQjnnM=; b=cpFz2ffvIBlx+rO4NAaHkuWG81OgljbnQ0kiIznZzuq0dsltor/HAntLTbx+vwEcbV YwqSRX4vb9eSTGHYeWjahcmrrUvoitfm6flp/hgCshiahQG3RcMxzn7TQ/EFM/OJQWhj c34VqNfnCzQGMLzIBk80J+8afTUjUQhHyN944= Received: by 10.204.145.202 with SMTP id e10mr3288116bkv.134.1315399918312; Wed, 07 Sep 2011 05:51:58 -0700 (PDT) Received: from [192.168.66.106] ([80.253.27.98]) by mx.google.com with ESMTPS id k8sm254848bku.7.2011.09.07.05.51.56 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 05:51:57 -0700 (PDT) Message-ID: <4E6768E4.4080600@gmail.com> Date: Wed, 07 Sep 2011 16:51:48 +0400 From: Vladimir Budnev User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru_RU; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12 MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Which module contains functins(arptimer)? 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, 07 Sep 2011 13:22:38 -0000 Hello. How to determine which module contains specific functinos?. For example we have arptimer in netinet/if_ether.c. But how to find in which ko it compiles? Iv tried ls /boot/kernel/ | grep ko.symbols | xargs strings | grep -i arptimer but that didnt work :( Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 13:29:57 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 709A2106566B for ; Wed, 7 Sep 2011 13:29:57 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 358538FC13 for ; Wed, 7 Sep 2011 13:29:56 +0000 (UTC) Received: by ywa17 with SMTP id 17so216952ywa.13 for ; Wed, 07 Sep 2011 06:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B2ki3r1JQYJK8s/A6NYcsavRPP6Q0ZOkuJvE3u50Pdw=; b=AqOHkAnKRphQLS44m8Q43sFdEcMv4QFnyb0BJUqyHVBylDQfiQtEPcQrFVJj5SAiBf Al2ugvHIkD2I77GqjY4bwYKze6V2cbB+MRhQkgWPvedF0lZJNS7cuApB0H55JqI5zGGx CiwcHAGVWxPVfucov+WUTvwJZuY8AxjplNEXU= MIME-Version: 1.0 Received: by 10.150.170.10 with SMTP id s10mr4998028ybe.171.1315402196513; Wed, 07 Sep 2011 06:29:56 -0700 (PDT) Received: by 10.150.53.2 with HTTP; Wed, 7 Sep 2011 06:29:56 -0700 (PDT) In-Reply-To: <4E6768E4.4080600@gmail.com> References: <4E6768E4.4080600@gmail.com> Date: Wed, 7 Sep 2011 17:29:56 +0400 Message-ID: From: Sergey Kandaurov To: Vladimir Budnev Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Re: Which module contains functins(arptimer)? 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, 07 Sep 2011 13:29:57 -0000 On 7 September 2011 16:51, Vladimir Budnev wrote: > Hello. > > How to determine which module contains specific functinos?. For example we > have arptimer in netinet/if_ether.c. > But how to find in which ko it compiles? > Iv tried > ls /boot/kernel/ | grep ko.symbols | xargs strings | grep -i arptimer > but that didnt work :( > Try objdump -t -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 13:42:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A97EF106564A; Wed, 7 Sep 2011 13:42:02 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4605B8FC12; Wed, 7 Sep 2011 13:42:02 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1IO7-0001Uv-RC; Wed, 07 Sep 2011 17:41:59 +0400 Message-ID: <4E677479.5040903@ipfw.ru> Date: Wed, 07 Sep 2011 17:41:13 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20110120 Thunderbird/3.0.11 MIME-Version: 1.0 To: Julian Elischer References: <4E671A9D.2030902@freebsd.org> In-Reply-To: <4E671A9D.2030902@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "Bjoern A. Zeeb" , Vlad Galu , Hiroki Sato , freebsd-net@freebsd.org Subject: Re: FIB separation 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, 07 Sep 2011 13:42:02 -0000 On 07.09.2011 11:17, Julian Elischer wrote: > On 7/16/11 5:43 AM, Vlad Galu wrote: >> Hello, >> Hello! >> A couple of years ago, Stef Walter proposed a patch[1] that enforced >> the scope of routing messages. The general consesus was that the best >> approach would be the OpenBSD way - transporting the FIB number in the >> message and letting the user applications filter out unwanted messages. >> >> Are there any plans to tackle this before 9.0? > > I haven't really been following this unfortunately but I see at least > part got done. (ifconfig) Yes, it is committed as r223735 and r223741. Unfortunately this is not (directly) related to routing socket. kern/134931 still remains as it is. > > is there anything we need to do before 9.0 that is small but would make > a big difference? > (i.e. fixes, tweaks) rtsock is a great candidate :) > > Julian > > One thing that I haven't done and I only recently remembered, was the > ability to have a socket inherit > it's fib from the incoming connection SYN instead of from the socket > opening process. It is a very good idea to have such possibility but it has to be controlled at least by some sort of sysctl or even per-socket ioctl (turned off by default) > (at least I am pretty sure I never got that done. (must go check)). > > >> Thanks, >> Vlad >> >> [1] >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931_______________________________________________ >> >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> >> > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 14:06: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 D304B106564A for ; Wed, 7 Sep 2011 14:06:42 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id A7A6B8FC17 for ; Wed, 7 Sep 2011 14:06:42 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1R1Im1-000LxO-Kk; Wed, 07 Sep 2011 10:06:41 -0400 Date: Wed, 7 Sep 2011 10:06:41 -0400 From: Gary Palmer To: Vladimir Budnev Message-ID: <20110907140641.GA42938@in-addr.com> References: <4E6768E4.4080600@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6768E4.4080600@gmail.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: FreeBSD Net Subject: Re: Which module contains functins(arptimer)? 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, 07 Sep 2011 14:06:42 -0000 On Wed, Sep 07, 2011 at 04:51:48PM +0400, Vladimir Budnev wrote: > Hello. > > How to determine which module contains specific functinos?. For example > we have arptimer in netinet/if_ether.c. > But how to find in which ko it compiles? > Iv tried > ls /boot/kernel/ | grep ko.symbols | xargs strings | grep -i arptimer > but that didnt work :( > > Thanks in advance. arptimer is declared static so I doubt it will show up in linker symbol tables or via "strings". Also AFAIK we don't support loading TCP/IP as a module so its probably only compiled into the kernel itself and not available as a module. Gary From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 14:30: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 D1913106566B for ; Wed, 7 Sep 2011 14:30:16 +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 A50CD8FC14 for ; Wed, 7 Sep 2011 14:30:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p87EUG0J095765 for ; Wed, 7 Sep 2011 14:30:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p87EUGBH095764; Wed, 7 Sep 2011 14:30:16 GMT (envelope-from gnats) Date: Wed, 7 Sep 2011 14:30:16 GMT Message-Id: <201109071430.p87EUGBH095764@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Nikos Vassiliadis Cc: Subject: Re: kern/136426: [panic] spawning several dhclients in parallel panics the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nikos Vassiliadis List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 14:30:16 -0000 The following reply was made to PR kern/136426; it has been noted by GNATS. From: Nikos Vassiliadis To: bug-followup@FreeBSD.org, nvass9573@gmx.com Cc: Subject: Re: kern/136426: [panic] spawning several dhclients in parallel panics the kernel Date: Wed, 07 Sep 2011 17:23:18 +0300 Please close this PR. It must have been hardware specific. I don't have that hardware anymore. Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 14:53: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 3DDB0106564A for ; Wed, 7 Sep 2011 14:53:06 +0000 (UTC) (envelope-from melifaro@yandex-team.ru) Received: from forward10.mail.yandex.net (forward10.mail.yandex.net [IPv6:2a02:6b8:0:202::5]) by mx1.freebsd.org (Postfix) with ESMTP id B76BE8FC08 for ; Wed, 7 Sep 2011 14:53:05 +0000 (UTC) Received: from smtpcorp2.mail.yandex.net (smtpcorp2.mail.yandex.net [77.88.61.36]) by forward10.mail.yandex.net (Yandex) with ESMTP id A5ACA1023425; Wed, 7 Sep 2011 18:53:03 +0400 (MSD) Received: from smtpcorp2.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp2.mail.yandex.net (Yandex) with ESMTP id 92D55740223; Wed, 7 Sep 2011 18:53:03 +0400 (MSD) Received: from dhcp170-36-red.yandex.net (dhcp170-36-red.yandex.net [95.108.170.36]) by smtpcorp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id r3LCtMFm; Wed, 7 Sep 2011 18:53:03 +0400 Message-ID: <4E678521.7080006@yandex-team.ru> Date: Wed, 07 Sep 2011 18:52:17 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20110120 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org, jfvogel@gmail.com, melifaro@ipfw.ru Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 07 Sep 2011 15:29:47 +0000 Cc: Subject: igb/ixgbe RSS/RX queues for non-IP traffic 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, 07 Sep 2011 14:53:06 -0000 Hello list! (CC'in Jack Vogel since this is intel drivers/hardware specific question) There are some techniques for assigning network traffic to different NIC RX queues (bound to different CPUs/cores). The main problem for all techniques is avoiding any possible packet reordering in single flow. Most obvious (and most used) are described in Microsoft NDIS driver specification: Hashing is done on various tuples like: * IPv46 src/dst + TCP/UDP src/dst port for TCP/UDP * IPv46 src/dst for general IPv46 traffic igb's have a bit more options like assigning selected ethertype or TCP SYN to different queue (See section 7.1.1 of 82576EB datasheet) ixgbe (82599) goes even more far: flow director functionality permits 8K 'perfect match' filters allowing to select any subset in: * vlan * IPv46 src/dst * L4 proto * TCP/UDP/SCTP protocol ports and even 'flexible 2-byte tuple anywhere in the first 64 bytes of the packet' There are other possibilities to assign traffic to different queues in ixbge like using .1q priority filed (DCB functionality) More information can be found in sections 7.1.2 (RX queues assignment), 7.1.2.7(Flow Director), 7.7.1 (DCB) of 82599 datasheet However, there are many setups where PC can be used as platform for routing/dispatching non-IP traffic. PPPoE server is a typical example. People have to do some tricks (link aggregation, non-direct ISR) to get traffic dispatched by more than single CPU/core, but this much less efficient. I'm a bit curious: why some generic hashing mechanism based on something like 'flexible 2-byte tuple anywhere in the first 64 bytes of the packet' were not added? It can be (at least from my point of view) easily based on (for example) flow director functionality. Particularly I'm trying to figure out how can I use all this variety of filters to get MPLS traffic split to different RX queues. Maybe someone can point me to the right direction? -- Alexander V. Chernikov Yandex NOC From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 15:53: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 5FFF5106566C; Wed, 7 Sep 2011 15:53:49 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B65738FC14; Wed, 7 Sep 2011 15:53:48 +0000 (UTC) Received: by bkat8 with SMTP id t8so399511bka.13 for ; Wed, 07 Sep 2011 08:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=+rqX9+nQR2HsTUQqnS+6Rg8LUw1+XtCuP73VX+ZPpuA=; b=cvM6jbntzbBMS6ErkzsgaEd8AjFnyifwX8HBO8V4yqsqe9VB3aVFexE48BaXpmGsu7 J+5uO2Ou7Ub9nR1tl86yYKGhTYmYQRh9ijN9/n4kMsnva3sssRyXJ9nm7qbTvBAnL5wW hXW9WZA8sArvZsw+rjnGYzoPNPgylm2370KyE= Received: by 10.204.132.79 with SMTP id a15mr490642bkt.329.1315409234612; Wed, 07 Sep 2011 08:27:14 -0700 (PDT) Received: from rimwks1x64 ([92.124.13.228]) by mx.google.com with ESMTPS id y8sm605702bkb.4.2011.09.07.08.27.11 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 08:27:13 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Gary Palmer'" , "'Vladimir Budnev'" References: <4E6768E4.4080600@gmail.com> <20110907140641.GA42938@in-addr.com> In-Reply-To: <20110907140641.GA42938@in-addr.com> Date: Thu, 8 Sep 2011 00:27:07 +0900 Message-ID: <4e678d51.4819cc0a.4143.3b0a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxtZ2y4Eng7zUSSSEGderao7yONCAACludQ Content-Language: ru Cc: 'FreeBSD Net' Subject: RE: Which module contains functins(arptimer)? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 15:53:49 -0000 Arp - is a part of INET (ipv4). But arp proto can be used with any other L3 proto to resolve L2 addr = from L3 addr. TCP/IP is L4 proto and it can work without IPv4 - on IPv6. =A0 -- Rozhuk Ivan =A0=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Gary Palmer > Sent: Wednesday, September 07, 2011 11:07 PM > To: Vladimir Budnev > Cc: FreeBSD Net > Subject: Re: Which module contains functins(arptimer)? >=20 > On Wed, Sep 07, 2011 at 04:51:48PM +0400, Vladimir Budnev wrote: > > Hello. > > > > How to determine which module contains specific functinos?. For > example > > we have arptimer in netinet/if_ether.c. > > But how to find in which ko it compiles? > > Iv tried > > ls /boot/kernel/ | grep ko.symbols | xargs strings | grep -i = arptimer > > but that didnt work :( > > > > Thanks in advance. >=20 > arptimer is declared static so I doubt it will show up in linker = symbol > tables or via "strings". Also AFAIK we don't support loading TCP/IP = as > a > module so its probably only compiled into the kernel itself and not > available as a module. >=20 > Gary > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 16:41:37 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 1A9951065677; Wed, 7 Sep 2011 16:41:37 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E61D28FC1C; Wed, 7 Sep 2011 16:41:36 +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 p87Gfa7s025284; Wed, 7 Sep 2011 16:41:36 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p87GfaFO025280; Wed, 7 Sep 2011 16:41:36 GMT (envelope-from vwe) Date: Wed, 7 Sep 2011 16:41:36 GMT Message-Id: <201109071641.p87GfaFO025280@freefall.freebsd.org> To: nvass9573@gmx.com, vwe@FreeBSD.org, freebsd-net@FreeBSD.org, vwe@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/136426: [panic] spawning several dhclients in parallel panics the kernel 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, 07 Sep 2011 16:41:37 -0000 Synopsis: [panic] spawning several dhclients in parallel panics the kernel State-Changed-From-To: open->closed State-Changed-By: vwe State-Changed-When: Wed Sep 7 16:39:59 UTC 2011 State-Changed-Why: closing this per submitters request thank you for reporting, Nikos Responsible-Changed-From-To: freebsd-net->vwe Responsible-Changed-By: vwe Responsible-Changed-When: Wed Sep 7 16:39:59 UTC 2011 Responsible-Changed-Why: track http://www.freebsd.org/cgi/query-pr.cgi?pr=136426 From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 23:19: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 29EE41065675 for ; Wed, 7 Sep 2011 23:19:47 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 065368FC12 for ; Wed, 7 Sep 2011 23:19:46 +0000 (UTC) Received: by pzk33 with SMTP id 33so1301935pzk.18 for ; Wed, 07 Sep 2011 16:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fJwSO8ed6BNNX1Z0AxSHBj4gZA5WbFT/B0Wp93Y13kg=; b=ofR4233Fjg2Xg4WhgF16ziCq754IaZ4g6VvDBuQBQxyJQWBNIdUBO8rWiO76W0WVLH 6owVSWTyqiu/QMHMx25guN5098QW3H2qCKljaJLs3BAz53kXxWm+TmGshhREBbw7+eRy sbErpbc3vcleqafdHEdgi2H8BGXwIOe8bom9k= MIME-Version: 1.0 Received: by 10.68.7.170 with SMTP id k10mr16142pba.176.1315437586124; Wed, 07 Sep 2011 16:19:46 -0700 (PDT) Received: by 10.142.232.15 with HTTP; Wed, 7 Sep 2011 16:19:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 19:19:46 -0400 Message-ID: From: Arnaud Lacombe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack Vogel Subject: Re: FreeBSD 7-STABLE mbuf corruption 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, 07 Sep 2011 23:19:47 -0000 Hi, On Mon, Sep 5, 2011 at 2:59 AM, Arnaud Lacombe wrote: > Hi folks, > > We have been trying to track down a bad mbuf management for about two > weeks on a customized 7.1 base. I have finally been able to reproduce > it with a stock FreeBSD 7-STABLE (kernel from r225276, userland from > 7.4). > > With the help of the attached patches, I have just been able to > trigger the following panic: > > panic: Corrupted unused flags, expected 0xffffffff00000000, got 0x0, flags 0x3 > cpuid = 1 > Uptime: 3d10h5m3s > Cannot dump. No dump device defined > General form of the crash is: panic: Corrupted unused flags, expected 0xffffffff00000000, got 0xbabe0000000000, flags 0xbabe0000babe00 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0874e29,0,c0835757,f4574c48,0,...) at db_trace_self_wrapper+0x26 panic(c0835757,0,ffffffff,0,babe00,...) at panic+0x10b igb_txeof(c6a25008,0,c0837083,5ea,17c,...) at igb_txeof+0x399 igb_msix_que(c6a2b800,0,c084d367,4b6,c69dd068,...) at igb_msix_que+0x7b ithread_loop(c6a29090,f4574d38,c084d0db,31c,c6a16828,...) at ithread_loop+0xc3 fork_exit(c061d520,c6a29090,f4574d38) at fork_exit+0xa6 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf4574d70, ebp = 0 --- Uptime: 1m42s It happens particularly easily when the box receives wall of SYN (about 1000 cnx attempts at once) every 5s or so. - Arnaud > > [cut stuff no one cares about...] From owner-freebsd-net@FreeBSD.ORG Wed Sep 7 23:57:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0FA106564A for ; Wed, 7 Sep 2011 23:57:18 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 419AA8FC0A for ; Wed, 7 Sep 2011 23:57:17 +0000 (UTC) Received: by vws14 with SMTP id 14so317778vws.37 for ; Wed, 07 Sep 2011 16:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4JnmgbJMz0tBWzZ3uzHdIou9LlbxpqeSgZbEwJNugvg=; b=NJytfQi0YaS0aGUIlZE71g6kR4ytiY6kMFl7kZdPEd1bZY1gPz01pTY9lFvzxmb/OW u1aueYksKEwQ5pa3oXMeyff9byax1MVVT1Ia3WN/nROXwcNl1kThEcyMT1WPuu7FBtG8 gAqh0I16X0RJSJA25gib0VkLjAknvmYj+JxoU= MIME-Version: 1.0 Received: by 10.52.91.34 with SMTP id cb2mr21455vdb.244.1315439837439; Wed, 07 Sep 2011 16:57:17 -0700 (PDT) Received: by 10.52.160.170 with HTTP; Wed, 7 Sep 2011 16:57:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 7 Sep 2011 16:57:17 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7-STABLE mbuf corruption 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, 07 Sep 2011 23:57:18 -0000 I have seen this, but I don't have any hot ideas right off the top of my head yet :( Jack On Wed, Sep 7, 2011 at 4:19 PM, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 2:59 AM, Arnaud Lacombe wrote: > > Hi folks, > > > > We have been trying to track down a bad mbuf management for about two > > weeks on a customized 7.1 base. I have finally been able to reproduce > > it with a stock FreeBSD 7-STABLE (kernel from r225276, userland from > > 7.4). > > > > With the help of the attached patches, I have just been able to > > trigger the following panic: > > > > panic: Corrupted unused flags, expected 0xffffffff00000000, got 0x0, > flags 0x3 > > cpuid = 1 > > Uptime: 3d10h5m3s > > Cannot dump. No dump device defined > > > General form of the crash is: > > panic: Corrupted unused flags, expected 0xffffffff00000000, got > 0xbabe0000000000, flags 0xbabe0000babe00 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c0874e29,0,c0835757,f4574c48,0,...) at > db_trace_self_wrapper+0x26 > panic(c0835757,0,ffffffff,0,babe00,...) at panic+0x10b > igb_txeof(c6a25008,0,c0837083,5ea,17c,...) at igb_txeof+0x399 > igb_msix_que(c6a2b800,0,c084d367,4b6,c69dd068,...) at igb_msix_que+0x7b > ithread_loop(c6a29090,f4574d38,c084d0db,31c,c6a16828,...) at > ithread_loop+0xc3 > fork_exit(c061d520,c6a29090,f4574d38) at fork_exit+0xa6 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf4574d70, ebp = 0 --- > Uptime: 1m42s > > It happens particularly easily when the box receives wall of SYN > (about 1000 cnx attempts at once) every 5s or so. > > - Arnaud > > > > > [cut stuff no one cares about...] > From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 00:19: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 BE2901065672 for ; Thu, 8 Sep 2011 00:19:12 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 815D38FC17 for ; Thu, 8 Sep 2011 00:19:12 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p880Ix5P071511; Wed, 7 Sep 2011 17:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1315441139; bh=fgIvCPstyodWP4PD5+paf3r00LW2gFZ2PDR+K85Zsbs=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=TlQ6eCGdwFiAfhJ+rfpgBdVrocZxyyDr8IXB0cHR9eO53yeWcJjME8q+FpDzCthMk tk+1X0fx0OMRZzPIhNXe7SlqjZhbPcjoPHSfIHw0JC+hXLAiocn2Vhq+tbU2LQlGkL A2b5Y4NYC6eqVsLfN6VavyPdhFEBIaTReQlmvLLI= From: Sean Bruno To: Arnaud Lacombe In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Sep 2011 17:18:58 -0700 Message-ID: <1315441138.2872.13.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: FreeBSD 7-STABLE mbuf corruption 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, 08 Sep 2011 00:19:12 -0000 On Wed, 2011-09-07 at 16:19 -0700, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 5, 2011 at 2:59 AM, Arnaud Lacombe wrote: > > Hi folks, > > > > We have been trying to track down a bad mbuf management for about two > > weeks on a customized 7.1 base. I have finally been able to reproduce > > it with a stock FreeBSD 7-STABLE (kernel from r225276, userland from > > 7.4). > > > > With the help of the attached patches, I have just been able to > > trigger the following panic: > > > > panic: Corrupted unused flags, expected 0xffffffff00000000, got 0x0, flags 0x3 > > cpuid = 1 > > Uptime: 3d10h5m3s > > Cannot dump. No dump device defined > > > General form of the crash is: > > panic: Corrupted unused flags, expected 0xffffffff00000000, got > 0xbabe0000000000, flags 0xbabe0000babe00 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c0874e29,0,c0835757,f4574c48,0,...) at > db_trace_self_wrapper+0x26 > panic(c0835757,0,ffffffff,0,babe00,...) at panic+0x10b > igb_txeof(c6a25008,0,c0837083,5ea,17c,...) at igb_txeof+0x399 > igb_msix_que(c6a2b800,0,c084d367,4b6,c69dd068,...) at igb_msix_que+0x7b > ithread_loop(c6a29090,f4574d38,c084d0db,31c,c6a16828,...) at ithread_loop+0xc3 > fork_exit(c061d520,c6a29090,f4574d38) at fork_exit+0xa6 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf4574d70, ebp = 0 --- > Uptime: 1m42s > > It happens particularly easily when the box receives wall of SYN > (about 1000 cnx attempts at once) every 5s or so. > > - Arnaud > > > I swear that we squashed this last year on "Yahoo BSD" last year with Jack's help. I know that we set: hw.igb.num_queues="1" hw.igb.rxd="4096" hw.igb.txd="4096" In addition to some txeof() handling patches ... Jack can see if this is still relevant in the freebsd7 universe. Note that Yahoo is "special" and we pluck and chuck code/drivers/whatever at will so I don't know how this code will apply to stable-7 or if it has been applied already. Note that this code "rage-quits" the EIAM/EIAC auto ack strategy and tries to handle the OACTIVE state handling better. I hope these clues find you well. --- //depot/yahoo/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-11-29 20:47:23.000000000 0000 +++ /home/seanbru/ybsd_7/src/sys/dev/e1000/if_igb.c 2010-11-29 20:47:23.000000000 0000 @@ -30,7 +30,7 @@ POSSIBILITY OF SUCH DAMAGE. ******************************************************************************/ -/*$FreeBSD: src/sys/dev/e1000/if_igb.c,v 1.3.2.13 2010/11/27 01:09:54 jfv Exp $*/ +/*$FreeBSD: stable/7/sys/dev/e1000/if_igb.c 216465 2010-12-15 22:48:44Z jfv $*/ #ifdef HAVE_KERNEL_OPTION_HEADERS @@ -318,10 +318,6 @@ static bool igb_header_split = FALSE; TUNABLE_INT("hw.igb.hdr_split", &igb_header_split); -/* -** This will autoconfigure based on -** the number of CPUs if left at 0. -*/ static int igb_num_queues = 0; TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); @@ -784,10 +780,14 @@ return; /* Call cleanup if number of TX descriptors low */ +#if 0 if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) igb_txeof(txr); +#endif while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { + if (txr->tx_avail <= IGB_TX_CLEANUP_THRESHOLD) + igb_txeof(txr); if (txr->tx_avail <= IGB_TX_OP_THRESHOLD) { ifp->if_drv_flags |= IFF_DRV_OACTIVE; break; @@ -1162,10 +1162,10 @@ IGB_TX_LOCK(txr); if (igb_txeof(txr)) more = TRUE; - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) - igb_start_locked(txr, ifp); + /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Pointless as igb_start_locked() checks this right off the bat*/ + igb_start_locked(txr, ifp); IGB_TX_UNLOCK(txr); - if (more) { + if (more || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) { taskqueue_enqueue(que->tq, &que->que_task); return; } @@ -1298,15 +1298,20 @@ struct rx_ring *rxr = que->rxr; u32 newitr = 0; bool more_tx, more_rx; + struct ifnet *ifp = adapter->ifp; +#if 0 E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims); + newitr = E1000_READ_REG(&adapter->hw, E1000_EICR); +#endif + E1000_WRITE_REG(&adapter->hw, E1000_EICR, que->eims); ++que->irqs; IGB_TX_LOCK(txr); more_tx = igb_txeof(txr); IGB_TX_UNLOCK(txr); - more_rx = igb_rxeof(que, adapter->rx_process_limit, NULL); + more_rx = igb_rxeof(que, -1, NULL); if (igb_enable_aim == FALSE) goto no_calc; @@ -1361,7 +1366,7 @@ no_calc: /* Schedule a clean task if needed*/ - if (more_tx || more_rx) + if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACTIVE)) taskqueue_enqueue(que->tq, &que->que_task); else /* Reenable this interrupt */ @@ -1382,6 +1387,7 @@ struct adapter *adapter = arg; u32 icr; + E1000_WRITE_REG(&adapter->hw, E1000_EICR, adapter->link_mask); ++adapter->link_irq; icr = E1000_READ_REG(&adapter->hw, E1000_ICR); if (!(icr & E1000_ICR_LSC)) @@ -1535,6 +1541,14 @@ if (m_head->m_flags & M_VLANTAG) cmd_type_len |= E1000_ADVTXD_DCMD_VLE; +/* + * We just did this in before invocation, seems completely + * redundant, igb_handle_queue -> igb_txeof + * Pretty sure this is impossible as we check for the + * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens + * before this func in invoked + */ +#if 0 /* * Force a cleanup if number of TX descriptors * available hits the threshold @@ -1547,6 +1561,7 @@ return (ENOBUFS); } } +#endif /* * Map the packet for DMA. @@ -2082,6 +2097,7 @@ que->eims = E1000_EICR_TX_QUEUE0 << i; else que->eims = 1 << vector; + device_printf(adapter->dev, "que %d eims= 0x%x\n", i, que->eims); /* ** Bind the msix vector, and thus the ** rings to the corresponding cpu. @@ -3264,8 +3280,6 @@ case ETHERTYPE_IPV6: ip6 = (struct ip6_hdr *)(mp->m_data + ehdrlen); ip_hlen = sizeof(struct ip6_hdr); - if (mp->m_len < ehdrlen + ip_hlen) - return (FALSE); ipproto = ip6->ip6_nxt; type_tucmd_mlhl |= E1000_ADVTXD_TUCMD_IPV6; break; @@ -4461,6 +4475,24 @@ static void igb_enable_intr(struct adapter *adapter) { + uint32_t ims, regval; + + if (adapter->msix_mem) { + ims = E1000_IMS_LSC | E1000_IMS_DOUTSYNC; + regval = E1000_READ_REG(&adapter->hw, E1000_EIAC); +#if 0 + E1000_WRITE_REG(&adapter->hw, E1000_EIAC, regval | adapter->eims_mask); + regval = E1000_READ_REG(&adapter->hw, E1000_EIAM); + E1000_WRITE_REG(&adapter->hw, E1000_EIAM, regval | adapter->eims_mask); +#endif + E1000_WRITE_REG(&adapter->hw, E1000_EIMS, adapter->eims_mask); + E1000_WRITE_REG(&adapter->hw, E1000_IMS, ims); + } else { + E1000_WRITE_REG(&adapter->hw, E1000_IMS, IMS_ENABLE_MASK | E1000_IMS_DRSTA); + E1000_WRITE_REG(&adapter->hw, E1000_IAM, IMS_ENABLE_MASK | E1000_IMS_DRSTA); + } + +#if 0 /* With RSS set up what to auto clear */ if (adapter->msix_mem) { E1000_WRITE_REG(&adapter->hw, E1000_EIAC, @@ -4475,6 +4507,7 @@ E1000_WRITE_REG(&adapter->hw, E1000_IMS, IMS_ENABLE_MASK); } +#endif E1000_WRITE_FLUSH(&adapter->hw); return; @@ -4483,11 +4516,33 @@ static void igb_disable_intr(struct adapter *adapter) { + uint32_t regval; + + /* + * we need to be careful when disabling interrupts. The VFs are also + * mapped into these registers and so clearing the bits can cause + * issues on the VF drivers so we only need to clear what we set + */ + if (adapter->msix_mem) { + regval = E1000_READ_REG(&adapter->hw, E1000_EIAM); +#if 0 + E1000_WRITE_REG(&adapter->hw, E1000_EIAM, regval & ~adapter->eims_mask); + regval = E1000_READ_REG(&adapter->hw, E1000_EIAC); + E1000_WRITE_REG(&adapter->hw, E1000_EIAC, regval & ~adapter->eims_mask); +#endif + E1000_WRITE_REG(&adapter->hw, E1000_EIMC, adapter->eims_mask); + } + + E1000_WRITE_REG(&adapter->hw, E1000_IAM, 0); + E1000_WRITE_REG(&adapter->hw, E1000_IMC, ~0); + +#if 0 if (adapter->msix_mem) { E1000_WRITE_REG(&adapter->hw, E1000_EIMC, ~0); E1000_WRITE_REG(&adapter->hw, E1000_EIAC, 0); } E1000_WRITE_REG(&adapter->hw, E1000_IMC, ~0); +#endif E1000_WRITE_FLUSH(&adapter->hw); return; } @@ -4876,8 +4931,8 @@ struct sysctl_oid_list *child = SYSCTL_CHILDREN(tree); struct e1000_hw_stats *stats = adapter->stats; - struct sysctl_oid *stat_node, *queue_node, *int_node, *host_node; - struct sysctl_oid_list *stat_list, *queue_list, *int_list, *host_list; + struct sysctl_oid *stat_node, *queue_node, *int_node, *host_node, *debug_node; + struct sysctl_oid_list *stat_list, *queue_list, *int_list, *host_list, *debug_list; #define QUEUE_NAME_LEN 32 char namebuf[QUEUE_NAME_LEN]; @@ -5245,6 +5300,27 @@ SYSCTL_ADD_QUAD(ctx, host_list, OID_AUTO, "header_redir_missed", CTLFLAG_RD, &stats->hrmpc, "Header Redirection Missed Packet Count"); + + + debug_node = SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "debug", + CTLFLAG_RD, NULL, + "Debug info"); + + debug_list = SYSCTL_CHILDREN(debug_node); + + txr = adapter->tx_rings; + SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "desc_avail", + CTLFLAG_RD, (u_int *)(uintptr_t)&txr->tx_avail, 0, + ""); + + SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "next_to_clean", + CTLFLAG_RD, &txr->next_to_clean, 0, + ""); + + SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "if_flags", + CTLFLAG_RD, &adapter->ifp->if_drv_flags, 0, + ""); + } From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 00:47:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382691065674 for ; Thu, 8 Sep 2011 00:47:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1002F8FC13 for ; Thu, 8 Sep 2011 00:47:36 +0000 (UTC) Received: by pzk33 with SMTP id 33so1631376pzk.18 for ; Wed, 07 Sep 2011 17:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4Sp3GuMErurpv6su0ytkY9j6+VvsuJl183e5FrglIv4=; b=vn7vVG1cr1rNGNx4BXL1Lgnn76RGm7eReY5iXsNrfetvBww4YHdTUZ+9MywU6NWvS6 1Ewqjz5zrPSE7sE4P6mOZouwm0re0Yy94AyqaWVrpIhp1eQ9DAmm7LnkKMGP58knH+cl 4MqhAVMluSRfPwzVp1Sp7QQCEkvjs2S/LOvoc= MIME-Version: 1.0 Received: by 10.68.21.197 with SMTP id x5mr112261pbe.42.1315442856580; Wed, 07 Sep 2011 17:47:36 -0700 (PDT) Received: by 10.142.232.15 with HTTP; Wed, 7 Sep 2011 17:47:36 -0700 (PDT) In-Reply-To: <1315441138.2872.13.camel@hitfishpass-lx.corp.yahoo.com> References: <1315441138.2872.13.camel@hitfishpass-lx.corp.yahoo.com> Date: Wed, 7 Sep 2011 20:47:36 -0400 Message-ID: From: Arnaud Lacombe To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: FreeBSD 7-STABLE mbuf corruption 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, 08 Sep 2011 00:47:37 -0000 Hi, On Wed, Sep 7, 2011 at 8:18 PM, Sean Bruno wrote: > On Wed, 2011-09-07 at 16:19 -0700, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Sep 5, 2011 at 2:59 AM, Arnaud Lacombe wrot= e: >> > Hi folks, >> > >> > We have been trying to track down a bad mbuf management for about two >> > weeks on a customized 7.1 base. I have finally been able to reproduce >> > it with a stock FreeBSD 7-STABLE (kernel from r225276, userland from >> > 7.4). >> > >> > With the help of the attached patches, I have just been able to >> > trigger the following panic: >> > >> > panic: Corrupted unused flags, expected 0xffffffff00000000, got 0x0, f= lags 0x3 >> > cpuid =3D 1 >> > Uptime: 3d10h5m3s >> > Cannot dump. No dump device defined >> > >> General form of the crash is: >> >> panic: Corrupted unused flags, expected 0xffffffff00000000, got >> 0xbabe0000000000, flags 0xbabe0000babe00 >> cpuid =3D 0 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0874e29,0,c0835757,f4574c48,0,...) at >> db_trace_self_wrapper+0x26 >> panic(c0835757,0,ffffffff,0,babe00,...) at panic+0x10b >> igb_txeof(c6a25008,0,c0837083,5ea,17c,...) at igb_txeof+0x399 >> igb_msix_que(c6a2b800,0,c084d367,4b6,c69dd068,...) at igb_msix_que+0x7b >> ithread_loop(c6a29090,f4574d38,c084d0db,31c,c6a16828,...) at ithread_loo= p+0xc3 >> fork_exit(c061d520,c6a29090,f4574d38) at fork_exit+0xa6 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0, eip =3D 0, esp =3D 0xf4574d70, ebp =3D 0 --- >> Uptime: 1m42s >> >> It happens particularly easily when the box receives wall of SYN >> (about 1000 cnx attempts at once) every 5s or so. >> >> =A0- Arnaud >> >> > > > I swear that we squashed this last year on "Yahoo BSD" last year with > Jack's help. > > I know that we set: > hw.igb.num_queues=3D"1" > hw.igb.rxd=3D"4096" > hw.igb.txd=3D"4096" > Actually, as I pointed out in my original mail, when we had the issue end of last year, lowering the number of queue to 1 fixed the problem. As it did for PR/155597. However, we are now seeing this with em(4), and eventually vr(4). So this might not be igb(4) specific. Anyhow, I'll add your patch to my test kernel. Thanks, - Arnaud > In addition to some txeof() handling patches ... Jack can see if this is > still relevant in the freebsd7 universe. Note that Yahoo is "special" > and we pluck and chuck code/drivers/whatever at will so I don't know how > this code will apply to stable-7 or if it has been applied already. > > Note that this code "rage-quits" the EIAM/EIAC auto ack strategy and > tries to handle the OACTIVE state handling better. =A0I hope these clues > find you well. > > --- //depot/yahoo/ybsd_7/src/sys/dev/e1000/if_igb.c =A0 =A0 2010-11-29 > 20:47:23.000000000 0000 > +++ /home/seanbru/ybsd_7/src/sys/dev/e1000/if_igb.c =A0 =A0 2010-11-29 > 20:47:23.000000000 0000 > @@ -30,7 +30,7 @@ > =A0 POSSIBILITY OF SUCH DAMAGE. > > > *************************************************************************= *****/ > -/*$FreeBSD: src/sys/dev/e1000/if_igb.c,v 1.3.2.13 2010/11/27 01:09:54 > jfv Exp $*/ > +/*$FreeBSD: stable/7/sys/dev/e1000/if_igb.c 216465 2010-12-15 22:48:44Z > jfv $*/ > > > =A0#ifdef HAVE_KERNEL_OPTION_HEADERS > @@ -318,10 +318,6 @@ > =A0static bool igb_header_split =3D FALSE; > =A0TUNABLE_INT("hw.igb.hdr_split", &igb_header_split); > > -/* > -** This will autoconfigure based on > -** the number of CPUs if left at 0. > -*/ > =A0static int igb_num_queues =3D 0; > =A0TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); > > @@ -784,10 +780,14 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > > =A0 =A0 =A0 =A0/* Call cleanup if number of TX descriptors low */ > +#if 0 > =A0 =A0 =A0 =A0if (txr->tx_avail <=3D IGB_TX_CLEANUP_THRESHOLD) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igb_txeof(txr); > +#endif > > =A0 =A0 =A0 =A0while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (txr->tx_avail <=3D IGB_TX_CLEANUP_THRES= HOLD) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_txeof(txr); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (txr->tx_avail <=3D IGB_TX_OP_THRESHOLD= ) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifp->if_drv_flags |=3D IFF= _DRV_OACTIVE; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > @@ -1162,10 +1162,10 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IGB_TX_LOCK(txr); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (igb_txeof(txr)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0more =3D TRUE; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_start_locked(txr, ifp); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Poin= tless as > igb_start_locked() checks this right off the bat*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_start_locked(txr, ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IGB_TX_UNLOCK(txr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (more) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (more || (ifp->if_drv_flags & IFF_DRV_OA= CTIVE)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_enqueue(que->tq,= &que->que_task); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > @@ -1298,15 +1298,20 @@ > =A0 =A0 =A0 =A0struct rx_ring *rxr =3D que->rxr; > =A0 =A0 =A0 =A0u32 =A0 =A0 =A0 =A0 =A0 =A0 newitr =3D 0; > =A0 =A0 =A0 =A0bool =A0 =A0 =A0 =A0 =A0 =A0more_tx, more_rx; > + =A0 =A0 =A0 struct ifnet =A0 =A0*ifp =3D adapter->ifp; > > +#if 0 > =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims); > + =A0 =A0 =A0 newitr =3D E1000_READ_REG(&adapter->hw, E1000_EICR); > +#endif > + =A0 =A0 =A0 E1000_WRITE_REG(&adapter->hw, E1000_EICR, que->eims); > =A0 =A0 =A0 =A0++que->irqs; > > =A0 =A0 =A0 =A0IGB_TX_LOCK(txr); > =A0 =A0 =A0 =A0more_tx =3D igb_txeof(txr); > =A0 =A0 =A0 =A0IGB_TX_UNLOCK(txr); > > - =A0 =A0 =A0 more_rx =3D igb_rxeof(que, adapter->rx_process_limit, NULL)= ; > + =A0 =A0 =A0 more_rx =3D igb_rxeof(que, -1, NULL); > > =A0 =A0 =A0 =A0if (igb_enable_aim =3D=3D FALSE) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto no_calc; > @@ -1361,7 +1366,7 @@ > > =A0no_calc: > =A0 =A0 =A0 =A0/* Schedule a clean task if needed*/ > - =A0 =A0 =A0 if (more_tx || more_rx) > + =A0 =A0 =A0 if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACT= IVE)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_enqueue(que->tq, &que->que_task)= ; > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Reenable this interrupt */ > @@ -1382,6 +1387,7 @@ > =A0 =A0 =A0 =A0struct adapter =A0*adapter =3D arg; > =A0 =A0 =A0 =A0u32 =A0 =A0 =A0 =A0 =A0 =A0 icr; > > + =A0 =A0 =A0 E1000_WRITE_REG(&adapter->hw, E1000_EICR, adapter->link_mas= k); > =A0 =A0 =A0 =A0++adapter->link_irq; > =A0 =A0 =A0 =A0icr =3D E1000_READ_REG(&adapter->hw, E1000_ICR); > =A0 =A0 =A0 =A0if (!(icr & E1000_ICR_LSC)) > @@ -1535,6 +1541,14 @@ > =A0 =A0 =A0 =A0if (m_head->m_flags & M_VLANTAG) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cmd_type_len |=3D E1000_ADVTXD_DCMD_VLE; > > +/* > + * We just did this in before invocation, seems completely > + * redundant, igb_handle_queue -> igb_txeof > + * Pretty sure this is impossible as we check for the > + * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens > + * before this func in invoked > + */ > +#if 0 > =A0 =A0 =A0 =A0 /* > =A0 =A0 =A0 =A0 =A0* Force a cleanup if number of TX descriptors > =A0 =A0 =A0 =A0 =A0* available hits the threshold > @@ -1547,6 +1561,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENOBUFS); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0} > +#endif > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0* Map the packet for DMA. > @@ -2082,6 +2097,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0que->eims =3D E1000_EICR_T= X_QUEUE0 << i; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0que->eims =3D 1 << vector; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_printf(adapter->dev, "que %d eims=3D= 0x%x\n", i, > que->eims); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0** Bind the msix vector, and thus the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0** rings to the corresponding cpu. > @@ -3264,8 +3280,6 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case ETHERTYPE_IPV6: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ip6 =3D (struct ip6_hdr *)= (mp->m_data + ehdrlen); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ip_hlen =3D sizeof(struct = ip6_hdr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (mp->m_len < ehdrlen + i= p_hlen) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (FAL= SE); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ipproto =3D ip6->ip6_nxt; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type_tucmd_mlhl |=3D E1000= _ADVTXD_TUCMD_IPV6; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > @@ -4461,6 +4475,24 @@ > =A0static void > =A0igb_enable_intr(struct adapter *adapter) > =A0{ > + =A0 =A0 =A0 uint32_t ims, regval; > + > + =A0 =A0 =A0 =A0if (adapter->msix_mem) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ims =3D E1000_IMS_LSC | E1000_IMS_DOUTSY= NC; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAC); > +#if 0 > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC= , regval | > adapter->eims_mask); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAM); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAM= , regval | > adapter->eims_mask); > +#endif > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMS= , > adapter->eims_mask); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMS,= ims); > + =A0 =A0 =A0 =A0} else { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMS, > IMS_ENABLE_MASK | E1000_IMS_DRSTA); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IAM, > IMS_ENABLE_MASK | E1000_IMS_DRSTA); > + =A0 =A0 =A0 =A0} > + > +#if 0 > =A0 =A0 =A0 =A0/* With RSS set up what to auto clear */ > =A0 =A0 =A0 =A0if (adapter->msix_mem) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC, > @@ -4475,6 +4507,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMS, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IMS_ENABLE_MASK); > =A0 =A0 =A0 =A0} > +#endif > =A0 =A0 =A0 =A0E1000_WRITE_FLUSH(&adapter->hw); > > =A0 =A0 =A0 =A0return; > @@ -4483,11 +4516,33 @@ > =A0static void > =A0igb_disable_intr(struct adapter *adapter) > =A0{ > + =A0 =A0 =A0 uint32_t regval; > + > + =A0 =A0 =A0 =A0/* > + =A0 =A0 =A0 =A0 * we need to be careful when disabling interrupts. =A0T= he VFs > are also > + =A0 =A0 =A0 =A0 * mapped into these registers and so clearing the bits = can > cause > + =A0 =A0 =A0 =A0 * issues on the VF drivers so we only need to clear wha= t we > set > + =A0 =A0 =A0 =A0 */ > + =A0 =A0 =A0 =A0if (adapter->msix_mem) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAM); > +#if 0 > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAM= , regval & > ~adapter->eims_mask); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAC); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC= , regval & > ~adapter->eims_mask); > +#endif > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMC= , > adapter->eims_mask); > + =A0 =A0 =A0 =A0} > + > + =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IAM, 0); > + =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMC, ~0); > + > +#if 0 > =A0 =A0 =A0 =A0if (adapter->msix_mem) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMC, = ~0); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC, = 0); > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMC, ~0); > +#endif > =A0 =A0 =A0 =A0E1000_WRITE_FLUSH(&adapter->hw); > =A0 =A0 =A0 =A0return; > =A0} > @@ -4876,8 +4931,8 @@ > =A0 =A0 =A0 =A0struct sysctl_oid_list *child =3D SYSCTL_CHILDREN(tree); > =A0 =A0 =A0 =A0struct e1000_hw_stats *stats =3D adapter->stats; > > - =A0 =A0 =A0 struct sysctl_oid *stat_node, *queue_node, *int_node, > *host_node; > - =A0 =A0 =A0 struct sysctl_oid_list *stat_list, *queue_list, *int_list, > *host_list; > + =A0 =A0 =A0 struct sysctl_oid *stat_node, *queue_node, *int_node, > *host_node, *debug_node; > + =A0 =A0 =A0 struct sysctl_oid_list *stat_list, *queue_list, *int_list, > *host_list, *debug_list; > > =A0#define QUEUE_NAME_LEN 32 > =A0 =A0 =A0 =A0char namebuf[QUEUE_NAME_LEN]; > @@ -5245,6 +5300,27 @@ > =A0 =A0 =A0 =A0SYSCTL_ADD_QUAD(ctx, host_list, OID_AUTO, "header_redir_mi= ssed", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CTLFLAG_RD, &stats->hrmpc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Header Redirection Missed= Packet Count"); > + > + > + =A0 =A0 =A0 debug_node =3D SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "debug= ", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTL= FLAG_RD, NULL, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "De= bug info"); > + > + =A0 =A0 =A0 debug_list =3D SYSCTL_CHILDREN(debug_node); > + > + =A0 =A0 =A0 txr =3D adapter->tx_rings; > + =A0 =A0 =A0 SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "desc_avail", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTLFLAG_RD, (u_int *)(uintp= tr_t)&txr->tx_avail, > 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ""); > + > + =A0 =A0 =A0 SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "next_to_clean", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTLFLAG_RD, &txr->next_to_c= lean, 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ""); > + > + =A0 =A0 =A0 SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "if_flags", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTLFLAG_RD, &adapter->ifp->= if_drv_flags, 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ""); > + > =A0} > > > > From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 05:53:30 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D2BD106566B for ; Thu, 8 Sep 2011 05:53:30 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f179.google.com (mail-gx0-f179.google.com [209.85.161.179]) by mx1.freebsd.org (Postfix) with ESMTP id 453A18FC08 for ; Thu, 8 Sep 2011 05:53:29 +0000 (UTC) Received: by gxk1 with SMTP id 1so751203gxk.10 for ; Wed, 07 Sep 2011 22:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition; bh=tPMVcBK+fM5O6Ph/EV33dcw8HdjuBtqQjW10P+V1ITk=; b=WZ9AIxicl7wJ7y5YITwAy6cBGt+Cqe1cO7pI824DePje8OPnlM6a38alfEAIi3AwQj o7Kf8IEAqzYPcsD3KFKr/+wnJ2IZBgEicm5E8wkzjerD0DykkvLr/B9Fs4/ZezbchEVv iwIM30usUAGBs7E2AyvweA45Zae76nzIrT77g= Received: by 10.236.80.9 with SMTP id j9mr1343480yhe.94.1315459723450; Wed, 07 Sep 2011 22:28:43 -0700 (PDT) Received: from DataIX.net (adsl-99-190-81-85.dsl.klmzmi.sbcglobal.net [99.190.81.85]) by mx.google.com with ESMTPS id f63sm2464435yhj.14.2011.09.07.22.28.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 22:28:42 -0700 (PDT) Sender: "J. Hellenthal" Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p885ScIl037792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Sep 2011 01:28:39 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p885Sctt037791 for net@FreeBSD.org; Thu, 8 Sep 2011 01:28:38 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Thu, 8 Sep 2011 01:28:38 -0400 From: Jason Hellenthal To: net@FreeBSD.org Message-ID: <20110908052838.GA36011@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline Cc: Subject: Last Address on Interface Receiving RST ACK. 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, 08 Sep 2011 05:53:30 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Net, With a default setup of dc0 on 8.2-STABLE r224908 I have noticed that when the interface is configured with more than one address that the last address configured recieves RSTs & ACKs that were generated on the primary address. The configuration is like such: PF with no NAT or redirection. Default route: 192.168.1.1 ipv4_addrs_dc0="192.168.1.2/24" And then a jail brings up alias 192.168.1.100/32 I have mail pulling down to this system every 20 minutes and this is repeated every 20 minutes but not soley dependent to just this service or destination. Rule 26: block drop in log quick proto tcp from ! port < 1024 to any Keep in mind the only way I caught this is because the jail is not generating any traffic and since there is no state for that address this rule kicks in to block what should not be recieved by that address. Any help with this would be appreciated. 00:56:05.274815 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 13179, offset 0, flags [none], proto TCP (6), length 40) 91.121.XXX.XXX.443 > 192.168.1.100.33581: Flags [R.], cksum 0x0a57 (correct), seq 1397498691, ack 1491506967, win 0, length 0 00:56:49.351521 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 44594, offset 0, flags [none], proto TCP (6), length 40) 74.125.XXX.X.443 > 192.168.1.100.58794: Flags [R.], cksum 0x0268 (correct), seq 3217610262, ack 840102530, win 0, length 0 00:57:49.465331 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 49671, offset 0, flags [none], proto TCP (6), length 40) 74.125.XXX.XX.443 > 192.168.1.100.35474: Flags [R.], cksum 0x5c5e (correct), seq 3787279118, ack 1664887624, win 0, length 0 00:58:23.524232 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 54499, offset 0, flags [none], proto TCP (6), length 40) 74.125.XXX.XXX.993 > 192.168.1.100.55544: Flags [R.], cksum 0x9962 (correct), seq 1419741552, ack 2168011860, win 0, length 0 00:58:49.586119 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 61912, offset 0, flags [none], proto TCP (6), length 40) 74.125.XXX.XX.443 > 192.168.1.100.64663: Flags [R.], cksum 0xf8db (correct), seq 1228724784, ack 2559832299, win 0, length 0 00:58:51.573874 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 49850, offset 0, flags [none], proto TCP (6), length 40) 12.22.XX.XX.873 > 192.168.1.100.60330: Flags [R.], cksum 0xfcbd (correct), seq 1803075968, ack 944126062, win 0, length 0 00:59:05.594207 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 18167, offset 0, flags [none], proto TCP (6), length 40) 12.22.XX.XX.873 > 192.168.1.100.16970: Flags [R.], cksum 0x851b (correct), seq 1913818609, ack 3282631427, win 0, length 0 01:08:24.602213 rule 26/0(match): block in on dc0: (tos 0x0, ttl 254, id 19516, offset 0, flags [none], proto TCP (6), length 40) 74.125.XXX.XX.993 > 192.168.1.100.27724: Flags [R.], cksum 0xa62d (correct), seq 3861575754, ack 1373823783, win 0, length 0 --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJOaFKFAAoJEJBXh4mJ2FR+qJoH/RcrEd91ueDvHjsTEVsMNj5k EeP/NwpU2qE3NA+B3oFBQeCo2O2sVbESivbf8OfCu+JagKFkog5p0MQ2F0oASEKh gSOVLu+LHNYjGDAmmNSXrPy+k2LF0/n43aP69q+b8nl4Tfu6w2eL5sbXBIKq8ljm 4bqEorZHZ6hJNrzQjq/y+G34heqqjSztf458ep6dGG9wq2EfjHKR+Svz42jGNFYF iwdkmAwqLUQSZw1a0hXUF2JAvyfGGWoE5YZUZ/ndrNjfIbBtz+09Fs++X/8tzwcN 5j6E/ZrKB6jUGp65xAteAIU8Au+/MoFwZf7NBgbT9RDvGlaOHXbIy5qsfWymQWA= =osYO -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 08:01: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 30A1B106564A for ; Thu, 8 Sep 2011 08:01:36 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B04E68FC13 for ; Thu, 8 Sep 2011 08:01:35 +0000 (UTC) Received: by bkat8 with SMTP id t8so496515bka.13 for ; Thu, 08 Sep 2011 01:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wf3DtcOmaF/pFNTjTo3JMm8QzVZR0c1J+eoP2wcBFtA=; b=umRVseVb6wQ4LRGz+NnhxBoJ6Pd8WQi9qaywZjWhdS8QaZbM5cRzNlf6tcIxhXULjY 5go/fjfJCfwl9dfal/ELoySVYsZgswTkG8PLBhpbQ+aiRuDnFro3zpfpH77JDlXupYOk 2lIuqIYYI5Jm3S0rZdO+6zWjuSwy+91huiPqI= Received: by 10.204.133.11 with SMTP id d11mr236532bkt.291.1315468894044; Thu, 08 Sep 2011 01:01:34 -0700 (PDT) Received: from [192.168.66.106] ([80.253.27.98]) by mx.google.com with ESMTPS id y8sm1901607bkb.4.2011.09.08.01.01.32 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 01:01:33 -0700 (PDT) Message-ID: <4E687653.6040000@gmail.com> Date: Thu, 08 Sep 2011 12:01:23 +0400 From: Vladimir Budnev User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru_RU; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12 MIME-Version: 1.0 To: Gary Palmer References: <4E6768E4.4080600@gmail.com> <20110907140641.GA42938@in-addr.com> In-Reply-To: <20110907140641.GA42938@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Which module contains functins(arptimer)? 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, 08 Sep 2011 08:01:36 -0000 On 09/07/11 18:06, Gary Palmer wrote: > On Wed, Sep 07, 2011 at 04:51:48PM +0400, Vladimir Budnev wrote: >> Hello. >> >> How to determine which module contains specific functinos?. For example >> we have arptimer in netinet/if_ether.c. >> But how to find in which ko it compiles? >> Iv tried >> ls /boot/kernel/ | grep ko.symbols | xargs strings | grep -i arptimer >> but that didnt work :( >> >> Thanks in advance. > arptimer is declared static so I doubt it will show up in linker symbol > tables or via "strings". Also AFAIK we don't support loading TCP/IP as a > module so its probably only compiled into the kernel itself and not > available as a module. > > Gary Ok, roger that. Thank you for answers From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 08:12:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C972F106566B; Thu, 8 Sep 2011 08:12:18 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 726D48FC1B; Thu, 8 Sep 2011 08:12:17 +0000 (UTC) Received: by qyk4 with SMTP id 4so182944qyk.13 for ; Thu, 08 Sep 2011 01:12:17 -0700 (PDT) Received: by 10.229.66.197 with SMTP id o5mr263906qci.162.1315469537154; Thu, 08 Sep 2011 01:12:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.187.212 with HTTP; Thu, 8 Sep 2011 01:11:37 -0700 (PDT) In-Reply-To: <1315221674.3092.282.camel@deadeye> References: <1315221674.3092.282.camel@deadeye> From: Takuya ASADA Date: Thu, 8 Sep 2011 17:11:37 +0900 Message-ID: To: Ben Hutchings Content-Type: text/plain; charset=UTF-8 Cc: jfv@freebsd.org, freebsd-net@freebsd.org Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 08:12:18 -0000 Hi, 2011/9/5 Ben Hutchings : > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >> Hi, >> >> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: >> >> - Adding removing signature filter >> On linux version of ixgbe driver, it has ability to set/remove perfect >> filter from userland using ethtool command. >> I implemented similar feature, but on sysctl, and not perfect filter >> but signature filter(which means hash collision may occurs). > [...] > > Linux also has a generic interface to RX filtering and hashing > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > to support something like that? > > Ben. Linux implement it on ethtool command, what should we do? Maybe a new option for ifconfig, or provide new command for it? From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 09:20:22 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 D418F106566B for ; Thu, 8 Sep 2011 09:20:22 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3828FC08 for ; Thu, 8 Sep 2011 09:20:22 +0000 (UTC) Received: by fxe4 with SMTP id 4so1816832fxe.13 for ; Thu, 08 Sep 2011 02:20:21 -0700 (PDT) Received: by 10.223.85.154 with SMTP id o26mr766791fal.72.1315472162954; Thu, 08 Sep 2011 01:56:02 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id h5sm1059132fae.13.2011.09.08.01.56.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 01:56:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: Date: Thu, 8 Sep 2011 10:55:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1315221674.3092.282.camel@deadeye> To: Takuya ASADA X-Mailer: Apple Mail (2.1244.3) Cc: freebsd-net@freebsd.org Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 09:20:22 -0000 On Sep 8, 2011, at 10:11 AM, Takuya ASADA wrote: > Hi, >=20 > 2011/9/5 Ben Hutchings : >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >>> Hi, >>>=20 >>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a = detail: >>>=20 >>> - Adding removing signature filter >>> On linux version of ixgbe driver, it has ability to set/remove = perfect >>> filter from userland using ethtool command. >>> I implemented similar feature, but on sysctl, and not perfect filter >>> but signature filter(which means hash collision may occurs). >> [...] >>=20 >> Linux also has a generic interface to RX filtering and hashing >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for = FreeBSD >> to support something like that? >>=20 >> Ben. >=20 > Linux implement it on ethtool command, what should we do? > Maybe a new option for ifconfig, or provide new command for it? I for one would love to see this functionality built into ifconfig. = Linux always seems to have one tool too many. There's ifconfig, = iproute2, route, mii-tool and ethtool. From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 13:46:54 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 D911D1065675; Thu, 8 Sep 2011 13:46:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ADD908FC13; Thu, 8 Sep 2011 13:46:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5833D46B0A; Thu, 8 Sep 2011 09:46:54 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D38C58A02F; Thu, 8 Sep 2011 09:46:53 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 8 Sep 2011 08:34:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <1315221674.3092.282.camel@deadeye> In-Reply-To: <1315221674.3092.282.camel@deadeye> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201109080834.11607.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 08 Sep 2011 09:46:53 -0400 (EDT) Cc: Ben Hutchings , Takuya ASADA , jfv@freebsd.org, Navdeep Parhar Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 13:46:54 -0000 On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > Hi, > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > > > - Adding removing signature filter > > On linux version of ixgbe driver, it has ability to set/remove perfect > > filter from userland using ethtool command. > > I implemented similar feature, but on sysctl, and not perfect filter > > but signature filter(which means hash collision may occurs). > [...] > > Linux also has a generic interface to RX filtering and hashing > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > to support something like that? Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers both provide their own tools to manipulate filters, though they do not provide explicit steering IIRC. We would need to come up with some sort of standard interface (ioctls?) for adding filters however. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 14:13: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 0C56B1065672; Thu, 8 Sep 2011 14:13:20 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id D65AF8FC08; Thu, 8 Sep 2011 14:13:19 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 07:13:18 -0700 From: Ben Hutchings To: John Baldwin Date: Thu, 08 Sep 2011 15:13:13 +0100 In-Reply-To: <201109080834.11607.jhb@freebsd.org> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2- Content-Transfer-Encoding: 7bit Message-ID: <1315491196.23168.33.camel@deadeye> Mime-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 14:13:19.0143 (UTC) FILETIME=[758B7B70:01CC6E31] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18372.005 X-TM-AS-Result: No--17.794300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Takuya ASADA , freebsd-net@freebsd.org, jfv@freebsd.org, Navdeep Parhar Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 14:13:20 -0000 On Thu, 2011-09-08 at 08:34 -0400, John Baldwin wrote: > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > > Hi, > > > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > > > > > - Adding removing signature filter > > > On linux version of ixgbe driver, it has ability to set/remove perfect > > > filter from userland using ethtool command. > > > I implemented similar feature, but on sysctl, and not perfect filter > > > but signature filter(which means hash collision may occurs). > > [...] > > > > Linux also has a generic interface to RX filtering and hashing > > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > to support something like that? > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > both provide their own tools to manipulate filters, though they do not > provide explicit steering IIRC. > > We would need to come up with some sort of standard interface (ioctls?) for > adding filters however. On Linux, filtering and steering are supported on the Freescale TSEC/FEC (gianfar), Intel Niantic (ixgbe), Solarflare (sfc) and Sun Neptune (niu) hardware. The exact capabilities of the hardware are all quite different and we're still recovering from the early mistake of defining two subtly different interfaces. I believe several other 10G Ethernet vendors have implemented these sorts of hardware capabilities. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 14:35:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89D11065670 for ; Thu, 8 Sep 2011 14:35:59 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 794CD8FC12 for ; Thu, 8 Sep 2011 14:35:59 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 07:35:58 -0700 From: Ben Hutchings To: Vlad Galu Date: Thu, 08 Sep 2011 15:35:53 +0100 In-Reply-To: References: <1315221674.3092.282.camel@deadeye> Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2- Content-Transfer-Encoding: 7bit Message-ID: <1315492556.23168.45.camel@deadeye> Mime-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 14:35:58.0810 (UTC) FILETIME=[9FF833A0:01CC6E34] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18372.005 X-TM-AS-Result: No--19.508400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Takuya ASADA , freebsd-net@freebsd.org Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 14:35:59 -0000 On Thu, 2011-09-08 at 10:55 +0200, Vlad Galu wrote: > On Sep 8, 2011, at 10:11 AM, Takuya ASADA wrote: > > Hi, > > > > 2011/9/5 Ben Hutchings : > >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > >>> Hi, > >>> > >>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > >>> > >>> - Adding removing signature filter > >>> On linux version of ixgbe driver, it has ability to set/remove perfect > >>> filter from userland using ethtool command. > >>> I implemented similar feature, but on sysctl, and not perfect filter > >>> but signature filter(which means hash collision may occurs). > >> [...] > >> > >> Linux also has a generic interface to RX filtering and hashing > >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > >> to support something like that? > >> > >> Ben. > > > > Linux implement it on ethtool command, what should we do? > > Maybe a new option for ifconfig, or provide new command for it? > > I for one would love to see this functionality built into ifconfig. > Linux always seems to have one tool too many. There's ifconfig, > iproute2, route, mii-tool and ethtool. The current tools are iproute2 (replacing ifconfig and route) and ethtool. mii-tool might still be useful for debugging a 10M or 100M driver, but ethtool can display anything an administrator would be interested in. Now you could quite reasonably say that the improvements made in iproute2 ought to have been done without creating a new command. But it is not true that all these different commands are required. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 14:38: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 3199D106566B for ; Thu, 8 Sep 2011 14:38:53 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id BE48A8FC18 for ; Thu, 8 Sep 2011 14:38:52 +0000 (UTC) Received: by eye4 with SMTP id 4so548620eye.31 for ; Thu, 08 Sep 2011 07:38:51 -0700 (PDT) Received: by 10.223.97.214 with SMTP id m22mr732246fan.29.1315492731512; Thu, 08 Sep 2011 07:38:51 -0700 (PDT) Received: from [192.168.10.3] ([82.76.253.74]) by mx.google.com with ESMTPS id s13sm1473268fad.18.2011.09.08.07.38.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 07:38:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Vlad Galu In-Reply-To: <1315492556.23168.45.camel@deadeye> Date: Thu, 8 Sep 2011 16:38:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1315221674.3092.282.camel@deadeye> <1315492556.23168.45.camel@deadeye> To: Ben Hutchings X-Mailer: Apple Mail (2.1244.3) Cc: Takuya ASADA , freebsd-net@freebsd.org Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 14:38:53 -0000 On Sep 8, 2011, at 4:35 PM, Ben Hutchings wrote: > On Thu, 2011-09-08 at 10:55 +0200, Vlad Galu wrote: >> On Sep 8, 2011, at 10:11 AM, Takuya ASADA wrote: >>> Hi, >>>=20 >>> 2011/9/5 Ben Hutchings : >>>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >>>> [...] >>>>=20 >>>> Linux also has a generic interface to RX filtering and hashing >>>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for = FreeBSD >>>> to support something like that? >>>>=20 >>>> Ben. >>>=20 >>> Linux implement it on ethtool command, what should we do? >>> Maybe a new option for ifconfig, or provide new command for it? >>=20 >> I for one would love to see this functionality built into ifconfig. >> Linux always seems to have one tool too many. There's ifconfig, >> iproute2, route, mii-tool and ethtool. >=20 > The current tools are iproute2 (replacing ifconfig and route) and > ethtool. mii-tool might still be useful for debugging a 10M or 100M > driver, but ethtool can display anything an administrator would be > interested in. >=20 > Now you could quite reasonably say that the improvements made in > iproute2 ought to have been done without creating a new command. But = it > is not true that all these different commands are required. >=20 > Ben. You're right, I didn't mean that, only that, sometimes, diversity isn't = necessarily a good thing. From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 14:48: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 128DC1065707; Thu, 8 Sep 2011 14:48:27 +0000 (UTC) (envelope-from kmacybsd@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 8D61E8FC13; Thu, 8 Sep 2011 14:48:26 +0000 (UTC) Received: by vxi39 with SMTP id 39so659514vxi.13 for ; Thu, 08 Sep 2011 07:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FsKeXPjM7TYfto9iqWcVGqvvPAthWhfTYgX0jvoow8Q=; b=B2OgapadFjuP+B5vgYTDt8EsG4taoky9eTqDp5OLq0q7sm8OUUvlUQfl6B/s1QnhnB Ye9yyMI6Wg7vgnxSudsFFS3sHoWlwo4Ic0j41NzG3QbGpQQiUUEgJzmZTeGEc2XUwosa Gzmpt7zDJbCLWRtOKszzQbb2Ud03xduBUItzg= MIME-Version: 1.0 Received: by 10.52.90.37 with SMTP id bt5mr772895vdb.364.1315493305745; Thu, 08 Sep 2011 07:48:25 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.169 with HTTP; Thu, 8 Sep 2011 07:48:25 -0700 (PDT) In-Reply-To: <201109080834.11607.jhb@freebsd.org> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> Date: Thu, 8 Sep 2011 16:48:25 +0200 X-Google-Sender-Auth: lCxXXFzOrKzeOff--jMk_wVtv_I Message-ID: From: "K. Macy" To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ben Hutchings , freebsd-net@freebsd.org, jfv@freebsd.org, Navdeep Parhar , Takuya ASADA Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 14:48:27 -0000 On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >> > Hi, >> > >> > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a det= ail: >> > >> > - Adding removing signature filter >> > On linux version of ixgbe driver, it has ability to set/remove perfect >> > filter from userland using ethtool command. >> > I implemented similar feature, but on sysctl, and not perfect filter >> > but signature filter(which means hash collision may occurs). >> [...] >> >> Linux also has a generic interface to RX filtering and hashing >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD >> to support something like that? > > Some sort of shared interface might be nice. =A0The cxgb(4) and cxgbe(4) = drivers > both provide their own tools to manipulate filters, though they do not > provide explicit steering IIRC. > > We would need to come up with some sort of standard interface (ioctls?) f= or > adding filters however. I know this must sound like nitpicking, but please don't add more ioctls if you can avoid it. If you want to add new interfaces try to stick with sysctl as it tends to be less prone to breakage across releases. The biggest problem in defining a new API is the lack of anyone with a global overview of the functionality provided by NIC vendors and their near-term roadmaps. It doesn't make sense to add an API that we only know works for one or two vendors. Cheers From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 16:01: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 0207F1065672; Thu, 8 Sep 2011 16:01:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C90488FC13; Thu, 8 Sep 2011 16:01:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 64B2346B23; Thu, 8 Sep 2011 12:01:43 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EE29B8A02E; Thu, 8 Sep 2011 12:01:42 -0400 (EDT) From: John Baldwin To: "K. Macy" Date: Thu, 8 Sep 2011 11:06:40 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201109080834.11607.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109081106.40714.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 08 Sep 2011 12:01:43 -0400 (EDT) Cc: Ben Hutchings , freebsd-net@freebsd.org, jfv@freebsd.org, Navdeep Parhar , Takuya ASADA Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 16:01:44 -0000 On Thursday, September 08, 2011 10:48:25 am K. Macy wrote: > On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: > > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > >> > Hi, > >> > > >> > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > >> > > >> > - Adding removing signature filter > >> > On linux version of ixgbe driver, it has ability to set/remove perfect > >> > filter from userland using ethtool command. > >> > I implemented similar feature, but on sysctl, and not perfect filter > >> > but signature filter(which means hash collision may occurs). > >> [...] > >> > >> Linux also has a generic interface to RX filtering and hashing > >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > >> to support something like that? > > > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > > both provide their own tools to manipulate filters, though they do not > > provide explicit steering IIRC. > > > > We would need to come up with some sort of standard interface (ioctls?) for > > adding filters however. > > I know this must sound like nitpicking, but please don't add more > ioctls if you can avoid it. If you want to add new interfaces try to > stick with sysctl as it tends to be less prone to breakage across > releases. Passing strings in via sysctls isn't an ideal interface. Passing in some sort of structure via ioctl would be far more typical, and it is possible to provide API compat since the size of the structure is encoded in the ioctl itself. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 16:21: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 48D9F1065672; Thu, 8 Sep 2011 16:21:21 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 229F98FC0A; Thu, 8 Sep 2011 16:21:20 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 09:21:20 -0700 From: Ben Hutchings To: John Baldwin In-Reply-To: <201109081106.40714.jhb@freebsd.org> References: <201109080834.11607.jhb@freebsd.org> <201109081106.40714.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Thu, 08 Sep 2011 17:21:17 +0100 Message-ID: <1315498877.2804.10.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2011 16:21:20.0562 (UTC) FILETIME=[58070120:01CC6E43] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18372.005 X-TM-AS-Result: No--30.412700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Takuya ASADA , freebsd-net@freebsd.org, jfv@freebsd.org, "K. Macy" , Navdeep Parhar Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 16:21:21 -0000 On Thu, 2011-09-08 at 11:06 -0400, John Baldwin wrote: > On Thursday, September 08, 2011 10:48:25 am K. Macy wrote: > > On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: > > > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > >> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > >> > Hi, > > >> > > > >> > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > >> > > > >> > - Adding removing signature filter > > >> > On linux version of ixgbe driver, it has ability to set/remove perfect > > >> > filter from userland using ethtool command. > > >> > I implemented similar feature, but on sysctl, and not perfect filter > > >> > but signature filter(which means hash collision may occurs). > > >> [...] > > >> > > >> Linux also has a generic interface to RX filtering and hashing > > >> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > >> to support something like that? > > > > > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > > > both provide their own tools to manipulate filters, though they do not > > > provide explicit steering IIRC. > > > > > > We would need to come up with some sort of standard interface (ioctls?) for > > > adding filters however. > > > > I know this must sound like nitpicking, but please don't add more > > ioctls if you can avoid it. If you want to add new interfaces try to > > stick with sysctl as it tends to be less prone to breakage across > > releases. > > Passing strings in via sysctls isn't an ideal interface. Passing in some sort > of structure via ioctl would be far more typical, and it is possible to provide > API compat since the size of the structure is encoded in the ioctl itself. Whatever the mechanism is, the interface should allow for: - Flexible matching on layer 2, 3 and 4 header fields - Masking out some bits before matching (e.g. ignoring priority bits of VLAN tag or least significant bits of IPv4 address) - Priority of rules in case several match a single flow. This may need to be combined with location, since in a TCAM location may determine priority. - Requesting packets to be dropped, steered to a single RX queue, or steered to a range of RX queues (using a flow hash and indirection table) - Use of multiple hash indirection tables Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 16:28:23 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 E543D1065670; Thu, 8 Sep 2011 16:28:23 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDF228FC18; Thu, 8 Sep 2011 16:28:22 +0000 (UTC) Received: by ewy1 with SMTP id 1so533147ewy.13 for ; Thu, 08 Sep 2011 09:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JtHzWBhFaBsbyn4iJ26Y7T1x5K+/CUkY9p0Yo0UUVAQ=; b=tVJYY/a1FyoAlPeh17crmk4bdsU0rCXn3liiRtjDYuaBHkmKlTsTcYvPKMpazpFifx licevF7oFfAKWzKItLcQKyv8bzOUTN7DzkayYfP2f6jU3lzr5i7FRAIw3zsFy+I56Pht dlil6V5pHsnMqJA7GPO1n7GXWtk9WnlH4o8uM= MIME-Version: 1.0 Received: by 10.52.96.227 with SMTP id dv3mr965970vdb.230.1315499301480; Thu, 08 Sep 2011 09:28:21 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.169 with HTTP; Thu, 8 Sep 2011 09:28:21 -0700 (PDT) In-Reply-To: <1315498877.2804.10.camel@bwh-desktop> References: <201109080834.11607.jhb@freebsd.org> <201109081106.40714.jhb@freebsd.org> <1315498877.2804.10.camel@bwh-desktop> Date: Thu, 8 Sep 2011 18:28:21 +0200 X-Google-Sender-Auth: QrW52a0a4jANXgxaBjDW7HiIBf8 Message-ID: From: "K. Macy" To: Ben Hutchings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Takuya ASADA , freebsd-net@freebsd.org, jfv@freebsd.org, John Baldwin , Navdeep Parhar Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 16:28:24 -0000 > Whatever the mechanism is, the interface should allow for: > > - Flexible matching on layer 2, 3 and 4 header fields > - Masking out some bits before matching (e.g. ignoring priority bits of > =A0VLAN tag or least significant bits of IPv4 address) > - Priority of rules in case several match a single flow. =A0This may > =A0need to be combined with location, since in a TCAM location may > =A0determine priority. > - Requesting packets to be dropped, steered to a single RX queue, or > =A0steered to a range of RX queues (using a flow hash and indirection > =A0table) > - Use of multiple hash indirection tables Do you feel that the Linux API for this is the right place to start looking? Earlier you said: "The exact capabilities of the hardware are all quite different and we're still recovering from the early mistake of defining two subtly different interfaces." Have the two APIs been unified, if not which one do you believe is the "right" one? Cheers From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 17:27:43 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 F23E4106564A; Thu, 8 Sep 2011 17:27:42 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id CB9648FC0C; Thu, 8 Sep 2011 17:27:42 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 10:27:42 -0700 From: Ben Hutchings To: "K. Macy" In-Reply-To: References: <201109080834.11607.jhb@freebsd.org> <201109081106.40714.jhb@freebsd.org> <1315498877.2804.10.camel@bwh-desktop> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Thu, 08 Sep 2011 18:27:39 +0100 Message-ID: <1315502859.2804.14.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2011 17:27:42.0357 (UTC) FILETIME=[9D5CB450:01CC6E4C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18372.005 X-TM-AS-Result: No--18.630900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Takuya ASADA , freebsd-net@freebsd.org, jfv@freebsd.org, John Baldwin , Navdeep Parhar Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 17:27:43 -0000 On Thu, 2011-09-08 at 18:28 +0200, K. Macy wrote: > > Whatever the mechanism is, the interface should allow for: > > > > - Flexible matching on layer 2, 3 and 4 header fields > > - Masking out some bits before matching (e.g. ignoring priority bits of > > VLAN tag or least significant bits of IPv4 address) > > - Priority of rules in case several match a single flow. This may > > need to be combined with location, since in a TCAM location may > > determine priority. > > - Requesting packets to be dropped, steered to a single RX queue, or > > steered to a range of RX queues (using a flow hash and indirection > > table) > > - Use of multiple hash indirection tables > > Do you feel that the Linux API for this is the right place to start > looking? You can certainly learn from the mistakes made in Linux. :-) > Earlier you said: "The exact capabilities of the hardware > are all quite > different and we're still recovering from the early mistake of > defining two subtly different interfaces." Have the two APIs been > unified, if not which one do you believe is the "right" one? RX NFC is the right one. The other one (RX n-tuple) will be removed once I've converted the sfc driver to use RX NFC. It isn't flexible enough to cover the full matching capabilities and it doesn't allow for requesting steering + hashing, although I'm hoping to extend it to cover that later. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 18:49:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id B3BA91065672; Thu, 8 Sep 2011 18:49:28 +0000 (UTC) Date: Thu, 8 Sep 2011 18:49:28 +0000 From: Navdeep Parhar To: John Baldwin Message-ID: <20110908184928.GA87872@hub.freebsd.org> Mail-Followup-To: John Baldwin , freebsd-net@freebsd.org, Ben Hutchings , Takuya ASADA , jfv@freebsd.org References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201109080834.11607.jhb@freebsd.org> User-Agent: Mutt/1.4.2.1i Cc: Ben Hutchings , freebsd-net@freebsd.org, jfv@freebsd.org, Takuya ASADA Subject: Re: Adding Flow Director sysctls to ixgbe(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: Thu, 08 Sep 2011 18:49:28 -0000 On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: > On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > > Hi, > > > > > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > > > > > - Adding removing signature filter > > > On linux version of ixgbe driver, it has ability to set/remove perfect > > > filter from userland using ethtool command. > > > I implemented similar feature, but on sysctl, and not perfect filter > > > but signature filter(which means hash collision may occurs). > > [...] > > > > Linux also has a generic interface to RX filtering and hashing > > (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > to support something like that? > > Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > both provide their own tools to manipulate filters, though they do not > provide explicit steering IIRC. Both of them can filter as well as steer (and the tools let you do that). cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those features are perhaps too specialized to be configurable via a general purpose tool. > > We would need to come up with some sort of standard interface (ioctls?) for > adding filters however. +1 for a standard interface. imho the kernel needs to be aware of the rx and tx queues of a NIC, and not just for steering. But that's a separate discussion. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 19:04: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 88EB6106566B for ; Thu, 8 Sep 2011 19:04:36 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-gw0-f49.google.com (mail-gw0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id 4675B8FC13 for ; Thu, 8 Sep 2011 19:04:36 +0000 (UTC) Received: by gwb1 with SMTP id 1so310909gwb.36 for ; Thu, 08 Sep 2011 12:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rK6DQ+EWJ+dH8IGH+9OLpZduknY425Ao0HIntqvYSu4=; b=i6GAh0rv3fXrEoak2in9A5t08G15hxYZX4BwxSfqrFayAISNHPcHL2K7ZeMXlsDebG zcyTDCPETezTIYl+t18CVDfn1wn6WGFWBCPFRQy96Hrv2CwK4NnvcYSY7/Gl1P9OQT29 nDqtsknA4Yb4idilQgf4zGVbnpyAIBIirubAY= MIME-Version: 1.0 Received: by 10.68.20.99 with SMTP id m3mr1641616pbe.444.1315508675059; Thu, 08 Sep 2011 12:04:35 -0700 (PDT) Received: by 10.142.232.15 with HTTP; Thu, 8 Sep 2011 12:04:35 -0700 (PDT) In-Reply-To: <1315441138.2872.13.camel@hitfishpass-lx.corp.yahoo.com> References: <1315441138.2872.13.camel@hitfishpass-lx.corp.yahoo.com> Date: Thu, 8 Sep 2011 15:04:35 -0400 Message-ID: From: Arnaud Lacombe To: Sean Bruno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: FreeBSD 7-STABLE mbuf corruption 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, 08 Sep 2011 19:04:36 -0000 Hi, On Wed, Sep 7, 2011 at 8:18 PM, Sean Bruno wrote: > [...] > In addition to some txeof() handling patches ... Jack can see if this is > still relevant in the freebsd7 universe. Note that Yahoo is "special" > and we pluck and chuck code/drivers/whatever at will so I don't know how > this code will apply to stable-7 or if it has been applied already. > > Note that this code "rage-quits" the EIAM/EIAC auto ack strategy and > tries to handle the OACTIVE state handling better. =A0I hope these clues > find you well. > Just for the record, I'll comment inline. > --- //depot/yahoo/ybsd_7/src/sys/dev/e1000/if_igb.c =A0 =A0 2010-11-29 > 20:47:23.000000000 0000 > +++ /home/seanbru/ybsd_7/src/sys/dev/e1000/if_igb.c =A0 =A0 2010-11-29 > 20:47:23.000000000 0000 > @@ -30,7 +30,7 @@ > =A0 POSSIBILITY OF SUCH DAMAGE. > > > *************************************************************************= *****/ > -/*$FreeBSD: src/sys/dev/e1000/if_igb.c,v 1.3.2.13 2010/11/27 01:09:54 > jfv Exp $*/ > +/*$FreeBSD: stable/7/sys/dev/e1000/if_igb.c 216465 2010-12-15 22:48:44Z > jfv $*/ > > > =A0#ifdef HAVE_KERNEL_OPTION_HEADERS > @@ -318,10 +318,6 @@ > =A0static bool igb_header_split =3D FALSE; > =A0TUNABLE_INT("hw.igb.hdr_split", &igb_header_split); > > -/* > -** This will autoconfigure based on > -** the number of CPUs if left at 0. > -*/ > =A0static int igb_num_queues =3D 0; > =A0TUNABLE_INT("hw.igb.num_queues", &igb_num_queues); > > @@ -784,10 +780,14 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > > =A0 =A0 =A0 =A0/* Call cleanup if number of TX descriptors low */ > +#if 0 > =A0 =A0 =A0 =A0if (txr->tx_avail <=3D IGB_TX_CLEANUP_THRESHOLD) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igb_txeof(txr); > +#endif > > =A0 =A0 =A0 =A0while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (txr->tx_avail <=3D IGB_TX_CLEANUP_THRES= HOLD) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_txeof(txr); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (txr->tx_avail <=3D IGB_TX_OP_THRESHOLD= ) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ifp->if_drv_flags |=3D IFF= _DRV_OACTIVE; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > @@ -1162,10 +1162,10 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IGB_TX_LOCK(txr); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (igb_txeof(txr)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0more =3D TRUE; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_start_locked(txr, ifp); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 /*if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) Poin= tless as > igb_start_locked() checks this right off the bat*/ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 igb_start_locked(txr, ifp); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IGB_TX_UNLOCK(txr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (more) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (more || (ifp->if_drv_flags & IFF_DRV_OA= CTIVE)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_enqueue(que->tq,= &que->que_task); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} that hunk seem already to be in the HEAD driver. > @@ -1298,15 +1298,20 @@ > =A0 =A0 =A0 =A0struct rx_ring *rxr =3D que->rxr; > =A0 =A0 =A0 =A0u32 =A0 =A0 =A0 =A0 =A0 =A0 newitr =3D 0; > =A0 =A0 =A0 =A0bool =A0 =A0 =A0 =A0 =A0 =A0more_tx, more_rx; > + =A0 =A0 =A0 struct ifnet =A0 =A0*ifp =3D adapter->ifp; > > +#if 0 > =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims); > + =A0 =A0 =A0 newitr =3D E1000_READ_REG(&adapter->hw, E1000_EICR); > +#endif > + =A0 =A0 =A0 E1000_WRITE_REG(&adapter->hw, E1000_EICR, que->eims); > =A0 =A0 =A0 =A0++que->irqs; > > =A0 =A0 =A0 =A0IGB_TX_LOCK(txr); > =A0 =A0 =A0 =A0more_tx =3D igb_txeof(txr); > =A0 =A0 =A0 =A0IGB_TX_UNLOCK(txr); > already in HEAD. > - =A0 =A0 =A0 more_rx =3D igb_rxeof(que, adapter->rx_process_limit, NULL)= ; > + =A0 =A0 =A0 more_rx =3D igb_rxeof(que, -1, NULL); > > =A0 =A0 =A0 =A0if (igb_enable_aim =3D=3D FALSE) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto no_calc; applied manually. > @@ -1361,7 +1366,7 @@ > > =A0no_calc: > =A0 =A0 =A0 =A0/* Schedule a clean task if needed*/ > - =A0 =A0 =A0 if (more_tx || more_rx) > + =A0 =A0 =A0 if (more_tx || more_rx || (ifp->if_drv_flags & IFF_DRV_OACT= IVE)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0taskqueue_enqueue(que->tq, &que->que_task)= ; > =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Reenable this interrupt */ already in HEAD. > @@ -1382,6 +1387,7 @@ > =A0 =A0 =A0 =A0struct adapter =A0*adapter =3D arg; > =A0 =A0 =A0 =A0u32 =A0 =A0 =A0 =A0 =A0 =A0 icr; > > + =A0 =A0 =A0 E1000_WRITE_REG(&adapter->hw, E1000_EICR, adapter->link_mas= k); > =A0 =A0 =A0 =A0++adapter->link_irq; > =A0 =A0 =A0 =A0icr =3D E1000_READ_REG(&adapter->hw, E1000_ICR); > =A0 =A0 =A0 =A0if (!(icr & E1000_ICR_LSC)) applied manually. > @@ -1535,6 +1541,14 @@ > =A0 =A0 =A0 =A0if (m_head->m_flags & M_VLANTAG) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cmd_type_len |=3D E1000_ADVTXD_DCMD_VLE; > > +/* > + * We just did this in before invocation, seems completely > + * redundant, igb_handle_queue -> igb_txeof > + * Pretty sure this is impossible as we check for the > + * IGB_TX_CLEANUP_THRESHOLD in igb_start_locked() which happens > + * before this func in invoked > + */ > +#if 0 > =A0 =A0 =A0 =A0 /* > =A0 =A0 =A0 =A0 =A0* Force a cleanup if number of TX descriptors > =A0 =A0 =A0 =A0 =A0* available hits the threshold > @@ -1547,6 +1561,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (ENOBUFS); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0} > +#endif > > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0* Map the packet for DMA. already in HEAD. > @@ -2082,6 +2097,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0que->eims =3D E1000_EICR_T= X_QUEUE0 << i; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0que->eims =3D 1 << vector; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_printf(adapter->dev, "que %d eims=3D= 0x%x\n", i, > que->eims); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0** Bind the msix vector, and thus the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0** rings to the corresponding cpu. applied manually > @@ -3264,8 +3280,6 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0case ETHERTYPE_IPV6: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ip6 =3D (struct ip6_hdr *)= (mp->m_data + ehdrlen); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ip_hlen =3D sizeof(struct = ip6_hdr); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (mp->m_len < ehdrlen + i= p_hlen) > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (FAL= SE); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ipproto =3D ip6->ip6_nxt; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type_tucmd_mlhl |=3D E1000= _ADVTXD_TUCMD_IPV6; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; already in HEAD. > @@ -4461,6 +4475,24 @@ > =A0static void > =A0igb_enable_intr(struct adapter *adapter) > =A0{ > + =A0 =A0 =A0 uint32_t ims, regval; > + > + =A0 =A0 =A0 =A0if (adapter->msix_mem) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ims =3D E1000_IMS_LSC | E1000_IMS_DOUTSY= NC; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAC); > +#if 0 > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC= , regval | > adapter->eims_mask); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAM); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAM= , regval | > adapter->eims_mask); > +#endif > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMS= , > adapter->eims_mask); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMS,= ims); > + =A0 =A0 =A0 =A0} else { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMS, > IMS_ENABLE_MASK | E1000_IMS_DRSTA); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IAM, > IMS_ENABLE_MASK | E1000_IMS_DRSTA); > + =A0 =A0 =A0 =A0} > + > +#if 0 > =A0 =A0 =A0 =A0/* With RSS set up what to auto clear */ > =A0 =A0 =A0 =A0if (adapter->msix_mem) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC, > @@ -4475,6 +4507,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMS, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IMS_ENABLE_MASK); > =A0 =A0 =A0 =A0} > +#endif > =A0 =A0 =A0 =A0E1000_WRITE_FLUSH(&adapter->hw); > > =A0 =A0 =A0 =A0return; > @@ -4483,11 +4516,33 @@ > =A0static void > =A0igb_disable_intr(struct adapter *adapter) > =A0{ > + =A0 =A0 =A0 uint32_t regval; > + > + =A0 =A0 =A0 =A0/* > + =A0 =A0 =A0 =A0 * we need to be careful when disabling interrupts. =A0T= he VFs > are also > + =A0 =A0 =A0 =A0 * mapped into these registers and so clearing the bits = can > cause > + =A0 =A0 =A0 =A0 * issues on the VF drivers so we only need to clear wha= t we > set > + =A0 =A0 =A0 =A0 */ > + =A0 =A0 =A0 =A0if (adapter->msix_mem) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAM); > +#if 0 > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAM= , regval & > ~adapter->eims_mask); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regval =3D E1000_READ_REG(&adapter->hw, = E1000_EIAC); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC= , regval & > ~adapter->eims_mask); > +#endif > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMC= , > adapter->eims_mask); > + =A0 =A0 =A0 =A0} > + > + =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IAM, 0); > + =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMC, ~0); > + > +#if 0 > =A0 =A0 =A0 =A0if (adapter->msix_mem) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIMC, = ~0); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_EIAC, = 0); > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0E1000_WRITE_REG(&adapter->hw, E1000_IMC, ~0); > +#endif > =A0 =A0 =A0 =A0E1000_WRITE_FLUSH(&adapter->hw); > =A0 =A0 =A0 =A0return; > =A0} applied manually. > @@ -4876,8 +4931,8 @@ > =A0 =A0 =A0 =A0struct sysctl_oid_list *child =3D SYSCTL_CHILDREN(tree); > =A0 =A0 =A0 =A0struct e1000_hw_stats *stats =3D adapter->stats; > > - =A0 =A0 =A0 struct sysctl_oid *stat_node, *queue_node, *int_node, > *host_node; > - =A0 =A0 =A0 struct sysctl_oid_list *stat_list, *queue_list, *int_list, > *host_list; > + =A0 =A0 =A0 struct sysctl_oid *stat_node, *queue_node, *int_node, > *host_node, *debug_node; > + =A0 =A0 =A0 struct sysctl_oid_list *stat_list, *queue_list, *int_list, > *host_list, *debug_list; > > =A0#define QUEUE_NAME_LEN 32 > =A0 =A0 =A0 =A0char namebuf[QUEUE_NAME_LEN]; > @@ -5245,6 +5300,27 @@ > =A0 =A0 =A0 =A0SYSCTL_ADD_QUAD(ctx, host_list, OID_AUTO, "header_redir_mi= ssed", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CTLFLAG_RD, &stats->hrmpc, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Header Redirection Missed= Packet Count"); > + > + > + =A0 =A0 =A0 debug_node =3D SYSCTL_ADD_NODE(ctx, child, OID_AUTO, "debug= ", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTL= FLAG_RD, NULL, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "De= bug info"); > + > + =A0 =A0 =A0 debug_list =3D SYSCTL_CHILDREN(debug_node); > + > + =A0 =A0 =A0 txr =3D adapter->tx_rings; > + =A0 =A0 =A0 SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "desc_avail", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTLFLAG_RD, (u_int *)(uintp= tr_t)&txr->tx_avail, > 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ""); > + > + =A0 =A0 =A0 SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "next_to_clean", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTLFLAG_RD, &txr->next_to_c= lean, 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ""); > + > + =A0 =A0 =A0 SYSCTL_ADD_UINT(ctx, debug_list, OID_AUTO, "if_flags", > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CTLFLAG_RD, &adapter->ifp->= if_drv_flags, 0, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ""); > + > =A0} > applied manually. LYK, - Arnaud From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:13:55 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 25AE1106564A; Fri, 9 Sep 2011 00:13:55 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id DAE1D8FC16; Fri, 9 Sep 2011 00:13:51 +0000 (UTC) Received: from [50.12.52.187] (helo=[192.168.1.10]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1oj8-0006hQ-HU; Thu, 08 Sep 2011 20:13:50 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20110908184928.GA87872@hub.freebsd.org> Date: Thu, 8 Sep 2011 20:13:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> <20110908184928.GA87872@hub.freebsd.org> To: Navdeep Parhar X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Ben Hutchings , freebsd-net@freebsd.org, jfv@freebsd.org, John Baldwin , Takuya ASADA Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 00:13:55 -0000 On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote: > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >>>> Hi, >>>>=20 >>>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a = detail: >>>>=20 >>>> - Adding removing signature filter >>>> On linux version of ixgbe driver, it has ability to set/remove = perfect >>>> filter from userland using ethtool command. >>>> I implemented similar feature, but on sysctl, and not perfect = filter >>>> but signature filter(which means hash collision may occurs). >>> [...] >>>=20 >>> Linux also has a generic interface to RX filtering and hashing >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for = FreeBSD >>> to support something like that? >>=20 >> Some sort of shared interface might be nice. The cxgb(4) and = cxgbe(4) drivers >> both provide their own tools to manipulate filters, though they do = not >> provide explicit steering IIRC. >=20 > Both of them can filter as well as steer (and the tools let you do = that). > cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but = those > features are perhaps too specialized to be configurable via a general > purpose tool. >=20 >>=20 >> We would need to come up with some sort of standard interface = (ioctls?) for=20 >> adding filters however. >=20 > +1 for a standard interface. >=20 > imho the kernel needs to be aware of the rx and tx queues of a NIC, = and > not just for steering. But that's a separate discussion. >=20 Well I do think this is actually all of a part. Most of us realize by = now that high speed (e.g. 10G and higher) NICs only make sense if you can steer = traffic and pin queues to cores etc. Without those pieces in place it's impossible = to get the full utilization out of the NIC because things like cache misses = just kill your performance. Having looked at a few 10G NICs in the last couple of = years the one thing I notice is that everyone wants to do things like offload and = steering but that the specifics are quite different between different cards. = Some of that has to do with the libraries that expose these things to the kernel and = user programs, but some has to do with how the device is modeled. What this means is = that we have a failure of abstraction. Abstraction has a cost, and some of the = people who want access to low level queues are not interested in paying an extra = abstraction cost. I think that some of the abstractions we need are tied up in the work = that Takuya did for SoC and some of it is in the work done by Luigi on netmap. I'd go = so far as to say that what we should do is try to combine those two pieces of code into a = set of low level APIs for programs to interact with high speed NICs. The one = thing most people do not talk about is extending our socket API to do two things = that I think would be a win for 80% of our users. If a socket, and also a kqueue, could be = pinned to a CPU as well as a NIC queue that should improve overall bandwidth = for a large number of our users. The API there is definitely an ioctl() and the = hard part is doing the tying together. To do this we need to also work out our low = level story. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:21: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 68990106566C for ; Fri, 9 Sep 2011 00:21:21 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 41F718FC0C for ; Fri, 9 Sep 2011 00:21:21 +0000 (UTC) Received: from [50.12.52.187] (helo=[192.168.1.10]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1oqO-00025c-Jq; Thu, 08 Sep 2011 20:21:20 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: <4E4E3522.6030207@gmail.com> Date: Thu, 8 Sep 2011 20:21:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E4E3522.6030207@gmail.com> To: Ben Gray X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-net@freebsd.org Subject: Re: Test tools for new network 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, 09 Sep 2011 00:21:21 -0000 On Aug 19, 2011, at 06:04 , Ben Gray wrote: > Hi, >=20 > I'm not sure if this the right list to post to, but here goes ... >=20 > I'm currently writing a driver for the SMSC LAN95xx range of USB to = Ethernet adapter chips = (http://www.smsc.com/index.php?tid=3D300&pid=3D135&tab=3D1). The basic = RX/TX works and now I'm trying to get the H/W checksum offload working, = however I've come across some problems with the H/W implementation, e.g. = it doesn't work with small (<64 byte) packets. >=20 > So I was wondering if anyone knows of any test tools I can use to = fire all the different unusual sort of packets at the interface to see = how the H/W csum reacts, i.e. runt packets, packets with IP options, = IPv6 packets with extension headers, etc. >=20 Sorry to be late on this one. http://pcs.sf.net and /usr/ports/net/py-pcs If you have questions on it let me know. I'm the author. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:28: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 795D01065672 for ; Fri, 9 Sep 2011 00:28:04 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC718FC0C for ; Fri, 9 Sep 2011 00:28:04 +0000 (UTC) Received: from [50.12.52.187] (helo=[192.168.1.10]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1owt-0005hg-KT; Thu, 08 Sep 2011 20:28:03 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: Date: Thu, 8 Sep 2011 20:28:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9B975567-2C08-44D3-B328-BB86C72EF700@neville-neil.com> References: To: Johannes X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-net@freebsd.org, Sami Halabi Subject: Re: Intel NIC stops working 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, 09 Sep 2011 00:28:04 -0000 On Aug 17, 2011, at 04:06 , Johannes wrote: > Hi Sami, >=20 > thanks for the reply. Unfortunately, down/up the interface does not > resolve the problem. > I have to reboot my server in order to use the nic again. >=20 Crazy suggestion. Check the memory on your server using memtest or the = like. Those stats you quoted just look very wrong to me, since they numbers = are huge for broadcast and multicast. I think something in memory is trashed. = Now, it may be a bug in the driver or somewhere else, but check your memory = first. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:31:54 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 D93B2106564A; Fri, 9 Sep 2011 00:31:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id A41978FC08; Fri, 9 Sep 2011 00:31:54 +0000 (UTC) Received: from [209.249.190.124] (helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1glq-00011b-7i; Thu, 08 Sep 2011 11:44:06 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: Date: Thu, 8 Sep 2011 11:44:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <221A0471-8D58-43F8-B850-873EE2DE2B2F@neville-neil.com> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> To: K. Macy X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Takuya ASADA , John Baldwin , freebsd-net@freebsd.org, jfv@freebsd.org, Navdeep Parhar , Ben Hutchings Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 00:31:54 -0000 On Sep 8, 2011, at 10:48 , K. Macy wrote: > On Thu, Sep 8, 2011 at 2:34 PM, John Baldwin wrote: >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: >>>> Hi, >>>>=20 >>>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a = detail: >>>>=20 >>>> - Adding removing signature filter >>>> On linux version of ixgbe driver, it has ability to set/remove = perfect >>>> filter from userland using ethtool command. >>>> I implemented similar feature, but on sysctl, and not perfect = filter >>>> but signature filter(which means hash collision may occurs). >>> [...] >>>=20 >>> Linux also has a generic interface to RX filtering and hashing >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for = FreeBSD >>> to support something like that? >>=20 >> Some sort of shared interface might be nice. The cxgb(4) and = cxgbe(4) drivers >> both provide their own tools to manipulate filters, though they do = not >> provide explicit steering IIRC. >>=20 >> We would need to come up with some sort of standard interface = (ioctls?) for >> adding filters however. >=20 > I know this must sound like nitpicking, but please don't add more > ioctls if you can avoid it. If you want to add new interfaces try to > stick with sysctl as it tends to be less prone to breakage across > releases. >=20 >=20 > The biggest problem in defining a new API is the lack of anyone with a > global overview of the functionality provided by NIC vendors and their > near-term roadmaps. It doesn't make sense to add an API that we only > know works for one or two vendors. >=20 I think this is doable. I've seen enough of these cards to know a bit of what we'd want. This is a subject we've covered in a few different BSDCans but it's probably time for a straw man. I'm not against the sysctl approach but I'll have to give this a bit more thought. The only real options are sockets, ioctls and sysctls, that I can see. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:43:18 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86611106566C for ; Fri, 9 Sep 2011 00:43:18 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 57A478FC16 for ; Fri, 9 Sep 2011 00:43:18 +0000 (UTC) Received: from [50.12.52.187] (helo=[192.168.1.10]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1ot1-0003Y8-JK; Thu, 08 Sep 2011 20:24:05 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: Date: Thu, 8 Sep 2011 20:24:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <567B01DF-7D52-4C5C-8F69-96CDB20FAC92@neville-neil.com> References: <2AB05A3E-BDC3-427D-B4A7-ABDDFA98D194@dudu.ro> <0BB87D28-3094-422D-8262-5FA0E40BFC7C@dudu.ro> To: Takuya ASADA X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: net@freebsd.org Subject: Re: Multiqueue support for bpf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 00:43:18 -0000 On Aug 19, 2011, at 04:21 , Takuya ASADA wrote: > Any comments or suggestions? >=20 >=20 One comment, one question. First, I think we should try to integrate this work and then tune it up = more. The API is, I think, fine, and performance tuning takes a bit of work. Second, what are the parameters set on buffers for the drivers? I.e. = how many slots do they have in their queues etc.? If they defaults are too small, and = often they are, then that's going to hurt your performance. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:44: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 3BA07106564A; Fri, 9 Sep 2011 00:44:39 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 171978FC17; Fri, 9 Sep 2011 00:44:38 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 17:44:37 -0700 From: Ben Hutchings To: George Neville-Neil In-Reply-To: <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> <20110908184928.GA87872@hub.freebsd.org> <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Fri, 09 Sep 2011 01:44:34 +0100 Message-ID: <1315529074.2804.63.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2011 00:44:38.0366 (UTC) FILETIME=[A75237E0:01CC6E89] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18372.005 X-TM-AS-Result: No--35.371100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: jfv@freebsd.org, freebsd-net@freebsd.org, Navdeep Parhar , John Baldwin , Takuya ASADA Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 00:44:39 -0000 On Thu, 2011-09-08 at 20:13 -0400, George Neville-Neil wrote: > On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote: > > > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: > >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > >>>> Hi, > >>>> > >>>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > >>>> > >>>> - Adding removing signature filter > >>>> On linux version of ixgbe driver, it has ability to set/remove perfect > >>>> filter from userland using ethtool command. > >>>> I implemented similar feature, but on sysctl, and not perfect filter > >>>> but signature filter(which means hash collision may occurs). > >>> [...] > >>> > >>> Linux also has a generic interface to RX filtering and hashing > >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > >>> to support something like that? > >> > >> Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > >> both provide their own tools to manipulate filters, though they do not > >> provide explicit steering IIRC. > > > > Both of them can filter as well as steer (and the tools let you do that). > > cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those > > features are perhaps too specialized to be configurable via a general > > purpose tool. > > > >> > >> We would need to come up with some sort of standard interface (ioctls?) for > >> adding filters however. > > > > +1 for a standard interface. > > > > imho the kernel needs to be aware of the rx and tx queues of a NIC, and > > not just for steering. But that's a separate discussion. > > > > Well I do think this is actually all of a part. Most of us realize by now that > high speed (e.g. 10G and higher) NICs only make sense if you can steer traffic and > pin queues to cores etc. Well, you can get way better than 1G performance without that. And for routers, flow hashing may be fine. But for a host, of course, steering packets properly can provide a major performance win. [...] > What this means is that we have > a failure of abstraction. Abstraction has a cost, and some of the people who want > access to low level queues are not interested in paying an extra abstraction cost. Abstraction has a cost, but it's not necessarily that high compared to rewriting a whole chunk of sockets code (especially if you don't actually have the source code). > I think that some of the abstractions we need are tied up in the work that Takuya did > for SoC and some of it is in the work done by Luigi on netmap. I'd go so far as to say > that what we should do is try to combine those two pieces of code into a set of > low level APIs for programs to interact with high speed NICs. The one thing most > people do not talk about is extending our socket API to do two things that I think would > be a win for 80% of our users. If a socket, and also a kqueue, could be pinned > to a CPU as well as a NIC queue that should improve overall bandwidth for a large > number of our users. The API there is definitely an ioctl() and the hard part is > doing the tying together. To do this we need to also work out our low level story. But it would be a lot nicer if this could be done automatically. Which I believe it can - see the RFS and XPS features in Linux. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 00:48:14 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0104F106566C for ; Fri, 9 Sep 2011 00:48:14 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id CE5F68FC15 for ; Fri, 9 Sep 2011 00:48:13 +0000 (UTC) Received: from [50.12.52.187] (helo=[192.168.1.10]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1R1ou9-0004X2-1x; Thu, 08 Sep 2011 20:25:13 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: <4E4CC02A.7090104@ipfw.ru> Date: Thu, 8 Sep 2011 20:25:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <62A4AFEC-0178-4066-9321-9656281496DE@neville-neil.com> References: <4E4CC02A.7090104@ipfw.ru> To: Alexander V. Chernikov X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: "net@freebsd.org" Subject: Re: IP_MINTTL and RFC5082 (TTL security, GTSM) 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: Fri, 09 Sep 2011 00:48:14 -0000 On Aug 18, 2011, at 03:32 , Alexander V. Chernikov wrote: > Hello list! >=20 > FreeBSD supports IP_MINTTL since long ago (5.x ?). This is = RFC3682-compatible implementation. >=20 > It is very simple: if we can associate incoming packet with any = socket, socket is checked for minimum TTL value existence. If such value = exists and received packet TTL is lower, packet is dropped. >=20 > However, it is not enough for real security. ICMP messages are not = checked for minimum TTL (which is now required by RFC 5082 6.1.) >=20 > Icmp messages are passed via .pr_ctlinput upper level protocol hook. > Icmp code, originator address (sockaddr *) and part of problem = datagramm (received in icmp packet) are passed as arguments. >=20 > As a result, TTL of ICMP packet is not passed to upper layer proto and = TTL security cannot be enforced. >=20 > What can possibly be done: >=20 > * New hook .pr_ctlinput2 with additional argument pointing to original = ICMP header can be added. After that we convert all base code to use = .pr_ctlinput2 and appropriate icmp_input() parts can be changed like = this: >=20 >=20 > ctlfunc2 =3D inetsw[ip_protox[icp->icmp_ip.ip_p]].pr_ctlinput2; > if (ctlfunc2) > (*ctlfunc2)(code, (struct sockaddr *)&icmpsrc, > (void *)&icp->icmp_ip, (void *)icp); > else { > ctlfunc =3D inetsw[ip_protox[icp->icmp_ip.ip_p]].pr_ctlinput; > if (ctlfunc) > (*ctlfunc)(code, (struct sockaddr *)&icmpsrc, > (void *)&icp->icmp_ip); >=20 > } >=20 > * .pr_ctlinput() can be altered (if it's not too late for 9.x) and = some trick like supplying TTL data directly after (struct sockaddr*) can = be used as 8.x MFC >=20 >=20 > P.S. We should implement IP_MINTTL variant for IPv6. I can submit = patches but this seems to be reasonable only after we got some solution = for ICMP security. >=20 > Linux people added compatible opt for IPv4 in 2.6.34: > = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcom= mitdiff;h=3Dd218d11133d888f9745802146a50255a4781d37a >=20 > .. and IPV6_MINHOPCOUNT for IPv6 in 2.6.35: >=20 > = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcom= mitdiff;h=3De802af9cabb011f09b9c19a82faef3dd315f27eb >=20 > so we can consider using IPV6_MINHOPCOUNT as appropriate setsockopt = name Sounds good. Do you have a patch already? It seems like you might. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 01:53:10 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id 92BBC1065672; Fri, 9 Sep 2011 01:53:10 +0000 (UTC) Date: Fri, 9 Sep 2011 01:53:10 +0000 From: Navdeep Parhar To: Ben Hutchings , rwatson@FreeBSD.org Message-ID: <20110909015310.GB24670@hub.freebsd.org> Mail-Followup-To: Ben Hutchings , rwatson@FreeBSD.org, George Neville-Neil , John Baldwin , freebsd-net@freebsd.org, jfv@freebsd.org, Takuya ASADA References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> <20110908184928.GA87872@hub.freebsd.org> <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> <1315529074.2804.63.camel@bwh-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1315529074.2804.63.camel@bwh-desktop> User-Agent: Mutt/1.4.2.1i Cc: jfv@freebsd.org, freebsd-net@freebsd.org, John Baldwin , Takuya ASADA Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 01:53:10 -0000 On Fri, Sep 09, 2011 at 01:44:34AM +0100, Ben Hutchings wrote: > On Thu, 2011-09-08 at 20:13 -0400, George Neville-Neil wrote: > > On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote: > > > > > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote: > > >> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote: > > >>> On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote: > > >>>> Hi, > > >>>> > > >>>> I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail: > > >>>> > > >>>> - Adding removing signature filter > > >>>> On linux version of ixgbe driver, it has ability to set/remove perfect > > >>>> filter from userland using ethtool command. > > >>>> I implemented similar feature, but on sysctl, and not perfect filter > > >>>> but signature filter(which means hash collision may occurs). > > >>> [...] > > >>> > > >>> Linux also has a generic interface to RX filtering and hashing > > >>> (ethtool_rxnfc) which ixgbe supports; wouldn't it be better for FreeBSD > > >>> to support something like that? > > >> > > >> Some sort of shared interface might be nice. The cxgb(4) and cxgbe(4) drivers > > >> both provide their own tools to manipulate filters, though they do not > > >> provide explicit steering IIRC. > > > > > > Both of them can filter as well as steer (and the tools let you do that). > > > cxgbe(4) can do a lot more (rewrite + switch, replicate, etc.) but those > > > features are perhaps too specialized to be configurable via a general > > > purpose tool. > > > > > >> > > >> We would need to come up with some sort of standard interface (ioctls?) for > > >> adding filters however. > > > > > > +1 for a standard interface. > > > > > > imho the kernel needs to be aware of the rx and tx queues of a NIC, and > > > not just for steering. But that's a separate discussion. > > > > > > > Well I do think this is actually all of a part. Most of us realize by now that > > high speed (e.g. 10G and higher) NICs only make sense if you can steer traffic and > > pin queues to cores etc. > > Well, you can get way better than 1G performance without that. And for > routers, flow hashing may be fine. But for a host, of course, steering > packets properly can provide a major performance win. > > [...] > > What this means is that we have > > a failure of abstraction. Abstraction has a cost, and some of the people who want > > access to low level queues are not interested in paying an extra abstraction cost. > > Abstraction has a cost, but it's not necessarily that high compared to > rewriting a whole chunk of sockets code (especially if you don't > actually have the source code). > > > I think that some of the abstractions we need are tied up in the work that Takuya did > > for SoC and some of it is in the work done by Luigi on netmap. I'd go so far as to say > > that what we should do is try to combine those two pieces of code into a set of > > low level APIs for programs to interact with high speed NICs. The one thing most > > people do not talk about is extending our socket API to do two things that I think would > > be a win for 80% of our users. If a socket, and also a kqueue, could be pinned > > to a CPU as well as a NIC queue that should improve overall bandwidth for a large > > number of our users. The API there is definitely an ioctl() and the hard part is > > doing the tying together. To do this we need to also work out our low level story. > > But it would be a lot nicer if this could be done automatically. Which > I believe it can - see the RFS and XPS features in Linux. rwatson@ has been working on "connection groups" (not sure what he calls his project) with a goal to improve the placement of work in the FreeBSD network stack. Some of the code is in the kernel but the parts that require closer cooperation with a NIC are not. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 04:18:30 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C39D1065670; Fri, 9 Sep 2011 04:18:30 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-gx0-f179.google.com (mail-gx0-f179.google.com [209.85.161.179]) by mx1.freebsd.org (Postfix) with ESMTP id E63B68FC08; Fri, 9 Sep 2011 04:18:29 +0000 (UTC) Received: by gxk1 with SMTP id 1so812138gxk.10 for ; Thu, 08 Sep 2011 21:18:29 -0700 (PDT) Received: by 10.231.25.19 with SMTP id x19mr1109167ibb.16.1315541908781; Thu, 08 Sep 2011 21:18:28 -0700 (PDT) Received: from [126.230.176.83] (pw126230176083.16.tss.panda-world.ne.jp [126.230.176.83]) by mx.google.com with ESMTPS id j2sm6798813ibx.11.2011.09.08.21.18.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 21:18:27 -0700 (PDT) References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> <20110908184928.GA87872@hub.freebsd.org> <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> <1315529074.2804.63.camel@bwh-desktop> In-Reply-To: <1315529074.2804.63.camel@bwh-desktop> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3AD2C27D-29A0-4776-8A61-2D33B76BC7C7@dokukino.com> X-Mailer: iPhone Mail (9A5313e) From: Takuya ASADA Date: Fri, 9 Sep 2011 13:18:13 +0900 To: Ben Hutchings Cc: "jfv@freebsd.org" , "freebsd-net@freebsd.org" , Navdeep Parhar , John Baldwin Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 04:18:30 -0000 On Sep 9, 2011, at 9:44 AM, Ben Hutchings wrote: > But it would be a lot nicer if this could be done automatically. Which > I believe it can - see the RFS and XPS features in Linux. Does it cooperate with hw queues and hw hashing now? When I saw RFS code, it was just worked with RPS. From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 11:23: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 9C478106566B; Fri, 9 Sep 2011 11:23:13 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1897F8FC0C; Fri, 9 Sep 2011 11:23:12 +0000 (UTC) Received: by vws14 with SMTP id 14so1260233vws.37 for ; Fri, 09 Sep 2011 04:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EpUPhfiPAgdSDO5oZlb/zg40giEUYlseSKUTDNMSgh4=; b=X6j00xC3++p+vI2GTN/RQaGYISnTPpA8xP+6em1UjrqHGc0og7YRhC0DPBvePp/WBs jDfb01yCHvqDNcCO6sG1s7NQBZCdaSXJQMVB/WaB668eWTOF/tEAF9D93cqJkqUHV3yH XugrGxDU9vjVEJ+Ti8BhElLrcisaDjd07o5FQ= MIME-Version: 1.0 Received: by 10.52.66.164 with SMTP id g4mr66495vdt.96.1315567392270; Fri, 09 Sep 2011 04:23:12 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.52.113.169 with HTTP; Fri, 9 Sep 2011 04:23:12 -0700 (PDT) In-Reply-To: <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> <20110908184928.GA87872@hub.freebsd.org> <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> Date: Fri, 9 Sep 2011 13:23:12 +0200 X-Google-Sender-Auth: 0goJnOwbkegL8e3IYvNPLvuMoLI Message-ID: From: "K. Macy" To: George Neville-Neil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Takuya ASADA , John Baldwin , freebsd-net@freebsd.org, jfv@freebsd.org, Navdeep Parhar , Ben Hutchings Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 11:23:13 -0000 >=A0What this means is that we have > a failure of abstraction. =A0Abstraction has a cost, and some of the peop= le who want > access to low level queues are not interested in paying an extra abstract= ion cost. I think a case can be made that that isn't necessarily the case depending on how well the abstraction is defined. As an example, I don't believe that there is any performance penalty for the higher level of abstraction in the BSD pmap API vs. representing the MD layer as a multi-level page table. > > I think that some of the abstractions we need are tied up in the work tha= t Takuya did > for SoC and some of it is in the work done by Luigi on netmap. =A0I'd go = so far as to say > that what we should do is try to combine those two pieces of code into a = set of > low level APIs for programs to interact with high speed NICs. I'm inclined to agree although I have fairly recently changed the ifnet API for multi-queue I have received very little in the way of useful responses to my inquiries with various individuals about the interfaces exported by current cards. Based on my limited understanding of netmap as it exists now, I think that going forward netmap should develop in to a general API for safely exporting of queues to userspace, with the current limitations placed on it being solely for cards that don't support the more advanced features. I am only familiar with the documentation for Solarflare's quasi iommu and have access to an implementation of exporting queues to userspace on ixgbe cards. It appears that for a broader understanding of current NIC feature sets I will have to resort to spelunking through the network driver sources on kernel.org. This is probably reasonable when it comes to directing flows as linux is converging on a single API, but I am not aware of a similar general API for exporting queues. > The one thing most > people do not talk about is extending our socket API to do two things tha= t I think would > be a win for 80% of our users. =A0If a socket, and also a kqueue, could b= e pinned > to a CPU as well as a NIC queue that should improve overall bandwidth for= a large > number of our users. =A0The API there is definitely an ioctl() and the ha= rd part is > doing the tying together. =A0To do this we need to also work out our low = level story. This is clearly a useful application, perhaps the most straightforward, but I think there is a much broader set of possible uses. Cheers From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 12:22: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 85F861065674 for ; Fri, 9 Sep 2011 12:22:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6B68FC1F for ; Fri, 9 Sep 2011 12:22:41 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0B06246B0D; Fri, 9 Sep 2011 08:22:41 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C2028A02F; Fri, 9 Sep 2011 08:22:40 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 9 Sep 2011 08:22:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E678521.7080006@yandex-team.ru> In-Reply-To: <4E678521.7080006@yandex-team.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109090822.39325.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 09 Sep 2011 08:22:40 -0400 (EDT) Cc: "Alexander V. Chernikov" , jfvogel@gmail.com, melifaro@ipfw.ru Subject: Re: igb/ixgbe RSS/RX queues for non-IP traffic 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, 09 Sep 2011 12:22:41 -0000 On Wednesday, September 07, 2011 10:52:17 am Alexander V. Chernikov wrote: > Hello list! > > (CC'in Jack Vogel since this is intel drivers/hardware specific question) > > There are some techniques for assigning network traffic to different NIC > RX queues (bound to different CPUs/cores). > The main problem for all techniques is avoiding any possible packet > reordering in single flow. > > Most obvious (and most used) are described in Microsoft NDIS driver > specification: > Hashing is done on various tuples like: > * IPv46 src/dst + TCP/UDP src/dst port for TCP/UDP > * IPv46 src/dst for general IPv46 traffic > > igb's have a bit more options like assigning selected ethertype or TCP > SYN to different queue (See section 7.1.1 of 82576EB datasheet) > ixgbe (82599) goes even more far: flow director functionality permits 8K > 'perfect match' filters allowing to select any subset in: > * vlan > * IPv46 src/dst > * L4 proto > * TCP/UDP/SCTP protocol ports > and even 'flexible 2-byte tuple anywhere in the first 64 bytes of the > packet' > > There are other possibilities to assign traffic to different queues in > ixbge like using .1q priority filed (DCB functionality) > More information can be found in sections 7.1.2 (RX queues assignment), > 7.1.2.7(Flow Director), 7.7.1 (DCB) of 82599 datasheet > > However, there are many setups where PC can be used as platform for > routing/dispatching non-IP traffic. > PPPoE server is a typical example. > > People have to do some tricks (link aggregation, non-direct ISR) to get > traffic dispatched by more than single CPU/core, but this much less > efficient. > I'm a bit curious: why some generic hashing mechanism based on something > like 'flexible 2-byte tuple anywhere in the first 64 bytes of the > packet' were not added? > It can be (at least from my point of view) easily based on (for example) > flow director functionality. > > Particularly I'm trying to figure out how can I use all this variety of > filters to get MPLS traffic split to different RX queues. > > Maybe someone can point me to the right direction? There is another thread on net@ currently talking a good bit about this. It started with a post with a patch to support the traffic steering on ixgbe adapters using sysctls. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 13:01: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 6151A106564A; Fri, 9 Sep 2011 13:01:27 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 39A568FC17; Fri, 9 Sep 2011 13:01:27 +0000 (UTC) Received: from [192.168.4.185] ([88.96.1.126]) by exchange.solarflare.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Sep 2011 06:01:26 -0700 From: Ben Hutchings To: Takuya ASADA Date: Fri, 09 Sep 2011 14:01:21 +0100 In-Reply-To: <3AD2C27D-29A0-4776-8A61-2D33B76BC7C7@dokukino.com> References: <1315221674.3092.282.camel@deadeye> <201109080834.11607.jhb@freebsd.org> <20110908184928.GA87872@hub.freebsd.org> <37419C45-4436-4738-851B-2B765BC2C60F@neville-neil.com> <1315529074.2804.63.camel@bwh-desktop> <3AD2C27D-29A0-4776-8A61-2D33B76BC7C7@dokukino.com> Organization: Solarflare Communications Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2- Content-Transfer-Encoding: 7bit Message-ID: <1315573284.23168.85.camel@deadeye> Mime-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2011 13:01:26.0687 (UTC) FILETIME=[9588AAF0:01CC6EF0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18374.005 X-TM-AS-Result: No--15.693400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: "jfv@freebsd.org" , "freebsd-net@freebsd.org" , Navdeep Parhar , John Baldwin Subject: Re: Adding Flow Director sysctls to ixgbe(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: Fri, 09 Sep 2011 13:01:27 -0000 On Fri, 2011-09-09 at 13:18 +0900, Takuya ASADA wrote: > On Sep 9, 2011, at 9:44 AM, Ben Hutchings wrote: > > > But it would be a lot nicer if this could be done automatically. Which > > I believe it can - see the RFS and XPS features in Linux. > > Does it cooperate with hw queues and hw hashing now? > When I saw RFS code, it was just worked with RPS. I added support for using hardware filters ('accelerated RFS'). Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Fri Sep 9 14:45:23 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 3E0DA106566C for ; Fri, 9 Sep 2011 14:45:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx1.freebsd.org (Postfix) with ESMTP id CC3098FC12 for ; Fri, 9 Sep 2011 14:45:22 +0000 (UTC) Received: by eye4 with SMTP id 4so1327417eye.31 for ; Fri, 09 Sep 2011 07:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zn5/BzCepxxSDQVjo1ec2SBu7hVvowFtXyXglmDqdy8=; b=uny6NmDEbfyWKv6TPcF56frMsPCMJjagC3crvUBdUaNJs4xKVw3L6H+q695tSxUyA0 8bSRRyAnJnWHVlRFZNGwerhm0a0ffh3mM9GAtT/+FrGY1cmKwI+7yt1flzkqarFfBgJZ 9U87DdkcoFEd69D9sKHYwXH90/1TYZR4bnIi4= MIME-Version: 1.0 Received: by 10.213.20.212 with SMTP id g20mr613568ebb.107.1315577649208; Fri, 09 Sep 2011 07:14:09 -0700 (PDT) Received: by 10.213.28.142 with HTTP; Fri, 9 Sep 2011 07:14:09 -0700 (PDT) In-Reply-To: <4E678521.7080006@yandex-team.ru> References: <4E678521.7080006@yandex-team.ru> Date: Fri, 9 Sep 2011 10:14:09 -0400 Message-ID: From: Ryan Stone To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, jfvogel@gmail.com, melifaro@ipfw.ru Subject: Re: igb/ixgbe RSS/RX queues for non-IP traffic 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, 09 Sep 2011 14:45:23 -0000 On Wed, Sep 7, 2011 at 10:52 AM, Alexander V. Chernikov wrote: > Particularly I'm trying to figure out how can I use all this variety of > filters to get MPLS traffic split to different RX queues. I've got bad news for you on this. From Section 7.1.2.7 of the 82599 datasheet(Flow Director Filters). - IP packets are candidates for the flow director filters (meaning non-IP packets miss all filters)