From owner-freebsd-net@FreeBSD.ORG Sun Oct 28 18:47:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53E5C9AC; Sun, 28 Oct 2012 18:47:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5808FC08; Sun, 28 Oct 2012 18:47:26 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so3048602pad.13 for ; Sun, 28 Oct 2012 11:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Uyu1GfMmsLFdHsUeepQuWFMxIMEaPlhKJe3xCbvoO/0=; b=NeBVJUdrVroRgG8R9oeJCGPPSojOMtVuny/gnU7yf+9gpcbQc8me6BK4kn5hWeU6pH /ipXsyiQwQxEHpPV1cS2pCnm5e690avJNfgPN0PyPol677KDqlIaOnzjXIVu0OpiHzoo 9Vd62e+yjjruIKU4OLO//FPry2CASvj+rbEv4CO5PqLla8ssl6CPNB7Itg82GSMU5Mfg xneFGSZSuknK6EI84Aj2WblaGHIkxTVZkUT9jNQe9YXwf6QXS/cqqOZtsXt9NUTZOten XMoLKd9EDXJyE5OoNN6sz/RNYX9LdDFBQxjZ+l/GF1BukJgTeRcAlHefH5AthQ30liYi i1kg== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr77519338pav.75.1351450040374; Sun, 28 Oct 2012 11:47:20 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 28 Oct 2012 11:47:20 -0700 (PDT) In-Reply-To: References: <201210222317.00457.zec@fer.hr> <201210230916.11513.zec@fer.hr> Date: Sun, 28 Oct 2012 11:47:20 -0700 X-Google-Sender-Auth: LkNEQCp-lyJMnxLbuq-53mUk1wo Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec , Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Oct 2012 18:47:27 -0000 ping? Marko - would you be willing to add the if_free() vnet context setup into -HEAD? Hans, what do you think about USB device attach? detach will be covered by the above (I hope!) but we still need to do a CURVNET_SET(vnet0); during hotplug attach. Thanks, Adrian On 23 October 2012 10:37, Adrian Chadd wrote: > On 23 October 2012 00:16, Marko Zec wrote: > >> As already mentioned earlier, I don't terribly object if you'd place >> CURVNET_SET(ifp->if_vnet) inside if_free() and a limited number of similar >> functions, but I don't quite believe this is will enough to solve the >> device_detach() issue without having to touch any of the drivers... > > That's why I'm asking for more/better ideas. > > So far my ideas are: > > * for hotplug insert - do the same as what you're doing during the > kldload and boot device enumeration pass - call CURVNET_SET(vnet0) > * for device unload (hotplug or otherwise) - if vnet isn't set, > implicitly set it to vnet0 > * for the net80211 vaps, they get destroyed in a few places (ioctl > path, device detach path, I'm sure I saw one more) so I have to use > CURVNET_SET(ifp->if_vnet) on those. > > Now, that _should_ fix it for ath(4) and net80211, and it should fix > it for all the other non-USB wireless devices out there. > > Now as for USB - Hans, what do you think? Should we do something > similar? How does VIMAGE work right now with USB wireless and USB > ethernet devices? > > Marko - thanks for persisting with this. I'd like to try and make this > work for 10.0. > > > > Adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 28 21:05:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A5CFA; Sun, 28 Oct 2012 21:05:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.c2i.net [212.247.154.34]) by mx1.freebsd.org (Postfix) with ESMTP id D1EB98FC12; Sun, 28 Oct 2012 21:05:42 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 337992001; Sun, 28 Oct 2012 22:00:33 +0100 From: Hans Petter Selasky To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Sun, 28 Oct 2012 22:02:13 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210282202.13679.hselasky@c2i.net> Cc: freebsd-net@freebsd.org, Marko Zec , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Oct 2012 21:05:44 -0000 Hi, I currently have not tested VIMAGE with USB devices. Detach is the final exit for a USB device. There is also shutdown, but softc still is around. --HPS On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote: > ping? > > Marko - would you be willing to add the if_free() vnet context setup into > -HEAD? > > Hans, what do you think about USB device attach? detach will be > covered by the above (I hope!) but we still need to do a > CURVNET_SET(vnet0); during hotplug attach. > > Thanks, > > > Adrian > > On 23 October 2012 10:37, Adrian Chadd wrote: > > On 23 October 2012 00:16, Marko Zec wrote: > >> As already mentioned earlier, I don't terribly object if you'd place > >> CURVNET_SET(ifp->if_vnet) inside if_free() and a limited number of > >> similar functions, but I don't quite believe this is will enough to > >> solve the device_detach() issue without having to touch any of the > >> drivers... > > > > That's why I'm asking for more/better ideas. > > > > So far my ideas are: > > > > * for hotplug insert - do the same as what you're doing during the > > kldload and boot device enumeration pass - call CURVNET_SET(vnet0) > > * for device unload (hotplug or otherwise) - if vnet isn't set, > > implicitly set it to vnet0 > > * for the net80211 vaps, they get destroyed in a few places (ioctl > > path, device detach path, I'm sure I saw one more) so I have to use > > CURVNET_SET(ifp->if_vnet) on those. > > > > Now, that _should_ fix it for ath(4) and net80211, and it should fix > > it for all the other non-USB wireless devices out there. > > > > Now as for USB - Hans, what do you think? Should we do something > > similar? How does VIMAGE work right now with USB wireless and USB > > ethernet devices? > > > > Marko - thanks for persisting with this. I'd like to try and make this > > work for 10.0. > > > > > > > > Adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 03:43:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A22CD7C for ; Mon, 29 Oct 2012 03:43:24 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm29-vm6.bullet.mail.gq1.yahoo.com (nm29-vm6.bullet.mail.gq1.yahoo.com [98.136.216.181]) by mx1.freebsd.org (Postfix) with ESMTP id B4B228FC0C for ; Mon, 29 Oct 2012 03:43:23 +0000 (UTC) Received: from [98.137.12.188] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 29 Oct 2012 03:43:16 -0000 Received: from [208.71.42.208] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 29 Oct 2012 03:43:16 -0000 Received: from [127.0.0.1] by smtp219.mail.gq1.yahoo.com with NNFMP; 29 Oct 2012 03:43:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1351482196; bh=ifpcIiW55wLwBqyTqcAYkIvvIRYtPZAF7e12E/Tof6M=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=w5kIi6s1FskAfPsFGJJNLH/fhxtmC+/enk/qABEmeZtymoQUvczLexvjAZhpNEfnrDD7VpC6Nzm7rQKgyuuZg5Rmp1+yv3VVEHo10QeUGqRvKQkp5h6D9LUjPOPDyN4UNC2rUR1rFZXJ3dCdvAOJrWTeoD5QVkWS/BM9rTy7jqo= X-Yahoo-Newman-Id: 538426.35644.bm@smtp219.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aNQbV10VM1nE8rtzqacKdq3yhdzyPmDpIUNLtROR3ElaVvH vYfKiAfctFBAfZcdrqXbdrzGT89gGtw9amossiuBPyd7DqrVmyHP4r1jNdBM apORDQuCzQFOHXTyxQ6mqkFH_aXPiyin5H3If7o0wdVXhuPBMS5exSdqMvc4 9QThc1Mwgrf0gQ62c1sPAYKVVL1FOhBhOCBR3oz2H4qkbPvpPv0d7HmY.DI1 xnws2FUaTI.fM6Dsu8UaTPi1MRSf2t.hJ82R.GJDHPB..H1LHZ23Hjmo0Vkm wsZ6C_drna8jjUIGkQHuEhEUJ5eKrYzZYuBqXOzwWOrBzaBnJMmO0ZGOv2BQ grPhM8kyssQyZynxAyBCJF8VxLOxnTRC8h.B_jq.8bSpZtfIZnseh38cEJOw 1wfXF3RcIB.gCbMqIGrJ2ZKxVgjihP1QUclYWuWT1tUtWiKGtZrVhdfpqCd. Zw0v9V_9FJ7LVJ4rzJe5LWMOpHzAZDkgklULDI6G9IbtxAboHXgLHO_RAm6Q HNtVhj11HE5Jw X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vb0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp219.mail.gq1.yahoo.com with SMTP; 28 Oct 2012 20:43:16 -0700 PDT Received: by mail-vb0-f54.google.com with SMTP id l1so1074477vba.13 for ; Sun, 28 Oct 2012 20:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.33.229 with SMTP id u5mr256765vei.0.1351482195306; Sun, 28 Oct 2012 20:43:15 -0700 (PDT) Received: by 10.58.182.72 with HTTP; Sun, 28 Oct 2012 20:43:15 -0700 (PDT) Date: Sun, 28 Oct 2012 21:43:15 -0600 Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: PseudoCylon To: Adrian Chadd , freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 03:43:24 -0000 > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 27 Oct 2012 16:18:11 -0700 > From: Adrian Chadd > To: freebsd-wireless@freebsd.org > Cc: FreeBSD Net , freebsd-arch@freebsd.org > Subject: request for help: 'fixing' the 802.11 TX path > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > > I'd like to try and sort out the last remaining niggles in the 802.11 > code - this email is focusing on the TX path. > > The TX path has a few problems: > > * there's a normal versus raw TX path (for raw frames, management > frames, etc) - the raw path doesn't necessarily queue frames into the > raw TX queue, so it's a kind of "side path" to the driver. This causes > frame ordering problems with things like sequence number allocation. > * there's limited locking in the TX path, primarily because you can't > _really_ fine grain lock the TX path. Since you have multiple TX > thread contexts all sending into the same driver queue and that queue > has to share incrementing sequence number, aggregate status and CCMP > encryption replay counters, you _have_ to either use some long-held > mutexes to enforce this _or_ throw all sending into a TX thread and > run that. > * raw TX requires some extra state to be glued (the bpf_params info); > I'd like to glue that into mbufs as an option, so the driver can use > those instead of interpreting their own 802.11 header contents. > > And the one I'd like to discuss here: > > * Fragment transmission is totally broken and causes mbufs to be just > leaked. The problem with sending fragments (at least for the ath > drivr) is the packet duration calcluation requires the _next_ fragment > to be available. > > Now, this is a design hold-over from the previous, pre-vap scheme. The > driver netif would be handed a raw mbuf frame, which it would then > pass through the net80211 encapsulation code and that would > potentially generate 802.11 fragments. The rest of the driver TX path > would then see that it was handed a fragment list and TX those. > Fragments were chained together using m_nextpkt, like a normal mbuf > list. > > This doesn't happen any longer. The net80211 vap gets the raw frame, > which then sends that to the driver netif after doing the vap and > 802.11 state / encapsulation work. But since all the wifi drivers use > if_start() right now, m_nextpkt gets blanked on both encap and decap.. > and thus things leak. > > Now I can't really see a way around this, without doing dirty hacks > with mbuf attributes to link the fragments together. The only clean > way I can see is to force all wifi drivers to use if_transmit(), and > then have if_transmit() interpret a chain of frames as "the fragment > list." Cannot we just add custom hand off function to ieee80211_start()? ieee80211_start() { encap; IF_LOCK(parent->if_snd); do_seqnum_stuff; /* We can also queue mgt packets to the same queue */ for (m0 = m; m0->m_nextpkt != NULL; m0 = m0->m_nextpkt); ifq_tail = m0; IF_UNLOCK(); taskqueue_enqueue(taskqueue, parent->if_new_tx_function); /* or wake(); */ } Because of IF_LOCK, queued packets and seq num should be in order. Then, the driver only need to dequeue and Tx. The drivers can tell if the packet is a fragmented packet or a standalone packet from ieee80211 header or we can add a new member to bpf_params. AK From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 03:53:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63DC4A45; Mon, 29 Oct 2012 03:53:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 269D18FC0C; Mon, 29 Oct 2012 03:53:11 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so4137872pbb.13 for ; Sun, 28 Oct 2012 20:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kgzlGGvA9hUShv3MWfZgPHASiV2bZeqcuGNaPvjI8Sc=; b=Gg0cBSRV2WzQLy2ZCzpKW2z7QGMlMXyJTYbJkshe+W5RqDiN9gBdtMyNUT4xO857+M ecRuxL8csB0bo8vnGQ8xuJx4+fmsaJJ4H56QYrDzaSovh791XKLCgKrhXD+zxPfuh0PX blHIdHOQZF2CuUHMk3Fg2409T4G/2dpN/4Sa6HnWfAQgyeT3Ne4cwvNAJWoTlucOtN/4 npTY75BsObQydTbxC435k0YOxFwzfTPmxeyBlKhcWrz91Q8ntnwaYLXO0QYxSU7UjU4t LOubpxujwjEaww7eJAQqxggn6eLH3Qx/5gznO3iAbF4r6ul+E21plOgP30+rVcj93g60 PsMQ== MIME-Version: 1.0 Received: by 10.66.74.65 with SMTP id r1mr79954465pav.75.1351482790930; Sun, 28 Oct 2012 20:53:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.146.233 with HTTP; Sun, 28 Oct 2012 20:53:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Oct 2012 20:53:10 -0700 X-Google-Sender-Auth: ZEzdqL8YeED0RsLvQe31kI_Bp4I Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 03:53:11 -0000 On 28 October 2012 20:43, PseudoCylon wrote: > Cannot we just add custom hand off function to ieee80211_start()? Yes. That's the general idea. But what I don't want to do is have it just wake up the driver TX taskqueue - well, unless we have to. That means we'll have two context switches for each frame being transmitted and that as a concept just sucks. See my (very recent) email to -wireless - I broke TCP throughput quite substantially by moving ath(4) TX into the taskqueue. I thought the problem was _just_ going to be how overlapping, direct dispatch TX could be preempted by the RX tasklet and TX completion, but there's obviously more going on. I'm going to experiment some more with it before I go down this path. I don't want to do the linux thing of "just grab a txrx spinlock in mac80211 before calling the driver", serialising everything that way. That feels plain ugly. But then, a lot of our network drivers do much the same thing - they grab big, long-held locks and they either implement their own lockless queue in front of that lock (eg, what the intel/chelsio code does) or they just ignore it entirely and leave it up to the scheduler to wake up threads once the contending lock is unlocked. I have all kinds of concerns about the behaviour of if_bridge and other if_transmit() enabled friends when sending to one of these badly locked drivers, however that's going to have to wait. Well, maybe I'll poke the network people at meetbsd this weekend and see what they think. Adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 08:35:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 241636E for ; Mon, 29 Oct 2012 08:35:16 +0000 (UTC) (envelope-from remi.pauchet@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7008FC0A for ; Mon, 29 Oct 2012 08:35:14 +0000 (UTC) Received: from [10.2.9.2] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id 8415B2705606; Mon, 29 Oct 2012 09:35:02 +0100 (CET) Subject: Re: ixgbe and ixgbevf drivers are not working in virtualization environment Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_2C88C3A1-9FD4-490F-A79E-5C4B8D38D2BD"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?R=E9mi_Pauchet?= In-Reply-To: Date: Mon, 29 Oct 2012 09:35:01 +0100 Message-Id: <61139DF3-42F3-4589-8A78-F89C61694F6D@netasq.com> References: <792D5931-19E7-4239-A3E8-5D2BC90F03FD@netasq.com> <70DCE61F-E1B9-445F-A3F6-BC90646FA2AE@netasq.com> To: Sami Halabi X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 08:35:16 -0000 --Apple-Mail=_2C88C3A1-9FD4-490F-A79E-5C4B8D38D2BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 26 oct. 2012 =E0 23:40, Sami Halabi a =E9crit : > Hi, > did you try explicit "ifconfig ix0 up" instead of rebooting? In fact, down, then up commands are necessary : ifconfig ix0 down ifconfig ix0 up Regards, R=E9mi >=20 > Sami >=20 > On Thu, Oct 25, 2012 at 4:29 PM, R=E9mi Pauchet = wrote: > more informations about the SR-IOV issue. >=20 > The problem is that the link is not updated in the virtual machine (VF = driver). >=20 > ie: I start the VM with my fiber unplugged, the vf link is "no = carrier". > I plug the fiber, the link stays in state "no carrier". > If I reboot the vm, I get the active link. > I reproduce the issue with esxi 5.1 and xenserver 6 >=20 >=20 > On other hand, I still haven't managed to get an active link with = VMWare DirectPath. >=20 > Regards, > R=E9mi >=20 >=20 > Le 17 oct. 2012 =E0 09:42, R=E9mi Pauchet a =E9crit : >=20 > > Hi > > > > My interface is configured, UP and running and I still can't get a = link > > > > Can you help me with this issue ? > > > > Regards, > > R=E9mi > > > > > > Le 12 oct. 2012 =E0 09:38, R=E9mi Pauchet a =E9crit : > > > >> Hi, > >> > >> Unfortunately not: > >> > >> ix0: flags=3D8843 metric 0 = mtu 1500 > >> = options=3D401bb > >> ether 00:e0:ed:1c:99:4e > >> inet 172.16.255.254 netmask 0xffff0000 broadcast = 172.16.255.255 > >> inet6 fe80::2e0:edff:fe1c:994e%ix0 prefixlen 64 scopeid 0x2 > >> nd6 options=3D29 > >> media: Ethernet autoselect > >> status: no carrier > >> ix1: flags=3D8843 metric 0 = mtu 1500 > >> = options=3D401bb > >> ether 00:e0:ed:1c:99:4f > >> inet 172.17.255.254 netmask 0xffff0000 broadcast = 172.17.255.255 > >> inet6 fe80::2e0:edff:fe1c:994f%ix1 prefixlen 64 scopeid 0x3 > >> nd6 options=3D29 > >> media: Ethernet autoselect > >> status: no carrier > >> > >> Regards, > >> R=E9mi > >> > >> Le 11 oct. 2012 =E0 18:25, Jack Vogel a =E9crit : > >> > >>> The ixgbe device will not get link until you have run init, so = assign it an address or just do an ifconfig up. > >>> > >>> I have never used the driver using a passthru type setup but I = believe its been done successfully if > >>> memory serves. > >>> > >>> Jack > >>> > >>> > >>> On Thu, Oct 11, 2012 at 8:39 AM, R=E9mi Pauchet = wrote: > >>> Hi, > >>> > >>> I'm trying to use the ixgbe (10Gb) driver in a FreeBSD virtual = machine on an esxi 5 using DirectPath (PCI Passthrough) and the card is = detected, but I can't get a link (status: no carrier) > >>> > >>> ix0: mem 0xd2420000-0xd243ffff,0xd2400000-0xd2403fff irq 18 at device = 0.0 on pci3 > >>> > >>> ix0: flags=3D8802 metric 0 mtu 1500 > >>> = options=3D401bb > >>> ether 00:e0:ed:1c:99:4e > >>> nd6 options=3D29 > >>> media: Ethernet autoselect > >>> status: no carrier > >>> > >>> I have also tested with XenServer 6, using SR-IOV (ixgbevf driver) = with the same result: the driver is loading, but no link detected. > >>> > >>> In both case (VMWare DirectPath and XenServer SR-IOV), I tested = Linux with success. > >>> > >>> > >>> The card is an Intel 82599EB, the motherboard is an Intel X58 = (supermicro X8ST3) with a Xeon W3680 and I've tested FreeBSD 8.3 and 9.0 > >>> > >>> I've found a forum thread with the same issue: = http://forums.freebsd.org/showthread.php?t=3D29855 and no answer :) > >>> > >>> > >>> Please find in attachment the dmesg (boot -v) with the ix driver = compiled with DEBUG flags using vmware. > >>> > >>> > >>> Can anyone provide feedback about this issue ? > >>> > >>> Regards, > >>> R=E9mi Pauchet > >>> > >>> > >>> > >> > > >=20 >=20 >=20 >=20 > --=20 > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert >=20 --Apple-Mail=_2C88C3A1-9FD4-490F-A79E-5C4B8D38D2BD-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 09:47:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29337442 for ; Mon, 29 Oct 2012 09:47:20 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 790EA8FC16 for ; Mon, 29 Oct 2012 09:47:18 +0000 (UTC) Received: (qmail 95762 invoked from network); 29 Oct 2012 11:24:15 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Oct 2012 11:24:15 -0000 Message-ID: <508E50A3.1030008@networx.ch> Date: Mon, 29 Oct 2012 10:47:15 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: request for help: 'fixing' the 802.11 TX path References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , PseudoCylon , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 09:47:20 -0000 On 29.10.2012 04:53, Adrian Chadd wrote: > On 28 October 2012 20:43, PseudoCylon wrote: > >> Cannot we just add custom hand off function to ieee80211_start()? > > Yes. That's the general idea. But what I don't want to do is have it > just wake up the driver TX taskqueue - well, unless we have to. > > That means we'll have two context switches for each frame being > transmitted and that as a concept just sucks. > > See my (very recent) email to -wireless - I broke TCP throughput quite > substantially by moving ath(4) TX into the taskqueue. I thought the > problem was _just_ going to be how overlapping, direct dispatch TX > could be preempted by the RX tasklet and TX completion, but there's > obviously more going on. I can't believe that TCP is getting broken by just introducing some additional delay in the TX path. That can't add more than 300ms, can it? There must be something else going on. Most likely either severe packet loss (the m_nextpkt leak you mentioned earlier) or severe packet re-ordering. So don't rule out the TX taskqueue concept quite yet. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 10:15:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4637C751; Mon, 29 Oct 2012 10:15:43 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id BAB8E8FC16; Mon, 29 Oct 2012 10:15:42 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Mon, 29 Oct 2012 11:15:35 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Oct 2012 11:15:35 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Oct 2012 11:15:34 +0100 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Mon, 29 Oct 2012 11:15:23 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201210291115.23845.zec@fer.hr> X-OriginalArrivalTime: 29 Oct 2012 10:15:34.0961 (UTC) FILETIME=[55AFCA10:01CDB5BE] Cc: freebsd-net@freebsd.org, Hans Petter Selasky , freebsd-hackers@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 10:15:43 -0000 On Sunday 28 October 2012 19:47:20 Adrian Chadd wrote: > ping? > > Marko - would you be willing to add the if_free() vnet context setup into > -HEAD? Feel free to do it - though I'd suggest to use the CURVNET_SET_QUIET() variant there, to reduce the console spam with VNET_DEBUG. Marko Index: if.c =================================================================== --- if.c (revision 242304) +++ if.c (working copy) @@ -513,7 +513,9 @@ if (!refcount_release(&ifp->if_refcount)) return; + CURVNET_SET_QUIET(ifp->if_vnet); if_free_internal(ifp); + CURVNET_RESTORE(); } /* From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 11:06:36 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57C6AB45 for ; Mon, 29 Oct 2012 11:06:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3A69A8FC16 for ; Mon, 29 Oct 2012 11:06:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9TB6a2u028556 for ; Mon, 29 Oct 2012 11:06:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9TB6ZOl028554 for freebsd-net@FreeBSD.org; Mon, 29 Oct 2012 11:06:35 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Oct 2012 11:06:35 GMT Message-Id: <201210291106.q9TB6ZOl028554@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 Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 11:06:36 -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/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o 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/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 425 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 17:38:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 985DAC3C for ; Mon, 29 Oct 2012 17:38:14 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by mx1.freebsd.org (Postfix) with ESMTP id 449038FC14 for ; Mon, 29 Oct 2012 17:38:14 +0000 (UTC) Received: from [98.138.90.55] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 29 Oct 2012 17:38:07 -0000 Received: from [98.138.226.31] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Oct 2012 17:38:07 -0000 Received: from [127.0.0.1] by smtp202.mail.ne1.yahoo.com with NNFMP; 29 Oct 2012 17:38:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1351532287; bh=LM9cqYzZn55ZOV7/b3pl/8d+o4VoguqXOvn7kj4rCAI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=TF7Xu/QO6X63h9Z4ySNSgR1dCzfqxezXHmMf+foO2o3vSVEU0/mh9WdpdpZw/L2Ak5SjxpiDXSYigYb1c2IkXQ96yFFqtx1KOJj8AzE0sFcBn7VY059sPko691wV6nasXGAAMhAcjzQAx/T/1MlcvHjMTF4JM8/QYRB1NFRIaI0= X-Yahoo-Newman-Id: 653555.32931.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8zBtlvMVM1ny58J_AnS7cI97H1NarIBQwK6o4iTzjokaJSP ZaJHGjXBt7xXF3K7X02xwvmi38VLgOtcr3NpG7wK6ymgcgKa5I2rnwyTiVAc nUdS4xBa_eWVAcv7n8_x0z9HrBcLBRBIHJvcw8iF3KD8ssduhCQSkcKlfZH9 GFnsiOWw3_KbiGtBJHnmzJ8rtcVl9HXiJduBvPNFmrc15rM_x.cw5vDreuj. vBH_FMV5Tu7s38lLnx2tLYvbQv9_x2vX1sKVBhdcap_rJaR2u7XtdLwNGGgE OiYrd1kXcbre8hUbpKQ8oCAnrfp_QXqxCCTwa5XMUpfTwAXO5zG.6Q_rIL06 Tg8yTOTP3U2WD_OqUfHjzjK_CxlPsp_FWrW5Pg3Hev62ArLZtihtWqbZ17fE nWMZRoCNLlC5FKukcUxCskSmlNFytNAdPvq.qhXayPHHALNuke69iaWLTYeU W4YoGY2oU1TUikTVmnFA- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vb0-f54.google.com (moonlightakkiy@209.85.212.54 with plain) by smtp202.mail.ne1.yahoo.com with SMTP; 29 Oct 2012 10:38:07 -0700 PDT Received: by mail-vb0-f54.google.com with SMTP id l1so1981853vba.13 for ; Mon, 29 Oct 2012 10:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.66.36 with SMTP id c4mr39497747vdt.6.1351532286228; Mon, 29 Oct 2012 10:38:06 -0700 (PDT) Received: by 10.58.182.72 with HTTP; Mon, 29 Oct 2012 10:38:06 -0700 (PDT) In-Reply-To: <508E50A3.1030008@networx.ch> References: <508E50A3.1030008@networx.ch> Date: Mon, 29 Oct 2012 11:38:06 -0600 Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: PseudoCylon To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , Adrian Chadd , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 17:38:14 -0000 On Mon, Oct 29, 2012 at 3:47 AM, Andre Oppermann wrote: > On 29.10.2012 04:53, Adrian Chadd wrote: >> >> On 28 October 2012 20:43, PseudoCylon wrote: >> >>> Cannot we just add custom hand off function to ieee80211_start()? >> >> >> Yes. That's the general idea. But what I don't want to do is have it >> just wake up the driver TX taskqueue - well, unless we have to. >> >> That means we'll have two context switches for each frame being >> transmitted and that as a concept just sucks. Plan B vap->iv_ifp->if_transmit = ieee80211_transmit; ieee80211_transmit() /* new */ { /* Alternatively, we can make a list of param and attach mbuf to it. */ HANDOFF(parent->if_snd, m); ieee80211_new_tx(vap, m); } /* enque packet, but keep working on the same mbuf */ ieee80211_new_tx(vap, m) { encap; if (fragment) insert_fragmented_packet_to_queue; /* don't forget about a fragmented packet */ for (; m->m_nextpkt != NULL; m = m->m_nextpkt) parent->if_new_tx(vap, m); } /* keep working on the same mbuf */ driver_new_tx(vap, m) { do_descriptor_stuff; m->m_flags |= ALL_SET; /* * If, for instance, processing of queue #5 packet finished before queue #1, * #5 packet will stay in queue until all of preceding packets get processed. */ if (parent->if_sc->sc_tx == NOT_RUNNING && ifq_head->m_flags & ALL_SET) driver_pass2hw(parent); } /* finally, process mbuf from the head of queue */ driver_pass2hw() { /* only one thread to dequeue */ if (atomic_compset(&sc->sc_tx, NOT_RUNNING, RUNNING) == 0) return; for (;;) { DEQUEUE(ifq, m); if (!(m->m_flags & ALL_SET)) { PREPEND(); break; } /* * want to do seq stuff somewhere in ieee80211_*(), * but I guess this is the only place could do. */ do_seqnum_stuff; /* simply put a packet onto dma-able memory area */ pass2hw; } sc->sc_tx = NOT_RUNNING; } No additional context switching, no long-held lock, but first queue first tx. AK >> >> See my (very recent) email to -wireless - I broke TCP throughput quite >> substantially by moving ath(4) TX into the taskqueue. I thought the >> problem was _just_ going to be how overlapping, direct dispatch TX >> could be preempted by the RX tasklet and TX completion, but there's >> obviously more going on. > > > I can't believe that TCP is getting broken by just introducing some > additional delay in the TX path. That can't add more than 300ms, > can it? There must be something else going on. Most likely either > severe packet loss (the m_nextpkt leak you mentioned earlier) or > severe packet re-ordering. > > So don't rule out the TX taskqueue concept quite yet. > > -- > Andre > From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 17:52:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92F6038B; Mon, 29 Oct 2012 17:52:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 301E68FC16; Mon, 29 Oct 2012 17:52:55 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so6299209obb.13 for ; Mon, 29 Oct 2012 10:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=H6UIu1viDS7/ULG8ZXlWQYGpRnJK290lXLYbkhIhJJw=; b=pgxAVRoi8mMswUhDDitkFBC8cJMJgCBkiTooDANVOc68XzFNvclBgSdSeOpxno76zH oMnjV43biBi1XyydD9HefofuufDcrM6hV5M69tym0HwjxTl5bvTx9w6IeSSgQ+r7uRrH 2gcZ13vYa9hXeFn9ZfE041NNed15redRKFncMFYTeZZM4/gfr0St4Awb6IL8HnUcRzWa ECJe0YYHdwJGt8mAfgHYGBAspHKMc6FS109gj/4bC4HHjE6qVRKGjK3FQbdb1k8H/NxN 44OWerHwkz7xsWOPmI7jvPcCJiJrGsz8ksP90Zmac/hHdgRT8GG56xX/2FkXIZ5StCEL hqig== MIME-Version: 1.0 Received: by 10.182.69.50 with SMTP id b18mr25300096obu.75.1351533175595; Mon, 29 Oct 2012 10:52:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Mon, 29 Oct 2012 10:52:55 -0700 (PDT) In-Reply-To: References: <508E50A3.1030008@networx.ch> Date: Mon, 29 Oct 2012 10:52:55 -0700 X-Google-Sender-Auth: XduIE-ahB3kfGazWrAdsRRvCLU0 Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 29 Oct 2012 17:52:56 -0000 The problem with this is that fragments need to be handed as an entire list to the driver. ath(4) looks ahead to the next fragment, calculates the rate, and then adds that to the NAV of the previous frame. So yeah what I'm thinking about for now is something like the following: * say that wifi drivers have to move to if_transmit(); * "abuse" if_transmit() semantics to assume a m_nextpkt chain of mbufs is a fragment list for a single frame; * for now, figure out why the hell the ath(4) TX taskqueue setup is providing crappy throughput and fix _that_; * then migrate the net80211 TX to a taskqueue; * .. and then just undo the ath(4) TX taskqueue since now TX is serialised by if_transmit() inside the net80211 TX taskqueue. There are other things to do, mostly surrounding fixing up the power save queue handling to repopulate the queue packet-by-packet, rather than doing if_snd gymnastics. Once that's done, we can look at ways to implement serialisation besides just using a taskqueue - eg, using the running/not-running flag idea you've suggested. The big problem here is that once TX completion occurs, drivers kick off new TX. Now, if all TX is triggered by a frame TX, the TX will stall until the next frame is attempted. What we'd have to do is tell the drivers how to 'kick' the net80211 stack TX again. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 02:57:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8136DDA for ; Tue, 30 Oct 2012 02:57:01 +0000 (UTC) (envelope-from prvs=1650b10a0f=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 609948FC12 for ; Tue, 30 Oct 2012 02:57:00 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50000874486.msg for ; Tue, 30 Oct 2012 02:56:59 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 30 Oct 2012 02:56:59 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1650b10a0f=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: , "Jack Vogel" Subject: Missing / broken ixgbe sysctl's and tunables PR kern/173201 (patch included) Date: Tue, 30 Oct 2012 02:56:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 02:57:01 -0000 I've been having issues getting a ixgbe (ix) device to link reliably in a decent amount of time at boot to 1Gbps switch connected on cat 5, even netwait was timing out. Having a dig in the code there's advertise_speed which seemed like it was just what I was looking for but unfortunately sysctl.conf is too late in the boot process to have any effect. Looking for the syscyl for ixgbe I found none so dug around and noticed all the tunables where missing sysctl's hence not displaying. In addition noticed enable_aim was using a common var instead of device independent which is what its config dev.ix.0.enable_aim indicated to me. I've created a patch to fix all of the above which can be found here in PR here when its been processed:- http://www.freebsd.org/cgi/query-pr.cgi?pr=173201 Hope it helps. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 07:29:46 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5842556E; Tue, 30 Oct 2012 07:29:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 271598FC0C; Tue, 30 Oct 2012 07:29:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9U7Tk52049047; Tue, 30 Oct 2012 07:29:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9U7Tjb4049043; Tue, 30 Oct 2012 07:29:45 GMT (envelope-from linimon) Date: Tue, 30 Oct 2012 07:29:45 GMT Message-Id: <201210300729.q9U7Tjb4049043@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173201: [ixgbe] [patch] Missing / broken ixgbe sysctl's and tunables (patch included) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 07:29:46 -0000 Old Synopsis: Missing / broken ixgbe sysctl's and tunables (patch included) New Synopsis: [ixgbe] [patch] Missing / broken ixgbe sysctl's and tunables (patch included) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 30 07:29:33 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173201 From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 15:11:14 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FE4C566; Tue, 30 Oct 2012 15:11:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2D69C8FC0C; Tue, 30 Oct 2012 15:11:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q9UFBEmS096206; Tue, 30 Oct 2012 15:11:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q9UFBEri096202; Tue, 30 Oct 2012 15:11:14 GMT (envelope-from linimon) Date: Tue, 30 Oct 2012 15:11:14 GMT Message-Id: <201210301511.q9UFBEri096202@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173002: [patch] data type size problem in if_spppsubr.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 15:11:14 -0000 Old Synopsis: data type size problem in if_spppsubr.c New Synopsis: [patch] data type size problem in if_spppsubr.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 30 15:10:40 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173002 From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 15:23:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DF0C9886 for ; Tue, 30 Oct 2012 15:23:41 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 837E18FC0A for ; Tue, 30 Oct 2012 15:23:41 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so558706vcb.13 for ; Tue, 30 Oct 2012 08:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomjudge.com; s=google; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding; bh=pDQjGdzu6eiP9URVB/14yShaitKAQqMXUWBwf0YbQF8=; b=MFwWyWFIZ1+9nR8dT0teYu4dSiSAAgA0i9L2LsmI/6SnER3hPAbz0BnEo9rlg3vFKP S5EcookR0Zch4E+iPWukEVFDk2jpAatmSMCy9VZhQZcfu5GEiOIZkKj6q07Oq0yWdd22 VNEcrwRAjJD2EOAEbeaDKFqriRdqKpZg+jsKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:x-enigmail-version:content-type:content-transfer-encoding :x-gm-message-state; bh=pDQjGdzu6eiP9URVB/14yShaitKAQqMXUWBwf0YbQF8=; b=OsarMYyf6ruan09l9RtMGqHYH3h+n6pOcop7NqRUUOCVBAsH5H0bxkploE8LxbnKIX MH6x++6RZ7YAJlx711EYf6NSl87juZJU06ksvChNEelvfa8P3+ZQjftvAcrCdSnnfgyM ZHih5xFZfkG1Rs6z/Up7c8YcTVxAtLQBXLhU9golu7FXJHcoPXH6lm8mzuof1WHlQnRg AynSFTeOtdRE2KfK+h2crzjkI4JQFsC+4tE93gxrMX4wgS63WbAA8T/J4yn3bPDEGvAj vlr1lyt2ORzYNj4xiXln9H73VSOnl/fwt2X0uCfN0nP7h+N8IamcOiCG9nGD9eSpoqs7 bUQw== Received: by 10.220.229.133 with SMTP id ji5mr13384542vcb.51.1351610619709; Tue, 30 Oct 2012 08:23:39 -0700 (PDT) Received: from 192-168-200-56.lan.tj.home.tomjudge.com (ip98-169-137-241.dc.dc.cox.net. [98.169.137.241]) by mx.google.com with ESMTPS id w17sm507013vdf.16.2012.10.30.08.23.38 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 08:23:38 -0700 (PDT) Sender: Tom Judge Message-ID: <508FF0F9.9020105@freebsd.org> Date: Tue, 30 Oct 2012 11:23:37 -0400 From: Tom Judge Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: FreeBSD Net Subject: bxe + if_lagg X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQllI19Ib+iA1zALHNmPdYSJa8qGobi47iU7y147Som/nwTPlGBNtXnX26pqWZ93p/kyOUf6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 15:23:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to get if_lagg working in an HP blade for failover between the 2 in chassis cisco switches, but it would seem that the link state is not being propagated up to the lagg device. Any hints/ideas? dmesg: bxe1: metric 0 mtu 1500 options=1bb ether 00:25:b3:a8:76:e4 nd6 options=29 media: Ethernet autoselect (10Gbase-SR ) status: active lagg0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:25:b3:a8:76:e4 nd6 options=29 media: Ethernet autoselect status: no carrier laggproto failover laggport: bxe1 flags=1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQj/D5AAoJEEJSM9yB4iIWxG4H/250zytRh6knhMPlml/fRh5V 0pwUMA/kFR6+8Ov4LU5o0NMzaFJ7OpwLILgmyxup8xP6XIcxmVkuK72X0h+wYB+6 aVLyGPiqro7lDj4SPFQOO6KxXghZf41O0dwjrUxf7cHIZRGAyQd0c+L4i+r4Q6g4 HJQqNZ+M7x6MBvyhA3T53IvXtPVxXbHw/D5gK3Y92HtoiIAaSaaaDBA2wEg2q8Pi pwXXTkAklwsMQpJzoRuRdWjud1VunH5PQ6uvfi5Wp5ldmyH1c2BtZ0gech09sMar xV/INBNc2xijBxX/Cv7hx3JbUOCGFg/t8i5gD5jxYgpiXXJ/WMU/6oxWFcFQaD8= =bk5c -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 16:12:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3D9AE97 for ; Tue, 30 Oct 2012 16:12:14 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id C2A368FC14 for ; Tue, 30 Oct 2012 16:12:14 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id CFB3B86A62 for ; Tue, 30 Oct 2012 12:12:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py4oojvX14J3 for ; Tue, 30 Oct 2012 12:12:07 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <508FFC57.6040302@egr.msu.edu> Date: Tue, 30 Oct 2012 12:12:07 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bxe + if_lagg References: <508FF0F9.9020105@freebsd.org> In-Reply-To: <508FF0F9.9020105@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 16:12:15 -0000 On 10/30/12 11:23, Tom Judge wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > I am trying to get if_lagg working in an HP blade for failover between > the 2 in chassis cisco switches, but it would seem that the link state > is not being propagated up to the lagg device. > > Any hints/ideas? > > > > dmesg: > bxe1: bxe1: Ethernet address: 00:25:b3:a8:76:e4 > bxe1: ASIC (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags > (MSI-X); Queues (RSS:16); BD's (RX:510,TX:255); Firmware (5.2.13); > Bootcode (4.8.0) > > > > bxe1: flags=8843 metric 0 > mtu 1500 > options=1bb > ether 00:25:b3:a8:76:e4 > nd6 options=29 > media: Ethernet autoselect (10Gbase-SR ) > status: active > > lagg0: flags=8843 metric 0 > mtu 1500 > options=1bb > ether 00:25:b3:a8:76:e4 > nd6 options=29 > media: Ethernet autoselect > status: no carrier > laggproto failover > laggport: bxe1 flags=1 Do you need two physical interfaces configured for failover mode to do any good? From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 16:45:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6F1D724 for ; Tue, 30 Oct 2012 16:45:12 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E1C98FC0C for ; Tue, 30 Oct 2012 16:45:12 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so689854vcb.13 for ; Tue, 30 Oct 2012 09:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomjudge.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=lhmv7mW7yteixfTkIWOZER7KIDnpjKdsozbF+oF0+Pc=; b=gLztfh2iCQw8PT3N9MHRplniZm1+XmBY7CqJmlbkpg3HUFv9ZVzcaJbH0oRTQ0uzLU d6pRdL8Ssvo3eIDUqk2wi0beYxaqbP0ViYngv1cbDZrox3qYP6YcK3Fed5rxMnNEPPN5 nXH9CVC5xAledcrmkQEbQKNhXd+UAOJulNoMI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=lhmv7mW7yteixfTkIWOZER7KIDnpjKdsozbF+oF0+Pc=; b=pTknsZY1kO5gZB0KnCwHvoUxRYpiQm35Gf1C4I08ty57hduXAW3e1VPLGxIIa8vJZt qzmqwaYNj7s0R2AwvBg10EVJVW8xOa22Kojx19aK+v7zcKBu/wA68H5tmvHwjFMaleUj cj9l3vbM0KU2A9b9s/GjeMffGnyAUzRD/tYp9U3avoYvyeyh7SpsWmhLpWEamy30U6Y3 7yTCJ+g00uHjuSMUlSmSBxADUrGHfU29ryTCftiKn1GqU3I7CWix1eopq0gPJClSKaW4 o50JY9r4o+kt/kOYqBxx5H8DRGe/HXRumJM5mjof2ZEGOoTG9N5AL2pJF7ij4XlgCPs5 6ULA== Received: by 10.52.95.34 with SMTP id dh2mr43677180vdb.69.1351615511658; Tue, 30 Oct 2012 09:45:11 -0700 (PDT) Received: from 192-168-200-56.lan.tj.home.tomjudge.com (ip98-169-137-241.dc.dc.cox.net. [98.169.137.241]) by mx.google.com with ESMTPS id u2sm623388vdt.11.2012.10.30.09.45.10 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 09:45:11 -0700 (PDT) Message-ID: <50900415.8060602@tomjudge.com> Date: Tue, 30 Oct 2012 12:45:09 -0400 From: Tom Judge User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Adam McDougall Subject: Re: bxe + if_lagg References: <508FF0F9.9020105@freebsd.org> <508FFC57.6040302@egr.msu.edu> In-Reply-To: <508FFC57.6040302@egr.msu.edu> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQly0Ht9zPz7CHF0TsWDs/VuvaSiefZZCqVyO2XLxWEqeQnAGjauyeDfmS/IQFiLEq6km3FO Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 16:45:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/10/2012 12:12, Adam McDougall wrote: > On 10/30/12 11:23, Tom Judge wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> >> I am trying to get if_lagg working in an HP blade for failover >> between the 2 in chassis cisco switches, but it would seem that >> the link state is not being propagated up to the lagg device. >> >> Any hints/ideas? >> >> >> >> dmesg: bxe1: > v:1.5.52 bxe1: Ethernet address: 00:25:b3:a8:76:e4 bxe1: ASIC >> (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags (MSI-X); >> Queues (RSS:16); BD's (RX:510,TX:255); Firmware (5.2.13); >> Bootcode (4.8.0) >> >> >> >> bxe1: flags=8843 metric >> 0 mtu 1500 >> options=1bb >> >> >> ether 00:25:b3:a8:76:e4 >> nd6 options=29 media: >> Ethernet autoselect (10Gbase-SR ) status: active >> >> lagg0: flags=8843 metric >> 0 mtu 1500 >> options=1bb >> >> >> ether 00:25:b3:a8:76:e4 >> nd6 options=29 media: >> Ethernet autoselect status: no carrier laggproto failover >> laggport: bxe1 flags=1 > > Do you need two physical interfaces configured for failover mode to > do any good? > Forgot to mention this is 9.0-RELEASE. No, a single interface should set status active: bce0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:1e:0b:c4:00:a2 nd6 options=29 media: Ethernet autoselect (1000baseSX ) status: active lagg0: flags=8843 metric 0 mtu 1500 options=c01bb ether 00:1e:0b:c4:00:a2 nd6 options=29 media: Ethernet autoselect status: active laggproto failover laggport: bce0 flags=5 > _______________________________________________ > 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" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkAQVAAoJEEJSM9yB4iIWf2wH/2ven2WIK/mdj4dTW5Q6GzlG rCSZb7ZJxVFXEjtr5Kb17veNvlxOvVqk5ZFW7Eln/Ovydz2m/Q2bOrV6Y85xkxlN YJJBs8luYKG11quXnvpgoCX5kttoYkvBuDsBkuTcype1AveYcOpsuITUAbosPIUt dc7+sXhzkKNmQQgBQR0YJKHUmimanR4hCF6zhY9O3g9fJwHgy3sIlRQPMXmvBDmg HGcbYR7ZpowqPHfrT0DtsYfviHGwEOOoR7v9OyDfzngEb9NCLGgjQVVU5ckl1bpJ jJQU4mqktyX49GZN9aX0quaHUcGU5PnWohcA5bYJAstA2217mk2fUq83wZD/r+s= =89pg -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 16:51:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 891C98EE for ; Tue, 30 Oct 2012 16:51:18 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 548638FC0C for ; Tue, 30 Oct 2012 16:51:18 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so331721pad.13 for ; Tue, 30 Oct 2012 09:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=62nsPJywDjzoWd4vIDihCcClIE+MBaUp3AyEPbQuttg=; b=PRtBYFUCJd/aFh8EDAwnnBWdo+nyTooYGVAVJLGNJuJmb8YbYnz0Vd1q4KHByP88JB TC5vym0U/k5tKNsM6QeNNzxnpoRzH8FdiXpQ2mQ9GgKuQyMR4pCnoOC/OfmSVXKqkelZ a7MgjL6M8mvoehjQL0W+mDQ2OFG509Rnn5oPue+3EuSCE13wuIRoOEQFMmhEg1WtJOJG a4JpTq4Iioio1jfCjHgQwkQ1ulsP6j3bDHqGj46vt8Ih5yW58tK3TPgQ+R8AQeWnYqgY 4YejItb4WE3dsekHDcfMTI3RmPXepOnspQHCLK2RgGDSviBLf3+uAqYj7J1WJQ98LcXw xWiw== Received: by 10.68.234.201 with SMTP id ug9mr62668761pbc.63.1351615878068; Tue, 30 Oct 2012 09:51:18 -0700 (PDT) Received: from [10.142.190.62] (mobile-166-147-081-075.mycingular.net. [166.147.81.75]) by mx.google.com with ESMTPS id c8sm663404pav.4.2012.10.30.09.51.15 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 09:51:17 -0700 (PDT) References: <508FF0F9.9020105@freebsd.org> <508FFC57.6040302@egr.msu.edu> <50900415.8060602@tomjudge.com> Mime-Version: 1.0 (1.0) In-Reply-To: <50900415.8060602@tomjudge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: Garrett Cooper Subject: Re: bxe + if_lagg Date: Tue, 30 Oct 2012 09:51:13 -0700 To: Tom Judge Cc: "freebsd-net@freebsd.org" , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 16:51:18 -0000 On Oct 30, 2012, at 9:45 AM, Tom Judge wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 30/10/2012 12:12, Adam McDougall wrote: >> On 10/30/12 11:23, Tom Judge wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>=20 >>>=20 >>>=20 >>> I am trying to get if_lagg working in an HP blade for failover >>> between the 2 in chassis cisco switches, but it would seem that >>> the link state is not being propagated up to the lagg device. >>>=20 >>> Any hints/ideas? >>>=20 >>>=20 >>>=20 >>> dmesg: bxe1: >> v:1.5.52 bxe1: Ethernet address: 00:25:b3:a8:76:e4 bxe1: ASIC >>> (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags (MSI-X); >>> Queues (RSS:16); BD's (RX:510,TX:255); Firmware (5.2.13);=20 >>> Bootcode (4.8.0) >>>=20 >>>=20 >>>=20 >>> bxe1: flags=3D8843 metric >>> 0 mtu 1500=20 >>> options=3D1bb > ether 00:25:b3:a8:76:e4 >>> nd6 options=3D29 media: >>> Ethernet autoselect (10Gbase-SR ) status: active >>>=20 >>> lagg0: flags=3D8843 metric >>> 0 mtu 1500=20 >>> options=3D1bb > ether 00:25:b3:a8:76:e4 >>> nd6 options=3D29 media: >>> Ethernet autoselect status: no carrier laggproto failover=20 >>> laggport: bxe1 flags=3D1 >>=20 >> Do you need two physical interfaces configured for failover mode to >> do any good? >=20 > Forgot to mention this is 9.0-RELEASE. >=20 > No, a single interface should set status active: >=20 > bce0: flags=3D8843 metric 0 mtu 15= 00 > options=3Dc01bb > ether 00:1e:0b:c4:00:a2 > nd6 options=3D29 > media: Ethernet autoselect (1000baseSX ) > status: active >=20 > lagg0: flags=3D8843 metric 0 mtu > 1500 > options=3Dc01bb > ether 00:1e:0b:c4:00:a2 > nd6 options=3D29 > media: Ethernet autoselect > status: active > laggproto failover > laggport: bce0 flags=3D5 Have you tried ifconfig up'ing the lagg? Shouldn't have to if things were fu= nctioning properly, but you might have to. If that works, then assigning an address to the interface or adding an ifcon= fig up in rc.local might workaround the issue. Cheers, -Garrett= From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 17:10:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 880FE89E for ; Tue, 30 Oct 2012 17:10:42 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6408FC12 for ; Tue, 30 Oct 2012 17:10:41 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so707018vba.13 for ; Tue, 30 Oct 2012 10:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomjudge.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=xrI+xeXABqIn7G9VGN+ycPT2vHdHMX4KuvyNXc0S3So=; b=ZTh+VfMqgD+chW7EDUTplVm3rWgM4XFI91ZKSzXAUc4SsQkgniEMMlE47EiyTx2wNi VeWfPy8neir0eFmkHgA51lygcUnuCQdI8j3k5wUQEZD47n5D4Re+fVhN10XbVdxdDxKN +B8nCgmxgMfUv4JlqQR0srqKlY6zGV+NIcGLI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=xrI+xeXABqIn7G9VGN+ycPT2vHdHMX4KuvyNXc0S3So=; b=XkEjKD51Dw+CzR4XdCdn5+t/ApFvxEEEaF0D/0E7hksoZrV4ueL8FIsne+lBCvh1vS Y+66xDZ7dR/4GMBvuLI41I9UQvRlRBigfH2hX/QwoSHCO763HzIpqFe1A4PIANcUVpbb y1bAI2AMLFOB3swV8+VfMDfBMK1Ka/zu1NqOgAsF2dT2c3Cl/yyVFHBOlWx2iJQF6OIY OXWEK2K4k+fTL3Re3DrGRhqDo3e7VVU+GZdT4odg0WGUe7WOHZ0Ioq8VbeSGAmXzZ1qX 1oJ/IFdBWXRf9j1obRmLcJECcubyp4hMVTkRMjJ7V1zJCbHBSYKEq5WADWFheLRK7gH5 YoiA== Received: by 10.220.227.70 with SMTP id iz6mr14477034vcb.45.1351617040221; Tue, 30 Oct 2012 10:10:40 -0700 (PDT) Received: from 192-168-200-56.lan.tj.home.tomjudge.com (ip98-169-137-241.dc.dc.cox.net. [98.169.137.241]) by mx.google.com with ESMTPS id u2sm660465vdt.11.2012.10.30.10.10.38 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 10:10:39 -0700 (PDT) Message-ID: <50900A0D.7080502@tomjudge.com> Date: Tue, 30 Oct 2012 13:10:37 -0400 From: Tom Judge User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: bxe + if_lagg References: <508FF0F9.9020105@freebsd.org> <508FFC57.6040302@egr.msu.edu> <50900415.8060602@tomjudge.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnx9Frg0E5kg7qYatMocF7DzDAaTwpiEYfDlvUUkF5GFdPUScprpXa1VYk2wUl8HuOofZoY Cc: "freebsd-net@freebsd.org" , Adam McDougall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 30 Oct 2012 17:10:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/10/2012 12:51, Garrett Cooper wrote: > On Oct 30, 2012, at 9:45 AM, Tom Judge wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 30/10/2012 12:12, Adam McDougall wrote: >>> On 10/30/12 11:23, Tom Judge wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> >>>> >>>> I am trying to get if_lagg working in an HP blade for >>>> failover between the 2 in chassis cisco switches, but it >>>> would seem that the link state is not being propagated up to >>>> the lagg device. >>>> >>>> Any hints/ideas? >>>> >>>> >>>> >>>> dmesg: bxe1: >>> v:1.5.52 bxe1: Ethernet address: 00:25:b3:a8:76:e4 bxe1: >>>> ASIC (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags >>>> (MSI-X); Queues (RSS:16); BD's (RX:510,TX:255); Firmware >>>> (5.2.13); Bootcode (4.8.0) >>>> >>>> >>>> >>>> bxe1: flags=8843 >>>> metric 0 mtu 1500 >>>> options=1bb >> >>>> ether 00:25:b3:a8:76:e4 >>>> nd6 options=29 media: >>>> Ethernet autoselect (10Gbase-SR ) status: >>>> active >>>> >>>> lagg0: flags=8843 >>>> metric 0 mtu 1500 >>>> options=1bb >> >>>> ether 00:25:b3:a8:76:e4 >>>> nd6 options=29 media: >>>> Ethernet autoselect status: no carrier laggproto failover >>>> laggport: bxe1 flags=1 >>> >>> Do you need two physical interfaces configured for failover >>> mode to do any good? >> >> Forgot to mention this is 9.0-RELEASE. >> >> No, a single interface should set status active: >> >> bce0: flags=8843 metric 0 >> mtu 1500 >> options=c01bb >> >> ether 00:1e:0b:c4:00:a2 >> nd6 options=29 media: >> Ethernet autoselect (1000baseSX ) status: active >> >> lagg0: flags=8843 metric >> 0 mtu 1500 >> options=c01bb >> >> ether 00:1e:0b:c4:00:a2 >> nd6 options=29 media: >> Ethernet autoselect status: active laggproto failover laggport: >> bce0 flags=5 > > Have you tried ifconfig up'ing the lagg? Shouldn't have to if > things were functioning properly, but you might have to. > > If that works, then assigning an address to the interface or adding > an ifconfig up in rc.local might workaround the issue. > Nope these don't resolve the issue, its almost like lagg cant see the link state of the members. Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkAoNAAoJEEJSM9yB4iIWyKEH/05lgpN4U7UzNuhLCXq5Wi33 GlpGX3yFWVS/eFo3HYv5aMh6KyF8THrlfiqWA+PYjdk7qHwa9iwLbOrr/XwtqbbV ZtKYFYPWd/gVGEwvE273u/tqQGHHn7FtoY1wQUCry1F3WcVjbY00ZjtOYzqnHZcd NYY/VhkViqh2MaD3CmIWUARRwTjm1k/km6NcUmjsb49FcMT6XpkVQYRkLJc7SQtI li4HnppzU2LIJaI1PaPGlFHEJXYX5qkiH19hA8AFxxXCyB8MA+SZN1JY2nX7OE3N mvy/FlmBkbb/V5TnPCksjaZne2Rkw/xugi7NTG2MWeLtGOmxBmDZU78ZJmAd4GA= =7lbT -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Oct 30 19:39:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBEEBFB1 for ; Tue, 30 Oct 2012 19:39:27 +0000 (UTC) (envelope-from 538c.21f8275e@vmail17.mynewsletterbuilder.com) Received: from vmail17.mynewsletterbuilder.com (vmail17.mynewsletterbuilder.com [208.83.141.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5048A8FC18 for ; Tue, 30 Oct 2012 19:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mynewsletterbuilder.com; s=dknewsletter; t=1351625965; bh=JU0/UuUp8TO1lHuomleOQ65W27U=; h=Date:From:Reply-To:To:Subject:Message-ID:List-Unsubscribe: Content-Type:MIME-Version; b=RYjSexMNuJSoR/h7uFtEE4gjgwRWgwcBEaqsSUJ2+jA6WwkM23aJLoBOSBKGgw0sM 0D5A9E6fGlC+3rH3A9EPddgDtiS0+afuUC8XCADzAj/hfC6ebQ1Fy43Caz9Fk51egR K3WcueFVBmbjZwIXYtPQ6HJLkZA/IabByG3YOqlk= Date: Tue, 30 Oct 2012 15:39:25 -0400 From: "Dave George" To: Subject: Halloween Weekend Sale Get 15% Off this Weekend Message-ID: <538c.21f8275e.35c2e1d5@vmail17.mynewsletterbuilder.com> X-MNB-TRACKING: YmVhdHNmb3JyYXBwZXJzIDogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcgOiA4MTMwNTg2NDM0 X-MNB-SENDID: 8130586434 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Dave George List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:39:27 -0000 Halloween Sale - GET 15% OFF USE COUPON CODE "HALL"=C2=A0Brand New | You Asked for it You Got it ! | 100= % Targetted Followers =C2=A0FaceBook Likes | YouTube Views | Twitter Followers : http://promogoons.com/?product=3Dnew-100-targeted-followers 100% Targeted= Followers : http://promogoons.com/?product=3Dnew-100-targeted-followers Ge= t 100% Laser-Targeted Followers . Packages from 1000 to 4000 targeted Follo= wers per month , read more... : http://promogoons.com/?product=3Dnew-100-ta= rgeted-followers : http://promogoons.com/?product=3Dtwitter 10,000 Followe= rs $20 : http://promogoons.com/?product=3Dtwitter Get 10,000 Untargeted Fol= lowers for just $50 . We can help you jumpstart your twitter account , read= more ... : http://promogoons.com/?product=3Dtwitter : http://promogoons.com/?product=3Dyoutube Real Youtube Views : http://prom= ogoons.com/?product=3Dyoutube Need Youtube Views to catch that A&R's eye ? = We have 100% Real Views and are Partner Safe, =C2=A0=C2=A0read more... : ht= tp://promogoons.com/?product=3Dyoutube : http://promogoons.com/?product=3D= facebook FaceBook Likes : http://promogoons.com/?product=3Dfacebook Lets fa= ce it , who doesnt need more facebook likes ? We have what you need , read more ... : http://promogoons.com/?product=3Dfacebook : http://promogoons.com/?product=3Dsoundcloud SoundCloud Plays : http://pro= mogoons.com/?product=3Dsoundcloud Fast , Economical and Fun, Let Us Help yo= u get more Soundcloud plays , read more... : http://promogoons.com/?product= =3Dsoundcloud : http://promogoons.com/?product=3Ddatpiff-plays DatPiff Str= eams : http://promogoons.com/?product=3Ddatpiff-plays Got A Hot Mixtape on = DatPiff ? ? Cant Seem to cut through the wack tapes on the front page ? rea= d more... : http://promogoons.com/?product=3Ddatpiff-plays REPEAT CLIENTS GET 15% OFF |=C2=A0USE COUPON CODE "HALL" ON CHECKOUT Promogoons.com : http://promogoons.com | The Major Label's Dirty Little Se= cret Dave George - 678 508 2941 - sales@promogoons.com : mailto:sales@promogoons= .com=20 Skype | Yahoo | AIM : Promogoons United Promotions - po box 1526 - atlanta - GA - 30316 Subscribe to this newsletter: https://www.mynewsletterbuilder.com/tools/subscription.php?username=3Dbeats= forrappers&send_id=3D8130586434&l=3Ds&newsletter_id=3D1411516624 Unsubscribe freebsd-net@freebsd.org: https://www.mynewsletterbuilder.com/tools/subscription.php?username=3Dbeats= forrappers&send_id=3D8130586434&l=3Du&email=3Dfreebsd-net@freebsd.org Change your preferences: https://www.mynewsletterbuilder.com/tools/subscription.php?username=3Dbeats= forrappers&send_id=3D8130586434&l=3Dp&email=3Dfreebsd-net@freebsd.org Forward to a friend: https://www.mynewsletterbuilder.com/tools/forward.php?username=3Dbeatsforra= ppers&newsletter_id=3D1411516624&send_id=3D8130586434 Report this email as spam: https://www.mynewsletterbuilder.com/tools/abuse_report.php?username=3Dbeats= forrappers&send_id=3D8130586434&email=3Dfreebsd-net@freebsd.org This email was sent using MyNewsletterBuilder.com. From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 06:42:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E6026BA; Wed, 31 Oct 2012 06:42:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D08408FC14; Wed, 31 Oct 2012 06:42:35 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so806301pbb.13 for ; Tue, 30 Oct 2012 23:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dt5l5MclRcSnB1EKVJHhUdxaDN4rTy4U2FGmJPwu4bU=; b=Ai2MBcLt5LtPhc34L/2bxr7AdJb8p+wmKho/cRGL+/hkp19EC703QNiK1xxJMGRhNK xSA5A5lo4cQUnl/MBo0nF8CpdHtowhB4+fkcLL2SnmLWw2l2pOwmrdjLIunUTwYcnnKC YAR4QdTbCdjTn1KbZXHdayaF6DPee9jgrQnIq3WFuytAV0fC+58M+KoOJ811mkCaeLbs pXrrRj86Ki/2YtP2o88VV6rsbk83PDuySSTe/yhTS2IB4y1R/wD4dOIw03OHR3whasaD mLkVt+oraRPWZGNVIIyVJ/ldPyOuRDxhDwK8JFlQf6X2OaLlmfVXFnIhlXictDTJROQf Gl0Q== MIME-Version: 1.0 Received: by 10.66.73.230 with SMTP id o6mr99340786pav.45.1351665755328; Tue, 30 Oct 2012 23:42:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Tue, 30 Oct 2012 23:42:35 -0700 (PDT) In-Reply-To: References: <508E50A3.1030008@networx.ch> Date: Tue, 30 Oct 2012 23:42:35 -0700 X-Google-Sender-Auth: RHA8otk43RPWLQ4-E6groky9SQo Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 06:42:36 -0000 So I cheaped out for now and just wrapped the ath TX path in a new TX only lock. I'm open to other suggestions about how to make the "queue everything through a taskqueue" work, but unfortunately it seems that I'm defeated by the inner workings of the network stack locking and how that plays with the scheduler. I even tried experimenting with a second taskqueue just for TX but it still suffered from much reduced performance. The annoying thing? Changing the eventtimer to enable periodic+idletick improved performance as well as flipping machdep.idle=spin. I thought that stuff was fixed but alas. So now this is done, I may create a per-VAP TX lock in net80211 in order to serialise raw and normal net80211 TX; that will fix a lot of the the serialisation and state issues that creep up. Then it's off to if_transmit() land. Thanks everyone, Adrian From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 07:48:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12762327; Wed, 31 Oct 2012 07:48:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C9D328FC0A; Wed, 31 Oct 2012 07:48:11 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so844026pbb.13 for ; Wed, 31 Oct 2012 00:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0ryJgnm+95r0Y0odPSwQTJRdA8y9paBPN9fkXYqc4Q0=; b=yUQqc1eKvWf8AV/6O9EDbFVwzNK6ZR+bA2a9oi1VhTMWAhaH5WM2m3KP8QRW9xNHo/ auPCwUxJVjkAlyyIgZXTVa5wdR5kQD/qVYNUKaHi6MrvUlGkZgxKwwyB64erdnixJoUO 7GAj8tuORkrE9oq3spCKv67Y3z9RkrJo6wf09uYq4+c2rgjdiPw4BYhXgnMMZtPL5A4i pXFJIb96ME7BKgM1TBNGtzfiBg+AbAdNswo/XVQU1wLwdovKFYVVTT4RoD5jEJFjM6xV HRBYH3QiLH+HEhwNk0Rud0TervQWqLI4OaYLBxj/Z7tdUHeuHHmkxlJk4aVn0Q8Xy33/ mpFA== Received: by 10.68.224.69 with SMTP id ra5mr109874668pbc.114.1351669691238; Wed, 31 Oct 2012 00:48:11 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id vw4sm1906105pbc.26.2012.10.31.00.48.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 00:48:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 31 Oct 2012 16:47:37 +0900 From: YongHyeon PYUN Date: Wed, 31 Oct 2012 16:47:37 +0900 To: Tom Judge Subject: Re: bxe + if_lagg Message-ID: <20121031074737.GB1471@michelle.cdnetworks.com> References: <508FF0F9.9020105@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline In-Reply-To: <508FF0F9.9020105@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 07:48:12 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 30, 2012 at 11:23:37AM -0400, Tom Judge wrote: [...] > I am trying to get if_lagg working in an HP blade for failover between > the 2 in chassis cisco switches, but it would seem that the link state > is not being propagated up to the lagg device. > > Any hints/ideas? > > > > dmesg: > bxe1: bxe1: Ethernet address: 00:25:b3:a8:76:e4 > bxe1: ASIC (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags > (MSI-X); Queues (RSS:16); BD's (RX:510,TX:255); Firmware (5.2.13); > Bootcode (4.8.0) > Try attached patch and let me know whether it makes any difference. --s2ZSL+KKDSLx8OML Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bxe.linkstate.diff" Index: sys/dev/bxe/if_bxe.c =================================================================== --- sys/dev/bxe/if_bxe.c (revision 242340) +++ sys/dev/bxe/if_bxe.c (working copy) @@ -2138,8 +2138,10 @@ bxe_attach(device_t dev) ifp->if_init = bxe_init; ifp->if_hwassist = BXE_IF_HWASSIST; ifp->if_capabilities = BXE_IF_CAPABILITIES; + ifp->if_capabilities |= IFCAP_LINKSTATE; /* TPA not enabled by default. */ ifp->if_capenable = BXE_IF_CAPABILITIES & ~IFCAP_LRO; + ifp->if_capenable |= IFCAP_LINKSTATE; if_initbaudrate(ifp, IF_Gbps(10)); ifp->if_snd.ifq_drv_maxlen = sc->tx_ring_size; --s2ZSL+KKDSLx8OML-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 08:59:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 300B86AA for ; Wed, 31 Oct 2012 08:59:51 +0000 (UTC) (envelope-from tsaregorodtsev.denis@itmh.ru) Received: from fatboy.mirasystem.net (unknown [IPv6:2a02:17d0:af:ff01:1:2::]) by mx1.freebsd.org (Postfix) with ESMTP id 97E6A8FC0A for ; Wed, 31 Oct 2012 08:59:50 +0000 (UTC) Received: from tsar.itmh.local (unknown [IPv6:2a02:17d0:8002::92]) by fatboy.mirasystem.net (Postfix) with ESMTP id 9BEF9126D5AE for ; Wed, 31 Oct 2012 13:59:45 +0500 (YEKT) Message-ID: <5090E884.4090901@itmh.ru> Date: Wed, 31 Oct 2012 14:59:48 +0600 From: "tsaregorodtsev.denis@itmh.ru" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPv6 aliases don't work on carp interface Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 08:59:51 -0000 Hi, I've run into a problem while adding IPv6 aliases on carp interface on FreeBSD 8.1. All IPv6 aliases on carp interface are unreachable from other devices but the first IPv6 on carp interface works well. # ifconfig em0: flags=8943 metric 0 mtu 1500 options=9b ether 00:50:56:ad:00:5f inet 172.16.249 netmask 0xffffff00 broadcast 255.255.255.224 inet6 2001:db8:af:ff01:1:be60:80:700 prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 carp0: flags=49 metric 0 mtu 1500 inet6 2001:db8:af:ff01:1:be60:80:70f prefixlen 128 inet6 2001:db8:af:ff01:1:be60:80:70e prefixlen 128 nd6 options=3 carp: MASTER vhid 250 advbase 1 advskew 0 # ping6 2001:db8:af:ff01:1:be60:80:70f PING 2001:db8:af:ff01:1:be60:80:70f(2001:db8:af:ff01:1:be60:80:70f) 56 data bytes 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=1 ttl=59 time=0.793 ms 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=2 ttl=59 time=0.837 ms # ping6 2001:db8:af:ff01:1:be60:80:70e PING 2001:db8:af:ff01:1:be60:80:70e(2001:db8:af:ff01:1:be60:80:70e) 56 data bytes From 2001:db8:af:ff00::1 icmp_seq=1 Destination unreachable: Address unreachable From 2001:db8:af:ff00::1 icmp_seq=4 Destination unreachable: Address unreachable If I delete both IPs and add inet6 2001:db8:af:ff01:1:be60:80:70e before inet6 2001:db8:af:ff01:1:be60:80:70f then 2001:db8:af:ff01:1:be60:80:70e does work and 2001:db8:af:ff01:1:be60:80:70f does not. I googled this issue and found a patchhttp://lists.freebsd.org/pipermail/freebsd-net/2011-August/029619.html I've tried to apply it but the problem still exists. I've tested this issue on FreeBSD9.1 RC2 as well and there was the same problem. Best Regards, Tsaregorodtsev Denis From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 09:48:19 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 668B1108; Wed, 31 Oct 2012 09:48:19 +0000 (UTC) (envelope-from remi.pauchet@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id EC7BE8FC14; Wed, 31 Oct 2012 09:48:18 +0000 (UTC) Received: from [10.2.9.2] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id AAE0327057D1; Wed, 31 Oct 2012 10:48:17 +0100 (CET) Subject: Re: panic ixgbevf / SMP under high network load Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_E52DEB8F-A706-41F2-A7F2-A8D0A5885E2B"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?R=E9mi_Pauchet?= In-Reply-To: <20121026103006.GB70741@glebius.int.ru> Date: Wed, 31 Oct 2012 10:47:59 +0100 Message-Id: <7E43156D-C927-4C18-AD3A-200582C81C65@netasq.com> References: <20121025164031.GA70741@FreeBSD.org> <20121026103006.GB70741@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 09:48:19 -0000 --Apple-Mail=_E52DEB8F-A706-41F2-A7F2-A8D0A5885E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, from a svn checkout r242392: #0 doadump (textdump=3D1) at /usr/svn/head/sys/kern/kern_shutdown.c:266 #1 0xffffffff808d3b72 in kern_reboot (howto=3D260) at = /usr/svn/head/sys/kern/kern_shutdown.c:449 #2 0xffffffff808d359a in panic (fmt=3D0x0) at = /usr/svn/head/sys/kern/kern_shutdown.c:637 #3 0xffffffff8033f737 in db_panic (addr=3DVariable "addr" is not = available. ) at /usr/svn/head/sys/ddb/db_command.c:482 #4 0xffffffff8033fbe1 in db_command (last_cmdp=3D0xffffffff812eb1e0, = cmd_table=3DVariable "cmd_table" is not available. ) at /usr/svn/head/sys/ddb/db_command.c:449 #5 0xffffffff8033fe30 in db_command_loop () at = /usr/svn/head/sys/ddb/db_command.c:502 #6 0xffffffff80341f89 in db_trap (type=3DVariable "type" is not = available. ) at /usr/svn/head/sys/ddb/db_main.c:231 #7 0xffffffff8090c388 in kdb_trap (type=3D12, code=3D0, = tf=3D0xffffff80003739c0) at /usr/svn/head/sys/kern/subr_kdb.c:654 #8 0xffffffff80c61dcd in trap_fatal (frame=3D0xffffff80003739c0, = eva=3DVariable "eva" is not available. ) at /usr/svn/head/sys/amd64/amd64/trap.c:867 #9 0xffffffff80c61f8a in trap_pfault (frame=3D0xffffff80003739c0, = usermode=3D0) at /usr/svn/head/sys/amd64/amd64/trap.c:789 #10 0xffffffff80c626ca in trap (frame=3D0xffffff80003739c0) at = /usr/svn/head/sys/amd64/amd64/trap.c:463 #11 0xffffffff80c4bdb3 in calltrap () at = /usr/svn/head/sys/amd64/amd64/exception.S:228 #12 0xffffffff805a5fbf in ixv_rxeof (que=3D0xfffffe000220cd00, = count=3D118) at /usr/svn/head/sys/dev/ixgbe/ixv.c:3438 #13 0xffffffff805aac91 in ixv_handle_que (context=3DVariable "context" = is not available. ) at /usr/svn/head/sys/dev/ixgbe/ixv.c:980 #14 0xffffffff80919df3 in taskqueue_run_locked = (queue=3D0xfffffe000221a900) at = /usr/svn/head/sys/kern/subr_taskqueue.c:308 #15 0xffffffff8091a89e in taskqueue_thread_loop (arg=3DVariable "arg" is = not available. ) at /usr/svn/head/sys/kern/subr_taskqueue.c:497 #16 0xffffffff808a3e45 in fork_exit (callout=3D0xffffffff8091a860 = , arg=3D0xfffffe000220cd58,=20 frame=3D0xffffff8000373c00) at = /usr/svn/head/sys/kern/kern_fork.c:995 #17 0xffffffff80c4c2de in fork_trampoline () at = /usr/svn/head/sys/amd64/amd64/exception.S:602 Regards, R=E9mi Le 26 oct. 2012 =E0 12:30, Gleb Smirnoff a =E9crit : > On Fri, Oct 26, 2012 at 11:09:20AM +0200, R?mi Pauchet wrote: > R> Hi > R>=20 > R> I have the same crash with FreeBSD 10-current > R>=20 > R> FreeBSD freebsd10 10.0-CURRENT FreeBSD 10.0-CURRENT #4 r241761: Sat = Oct 20 07:40:33 UTC 2012 = root@kaos.glenbarber.us:/usr/obj/usr/src/sys/GENERIC amd64 > R>=20 > R> Sorry for the screenshots: panic doesn't dump the memory to the = swap, I can't figure out why > R>=20 > R> I use udp frames (size 700) so this load is not supposed to produce = ip fragmentation. > R>=20 > R> And again, the panic happens with 4 vcpus, no issue with 1 vcpu. >=20 > r241761 predates conversion of the IPv4 stack to net byte order, which = happened > in r241913. >=20 > Can you please try out your test on head r242077 or later? >=20 > --=20 > Totus tuus, Glebius. --Apple-Mail=_E52DEB8F-A706-41F2-A7F2-A8D0A5885E2B-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 09:53:58 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DBC9348 for ; Wed, 31 Oct 2012 09:53:58 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id EFE158FC0A for ; Wed, 31 Oct 2012 09:53:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9V9rnSQ044235; Wed, 31 Oct 2012 13:53:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9V9rnV6044234; Wed, 31 Oct 2012 13:53:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 31 Oct 2012 13:53:49 +0400 From: Gleb Smirnoff To: R?mi Pauchet Subject: Re: panic ixgbevf / SMP under high network load Message-ID: <20121031095349.GL70741@glebius.int.ru> References: <20121025164031.GA70741@FreeBSD.org> <20121026103006.GB70741@glebius.int.ru> <7E43156D-C927-4C18-AD3A-200582C81C65@netasq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <7E43156D-C927-4C18-AD3A-200582C81C65@netasq.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 09:53:58 -0000 On Wed, Oct 31, 2012 at 10:47:59AM +0100, R?mi Pauchet wrote: R> Hi, R> R> from a svn checkout r242392: R> R> #0 doadump (textdump=1) at /usr/svn/head/sys/kern/kern_shutdown.c:266 R> #1 0xffffffff808d3b72 in kern_reboot (howto=260) at /usr/svn/head/sys/kern/kern_shutdown.c:449 R> #2 0xffffffff808d359a in panic (fmt=0x0) at /usr/svn/head/sys/kern/kern_shutdown.c:637 R> #3 0xffffffff8033f737 in db_panic (addr=Variable "addr" is not available. R> ) at /usr/svn/head/sys/ddb/db_command.c:482 R> #4 0xffffffff8033fbe1 in db_command (last_cmdp=0xffffffff812eb1e0, cmd_table=Variable "cmd_table" is not available. R> ) at /usr/svn/head/sys/ddb/db_command.c:449 R> #5 0xffffffff8033fe30 in db_command_loop () at /usr/svn/head/sys/ddb/db_command.c:502 R> #6 0xffffffff80341f89 in db_trap (type=Variable "type" is not available. R> ) at /usr/svn/head/sys/ddb/db_main.c:231 R> #7 0xffffffff8090c388 in kdb_trap (type=12, code=0, tf=0xffffff80003739c0) at /usr/svn/head/sys/kern/subr_kdb.c:654 R> #8 0xffffffff80c61dcd in trap_fatal (frame=0xffffff80003739c0, eva=Variable "eva" is not available. R> ) at /usr/svn/head/sys/amd64/amd64/trap.c:867 R> #9 0xffffffff80c61f8a in trap_pfault (frame=0xffffff80003739c0, usermode=0) at /usr/svn/head/sys/amd64/amd64/trap.c:789 R> #10 0xffffffff80c626ca in trap (frame=0xffffff80003739c0) at /usr/svn/head/sys/amd64/amd64/trap.c:463 R> #11 0xffffffff80c4bdb3 in calltrap () at /usr/svn/head/sys/amd64/amd64/exception.S:228 R> #12 0xffffffff805a5fbf in ixv_rxeof (que=0xfffffe000220cd00, count=118) at /usr/svn/head/sys/dev/ixgbe/ixv.c:3438 R> #13 0xffffffff805aac91 in ixv_handle_que (context=Variable "context" is not available. R> ) at /usr/svn/head/sys/dev/ixgbe/ixv.c:980 R> #14 0xffffffff80919df3 in taskqueue_run_locked (queue=0xfffffe000221a900) at /usr/svn/head/sys/kern/subr_taskqueue.c:308 R> #15 0xffffffff8091a89e in taskqueue_thread_loop (arg=Variable "arg" is not available. R> ) at /usr/svn/head/sys/kern/subr_taskqueue.c:497 R> #16 0xffffffff808a3e45 in fork_exit (callout=0xffffffff8091a860 , arg=0xfffffe000220cd58, R> frame=0xffffff8000373c00) at /usr/svn/head/sys/kern/kern_fork.c:995 R> #17 0xffffffff80c4c2de in fork_trampoline () at /usr/svn/head/sys/amd64/amd64/exception.S:602 This looks like another one. Can you please obtain the following information from kgdb: (kgdb) frame 12 (kgdb) print *mp -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 09:56:44 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA67740E for ; Wed, 31 Oct 2012 09:56:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 258068FC08 for ; Wed, 31 Oct 2012 09:56:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9V9uhat044306; Wed, 31 Oct 2012 13:56:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9V9uhYq044305; Wed, 31 Oct 2012 13:56:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 31 Oct 2012 13:56:43 +0400 From: Gleb Smirnoff To: "tsaregorodtsev.denis@itmh.ru" Subject: Re: IPv6 aliases don't work on carp interface Message-ID: <20121031095642.GN70741@FreeBSD.org> References: <5090E884.4090901@itmh.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5090E884.4090901@itmh.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 09:56:44 -0000 Denis, On Wed, Oct 31, 2012 at 02:59:48PM +0600, tsaregorodtsev.denis@itmh.ru wrote: t> I've run into a problem while adding IPv6 aliases on carp interface on FreeBSD 8.1. t> All IPv6 aliases on carp interface are unreachable from other devices but the first IPv6 on carp interface works well. t> t> # ifconfig t> em0: flags=8943 metric 0 mtu 1500 t> options=9b t> ether 00:50:56:ad:00:5f t> inet 172.16.249 netmask 0xffffff00 broadcast 255.255.255.224 t> inet6 2001:db8:af:ff01:1:be60:80:700 prefixlen 64 t> nd6 options=3 t> media: Ethernet autoselect (1000baseT ) t> status: active t> ipfw0: flags=8801 metric 0 mtu 65536 t> lo0: flags=8049 metric 0 mtu 16384 t> options=3 t> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 t> inet6 ::1 prefixlen 128 t> inet 127.0.0.1 netmask 0xff000000 t> nd6 options=3 t> carp0: flags=49 metric 0 mtu 1500 t> inet6 2001:db8:af:ff01:1:be60:80:70f prefixlen 128 t> inet6 2001:db8:af:ff01:1:be60:80:70e prefixlen 128 t> nd6 options=3 t> carp: MASTER vhid 250 advbase 1 advskew 0 t> t> # ping6 2001:db8:af:ff01:1:be60:80:70f t> PING 2001:db8:af:ff01:1:be60:80:70f(2001:db8:af:ff01:1:be60:80:70f) 56 data bytes t> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=1 ttl=59 time=0.793 ms t> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=2 ttl=59 time=0.837 ms t> t> # ping6 2001:db8:af:ff01:1:be60:80:70e t> PING 2001:db8:af:ff01:1:be60:80:70e(2001:db8:af:ff01:1:be60:80:70e) 56 data bytes From 2001:db8:af:ff00::1 icmp_seq=1 Destination unreachable: Address unreachable From 2001:db8:af:ff00::1 icmp_seq=4 Destination unreachable: Address unreachable t> t> If I delete both IPs and add inet6 2001:db8:af:ff01:1:be60:80:70e before inet6 2001:db8:af:ff01:1:be60:80:70f then 2001:db8:af:ff01:1:be60:80:70e does work and 2001:db8:af:ff01:1:be60:80:70f does not. t> t> I googled this issue and found a patchhttp://lists.freebsd.org/pipermail/freebsd-net/2011-August/029619.html t> I've tried to apply it but the problem still exists. I've tested this issue on FreeBSD9.1 RC2 as well and there was the same problem. This should work on 10-CURRENT, where the carp(4) had been significantly rewritten. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 09:57:38 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 511D04B3; Wed, 31 Oct 2012 09:57:38 +0000 (UTC) (envelope-from remi.pauchet@netasq.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id CE5AF8FC08; Wed, 31 Oct 2012 09:57:37 +0000 (UTC) Received: from [10.2.9.2] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id 97A1B27056E4; Wed, 31 Oct 2012 10:57:36 +0100 (CET) Subject: Re: panic ixgbevf / SMP under high network load Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_1F51F79A-4F97-4A79-8F8C-8A473870C0D3"; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?R=E9mi_Pauchet?= In-Reply-To: <20121031095349.GL70741@glebius.int.ru> Date: Wed, 31 Oct 2012 10:57:18 +0100 Message-Id: <2BF059F5-7A9C-4F13-AC73-87783E98209A@netasq.com> References: <20121025164031.GA70741@FreeBSD.org> <20121026103006.GB70741@glebius.int.ru> <7E43156D-C927-4C18-AD3A-200582C81C65@netasq.com> <20121031095349.GL70741@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 09:57:38 -0000 --Apple-Mail=_1F51F79A-4F97-4A79-8F8C-8A473870C0D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 31 oct. 2012 =E0 10:53, Gleb Smirnoff a =E9crit : > On Wed, Oct 31, 2012 at 10:47:59AM +0100, R?mi Pauchet wrote: > R> Hi, > R>=20 > R> from a svn checkout r242392: > R>=20 > R> #0 doadump (textdump=3D1) at = /usr/svn/head/sys/kern/kern_shutdown.c:266 > R> #1 0xffffffff808d3b72 in kern_reboot (howto=3D260) at = /usr/svn/head/sys/kern/kern_shutdown.c:449 > R> #2 0xffffffff808d359a in panic (fmt=3D0x0) at = /usr/svn/head/sys/kern/kern_shutdown.c:637 > R> #3 0xffffffff8033f737 in db_panic (addr=3DVariable "addr" is not = available. > R> ) at /usr/svn/head/sys/ddb/db_command.c:482 > R> #4 0xffffffff8033fbe1 in db_command (last_cmdp=3D0xffffffff812eb1e0,= cmd_table=3DVariable "cmd_table" is not available. > R> ) at /usr/svn/head/sys/ddb/db_command.c:449 > R> #5 0xffffffff8033fe30 in db_command_loop () at = /usr/svn/head/sys/ddb/db_command.c:502 > R> #6 0xffffffff80341f89 in db_trap (type=3DVariable "type" is not = available. > R> ) at /usr/svn/head/sys/ddb/db_main.c:231 > R> #7 0xffffffff8090c388 in kdb_trap (type=3D12, code=3D0, = tf=3D0xffffff80003739c0) at /usr/svn/head/sys/kern/subr_kdb.c:654 > R> #8 0xffffffff80c61dcd in trap_fatal (frame=3D0xffffff80003739c0, = eva=3DVariable "eva" is not available. > R> ) at /usr/svn/head/sys/amd64/amd64/trap.c:867 > R> #9 0xffffffff80c61f8a in trap_pfault (frame=3D0xffffff80003739c0, = usermode=3D0) at /usr/svn/head/sys/amd64/amd64/trap.c:789 > R> #10 0xffffffff80c626ca in trap (frame=3D0xffffff80003739c0) at = /usr/svn/head/sys/amd64/amd64/trap.c:463 > R> #11 0xffffffff80c4bdb3 in calltrap () at = /usr/svn/head/sys/amd64/amd64/exception.S:228 > R> #12 0xffffffff805a5fbf in ixv_rxeof (que=3D0xfffffe000220cd00, = count=3D118) at /usr/svn/head/sys/dev/ixgbe/ixv.c:3438 > R> #13 0xffffffff805aac91 in ixv_handle_que (context=3DVariable = "context" is not available. > R> ) at /usr/svn/head/sys/dev/ixgbe/ixv.c:980 > R> #14 0xffffffff80919df3 in taskqueue_run_locked = (queue=3D0xfffffe000221a900) at = /usr/svn/head/sys/kern/subr_taskqueue.c:308 > R> #15 0xffffffff8091a89e in taskqueue_thread_loop (arg=3DVariable = "arg" is not available. > R> ) at /usr/svn/head/sys/kern/subr_taskqueue.c:497 > R> #16 0xffffffff808a3e45 in fork_exit (callout=3D0xffffffff8091a860 = , arg=3D0xfffffe000220cd58,=20 > R> frame=3D0xffffff8000373c00) at = /usr/svn/head/sys/kern/kern_fork.c:995 > R> #17 0xffffffff80c4c2de in fork_trampoline () at = /usr/svn/head/sys/amd64/amd64/exception.S:602 >=20 > This looks like another one. >=20 > Can you please obtain the following information from kgdb: >=20 > (kgdb) frame 12 > (kgdb) print *mp (kgdb) frame 12 #12 0xffffffff805a5fbf in ixv_rxeof (que=3D0xfffffe000220cd00, = count=3D118) at /usr/svn/head/sys/dev/ixgbe/ixv.c:3438 3438 mp->m_len =3D plen; (kgdb) p *mp Cannot access memory at address 0x0 --Apple-Mail=_1F51F79A-4F97-4A79-8F8C-8A473870C0D3-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 10:42:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8EB45146 for ; Wed, 31 Oct 2012 10:42:49 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1458FC08 for ; Wed, 31 Oct 2012 10:42:48 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so604223bkc.13 for ; Wed, 31 Oct 2012 03:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AHTHUwM2HuYrvQgDTO3u6Pgnxon0pZ9RmwhCACjWaUw=; b=oi+tB8DhSYNEDhz6S8sV4Bg8GsZ2pWUAXe8EdN6JAHHswUB9lGWJnoOAwMOcYkJ5qy 75OeuUP1AGB+EkSgPlavFFQElL4or4Dqm6Np7WLs3P6jjQ2kpJtuWi4Rbh37a4uPbLjo a8I3ZIibFYVLevpGyLH0Mj5+Gvgwu4Ggq41jbtOZxxxy5kS9bMrxdLM9LzsavizE+2fQ 7IVdvQAwnNw4d/NZA4gbcqqLzUr32+BOWMf0NNuCpvLJvydg2DLvRmIboxjP3TUOHmks QQkU2aYSNDQy5gcFzdLdWJvM/5mtObmDpjF6sIkI7p1PndT9+5ie7RjjuX3kTA8g9qXa Cv7g== MIME-Version: 1.0 Received: by 10.204.145.214 with SMTP id e22mr10866461bkv.133.1351680168048; Wed, 31 Oct 2012 03:42:48 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.143.148 with HTTP; Wed, 31 Oct 2012 03:42:48 -0700 (PDT) In-Reply-To: <5090E884.4090901@itmh.ru> References: <5090E884.4090901@itmh.ru> Date: Wed, 31 Oct 2012 11:42:48 +0100 X-Google-Sender-Auth: DhsZpPfRNtVImV6wWCaCgOSsEzQ Message-ID: Subject: Re: IPv6 aliases don't work on carp interface From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: "tsaregorodtsev.denis@itmh.ru" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 10:42:49 -0000 On Wed, Oct 31, 2012 at 9:59 AM, tsaregorodtsev.denis@itmh.ru wrote: > Hi, > I've run into a problem while adding IPv6 aliases on carp interface on > FreeBSD 8.1. > All IPv6 aliases on carp interface are unreachable from other devices but > the first IPv6 on carp interface works well. > > # ifconfig > em0: flags=8943 metric 0 mtu > 1500 > options=9b > ether 00:50:56:ad:00:5f > inet 172.16.249 netmask 0xffffff00 broadcast 255.255.255.224 > inet6 2001:db8:af:ff01:1:be60:80:700 prefixlen 64 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > ipfw0: flags=8801 metric 0 mtu 65536 > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=3 > carp0: flags=49 metric 0 mtu 1500 > inet6 2001:db8:af:ff01:1:be60:80:70f prefixlen 128 > inet6 2001:db8:af:ff01:1:be60:80:70e prefixlen 128 > nd6 options=3 > carp: MASTER vhid 250 advbase 1 advskew 0 > > # ping6 2001:db8:af:ff01:1:be60:80:70f > PING 2001:db8:af:ff01:1:be60:80:70f(2001:db8:af:ff01:1:be60:80:70f) 56 data > bytes > 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=1 ttl=59 time=0.793 > ms > 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=2 ttl=59 time=0.837 > ms > > # ping6 2001:db8:af:ff01:1:be60:80:70e > PING 2001:db8:af:ff01:1:be60:80:70e(2001:db8:af:ff01:1:be60:80:70e) 56 data > bytes From 2001:db8:af:ff00::1 icmp_seq=1 Destination unreachable: Address > unreachable From 2001:db8:af:ff00::1 icmp_seq=4 Destination unreachable: > Address unreachable > > If I delete both IPs and add inet6 2001:db8:af:ff01:1:be60:80:70e before > inet6 2001:db8:af:ff01:1:be60:80:70f then 2001:db8:af:ff01:1:be60:80:70e > does work and 2001:db8:af:ff01:1:be60:80:70f does not. > > I googled this issue and found a > patchhttp://lists.freebsd.org/pipermail/freebsd-net/2011-August/029619.html > I've tried to apply it but the problem still exists. I've tested this issue > on FreeBSD9.1 RC2 as well and there was the same problem. > > Best Regards, > Tsaregorodtsev Denis > On pfSense there is a patch carp_ip_aliasfix.diff found here https://github.com/bsdperimeter/pfsense-tools/tree/master/patches/RELENG_8_3 Though the problem with that is that you have to apply many patches before it can be applied as well. > _______________________________________________ > 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" -- Ermal From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 10:43:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28E822B5; Wed, 31 Oct 2012 10:43:47 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC778FC0A; Wed, 31 Oct 2012 10:43:46 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so604751bkc.13 for ; Wed, 31 Oct 2012 03:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EPRCO4c9dM0aPCxF9hNj2CHEF2QWA1PW9SOE8XscW7k=; b=Lm+5MrFIGf8xcwokwBpT3KR5tYk2gaPekc5peCw69lJsGfOwVf0x/XS+O01hGeaow8 W34xtesVLhEY2SmKl5LJay9/wn6VCjMx8QtReD/QNNaK4GoT32DVJDQ51N/Du3NnGREh WWzXb66kdy+fT548t8pKF3vwAUFAZlqwDnuHRqJhoKOviWjbB3AjL/jpACKztXcMQKTI njal8bS8SrI9pMQ/y6T4HSFyEDwizmsKehtFjG/XsM7vFf+DtdEQhWz6WXZUzqB0GHAu o13EJoonw6qtnZWWPcL347WfAWrpIV/E5lCBs4x8Qb/YEEsAJOe2Ha+2ioJLWE3uVDyX 9oTA== MIME-Version: 1.0 Received: by 10.205.127.146 with SMTP id ha18mr11396597bkc.130.1351680225454; Wed, 31 Oct 2012 03:43:45 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.143.148 with HTTP; Wed, 31 Oct 2012 03:43:45 -0700 (PDT) In-Reply-To: <20121031095642.GN70741@FreeBSD.org> References: <5090E884.4090901@itmh.ru> <20121031095642.GN70741@FreeBSD.org> Date: Wed, 31 Oct 2012 11:43:45 +0100 X-Google-Sender-Auth: LDCa7SMG8e8MNVw0YD_tqpA3ky4 Message-ID: Subject: Re: IPv6 aliases don't work on carp interface From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: "tsaregorodtsev.denis@itmh.ru" , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 10:43:47 -0000 On Wed, Oct 31, 2012 at 10:56 AM, Gleb Smirnoff wrote: > Denis, > > On Wed, Oct 31, 2012 at 02:59:48PM +0600, tsaregorodtsev.denis@itmh.ru wrote: > t> I've run into a problem while adding IPv6 aliases on carp interface on FreeBSD 8.1. > t> All IPv6 aliases on carp interface are unreachable from other devices but the first IPv6 on carp interface works well. > t> > t> # ifconfig > t> em0: flags=8943 metric 0 mtu 1500 > t> options=9b > t> ether 00:50:56:ad:00:5f > t> inet 172.16.249 netmask 0xffffff00 broadcast 255.255.255.224 > t> inet6 2001:db8:af:ff01:1:be60:80:700 prefixlen 64 > t> nd6 options=3 > t> media: Ethernet autoselect (1000baseT ) > t> status: active > t> ipfw0: flags=8801 metric 0 mtu 65536 > t> lo0: flags=8049 metric 0 mtu 16384 > t> options=3 > t> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > t> inet6 ::1 prefixlen 128 > t> inet 127.0.0.1 netmask 0xff000000 > t> nd6 options=3 > t> carp0: flags=49 metric 0 mtu 1500 > t> inet6 2001:db8:af:ff01:1:be60:80:70f prefixlen 128 > t> inet6 2001:db8:af:ff01:1:be60:80:70e prefixlen 128 > t> nd6 options=3 > t> carp: MASTER vhid 250 advbase 1 advskew 0 > t> > t> # ping6 2001:db8:af:ff01:1:be60:80:70f > t> PING 2001:db8:af:ff01:1:be60:80:70f(2001:db8:af:ff01:1:be60:80:70f) 56 data bytes > t> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=1 ttl=59 time=0.793 ms > t> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=2 ttl=59 time=0.837 ms > t> > t> # ping6 2001:db8:af:ff01:1:be60:80:70e > t> PING 2001:db8:af:ff01:1:be60:80:70e(2001:db8:af:ff01:1:be60:80:70e) 56 data bytes From 2001:db8:af:ff00::1 icmp_seq=1 Destination unreachable: Address unreachable From 2001:db8:af:ff00::1 icmp_seq=4 Destination unreachable: Address unreachable > t> > t> If I delete both IPs and add inet6 2001:db8:af:ff01:1:be60:80:70e before inet6 2001:db8:af:ff01:1:be60:80:70f then 2001:db8:af:ff01:1:be60:80:70e does work and 2001:db8:af:ff01:1:be60:80:70f does not. > t> > t> I googled this issue and found a patchhttp://lists.freebsd.org/pipermail/freebsd-net/2011-August/029619.html > t> I've tried to apply it but the problem still exists. I've tested this issue on FreeBSD9.1 RC2 as well and there was the same problem. > > This should work on 10-CURRENT, where the carp(4) had been significantly rewritten. > Just to correct the marketing! You have change the interface of carp(4) with the operation system interaction but not re-written carp(4). To me these are different things. > -- > Totus tuus, Glebius. > _______________________________________________ > 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" -- Ermal From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 12:21:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92951BFF; Wed, 31 Oct 2012 12:21:59 +0000 (UTC) (envelope-from tsaregorodtsev.denis@itmh.ru) Received: from fatboy.mirasystem.net (unknown [IPv6:2a02:17d0:af:ff01:1:2::]) by mx1.freebsd.org (Postfix) with ESMTP id 0312C8FC0C; Wed, 31 Oct 2012 12:21:58 +0000 (UTC) Received: from tsar.itmh.local (unknown [IPv6:2a02:17d0:8002::92]) by fatboy.mirasystem.net (Postfix) with ESMTP id CF767126D530; Wed, 31 Oct 2012 17:21:53 +0500 (YEKT) Message-ID: <509117E4.3000809@itmh.ru> Date: Wed, 31 Oct 2012 18:21:56 +0600 From: "tsaregorodtsev.denis@itmh.ru" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: IPv6 aliases don't work on carp interface References: <5090E884.4090901@itmh.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 12:21:59 -0000 On 31.10.2012 16:42, Ermal Luçi wrote: > On Wed, Oct 31, 2012 at 9:59 AM, tsaregorodtsev.denis@itmh.ru > wrote: >> Hi, >> I've run into a problem while adding IPv6 aliases on carp interface on >> FreeBSD 8.1. >> All IPv6 aliases on carp interface are unreachable from other devices but >> the first IPv6 on carp interface works well. >> >> # ifconfig >> em0: flags=8943 metric 0 mtu >> 1500 >> options=9b >> ether 00:50:56:ad:00:5f >> inet 172.16.249 netmask 0xffffff00 broadcast 255.255.255.224 >> inet6 2001:db8:af:ff01:1:be60:80:700 prefixlen 64 >> nd6 options=3 >> media: Ethernet autoselect (1000baseT ) >> status: active >> ipfw0: flags=8801 metric 0 mtu 65536 >> lo0: flags=8049 metric 0 mtu 16384 >> options=3 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=3 >> carp0: flags=49 metric 0 mtu 1500 >> inet6 2001:db8:af:ff01:1:be60:80:70f prefixlen 128 >> inet6 2001:db8:af:ff01:1:be60:80:70e prefixlen 128 >> nd6 options=3 >> carp: MASTER vhid 250 advbase 1 advskew 0 >> >> # ping6 2001:db8:af:ff01:1:be60:80:70f >> PING 2001:db8:af:ff01:1:be60:80:70f(2001:db8:af:ff01:1:be60:80:70f) 56 data >> bytes >> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=1 ttl=59 time=0.793 >> ms >> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=2 ttl=59 time=0.837 >> ms >> >> # ping6 2001:db8:af:ff01:1:be60:80:70e >> PING 2001:db8:af:ff01:1:be60:80:70e(2001:db8:af:ff01:1:be60:80:70e) 56 data >> bytes From 2001:db8:af:ff00::1 icmp_seq=1 Destination unreachable: Address >> unreachable From 2001:db8:af:ff00::1 icmp_seq=4 Destination unreachable: >> Address unreachable >> >> If I delete both IPs and add inet6 2001:db8:af:ff01:1:be60:80:70e before >> inet6 2001:db8:af:ff01:1:be60:80:70f then 2001:db8:af:ff01:1:be60:80:70e >> does work and 2001:db8:af:ff01:1:be60:80:70f does not. >> >> I googled this issue and found a >> patchhttp://lists.freebsd.org/pipermail/freebsd-net/2011-August/029619.html >> I've tried to apply it but the problem still exists. I've tested this issue >> on FreeBSD9.1 RC2 as well and there was the same problem. >> >> Best Regards, >> Tsaregorodtsev Denis >> > On pfSense there is a patch carp_ip_aliasfix.diff found here > https://github.com/bsdperimeter/pfsense-tools/tree/master/patches/RELENG_8_3 > Though the problem with that is that you have to apply many patches > before it can be applied as well. Thank you for your answers. Ermal I have several questions. Does carp_ip_alias_fix.diff solve the problem with IPv6 aliases on carp interfaces? To apply this patch I need to apply certain patches before. Is there a complete list of these patches and the sequence order? >> _______________________________________________ >> 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 Oct 31 12:48:44 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2081559; Wed, 31 Oct 2012 12:48:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 29A228FC08; Wed, 31 Oct 2012 12:48:43 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q9VCmgQM045363; Wed, 31 Oct 2012 16:48:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q9VCmg1j045362; Wed, 31 Oct 2012 16:48:42 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 31 Oct 2012 16:48:42 +0400 From: Gleb Smirnoff To: R?mi Pauchet , jfv@FreeBSD.org, melifaro@FreeBSD.org Subject: Re: panic ixgbevf / SMP under high network load Message-ID: <20121031124842.GS70741@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="WlEyl6ow+jlIgNUh" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 12:48:44 -0000 --WlEyl6ow+jlIgNUh Content-Type: text/plain; charset=koi8-r Content-Disposition: inline [back to list and adding Jack to Cc] On Thu, Oct 25, 2012 at 10:06:40AM +0200, R?mi Pauchet wrote: R> I'm testing network performance of FreeBSD using vmware esxi 5.1 with SR-IOV R> R> I'm using FreeBSD 8.3 kernel GENERIC, 4 cpus, ixgbevf driver with an Intel 82599EB dual 10 Gbps network interface R> R> After a few seconds of udp ipv4 load (5Gbps x2, frame size 700), I have the following panic : Remi reported that attached patch fixes the panic. Looks like ixv_rxeof() isn't thread safe since doesn't expect its state being changed while lock is temporarily dropped. This is deja vu of an old problem in em(4): http://freshbsd.org/commit/freebsd/r151314 Similar fix can be made for ixgbe(4). However, recently we had discussion on removing this unlock entirely from drivers. Unlock/lock removal would not only fix such kind of problems, but also would speed up processing. Discussion starts here: http://lists.freebsd.org/pipermail/freebsd-net/2012-October/033520.html -- Totus tuus, Glebius. --WlEyl6ow+jlIgNUh Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="ixv.c.diff" Index: ixv.c =================================================================== --- ixv.c (revision 242127) +++ ixv.c (working copy) @@ -3250,9 +3250,7 @@ if (tcp_lro_rx(&rxr->lro, m, 0) == 0) return; } - IXV_RX_UNLOCK(rxr); (*ifp->if_input)(ifp, m); - IXV_RX_LOCK(rxr); } static __inline void --WlEyl6ow+jlIgNUh-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 13:10:33 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C56DEDA9; Wed, 31 Oct 2012 13:10:33 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5506C8FC16; Wed, 31 Oct 2012 13:10:33 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TTY7M-0009dC-9U; Wed, 31 Oct 2012 17:14:00 +0400 Message-ID: <509122E1.3020408@FreeBSD.org> Date: Wed, 31 Oct 2012 17:08:49 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ryan Stone Subject: Re: ixgbe & if_igb RX ring locking References: <5079A9A1.4070403@FreeBSD.org> <20121015162926.GV89655@FreeBSD.org> <507D4F11.2030704@FreeBSD.org> <20121016124733.GC89655@glebius.int.ru> <50843D39.5000003@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jack Vogel , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 13:10:33 -0000 On 22.10.2012 05:43, Ryan Stone wrote: > On Sun, Oct 21, 2012 at 2:21 PM, Alexander V. Chernikov > wrote: >>> ix:rx -> udp is also fairly obvious (here's one backtrace): >> The same question, where "udp" -> "ix:rx" can happen ? > > It can't happen directly as far as I can tell. But to trigger a > deadlock, "all" that has to happen is that a thread holds each mutex > in the cycle while trying to acquire the next mutex in the cycle. I Sorry, which mutex ? What cycle? > realize that in this case that requires five separate threads to all 5? > lose a race simultaneously, but it's still theoretically possible and > needs to be avoided. Can you please be more explicit? Once again, initial point of discussion was: do we _really_ need to unlock rx ring before calling if_input? It has been said that there are some complicated cases, where something bad can happen so we still need to call unlock. That's OK and we probably should try to fix such cases generally in networking stack if we can (maybe by saying explicitly that, say, ioctl calls are forbidden in ithreads). However, it is still unclear (at least to me) how both LORs can really happen in current code (especially given modified ixgbe driver in your traces). > _______________________________________________ > 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" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 15:57:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09E8EA48 for ; Wed, 31 Oct 2012 15:57:18 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE938FC12 for ; Wed, 31 Oct 2012 15:57:17 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jf20so797587bkc.13 for ; Wed, 31 Oct 2012 08:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0/i3B11G/NLXDxZ8Ws4r+CcNlW9MWg8Jmk1UVmyYkwk=; b=rk+fx2dZcn77JEBv/AgXqC5y+4G/E7W4MsKux9omDA5rdOf5z6ICTOrn7z7rusXST6 lpWTNY4S0KWc+yURYzSAy5hasxvC8Ue9j5znU6Lyt4W0jK18zRhNtN8byfXrNPIwT8ye FLkwcaqN+LVJpa3N02RrCPHZ2atPMDltVnkMOoiO9+e0nKlcgZsXWy+Zc4he4Ja6K+2k /dLf1KWLsSa5giMp2kKGs35htsQj9MPRLPZYW92EtqFkNMt1tjOa9XEiJ7kSSwxu3ZN9 qoXsVLwdXogQPD07Qn8o9BXF0OPFeEYgB59DzQydhXUIqrXFeQwytZRzSkSvEaAkm39N HgiA== MIME-Version: 1.0 Received: by 10.204.6.75 with SMTP id 11mr11286937bky.10.1351699036326; Wed, 31 Oct 2012 08:57:16 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.204.143.148 with HTTP; Wed, 31 Oct 2012 08:57:16 -0700 (PDT) In-Reply-To: <509117E4.3000809@itmh.ru> References: <5090E884.4090901@itmh.ru> <509117E4.3000809@itmh.ru> Date: Wed, 31 Oct 2012 16:57:16 +0100 X-Google-Sender-Auth: GwLZce-9kNDhzuCCJ8GreDB6xJ8 Message-ID: Subject: Re: IPv6 aliases don't work on carp interface From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: "tsaregorodtsev.denis@itmh.ru" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 15:57:18 -0000 On Wed, Oct 31, 2012 at 1:21 PM, tsaregorodtsev.denis@itmh.ru wrote: > On 31.10.2012 16:42, Ermal Lu=E7i wrote: >> >> On Wed, Oct 31, 2012 at 9:59 AM, tsaregorodtsev.denis@itmh.ru >> wrote: >>> >>> Hi, >>> I've run into a problem while adding IPv6 aliases on carp interface on >>> FreeBSD 8.1. >>> All IPv6 aliases on carp interface are unreachable from other devices b= ut >>> the first IPv6 on carp interface works well. >>> >>> # ifconfig >>> em0: flags=3D8943 metri= c 0 >>> mtu >>> 1500 >>> options=3D9b >>> ether 00:50:56:ad:00:5f >>> inet 172.16.249 netmask 0xffffff00 broadcast 255.255.255.224 >>> inet6 2001:db8:af:ff01:1:be60:80:700 prefixlen 64 >>> nd6 options=3D3 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> ipfw0: flags=3D8801 metric 0 mtu 65536 >>> lo0: flags=3D8049 metric 0 mtu 16384 >>> options=3D3 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >>> inet6 ::1 prefixlen 128 >>> inet 127.0.0.1 netmask 0xff000000 >>> nd6 options=3D3 >>> carp0: flags=3D49 metric 0 mtu 1500 >>> inet6 2001:db8:af:ff01:1:be60:80:70f prefixlen 128 >>> inet6 2001:db8:af:ff01:1:be60:80:70e prefixlen 128 >>> nd6 options=3D3 >>> carp: MASTER vhid 250 advbase 1 advskew 0 >>> >>> # ping6 2001:db8:af:ff01:1:be60:80:70f >>> PING 2001:db8:af:ff01:1:be60:80:70f(2001:db8:af:ff01:1:be60:80:70f) 56 >>> data >>> bytes >>> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=3D1 ttl=3D59 >>> time=3D0.793 >>> ms >>> 64 bytes from 2001:db8:af:ff01:1:be60:80:70f: icmp_seq=3D2 ttl=3D59 >>> time=3D0.837 >>> ms >>> >>> # ping6 2001:db8:af:ff01:1:be60:80:70e >>> PING 2001:db8:af:ff01:1:be60:80:70e(2001:db8:af:ff01:1:be60:80:70e) 56 >>> data >>> bytes From 2001:db8:af:ff00::1 icmp_seq=3D1 Destination unreachable: >>> Address >>> unreachable From 2001:db8:af:ff00::1 icmp_seq=3D4 Destination unreachab= le: >>> Address unreachable >>> >>> If I delete both IPs and add inet6 2001:db8:af:ff01:1:be60:80:70e befor= e >>> inet6 2001:db8:af:ff01:1:be60:80:70f then 2001:db8:af:ff01:1:be60:80:70= e >>> does work and 2001:db8:af:ff01:1:be60:80:70f does not. >>> >>> I googled this issue and found a >>> >>> patchhttp://lists.freebsd.org/pipermail/freebsd-net/2011-August/029619.= html >>> I've tried to apply it but the problem still exists. I've tested this >>> issue >>> on FreeBSD9.1 RC2 as well and there was the same problem. >>> >>> Best Regards, >>> Tsaregorodtsev Denis >>> >> On pfSense there is a patch carp_ip_aliasfix.diff found here >> >> https://github.com/bsdperimeter/pfsense-tools/tree/master/patches/RELENG= _8_3 >> Though the problem with that is that you have to apply many patches >> before it can be applied as well. > > Thank you for your answers. > Ermal I have several questions. Does carp_ip_alias_fix.diff solve the > problem with IPv6 aliases on carp interfaces? > To apply this patch I need to apply certain patches before. Is there a > complete list of these patches and the sequence order? The list of patches is https://github.com/bsdperimeter/pfsense-tools/blob/master/builder_scripts/p= atches.RELENG_8_3 Just use the ones with carp in the name. In pfSense carp ip aliases work quite ok on both v4 and v6. > >>> _______________________________________________ >>> 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" >> >> >> > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Wed Oct 31 16:05:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40DA3C60 for ; Wed, 31 Oct 2012 16:05:43 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D028C8FC0C for ; Wed, 31 Oct 2012 16:05:42 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fw7so2215625vcb.13 for ; Wed, 31 Oct 2012 09:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomjudge.com; s=google; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=OyHKbrbJ2SWatpvra84jnkJr8IzKnggdA3K9n2ad06Q=; b=PhNjrbjOHBi2Wrgye681CDiIJPGaPaTu6/1tZ65FBSRtExnLJUqZnmsi0bes3mW4fq usUrrMc8OlgtQ5SVHbsZ1vAPdz+OlyLwel9xHIcy376fHry0eL3N4xbUDpgKjZLmoXqf H64XlMXfgp+pRuHxPaTziuKu4sv21LNsnE2Qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=OyHKbrbJ2SWatpvra84jnkJr8IzKnggdA3K9n2ad06Q=; b=QihjIIZmTr7E2avPEKSixI3MOkOFmlkMz52GV/TE+KzwQQzHL/KOQC6euRLPCiNkSn V1ZSOJvFyNomJNzdlnF1eFbnqWLkuWpWhWoco7FIjwYSAVkjWvfwTvR/D9UAsQ6ghgtW kB+tGXQarJ1Ubid52/DUBLvbpv8bgEhwVf0fFiNR3FLMgc7jxisWgBCT7vOxqQ7ulTqS ky2Wc3FoxJoNsqn9XGrgBasG47NUi5tHHQ52RHN0ewaBWamltAu/+f1HUj5eKqt3O1qU McE3LO5tuL8PoPfKvO6wE/bRE4kSjfQIsGwn60wNfP6CKvuAmlCHCzUtLqBvYCzxWxKD HOVQ== Received: by 10.59.6.39 with SMTP id cr7mr64061903ved.17.1351699541866; Wed, 31 Oct 2012 09:05:41 -0700 (PDT) Received: from dustpuppy.vrt.sourcefire.com (sf-nat.sourcefire.com. [64.214.53.2]) by mx.google.com with ESMTPS id dh10sm2091675veb.8.2012.10.31.09.05.38 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 09:05:38 -0700 (PDT) Sender: Tom Judge Message-ID: <50914C51.50407@freebsd.org> Date: Wed, 31 Oct 2012 12:05:37 -0400 From: Tom Judge User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pyunyh@gmail.com Subject: Re: bxe + if_lagg References: <508FF0F9.9020105@freebsd.org> <20121031074737.GB1471@michelle.cdnetworks.com> In-Reply-To: <20121031074737.GB1471@michelle.cdnetworks.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkMhoMcBaOY6sTFHI4pB4JdWY1cbpDO+vKaGCNOaOhkUhlA5QQAngiRFILn15lR3OlwKGzb Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 31 Oct 2012 16:05:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/31/12 3:47 AM, YongHyeon PYUN wrote: > On Tue, Oct 30, 2012 at 11:23:37AM -0400, Tom Judge wrote: > > [...] > >> I am trying to get if_lagg working in an HP blade for failover >> between the 2 in chassis cisco switches, but it would seem that >> the link state is not being propagated up to the lagg device. >> >> Any hints/ideas? >> >> >> >> dmesg: bxe1: > v:1.5.52 bxe1: Ethernet address: 00:25:b3:a8:76:e4 bxe1: ASIC >> (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags (MSI-X); >> Queues (RSS:16); BD's (RX:510,TX:255); Firmware (5.2.13); >> Bootcode (4.8.0) >> > > Try attached patch and let me know whether it makes any > difference. > This results in zero network connectivity, even with an IP assigned to the bxe device directly. It does show status: active and the same 10Gbase-SR media however. Ping results in no route to host. Tom - -- FreeBSD Ports Committer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkUxRAAoJEEJSM9yB4iIWPQQH/A2Irw0B9YHElcGBYZ+LMWaD O4/MLbK5xUFlMTHghwEFEHBvvPpY6wiz8B0qNxs6t86wd6TwgWn3TVyRAow3VBHO 2ePtfFmGoo5P6i2oXApTu8EN+MXkDcHuxsHtkrYk5ZXRDTAT9Bs7jZLNCBOxB2RB LPla89xBtTMBhgTMuzBGdS0DQz54r22puvuHemHgmAr0IzgXnNO+0OVFd7TN0iPG rVFu5A5rUjeWYM0oKJUt29CgE6+x4aUrYABLgm3EByaCTi4ifFN1Ua7aUGZx2Nzn SNmsoccufnX6x2XX8/1K5cv66jBpQnkaxq+lWMRovQRsFxuCymEG+9Hp58OCrXU= =PzdL -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Nov 1 00:40:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2B4C40C; Thu, 1 Nov 2012 00:40:38 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 793178FC0A; Thu, 1 Nov 2012 00:40:38 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id rp8so1447308pbb.13 for ; Wed, 31 Oct 2012 17:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mq2gcRrLrIj80S4zpFggUhRh5uTCi421czrVpl+I1+0=; b=isgqx0dwXbpTSbfMl+XT75k+Woh0aXit7NU+6KiNUBAw7IF+XS2x09wwxvx08I5Xvu Qos5NKPRocPJNjwkenU4Jhqc7droUya6KwbuZUA9K44kq20d3/R1nVv4OPq02dI+osiA UlEswR0Muf9ybENHygiFL6HeD9GaQAX8/m/CpK18GUuY1NqiT6uYHpC8uJJXWzgRxkg7 SVa4sgihlBaapUs19qg76q8mUygtalOqnMhW95HBuH5vPE7zLpeFKpHr2FwOOxzWRvqt 5JjEW27b1KiNq+9grPvlFar6wzh9jiY80qo+zhvVzHKpp5m505mPJ7oOm601GO0vP32a +XJA== Received: by 10.68.237.6 with SMTP id uy6mr15813365pbc.147.1351730437888; Wed, 31 Oct 2012 17:40:37 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id pw2sm3064126pbb.59.2012.10.31.17.40.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 17:40:36 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 01 Nov 2012 09:40:08 +0900 From: YongHyeon PYUN Date: Thu, 1 Nov 2012 09:40:08 +0900 To: Tom Judge Subject: Re: bxe + if_lagg Message-ID: <20121101004008.GA3154@michelle.cdnetworks.com> References: <508FF0F9.9020105@freebsd.org> <20121031074737.GB1471@michelle.cdnetworks.com> <50914C51.50407@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50914C51.50407@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:40:38 -0000 On Wed, Oct 31, 2012 at 12:05:37PM -0400, Tom Judge wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/31/12 3:47 AM, YongHyeon PYUN wrote: > > On Tue, Oct 30, 2012 at 11:23:37AM -0400, Tom Judge wrote: > > > > [...] > > > >> I am trying to get if_lagg working in an HP blade for failover > >> between the 2 in chassis cisco switches, but it would seem that > >> the link state is not being propagated up to the lagg device. > >> > >> Any hints/ideas? > >> > >> > >> > >> dmesg: bxe1: >> v:1.5.52 bxe1: Ethernet address: 00:25:b3:a8:76:e4 bxe1: ASIC > >> (0x16500000); Rev (A0); Bus (PCIe x4, 5Gbps); Flags (MSI-X); > >> Queues (RSS:16); BD's (RX:510,TX:255); Firmware (5.2.13); > >> Bootcode (4.8.0) > >> > > > > Try attached patch and let me know whether it makes any > > difference. > > > > This results in zero network connectivity, even with an IP assigned to > the bxe device directly. > > It does show status: active and the same 10Gbase-SR media however. > > Ping results in no route to host. :-( It seems upper stack still thinks link is down so it didn't even bother to send any packets. Probably that was the reason why bxe(4) did not announce IFCAP_LINKSTATE capability to stack. It seems slow path handler(link state change tracker) does not work as expected. From owner-freebsd-net@FreeBSD.ORG Thu Nov 1 10:37:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 38DA8213 for ; Thu, 1 Nov 2012 10:37:53 +0000 (UTC) (envelope-from shuriku@shurik.kiev.ua) Received: from graal.it-profi.org.ua (graal.shurik.kiev.ua [193.239.74.7]) by mx1.freebsd.org (Postfix) with ESMTP id C46798FC0C for ; Thu, 1 Nov 2012 10:37:52 +0000 (UTC) Received: from [217.76.201.82] (helo=thinkpad.it-profi.org.ua) by graal.it-profi.org.ua with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TTrfS-000Li8-5n for freebsd-net@freebsd.org; Thu, 01 Nov 2012 12:06:30 +0200 Message-ID: <509249A0.7010807@shurik.kiev.ua> Date: Thu, 01 Nov 2012 12:06:24 +0200 From: Alexandr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62928F91F72D805226246853" X-SA-Exim-Connect-IP: 217.76.201.82 X-SA-Exim-Mail-From: shuriku@shurik.kiev.ua X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on graal.it-profi.org.ua X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.2 Subject: if_bridge as member of lagg X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on graal.it-profi.org.ua) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 01 Nov 2012 10:37:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62928F91F72D805226246853 Content-Type: multipart/mixed; boundary="------------030705050409070001020403" This is a multi-part message in MIME format. --------------030705050409070001020403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, community! I found some patches made by Eugene Grosbein that add support of ehterip (via bridge+gif) as member of lagg interface. This may be helpful in building failover l2-tunnel between remote networks. Patches are attached and against 7.2-STABLE. Can anyone review it? P.S. Please, cc me on answer --------------030705050409070001020403 Content-Type: application/octet-stream; name="lagg-0.3.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lagg-0.3.tgz" H4sIAITgWEoAA+06XXMaSZLzCr8ixxvrQAKkpgEhy2fvYIE8hPV1gLz2bVx0tJpC6hB0M92N bN+cf838kUUnbGNJtIXQYHl3/bTvtxH3sK+b9dFNIyHJnpA9d3tUOIy6qjIrvysrq2rq1lZc mknOfvPlmiRJmXQa8DeRScv0lzbvl38kErI8l5iTEqkkSAk5LUvfQPoL0uS3pu2oFpJCmlvE uGLes21CaleMjzIFN0zlF2s1T/96Vdm09MoWmdFmKnq1eoNroDzmUqnzevd+E4lUIiH0n87I c1T/6WQ6/Q1IN0jDpc3Tv2WazlXz/kn1H4/HIah609K3QrIkzcelO3FpHvWykJhfkKSZoatG pXlJCkej0SAghUGATDwhgyQvpOYX0vIFmO++g3hCSsfmIEp/MvDdd2H4jW5otWaFwL8YxEEz nNm+f7FT0WqmQcYPVWq0P3qhv04qujoexHnRIPb4oV3VGjPQqOpsFcaBnETSowk5hYwwDoiB HhMEqavatm6QWd1QtB27Wb+IURfLEWeb0AVhdhqqpgW2YzU1B1SroZl1mJ4Nx0cJ4fK2ncZ4 6vnweB5wuFbTLuG6phoe64zHO3di8h1kEn85ky/vIliFVJHw0KblKHq1EQqxvyq2E7+/iUiw Kwzh+Ox0OA7TUDKrzjPVIsiS6hDGHEGxgLAYOge5E/zyTsVGGA1+DMdDol+vIoGh0LStUex3 QyilurpDwNnWbVAN0A2HWFVVIwxZaLlQKiv51XLxaSSIcQoQvqbbzt0h5rrzPBTCbvwN9Gq7 rFPbpX1NxJ6UFYd1Iad19bmg4Dn8BswqqJWKRWyb2Hz18/M1w2HztaY180kAjl4nZpMDWQ6I T2QSbKKZRkWAebSqtRoOC2DxxWA5796EMWvpVSoNxSJVvhapambTcLgFesOXwz33OLsKkOni +3w2F4l56uXDU8OZXJykvkmsgCqvxGE5hlkhU0BNwnK2VXubITGbFiUCDa6iG1vgqJs1ci0O hsKngy27SyxbNw2mrE1zl4wRAl9V2SEvGBj+MvZp56dwbjdUw1+TfkDDtBw7wLXnE+jlCnMe uip+3A1RkFJ5XbjUWBsizzVCKqTC0DOj09DrCFQss8HtBz05HmYodA2G3gAhQStTMXMLILvE QG6NSo1YiqNueVMqxEGkimaaOzqBe7C6sbyM01nokFMJGuDlxHxsnkUOsdKuqVd8+Ga9/gI9 O+Itv9mswnQMgl4P01N3xwLbjtmIjM6MUeu5dLpqOZELmKNiKgJ6M9mGoWjI7xa5HCCIm0PQ gaZ9gST/m82yyA8jHI1w7lmJ0WieJzU2OjOAIUA5evm1kP6nbWo7NBBhVxhCIcAmRtB6DMd6 wVahqkzNsb06lUrF5DTTZRgKS4tKqbCyvpxXcvnF5WwxL0JtDCRKXDi6kl1eXlvE0aXCaj6y ojwoFhbXVmJwC+fhpnYL/8Ku3MN8wOXZX4Zas29RSY/IejocFVzScKZFmlRDFtAt/LzB4BYx FY7+GI6GRrbR0LSqIdYQ/lM1tNY6R2Tr/0HMamRk6lQMhgSvKL/PFsprj+A/8c9/yxfXKG2I In5fZdsRoqKbEqU3ZBGnaRkQUTU66eU5HnwWqhYhEdoD07haDALMCMrZDDbmEeIhDOg97MWV OsYx6qMR/KNZIwoq26wwbxAC4mtVVEedCuPGyrQ6n0TPjKbmE7GExLQausyv849xM/0+u5pb zheVYv4hBrZ8MeJZDZM6wjTQwZoWURglgZDHscVYdPBNbQTlerGgZFefMrmGMIOwyBYGH4w1 KACh7sJSWeHm4mNmA/4XFRg1PMoEUXfoX5pqE1hZyykbq8tr2dyCwF4hV+LnSEboy+V9pscz 63E1Tn4cn5e7irHIbTGVdVrC0dKZdAwT5yj9lXm+xXeRwmqhHLlto8kFdg7mZoCYG/H7iJ4n Tfdwb+GmiHG/YOiOrtbQwKFhk2bFBBaDmE2wTSAaEmEJY47u+CuwLnRkX7jBkBhDqACvwdjH FOhhxNhyHmFhaUXJl7/PF9GV6N9yWpKU0hPxtZR7wtakdvK5mBLSQ2W5eCOIkKTyzSBSyjfD 2o3Qk90or40AB8BtckH348AZFDU4Zi2GWifoDg0MM1WNWqCm0C4MZjjIjN6zzGpN3bLRMgtL S+hj6ImL2RJnaUnsIU/E18rGcrlAR4Pguqk5NQT3Agr9DI6znX04zj5H4JGeADh+BUepLzDa PP/ncuWDNd3Y4bkXTlkurD5SSuVsOa9srFMUhaV/VUr5srKSfbKcX43c9gkyaOyt/oAHhBox RkSBQzM4olSsXYUPs91DTA0iLWLi+HQEpwgScym2G8+l74iTMwJxylmcW3wUsTW+A/v6tUgd c1gMdKNanuJBkp0OkCJVN/xx/yAhggzmgQqGyR0/bnnZoSAqk6YHxGgmk4olEmIzeRkMxkgN C8elwtpiCQ0qnytkF4KdDwOdIWJZmErfAz86UZ1zYxtmNzyVontaDM5Zr1av8M1ELB/1dgNv +fLGAqUOY2TOBMPEfR+5fYbnSdwwyhvgmLCJBycW7yqA5wA6II5TGDZhSGG+sPo4u8yFIMvz TApyUsJjc4qLwcsIhNvBSyqLwBYevT7rHOYzNKZvGaZFePD2cEtXJhtXZKdMomMSVL1ujWZQ IwdzPHMh55GxQ1Mj2xEPM8I6h7aJllm36Ky6IIs5IAaZxXLhcd6LOCjXQm5ksqo5+i4Rk68K tneHqwZ9gudPs9NhAO90jJZuqhW0DWeB9oZ/7ULcr9T8+m+RqJU6+SJrDOu/Y+v/yblMoP6f pPXfJMa6r1z//X9a//9bq/+xA/uHx5CZkeO4yT1Yzs/A33qdg8PW/tmg1X+/EA5rFZht2tas bWmz9gt7FkNIWFMdmG2ozvasY85WdCv+THe249ihbRN7dprdIaBfso5w+K+tw3Yb3rV77RN3 r4dY4cjdPz3s0BLyll6d2TFjgWryjglshBonfoQPO3suHO/33Bi0TxBIwHbb0Dl55x6+/3D6 x/7J8Qz8HU4OTz+2/G530Op2jsN/7nfeQL/30xsO2H7LcOHHz12XIhFkdRhdHa/nde/0Z9px 0jnpt49OY+EW9BHpgSuWnwmHCzPw33unH9vdTlswEklNcdI5J/TzxP2w36KChP5pt9tGuvO0 5ltYD++1P8Ber7P/c5vRiSS2XnUOWjCAV50PnY/tkwPE2+n2271X7bcnZ7jgX1FPf+67r12c 4y8Cg277pN09g313rzU4RGqOUWdxjhr6bWTmPbxye0ed3mm7j+S96eFy/XOl5kjwcDUbPFvh IYcZCF03Bh/77t4ZDM7+1N7/EyXvg2Dr2GMLXvXab4/OUEqvkde9M2ScqnzP7be6Z4hq0O69 6XaOOnDacwfdY/wD5YtcR6g4BDGvW0hiv9OjCoQdYhmkhpZk6DSWh9E4uVC7nQ5nsgUn0N7v dE/6g3a3e3YE79xe3z1CIQ06+21AvXhiQLOgBoLWEsY/u+5/0flvgVXh0arjnJf3mAavx1v7 aBYtzrpgsdvad5Hc1qDTfx/u4rKtI1yG6zCGo3SpGBz03KO2gHnfPXszxOYOqHX1e+09brHI DPO/Lqr9gA4NDjvHf+xTTExip8KsgjYlfKA/avzITtzt79MF3ZN+J4acoqEcncK7nvsO10A+ W8fClltARS3UJVhuvw1zHaGFIKp3vfbPXbR6auTnrJw6JTNz38cumjaiOOm191Ef7lH4Ms9A 3P/j7nGduUCJpHyLFeCog0aCUaMbQzW6+91TlHvP/XhwCnHk9cPAPTymxhwkgoqWe6ivz6H3 oHrcIAHxX+5Yg9HUxxt1qXW1z2VV4OWmaPnCWtEdqDRRGUcYRnqC9tZh5yMK+BS5eE0xdY/7 GLoAbh12ugetW6h17D5B3brHNFagCxy4ParqGZwUBl9u1FxHwh9zhhY3OqZcNHtEtX/67rB9 gPZNA14Xo+LAfYtoPKxUFdSAGPTp0JyGwhHkU5yURMBU7AFm2uUns0s5lOjfPdO9RIhilEba /dZPSFfroN1HLQ1Qt73WX35Cv2xzeSERlCk+E51FBBAkVkQQEUAGw1gJVBTCUbjMjwfUXk6O h6Gh3zpwKRIfqC3c8Qpv5J7+NkYHPX7QwREbQrhv493O3un++7CnC9qNYRwtnC87+AS39MnB WEGRXOKWN7X/B+//6UZ845f/31x3/y/JyVQa8z8pnUhKciadwfwvhSnh5P7/azRx/89VH7j8 p/f/kJhbkDILqbnLLv8ZlA+QSIOcWEimFuT0+Jv/JDsk05877IhcelpaLC8rhdVyRKHFVVZ0 YTvoWiEn6lYN1cKMhNQUp2lgFmDHAEGWlrMPleLvaWKC7fbFOVIMbmXZwd4bAzH2u1u8RIIH 6sBeZjcb9BKOHa7Jc3oVMXp3EpmmM/n9jNKYuvaKhh02QTMbL6BqYT4TSJz9S3+7uWnNaKyq IA7vmmnYjnclwOb4Z1R6X/MHdvBVsrlcUVnOr/473KP1iNCPID2vosyu+p/e3rM6c3KeqiCd SogSUkhUa1hxIjSsnG2+cIgN0XtQj9+vK40dZ7tizYhCVYjo9Oqj7piVSN3nndGrN5RtPEcS i19UsfI3RHB+/D7+p+ziwLf3vJp5hPFTWFce54ulwtoq3IZAD+tVVrKlR1NT4uIiPSfThxfp ubmYLI2Q7535C6vrG2VeLqozPcdDnIQ6rssKoHD7Nr20oZ9mrUILLIg8Cv60e3zaFO8ThRZe zeBTxgPTAs337J4UmJFwtavgGZhvXWyywBMoQ/I6ZCGfz89jPMzm0MCHuEOPsqVSvliOBI3Q YyjGJlF50pmRW7+1F/xcgNa3amhBpPItJhCKUm0amqJMUQPliOu0nHPOtn3piTkj4vPkwkwF Rs3D0nb1qg+Gvkb8yb4Y2TdXWYiWY+gvTEN5WGXbUncJNG3YVLUd0B2b1KpgWmAahN5lo5H5 QPzdgM0u359t69o2K9ZVLbWOSrD9txaVm9ss/wlbcP9nx+0vkABcU/+R5uQUZo+ZVDKVSMpz Mn3/l8gkJ/Wfr9HE/i9UH0gAEvQlnywtpJILidH9PDNMADjYECIFsrwgSQtJ+QIEu3mW52kA 5z88fnuV7PyDjdJTceeAsfTJkyeQ021enDdMI+6d6IZvBmyIsFdg9rbZrFVo2V41XtAYgRF0 ir+NuRBnv+Vxlm0zU+ye5IoJYqu4MChui0eoXy+ulddW10ob6+trxfKQj6x/u1DVLdzc8x4b 4tGTYwJ/U+ffQCDhX1P/F9//sleANxoELub/GAcSw/w/k04O3/9m5pj/S4n/Zfn/de3/tv8H VR8IAql4QoIEunRiQb70FBCAHfMKODX2LJBheSj+f+fcG2CaJf/QJM3zb31pP30C6T1tPf/e d+Rd7BVvgYfXQItmva7SN5VNzBHoG0vqgeyaMFd8XFrPLwK7fJwBWDUd7p8109xpNvw8xL9L Cj5k4hkLxqUd8oJeIVbZZJRTxdoVuXLTIjP8RJTIsBORLMWSPKH1Xtg+KOYelgpL2ZXsk1Ao KbGngjRqqM8Da9EMx6YBbNMiP7CQB4y76Ce8vo2ybHT869voL3p9G/2E17fRsa9vo2Ne30Y/ 8/XtxfnXvL69CPBJr2+jv+T1bfQXvr4dD/cJr2+jN/D6diyOz3x9eyWOT3x9G/2s17fXcX7d 69vo57y+vWhD176+DfgWrw/7zSsUC63QMbS6qr7FwF6yM6gIXQ+JgWdtzbc003Ass4b2gJHT dmhBmFcVxEI0PKBb/9pbzaRN2qRN2qRN2qRN2qRN2qRN2qRN2qRN2qRN2qRN2qRN2qRN2qR9 hfYPONsWtgBQAAA= --------------030705050409070001020403-- --------------enig62928F91F72D805226246853 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQkkmgAAoJENymDnon3wetHzkH/jwwP3Hn+Kx9LRWy4xjp6ty6 wiZSxVIAT5JaTfLcfHmBJJHoUruwWdmBm6vz/MqWtMgvnMeuz3ZXDVn4/qvypS+g d33tXbNpdHESVo12Xsa2WJrM437I2qQnAf1LaessIVtHtzoTghisFgp29JTBbaJN yXrZnXsdxhN6B8ylU1iohjJazXiqZOfbdzbKgwd/TL0+9UhNaUKe2ifhY16Vf4lW 5hh6i1E6m3B2AM8N45luVp2K31nnEStcHf4CCoFNbjlqkx9mxQ+ElkyKQcheODK5 pFFLkM7Ugde0U4CvyfKOLDtKSB5HZk8kn524mmAFu4lbTqp3IKeWKo5ud2/KKhM= =Rv4w -----END PGP SIGNATURE----- --------------enig62928F91F72D805226246853-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 00:08:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CEE063D0 for ; Fri, 2 Nov 2012 00:08:38 +0000 (UTC) (envelope-from rand@meridian-enviro.com) Received: from zimbra.meridian-enviro.com (zimbra.meridian-enviro.com [12.192.92.32]) by mx1.freebsd.org (Postfix) with ESMTP id 770908FC08 for ; Fri, 2 Nov 2012 00:08:38 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.meridian-enviro.com (Postfix) with ESMTP id CFA07307009B for ; Thu, 1 Nov 2012 18:59:05 -0500 (CDT) X-Virus-Scanned: amavisd-new at meridian-enviro.com Received: from zimbra.meridian-enviro.com ([127.0.0.1]) by localhost (zimbra.meridian-enviro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHJ-FjkQgOCZ; Thu, 1 Nov 2012 18:59:04 -0500 (CDT) Received: from delta.meridian-enviro.com (delta.meridian-enviro.com [10.10.10.43]) by zimbra.meridian-enviro.com (Postfix) with ESMTPSA id E72C1307009A; Thu, 1 Nov 2012 18:59:04 -0500 (CDT) Message-ID: <50930CC8.4050406@meridian-enviro.com> Date: Thu, 01 Nov 2012 18:59:04 -0500 From: "Douglas K. Rand" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120522 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Trouble with TCP/UDP picking source addresses Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ryan Langseth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 00:08:38 -0000 We have an 8.3 system that picks the wrong, or at least inconvenient, source IP address for UDP and TCP packets. This *only* happens when sending packets to itself, never when sending packets to other hosts. And not when sending packets to 127.0.0.1. I *think* the problem might be related to this system being a CARP backup system. The local system has as its "internal" IP address 10.100.2.11. This is on a VLAN interface called internal0. It also has a carp0 interface in backup state with 10.100.2.1 as an address. When I send TCP or UDP packets from the system back to itself using 10.100.2.11, tcpdump (watching lo0) shows the source address as 10.100.2.1: 18:47:44.742063 IP 10.100.2.1.45061 > 10.100.2.11.53: 31845+ A? puppet.r2.ivr.meridian-enviro.com. (51) And of course I see named trying to reply to this request on the internal0 interface, but the packet gets routed out to the other CARP host that is currently master: 18:47:44.742245 IP 10.100.2.11.53 > 10.100.2.1.45061: 31845* 2/3/3 CNAME front0-vpn.r2.ivr.meridian-enviro.com., A 10.100.2.10 (201) I can "fix" this by destroying and re-creating the carp0 interface. What I'm thinking is that somehow the kernel is latching onto the IP address of carp0 instead of internal0. Perhaps because carp0 is created before internal0 during boot? If I destroy and re-create carp0, then internal0 is earlier in the list of interfaces. At least how I seem them with ifconfig. I've verified that both UDP and TCP do the same thing. But ICMP doesn't for some reason, it picks the "right" address of 10.100.2.11 as the source address when I use ping. We have another 8.3 based firewall with a similar, but not quite identical, configuration. But it doesn't exhibit the problem, it picks a source from the VLAN interface, not the CARP interface. I was wondering if anybody has any ideas. Here is the output from ifconfig: bce0: flags=8843 \ metric 0 mtu 1500 options=c01bb ether 84:8f:69:e3:a1:51 inet 65.101.96.19 netmask 0xfffffff8 broadcast 65.101.96.23 media: Ethernet autoselect (1000baseT ) status: active bce1: flags=8943 \ metric 0 mtu 1500 options=c01bb ether 84:8f:69:e3:a1:53 media: Ethernet autoselect (1000baseT ) status: active bce2: flags=8802 metric 0 mtu 1500 options=c01bb ether 84:8f:69:e3:a1:55 media: Ethernet autoselect bce3: flags=8843 \ metric 0 mtu 1500 options=c01bb ether 84:8f:69:e3:a1:57 inet 10.254.3.11 netmask 0xffffff00 broadcast 10.254.3.255 media: Ethernet autoselect (1000baseT ) status: active ipfw0: flags=8801 metric 0 mtu 65536 lo0: flags=8149 \ metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xc inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: bce3 syncpeer: 10.254.3.10 maxupd: 128 pflog0: flags=141 metric 0 mtu 33152 carp0: flags=49 metric 0 mtu 1500 inet 10.100.2.1 netmask 0xffffff00 carp: BACKUP vhid 12 advbase 1 advskew 150 internal0: flags=8943 \ metric 0 mtu 1500 options=103 ether 84:8f:69:e3:a1:53 inet 10.100.2.11 netmask 0xffffff00 broadcast 10.100.2.255 media: Ethernet autoselect (1000baseT ) status: active vlan: 1 parent interface: bce1 management0: flags=8843 \ metric 0 mtu 1500 options=103 ether 84:8f:69:e3:a1:53 inet 10.253.0.11 netmask 0xffffff00 broadcast 10.253.0.255 media: Ethernet autoselect (1000baseT ) status: active vlan: 410 parent interface: bce1 From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 12:38:19 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D7275F8 for ; Fri, 2 Nov 2012 12:38:19 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 777A38FC16 for ; Fri, 2 Nov 2012 12:38:18 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qA2CcHrp060444 for ; Fri, 2 Nov 2012 16:38:17 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qA2CcHN1060443 for net@FreeBSD.org; Fri, 2 Nov 2012 16:38:17 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 2 Nov 2012 16:38:17 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Subject: splitting m_flags to pkthdr.flags + m_flags Message-ID: <20121102123817.GP70741@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ijf6z65S790CMqo8" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 12:38:19 -0000 --ijf6z65S790CMqo8 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hello networkers, some (most) of m_flags bits are describing features that can be present on a packet only, not on a single mbuf. Since we are close to exhaustion of available bits, and many subsystems prefer to use one of M_PROTO bits instead of grabbing a flag, I propose to split m_flags to two parts: In the m_flags remain: #define M_EXT 0x00000001 /* has associated external storage */ #define M_PKTHDR 0x00000002 /* start of record */ #define M_EOR 0x00000004 /* end of record */ #define M_RDONLY 0x00000008 /* associated data is marked read-only */ and all M_PROTO flags. struct pkthdr grows by one word and its new flag word now posesses: #define M_BCAST 0x00000200 /* send/received as link-level broadcast */ #define M_MCAST 0x00000400 /* send/received as link-level multicast */ #define M_FRAG 0x00000800 /* packet is a fragment of a larger packet */ #define M_FIRSTFRAG 0x00001000 /* packet is first fragment */ #define M_LASTFRAG 0x00002000 /* packet is last fragment */ #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ #define M_PROMISC 0x00020000 /* packet was not for us */ #define M_FLOWID 0x00400000 /* deprecated: flowid is valid */ #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */ Some M_PROTO abusements like M_FASTFWD_OURS and recently added M_IP_NEXTHOP also go to the pkthdr mbuf flags. P.S. An attentive reader may have noticed that I missed M_NOFREE and M_FREELIST. Yep, these flags coming from historical mbuf allocator from FreeBSD 4.x times are about to be deleted, we carefully examine them, but never set. Patch for review attached. -- Totus tuus, Glebius. --ijf6z65S790CMqo8 Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="historical_mbuf_flags.diff" Index: share/man/man9/mbuf.9 =================================================================== --- share/man/man9/mbuf.9 (revision 242471) +++ share/man/man9/mbuf.9 (working copy) @@ -215,7 +215,6 @@ #define M_PROTO4 0x0080 /* protocol-specific */ #define M_PROTO5 0x0100 /* protocol-specific */ #define M_PROTO6 0x4000 /* protocol-specific (avoid M_BCAST conflict) */ -#define M_FREELIST 0x8000 /* mbuf is on the free list */ /* mbuf pkthdr flags (also stored in m_flags) */ #define M_BCAST 0x0200 /* send/received as link-level broadcast */ Index: sys/sys/mbuf.h =================================================================== --- sys/sys/mbuf.h (revision 242471) +++ sys/sys/mbuf.h (working copy) @@ -192,10 +192,10 @@ #define M_FIRSTFRAG 0x00001000 /* packet is first fragment */ #define M_LASTFRAG 0x00002000 /* packet is last fragment */ #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ -#define M_FREELIST 0x00008000 /* mbuf is on the free list */ +/* 0x00008000 was M_FREELIST */ #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ #define M_PROMISC 0x00020000 /* packet was not for us */ -#define M_NOFREE 0x00040000 /* do not free mbuf, embedded in cluster */ +/* 0x00040000 was M_NOFREE */ #define M_PROTO6 0x00080000 /* protocol-specific */ #define M_PROTO7 0x00100000 /* protocol-specific */ #define M_PROTO8 0x00200000 /* protocol-specific */ @@ -650,7 +650,7 @@ if (m->m_flags & M_EXT) mb_free_ext(m); - else if ((m->m_flags & M_NOFREE) == 0) + else uma_zfree(zone_mbuf, m); return (n); } Index: sys/kern/uipc_mbuf.c =================================================================== --- sys/kern/uipc_mbuf.c (revision 242471) +++ sys/kern/uipc_mbuf.c (working copy) @@ -210,17 +210,10 @@ void mb_free_ext(struct mbuf *m) { - int skipmbuf; KASSERT((m->m_flags & M_EXT) == M_EXT, ("%s: M_EXT not set", __func__)); KASSERT(m->m_ext.ref_cnt != NULL, ("%s: ref_cnt not set", __func__)); - - /* - * check if the header is embedded in the cluster - */ - skipmbuf = (m->m_flags & M_NOFREE); - /* Free attached storage if this mbuf is the only reference to it. */ if (*(m->m_ext.ref_cnt) == 1 || atomic_fetchadd_int(m->m_ext.ref_cnt, -1) == 1) { @@ -261,8 +254,6 @@ ("%s: unknown ext_type", __func__)); } } - if (skipmbuf) - return; /* * Free this mbuf back to the mbuf zone with all m_ext @@ -327,7 +318,7 @@ m_freem(m->m_nextpkt); m->m_nextpkt = NULL; } - m->m_flags = m->m_flags & (M_EXT|M_RDONLY|M_FREELIST|M_NOFREE); + m->m_flags = m->m_flags & (M_EXT|M_RDONLY); } } Index: sys/kern/kern_mbuf.c =================================================================== --- sys/kern/kern_mbuf.c (revision 242471) +++ sys/kern/kern_mbuf.c (working copy) @@ -443,7 +443,6 @@ if ((flags & MB_NOTAGS) == 0 && (m->m_flags & M_PKTHDR) != 0) m_tag_delete_chain(m, NULL); KASSERT((m->m_flags & M_EXT) == 0, ("%s: M_EXT set", __func__)); - KASSERT((m->m_flags & M_NOFREE) == 0, ("%s: M_NOFREE set", __func__)); #ifdef INVARIANTS trash_dtor(mem, size, arg); #endif Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 242471) +++ sys/dev/bce/if_bce.c (working copy) @@ -9878,7 +9878,7 @@ "csum_flags = %b\n", mp->m_pkthdr.len, mp->m_flags, "\20\12M_BCAST\13M_MCAST\14M_FRAG" "\15M_FIRSTFRAG\16M_LASTFRAG\21M_VLANTAG" - "\22M_PROMISC\23M_NOFREE", + "\22M_PROMISC", mp->m_pkthdr.csum_flags, "\20\1CSUM_IP\2CSUM_TCP\3CSUM_UDP\4CSUM_IP_FRAGS" "\5CSUM_FRAGMENT\6CSUM_TSO\11CSUM_IP_CHECKED" Index: sys/dev/bxe/if_bxe.c =================================================================== --- sys/dev/bxe/if_bxe.c (revision 242471) +++ sys/dev/bxe/if_bxe.c (working copy) @@ -16279,7 +16279,7 @@ "csum_flags = %b\n", m->m_pkthdr.len, m->m_flags, "\20\12M_BCAST\13M_MCAST\14M_FRAG" "\15M_FIRSTFRAG\16M_LASTFRAG\21M_VLANTAG" - "\22M_PROMISC\23M_NOFREE", + "\22M_PROMISC", m->m_pkthdr.csum_flags, "\20\1CSUM_IP\2CSUM_TCP\3CSUM_UDP\4CSUM_IP_FRAGS" "\5CSUM_FRAGMENT\6CSUM_TSO\11CSUM_IP_CHECKED" Index: sys/net80211/ieee80211_freebsd.h =================================================================== --- sys/net80211/ieee80211_freebsd.h (revision 242471) +++ sys/net80211/ieee80211_freebsd.h (working copy) @@ -223,14 +223,14 @@ #define IEEE80211_MBUF_TX_FLAG_BITS \ "\20\1M_EXT\2M_PKTHDR\3M_EOR\4M_RDONLY\5M_ENCAP\6M_WEP\7M_EAPOL" \ "\10M_PWR_SAV\11M_MORE_DATA\12M_BCAST\13M_MCAST\14M_FRAG\15M_FIRSTFRAG" \ - "\16M_LASTFRAG\17M_SKIP_FIREWALL\20M_FREELIST\21M_VLANTAG\22M_PROMISC" \ - "\23M_NOFREE\24M_FF\25M_TXCB\26M_AMPDU_MPDU\27M_FLOWID" + "\16M_LASTFRAG\17M_SKIP_FIREWALL\21M_VLANTAG\22M_PROMISC" \ + "\24M_FF\25M_TXCB\26M_AMPDU_MPDU\27M_FLOWID" #define IEEE80211_MBUF_RX_FLAG_BITS \ "\20\1M_EXT\2M_PKTHDR\3M_EOR\4M_RDONLY\5M_AMPDU\6M_WEP\7M_PROTO3" \ "\10M_PROTO4\11M_PROTO5\12M_BCAST\13M_MCAST\14M_FRAG\15M_FIRSTFRAG" \ - "\16M_LASTFRAG\17M_SKIP_FIREWALL\20M_FREELIST\21M_VLANTAG\22M_PROMISC" \ - "\23M_NOFREE\24M_PROTO6\25M_PROTO7\26M_AMPDU_MPDU\27M_FLOWID" + "\16M_LASTFRAG\17M_SKIP_FIREWALL\21M_VLANTAG\22M_PROMISC" \ + "\24M_PROTO6\25M_PROTO7\26M_AMPDU_MPDU\27M_FLOWID" /* * Store WME access control bits in the vlan tag. --ijf6z65S790CMqo8-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 12:55:03 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD004C74 for ; Fri, 2 Nov 2012 12:55:03 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE308FC0C for ; Fri, 2 Nov 2012 12:55:02 +0000 (UTC) Received: (qmail 84993 invoked from network); 2 Nov 2012 14:31:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Nov 2012 14:31:08 -0000 Message-ID: <5093C29A.4020902@networx.ch> Date: Fri, 02 Nov 2012 13:54:50 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: splitting m_flags to pkthdr.flags + m_flags References: <20121102123817.GP70741@FreeBSD.org> In-Reply-To: <20121102123817.GP70741@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 12:55:03 -0000 On 02.11.2012 13:38, Gleb Smirnoff wrote: > Hello networkers, > > some (most) of m_flags bits are describing features that can > be present on a packet only, not on a single mbuf. Since we are > close to exhaustion of available bits, and many subsystems prefer > to use one of M_PROTO bits instead of grabbing a flag, I propose The use of M_PROTO for protocol and layer specific use is very much its intended purpose and should be kept that way with overlays. The available range of M_PROTO can be extended with your proposed change. M_PROTO could be split into mbuf and mbuf header flags. Most of the time they are also only relevant on packets. > to split m_flags to two parts: I fully agree on the split. The previous mixing of mbuf and mbuf header flags was irritating and confusing. > In the m_flags remain: > #define M_EXT 0x00000001 /* has associated external storage */ > #define M_PKTHDR 0x00000002 /* start of record */ > #define M_EOR 0x00000004 /* end of record */ > #define M_RDONLY 0x00000008 /* associated data is marked read-only */ > and all M_PROTO flags. > > struct pkthdr grows by one word and its new flag word now > posesses: > > #define M_BCAST 0x00000200 /* send/received as link-level broadcast */ > #define M_MCAST 0x00000400 /* send/received as link-level multicast */ > #define M_FRAG 0x00000800 /* packet is a fragment of a larger packet */ > #define M_FIRSTFRAG 0x00001000 /* packet is first fragment */ > #define M_LASTFRAG 0x00002000 /* packet is last fragment */ I wonder if actually have any users of the M_*FRAG flags. And if yes, if it can be solved in a different way with less flags. > #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ This one should become an M_PROTO overlay. It is only relevant within a protocol layer. > #define M_VLANTAG 0x00010000 /* ether_vtag is valid */ > #define M_PROMISC 0x00020000 /* packet was not for us */ > #define M_FLOWID 0x00400000 /* deprecated: flowid is valid */ > #define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */ > > Some M_PROTO abusements like M_FASTFWD_OURS and recently added M_IP_NEXTHOP > also go to the pkthdr mbuf flags. On the contrary. This isn't abuse of M_PROTO. It's the exact pupose of it. > P.S. > An attentive reader may have noticed that I missed M_NOFREE and M_FREELIST. > Yep, these flags coming from historical mbuf allocator from FreeBSD 4.x times > are about to be deleted, we carefully examine them, but never set. Patch > for review attached. Looks good. Go ahead from me. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 14:42:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C81E1C7; Fri, 2 Nov 2012 14:42:35 +0000 (UTC) (envelope-from guy.helmer@gmail.com) Received: from mail.palisadesystems.com (mail.palisadesystems.com [216.81.178.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4938FC08; Fri, 2 Nov 2012 14:42:35 +0000 (UTC) Received: from [192.168.221.153] ([192.168.221.153]) (authenticated bits=0) by mail.palisadesystems.com (8.14.3/8.14.3) with ESMTP id qA2EUenC064918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Nov 2012 09:30:48 -0500 (CDT) (envelope-from guy.helmer@gmail.com) X-DKIM: Sendmail DKIM Filter v2.8.3 mail.palisadesystems.com qA2EUenC064918 From: Guy Helmer Subject: Panic in bpf.c catchpacket() Message-Id: Date: Fri, 2 Nov 2012 09:30:40 -0500 To: freebsd-hackers@freebsd.org, "freebsd-net@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.palisadesystems.com [172.16.1.5]); Fri, 02 Nov 2012 09:30:48 -0500 (CDT) X-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner-ID: qA2EUenC064918 X-Palisade-MailScanner: Found to be clean X-Palisade-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.085, required 5, ALL_TRUSTED -1.00, BAYES_00 -1.90, FREEMAIL_FROM 1.00, HTML_MESSAGE 0.00, RP_8BIT 1.98) X-Palisade-MailScanner-From: guy.helmer@gmail.com X-Spam-Status: No Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 14:42:35 -0000 Still working this problem I've previously mentioned, and my working = theory now is a race between catchpacket() and this code in bpfread(): /* * At this point, we know we have something in the hold slot. */ BPFD_UNLOCK(d); /* * Move data from hold buffer into user space. * We know the entire buffer is transferred since * we checked above that the read buffer is bpf_bufsize bytes. * * XXXRW: More synchronization needed here: what if a second = thread * issues a read on the same fd at the same time? Don't want = this * getting invalidated. */ error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); =20 BPFD_LOCK(d); d->bd_fbuf =3D d->bd_hbuf; d->bd_hbuf =3D NULL; d->bd_hlen =3D 0; bpf_buf_reclaimed(d); BPFD_UNLOCK(d); Assuming it's unwise to hold the descriptor lock over the uiomove() = call, it seems we at least need to check to make sure bd_hbuf is still = valid: @@ -809,10 +948,15 @@ bpfread(struct cdev *dev, struct uio *uio, int iof error =3D bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); =20 BPFD_LOCK(d); - d->bd_fbuf =3D d->bd_hbuf; - d->bd_hbuf =3D NULL; - d->bd_hlen =3D 0; - bpf_buf_reclaimed(d); + if (d->bd_hbuf =3D=3D NULL) { + printf("bpfread: lost race: bd_hbuf=3D%p bd_sbuf=3D%p = bd_fbuf=3D%p\n", + d->bd_hbuf, d->bd_sbuf, d->bd_fbuf); + } else { + d->bd_fbuf =3D d->bd_hbuf; + d->bd_hbuf =3D NULL; + d->bd_hlen =3D 0; + bpf_buf_reclaimed(d); + } BPFD_UNLOCK(d); =20 return (error); This still seems vulnerable to me -- a ROTATE_BUFFERS() or reset_d() = could be done between the BPFD_UNLOCK() and the bpf_uiomove(). Would a = new lock to protect the buffers be necessary, or a flag+condition = variable to indicate "hold buffer in use"? Guy= From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 14:43:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D62A288 for ; Fri, 2 Nov 2012 14:43:25 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E31418FC0C for ; Fri, 2 Nov 2012 14:43:24 +0000 (UTC) Received: (qmail 85841 invoked from network); 2 Nov 2012 16:19:34 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Nov 2012 16:19:34 -0000 Message-ID: <5093DC04.2010902@freebsd.org> Date: Fri, 02 Nov 2012 15:43:16 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r242473 - user/andre/tcp_workqueue/sys/dev/ixgbe References: <201211021343.qA2DhHHr031786@svn.freebsd.org> In-Reply-To: <201211021343.qA2DhHHr031786@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: jfv@FreeBSD.org, freebsd-net@freebsd.org, yongari@FreeBSD.org, davidch@FreeBSD.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 14:43:25 -0000 On 02.11.2012 14:43, Andre Oppermann wrote: > Author: andre > Date: Fri Nov 2 13:43:17 2012 > New Revision: 242473 > URL: http://svn.freebsd.org/changeset/base/242473 > > Log: > Merge ixgbe_tx_ctx_setup() and ixgbe_tso_setup() together into > ixgbe_offload_setup() as they have a large overlap in packet > inspection and variables. > > Add UDP fragmentation offload functionality as well. > > Also the driver can assume that the necessary headers for the > activated offload functions are contiguously present in the > first mbuf. This assumption is not formalized yet but significantly > simplify the driver code. The upper layers of the stack adhere > to this assumption as well. We leave enough leading space in the > mbufs to prepend all registered (max_linkhdr) encapsulations. > There may be misbehaving packet transformations that have to be > fixed. Assertion functions have to be provided as well. The new formal assumptions at the stack/driver boundary will be: CSUM_IP: lower and IP header including IP options contiguous in first mbuf ip_sum is zero CSUM_TCP: lower and TCP header including TCP options contiguous in first mbuf pseudo header checksum is valid and present in th_sum CSUM_IP is implied, but should be flagged as well CSUM_UDP: lower and UDP header contiguous in first mbuf pseudo header checksum is valid and present in uh_sum CSUM_IP is implied, but should be flagged as well CSUM_SCTP: lower and SCTP header contiguous in first mbuf CSUM_IP is implied, but should be flagged as well CSUM_TSO: lower and TCP header including TCP options contiguous in first mbuf pseudo header checksum is valid and present in th_sum CSUM_IP and CSUM_TCP is implied, but should be flagged as well no TSO flag when no TCP segmentation is required (m_pkthdr.len <= mss + tcpiphdr) no IP options present As I said the standard upper layers already behave like this. The step now is to formalize and assert/enforce this. Enforcement is done by returning an error for a misbehaving packet w/o trying to fix it up. If you have any comments, please speak up. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 16:12:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6140F8C for ; Fri, 2 Nov 2012 16:12:44 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 77B1B8FC0C for ; Fri, 2 Nov 2012 16:12:44 +0000 (UTC) Received: by mail-yh0-f54.google.com with SMTP id s35so680468yhf.13 for ; Fri, 02 Nov 2012 09:12:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=xkRW820isXpjmLfYcnCgDeqQidXRoxCobaZ3+JEaEy8=; b=Rveg4T/LieFekEROGkkv0em2/nsb/amdD23Nh+kow/QfajL4BJRD+U5mBSyVy5dedF vhBCvZDwQqvGcbiwOYdYBQ/kKMAn8Apsk+DrAUWcJ+ZBCl+r6qKC2Txg+OO8eaKm+m4g UWlcUhvOQuaPkrZTTEOXE0f4GBKVcV0N0vKNjz8LHXZWjvsIhAY0tymqWSMUeu/wvfj5 rqcUPrudW2AZqFy9Dd/bHqiexImdYpu5nYdleap3a7lU3EG1srh+uBmfogYsxt9qJFtB SlnFr44AmpLmldZbFzNwrDx8A0XJVxltnUxDPJi9oyf3dtqSAlH9WmjH6an7UcGJ7LQx +eog== Received: by 10.236.86.43 with SMTP id v31mr2129177yhe.62.1351872763642; Fri, 02 Nov 2012 09:12:43 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.146.227.39 with HTTP; Fri, 2 Nov 2012 09:12:23 -0700 (PDT) In-Reply-To: <5093C29A.4020902@networx.ch> References: <20121102123817.GP70741@FreeBSD.org> <5093C29A.4020902@networx.ch> From: Juli Mallett Date: Fri, 2 Nov 2012 09:12:23 -0700 X-Google-Sender-Auth: gSdmiIz9NzzmXF2h8uNKozgwPRs Message-ID: Subject: Re: splitting m_flags to pkthdr.flags + m_flags To: Andre Oppermann X-Gm-Message-State: ALoCoQnN18oC1qo/YhkDEzlEJAxR5TiG7BFFqXBXNG3Ebq+6bTBOypViDKryQKsHmSc0KbSd3mth Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 16:12:44 -0000 On Fri, Nov 2, 2012 at 5:54 AM, Andre Oppermann wrote: > On 02.11.2012 13:38, Gleb Smirnoff wrote: > >> #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ >> > > This one should become an M_PROTO overlay. It is only relevant within > a protocol layer. No, like M_PROMISC it needs to follow packets around throughout the stack, and not conflict with anything else. My memory of the details is a bit hazy, but ipfw2 unfortunately does need the flag to not be something that could be accidentally set or cleared by another protocol layer, and the flag needs to persist. Or did 8 years ago. http://svnweb.freebsd.org/base?view=revision&revision=132274 But there was some disagreement at the time about whether ipfw2 was doing the right thing, and this behavior should be legitimized by making it actually work right: http://lists.freebsd.org/pipermail/cvs-src/2004-July/027830.html If the flag is made back into an M_PROTO (or, even better, removed) then it would be best to verify that it does not need to persist, it is okay if the flag is set by a different protocol layer, etc., today. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 17:06:57 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4763947A; Fri, 2 Nov 2012 17:06:57 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C63018FC16; Fri, 2 Nov 2012 17:06:56 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D7C6D7300A; Fri, 2 Nov 2012 18:18:15 +0100 (CET) Date: Fri, 2 Nov 2012 18:18:15 +0100 From: Luigi Rizzo To: Juli Mallett Subject: Re: splitting m_flags to pkthdr.flags + m_flags Message-ID: <20121102171815.GA64911@onelab2.iet.unipi.it> References: <20121102123817.GP70741@FreeBSD.org> <5093C29A.4020902@networx.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 17:06:57 -0000 On Fri, Nov 02, 2012 at 09:12:23AM -0700, Juli Mallett wrote: > On Fri, Nov 2, 2012 at 5:54 AM, Andre Oppermann wrote: > > > On 02.11.2012 13:38, Gleb Smirnoff wrote: > > > >> #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ > >> > > > > This one should become an M_PROTO overlay. It is only relevant within > > a protocol layer. > > > No, like M_PROMISC it needs to follow packets around throughout the stack, > and not conflict with anything else. My memory of the details is a bit > hazy, but ipfw2 unfortunately does need the flag to not be something that > could be accidentally set or cleared by another protocol layer, and the > flag needs to persist. Or did 8 years ago. M_SKIP_FIREWALL was introduced to make sure that packets coming out of a dummynet pipe were not reinjected in the firewall unless explicitly requested by the configuration. I think it is also used by the ipfw stateful code so that probes to refresh the state of dynamic rules do not end up fooling the firewall itself. Besides the firewall can be invoked at multiple layers, so I believe it makes more sense to preserve the current behaviour rather than make it into a M_PROTO flag. cheers luigi > > http://svnweb.freebsd.org/base?view=revision&revision=132274 > > But there was some disagreement at the time about whether ipfw2 was doing > the right thing, and this behavior should be legitimized by making it > actually work right: > > http://lists.freebsd.org/pipermail/cvs-src/2004-July/027830.html > > If the flag is made back into an M_PROTO (or, even better, removed) then it > would be best to verify that it does not need to persist, it is okay if the > flag is set by a different protocol layer, etc., today. > > Thanks, > Juli. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 19:04:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 86110A89 for ; Fri, 2 Nov 2012 19:04:12 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 12E608FC0A for ; Fri, 2 Nov 2012 19:04:11 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c50so2528684eek.13 for ; Fri, 02 Nov 2012 12:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w5Dc8mIjkRF2ope0LKOFS0gGShoHoZW7Wd8fNtYXpM0=; b=lNHzVr6TwywMqFNeeV3azBcitA7AwtKJoAkTEP6TWKbngargBNtFzAud8JfSGaW72n WxftbwTwsxIZd7baIq8xwkc6aBp5FQQpVRCKK3bmpFrGMoDP6F17bEvqfkObixWpvotF BrS5UgJ10CHA7hgwEuwZxjMZSlXvbJvFfuAQy1VJL/Z+8k2pxjw7DqkJp3dSff2fdQsz Ar9CHsZQB7ObXwwhba0zPUkQnHxIKb2E0bzgtIsLhpDJfH/QtilJDDiiV0iUdIfgiRhX DRRa7RJtcoaaDOdIpWp6camPIV8ZzIIc3ot31eC3It2MVlGm6sunLoMz/M+Eaxb0zVKD Z0bA== MIME-Version: 1.0 Received: by 10.14.182.5 with SMTP id n5mr9808367eem.5.1351883050759; Fri, 02 Nov 2012 12:04:10 -0700 (PDT) Received: by 10.14.218.133 with HTTP; Fri, 2 Nov 2012 12:04:10 -0700 (PDT) Date: Fri, 2 Nov 2012 12:04:10 -0700 Message-ID: Subject: Session MTU update patch only 9 From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 19:04:12 -0000 Hi, While attempting to fix a PMTUD bug in 8.3-RELEASE-p4 that appears to now be resolved by r234342, I also came across r238516. It appears this fix only made it into 9/STABLE though, does anyone know why it wasn't brought back to 8? It's a fairly easy port, but I just wanted to confirm there wasn't something else at play I'm missing. "If ip_output() returns EMSGSIZE to tcp_output(), then the latter calls tcp_mtudisc(), which in its turn may call tcp_output(). Under certain conditions (must admit they are very special) an infinite recursion can happen. To avoid recursion we can pass struct route to ip_output() and obtain correct mtu. This allows us not to use tcp_mtudisc() but call tcp_mss_update() directly." Jason From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 22:29:04 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4A52A6F for ; Fri, 2 Nov 2012 22:29:04 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0228FC16 for ; Fri, 2 Nov 2012 22:29:03 +0000 (UTC) Received: (qmail 89184 invoked from network); 3 Nov 2012 00:05:10 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Nov 2012 00:05:10 -0000 Message-ID: <50944927.2040902@networx.ch> Date: Fri, 02 Nov 2012 23:28:55 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Luigi Rizzo Subject: Re: splitting m_flags to pkthdr.flags + m_flags References: <20121102123817.GP70741@FreeBSD.org> <5093C29A.4020902@networx.ch> <20121102171815.GA64911@onelab2.iet.unipi.it> In-Reply-To: <20121102171815.GA64911@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Juli Mallett , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Nov 2012 22:29:04 -0000 On 02.11.2012 18:18, Luigi Rizzo wrote: > On Fri, Nov 02, 2012 at 09:12:23AM -0700, Juli Mallett wrote: >> On Fri, Nov 2, 2012 at 5:54 AM, Andre Oppermann wrote: >> >>> On 02.11.2012 13:38, Gleb Smirnoff wrote: >>> >>>> #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ >>>> >>> >>> This one should become an M_PROTO overlay. It is only relevant within >>> a protocol layer. >> >> >> No, like M_PROMISC it needs to follow packets around throughout the stack, >> and not conflict with anything else. My memory of the details is a bit >> hazy, but ipfw2 unfortunately does need the flag to not be something that >> could be accidentally set or cleared by another protocol layer, and the >> flag needs to persist. Or did 8 years ago. > > M_SKIP_FIREWALL was introduced to make sure that packets coming > out of a dummynet pipe were not reinjected in the firewall > unless explicitly requested by the configuration. Dummynet doesn't set or use M_SKIP_FIREWALL. > I think it is also used by the ipfw stateful code so that > probes to refresh the state of dynamic rules do not end up > fooling the firewall itself. Indeed. > Besides the firewall can be invoked at multiple layers, > so I believe it makes more sense to preserve the current behaviour > rather than make it into a M_PROTO flag. I've looked at the code and it all happens at the IP[46] layer. No layer crossing going on. M_PROTO use is perfectly valid here. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Nov 3 20:53:03 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB553120 for ; Sat, 3 Nov 2012 20:53:03 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 336FE8FC0A for ; Sat, 3 Nov 2012 20:53:02 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qA3KqtPF066996; Sun, 4 Nov 2012 00:52:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qA3KqsSh066995; Sun, 4 Nov 2012 00:52:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 4 Nov 2012 00:52:54 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: splitting m_flags to pkthdr.flags + m_flags Message-ID: <20121103205254.GX70741@glebius.int.ru> References: <20121102123817.GP70741@FreeBSD.org> <5093C29A.4020902@networx.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5093C29A.4020902@networx.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 20:53:03 -0000 On Fri, Nov 02, 2012 at 01:54:50PM +0100, Andre Oppermann wrote: A> > An attentive reader may have noticed that I missed M_NOFREE and M_FREELIST. A> > Yep, these flags coming from historical mbuf allocator from FreeBSD 4.x times A> > are about to be deleted, we carefully examine them, but never set. Patch A> > for review attached. A> A> Looks good. Go ahead from me. History review reveals that M_NOFREE comes from r172463 by Kip Macy. The idea was to have mbufs embdedded into clusters. The feature isn't used by any module and isn't tested at all. I ponder on should we leave the code as is or not? M_FREELIST actually has nothing to do with historic mbuf allocator. It was a bandaid that helped to debug double-frees. The code was washed out from the repo, only the flag left. Also the functionality is now available via generic allocator invariants. So M_FREELIST definitely should be deleted. But I'm not sure about M_NOFREE. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Nov 3 21:00:47 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFADB4F2; Sat, 3 Nov 2012 21:00:47 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1EF8FC14; Sat, 3 Nov 2012 21:00:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA3L0luc007808; Sat, 3 Nov 2012 21:00:47 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA3L0lvE007804; Sat, 3 Nov 2012 21:00:47 GMT (envelope-from linimon) Date: Sat, 3 Nov 2012 21:00:47 GMT Message-Id: <201211032100.qA3L0lvE007804@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 21:00:47 -0000 Old Synopsis: TCP connections often prematurely closed by the server side after r242262 New Synopsis: [tcp] TCP connections often prematurely closed by the server side after r242262 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 3 21:00:20 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173309 From owner-freebsd-net@FreeBSD.ORG Sat Nov 3 22:51:50 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 155ECA99; Sat, 3 Nov 2012 22:51:50 +0000 (UTC) (envelope-from andre@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D7E898FC08; Sat, 3 Nov 2012 22:51:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA3MpnAA017080; Sat, 3 Nov 2012 22:51:49 GMT (envelope-from andre@freefall.freebsd.org) Received: (from andre@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qA3Mpnp6017076; Sat, 3 Nov 2012 22:51:49 GMT (envelope-from andre) Date: Sat, 3 Nov 2012 22:51:49 GMT Message-Id: <201211032251.qA3Mpnp6017076@freefall.freebsd.org> To: andre@FreeBSD.org, freebsd-net@FreeBSD.org, andre@FreeBSD.org From: andre@FreeBSD.org Subject: Re: kern/173309: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 22:51:50 -0000 Synopsis: [tcp] TCP connections often prematurely closed by the server side after r242262 [regression] Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Sat Nov 3 22:51:21 UTC 2012 Responsible-Changed-Why: Take over, was my commit. http://www.freebsd.org/cgi/query-pr.cgi?pr=173309