From owner-freebsd-net@FreeBSD.ORG Sun May 5 00:08:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 05C74483; Sun, 5 May 2013 00:08:23 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id DB03B7BA; Sun, 5 May 2013 00:08:21 +0000 (UTC) Received: from latitude.home.vangyzen.net (173-17-250-12.client.mchsi.com [173.17.250.12]) by smtp.vangyzen.net (Postfix) with ESMTP id BD2EC5641F; Sat, 4 May 2013 18:59:53 -0500 (CDT) Message-ID: <5185A0F8.5050808@vangyzen.net> Date: Sat, 04 May 2013 18:59:52 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Sharpe Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? References: In-Reply-To: Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Adrian Chadd , 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: Sun, 05 May 2013 00:08:23 -0000 On 05/04/2013 04:19 PM, Richard Sharpe wrote: > On Sat, May 4, 2013 at 2:18 PM, Jack Vogel wrote: >> Ahh, Twinville, new hardware :) The version at the tip is 2.5.8 and I am >> working on version 2.5.12 internally that I hope to commit next week... >> so your version is "a bit old" :) I would do some testing on newer code. > > I would love to. Where is the repo. https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=14688&keyword=%22ixgbe%22&DownloadType=Drivers&lang=eng Eric From owner-freebsd-net@FreeBSD.ORG Sun May 5 02:03:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64E9C5EE; Sun, 5 May 2013 02:03:48 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id CA1D6AA9; Sun, 5 May 2013 02:03:47 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id r3so2101975wey.4 for ; Sat, 04 May 2013 19:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zRN89adueDxQ5QWvdLzDd5Rjoe9EoI7ZeHsi7scbc+0=; b=FhzQeUDMckDyq23WkTEW55w0SjRueN8e8hJzY3oweniGMb/gNONHptdeDS9z04Vypm fE8cpHdmbVkXf7i3B0CcVVoWoJdf/tvR4wQ1gZIz4YION3d4KDsQsfl/Z6/WYu7BGVml KMORPMrN2VzvHkB+blb8qhnaGXBJmH/GD7rTt563yrJbCzNOecqhBrpo4kbkdUOeq1AT uBLsm4Bw0JzrDe9C99GvRU/jQNXXSM1djTRQD3MslcUb9NUgLo1Md9YW/3XUN0LRl+GN NkjJlRUMaJ/mKaEVNg2vEwwZFLu8hN9yWJLQAs5RG1gcf9+lgh5ec5OyVEXq3yozpkjE /W5Q== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr19726675wjb.29.1367719426025; Sat, 04 May 2013 19:03:46 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Sat, 4 May 2013 19:03:45 -0700 (PDT) In-Reply-To: <5185A0F8.5050808@vangyzen.net> References: <5185A0F8.5050808@vangyzen.net> Date: Sat, 4 May 2013 19:03:45 -0700 Message-ID: Subject: Re: Is there any way to limit the amount of data in an mbuf chain submitted to a driver? From: Richard Sharpe To: Eric van Gyzen Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , Adrian Chadd , 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: Sun, 05 May 2013 02:03:48 -0000 On Sat, May 4, 2013 at 4:59 PM, Eric van Gyzen wrote: > On 05/04/2013 04:19 PM, Richard Sharpe wrote: >> On Sat, May 4, 2013 at 2:18 PM, Jack Vogel wrote: >>> Ahh, Twinville, new hardware :) The version at the tip is 2.5.8 and I = am >>> working on version 2.5.12 internally that I hope to commit next week... >>> so your version is "a bit old" :) I would do some testing on newer code= . >> >> I would love to. Where is the repo. > > https://downloadcenter.intel.com/Detail_Desc.aspx?agr=3DY&DwnldID=3D14688= &keyword=3D%22ixgbe%22&DownloadType=3DDrivers&lang=3Deng Thank you. After asking I went an looked and eventually found it. --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) From owner-freebsd-net@FreeBSD.ORG Sun May 5 16:40:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3EB8DD0C for ; Sun, 5 May 2013 16:40:44 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id D309233D for ; Sun, 5 May 2013 16:40:43 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id y10so2980468wgg.32 for ; Sun, 05 May 2013 09:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nTmvVYhanR+u17ZrGXdjALNFBh8pYLnCcRgiR2S4oUc=; b=jcUV5csSe/kuIzpt0OV0lB1KAkWPlbsBKczyIc6bgv1RSO87EhhEEgTSXQIDVHzfiL JP8IYI2synusEPPsFXJFv8WRYCB1ij4vySqNbhawZrXnPLPH67qvODR7KHxKmqHhiHap nzJJ0+aLJUr4ES4yxVisEfW89YlckyPVWRiEXBgIar1vw6SU3PhTvVr/5QV86TEH70FQ U4KUQp5JmLYNnshDTmQcklp+adeNVpp40QIN/rNSlneqmK+oxLZcpnoHrkzwQ+hfGsK2 L8gszxWjakb1DOKvrwSXwFljA73V2H20NsEw5twKTs8pZ5fCqrukT4t4ajU5x9G+6Z8E 2Ykw== MIME-Version: 1.0 X-Received: by 10.180.82.74 with SMTP id g10mr5272590wiy.10.1367772042266; Sun, 05 May 2013 09:40:42 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Sun, 5 May 2013 09:40:42 -0700 (PDT) Date: Sun, 5 May 2013 09:40:42 -0700 Message-ID: Subject: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE From: Richard Sharpe To: FreeBSD Net Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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, 05 May 2013 16:40:44 -0000 Samba currently has a way to set socket parameters from the smb.conf. This works fine for things like SO_SNDBUF etc, but not so well for the TCP KeepAlive parameters. In this area Samba has a Linux bias. I am looking at adding support for this under FreeBSD. The simplest way, it seems to me, is to enhance configure to find the appropriate symbols under FreeBSD (and it might be extendable to NetBSD etc) and then map them to the Linux symbols: #ifdef THIS_IS_SOME_SORT_OF_BSD #define TCP_KEEPIDLE TCPTV_KEEP_IDLE #endif However, that does mean that *BSD types would have to know that this happening because the names you would use in the smb.conf file would be Linux-specific, and documentation is often woefully incomplete. Is there a better method? --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) From owner-freebsd-net@FreeBSD.ORG Sun May 5 19:34:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6FE6445B for ; Sun, 5 May 2013 19:34:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2971EAAF for ; Sun, 5 May 2013 19:34:50 +0000 (UTC) Received: from Julian-MBP3.local ([12.157.112.67]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r45JKtHj041253 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 5 May 2013 12:20:55 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5186B112.7040202@freebsd.org> Date: Sun, 05 May 2013 12:20:50 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eitan Adler Subject: Re: Seeing EINVAL from writev on 8.0 to a non-blocking socket even though the data seems to hit the wire References: <5181ECDF.1040905@mu.org> <51827DAA.2020009@vangyzen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Alfred Perlstein , Eric van Gyzen , Richard Sharpe 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, 05 May 2013 19:34:51 -0000 On 5/2/13 5:18 PM, Eitan Adler wrote: > On 2 May 2013 20:14, Eitan Adler wrote: > >> gprof in base >> valgrind --callgrind >> doxygen can also do this. >> > I was reminded this was about the kernel, not userland, sorry for the noise. > hey richard.. dtrace is your friend. (and I happen to know you have it on your system) will catch you tomorrow (monday) and we can look into it.. From owner-freebsd-net@FreeBSD.ORG Mon May 6 08:13:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 20044FD6; Mon, 6 May 2013 08:13:03 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 951FF9CA; Mon, 6 May 2013 08:13:02 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r468D1wh071410; Mon, 6 May 2013 12:13:01 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r468D0lP071409; Mon, 6 May 2013 12:13:00 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 6 May 2013 12:13:00 +0400 From: Gleb Smirnoff To: Richard Sharpe Subject: Re: Seeing EINVAL from writev on 8.0 to a non-blocking socket even though the data seems to hit the wire Message-ID: <20130506081300.GU15182@glebius.int.ru> References: <5181ECDF.1040905@mu.org> <51827DAA.2020009@vangyzen.net> <5183CC06.9020806@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jfv@FreeBSD.org, freebsd-net@freebsd.org, Eric van Gyzen , Alfred Perlstein , 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, 06 May 2013 08:13:03 -0000 [I'm adding Jack Vogel, maintainer of ixgbe, to cc] On Fri, May 03, 2013 at 07:01:18PM -0700, Richard Sharpe wrote: R> On Fri, May 3, 2013 at 10:18 AM, Richard Sharpe R> wrote: R> > On Fri, May 3, 2013 at 7:39 AM, Eric van Gyzen wrote: R> >> On 05/02/2013 19:00, Richard Sharpe wrote: R> >>> On Thu, May 2, 2013 at 7:52 AM, Eric van Gyzen wrote: R> >>>> On 05/02/2013 08:48, Richard Sharpe wrote: R> >>>>> On Wed, May 1, 2013 at 9:34 PM, Alfred Perlstein wrote: R> >>>>>> On 5/1/13 8:03 PM, Richard Sharpe wrote: R> >>>>>>> Hi folks, R> >>>>>>> R> >>>>>>> I am checking to see if there are any known bugs with respect to this R> >>>>>>> in FreeBSD 8.0. R> >>>>>>> R> >>>>>>> Situation is that Samba 3.6.6 uses writev to a non-blocking socket to R> >>>>>>> get the SMB2 requests on the wire. R> >>>>>>> R> >>>>>>> Intermittently, we see the writev return EINVAL even though the data R> >>>>>>> has gotten on the wire. This I have verified by grabbing a capture and R> >>>>>>> comparing the SMB Sequence number in the last outgoing packet on the R> >>>>>>> wire vs the in-memory contents when we get EINVAL. R> >>>>>>> R> >>>>>>> Sometimes it occurs on a four-element IOVEC, sometimes we get EAGAIN R> >>>>>>> on the four-element IOVEC and then we get EINVAL when retrying on a R> >>>>>>> smaller IOVEC. R> >>>>>>> R> >>>>>>> Where should I look to check if there is some path where this might be R> >>>>>>> happening? Is this even the correct mailing list? R> >>>>>>> R> >>>>>> What does the iovec look like when you get EINVAL? Can you sanity check R> >>>>>> it? Is there anything special about it? (zero length vecs?) R> >>>>>> R> >>>>>> I think there are a few "maxvals" that if overrun cause EINVAL to be R> >>>>>> returned. example is if your iovec is somehow huge or has many, many R> >>>>>> elements. R> >>>>> Can anyone tell me the call graph down to the TCP code? R> >>>>> R> >>>> writev kern/sys_generic.c R> >>>> kern_writev R> >>>> dofilewrite R> >>>> fo_write in sys/file.h R> >>>> soo_write in kern/sys_socket.c R> >>>> sosend in kern/uipc_socket.c R> >>>> sosend_generic R> >>>> tcp_usr_send in netinet/tcp_usrreq.c R> >>> Is there a tool that generates call graphs? R> >> R> >> I'm not aware of one that works in the kernel--other than the kernel R> >> itself, of course. With DDB compiled in, you could set a breakpoint on, R> >> say, tcp_output, and show the call stack with bt. R> >> R> >> Also, take a look at stack(9). R> >> R> >>> I have been able to demonstrate that I am getting EINVAL returned from R> >>> writev kern/sys_generic.c, kern_writev, dofilewrite and soo_write, R> >>> but when I add printfs to sosend/sosend_generic it becomes very hard R> >>> to provoke this problem. R> >> R> >> So, either relocating code or changing the timing has changed the R> >> behavior--a Heisenbug. R> >> R> >> If your code looks like this: R> >> R> >> if (error == EINVAL) R> >> printf("you are here\n"); R> >> R> >> You might add __predict_false, like this: R> >> R> >> if (__predict_false(error == EINVAL)) R> >> printf("you are here\n"); R> >> R> >> That /might/ reduce the impact on runtime behavior. R> > R> > Thanks for that. The problem does not appear to be in the TCP or IP R> > layers. Rather, it appears to be in the ixgbe driver. R> > R> > The problem takes a little more effort to provoke, but simple printfs R> > are doing the job so far. R> R> The version of the ixgbe driver we are using seems to set the max size R> of a dma element to 65535 (IXGBE_TSO_SIZE) and, even though large R> numbers of iovecs are sent where the last element is 65536 bytes in R> size, sometimes this causes EINVAL to be returned ... Jack, can you look at this please? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon May 6 08:15:32 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2986D25E; Mon, 6 May 2013 08:15:32 +0000 (UTC) (envelope-from glebius@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 07170A9E; Mon, 6 May 2013 08:15:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r468FVIA090271; Mon, 6 May 2013 08:15:31 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r468FVZr090270; Mon, 6 May 2013 08:15:31 GMT (envelope-from glebius) Date: Mon, 6 May 2013 08:15:31 GMT Message-Id: <201305060815.r468FVZr090270@freefall.freebsd.org> To: rich@enterprisesystems.net, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Subject: Re: kern/178288: [fxp] fxp network driver broken in 7.4 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, 06 May 2013 08:15:32 -0000 Synopsis: [fxp] fxp network driver broken in 7.4 State-Changed-From-To: open->closed State-Changed-By: glebius State-Changed-When: Mon May 6 08:14:11 UTC 2013 State-Changed-Why: I'm sorry, but 7.4-RELEASE isn't a supported release, its EoL was February 28, 2013. http://www.freebsd.org/security/unsupported.html Can you please try 9.1-RELEASE? http://www.freebsd.org/cgi/query-pr.cgi?pr=178288 From owner-freebsd-net@FreeBSD.ORG Mon May 6 08:22:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64A149D3 for ; Mon, 6 May 2013 08:22:37 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id E7467CFD for ; Mon, 6 May 2013 08:22:36 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r468MZUi071506; Mon, 6 May 2013 12:22:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r468MZF5071505; Mon, 6 May 2013 12:22:35 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 6 May 2013 12:22:35 +0400 From: Gleb Smirnoff To: Richard Sharpe Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE Message-ID: <20130506082235.GV15182@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net 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, 06 May 2013 08:22:37 -0000 On Sun, May 05, 2013 at 09:40:42AM -0700, Richard Sharpe wrote: R> Samba currently has a way to set socket parameters from the smb.conf. R> R> This works fine for things like SO_SNDBUF etc, but not so well for the R> TCP KeepAlive parameters. R> R> In this area Samba has a Linux bias. R> R> I am looking at adding support for this under FreeBSD. R> R> The simplest way, it seems to me, is to enhance configure to find the R> appropriate symbols under FreeBSD (and it might be extendable to R> NetBSD etc) and then map them to the Linux symbols: R> R> #ifdef THIS_IS_SOME_SORT_OF_BSD R> #define TCP_KEEPIDLE TCPTV_KEEP_IDLE R> #endif R> R> However, that does mean that *BSD types would have to know that this R> happening because the names you would use in the smb.conf file would R> be Linux-specific, and documentation is often woefully incomplete. R> R> Is there a better method? I don't see the problem you are describing. AFAIK, these socket options have same names in FreeBSD and Linux. For example in Samba 3.6.14 sources it just checks for value defined and if defined compiles support in. See source3/lib/util_sock.c: #ifdef TCP_KEEPCNT {"TCP_KEEPCNT", IPPROTO_TCP, TCP_KEEPCNT, 0, OPT_INT}, #endif #ifdef TCP_KEEPIDLE {"TCP_KEEPIDLE", IPPROTO_TCP, TCP_KEEPIDLE, 0, OPT_INT}, #endif #ifdef TCP_KEEPINTVL {"TCP_KEEPINTVL", IPPROTO_TCP, TCP_KEEPINTVL, 0, OPT_INT}, #endif P.S. Since you mention TCPTV_KEEP_IDLE, I've tried to grep samba sources for this definition getting zero results. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon May 6 10:37:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ACCBB1BA for ; Mon, 6 May 2013 10:37:34 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 40B3E7D5 for ; Mon, 6 May 2013 10:37:34 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id EB4257E81E; Mon, 6 May 2013 20:37:25 +1000 (EST) Message-ID: <518787E5.1030500@freebsd.org> Date: Mon, 06 May 2013 20:37:25 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Angelogiannopoulos, Aris" Subject: Re: Siftr inflight byte question References: <51876A60.10209@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net 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: Mon, 06 May 2013 10:37:34 -0000 [ccing freebsd-net@ so my problem description enters the collective subconscious in case I forget about this again] For everyone tuning in, Aris asked me the apt question of why siftr(4)'s "# inflight bytes" field doesn't take into account sacked bytes. On 05/06/13 18:45, Angelogiannopoulos, Aris wrote: > On 05/06/13 18:31, Lawrence Stewart wrote: >> On 05/06/13 18:18, Angelogiannopoulos, Aris wrote: >>> I noticed that the sent_inflight_bytes variable doesn’t take >>> into account the SACKd bytes in case SACK is used. >>> >>> Is there a specific reason for this? >> >> There is a very good reason - I was too lazy at the time ;) >> >> More specifically, calculating the number of bytes SACKed by the >> receiver is more difficult than pulling simple variables out of the >> TCP control block and I was new to the TCP stack when I wrote >> SIFTR. I've simply never bothered to go back and improve things in >> this regard. > > isn't it as simple as (tp->snd_nxt - tp->snd_fack) + > tp->sackhint.sack_bytes_rexmit ? This is the way the stack is doing > it in case of more than three duplicate acks. You would hope so given the comment accompanying that calculation in tcp_do_segment(), but I'm pretty sure that when I looked into this many moons ago, I found that calculation to be incorrect. I should obviously have gotten to the bottom of the problem back then, but from memory it was not crucial to what I was working on at the time and I subsequently forgot about it. It's good to come back to this now as it should be fixed. >>> Should we change it to better reflect the conditions on the >>> channel? >> >> Ideally, yes. Feel like having a go and submitting a patch? I can >> give you some hints on how to do it if you want a concrete starting >> point. > > Sure why not? My write up below is partially from memory and from a 2 min look at the code just now i.e. parts may be incorrect - please use it as a starting point only... So snd_fack effectively acts as a proxy for snd_una while SACK recovery is happening i.e. it tracks the highest sequence number we've been cumulatively SACKed for (left edge of the window). sack_bytes_rexmit counts the number of bytes we've retransmitted from the known holes during the current recovery episode. snd_max is the highest sequence number we've sent (right edge of the window). Another important bit of info is that the sender-side sack scoreboard stores holes (bytes missing at the receiver), whereas the sack blocks that come in on the wire refer to received byte ranges (bytes successfully received at the receiver). Therefore from the senders perspective, I believe the "pseudo" calculation for bytes in flight during a SACK recovery episode should look something like: (snd_max - snd_fack) - total_hole_bytes + sack_bytes_rexmit 3 of those variables are already around and (hopefully) usable, but I don't believe we currently track a variable equivalent to total_hole_bytes. Hopefully someone will chime in and correct me if any of the above is misguided. Otherwise, your challenge, should you choose to accept it, is to patch SIFTR to perform the above calculation, and to verify that the reported result is correct - perhaps by running some controlled lab experiments where you can review the value reported by SIFTR against the known SACK blocks and sequence numbers on the wire during the recovery episode. You could choose to make total_hole_bytes a sackhint like sack_bytes_rexmit, but I suggest you create a first version of the patch which manually walks the sack scoreboard each time through siftr_siftdata() to sum the # bytes in each hole to ensure you don't inadvertently introduce accounting bugs while developing the patch. Patch v2 can include total_hole_bytes as a sackhint. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Mon May 6 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9D34C9F7 for ; Mon, 6 May 2013 11:06:49 +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 8E074A09 for ; Mon, 6 May 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r46B6npQ023867 for ; Mon, 6 May 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r46B6njQ023865 for freebsd-net@FreeBSD.org; Mon, 6 May 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 May 2013 11:06:49 GMT Message-Id: <201305061106.r46B6njQ023865@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, 06 May 2013 11:06:49 -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/178116 net [tcp] [panic] Kernel panic: general protection fault i o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod o kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176667 net [libalias] [patch] libalias locks on uninitalized data o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c 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/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet 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 checksu 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] [ipfilter] ipfilter/nat NULL pointer deference p 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/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S 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 [new driver] [request]: Port brcm80211 driver from Lin 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 [ipfilter] There is no ippool start script/ipfilter ma 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/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 [ipfilter] [rc.d] [patch] No good way to set ipfilter 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 [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe 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 [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault 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 [ipfilter] [patch] ipfilter drops OOW packets under 6. 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 [ipfilter] [patch] wrong behaviour with skip rule insi 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 [ipfilter] [panic] using ipfilter "auth" keyword leads 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 [ipfilter] 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 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 [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m 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 [ipfilter] ipfilter ipnat problem with h323 proxy supp 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 [ipfilter] [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 [ipfilter] [ppp] Interactive use of user PPP and ipfil 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 463 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:15:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1FA6E601; Mon, 6 May 2013 13:15:13 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 88B14311; Mon, 6 May 2013 13:15:12 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hm14so2525957wib.5 for ; Mon, 06 May 2013 06:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=w/xcEf2NfdALhYEKgX5VMynyYjlKbWN0h/8DyYw4EjU=; b=tgB2Ph9W5UC1PDz1HGFNNkfZAYluSaSy5zIeD2ud4NQl2t8zXjitUrrwJNuBYZNwaZ 9PtSk9bb9w6EaAnJhYuLkouf9AS6kp8hqD5GNlmX72aT23ymiHxNKrkbXbrV1hwFQVuZ VYSNkDB8RdPoGHFXwuodpeL8ng1HhSO7S6xg25aIZGG8skzVy8lV8frxX3MpEtm7gYOw DmNedTc0rYdGr3Wqmd9llxa9455+uyr9DOzDK6u3TWynQUM4Ai5ZVHq5UgRrcL3qlCW8 o4M+bP6KAkzNdhQ+JEQbo/4cHFYhiYcdJQQ61SgGR+gP9oMEGvF9mjJSIbmi/D5eEhmt DegQ== MIME-Version: 1.0 X-Received: by 10.195.13.75 with SMTP id ew11mr12703413wjd.25.1367846111321; Mon, 06 May 2013 06:15:11 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Mon, 6 May 2013 06:15:11 -0700 (PDT) In-Reply-To: <20130506082235.GV15182@FreeBSD.org> References: <20130506082235.GV15182@FreeBSD.org> Date: Mon, 6 May 2013 06:15:11 -0700 Message-ID: Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE From: Richard Sharpe To: Gleb Smirnoff Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 May 2013 13:15:13 -0000 On Mon, May 6, 2013 at 1:22 AM, Gleb Smirnoff wrote: > On Sun, May 05, 2013 at 09:40:42AM -0700, Richard Sharpe wrote: > R> Samba currently has a way to set socket parameters from the smb.conf. > R> > R> This works fine for things like SO_SNDBUF etc, but not so well for the > R> TCP KeepAlive parameters. > R> > R> In this area Samba has a Linux bias. > R> > R> I am looking at adding support for this under FreeBSD. > R> > R> The simplest way, it seems to me, is to enhance configure to find the > R> appropriate symbols under FreeBSD (and it might be extendable to > R> NetBSD etc) and then map them to the Linux symbols: > R> > R> #ifdef THIS_IS_SOME_SORT_OF_BSD > R> #define TCP_KEEPIDLE TCPTV_KEEP_IDLE > R> #endif > R> > R> However, that does mean that *BSD types would have to know that this > R> happening because the names you would use in the smb.conf file would > R> be Linux-specific, and documentation is often woefully incomplete. > R> > R> Is there a better method? > > I don't see the problem you are describing. AFAIK, these socket options > have same names in FreeBSD and Linux. > > For example in Samba 3.6.14 sources it just checks for value defined > and if defined compiles support in. See source3/lib/util_sock.c: Yes, I know that. However, when I do a find and grep over /usr/include looking for files where TCP_KEEPIDLE is defined, I find nothing. When I do the same for TCPTV_KEEP_IDLE I find /usr/include/netinet/tcp_timer.h. This seems to mean that the symbols Samba is using are not defined on FreeB= SD. These appear to be the symbols defined in FreeBSD 8,0: * connection is idle (no segments received) for TCPTV_KEEP_INIT amount of = time, * is established, if the connection is idle for TCPTV_KEEP_IDLE time #define TCPTV_KEEP_INIT ( 75*hz) /* initial connect keepalive */ #define TCPTV_KEEP_IDLE (120*60*hz) /* dflt time before probing */ #define TCPTV_KEEPINTVL ( 75*hz) /* default probe interval */ #define TCPTV_KEEPCNT 8 /* max probes before drop */ Then, a strings over the smbd produced in one of my recent builds fails to turn up TCP_KEEP*, supporting my contention that the TCP_KEEP* versions of the symbols are not defined. So, at this stage I am terribly confused. > #ifdef TCP_KEEPCNT > {"TCP_KEEPCNT", IPPROTO_TCP, TCP_KEEPCNT, 0, OPT_INT}, > #endif > #ifdef TCP_KEEPIDLE > {"TCP_KEEPIDLE", IPPROTO_TCP, TCP_KEEPIDLE, 0, OPT_INT}, > #endif > #ifdef TCP_KEEPINTVL > {"TCP_KEEPINTVL", IPPROTO_TCP, TCP_KEEPINTVL, 0, OPT_INT}, > #endif > > P.S. > Since you mention TCPTV_KEEP_IDLE, I've tried to grep samba sources > for this definition getting zero results. > > -- > Totus tuus, Glebius. --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:23:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A0339850 for ; Mon, 6 May 2013 13:23:34 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 15B6037D for ; Mon, 6 May 2013 13:23:33 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r46DNWCQ073025; Mon, 6 May 2013 17:23:32 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r46DNWZV073024; Mon, 6 May 2013 17:23:32 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 6 May 2013 17:23:32 +0400 From: Gleb Smirnoff To: Richard Sharpe Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE Message-ID: <20130506132332.GZ15182@glebius.int.ru> References: <20130506082235.GV15182@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net 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, 06 May 2013 13:23:34 -0000 On Mon, May 06, 2013 at 06:15:11AM -0700, Richard Sharpe wrote: R> On Mon, May 6, 2013 at 1:22 AM, Gleb Smirnoff wrote: R> > On Sun, May 05, 2013 at 09:40:42AM -0700, Richard Sharpe wrote: R> > R> Samba currently has a way to set socket parameters from the smb.conf. R> > R> R> > R> This works fine for things like SO_SNDBUF etc, but not so well for the R> > R> TCP KeepAlive parameters. R> > R> R> > R> In this area Samba has a Linux bias. R> > R> R> > R> I am looking at adding support for this under FreeBSD. R> > R> R> > R> The simplest way, it seems to me, is to enhance configure to find the R> > R> appropriate symbols under FreeBSD (and it might be extendable to R> > R> NetBSD etc) and then map them to the Linux symbols: R> > R> R> > R> #ifdef THIS_IS_SOME_SORT_OF_BSD R> > R> #define TCP_KEEPIDLE TCPTV_KEEP_IDLE R> > R> #endif R> > R> R> > R> However, that does mean that *BSD types would have to know that this R> > R> happening because the names you would use in the smb.conf file would R> > R> be Linux-specific, and documentation is often woefully incomplete. R> > R> R> > R> Is there a better method? R> > R> > I don't see the problem you are describing. AFAIK, these socket options R> > have same names in FreeBSD and Linux. R> > R> > For example in Samba 3.6.14 sources it just checks for value defined R> > and if defined compiles support in. See source3/lib/util_sock.c: R> R> Yes, I know that. However, when I do a find and grep over /usr/include R> looking for files where TCP_KEEPIDLE is defined, I find nothing. When R> I do the same for TCPTV_KEEP_IDLE I find R> /usr/include/netinet/tcp_timer.h. R> R> This seems to mean that the symbols Samba is using are not defined on FreeBSD. R> R> These appear to be the symbols defined in FreeBSD 8,0: The discussed socket options aren't supported in 8.0. Please install FreeBSD 9.1 and recompile Samba port. It will pick up all supported options. R> * connection is idle (no segments received) for TCPTV_KEEP_INIT amount of time, R> * is established, if the connection is idle for TCPTV_KEEP_IDLE time R> #define TCPTV_KEEP_INIT ( 75*hz) /* initial connect keepalive */ R> #define TCPTV_KEEP_IDLE (120*60*hz) /* dflt time before probing */ R> #define TCPTV_KEEPINTVL ( 75*hz) /* default probe interval */ R> #define TCPTV_KEEPCNT 8 /* max probes before drop */ These defines are not socket options, although they are relevant to discussed socket options. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:26:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D37A9CB; Mon, 6 May 2013 13:26:16 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id E51293D5; Mon, 6 May 2013 13:26:15 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id u3so2956360wey.22 for ; Mon, 06 May 2013 06:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=1XHQZLKHrT8H4ALN62/3MVya3FN9Sasb/w1dOAIa8MA=; b=Yoig39ZjscGb/DjSk1+EsOl9gNwseA1pxHbwujd2fRCK3auTqfMtlAu6w5T009L0Tc A6YIoeOf0VypetFWzavCvSPjbH0k9BZshRtgf8I5N2gh8OXUAUsrypmZBuHqLPCdO3si /18LP1AeBfz3TNZEN6W+BPlQs7PPMcbOaFhM3Suq7Bvjl+yvZJ/OMBHimqXw7a/Z1xLI LNRHWBZo7tDfUx2kKvUwXIIYuOrt+hGSw8O9q4e0++epZIfgRXx5uSCFTLqAYM//S1js dQRue3774l+eW0gbnQ6cwPwi6efuvf9aW7aR9GKq4hS5jhnWyfVX9tVChdlnS1VjjDuf ALjg== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr25342808wjb.29.1367846774455; Mon, 06 May 2013 06:26:14 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Mon, 6 May 2013 06:26:14 -0700 (PDT) In-Reply-To: <20130506132332.GZ15182@glebius.int.ru> References: <20130506082235.GV15182@FreeBSD.org> <20130506132332.GZ15182@glebius.int.ru> Date: Mon, 6 May 2013 06:26:14 -0700 Message-ID: Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE From: Richard Sharpe To: Gleb Smirnoff Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 May 2013 13:26:16 -0000 On Mon, May 6, 2013 at 6:23 AM, Gleb Smirnoff wrote: > On Mon, May 06, 2013 at 06:15:11AM -0700, Richard Sharpe wrote: > R> On Mon, May 6, 2013 at 1:22 AM, Gleb Smirnoff wr= ote: > R> > On Sun, May 05, 2013 at 09:40:42AM -0700, Richard Sharpe wrote: > R> > R> Samba currently has a way to set socket parameters from the smb.c= onf. > R> > R> > R> > R> This works fine for things like SO_SNDBUF etc, but not so well fo= r the > R> > R> TCP KeepAlive parameters. > R> > R> > R> > R> In this area Samba has a Linux bias. > R> > R> > R> > R> I am looking at adding support for this under FreeBSD. > R> > R> > R> > R> The simplest way, it seems to me, is to enhance configure to find= the > R> > R> appropriate symbols under FreeBSD (and it might be extendable to > R> > R> NetBSD etc) and then map them to the Linux symbols: > R> > R> > R> > R> #ifdef THIS_IS_SOME_SORT_OF_BSD > R> > R> #define TCP_KEEPIDLE TCPTV_KEEP_IDLE > R> > R> #endif > R> > R> > R> > R> However, that does mean that *BSD types would have to know that t= his > R> > R> happening because the names you would use in the smb.conf file wo= uld > R> > R> be Linux-specific, and documentation is often woefully incomplete= . > R> > R> > R> > R> Is there a better method? > R> > > R> > I don't see the problem you are describing. AFAIK, these socket opti= ons > R> > have same names in FreeBSD and Linux. > R> > > R> > For example in Samba 3.6.14 sources it just checks for value defined > R> > and if defined compiles support in. See source3/lib/util_sock.c: > R> > R> Yes, I know that. However, when I do a find and grep over /usr/include > R> looking for files where TCP_KEEPIDLE is defined, I find nothing. When > R> I do the same for TCPTV_KEEP_IDLE I find > R> /usr/include/netinet/tcp_timer.h. > R> > R> This seems to mean that the symbols Samba is using are not defined on = FreeBSD. > R> > R> These appear to be the symbols defined in FreeBSD 8,0: > > The discussed socket options aren't supported in 8.0. > > Please install FreeBSD 9.1 and recompile Samba port. It will pick up > all supported options. > > R> * connection is idle (no segments received) for TCPTV_KEEP_INIT amoun= t of time, > R> * is established, if the connection is idle for TCPTV_KEEP_IDLE time > R> #define TCPTV_KEEP_INIT ( 75*hz) /* initial connec= t keepalive */ > R> #define TCPTV_KEEP_IDLE (120*60*hz) /* dflt time befo= re probing */ > R> #define TCPTV_KEEPINTVL ( 75*hz) /* default probe = interval */ > R> #define TCPTV_KEEPCNT 8 /* max probes bef= ore drop */ > > These defines are not socket options, although they are relevant to discu= ssed > socket options. Thank you for that answer. I don't have the option to install FreeBSD 9.1. Maybe we will move to 9.1 in the future. However, I now understand the issues better. Of course that does complicate my proposal on Samba technical, just a little. --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:28:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D7E37B48 for ; Mon, 6 May 2013 13:28:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6420F3EC for ; Mon, 6 May 2013 13:28:22 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r46DSLBG073060; Mon, 6 May 2013 17:28:21 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r46DSL23073059; Mon, 6 May 2013 17:28:21 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 6 May 2013 17:28:21 +0400 From: Gleb Smirnoff To: Richard Sharpe Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE Message-ID: <20130506132821.GA15182@glebius.int.ru> References: <20130506082235.GV15182@FreeBSD.org> <20130506132332.GZ15182@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net 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, 06 May 2013 13:28:23 -0000 On Mon, May 06, 2013 at 06:26:14AM -0700, Richard Sharpe wrote: R> Thank you for that answer. I don't have the option to install FreeBSD R> 9.1. Maybe we will move to 9.1 in the future. R> R> However, I now understand the issues better. Of course that does R> complicate my proposal on Samba technical, just a little. I don't understand the proposal. Samba correctly compiles with support for the discussed socket options on those operating systems that support them. No "fixes" to Samba are required, everything works correctly. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:32:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1CACD17; Mon, 6 May 2013 13:32:38 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 245AE600; Mon, 6 May 2013 13:32:37 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id r46so2996962wey.41 for ; Mon, 06 May 2013 06:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=IIbqruCxpafY73I/lUkKcn0SYqt3YpWn949GRcojd+8=; b=08VTEAebhlDt2SdF7mzGjS/3s2vNSVfxp+GEzt0OXpQbrX8Ihi5qhW5VSI0JRaqFCm JUl4klMP9/Tm3wxU4jcS0L3N93/oAawBxbC2Hza2ipPfAxFfXrGXMLhSw7TOptk6Yfj8 o6YlpqKio6sv+muuDFjhiEDAC/rFTzfRioDNz70D9r4EDXxh3wHIYC7p5C/qCA5/VnGE B9oMGLvdL+2IQO5/qjqvOi2gXBKPN4U7MRF9FjnE+lcuuA/8k2RkZqImrpJ3R9wmw/hr wraSaw71C+wh0zanikkpi9dXw+b3gxLGiEjdCkKCvs/BOuktnYoBif40Me2kUVvnhKi/ BySg== MIME-Version: 1.0 X-Received: by 10.195.13.75 with SMTP id ew11mr12795047wjd.25.1367847157364; Mon, 06 May 2013 06:32:37 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Mon, 6 May 2013 06:32:37 -0700 (PDT) In-Reply-To: <20130506132821.GA15182@glebius.int.ru> References: <20130506082235.GV15182@FreeBSD.org> <20130506132332.GZ15182@glebius.int.ru> <20130506132821.GA15182@glebius.int.ru> Date: Mon, 6 May 2013 06:32:37 -0700 Message-ID: Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE From: Richard Sharpe To: Gleb Smirnoff Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 May 2013 13:32:38 -0000 On Mon, May 6, 2013 at 6:28 AM, Gleb Smirnoff wrote: > On Mon, May 06, 2013 at 06:26:14AM -0700, Richard Sharpe wrote: > R> Thank you for that answer. I don't have the option to install FreeBSD > R> 9.1. Maybe we will move to 9.1 in the future. > R> > R> However, I now understand the issues better. Of course that does > R> complicate my proposal on Samba technical, just a little. > > I don't understand the proposal. Samba correctly compiles with support > for the discussed socket options on those operating systems that support > them. No "fixes" to Samba are required, everything works correctly. Perhaps there are others out there like us who have to stick with earlier versions of FreeBSD where the symbols Samba currently uses are not supported. In the spirit of few or no surprises for users, a small amount of #ifdef stuff will work. Of course, my fellow Samba team members might decide that it is not worth i= t. --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:35:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E180178 for ; Mon, 6 May 2013 13:35:43 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9A88562C for ; Mon, 6 May 2013 13:35:42 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r46DZfwL073146; Mon, 6 May 2013 17:35:41 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r46DZf9e073145; Mon, 6 May 2013 17:35:41 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 6 May 2013 17:35:41 +0400 From: Gleb Smirnoff To: Richard Sharpe Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE Message-ID: <20130506133541.GB15182@glebius.int.ru> References: <20130506082235.GV15182@FreeBSD.org> <20130506132332.GZ15182@glebius.int.ru> <20130506132821.GA15182@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Net 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, 06 May 2013 13:35:43 -0000 On Mon, May 06, 2013 at 06:32:37AM -0700, Richard Sharpe wrote: R> On Mon, May 6, 2013 at 6:28 AM, Gleb Smirnoff wrote: R> > On Mon, May 06, 2013 at 06:26:14AM -0700, Richard Sharpe wrote: R> > R> Thank you for that answer. I don't have the option to install FreeBSD R> > R> 9.1. Maybe we will move to 9.1 in the future. R> > R> R> > R> However, I now understand the issues better. Of course that does R> > R> complicate my proposal on Samba technical, just a little. R> > R> > I don't understand the proposal. Samba correctly compiles with support R> > for the discussed socket options on those operating systems that support R> > them. No "fixes" to Samba are required, everything works correctly. R> R> Perhaps there are others out there like us who have to stick with R> earlier versions of FreeBSD where the symbols Samba currently uses are R> not supported. R> R> In the spirit of few or no surprises for users, a small amount of R> #ifdef stuff will work. R> R> Of course, my fellow Samba team members might decide that it is not worth it. No, small amount of ifdef stuff would not work. FreeBSD 8.0 doesn't have these socket options, you can't bring support for them defining their values. Even if you manage to compile samba with support for these socket options, it will fail at runtime, getting EINVAL error from the setsockopt() system call. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon May 6 13:45:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D7F6668; Mon, 6 May 2013 13:45:20 +0000 (UTC) (envelope-from realrichardsharpe@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 04CF66A9; Mon, 6 May 2013 13:45:19 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hm14so2558350wib.5 for ; Mon, 06 May 2013 06:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Y9R4vCxpCWg53p29QOj8h5Xv4onWOTG+pe3tTvE6BZc=; b=Xh/1DeTsSHNCdeNuqyiE9pl1X19lG/u+LoeDsHkft00IAsSmgTbZ9bZvTSJ00Kgrgi TLcATLua8MH+xYOzb/qbbpHH1bBS2sRqmIRdff4bYWQ9JIEsygyj5TafqwyMvXBY4ulu vVIGVZWOFA/+onS52qKvpDuj/zYUYn/lhDg5mnSktu6WdVoTLj/vbjKmafNmeAmSRuQv J1QgpGb0godvuCMRyhRTB41Vd+gTnpPk64rC3XlDLo9dMifvaKX31RpxIUcW7MC/4gmS 76JnH6U8CXA6vbq/mjG80canlKsvJcOkbRf2IhIhkYifSlCZaD9BNcFnk5UNn/SWpxU+ O9cQ== MIME-Version: 1.0 X-Received: by 10.195.13.75 with SMTP id ew11mr12869934wjd.25.1367847919230; Mon, 06 May 2013 06:45:19 -0700 (PDT) Received: by 10.194.179.194 with HTTP; Mon, 6 May 2013 06:45:19 -0700 (PDT) In-Reply-To: <20130506133541.GB15182@glebius.int.ru> References: <20130506082235.GV15182@FreeBSD.org> <20130506132332.GZ15182@glebius.int.ru> <20130506132821.GA15182@glebius.int.ru> <20130506133541.GB15182@glebius.int.ru> Date: Mon, 6 May 2013 06:45:19 -0700 Message-ID: Subject: Re: TCP_KEEPIDLE vs TCPTV_KEEP_IDLE From: Richard Sharpe To: Gleb Smirnoff Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 May 2013 13:45:20 -0000 On Mon, May 6, 2013 at 6:35 AM, Gleb Smirnoff wrote: > On Mon, May 06, 2013 at 06:32:37AM -0700, Richard Sharpe wrote: > R> On Mon, May 6, 2013 at 6:28 AM, Gleb Smirnoff wr= ote: > R> > On Mon, May 06, 2013 at 06:26:14AM -0700, Richard Sharpe wrote: > R> > R> Thank you for that answer. I don't have the option to install Fre= eBSD > R> > R> 9.1. Maybe we will move to 9.1 in the future. > R> > R> > R> > R> However, I now understand the issues better. Of course that does > R> > R> complicate my proposal on Samba technical, just a little. > R> > > R> > I don't understand the proposal. Samba correctly compiles with suppo= rt > R> > for the discussed socket options on those operating systems that sup= port > R> > them. No "fixes" to Samba are required, everything works correctly. > R> > R> Perhaps there are others out there like us who have to stick with > R> earlier versions of FreeBSD where the symbols Samba currently uses are > R> not supported. > R> > R> In the spirit of few or no surprises for users, a small amount of > R> #ifdef stuff will work. > R> > R> Of course, my fellow Samba team members might decide that it is not wo= rth it. > > No, small amount of ifdef stuff would not work. FreeBSD 8.0 doesn't have > these socket options, you can't bring support for them defining their val= ues. > > Even if you manage to compile samba with support for these socket options= , > it will fail at runtime, getting EINVAL error from the setsockopt() syste= m > call. OK, I see what you mean. A trawl over the kernel code shows that these values are only used for setting up the defaults. OK, that closes one avenue for me. --=20 Regards, Richard Sharpe (=A6=F3=A5H=B8=D1=BC~=A1H=B0=DF=A6=B3=A7=F9=B1d=A1C--=B1=E4=BE=DE) From owner-freebsd-net@FreeBSD.ORG Mon May 6 15:50:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 68760F29 for ; Mon, 6 May 2013 15:50:02 +0000 (UTC) (envelope-from gnats@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 588DAE1A for ; Mon, 6 May 2013 15:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r46Fo1Nc081258 for ; Mon, 6 May 2013 15:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r46Fo1OA081257; Mon, 6 May 2013 15:50:01 GMT (envelope-from gnats) Date: Mon, 6 May 2013 15:50:01 GMT Message-Id: <201305061550.r46Fo1OA081257@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Subject: Re: kern/165903: mbuf leak X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:50:02 -0000 The following reply was made to PR kern/165903; it has been noted by GNATS. From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= To: bug-followup@freebsd.org, eugene@zhegan.in Cc: Subject: Re: kern/165903: mbuf leak Date: Mon, 6 May 2013 17:48:41 +0200 Same problem here on all my firewalls (FreeBSD 9.0-RELEASE-p3 with pf + pfsync + carp) with bce(4) and/or em(4). I need to reboot lot's of them each month. # netstat -m 13555746/999/13556745 mbufs in use (current/cache/total) 5104/1358/6462/25600 mbuf clusters in use (current/cache/total/max) 5104/528 mbuf+clusters out of packet secondary zone in use (current/cache) 0/35/35/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 3399144K/3105K/3402250K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # w 12:13PM up 46 days, 21:52, 2 users, load averages: 0.00, 0.01, 0.00 # pfctl -si Status: Enabled for 0 days 01:38:10 Debug: Urgent State Table Total Rate current entries 801 searches 27756329 4712.4/s inserts 20571 3.5/s removals 19770 3.4/s Counters match 48811 8.3/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 2 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 3 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s # vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP UMA Kegs: 208, 0, 104, 15, 104, 0, 0 UMA Zones: 896, 0, 104, 0, 104, 0, 0 UMA Slabs: 568, 0, 1321, 65, 5465, 0, 0 UMA RCntSlabs: 568, 0, 3266, 290, 3740, 0, 0 UMA Hash: 256, 0, 0, 0, 3, 0, 0 16 Bucket: 152, 0, 51, 124, 175, 0, 0 32 Bucket: 280, 0, 93, 75, 285, 0, 0 64 Bucket: 536, 0, 89, 30, 477, 57, 0 128 Bucket: 1048, 0, 227, 13, 1912,1638, 0 VM OBJECT: 216, 0, 5217, 723,115975437, 0, 0 MAP: 232, 0, 7, 25, 7, 0, 0 KMAP ENTRY: 120, 149110, 93, 682, 245210, 0, 0 MAP ENTRY: 120, 0, 683, 929,281097240, 0, 0 fakepg: 120, 0, 0, 0, 0, 0, 0 mt_zone: 4112, 0, 249, 14, 249, 0, 0 16: 16, 0, 2718, 978, 6192471, 0, 0 32: 32, 0, 3533, 810,38936771, 0, 0 64: 64, 0, 5607, 1057,4608723559, 0, 0 128: 128, 0, 6998, 2369, 2110233, 0, 0 256: 256, 0, 673, 1412,45732110, 0, 0 512: 512, 0, 1115, 691, 6694864, 0, 0 1024: 1024, 0, 60, 232, 5016833, 0, 0 2048: 2048, 0, 107, 235, 3859789, 0, 0 4096: 4096, 0, 377, 232,983233228, 0, 0 Files: 80, 0, 90, 630,68087991, 0, 0 TURNSTILE: 136, 0, 502, 58, 502, 0, 0 umtx pi: 96, 0, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0, 0 PROC: 1160, 0, 50, 355, 5373594, 0, 0 THREAD: 1112, 0, 469, 32, 469, 0, 0 SLEEPQUEUE: 80, 0, 502, 107, 502, 0, 0 VMSPACE: 392, 0, 27, 503, 5373726, 0, 0 cpuset: 72, 0, 2, 98, 2, 0, 0 audit_record: 960, 0, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 5103, 529,1840345056, 0, 0 mbuf: 256, 0,13550641, 472,3618521303, 0, 0 mbuf_cluster: 2048, 25600, 5632, 830,125290521, 0, 0 mbuf_jumbo_page: 4096, 12800, 0, 35, 85, 0, 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 656, 6840437, 0, 0 ttyinq: 160, 0, 105, 135, 480, 0, 0 ttyoutq: 256, 0, 55, 110, 250, 0, 0 ata_request: 328, 0, 0, 36, 15, 0, 0 ata_composite: 336, 0, 0, 0, 0, 0, 0 VNODE: 480, 0, 19475, 645, 202179, 0, 0 VNODEPOLL: 112, 0, 0, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 160,118983533, 0, 0 S VFS Cache: 108, 0, 24400, 548, 611353, 0, 0 L VFS Cache: 328, 0, 794, 70, 805, 0, 0 DIRHASH: 1024, 0, 4, 108, 300, 0, 0 Mountpoints: 768, 0, 6, 19, 15, 0, 0 pipe: 728, 0, 9, 326, 4418624, 0, 0 ksiginfo: 112, 0, 395, 496, 216846, 0, 0 itimer: 344, 0, 1, 32, 2, 0, 0 KNOTE: 128, 0, 0, 145, 1230, 0, 0 bridge_rtnode: 64, 0, 0, 0, 0, 0, 0 pfsrctrpl: 152, 10000, 0, 0, 0, 0, 0 pfrulepl: 936, 0, 229, 11, 229, 0, 0 pfstatepl: 288, 1200004, 916, 1216,35933253, 0, 0 pfstatekeypl: 288, 0, 1087, 1487,37621186, 0, 0 pfstateitempl: 288, 0, 1088, 1499, 9798813, 0, 0 pfaltqpl: 240, 0, 4, 28, 4, 0, 0 pfpooladdrpl: 88, 0, 5, 79, 5, 0, 0 pfrktable: 1296, 10002, 69, 141, 1567, 0, 0 pfrkentry: 160, 200016, 549, 651, 4612, 0, 0 pffrent: 32, 10100, 0, 0, 0, 0, 0 pffrag: 80, 0, 0, 0, 0, 0, 0 pffrcache: 80, 10035, 0, 0, 0, 0, 0 pffrcent: 24, 50022, 0, 0, 0, 0, 0 pfstatescrub: 40, 0, 39, 2397, 1722001, 0, 0 pfiaddrpl: 120, 0, 1, 61, 1, 0, 0 pfospfen: 112, 0, 700, 26, 700, 0, 0 pfosfp: 40, 0, 410, 94, 410, 0, 0 pfsync: 88, 0, 0, 210,41325226, 0, 0 socket: 680, 25602, 36, 378,16623612, 0, 0 unpcb: 240, 25600, 10, 182, 366692, 0, 0 ipq: 56, 819, 0, 0, 0, 0, 0 udp_inpcb: 392, 25600, 23, 157,15263309, 0, 0 udpcb: 16, 25704, 23, 649,15263309, 0, 0 tcp_inpcb: 392, 25600, 2, 408, 978814, 0, 0 tcpcb: 976, 25600, 2, 282, 978814, 0, 0 tcptw: 72, 5150, 0, 100, 16, 0, 0 syncache: 152, 15375, 0, 75, 15, 0, 0 hostcache: 136, 15372, 3, 109, 15, 0, 0 tcpreass: 40, 1680, 0, 252, 210, 0, 0 sackhole: 32, 0, 0, 0, 0, 0, 0 sctp_ep: 1368, 25600, 0, 0, 0, 0, 0 sctp_asoc: 2280, 40000, 0, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 216, 42, 0, 0 sctp_raddr: 704, 80000, 0, 0, 0, 0, 0 sctp_chunk: 136, 400008, 0, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0, 0 sctp_stream_msg_out: 112, 400026, 0, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0, 0 ripcb: 392, 25600, 0, 50, 13528, 0, 0 rtentry: 200, 0, 178, 107, 1370, 0, 0 selfd: 56, 0, 397, 485,94221054, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0, 0 FFS inode: 168, 0, 19366, 720, 202047, 0, 0 FFS1 dinode: 128, 0, 16749, 448, 18414, 0, 0 FFS2 dinode: 256, 0, 2617, 653, 183633, 0, 0 md0: 512, 0, 3015, 170, 3015, 0, 0 md1: 512, 0, 5949, 176, 5996, 0, 0 #rc.conf extract: cloned_interfaces="vlan121 vlan125 vlan20 vlan540 vlan950 vlan958 carp121 carp125 carp20 carp540 carp950 carp958" network_interfaces="bce1 carp121 carp125 carp20 carp540 carp950 carp958 vlan121 vlan125 vlan20 vlan540 vlan950 vlan958" vlans_bce0="vlan20 vlan121 vlan125 vlan958" create_args_vlan20="vlan 20 vlandev bce0" create_args_vlan121="vlan 121 vlandev bce0" create_args_vlan125="vlan 125 vlandev bce0" create_args_vlan958="vlan 958 vlandev bce0" ifconfig_bce0=" media 100baseTX mediaopt full-duplex up" ifconfig_bce1="172.16.0.1 netmask 0xfffffffc up" vlans_em0="vlan950 vlan540" create_args_vlan950="vlan 950 vlandev em0" create_args_vlan540="vlan 540 vlandev em0" ifconfig_em0=" media 1000baseTX mediaopt full-duplex up" # cat /var/run/dmesg.boot Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE-p3 #0: Thu Sep 20 13:34:07 CEST 2012 root@WALL:/usr/obj/WALL.amd64/usr/local/wall/FreeBSD/src/sys/WALL-AMD64 amd64 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.12-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4048449536 (3860 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20110527/tbfadt-638) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 3 range: 1 vs 8100000000 pci0: on pcib0 pcib1: irq 28 at device 1.0 on pci0 pci11: on pcib1 bce0: mem 0x92000000-0x93ffffff irq 28 at device 0.0 on pci11 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: e4:1f:13:62:cd:20 bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (5.2.2); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.6) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1: mem 0x94000000-0x95ffffff irq 40 at device 0.1 on pci11 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: Ethernet address: e4:1f:13:62:cd:22 bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (5.2.2); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.6) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib2: irq 29 at device 2.0 on pci0 pci16: on pcib2 pcib3: irq 24 at device 3.0 on pci0 pci21: on pcib3 pcib4: irq 30 at device 7.0 on pci0 pci26: on pcib4 pcib5: at device 0.0 on pci26 pci27: on pcib5 pcib6: at device 0.0 on pci27 pci28: on pcib6 em0: port 0x3020-0x303f mem 0x97b60000-0x97b7ffff,0x97b40000-0x97b5ffff irq 37 at device 0.0 on pci28 em0: Using an MSI interrupt em0: Ethernet address: 00:15:17:75:58:1d em1: port 0x3000-0x301f mem 0x97b20000-0x97b3ffff,0x97b00000-0x97b1ffff irq 30 at device 0.1 on pci28 em1: Using an MSI interrupt em1: Ethernet address: 00:15:17:75:58:1c pcib7: at device 1.0 on pci27 pci29: on pcib7 em2: port 0x2020-0x203f mem 0x97a60000-0x97a7ffff,0x97a40000-0x97a5ffff irq 39 at device 0.0 on pci29 em2: Using an MSI interrupt em2: Ethernet address: 00:15:17:75:58:1f em3: port 0x2000-0x201f mem 0x97a20000-0x97a3ffff,0x97a00000-0x97a1ffff irq 37 at device 0.1 on pci29 em3: Using an MSI interrupt em3: Ethernet address: 00:15:17:75:58:1e pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0x40a0-0x40bf irq 17 at device 26.0 on pci0 usbus0: on uhci0 uhci1: port 0x4080-0x409f irq 18 at device 26.1 on pci0 usbus1: on uhci1 ehci0: mem 0x97c21000-0x97c213ff irq 19 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 pcib8: irq 16 at device 28.0 on pci0 pci1: on pcib8 mpt0: port 0x1000-0x10ff mem 0x97910000-0x97913fff,0x97900000-0x9790ffff irq 16 at device 0.0 on pci1 mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 1 Active Volume (2 Max) mpt0: 2 Hidden Drive Members (14 Max) pcib9: irq 16 at device 28.4 on pci0 pci6: on pcib9 pcib10: irq 16 at device 0.0 on pci6 pci7: on pcib10 vgapci0: mem 0x96000000-0x96ffffff,0x97800000-0x97803fff,0x97000000-0x977fffff irq 16 at device 0.0 on pci7 uhci2: port 0x4060-0x407f irq 17 at device 29.0 on pci0 usbus3: on uhci2 uhci3: port 0x4040-0x405f irq 18 at device 29.1 on pci0 usbus4: on uhci3 uhci4: port 0x4020-0x403f irq 19 at device 29.2 on pci0 usbus5: on uhci4 ehci1: mem 0x97c20000-0x97c203ff irq 17 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6: on ehci1 pcib11: at device 30.0 on pci0 pci31: on pcib11 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x40f0-0x40ff,0x40e0-0x40ef irq 16 at device 31.2 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) atapci1: port 0x4108-0x410f,0x4124-0x4127,0x4100-0x4107,0x4120-0x4123,0x40d0-0x40df,0x40c0-0x40cf irq 21 at device 31.5 on pci0 ata2: on atapci1 ata3: on atapci1 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard pcib12: pcibus 255 on qpi0 pci255: on pcib12 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 usbus6: 480Mbps High Speed USB v2.0 ugen6.1: at usbus6 uhub6: on usbus6 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub2: 6 ports with 6 removable, self powered mpt0: mpt_read_cfg_page: Config Info Status 22 mpt0:vol0(mpt0:0:0): mpt_refresh_raid_vol: Failed to read RAID Vol Page(0) mpt0:vol0(mpt0:0:0): Settings ( ) mpt0:vol0(mpt0:0:0): 0 Members: mpt0:vol0(mpt0:0:0): RAID-0 - Optimal (mpt0:0:2): Physical (mpt0:0:2:0), Pass-thru (mpt0:1:0:0) uhub6: 6 ports with 6 removable, self powered (mpt0:0:2): Online (mpt0:0:3): Physical (mpt0:0:3:0), Pass-thru (mpt0:1:1:0) (mpt0:0:3): Online da0 at mpt0 bus 0 scbus0 target 1 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 68664MB (140623872 512 byte sectors: 255H 63S/T 8753C) cd0 at ata0 bus 0 scbus2 target 0 lun 0 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! cd0: Removable CD-ROM SCSI-0 device SMP: AP CPU #2 Launched! cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ufs/WALLs1a [ro]... ugen3.2: at usbus3 bce1: Gigabit link up! bce1: Gigabit link up! bce1: Gigabit link up! altq: emulate 256000000Hz cpu clock # pciconf -lvbc hostb0@pci0:0:0:0: class=0x060000 card=0x72701014 chip=0x34068086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520 I/O Hub to ESI Port' class = bridge subclass = HOST-PCI cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 128(128) link x4(x4) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib1@pci0:0:1:0: class=0x060400 card=0x34081014 chip=0x34088086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x34081014 cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x2(x2) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib2@pci0:0:2:0: class=0x060400 card=0x34091014 chip=0x34098086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 2' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x34091014 cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x0(x2) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 pcib3@pci0:0:3:0: class=0x060400 card=0x340a1014 chip=0x340a8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 3' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340a1014 cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x0(x16) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 pcib4@pci0:0:7:0: class=0x060400 card=0x340e1014 chip=0x340e8086 rev=0x13 hdr=0x01 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub PCI Express Root Port 7' class = bridge subclass = PCI-PCI cap 0d[40] = PCI Bridge card=0x340e1014 cap 05[60] = MSI supports 2 messages, vector masks cap 10[90] = PCI-Express 2 root port max data 256(256) link x4(x16) cap 01[e0] = powerspec 3 supports D0 D3 current D0 ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 000d[150] = unknown 1 ecap 000b[160] = unknown 0 none0@pci0:0:16:0: class=0x080000 card=0x00000000 chip=0x34258086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Physical and Link Layer Registers Port 0' class = base peripheral subclass = interrupt controller cap 09[50] = vendor (length 255) Intel cap 15 version 0 none1@pci0:0:16:1: class=0x080000 card=0x00000000 chip=0x34268086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Routing and Protocol Layer Registers Port 0' class = base peripheral subclass = interrupt controller none2@pci0:0:17:0: class=0x080000 card=0x00000000 chip=0x34278086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500 Physical and Link Layer Registers Port 1' class = base peripheral subclass = interrupt controller cap 09[50] = vendor (length 255) Intel cap 15 version 0 none3@pci0:0:17:1: class=0x080000 card=0x00000000 chip=0x34288086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500 Routing & Protocol Layer Register Port 1' class = base peripheral subclass = interrupt controller none4@pci0:0:20:0: class=0x080000 card=0x00000000 chip=0x342e8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub System Management Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none5@pci0:0:20:1: class=0x080000 card=0x00000000 chip=0x34228086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none6@pci0:0:20:2: class=0x080000 card=0x00000000 chip=0x34238086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub Control Status and RAS Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none7@pci0:0:20:3: class=0x080000 card=0x00000000 chip=0x34388086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 I/O Hub Throttle Registers' class = base peripheral subclass = interrupt controller ioapic0@pci0:0:21:0: class=0x080020 card=0x00000000 chip=0x342f8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Trusted Execution Technology Registers' class = base peripheral subclass = interrupt controller none8@pci0:0:22:0: class=0x088000 card=0x34301014 chip=0x34308086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c00000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none9@pci0:0:22:1: class=0x088000 card=0x34311014 chip=0x34318086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c04000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none10@pci0:0:22:2: class=0x088000 card=0x34321014 chip=0x34328086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c08000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none11@pci0:0:22:3: class=0x088000 card=0x34331014 chip=0x34338086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c0c000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none12@pci0:0:22:4: class=0x088000 card=0x34291014 chip=0x34298086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c10000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none13@pci0:0:22:5: class=0x088000 card=0x342a1014 chip=0x342a8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c14000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none14@pci0:0:22:6: class=0x088000 card=0x342b1014 chip=0x342b8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c18000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 none15@pci0:0:22:7: class=0x088000 card=0x342c1014 chip=0x342c8086 rev=0x13 hdr=0x00 vendor = 'Intel Corporation' device = '5520/5500/X58 Chipset QuickData Technology Device' class = base peripheral bar [10] = type Memory, range 64, base 0x97c1c000, size 16384, enabled cap 11[80] = MSI-X supports 1 message in map 0x10 cap 10[90] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) cap 01[e0] = powerspec 3 supports D0 D3 current D0 uhci0@pci0:0:26:0: class=0x0c0300 card=0x3a371014 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x40a0, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci1@pci0:0:26:1: class=0x0c0300 card=0x3a381014 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x4080, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=0x0c0320 card=0x3a3c1014 chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0x97c21000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib8@pci0:0:28:0: class=0x060400 card=0x3a401014 chip=0x3a408086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) PCI Express Root Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x4(x4) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x3a401014 cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = unknown 1 pcib9@pci0:0:28:4: class=0x060400 card=0x3a481014 chip=0x3a488086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) PCI Express Root Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x3a481014 cap 01[a0] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 ecap 0005[180] = unknown 1 uhci2@pci0:0:29:0: class=0x0c0300 card=0x3a341014 chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x4060, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci3@pci0:0:29:1: class=0x0c0300 card=0x3a351014 chip=0x3a358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x4040, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP uhci4@pci0:0:29:2: class=0x0c0300 card=0x3a361014 chip=0x3a368086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x4020, size 32, enabled cap 13[50] = PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=0x0c0320 card=0x3a3a1014 chip=0x3a3a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0x97c20000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 cap 13[98] = PCI Advanced Features: FLR TP pcib11@pci0:0:30:0: class=0x060401 card=0x244e1014 chip=0x244e8086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI cap 0d[50] = PCI Bridge card=0x244e1014 isab0@pci0:0:31:0: class=0x060100 card=0x3a181014 chip=0x3a188086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JIB (ICH10) LPC Interface Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: Quick Resume, SATA RAID-5, 4 PCI-e x1 slots, SATA RAID-0/1/10 atapci0@pci0:0:31:2: class=0x01018a card=0x3a201014 chip=0x3a208086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) 4 port SATA IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0x40f0, size 16, enabled bar [24] = type I/O Port, range 32, base 0x40e0, size 16, enabled cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 13[b0] = PCI Advanced Features: FLR TP none16@pci0:0:31:3: class=0x0c0500 card=0x3a301014 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) SMBus Controller' class = serial bus subclass = SMBus bar [10] = type Memory, range 64, base 0x97c22000, size 256, enabled bar [20] = type I/O Port, range 32, base 0x4000, size 32, enabled atapci1@pci0:0:31:5: class=0x010185 card=0x3a261014 chip=0x3a268086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82801JI (ICH10 Family) 2 port SATA IDE Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x4108, size 8, enabled bar [14] = type I/O Port, range 32, base 0x4124, size 4, enabled bar [18] = type I/O Port, range 32, base 0x4100, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x4120, size 4, enabled bar [20] = type I/O Port, range 32, base 0x40d0, size 16, enabled bar [24] = type I/O Port, range 32, base 0x40c0, size 16, enabled cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 13[b0] = PCI Advanced Features: FLR TP bce0@pci0:11:0:0: class=0x020000 card=0x03a91014 chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709 Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0x92000000, size 33554432, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 16 messages, 64 bit enabled with 1 message cap 11[a0] = MSI-X supports 9 messages in map 0x10 cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x2(x4) ecap 0003[100] = Serial 1 e41f13fffe62cd20 ecap 0001[110] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] = unknown 1 ecap 0002[160] = VC 1 max VC0 bce1@pci0:11:0:1: class=0x020000 card=0x03a91014 chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709 Gigabit Ethernet' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0x94000000, size 33554432, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 16 messages, 64 bit enabled with 1 message cap 11[a0] = MSI-X supports 9 messages in map 0x10 cap 10[ac] = PCI-Express 2 endpoint max data 256(512) link x2(x4) ecap 0003[100] = Serial 1 e41f13fffe62cd22 ecap 0001[110] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] = unknown 1 ecap 0002[160] = VC 1 max VC0 pcib5@pci0:26:0:0: class=0x060400 card=0x00000000 chip=0x8018111d rev=0x04 hdr=0x01 vendor = 'Integrated Device Technology, Inc.' device = 'PES12N3A PCI Express Switch' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 upstream port max data 256(2048) link x4(x4) cap 01[70] = powerspec 2 supports D0 D3 current D0 ecap 0002[100] = VC 1 max VC0 pcib6@pci0:27:0:0: class=0x060400 card=0x00000000 chip=0x8018111d rev=0x04 hdr=0x01 vendor = 'Integrated Device Technology, Inc.' device = 'PES12N3A PCI Express Switch' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 downstream port max data 256(2048) link x4(x4) cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[7c] = MSI supports 1 message, 64 bit ecap 0002[100] = VC 1 max VC0 pcib7@pci0:27:1:0: class=0x060400 card=0x00000000 chip=0x8018111d rev=0x04 hdr=0x01 vendor = 'Integrated Device Technology, Inc.' device = 'PES12N3A PCI Express Switch' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 downstream port max data 256(2048) link x4(x4) cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[7c] = MSI supports 1 message, 64 bit ecap 0002[100] = VC 1 max VC0 em0@pci0:28:0:0: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0x97b60000, size 131072, enabled bar [14] = type Memory, range 32, base 0x97b40000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x3020, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffff75581c em1@pci0:28:0:1: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0x97b20000, size 131072, enabled bar [14] = type Memory, range 32, base 0x97b00000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x3000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffff75581c em2@pci0:29:0:0: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0x97a60000, size 131072, enabled bar [14] = type Memory, range 32, base 0x97a40000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2020, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffff75581e em3@pci0:29:0:1: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0x97a20000, size 131072, enabled bar [14] = type Memory, range 32, base 0x97a00000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 256(256) link x4(x4) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffff75581e mpt0@pci0:1:0:0: class=0x010000 card=0x03941014 chip=0x00581000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS1068E PCI-Express Fusion-MPT SAS' class = mass storage subclass = SCSI bar [10] = type I/O Port, range 32, base 0x1000, size 256, disabled bar [14] = type Memory, range 64, base 0x97910000, size 16384, enabled bar [1c] = type Memory, range 64, base 0x97900000, size 65536, enabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 1 endpoint max data 128(4096) link x4(x8) cap 05[98] = MSI supports 1 message, 64 bit cap 11[b0] = MSI-X supports 1 message in map 0x14 enabled ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected pcib10@pci0:6:0:0: class=0x060400 card=0x03691014 chip=0x0452101b rev=0x01 hdr=0x01 vendor = 'Vitesse Semiconductor' device = 'VSC452 [SuperBMC]' class = bridge subclass = PCI-PCI cap 05[50] = MSI supports 2 messages, 64 bit cap 01[78] = powerspec 3 supports D0 D3 current D0 cap 10[80] = PCI-Express 1 PCI bridge max data 128(128) link x1(x1) cap 0d[a4] = PCI Bridge card=0x03691014 ecap 0002[100] = VC 1 max VC0 vgapci0@pci0:7:0:0: class=0x030000 card=0x03691014 chip=0x0530102b rev=0x00 hdr=0x00 vendor = 'Matrox Graphics, Inc.' device = 'MGA G200EV' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0x96000000, size 16777216, enabled bar [14] = type Memory, range 32, base 0x97800000, size 16384, enabled bar [18] = type Memory, range 32, base 0x97000000, size 8388608, enabled cap 01[dc] = powerspec 1 supports D0 D3 current D0 hostb1@pci0:255:0:0: class=0x060000 card=0x80868086 chip=0x2c408086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 QuickPath Architecture Generic Non-Core Registers' class = bridge subclass = HOST-PCI hostb2@pci0:255:0:1: class=0x060000 card=0x80868086 chip=0x2c018086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 QuickPath Architecture System Address Decoder' class = bridge subclass = HOST-PCI hostb3@pci0:255:2:0: class=0x060000 card=0x80868086 chip=0x2c108086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 QPI Link 0' class = bridge subclass = HOST-PCI hostb4@pci0:255:2:1: class=0x060000 card=0x80868086 chip=0x2c118086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 QPI Physical 0' class = bridge subclass = HOST-PCI hostb5@pci0:255:2:4: class=0x060000 card=0x80868086 chip=0x2c148086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 QPI Link 1' class = bridge subclass = HOST-PCI hostb6@pci0:255:2:5: class=0x060000 card=0x80868086 chip=0x2c158086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 QPI Physical 1' class = bridge subclass = HOST-PCI hostb7@pci0:255:3:0: class=0x060000 card=0x80868086 chip=0x2c188086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller' class = bridge subclass = HOST-PCI hostb8@pci0:255:3:1: class=0x060000 card=0x80868086 chip=0x2c198086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Target Address Decoder' class = bridge subclass = HOST-PCI hostb9@pci0:255:3:2: class=0x060000 card=0x80868086 chip=0x2c1a8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller RAS Registers' class = bridge subclass = HOST-PCI hostb10@pci0:255:3:4: class=0x060000 card=0x80868086 chip=0x2c1c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Test Registers' class = bridge subclass = HOST-PCI hostb11@pci0:255:4:0: class=0x060000 card=0x80868086 chip=0x2c208086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Control Registers' class = bridge subclass = HOST-PCI hostb12@pci0:255:4:1: class=0x060000 card=0x80868086 chip=0x2c218086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Address Registers' class = bridge subclass = HOST-PCI hostb13@pci0:255:4:2: class=0x060000 card=0x80868086 chip=0x2c228086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Rank Registers' class = bridge subclass = HOST-PCI hostb14@pci0:255:4:3: class=0x060000 card=0x80868086 chip=0x2c238086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Thermal Control Registers' class = bridge subclass = HOST-PCI hostb15@pci0:255:5:0: class=0x060000 card=0x80868086 chip=0x2c288086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Control Registers' class = bridge subclass = HOST-PCI hostb16@pci0:255:5:1: class=0x060000 card=0x80868086 chip=0x2c298086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Address Registers' class = bridge subclass = HOST-PCI hostb17@pci0:255:5:2: class=0x060000 card=0x80868086 chip=0x2c2a8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Rank Registers' class = bridge subclass = HOST-PCI hostb18@pci0:255:5:3: class=0x060000 card=0x80868086 chip=0x2c2b8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Thermal Control Registers' class = bridge subclass = HOST-PCI hostb19@pci0:255:6:0: class=0x060000 card=0x80868086 chip=0x2c308086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Control Registers' class = bridge subclass = HOST-PCI hostb20@pci0:255:6:1: class=0x060000 card=0x80868086 chip=0x2c318086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Address Registers' class = bridge subclass = HOST-PCI hostb21@pci0:255:6:2: class=0x060000 card=0x80868086 chip=0x2c328086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Rank Registers' class = bridge subclass = HOST-PCI hostb22@pci0:255:6:3: class=0x060000 card=0x80868086 chip=0x2c338086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Thermal Control Registers' class = bridge subclass = HOST-PCI From owner-freebsd-net@FreeBSD.ORG Mon May 6 19:12:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2D41EA7A; Mon, 6 May 2013 19:12:47 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id EE690CE6; Mon, 6 May 2013 19:12:46 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 46CE817331BF; Mon, 6 May 2013 16:12:39 -0300 (ADT) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 06289-07; Mon, 6 May 2013 19:12:39 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 8840A17331BE; Mon, 6 May 2013 16:12:37 -0300 (ADT) From: "Marc G. Fournier" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: VirtualBox + FreeBSD 9-STABLE == Frozen Ethernet Date: Mon, 6 May 2013 12:12:35 -0700 Message-Id: <1601E2D3-DF60-4CCB-9F92-9AD05BCBCB10@hub.org> To: "freebsd-net@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "freebsd-virtualization@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, 06 May 2013 19:12:47 -0000 I'm having an odd issue with FreeBSD that I'm not sure how to trace / = where to look =85=20 I have 6 servers, all identical RAM / CPU / Ethernet / etc =85 4 of them = are running VirtualBox, 2 are running Jails =85 one of the 4 I just = switched from Jail -> Virtualbox =85 When running jail(s), the servers are rock solid =85 as soon as I switch = to VirtualBox (the one I just switched is running one Vbox with a = FreeBSD Guest) =85 nothing else is running on the server =85 but I will = get sporadic freezes of the Ethernet. One ran 46 days before it froze, = then after a reboot, it happened a few hours later, now its been running = several hours again without any issues =85 The machine itself is not frozen =85 I can connect via remote console, = login, do ps, etc =85 so its as if the Ethernet (bce device) just went = offline. I was pointed to a wiki about VirtualBox, and my current loader.conf = looks like: =3D=3D=3D aio_load=3D"YES" kern.ipc.shm_use_phys=3D1 accf_http_load=3D"YES" if_bridge_load=3D"YES" if_tap_load=3D"YES" hw.pci.enable_msix=3D0 vboxdrv_load=3D"YES" net.graph.maxdata=3D65536 =3D=3D=3D I'm running the latest version of 9-STABLE as well as the latest version = of vBox available in ports =85 the bce device is an older version of = Broadcom, so not dealing a new one with new features: bce0: And as I say, these work great with jail'd environments ALIASed onto = them =85 The vBox environments are all configured for network using: --nic1 bridged --bridgeadapter1 bce1 Maybe I'm setting up the network wrong? But, it does work for awhile =85=20= I'm not seeing any errors on the console when the ethernet stops working = =85 nothing to indicate an buffer overflowing or something like that =85 = but, again, I can login and run commands, so if there is something I can = run to get more useful details =85 ? From owner-freebsd-net@FreeBSD.ORG Mon May 6 19:43:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 886FEFF9; Mon, 6 May 2013 19:43:25 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 38C2FE71; Mon, 6 May 2013 19:43:24 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id ib11so3352224vcb.7 for ; Mon, 06 May 2013 12:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EOJogWYIPrRE7sHRMVwSMMVCY3SatMP3Bw+tr5iW11k=; b=diN6sNg70W0a7iGzMN8WaV1MdT/1hnVhuph7wNElSDl/gJgSn5u2ElC9DiVkfiMhQ6 OsclxZ45G+fZMOlBUHSTQifa/9kkqDg9/JN0Vz6BL/Q/nz2N9c9AjOOL0sXGqEnBbN5E O8JW5dUOQfPG73bPsPP7mYO3B8bpYqT9+d420IvIBVPusQXCA4XMFAyrFlp8KsBWIj4f 9MZ60AsTVK8rIasky/wOZ7iX0Z3OyHG7KNAKngS7tKuaVGk1BtRwud9bff1jNtXCZ1nI KhRA/5U5SU3UXDH+4iZeGSbruQOJJ3jFvyzSQU4zN7SANK5hSBTPtlp+B2Ns8zNrimL2 uWnA== MIME-Version: 1.0 X-Received: by 10.220.176.71 with SMTP id bd7mr7174570vcb.12.1367869404398; Mon, 06 May 2013 12:43:24 -0700 (PDT) Received: by 10.220.33.135 with HTTP; Mon, 6 May 2013 12:43:24 -0700 (PDT) In-Reply-To: <1601E2D3-DF60-4CCB-9F92-9AD05BCBCB10@hub.org> References: <1601E2D3-DF60-4CCB-9F92-9AD05BCBCB10@hub.org> Date: Mon, 6 May 2013 15:43:24 -0400 Message-ID: Subject: Re: VirtualBox + FreeBSD 9-STABLE == Frozen Ethernet From: Zaphod Beeblebrox To: "Marc G. Fournier" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , "freebsd-virtualization@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, 06 May 2013 19:43:25 -0000 Heh. VirtualBox has (in my experience) been buggy as heck. Beyond buggy as heck. I have 3 virtualization platforms at my disposal (and the host here is win 7). VirtualBox, VMWare and Windows Virtual PC. I can report that under VirtualBox, every major type of guest caused stability problems with the host (Windows 7, Windows XP, FreeBSD, Linux). Stability problems would include crashing of the guest, crashing of the host, network bogons (from interfaces resetting to interfaces hanging --- like yours). I switched various guests to VMWare (the free "player" version) and everything was smooth. Really smooth. No problems running guests for _days_. No problems running multiple guests. I don't use virtual PC much --- it runs XP mode ... just because that's included with Windows 7... but it never causes problems either FWIW. It seemed to me that every update after Sun passed to Oracle brought more bugs. My advice: run away from VirtualBox. On Mon, May 6, 2013 at 3:12 PM, Marc G. Fournier wrote: > > I'm having an odd issue with FreeBSD that I'm not sure how to trace / > where to look =85 > > I have 6 servers, all identical RAM / CPU / Ethernet / etc =85 4 of them = are > running VirtualBox, 2 are running Jails =85 one of the 4 I just switched = from > Jail -> Virtualbox =85 > > When running jail(s), the servers are rock solid =85 as soon as I switch = to > VirtualBox (the one I just switched is running one Vbox with a FreeBSD > Guest) =85 nothing else is running on the server =85 but I will get spora= dic > freezes of the Ethernet. One ran 46 days before it froze, then after a > reboot, it happened a few hours later, now its been running several hours > again without any issues =85 > > The machine itself is not frozen =85 I can connect via remote console, > login, do ps, etc =85 so its as if the Ethernet (bce device) just went > offline. > > I was pointed to a wiki about VirtualBox, and my current loader.conf look= s > like: > > =3D=3D=3D > aio_load=3D"YES" > kern.ipc.shm_use_phys=3D1 > accf_http_load=3D"YES" > if_bridge_load=3D"YES" > if_tap_load=3D"YES" > hw.pci.enable_msix=3D0 > vboxdrv_load=3D"YES" > net.graph.maxdata=3D65536 > =3D=3D=3D > > I'm running the latest version of 9-STABLE as well as the latest version > of vBox available in ports =85 the bce device is an older version of > Broadcom, so not dealing a new one with new features: > > bce0: > > And as I say, these work great with jail'd environments ALIASed onto them= =85 > > The vBox environments are all configured for network using: > > --nic1 bridged --bridgeadapter1 bce1 > > Maybe I'm setting up the network wrong? But, it does work for awhile =85 > > I'm not seeing any errors on the console when the ethernet stops working = =85 > nothing to indicate an buffer overflowing or something like that =85 but, > again, I can login and run commands, so if there is something I can run t= o > get more useful details =85 ? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon May 6 20:45:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4CDCA6D0 for ; Mon, 6 May 2013 20:45:17 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id E09A7347 for ; Mon, 6 May 2013 20:45:16 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id f11so3869474wgh.3 for ; Mon, 06 May 2013 13:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Vcnv4w7II8M8KLPObd1s+JZ+YpbafxFYTwuLASVkF4U=; b=zQ51eHvHggdiVbi6KV7QDtFq73Uiifi2qDjn29M8M7vv1GxpzKJZn8rS5H/zxCDzSI GE28f5hQCKndU1Iaiw7Gc5LiiTWKaXBeyM1BlPVNfL7z8Z0TQaPIH7YZtQpgo6Q3qbkM AkAVBozGu6XHVBfwB7/HNVTN2zkEf6hfKyUU0jenpLz9/gEAbvYHvbP3PBukCQoJObvc 9/lrwSMh8t7QPcxz5hvLB4JIukY+V7HIjfA8K06FEpVC5BfmHtya8xrVbfpDpPjag6au DMuB3OHHQ9wG2gmokUgIczLeVZeBU4z7xxJjqVggHIWPTHpmtwDGj0TFls+4H9S4gtmo NVLw== MIME-Version: 1.0 X-Received: by 10.194.78.204 with SMTP id d12mr27218516wjx.42.1367873115936; Mon, 06 May 2013 13:45:15 -0700 (PDT) Received: by 10.194.71.34 with HTTP; Mon, 6 May 2013 13:45:15 -0700 (PDT) Date: Mon, 6 May 2013 20:45:15 +0000 Message-ID: Subject: Enabling netmap in fbsd9.1 From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Mon, 06 May 2013 20:45:17 -0000 Hi all, According to fbsd 9.1 release notes, netmap is included in this release, but how do I need to do to enable this feature?. Do I need to recompile default kernel with 'device netmap' option enabled?. Only load kernel modules?. My fbsd hosts contains em drivers. Thanks. From owner-freebsd-net@FreeBSD.ORG Tue May 7 04:45:24 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 061453AE; Tue, 7 May 2013 04:45:24 +0000 (UTC) (envelope-from hiren@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 D7005DFC; Tue, 7 May 2013 04:45:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r474jN3P039429; Tue, 7 May 2013 04:45:23 GMT (envelope-from hiren@freefall.freebsd.org) Received: (from hiren@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r474jN6T039428; Tue, 7 May 2013 04:45:23 GMT (envelope-from hiren) Date: Tue, 7 May 2013 04:45:23 GMT Message-Id: <201305070445.r474jN6T039428@freefall.freebsd.org> To: marka@isc.org, hiren@FreeBSD.org, freebsd-net@FreeBSD.org From: hiren@FreeBSD.org Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS 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, 07 May 2013 04:45:24 -0000 Synopsis: [netinet] [patch] Wrong control used to return TOS State-Changed-From-To: open->feedback State-Changed-By: hiren State-Changed-When: Tue May 7 04:42:42 UTC 2013 State-Changed-Why: tuexen@ does not see a need for code change. Waiting for submitter feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=177362 From owner-freebsd-net@FreeBSD.ORG Tue May 7 04:48:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 11E10745; Tue, 7 May 2013 04:48:49 +0000 (UTC) (envelope-from hiren@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 B7974E22; Tue, 7 May 2013 04:48:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r474mm4i039492; Tue, 7 May 2013 04:48:48 GMT (envelope-from hiren@freefall.freebsd.org) Received: (from hiren@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r474mm8H039491; Tue, 7 May 2013 04:48:48 GMT (envelope-from hiren) Date: Tue, 7 May 2013 04:48:48 GMT Message-Id: <201305070448.r474mm8H039491@freefall.freebsd.org> To: hiren@FreeBSD.org, freebsd-net@FreeBSD.org, hiren@FreeBSD.org From: hiren@FreeBSD.org Subject: Re: kern/177184: [bge] [patch] enable wake on lan 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, 07 May 2013 04:48:49 -0000 Synopsis: [bge] [patch] enable wake on lan Responsible-Changed-From-To: freebsd-net->hiren Responsible-Changed-By: hiren Responsible-Changed-When: Tue May 7 04:48:09 UTC 2013 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=177184 From owner-freebsd-net@FreeBSD.ORG Tue May 7 05:05:31 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8B884BD0; Tue, 7 May 2013 05:05:31 +0000 (UTC) (envelope-from hiren@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 65897ECE; Tue, 7 May 2013 05:05:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r4755Vms043029; Tue, 7 May 2013 05:05:31 GMT (envelope-from hiren@freefall.freebsd.org) Received: (from hiren@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r4755UK9043028; Tue, 7 May 2013 05:05:30 GMT (envelope-from hiren) Date: Tue, 7 May 2013 05:05:30 GMT Message-Id: <201305070505.r4755UK9043028@freefall.freebsd.org> To: lutz@iks-service.de, hiren@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: hiren@FreeBSD.org Subject: Re: kern/176667: [libalias] [patch] libalias locks on uninitalized data 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, 07 May 2013 05:05:31 -0000 Synopsis: [libalias] [patch] libalias locks on uninitalized data State-Changed-From-To: open->patched State-Changed-By: hiren State-Changed-When: Tue May 7 05:03:30 UTC 2013 State-Changed-Why: Gleb committed r248158. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: hiren Responsible-Changed-When: Tue May 7 05:03:30 UTC 2013 Responsible-Changed-Why: Gleb committed r248158. http://www.freebsd.org/cgi/query-pr.cgi?pr=176667 From owner-freebsd-net@FreeBSD.ORG Tue May 7 08:59:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C4E21E4 for ; Tue, 7 May 2013 08:59:18 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id D33DE9E9 for ; Tue, 7 May 2013 08:59:17 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UZdVH-0006cU-21 for freebsd-net@freebsd.org; Tue, 07 May 2013 10:44:07 +0200 Received: from office-nat.spylog.net ([193.169.234.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 May 2013 10:44:07 +0200 Received: from citrin by office-nat.spylog.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 May 2013 10:44:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Anton Yuzhaninov Subject: Re: Enabling netmap in fbsd9.1 Date: Tue, 7 May 2013 08:43:50 +0000 (UTC) Organization: Vega Lines: 7 Sender: Anton Yuzhaninov Message-ID: References: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: office-nat.spylog.net X-Comment-To: "C. L. Martinez" User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (FreeBSD/10.0-CURRENT (i386)) 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, 07 May 2013 08:59:18 -0000 On Tue, 07 May 2013 00:45:15, C. L. Martinez wrote: CLM> According to fbsd 9.1 release notes, netmap is included in this release, CLM> but how do I need to do to enable this feature?. Do I need to recompile CLM> default kernel with 'device netmap' option enabled?. Only load kernel CLM> modules?. Yes, you have to recompile kernel with 'device netmap'. From owner-freebsd-net@FreeBSD.ORG Tue May 7 09:17:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ACBA16AE for ; Tue, 7 May 2013 09:17:07 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7E1A8B for ; Tue, 7 May 2013 09:17:07 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id h11so3486049wiv.14 for ; Tue, 07 May 2013 02:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=6eX8F50/2oLpMSlduPtdbXFB4ynv6+xPo5t3VVXLufE=; b=IexOhjxgSo3kWpgWg4ldFe8tIFPaszm5+ObyAFX9L/jjVgRMgJ2j89dFYBZVtabl/2 a1SbS+5PhaNMu7xK5YNWN/7U0NLESvVvzPGMNGS3x3S5su7KHOW/leHilnE82bflIPxc GTksyjNF5JZef1bLbYV8GJ41/ys6sDELEdl4zYZnRR9bY91m90aj9S/7lY+DS2uH3F+E 6PjLdsPyLyf9ESWiiXAtY+A2wMjlbVRb7L1s22/OKrxwabCQv/ZvWdI4JCoer1aNui/b YRDItIaBsvDfmah24/NIkSgskS3ZCGSph3OAMyQl1vtzN+Y0bBS+qI3yNgj5yBc61k/t B4sw== MIME-Version: 1.0 X-Received: by 10.180.185.207 with SMTP id fe15mr1716749wic.33.1367918226473; Tue, 07 May 2013 02:17:06 -0700 (PDT) Received: by 10.194.71.34 with HTTP; Tue, 7 May 2013 02:17:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 May 2013 09:17:06 +0000 Message-ID: Subject: Re: Enabling netmap in fbsd9.1 From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 07 May 2013 09:17:07 -0000 On Tue, May 7, 2013 at 8:43 AM, Anton Yuzhaninov wrote: > On Tue, 07 May 2013 00:45:15, C. L. Martinez wrote: > CLM> According to fbsd 9.1 release notes, netmap is included in this release, > CLM> but how do I need to do to enable this feature?. Do I need to recompile > CLM> default kernel with 'device netmap' option enabled?. Only load kernel > CLM> modules?. > > Yes, you have to recompile kernel with 'device netmap'. Many thanks Anton. From owner-freebsd-net@FreeBSD.ORG Tue May 7 11:30:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0724DD48 for ; Tue, 7 May 2013 11:30:26 +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 3CDE891 for ; Tue, 7 May 2013 11:30:24 +0000 (UTC) Received: (qmail 62671 invoked from network); 7 May 2013 12:32:42 -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 ; 7 May 2013 12:32:42 -0000 Message-ID: <5188E5BF.5060302@freebsd.org> Date: Tue, 07 May 2013 13:30:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: Siftr inflight byte question References: <51876A60.10209@swin.edu.au> <518787E5.1030500@freebsd.org> In-Reply-To: <518787E5.1030500@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-net@freebsd.org" , "Angelogiannopoulos, Aris" 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, 07 May 2013 11:30:26 -0000 On 06.05.2013 12:37, Lawrence Stewart wrote: > [ccing freebsd-net@ so my problem description enters the collective > subconscious in case I forget about this again] > > For everyone tuning in, Aris asked me the apt question of why siftr(4)'s > "# inflight bytes" field doesn't take into account sacked bytes. > > On 05/06/13 18:45, Angelogiannopoulos, Aris wrote: >> On 05/06/13 18:31, Lawrence Stewart wrote: >>> On 05/06/13 18:18, Angelogiannopoulos, Aris wrote: >>>> I noticed that the sent_inflight_bytes variable doesn’t take >>>> into account the SACKd bytes in case SACK is used. >>>> >>>> Is there a specific reason for this? >>> >>> There is a very good reason - I was too lazy at the time ;) >>> >>> More specifically, calculating the number of bytes SACKed by the >>> receiver is more difficult than pulling simple variables out of the >>> TCP control block and I was new to the TCP stack when I wrote >>> SIFTR. I've simply never bothered to go back and improve things in >>> this regard. >> >> isn't it as simple as (tp->snd_nxt - tp->snd_fack) + >> tp->sackhint.sack_bytes_rexmit ? This is the way the stack is doing >> it in case of more than three duplicate acks. > > You would hope so given the comment accompanying that calculation in > tcp_do_segment(), but I'm pretty sure that when I looked into this many > moons ago, I found that calculation to be incorrect. I should obviously > have gotten to the bottom of the problem back then, but from memory it > was not crucial to what I was working on at the time and I subsequently > forgot about it. It's good to come back to this now as it should be fixed. It's not accurate but also not totally wrong. >>>> Should we change it to better reflect the conditions on the >>>> channel? >>> >>> Ideally, yes. Feel like having a go and submitting a patch? I can >>> give you some hints on how to do it if you want a concrete starting >>> point. >> >> Sure why not? > > My write up below is partially from memory and from a 2 min look at the > code just now i.e. parts may be incorrect - please use it as a starting > point only... > > So snd_fack effectively acts as a proxy for snd_una while SACK recovery > is happening i.e. it tracks the highest sequence number we've been > cumulatively SACKed for (left edge of the window). snd_fack tracks the highest SEQ# that has been SACKed to us so we don't retransmit beyond it during SACK recovery. > sack_bytes_rexmit counts the number of bytes we've retransmitted from > the known holes during the current recovery episode. Yes, this is to avoid resending already resent data on the next incoming (S)ACK and to find the next available hole to resend. > snd_max is the highest sequence number we've sent (right edge of the > window). Yes. > Another important bit of info is that the sender-side sack scoreboard > stores holes (bytes missing at the receiver), whereas the sack blocks > that come in on the wire refer to received byte ranges (bytes > successfully received at the receiver). Yes. It's important to avoid confusion here. We're talking about sender side SACK (for retransmits we have to send). There's also, but unrelated to this discussion, the SACK blocks we send based on the data we received and is waiting in the reassembly queue. > Therefore from the senders perspective, I believe the "pseudo" > calculation for bytes in flight during a SACK recovery episode should > look something like: > > (snd_max - snd_fack) - total_hole_bytes + sack_bytes_rexmit This isn't accurate either. It likely over-estimates the amount of data still in flight with multiple holes while "(snd_max - snd_fack) + sack_bytes_rexmit" likely under-estimates it in the presence of re-ordering. So instead of total_hole_bytes only those bytes from the holes that are assumed lost should be counted per the hole retransmission rules. It would require some serious work to make our current SACK code track this contiguously. Also for this reason SACK doesn't / shouldn't immediately retransmit any holes but wait for more (S)ACKs to arrive (as specified in the applicable RFCs). I haven't verified that our code does the right thing in all cases. For reference the graphical representation: snd_una snd_max snd_seq .....|ooo#########ooo#######xxx#######***********|..... ^ ^ snd_nxt snd_fack new_inflight <---------> hole_bytes <-> + <-> + <-> sack_rexmit <-> + <-> total_inflt <-> + <-> + <---------> x hole o hole retansmitted # SACKed * new inflight To play devils advocate likely the best approximation compromise we can do at the moment is: inflight = (snd_max - snd_fack) + ((total_hole_bytes - sack_bytes_rexmit) / 2); > 3 of those variables are already around and (hopefully) usable, but I > don't believe we currently track a variable equivalent to total_hole_bytes. Some of them only contain valid information when SACK is active. > Hopefully someone will chime in and correct me if any of the above is > misguided. Otherwise, your challenge, should you choose to accept it, is > to patch SIFTR to perform the above calculation, and to verify that the > reported result is correct - perhaps by running some controlled lab > experiments where you can review the value reported by SIFTR against the > known SACK blocks and sequence numbers on the wire during the recovery > episode. That would be an excellent verification. > You could choose to make total_hole_bytes a sackhint like > sack_bytes_rexmit, but I suggest you create a first version of the patch > which manually walks the sack scoreboard each time through > siftr_siftdata() to sum the # bytes in each hole to ensure you don't > inadvertently introduce accounting bugs while developing the patch. > Patch v2 can include total_hole_bytes as a sackhint. Agreed. There's a limit on the number of SACK holes so in certain situations it may not be able to accurately reflect all available information. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue May 7 18:13:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EFA4D8FF for ; Tue, 7 May 2013 18:13:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 8D382984 for ; Tue, 7 May 2013 18:13:52 +0000 (UTC) Received: from [82.113.99.104] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UZmOc-0005Hj-5L for freebsd-net@freebsd.org; Tue, 07 May 2013 20:13:50 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id r47IDl1r001000 for ; Tue, 7 May 2013 20:13:48 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id r47IDlOl000999 for freebsd-net@freebsd.org; Tue, 7 May 2013 20:13:47 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 7 May 2013 20:13:47 +0200 From: Matthias Apitz To: freebsd-net@freebsd.org Subject: ppp(8) and inbound IP connections Message-ID: <20130507181345.GA992@tiny.Sisis.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.99.104 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:13:53 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I'm using ppp(8) for many years to connect via UMTS to my service provider and Internet, actually www.fonic.de; all this works fine already for long time, works fine for outgoing TCP and UDP connections to Internet. Until now, I did not care about incoming TCP connections, for example for SSH'ing from remote to my netbook, connected via ppp(8), or for incoming SIP; it turns out now,, that I can: - check with "lynx -dump myip.nl | fgrep WAN" with which addr I show up in Internet: $ lynx -dump myip.nl | fgrep WAN WAN IP adres: 82.113.99.104 - can SSH fine to some remote server, - but can not SSH back to the addr 82.113.99.104; I contacted the provider thinking that he is blocking all IP connects which have not been originated by a SYN pkg from my side; but he claims not blocking anything; and now? how can I debug this? My interface looks like this: tun6: flags=8051 metric 0 mtu 1500 options=80000 inet 10.33.28.104 --> 10.64.64.64 netmask 0xffffffff nd6 options=21 Opened by PID 799 and the routing is: Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.64.64.64 UGS 0 1694 tun6 10.33.28.104 link#7 UHS 0 0 lo0 10.64.64.64 link#7 UHS 0 1 tun6 127.0.0.1 link#6 UH 0 75 lo0 Any ideas about this? Thanks. I'm attaching the ppp.conf file. matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: guru@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ppp.conf" # # $Id: ppp.conf,v 1.1 2011/11/20 06:07:03 guru Exp $ # # based on hint: # http://groups.google.com/group/lucky.freebsd.usb/msg/2b88fb344c6932fe # # Fonic values now tested # PIN: xxxx # APN (AT+CGDCONT value): pinternet.interkom.de # # default: set log Phase Chat LCP IPCP CCP tun command umts: set device /dev/cuaU0.0 # device name in CURRENT set speed 921600 # set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK ATZ OK \ AT+CFUN=1 OK \ AT+COPS=0 OK \ AT+CGDCONT=1,\\\"IP\\\",\\\"pinternet.interkom.de\\\" OK \ \\dATDT\\T TIMEOUT 40 CONNECT" set logout "ABORT BUSY ABORT ERROR TIMEOUT 30 \"\" +++ATH O ATH OK" # NAT (not used by me) # nat enable yes # alias enable yes # nat port tcp 192.168.0.0:ftp ftp # nat port tcp 192.168.0.0:http http nat enable yes nat port udp 127.0.0.1:1024-1030 1024-1030 nat port tcp 127.0.0.1:22 22 set phone *99*1\# set authname "fonic" set authkey "fonic" set timeout 300 # set ifaddr 10.64.64.64/0 10.64.64.64/0 255.255.255.255 0.0.0.0 # add default HISADDR # Add a (sticky) default route enable dns disable ipv6cp --cWoXeonUoKmBZSoM-- From owner-freebsd-net@FreeBSD.ORG Tue May 7 18:43:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0422DED1 for ; Tue, 7 May 2013 18:43:59 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id C50F4AE1 for ; Tue, 7 May 2013 18:43:58 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 3b4qTf6K9yzYx; Tue, 7 May 2013 19:43:50 +0100 (BST) Message-ID: <51894B52.2050903@rewt.org.uk> Date: Tue, 07 May 2013 19:43:30 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Matthias Apitz Subject: Re: ppp(8) and inbound IP connections References: <20130507181345.GA992@tiny.Sisis.de> In-Reply-To: <20130507181345.GA992@tiny.Sisis.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 07 May 2013 18:43:59 -0000 Matthias Apitz wrote: > > Hello, > > I'm using ppp(8) for many years to connect via UMTS to my service provider > and Internet, actually www.fonic.de; all this works fine already for long > time, works fine for outgoing TCP and UDP connections to Internet. > > Until now, I did not care about incoming TCP connections, for example for > SSH'ing from remote to my netbook, connected via ppp(8), or for incoming > SIP; it turns out now,, that I can: > > - check with "lynx -dump myip.nl | fgrep WAN" with which addr I show > up in Internet: > > $ lynx -dump myip.nl | fgrep WAN > WAN IP adres: 82.113.99.104 > > - can SSH fine to some remote server, > > - but can not SSH back to the addr 82.113.99.104; > > I contacted the provider thinking that he is blocking all IP connects which > have not been originated by a SYN pkg from my side; but he claims not > blocking anything; and now? how can I debug this? > > My interface looks like this: > > > tun6: flags=8051 metric 0 mtu 1500 > options=80000 > inet 10.33.28.104 --> 10.64.64.64 netmask 0xffffffff > nd6 options=21 > Opened by PID 799 > > and the routing is: > > > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 10.64.64.64 UGS 0 1694 tun6 > 10.33.28.104 link#7 UHS 0 0 lo0 > 10.64.64.64 link#7 UHS 0 1 tun6 > 127.0.0.1 link#6 UH 0 75 lo0 > > Any ideas about this? Thanks. > > I'm attaching the ppp.conf file. > > matthias > It seems quite clear from your ifconfig output that your provider doesn't give you a routable address, so you will never see inbound connections. Usually providers have an alternate APN that will give you one, but that depends on the provider in question. From owner-freebsd-net@FreeBSD.ORG Tue May 7 18:56:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99B1A30F for ; Tue, 7 May 2013 18:56:30 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id 39ADBB5A for ; Tue, 7 May 2013 18:56:30 +0000 (UTC) Received: from [82.113.99.104] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UZn3s-0003Hl-P3; Tue, 07 May 2013 20:56:29 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id r47IuQW2001144; Tue, 7 May 2013 20:56:26 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id r47IuOIk001143; Tue, 7 May 2013 20:56:24 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 7 May 2013 20:56:24 +0200 From: Matthias Apitz To: Joe Holden Subject: Re: ppp(8) and inbound IP connections Message-ID: <20130507185623.GA1115@tiny.Sisis.de> References: <20130507181345.GA992@tiny.Sisis.de> <51894B52.2050903@rewt.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51894B52.2050903@rewt.org.uk> X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.99.104 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:56:30 -0000 El día Tuesday, May 07, 2013 a las 07:43:30PM +0100, Joe Holden escribió: > > tun6: flags=8051 metric 0 mtu 1500 > > options=80000 > > inet 10.33.28.104 --> 10.64.64.64 netmask 0xffffffff > > nd6 options=21 > > Opened by PID 799 > > > > and the routing is: > > > > > > Routing tables > > > > Internet: > > Destination Gateway Flags Refs Use Netif Expire > > default 10.64.64.64 UGS 0 1694 tun6 > > 10.33.28.104 link#7 UHS 0 0 lo0 > > 10.64.64.64 link#7 UHS 0 1 tun6 > > 127.0.0.1 link#6 UH 0 75 lo0 > > > > Any ideas about this? Thanks. > > > > I'm attaching the ppp.conf file. > > > > matthias > > > It seems quite clear from your ifconfig output that your provider > doesn't give you a routable address, so you will never see inbound > connections. Usually providers have an alternate APN that will give you > one, but that depends on the provider in question. Ofc, the provider must NAT somehow my local addr behind some routable valid IP addr, in our case 82.113.99.104; without this nothing would come back, even when the 1st SYN was from my side; the question is, why they do not manage the NAT table so any SYN to 82.113.99.104 is sent to my ppp link; or if they do send it, and my ppp config is wrong? Thanks for your reply in any case matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: guru@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards From owner-freebsd-net@FreeBSD.ORG Tue May 7 19:17:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F95A947 for ; Tue, 7 May 2013 19:17:36 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by mx1.freebsd.org (Postfix) with ESMTP id 672DFD21 for ; Tue, 7 May 2013 19:17:35 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.87,629,1363150800"; d="scan'208";a="29980985" Message-ID: <5189534D.4020605@vangyzen.net> Date: Tue, 7 May 2013 14:17:33 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: ppp(8) and inbound IP connections References: <20130507181345.GA992@tiny.Sisis.de> <51894B52.2050903@rewt.org.uk> <20130507185623.GA1115@tiny.Sisis.de> In-Reply-To: <20130507185623.GA1115@tiny.Sisis.de> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Joe Holden 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, 07 May 2013 19:17:36 -0000 On 05/07/2013 13:56, Matthias Apitz wrote: > El día Tuesday, May 07, 2013 a las 07:43:30PM +0100, Joe Holden escribió: > >>> tun6: flags=8051 metric 0 mtu 1500 >>> options=80000 >>> inet 10.33.28.104 --> 10.64.64.64 netmask 0xffffffff >>> nd6 options=21 >>> Opened by PID 799 >>> >>> and the routing is: >>> >>> >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif Expire >>> default 10.64.64.64 UGS 0 1694 tun6 >>> 10.33.28.104 link#7 UHS 0 0 lo0 >>> 10.64.64.64 link#7 UHS 0 1 tun6 >>> 127.0.0.1 link#6 UH 0 75 lo0 >>> >>> Any ideas about this? Thanks. >>> >>> I'm attaching the ppp.conf file. >>> >>> matthias >>> >> It seems quite clear from your ifconfig output that your provider >> doesn't give you a routable address, so you will never see inbound >> connections. Usually providers have an alternate APN that will give you >> one, but that depends on the provider in question. > Ofc, the provider must NAT somehow my local addr behind some routable > valid IP addr, in our case 82.113.99.104; without this nothing would > come back, even when the 1st SYN was from my side; the question is, why > they do not manage the NAT table so any SYN to 82.113.99.104 is sent to > my ppp link; > > or if they do send it, and my ppp config is wrong? Most likely, multiple customers' local addresses are NATed to the same routable address, so the router can't know which customer to chose for a new incoming connection. De-NATing of incoming packets for existing sessions is done via per-connection state-tracking, which of course doesn't exist for a new incoming connection. Eric From owner-freebsd-net@FreeBSD.ORG Tue May 7 19:24:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E62CCD5A for ; Tue, 7 May 2013 19:24:41 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms16-1.1blu.de (ms16-1.1blu.de [89.202.0.34]) by mx1.freebsd.org (Postfix) with ESMTP id AB380D8E for ; Tue, 7 May 2013 19:24:41 +0000 (UTC) Received: from [82.113.99.104] (helo=tiny.Sisis.de) by ms16-1.1blu.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1UZnV9-00032P-Oi; Tue, 07 May 2013 21:24:40 +0200 Received: from tiny.Sisis.de (localhost [127.0.0.1]) by tiny.Sisis.de (8.14.5/8.14.3) with ESMTP id r47JOagJ001355; Tue, 7 May 2013 21:24:37 +0200 (CEST) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by tiny.Sisis.de (8.14.5/8.14.3/Submit) id r47JOZIm001354; Tue, 7 May 2013 21:24:35 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: tiny.Sisis.de: guru set sender to guru@unixarea.de using -f Date: Tue, 7 May 2013 21:24:35 +0200 From: Matthias Apitz To: Eric van Gyzen Subject: Re: ppp(8) and inbound IP connections Message-ID: <20130507192433.GA1304@tiny.Sisis.de> References: <20130507181345.GA992@tiny.Sisis.de> <51894B52.2050903@rewt.org.uk> <20130507185623.GA1115@tiny.Sisis.de> <5189534D.4020605@vangyzen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5189534D.4020605@vangyzen.net> X-Operating-System: FreeBSD 10.0-CURRENT r235646 (i386) User-Agent: Mutt/1.5.21 (2010-09-15) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.99.104 Cc: freebsd-net@freebsd.org, Joe Holden X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matthias Apitz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:24:42 -0000 El día Tuesday, May 07, 2013 a las 02:17:33PM -0500, Eric van Gyzen escribió: > > Ofc, the provider must NAT somehow my local addr behind some routable > > valid IP addr, in our case 82.113.99.104; without this nothing would > > come back, even when the 1st SYN was from my side; the question is, why > > they do not manage the NAT table so any SYN to 82.113.99.104 is sent to > > my ppp link; > > > > or if they do send it, and my ppp config is wrong? > > Most likely, multiple customers' local addresses are NATed to the same > routable address, so the router can't know which customer to chose for a > new incoming connection. De-NATing of incoming packets for existing > sessions is done via per-connection state-tracking, which of course > doesn't exist for a new incoming connection. That is my understanding as well, but why they claim that they do support incoming connections? matthias -- Sent from my FreeBSD netbook Matthias Apitz | - No system with backdoors like Apple/Android E-mail: guru@unixarea.de | - Never being an iSlave WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF in E-mail phone: +49-170-4527211 | - Respect for open standards From owner-freebsd-net@FreeBSD.ORG Tue May 7 19:33:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A31BE1E4 for ; Tue, 7 May 2013 19:33:58 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by mx1.freebsd.org (Postfix) with ESMTP id 775C6DF5 for ; Tue, 7 May 2013 19:33:58 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.87,629,1363150800"; d="scan'208";a="27593566" Message-ID: <518956F7.6030508@vangyzen.net> Date: Tue, 7 May 2013 14:33:11 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: ppp(8) and inbound IP connections References: <20130507181345.GA992@tiny.Sisis.de> <51894B52.2050903@rewt.org.uk> <20130507185623.GA1115@tiny.Sisis.de> <5189534D.4020605@vangyzen.net> <20130507192433.GA1304@tiny.Sisis.de> In-Reply-To: <20130507192433.GA1304@tiny.Sisis.de> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Joe Holden 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, 07 May 2013 19:33:58 -0000 On 05/07/2013 14:24, Matthias Apitz wrote: > El día Tuesday, May 07, 2013 a las 02:17:33PM -0500, Eric van Gyzen escribió: > >>> Ofc, the provider must NAT somehow my local addr behind some routable >>> valid IP addr, in our case 82.113.99.104; without this nothing would >>> come back, even when the 1st SYN was from my side; the question is, why >>> they do not manage the NAT table so any SYN to 82.113.99.104 is sent to >>> my ppp link; >>> >>> or if they do send it, and my ppp config is wrong? >> Most likely, multiple customers' local addresses are NATed to the same >> routable address, so the router can't know which customer to chose for a >> new incoming connection. De-NATing of incoming packets for existing >> sessions is done via per-connection state-tracking, which of course >> doesn't exist for a new incoming connection. > That is my understanding as well, but why they claim that they do > support incoming connections? Miscommunication, perhaps? Eric From owner-freebsd-net@FreeBSD.ORG Tue May 7 19:36:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6215D432 for ; Tue, 7 May 2013 19:36:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 312B0E25 for ; Tue, 7 May 2013 19:36:18 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r47JaGPj063185; Tue, 7 May 2013 15:36:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <518957A9.9010700@sentex.net> Date: Tue, 07 May 2013 15:36:09 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Matthias Apitz Subject: Re: ppp(8) and inbound IP connections References: <20130507181345.GA992@tiny.Sisis.de> <51894B52.2050903@rewt.org.uk> <20130507185623.GA1115@tiny.Sisis.de> <5189534D.4020605@vangyzen.net> <20130507192433.GA1304@tiny.Sisis.de> In-Reply-To: <20130507192433.GA1304@tiny.Sisis.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-net@freebsd.org, Joe Holden 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, 07 May 2013 19:36:18 -0000 On 5/7/2013 3:24 PM, Matthias Apitz wrote: > > That is my understanding as well, but why they claim that they do > support incoming connections? As Joe Holden said before, to support incoming connections, you probably need to use a different APN, or pay for that service. The carriers here in Canada do that. It would not be manageable otherwise by the carrier. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue May 7 22:03:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 176F3504; Tue, 7 May 2013 22:03:36 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id C18163F7; Tue, 7 May 2013 22:03:35 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id pb11so1132574veb.5 for ; Tue, 07 May 2013 15:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=kMVgOkBDF1RxgGv+453ErXi8QpYJAkDFND613UQV3Zg=; b=PXSZ2Z4wLhwCm5EdSfaOe0sdwhNdEziIka22j5gCP/SLB+SMVJeZd1vow3Ne3QIhsK jaerWsikGROQE91/B9hHcrdwUcu5rvm+EjU81EbXn8qBnOh9ZFFaHAMliUbEO2ln91i7 Xr0CCFD6gxt5kF6M1kxnxkJBcd9eRilDKo3RQCg6og2xKyTiM91B3T7G7rmb9CnqIWQE dMUQyhMeGnmqyZ3sFcRkWGrb4VeszBEK5fNVz03ii0WRPSFNJ0IHg6RqZYf8l600L+uB bjDnqXbNahYX6XTQmn+RF91B/CU4PX9GNF49cBe4LvvD4z6X3l2VBXhz25qMko9547Le v/gQ== MIME-Version: 1.0 X-Received: by 10.52.21.173 with SMTP id w13mr2190492vde.99.1367964215305; Tue, 07 May 2013 15:03:35 -0700 (PDT) Received: by 10.220.141.72 with HTTP; Tue, 7 May 2013 15:03:35 -0700 (PDT) Date: Tue, 7 May 2013 15:03:35 -0700 Message-ID: Subject: LOR: "taskqueue_drain with the following non-sleepable locks held" with if_em From: Garrett Cooper To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: jfv@FreeBSD.org, haven.hash@isilon.com 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, 07 May 2013 22:03:36 -0000 Saw the following LOR on a CURRENT build as of yesterday with an almost idle machine processing ARP requests: root@wf220:/mnt # taskqueue_drain with the following non-sleepable locks held: exclusive rw lle (lle) r = 0 (0xfffffe001450b410) locked @ /usr/src/sys/netinet/in.c:1484 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff848d4f7690 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff848d4f7740 witness_warn() at witness_warn+0x4a8/frame 0xffffff848d4f7800 taskqueue_drain() at taskqueue_drain+0x3a/frame 0xffffff848d4f7840 set_timeout() at set_timeout+0x4a/frame 0xffffff848d4f7860 netevent_callback() at netevent_callback+0x16/frame 0xffffff848d4f7870 arpintr() at arpintr+0x9b5/frame 0xffffff848d4f7930 netisr_dispatch_src() at netisr_dispatch_src+0x60/frame 0xffffff848d4f79a0 ether_demux() at ether_demux+0x130/frame 0xffffff848d4f79d0 ether_nh_input() at ether_nh_input+0x369/frame 0xffffff848d4f7a30 netisr_dispatch_src() at netisr_dispatch_src+0x60/frame 0xffffff848d4f7aa0 em_rxeof() at em_rxeof+0x30e/frame 0xffffff848d4f7b10 em_msix_rx() at em_msix_rx+0x33/frame 0xffffff848d4f7b40 intr_event_execute_handlers() at intr_event_execute_handlers+0x80/frame 0xffffff848d4f7b70 ithread_loop() at ithread_loop+0x128/frame 0xffffff848d4f7bb0 fork_exit() at fork_exit+0x71/frame 0xffffff848d4f7bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848d4f7bf0 --- trap 0, rip = 0, rsp = 0xffffff848d4f7cb0, rbp = 0 --- root@wf220:/mnt # uname -a FreeBSD wf220.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Tue May 7 08:04:59 PDT 2013 root@wf220.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 I've seen this issue before for a few weeks/months, so it's nothing new (but probably should be fixed...). Thanks! -Garrett PS Please CC me as I'm not subscribed to the list. From owner-freebsd-net@FreeBSD.ORG Tue May 7 23:06:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 128CC5B4; Tue, 7 May 2013 23:06:26 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id E38DD80F; Tue, 7 May 2013 23:06:25 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 24F0640C7; Tue, 7 May 2013 16:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1367967985; bh=QzlF/DBYWEfYeVLbePQiHw/3j+Kk31sehS3YdMaCF7Q=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=KIjBsx4Fm6xj2qD5SO5aK++QbE7JiqCc2O3OVzk1EdXduqZfyJp+74K+yr1YRNTaC 6NBBmdDxRaCgBm1sa36I1cl02h1xzWznxK+qpaXb+flh4MCOpa/UQlO8rDOkP13Uz6 FhYuj2ywPf60oveXuNlQszEonkv92lxofcbbU5HY= Message-ID: <518988F0.2080902@delphij.net> Date: Tue, 07 May 2013 16:06:24 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper Subject: Re: LOR: "taskqueue_drain with the following non-sleepable locks held" with if_em References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jfv@FreeBSD.org, freebsd-net@freebsd.org, haven.hash@isilon.com, jeff@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 23:06:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/13 15:03, Garrett Cooper wrote: > Saw the following LOR on a CURRENT build as of yesterday with an > almost idle machine processing ARP requests: > > root@wf220:/mnt # taskqueue_drain with the following non-sleepable > locks held: exclusive rw lle (lle) r = 0 (0xfffffe001450b410) > locked @ /usr/src/sys/netinet/in.c:1484 KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xffffff848d4f7690 kdb_backtrace() at kdb_backtrace+0x39/frame > 0xffffff848d4f7740 witness_warn() at witness_warn+0x4a8/frame > 0xffffff848d4f7800 taskqueue_drain() at taskqueue_drain+0x3a/frame > 0xffffff848d4f7840 set_timeout() at set_timeout+0x4a/frame > 0xffffff848d4f7860 netevent_callback() at > netevent_callback+0x16/frame 0xffffff848d4f7870 arpintr() at > arpintr+0x9b5/frame 0xffffff848d4f7930 netisr_dispatch_src() at > netisr_dispatch_src+0x60/frame 0xffffff848d4f79a0 ether_demux() at > ether_demux+0x130/frame 0xffffff848d4f79d0 ether_nh_input() at > ether_nh_input+0x369/frame 0xffffff848d4f7a30 netisr_dispatch_src() > at netisr_dispatch_src+0x60/frame 0xffffff848d4f7aa0 em_rxeof() at > em_rxeof+0x30e/frame 0xffffff848d4f7b10 em_msix_rx() at > em_msix_rx+0x33/frame 0xffffff848d4f7b40 > intr_event_execute_handlers() at > intr_event_execute_handlers+0x80/frame 0xffffff848d4f7b70 > ithread_loop() at ithread_loop+0x128/frame 0xffffff848d4f7bb0 > fork_exit() at fork_exit+0x71/frame 0xffffff848d4f7bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848d4f7bf0 > --- trap 0, rip = 0, rsp = 0xffffff848d4f7cb0, rbp = 0 --- > root@wf220:/mnt # uname -a FreeBSD wf220.west.isilon.com > 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Tue May 7 08:04:59 PDT 2013 > root@wf220.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 > > I've seen this issue before for a few weeks/months, so it's nothing > new (but probably should be fixed...). Thanks! This have nothing to do with em(4) but looks like a bug in our Linux compatibility wrapper. In the InfiniBand code, its _handle_arp_update_event() calls netevent_callback() with NETEVENT_NEIGH_UPDATE, where a cancel_delayed_work() causes the drain. Looking at the Linux code, it seems that we just shouldn't do the drain in the cancel_delayed_work() wrapper (sys/ofed/include/linux/workqueue.h) so it seems like we need something like this: Index: sys/ofed/include/linux/workqueue.h =================================================================== - --- sys/ofed/include/linux/workqueue.h (revision 250337) +++ sys/ofed/include/linux/workqueue.h (working copy) @@ -184,9 +184,9 @@ { callout_stop(&work->timer); - - if (work->work.taskqueue && - - taskqueue_cancel(work->work.taskqueue, &work->work.work_task, NULL)) - - taskqueue_drain(work->work.taskqueue, &work->work.work_task); + if (work->work.taskqueue) + return (taskqueue_cancel(work->work.taskqueue, + &work->work.work_task, NULL) != 0); return 0; } I've added Jeff to Cc. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRiYjwAAoJEG80Jeu8UPuzOC0H+wbTxVq3nPOuQqZynOLcxHVj L19b1D8opm8hl3AwXfvbOyCbEEenoHJm0FjBd+5eas+9ol1kuRoOyBKVnoZRr2vO 7hcFt/iA7WAQKrZR7ReLUebjLcIymjzDRO6ztZCPMwSzIg1CzypY4KdJhlW438te DvAkzYbgy1YG4C8Uxjg7wR7PR4SY1UgLFYPMeNyvwCCJmSEN/RQB1qrOaJovFks5 C53j713BIHOI0H4G3IhKJd9ujPhVrfQperItlJ4Lg7y0Ix5HlLFdSNRkpzvNrXN4 TN6Xb/atMo1EIiDReqx8Mpus52yUOl3oHXkKzTRZpGM3mW0vLIieajCK0JGBd6c= =tU/S -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Wed May 8 02:49:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2555658; Wed, 8 May 2013 02:49:58 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id BF949ED9; Wed, 8 May 2013 02:49:58 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 4F6411E56DB9; Tue, 7 May 2013 23:49:51 -0300 (ADT) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 21571-07; Wed, 8 May 2013 02:49:51 +0000 (UTC) Received: from Marc-Fourniers-Mac-mini.local (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id A0E861E56DB8; Tue, 7 May 2013 23:49:50 -0300 (ADT) Message-ID: <5189BD4D.70400@hub.org> Date: Tue, 07 May 2013 19:49:49 -0700 From: "Marc G. Fournier" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org, freebsd-net@freebsd.org Subject: Re: VirtualBox + FreeBSD 9-STABLE == Frozen Ethernet References: <1601E2D3-DF60-4CCB-9F92-9AD05BCBCB10@hub.org> <51882568.4080402@informatik.uni-bremen.de> In-Reply-To: <51882568.4080402@informatik.uni-bremen.de> 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, 08 May 2013 02:49:59 -0000 On 2013-05-06 2:49 PM, Norbert Beckmann wrote: > To Marc G. Fournier > > I do not think it's an issue with VirtualBox. I am running VirtualBox > under Solaris. And I never had problems with it. > Guests: ubuntu, Windows 7, Linux Mint, FreeBSD, Chrome OS. > But the people of VirtualBox themselves state that Windows is somewhat > delicate (don't remember whether they meant as guest or as host, I > think both). > Which would be comprehensible, because Windows has never become a real > multi user / multi process system as Unix was by birth (nearly). > I can neither help concerning the freezing Ethernet nor did I encounter > similar things (as far as I remember). My first thought is that its something in the vboxnet kernel module when using a bridge ... I think the problem has been getting progressively worse, with each upgrade, but since I upgrade both vBox and the kernel in tandem, I'm currently working on going 'back in time' with the code, see if I can find some 'stable point' ... If anyone with more knowledge can suggest any commands I can run to provide debug info, or such ... ? I don't mind debugging, just dont' know what to provide that is useful ... From owner-freebsd-net@FreeBSD.ORG Wed May 8 04:55:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6E9F454; Wed, 8 May 2013 04:55:17 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id 780C85F3; Wed, 8 May 2013 04:55:17 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id ib11so1284120vcb.7 for ; Tue, 07 May 2013 21:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HFnt7X928KQdn79Nu6N9dP7YOnGIkudn42KKUEDdTb0=; b=REqN7FPnaQtA68O35ATmtGDg1nR+x1OqanMUOI9Q82KhdZCmZzMBnsXg4ee4ugL0wY 1MqpvjlgrpeQERrXvyejUsyer4eG3t3wdb8fgOBt6XC3y9dfgSpuuudl1rmYbjMwjpKG fodeLgDoVDWC1jOtbTejvswNhBsVagBuOzLvRcDXD79+I2Ez0O9+vXybk043GE87kF4/ Uj2/xuh3hsTvmFe6u4khG9EjHtH+FiIPxLgHZucGYXSC4UJMMlczW5wowbbJJbS/rzQu DiWg3gKO17wuooA09jTKSCeKQCqhSBQ8cwIVlshxQxrIdM9D6Hap98/Tw0tJVDO3YQ9L H/7g== MIME-Version: 1.0 X-Received: by 10.52.176.163 with SMTP id cj3mr2938980vdc.35.1367988916402; Tue, 07 May 2013 21:55:16 -0700 (PDT) Received: by 10.220.141.72 with HTTP; Tue, 7 May 2013 21:55:16 -0700 (PDT) In-Reply-To: <518988F0.2080902@delphij.net> References: <518988F0.2080902@delphij.net> Date: Tue, 7 May 2013 21:55:16 -0700 Message-ID: Subject: Re: LOR: "taskqueue_drain with the following non-sleepable locks held" with if_em From: Garrett Cooper To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 Cc: jfv@freebsd.org, freebsd-net@freebsd.org, Haven Hash , jeff@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, 08 May 2013 04:55:17 -0000 On Tue, May 7, 2013 at 4:06 PM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 05/07/13 15:03, Garrett Cooper wrote: >> Saw the following LOR on a CURRENT build as of yesterday with an >> almost idle machine processing ARP requests: >> >> root@wf220:/mnt # taskqueue_drain with the following non-sleepable >> locks held: exclusive rw lle (lle) r = 0 (0xfffffe001450b410) >> locked @ /usr/src/sys/netinet/in.c:1484 KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xffffff848d4f7690 kdb_backtrace() at kdb_backtrace+0x39/frame >> 0xffffff848d4f7740 witness_warn() at witness_warn+0x4a8/frame >> 0xffffff848d4f7800 taskqueue_drain() at taskqueue_drain+0x3a/frame >> 0xffffff848d4f7840 set_timeout() at set_timeout+0x4a/frame >> 0xffffff848d4f7860 netevent_callback() at >> netevent_callback+0x16/frame 0xffffff848d4f7870 arpintr() at >> arpintr+0x9b5/frame 0xffffff848d4f7930 netisr_dispatch_src() at >> netisr_dispatch_src+0x60/frame 0xffffff848d4f79a0 ether_demux() at >> ether_demux+0x130/frame 0xffffff848d4f79d0 ether_nh_input() at >> ether_nh_input+0x369/frame 0xffffff848d4f7a30 netisr_dispatch_src() >> at netisr_dispatch_src+0x60/frame 0xffffff848d4f7aa0 em_rxeof() at >> em_rxeof+0x30e/frame 0xffffff848d4f7b10 em_msix_rx() at >> em_msix_rx+0x33/frame 0xffffff848d4f7b40 >> intr_event_execute_handlers() at >> intr_event_execute_handlers+0x80/frame 0xffffff848d4f7b70 >> ithread_loop() at ithread_loop+0x128/frame 0xffffff848d4f7bb0 >> fork_exit() at fork_exit+0x71/frame 0xffffff848d4f7bf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff848d4f7bf0 >> --- trap 0, rip = 0, rsp = 0xffffff848d4f7cb0, rbp = 0 --- >> root@wf220:/mnt # uname -a FreeBSD wf220.west.isilon.com >> 10.0-CURRENT FreeBSD 10.0-CURRENT #1: Tue May 7 08:04:59 PDT 2013 >> root@wf220.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC amd64 >> >> I've seen this issue before for a few weeks/months, so it's nothing >> new (but probably should be fixed...). Thanks! > > This have nothing to do with em(4) but looks like a bug in our Linux > compatibility wrapper. In the InfiniBand code, its > _handle_arp_update_event() calls netevent_callback() with > NETEVENT_NEIGH_UPDATE, where a cancel_delayed_work() causes the drain. > > Looking at the Linux code, it seems that we just shouldn't do the > drain in the cancel_delayed_work() wrapper > (sys/ofed/include/linux/workqueue.h) so it seems like we need > something like this: > > Index: sys/ofed/include/linux/workqueue.h > =================================================================== > - --- sys/ofed/include/linux/workqueue.h (revision 250337) > +++ sys/ofed/include/linux/workqueue.h (working copy) > @@ -184,9 +184,9 @@ > { > > callout_stop(&work->timer); > - - if (work->work.taskqueue && > - - taskqueue_cancel(work->work.taskqueue, &work->work.work_task, NULL)) > - - taskqueue_drain(work->work.taskqueue, &work->work.work_task); > + if (work->work.taskqueue) > + return (taskqueue_cancel(work->work.taskqueue, > + &work->work.work_task, NULL) != 0); > return 0; > } > > > > I've added Jeff to Cc. The patch LGTM (I haven't hit the issue after 10 minutes of use; generally it pops up almost immediately after boot or within the first couple of minutes). Thanks a million! -Garrett From owner-freebsd-net@FreeBSD.ORG Wed May 8 06:10:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA802DC7 for ; Wed, 8 May 2013 06:10:28 +0000 (UTC) (envelope-from prvs=1840d66bd5=agave.spring@cadamericas.com) Received: from cadamericas.com (mail02.amotive.com [173.164.153.20]) by mx1.freebsd.org (Postfix) with ESMTP id CE02084A for ; Wed, 8 May 2013 06:10:28 +0000 (UTC) Received: from agave.cadamericas.com ([64.183.139.162]) by amotive.com (mail02.amotive.com) (MDaemon PRO v13.0.2) with ESMTP id md50001943302.msg; Tue, 07 May 2013 23:10:16 -0700 X-Spam-Processed: mail02.amotive.com, Tue, 07 May 2013 23:10:16 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 64.183.139.162 X-Return-Path: prvs=1840d66bd5=agave.spring@cadamericas.com X-Envelope-From: agave.spring@cadamericas.com X-MDaemon-Deliver-To: freebsd-net@freebsd.org Date: Tue, 7 May 2013 23:09:17 -0700 To: freebsd-net From: CAD Americas Subject: AutoCAD and Electrical Evangelists Lynn Allen and Randy Brunette Speak at CAD Americas Message-ID: <62aebc2450fcd396e40c7c1ab6dd9534@agave.cadamericas.com> X-Priority: 3 X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/) X-CampTrackID: 86fd4794-f448-e566-5d1b-5189ec3a856f MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 Reply-To: CAD Americas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 06:10:29 -0000 CAD AMERICAS TECHNICAL SESSSIONS NOW ONLINE: Attend CAD Americas Training D= ays to learn how to optimize your CAD tools=C2=A0=0A=C2=A0=0A=0A=0ADiscover= new productivity techniques that are certain to improve your everyday draw= ing life. Lynn Allen, Autodesk Technical Evangelist, Cadalyst columnist and= author, will walk you through a whirlwind of tips and tricks you can put t= o use immediately.=0A=0ALynn Allen Autodesk Evangelist More=0A=C2=A0=0A=C2= =A0=0A=0A=0AExplore new CAD Management techniques with Robert Green, a well= known author, instructor and consultant. Join the discussions on how to mi= grate from 2D to 3D, automate your CAD environment to reduce keystrokes, be= tter manage your CAD/BIM environment, speed processes, take the drudgery ou= t of the day-to-day CAD usage =E2=80=A6 and much more.=0A=0ARobert Green CA= D Mgmt. Expert More=0A=C2=A0=0A=C2=A0=0A=0A=0ALearn how to build 3D design= models with Steve Schain, an industry luminary, instructor and consultant.= During his sessions, Steve will demonstrate motion simulation, show how to= integrate rapid prototyping into the product design process, and much more= .=0A=0ASteve Schain Mechanical Design Expert More=0A=C2=A0=0A=C2=A0=0A=0A= =0AFind out how to optimize factory layouts using the latest software tools= Tod Stephens, frequent speaker and consultant, will demonstrates how Finit= e Element Analysis minimizes the prototyping phase of product development = =E2=80=A6 and much more.=0A=0ATod Stephens Design Expert More=0A=C2=A0=0ACl= ick here to see more session descriptions.=0ACAD AMERICAS TRAINING DAYS ARR= IVE IN YOUR AREA SOON!=0AJune 4June 6June 7June 12June 13June 26 June 27=0A= Cleveland Cincinnati Detroit Atlanta Dallas San Jose San_Bernardino = =0AREGISTER BY MAY 7th AND SAVERegister for this CAD Americas Training Day = by May 7th and save.=0ABird Rate: $150 (Until May 7th)=0AStandard Rate: $19= 5 (AFTER May 7th)=0AStudent/Faculty Rate: $95 (must present current student= ID upon check-in at registration)=0AREGISTER FOR CAD AMERICAS TRAINING TOD= AY!=0A=0A=0A=0A Join us at=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=C2=A0INTERNATIONAL= SPONSORS=0A=0A=0A =0A=0AEDUCATION SPONSOR=0A=0A=0AMEDIA SPONSORS=0A=0A=C2= =A0=0AThis email was sent to email address: here to Opt-Out=0A From owner-freebsd-net@FreeBSD.ORG Wed May 8 10:16:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BDBAF0E for ; Wed, 8 May 2013 10:16:04 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from ca2.route.mx (ca2.route.mx [72.55.175.69]) by mx1.freebsd.org (Postfix) with ESMTP id E4AF3329 for ; Wed, 8 May 2013 10:16:03 +0000 (UTC) Received: (route-mx 8260 invoked from network); 8 May 2013 10:09:21 -0000 Received: from unknown (HELO nbari-z200.diz.la) (nbari@inbox.im@route.mx) (envelope-sender ) by ca2.route.mx (route-mx) with CAMELLIA256-SHA encrypted SMTP for ; 8 May 2013 10:09:21 -0000 Message-ID: <518A244C.3010601@inbox.im> Date: Wed, 08 May 2013 11:09:16 +0100 From: Nicolas de Bari Embriz Garcia Rojas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Marc G. Fournier" Subject: Re: VirtualBox + FreeBSD 9-STABLE == Frozen Ethernet References: <1601E2D3-DF60-4CCB-9F92-9AD05BCBCB10@hub.org> <51882568.4080402@informatik.uni-bremen.de> <5189BD4D.70400@hub.org> In-Reply-To: <5189BD4D.70400@hub.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-virtualization@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, 08 May 2013 10:16:04 -0000 When using bridge mode, use tap interfaces otherwise you will get problems when using more than one VM. regards On 05/08/2013 03:49, Marc G. Fournier wrote: > On 2013-05-06 2:49 PM, Norbert Beckmann wrote: >> To Marc G. Fournier >> >> I do not think it's an issue with VirtualBox. I am running VirtualBox >> under Solaris. And I never had problems with it. >> Guests: ubuntu, Windows 7, Linux Mint, FreeBSD, Chrome OS. >> But the people of VirtualBox themselves state that Windows is somewhat >> delicate (don't remember whether they meant as guest or as host, I >> think both). >> Which would be comprehensible, because Windows has never become a real >> multi user / multi process system as Unix was by birth (nearly). >> I can neither help concerning the freezing Ethernet nor did I encounter >> similar things (as far as I remember). > My first thought is that its something in the vboxnet kernel module > when using a bridge ... I think the problem has been getting > progressively worse, with each upgrade, but since I upgrade both vBox > and the kernel in tandem, I'm currently working on going 'back in > time' with the code, see if I can find some 'stable point' ... > > If anyone with more knowledge can suggest any commands I can run to > provide debug info, or such ... ? I don't mind debugging, just dont' > know what to provide that is useful ... > > > _______________________________________________ > 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 May 8 14:40:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6D59739 for ; Wed, 8 May 2013 14:40:01 +0000 (UTC) (envelope-from gnats@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 B845929D for ; Wed, 8 May 2013 14:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r48Ee18l008659 for ; Wed, 8 May 2013 14:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r48Ee1TT008658; Wed, 8 May 2013 14:40:01 GMT (envelope-from gnats) Date: Wed, 8 May 2013 14:40:01 GMT Message-Id: <201305081440.r48Ee1TT008658@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Nate Denning Subject: Re: kern/178116: [tcp] [panic] Kernel panic: general protection fault in tcp_do_segment X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Nate Denning List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 14:40:01 -0000 The following reply was made to PR kern/178116; it has been noted by GNATS. From: Nate Denning To: Gleb Smirnoff Cc: bug-followup@FreeBSD.org Subject: Re: kern/178116: [tcp] [panic] Kernel panic: general protection fault in tcp_do_segment Date: Wed, 8 May 2013 08:30:01 -0600 On May 1, 2013, at 9:32 AM, Nate Denning wrote: >=20 > On May 1, 2013, at 9:27 AM, Gleb Smirnoff wrote: >=20 >> Nate, >>=20 >> On Wed, May 01, 2013 at 09:26:04AM -0600, Nate Denning wrote: >> N> > do you run any additional network modules: ipfw, pf, netgraph, >> N> > accept filters, etc? How your system differes from a default >> N> > installation? >> N>=20 >> N> Yes, ipfilter, accf_http and accf_data (accf is for Apache). No = ipfw, pf, or netgraph. Output of kldstat: >>=20 >> I would suspect ipfilter. :( >>=20 >> Is it possible for you to rewrite your rules to ipfw or pf and try >> running with that? >>=20 >=20 > Certainly, I'll switch to pf and see how that goes. I switched to pf and I'm at about a week now with no panics where there = were typically several per day with ipfilter. I need this host to be = stable so I would like to stick to pf, but is there any more info, = configs, etc. I can provide to help debug the ipfilter issue? Thanks, Nate= From owner-freebsd-net@FreeBSD.ORG Wed May 8 15:21:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA198C95 for ; Wed, 8 May 2013 15:21:07 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 95F4F7AF for ; Wed, 8 May 2013 15:21:07 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 5914670B0 for ; Wed, 8 May 2013 17:21:04 +0200 (CEST) Message-ID: <518A6D5C.3030804@peterschmitt.fr> Date: Wed, 08 May 2013 17:21:00 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPv6 configuration missunderstanding X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2HFROWTRHUGJVOTKXNWNW" 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, 08 May 2013 15:21:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HFROWTRHUGJVOTKXNWNW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I want to configure IPv6 in FreeBSD 9.1-RELEASE like this : ipv6_enable=3Dyes ipv6_activate_all_interfaces=3Dyes ifconfig_em0_ipv6=3D"inet6 2001:41D0:8:B81f:: prefixlen 64" -interface em0" ipv6_defaultrouter=3D"2001:41D0:8:B8ff:ff:ff:ff:ff" But at boot I have : default fe80::264:40ff:fe3a:fac0%em0 UG em0 Strange because fe80 in link local=85 And if ipv6_enable=3Dyes is not here (although it's depreciated), no IPv6= at all. Dont really understand what to do. --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2HFROWTRHUGJVOTKXNWNW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRim1fAAoJEMtO2Sol0IImj60H/3SU84deOA3D19BqqwiKWTX4 nE8i0L8sakwCjpD8c75/z9TqSNfORzEuYCCgAqGdeN7BXlBA/YQVZem9y7b9KVSn RCudphj+x+Or/0n5aGDYHE7QKD1hsIi4VJJ8yoEZiTOznHIqy/71AKhvOABJLbBD FZJl2dD2yRbattUrQnmhcocP1dWMqjGhNVnoKy/uF2bo9EsycWUeFuUxmdQrdzLa Z0NN404kqAoe5lGDdyJhMneaplMwZRATQT7A9brL1hoBy3OYdiNBhLAhBcL5gXIk hpFzISOmuHcY9VyJF3pWc5WqXeVhvEl6m56VJczLn+QPkFF58v9GwElkyzNvxB8= =gpuX -----END PGP SIGNATURE----- ------enig2HFROWTRHUGJVOTKXNWNW-- From owner-freebsd-net@FreeBSD.ORG Wed May 8 15:54:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5381EAF0 for ; Wed, 8 May 2013 15:54:57 +0000 (UTC) (envelope-from chip@2bithacker.net) Received: from mail.2bithacker.net (mail.2bithacker.net [IPv6:2001:470:1f07:202::123]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA81A43 for ; Wed, 8 May 2013 15:54:57 +0000 (UTC) Received: from 2bithacker.net (nat-04-mht.dyndns.com [216.146.45.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chip) by mail.2bithacker.net (Postfix) with ESMTPSA id 04CEA51A18 for ; Wed, 8 May 2013 11:54:49 -0400 (EDT) Date: Wed, 8 May 2013 11:54:46 -0400 From: Chip Marshall To: freebsd-net@freebsd.org Subject: gre and MONITOR Message-ID: <20130508155446.GB95890@2bithacker.net> Mail-Followup-To: chip@2bithacker.net, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5" Content-Disposition: inline X-OS: Mac OS X 10.8.3 x86_64 up 21 days User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: chip@2bithacker.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:54:57 -0000 --s/l3CgOIzMHHjg/5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It appears the MONITOR flag doesn't work on gre interfaces. I have a GRE tunnel set up between a FreeBSD 8.2-RELEASE box and a Juniper router. Config on the FreeBSD end: gre0: flags=3D4b051 m= etric 0 mtu 1476 tunnel inet 10.162.163.133 --> 10.162.163.131 inet6 fe80::20c:29ff:fe9f:de64%gre0 prefixlen 64 scopeid 0x6 inet 10.200.0.2 --> 10.200.0.1 netmask 0xfffffffc nd6 options=3D3 Config on the Juniper end: tunnel { source 10.162.163.131; destination 10.162.163.133; } family inet { address 10.200.0.1/30; } And from the Juniper, I am able to ping the 10.200.0.2 IP on the FreeBSD end of the GRE tunnel. As I understand it, this shouldn't happen with the MONITOR flag there, right? > ping 10.200.0.2 rapid PING 10.200.0.2 (10.200.0.2): 56 data bytes !!!!! --- 10.200.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev =3D 0.265/0.297/0.382/0.043 ms --=20 Chip Marshall http://2bithacker.net/ --s/l3CgOIzMHHjg/5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) iEYEARECAAYFAlGKdUYACgkQnTUxIUPEgZ4QVQCeKmEMa2iS51nXkp52PARuiCtq SJUAn0dpF6yVrTSh+dJd6oAtO8ulgT+O =3HX7 -----END PGP SIGNATURE----- --s/l3CgOIzMHHjg/5-- From owner-freebsd-net@FreeBSD.ORG Wed May 8 16:32:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53B3126F; Wed, 8 May 2013 16:32:20 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 20E5FE06; Wed, 8 May 2013 16:32:20 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id 6929F4FFC2B; Wed, 8 May 2013 13:32:18 -0300 (ADT) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 86850-04; Wed, 8 May 2013 16:32:18 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id C78F84FFC2A; Wed, 8 May 2013 13:32:16 -0300 (ADT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: VirtualBox + FreeBSD 9-STABLE == Frozen Ethernet From: "Marc G. Fournier" In-Reply-To: <518A244C.3010601@inbox.im> Date: Wed, 8 May 2013 09:32:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1601E2D3-DF60-4CCB-9F92-9AD05BCBCB10@hub.org> <51882568.4080402@informatik.uni-bremen.de> <5189BD4D.70400@hub.org> <518A244C.3010601@inbox.im> To: Nicolas de Bari Embriz Garcia Rojas X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org, freebsd-virtualization@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, 08 May 2013 16:32:20 -0000 Do you happen to know of a HowTO for doing this? =20 figure there are a few extra steps then simply: ifconfig tapX plumb --bridgeadapter tapX Thx .. On 2013-05-08, at 03:09 , Nicolas de Bari Embriz Garcia Rojas = wrote: > When using bridge mode, use tap interfaces otherwise you will get > problems when using more than one VM. >=20 > regards >=20 > On 05/08/2013 03:49, Marc G. Fournier wrote: >> On 2013-05-06 2:49 PM, Norbert Beckmann wrote: >>> To Marc G. Fournier >>>=20 >>> I do not think it's an issue with VirtualBox. I am running = VirtualBox >>> under Solaris. And I never had problems with it. >>> Guests: ubuntu, Windows 7, Linux Mint, FreeBSD, Chrome OS. >>> But the people of VirtualBox themselves state that Windows is = somewhat >>> delicate (don't remember whether they meant as guest or as host, I >>> think both). >>> Which would be comprehensible, because Windows has never become a = real >>> multi user / multi process system as Unix was by birth (nearly). >>> I can neither help concerning the freezing Ethernet nor did I = encounter >>> similar things (as far as I remember). >> My first thought is that its something in the vboxnet kernel module >> when using a bridge ... I think the problem has been getting >> progressively worse, with each upgrade, but since I upgrade both vBox >> and the kernel in tandem, I'm currently working on going 'back in >> time' with the code, see if I can find some 'stable point' ... >>=20 >> If anyone with more knowledge can suggest any commands I can run to >> provide debug info, or such ... ? I don't mind debugging, just dont' >> know what to provide that is useful ... >>=20 >>=20 >> _______________________________________________ >> 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 From owner-freebsd-net@FreeBSD.ORG Wed May 8 17:47:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C4118917; Wed, 8 May 2013 17:47:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id AC9A018C; Wed, 8 May 2013 17:47:06 +0000 (UTC) Received: from zeta.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 4583A11846; Wed, 8 May 2013 10:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1368035220; bh=2LN/w7y1r510UbPD4w1rG43zhEeFVunR/jQxC6JgQuk=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=rqb5R3NiqPXLQZODqPpnTbYLwQ2ZY6hNLK3z2eonFHW+4zJ4LJRSMZjT17eO6aOTK hLB0j9JXBI3tb24BiWjAjwTk2aNAGrUynWDe99l9PEvopV7+vb/jF0mjYjDieTmk4i n8LM4wIw8j0EF5SdkFSyKpJCwlZ/pn1WyOsXOwYE= Message-ID: <518A8F92.30100@delphij.net> Date: Wed, 08 May 2013 10:46:58 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Garrett Cooper Subject: Re: LOR: "taskqueue_drain with the following non-sleepable locks held" with if_em References: <518988F0.2080902@delphij.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jfv@freebsd.org, freebsd-net@freebsd.org, Haven Hash , Xin LI , jeff@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 17:47:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/13 21:55, Garrett Cooper wrote: > On Tue, May 7, 2013 at 4:06 PM, Xin Li > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 05/07/13 15:03, Garrett Cooper wrote: >>> Saw the following LOR on a CURRENT build as of yesterday with >>> an almost idle machine processing ARP requests: >>> >>> root@wf220:/mnt # taskqueue_drain with the following >>> non-sleepable locks held: exclusive rw lle (lle) r = 0 >>> (0xfffffe001450b410) locked @ /usr/src/sys/netinet/in.c:1484 >>> KDB: stack backtrace: db_trace_self_wrapper() at >>> db_trace_self_wrapper+0x2b/frame 0xffffff848d4f7690 >>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff848d4f7740 >>> witness_warn() at witness_warn+0x4a8/frame 0xffffff848d4f7800 >>> taskqueue_drain() at taskqueue_drain+0x3a/frame >>> 0xffffff848d4f7840 set_timeout() at set_timeout+0x4a/frame >>> 0xffffff848d4f7860 netevent_callback() at >>> netevent_callback+0x16/frame 0xffffff848d4f7870 arpintr() at >>> arpintr+0x9b5/frame 0xffffff848d4f7930 netisr_dispatch_src() >>> at netisr_dispatch_src+0x60/frame 0xffffff848d4f79a0 >>> ether_demux() at ether_demux+0x130/frame 0xffffff848d4f79d0 >>> ether_nh_input() at ether_nh_input+0x369/frame >>> 0xffffff848d4f7a30 netisr_dispatch_src() at >>> netisr_dispatch_src+0x60/frame 0xffffff848d4f7aa0 em_rxeof() >>> at em_rxeof+0x30e/frame 0xffffff848d4f7b10 em_msix_rx() at >>> em_msix_rx+0x33/frame 0xffffff848d4f7b40 >>> intr_event_execute_handlers() at >>> intr_event_execute_handlers+0x80/frame 0xffffff848d4f7b70 >>> ithread_loop() at ithread_loop+0x128/frame 0xffffff848d4f7bb0 >>> fork_exit() at fork_exit+0x71/frame 0xffffff848d4f7bf0 >>> fork_trampoline() at fork_trampoline+0xe/frame >>> 0xffffff848d4f7bf0 --- trap 0, rip = 0, rsp = >>> 0xffffff848d4f7cb0, rbp = 0 --- root@wf220:/mnt # uname -a >>> FreeBSD wf220.west.isilon.com 10.0-CURRENT FreeBSD 10.0-CURRENT >>> #1: Tue May 7 08:04:59 PDT 2013 >>> root@wf220.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC >>> amd64 >>> >>> I've seen this issue before for a few weeks/months, so it's >>> nothing new (but probably should be fixed...). Thanks! >> >> This have nothing to do with em(4) but looks like a bug in our >> Linux compatibility wrapper. In the InfiniBand code, its >> _handle_arp_update_event() calls netevent_callback() with >> NETEVENT_NEIGH_UPDATE, where a cancel_delayed_work() causes the >> drain. >> >> Looking at the Linux code, it seems that we just shouldn't do >> the drain in the cancel_delayed_work() wrapper >> (sys/ofed/include/linux/workqueue.h) so it seems like we need >> something like this: >> >> Index: sys/ofed/include/linux/workqueue.h >> =================================================================== >> >> - - --- sys/ofed/include/linux/workqueue.h (revision 250337) >> +++ sys/ofed/include/linux/workqueue.h (working copy) @@ -184,9 >> +184,9 @@ { >> >> callout_stop(&work->timer); - - if (work->work.taskqueue && - >> - taskqueue_cancel(work->work.taskqueue, >> &work->work.work_task, NULL)) - - >> taskqueue_drain(work->work.taskqueue, &work->work.work_task); + >> if (work->work.taskqueue) + return >> (taskqueue_cancel(work->work.taskqueue, + >> &work->work.work_task, NULL) != 0); return 0; } >> >> >> >> I've added Jeff to Cc. > > The patch LGTM (I haven't hit the issue after 10 minutes of use; > generally it pops up almost immediately after boot or within the > first couple of minutes). Committed as r250374. (The return value is inverted in this version and I committed what I believed was correct, based on my reading of Linux documentation. The return value does not affect your test result though, as it's discarded anyway.) Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJRio+SAAoJEG80Jeu8UPuzvCUH+QHAXi3UCqyoBfUsNTkHofmB riKFONZem5QsR425tg1qPcYwpgcQKAaZpu6a5ILsWZ2IPliN3QysrXFDmkVsL53/ yYK4Pcpa9TA11EjyHj3Bt1hnUqRldz5Olwhpb+RExAWaBZ0Nczf26H2GDOZvEXB4 99OXYje7bR1mbZOUoPkVcDqr4Mh0EZDHct5SxQv3eMagble5iaEiVkvunS0/P3nk njpFbODbfMM9qs3QVxvukp3rA9M7E5cbyhl0WNDHs5h192kvy+rh5C4w3LYi+Vx9 Wlpjy9t1kxA8bLi2d0fyLqsigo2Yz6BHAwB9zs9nQ02Mg3wOPsBIIkr4y1DFiOY= =uH91 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu May 9 01:51:50 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84804261 for ; Thu, 9 May 2013 01:51:50 +0000 (UTC) (envelope-from nourimane21@gmail.com) Received: from mail-we0-x243.google.com (mail-we0-x243.google.com [IPv6:2a00:1450:400c:c03::243]) by mx1.freebsd.org (Postfix) with ESMTP id 14C6214F5 for ; Thu, 9 May 2013 01:51:49 +0000 (UTC) Received: by mail-we0-f195.google.com with SMTP id q59so640882wes.6 for ; Wed, 08 May 2013 18:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=yD1a23sNbgjzctgrMULltf8KWiKUWMsYx5mv2kTlF+M=; b=gwOXykPH6rtQre6UeYYtDTSfFOw4nUu9dPjJiuZK1fyk3RNz+2Wbyf+hTXYvP/WrgP tuEyHdZugLNBSHFzEWgV57382eWVCKTqZ1TPzTTuYu2DRV3D9lTqV+T+uAxGv7WHwUTp 1HOQREcfmYahywEWc6ZGLgUgkOLc2mm3GFOoE+KF9OhKJ96BwVq1lU0vnrLTfCBJn1tO 8S9L1IorMswiSqBQQdfGKbC2q4siDj/RPU5YLbEm3EXwC/DpvkAy6I2Utw0TVXOrdQqS fZipAKjsuCZTTXtD2NUDR+gBfrpq87QKf8Yc+X9Pz2co6Bi7iE/3GVO3Ti+X9pBXX2vZ bMew== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr13957055wic.32.1368064308221; Wed, 08 May 2013 18:51:48 -0700 (PDT) Received: by 10.227.0.80 with HTTP; Wed, 8 May 2013 18:51:48 -0700 (PDT) Date: Thu, 9 May 2013 01:51:48 +0000 Message-ID: Subject: mipv6 From: Ouyahia Nourimane To: 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: Thu, 09 May 2013 01:51:50 -0000 hello, i'm a student i have a project about mipv6 and i wish that you can help me i want to test mipv6 with freebsd but i didn't realize how to configure kame which is the last version that support kame and can you give me iso image of this version with kame ... i'm waiting your answer thanks From owner-freebsd-net@FreeBSD.ORG Thu May 9 08:34:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3C82ADC for ; Thu, 9 May 2013 08:34:40 +0000 (UTC) (envelope-from jason@b0rken.org) Received: from mail.b0rken.org (beastie.b0rken.org [IPv6:2001:470:1f09:84f::1fc1:84c7]) by mx1.freebsd.org (Postfix) with ESMTP id 95CDF8DD for ; Thu, 9 May 2013 08:34:40 +0000 (UTC) Received: from [192.168.0.64] (188-223-32-209.zone14.bethere.co.uk [188.223.32.209]) by mail.b0rken.org (Postfix) with ESMTPSA id 2111212478 for ; Thu, 9 May 2013 09:34:38 +0100 (BST) Message-ID: <518B5F51.8020804@b0rken.org> Date: Thu, 09 May 2013 09:33:21 +0100 From: Jason Mann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: IPv6 tunnel MTU of 1480 not effective 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: Thu, 09 May 2013 08:34:40 -0000 Hello list, I have a dedicated server running FreeBSD 9.1-RELEASE hosted with an IPv4-only hosting company and have set up a Hurricane Electric IPv6 tunnel to it. It's mostly working fine. However I'm only able to send IPv6 packets from my host that fit an MTU of 1280 even though I've set the tunnel interface and per-route MTU to 1480, based on the "outer" ethernet connection having an MTU of 1500. Hurricane Electric supports this and I've set the MTU to 1480 on their side as well. This issue is evident when I try to send IPv6 pings larger than 1280 bytes to the remote tunnel peer. The outgoing echo request is chopped into two fragments, while the response comes back in one fragment, as follows: % ping6 -c 1 -s 1432 2001:470:1f08:84f::1 PING6(1480=40+8+1432 bytes) 2001:470:1f09:84f::2 --> 2001:470:1f08:84f::1 1440 bytes from 2001:470:1f08:84f::1, icmp_seq=0 hlim=64 time=1.514 ms --- 2001:470:1f08:84f::1 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.514/1.514/1.514/0.000 ms The corresponding tcpdump output: 09:10:30.368328 IP6 2001:470:1f09:84f::2 > 2001:470:1f08:84f::1: frag (0|1232) ICMP6, echo request, seq 0, length 1232 09:10:30.368337 IP6 2001:470:1f09:84f::2 > 2001:470:1f08:84f::1: frag (1232|208) 09:10:30.369740 IP6 2001:470:1f08:84f::1 > 2001:470:1f09:84f::2: ICMP6, echo reply, seq 0, length 1440 Here's my config: % ifconfig gif0 gif0: flags=8151 metric 0 mtu 1480 tunnel inet --> 216.66.80.26 inet6 fe80::be30:5bff:feda:b396%gif0 prefixlen 64 scopeid 0x6 inet6 2001:470:1f08:84f::2 --> 2001:470:1f08:84f::1 prefixlen 128 nd6 options=21 options=1 % route -n get -inet6 default route to: :: destination: :: mask: default gateway: 2001:470:1f08:84f::1 interface: gif0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1480 1 0 Can anyone advise on what I may have done wrong or misunderstood here? I realise that an MTU of 1280 is the minimum supported by IPv6, but I don't see why I shouldn't be able to increase the MTU as high as the outer transport will support to improve efficiency. Thanks, JM From owner-freebsd-net@FreeBSD.ORG Thu May 9 09:13:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0449703 for ; Thu, 9 May 2013 09:13:14 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 17FDAA9F for ; Thu, 9 May 2013 09:13:13 +0000 (UTC) Received: (qmail 39309 invoked from network); 9 May 2013 09:06:31 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 May 2013 09:06:31 -0000 Date: Thu, 09 May 2013 11:06:31 +0200 (CEST) Message-Id: <20130509.110631.74720486.sthaug@nethelp.no> To: jason@b0rken.org Subject: Re: IPv6 tunnel MTU of 1480 not effective From: sthaug@nethelp.no In-Reply-To: <518B5F51.8020804@b0rken.org> References: <518B5F51.8020804@b0rken.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Thu, 09 May 2013 09:13:14 -0000 > However I'm only able to send IPv6 packets from my host that fit an MTU > of 1280 even though I've set the tunnel interface and per-route MTU to > 1480, based on the "outer" ethernet connection having an MTU of 1500. > Hurricane Electric supports this and I've set the MTU to 1480 on their > side as well. > > This issue is evident when I try to send IPv6 pings larger than 1280 > bytes to the remote tunnel peer. The outgoing echo request is chopped > into two fragments, while the response comes back in one fragment, as > follows: > > % ping6 -c 1 -s 1432 2001:470:1f08:84f::1 > PING6(1480=40+8+1432 bytes) 2001:470:1f09:84f::2 --> 2001:470:1f08:84f::1 > 1440 bytes from 2001:470:1f08:84f::1, icmp_seq=0 hlim=64 time=1.514 ms This is a "feature" (i.e. it's documented). See the ping6 -m option: -m By default, ping6 asks the kernel to fragment packets to fit into the minimum IPv6 MTU. The -m option will suppress the behavior in the following two levels: when the option is specified once, the behavior will be disabled for unicast packets. When the option is more than once, it will be disabled for both unicast and multicast packets. In my opinion this behavior badly breaks POLA, and should be removed (i.e. the current -m behavior should be the default). I have no great hope in getting this changed, though... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu May 9 10:23:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 181E05D4 for ; Thu, 9 May 2013 10:23:48 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id D695CDC9 for ; Thu, 9 May 2013 10:23:47 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 3555F7249 for ; Thu, 9 May 2013 12:23:45 +0200 (CEST) Message-ID: <518B792C.1020704@peterschmitt.fr> Date: Thu, 09 May 2013 12:23:40 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: mipv6 References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ADDOGHKKQDIGFONFTVXK" 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, 09 May 2013 10:23:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ADDOGHKKQDIGFONFTVXK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 09/05/2013 03:51, Ouyahia Nourimane a =E9crit : > hello, i'm a student > i have a project about mipv6 and i wish that you can help me > i want to test mipv6 with freebsd but i didn't realize how to configure= > kame > which is the last version that support kame and can you give me iso ima= ge > of this version with kame ... > i'm waiting your answer > thanks > _______________________________________________ > 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 Hi, FreeBSD has already the IPv6 stack so there is no special version to take= =2E See: http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt http://forums.freebsd.org/showthread.php?t=3D10077 https://ipv6.u-strasbg.fr/doku.php?id=3Dkame (french) What I see is that it should work without bringing any patch since there is no newer version for current versions of FreeBSD. --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2ADDOGHKKQDIGFONFTVXK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRi3kvAAoJEMtO2Sol0IImOPcIAIOUcbX4W1+DipUBgYAklSqf Y95hkjPf0/MPViBeap5m9hWs4xl26j+F8tUYoRyensdx4o0p0CHFuHCR8UhgPXWh eFd378WytMtRpMY2tkxsPIvyb3kMahpTYkLcx9hUfcBRa26pv3oAcADBQjMbAo5X +ac7M8SD2RqJd/cSNEw/rvDgYRAQo+edL8ICq342g9R4j54tXsu8yCXMnnOer6xi mm8C4maCK1olqQbT8QKJwf7aJw4YaoYdO28H9y264y+Kc6d5+ZBA3AIS41uwplGq a+dudZTsx+z9BVE9pzDwny3uyYW7DmACfZQ0b5R9E70yO8NnT8KfNU5vQFqrA/A= =xCfY -----END PGP SIGNATURE----- ------enig2ADDOGHKKQDIGFONFTVXK-- From owner-freebsd-net@FreeBSD.ORG Thu May 9 10:32:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 579CE7E4 for ; Thu, 9 May 2013 10:32:05 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 22050E20 for ; Thu, 9 May 2013 10:32:04 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id B7FFC724C for ; Thu, 9 May 2013 12:32:04 +0200 (CEST) Message-ID: <518B7B23.9080601@peterschmitt.fr> Date: Thu, 09 May 2013 12:32:03 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: mipv6 References: <518B792C.1020704@peterschmitt.fr> In-Reply-To: <518B792C.1020704@peterschmitt.fr> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2LNRARNMPQCWJGEOLBKWA" 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, 09 May 2013 10:32:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2LNRARNMPQCWJGEOLBKWA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 09/05/2013 12:23, Florent Peterschmitt a =E9crit : > Le 09/05/2013 03:51, Ouyahia Nourimane a =E9crit : >> hello, i'm a student >> i have a project about mipv6 and i wish that you can help me >> i want to test mipv6 with freebsd but i didn't realize how to configur= e >> kame >> which is the last version that support kame and can you give me iso im= age >> of this version with kame ... >> i'm waiting your answer >> thanks >> _______________________________________________ >> 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"= >> > Hi, >=20 > FreeBSD has already the IPv6 stack so there is no special version to ta= ke. >=20 > See: >=20 > http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt > http://forums.freebsd.org/showthread.php?t=3D10077 > https://ipv6.u-strasbg.fr/doku.php?id=3Dkame (french) >=20 > What I see is that it should work without bringing any patch since ther= e > is no newer version for current versions of FreeBSD. >=20 Hum I just found this: https://wiki.freebsd.org/IPv6TODO#Mobile_IPv6 :( --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2LNRARNMPQCWJGEOLBKWA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRi3sjAAoJEMtO2Sol0IImxm0H/2fFzjO9HJdilU5yPlegaOD2 zWs8AxFFc/KlzqCLV6CsuXogUs163pNdF897nOO2baPAS569pF0wP8dW5jWadSHI CXOM0HpY8+WfiOSaktRCkGKRenlhwjWfqnkZL3gCB8k6wzJUXzbKukgHCt0H2od8 kyAqdFz/aqW+6zoykbzwlmQC55b4XfGWj25QiFmqtWAR4hAKv85NdIJSTElUM2V4 oviulWsorMgSvoRKQvD8d2r97Z1oOMPSFjKNPom6wm24AdMcly66qDq4uQtSLp0F KJ/QxhntWcoAV59ETtMgfpgdgR9q/i0ck2sYJsCbGfWajUCqClzptr5Uj0Yt/UY= =zZr6 -----END PGP SIGNATURE----- ------enig2LNRARNMPQCWJGEOLBKWA-- From owner-freebsd-net@FreeBSD.ORG Thu May 9 10:45:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1E9479CD for ; Thu, 9 May 2013 10:45:22 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id E300FEC1 for ; Thu, 9 May 2013 10:45:21 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id u16so5330216iet.28 for ; Thu, 09 May 2013 03:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8JdqV9bM1r8FzohY1lmKXkglvNq5pKV+Ntt29BwdLZs=; b=bKdFnXQ8XAkFpWlNSBH4rAq/C85jJRwGEZwrdgozmigDbZnsNnDMQpHqYzyPCPyrWY H037i6KilFnTHNH4+Bgsz7K+Dpt7YpSFBaXZrrKhqUL/DpQ191DVvASOiUNYy1DKbW8F msCmmn4CHHFZs+8Ag9+Dvbnl84f/uEMtEZi+A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=8JdqV9bM1r8FzohY1lmKXkglvNq5pKV+Ntt29BwdLZs=; b=P5Bplth6oO3CLC8RQhVzWr6/fgNmGOxZPYcG0i5JKhCl7EyKvuIdm1AOJOCqCspIcr NavNaT7k2AI9BX09Z5uTc4lf6DercSDwj0DFdUi94aUBue0DoD6AAg5gWfWVCKkwD0cr f7QFEEbnihVrjznuUn40Z4RYt/KWG4IRybresjdpMAMbBzfLp/fUNF7YJzEQlx0izW0l 8EfK/rn2AgfskZ2A5o0hhiCjLlOyYPUQn/qxN9lTsUXKoDgxbrwQ3vLwAvlLFYD31U3T njofm+kIDwhdZlgqJ/coC9eE/0U44MPo4i7UNzGdAJAueEb0AbdtxGnId6A5mR57e2Wk wo7Q== X-Received: by 10.50.66.199 with SMTP id h7mr4651334igt.8.1368096320886; Thu, 09 May 2013 03:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.106.134 with HTTP; Thu, 9 May 2013 03:44:40 -0700 (PDT) In-Reply-To: <518B7B23.9080601@peterschmitt.fr> References: <518B792C.1020704@peterschmitt.fr> <518B7B23.9080601@peterschmitt.fr> From: Takuya ASADA Date: Thu, 9 May 2013 19:44:40 +0900 Message-ID: Subject: Re: mipv6 To: Florent Peterschmitt X-Gm-Message-State: ALoCoQlqY5XapEZU5jB2N0BlZJzeMuchF5y7IuOZIlez1lNyRupnujtlpIdiYKJGIk99TnuSlaJi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 09 May 2013 10:45:22 -0000 Hi, I know some of people who were worked on Mobility support on KAME project, and the code is still available on KAME site: http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ But it's for FreeBSD 5, probably not able to compile recent version of FreeBSD anymore. I guess there's no porting work, so if you want to use it, you need to port it. # Maybe not too difficult though? 2013/5/9 Florent Peterschmitt > Le 09/05/2013 12:23, Florent Peterschmitt a =C3=A9crit : > > Le 09/05/2013 03:51, Ouyahia Nourimane a =C3=A9crit : > >> hello, i'm a student > >> i have a project about mipv6 and i wish that you can help me > >> i want to test mipv6 with freebsd but i didn't realize how to configur= e > >> kame > >> which is the last version that support kame and can you give me iso > image > >> of this version with kame ... > >> i'm waiting your answer > >> thanks > >> _______________________________________________ > >> 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" > >> > > Hi, > > > > FreeBSD has already the IPv6 stack so there is no special version to > take. > > > > See: > > > > http://www.kame.net/~suz/freebsd-ipv6-config-guide.txt > > http://forums.freebsd.org/showthread.php?t=3D10077 > > https://ipv6.u-strasbg.fr/doku.php?id=3Dkame (french) > > > > What I see is that it should work without bringing any patch since ther= e > > is no newer version for current versions of FreeBSD. > > > Hum I just found this: > https://wiki.freebsd.org/IPv6TODO#Mobile_IPv6 :( > > -- > Florent Peterschmitt > +33 (0)6 64 33 97 92 > florent@peterschmitt.fr > > ------------------------ > O< ascii ribbon campaign > - stop html mail > - www.asciiribbon.org > > From owner-freebsd-net@FreeBSD.ORG Thu May 9 12:56:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AFC26E2A for ; Thu, 9 May 2013 12:56:56 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm36-vm4.bullet.mail.ne1.yahoo.com (nm36-vm4.bullet.mail.ne1.yahoo.com [98.138.229.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6E82C687 for ; Thu, 9 May 2013 12:56:55 +0000 (UTC) Received: from [98.138.226.176] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 09 May 2013 12:54:06 -0000 Received: from [98.138.86.157] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 09 May 2013 12:54:05 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 09 May 2013 12:54:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 969047.13898.bm@omp1015.mail.ne1.yahoo.com Received: (qmail 46460 invoked by uid 60001); 9 May 2013 12:54:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368104045; bh=+OSnL5CcPnO3QTRB3SB48wIMK2ITcELHTLsphBhfi+A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IgH03bcpbrGMJISMKjvMheDIU4zUBs+/As2H3vctTtOYsNCJC33iPrcvjvZyVGpD+C8RTKghl8VsNY8J3o3mcA9hIGA1hwii/wLAdfRocFwpe9t/zbLP33Yu1fNfk77iVQyi4r7pZEtVip1KaB7ZWvmQIHaJwbPoDhh0nwZ8q5o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XrbcjJE5tYN+73rO0232K5grvRcF/A3V/9BnFC/JSpECGzx0E4EgLEP23omVX826KN6jdM5FkmRLGZJ/UFx8/riC1LUytowtJ73dMVpCJvK0+716QJ2XktzdtBMN0GdkV17bpDcwALvsmxi58utiVO1sqfaB6GJjyAFkUO95eeQ=; X-YMail-OSG: kKgz8B0VM1k7RyetKh2Qae0O.yJ_Ulz_jbu0qmo89UdMQoG 1RerwHe5mozDJOQ3sAUfg0H0H5WuvQVF_IjLCr7KWVfMA11v8RBNHPH9Lkkd U48dJKPNN_WDuF3s2J8k5B.HTxc5B2Ne1yod0Gke9EeODfr96rNTos5b8IEF xv6ui2mdbGtgwXsNWIytEgkxWbfWobWcfzqYDJ7I.8rcgCCBKFGv7TVAEs3j md91NcjGTliTuZtIvmNy5PbObOIbUuLplAfUpCI40SdmPq.wZt6WosFqnjEp l4O2.077GOHb33Btd0nZqIs18ypH7bB4TUEjlmEIA0kgCnjyF9XtkPktt_n9 E5e1XGcQtD857Geras11AZLvQ2ZyHyivJWWKGWt0FhAtZNjevP_BpHcoT7uy mtGY0CS0d2GxahhaC19fGlQlUFnG3zUcJYgWvsUrb9vo2TL1U5Uk07TxrCt. 805svATvd.J0LpLwP9957ftk9gEgg7x.iTGMCkiL_YszFwWVyPYov2MWG6mw Mhobi9lTYrf18lZRZIpFhvK_jqytiD6vr0iDgwVvhU9_nJ_zQps3zyu5uDrA wvsB4p3HlZ9_yks8dk27BPnDr Received: from [98.203.118.124] by web121601.mail.ne1.yahoo.com via HTTP; Thu, 09 May 2013 05:54:05 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gU3VuLCA0LzI4LzEzLCBCYXJuZXkgQ29yZG9iYSA8YmFybmV5X2NvcmRvYmFAeWFob28uY29tPiB3cm90ZToKCj4gRnJvbTogQmFybmV5IENvcmRvYmEgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4KPiBTdWJqZWN0OiBSZTogSGlnaCBDUFUgaW50ZXJydXB0IGxvYWQgb24gaW50ZWwgSTM1MFQ0IHdpdGggaWdiIG9uIDguMwo.IFRvOiAiSmFjayBWb2dlbCIgPGpmdm9nZWxAZ21haWwuY29tPgo.IENjOiAiRnJlZUJTRCBOZXQiIDxmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZz4sICJDbMOpbWVudCABMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.141.536 Message-ID: <1368104045.43950.YahooMailClassic@web121601.mail.ne1.yahoo.com> Date: Thu, 9 May 2013 05:54:05 -0700 (PDT) From: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 To: nodens2099@gmail.com In-Reply-To: <1367175573.97340.YahooMailClassic@web121602.mail.ne1.yahoo.com> MIME-Version: 1.0 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: Thu, 09 May 2013 12:56:56 -0000 =0A=0A--- On Sun, 4/28/13, Barney Cordoba wrote:= =0A=0A> From: Barney Cordoba =0A> Subject: Re: Hi= gh CPU interrupt load on intel I350T4 with igb on 8.3=0A> To: "Jack Vogel" = =0A> Cc: "FreeBSD Net" , "Cl=E9= ment Hermann (nodens)" =0A> Date: Sunday, April 28, 2= 013, 2:59 PM=0A> The point of lists is to be able to=0A> benefit from other= 's experiences so you don't have to waste=0A> your time "trying" things tha= t others have already done.=0A> I'm not pontificating. I've done the tests.= There's no=0A> reason for every person who is=A0having to exact same probl= em=0A> to do the same tests over and over, hoping for somemagically=0A> dif= ferent result. The result will always be the same.=0A> Because there's no c= hance=A0of it=A0working properly by=0A> chance.=0A> BC=0A> =0A> =0A> --- On= Sun, 4/28/13, Jack Vogel =0A> wrote:=0A> =0A> From: Jac= k Vogel =0A> Subject: Re: High CPU interrupt load on int= el I350T4 with=0A> igb on 8.3=0A> To: "Barney Cordoba" =0A> Cc: "FreeBSD Net" ,=0A> "Cl=E9ment Herm= ann (nodens)" =0A> Date: Sunday, April 28, 2013, 1:07= PM=0A> =0A> Try setting your queues to 1, run some tests, then try=0A> set= tingyour queues to 2, then to 4... its called tuning, and=0A> rather thanju= st pontificating about it, which Barney so=0A> loves to do, you can=0A> dis= cover what works best. I ran tests last week preparing=0A> for anew driver = version and found the best results came not=0A> only whiletweaking queues, = but also ring size, and I could=0A> see changes based=0A> on the buf ring s= ize.... =A0There are lots of things that may=0A> improve ordegrade performa= nce depending on the workload.=0A> Jack=0A> =0A> =0A> =0A> On Sun, Apr 28, = 2013 at 7:21 AM, Barney Cordoba =0A> wrote:=0A> = =0A> =0A> =0A> =0A> =0A> --- On Fri, 4/26/13, "Cl=E9ment Hermann (nodens)" = =0A> wrote:=0A> =0A> =0A> =0A> > From: "Cl=E9ment Her= mann (nodens)" =0A> =0A> > Subject: High CPU interrup= t load on intel I350T4 with=0A> igb on 8.3=0A> =0A> > To: freebsd-net@freeb= sd.org=0A> =0A> > Date: Friday, April 26, 2013, 7:31 AM=0A> =0A> > Hi list,= =0A> =0A> >=0A> =0A> > We use pf+ALTQ for trafic shaping on some routers.= =0A> =0A> >%> =0A> > We are switching to new servers : Dell PowerEdge R620= =0A> with 2=0A> =0A> > 8-cores Intel Processor (E5-2650L), 8GB RAM and Inte= l=0A> I350T4=0A> =0A> > (quad port) using igb driver. The old hardware is u= sing=0A> em=0A> =0A> > driver, the CPU load is high but mostly due to kerne= l=0A> and a=0A> =0A> > large pf ruleset.=0A> =0A> >=0A> =0A> > On the new h= ardware, we see high CPU Interrupt load (up=0A> to=0A> =0A> > 95%), even th= ough there is not much trafic currently=0A> (peaks=0A> =0A> > about 150Mbps= and 40Kpps). All queues are used and=0A> binded to=0A> =0A> > a cpu accord= ing to top, but a lot of CPU time is spent=0A> on=0A> =0A> > igb queues (in= terrupt or wait). The load is fine when=0A> we=0A> =0A> > stay below 20Kpps= .=0A> =0A> >=0A> =0A> > We see no mbuf shortage, no dropped packet, but the= re=0A> is=0A> =0A> > little margin left on CPU time (about 25% idle at best= ,=0A> most=0A> =0A> > of CPU time is spent on interrupts), which is=0A> dis= turbing.=0A> =0A> >=0A> =0A> > We have done some tuning, but to no avail := =0A> =0A> >=0A> =0A> > sysctl.conf :=0A> =0A> >=0A> =0A> > # mbufs=0A> =0A>= > kern.ipc.nmbclusters=3D65536=0A> =0A> > # Sockets=0A> =0A> > kern.ipc.so= maxconn=3D8192=0A> =0A> > net.inet.tcp.delayed_ack=3D0=0A> =0A> > net.inet.= tcp.sendspace=3D65535=0A> =0A> > net.inet.udp.recvspace=3D65535=0A> =0A> > = net.inet.udp.maxdgram=3D57344=0A> =0A> > net.local.stream.recvspace=3D65535= =0A> =0A> > net.local.stream.sendspace=3D65535=0A> =0A> > # IGB=0A> =0A> > = dev.igb.0.rx_processing_limit=3D4096=0A> =0A> > dev.igb.1.rx_processing_lim= it=3D4096=0A> =0A> > dev.igb.2.rx_processing_limit=3D4096=0A> =0A> > dev.ig= b.3.rx_processing_limit=3D4096=0A> =0A> >=0A> =0A> > /boot/loader.conf :=0A= > =0A> >=0A> =0A> > vm.kmem_size=3D1G=0A> =0A> > hw.igb.max_interrupt_rate= =3D"32000"=A0 # maximum number=0A> of=0A> =0A> > interrupts/sec generated b= y single igb(4) (default=0A> 8000)=0A> =0A> > hw.igb.txd=3D"2048"=A0 =A0 = =A0 =A0 =A0 =A0=0A> =0A> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =0A> > =A0 #= number of transmit descriptors allocated by the=0A> =0A> > driver (2048 li= mit)=0A> =0A> > hw.igb.rxd=3D"2048"=A0 =A0 =A0 =A0 =A0 =A0=0A> =0A> > =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =0A> > =A0 # number of receive descriptors = allocated by the=0A> =0A> > driver (2048 limit)=0A> =0A> > hw.igb.rx_proces= s_limit=3D"1000"=A0 =A0=A0=A0#=0A> =0A> > maximum number of received packet= s to process at a=0A> time, The=0A> =0A> > default of 100 is=0A> =0A> > =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =0A> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A>= =0A> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =0A> > =A0 =A0 =A0 =A0 =A0 =A0= =0A> =0A> > =A0=A0=A0# too low for most firewalls. (-1 means=0A> =0A> > unl= imited)=0A> =0A> >=0A> =0A> > Kernel HZ is 1000.=0A> =0A> >=0A> =0A> > The = IGB /boot/loader.conf tuning was our last attempt,=0A> it=0A> =0A> > didn't= change anything.=0A> =0A> >=0A> =0A> > Does anyone have any pointer ? How = could we lower CPU=0A> =0A> > interrupt load ? should we set=0A> hw.igb.max= _interrupt_rate=0A> =0A> > lower instead of higher ?=0A> =0A> > From what w= e saw here and there, we should be able to=0A> do=0A> =0A> > much better wi= th this hardware.=0A> =0A> >=0A> =0A> >=0A> =0A> > relevant sysctl (igb1 an= d igb2 only, other interfaces=0A> are=0A> =0A> > unused) :=0A> =0A> >=0A> = =0A> > sysctl dev.igb | grep -v ": 0$"=0A> =0A> > dev.igb.1.%desc: Intel(R)= PRO/1000 Network Connection=0A> =0A> > version - 2.3.1=0A> =0A> > dev.igb.= 1.%driver: igb=0A> =0A> > dev.igb.1.%location: slot=3D0 function=3D1=0A> = =0A> > dev.igb.1.%pnpinfo: vendor=3D0x8086 device=3D0x1521=0A> =0A> > subve= ndor=3D0x8086 subdevice=3D0x5001 class=3D0x020000=0A> =0A> > dev.igb.1.%par= ent: pci5=0A> =0A> > dev.igb.1.nvm: -1=0A> =0A> > dev.igb.1.enable_aim: 1= =0A> =0A> > dev.igb.1.fc: 3=0A> =0A> > dev.igb.1.rx_processing_limit: 4096= =0A> =0A> > dev.igb.1.eee_disabled: 1=0A> =0A> > dev.igb.1.link_irq: 2=0A> = =0A> > dev.igb.1.device_control: 1209795137=0A> =0A> > dev.igb.1.rx_control= : 67141658=0A> =0A> > dev.igb.1.interrupt_mask: 4=0A> =0A> > dev.igb.1.exte= nded_int_mask: 2147483981=0A> =0A> > dev.igb.1.fc_high_water: 33168=0A> =0A= > > dev.igb.1.fc_low_water: 33152=0A> =0A> > dev.igb.1.queue0.interrupt_rat= e: 71428=0A> =0A> > dev.igb.1.queue0.txd_head: 1318=0A> =0A> > dev.igb.1.qu= eue0.txd_tail: 1318=0A> =0A> > dev.igb.1.queue0.tx_packets: 84663594=0A> = =0A> > dev.igb.1.queue0.rxd_head: 717=0A> =0A> > dev.igb.1.queue0.rxd_tail:= 715=0A> =0A> > dev.igb.1.queue0.rx_packets: 43899597=0A> =0A> > dev.igb.1.= queue0.rx_bytes: 8905556030=0A> =0A> > dev.igb.1.queue1.interrupt_rate: 909= 09=0A> =0A> > dev.igb.1.queue1.txd_head: 693=0A> =0A> > dev.igb.1.queue1.tx= d_tail: 693=0A> =0A> > dev.igb.1.queue1.tx_packets: 57543349=0A> =0A> > dev= .igb.1.queue1.rxd_head: 1033=0A> =0A> > dev.igb.1.queue1.rxd_tail: 1032=0A>= =0A> > dev.igb.1.queue1.rx_packets: 54821897=0A> =0A> > dev.igb.1.queue1.r= x_bytes: 9944955108=0A> =0A> > dev.igb.1.queue2.interrupt_rate: 100000=0A> = =0A> > dev.igb.1.queue2.txd_head: 350=0A> =0A> > dev.igb.1.queue2.txd_tail:= 350=0A> =0A> > dev.igb.1.queue2.tx_packets: 62320990=0A> =0A> > dev.igb.1.= queue2.rxd_head: 1962=0A> =0A> > dev.igb.1.queue2.rxd_tail: 1939=0A> =0A> >= dev.igb.1.queue2.rx_packets: 43909016=0A> =0A> > dev.igb.1.queue2.rx_bytes= : 8673941461=0A> =0A> > dev.igb.1.queue3.interrupt_rate: 14925=0A> =0A> > d= ev.igb.1.queue3.txd_head: 647=0A> =0A> > dev.igb.1.queue3.txd_tail: 647=0A>= =0A> > dev.igb.1.queue3.tx_packets: 58776199=0A> =0A> > dev.igb.1.queue3.r= xd_head: 692=0A> =0A> > dev.igb.1.queue3.rxd_tail: 691=0A> =0A> > dev.igb.1= .queue3.rx_packets: 55138996=0A> =0A> > dev.igb.1.queue3.rx_bytes: 93102173= 54=0A> =0A> > dev.igb.1.queue4.interrupt_rate: 100000=0A> =0A> > dev.igb.1.= queue4.txd_head: 1721=0A> =0A> > dev.igb.1.queue4.txd_tail: 1721=0A> =0A> >= dev.igb.1.queue4.tx_packets: 54337209=0A> =0A> > dev.igb.1.queue4.rxd_head= : 1609=0A> =0A> > dev.igb.1.queue4.rxd_tail: 1598=0A> =0A> > dev.igb.1.queu= e4.rx_packets: 46546503=0A> =0A> > dev.igb.1.queue4.rx_bytes: 8818182840=0A= > =0A> > dev.igb.1.queue5.interrupt_rate: 11627=0A> =0A> > dev.igb.1.queue5= .txd_head: 254=0A> =0A> > dev.igb.1.queue5.txd_tail: 254=0A> =0A> > dev.igb= .1.queue5.tx_packets: 53117182=0A> =0A> > dev.igb.1.queue5.rxd_head: 701=0A= > =0A> > dev.igb.1.queue5.rxd_tail: 685=0A> =0A> > dev.igb.1.queue5.rx_pack= ets: 43014837=0A> =0A> > dev.igb.1.queue5.rx_bytes: 8699057447=0A> =0A> > d= ev.igb.1.queue6.interrupt_rate: 55555=0A> =0A> > dev.igb.1.queue6.txd_head:= 8=0A> =0A> > dev.igb.1.queue6.txd_tail: 8=0A> =0A> > dev.igb.1.queue6.tx_p= ackets: 52654088=0A> =0A> > dev.igb.1.queue6.rxd_head: 1057=0A> =0A> > dev.= igb.1.queue6.rxd_tail: 1041=0A> =0A> > dev.igb.1.queue6.rx_packets: 4522703= 0=0A> =0A> > dev.igb.1.queue6.rx_bytes: 9494489640=0A> =0A> > dev.igb.1.que= ue7.interrupt_rate: 5235=0A> =0A> > dev.igb.1.queue7.txd_head: 729=0A> =0A>= > dev.igb.1.queue7.txd_tail: 729=0A> =0A> > dev.igb.1.queue7.tx_packets: 6= 1926105=0A> =0A> > dev.igb.1.queue7.rxd_head: 146=0A> =0A> > dev.igb.1.queu= e7.rxd_tail: 140=0A> =0A> > dev.igb.1.queue7.rx_packets: 51781775=0A> =0A> = > dev.igb.1.queue7.rx_bytes: 8901279226=0A> =0A> > dev.igb.1.mac_stats.miss= ed_packets: 1657=0A> =0A> > dev.igb.1.mac_stats.recv_no_buff: 405=0A> =0A> = > dev.igb.1.mac_stats.total_pkts_recvd: 384332760=0A> =0A> > dev.igb.1.mac_= stats.good_pkts_recvd: 384331103=0A> =0A> > dev.igb.1.mac_stats.bcast_pkts_= recvd: 15510=0A> =0A> > dev.igb.1.mac_stats.mcast_pkts_recvd: 52957=0A> =0A= > > dev.igb.1.mac_stats.rx_frames_64: 195496498=0A> =0A> > dev.igb.1.mac_st= ats.rx_frames_65_127: 133346124=0A> =0A> > dev.igb.1.mac_stats.rx_frames_12= 8_255: 5254911=0A> =0A> > dev.igb.1.mac_stats.rx_frames_256_511: 9700049=0A= > =0A> > dev.igb.1.mac_stats.rx_frames_512_1023: 16885886=0A> =0A> > dev.ig= b.1.mac_stats.rx_frames_1024_1522: 23647635=0A> =0A> > dev.igb.1.mac_stats.= good_octets_recvd: 74284029276=0A> =0A> > dev.igb.1.mac_stats.good_octets_t= xd: 544536708502=0A> =0A> > dev.igb.1.mac_stats.total_pkts_txd: 485327419= =0A> =0A> > dev.igb.1.mac_stats.good_pkts_txd: 485327419=0A> =0A> > dev.igb= .1.mac_stats.bcast_pkts_txd: 72=0A> =0A> > dev.igb.1.mac_stats.mcast_pkts_t= xd: 52820=0A> =0A> > dev.igb.1.mac_stats.tx_frames_64: 57820809=0A> =0A> > = dev.igb.1.mac_stats.tx_frames_65_127: 51586341=0A> =0A> > dev.igb.1.mac_sta= ts.tx_frames_128_255: 7050579=0A> =0A> > dev.igb.1.mac_stats.tx_frames_256_= 511: 7887126=0A> =0A> > dev.igb.1.mac_stats.tx_frames_512_1023: 10130891=0A= > =0A> > dev.igb.1.mac_stats.tx_frames_1024_1522: 350851673=0A> =0A> > dev.= igb.1.interrupts.asserts: 551135045=0A> =0A> > dev.igb.1.interrupts.rx_pkt_= timer: 384326679=0A> =0A> > dev.igb.1.interrupts.tx_queue_empty: 485323376= =0A> =0A> > dev.igb.1.interrupts.tx_queue_min_thresh: 6324386=0A> =0A> > de= v.igb.1.host.rx_pkt: 4424=0A> =0A> > dev.igb.1.host.tx_good_pkt: 4043=0A> = =0A> > dev.igb.1.host.rx_good_bytes: 74284030864=0A> =0A> > dev.igb.1.host.= tx_good_bytes: 544536708502=0A> =0A> > dev.igb.2.%desc: Intel(R) PRO/1000 N= etwork Connection=0A> =0A> > version - 2.3.1=0A> =0A> > dev.igb.2.%driver: = igb=0A> =0A> > dev.igb.2.%location: slot=3D0 function=3D2=0A> =0A> > dev.ig= b.2.%pnpinfo: vendor=3D0x8086 device=3D0x1521=0A> =0A> > subvendor=3D0x8086= subdevice=3D0x5001 class=3D0x020000=0A> =0A> > dev.igb.2.%parent: pci5=0A>= =0A> > dev.igb.2.nvm: -1=0A> =0A> > dev.igb.2.enable_aim: 1=0A> =0A> > dev= .igb.2.fc: 3=0A> =0A> > dev.igb.2.rx_processing_limit: 4096=0A> =0A> > dev.= igb.2.eee_disabled: 1=0A> =0A> > dev.igb.2.link_irq: 2=0A> =0A> > dev.igb.2= .device_control: 1209795137=0A> =0A> > dev.igb.2.rx_control: 67141658=0A> = =0A> > dev.igb.2.interrupt_mask: 4=0A> =0A> > dev.igb.2.extended_int_mask: = 2147483959=0A> =0A> > dev.igb.2.fc_high_water: 33168=0A> =0A> > dev.igb.2.f= c_low_water: 33152=0A> =0A> > dev.igb.2.queue0.interrupt_rate: 13698=0A> = =0A> > dev.igb.2.queue0.txd_head: 1618=0A> =0A> > dev.igb.2.queue0.txd_tail= : 1618=0A> =0A> > dev.igb.2.queue0.tx_packets: 46401106=0A> =0A> > dev.igb.= 2.queue0.rxd_head: 831=0A> =0A> > dev.igb.2.queue0.rxd_tail: 827=0A> =0A> >= dev.igb.2.queue0.rx_packets: 69356350=0A> =0A> > dev.igb.2.queue0.rx_bytes= : 68488772907=0A> =0A> > dev.igb.2.queue1.interrupt_rate: 5405=0A> =0A> > d= ev.igb.2.queue1.txd_head: 190=0A> =0A> > dev.igb.2.queue1.txd_tail: 190=0A>= =0A> > dev.igb.2.queue1.tx_packets: 55965886=0A> =0A> > dev.igb.2.queue1.r= xd_head: 268=0A> =0A> > dev.igb.2.queue1.rxd_tail: 256=0A> =0A> > dev.igb.2= .queue1.rx_packets: 58958084=0A> =0A> > dev.igb.2.queue1.rx_bytes: 69154569= 937=0A> =0A> > dev.igb.2.queue2.interrupt_rate: 83333=0A> =0A> > dev.igb.2.= queue2.txd_head: 568=0A> =0A> > dev.igb.2.queue2.txd_tail: 568=0A> =0A> > d= ev.igb.2.queue2.tx_packets: 44974648=0A> =0A> > dev.igb.2.queue2.rxd_head: = 371=0A> =0A> > dev.igb.2.queue2.rxd_tail: 219=0A> =0A> > dev.igb.2.queue2.r= x_packets: 67037407=0A> =0A> > dev.igb.2.queue2.rx_bytes: 72042326102=0A> = =0A> > dev.igb.2.queue3.interrupt_rate: 12658=0A> =0A> > dev.igb.2.queue3.t= xd_head: 867=0A> =0A> > dev.igb.2.queue3.txd_tail: 867=0A> =0A> > dev.igb.2= .queue3.tx_packets: 55962467=0A> =0A> > dev.igb.2.queue3.rxd_head: 85=0A> = =0A> > dev.igb.2.queue3.rxd_tail: 1953=0A> =0A> > dev.igb.2.queue3.rx_packe= ts: 60972965=0A> =0A> > dev.igb.2.queue3.rx_bytes: 70397176035=0A> =0A> > d= ev.igb.2.queue4.interrupt_rate: 90909=0A> =0A> > dev.igb.2.queue4.txd_head:= 1920=0A> =0A> > dev.igb.2.queue4.txd_tail: 1920=0A> =0A> > dev.igb.2.queue= 4.tx_packets: 47660931=0A> =0A> > dev.igb.2.queue4.rxd_head: 1397=0A> =0A> = > dev.igb.2.queue4.rxd_tail: 1379=0A> =0A> > dev.igb.2.queue4.rx_packets: 5= 9110758=0A> =0A> > dev.igb.2.queue4.rx_bytes: 68919201478=0A> =0A> > dev.ig= b.2.queue5.interrupt_rate: 111111=0A> =0A> > dev.igb.2.queue5.txd_head: 886= =0A> =0A> > dev.igb.2.queue5.txd_tail: 886=0A> =0A> > dev.igb.2.queue5.tx_p= ackets: 45103990=0A> =0A> > dev.igb.2.queue5.rxd_head: 812=0A> =0A> > dev.i= gb.2.queue5.rxd_tail: 799=0A> =0A> > dev.igb.2.queue5.rx_packets: 59030312= =0A> =0A> > dev.igb.2.queue5.rx_bytes: 69234293962=0A> =0A> > dev.igb.2.que= ue6.interrupt_rate: 5208=0A> =0A> > dev.igb.2.queue6.txd_head: 1926=0A> =0A= > > dev.igb.2.queue6.txd_tail: 1926=0A> =0A> > dev.igb.2.queue6.tx_packets:= 46215046=0A> =0A> > dev.igb.2.queue6.rxd_head: 692=0A> =0A> > dev.igb.2.qu= eue6.rxd_tail: 689=0A> =0A> > dev.igb.2.queue6.rx_packets: 58256050=0A> =0A= > > dev.igb.2.queue6.rx_bytes: 68429172749=0A> =0A> > dev.igb.2.queue7.inte= rrupt_rate: 50000=0A> =0A> > dev.igb.2.queue7.txd_head: 126=0A> =0A> > dev.= igb.2.queue7.txd_tail: 126=0A> =0A> > dev.igb.2.queue7.tx_packets: 52451455= =0A> =0A> > dev.igb.2.queue7.rxd_head: 968=0A> =0A> > dev.igb.2.queue7.rxd_= tail: 885=0A> =0A> > dev.igb.2.queue7.rx_packets: 65946491=0A> =0A> > dev.i= gb.2.queue7.rx_bytes: 70263478849=0A> =0A> > dev.igb.2.mac_stats.missed_pac= kets: 958=0A> =0A> > dev.igb.2.mac_stats.recv_no_buff: 69=0A> =0A> > dev.ig= b.2.mac_stats.total_pkts_recvd: 498658079=0A> =0A> > dev.igb.2.mac_stats.go= od_pkts_recvd: 498657121=0A> =0A> > dev.igb.2.mac_stats.bcast_pkts_recvd: 1= 6867=0A> =0A> > dev.igb.2.mac_stats.mcast_pkts_recvd: 52957=0A> =0A> > dev.= igb.2.mac_stats.rx_frames_64: 59089332=0A> =0A> > dev.igb.2.mac_stats.rx_fr= ames_65_127: 52880118=0A> =0A> > dev.igb.2.mac_stats.rx_frames_128_255: 752= 6966=0A> =0A> > dev.igb.2.mac_stats.rx_frames_256_511: 8468389=0A> =0A> > d= ev.igb.2.mac_stats.rx_frames_512_1023: 10434770=0A> =0A> > dev.igb.2.mac_st= ats.rx_frames_1024_1522: 360257545=0A> =0A> > dev.igb.2.mac_stats.good_octe= ts_recvd: 558910494322=0A> =0A> > dev.igb.2.mac_stats.good_octets_txd: 8461= 8858153=0A> =0A> > dev.igb.2.mac_stats.total_pkts_txd: 394726904=0A> =0A> >= dev.igb.2.mac_stats.good_pkts_txd: 394726904=0A> =0A> > dev.igb.2.mac_stat= s.bcast_pkts_txd: 48=0A> =0A> > dev.igb.2.mac_stats.mcast_pkts_txd: 52821= =0A> =0A> > dev.igb.2.mac_stats.tx_frames_64: 196605932=0A> =0A> > dev.igb.= 2.mac_stats.tx_frames_65_127: 134602807=0A> =0A> > dev.igb.2.mac_stats.tx_f= rames_128_255: 5705236=0A> =0A> > dev.igb.2.mac_stats.tx_frames_256_511: 10= 267168=0A> =0A> > dev.igb.2.mac_stats.tx_frames_512_1023: 17165496=0A> =0A>= > dev.igb.2.mac_stats.tx_frames_1024_1522: 30380265=0A> =0A> > dev.igb.2.i= nterrupts.asserts: 465994260=0A> =0A> > dev.igb.2.interrupts.rx_pkt_timer: = 498647546=0A> =0A> > dev.igb.2.interrupts.tx_queue_empty: 394720657=0A> =0A= > > dev.igb.2.interrupts.tx_queue_min_thresh: 24424555=0A> =0A> > dev.igb.2= .host.rx_pkt: 9575=0A> =0A> > dev.igb.2.host.tx_good_pkt: 6248=0A> =0A> > d= ev.igb.2.host.rx_good_bytes: 558910513984=0A> =0A> > dev.igb.2.host.tx_good= _bytes: 84618858217=0A> =0A> >=0A> =0A> >=0A> =0A> > Thanks for your help.= =0A> =0A> >=0A> =0A> > Cheers,=0A> =0A> =0A> =0A> You're experiencing lock = contention=0A> =0A> =0A> =0A> Try editing igb.c and setting the queues to 1= . The=0A> multiqueue=0A> =0A> implementation in igb has a negative impact.= =0A> =0A> =0A> =0A> If you have just 1 system get a dual port 82571 card an= d use=0A> the=0A> =0A> em driver.=0A> =0A> =0A> =0A> BC=0A> =0A=0AI'm curio= us as to why you are going to spend $4000. on hardware rather=0Athan just b= uying a commercial firewall? You shouldn't need 16 cores to=0Afilter 150Kpp= s. You can do that with 2 cores.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Thu May 9 14:55:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D5EC9472 for ; Thu, 9 May 2013 14:55:52 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 74249BE9 for ; Thu, 9 May 2013 14:55:52 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r49EtlfF007170; Thu, 9 May 2013 21:55:48 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <518BB8EE.2080705@rdtc.ru> Date: Thu, 09 May 2013 21:55:42 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?IkNsw6ltZW50IEhlcm1hbm4gKG5vZGVucyki?= Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <517A657B.7060003@gmail.com> In-Reply-To: <517A657B.7060003@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Thu, 09 May 2013 14:55:52 -0000 On 26.04.2013 18:31, "Clément Hermann (nodens)" wrote: > Hi list, > > We use pf+ALTQ for trafic shaping on some routers. > > We are switching to new servers : Dell PowerEdge R620 with 2 8-cores > Intel Processor (E5-2650L), 8GB RAM and Intel I350T4 (quad port) using > igb driver. The old hardware is using em driver, the CPU load is high > but mostly due to kernel and a large pf ruleset. > > On the new hardware, we see high CPU Interrupt load (up to 95%), even > though there is not much trafic currently (peaks about 150Mbps and > 40Kpps). All queues are used and binded to a cpu according to top, but a > lot of CPU time is spent on igb queues (interrupt or wait). The load is > fine when we stay below 20Kpps. > > We see no mbuf shortage, no dropped packet, but there is little margin > left on CPU time (about 25% idle at best, most of CPU time is spent on > interrupts), which is disturbing. It seems you suffer from pf lock contention. You should stop using pf with multi-core systems with 8.3. Move to ipfw+dummynet or ng_car for 8.3 or move to 10.0-CURRENT having new, rewritten pf that does not have this problem. Network device driver is not guilty here, that's just pf's contention running in igb's context. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu May 9 16:25:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B637BDB for ; Thu, 9 May 2013 16:25:28 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) by mx1.freebsd.org (Postfix) with ESMTP id DEBF07C for ; Thu, 9 May 2013 16:25:27 +0000 (UTC) Received: from [98.138.226.176] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 09 May 2013 16:25:21 -0000 Received: from [98.138.89.164] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 09 May 2013 16:25:20 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 09 May 2013 16:25:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 971680.98652.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 51753 invoked by uid 60001); 9 May 2013 16:25:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368116720; bh=sbQswaQvDIJgE7Iy8BZkzuBd2514ZPzDPqpb/Qln1Ro=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=E4V+b0CllZJg6b2b9SlqBok6g3npz+5NmddOf+XEa8wD8JZaTM+Tw/W7Ljn1r/4pJjxwbeExYP7Q2MnW+g+urr7VGwS/WAMmoS7xYTMFbMKjW8+Nlww6IElD6s1oXlkn14ms2GDlTGUBrfiLl1LGBO09ZoFPnpy+c8c8QOu+T0U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yPnbkaOC8UmBm8qV0L2ye6ZeylXEqFMS81DtvAGhXxf+JZuQxMCT+gm9NTMyY8fw4uA/nV7IDbUJSyRwC91qVEHDvvQowv5dXj4G6hFZayvOOv79LMnqQjx0WigeCVqJfEUVqjp2tmowd/l6DMnyVH+bfQ5euIMt71b5iQb/SX4=; X-YMail-OSG: H.XcFvgVM1n4KDeuMPlkcHYekqQ1pBWhHdj2XviZCG92q5M 8nQQFQtI7W0K7jEnMF7hAEjdIrwhbzCVJ49JlhreHeGRNyAhuLGYapH9Axxr .HfvXezpS4nezYxdqa1eCBYkE3vpzO3tK_XjsuYALk9ux33gXeOXWReGArKM arLjyxkz1A5yCNMnRCsYx8J4Y7RlXmRyqgDWZAvBmgM7TMc5eL_ejpVmDeZ5 1AYP2pOX4AAM8j4xnfeKHGiRxHVDer.XgbbzEiY7lHAHV8vU2H_eN1K_U9B2 pc51nwvp3zTEMT2EAXjZXgV2mL.Wn3ZbemApwiUaUSAWYCYybPk0p6C0gZg4 Ry8Vc.EkQE1Z4CtXHLW8puYw.hRfdh6hg2bB_cLiDFj9YW2lu4VMuqpQno1V 8uaLP2tEdaAt7V_cKqep32a4A5ru3GRVgB48HEe0zLClg4QhUZC5dqAhjD8F V0iJjkp_8q8xDJVbTbpZFeZS3C9ikS_cDnn7aLrFeuLLKdzokgxBQ8dEgTTw Ws2mp99OYkxVMlQSdeM6yeSzbNXLyiw-- Received: from [98.203.118.124] by web121606.mail.ne1.yahoo.com via HTTP; Thu, 09 May 2013 09:25:20 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gVGh1LCA1LzkvMTMsIEV1Z2VuZSBHcm9zYmVpbiA8ZWdyb3NiZWluQHJkdGMucnU.IHdyb3RlOgoKPiBGcm9tOiBFdWdlbmUgR3Jvc2JlaW4gPGVncm9zYmVpbkByZHRjLnJ1Pgo.IFN1YmplY3Q6IFJlOiBIaWdoIENQVSBpbnRlcnJ1cHQgbG9hZCBvbiBpbnRlbCBJMzUwVDQgd2l0aCBpZ2Igb24gOC4zCj4gVG86ICIiQ2zDqW1lbnQgSGVybWFubiAobm9kZW5zKSIiIDxub2RlbnMyMDk5QGdtYWlsLmNvbT4KPiBDYzogZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcKPiBEYXRlOiBUaHVyc2RheSwgTWEBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.141.536 Message-ID: <1368116720.51479.YahooMailClassic@web121606.mail.ne1.yahoo.com> Date: Thu, 9 May 2013 09:25:20 -0700 (PDT) From: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 To: =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= , Eugene Grosbein In-Reply-To: <518BB8EE.2080705@rdtc.ru> MIME-Version: 1.0 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: Thu, 09 May 2013 16:25:28 -0000 =0A=0A--- On Thu, 5/9/13, Eugene Grosbein wrote:=0A=0A>= From: Eugene Grosbein =0A> Subject: Re: High CPU interr= upt load on intel I350T4 with igb on 8.3=0A> To: ""Cl=E9ment Hermann (noden= s)"" =0A> Cc: freebsd-net@freebsd.org=0A> Date: Thurs= day, May 9, 2013, 10:55 AM=0A> On 26.04.2013 18:31, "Cl=E9ment=0A> Hermann = (nodens)" wrote:=0A> > Hi list,=0A> > =0A> > We use pf+ALTQ for trafic shap= ing on some routers.=0A> > =0A> > We are switching to new servers : Dell Po= werEdge R620=0A> with 2 8-cores =0A> > Intel Processor (E5-2650L), 8GB RAM = and Intel I350T4=0A> (quad port) using =0A> > igb driver. The old hardware = is using em driver, the=0A> CPU load is high =0A> > but mostly due to kerne= l and a large pf ruleset.=0A> > =0A> > On the new hardware, we see high CPU= Interrupt load (up=0A> to 95%), even =0A> > though there is not much trafi= c currently (peaks about=0A> 150Mbps and =0A> > 40Kpps). All queues are use= d and binded to a cpu=0A> according to top, but a =0A> > lot of CPU time is= spent on igb queues (interrupt or=0A> wait). The load is =0A> > fine when = we stay below 20Kpps.=0A> > =0A> > We see no mbuf shortage, no dropped pack= et, but there=0A> is little margin =0A> > left on CPU time (about 25% idle = at best, most of CPU=0A> time is spent on =0A> > interrupts), which is dist= urbing.=0A> =0A> It seems you suffer from pf lock contention. You should st= op=0A> using pf=0A> with multi-core systems with 8.3. Move to ipfw+dummynet= or=0A> ng_car for 8.3=0A> or move to 10.0-CURRENT having new, rewritten pf= that does=0A> not have this problem.=0A> =0A> Network device driver is not= guilty here, that's just pf's=0A> contention=0A> running in igb's context.= =0A> =0A> Eugene Grosbein=0A=0AThey're both at play. Single threadedness ag= gravates subsystems that =0Ahave too many lock points.=0A=0AIt can also be = "solved" with using 1 queue, because then you don't=0Ahave 4 queues going i= nto a single thread.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Thu May 9 16:30:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 22DFCF2F for ; Thu, 9 May 2013 16:30:46 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4D88EDD for ; Thu, 9 May 2013 16:30:44 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r49GUfnh007850; Thu, 9 May 2013 23:30:41 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <518BCF2C.3080307@rdtc.ru> Date: Thu, 09 May 2013 23:30:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <1368116720.51479.YahooMailClassic@web121606.mail.ne1.yahoo.com> In-Reply-To: <1368116720.51479.YahooMailClassic@web121606.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?UTF-8?B?IkNsw6ltZW50IEhlcm1hbm4gKG5vZGVucyki?= 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, 09 May 2013 16:30:46 -0000 On 09.05.2013 23:25, Barney Cordoba wrote: >> Network device driver is not guilty here, that's just pf's >> contention >> running in igb's context. >> >> Eugene Grosbein > > They're both at play. Single threadedness aggravates subsystems that > have too many lock points. > > It can also be "solved" with using 1 queue, because then you don't > have 4 queues going into a single thread. Again, the problem is within pf(4)'s global lock, not in the igb(4). From owner-freebsd-net@FreeBSD.ORG Thu May 9 17:53:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 32120340 for ; Thu, 9 May 2013 17:53:07 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id C2FCA906 for ; Thu, 9 May 2013 17:53:06 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id z7so695690eaf.19 for ; Thu, 09 May 2013 10:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=J4TndguVqk68vH7lfqIYJpv8lyu0bZy5nYwuhMxZP58=; b=b4PCdMyyMK7RNG7IfwF70ic85WT/QtTKSRLyim0h2C/AWuKxB5DT4QJ4yOO4m2/x+Q 9+qK8Z/eAXcuUvL/N6FyPVj+Cii5DqL7nOEQMIXyhJkLYCJbFweL+TDt0uoxOjNuMIxr 2WhX+gxj7PDKqiNe4GNrIU+nCjkPxRVJBe2hQePbM87LT29L1odRGsRBJJkbn/6rDaMP rShd4qeJ0UR1YimVO5Ad5paLfygjkFfVMULqfL+yVxmHF7KudxNLHpBPztOngmMFhLQP 2Yfo9qs43Xj9rnq2HOHwbSG8x1vqH0qs77EBz/mixL7lS7TnQyq3kCOlejGHFArWRCaY ixzA== MIME-Version: 1.0 X-Received: by 10.15.48.193 with SMTP id h41mr31556149eew.23.1368121985764; Thu, 09 May 2013 10:53:05 -0700 (PDT) Received: by 10.223.76.134 with HTTP; Thu, 9 May 2013 10:53:05 -0700 (PDT) Date: Thu, 9 May 2013 10:53:05 -0700 Message-ID: Subject: VIMAGE and socreate From: Vijay Singh 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: Thu, 09 May 2013 17:53:07 -0000 In 8.3, socreate() does: so = soalloc(CRED_TO_VNET(cred)); Is there a reason why we don't do soalloc(curvnet) here? Since CURVNET_SET() doesn't update the vnet in the thread ucred, which is passed into socreate(), it doesn't take effect for socket creations. Any ideas? -vijay From owner-freebsd-net@FreeBSD.ORG Thu May 9 18:09:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C47B050F for ; Thu, 9 May 2013 18:09:34 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDDE99B for ; Thu, 9 May 2013 18:09:33 +0000 (UTC) Received: from tpx32.lan (89.164.242.51) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 9 May 2013 20:08:24 +0200 From: Marko Zec To: Subject: Re: VIMAGE and socreate Date: Thu, 9 May 2013 20:07:28 +0200 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: <201305092007.28666.zec@fer.hr> X-Originating-IP: [89.164.242.51] Cc: Vijay Singh 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, 09 May 2013 18:09:34 -0000 On Thursday 09 May 2013 19:53:05 Vijay Singh wrote: > In 8.3, socreate() does: > > so = soalloc(CRED_TO_VNET(cred)); > > Is there a reason why we don't do soalloc(curvnet) here? Since > CURVNET_SET() doesn't update the vnet in the thread ucred, which is > passed into socreate(), it doesn't take effect for socket creations. Because CRED_TO_VNET(cred) and curvnet are fundamentally different things: #define CRED_TO_VNET(cr) (cr)->cr_prison->pr_vnet #define curvnet curthread->td_vnet and moreover at the time soalloc() gets called curvnet is (usually) NULL. Marko From owner-freebsd-net@FreeBSD.ORG Thu May 9 19:20:02 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D7F9742 for ; Thu, 9 May 2013 19:20:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 23132D73 for ; Thu, 9 May 2013 19:20:01 +0000 (UTC) Received: from alph.d.allbsd.org (p2175-ipbf701funabasi.chiba.ocn.ne.jp [122.25.209.175]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r49JJj95073621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 May 2013 04:19:55 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r49JJhpJ036423; Fri, 10 May 2013 04:19:45 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 10 May 2013 04:19:34 +0900 (JST) Message-Id: <20130510.041934.19893072298744952.hrs@allbsd.org> To: florent@peterschmitt.fr Subject: Re: IPv6 configuration missunderstanding From: Hiroki Sato In-Reply-To: <518A6D5C.3030804@peterschmitt.fr> References: <518A6D5C.3030804@peterschmitt.fr> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_May_10_04_19_34_2013_266)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 10 May 2013 04:19:55 +0900 (JST) X-Spam-Status: No, score=-94.5 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,RCVD_IN_PBL,SAMEHELOBY2HOP,TO_NO_BRKTS_PCNT,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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: Thu, 09 May 2013 19:20:02 -0000 ----Security_Multipart(Fri_May_10_04_19_34_2013_266)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Florent Peterschmitt wrote in <518A6D5C.3030804@peterschmitt.fr>: fl> Hi, fl> fl> I want to configure IPv6 in FreeBSD 9.1-RELEASE like this : fl> fl> ipv6_enable=yes fl> ipv6_activate_all_interfaces=yes fl> ifconfig_em0_ipv6="inet6 2001:41D0:8:B81f:: prefixlen 64" fl> -interface em0" fl> ipv6_defaultrouter="2001:41D0:8:B8ff:ff:ff:ff:ff" Why the default router is not in 2001:41d0:8:b81f::/64? fl> But at boot I have : fl> fl> default fe80::264:40ff:fe3a:fac0%em0 UG em0 I guess this is provided by the router via Router Advertisement messages. fl> And if ipv6_enable=yes is not here (although it's depreciated), no IPv6 fl> at all. Please remove ipv6_enable=yes and ipv6_activate_all_interfaces=yes unless you understand you really need them. I think only the following line is sufficient for your environment: ifconfig_em0_ipv6="inet6 2001:41d0:8:b81f::1 prefixlen 64 accept_rtadv" -- Hiroki ----Security_Multipart(Fri_May_10_04_19_34_2013_266)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlGL9sYACgkQTyzT2CeTzy0KBACdE/pLdXtHCvJtHfqxYCcwdb1q EiUAoJu8SApJSArIyka5BkbGHMej2jtw =pl1f -----END PGP SIGNATURE----- ----Security_Multipart(Fri_May_10_04_19_34_2013_266)---- From owner-freebsd-net@FreeBSD.ORG Thu May 9 19:41:51 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17F8AE73 for ; Thu, 9 May 2013 19:41:51 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id D3F77E43 for ; Thu, 9 May 2013 19:41:50 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 7E9D3774D for ; Thu, 9 May 2013 21:41:46 +0200 (CEST) Message-ID: <518BFBF6.4040907@peterschmitt.fr> Date: Thu, 09 May 2013 21:41:42 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 CC: freebsd-net@FreeBSD.org Subject: Re: IPv6 configuration missunderstanding References: <518A6D5C.3030804@peterschmitt.fr> <20130510.041934.19893072298744952.hrs@allbsd.org> In-Reply-To: <20130510.041934.19893072298744952.hrs@allbsd.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MELBRJIMBKDOWLJJRQGF" 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, 09 May 2013 19:41:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MELBRJIMBKDOWLJJRQGF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 09/05/2013 21:19, Hiroki Sato a =E9crit : > Florent Peterschmitt wrote > in <518A6D5C.3030804@peterschmitt.fr>: >=20 > fl> Hi, > fl> > fl> I want to configure IPv6 in FreeBSD 9.1-RELEASE like this : > fl> > fl> ipv6_enable=3Dyes > fl> ipv6_activate_all_interfaces=3Dyes > fl> ifconfig_em0_ipv6=3D"inet6 2001:41D0:8:B81f:: prefixlen 64" > fl> -interface em0" > fl> ipv6_defaultrouter=3D"2001:41D0:8:B8ff:ff:ff:ff:ff" >=20 > Why the default router is not in 2001:41d0:8:b81f::/64? >=20 > fl> But at boot I have : > fl> > fl> default fe80::264:40ff:fe3a:fac0%em0 UG em0 >=20 > I guess this is provided by the router via Router Advertisement > messages. >=20 > fl> And if ipv6_enable=3Dyes is not here (although it's depreciated), n= o IPv6 > fl> at all. >=20 > Please remove ipv6_enable=3Dyes and ipv6_activate_all_interfaces=3Dyes= > unless you understand you really need them. >=20 > I think only the following line is sufficient for your environment: >=20 > ifconfig_em0_ipv6=3D"inet6 2001:41d0:8:b81f::1 prefixlen 64 accept_rta= dv" >=20 > -- Hiroki >=20 I found how to configure it: ip6addrctl_policy=3D"ipv6_prefer" ipv6_activate_all_interfaces=3Dyes ifconfig_em0_ipv6=3D"inet6 2001:41d0:8:b81f::1 prefixlen 64" ipv6_defaultrouter=3D"2001:41d0:8:b8ff:ff:ff:ff:ff" Router advertisement is disabled at OVH and the gateway is the given one. Well, everything is good now ;) --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2MELBRJIMBKDOWLJJRQGF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRi/v5AAoJEMtO2Sol0IIm0IcH/A9XrJECTXK2XmEeTn2FQEgM 0BHJAvgs1e7tPN8ax+kvOQ5ox2fz54CLmR+NvdACNhoSshyl3KwJ2QcreLb5GYQI hury33dRwtazR9DXRL83pVHOV0vykVXyisIdApAeVtuJ91hjVwpTM7lS5Z2e4GHE kNFrAxbhefQH8OE+fLw4IcCJpwHtHvpplrSI8wes7u4RUs9f06m6AfxssdagF5RK Rx5/aOcQ4U8rWY6vS6APsMYQhHVnZlJ330ZwuTef4IeVBkn+EBn0ebhzuooqYW42 dNcqoI18i6GCOUm2ghaAD6oCBU1dHGXzl8I84888/nXDyxvxyuNy+PjnLt4luDw= =39DB -----END PGP SIGNATURE----- ------enig2MELBRJIMBKDOWLJJRQGF-- From owner-freebsd-net@FreeBSD.ORG Thu May 9 19:51:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1F7D1353 for ; Thu, 9 May 2013 19:51:16 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 1A88DEB2 for ; Thu, 9 May 2013 19:51:14 +0000 (UTC) Received: from alph.d.allbsd.org (p2175-ipbf701funabasi.chiba.ocn.ne.jp [122.25.209.175]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r49JovJq077800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 May 2013 04:51:08 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r49JouQU059542; Fri, 10 May 2013 04:50:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 10 May 2013 04:49:31 +0900 (JST) Message-Id: <20130510.044931.944156092944449444.hrs@allbsd.org> To: florent@peterschmitt.fr Subject: Re: IPv6 configuration missunderstanding From: Hiroki Sato In-Reply-To: <518BFBF6.4040907@peterschmitt.fr> References: <518A6D5C.3030804@peterschmitt.fr> <20130510.041934.19893072298744952.hrs@allbsd.org> <518BFBF6.4040907@peterschmitt.fr> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_May_10_04_49_31_2013_611)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 10 May 2013 04:51:08 +0900 (JST) X-Spam-Status: No, score=-93.9 required=13.0 tests=CONTENT_TYPE_PRESENT, MIMEQENC,ONLY1HOPDIRECT,QENCPTR1,QENCPTR2,RCVD_IN_PBL,SAMEHELOBY2HOP, TO_NO_BRKTS_PCNT,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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: Thu, 09 May 2013 19:51:16 -0000 ----Security_Multipart(Fri_May_10_04_49_31_2013_611)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Florent Peterschmitt wrote in <518BFBF6.4040907@peterschmitt.fr>: fl> Le 09/05/2013 21:19, Hiroki Sato a =E9crit : fl> > Florent Peterschmitt wrote fl> > in <518A6D5C.3030804@peterschmitt.fr>: fl> > = fl> > fl> Hi, fl> > fl> fl> > fl> I want to configure IPv6 in FreeBSD 9.1-RELEASE like this : fl> > fl> fl> > fl> ipv6_enable=3Dyes fl> > fl> ipv6_activate_all_interfaces=3Dyes fl> > fl> ifconfig_em0_ipv6=3D"inet6 2001:41D0:8:B81f:: prefixlen 64" fl> > fl> -interface em0" fl> > fl> ipv6_defaultrouter=3D"2001:41D0:8:B8ff:ff:ff:ff:ff" fl> > = fl> > Why the default router is not in 2001:41d0:8:b81f::/64? fl> > = fl> > fl> But at boot I have : fl> > fl> fl> > fl> default fe80::264:40ff:fe3a:fac0%em0 UG em0 fl> > = fl> > I guess this is provided by the router via Router Advertisement fl> > messages. fl> > = fl> > fl> And if ipv6_enable=3Dyes is not here (although it's depreciat= ed), no IPv6 fl> > fl> at all. fl> > = fl> > Please remove ipv6_enable=3Dyes and ipv6_activate_all_interfaces= =3Dyes fl> > unless you understand you really need them. fl> > = fl> > I think only the following line is sufficient for your environme= nt: fl> > = fl> > ifconfig_em0_ipv6=3D"inet6 2001:41d0:8:b81f::1 prefixlen 64 acce= pt_rtadv" fl> > = fl> > -- Hiroki fl> > = fl> I found how to configure it: fl> = fl> ip6addrctl_policy=3D"ipv6_prefer" fl> ipv6_activate_all_interfaces=3Dyes fl> ifconfig_em0_ipv6=3D"inet6 2001:41d0:8:b81f::1 prefixlen 64" fl> ipv6_defaultrouter=3D"2001:41d0:8:b8ff:ff:ff:ff:ff" fl> = fl> Router advertisement is disabled at OVH and the gateway is the give= n fl> one. Well, everything is good now ;) So, why do you need ipv6_activate_all_interfaces=3Dyes? And, using an address on the different subnet as the default router is wrong even if it looks working. -- Hiroki ----Security_Multipart(Fri_May_10_04_49_31_2013_611)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlGL/csACgkQTyzT2CeTzy2f1ACgjTq/5kyZEjYoRs4zY+EyJw44 IN4AoIiNQavADI1f/vamz+HpHaYO9Oti =4fdw -----END PGP SIGNATURE----- ----Security_Multipart(Fri_May_10_04_49_31_2013_611)---- From owner-freebsd-net@FreeBSD.ORG Thu May 9 19:54:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F75A3FD for ; Thu, 9 May 2013 19:54:02 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id EC1DDEC9 for ; Thu, 9 May 2013 19:54:01 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 747F677AE for ; Thu, 9 May 2013 21:54:01 +0200 (CEST) Message-ID: <518BFED5.4000702@peterschmitt.fr> Date: Thu, 09 May 2013 21:53:57 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: IPv6 configuration missunderstanding References: <518A6D5C.3030804@peterschmitt.fr> <20130510.041934.19893072298744952.hrs@allbsd.org> <518BFBF6.4040907@peterschmitt.fr> <20130510.044931.944156092944449444.hrs@allbsd.org> In-Reply-To: <20130510.044931.944156092944449444.hrs@allbsd.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2UEHVWDHMLBDOCBNVJOQL" 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, 09 May 2013 19:54:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UEHVWDHMLBDOCBNVJOQL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 09/05/2013 21:49, Hiroki Sato a =E9crit : > Florent Peterschmitt wrote > fl> I found how to configure it: > fl>=20 > fl> ip6addrctl_policy=3D"ipv6_prefer" > fl> ipv6_activate_all_interfaces=3Dyes > fl> ifconfig_em0_ipv6=3D"inet6 2001:41d0:8:b81f::1 prefixlen 64" > fl> ipv6_defaultrouter=3D"2001:41d0:8:b8ff:ff:ff:ff:ff" > fl>=20 > fl> Router advertisement is disabled at OVH and the gateway is the give= n > fl> one. Well, everything is good now ;) >=20 > So, why do you need ipv6_activate_all_interfaces=3Dyes? >=20 > And, using an address on the different subnet as the default router > is wrong even if it looks working. >=20 > -- Hiroki >=20 I should use /56 prefix ? Even if my IPv6 is a /64 ? Does ipv6 configures automatically on lo0 without ipv6_activace_all_interfaces ? In that case, yes it is not necessary. --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2UEHVWDHMLBDOCBNVJOQL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRi/7YAAoJEMtO2Sol0IImF54H/iOnkBUf77eWN4IS0pC7RjJT qQCz4hAUVPKBZ3+AVy18Q17WjmS22Dml97e1Cu/tvGQMRRAU96yVkEi6lYD+WI/W lj0op/83zKEdjCN9n8ChjLKpXsm9bNVr4OmL8/fW08qlLMPU4AO8uio6xXTwYTOT Bi+JpF0UpeYv5CZEq52w6gtN+b+2To76pd6YAbFugM76ulLO02VYOyPOjgJEGz5V oX3ehOeTByBtUm2UhT2qaRfd6GMzHkHVb4JTtiZadub1m+7Cw7fO82rZnGM++rMk t9/oEGcGhhKkdXCzrBR3Qm63sVk6FFWfydGwOfeV/xp6PtnpViOsOtSCWLtD3qM= =Qll3 -----END PGP SIGNATURE----- ------enig2UEHVWDHMLBDOCBNVJOQL-- From owner-freebsd-net@FreeBSD.ORG Thu May 9 20:09:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5DA7D7BF for ; Thu, 9 May 2013 20:09:34 +0000 (UTC) (envelope-from florent@peterschmitt.fr) Received: from peterschmitt.fr (peterschmitt.fr [5.135.177.31]) by mx1.freebsd.org (Postfix) with ESMTP id 25FA8F48 for ; Thu, 9 May 2013 20:09:34 +0000 (UTC) Received: from [192.168.0.23] (4ab54-4-88-163-248-31.fbx.proxad.net [88.163.248.31]) by peterschmitt.fr (Postfix) with ESMTPSA id 9720177B7 for ; Thu, 9 May 2013 22:09:33 +0200 (CEST) Message-ID: <518C027C.5060905@peterschmitt.fr> Date: Thu, 09 May 2013 22:09:32 +0200 From: Florent Peterschmitt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: IPv6 configuration missunderstanding References: <518A6D5C.3030804@peterschmitt.fr> <20130510.041934.19893072298744952.hrs@allbsd.org> <518BFBF6.4040907@peterschmitt.fr> <20130510.044931.944156092944449444.hrs@allbsd.org> <518BFED5.4000702@peterschmitt.fr> In-Reply-To: <518BFED5.4000702@peterschmitt.fr> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2RGUNMUEIDOQRJKTDBMCP" 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, 09 May 2013 20:09:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RGUNMUEIDOQRJKTDBMCP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le 09/05/2013 21:53, Florent Peterschmitt a =E9crit : > I should use /56 prefix ? Even if my IPv6 is a /64 ? >=20 > Does ipv6 configures automatically on lo0 without > ipv6_activace_all_interfaces ? >=20 > In that case, yes it is not necessary. >=20 If fact, it is necessary to have ipv6_activate_all_interfaces. If not provided, the default route is bad. --=20 Florent Peterschmitt +33 (0)6 64 33 97 92 florent@peterschmitt.fr ------------------------ O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ------enig2RGUNMUEIDOQRJKTDBMCP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRjAJ8AAoJEMtO2Sol0IIm5FAIAI6TNcnT+jPpz+5xgsJYDPLq vkhybjzfzSIrKJvYCUsVaGBBV9IBo0QUp7zCeMJeOq+7b4roPrdzw9H9vdT8qT4P HkCQq42QimJouy1nf+0XWnt+MO21irGQ0qGzH7qLJkLlxal7eU7308qbDcQYRmHv LrcflSpBk7OETgR6bzTu+sYfMkj+SR4ZGYYdtiLfNgDVWK1lydfhOWeGYjWVGJ7s koxWNem7J9ri7nOd3LULx8F//DkUE8pBa92L0Qbo+0N1jNR+EG6gKGyTc5glGq2T SZ4Um9vju65C7JE03mRP5WXMPTbsmZbbvWsgQR906Swb1KPX+VdaHBzcCZJnZ2I= =Onsz -----END PGP SIGNATURE----- ------enig2RGUNMUEIDOQRJKTDBMCP-- From owner-freebsd-net@FreeBSD.ORG Thu May 9 22:19:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 712759B2 for ; Thu, 9 May 2013 22:19:48 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm4-vm4.bullet.mail.ne1.yahoo.com (nm4-vm4.bullet.mail.ne1.yahoo.com [98.138.91.164]) by mx1.freebsd.org (Postfix) with ESMTP id 11D82784 for ; Thu, 9 May 2013 22:19:47 +0000 (UTC) Received: from [98.138.90.53] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 09 May 2013 22:16:47 -0000 Received: from [98.138.88.237] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 09 May 2013 22:16:47 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 09 May 2013 22:16:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 277087.64684.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 20977 invoked by uid 60001); 9 May 2013 22:16:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368137807; bh=WzI4RZpMmSV8L0C4B9IqoR7Dv7zv5MDsfSMe2P9HpoI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6v/ZNOpdMKzQw0qjFmlziV30ipQ9XEoBpqmzhzu8dQ1T10Q3M8N31s37y4CpkjWmR2xWBrsyDZVqxjEkPbt/sg7zszFiTEEQ/urKuykQ359GypDRuFsmtYMPbpXKPOYPWIp/pze8F4EsCjVHmWxYlmJLuVsyX9kdcWiOw43Nxcs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=USpKoc3jQy9+J99t4hOITPF8V0BRXrBGDlvvp+A0blNoK2GzuGdIL2bIkoGnwrTMPhalBWjBtcs+nCIrC/EB1qlO3n8fGXtPRI8ZbuWCAKusT0utEiMz3vwOSRWi2D3bLNQ1dXH66GwPNApfDs6rbGExRo3UsfxfngvIZOoudrM=; X-YMail-OSG: uuKrIUYVM1m4g4vLPFYiXf1ap0Foff38LyAnOBJ4spljdaH IOIQ9W.xrk.6kuZ53JYxR9_ddUx8NXWdNlCGsStVz_WlIBQDQSzxO6kvtf.b 6QYRR8k8WxdF_wsoewKeWzr_Ur2yACq8g0.MR06Ni0zZ3x7lVYWOV1UjQTbF nYYazxE_OYVUGIOc1YtL5hCvhMEF1PaiajUoO4WBgD9Z97qRjgQcXRbM4Vcl lZ9.14IKZ9DjLaeL2Sj78gxbnTXJfGTxp6pPRl4IovPtilON0GQBMfRhm8Ci 53Av1MMQKszZZV1n4ge7XPkFW.Rt3a_4Gvtv8tsaADpvXtLy1dAp924DykEU vLJuF_q7EaXxksEXxU4J1iMpQJ5GsxIb_1LBS7swz74EL_U9ABPUru26I.e9 ty3fiRx_D4NN4UkKCoUkUwUXSdYVdAZacl6bbtu4PxWI9dtprZMZCaj0Z1yE gfkvyj_ZbKt.MAyAOg_WMZ0mhU.9br.1BjwGbU.aJFmDLM0S4daL4HeN_QMe IgX3YvUV0rU0ooU1g8D2.bS3._j7_3Q-- Received: from [98.203.118.124] by web121603.mail.ne1.yahoo.com via HTTP; Thu, 09 May 2013 15:16:47 PDT X-Rocket-MIMEInfo: 002.001, CgotLS0gT24gVGh1LCA1LzkvMTMsIEV1Z2VuZSBHcm9zYmVpbiA8ZWdyb3NiZWluQHJkdGMucnU.IHdyb3RlOgoKPiBGcm9tOiBFdWdlbmUgR3Jvc2JlaW4gPGVncm9zYmVpbkByZHRjLnJ1Pgo.IFN1YmplY3Q6IFJlOiBIaWdoIENQVSBpbnRlcnJ1cHQgbG9hZCBvbiBpbnRlbCBJMzUwVDQgd2l0aCBpZ2Igb24gOC4zCj4gVG86ICJCYXJuZXkgQ29yZG9iYSIgPGJhcm5leV9jb3Jkb2JhQHlhaG9vLmNvbT4KPiBDYzogIiJDbMOpbWVudCBIZXJtYW5uIChub2RlbnMpIiIgPG5vZGVuczIwOTlAZ21haWwuY29tPiwBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.141.536 Message-ID: <1368137807.20874.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Thu, 9 May 2013 15:16:47 -0700 (PDT) From: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 To: Eugene Grosbein In-Reply-To: <518BCF2C.3080307@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= 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, 09 May 2013 22:19:48 -0000 =0A=0A--- On Thu, 5/9/13, Eugene Grosbein wrote:=0A=0A>= From: Eugene Grosbein =0A> Subject: Re: High CPU interr= upt load on intel I350T4 with igb on 8.3=0A> To: "Barney Cordoba" =0A> Cc: ""Cl=E9ment Hermann (nodens)"" , freebsd-net@freebsd.org=0A> Date: Thursday, May 9, 2013, 12:30 PM=0A>= On 09.05.2013 23:25, Barney Cordoba=0A> wrote:=0A> =0A> >> Network device = driver is not guilty here, that's=0A> just pf's=0A> >> contention=0A> >> ru= nning in igb's context.=0A> >>=0A> >> Eugene Grosbein=0A> > =0A> > They're = both at play. Single threadedness aggravates=0A> subsystems that =0A> > hav= e too many lock points.=0A> > =0A> > It can also be "solved" with using 1 q= ueue, because=0A> then you don't=0A> > have 4 queues going into a single th= read.=0A> =0A> Again, the problem is within pf(4)'s global lock, not in the= =0A> igb(4).=0A> =0A=0AAgain, you're wrong. It's not the bottleneck's fault= ; it's the fault of =0Athe multi-threaded code for only working properly wh= en there are no=0Abottlenecks.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Fri May 10 02:37:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 017EA6F8 for ; Fri, 10 May 2013 02:37:01 +0000 (UTC) (envelope-from delivery@mx.sailthru.com) Received: from mx-fab-e.sailthru.com (mx-fab-e.sailthru.com [65.39.215.63]) by mx1.freebsd.org (Postfix) with ESMTP id B72AB1E6 for ; Fri, 10 May 2013 02:37:00 +0000 (UTC) Received: from nyp1-jmailer24.sailthru.pvt (nyp1-jmailer24.sailthru.com [65.39.215.176]) by mx-fab-e.sailthru.com (Postfix) with ESMTP id 21D7E644E81 for ; Thu, 9 May 2013 19:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; t=1368153420; s=sailthru; d=fab.com; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:List-ID:List-Unsubscribe; bh=TGEPDcdwfP6ab0FVU3PNkT4kP0CJQW8etzSrapz8ZmE=; b=Z06AbfKeUfMWUC8mP3HPmRwRhaOqmk5S4dS8xNML52zYO8crlymKhWqYZX/JJN8y WmrcSH+ZTlGpwcbRJv9MI+m4IZEnno8lUlUYsuBL7RSKlMRXGwUpqDYq0kbAimDedzP xpqfYCVkWOL694Y3kVINlpjWpq/MS6kT832BIhF0= Date: Thu, 9 May 2013 22:37:00 -0400 (EDT) From: Fab To: freebsd-net@freebsd.org Message-ID: <20130510023700.518c5d4cd2f880997d000074@sailthru.com> Subject: Invite from munguti.jacinta66@yahoo.com to fab.com, daily design sales and inspirations MIME-Version: 1.0 X-TM-ID: 20130510023700.518c5d4cd2f880997d000074 X-Info: Message sent by sailthru.com customer fab X-Info: We do not permit unsolicited commercial email X-Info: Please report abuse by forwarding complete headers to X-Info: abuse@sailthru.com X-Mailer: sailthru.com X-IADB-IP: 65.39.215.63 X-IADB-IP-REVERSE: 63.215.39.65 X-IADB-URL: http://www.isipp.com/iadb.php X-Unsubscribe-Web: http://mailer.fab.com/oc/518c5d4caf850a6c80721e51518c5d4cd2f880997d000074/df04cce7 Content-Type: text/plain; charset=utf-8 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, 10 May 2013 02:37:01 -0000 =C2=A0 =C2=A0 =C2=A0 If you are unable to see this message, click here to viewTo ensure delivery to = your inbox, please add info@fab.com t= o your address book. =C2=A0 =C2=A0 Great News!freeb= sd-net@freebsd.org
Here's your exc= lusive invite from munguti.jacinta66@yahoo.com to register for the new= Fab.com provides daily design inspirations and sales from the w= orld's leading designers and manufacturers at= prices up to 70% off retail. About Help Contact Us Return Policy Sh= ipping Terms Priv= acy tw fb =C2=A0=20 You received this email because you are registered on fab.com with the emai= l address: freebsd-net@freebsd.org. We respect your privacy. View our privacy policy at http://fab.com/privacy/= . If you believe this has been sent to you in error, please safely unsubscr= ibe at http://mailer.fab.com/oc/518c5d4caf850a6c80721e51518c5d4cd2f880997d0= 00074/df04cce7. Fab.com Inc http://fab.com | 95 Morton Street, 8th Floor New York, NY 10014 From owner-freebsd-net@FreeBSD.ORG Fri May 10 05:03:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75A8C1DD for ; Fri, 10 May 2013 05:03:08 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 419ABD08 for ; Fri, 10 May 2013 05:03:08 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id ECD2117C5AC5 for ; Fri, 10 May 2013 02:03:04 -0300 (ADT) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 62770-03 for ; Fri, 10 May 2013 05:03:03 +0000 (UTC) Received: from Marc-Fourniers-Mac-mini.local (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id 838E617C5AC4 for ; Fri, 10 May 2013 02:03:03 -0300 (ADT) Message-ID: <518C7F85.3000405@hub.org> Date: Thu, 09 May 2013 22:03:01 -0700 From: "Marc G. Fournier" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: status of a tap device ... 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: Fri, 10 May 2013 05:03:08 -0000 Quick question ... is there a command I can run that will tell me if a tap device is open? I know I can do 'ifconfig tap0' and see the 'Opened by' line, but I want to do this within a perl script, for instance, akin to how I can use the fstat function to get information about a file ... Rather avoid re-creating the wheel, so to say, if its already been created ... Thx From owner-freebsd-net@FreeBSD.ORG Fri May 10 05:19:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A37338C for ; Fri, 10 May 2013 05:19:51 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 088A4D81 for ; Fri, 10 May 2013 05:19:50 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id 9so7281118iec.36 for ; Thu, 09 May 2013 22:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=u9AoySA4M3m8QTZnmHcM+Uz+gTl9hhqiIzoU+oKEqNY=; b=RFqtiQb+RSAKhYfphD3ZggLLjeKJ+a+aSX9w61vF4rFq/CNCFDhhSeyYiWzRrzYHBs 2yqQfBJyiiZ0hlFXMB8EPZH2EeBMQNGwPemFIfewyCZ5G8VF7IkTxWFIZaIvtr7XBJQF UkuqpfCcTq+a8PHLfiwja48rHQXnubFJf27ys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=u9AoySA4M3m8QTZnmHcM+Uz+gTl9hhqiIzoU+oKEqNY=; b=QlEru8tBSvsJOkm7q0PHJK/u9TvwF1HexcXNM/S8CgfOYRRx575vysAuPpjJhrUJQL epdK0I2jCLzysMbcP+W5vAyuHOIqJSnDmzBWxF3FWMiqjxMCjbv8hG6mFyS+zrMGAMcO hA6di3G5SCjWR8fdvcGAVxq40T+5rzdDwe9g4Q5aD4iSIOlCzcG2xanBb/S6mtVi4Eo+ KLpDAUD8wJ9/vOxcLYNI4xdLije1WU4lpxs1+opURV+Ve8X7drHuwUBMIx0CW+uuYW0H u0bXRLRRRPOLSw3qfpPqn//zim6ejU8rQzyfYUOulWSSZLxNGO7ftPWv4V21bbmFPAbh MOoA== X-Received: by 10.50.49.7 with SMTP id q7mr848848ign.6.1368163190671; Thu, 09 May 2013 22:19:50 -0700 (PDT) Received: from [192.168.30.77] (24-236-152-143.dhcp.aldl.mi.charter.com. [24.236.152.143]) by mx.google.com with ESMTPSA id d4sm2158175igc.3.2013.05.09.22.19.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 22:19:49 -0700 (PDT) References: <518C7F85.3000405@hub.org> Mime-Version: 1.0 (1.0) In-Reply-To: <518C7F85.3000405@hub.org> Message-Id: <746BAC62-DA57-4D4D-A7F4-46A1C74C73B6@DataIX.net> X-Mailer: iPhone Mail (10B329) From: Jason Hellenthal Subject: Re: status of a tap device ... Date: Fri, 10 May 2013 01:19:45 -0400 To: "Marc G. Fournier" X-Gm-Message-State: ALoCoQmXBfYrJBkf4L6npfVytYVQBZsc12drYVRNt1GUgr70no1IlSCZxAwdwY+m1vSbw0uQC9+m Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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, 10 May 2013 05:19:51 -0000 Ifconfig -v tap0 ? Does this work for you ? Also upon opening a tap... ifconfig tap create Will return the numeric portion of the tap that was created with $? So scripting it out it would be similar to... ifconfig tap create && export MYTUNIS=3D"$?" echo "tap$MYTAPIS" --=20 Jason Hellenthal IS&T Services Professional Inbox: jhellenthal@DataIX.net JJH48-ARIN On May 10, 2013, at 1:03, "Marc G. Fournier" wrote: >=20 > Quick question ... is there a command I can run that will tell me if a tap= device is open? I know I can do 'ifconfig tap0' and see the 'Opened by' li= ne, but I want to do this within a perl script, for instance, akin to how I c= an use the fstat function to get information about a file ... >=20 > Rather avoid re-creating the wheel, so to say, if its already been created= ... >=20 > Thx > _______________________________________________ > 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 May 10 05:33:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E1016AD for ; Fri, 10 May 2013 05:33:09 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7AAE19 for ; Fri, 10 May 2013 05:33:08 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id A65D6C0077B; Fri, 10 May 2013 02:33:04 -0300 (ADT) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 81574-01; Fri, 10 May 2013 05:33:02 +0000 (UTC) Received: from Marc-Fourniers-Mac-mini.local (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id E81FBC00772; Fri, 10 May 2013 02:33:00 -0300 (ADT) Message-ID: <518C8688.5040908@hub.org> Date: Thu, 09 May 2013 22:32:56 -0700 From: "Marc G. Fournier" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jason Hellenthal , freebsd-net@freebsd.org Subject: Re: status of a tap device ... References: <518C7F85.3000405@hub.org> <746BAC62-DA57-4D4D-A7F4-46A1C74C73B6@DataIX.net> In-Reply-To: <746BAC62-DA57-4D4D-A7F4-46A1C74C73B6@DataIX.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, 10 May 2013 05:33:09 -0000 Ended up finding the perl module: p5-Net-Ifconfig-Wrapper that does the trick ... Although your suggestinos are much appreciated below, the problem is that I have the tap devices, and bridge 'addm's happening on server reboot, but need to know which one is in use before starting up / using them for vBox ... Thank you for the response though ... On 2013-05-09 10:19 PM, Jason Hellenthal wrote: > Ifconfig -v tap0 ? Does this work for you ? > > Also upon opening a tap... > > ifconfig tap create > > Will return the numeric portion of the tap that was created with $? > > So scripting it out it would be similar to... > > ifconfig tap create && export MYTUNIS="$?" > > echo "tap$MYTAPIS" > > /-- / > > /*Jason Hellenthal*/ > > IS&T Services Professional > > Inbox: /jhellenthal@DataIX.net / > > JJH48-ARIN > > > > On May 10, 2013, at 1:03, "Marc G. Fournier" > wrote: > >> >> Quick question ... is there a command I can run that will tell me if >> a tap device is open? I know I can do 'ifconfig tap0' and see the >> 'Opened by' line, but I want to do this within a perl script, for >> instance, akin to how I can use the fstat function to get information >> about a file ... >> >> Rather avoid re-creating the wheel, so to say, if its already been >> created ... >> >> Thx >> _______________________________________________ >> 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 May 10 07:29:42 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 81D833C5 for ; Fri, 10 May 2013 07:29:42 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id E125462C for ; Fri, 10 May 2013 07:29:41 +0000 (UTC) Received: from alph.d.allbsd.org (p2175-ipbf701funabasi.chiba.ocn.ne.jp [122.25.209.175]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id r4A7THxv062773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 May 2013 16:29:28 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.5/8.14.5) with ESMTP id r4A7TFs7080289; Fri, 10 May 2013 16:29:17 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 10 May 2013 16:28:42 +0900 (JST) Message-Id: <20130510.162842.1050661389388959145.hrs@allbsd.org> To: chip@2bithacker.net Subject: Re: gre and MONITOR From: Hiroki Sato In-Reply-To: <20130508155446.GB95890@2bithacker.net> References: <20130508155446.GB95890@2bithacker.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Fri_May_10_16_28_42_2013_758)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Fri, 10 May 2013 16:29:28 +0900 (JST) X-Spam-Status: No, score=-93.8 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_ZERO,ONLY1HOPDIRECT,QENCPTR1,RCVD_IN_PBL,SAMEHELOBY2HOP, TO_NO_BRKTS_PCNT,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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, 10 May 2013 07:29:42 -0000 ----Security_Multipart0(Fri_May_10_16_28_42_2013_758)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_May_10_16_28_42_2013_496)--" Content-Transfer-Encoding: 7bit ----Next_Part(Fri_May_10_16_28_42_2013_496)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chip Marshall wrote in <20130508155446.GB95890@2bithacker.net>: ch> It appears the MONITOR flag doesn't work on gre interfaces. ch> ch> I have a GRE tunnel set up between a FreeBSD 8.2-RELEASE box and a ch> Juniper router. ch> ch> Config on the FreeBSD end: ch> ch> gre0: flags=4b051 metric 0 mtu 1476 ch> tunnel inet 10.162.163.133 --> 10.162.163.131 ch> inet6 fe80::20c:29ff:fe9f:de64%gre0 prefixlen 64 scopeid 0x6 ch> inet 10.200.0.2 --> 10.200.0.1 netmask 0xfffffffc ch> nd6 options=3 ch> ch> Config on the Juniper end: ch> ch> tunnel { ch> source 10.162.163.131; ch> destination 10.162.163.133; ch> } ch> family inet { ch> address 10.200.0.1/30; ch> } ch> ch> And from the Juniper, I am able to ping the 10.200.0.2 IP on the ch> FreeBSD end of the GRE tunnel. As I understand it, this shouldn't ch> happen with the MONITOR flag there, right? The attached patch should fix this. Can you try it? -- Hiroki ----Next_Part(Fri_May_10_16_28_42_2013_496)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gre_monitor-20130510-1.diff" Index: sys/net/if_gre.c =================================================================== --- sys/net/if_gre.c (revision 250243) +++ sys/net/if_gre.c (working copy) @@ -341,6 +341,12 @@ if (bpf_peers_present(ifp->if_bpf)) bpf_mtap2(ifp->if_bpf, &af, sizeof(af), m); + if ((ifp->if_flags & IFF_MONITOR) != 0) { + m_freem(m); + error = ENETDOWN; + goto end; + } + m->m_flags &= ~(M_BCAST|M_MCAST); if (sc->g_proto == IPPROTO_MOBILE) { Index: sys/netinet/ip_gre.c =================================================================== --- sys/netinet/ip_gre.c (revision 250243) +++ sys/netinet/ip_gre.c (working copy) @@ -205,6 +205,11 @@ bpf_mtap2(GRE2IFP(sc)->if_bpf, &af, sizeof(af), m); } + if ((GRE2IFP(sc)->if_flags & IFF_MONITOR) != 0) { + m_freem(m); + return(NULL); + } + m->m_pkthdr.rcvif = GRE2IFP(sc); netisr_queue(isr, m); @@ -287,6 +292,11 @@ bpf_mtap2(GRE2IFP(sc)->if_bpf, &af, sizeof(af), m); } + if ((GRE2IFP(sc)->if_flags & IFF_MONITOR) != 0) { + m_freem(m); + return; + } + m->m_pkthdr.rcvif = GRE2IFP(sc); netisr_queue(NETISR_IP, m); ----Next_Part(Fri_May_10_16_28_42_2013_496)---- ----Security_Multipart0(Fri_May_10_16_28_42_2013_758)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlGMoaoACgkQTyzT2CeTzy1JHgCgtZ+Q5wvReZchhVvmgFKoZz4h hrAAoNuzFRP6XClkmWX8MOUaTgtC9BvH =RRDz -----END PGP SIGNATURE----- ----Security_Multipart0(Fri_May_10_16_28_42_2013_758)---- From owner-freebsd-net@FreeBSD.ORG Fri May 10 12:10:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A3AB3D9; Fri, 10 May 2013 12:10:03 +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 E74D03FF; Fri, 10 May 2013 12:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r4ACA2Q7014232; Fri, 10 May 2013 12:10:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r4ACA2Dp014231; Fri, 10 May 2013 12:10:02 GMT (envelope-from linimon) Date: Fri, 10 May 2013 12:10:02 GMT Message-Id: <201305101210.r4ACA2Dp014231@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/178472: [ip6] [patch] make return code consistent with IPv4 code 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, 10 May 2013 12:10:03 -0000 Old Synopsis: make return code consistent with IPv4 code New Synopsis: [ip6] [patch] make return code consistent with IPv4 code Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 10 12:09:35 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=178472 From owner-freebsd-net@FreeBSD.ORG Fri May 10 12:57:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72B98220 for ; Fri, 10 May 2013 12:57:06 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id E5604820 for ; Fri, 10 May 2013 12:57:03 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r4ACuweB015544; Fri, 10 May 2013 19:56:59 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <518CEE95.7020702@rdtc.ru> Date: Fri, 10 May 2013 19:56:53 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <1368137807.20874.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1368137807.20874.YahooMailClassic@web121603.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?UTF-8?B?IkNsw6ltZW50IEhlcm1hbm4gKG5vZGVucyki?= 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, 10 May 2013 12:57:06 -0000 On 10.05.2013 05:16, Barney Cordoba wrote: >>>> Network device driver is not guilty here, that's >> just pf's >>>> contention >>>> running in igb's context. >>> >>> They're both at play. Single threadedness aggravates >> subsystems that >>> have too many lock points. >>> >>> It can also be "solved" with using 1 queue, because >> then you don't >>> have 4 queues going into a single thread. >> >> Again, the problem is within pf(4)'s global lock, not in the >> igb(4). >> > > Again, you're wrong. It's not the bottleneck's fault; it's the fault of > the multi-threaded code for only working properly when there are no > bottlenecks. In practice, the problem is easily solved without any change in the igb code. The same problem will occur for other NIC drivers too - if several NICs were combined within one lagg(4). So, driver is not guilty and solution would be same - eliminate bottleneck and you will be fine and capable to spread the load on several CPU cores. Therefore, I don't care of CS theory for this particular case. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri May 10 13:05:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 93CB32F4 for ; Fri, 10 May 2013 13:05:09 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from nm36-vm3.bullet.mail.bf1.yahoo.com (nm36-vm3.bullet.mail.bf1.yahoo.com [72.30.238.139]) by mx1.freebsd.org (Postfix) with ESMTP id 48EEF84C for ; Fri, 10 May 2013 13:05:08 +0000 (UTC) Received: from [98.139.212.151] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 10 May 2013 13:05:01 -0000 Received: from [98.139.212.227] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 May 2013 13:05:01 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 10 May 2013 13:05:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 875024.86374.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 67542 invoked by uid 60001); 10 May 2013 13:05:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368191101; bh=sti9WMiN/0qt5eh4lD3J5lyML8rTWCOKISOY3Zm4U7o=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=QHy1vcCSo+qZ5hkXjVLZaLRFYjTPpkHLfNdzmRCmVqTKS205r6k/H92Ipnp+tQBzfdFMhSf+EEFaHzJAOYHDA/dveSx0o8REoAmxJYGA+RQiotBOAwB99qHxY5f5ap6CjXbQSo2PMYNFZXyQEyBHibY1T9kxV4/gtKxVqPiVMBs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=HW9M0OK7V/n8gjJ8E6dAwWiImCitXNK5ZgudauCvInUWAL0IY+uQJJ3goVZirTDzTp/i6n9MqcV2GE8yhOXVivpmVvH4qmIaRpgOox8AGrPnDfPCfKJ48fR6PGzvtGZdR/DWtfRDToMxfsO//iLv/+X4x1Nc4muZQcb17sji+J4=; X-YMail-OSG: zv.8UwIVM1nU8_4LvPy49Mfc8ogGsRbM7A_qaRGCCoTOMS5 pl4bCQ98AAc7g5sVv3iKWtaBKHN44UAyTYk8obvLUZBY05acFNuT4XJNQzM4 yv7jY6XvLy27qZ5sWOcWC0Bw.8tMpZMnQcRYvFXt1ZCE3liAtS4DMGYO5qAF P6pT6xZB6Qn6PD.TSldtac0yQLdgmEgcV4D0ykHaZybeNMU.0ZqtSpmveYXc WxAUgNPN9qiB5051.Q_IHR2QtVU8ZD1aqy3KZQw84j.lo1w1oABdJWrglcx9 WoqIVTXpxnOBSn0kPCkGfNvhzw8PM5Cl42KihhOzIelPPZ8tn3WcfBxW_iTf RTDlQN4b4zWzXFeofat5SDtP5uC0bq8u.PUzYjdXRbvcGxn_3p4TIrelNMDd _v1rZXNZvMl1RetX0hVf2h9eZE7TwSSdlfJUdP8vYh1OCLzgi3BB_8zTeV3v ixd3RlYGh.JG_wzMlcLob8yzeuFZ2dRHCo55J Received: from [89.165.120.140] by web165006.mail.bf1.yahoo.com via HTTP; Fri, 10 May 2013 06:05:01 PDT X-Rocket-MIMEInfo: 002.001, aGksCgpJIGhhdmUgYSBGcmVlQlNEIDguMiBzZXJ2ZXIgd2l0aCBzb21lIGVtICYgaWdiIGludGVyZmFjZXMuIChlbSBkcml2ZXIgdmVyc2lvbiBpcyA3LjMuMiAmIGlnYiBkcml2ZXIgdmVyc2lvbiBpcyAyLjMuMSkKSXQgZG9lc24ndCBoYXZlIGEgZnVsbC1sb2FkIHRyYWZmaWMgb24gaXQgKG1heGltdW0gNTAtMTAwTWJwcyBwZXItaW50ZXJmYWNlIG9uIDFHYnBzIGludGVyZmFjZSkuIGJ1dCBvY2Nhc2lvbmFsbHkgb25lIG9mIGl0cyBpbnRlcmZhY2VzIHN0b3BwZWQgcmVzcG9uZGluZyAobW9zdGx5ICJlbSIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 Message-ID: <1368191101.66470.YahooMailNeo@web165006.mail.bf1.yahoo.com> Date: Fri, 10 May 2013 06:05:01 -0700 (PDT) From: "M. V." To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 Reply-To: "M. V." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 13:05:09 -0000 hi,=0A=0AI have a FreeBSD 8.2 server with some em & igb interfaces. (em dri= ver version is 7.3.2 & igb driver version is 2.3.1)=0AIt doesn't have a ful= l-load traffic on it (maximum 50-100Mbps per-interface on 1Gbps interface).= but occasionally one of its interfaces stopped responding (mostly "em") an= d when I log in to server and ping the other side from it, i got "no buffer= space=A0available" error. and I have to do a "ifconfig em0 down; ifconfig = em0 up" to solve the problem.=0Arelated buffer sizes seem more than enough = for existing low traffic on server:=0Akern.ipc.nmbclusters=3D1000000=0Akern= .ipc.maxsockbuf=3D4000000=0Anet.inet.tcp.sendbuf_max=3D16777216=0Anet.inet.= tcp.recvbuf_max=3D16777216=0Anet.inet.tcp.sendspace=3D1000000=0Anet.inet.tc= p.recvspace=3D1000000=0Anet.inet.udp.recvspace=3D1000000=0A=0Ahw.igb.rxd=3D= 1024=0Ahw.igb.txd=3D1024=0Ahw.em.rxd=3D1024=0Ahw.em.txd=3D1024=0A=0Aproblem= is, most of the time I'm not at the server when it happens and I can't upd= ate it's kernel for now (although I don't even know if it helps). So I want= ed to write a simple shell =A0that gets executed in background and everytim= e this problem happened on an interface, it automatically "down/up"s it to = make it work.=0A=0Aso my question is:=0A1- how can I discover if an interfa= ce's buffer is filled out, and "no buffer space available" situation is hap= pened on that interface?=0A2- I know "down/up"ing interface is not an ideal= work to do, but it's the only solution I can think of. any other suggestio= ns?=0A=0A=0Athank you. From owner-freebsd-net@FreeBSD.ORG Fri May 10 13:07:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 77F0B445 for ; Fri, 10 May 2013 13:07:37 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from nm40-vm7.bullet.mail.bf1.yahoo.com (nm40-vm7.bullet.mail.bf1.yahoo.com [72.30.239.215]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6A5879 for ; Fri, 10 May 2013 13:07:36 +0000 (UTC) Received: from [98.139.212.151] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 10 May 2013 13:07:30 -0000 Received: from [98.139.212.232] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 10 May 2013 13:07:30 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 10 May 2013 13:07:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 233559.87757.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 36441 invoked by uid 60001); 10 May 2013 13:07:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368191249; bh=TtEn1/X9JMFeJc1hM6rxR18yJKR4LSLhMJu5VnXIdFA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=01BuaptxofgR3qAprkPcNLvf828I5J1rOU5RGUFDW41v1JotzpMuK53eIR5pLLez6mzYfT26oIZ/0vucafpcfpM55fuehFy+C0snCN8LZE4za3PltRwJEuMik5WQDRpIuMjJlVH9dhOyBp3k4NtqU3+xFnxul8rVAEHYOBx64GE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=j/Us9KtU50l++XcSu6UrdJr4lKqU8AhI3AmsxnXGBjVOk+3LLA6Q5IFMMQz7aY61lDaxCNSjRhq3vvWOhktJm9rmj4zxHErhG96YQmxKzEhlOFq6flDiu7cKGBiSETMdcP1RgIUviygBUBM2I2aEXTahFZoh1BmqMiz7uMO9lwM=; X-YMail-OSG: Ci5SXtYVM1li3lbr15CxEICkJMQ8uFIA_wA.1qIPqAfOJLb 4QJF58X4QAgzx5YP3PkDSuHkRL34eXjppwNftNMNfLFT5RIR.f3BsT_ow._J .zrJfrYMxkMDAk.x2E8lnGnupzwy3OQVYsVJNidURM2PACzEj5qZnLiyYLFG YamlyybQ6mOwaigst5MvGm54n6gLKyaEmI.ZB.B_5HphAH3FA11x2u2eaDLQ yvav5kSrPFzkNHEDDojlSf.jmXU_2DViSjlS6_hprR5G8BtsX8PyCS3OFd5G 8xpOVwSOG2cLA8DyYZ722cQIcT8XhYA2R1Tf.5rKveC9ZZRn7MANH858lqZK 2h5e4iJU0Mpr3gb4deeTUlEfEe_KnCKkdNiuP6FXHPB1rVf0h7.GxymZ0J6E jObMaZUE1jIMci503FqMzm57BAsyog6Ls9R96ZyEr52ZZeebcVVXskbx.Vy6 FPF_5nfGbun0MnzfpCYCQtDCcQc6V1T1OmEQEUgZv8.5N2m6G2qalnAz7Eng - Received: from [89.165.120.140] by web165001.mail.bf1.yahoo.com via HTTP; Fri, 10 May 2013 06:07:29 PDT X-Rocket-MIMEInfo: 002.001, aGksCgpJIGhhdmUgYSBGcmVlQlNEIDguMiBzZXJ2ZXIgd2l0aCBzb21lIGVtICYgaWdiIGludGVyZmFjZXMuIChlbSBkcml2ZXIgdmVyc2lvbiBpcyA3LjMuMiAmIGlnYiBkcml2ZXIgdmVyc2lvbiBpcyAyLjMuMSkKSXQgZG9lc24ndCBoYXZlIGEgZnVsbC1sb2FkIHRyYWZmaWMgb24gaXQgKG1heGltdW0gNTAtMTAwTWJwcyBwZXItaW50ZXJmYWNlIG9uIDFHYnBzIGludGVyZmFjZSkuIGJ1dCBvY2Nhc2lvbmFsbHkgb25lIG9mIGl0cyBpbnRlcmZhY2VzIHN0b3BwZWQgcmVzcG9uZGluZyAobW9zdGx5ICJlbSIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: <1368191101.66470.YahooMailNeo@web165006.mail.bf1.yahoo.com> Message-ID: <1368191249.23733.YahooMailNeo@web165001.mail.bf1.yahoo.com> Date: Fri, 10 May 2013 06:07:29 -0700 (PDT) From: "M. V." Subject: "no buffer space available" problem To: "freebsd-net@freebsd.org" In-Reply-To: <1368191101.66470.YahooMailNeo@web165006.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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 Reply-To: "M. V." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 13:07:37 -0000 hi,=0A=0AI have a FreeBSD 8.2 server with some em & igb interfaces. (em dri= ver version is 7.3.2 & igb driver version is 2.3.1)=0AIt doesn't have a ful= l-load traffic on it (maximum 50-100Mbps per-interface on 1Gbps interface).= but occasionally one of its interfaces stopped responding (mostly "em") an= d when I log in to server and ping the other side from it, i got "no buffer= space=A0available" error. and I have to do a "ifconfig em0 down; ifconfig = em0 up" to solve the problem.=0Arelated buffer sizes seem more than enough = for existing low traffic on server:=0Akern.ipc.nmbclusters=3D1000000=0Akern= .ipc.maxsockbuf=3D4000000=0Anet.inet.tcp.sendbuf_max=3D16777216=0Anet.inet.= tcp.recvbuf_max=3D16777216=0Anet.inet.tcp.sendspace=3D1000000=0Anet.inet.tc= p.recvspace=3D1000000=0Anet.inet.udp.recvspace=3D1000000=0A=0Ahw.igb.rxd=3D= 1024=0Ahw.igb.txd=3D1024=0Ahw.em.rxd=3D1024=0Ahw.em.txd=3D1024=0A=0Aproblem= is, most of the time I'm not at the server when it happens and I can't upd= ate it's kernel for now (although I don't even know if it helps). So I want= ed to write a simple shell =A0that gets executed in background and everytim= e this problem happened on an interface, it automatically "down/up"s it to = make it work.=0A=0Aso my question is:=0A1- how can I discover if an interfa= ce's buffer is filled out, and "no buffer space available" situation is hap= pened on that interface?=0A2- I know "down/up"ing interface is not an ideal= work to do, but it's the only solution I can think of. any other suggestio= ns?=0A=0A=0Athank you. From owner-freebsd-net@FreeBSD.ORG Fri May 10 16:02:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE362822 for ; Fri, 10 May 2013 16:02:51 +0000 (UTC) (envelope-from jbiskofski@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id DB4ED36C for ; Fri, 10 May 2013 16:02:50 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id z12so4270998wgg.35 for ; Fri, 10 May 2013 09:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=PiCDKI0yYUF8tphHEBFPr8/wD+TyEV2Unw0QgQCm3o4=; b=zgDzvPw/4q3/CvFd1KukrfkmqRv1+cKUFK7r7te89uJ6/ADIVeE9BG6Sw7NDXoTvhL cA1KfXsXfQ7nVTNjUPSC0cG7ouQH9x0XP0sL4v+rw2bUfY7UWjTWQkZM3BTfoUE58g2d 9EcxvqOWo00umMU7yT19kaSMZtNoULkfKXEcErMtEF0IjvRbeJHznYuKrBtJD/NkEsLD zC/SJPzECrUoKh/H1AricDer2dkld2l4X6zrZdmGeeMdCsc8zMgUYlZYz5FK0ZcH6zVJ ldq6ivcZUiNRyFzQNEINdSvan7k7BpvQamJBqenjf2KkyChVfECVWsTeRybjkGc1xmYX v92w== MIME-Version: 1.0 X-Received: by 10.180.90.164 with SMTP id bx4mr4895699wib.13.1368201770016; Fri, 10 May 2013 09:02:50 -0700 (PDT) Received: by 10.194.9.231 with HTTP; Fri, 10 May 2013 09:02:49 -0700 (PDT) Date: Fri, 10 May 2013 11:02:49 -0500 Message-ID: Subject: MPD5 - Can't establish VPN connection from windows to FreeBSD MPD5 Server From: jbiskofski 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, 10 May 2013 16:02:51 -0000 Hey Everyone, I just cant get this to work. I would appreciate any suggestions. My FreeBSD Version : *algebraix@node01:/home/algebraix % uname -a * *FreeBSD node01.algebraix.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64* * * My MPD5 Version : *algebraix@node01:/home/algebraix % mpd5 --version* *Version 5.6 (root@node01.algebraix.com 17:03 9-May-2013)* * * My mpd.conf file : *algebraix@node01:/home/algebraix % cd /usr/local/etc/mpd5/* *algebraix@node01:/usr/local/etc/mpd5 % cat mpd.conf * *startup:* * set console close* * set web close* * * *default:* * load pptp_server* * * *pptp_server:* * set ippool add pool1 10.0.3.240 10.0.3.250* * create bundle template B* * set iface enable proxy-arp* * set iface idle 1800* * set iface enable tcpmssfix* * set ipcp yes vjcomp* * set ipcp ranges 10.0.3.254/32 ippool pool1* * set ipcp dns 8.8.8.8* * set bundle enable compression* * * * set ccp yes mppc* * set mppc yes e40* * set mppc yes e128* * set mppc yes stateless* * * * create link template L pptp* * set link action bundle B* * set link enable multilink* * set link yes acfcomp protocomp* * set link no pap chap* * set link enable chap* * set link keep-alive 10 60* * set link mtu 1460* * set pptp self em1* * set link enable incoming* * set link fsm-timeout 5* mpd.secret file contents : *root@node01:/usr/local/etc/mpd5 # cat mpd.secret * *user1 "NOT-THE-REAL-PASSWORD"* And this is my sad result : *root@node01:/usr/local/etc/mpd5 # mpd5 * *Multi-link PPP daemon for FreeBSD* * * *process 67438 started, version 5.6 (root@node01.algebraix.com 17:03 9-May-2013)* *web: web is not running* *PPTP: waiting for connection on 66.85.188.122 1723* *[L] log +all* *[L] EVENT: Processing event EVENT_READ ConsoleSessionReadEvent() done* *EVENT: Processing event EVENT_READ PptpCtrlListenEvent()* *PPTP: Incoming control connection from 187.162.54.172 51112 to 66.85.188.122 1723* *pptp0: ctrl state FREE --> IDLE* *pptp0: attached to connection with 187.162.54.172 51112* *EVENT: Registering event EVENT_READ PptpCtrlReadCtrl() at pptp_ctrl.c:930* *EVENT: Registering event EVENT_READ PptpCtrlReadCtrl() done at pptp_ctrl.c:930* *EVENT: Stopping timer "(null)" (null)() at pptp_ctrl.c:1680* *EVENT: Starting timer "PptpIdle" PptpCtrlIdleTimeout() for 60000 ms at pptp_ctrl.c:1683* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() at timer.c:50* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() done at timer.c:50* *EVENT: Processing event EVENT_READ PptpCtrlListenEvent() done* *EVENT: Processing event EVENT_READ PptpCtrlReadCtrl()* *pptp0: read 12 bytes ctrl data* * 00 9c 00 01 1a 2b 3c 4d 00 01 00 00 .....+ ESTABLISHED* *pptp0: send StartCtrlConnReply msg* * len=0x9c msgType=1 magic=0x1a2b3c4d type=2* * vers=0x100 result=1 err=0 frameCap=3 bearCap=3 maxChan=0* * firm=0x101 host="node01.algebraix.com" vend="FreeBSD MPD"* *pptp0: wrote 156 bytes ctrl data* * 00 9c 00 01 1a 2b 3c 4d 00 02 00 00 01 00 01 00 .....+ WAIT_ANSWER* *[L-1] Accepting PPTP connection* *EVENT: Message 1 to LinkMsg() sent* *EVENT: Processing event EVENT_READ PptpCtrlReadCtrl() done* *EVENT: Processing event EVENT_READ MsgEvent()* *EVENT: Message 1 to LinkMsg() received* *[L-1] Link: OPEN event* *[L-1] LCP: Open event* *[L-1] LCP: state change Initial --> Starting* *EVENT: Stopping timer "(null)" (null)() at fsm.c:190* *[L-1] LCP: LayerStart* *EVENT: Message 1 to PhysMsg() sent* *EVENT: Message 1 to LinkMsg() processed* *EVENT: Message 1 to PhysMsg() received* *[L-1] device: OPEN event* *[L-1] PPTP: attaching to peer's outgoing call* *pptp0-0: chan state WAIT_ANSWER --> ESTABLISHED* *pptp0: send OutCallReply msg* * len=32 msgType=1 magic=0x1a2b3c4d type=8* * cid=0xfa27 peerCid=0xdba1 result=1 err=0 cause=0 speed=0xfa00* * recvWin=16 ppd=1 channel=0* *pptp0: wrote 32 bytes ctrl data* * 00 20 00 01 1a 2b 3c 4d 00 08 00 00 fa 27 db a1 .....+ Req-Sent* *[L-1] LCP: phase shift DEAD --> ESTABLISH* *EVENT: Stopping timer "(null)" (null)() at fsm.c:531* *[L-1] LCP: SendConfigReq #1* * [L-1] ACFCOMP* *[L-1] PROTOCOMP* *[L-1] MRU 1500* *[L-1] MAGICNUM 387e07ae* *[L-1] AUTHPROTO CHAP MSOFTv2* *[L-1] MP MRRU 2048* *[L-1] MP SHORTSEQ* *[L-1] ENDPOINTDISC [802.1] 00 25 90 3c 63 24* *[L-1] xmit frame to link proto=0xc021* * ff 03 c0 21 01 01 00 26 08 02 07 02 01 04 05 dc ...!...&........* * 05 06 38 7e 07 ae 03 05 c2 23 81 11 04 08 00 12 ..8~.....#......* * 02 13 09 03 00 25 90 3c 63 24 .....%. Stopped* *EVENT: Stopping timer "LCP" FsmTimeout() at fsm.c:190* *EVENT: Unregistering event EVENT_TIMEOUT TimerExpires() at timer.c:83* *EVENT: Unregistering event EVENT_TIMEOUT TimerExpires() done at timer.c:83* *[L-1] LCP: LayerFinish* *EVENT: Stopping timer "(null)" (null)() at auth.c:681* *EVENT: Stopping timer "(null)" (null)() at pap.c:64* *EVENT: Stopping timer "(null)" (null)() at chap.c:93* *EVENT: Stopping timer "(null)" (null)() at chap.c:94* *EVENT: Stopping timer "(null)" (null)() at eap.c:146* *EVENT: Stopping timer "(null)" (null)() at eap.c:147* * EVENT: Message 2 to PhysMsg() sent* *EVENT: Processing event EVENT_READ LinkNgDataEvent() done* *EVENT: Processing event EVENT_READ MsgEvent()* *EVENT: Message 2 to PhysMsg() received* *[L-1] device: CLOSE event* *pptp0-0: clearing call* *pptp0: send CallDiscNotify msg* * len=0x94 msgType=1 magic=0x1a2b3c4d type=13* * cid=0xfa27 result=3 err=0 cause=0 stats=""* *pptp0: wrote 148 bytes ctrl data* * 00 94 00 01 1a 2b 3c 4d 00 0d 00 00 fa 27 03 00 .....+ Closed* *EVENT: Stopping timer "LCP" FsmTimeout() at fsm.c:190* *[L-1] LCP: Down event* *[L-1] LCP: state change Closed --> Initial* * [L-1] LCP: phase shift ESTABLISH --> DEAD* *EVENT: Message 5 to LinkMsg() sent* *EVENT: Stopping timer "LCP" FsmTimeout() at fsm.c:190* *EVENT: Message 5 to LinkMsg() sent* *pptp0-0: chan state ESTABLISHED --> DYING* *EVENT: Starting timer "PptpKillCh" (void (*)(void *))PptpCtrlFreeChan() for 0 ms at pptp_ctrl.c:1594* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() at timer.c:50* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() done at timer.c:50* *EVENT: Starting timer "PptpUnused" (void (*)(void *))PptpCtrlCloseCtrl() for 10000 ms at pptp_ctrl.c:1601* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() at timer.c:50* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() done at timer.c:50* *EVENT: Message 2 to PhysMsg() processed* *EVENT: Message 5 to LinkMsg() received* *[L-1] Link: SHUTDOWN event* *[L-1] Link: Shutdown* *EVENT: Message 5 to LinkMsg() processed* * EVENT: Message 5 to LinkMsg() received* *EVENT: Message 5 to LinkMsg() processed* *EVENT: Processing event EVENT_READ MsgEvent() done* *EVENT: Processing event EVENT_TIMEOUT TimerExpires()* * EVENT: Processing timer "PptpKillCh" (void (*)(void *))PptpCtrlFreeChan()* *EVENT: Processing timer "PptpKillCh" (void (*)(void *))PptpCtrlFreeChan() done* *EVENT: Processing event EVENT_TIMEOUT TimerExpires() done* *EVENT: Processing event EVENT_READ MsgEvent()* *EVENT: Processing event EVENT_READ MsgEvent() done* *EVENT: Processing event EVENT_READ PptpCtrlReadCtrl()* *pptp0: read 12 bytes ctrl data* * 00 10 00 01 1a 2b 3c 4d 00 03 00 00 .....+ IDLE* *pptp0: send StopCtrlConnReply msg* * len=16 msgType=1 magic=0x1a2b3c4d type=4* * result=1 err=0* *pptp0: wrote 16 bytes ctrl data* * 00 10 00 01 1a 2b 3c 4d 00 04 00 00 01 00 00 00 .....+ DYING* *pptp0: killing connection with 187.162.54.172 51112* *EVENT: Unregistering event (null) at pptp_ctrl.c:1442* *EVENT: Unregistering event (null) done at pptp_ctrl.c:1442* *EVENT: Unregistering event EVENT_READ PptpCtrlReadCtrl() at pptp_ctrl.c:1443* * EVENT: Unregistering event EVENT_READ PptpCtrlReadCtrl() done at pptp_ctrl.c:1443* *EVENT: Stopping timer "PptpIdle" PptpCtrlIdleTimeout() at pptp_ctrl.c:1444* *EVENT: Unregistering event EVENT_TIMEOUT TimerExpires() at timer.c:83* *EVENT: Unregistering event EVENT_TIMEOUT TimerExpires() done at timer.c:83* *EVENT: Stopping timer "PptpUnused" (void (*)(void *))PptpCtrlCloseCtrl() at pptp_ctrl.c:1445* *EVENT: Unregistering event EVENT_TIMEOUT TimerExpires() at timer.c:83* *EVENT: Unregistering event EVENT_TIMEOUT TimerExpires() done at timer.c:83* *EVENT: Starting timer "PptpKill" (void (*)(void *))PptpCtrlFreeCtrl() for 0 ms at pptp_ctrl.c:1455* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() at timer.c:50* *EVENT: Registering event EVENT_TIMEOUT TimerExpires() done at timer.c:50* *EVENT: Processing event EVENT_READ PptpCtrlReadCtrl() done* *EVENT: Processing event EVENT_TIMEOUT TimerExpires()* *EVENT: Processing timer "PptpKill" (void (*)(void *))PptpCtrlFreeCtrl()* *EVENT: Processing timer "PptpKill" (void (*)(void *))PptpCtrlFreeCtrl() done* *EVENT: Processing event EVENT_TIMEOUT TimerExpires() done* In my windows 7 box I get an error 619, I also tried connecting from a windows XP machine and got the same result. Thanks everyone. - Jose from Mexico From owner-freebsd-net@FreeBSD.ORG Fri May 10 17:11:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08F13721; Fri, 10 May 2013 17:11:16 +0000 (UTC) (envelope-from chip@2bithacker.net) Received: from mail.2bithacker.net (kyzoku.2bithacker.net [208.65.173.123]) by mx1.freebsd.org (Postfix) with ESMTP id D2DC7A66; Fri, 10 May 2013 17:11:15 +0000 (UTC) Received: from 2bithacker.net (nat-04-mht.dyndns.com [216.146.45.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chip) by mail.2bithacker.net (Postfix) with ESMTPSA id 690CE4FBFE; Fri, 10 May 2013 13:11:08 -0400 (EDT) Date: Fri, 10 May 2013 13:11:04 -0400 From: Chip Marshall To: Hiroki Sato Subject: Re: gre and MONITOR Message-ID: <20130510171103.GB7444@2bithacker.net> Mail-Followup-To: chip@2bithacker.net, Hiroki Sato , freebsd-net@FreeBSD.org References: <20130508155446.GB95890@2bithacker.net> <20130510.162842.1050661389388959145.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <20130510.162842.1050661389388959145.hrs@allbsd.org> X-OS: Mac OS X 10.8.3 x86_64 up 23 days 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 Reply-To: chip@2bithacker.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:11:16 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-05-10, Hiroki Sato sent: > Chip Marshall wrote > ch> It appears the MONITOR flag doesn't work on gre interfaces. >=20 > The attached patch should fix this. Can you try it? Appears to work for what I need it for, thank you! --=20 Chip Marshall http://2bithacker.net/ --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (Darwin) iEYEARECAAYFAlGNKicACgkQnTUxIUPEgZ48PgCfRo/K+1s0wU8EjdG/eaXCfXA2 UoEAn3hn+rhSdzlhqem642MCaSN2qeMX =uwN/ -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-net@FreeBSD.ORG Fri May 10 22:01:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C64F6BAE; Fri, 10 May 2013 22:01:26 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEC3A6E; Fri, 10 May 2013 22:01:26 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id h14so2414532eaj.38 for ; Fri, 10 May 2013 15:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=g24a3WSoSsjEy1TNQkpaPa5qshYH034HLATct2Q6apo=; b=fklh9dobpehwRkFdjvpzQuZ2c9IayRH18Yo4hnlF0DfrOZO0ZNOF2dQc9jL2oieQOf HtgpNNOJBiQCnotM8+ZAyLJtgSZUTqokng1/vW3yEFDZpa+iKVsNUqONiH6p4UCkLfN5 FPqkcVeE7zJCqvgaRrqKoErvq3iG/VXk16/LsCST1ueeus5j013sty3B6XlnmCtBIFoJ /CcmVq60VbqnqLXOtMrEUVRJbG4h6UJdnvLE3skraPeKeFGDorF81wpkKM9eIktwBGDI EISQREJf8ggBd7SdgLt7NAMTsexO6YdQG0L7McJk/b8rH185976nV1n7T5lM0itUPspS mcIQ== MIME-Version: 1.0 X-Received: by 10.14.42.9 with SMTP id i9mr45898190eeb.18.1368223285362; Fri, 10 May 2013 15:01:25 -0700 (PDT) Received: by 10.223.76.134 with HTTP; Fri, 10 May 2013 15:01:25 -0700 (PDT) Date: Fri, 10 May 2013 15:01:25 -0700 Message-ID: Subject: anyone running the ofed code From: Vijay Singh To: hackers@freebsd.org, "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, 10 May 2013 22:01:26 -0000 Apologies for the cross post. Were trying out the ofed code and running into some issues, so would love to discuss. -vijay From owner-freebsd-net@FreeBSD.ORG Sat May 11 13:50:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED497C47 for ; Sat, 11 May 2013 13:50:56 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF31949 for ; Sat, 11 May 2013 13:50:56 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r4BDooIH022407; Sat, 11 May 2013 20:50:51 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <518E4CB5.4060105@rdtc.ru> Date: Sat, 11 May 2013 20:50:45 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: "M. V." Subject: Re: "no buffer space available" problem References: <1368191101.66470.YahooMailNeo@web165006.mail.bf1.yahoo.com> <1368191249.23733.YahooMailNeo@web165001.mail.bf1.yahoo.com> In-Reply-To: <1368191249.23733.YahooMailNeo@web165001.mail.bf1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 11 May 2013 13:50:57 -0000 On 10.05.2013 20:07, M. V. wrote: > hi, > > I have a FreeBSD 8.2 server with some em & igb interfaces. (em driver version is 7.3.2 & igb driver version is 2.3.1) > It doesn't have a full-load traffic on it (maximum 50-100Mbps per-interface on 1Gbps interface). but occasionally one of its interfaces stopped responding (mostly "em") and when I log in to server and ping the other side from it, i got "no buffer space available" error. and I have to do a "ifconfig em0 down; ifconfig em0 up" to solve the problem. The problem is known and fixed in recent versions. Just upgrade to 8.3 or 8.4-STABLE or 9.1 From owner-freebsd-net@FreeBSD.ORG Sat May 11 13:54:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EB11ECF2 for ; Sat, 11 May 2013 13:54:14 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2967296F for ; Sat, 11 May 2013 13:54:13 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r4BDsBh0022426; Sat, 11 May 2013 20:54:12 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <518E4D7E.4050404@rdtc.ru> Date: Sat, 11 May 2013 20:54:06 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: jbiskofski Subject: Re: MPD5 - Can't establish VPN connection from windows to FreeBSD MPD5 Server References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Sat, 11 May 2013 13:54:15 -0000 On 10.05.2013 23:02, jbiskofski wrote: > Hey Everyone, > > I just cant get this to work. I would appreciate any suggestions. It seems GRE protocol is blocked in the direction from mpd5 server to client. You should blame your provider. Or change VPN type from PPtP to L2TP that uses UDP only, not GRE. From owner-freebsd-net@FreeBSD.ORG Sat May 11 15:59:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 529AAA1E for ; Sat, 11 May 2013 15:59:02 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm37-vm3.bullet.mail.ne1.yahoo.com (nm37-vm3.bullet.mail.ne1.yahoo.com [98.138.229.131]) by mx1.freebsd.org (Postfix) with ESMTP id EE397E0B for ; Sat, 11 May 2013 15:59:00 +0000 (UTC) Received: from [98.138.226.180] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 11 May 2013 15:56:38 -0000 Received: from [98.138.89.244] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 11 May 2013 15:56:37 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 11 May 2013 15:56:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 658195.68110.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 70714 invoked by uid 60001); 11 May 2013 15:56:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1368287797; bh=PSXfxDGODSpbzcxPpHOC64S7zaKG7JAlslm3p2fZn+g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wFHME/MRJZf8xu9l5GzEUan0VbezMI0SjUGEBL6hCTEdENmfuD7kfIZoeY8RsjONsuW5iLv8oL9V52Y2qHur3s2ulpHRKOLHh+WhBirqKDdWAkr2hLV9R/CnQdUM5GjweON8zqgnfHlmdZ6NSNhbDT15hg8Xp35Cr5cF9Jg67wM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WJnNe/bGUxrRDV3TAtFKU4c+z2Xa2XZCW0WbMy2/hJzVo97WoK7ro4ee81PXz3LI6bOIYwhkKkEKFqmbr2KVTxu78CmOptgvi0gZprnHrbVPt4YrcLPdTsrqVCt1vuikSiyIDLNW7f37BHGWILWf7gJtsJyNyHGUme5zWXD93n8=; X-YMail-OSG: c9G26MAVM1k5sG1bdGOkqzvFvGR4EOUXC5i6oEKDafCceEC zX2P.vMo9_9iVeqCHz.5pm.xg47upvN80_djxaWG_A5vZ1X932M66.ltqGJi mtmPltsCvdGn.xLJmhbz3vQAoxJW_XbF3yQRGjZIM4F_wm_GvP.FBuBhOu1U 6kAXFsFpYV8tnA8HgdDsfEnE3rkHLNh4E0RUxPS6fw9I_mkQAzt4esOkQzmX eWa683lKU2a6Zd54aUr0heyRlN9Qa1aH9qp9JmeskuhzHA1hn2E6nQjLD3Jj P1iBgV5F6OqARc0840eJPr5wzdDtO4WPHtoA4dfVmvLBaID4KV8xC7vSg_LV WsLGKuUw5WBWKjLFhrhuRHi46Wo49vmsXla7C_bLTw_b80u_Pj2uHAO.CUo0 8liWpgHUZyw1uJ.1OAetD5J.pgo71j_IhQXPwM2N2l4JLTyB6pEpXUUnLPbf LuV836uHfZd62lNkz8qamfoL503KV6JtHarkfUg8UH03fD25O3N0q5.v6mIE l0e0hpt77JKV_aLNBDbiJXHOwnvuicA-- Received: from [98.203.118.124] by web121603.mail.ne1.yahoo.com via HTTP; Sat, 11 May 2013 08:56:37 PDT X-Rocket-MIMEInfo: 002.001, DQoNCi0tLSBPbiBGcmksIDUvMTAvMTMsIEV1Z2VuZSBHcm9zYmVpbiA8ZWdyb3NiZWluQHJkdGMucnU.IHdyb3RlOg0KDQo.IEZyb206IEV1Z2VuZSBHcm9zYmVpbiA8ZWdyb3NiZWluQHJkdGMucnU.DQo.IFN1YmplY3Q6IFJlOiBIaWdoIENQVSBpbnRlcnJ1cHQgbG9hZCBvbiBpbnRlbCBJMzUwVDQgd2l0aCBpZ2Igb24gOC4zDQo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.DQo.IENjOiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZywgIiJDbMOpbWVudCBIZXJtYW5uICgBMAEBAQE- X-Mailer: YahooMailClassic/15.1.8 YahooMailWebService/0.8.141.536 Message-ID: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Sat, 11 May 2013 08:56:37 -0700 (PDT) From: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 To: Eugene Grosbein In-Reply-To: <518CEE95.7020702@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, =?iso-8859-1?Q?Cl=E9ment_Hermann_=28nodens=29?= 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, 11 May 2013 15:59:02 -0000 --- On Fri, 5/10/13, Eugene Grosbein wrote: > From: Eugene Grosbein > Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org, ""Cl=E9ment Hermann (nodens)"" > Date: Friday, May 10, 2013, 8:56 AM > On 10.05.2013 05:16, Barney Cordoba > wrote: >=20 > >>>> Network device driver is not guilty here, > that's > >> just pf's > >>>> contention > >>>> running in igb's context. > >>> > >>> They're both at play. Single threadedness > aggravates > >> subsystems that=20 > >>> have too many lock points. > >>> > >>> It can also be "solved" with using 1 queue, > because > >> then you don't > >>> have 4 queues going into a single thread. > >> > >> Again, the problem is within pf(4)'s global lock, > not in the > >> igb(4). > >> > >=20 > > Again, you're wrong. It's not the bottleneck's fault; > it's the fault of=20 > > the multi-threaded code for only working properly when > there are no > > bottlenecks. >=20 > In practice, the problem is easily solved without any change > in the igb code. > The same problem will occur for other NIC drivers too - > if several NICs were combined within one lagg(4). So, driver > is not guilty and > solution would be same - eliminate bottleneck and you will > be fine and capable > to spread the load on several CPU cores. >=20 > Therefore, I don't care of CS theory for this particular > case. Clearly you don't understand the problem. Your logic is that because other drivers are defective also; therefore its not a driver problem? The problem is caused by a multi-threaded driver that haphazardly launches tasks and that doesn't manage the case that the rest of the system can't handle the load. It's no different than a driver that barfs when mbuf clusters are exhausted. The answer isn't to increase memory or mbufs, even though that may alleviate the problem. The answer is to fix the driver, so that it doesn't crash the system for an event that is wholly predictable= . igb has 1) too many locks and 2) exasperates the problem by binding to cpus, which causes it to not only have to wait for the lock to free, but=20 also for a specific cpu to become free. So it chugs along happily until=20 it encounters a bottleneck, at which point it quickly blows up the entire system in a domino effect. It needs to manage locks more efficiently, and also to detect when the backup is unmanageable. Ever since FreeBSD 5 the answer has been "it's fixed in 7, or its fixed in 9, or it's fixed in 10". There will always be bottlenecks, and no driver should blow up the system no matter what intermediate code may present a problem. Its the driver's responsibility to behave and to drop packets if necessary. BC From owner-freebsd-net@FreeBSD.ORG Sat May 11 20:12:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0421C17 for ; Sat, 11 May 2013 20:12:59 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 78198781 for ; Sat, 11 May 2013 20:12:59 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id q57so4992801wes.37 for ; Sat, 11 May 2013 13:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=biq3JpBKDoTTK1sIYqWUguduBYuza9VzNphy80Icq88=; b=Sgt97VBCh3iHktHcpwcAuLJc86Lftr8wbm3U861X63D8chSJQz7FjXB805ariw1X70 9rSPZeEBJKUxNf7Uu6RIyvFTYQcgryww9ywiWM+0RF0FaRyLwUDPqfn2WfcI4b9jXV03 nPD558cCvhLkPlVsMc6uM31Im03RNKniSbpYe6f+63fviKKSzJEHwtlVeOJ+omZhswvl 0MvjFyL8t3TRIw7tzin7w1WbjyGnDFmAUhBqXzdyPKTDPXLbM295l8Wdx4hfFSreUO0J Dkx4cCxmk29d7AbUfkx4c2HjEXT4bor+octgs+DL9ta+2FE7jU51LjwpYcO06LJ+rIyR J5Og== X-Received: by 10.180.183.133 with SMTP id em5mr10293997wic.26.1368303178628; Sat, 11 May 2013 13:12:58 -0700 (PDT) Received: from [192.168.2.30] ([2.176.140.14]) by mx.google.com with ESMTPSA id i4sm5703957wix.10.2013.05.11.13.12.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 May 2013 13:12:57 -0700 (PDT) Message-ID: <518EA643.5010505@gmail.com> Date: Sun, 12 May 2013 00:42:51 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 References: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> In-Reply-To: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, =?ISO-8859-1?Q?=22Cl=E9ment_Hermann_=28nodens=29=22?= , Eugene Grosbein 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, 11 May 2013 20:12:59 -0000 On 5/11/2013 8:26 PM, Barney Cordoba wrote: > Clearly you don't understand the problem. Your logic is that because other drivers are defective also; therefore its not a driver problem? The problem is caused by a multi-threaded driver that > haphazardly launches tasks and that doesn't manage the case that the rest of the system can't handle the load. It's no different than a driver that barfs when mbuf clusters are exhausted. The answer > isn't to increase memory or mbufs, even though that may alleviate the problem. The answer is to fix the driver, so that it doesn't crash the system for an event that is wholly predictable. igb has > 1) too many locks and 2) exasperates the problem by binding to cpus, which causes it to not only have to wait for the lock to free, but also for a specific cpu to become free. So it chugs along > happily until it encounters a bottleneck, at which point it quickly blows up the entire system in a domino effect. It needs to manage locks more efficiently, and also to detect when the backup is > unmanageable. Ever since FreeBSD 5 the answer has been "it's fixed in 7, or its fixed in 9, or it's fixed in 10". There will always be bottlenecks, and no driver should blow up the system no matter > what intermediate code may present a problem. Its the driver's responsibility to behave and to drop packets if necessary. BC And how the driver should behave? You suggest dropping the packets. Even if we accept that dropping packets is a good strategy in all configurations (which I doubt), the driver is definitely not the best place to implement it, since that involves duplication of similar code between drivers. Somewhere like the Ethernet layer is a much better choice to watch load of packets and drop them to prevent them to eat all the cores. Furthermore, ignoring the fact that pf is not optimized for multi-processors and blaming drivers for not adjusting themselves with the this pf's fault, is a bit unfair, I believe. -- Best regards. Hooman Fazaeli From owner-freebsd-net@FreeBSD.ORG Sat May 11 22:16:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1A1F542 for ; Sat, 11 May 2013 22:16:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 5A585CC8 for ; Sat, 11 May 2013 22:16:52 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id t59so4954637wes.38 for ; Sat, 11 May 2013 15:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XgYOixMomRppXxfWAd4occAcvmMaI6Wed3C9aTM/HRY=; b=hL08YB4TJH2+d+lxnn3coAYJOQ6OCd3ct6yVesT2GcXrVx3nz+duLvFLDUBVKoxLaL Jq+pF06Y6Tn8EJX4sRLtAx7oKR/l1LjOJEDj+5HC3NMcz144wsMAiWnT26EQVXJhYXNa 0cKT5CEsjSbPiZ+OBtJbZg/IIKPFGrJeAwkRyU/PEV0YU0k69E9F1KoLWL6onXMe2fHR 9HPH/DfbOcNWShi/z2lLRmOGNtBPa32DRzP7xzXaz1/wGH8WYMZpKd7+mQGTTmg9Kvlo b0x5g9pBZahNwDE4Zx2pjMYh6q4s9iHzdgnwdDfIGnDg7ObLut/F5wbR/ty+SVKXG97R 3rXw== MIME-Version: 1.0 X-Received: by 10.180.93.134 with SMTP id cu6mr10623580wib.8.1368310610801; Sat, 11 May 2013 15:16:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.58.138 with HTTP; Sat, 11 May 2013 15:16:50 -0700 (PDT) In-Reply-To: <518EA643.5010505@gmail.com> References: <1368287797.70288.YahooMailClassic@web121603.mail.ne1.yahoo.com> <518EA643.5010505@gmail.com> Date: Sat, 11 May 2013 15:16:50 -0700 X-Google-Sender-Auth: KiRihRTJJb2mW-CfzgJzDDkIfsQ Message-ID: Subject: Re: High CPU interrupt load on intel I350T4 with igb on 8.3 From: Adrian Chadd To: Hooman Fazaeli Content-Type: text/plain; charset=ISO-8859-1 Cc: Barney Cordoba , =?ISO-8859-1?B?IkNs6W1lbnQgSGVybWFubiAobm9kZW5zKSI=?= , Eugene Grosbein , 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: Sat, 11 May 2013 22:16:52 -0000 Hi, The motivation behind the locking scheme in igb in friends is for a very specific, userland-traffic-origin workload. Sure, it may or may not work well for forwarding/filtering workloads. If you want to fix it, let's have a discussion about how to do it, followed by some patches to do so. Adrian On 11 May 2013 13:12, Hooman Fazaeli wrote: > On 5/11/2013 8:26 PM, Barney Cordoba wrote: >> Clearly you don't understand the problem. Your logic is that because other drivers are defective also; therefore its not a driver problem? The problem is caused by a multi-threaded driver that >> haphazardly launches tasks and that doesn't manage the case that the rest of the system can't handle the load. It's no different than a driver that barfs when mbuf clusters are exhausted. The answer >> isn't to increase memory or mbufs, even though that may alleviate the problem. The answer is to fix the driver, so that it doesn't crash the system for an event that is wholly predictable. igb has >> 1) too many locks and 2) exasperates the problem by binding to cpus, which causes it to not only have to wait for the lock to free, but also for a specific cpu to become free. So it chugs along >> happily until it encounters a bottleneck, at which point it quickly blows up the entire system in a domino effect. It needs to manage locks more efficiently, and also to detect when the backup is >> unmanageable. Ever since FreeBSD 5 the answer has been "it's fixed in 7, or its fixed in 9, or it's fixed in 10". There will always be bottlenecks, and no driver should blow up the system no matter >> what intermediate code may present a problem. Its the driver's responsibility to behave and to drop packets if necessary. BC > > And how the driver should behave? You suggest dropping the packets. Even if we accept > that dropping packets is a good strategy in all configurations (which I doubt), the driver is > definitely not the best place to implement it, since that involves duplication of similar > code between drivers. Somewhere like the Ethernet layer is a much better choice to watch > load of packets and drop them to prevent them to eat all the cores. Furthermore, ignoring > the fact that pf is not optimized for multi-processors and blaming drivers for not adjusting > themselves with the this pf's fault, is a bit unfair, I believe. > > > -- > > Best regards. > Hooman Fazaeli > > _______________________________________________ > 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"