From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 16:57:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD4B106564A; Sun, 2 Sep 2012 16:57:01 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 24EF88FC12; Sun, 2 Sep 2012 16:57:01 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T8DTo-0005gW-A5; Sun, 02 Sep 2012 18:57:00 +0200 Date: Sun, 2 Sep 2012 18:57:00 +0200 From: Kurt Jaeger To: bug-followup@FreeBSD.org, peterjeremy@optushome.com.au Message-ID: <20120902165700.GA21474@home.opsec.eu> References: <20111230192212.GJ52832@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111230192212.GJ52832@home.opsec.eu> Cc: freebsd-net@freebsd.org Subject: Re: ports/124825: tcpdump/print-pfsync feature request submitted to tcpdump on sourceforge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 16:57:01 -0000 Hi! > I added some pointer to your PR at: > > https://sourceforge.net/tracker/?func=detail&atid=469576&aid=3467532&group_id=53066 The answer to that pointer was from http://sourceforge.net/users/guy_harris/ -------- I, at least, have no plan to include anything that requires that, in order to build tcpdump, a -I flag that points to a header file that's internal to some project's source tree rather than being installed under /usr/include. Unfortunately, both packet-pfsync.c and pf_print_state.c, in both that patch and in OpenBSD, will build only if the include path includes the source directory for the pfctl command, so I'm not going to do any more work on this until at least one OS makes all the required include files public headers installed in /usr/include or a directory under that. -------- So, if /usr/src/sbin/pfctl/Makefile would install pfctl.h and pfctl_parser.h into /usr/include/net, the tcpdump people would include print-pfsync.c. Any chance for this ? -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 17:12:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7DDE106566B; Sun, 2 Sep 2012 17:12:27 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 636B28FC15; Sun, 2 Sep 2012 17:12:27 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T8Dim-0005v1-SX; Sun, 02 Sep 2012 19:12:28 +0200 Date: Sun, 2 Sep 2012 19:12:28 +0200 From: Kurt Jaeger To: bug-followup@FreeBSD.org, peterjeremy@optushome.com.au Message-ID: <20120902171228.GA22730@home.opsec.eu> References: <20111230192212.GJ52832@home.opsec.eu> <20120902165700.GA21474@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120902165700.GA21474@home.opsec.eu> Cc: freebsd-net@freebsd.org Subject: Re: ports/124825: tcpdump/print-pfsync feature request submitted to tcpdump on sourceforge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 17:12:27 -0000 Hi! So, if /usr/src/sbin/pfctl/Makefile would install pfctl.h and pfctl_parser.h into /usr/include/net, the tcpdump people would include print-pfsync.c. Any chance for this ? -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 20:43:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E99B81065670; Sun, 2 Sep 2012 20:43:45 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 74AC38FC16; Sun, 2 Sep 2012 20:43:44 +0000 (UTC) Received: from aspire.rulingia.com (12.58.233.220.static.exetel.com.au [220.233.58.12]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q82Khcbd022917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Sep 2012 06:43:42 +1000 (EST) (envelope-from peter@rulingia.com) Received: from aspire.rulingia.com (localhost [127.0.0.1]) by aspire.rulingia.com (8.14.5/8.14.5) with ESMTP id q82KhUVx002704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Sep 2012 06:43:31 +1000 (EST) (envelope-from peter@aspire.rulingia.com) Received: (from peter@localhost) by aspire.rulingia.com (8.14.5/8.14.5/Submit) id q82KhUL4002703; Mon, 3 Sep 2012 06:43:30 +1000 (EST) (envelope-from peter) Date: Mon, 3 Sep 2012 06:43:29 +1000 From: Peter Jeremy To: Lev Serebryakov Message-ID: <20120902204329.GA2654@aspire.rulingia.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <1435570640.20120831001711@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <1435570640.20120831001711@serebryakov.spb.ru> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 (was: ipfw, "ip|all" proto and PPPoE -- does PPPoE packets passed to ipfw?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 20:43:46 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-31 00:17:11 +0400, Lev Serebryakov wrote: > Is it possible to use gprof with kernel? As here is no userland >processes involved: PPPoE is porcessed by netgrpah, routing & ipfw is >kernel stuff too... Since no-one else has mentioned it, see the '-p' option to config(8) and kgmon(8). There's also dtrace. --=20 Peter Jeremy --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBDxPEACgkQ/opHv/APuIeQOACeJrMdOehu7t5HQdlhYpDCa4Pr uewAniMM73mbQaKJg9smvnGFIbL0klS8 =ioRv -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 21:37:53 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85F7D1065670; Sun, 2 Sep 2012 21:37:53 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id F196A8FC18; Sun, 2 Sep 2012 21:37:52 +0000 (UTC) Received: from aspire.rulingia.com (12.58.233.220.static.exetel.com.au [220.233.58.12]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q82Lbo45023326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Sep 2012 07:37:51 +1000 (EST) (envelope-from peter@rulingia.com) Received: from aspire.rulingia.com (localhost [127.0.0.1]) by aspire.rulingia.com (8.14.5/8.14.5) with ESMTP id q82LUciA002928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Sep 2012 07:30:38 +1000 (EST) (envelope-from peter@aspire.rulingia.com) Received: (from peter@localhost) by aspire.rulingia.com (8.14.5/8.14.5/Submit) id q82LU8CV002925; Mon, 3 Sep 2012 07:30:08 +1000 (EST) (envelope-from peter) Date: Mon, 3 Sep 2012 07:29:52 +1000 From: Peter Jeremy To: Adrian Chadd Message-ID: <20120902212952.GB2654@aspire.rulingia.com> References: <20120830215147.GA2383@-> <20120831104532.GA1758@-> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kaltheat@googlemail.com, net@freebsd.org Subject: Re: lagg failover issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:37:53 -0000 --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Adrian, On 2012-Aug-31 04:29:53 -0700, Adrian Chadd wrote: >You can't override set the outbound MAC address of a wireless station. >It associates with the MAC address of the card/vap/device. The AP >_will_ store that MAC address in its node table. Are you saying I can't portably do the following: # ifconfig ath0 ether 00:11:22:33:44:55 # ifconfig create wlan0 wlandev ath0 ssid my_net up My understanding was that the first line changes the MAC associated with ath0. The second line then creates a wlan device and allows ath0 to associate with an AP with ssid "my_net" - and this association will be performed using the updated MAC address. Which part of this doesn't work? >What you really want is for the same IP to exist but only both >interfaces and have the source interface/MAC seamlessly change. Actually, lagg(4) requires all associated interfaces to have the same MAC address - it doesn't change them during operation. Normally, it updates the MAC address when it does the "addm" but this doesn't work for "addm wlan0" (presumably for the reasons you describe) but manually changing the MAC address of the WiFi NIC before creating the wlan device avoids this. --=20 Peter Jeremy --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBDz9AACgkQ/opHv/APuIccJwCgpPZRq5+BLx9rVWhs+V1C5i0N Tb4AnRL2b2F+0IfNMxbZDJO4+oRLlimo =yY6Q -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 21:50:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50919106564A for ; Sun, 2 Sep 2012 21:50:52 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from rush.bluerosetech.com (rush.bluerosetech.com [IPv6:2607:fc50:1000:9b00::25]) by mx1.freebsd.org (Postfix) with ESMTP id 20A5A8FC1C for ; Sun, 2 Sep 2012 21:50:52 +0000 (UTC) Received: from vivi.cat.pdx.edu (vivi.cat.pdx.edu [IPv6:2610:10:20:214::6]) by rush.bluerosetech.com (Postfix) with ESMTPSA id 18DF01142E for ; Sun, 2 Sep 2012 14:50:45 -0700 (PDT) Received: from [127.0.0.1] (c-76-27-220-79.hsd1.wa.comcast.net [76.27.220.79]) by vivi.cat.pdx.edu (Postfix) with ESMTPSA id 6909F24CD6 for ; Sun, 2 Sep 2012 14:50:43 -0700 (PDT) Message-ID: <5043D4B3.7010009@bluerosetech.com> Date: Sun, 02 Sep 2012 14:50:43 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.6esrpre) Gecko/20120713 Thunderbird/10.0.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: How to do both DHCPv4 and DHCPv6 at the same time? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 21:50:52 -0000 Comcast does IPv6 using DHCPv6 and DHCPv6-PD. At least in 8.3-p3, the in-base dhclient doesn't do DHCPv6. I installed the net/isc-dhcp42-client port and am successfully using as a workalike drop-in replacement with the following in /etc/rc.conf: dhclient_flags="-lf /var/db/dhclient.leases.${ifn} -pf /var/run/${name}.${ifn}.pid -cf /usr/local/etc/dhclient.conf" dhclient_program="/usr/local/sbin/dhclient" According to the port's dhclient man page, I need add "-6" to dhclient_flags to make dhclient do DHCPv6. The problem is the network scripts in the base don't differentiate between DHCPv6 and DHCPv4, so adding that would break my network config (or at least prevent the system from getting an IPv4 address). Writing my own RC script for this is completely the wrong solution, so I'm sure I'm overlooking something. What am I missing? From owner-freebsd-net@FreeBSD.ORG Sun Sep 2 22:26:05 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 105481065675; Sun, 2 Sep 2012 22:26:05 +0000 (UTC) (envelope-from sergv326@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52D9A8FC12; Sun, 2 Sep 2012 22:26:04 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so2656618lbb.13 for ; Sun, 02 Sep 2012 15:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:user-agent:in-reply-to:mime-version:content-type :content-transfer-encoding:subject:from:date:to:cc:message-id; bh=87UGpEyq22Wl42oHKNWhHJ49bJlOaIBzPnq5MhXt+3c=; b=jQQO3MlVnM0oRfSlizu+GPClg+Do54ViLfyeevCuwossxg+BBFheDL59GEe89805ke IQdZyykHCajafvofPbfWjpvbhLAkUAq57MVCv+jy4dQeePeETIeNmBGIafYKww7g/EgC +Z382SsxIR8tOUxxJCNKq4mfIzaguvdpu7gRznq5Li+TIsuc8Z258wNz000QRzfvtd+B 3upoX/2lTo5TaNqnvBVtj333P6EG4y2SQTTCdy3SF+1+9ECCHzxGiHR1vLzHnF3ekQ22 OvFzWBS3ng3/DhfDn8EKyMgAX48KvT8cn0STJKMIXBE+BkN4XqB9Y1Uc4hqg9i/U6oIH niGQ== Received: by 10.152.114.3 with SMTP id jc3mr12304204lab.11.1346624763191; Sun, 02 Sep 2012 15:26:03 -0700 (PDT) Received: from android-57e53d9003b75926.lan ([2.92.63.115]) by mx.google.com with ESMTPS id lx11sm11662909lab.4.2012.09.02.15.26.02 (version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 15:26:02 -0700 (PDT) References: <20120830215147.GA2383@-> <20120831104532.GA1758@-> <20120902212952.GB2654@aspire.rulingia.com> User-Agent: =?UTF-8?Q?K-9_Mail_=D0=B4=D0=BB=D1=8F_Android?= In-Reply-To: <20120902212952.GB2654@aspire.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Serg Date: Mon, 03 Sep 2012 02:25:57 +0400 To: Peter Jeremy ,Adrian Chadd Message-ID: Cc: kaltheat@googlemail.com, net@freebsd.org Subject: Re: lagg failover issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 22:26:05 -0000 Peter Jeremy написал(а): >Adrian, > >On 2012-Aug-31 04:29:53 -0700, Adrian Chadd wrote: >>You can't override set the outbound MAC address of a wireless station. >>It associates with the MAC address of the card/vap/device. The AP >>_will_ store that MAC address in its node table. > >Are you saying I can't portably do the following: > # ifconfig ath0 ether 00:11:22:33:44:55 > # ifconfig create wlan0 wlandev ath0 ssid my_net up > >My understanding was that the first line changes the MAC associated >with ath0. The second line then creates a wlan device and allows ath0 >to associate with an AP with ssid "my_net" - and this association will >be performed using the updated MAC address. Which part of this >doesn't work? > >>What you really want is for the same IP to exist but only both >>interfaces and have the source interface/MAC seamlessly change. > >Actually, lagg(4) requires all associated interfaces to have the same >MAC address - it doesn't change them during operation. Normally, it >updates the MAC address when it does the "addm" but this doesn't work >for "addm wlan0" (presumably for the reasons you describe) but >manually changing the MAC address of the WiFi NIC before creating the >wlan device avoids this. > >-- >Peter Jeremy You can change lagg MAC address to match your wlan MAC address but it changes nothing... From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 00:21:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B07D210656D3 for ; Mon, 3 Sep 2012 00:21:58 +0000 (UTC) (envelope-from pallingz30@vodafone.com.au) Received: from remote.islyft.is (remote.islyft.is [194.144.41.133]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6908FC0A for ; Mon, 3 Sep 2012 00:21:47 +0000 (UTC) Received: from [49.66.11.19] (account pallingz30@vodafone.com.au HELO napndmouvslauka.skdsh.ru) by remote.islyft.is (CommuniGate Pro SMTP 5.2.3) with ESMTPA id 152609748 for freebsd-net@freebsd.org; Mon, 3 Sep 2012 00:21:46 +0000 From: MyCustomer.com To: Date: Mon, 3 Sep 2012 00:21:46 +0000 MIME-Version: 1.0 X-Priority: 3 X-Mailer: pqwk-53 Message-ID: <7381367143.G556XGXR806633@pkofsy.ozalizegitiuxna.va> Content-Type: multipart/mixed; boundary="----=a__rzbzcl_52_41_25" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Four steps to global Facebook success X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 00:21:58 -0000 ------=a__rzbzcl_52_41_25 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Four steps to global Facebook success /* Based on The MailChi= mp Reset INLINE: Yes. */ /* Client-specific Styles */ #outlook a {pad= ding:0;} /* Force Outlook to provide a "view in browser" menu link. */ b= ody{width:100% !important; -webkit-text-size-adjust:100%; -ms-text-size-a= djust:100%; margin:0; padding:0;} /* Prevent Webkit and Windows Mobile = platforms from changing default font sizes.*/ .ExternalClass {width:100= %;} /* Force Hotmail to display emails at full width */ .ExternalClass= , .ExternalClass p, .ExternalClass span, .ExternalClass font, .ExternalCl= ass td, .ExternalClass div {line-height: 100%;} /* Forces Hotmail to dis= play normal line spacing. More on that: http://www.emailonacid.com/forum= /viewthread/43/ */ #backgroundTable {margin:0; padding:20; width:100% != important; line-height: 100% !important;} /* End reset */ /* Some sensi= ble defaults for images Bring inline: Yes. */ img {outline:none; text-d= ecoration:none; -ms-interpolation-mode: bicubic;} a img {border:none;} = .image_fix {display} /* Yahoo paragraph fix Bring inline: Yes. */ p = {margin: 1em 0;} /* Hotmail header color reset Bring inline: Yes. */ /= * Outlook 07, 10 Padding issue fix Bring inline: No.*/ table td {border= -collapse: collapse;} /* Styling your links has become much simpler with= the new Yahoo. In fact, it falls in line with the main credo of styling= in email and make sure to bring your styles inline. Your link colors wi= ll be uniform across clients when brought inline. Bring inline: Yes. */ = a {color: orange;} /***************************************************= **************************************************** MOBILE TARGETING = **************************************************** ******************= *********************************/ @media only screen and (max-device-wi= dth: 480px) { /* Part one of controlling phone number linking for mobil= e. */ a[href^=3D"tel"], a[href^=3D"sms"] { text-decoration: none; = color: blue; /* or whatever your want */ pointer-events: none; = cursor: default; } .mobile_link a[href^=3D"tel"], .mobile_link= a[href^=3D"sms"] { text-decoration: default; color: orange !im= portant; pointer-events: auto; cursor: default; } } /* Mo= re Specific Targeting */ @media only screen and (min-device-width: 768px= ) and (max-device-width: 1024px) { /* You guessed it, ipad (tablets, sma= ller screens, etc) */ /* repeating for the ipad */ a[href^=3D"tel"], = a[href^=3D"sms"] { text-decoration: none; color: blue; /* or wh= atever your want */ pointer-events: none; cursor: default; = } .mobile_link a[href^=3D"tel"], .mobile_link a[href^=3D"sms"] { t= ext-decoration: default; color: orange !important; pointer-even= ts: auto; cursor: default; } } @media only screen and (-webkit= -min-device-pixel-ratio: 2) { /* Put your iPhone 4g styles in here */ = } /* Android targeting */ @media only screen and (-webkit-device-pixel-= ratio:.75){ /* Put CSS for low density (ldpi) Android layouts in here */= } @media only screen and (-webkit-device-pixel-ratio:1){ /* Put CSS f= or medium density (mdpi) Android layouts in here */ } @media only scree= n and (-webkit-device-pixel-ratio:1.5){ /* Put CSS for high density (hdp= i) Android layouts in here */ } /* end Android targeting */ = = = = Four steps to global Facebook success! = Social networking = is a global phenomenon. A recent Forrester study showed three-quarters o= f Facebook users are now outside the United States. = It's not enough to focus social efforts on English-speaking consumers in= the United States and Europe through a one-size-fits-all approach. But t= he right strategy is not always obvious. = There are lots of questions to be answered - questions about language, c= ulture, localised knowledge, design and whether you need different pages = for different regions. We've attached th= is free guide which identifies four steps to makin= g your brand a global Facebook success. Find ou= t about the four steps to global Facebook success in the attached file. = = Copyright © 2012, Sift Media All rights reserved. = Sift Media Ltd, 6th Floor, 48-52 Baldwin Stre= et, Bristol BS1 1QB Company Registration No. 05923= 499 | Registered in England and Wales VAT No. 741 844 722 = Unsubscribe | = Contact us = ------=a__rzbzcl_52_41_25-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 02:41:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7143B106564A; Mon, 3 Sep 2012 02:41:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34CB28FC08; Mon, 3 Sep 2012 02:41:03 +0000 (UTC) Received: by dadr6 with SMTP id r6so3166767dad.13 for ; Sun, 02 Sep 2012 19:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=xjGKoprUldiNBfc4KLLyp4JBZvrTVx972rJa5vsWCEs=; b=zVCe7MmwWW4KjQ31IySvMYZ9EhXOMbiKS6P+7bWiiiLJ9gPA9gsHCopLQhOVb7BAdM E2vhRNIMBtX2l6Yp+HMrB3akj3M+FmDSjDyWgzlXgvDZTio9xjnoAfyPzPkE3HQhp+n4 84UngI7SQQTfuJBNhjDkzwpNQpT1oR6eiKeFo5NH8MQMexBWKiqTuXoYU2ZUe2w2egQu /hJKvRXYoKHUdaQ+q7fcIta28GK4QnWlXpo0pWmy5/HOvG/3fTRxcdWTt9GOV/n52vOa 4evJkoIIu8nicKHIyU6zZWd91bKN0F3tB+BQhCbi4H0A9jHWjGMKBFwycz0062iJl2uI CTwA== Received: by 10.68.241.226 with SMTP id wl2mr34151027pbc.62.1346640057039; Sun, 02 Sep 2012 19:40:57 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id kt1sm8838681pbc.45.2012.09.02.19.40.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 19:40:56 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 03 Sep 2012 11:40:49 -0700 From: YongHyeon PYUN Date: Mon, 3 Sep 2012 11:40:49 -0700 To: Eugene Grosbein Message-ID: <20120903184049.GB3730@michelle.cdnetworks.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50404F91.8080302@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 02:41:03 -0000 On Fri, Aug 31, 2012 at 12:45:53PM +0700, Eugene Grosbein wrote: > In previous letter I've described my attempts to try vr(4) from HEAD. > Now I'd like to explain why I've tried it. > > The problem is that stock vr(4) from 8.3-STABLE/i386 has serious issues for my system. > I have home router with two vr interfaces, vr0 is for LAN (IPoE) and vr1 is for WAN (PPPoE/mpd). > > Presently, every day my WAN vr interface stops running correctly: > sometimes it stops receiving all packets - tcpdump shows none of them. > Sometimes, it receives some but with great delay - up to 10 seconds (not miliseconds) > and even more. tcpdump shows that delay occurs on receive path. > Sometimes, it even rearranges packets - tcpdump shows that some incoming ICMP echo requests > with lower sequence numbers come in later that already answered higher-numbered requests. Hmm, it seems driver's consumer/producer index of RX path were corrupted. > > ifconfig vr1 down/up revives interface completely until next morning. > sysctl net.inet.ip.fw.enable=0 does not solve the problem. > > I have control over WAN switching/routing network and may assure it runs just fine. > However, I can't guarantee it has no "soft" anomalies like short storms or some silly broadcasts. > > I've tried to make incoming flood with ng_source(4) generated UDP flood at 100M rate > for 60 seconds and failed to reproduce the problem artificially. > > I've tried to move WAN from vr1 to vr0 and the problem has moved to vr0 too. > My LAN has very little traffic and corresponding vr interface exhibits no problems. > > This router also routinely runs transmission (torrent client from ports) > serving torrents from USB-attached HDD making severe CPU load, so I suspect > the problem may be related with CPU load. > > I've also checked mbuf/mbuf clusters usage and they are all right: > > # netstat -m > 1539/2076/3615 mbufs in use (current/cache/total) > 1200/1278/2478/65536 mbuf clusters in use (current/cache/total/max) > 1200/306 mbuf+clusters out of packet secondary zone in use (current/cache) > 318/181/499/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) > 4056K/3799K/7855K 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/4/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > # vmstat -z | egrep -i 'ITEM|mbuf' > ITEM SIZE LIMIT USED FREE REQUESTS FAILURES > mbuf_packet: 256, 0, 1429, 77, 112854470, 0 > mbuf: 256, 0, 489, 1620, 369073316, 0 > mbuf_cluster: 2048, 65536, 1506, 604, 5401864, 0 > mbuf_jumbo_page: 4096, 12800, 469, 158, 8306777, 0 > mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, 0 > mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, 0 > mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 > NetGraph items: 36, 4130, 1, 117, 263123, 0 > NetGraph data items: 36, 531, 0, 295, 106663377, 0 > > While ifconfig vr1 down/up solves the problem completely (for some long time), > taking link down/up using switch solves it "in half" - huge packet delays disappear > and turn to 25% packet loss happening in regular short intervals, once a second of like. > > ifconfig down/up clears this mess too. > > Please help me to debug this, it's pretty annoying. By chance, did vr(4) spew some kind of diagnostics messages to console? If I remember correctly, vr(4) automatically restarts controller and show these errors when it detects abnormal condition. Abnormal conditions for vr(4) would be: - TX/RX MAC stuck - RX MAC stop due to FIFO overflow or no RX buffers - PCI bus errors - TX abort - TX underrun > I had a hope new vr(4) driver would help but it takes my system down under average load > and is unusable. > > Here is start of 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 8.3-STABLE #1: Wed Aug 29 22:49:45 NOVT 2012 > root@grosbein.pp.ru:/usr/local/obj/nanobsd.gw/i386/usr/local/src/sys/GW i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Geode(TM) Integrated Processor by AMD PCS (499.91-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x5a2 Family = 5 Model = a Stepping = 2 > Features=0x88a93d > AMD Features=0xc0400000 > real memory = 1065025536 (1015 MB) > avail memory = 1032929280 (985 MB) > K6-family MTRR support enabled (2 registers) > > I must also note that this system runs with ACPI disabled in /boot/loader.conf: > hint.acpi.0.disabled=1 > > Otherwise, its timekeeping becomes broken. > > Eugene Gtosbein From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 04:56:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3531E106564A; Mon, 3 Sep 2012 04:56:44 +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 886358FC0C; Mon, 3 Sep 2012 04:56:43 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q834uegw030240; Mon, 3 Sep 2012 11:56:40 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <50443888.9080400@rdtc.ru> Date: Mon, 03 Sep 2012 11:56:40 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> In-Reply-To: <20120903184049.GB3730@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 04:56:44 -0000 04.09.2012 01:40, YongHyeon PYUN : >> Presently, every day my WAN vr interface stops running correctly: >> sometimes it stops receiving all packets - tcpdump shows none of them. >> Sometimes, it receives some but with great delay - up to 10 seconds (not miliseconds) >> and even more. tcpdump shows that delay occurs on receive path. >> Sometimes, it even rearranges packets - tcpdump shows that some incoming ICMP echo requests >> with lower sequence numbers come in later that already answered higher-numbered requests. > > Hmm, it seems driver's consumer/producer index of RX path were > corrupted. Have you any idea how to find that out for sure? Add some debug printfs or KASSERT, may be? I'm ready to test. > By chance, did vr(4) spew some kind of diagnostics messages to > console? If I remember correctly, vr(4) automatically restarts > controller and show these errors when it detects abnormal > condition. Abnormal conditions for vr(4) would be: > - TX/RX MAC stuck > - RX MAC stop due to FIFO overflow or no RX buffers > - PCI bus errors > - TX abort > - TX underrun > None. I've read its source and learned it prints its debug to the kernel dmesg buffer with sysctl dev.vr.1.stats=1 and done that before, during and after noted failure - all counters are zero except of good frames conters (in/out). Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 05:43:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 171B3106564A; Mon, 3 Sep 2012 05:43:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CDC238FC19; Mon, 3 Sep 2012 05:43:41 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7454542pbb.13 for ; Sun, 02 Sep 2012 22:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=RgMob0m3zZWLjIMWlI7lygFAicBJTNDadx1oMhWml3M=; b=G2lfFoIyfFqoh3sVSsIs6LS1zmm9Jkd3A6jWQr4JnoxN6pExSAbmyJKus8vueW6Zgp /XGeWKlnuMy72oamJXX2vpwaAVABU4/qANtFYZUXG8c9ZoUO2JDJcsv/Z/XMIpHOPg7H LljRhnzsd5TpzpvUyOPivswN3S1TEG3wlSY5vZOd18ruUHSL5Lti9UV9iTuwQKOd+D12 RtwkE8UnfOJSbeP0vz5pSEHGcTZye3GJbpEqbZm9Aa4mwA0p5j90k16SoUB+RHFXn06p 6zBZeQyWTva16wRFHawiL/f36UdPL8c2cRJXv6gdf+qjG9J2XK6+2lHZuXahf4C3oWhf CThA== Received: by 10.66.84.130 with SMTP id z2mr31532321pay.77.1346651021429; Sun, 02 Sep 2012 22:43:41 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id oc2sm9154599pbb.69.2012.09.02.22.43.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Sep 2012 22:43:40 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 03 Sep 2012 14:43:33 -0700 From: YongHyeon PYUN Date: Mon, 3 Sep 2012 14:43:33 -0700 To: Eugene Grosbein Message-ID: <20120903214333.GC3730@michelle.cdnetworks.com> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50443888.9080400@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 05:43:42 -0000 On Mon, Sep 03, 2012 at 11:56:40AM +0700, Eugene Grosbein wrote: > 04.09.2012 01:40, YongHyeon PYUN пишет: > > >> Presently, every day my WAN vr interface stops running correctly: > >> sometimes it stops receiving all packets - tcpdump shows none of them. > >> Sometimes, it receives some but with great delay - up to 10 seconds (not miliseconds) > >> and even more. tcpdump shows that delay occurs on receive path. > >> Sometimes, it even rearranges packets - tcpdump shows that some incoming ICMP echo requests > >> with lower sequence numbers come in later that already answered higher-numbered requests. > > > > Hmm, it seems driver's consumer/producer index of RX path were > > corrupted. > > Have you any idea how to find that out for sure? Sorry, no clue yet. The only wild guess I have at this moment is handling for VR_ISR_RX_NOBUF/VR_ISR_RX_OFLOW interrupt. It forces to restart RX MAC by reprogramming VR_RXADDR register. If driver is out of sync with hardware this may produce unexpected results. The VIA data sheet I have has no special comments on this as other VIA data sheets. > Add some debug printfs or KASSERT, may be? > I'm ready to test. > > > By chance, did vr(4) spew some kind of diagnostics messages to > > console? If I remember correctly, vr(4) automatically restarts > > controller and show these errors when it detects abnormal > > condition. Abnormal conditions for vr(4) would be: > > - TX/RX MAC stuck > > - RX MAC stop due to FIFO overflow or no RX buffers > > - PCI bus errors > > - TX abort > > - TX underrun > > > > None. I've read its source and learned it prints its debug > to the kernel dmesg buffer with sysctl dev.vr.1.stats=1 > and done that before, during and after noted failure - > all counters are zero except of good frames conters (in/out). Ok, it seems you didn't encounter TX/RX MAC shutdown/restart related issues. To get more verbose debugging messages, you have to define VR_SHOW_ERRORS in if_vr.c. BTW, I see really poor bulk TCP performance on vr(4) with CURRENT (< 12 Mbps). :-( This is a quad-port VT6105 with Core2 Duo E6550. Pre-r235334 restores the old good performance for me(> 86Mbps). However I can't explain how taskq change shows this huge difference. > > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 07:47:26 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A522F106564A; Mon, 3 Sep 2012 07:47:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7877A8FC0A; Mon, 3 Sep 2012 07:47:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q837lQxh047945; Mon, 3 Sep 2012 07:47:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q837lQgj047932; Mon, 3 Sep 2012 07:47:26 GMT (envelope-from linimon) Date: Mon, 3 Sep 2012 07:47:26 GMT Message-Id: <201209030747.q837lQgj047932@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171228: [re] [patch] if_re - eeprom write issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 07:47:26 -0000 Old Synopsis: [ patch ] if_re - eeprom write issues New Synopsis: [re] [patch] if_re - eeprom write issues Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 3 07:47:08 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171228 From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 08:27:42 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A103B106566B; Mon, 3 Sep 2012 08:27:42 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 564BD8FC08; Mon, 3 Sep 2012 08:27:42 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 7B7ADC4935; Mon, 3 Sep 2012 11:27:34 +0300 (EEST) Date: Mon, 3 Sep 2012 11:29:32 +0300 From: Aleksandr Rybalko To: Gleb Smirnoff Message-Id: <20120903112932.634df332.ray@dlink.ua> In-Reply-To: <20120830131057.GE90597@FreeBSD.org> References: <20120830131057.GE90597@FreeBSD.org> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: [CFT] if_transmit method for if_bridge(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:27:42 -0000 On Thu, 30 Aug 2012 17:10:57 +0400 Gleb Smirnoff wrote: >> Hi, >> >> I have a patch laying around, that makes if_bridge(4) utilize >> if_transmit method. That should improvide performance. >> >> I'd appreciate if someone who actually do use if_bridge(4) tests >> this patch. >> >> -- >> Totus tuus, Glebius. Hi Glebius, simple http fetch test give about of 10% of throughput: before ~59Mbps after ~65Mbps I'm not sure that results is precise, but I'm sure it gives few percent anyway. Seems no problem in configuration when wired network and wireless joined into bridge (typical AP). Thank you very much! Keep going! :) WBW -- Alexandr Rybalko aka Alex RAY From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 09:24:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59D15106564A; Mon, 3 Sep 2012 09:24:01 +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 AEE7C8FC15; Mon, 3 Sep 2012 09:24:00 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q839NuET032619; Mon, 3 Sep 2012 16:23:56 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5044772C.8090302@rdtc.ru> Date: Mon, 03 Sep 2012 16:23:56 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> In-Reply-To: <20120903214333.GC3730@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 09:24:01 -0000 04.09.2012 04:43, YongHyeon PYUN : >> None. I've read its source and learned it prints its debug >> to the kernel dmesg buffer with sysctl dev.vr.1.stats=1 >> and done that before, during and after noted failure - >> all counters are zero except of good frames conters (in/out). > > Ok, it seems you didn't encounter TX/RX MAC shutdown/restart > related issues. To get more verbose debugging messages, you have > to define VR_SHOW_ERRORS in if_vr.c. I'll try this evening. > BTW, I see really poor bulk TCP performance on vr(4) with CURRENT > (< 12 Mbps). :-( > This is a quad-port VT6105 with Core2 Duo E6550. Pre-r235334 > restores the old good performance for me(> 86Mbps). However I can't > explain how taskq change shows this huge difference. Have you tried to remove options PREEMPTING from the kernel for newest driver? That helped me a lot - performance of new driver returned to the level of old one. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 11:09:46 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AA6610656D6 for ; Mon, 3 Sep 2012 11:09:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4329E8FC21 for ; Mon, 3 Sep 2012 11:09:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q83B9kJP048705 for ; Mon, 3 Sep 2012 11:09:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83B9igF048333 for freebsd-net@FreeBSD.org; Mon, 3 Sep 2012 11:09:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2012 11:09:44 GMT Message-Id: <201209031109.q83B9igF048333@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 11:09:46 -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/171228 net [re] [patch] if_re - eeprom write issues o kern/170713 net [cxgb] Driver must be loaded after boot due to timing 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/169634 net [bge] Network unavailable when booting directly to Fre 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 o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not 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/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 416 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 11:51:59 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2947106564A; Mon, 3 Sep 2012 11:51:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 48BEE8FC19; Mon, 3 Sep 2012 11:51:59 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q83Bpvj9015141; Mon, 3 Sep 2012 15:51:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q83BpvT2015140; Mon, 3 Sep 2012 15:51:57 +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, 3 Sep 2012 15:51:57 +0400 From: Gleb Smirnoff To: Kurt Jaeger Message-ID: <20120903115157.GE9305@FreeBSD.org> References: <20111230192212.GJ52832@home.opsec.eu> <20120902165700.GA21474@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20120902165700.GA21474@home.opsec.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: peterjeremy@optushome.com.au, bug-followup@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: ports/124825: tcpdump/print-pfsync feature request submitted to tcpdump on sourceforge X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 11:51:59 -0000 On Sun, Sep 02, 2012 at 06:57:00PM +0200, Kurt Jaeger wrote: K> > I added some pointer to your PR at: K> > K> > https://sourceforge.net/tracker/?func=detail&atid=469576&aid=3467532&group_id=53066 K> K> The answer to that pointer was from K> http://sourceforge.net/users/guy_harris/ K> K> -------- K> I, at least, have no plan to include anything that requires that, in order K> to build tcpdump, a -I flag that points to a header file that's internal to K> some project's source tree rather than being installed under /usr/include. K> K> Unfortunately, both packet-pfsync.c and pf_print_state.c, in both that K> patch and in OpenBSD, will build only if the include path includes the K> source directory for the pfctl command, so I'm not going to do any more K> work on this until at least one OS makes all the required include files K> public headers installed in /usr/include or a directory under that. K> -------- K> K> So, if /usr/src/sbin/pfctl/Makefile would install pfctl.h and K> pfctl_parser.h into /usr/include/net, the tcpdump people would K> include print-pfsync.c. K> K> Any chance for this ? This is possible. May be in 10.0-RELEASE. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 18:26:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD8BC106564A; Mon, 3 Sep 2012 18:26:02 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1158FC16; Mon, 3 Sep 2012 18:26:01 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 76FC274815; Mon, 3 Sep 2012 20:25:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id Fo06Vgbq6R5F; Mon, 3 Sep 2012 20:25:52 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id ADECA7480B; Mon, 3 Sep 2012 20:25:52 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 9F02B19C16A; Mon, 3 Sep 2012 08:40:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id HTLd8if963i1; Mon, 3 Sep 2012 08:40:22 +0200 (CEST) Received: from [192.168.231.11] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 1192319C165; Mon, 3 Sep 2012 08:40:21 +0200 (CEST) Message-ID: <5044F62E.8030001@zirakzigil.org> Date: Mon, 03 Sep 2012 20:25:50 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, "freebsd-stable@freebsd.org" References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> <503E7A16.6030600@zirakzigil.org> In-Reply-To: <503E7A16.6030600@zirakzigil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 18:26:03 -0000 No idea anybody why this bug happens? Patches? On 08/29/2012 10:22 PM, Giulio Ferro wrote: > On 08/28/2012 11:12 AM, Damien Fleuriot wrote: >> Hi Giulio, >> >> >> >> Just to clear things up: >> igb0: 192.168.9.60/24 >> lagg0: 192.168.12.21/24 >> > > Yes. > Actually I notice now that the lagg0 address is different from what > I wrote below in my rc.conf (192.168.12.7). I've just made many test > with different configuration, but no matter, it just doesn't work... > > >> >> What's the IP of the host you're trying ssh connections from ? > > I'm just trying to connect to and from management interface igb0 > (192.168.9.60). > From external pc I do : ssh myuser@192.168.9.60 > From that server I do : ssh myuser@pcaddress > > Just to be more precise, the consequences are: > 1) daemon sshd on the server gets stuck and becomes unkillable > 2) the first connection may work, but then the program ssh on the > server becomes unresponsive and unkillable > > If I don't create a lagg0 interface and just connect (say) igb1 to > the data switch, I've no problem and everything works. > > Just to answer others' question, I connect igb1, igb2 and igb3 to the > same data switch in ports configured for aggregation. > I connect igb0 to another management switch (of course not configured > for aggregation) > > >> >> Also, just in case, did you enable any firewall ? (PF, ipfw) > > As I already said, no. Nothing is working/active on this server, just sshd. > > Thank you. > > >> >> >> >> On 27 August 2012 21:22, Giulio Ferro wrote: >>> Hi, thanks for the answer >>> >>> Here is what you asked for: >>> >>> # ifconfig igb0 >>> igb0: flags=8843 metric 0 mtu >>> 1500 >>> >>> options=4401bb >>> >>> ether ... >>> inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 >>> inet6 .... prefixlen 64 scopeid 0x1 >>> nd6 options=29 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> >>> >>> >>> # netstat -rn >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Netif >>> Expire >>> default 192.168.9.1 UGS 0 0 igb0 >>> 127.0.0.1 link#12 UH 0 0 lo0 >>> 192.168.9.0/24 link#1 U 0 14 igb0 >>> 192.168.9.60 link#1 UHS 0 0 lo0 >>> 192.168.12.0/24 link#13 U 0 109 lagg0 >>> 192.168.12.21 link#13 UHS 0 0 lo0 >>> >>> Internet6: >>> Destination Gateway Flags >>> Netif Expire >>> ::/96 ::1 >>> UGRS lo0 >>> ::1 link#12 >>> UH lo0 >>> ::ffff:0.0.0.0/96 ::1 >>> UGRS lo0 >>> fe80::/10 ::1 >>> UGRS lo0 >>> fe80::%igb0/64 link#1 U >>> igb0 >>> fe80::ea39:35ff:feb6:a0d4%igb0 link#1 >>> UHS lo0 >>> fe80::%igb1/64 link#2 U >>> igb1 >>> fe80::ea39:35ff:feb6:a0d5%igb1 link#2 >>> UHS lo0 >>> fe80::%igb2/64 link#3 U >>> igb2 >>> fe80::ea39:35ff:feb6:a0d6%igb2 link#3 >>> UHS lo0 >>> fe80::%igb3/64 link#4 U >>> igb3 >>> fe80::ea39:35ff:feb6:a0d7%igb3 link#4 >>> UHS lo0 >>> fe80::%lo0/64 link#12 U >>> lo0 >>> fe80::1%lo0 link#12 >>> UHS lo0 >>> fe80::%lagg0/64 link#13 U >>> lagg0 >>> fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 >>> UHS lo0 >>> ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 >>> U igb0 >>> ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 >>> U igb1 >>> ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 >>> U igb2 >>> ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 >>> U igb3 >>> ff01::%lo0/32 ::1 U >>> lo0 >>> ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >>> lagg0 >>> ff02::/16 ::1 >>> UGRS lo0 >>> ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 >>> U igb0 >>> ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 >>> U igb1 >>> ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 >>> U igb2 >>> ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 >>> U igb3 >>> ff02::%lo0/32 ::1 U >>> lo0 >>> ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >>> lagg0 >>> >>> >>> >>> # netstat -aln | grep 22 >>> tcp4 0 0 *.22 *.* LISTEN >>> tcp6 0 0 *.22 *.* LISTEN >>> >>> Note that I already tried to only listen on igb0 interface >>> (192.168.9.60) in >>> sshd_config, but the results are exactly >>> the same described below. >>> >>> >>> >>> >>> >>> >>> >>> On 08/25/2012 01:22 PM, Damien Fleuriot wrote: >>>> >>>> In the meantime kindly post: >>>> >>>> >>>> Ifconfig for your igb0 >>>> Netstat -rn >>>> Netstat -aln | grep 22 >>>> >>>> >>>> >>>> On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: >>>> >>>>> I'll get back to you regarding link aggregation when I'm done with >>>>> groceries. >>>>> >>>>> We use it here in production and it works flawlessly. >>>>> >>>>> >>>>> >>>>> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >>>>> >>>>>> No answer, so it seems that link aggregation doesn't really work in >>>>>> freebsd, >>>>>> this may help others with the same problem... >>>>>> >>>>>> I reverted back to one link for management and one for service, >>>>>> and ssh >>>>>> works as it should... >>>>>> >>>>>> >>>>>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>>>>> >>>>>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 >>>>>>> nic >>>>>>> (igb) >>>>>>> >>>>>>> 1 nic is connected standalone to the management switch, the 3 other >>>>>>> nics >>>>>>> are connected to a switch configured for aggregation. >>>>>>> >>>>>>> If I configure the first nic (igb0) there is no problem, I can >>>>>>> operate >>>>>>> as I normally do and sshd functions normally. >>>>>>> >>>>>>> The problems start when I configure the 3 other nics for >>>>>>> aggregation: >>>>>>> >>>>>>> in /etc/rc.conf >>>>>>> ... >>>>>>> ifconfig_igb1="up" >>>>>>> ifconfig_igb2="up" >>>>>>> ifconfig_igb3="up" >>>>>>> >>>>>>> cloned_interfaces=lagg0 >>>>>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport >>>>>>> igb3 192.168.12.7/24" >>>>>>> ... >>>>>>> >>>>>>> I restart the server and the aggregation seems to work correctly, in >>>>>>> fact ifconfig returns the correct lagg0 interface with the >>>>>>> aggregated >>>>>>> links, the correct protocol (lacp) and the correct ip address and >>>>>>> the >>>>>>> status is active. I can ping other IPs on the aggregated link. >>>>>>> >>>>>>> Also the other (standalone) link seems to work correctly. I can ping >>>>>>> that address from other machines, and I can ping other IPs from that >>>>>>> server. >>>>>>> >>>>>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>>>>> servers so there seems to be no problem on the network stack. >>>>>>> >>>>>>> But if I try to connect to the sshd service on that server, it hangs >>>>>>> indefinitely. On the server I find two sshd processes: >>>>>>> /usr/sbin/sshd >>>>>>> /usr/sbin/sshd -R >>>>>>> >>>>>>> There is no message in the logs. >>>>>>> >>>>>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays >>>>>>> there >>>>>>> forever waiting for the pid to die (it never does) >>>>>>> >>>>>>> Even ssh client doesn't seem to work. In fact, if I try to >>>>>>> connect to >>>>>>> another server, the ssh client may start to work correctly, then >>>>>>> soon >>>>>>> or later it just hangs there forever, and I can't kill it with >>>>>>> ctrl-c. >>>>>>> >>>>>>> No firewall is configured, there is nothing else working on this >>>>>>> server. >>>>>>> >>>>>>> Thanks for any suggestions... >>>>>>> _______________________________________________ >>>>>>> freebsd-stable@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>>> To unsubscribe, send any mail to >>>>>>> "freebsd-stable-unsubscribe@freebsd.org" >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-stable@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-stable-unsubscribe@freebsd.org" >>> >>> >>> _______________________________________________ >>> 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" > > _______________________________________________ > 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 Tue Sep 4 16:06:22 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19D69106567B; Tue, 4 Sep 2012 16:06:22 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 72BDD8FC1C; Tue, 4 Sep 2012 16:06:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 5AEE75CA7C; Tue, 4 Sep 2012 19:06:14 +0300 (EEST) X-Virus-Scanned: amavisd-new at bulinfo.net Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCnReuFO-QrI; Tue, 4 Sep 2012 19:06:14 +0300 (EEST) Received: from [192.168.2.187] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id F131D5CA57; Tue, 4 Sep 2012 19:06:13 +0300 (EEST) Message-ID: <504626F6.3010009@bulinfo.net> Date: Tue, 04 Sep 2012 19:06:14 +0300 From: Krassimir Slavchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.6esrpre) Gecko/20120802 Thunderbird/10.0.6 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.org References: <5044BA4D.2010403@bulinfo.net> In-Reply-To: <5044BA4D.2010403@bulinfo.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: bce related panic on 8.3-STABLE [updated] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:06:22 -0000 Hi, Crash dump files are available here: http://193.194.156.21/_debug/ #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:266 #1 0xffffffff80223b9c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff80223ed1 in db_command (last_cmdp=0xffffffff80d06280, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff80224120 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff802261e9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:231 #5 0xffffffff80696361 in kdb_trap (type=12, code=0, tf=0xffffff86c3de2680) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff8093140d in trap_fatal (frame=0xffffff86c3de2680, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:843 #7 0xffffffff8093178e in trap_pfault (frame=0xffffff86c3de2680, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:764 #8 0xffffffff80931c5e in trap (frame=0xffffff86c3de2680) at /usr/src/sys/amd64/amd64/trap.c:457 #9 0xffffffff809180b4 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #10 0xffffffff80653198 in _thread_lock_flags (td=0xffffff000479f8d0, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:582 #11 0xffffffff806a4401 in propagate_priority (td=0xffffff000479f8d0) at /usr/src/sys/kern/subr_turnstile.c:210 #12 0xffffffff806a51ef in turnstile_wait (ts=Variable "ts" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:743 #13 0xffffffff806610d1 in _rw_rlock (rw=0xffffffff80d66088, file=Variable "file" is not available. ) at /usr/src/sys/kern/kern_rwlock.c:470 #14 0xffffffff807e5ce1 in tcp_input (m=0xffffff003a2cda00, off0=20) at /usr/src/sys/netinet/tcp_input.c:745 #15 0xffffffff8077bf5c in ip_input (m=0xffffff003a2cda00) at /usr/src/sys/netinet/ip_input.c:787 #16 0xffffffff8072439e in netisr_dispatch_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:859 #17 0xffffffff8071a36c in ether_demux (ifp=0xffffff00049b0000, m=0xffffff003a2cda00) at /usr/src/sys/net/if_ethersubr.c:899 #18 0xffffffff8071a757 in ether_input (ifp=0xffffff00049b0000, m=0xffffff003a2cda00) at /usr/src/sys/net/if_ethersubr.c:758 #19 0xffffffff80330e77 in bce_intr (xsc=Variable "xsc" is not available. ) at /usr/src/sys/dev/bce/if_bce.c:6903 #20 0xffffffff8063a824 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1219 #21 0xffffffff8063beb5 in ithread_loop (arg=0xffffff00049c6ba0) at /usr/src/sys/kern/kern_intr.c:1232 #22 0xffffffff806374bf in fork_exit (callout=0xffffffff8063be20 , arg=0xffffff00049c6ba0, frame=0xffffff86c3de2c40) at /usr/src/sys/kern/kern_fork.c:876 #23 0xffffffff809185fe in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000001 in ?? () On 09/03/12 17:10, Krassimir Slavchev wrote: > Hi All, > > Today, after upgrading an HP Proliant DL380 G6 to 8.3-STABLE we had the > following panic few minutes after going to multiuser mode: > > http://193.194.156.21/bce_crash.jpg > > dmesg from 8.3-STABLE kernel (Note the link up/down events): > ... > Sep 3 14:19:54 m kernel: bce0: Server Adapter (C0)> mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci2 > Sep 3 14:19:54 m kernel: miibus0: on bce0 > Sep 3 14:19:54 m kernel: brgphy0: PHY > 1 on miibus0 > Sep 3 14:19:54 m kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, > 1000baseT-FDX-master, auto, auto-flow > Sep 3 14:19:54 m kernel: bce0: Ethernet address: 00:26:55:52:27:06 > Sep 3 14:19:54 m kernel: bce0: [ITHREAD] > Sep 3 14:19:54 mkernel: bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe > x2, 2.5Gbps); B/C (4.6.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); > MFW (NCSI 1.0.3) > Sep 3 14:19:54 m kernel: Coal (RX:6,6,18,18; TX:20,20,80,80) > ... > Sep 3 14:19:54 m kernel: Trying to mount root from ufs:/dev/da0s1a > Sep 3 14:19:57 m kernel: bce0: > Sep 3 14:19:57 m kernel: bce0: link state changed to UP > Sep 3 14:19:57 m kernel: Gigabit link up! > Sep 3 14:19:57 m kernel: bce0: Gigabit link up! > Sep 3 14:19:58 m kernel: bce1: > Sep 3 14:19:58 m kernel: bce1: link state changed to UP > Sep 3 14:19:58 m kernel: Gigabit link up! > Sep 3 14:19:58 m kernel: bce1: Gigabit link up! > Sep 3 14:20:01 m kernel: bce1: Gigabit link up! > Sep 3 14:20:27 m kernel: bce0: Gigabit link up! > Sep 3 14:24:25 m syslogd: kernel boot file is /boot/kernel/kernel > ... > > > The previous kernel from the middle of May last year (8.2-STABLE): > > $sysctl dev.bce.0 > dev.bce.0.%desc: HP NC382i DP Multifunction Gigabit Server Adapter (C0) > dev.bce.0.%driver: bce > dev.bce.0.%location: slot=0 function=0 > dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x1639 subvendor=0x103c > subdevice=0x7055 class=0x020000 > dev.bce.0.%parent: pci2 > dev.bce.0.l2fhdr_error_count: 0 > dev.bce.0.mbuf_alloc_failed_count: 0 > dev.bce.0.mbuf_frag_count: 0 > dev.bce.0.dma_map_addr_rx_failed_count: 0 > dev.bce.0.dma_map_addr_tx_failed_count: 51 > dev.bce.0.unexpected_attention_count: 0 > dev.bce.0.stat_IfHcInOctets: 8862469148 > dev.bce.0.stat_IfHCInBadOctets: 329986 > dev.bce.0.stat_IfHCOutOctets: 89884604332 > dev.bce.0.stat_IfHCOutBadOctets: 0 > dev.bce.0.stat_IfHCInUcastPkts: 47972963 > dev.bce.0.stat_IfHCInMulticastPkts: 0 > dev.bce.0.stat_IfHCInBroadcastPkts: 301 > dev.bce.0.stat_IfHCOutUcastPkts: 72217877 > dev.bce.0.stat_IfHCOutMulticastPkts: 0 > dev.bce.0.stat_IfHCOutBroadcastPkts: 45 > dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 > dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 > dev.bce.0.stat_Dot3StatsFCSErrors: 0 > dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 > dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 > dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 > dev.bce.0.stat_Dot3StatsLateCollisions: 0 > dev.bce.0.stat_EtherStatsCollisions: 0 > dev.bce.0.stat_EtherStatsFragments: 0 > dev.bce.0.stat_EtherStatsJabbers: 0 > dev.bce.0.stat_EtherStatsUndersizePkts: 0 > dev.bce.0.stat_EtherStatsOversizePkts: 0 > dev.bce.0.stat_EtherStatsPktsRx64Octets: 28900335 > dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 11130062 > dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 94457 > dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 268122 > dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 6647988 > dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 932300 > dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 > dev.bce.0.stat_EtherStatsPktsTx64Octets: 2695217 > dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 2635924 > dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 2697153 > dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 4127448 > dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 2505593 > dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 57556587 > dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 > dev.bce.0.stat_XonPauseFramesReceived: 0 > dev.bce.0.stat_XoffPauseFramesReceived: 0 > dev.bce.0.stat_OutXonSent: 0 > dev.bce.0.stat_OutXoffSent: 0 > dev.bce.0.stat_FlowControlDone: 0 > dev.bce.0.stat_MacControlFramesReceived: 0 > dev.bce.0.stat_XoffStateEntered: 0 > dev.bce.0.stat_IfInFramesL2FilterDiscards: 4331 > dev.bce.0.stat_IfInRuleCheckerDiscards: 0 > dev.bce.0.stat_IfInFTQDiscards: 0 > dev.bce.0.stat_IfInMBUFDiscards: 0 > dev.bce.0.stat_IfInRuleCheckerP4Hit: 301 > dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 > dev.bce.0.stat_CatchupInFTQDiscards: 0 > dev.bce.0.stat_CatchupInMBUFDiscards: 0 > dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 > dev.bce.0.com_no_buffers: 0 > > $vmstat -i > > interrupt total rate > irq1: atkbd0 2035 0 > irq17: atapci0 35 0 > irq22: uhci2 uhci4 10250 1 > cpu0: timer 4649590 799 > irq256: ciss0 2682286 461 > irq257: bce0 47790473 8221 > irq258: bce1 2746014 472 > cpu1: timer 4646382 799 > cpu9: timer 4646256 799 > cpu6: timer 4646397 799 > cpu15: timer 4646263 799 > cpu7: timer 4646397 799 > cpu10: timer 4646250 799 > cpu5: timer 4646397 799 > cpu11: timer 4646263 799 > cpu4: timer 4646397 799 > cpu13: timer 4646227 799 > cpu3: timer 4646396 799 > cpu12: timer 4646244 799 > cpu2: timer 4646372 799 > cpu14: timer 4646263 799 > cpu8: timer 4646163 799 > Total 127575350 21946 > > $pciconv -lv > ... > bce0@pci0:2:0:0: class=0x020000 card=0x7055103c chip=0x163914e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II Gigabit Ethernet (BCM5709)' > class = network > subclass = ethernet > bce1@pci0:2:0:1: class=0x020000 card=0x7055103c chip=0x163914e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II Gigabit Ethernet (BCM5709)' > class = network > subclass = ethernet > bce2@pci0:3:0:0: class=0x020000 card=0x7055103c chip=0x163914e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II Gigabit Ethernet (BCM5709)' > class = network > subclass = ethernet > bce3@pci0:3:0:1: class=0x020000 card=0x7055103c chip=0x163914e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II Gigabit Ethernet (BCM5709)' > class = network > subclass = ethernet > ... > > > We had to increase RX_PAGES/TX_PAGES 2 -> 64 to suppress Ierrs shown by > nenstat -ni. > > > Best Regards > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 04:35:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E61B106564A for ; Wed, 5 Sep 2012 04:35:22 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id B49408FC12 for ; Wed, 5 Sep 2012 04:35:21 +0000 (UTC) Received: (qmail 13693 invoked by uid 0); 5 Sep 2012 04:35:14 -0000 Received: from 71.195.27.106 (HELO telemachus.local) (71.195.27.106) by relay02.pair.com with SMTP; 5 Sep 2012 04:35:14 -0000 X-pair-Authenticated: 71.195.27.106 Message-ID: <5046D681.2040806@silby.com> Date: Tue, 04 Sep 2012 23:35:13 -0500 From: Mike Silbersack User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org, davidch@freebsd.org, yongari@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [patch] if_bxe shutdown fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 04:35:22 -0000 Does anyone want to review this patch before I check it in? The change has been reviewed and tested by coworkers, but not yet reviewed by any other FreeBSD committers. http://www.silby.com/patches/if_bxe.c-safestop.patch This resolves an issue we saw at work where IPMI would report bus errors when you rebooted a system with bxe NICs if you had not UP'd all of the bxe NICs before the shutdown. Thanks, Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 04:57:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42605106566C; Wed, 5 Sep 2012 04:57:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 028D58FC0A; Wed, 5 Sep 2012 04:57:03 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so302175pbb.13 for ; Tue, 04 Sep 2012 21:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=G/CU4kU2hyr88vR189DS3OG51VpdmzJar6HjPVVa2Oc=; b=clQ9d7/AQnMw7Nj1zc5GwtfwpEAWbg5sEagf4bvduf52vjDAg2bzUbT5FPrIqXwSXP gY0hDGoP3KylOkATadyTkwYioLgm8KmqNlZLxA6nlYtGI3sT9mJ7mNdPyNE4KE9b2y4W qCpW/60/UgHAlVbNTjLK1Ol+un7dMESzlERqcjF6LuommmIyXtXuAcGooTbr3rDGZJbm tTYqrb8cFOKEOWdrhKfI9jFz1eNUo4MIBEWKwfBdOTichI0ELyhpazTo/ToYzzzpqsL6 aGCDLcYc8QMcBMaCoBM4ESVVO5ez3LVIPfmKU1eWZWU56NoxiiPDlPy/+2JIWAGon2el rc9Q== Received: by 10.68.217.69 with SMTP id ow5mr50935038pbc.35.1346821023631; Tue, 04 Sep 2012 21:57:03 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id jz10sm596265pbc.8.2012.09.04.21.57.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 21:57:02 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 05 Sep 2012 13:56:54 -0700 From: YongHyeon PYUN Date: Wed, 5 Sep 2012 13:56:54 -0700 To: Mike Silbersack Message-ID: <20120905205654.GA1449@michelle.cdnetworks.com> References: <5046D681.2040806@silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5046D681.2040806@silby.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, davidch@freebsd.org, yongari@freebsd.org Subject: Re: [patch] if_bxe shutdown fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 04:57:04 -0000 On Tue, Sep 04, 2012 at 11:35:13PM -0500, Mike Silbersack wrote: > Does anyone want to review this patch before I check it in? The change > has been reviewed and tested by coworkers, but not yet reviewed by any > other FreeBSD committers. > > http://www.silby.com/patches/if_bxe.c-safestop.patch > > This resolves an issue we saw at work where IPMI would report bus errors > when you rebooted a system with bxe NICs if you had not UP'd all of the > bxe NICs before the shutdown. Yeah I also have a similar patch. But I checked sc->state after getting a BXE_CORE_LOCK as the state is protected by the lock. > > Thanks, > > Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 05:11:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65121065673 for ; Wed, 5 Sep 2012 05:11:22 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id C78B88FC18 for ; Wed, 5 Sep 2012 05:11:21 +0000 (UTC) Received: (qmail 75771 invoked by uid 0); 5 Sep 2012 05:11:15 -0000 Received: from 71.195.27.106 (HELO telemachus.local) (71.195.27.106) by relay01.pair.com with SMTP; 5 Sep 2012 05:11:15 -0000 X-pair-Authenticated: 71.195.27.106 Message-ID: <5046DEF2.9040901@silby.com> Date: Wed, 05 Sep 2012 00:11:14 -0500 From: Mike Silbersack User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <5046D681.2040806@silby.com> <20120905205654.GA1449@michelle.cdnetworks.com> In-Reply-To: <20120905205654.GA1449@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, davidch@freebsd.org, yongari@freebsd.org Subject: Re: [patch] if_bxe shutdown fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 05:11:22 -0000 On 9/5/12 3:56 PM, YongHyeon PYUN wrote: > On Tue, Sep 04, 2012 at 11:35:13PM -0500, Mike Silbersack wrote: >> Does anyone want to review this patch before I check it in? The change >> has been reviewed and tested by coworkers, but not yet reviewed by any >> other FreeBSD committers. >> >> http://www.silby.com/patches/if_bxe.c-safestop.patch >> >> This resolves an issue we saw at work where IPMI would report bus errors >> when you rebooted a system with bxe NICs if you had not UP'd all of the >> bxe NICs before the shutdown. > Yeah I also have a similar patch. But I checked sc->state after > getting a BXE_CORE_LOCK as the state is protected by the lock. > >> Thanks, >> >> Mike "Silby" Silbersack Good catch. How does this look? http://www.silby.com/patches/if_bxe.c-safestop-2.patch Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 06:05:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A4C4106564A; Wed, 5 Sep 2012 06:05:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8308FC18; Wed, 5 Sep 2012 06:05:51 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so384252pbb.13 for ; Tue, 04 Sep 2012 23:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SIf/CB0xYf4ITgftxI5PCAwEr6+dPTY+CAVsIMIkm5U=; b=yMdwX1O3xlcPM8oNu9nIBCcR2j885hml7eWHKq6+2AdEJTtDiXwhkHc4OjCqdV6bIm C8aaMX1GT7/gZ30F36ePN4u+NaxrqDRoz9zUbNUiu8C53JFzvl8fOZQqiyU63omdZF8o TXXawFJSAifvdst752/sqir2vsBMPgGrHl/93w1RL1fcpEZRko5br7CaAWJ7tLP5h4bH JW+Q6Od+C1mZASgzD3ReQPwa9VCNx2V1KHvpwiFvXLdeSLpp0MzTN3oAcmb6EjySTDAo i0OYABQ44hgUADg7xF0H1TQPzKcZj0NpskqbxTNyF05m4et+DBFs0yqgE85JfaMcYbjG SO0Q== Received: by 10.68.220.201 with SMTP id py9mr51252049pbc.137.1346825150837; Tue, 04 Sep 2012 23:05:50 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id pj8sm691377pbb.60.2012.09.04.23.05.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 23:05:50 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 05 Sep 2012 15:05:41 -0700 From: YongHyeon PYUN Date: Wed, 5 Sep 2012 15:05:41 -0700 To: Mike Silbersack Message-ID: <20120905220541.GB1449@michelle.cdnetworks.com> References: <5046D681.2040806@silby.com> <20120905205654.GA1449@michelle.cdnetworks.com> <5046DEF2.9040901@silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5046DEF2.9040901@silby.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, davidch@freebsd.org, yongari@freebsd.org Subject: Re: [patch] if_bxe shutdown fix X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:05:51 -0000 On Wed, Sep 05, 2012 at 12:11:14AM -0500, Mike Silbersack wrote: > On 9/5/12 3:56 PM, YongHyeon PYUN wrote: > >On Tue, Sep 04, 2012 at 11:35:13PM -0500, Mike Silbersack wrote: > >>Does anyone want to review this patch before I check it in? The change > >>has been reviewed and tested by coworkers, but not yet reviewed by any > >>other FreeBSD committers. > >> > >>http://www.silby.com/patches/if_bxe.c-safestop.patch > >> > >>This resolves an issue we saw at work where IPMI would report bus errors > >>when you rebooted a system with bxe NICs if you had not UP'd all of the > >>bxe NICs before the shutdown. > >Yeah I also have a similar patch. But I checked sc->state after > >getting a BXE_CORE_LOCK as the state is protected by the lock. > > > >>Thanks, > >> > >>Mike "Silby" Silbersack > > Good catch. How does this look? > > http://www.silby.com/patches/if_bxe.c-safestop-2.patch > Patch looks good to me. From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 06:53:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C3AE106564A; Wed, 5 Sep 2012 06:53:47 +0000 (UTC) (envelope-from brianstivala@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12F908FC15; Wed, 5 Sep 2012 06:53:46 +0000 (UTC) Received: by iebc12 with SMTP id c12so527769ieb.13 for ; Tue, 04 Sep 2012 23:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QhZNSAANn89KSvlYzc9uTfXqIeL9WFa/NTkPYcHxFyk=; b=gUPhkOUPuCoshjxfVHWp06aaAHDhCUF0KU2zVsaEj4MfsmcUnyTKrRfri4Sh4CVFxA fNHbugcVTzFpM92YzQKT8fVq/v4iSISbzBQ6qvJoU6VlJ5UI+H4jjzx76o+5h4gjVe1X aIngRgU2Ql8uXsK8k8pcAGWwwQ6PdA2GJT1PIL0nTNTI6IGOpxQ0kx/OS67KGwniw8NA JzOIBXX4WMR1u9JiNwjzK5G5n6B5MLJswGfOSFiR0i/4JupirfKoj3Ty+63WShEAMQ62 ze5GKqof8rXIWjC/TUmEhqGJSMM5jR25k1BH2SclAFwe66c7D+eb2uaEa6cXpPpE3pSB t0RQ== MIME-Version: 1.0 Received: by 10.60.10.6 with SMTP id e6mr17009580oeb.45.1346828026143; Tue, 04 Sep 2012 23:53:46 -0700 (PDT) Received: by 10.76.74.161 with HTTP; Tue, 4 Sep 2012 23:53:46 -0700 (PDT) In-Reply-To: <5046640E.10806@FreeBSD.org> References: <5046640E.10806@FreeBSD.org> Date: Wed, 5 Sep 2012 08:53:46 +0200 Message-ID: From: Brian Stivala To: Matthew Seaman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBsd modules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 06:53:47 -0000 Hi Matthew, Thanks for your reply, This is my Pciconf and the /var/log/dmesg.boot. As you can see the ethernet card is there but it is not recognisable in PFSense. The only functional nics are FXP0 and FXP1 the onboard chipset. [2.0.1-RELEASE][root@pfSense.localdomain]/root(1): pciconf -l -v hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x00000000 chip=3D0x7192808= 6 rev=3D0x03 hdr=3D0x00 class =3D bridge subclass =3D HOST-PCI fxp0@pci0:0:5:0: class=3D0x020000 card=3D0x00000000 chip=3D0x1209808= 6 rev=3D0x09 hdr=3D0x00 class =3D network subclass =3D ethernet fxp1@pci0:0:6:0: class=3D0x020000 card=3D0x00000000 chip=3D0x1209808= 6 rev=3D0x09 hdr=3D0x00 class =3D network subclass =3D ethernet isab0@pci0:0:7:0: class=3D0x060100 card=3D0x00000000 chip=3D0x7110808= 6 rev=3D0x02 hdr=3D0x00 class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:7:1: class=3D0x010180 card=3D0x00000000 chip=3D0x7111808= 6 rev=3D0x01 hdr=3D0x00 class =3D mass storage subclass =3D ATA uhci0@pci0:0:7:2: class=3D0x0c0300 card=3D0x00000000 chip=3D0x7112808= 6 rev=3D0x01 hdr=3D0x00 class =3D serial bus subclass =3D USB piix0@pci0:0:7:3: class=3D0x068000 card=3D0x00000000 chip=3D0x7113808= 6 rev=3D0x02 hdr=3D0x00 class =3D bridge none0@pci0:0:8:0: class=3D0x0b4000 card=3D0x00000000 chip=3D0x000613a= 3 rev=3D0x01 hdr=3D0x00 class =3D processor none1@pci0:0:9:0: class=3D0x020000 card=3D0x00000000 chip=3D0x0201161= 7 rev=3D0x00 hdr=3D0x00 class =3D network subclass =3D ethernet [2.0.1-RELEASE][root@pfSense.localdomain]/root/var(5): cat /var/log/dmesg.boot Copyright (c) 1992-2010 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 8.1-RELEASE-p6 #0: Mon Dec 12 18:59:41 EST 2011 root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj./usr/pfSensesrc= /src/sys/pfSense_wrap.8.i386 i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (847.74-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x68a Family =3D 6 Model =3D 8 Stepp= ing =3D 10 Features=3D0x387f9ff real memory =3D 268435456 (256 MB) avail memory =3D 243433472 (232 MB) netisr_init: forcing maxthreads to 1 and bindthreads to 0 for device pollin= g wlan: mac acl policy registered ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=3D1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0710010, 0) error 1 ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=3D= 1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc07100b0, 0) error 1 wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. wpi: If you agree with the license, set legal.intel_wpi.license_ack=3D1 in /boot/loader.conf. module_register_init: MOD_LOAD (wpi_fw, 0xc0883050, 0) error 1 ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=3D1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0710150, 0) error 1 ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. cryptosoft0: on motherboard padlock0: No ACE support. pcib0: pcibus 0 on motherboard pci0: on pcib0 fxp0: port 0xfc00-0xfc3f mem 0xc0000000-0xc0000fff,0xc0020000-0xc003ffff irq 9 at device 5.0 on pci0 fxp0: Enabling Rx lock-up workaround miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: [ITHREAD] fxp1: port 0xf800-0xf83f mem 0xc0040000-0xc0040fff,0xc0060000-0xc007ffff irq 6 at device 6.0 on pci0 fxp1: Enabling Rx lock-up workaround miibus1: on fxp1 inphy1: PHY 1 on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: [ITHREAD] isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xf000-0xf01f irq 11 at device 7.2 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 piix0: port 0x10a0-0x10af at device 7.3 on pci0 Timecounter "PIIX" frequency 3579545 Hz quality 0 pci0: at device 8.0 (no driver attached) pci0: at device 9.0 (no driver attached) cpu0 on motherboard atrtc0: at port 0x70 irq 8 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] RTC BIOS diagnostic error 42 Timecounter "TSC" frequency 847739306 Hz quality 800 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. usbus0: 12Mbps Full Speed USB v1.0 ad0: 1967MB at ata0-master PIO4 ugen0.1: at usbus0 uhub0: on usbus0 Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/ufs/pfsense0 Invalid time in real time clock. Check and reset the date immediately! Regards, Brian Stivala On Tue, Sep 4, 2012 at 10:26 PM, Matthew Seaman wrote= : > On 04/09/2012 19:33, Brian Stivala wrote: > > I have a watchguard firewall v80 which I=92ve decided to amend it to > PFSense > > based on freebsd. So far I=92ve installed PFSense and everything is wor= king > > accordingly. This firewall has 2x onboard nic cards and a PCI quad nic, > as > > per attached photo. > > Unfortunately the list management software ate your photo, but never > mind. Your verbal description is sufficient. > > > The onboard nics can be recognized however the PCI card is not being > > recognised, and the strange thing is that both onboard and the PCI uses > the > > same chipset Intel 82559er Ethernet. How can I amend changes in freebsd > > modules so that the PCI card can be recognised. > > There may be a good reason for your quad card not being recognised, or > it might just be a bug. > > If you run: > > % pciconf -lv > > You should be able to pick out your unrecognised device. If you ask > again on freebsd-net@freebsd.org and include relevant sections from > the pciconf output, you should get to the attention of some of the guys > that write network drivers. > > > Usually in other distros modules can be located in /etc/module however = I > > cannot find where the modules are located in freebsd. > > Verb Sap. Calling FreeBSD a 'distro' is definitely non-U. We generally > consider penguins a bit fishy round here... > > If you want to locate the kernel modules for various hardware, look in > /boot/kernel. NIC modules will generally have a name beginning 'if_'. > > If you want to see what modules have been loaded into the kernel, then > run: > > % kldstat > > There's also 'kldload' and 'kldunload' but they aren't going to help you > for this problem. PCI devices are discovered when the kernel probes the > bus at boot time: if the kernel hasn't already assigned a driver for the > device, then there isn't one available. > > > Can I have some assistance. > > Keeps asking good questions and you'll get useful answers. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. > PGP: http://www.infracaninophile.co.uk/pgpkey > > > From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 07:03:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A74C1065674; Wed, 5 Sep 2012 07:03:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2013D8FC1F; Wed, 5 Sep 2012 07:03:19 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so458472pbb.13 for ; Wed, 05 Sep 2012 00:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N6mFElNuHM12l7a0xRYrxIVYC7LLyqHLuuLKyJrVHFw=; b=RR7zvv+ciQAGajFXjIReVKQUCTVSbbTBrwKEq+CxNVno+WW9R3FQ9Tcx3QtZQ/B6yy 1DZx4jy5pHPCX0t/hENZp0iNWnYE2txCAEhPJgXcNya7t7E1FcuLVol1lYlkwlHUIKeO ZrXQTJwlT1uFbODUY2IqPLRkuNTFT9JkaDVCwA+6PK+nB8pS9+75s3eS5UAkeO+Tb/xx +4vQaCUl0mpK7RrXIWJ1mlS//YSyW0qYDVcdrmZ4YuIJMTYNXOyLChwTdcc4ekm2EJQL 0/CTFA21wK8MPHoz2VFbbLBj4aTk1dJzClGGq5/so1B3NIs3rMsaUOpHvSTdzvcJQGgC fGaw== MIME-Version: 1.0 Received: by 10.66.72.197 with SMTP id f5mr46873729pav.20.1346828599503; Wed, 05 Sep 2012 00:03:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Wed, 5 Sep 2012 00:03:19 -0700 (PDT) In-Reply-To: <5044772C.8090302@rdtc.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> Date: Wed, 5 Sep 2012 00:03:19 -0700 X-Google-Sender-Auth: 7PuxC-I69qdb21W4pL0JqcaNFv4 Message-ID: From: Adrian Chadd To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:03:20 -0000 waaaaaaaaait. Did you say that removing preemption from your kernel fixed your performance issues? If that's the case, we need to figure out why both you and i see that.. Adrian On 3 September 2012 02:23, Eugene Grosbein wrote: > 04.09.2012 04:43, YongHyeon PYUN =D0=C9=DB=C5=D4: > >>> None. I've read its source and learned it prints its debug >>> to the kernel dmesg buffer with sysctl dev.vr.1.stats=3D1 >>> and done that before, during and after noted failure - >>> all counters are zero except of good frames conters (in/out). >> >> Ok, it seems you didn't encounter TX/RX MAC shutdown/restart >> related issues. To get more verbose debugging messages, you have >> to define VR_SHOW_ERRORS in if_vr.c. > > I'll try this evening. > >> BTW, I see really poor bulk TCP performance on vr(4) with CURRENT >> (< 12 Mbps). :-( >> This is a quad-port VT6105 with Core2 Duo E6550. Pre-r235334 >> restores the old good performance for me(> 86Mbps). However I can't >> explain how taskq change shows this huge difference. > > Have you tried to remove options PREEMPTING from the kernel for newest dr= iver? > That helped me a lot - performance of new driver returned to the level of= old one. > > Eugene Grosbein > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 07:08:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71091106566B; Wed, 5 Sep 2012 07:08:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36DB88FC0A; Wed, 5 Sep 2012 07:08:00 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so464635pbb.13 for ; Wed, 05 Sep 2012 00:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8WdeS6aquuaz75E6TKg0IKoKgJ5WMFyShNeUpu16K9E=; b=INEClLs/FsiCBLn18wWsZ6Mn/V/3riYl2OoIQW6iZZOK3Q/fR93bZjyOUv5DzvgZQ8 TU6SOlQFxLz7HOIT2RthhqpN/guHjnHyvV88WXTtoAMy10au1Gs2fuCTH89ATBSCKlNV eYvmUF7AGoJbuvP6wnpvOzY0wre7mqf+2PDg71jA+CiWnHGhRIsS+Y7lJhYH/dxnALYp S+YoEKrjVOyec0ukVaiIS77RWUS9+8a6obqAHvSo1QKBOgQ1cOv1QbqGFV7tbU0DQ38+ rMH80vsLyH14lh9LJeeNO0LD8UrsGccGhok7Rvk5b5DELRbHyTcPZRWQsf7GHTG9fL3N ulEg== MIME-Version: 1.0 Received: by 10.68.138.169 with SMTP id qr9mr51944629pbb.27.1346828880468; Wed, 05 Sep 2012 00:08:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Wed, 5 Sep 2012 00:08:00 -0700 (PDT) In-Reply-To: <5040E749.9070200@rdtc.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> <5040508D.9080107@rdtc.ru> <5040DE1D.7040700@rdtc.ru> <5040E749.9070200@rdtc.ru> Date: Wed, 5 Sep 2012 00:08:00 -0700 X-Google-Sender-Auth: fQwhc7zqBYNFMpa9dlx_x8ygwUk Message-ID: From: Adrian Chadd To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:08:01 -0000 I'm so sorry for dropping off the radar here. Can you please compile your kernel with KTR enabled so we can capture some schedgraph traces? I'd like to let the scheduler people see what's going on. I bet it's something like preemption is allowing the taskqueues to preempt each other (which they shouldn't, not when they're at the same level) when an interrupt occurs that calls taskqueue_enqueue(). On a non-preempt kernel it'll just jump back to running the same thread until yield or tick; on a preempt kernel a driver taskqueue could be preempted by another driver. (Holy crap, this is one situation where maybe the linux spinlock_bh() semantics make sense. If used correctly. Yikes.) Adrian On 31 August 2012 09:33, Eugene Grosbein wrote: > 31.08.2012 22:54, Eugene Grosbein =D0=C9=DB=C5=D4: > >> I've rebuilt by kernel with SCHED_ULE and excluded PREEMPTION. >> Stock driver works without changes in behaviour and driver from HEAD >> now works very similar to old one: LA is not higher than 2 and >> userland is pretty responsive. Also, transfer speed with new driver is >> several percent more. That's good. >> >> Care to explain such dramatic difference for new driver >> with/without PREEMPTION for relatively slow uniprocessor system? >> >>> And run 4BSD + no preemption, try again? > > I've tried 4BSD without preemption too. Can't see any difference > from ULE without preemption. Should I stick with 4BSD for UP system? > > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 07:23:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0D25106566B; Wed, 5 Sep 2012 07:23:29 +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 4FDC38FC0A; Wed, 5 Sep 2012 07:23:28 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q857NQ9E050059; Wed, 5 Sep 2012 14:23:26 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5046FDEE.2000801@rdtc.ru> Date: Wed, 05 Sep 2012 14:23:26 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404957.302@rdtc.ru> <5040508D.9080107@rdtc.ru> <5040DE1D.7040700@rdtc.ru> <5040E749.9070200@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: Bad routing performance on 500Mhz Geode LX with CURRENT, ipfw and mpd5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:23:30 -0000 05.09.2012 14:08, Adrian Chadd : > I'm so sorry for dropping off the radar here. > > Can you please compile your kernel with KTR enabled so we can capture > some schedgraph traces? Yes, I can and will. What should I do besides of rebuilding the kernel with KTR and PREEMPTION? From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 07:25:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6BC6106566C; Wed, 5 Sep 2012 07:25:13 +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 25C508FC15; Wed, 5 Sep 2012 07:25:12 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q857PBnf050068; Wed, 5 Sep 2012 14:25:11 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5046FE57.3050903@rdtc.ru> Date: Wed, 05 Sep 2012 14:25:11 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:25:13 -0000 05.09.2012 14:03, Adrian Chadd : > waaaaaaaaait. > > Did you say that removing preemption from your kernel fixed your > performance issues? Yes. Also, it seems my original vr(4) troubles (RX path problem) have gone away since I run the kernel without preemption. > If that's the case, we need to figure out why both you and i see that.. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 10:33:20 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 57EBE106566B; Wed, 5 Sep 2012 10:33:20 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 0019814D862; Wed, 5 Sep 2012 10:32:57 +0000 (UTC) Message-ID: <50472A18.5050909@FreeBSD.org> Date: Wed, 05 Sep 2012 14:31:52 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: net@freebsd.org Content-Type: multipart/mixed; boundary="------------000105030205080004040409" Cc: arch@freebsd.org, Gleb Smirnoff , Luigi Rizzo Subject: [PATCH] Using PFIL lock in packet filters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:33:20 -0000 This is a multi-part message in MIME format. --------------000105030205080004040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello list! Currently we have the following locking strategy in our firewalls: On every input/output IP packet PFIL acquires read lock while traversing list and after that reader (e.g. firewall handler) acquires its own lock (rwlock in case of ipfw). Pfil framework currently uses per-head rmlock (e.g. different lock for IPv4 and IPv6 per each VNET instance). Since most popular firewalls (ipfw and pf) uses per-VNET rwlock(*), per-AF pfil locks does not give us much benefit. Proposed idea is to: 1) Use single pfil lock per VNET instance by default. 2) Permit filters to use this lock via pfil_[rw]_[un]lock functions. Patch for pfil and ipfw changes attached. I've got several production routers running for a week with previous version of this patch without any (ipfw-related) problems. Performance difference is quite significant, more details here: http://lists.freebsd.org/pipermail/freebsd-net/2012-July/032842.html I'm planning to commit these patches (with minor changes) at the beginning of next week if nobody objects. (*) currently pf uses mutex, but hopefully glebius@ is working on much more scalable solution -- WBR, Alexander --------------000105030205080004040409 Content-Type: text/plain; charset=UTF-8; name="0001-Export-pfil-lock.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Export-pfil-lock.patch" >From 347690db1c4ecaf267f3c027e18ea38734d28d42 Mon Sep 17 00:00:00 2001 From: "Alexander V. Chernikov" Date: Wed, 5 Sep 2012 13:09:16 +0400 Subject: [PATCH 1/2] Export pfil lock --- share/man/man9/pfil.9 | 55 ++++++++++++++++++++++++++++++++++++++++++++-- sys/net/pfil.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++ sys/net/pfil.h | 46 ++++++++++++++++++++++++++++++--------- 3 files changed, 147 insertions(+), 12 deletions(-) diff --git a/share/man/man9/pfil.9 b/share/man/man9/pfil.9 index 36a4d47..a76168b 100644 --- a/share/man/man9/pfil.9 +++ b/share/man/man9/pfil.9 @@ -28,7 +28,7 @@ .\" .\" $FreeBSD: stable/8/share/man/man9/pfil.9 162404 2006-09-18 15:24:20Z ru $ .\" -.Dd September 29, 2004 +.Dd September 5, 2012 .Dt PFIL 9 .Os .Sh NAME @@ -39,7 +39,11 @@ .Nm pfil_hook_get , .Nm pfil_add_hook , .Nm pfil_remove_hook , -.Nm pfil_run_hooks +.Nm pfil_run_hooks , +.Nm pfil_rlock +.Nm pfil_runlock +.Nm pfil_wlock +.Nm pfil_wunlock .Nd packet filter interface .Sh SYNOPSIS .In sys/param.h @@ -62,6 +66,14 @@ .Fn (*func) "void *arg" "struct mbuf **mp" "struct ifnet *" "int dir" "struct inpcb *" .Ft int .Fn pfil_run_hooks "struct pfil_head *head" "struct mbuf **mp" "struct ifnet *" "int dir" "struct inpcb *" +.Ft void +.Fn pfil_rlock "struct pfil_head *" "struct rm_priotracker *" +.Ft void +.Fn pfil_runlock "struct pfil_head *" "struct rm_priotracker *" +.Ft void +.Fn pfil_wlock "struct pfil_head *" +.Ft void +.Fn pfil_wunlock "struct pfil_head *" .Sh DESCRIPTION The .Nm @@ -86,6 +98,16 @@ The data link type is a .Xr bpf 4 DLT constant indicating what kind of header is present on the packet at the filtering point. +Each filtering point uses common per-VNET rmlock by default. +This can be changed by specifying +.Vt PFIL_FLAG_PRIVATE_LOCK +as +.Vt "flags" +field in the +.Vt pfil_head +structure. +Note that specifying private lock can break filters sharing the same +ruleset and/or state between different data link types. Filtering points may be unregistered with the .Fn pfil_head_unregister function. @@ -122,6 +144,31 @@ The filter returns an error (errno) if the packet processing is to stop, or 0 if the processing is to continue. If the packet processing is to stop, it is the responsibility of the filter to free the packet. +.Pp +Every filter hook is called with +.Nm +read lock held. +All heads uses the same lock within the same VNET instance. +Packet filter can use this lock instead of own locking model to +improve performance. +Since +.Nm +uses +.Xr rmlock 9 +.Fn pfil_rlock +and +.Fn pfil_runlock +require +.Va struct rm_priotracker +to be passed as argument. +Filter can acquire and release writer lock via +.Fn pfil_wlock +and +.Fn pfil_wunlock +functions. +See +.Xr rmlock 9 +for more details. .Sh RETURN VALUES If successful, .Fn pfil_head_get @@ -146,6 +193,7 @@ might sleep! .Sh SEE ALSO .Xr bpf 4 , .Xr if_bridge 4 +.Xr rmlock 4 .Sh HISTORY The .Nm @@ -181,6 +229,9 @@ as well as be less IP-centric. .Pp Fine-grained locking was added in .Fx 5.2 . +.Nm +lock export was added in +.Fx 10.0 . .Sh BUGS The .Fn pfil_hook_get diff --git a/sys/net/pfil.c b/sys/net/pfil.c index 788ca24..6c48334 100644 --- a/sys/net/pfil.c +++ b/sys/net/pfil.c @@ -61,6 +61,8 @@ static int pfil_list_remove(pfil_list_t *, LIST_HEAD(pfilheadhead, pfil_head); VNET_DEFINE(struct pfilheadhead, pfil_head_list); #define V_pfil_head_list VNET(pfil_head_list) +VNET_DEFINE(struct rmlock, pfil_lock); +#define V_pfil_lock VNET(pfil_lock) /* * pfil_run_hooks() runs the specified packet filter hooks. @@ -91,6 +93,60 @@ pfil_run_hooks(struct pfil_head *ph, struct mbuf **mp, struct ifnet *ifp, } /* + * pfil_try_rlock() acquires rm reader lock for specified head + * if this is immediately possible, + */ +int +pfil_try_rlock(struct pfil_head *ph, struct rm_priotracker *tracker) +{ + return PFIL_TRY_RLOCK(ph, tracker); +} + +/* + * pfil_rlock() acquires rm reader lock for specified head. + */ +void +pfil_rlock(struct pfil_head *ph, struct rm_priotracker *tracker) +{ + PFIL_RLOCK(ph, tracker); +} + +/* + * pfil_runlock() releases reader lock for specified head. + */ +void +pfil_runlock(struct pfil_head *ph, struct rm_priotracker *tracker) +{ + PFIL_RUNLOCK(ph, tracker); +} + +/* + * pfil_wlock() acquires writer lock for specified head. + */ +void +pfil_wlock(struct pfil_head *ph) +{ + PFIL_WLOCK(ph); +} + +/* + * pfil_wunlock() releases writer lock for specified head. + */ +void +pfil_wunlock(struct pfil_head *ph) +{ + PFIL_WUNLOCK(ph); +} + +/* + * pfil_wowned() releases writer lock for specified head. + */ +int +pfil_wowned(struct pfil_head *ph) +{ + return PFIL_WOWNED(ph); +} +/* * pfil_head_register() registers a pfil_head with the packet filter hook * mechanism. */ @@ -295,6 +351,7 @@ vnet_pfil_init(const void *unused) { LIST_INIT(&V_pfil_head_list); + PFIL_LOCK_INIT_REAL(&V_pfil_lock, "shared"); return (0); } @@ -306,6 +363,7 @@ vnet_pfil_uninit(const void *unused) { /* XXX should panic if list is not empty */ + PFIL_LOCK_DESTROY_REAL(&V_pfil_lock); return (0); } diff --git a/sys/net/pfil.h b/sys/net/pfil.h index d314a72..7c99148 100644 --- a/sys/net/pfil.h +++ b/sys/net/pfil.h @@ -64,6 +64,8 @@ typedef TAILQ_HEAD(pfil_list, packet_filter_hook) pfil_list_t; #define PFIL_TYPE_AF 1 /* key is AF_* type */ #define PFIL_TYPE_IFNET 2 /* key is ifnet pointer */ +#define PFIL_FLAG_PRIVATE_LOCK 0x01 /* Personal lock instead of global */ + struct pfil_head { pfil_list_t ph_in; pfil_list_t ph_out; @@ -72,7 +74,9 @@ struct pfil_head { #if defined( __linux__ ) || defined( _WIN32 ) rwlock_t ph_mtx; #else - struct rmlock ph_lock; + struct rmlock *ph_plock; /* Pointer to the used lock */ + struct rmlock ph_lock; /* Private lock storage */ + int flags; #endif union { u_long phu_val; @@ -90,21 +94,43 @@ int pfil_remove_hook(int (*func)(void *, struct mbuf **, struct ifnet *, int pfil_run_hooks(struct pfil_head *, struct mbuf **, struct ifnet *, int, struct inpcb *inp); +struct rm_priotracker; /* Do not require including rmlock header */ +int pfil_try_rlock(struct pfil_head *, struct rm_priotracker *); +void pfil_rlock(struct pfil_head *, struct rm_priotracker *); +void pfil_runlock(struct pfil_head *, struct rm_priotracker *); +void pfil_wlock(struct pfil_head *); +void pfil_wunlock(struct pfil_head *); +int pfil_wowned(struct pfil_head *ph); + int pfil_head_register(struct pfil_head *); int pfil_head_unregister(struct pfil_head *); struct pfil_head *pfil_head_get(int, u_long); #define PFIL_HOOKED(p) ((p)->ph_nhooks > 0) -#define PFIL_LOCK_INIT(p) \ - rm_init_flags(&(p)->ph_lock, "PFil hook read/write mutex", RM_RECURSE) -#define PFIL_LOCK_DESTROY(p) rm_destroy(&(p)->ph_lock) -#define PFIL_RLOCK(p, t) rm_rlock(&(p)->ph_lock, (t)) -#define PFIL_WLOCK(p) rm_wlock(&(p)->ph_lock) -#define PFIL_RUNLOCK(p, t) rm_runlock(&(p)->ph_lock, (t)) -#define PFIL_WUNLOCK(p) rm_wunlock(&(p)->ph_lock) -#define PFIL_LIST_LOCK() mtx_lock(&pfil_global_lock) -#define PFIL_LIST_UNLOCK() mtx_unlock(&pfil_global_lock) +#define PFIL_LOCK_INIT_REAL(l, t) \ + rm_init_flags(l, "PFil " t " rmlock", RM_RECURSE) +#define PFIL_LOCK_DESTROY_REAL(l) \ + rm_destroy(l) +#define PFIL_LOCK_INIT(p) do { \ + if ((p)->flags & PFIL_FLAG_PRIVATE_LOCK) { \ + PFIL_LOCK_INIT_REAL(&(p)->ph_lock, "private"); \ + (p)->ph_plock = &(p)->ph_lock; \ + } else \ + (p)->ph_plock = &V_pfil_lock; \ +} while (0) +#define PFIL_LOCK_DESTROY(p) do { \ + if ((p)->flags & PFIL_FLAG_PRIVATE_LOCK) \ + PFIL_LOCK_DESTROY_REAL((p)->ph_plock); \ +} while (0) +#define PFIL_TRY_RLOCK(p, t) rm_try_rlock((p)->ph_plock, (t)) +#define PFIL_RLOCK(p, t) rm_rlock((p)->ph_plock, (t)) +#define PFIL_WLOCK(p) rm_wlock((p)->ph_plock) +#define PFIL_RUNLOCK(p, t) rm_runlock((p)->ph_plock, (t)) +#define PFIL_WUNLOCK(p) rm_wunlock((p)->ph_plock) +#define PFIL_WOWNED(p) rm_wowned((p)->ph_plock) +#define PFIL_LIST_LOCK() mtx_lock(&pfil_global_lock) +#define PFIL_LIST_UNLOCK() mtx_unlock(&pfil_global_lock) static __inline struct packet_filter_hook * pfil_hook_get(int dir, struct pfil_head *ph) -- 1.7.9.4 --------------000105030205080004040409 Content-Type: text/plain; charset=UTF-8; name="0002-Make-ipfw-use-pfil-hooks.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-Make-ipfw-use-pfil-hooks.patch" >From 808f85d5bc8b0ac12bd9b11c6fa1f8b44ad936cd Mon Sep 17 00:00:00 2001 From: "Alexander V. Chernikov" Date: Wed, 5 Sep 2012 13:10:15 +0400 Subject: [PATCH 2/2] Make ipfw use pfil hooks --- sys/netinet/ipfw/ip_fw2.c | 22 ++++++++++++++++++++++ sys/netinet/ipfw/ip_fw_nat.c | 18 ++++++++++++++++++ sys/netinet/ipfw/ip_fw_private.h | 17 +++++++++-------- sys/netinet/ipfw/ip_fw_sockopt.c | 4 ++++ sys/netinet/ipfw/ip_fw_table.c | 1 + 5 files changed, 54 insertions(+), 8 deletions(-) diff --git a/sys/netinet/ipfw/ip_fw2.c b/sys/netinet/ipfw/ip_fw2.c index 352fd4a..bee16a3 100644 --- a/sys/netinet/ipfw/ip_fw2.c +++ b/sys/netinet/ipfw/ip_fw2.c @@ -62,6 +62,7 @@ __FBSDID("$FreeBSD: head/sys/netinet/ipfw/ip_fw2.c 240099 2012-09-04 19:43:26Z m #include #include #include +#include #include #include @@ -785,6 +786,10 @@ set_match(struct ip_fw_args *args, int slot, * All arguments are in args so we can modify them and return them * back to the caller. * + * We assume ipfw_chk is ALWAYS called from PFIL hook so + * read lock is alredy held. If this is not the case, PFIL + * read lock has to be acquired manually before calling ipfw_chk() + * * Parameters: * * args->m (in/out) The packet; we set to NULL when/if we nuke it. @@ -1203,9 +1208,13 @@ do { \ args->f_id.dst_port = dst_port = ntohs(dst_port); } +#if defined(__linux__) || defined(_WIN32) IPFW_RLOCK(chain); +#endif if (! V_ipfw_vnet_ready) { /* shutting down, leave NOW. */ +#if defined(__linux__) || defined(_WIN32) IPFW_RUNLOCK(chain); +#endif return (IP_FW_PASS); /* accept */ } if (args->rule.slot) { @@ -2476,7 +2485,9 @@ do { \ retval = IP_FW_DENY; printf("ipfw: ouch!, skip past end of rules, denying packet\n"); } +#if defined(__linux__) || defined(_WIN32) IPFW_RUNLOCK(chain); +#endif #ifdef __FreeBSD__ if (ucred_cache != NULL) crfree(ucred_cache); @@ -2639,6 +2650,17 @@ vnet_ipfw_init(const void *unused) chain->id = rule->id = 1; IPFW_LOCK_INIT(chain); +#ifdef __FreeBSD__ +#ifdef INET + chain->phead = pfil_head_get(PFIL_TYPE_AF, AF_INET); +#else + chain->phead = pfil_head_get(PFIL_TYPE_AF, AF_INET6); +#endif + if (error) { + printf("ipfw2: PFIL lock setup failed"); + return (ENOENT); + } +#endif ipfw_dyn_init(); /* First set up some values that are compile time options */ diff --git a/sys/netinet/ipfw/ip_fw_nat.c b/sys/netinet/ipfw/ip_fw_nat.c index 7b3f3a3..1e9b6af 100644 --- a/sys/netinet/ipfw/ip_fw_nat.c +++ b/sys/netinet/ipfw/ip_fw_nat.c @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD: head/sys/netinet/ipfw/ip_fw_nat.c 231991 2012-02-22 04:19:33 #include #include +#include #include #include #include @@ -201,6 +202,13 @@ add_redir_spool_cfg(char *buf, struct cfg_nat *ptr) } } +/* + * ipfw_nat - perform mbuf header translation. + * + * We assume ipfw_nat is ALWAYS called from ipfw_chk so + * PFIL read lock is alredy held. If this is not the case, + * read lock has to be acquired manually before calling ipfw_nat() + */ static int ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) { @@ -268,7 +276,9 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) found = 0; chain = &V_layer3_chain; +#if defined(__linux__) || defined(_WIN32) IPFW_RLOCK(chain); +#endif /* Check every nat entry... */ LIST_FOREACH(t, &chain->nat, _next) { if ((t->mode & PKT_ALIAS_SKIP_GLOBAL) != 0) @@ -281,7 +291,9 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) break; } } +#if defined(__linux__) || defined(_WIN32) IPFW_RUNLOCK(chain); +#endif if (found != 1) { /* No instance found, return ignore */ args->m = mcl; @@ -493,6 +505,9 @@ ipfw_nat_get_cfg(struct sockopt *sopt) struct cfg_spool *s; char *data; int gencnt, nat_cnt, len, error; +#ifdef __FreeBSD__ + struct rm_priotracker tracker; +#endif nat_cnt = 0; len = sizeof(nat_cnt); @@ -551,6 +566,9 @@ ipfw_nat_get_log(struct sockopt *sopt) struct cfg_nat *ptr; int i, size; struct ip_fw_chain *chain; +#ifdef __FreeBSD__ + struct rm_priotracker tracker; +#endif chain = &V_layer3_chain; diff --git a/sys/netinet/ipfw/ip_fw_private.h b/sys/netinet/ipfw/ip_fw_private.h index 1cb1115..44908d8 100644 --- a/sys/netinet/ipfw/ip_fw_private.h +++ b/sys/netinet/ipfw/ip_fw_private.h @@ -212,6 +212,8 @@ VNET_DECLARE(int, autoinc_step); VNET_DECLARE(unsigned int, fw_tables_max); #define V_fw_tables_max VNET(fw_tables_max) +struct pfil_head; + struct ip_fw_chain { struct ip_fw *rules; /* list of rules */ struct ip_fw *reap; /* list of rules to reap */ @@ -227,7 +229,7 @@ struct ip_fw_chain { spinlock_t rwmtx; spinlock_t uh_lock; #else - struct rwlock rwmtx; + struct pfil_head *phead; /* PFIL head used for locking */ struct rwlock uh_lock; /* lock for upper half */ #endif uint32_t id; /* ruleset id */ @@ -241,22 +243,21 @@ struct sockopt; /* used by tcp_var.h */ * so the variable and the macros must be here. */ +/* Additional locking init is done in vnet_ipfw_init() */ #define IPFW_LOCK_INIT(_chain) do { \ - rw_init(&(_chain)->rwmtx, "IPFW static rules"); \ rw_init(&(_chain)->uh_lock, "IPFW UH lock"); \ } while (0) #define IPFW_LOCK_DESTROY(_chain) do { \ - rw_destroy(&(_chain)->rwmtx); \ rw_destroy(&(_chain)->uh_lock); \ } while (0) -#define IPFW_WLOCK_ASSERT(_chain) rw_assert(&(_chain)->rwmtx, RA_WLOCKED) +#define IPFW_WLOCK_ASSERT(_chain) -#define IPFW_RLOCK(p) rw_rlock(&(p)->rwmtx) -#define IPFW_RUNLOCK(p) rw_runlock(&(p)->rwmtx) -#define IPFW_WLOCK(p) rw_wlock(&(p)->rwmtx) -#define IPFW_WUNLOCK(p) rw_wunlock(&(p)->rwmtx) +#define IPFW_RLOCK(p) pfil_rlock((p)->phead, &tracker) +#define IPFW_RUNLOCK(p) pfil_runlock((p)->phead, &tracker) +#define IPFW_WLOCK(p) pfil_wlock((p)->phead) +#define IPFW_WUNLOCK(p) pfil_wunlock((p)->phead) #define IPFW_UH_RLOCK(p) rw_rlock(&(p)->uh_lock) #define IPFW_UH_RUNLOCK(p) rw_runlock(&(p)->uh_lock) diff --git a/sys/netinet/ipfw/ip_fw_sockopt.c b/sys/netinet/ipfw/ip_fw_sockopt.c index a245143..b67b25d 100644 --- a/sys/netinet/ipfw/ip_fw_sockopt.c +++ b/sys/netinet/ipfw/ip_fw_sockopt.c @@ -56,6 +56,7 @@ __FBSDID("$FreeBSD: head/sys/netinet/ipfw/ip_fw_sockopt.c 233745 2012-03-31 11:2 #include #include #include +#include #include #include /* hooks */ @@ -953,6 +954,9 @@ ipfw_ctl(struct sockopt *sopt) u_int32_t rulenum[2]; uint32_t opt; char xbuf[128]; +#ifdef __FreeBSD__ + struct rm_priotracker tracker; +#endif ip_fw3_opheader *op3 = NULL; error = priv_check(sopt->sopt_td, PRIV_NETINET_IPFW); diff --git a/sys/netinet/ipfw/ip_fw_table.c b/sys/netinet/ipfw/ip_fw_table.c index d05c916..3eb412d 100644 --- a/sys/netinet/ipfw/ip_fw_table.c +++ b/sys/netinet/ipfw/ip_fw_table.c @@ -55,6 +55,7 @@ __FBSDID("$FreeBSD: head/sys/netinet/ipfw/ip_fw_table.c 238265 2012-07-08 21:13: #include #include /* ip_fw.h requires IFNAMSIZ */ #include +#include #include #include -- 1.7.9.4 --------------000105030205080004040409-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 11:51:52 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95199106566C; Wed, 5 Sep 2012 11:51:52 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E77F98FC14; Wed, 5 Sep 2012 11:51:48 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q85BpeEL029470; Wed, 5 Sep 2012 15:51:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q85BpeBO029469; Wed, 5 Sep 2012 15:51:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 5 Sep 2012 15:51:40 +0400 From: Gleb Smirnoff To: net@FreeBSD.org, pf@FreeBSD.org Message-ID: <20120905115140.GF15915@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [HEADS UP] merging projects/pf into head X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 11:51:52 -0000 Hi! [announce goes both to net@ and pf@, but any discussion should go on on pf@FreeBSD.org only, please] As you already may now, last half a year I've been working on making pf SMP-scalable and faster in general. More info can be found here: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html Since that announce in June, I've been running experimental code for more than 2 months in production on several routers. Also, some brave people volunteered to be beta-testers and also run the experimental branch in last couple of months. Code proved to be stable enough. The new code performs better in production: less CPU load, less jitter, more responsive system under high load. It performs better under synthetic benchmarks like random generated UDP flood. It performs much better when DoS comes in. Thus, I plan to merge projects/pf/head to head this weekend, and this is a HEADS UP email! You have been warned. :) What I'd like to do next: 1) Move pf out of contrib. 2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable kernel<->pfctl ABI. And probably other clean up tasks. ... 3) ... too far to build any plans, yet. :) -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 13:10:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18DF3106564A for ; Wed, 5 Sep 2012 13:10:02 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id AC49E8FC14 for ; Wed, 5 Sep 2012 13:10:01 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 941135C68A for ; Wed, 5 Sep 2012 15:02:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id sGqG7dBe3UAv for ; Wed, 5 Sep 2012 15:02:21 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 28A125C688 for ; Wed, 5 Sep 2012 15:02:21 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 22C3545084 for ; Wed, 5 Sep 2012 15:02:21 +0200 (CEST) Message-ID: <50474D5C.4020003@incore.de> Date: Wed, 05 Sep 2012 15:02:20 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Support for IPSec VPN's: some patches for netipsec/key.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:10:02 -0000 Hi, as continuation of http://lists.freebsd.org/pipermail/freebsd-stable/2012-April/067307.html I like to describe what I have done to get smartphones with IPSec VPN's working with a FreeBSD 8.3 server. The clients are IPhones with Cisco IPSec (authentication_method xauth_rsa_server in tunnel mode) and Androids with L2TP over IPSec (authentication_method rsasig in transport mode). On the server I have FreeBSD 8.3 with NAT-T support and the ports ipsec-tools-0.8.0_2 and mpd-5.5. To filter all packets in transport and tunnel mode on the enc0 interface, I use net.enc.out.ipsec_filter_mask=1 and net.enc.in.ipsec_filter_mask=3. Further my server has included the patches given in kern/146190 to ignore checksums and kern/169620 to avoid packet bypass on ngX. The following patches are all for netipsec/key.c: I use parameter "generate_policy on" in racoon.conf. This works for clients with NAT-T, but direct connected clients need the following patch (likewise in ipsec-tools/roadwarrior/client/phase1-up.sh): @@ -1927,19 +1930,27 @@ #if 1 if (newsp->req && newsp->req->saidx.src.sa.sa_family) { struct sockaddr *sa; + uint16_t *pport; sa = (struct sockaddr *)(src0 + 1); if (sa->sa_family != newsp->req->saidx.src.sa.sa_family) { _key_delsp(newsp); return key_senderror(so, m, EINVAL); } + pport = (uint16_t *)newsp->req->saidx.src.sa.sa_data; + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ + *pport = 0; } if (newsp->req && newsp->req->saidx.dst.sa.sa_family) { struct sockaddr *sa; + uint16_t *pport; sa = (struct sockaddr *)(dst0 + 1); if (sa->sa_family != newsp->req->saidx.dst.sa.sa_family) { _key_delsp(newsp); return key_senderror(so, m, EINVAL); } + pport = (uint16_t *)newsp->req->saidx.dst.sa.sa_data; + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ + *pport = 0; } #endif The next patch eliminates a (probably not important) mistake in loop handling and an important change in calling key_cmpsaidx() from key_getsah(). With this patch mixed transport and tunnel modes behind the same router work correct. @@ -1312,11 +1312,14 @@ continue; if (key_cmpspidx_exactly(spidx, &sp->spidx)) { SP_ADDREF(sp); - break; + SPTREE_UNLOCK(); + goto found; } } SPTREE_UNLOCK(); + return NULL; + found: return sp; } @@ -2968,11 +2983,15 @@ LIST_FOREACH(sah, &V_sahtree, chain) { if (sah->state == SADB_SASTATE_DEAD) continue; - if (key_cmpsaidx(&sah->saidx, saidx, CMP_REQID)) - break; + if (key_cmpsaidx(&sah->saidx, saidx, CMP_MODE_REQID)) { + SAHTREE_UNLOCK(); + goto found; + } } SAHTREE_UNLOCK(); + return NULL; + found: return sah; } The last patch makes it possible for a transport mode client to open a new connection to the server immediately after closing an old connection. Without this patch the client must wait for the routers to forget all there NAT entries. @@ -4065,10 +4084,12 @@ /* * If NAT-T is enabled, check ports for tunnel mode. * Do not check ports if they are set to zero in the SPD. - * Also do not do it for transport mode, as there is no + * Also do not do it for native transport mode, as there is no * port information available in the SP. */ - if (saidx1->mode == IPSEC_MODE_TUNNEL && + if ((saidx1->mode == IPSEC_MODE_TUNNEL || + (saidx1->mode == IPSEC_MODE_TRANSPORT && + saidx1->proto == IPPROTO_ESP)) && saidx1->src.sa.sa_family == AF_INET && saidx1->dst.sa.sa_family == AF_INET && ((const struct sockaddr_in *)(&saidx1->src))->sin_port && One case is left: At the moment it is not possible for the kernel to handle more than one IPSEC/L2TP (transport mode) connection from clients behind the same NAT router. To get rid of this limitation the kernel must do some housekeeping for the clients inner and outer udp src ports (the corresponding dst ports are 1701 and 4500) to find the correct SA for outgoing packets. I do not know what would be the best place to store these informations. Any suggestions ? At the end a question: At the beginning of ip_ipsec_output() in ip_ipsec.c the flag PACKET_TAG_IPSEC_PENDING_TDB is used, but I can not find the place where this flag is set in the kernel. Can somebody enlighten me ? -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lbeck, HRB 318 BS Geschftsfhrer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 13:45:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5F1106564A for ; Wed, 5 Sep 2012 13:45:08 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5D5408FC12 for ; Wed, 5 Sep 2012 13:45:05 +0000 (UTC) Received: from ken (ken.zen.inc [192.168.1.4]) by smtp.zeninc.net (smtpd) with ESMTP id 0A6BA2798BC for ; Wed, 5 Sep 2012 15:38:23 +0200 (CEST) Received: by ken (Postfix, from userid 1000) id C767D4040; Wed, 5 Sep 2012 15:38:22 +0200 (CEST) Date: Wed, 5 Sep 2012 15:38:22 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20120905133822.GA4762@zeninc.net> References: <50474D5C.4020003@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50474D5C.4020003@incore.de> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Support for IPSec VPN's: some patches for netipsec/key.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:45:09 -0000 On Wed, Sep 05, 2012 at 03:02:20PM +0200, Andreas Longwitz wrote: > Hi, as continuation of Hi. [....] > The following patches are all for netipsec/key.c: > > I use parameter "generate_policy on" in racoon.conf. This works for > clients with NAT-T, but direct connected clients need the following > patch (likewise in ipsec-tools/roadwarrior/client/phase1-up.sh): > > @@ -1927,19 +1930,27 @@ > #if 1 > if (newsp->req && newsp->req->saidx.src.sa.sa_family) { > struct sockaddr *sa; > + uint16_t *pport; > sa = (struct sockaddr *)(src0 + 1); > if (sa->sa_family != newsp->req->saidx.src.sa.sa_family) { > _key_delsp(newsp); > return key_senderror(so, m, EINVAL); > } > + pport = (uint16_t *)newsp->req->saidx.src.sa.sa_data; > + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ > + *pport = 0; > } > if (newsp->req && newsp->req->saidx.dst.sa.sa_family) { > struct sockaddr *sa; > + uint16_t *pport; > sa = (struct sockaddr *)(dst0 + 1); > if (sa->sa_family != newsp->req->saidx.dst.sa.sa_family) { > _key_delsp(newsp); > return key_senderror(so, m, EINVAL); > } > + pport = (uint16_t *)newsp->req->saidx.dst.sa.sa_data; > + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ > + *pport = 0; > } > #endif I'm not sure it will happen in real life configurations, but if someones does really want to setup a SP entry for port 500 (tunnel mode, or anything else which may need that), your patch will prevent it from working. It may be cleaner to have racoon generate the good SP entry, rather than kernel trying to guess what is right in a SPDADD command. [....] > The last patch makes it possible for a transport mode client to open a > new connection to the server immediately after closing an old > connection. Without this patch the client must wait for the routers to > forget all there NAT entries. > > @@ -4065,10 +4084,12 @@ > /* > * If NAT-T is enabled, check ports for tunnel mode. > * Do not check ports if they are set to zero in the SPD. > - * Also do not do it for transport mode, as there is no > + * Also do not do it for native transport mode, as there is no > * port information available in the SP. > */ > - if (saidx1->mode == IPSEC_MODE_TUNNEL && > + if ((saidx1->mode == IPSEC_MODE_TUNNEL || > + (saidx1->mode == IPSEC_MODE_TRANSPORT && > + saidx1->proto == IPPROTO_ESP)) && > saidx1->src.sa.sa_family == AF_INET && > saidx1->dst.sa.sa_family == AF_INET && > ((const struct sockaddr_in *)(&saidx1->src))->sin_port && Right, I'll commit it on HEAD ASAP. > At the end a question: At the beginning of ip_ipsec_output() in > ip_ipsec.c the flag PACKET_TAG_IPSEC_PENDING_TDB is used, but I can not > find the place where this flag is set in the kernel. Can somebody > enlighten me ? Good question..... According to my grep and gtags, nowhere...... Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 15:47:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2E731065680; Wed, 5 Sep 2012 15:47:23 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 30A278FC12; Wed, 5 Sep 2012 15:47:23 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 125B05C692; Wed, 5 Sep 2012 17:47:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id tErjlFqUw_8g; Wed, 5 Sep 2012 17:47:21 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 1CADB5C691; Wed, 5 Sep 2012 17:47:21 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 14B0645087; Wed, 5 Sep 2012 17:47:21 +0200 (CEST) Message-ID: <50477408.30003@incore.de> Date: Wed, 05 Sep 2012 17:47:20 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: VANHULLEBUS Yvan , freebsd-net@freebsd.org References: <50474D5C.4020003@incore.de> <20120905133822.GA4762@zeninc.net> In-Reply-To: <20120905133822.GA4762@zeninc.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Support for IPSec VPN's: some patches for netipsec/key.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:47:23 -0000 Hi, >> The following patches are all for netipsec/key.c: >> >> I use parameter "generate_policy on" in racoon.conf. This works for >> clients with NAT-T, but direct connected clients need the following >> patch (likewise in ipsec-tools/roadwarrior/client/phase1-up.sh): >> >> @@ -1927,19 +1930,27 @@ >> #if 1 >> if (newsp->req && newsp->req->saidx.src.sa.sa_family) { >> struct sockaddr *sa; >> + uint16_t *pport; >> sa = (struct sockaddr *)(src0 + 1); >> if (sa->sa_family != newsp->req->saidx.src.sa.sa_family) { >> _key_delsp(newsp); >> return key_senderror(so, m, EINVAL); >> } >> + pport = (uint16_t *)newsp->req->saidx.src.sa.sa_data; >> + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ >> + *pport = 0; >> } >> if (newsp->req && newsp->req->saidx.dst.sa.sa_family) { >> struct sockaddr *sa; >> + uint16_t *pport; >> sa = (struct sockaddr *)(dst0 + 1); >> if (sa->sa_family != newsp->req->saidx.dst.sa.sa_family) { >> _key_delsp(newsp); >> return key_senderror(so, m, EINVAL); >> } >> + pport = (uint16_t *)newsp->req->saidx.dst.sa.sa_data; >> + if ( *pport == htons(500) ) /* UDP_ENCAP_ESPINUDP_PORT */ >> + *pport = 0; >> } >> #endif > > I'm not sure it will happen in real life configurations, but if > someones does really want to setup a SP entry for port 500 (tunnel > mode, or anything else which may need that), your patch will prevent > it from working. Yes, I agree. > It may be cleaner to have racoon generate the good SP entry, rather > than kernel trying to guess what is right in a SPDADD command. The SPDADD command is done by racoon because I have generate_policy on, but racoon sets ports to 500 for direct connected clients. If this would be fixed in racoon, then the above kernel patch is superfluous. >> The last patch makes it possible for a transport mode client to open a >> new connection to the server immediately after closing an old >> connection. Without this patch the client must wait for the routers to >> forget all there NAT entries. >> >> @@ -4065,10 +4084,12 @@ >> /* >> * If NAT-T is enabled, check ports for tunnel mode. >> * Do not check ports if they are set to zero in the SPD. >> - * Also do not do it for transport mode, as there is no >> + * Also do not do it for native transport mode, as there is no >> * port information available in the SP. >> */ >> - if (saidx1->mode == IPSEC_MODE_TUNNEL && >> + if ((saidx1->mode == IPSEC_MODE_TUNNEL || >> + (saidx1->mode == IPSEC_MODE_TRANSPORT && >> + saidx1->proto == IPPROTO_ESP)) && >> saidx1->src.sa.sa_family == AF_INET && >> saidx1->dst.sa.sa_family == AF_INET && >> ((const struct sockaddr_in *)(&saidx1->src))->sin_port && > > Right, I'll commit it on HEAD ASAP. Good news, thanks ! Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 20:09:24 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E344B1065670; Wed, 5 Sep 2012 20:09:24 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6828FC1E; Wed, 5 Sep 2012 20:09:24 +0000 (UTC) Received: by iebc12 with SMTP id c12so2290708ieb.13 for ; Wed, 05 Sep 2012 13:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=BAaa1Wv/Bf5vA5OAKsyEV1J0V65x/iRPY6CQ24BrjaE=; b=YMTeteWrlxchI7sKHswQV5FYW6pTQmNM4wl9QOpxRMSOxnzAVE9q/aqHQvdhr3aY/t uTJBkaMM/iOkRJyxpr5ZNwPtBzFBaP/VXuhzcc6PUQc9BK4WqJuS6+LELuFBM7lqqDDC pkW1BMQ2aWNOWAyFdL+sCILteRWq4bABiuT45D+qNDJfvhk9tiVmGTU6m1pbmEw+bxdd x9WFbtcDjes3EOSyf1tHQjuAeDs1NNgc+We00tkT9xdr5CO/cz3t76G4fmyB91mPlLWL TE+gbZ6ua2w8W1yzCptirgYT36KaFtLz/a5MxVFfj+IWKaI6rS/8e4ZL2WY7yYJEedaJ IaKQ== MIME-Version: 1.0 Received: by 10.42.155.135 with SMTP id u7mr22127547icw.25.1346875764014; Wed, 05 Sep 2012 13:09:24 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.47.73 with HTTP; Wed, 5 Sep 2012 13:09:23 -0700 (PDT) In-Reply-To: <20120905115140.GF15915@FreeBSD.org> References: <20120905115140.GF15915@FreeBSD.org> Date: Wed, 5 Sep 2012 22:09:23 +0200 X-Google-Sender-Auth: KpA_Ufil8V4wmk4YQRXcnRAJ6hs Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: pf@freebsd.org, net@freebsd.org Subject: Re: [HEADS UP] merging projects/pf into head X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:09:25 -0000 Hi Gleb, On Wed, Sep 5, 2012 at 1:51 PM, Gleb Smirnoff wrote: > Hi! > > [announce goes both to net@ and pf@, but any discussion should > go on on pf@FreeBSD.org only, please] > > As you already may now, last half a year I've been working on > making pf SMP-scalable and faster in general. More info can be > found here: > > http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html > http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html > > Since that announce in June, I've been running experimental code for > more than 2 months in production on several routers. Also, some brave > people volunteered to be beta-testers and also run the experimental > branch in last couple of months. Code proved to be stable enough. > > The new code performs better in production: less CPU load, less > jitter, more responsive system under high load. It performs better > under synthetic benchmarks like random generated UDP flood. It > performs much better when DoS comes in. > Its good to see results on your work and is good moving forward. Claiming better behavior, under DoS or other comparison without showing any data or technical reason is a bit over this RFC. > Thus, I plan to merge projects/pf/head to head this weekend, and > this is a HEADS UP email! You have been warned. :) > > What I'd like to do next: > > 1) Move pf out of contrib. I do not see a reason behind this, any particular reason? > 2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable > kernel<->pfctl ABI. And probably other clean up tasks. Just this reason is a bit contradictory with 1) above! Let alone what does this mean to the user?! Nothing? They are after syntax stability, not breaking their machines on upgrade, ABI is nothing to them. Please reconsider the option of renaming the import and allowing both ports to coexist. Than you can have your changes going through. Regards, Ermal From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 20:15:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0435106564A for ; Wed, 5 Sep 2012 20:15:42 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id A1C828FC1E for ; Wed, 5 Sep 2012 20:15:42 +0000 (UTC) Received: from [209.249.190.124] (port=62442 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T9M0g-0003AA-PS; Wed, 05 Sep 2012 16:15:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: George Neville-Neil In-Reply-To: Date: Wed, 5 Sep 2012 16:15:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com> References: To: Anuranjan Shukla X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:15:43 -0000 On Aug 25, 2012, at 00:11 , Anuranjan Shukla wrote: > At Juniper Networks, we've been using FreeBSD to build JUNOS (Juniper's > network operating system). So far the additions and changes to the > functionality were made inline, making the task of upgrading to new > versions of FreeBSD progressively difficult. We've been looking at JUNOS > to see if we can build it off of a clean FreeBSD base rather than making > changes to the OS inline. As part of that work, we've come up with a few > expansive change proposals to FreeBSD kernel that will make this task > possible for us, and hopefully also contribute something of interest to > the community. If the community is in agreement with these, we'd like to > contribute/commit them to FreeBSD. > > This is a proposal and an RFC. The actual nomenclature is open to ideas > (naming etc). From Juniper, Marcel (marcel@freebsd.org) will be attending > the upcoming DevSummit at Cambridge. He's indicated that interested folks > are welcome to chat with him about this stuff during the summit. > Hello Anu, Yes, a bunch of this was discussed at the DevSummit, and I think there is already some agreement about these proposals, at least there was in the room, now to get some on net@. > The changes we propose are (the code/diffs etc are indicated > at the end of this email): > > - Network Device Drivers > - Building FreeBSD kernel without network stack, network stack as a module > - Changes to mbuf and socket structures (minor member additions) > > Network Device Drivers: > ----------------------- > As we indicated during DevSummit 2012, JUNOS extended the interface > functionality in a big way to support logical interfaces, interface > hierarchies and scaling in general. Not surprisingly this resulted in > changing the drivers to use our custom interface structure(s). A simple > way to resolve this without impacting the rest of the large codebase is to > avoid directly accessing (get/set) the ifnet structure from the drivers. > Using get/set functions to update the functionality would make the driver > more 'flexible' for the network stack to work with in situations where the > stack wants to extend the interface functionality. > > For eg, > > em_start_locked(struct ifnet *ifp, struct tx_ring *txr) > { > - struct adapter *adapter = ifp->if_softc; > + struct adapter *adapter = if_getsoftc(ifp); > struct mbuf *m_head; > > EM_TX_LOCK_ASSERT(txr); > > - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != > + if ((if_getdrvflags(ifp) & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != > IFF_DRV_RUNNING) > return; > > if (!adapter->link_active) > return; > > - while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > + while (!if_sendq_empty(ifp)) { > /* Call cleanup if number of TX descriptors low */ > if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > em_txeof(txr); > if (txr->tx_avail < EM_MAX_SCATTER) { > - ifp->if_drv_flags |= IFF_DRV_OACTIVE; > + if_setdrvflagbits(ifp,IFF_DRV_OACTIVE, 0); > break; > } > - IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); > + m_head = if_dequeue(ifp); > if (m_head == NULL) > break; > /* > @@ -1010,7 +1009,7 @@ em_start_locked(struct ifnet *ifp, struct tx_ring > if (em_xmit(txr, &m_head)) { > if (m_head == NULL) > break; > - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > + if_sendq_prepend(ifp, m_head); > break; > > This allows Juniper to have its own interface structure(s) instead of > ifnet, and still be able to use the driver without modification. Since the > notion of ifnet is abstracted away, other users can also find this useful > in plugging in functionality without having muck around in the driver code. > > The ifnet split/restructuring was discussed in DevSummit at BSDCan in May > 2012. This change can also aid in that work. > > This change can be applied to drivers in a phased way. Clearly, it won't > have any impact on drivers that haven't been changed. At Juniper we're > planning on converting em,fxp and tsec. Are there any strong feelings on > whether the phase-wise change is ok or not? > > I think these changes might be aided by something that bz@ and I talked about after the network session, to wit, we could stand to abstract a good deal of code away from the drivers, and up into the ethernet and other modules. I think trying to reduce the amount of code in the drivers, much of which is common code, is the way for us to go. As part of that we can start to use the functions that you mention. > Building FreeBSD without the network stack (network stack as a module) > ---------------------------------------------------------------------- > Today, not compiling networking stack related files in the kernel breaks > the kernel build due to dependencies the OS has on the network stack > (calling into functions in the network stack). Network stack module isn't > there. We've added these in JUNOS. The benefits for us are obvious (we can > load our own version of network stack if we desire!), but most likely this > functionality will benefit others too. > > The detailed implementation is indicated later in this email. In short the > changes are: > > - Load network stack as a module. For now via loader, not dynamically > loaded. (Is there interest in dynamic loading?). > - To facilitate calling network stack functionality from the generic > kernel, a new interface has been defined with the kobj framework. > - Some files and tunables needed to move to generic kernel areas (accept > filters) > - Generic socket code calls into network stack for interface and route > related ioctls. Network stack now registers these ioctl groups > - Other changes: uuid generation (register/query uuid sources), fib/sctp > system calls (moved to network stack code, with system calls register > dynamically). > This would be interesting for many reasons, and I think it would be a good contribution. Does the work you've done in this area handle the VNET stuff that is in the stack as well? That is, how well does the network stack as a module play with the vnet architecture? > Changes to mbuf and socket structures > -------------------------------------- > A couple additions to these structures help JUNOS incorporate cool things > like interface/route indices and logical routing. For us the diff today > looks > something like: > > struct pkthdr { > + uint32_t rcvidx; /* rcv interface index */ > + uint32_t rnhidx; /* route or nexthop index */ > struct ifnet *rcvif; /* rcv interface */ > These seem straightforward, but, of course must go into a .0 release. > struct socket { > > int so_fibnum; /* routing domain for this socket */ > uint32_t so_user_cookie; > + u_int so_oqueue; /* manage send prioritizing based on application > needs */ > + u_short so_lrid; /* logical routing */ > }; > I'd be interested to know how this is used. > A question for the community is if it's there're strong objections to > adding fields to these structures. If so, do we have another way or a > suggestion to consider? > So long as you're happy living with them in a .0 that's, I believe, fine. > For a detailed look, diffs can be found at: > http://people.freebsd.org/~marcel/Juniper/ddi-mbuf-socket.diff > http://people.freebsd.org/~marcel/Juniper/netstack.diff > > These will provide a good idea of the changes. They're not in final shape > yet. > OK, I think we should keep this moving along. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 20:16:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7FE61065672 for ; Wed, 5 Sep 2012 20:16:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8A16F8FC20 for ; Wed, 5 Sep 2012 20:16:31 +0000 (UTC) Received: from [209.249.190.124] (port=62442 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T9M1X-0003AA-7k; Wed, 05 Sep 2012 16:16:31 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: George Neville-Neil In-Reply-To: Date: Wed, 5 Sep 2012 16:16:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <570F1A37-38F0-41CF-91C7-B6047AA79E97@neville-neil.com> References: To: Anuranjan Shukla X-Mailer: Apple Mail (2.1486) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:16:31 -0000 One more note. Can you break the patches down into more bite sized = pieces? They're hard to review as is. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 04:46:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66E64106566C for ; Thu, 6 Sep 2012 04:46:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 336248FC0A for ; Thu, 6 Sep 2012 04:46:53 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2067406pbb.13 for ; Wed, 05 Sep 2012 21:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=f3HnE5DEQlnae+bAoUmNS9F4KwgPWkSVKg7KYVCD+p0=; b=QYBd+awNThIWvrT0t+g5Sk3ykvmoUHvMWw+dIX1iXITLOyTxwUTKU4bjNfW/chiAx8 L0iMcrg03GLLlfVoM9yru2YDl44gx2lBdHneYOkV307+ekIp9dIg7kULO8SCbZO56rmh SV77U3KfrOed6dJ17TuZBoF5gLBEqGYAt6nbF1sB1ofGqHXsh1y+/UGodgg2PoCCT5aZ 3VrYyfdUj5RrtJImgGm48AUCMrb5CZ96Si57gplvz9yEkB/LAGqsKp+7ShJBcAzP2qf9 8U3MxV3I3swhTWvcu52JYQ6J+8JNe8yfmm7/6n0eLrDTpY7wAI24htIKgKlVlzxR561V 6hDA== Received: by 10.68.125.133 with SMTP id mq5mr3098297pbb.42.1346906812711; Wed, 05 Sep 2012 21:46:52 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id tq4sm723613pbc.11.2012.09.05.21.46.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 21:46:51 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 06 Sep 2012 13:46:43 -0700 From: YongHyeon PYUN Date: Thu, 6 Sep 2012 13:46:43 -0700 To: Jason Wolfe Message-ID: <20120906204643.GC3160@michelle.cdnetworks.com> References: <4FFFBA0D.7080505@norma.perm.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, "Eugene M. Zheganin" Subject: Re: Broadcom NetXtreme BCM5719 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 04:46:53 -0000 On Wed, Jul 25, 2012 at 01:21:05PM -0700, Jason Wolfe wrote: > On Thu, Jul 12, 2012 at 11:02 PM, Eugene M. Zheganin wrote: > > Hi. > > > > > > On 13.07.2012 04:39, Jason Wolfe wrote: > >> > >> bge0: mem > >> 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq > >> 32 at device 0.0 on pci3 > >> bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > >> miibus0: on bge0 > >> bge0: Ethernet Address: xx:xx:xx:xx:xx:xx > >> ... > >> bge0: watchdog timeout -- resetting > >> bge0: link state changed to UP > >> bge0: link state changed to DOWN > >> bge0: link state changed to UP > >> bge0: link state changed to DOWN > >> bge0: link state changed to UP > >> bge0: link state changed to DOWN > >> ... > >> > >> > >> bge0@pci:0:3:0:0: class=0x020000 card=0x169d103c chip=0x165714e4 > >> rev=0x01 hdr=0x00 > >> vendor = 'Broadcom Corporation' > >> device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' > >> class = network > >> subclass = ethernet > >> > >> Anything in the pipe on this one, or any access I can provide that > >> might assist us? > >> > > I got a BMC5722 chip (and IBM x3250 mX systems), but same stuff with > > timeout/resets. I can say 8.1/8.2 were more stable concerning bge(4). > > You could try to switch off tso and vlanhwtso, at least it did the trick for > > me (did it ? not sure though. I was having problems one a month on 8.1/8.2, > > after upgrading to 8.3-STABLE I start having problems with it every day, > > literally, after ifconfig bge0 -tso -vlanhwtso it's running for 5 day now.) > > > > Eugene. > > Yeah, I had no luck even with all options disabled. The NIC > constantly bounces, and ifconfig never reports anything but "status: > no carrier". No love on the driver side for this NetXtreme BCM5719 > Gigabit Ethernet PCIe card? See kern/171121. Give latest WIP version spin and let me know how it goes on your box. > > Jason From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 07:08:08 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DAEA106564A; Thu, 6 Sep 2012 07:08:08 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 88CF58FC0A; Thu, 6 Sep 2012 07:08:07 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q867860v036324; Thu, 6 Sep 2012 11:08:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q86786eu036323; Thu, 6 Sep 2012 11:08:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 6 Sep 2012 11:08:06 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120906070806.GM15915@glebius.int.ru> References: <20120905115140.GF15915@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: pf@FreeBSD.org, net@FreeBSD.org Subject: Re: [HEADS UP] merging projects/pf into head X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:08:08 -0000 Ermal, On Wed, Sep 05, 2012 at 10:09:23PM +0200, Ermal Lu?i wrote: E> Its good to see results on your work and is good moving forward. E> Claiming better behavior, under DoS or other comparison without showing any data E> or technical reason is a bit over this RFC. Benchmark by authors are always biased, thus I didn't boast about results. Much better if benchmarking is performed by someone else. If you insist here is some data: 1) Casting UDP flood of 400k states in this simple setup: [box A] -> [pf] -> [blackhole] On my particular box, head pf can forward 520 kpps and anything above is lost. SMP-pf can do 980 kpps. If we increase number of states, results would be more dramatic. If we make load bidirectional (which is the case in 99%) results would be more dramatic. Increasing number of rx/tx threads (more NICs, or more smart NICs) as well as increasing number of CPUs would make results even more dramatic. 2) DoSes Results are just empirical. At my job, when running old pf and encountering DoS attack, we usually notice that by bad web sites responsibility, customers complaining, etc. The box under attack is very unresponsive via ssh. With new SMP-pf a DoS may come in and if it doesn't consume entire bandwidth it can be noticed only post-factum when looking at monitoring plots. I'd appreciate if you perform benchmarking and testing. As said above, results from author are usually biased, but results from opponents more interesting. E> > 1) Move pf out of contrib. E> I do not see a reason behind this, any particular reason? It is no longer contributed source, but source developed by the FreeBSD project. E> > 2) Refactor the pfvar.h into pf.h and pf_var.h. Provide stable E> > kernel<->pfctl ABI. And probably other clean up tasks. E> Just this reason is a bit contradictory with 1) above! E> Let alone what does this mean to the user?! Nothing? E> They are after syntax stability, not breaking their machines on E> upgrade, ABI is nothing to them. Do you understand that "absense of stable ABI" == "breaking machines after upgrade"? Right now, the structures supplied via ioctl() include many fields that aren't related to API, but are internal kernel. Any internal kernel change breaks ABI. If new API structures are introduced, then we can do a lot of hacking on pf in 11.0-CURRENT with ability to safely merge changes to 10.0-STABLE. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 17:00:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C925106564A; Thu, 6 Sep 2012 17:00:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 607338FC08; Thu, 6 Sep 2012 17:00:46 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2953227pbb.13 for ; Thu, 06 Sep 2012 10:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SBr5lNVrA6bLsqoAf/nLZgZsb4xgWCl4Gm0Du8BT50U=; b=0NCt4Re/I2Rc+RXE3Sh76y3xEKbdJY+LU76YZKS4gdSmrB1FdDQKydS23699ZkA4px Kyui2xifLj2a6DrBhbWwnD+n0LPWMLc9PZayyz+JreZhQlWaYCv+tw2miU9EDoyj4mXv peOy4eEoE33YfhEy5OKesukJ4qALncIwaM+HElnk+2/Wj7YaamgaH2s4BI8kcEChZ4mo 8WdQpBsXcBLsqIkGMYQGK0Rz+zjxdW3AcJkI0GKmzH59lS5rtg3VgtwpWl9slq3qaSd4 0lcr82fG7xRQbI2NZOTo3F3l7ALxidfBQ+V/cYHgJuuncaLFYpWJtfaLLptfJ/T7Omjq hZeA== MIME-Version: 1.0 Received: by 10.68.197.167 with SMTP id iv7mr1214760pbc.113.1346950845839; Thu, 06 Sep 2012 10:00:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 10:00:45 -0700 (PDT) In-Reply-To: <5046FE57.3050903@rdtc.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> Date: Thu, 6 Sep 2012 10:00:45 -0700 X-Google-Sender-Auth: 8Zc5goz7b_ufRlncHOnX8b8__Gs Message-ID: From: Adrian Chadd To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:00:46 -0000 On 5 September 2012 00:25, Eugene Grosbein wrote: > 05.09.2012 14:03, Adrian Chadd =D0=C9=DB=C5=D4: >> waaaaaaaaait. >> >> Did you say that removing preemption from your kernel fixed your >> performance issues? > > Yes. Also, it seems my original vr(4) troubles (RX path problem) > have gone away since I run the kernel without preemption. Ok. Can you please compile up both a preempt and non-preempt 4BSD kernel with KTR enabled? That way we can capture some schedgraph traces and see what the heck is going on. THanks, Adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 17:04:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EB07106566C; Thu, 6 Sep 2012 17:04:43 +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 7EED18FC15; Thu, 6 Sep 2012 17:04:42 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q86H4d0s062018; Fri, 7 Sep 2012 00:04:39 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5048D7A7.1030708@rdtc.ru> Date: Fri, 07 Sep 2012 00:04:39 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:04:43 -0000 07.09.2012 00:00, Adrian Chadd : > On 5 September 2012 00:25, Eugene Grosbein wrote: >> 05.09.2012 14:03, Adrian Chadd : >>> waaaaaaaaait. >>> >>> Did you say that removing preemption from your kernel fixed your >>> performance issues? >> >> Yes. Also, it seems my original vr(4) troubles (RX path problem) >> have gone away since I run the kernel without preemption. > > Ok. Can you please compile up both a preempt and non-preempt 4BSD > kernel with KTR enabled? Yes, I can easily. What should I do next? > That way we can capture some schedgraph traces and see what the heck > is going on. I have not used KTR before, please direct me :-) From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 17:34:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2401B1065701; Thu, 6 Sep 2012 17:34:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 757798FC0A; Thu, 6 Sep 2012 17:34:06 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2996600pbb.13 for ; Thu, 06 Sep 2012 10:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=39PxzDk65KYKpS1STM+Q56EANIrL4fnRm2NkoJNXc1M=; b=JUZ9sXMdV4z7xhx8bgLZ1ZnhPf/MmzQKuB9MclBpZpOhEwxigvDHhgYZ4Hv6M/NYQG fYfzwU3fzIaKyRcFiaZpUdzBvK89BGso3+93Fzkj4H3FQ36BvGaCShSH6yrXR3MaOJGB Z/76VrKgrREA1ihPZw3AxW3NUUo71muNg2ouKH9+n8Xx1uVbh7wnBCD4bcFdKtIxXF4M WVJohmo8dEgY5W/+qh4YkyFou0LUdgKrXa1XQ4TTL7Ao4RpsK7g2spnZcEQ6GOUYwhRb 0pNdf1UIqtpEB1e9FlrwNosCY0q/9l4sEtYwKVi2USIC5FIO9klP2yZx0qHKHo5Q3TyC SKIw== MIME-Version: 1.0 Received: by 10.68.129.131 with SMTP id nw3mr5660345pbb.43.1346952846235; Thu, 06 Sep 2012 10:34:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 10:34:05 -0700 (PDT) In-Reply-To: <5048D7A7.1030708@rdtc.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> Date: Thu, 6 Sep 2012 10:34:05 -0700 X-Google-Sender-Auth: SdUW-ZR9C1s2ahLl6sdb4XGYyEY Message-ID: From: Adrian Chadd To: Eugene Grosbein , Alexander Motin Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Lev Serebryakov , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:34:07 -0000 mav, where is the KTR/schedgraph help page(s) hiding? ADrian On 6 September 2012 10:04, Eugene Grosbein wrote: > 07.09.2012 00:00, Adrian Chadd =D0=C9=DB=C5=D4: >> On 5 September 2012 00:25, Eugene Grosbein wrote: >>> 05.09.2012 14:03, Adrian Chadd =D0=C9=DB=C5=D4: >>>> waaaaaaaaait. >>>> >>>> Did you say that removing preemption from your kernel fixed your >>>> performance issues? >>> >>> Yes. Also, it seems my original vr(4) troubles (RX path problem) >>> have gone away since I run the kernel without preemption. >> >> Ok. Can you please compile up both a preempt and non-preempt 4BSD >> kernel with KTR enabled? > > Yes, I can easily. What should I do next? > >> That way we can capture some schedgraph traces and see what the heck >> is going on. > > I have not used KTR before, please direct me :-) From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 17:38:58 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6593A106564A for ; Thu, 6 Sep 2012 17:38:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 379BB8FC15 for ; Thu, 6 Sep 2012 17:38:58 +0000 (UTC) Received: by dadr6 with SMTP id r6so1281621dad.13 for ; Thu, 06 Sep 2012 10:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WJdoaM4mvIjHuH3qKnWydfiD8lYOQyro9NsiQtMCHWY=; b=lHh8/gmwpKlUJhS3OTMOHgdnsY6LmTYLl1w9qV5eJLNPLuSWi9FZC5+SkPQciZ8JLz e/aUzj99i9dxFPpb11B2SY9svhYYOyerPArYY+Sm7DknF5M1YBRvWKmR5fMFBoCjpVbr RgWsbev+c95c+NgCQMA3eMI9qn5eapdof7nOnLUIia7JJ+WyUdF1q8gkeDoB7i9GQh/F iW/dDYlDbHTPQMxxW03aZfTkBE1vmwwqQ3OKcCC+0xtBAAmfjFPhTf3OQt5PJI934rvm eJtRRdEdDk8f+seGOaokQiYyDlNZq13dHaggVk1jlRGlpv5SNHHZToijiY1FBYunJXjb Skog== MIME-Version: 1.0 Received: by 10.66.85.4 with SMTP id d4mr4389980paz.11.1346953137546; Thu, 06 Sep 2012 10:38:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 10:38:57 -0700 (PDT) In-Reply-To: <20120902212952.GB2654@aspire.rulingia.com> References: <20120830215147.GA2383@-> <20120831104532.GA1758@-> <20120902212952.GB2654@aspire.rulingia.com> Date: Thu, 6 Sep 2012 10:38:57 -0700 X-Google-Sender-Auth: a3SEljVlT9BHijBQCjSVKguHP4g Message-ID: From: Adrian Chadd To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: kaltheat@googlemail.com, net@freebsd.org Subject: Re: lagg failover issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:38:58 -0000 On 2 September 2012 14:29, Peter Jeremy wrote: > Adrian, > > On 2012-Aug-31 04:29:53 -0700, Adrian Chadd wrote: >>You can't override set the outbound MAC address of a wireless station. >>It associates with the MAC address of the card/vap/device. The AP >>_will_ store that MAC address in its node table. > > Are you saying I can't portably do the following: > # ifconfig ath0 ether 00:11:22:33:44:55 > # ifconfig create wlan0 wlandev ath0 ssid my_net up There's some weird, undocumented crap surrounding changing MAC addresses but in theory, once the right incantation works, that should work fine. However, lagg would then have to ensure a broadcast frame will go out so the forwarding tables get updated. Or else various L2 devices won't know the location of your device has changed. I'ms aying if you placed an ath STA vap into a bridge group or some other device that sent frames from a source MAC that wasn't the STA MAC, it won't work. That only works with 4-address WDS mode. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 17:40:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 644A1106567C; Thu, 6 Sep 2012 17:40:21 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.62.193]) by mx1.freebsd.org (Postfix) with ESMTP id 093AB8FC12; Thu, 6 Sep 2012 17:40:20 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 6EDE3C381A; Thu, 6 Sep 2012 19:40:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at solomo.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9VQFWwzWsxro; Thu, 6 Sep 2012 19:40:18 +0200 (CEST) Received: from nibbler-osx-wlan.fritz.box (unknown [IPv6:2001:4dd0:ff00:8bb6:d0b2:2c4:6e43:ecfa]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id D8298C382B; Thu, 6 Sep 2012 19:40:14 +0200 (CEST) Message-ID: <5048DFF8.50405@smeets.im> Date: Thu, 06 Sep 2012 19:40:08 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0 MIME-Version: 1.0 To: Adrian Chadd References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEF70C40F6E02478251ABB40" Cc: pyunyh@gmail.com, Lev Serebryakov , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:40:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEF70C40F6E02478251ABB40 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 06.09.12 19:34, Adrian Chadd wrote: > mav, where is the KTR/schedgraph help page(s) hiding? >=20 At the top (below the license) of tools/sched/schedgraph.py there is a "# To use:" section. It should have everything you need. HTH, Florian --------------enigCEF70C40F6E02478251ABB40 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlBI3/kACgkQapo8P8lCvwkTHwCg4izU1bM4fsWPs8nD/w2BJnWw jBUAoK4br3f9Xv7znvNCQ2ADw9UorIin =m0Yz -----END PGP SIGNATURE----- --------------enigCEF70C40F6E02478251ABB40-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 17:41:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DE551065673; Thu, 6 Sep 2012 17:41:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A272F8FC21; Thu, 6 Sep 2012 17:41:39 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so3006336pbb.13 for ; Thu, 06 Sep 2012 10:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9uKMJ66HirGLxYtskt9CgCNrx3RSjCrl6lHV3NipjkU=; b=j1yw80zD5zWf8kXxR5godr0m1DcEKNDHX4m1hSxuLZxOCnxicnfxYpZQxkWZD6e+b2 jFJMiThFwL0bZfkLx/NFcP6UG7EhApBZDQrNAjMhKbWfMny0X7z3Wu/tahY+Ipo8wABh qsZ3dlZj4mF2qydpMmUcrihtGInFDU3pPawJ3cQzRt6e4L5TBiXdSrUtRXe6X7fJABmk JbBX86xt1Klcm9NEZgTuwuEpJOf7IDVx4OvGqCOGVTUMCfdRnlOQ7H/wkEEZqgencsY1 s5txmwIkFbGjCn2aSYWMUrsq3s9rY8MXINAPqmKI0L/5/x/56+Xxp+cc/gbhOiL/IdDU /rzw== MIME-Version: 1.0 Received: by 10.68.189.70 with SMTP id gg6mr5574758pbc.125.1346953299139; Thu, 06 Sep 2012 10:41:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 10:41:39 -0700 (PDT) In-Reply-To: <5048DFF8.50405@smeets.im> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> Date: Thu, 6 Sep 2012 10:41:39 -0700 X-Google-Sender-Auth: mN7eiG-YwPAR9AoqZbmfDxGGSt4 Message-ID: From: Adrian Chadd To: Florian Smeets Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, Lev Serebryakov , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:41:40 -0000 On 6 September 2012 10:40, Florian Smeets wrote: > On 06.09.12 19:34, Adrian Chadd wrote: >> mav, where is the KTR/schedgraph help page(s) hiding? >> > > At the top (below the license) of tools/sched/schedgraph.py there is a > "# To use:" section. It should have everything you need. Thanks, I thought there was also a wiki page somewhere? Adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:01:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CEBD106564A; Thu, 6 Sep 2012 18:01:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD028FC0C; Thu, 6 Sep 2012 18:01:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8574:b973:3b96:4bfa]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id EA85E4AC31; Thu, 6 Sep 2012 22:00:59 +0400 (MSK) Date: Thu, 6 Sep 2012 22:00:55 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <10710514011.20120906220055@serebryakov.spb.ru> To: Adrian Chadd In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, Florian Smeets , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:01:02 -0000 Hello, Adrian. You wrote 6 =F1=E5=ED=F2=FF=E1=F0=FF 2012 =E3., 21:41:39: >> At the top (below the license) of tools/sched/schedgraph.py there is a >> "# To use:" section. It should have everything you need. AC> Thanks, I thought there was also a wiki page somewhere? I have some KTR traces for SCHED with 4BSD and ULE under load on same Geode with same vr(4) adapters, but I don't understand how to read them. Yes, I could look at (very slow, small and bad looking) graphs with Python/Tk script, but I don't understand, what does it all mean. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:02:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E16106567C; Thu, 6 Sep 2012 18:02:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2FBB08FC1C; Thu, 6 Sep 2012 18:02:51 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so3033073pbb.13 for ; Thu, 06 Sep 2012 11:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0sFCF+SwJrcDx9nayFsTPZa6EVO3ipJT/u0wY9Bt4LY=; b=RiWKJIdlAKjgTg1psFZsWPySzW2xpQGBR+P+79K+UbaDGl7cqNxg6BEx2R8LQhq4aD IJsq6Sc5kP+GQ4MyaHDIxcsw7VvWKHnEvi9EYgaS0EF/iri3o55A0/2nNfMqgZbyRxpM 8EpQfd88cpXFZFPo5TPxUQc1nmvMPwrxW70uk8/w3PSC/YdMeC9K2JA3zdjILfZnAzSj Hh2ErZsRweNtywPHJE9S/CfqSeEr2beYtMqudvCTLEfnXi+7k4FYPaJDWzhlreRL6w2t rtOJso7clh6iRP44dAiyiYeLhbtSnhVj01vzYlxzqYc9jQS3iq7s6lLc7LD1hFTaaFSH DGZg== MIME-Version: 1.0 Received: by 10.68.138.169 with SMTP id qr9mr5767919pbb.27.1346954570973; Thu, 06 Sep 2012 11:02:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 11:02:50 -0700 (PDT) In-Reply-To: <10710514011.20120906220055@serebryakov.spb.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> <10710514011.20120906220055@serebryakov.spb.ru> Date: Thu, 6 Sep 2012 11:02:50 -0700 X-Google-Sender-Auth: 5s7W7yoJymqXNfavI5FFkBPkpd4 Message-ID: From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, Florian Smeets , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:02:51 -0000 Hiya, On 6 September 2012 11:00, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 6 =D3=C5=CE=D4=D1=C2=D2=D1 2012 =C7., 21:41:39: > >>> At the top (below the license) of tools/sched/schedgraph.py there is a >>> "# To use:" section. It should have everything you need. > AC> Thanks, I thought there was also a wiki page somewhere? > I have some KTR traces for SCHED with 4BSD and ULE under load on same > Geode with same vr(4) adapters, but I don't understand how to read > them. Yes, I could look at (very slow, small and bad looking) graphs > with Python/Tk script, but I don't understand, what does it all mean. Hi, ARe you able to repeat the same with 4bsd/ule and disabled PREEMPTION? Do you see performance issues go away when you disable preemption? adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:06:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3115106564A; Thu, 6 Sep 2012 18:06:00 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4578FC19; Thu, 6 Sep 2012 18:06:00 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8574:b973:3b96:4bfa]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id A3FEB4AC2D; Thu, 6 Sep 2012 22:05:58 +0400 (MSK) Date: Thu, 6 Sep 2012 22:05:54 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <143885439.20120906220554@serebryakov.spb.ru> To: Adrian Chadd In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> <10710514011.20120906220055@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, Florian Smeets , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:06:01 -0000 Hello, Adrian. You wrote 6 =D3=C5=CE=D4=D1=C2=D2=D1 2012 =C7., 22:02:50: AC> ARe you able to repeat the same with 4bsd/ule and disabled PREEMPTION? Yep, of course. AC> Do you see performance issues go away when you disable preemption? I didn't try it yet. So, I need to test 4 configurations (and, may be 8, with POLLING)! Oh my! :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:07:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A1B1065686; Thu, 6 Sep 2012 18:07:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4538F8FC14; Thu, 6 Sep 2012 18:07:09 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so3038648pbb.13 for ; Thu, 06 Sep 2012 11:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ptbw6vlfWJk9SQBDAKlUdvUDpU6/1DVWObAO2qY9pIE=; b=Ni3febJNBjg9uUwQmXpBHqOJMWZPr2TtRjMbUeJbmGOl/7DfZ71lEv49djDgRqo+oG wHIxJFkia5ZRuYv/f682zM44rfqmau0eZxmhMKnXTbO88w0WznNJ+nwecWZEKTgv/gfU RDZmktqvAUKzsstOLt/xPIHLwVoqnS/WiqIOIQzNpzbHacNUqdregSDDHiybFfl8EJ/2 XbcpxQBffTVX/xYX+xb6bdL5asHTV0Xu+m6gWsaKJauhO18fDoaxmAcTTpHV8wTX9QMQ fXX/2EwTTIbEzOKcRsmdmk807aRUwoeB0dIsCkxsFzzytnXEt9e+ENQuoYeSMME7wewz WELg== MIME-Version: 1.0 Received: by 10.66.74.196 with SMTP id w4mr4403624pav.32.1346954829016; Thu, 06 Sep 2012 11:07:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 11:07:08 -0700 (PDT) In-Reply-To: <143885439.20120906220554@serebryakov.spb.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> <10710514011.20120906220055@serebryakov.spb.ru> <143885439.20120906220554@serebryakov.spb.ru> Date: Thu, 6 Sep 2012 11:07:08 -0700 X-Google-Sender-Auth: Am5y8UY7_t7AaoxGND8YSvCpU6I Message-ID: From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, Florian Smeets , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:07:09 -0000 Oh don't worry about polling just yet. I just want to see what preempt/no-preempt does with ULE and 4BSD on these little single-CPU platforms. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:11:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21D2C106564A; Thu, 6 Sep 2012 18:11:42 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C51918FC12; Thu, 6 Sep 2012 18:11:41 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:8574:b973:3b96:4bfa]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 4C5504AC31; Thu, 6 Sep 2012 22:11:40 +0400 (MSK) Date: Thu, 6 Sep 2012 22:11:36 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1828371828.20120906221136@serebryakov.spb.ru> To: Adrian Chadd In-Reply-To: References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> <10710514011.20120906220055@serebryakov.spb.ru> <143885439.20120906220554@serebryak ov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, Florian Smeets , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:11:42 -0000 Hello, Adrian. You wrote 6 =F1=E5=ED=F2=FF=E1=F0=FF 2012 =E3., 22:07:08: AC> Oh don't worry about polling just yet. I just want to see what AC> preempt/no-preempt does with ULE and 4BSD on these little single-CPU AC> platforms. Ok, I'll do it. Should I post 4 outputs from ktrdump? Again, I don't understand how to interpret these data by myself. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 18:12:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 601431065695; Thu, 6 Sep 2012 18:12:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id DA6D68FC12; Thu, 6 Sep 2012 18:12:04 +0000 (UTC) Received: by dadr6 with SMTP id r6so1299517dad.13 for ; Thu, 06 Sep 2012 11:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=loSKI6gDTY41FLj6iXgVlxaMYcSTaJFqBK9balq6Tuc=; b=LNGf6D4X80SHWvGYMACClNE8LZqlHsbyVqcCBaJVsKwBpM7iTCPVxMl6Mi2+HLVZkJ xSdBvQV0+Zbm/k5gEXtkSUE9Jhi1xY4ml/w5HpX8H8zaMVAVs+v/FNAZ1xYZrnqdDACx 9p1JK/MIrTiBi8wsJstwWH+uMcxh4v+u82YOmohMFZ9Wm1a1fAtwq+2eosfKYKJlQLvL BtKumlaUtiAUBNxRztcXFi6wKlKfC9ktO2DeGkFkez0qfFKQbOi+46pVj0jnjNwwT9My dC5LmUyF0sX7asFlJhY0ZS6DZ/4bTdAppuc8tClS+5KhirR5Dfu4YehPLloNBH5XZdFC GL+g== MIME-Version: 1.0 Received: by 10.66.72.197 with SMTP id f5mr4478984pav.20.1346955124644; Thu, 06 Sep 2012 11:12:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 6 Sep 2012 11:12:04 -0700 (PDT) In-Reply-To: <1828371828.20120906221136@serebryakov.spb.ru> References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> <10710514011.20120906220055@serebryakov.spb.ru> <1828371828.20120906221136@serebryakov.spb.ru> Date: Thu, 6 Sep 2012 11:12:04 -0700 X-Google-Sender-Auth: 4Wyv21EcSQGcyPTDJYLEFzjqyhU Message-ID: From: Adrian Chadd To: lev@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, Florian Smeets , Eugene Grosbein , freebsd-net@freebsd.org, Alexander Motin , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:12:05 -0000 On 6 September 2012 11:11, Lev Serebryakov wrote: > Hello, Adrian. > You wrote 6 =D3=C5=CE=D4=D1=C2=D2=D1 2012 =C7., 22:07:08: > > AC> Oh don't worry about polling just yet. I just want to see what > AC> preempt/no-preempt does with ULE and 4BSD on these little single-CPU > AC> platforms. > Ok, I'll do it. Should I post 4 outputs from ktrdump? Again, I don't > understand how to interpret these data by myself. Yes. Adrian From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 20:30:31 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2D3BE106564A; Thu, 6 Sep 2012 20:30:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8ED8FC08; Thu, 6 Sep 2012 20:30:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA03549; Thu, 06 Sep 2012 23:30:20 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T9iiS-0007Tx-3g; Thu, 06 Sep 2012 23:30:20 +0300 Message-ID: <504907D9.6030309@FreeBSD.org> Date: Thu, 06 Sep 2012 23:30:17 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120901 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org References: <1865271844.20120829131610@serebryakov.spb.ru> <1807373989.20120829223125@serebryakov.spb.ru> <20120830152726.A33776@sola.nimnet.asn.au> <534292400.20120830131158@serebryakov.spb.ru> <20120831180721.GB3208@michelle.cdnetworks.com> <50404F91.8080302@rdtc.ru> <20120903184049.GB3730@michelle.cdnetworks.com> <50443888.9080400@rdtc.ru> <20120903214333.GC3730@michelle.cdnetworks.com> <5044772C.8090302@rdtc.ru> <5046FE57.3050903@rdtc.ru> <5048D7A7.1030708@rdtc.ru> <5048DFF8.50405@smeets.im> <10710514011.20120906220055@serebryakov.spb.ru> In-Reply-To: <10710514011.20120906220055@serebryakov.spb.ru> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: pyunyh@gmail.com, Adrian Chadd , lev@FreeBSD.org, Eugene Grosbein , Alexander Motin , Florian Smeets , Ian Smith Subject: Re: vr(4) troubles for AMD Geode CS5536 chipset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:30:31 -0000 on 06/09/2012 21:00 Lev Serebryakov said the following: > Hello, Adrian. > You wrote 6 2012 ., 21:41:39: > >>> At the top (below the license) of tools/sched/schedgraph.py there is a >>> "# To use:" section. It should have everything you need. > AC> Thanks, I thought there was also a wiki page somewhere? > I have some KTR traces for SCHED with 4BSD and ULE under load on same > Geode with same vr(4) adapters, but I don't understand how to read > them. Yes, I could look at (very slow, small and bad looking) graphs > with Python/Tk script, but I don't understand, what does it all mean. > _Very_ sorry to hijack this thread, but here is a link to another hijack of another thread: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-May/039000.html I think that those who are trying to help people with scheduling issues may want to invest some time in making analysis of those issues easier. I do want to get functionality like that, but permanently short of time... -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 05:22:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8C471065673 for ; Fri, 7 Sep 2012 05:22:30 +0000 (UTC) (envelope-from brianstivala@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 532E98FC17 for ; Fri, 7 Sep 2012 05:22:30 +0000 (UTC) Received: by vbmv11 with SMTP id v11so3412543vbm.13 for ; Thu, 06 Sep 2012 22:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4sl85YmjMqKEU4tS95MnxtfIXliPqKJ4+Sb9umxxve0=; b=cA67YkNWjOf77qnXVmfSXUCLF1mFAVCO8qCVlzM86Z+3f6UkJb1JnllC/lfCBXJ9vH fpZp+gZbRTMpGcvbnexPorltMkq+IVkGg1+xM3qMzWQPdN5CKqq7gSRbYH5Yk6vt3/m0 qX86/ng04o7iOPNmZYDOtZjPocGfKF900xqDd+RCItt/kP0xQdVzhZ5r/7uB2yaUP+bB 2txDo6ngN4kAStTvtTpCuVjR8BqocMDMpve9PcUJDlLSrdpEbxjISZhDDVQ2kZOX5nsO ZaOmyx0xolgJURB2HsRNrnfSfX28Dz+EBpdol8+Xdlodrf7ZMiu+8/7pt33OElGJ+n8c ri7g== MIME-Version: 1.0 Received: by 10.58.35.141 with SMTP id h13mr6351803vej.11.1346995349223; Thu, 06 Sep 2012 22:22:29 -0700 (PDT) Received: by 10.58.70.101 with HTTP; Thu, 6 Sep 2012 22:22:29 -0700 (PDT) In-Reply-To: References: <5046640E.10806@FreeBSD.org> Date: Fri, 7 Sep 2012 07:22:29 +0200 Message-ID: From: Brian Stivala To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: FreeBsd modules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 05:22:30 -0000 Hi, Can I get an answer regarding the below. Thanks Regards, Brian Stivala On Wed, Sep 5, 2012 at 8:53 AM, Brian Stivala wrote= : > Hi Matthew, > > Thanks for your reply, > > This is my Pciconf and the /var/log/dmesg.boot. As you can see the > ethernet card is there but it is not recognisable in PFSense. The only > functional nics are FXP0 and FXP1 the onboard chipset. > > [2.0.1-RELEASE][root@pfSense.localdomain]/root(1): pciconf -l -v > hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x00000000 chip=3D0x71928= 086 > rev=3D0x03 hdr=3D0x00 > class =3D bridge > subclass =3D HOST-PCI > fxp0@pci0:0:5:0: class=3D0x020000 card=3D0x00000000 chip=3D0x12098= 086 > rev=3D0x09 hdr=3D0x00 > class =3D network > subclass =3D ethernet > fxp1@pci0:0:6:0: class=3D0x020000 card=3D0x00000000 chip=3D0x12098= 086 > rev=3D0x09 hdr=3D0x00 > class =3D network > subclass =3D ethernet > isab0@pci0:0:7:0: class=3D0x060100 card=3D0x00000000 chip=3D0x71108= 086 > rev=3D0x02 hdr=3D0x00 > class =3D bridge > subclass =3D PCI-ISA > atapci0@pci0:0:7:1: class=3D0x010180 card=3D0x00000000 chip=3D0x71118= 086 > rev=3D0x01 hdr=3D0x00 > class =3D mass storage > subclass =3D ATA > uhci0@pci0:0:7:2: class=3D0x0c0300 card=3D0x00000000 chip=3D0x71128= 086 > rev=3D0x01 hdr=3D0x00 > class =3D serial bus > subclass =3D USB > piix0@pci0:0:7:3: class=3D0x068000 card=3D0x00000000 chip=3D0x71138= 086 > rev=3D0x02 hdr=3D0x00 > class =3D bridge > none0@pci0:0:8:0: class=3D0x0b4000 card=3D0x00000000 chip=3D0x00061= 3a3 > rev=3D0x01 hdr=3D0x00 > class =3D processor > none1@pci0:0:9:0: class=3D0x020000 card=3D0x00000000 chip=3D0x02011= 617 > rev=3D0x00 hdr=3D0x00 > class =3D network > subclass =3D ethernet > > [2.0.1-RELEASE][root@pfSense.localdomain]/root/var(5): cat > /var/log/dmesg.boot > Copyright (c) 1992-2010 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 8.1-RELEASE-p6 #0: Mon Dec 12 18:59:41 EST 2011 > root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj./usr/pfSenses= rc/src/sys/pfSense_wrap.8.i386 > i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (847.74-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x68a Family =3D 6 Model =3D 8 Ste= pping =3D 10 > > Features=3D0x387f9ff > real memory =3D 268435456 (256 MB) > avail memory =3D 243433472 (232 MB) > netisr_init: forcing maxthreads to 1 and bindthreads to 0 for device > polling > wlan: mac acl policy registered > ipw_bss: You need to read the LICENSE file in > /usr/share/doc/legal/intel_ipw/. > ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack= =3D1 > in /boot/loader.conf. > module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0710010, 0) error 1 > ipw_ibss: You need to read the LICENSE file in > /usr/share/doc/legal/intel_ipw/. > ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack= =3D1 > in /boot/loader.conf. > module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc07100b0, 0) error 1 > wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/= . > wpi: If you agree with the license, set legal.intel_wpi.license_ack=3D1 i= n > /boot/loader.conf. > module_register_init: MOD_LOAD (wpi_fw, 0xc0883050, 0) error 1 > ipw_monitor: You need to read the LICENSE file in > /usr/share/doc/legal/intel_ipw/. > ipw_monitor: If you agree with the license, set > legal.intel_ipw.license_ack=3D1 in /boot/loader.conf. > module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0710150, 0) error 1 > ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309) > ACPI: Table initialisation failed: AE_NOT_FOUND > ACPI: Try disabling either ACPI or apic support. > cryptosoft0: on motherboard > padlock0: No ACE support. > pcib0: pcibus 0 on > motherboard > pci0: on pcib0 > fxp0: port 0xfc00-0xfc3f mem > 0xc0000000-0xc0000fff,0xc0020000-0xc003ffff irq 9 at device 5.0 on pci0 > fxp0: Enabling Rx lock-up workaround > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: [ITHREAD] > fxp1: port 0xf800-0xf83f mem > 0xc0040000-0xc0040fff,0xc0060000-0xc007ffff irq 6 at device 6.0 on pci0 > fxp1: Enabling Rx lock-up workaround > miibus1: on fxp1 > inphy1: PHY 1 on miibus1 > inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp1: [ITHREAD] > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 7.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > uhci0: port 0xf000-0xf01f irq 1= 1 > at device 7.2 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > piix0: port 0x10a0-0x10af at device 7.3 on pci0 > Timecounter "PIIX" frequency 3579545 Hz quality 0 > pci0: at device 8.0 (no driver attached) > pci0: at device 9.0 (no driver attached) > cpu0 on motherboard > atrtc0: at port 0x70 irq 8 on isa0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > uart1: [FILTER] > RTC BIOS diagnostic error 42 > Timecounter "TSC" frequency 847739306 Hz quality 800 > Timecounters tick every 10.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 12Mbps Full Speed USB v1.0 > ad0: 1967MB at ata0-master PIO4 > ugen0.1: at usbus0 > uhub0: on usbus0 > Root mount waiting for: usbus0 > uhub0: 2 ports with 2 removable, self powered > Trying to mount root from ufs:/dev/ufs/pfsense0 > Invalid time in real time clock. > Check and reset the date immediately! > > > Regards, > Brian Stivala > > > On Tue, Sep 4, 2012 at 10:26 PM, Matthew Seaman wrot= e: > >> On 04/09/2012 19:33, Brian Stivala wrote: >> > I have a watchguard firewall v80 which I=92ve decided to amend it to >> PFSense >> > based on freebsd. So far I=92ve installed PFSense and everything is >> working >> > accordingly. This firewall has 2x onboard nic cards and a PCI quad nic= , >> as >> > per attached photo. >> >> Unfortunately the list management software ate your photo, but never >> mind. Your verbal description is sufficient. >> >> > The onboard nics can be recognized however the PCI card is not being >> > recognised, and the strange thing is that both onboard and the PCI use= s >> the >> > same chipset Intel 82559er Ethernet. How can I amend changes in freebs= d >> > modules so that the PCI card can be recognised. >> >> There may be a good reason for your quad card not being recognised, or >> it might just be a bug. >> >> If you run: >> >> % pciconf -lv >> >> You should be able to pick out your unrecognised device. If you ask >> again on freebsd-net@freebsd.org and include relevant sections from >> the pciconf output, you should get to the attention of some of the guys >> that write network drivers. >> >> > Usually in other distros modules can be located in /etc/module however= I >> > cannot find where the modules are located in freebsd. >> >> Verb Sap. Calling FreeBSD a 'distro' is definitely non-U. We generally >> consider penguins a bit fishy round here... >> >> If you want to locate the kernel modules for various hardware, look in >> /boot/kernel. NIC modules will generally have a name beginning 'if_'. >> >> If you want to see what modules have been loaded into the kernel, then >> run: >> >> % kldstat >> >> There's also 'kldload' and 'kldunload' but they aren't going to help you >> for this problem. PCI devices are discovered when the kernel probes the >> bus at boot time: if the kernel hasn't already assigned a driver for the >> device, then there isn't one available. >> >> > Can I have some assistance. >> >> Keeps asking good questions and you'll get useful answers. >> >> Cheers, >> >> Matthew >> >> -- >> Dr Matthew J Seaman MA, D.Phil. >> PGP: http://www.infracaninophile.co.uk/pgpkey >> >> >> > From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 07:46:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63299106564A; Fri, 7 Sep 2012 07:46:24 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.freebsd.org (Postfix) with ESMTP id 41BA38FC08; Fri, 7 Sep 2012 07:46:23 +0000 (UTC) Received: from [IPv6:::1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q877Zr12036858; Fri, 7 Sep 2012 00:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1347003354; bh=YestUcj76p+0sTLDcms5YxDD0dcrl6gRUpxa2eA1NPQ=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=i1yF3dbE+AyZqeYF/IeWfAGBCoYjJcz8J4E2/xc13UcnkeB+eej83owf/c2NBL/5h MXTNLAKyl1eCQVq9Y2jRoZ7tXAGzILs1wpncHJxK5/f5ice0TvcyuVlhJiAWCdoqBI EZZek2a3RuWFw8SGHoenHAPjbZ6P0++AR5Qyf/5k= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Sep 2012 00:35:53 -0700 Message-ID: <1347003353.3109.12.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 003353002 Subject: stable/9 igb(4) panic, udp_append X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:46:24 -0000 Just noted this happened today, running stable/9 ish from august 10th. It looks like I got a good and valid crashdump off of this if anyone is interested. igb0: port 0xe880-0xe89f mem 0xfbe60000-0xfbe7ffff,0xfbe40000-0xfbe5ffff,0xfbeb8000-0xfbebbfff irq 32 at device 0.0 on pci5 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 10:1f:74:2d:08:20 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb1: port 0xec00-0xec1f mem 0xfbee0000-0xfbefffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 42 at device 0.1 on pci5 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 10:1f:74:2d:08:21 igb1: Bound queue 0 to cpu 4 igb1: Bound queue 1 to cpu 5 igb1: Bound queue 2 to cpu 6 igb1: Bound queue 3 to cpu 7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (igb1 que) trap number = 12 panic: page fault cpuid = 12 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 trap_fatal() at trap_fatal+0x290 trap_pfault() at trap_pfault+0x1d6 trap() at trap+0x47a calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff80731312, rsp = 0xffffff846c8977d0, rbp = 0xffffff846c897860 --- udp_append() at udp_append+0x62 udp_input() at udp_input+0x4c8 ip_input() at ip_input+0xbd netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x17d ether_nh_input() at ether_nh_input+0x1fe netisr_dispatch_src() at netisr_dispatch_src+0x152 igb_rxeof() at igb_rxeof+0x3a4 igb_handle_que() at igb_handle_que+0x9b taskqueue_run_locked() at taskqueue_run_locked+0x93 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff846c897cf0, rbp = 0 --- Uptime: 10d1h16m54s Dumping 2527 out of 16353 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/modules/markdev_mod.ko...done. Loaded symbols for /boot/modules/markdev_mod.ko Reading symbols from /boot/modules/ylock_mod.ko...done. Loaded symbols for /boot/modules/ylock_mod.ko #0 doadump (textdump=1) at ../../../kern/kern_shutdown.c:265 265 ../../../kern/kern_shutdown.c: No such file or directory. in ../../../kern/kern_shutdown.c (kgdb) Hangup detected on fd 0 error detected on stdin From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 07:50:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1219106564A; Fri, 7 Sep 2012 07:50:36 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2848FC08; Fri, 7 Sep 2012 07:50:36 +0000 (UTC) Received: from [IPv6:::1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q877e4ZV095108; Fri, 7 Sep 2012 00:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1347003605; bh=xe9sukJgwySC7gYtgdL0tJXq/OfzDnWMuH1is93nxno=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=U5x2zRIEwKNre1gggs9CTgwNHS8CHGY1bHqmggkmsFYpAdzK8OAXGdGSlBTpD1wjd /E5xOnlJ+CwoRXrg3PYqgM+10HcR2VcAAzPgl/EW1n6TZ8Hb1yVnWEx0kFOZJsJ/Pb DK+K1pJuinjgF5873kUY+0cKow3hvRsZ2FeNINaQ= From: Sean Bruno To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Sep 2012 00:40:04 -0700 Message-ID: <1347003604.3109.15.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 003605002 Subject: stable/9 igb(4) panic, soabort X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:50:37 -0000 Since I saw other panics on our stable/9 I started poking around and found this one lying around too. And, I have a crashdump here as well. Not sure about reproduction, but I see it happened on two seperate servers over the course of the day. Here is one of them. igb0: port 0xe880-0xe89f mem 0xfbe60000-0xfbe7ffff,0xfbe40000-0xfbe5ffff,0xfbeb8000-0xfbebbfff irq 32 at device 0.0 on pci5 igb0: Using MSIX interrupts with 5 vectors igb0: Ethernet address: 44:1e:a1:61:0a:76 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb1: port 0xec00-0xec1f mem 0xfbee0000-0xfbefffff,0xfbec0000-0xfbedffff,0xfbebc000-0xfbebffff irq 42 at device 0.1 on pci5 igb1: Using MSIX interrupts with 5 vectors igb1: Ethernet address: 44:1e:a1:61:0a:77 igb1: Bound queue 0 to cpu 4 igb1: Bound queue 1 to cpu 5 igb1: Bound queue 2 to cpu 6 igb1: Bound queue 3 to cpu 7 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: soabort: so_count cpuid = 6 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 soabort() at soabort+0x99 syncache_expand() at syncache_expand+0x30c tcp_input() at tcp_input+0xe5c ip_input() at ip_input+0xbd netisr_dispatch_src() at netisr_dispatch_src+0x152 ether_demux() at ether_demux+0x17d ether_nh_input() at ether_nh_input+0x1fe netisr_dispatch_src() at netisr_dispatch_src+0x152 igb_rxeof() at igb_rxeof+0x3a4 igb_msix_que() at igb_msix_que+0xd5 intr_event_execute_handlers() at intr_event_execute_handlers+0x6a ithread_loop() at ithread_loop+0xb4 fork_exit() at fork_exit+0x135 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff846c888cf0, rbp = 0 --- Uptime: 1h17m18s Dumping 1141 out of 16353 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 08:29:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A0D1065701 for ; Fri, 7 Sep 2012 08:29:32 +0000 (UTC) (envelope-from anshukla@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id A44728FC1C for ; Fri, 7 Sep 2012 08:29:31 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUEmwY1BBZ/e3HKRPKF4faYPiW3mG5tx2@postini.com; Fri, 07 Sep 2012 01:29:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 7 Sep 2012 01:28:20 -0700 From: Anuranjan Shukla To: George Neville-Neil Date: Fri, 7 Sep 2012 01:28:16 -0700 Thread-Topic: Proposal for changes to network device drivers and network stack (RFC) Thread-Index: Ac2M0rzuKGHDCSRhRNuQSErTsm0BkQ== Message-ID: In-Reply-To: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:29:32 -0000 Hi George, Thanks for taking a look. Some answers/comments below. > >> Building FreeBSD without the network stack (network stack as a module) >> ---------------------------------------------------------------------- >> >This would be interesting for many reasons, and I think it would be a good >contribution. Does the work you've done in this area handle the VNET >stuff that is in the stack as well? That is, how well does the network >stack >as a module play with the vnet architecture? I'll follow up on this one separately. > >> struct socket { >>=20 >> int so_fibnum; /* routing domain for this socket */ >> uint32_t so_user_cookie; >> + u_int so_oqueue; /* manage send prioritizing based on >>application >> needs */ >> + u_short so_lrid; /* logical routing */ >> }; >>=20 > >I'd be interested to know how this is used. We use the first one as a 'direction' to the forwarding path to select an appropriate priority queue to send the packet on. In a generic (i.e. Something other than our specific system) system, one could consider interesting ways to use queues on a multi queue NIC with help from a driver. The second one is for a system with logical routing capabilities (multiple routing systems within the same chassis). It gives an application opening a socket an option to select the specific logical routing instance. I'll provide smaller pieces of diffs for the kernel without networking patch I'd sent out. Let me know if you prefer the device driver interface to be in that too. Thanks, Anu From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 10:01:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 684531065672 for ; Fri, 7 Sep 2012 10:01:36 +0000 (UTC) (envelope-from simond@irrelevant.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C46BB8FC0C for ; Fri, 7 Sep 2012 10:01:35 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so2396341lbb.13 for ; Fri, 07 Sep 2012 03:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irrelevant.org; s=irrelevant; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=llWj/5UdPdL4Frvzjyzw57JJdD4Diz0/jl6WjQc2MTM=; b=RU7KDjQ1Ydj2OjKYH2khOmK7fJQx79FzR+6KFNN3wd0RZ9j9YH94yYroKzbP4Mzj9K NC+70K0pMlD04V6lH6SxMnohW9lMaJfs8RRuLT8vPVwhpisPgdI9hqGPq2aPVqXrVCyZ jJZDZjiDYnZbf9BccPsr/5NoA8N5HhSZe6VdU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=llWj/5UdPdL4Frvzjyzw57JJdD4Diz0/jl6WjQc2MTM=; b=U7bPhoxtKv3x3DiF6/2oLsvG8pHtlr4SjTmOrAX/vqLPs5jFCQxBLf/msMTSq60EO6 qzWGaShsqNAUogSg/7CC5yrkKT+g8UoE6v+EWdGm+Bgu90bWPQ9N9dZdEfd5pPfMJTvk 2R7dfP8L2K2UdRi5R44A9cgFxoHJjLl8rXo80ZjgAn1a7yx7Adp00JvD7E1pmYv6Edkq tmbmKexT5f/iw3V/AhMrNYSLx1QqTO0uBuWrPgpNboywJMkOblzqe/oL8mmLk/e4n1Xb P2mC4Szj4B7sjVCIH54v7LWxwDzkvKPyfvgzKoky3qISKiCfGJL6IoPsPQ8qV47Mo8IM 4J6w== MIME-Version: 1.0 Received: by 10.112.23.196 with SMTP id o4mr1982645lbf.49.1347012094292; Fri, 07 Sep 2012 03:01:34 -0700 (PDT) Received: by 10.114.0.235 with HTTP; Fri, 7 Sep 2012 03:01:34 -0700 (PDT) X-Originating-IP: [94.31.26.5] In-Reply-To: <5044F62E.8030001@zirakzigil.org> References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> <503E7A16.6030600@zirakzigil.org> <5044F62E.8030001@zirakzigil.org> Date: Fri, 7 Sep 2012 11:01:34 +0100 Message-ID: From: Simon Dick To: Giulio Ferro Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnuGJ+lSFyjIYvrFaE0TRfPw2CrHjKrgysmLILpZD4dfT9MJ1dl1NeYaz9m/lVfTY1m2w4X Cc: freebsd-net@freebsd.org, "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:01:36 -0000 We've had similar problems with lagg at work, each lagg is made up of one igb and one em port, sometimes for no apparent reason they seem to stop passing through traffic. The easiest way we've found to get it working again is ifconfig down and up on one of the physical interfaces. This is on 8.1 On 3 September 2012 19:25, Giulio Ferro wrote: > No idea anybody why this bug happens? Patches? > > > > On 08/29/2012 10:22 PM, Giulio Ferro wrote: >> >> On 08/28/2012 11:12 AM, Damien Fleuriot wrote: >>> >>> Hi Giulio, >>> >>> >>> >>> Just to clear things up: >>> igb0: 192.168.9.60/24 >>> lagg0: 192.168.12.21/24 >>> >> >> Yes. >> Actually I notice now that the lagg0 address is different from what >> I wrote below in my rc.conf (192.168.12.7). I've just made many test >> with different configuration, but no matter, it just doesn't work... >> >> >>> >>> What's the IP of the host you're trying ssh connections from ? >> >> >> I'm just trying to connect to and from management interface igb0 >> (192.168.9.60). >> From external pc I do : ssh myuser@192.168.9.60 >> From that server I do : ssh myuser@pcaddress >> >> Just to be more precise, the consequences are: >> 1) daemon sshd on the server gets stuck and becomes unkillable >> 2) the first connection may work, but then the program ssh on the >> server becomes unresponsive and unkillable >> >> If I don't create a lagg0 interface and just connect (say) igb1 to >> the data switch, I've no problem and everything works. >> >> Just to answer others' question, I connect igb1, igb2 and igb3 to the >> same data switch in ports configured for aggregation. >> I connect igb0 to another management switch (of course not configured >> for aggregation) >> >> >>> >>> Also, just in case, did you enable any firewall ? (PF, ipfw) >> >> >> As I already said, no. Nothing is working/active on this server, just >> sshd. >> >> Thank you. >> >> >>> >>> >>> >>> On 27 August 2012 21:22, Giulio Ferro wrote: >>>> >>>> Hi, thanks for the answer >>>> >>>> Here is what you asked for: >>>> >>>> # ifconfig igb0 >>>> igb0: flags=8843 metric 0 mtu >>>> 1500 >>>> >>>> >>>> options=4401bb >>>> >>>> ether ... >>>> inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 >>>> inet6 .... prefixlen 64 scopeid 0x1 >>>> nd6 options=29 >>>> media: Ethernet autoselect (1000baseT ) >>>> status: active >>>> >>>> >>>> >>>> # netstat -rn >>>> Routing tables >>>> >>>> Internet: >>>> Destination Gateway Flags Refs Use Netif >>>> Expire >>>> default 192.168.9.1 UGS 0 0 igb0 >>>> 127.0.0.1 link#12 UH 0 0 lo0 >>>> 192.168.9.0/24 link#1 U 0 14 igb0 >>>> 192.168.9.60 link#1 UHS 0 0 lo0 >>>> 192.168.12.0/24 link#13 U 0 109 lagg0 >>>> 192.168.12.21 link#13 UHS 0 0 lo0 >>>> >>>> Internet6: >>>> Destination Gateway Flags >>>> Netif Expire >>>> ::/96 ::1 >>>> UGRS lo0 >>>> ::1 link#12 >>>> UH lo0 >>>> ::ffff:0.0.0.0/96 ::1 >>>> UGRS lo0 >>>> fe80::/10 ::1 >>>> UGRS lo0 >>>> fe80::%igb0/64 link#1 U >>>> igb0 >>>> fe80::ea39:35ff:feb6:a0d4%igb0 link#1 >>>> UHS lo0 >>>> fe80::%igb1/64 link#2 U >>>> igb1 >>>> fe80::ea39:35ff:feb6:a0d5%igb1 link#2 >>>> UHS lo0 >>>> fe80::%igb2/64 link#3 U >>>> igb2 >>>> fe80::ea39:35ff:feb6:a0d6%igb2 link#3 >>>> UHS lo0 >>>> fe80::%igb3/64 link#4 U >>>> igb3 >>>> fe80::ea39:35ff:feb6:a0d7%igb3 link#4 >>>> UHS lo0 >>>> fe80::%lo0/64 link#12 U >>>> lo0 >>>> fe80::1%lo0 link#12 >>>> UHS lo0 >>>> fe80::%lagg0/64 link#13 U >>>> lagg0 >>>> fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 >>>> UHS lo0 >>>> ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 >>>> U igb0 >>>> ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 >>>> U igb1 >>>> ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 >>>> U igb2 >>>> ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 >>>> U igb3 >>>> ff01::%lo0/32 ::1 U >>>> lo0 >>>> ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >>>> lagg0 >>>> ff02::/16 ::1 >>>> UGRS lo0 >>>> ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 >>>> U igb0 >>>> ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 >>>> U igb1 >>>> ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 >>>> U igb2 >>>> ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 >>>> U igb3 >>>> ff02::%lo0/32 ::1 U >>>> lo0 >>>> ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >>>> lagg0 >>>> >>>> >>>> >>>> # netstat -aln | grep 22 >>>> tcp4 0 0 *.22 *.* LISTEN >>>> tcp6 0 0 *.22 *.* LISTEN >>>> >>>> Note that I already tried to only listen on igb0 interface >>>> (192.168.9.60) in >>>> sshd_config, but the results are exactly >>>> the same described below. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 08/25/2012 01:22 PM, Damien Fleuriot wrote: >>>>> >>>>> >>>>> In the meantime kindly post: >>>>> >>>>> >>>>> Ifconfig for your igb0 >>>>> Netstat -rn >>>>> Netstat -aln | grep 22 >>>>> >>>>> >>>>> >>>>> On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: >>>>> >>>>>> I'll get back to you regarding link aggregation when I'm done with >>>>>> groceries. >>>>>> >>>>>> We use it here in production and it works flawlessly. >>>>>> >>>>>> >>>>>> >>>>>> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >>>>>> >>>>>>> No answer, so it seems that link aggregation doesn't really work in >>>>>>> freebsd, >>>>>>> this may help others with the same problem... >>>>>>> >>>>>>> I reverted back to one link for management and one for service, >>>>>>> and ssh >>>>>>> works as it should... >>>>>>> >>>>>>> >>>>>>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>>>>>> >>>>>>>> >>>>>>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 >>>>>>>> nic >>>>>>>> (igb) >>>>>>>> >>>>>>>> 1 nic is connected standalone to the management switch, the 3 other >>>>>>>> nics >>>>>>>> are connected to a switch configured for aggregation. >>>>>>>> >>>>>>>> If I configure the first nic (igb0) there is no problem, I can >>>>>>>> operate >>>>>>>> as I normally do and sshd functions normally. >>>>>>>> >>>>>>>> The problems start when I configure the 3 other nics for >>>>>>>> aggregation: >>>>>>>> >>>>>>>> in /etc/rc.conf >>>>>>>> ... >>>>>>>> ifconfig_igb1="up" >>>>>>>> ifconfig_igb2="up" >>>>>>>> ifconfig_igb3="up" >>>>>>>> >>>>>>>> cloned_interfaces=lagg0 >>>>>>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport >>>>>>>> igb3 192.168.12.7/24" >>>>>>>> ... >>>>>>>> >>>>>>>> I restart the server and the aggregation seems to work correctly, in >>>>>>>> fact ifconfig returns the correct lagg0 interface with the >>>>>>>> aggregated >>>>>>>> links, the correct protocol (lacp) and the correct ip address and >>>>>>>> the >>>>>>>> status is active. I can ping other IPs on the aggregated link. >>>>>>>> >>>>>>>> Also the other (standalone) link seems to work correctly. I can ping >>>>>>>> that address from other machines, and I can ping other IPs from that >>>>>>>> server. >>>>>>>> >>>>>>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>>>>>> servers so there seems to be no problem on the network stack. >>>>>>>> >>>>>>>> But if I try to connect to the sshd service on that server, it hangs >>>>>>>> indefinitely. On the server I find two sshd processes: >>>>>>>> /usr/sbin/sshd >>>>>>>> /usr/sbin/sshd -R >>>>>>>> >>>>>>>> There is no message in the logs. >>>>>>>> >>>>>>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays >>>>>>>> there >>>>>>>> forever waiting for the pid to die (it never does) >>>>>>>> >>>>>>>> Even ssh client doesn't seem to work. In fact, if I try to >>>>>>>> connect to >>>>>>>> another server, the ssh client may start to work correctly, then >>>>>>>> soon >>>>>>>> or later it just hangs there forever, and I can't kill it with >>>>>>>> ctrl-c. >>>>>>>> >>>>>>>> No firewall is configured, there is nothing else working on this >>>>>>>> server. >>>>>>>> >>>>>>>> Thanks for any suggestions... >>>>>>>> _______________________________________________ >>>>>>>> freebsd-stable@freebsd.org mailing list >>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>>>> To unsubscribe, send any mail to >>>>>>>> "freebsd-stable-unsubscribe@freebsd.org" >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> freebsd-stable@freebsd.org mailing list >>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>>> To unsubscribe, send any mail to >>>>>>> "freebsd-stable-unsubscribe@freebsd.org" >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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" >> >> >> _______________________________________________ >> 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" > > > _______________________________________________ > 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 Sep 7 10:57:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54B98106564A for ; Fri, 7 Sep 2012 10:57:56 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 99CF58FC0C for ; Fri, 7 Sep 2012 10:57:55 +0000 (UTC) Received: from vhoffman-macbooklocal.local (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q87AvqS4001694 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 11:57:53 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <5049D330.6060208@unsane.co.uk> Date: Fri, 07 Sep 2012 11:57:52 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Brian Stivala References: <5046640E.10806@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBsd modules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:57:56 -0000 On 07/09/2012 06:22, Brian Stivala wrote: > Hi, > > Can I get an answer regarding the below. > > Thanks > > Regards, > Brian Stivala I assume http://forum.pfsense.org/index.php?PHPSESSID=d9f0e7e874a14184be2074988f0f4a8a&topic=53277 is you also. >From the look of it and reading that thread I would say that the quad Gig card is not being exposed as standard intel adapters to the OS, but in a modified way though the rapidstream daughterboard. Note that the 2 fxp cards have chip=0x12098086 (device ID 0x1238 Vendor ID 0x8086) Indicating they are Intel chips, while the other card appears as chip=0x02011617 (Devince 0x0201 Vendor 0x1617) Indicating its a Rapidstream device. As far as I know this is not supported by FreeBSD but would be happy to be proved wrong if someone else knows differently. Vince > > On Wed, Sep 5, 2012 at 8:53 AM, Brian Stivala wrote: > >> Hi Matthew, >> >> Thanks for your reply, >> >> This is my Pciconf and the /var/log/dmesg.boot. As you can see the >> ethernet card is there but it is not recognisable in PFSense. The only >> functional nics are FXP0 and FXP1 the onboard chipset. >> >> [2.0.1-RELEASE][root@pfSense.localdomain]/root(1): pciconf -l -v >> hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x71928086 >> rev=0x03 hdr=0x00 >> class = bridge >> subclass = HOST-PCI >> fxp0@pci0:0:5:0: class=0x020000 card=0x00000000 chip=0x12098086 >> rev=0x09 hdr=0x00 >> class = network >> subclass = ethernet >> fxp1@pci0:0:6:0: class=0x020000 card=0x00000000 chip=0x12098086 >> rev=0x09 hdr=0x00 >> class = network >> subclass = ethernet >> isab0@pci0:0:7:0: class=0x060100 card=0x00000000 chip=0x71108086 >> rev=0x02 hdr=0x00 >> class = bridge >> subclass = PCI-ISA >> atapci0@pci0:0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 >> rev=0x01 hdr=0x00 >> class = mass storage >> subclass = ATA >> uhci0@pci0:0:7:2: class=0x0c0300 card=0x00000000 chip=0x71128086 >> rev=0x01 hdr=0x00 >> class = serial bus >> subclass = USB >> piix0@pci0:0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 >> rev=0x02 hdr=0x00 >> class = bridge >> none0@pci0:0:8:0: class=0x0b4000 card=0x00000000 chip=0x000613a3 >> rev=0x01 hdr=0x00 >> class = processor >> none1@pci0:0:9:0: class=0x020000 card=0x00000000 chip=0x02011617 >> rev=0x00 hdr=0x00 >> class = network >> subclass = ethernet >> >> [2.0.1-RELEASE][root@pfSense.localdomain]/root/var(5): cat >> /var/log/dmesg.boot >> Copyright (c) 1992-2010 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 8.1-RELEASE-p6 #0: Mon Dec 12 18:59:41 EST 2011 >> root@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 >> i386 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel Pentium III (847.74-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0x68a Family = 6 Model = 8 Stepping = 10 >> >> Features=0x387f9ff >> real memory = 268435456 (256 MB) >> avail memory = 243433472 (232 MB) >> netisr_init: forcing maxthreads to 1 and bindthreads to 0 for device >> polling >> wlan: mac acl policy registered >> ipw_bss: You need to read the LICENSE file in >> /usr/share/doc/legal/intel_ipw/. >> ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 >> in /boot/loader.conf. >> module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0710010, 0) error 1 >> ipw_ibss: You need to read the LICENSE file in >> /usr/share/doc/legal/intel_ipw/. >> ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 >> in /boot/loader.conf. >> module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc07100b0, 0) error 1 >> wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. >> wpi: If you agree with the license, set legal.intel_wpi.license_ack=1 in >> /boot/loader.conf. >> module_register_init: MOD_LOAD (wpi_fw, 0xc0883050, 0) error 1 >> ipw_monitor: You need to read the LICENSE file in >> /usr/share/doc/legal/intel_ipw/. >> ipw_monitor: If you agree with the license, set >> legal.intel_ipw.license_ack=1 in /boot/loader.conf. >> module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0710150, 0) error 1 >> ACPI Error: A valid RSDP was not found (20100331/tbxfroot-309) >> ACPI: Table initialisation failed: AE_NOT_FOUND >> ACPI: Try disabling either ACPI or apic support. >> cryptosoft0: on motherboard >> padlock0: No ACE support. >> pcib0: pcibus 0 on >> motherboard >> pci0: on pcib0 >> fxp0: port 0xfc00-0xfc3f mem >> 0xc0000000-0xc0000fff,0xc0020000-0xc003ffff irq 9 at device 5.0 on pci0 >> fxp0: Enabling Rx lock-up workaround >> miibus0: on fxp0 >> inphy0: PHY 1 on miibus0 >> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp0: [ITHREAD] >> fxp1: port 0xf800-0xf83f mem >> 0xc0040000-0xc0040fff,0xc0060000-0xc007ffff irq 6 at device 6.0 on pci0 >> fxp1: Enabling Rx lock-up workaround >> miibus1: on fxp1 >> inphy1: PHY 1 on miibus1 >> inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp1: [ITHREAD] >> isab0: at device 7.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 7.1 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> uhci0: port 0xf000-0xf01f irq 11 >> at device 7.2 on pci0 >> uhci0: [ITHREAD] >> usbus0: on uhci0 >> piix0: port 0x10a0-0x10af at device 7.3 on pci0 >> Timecounter "PIIX" frequency 3579545 Hz quality 0 >> pci0: at device 8.0 (no driver attached) >> pci0: at device 9.0 (no driver attached) >> cpu0 on motherboard >> atrtc0: at port 0x70 irq 8 on isa0 >> uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> uart0: [FILTER] >> uart0: console (9600,n,8,1) >> uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 >> uart1: [FILTER] >> RTC BIOS diagnostic error 42 >> Timecounter "TSC" frequency 847739306 Hz quality 800 >> Timecounters tick every 10.000 msec >> IPsec: Initialized Security Association Processing. >> usbus0: 12Mbps Full Speed USB v1.0 >> ad0: 1967MB at ata0-master PIO4 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> Root mount waiting for: usbus0 >> uhub0: 2 ports with 2 removable, self powered >> Trying to mount root from ufs:/dev/ufs/pfsense0 >> Invalid time in real time clock. >> Check and reset the date immediately! >> >> >> Regards, >> Brian Stivala >> >> >> On Tue, Sep 4, 2012 at 10:26 PM, Matthew Seaman wrote: >> >>> On 04/09/2012 19:33, Brian Stivala wrote: >>>> I have a watchguard firewall v80 which Ive decided to amend it to >>> PFSense >>>> based on freebsd. So far Ive installed PFSense and everything is >>> working >>>> accordingly. This firewall has 2x onboard nic cards and a PCI quad nic, >>> as >>>> per attached photo. >>> Unfortunately the list management software ate your photo, but never >>> mind. Your verbal description is sufficient. >>> >>>> The onboard nics can be recognized however the PCI card is not being >>>> recognised, and the strange thing is that both onboard and the PCI uses >>> the >>>> same chipset Intel 82559er Ethernet. How can I amend changes in freebsd >>>> modules so that the PCI card can be recognised. >>> There may be a good reason for your quad card not being recognised, or >>> it might just be a bug. >>> >>> If you run: >>> >>> % pciconf -lv >>> >>> You should be able to pick out your unrecognised device. If you ask >>> again on freebsd-net@freebsd.org and include relevant sections from >>> the pciconf output, you should get to the attention of some of the guys >>> that write network drivers. >>> >>>> Usually in other distros modules can be located in /etc/module however I >>>> cannot find where the modules are located in freebsd. >>> Verb Sap. Calling FreeBSD a 'distro' is definitely non-U. We generally >>> consider penguins a bit fishy round here... >>> >>> If you want to locate the kernel modules for various hardware, look in >>> /boot/kernel. NIC modules will generally have a name beginning 'if_'. >>> >>> If you want to see what modules have been loaded into the kernel, then >>> run: >>> >>> % kldstat >>> >>> There's also 'kldload' and 'kldunload' but they aren't going to help you >>> for this problem. PCI devices are discovered when the kernel probes the >>> bus at boot time: if the kernel hasn't already assigned a driver for the >>> device, then there isn't one available. >>> >>>> Can I have some assistance. >>> Keeps asking good questions and you'll get useful answers. >>> >>> Cheers, >>> >>> Matthew >>> >>> -- >>> Dr Matthew J Seaman MA, D.Phil. >>> PGP: http://www.infracaninophile.co.uk/pgpkey >>> >>> >>> > _______________________________________________ > 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 Sep 7 13:24:50 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0AC106566C; Fri, 7 Sep 2012 13:24:50 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id BA1198FC12; Fri, 7 Sep 2012 13:24:49 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q87DOm8S048041; Fri, 7 Sep 2012 17:24:48 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q87DOm8V048040; Fri, 7 Sep 2012 17:24:48 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 7 Sep 2012 17:24:48 +0400 From: Gleb Smirnoff To: sbruno@FreeBSD.org Message-ID: <20120907132448.GI44854@FreeBSD.org> References: <1347003353.3109.12.camel@powernoodle> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1347003353.3109.12.camel@powernoodle> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" Subject: Re: stable/9 igb(4) panic, udp_append X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:24:50 -0000 On Fri, Sep 07, 2012 at 12:35:53AM -0700, Sean Bruno wrote: S> Just noted this happened today, running stable/9 ish from august 10th. S> It looks like I got a good and valid crashdump off of this if anyone is S> interested. ... S> --- trap 0xc, rip = 0xffffffff80731312, rsp = 0xffffff846c8977d0, rbp = S> 0xffffff846c897860 --- S> udp_append() at udp_append+0x62 S> udp_input() at udp_input+0x4c8 S> ip_input() at ip_input+0xbd I guess I know this one. The problem is a race in in_pcblookup_*() when two threads want to acquire a pcb read-locked and third thread detaches it. I have reported this to Robert and now waiting for reply. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 15:48:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 713A6106564A for ; Fri, 7 Sep 2012 15:48:52 +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 40EDB8FC08 for ; Fri, 7 Sep 2012 15:48:52 +0000 (UTC) Received: from JRE-MBP-2.local (ppp121-45-230-94.lns20.per1.internode.on.net [121.45.230.94]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q87Fmgp1086631 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 7 Sep 2012 08:48:44 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <504A1755.6090902@freebsd.org> Date: Fri, 07 Sep 2012 23:48:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Anuranjan Shukla References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:48:52 -0000 On 9/7/12 4:28 PM, Anuranjan Shukla wrote: > Hi George, > Thanks for taking a look. Some answers/comments below. > >>> Building FreeBSD without the network stack (network stack as a module) >>> ---------------------------------------------------------------------- >>> >> This would be interesting for many reasons, and I think it would be a good >> contribution. Does the work you've done in this area handle the VNET >> stuff that is in the stack as well? That is, how well does the network >> stack >> as a module play with the vnet architecture? > I'll follow up on this one separately. > >>> struct socket { >>> >>> int so_fibnum; /* routing domain for this socket */ >>> uint32_t so_user_cookie; >>> + u_int so_oqueue; /* manage send prioritizing based on >>> application >>> needs */ >>> + u_short so_lrid; /* logical routing */ >>> }; >>> >> I'd be interested to know how this is used. > We use the first one as a 'direction' to the forwarding path to select an > appropriate priority queue to send the packet on. In a generic (i.e. > Something other than our specific system) system, one could consider > interesting ways to use queues on a multi queue NIC with help from a > driver. The second one is for a system with logical routing capabilities > (multiple routing systems within the same chassis). It gives an > application opening a socket an option to select the specific logical > routing instance. We have the second one with the SETFIB socket option, which allows a socket to select the routing instance (fib) to use. it's in the diff, 3 lines up. > I'll provide smaller pieces of diffs for the kernel without networking > patch I'd sent out. Let me know if you prefer the device driver interface > to be in that too. > > Thanks, > Anu > > _______________________________________________ > 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 Sep 7 17:43:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1C2106564A for ; Fri, 7 Sep 2012 17:43:32 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id BD09E8FC0A for ; Fri, 7 Sep 2012 17:43:32 +0000 (UTC) Received: from [209.249.190.124] (port=36220 helo=punk.neville-neil.com.neville-neil.com) by vps.hungerhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1TA2aZ-0007Mg-Kf; Fri, 07 Sep 2012 13:43:31 -0400 Date: Fri, 07 Sep 2012 13:45:43 -0400 Message-ID: <86har9iv5k.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: Anuranjan Shukla In-Reply-To: References: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.4 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 17:43:33 -0000 At Fri, 7 Sep 2012 01:28:16 -0700, Anuranjan Shukla wrote: > > > > > >> struct socket { > >> > >> int so_fibnum; /* routing domain for this socket */ > >> uint32_t so_user_cookie; > >> + u_int so_oqueue; /* manage send prioritizing based on > >>application > >> needs */ > >> + u_short so_lrid; /* logical routing */ > >> }; > >> > > > >I'd be interested to know how this is used. > > We use the first one as a 'direction' to the forwarding path to select an > appropriate priority queue to send the packet on. In a generic (i.e. > Something other than our specific system) system, one could consider > interesting ways to use queues on a multi queue NIC with help from a > driver. The second one is for a system with logical routing capabilities > (multiple routing systems within the same chassis). It gives an > application opening a socket an option to select the specific logical > routing instance. OK, that's what I guessed but thanks for confirming it. > I'll provide smaller pieces of diffs for the kernel without networking > patch I'd sent out. Let me know if you prefer the device driver interface > to be in that too. Yes, please. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 20:46:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B9401065670; Fri, 7 Sep 2012 20:46:17 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id D3B7F8FC12; Fri, 7 Sep 2012 20:46:16 +0000 (UTC) Received: from [IPv6:::1] (proxy6.corp.yahoo.com [216.145.48.19]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q87KjxI7086488; Fri, 7 Sep 2012 13:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1347050760; bh=a/1TXnTeUmZHpskiXuBCqPW1V1r45U1s6L9jVoVlxqk=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=dPeWZkUtSmCNgCuXB1mCsPcmU13EDCKHZCh0X1pbqA+g+HHuZoEGB4e5aKG//5puW VEnj75tSZhsXRF+KGHWpX8eqjURbqqYSULzeIhugjyU1GDPl3kdtrzFMdz9Ax2t0PB gV9djpa7cFNY3dtfjiCkeQsuc5oZqHC2EDazycJM= From: Sean Bruno To: John In-Reply-To: <20120816165651.GA39870@FreeBSD.org> References: <20120816165651.GA39870@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Sep 2012 13:45:59 -0700 Message-ID: <1347050759.3479.8.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 050759003 Cc: "freebsd-net@freebsd.org" Subject: Re: Dell PowerEdge R820 Broadcom BCM57800 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 20:46:17 -0000 On Thu, 2012-08-16 at 09:56 -0700, John wrote: > Hi Folks, > > I have an R820 I'm testing. The system seems to boot up fine, but > no network adapters show up. From pciconf -l : > > none4@pci0:1:0:0: class=0x020000 card=0x1f5c1028 chip=0x168a14e4 rev=0x10 hdr=0x00 > none5@pci0:1:0:1: class=0x020000 card=0x1f5c1028 chip=0x168a14e4 rev=0x10 hdr=0x00 > none6@pci0:1:0:2: class=0x020000 card=0x1f671028 chip=0x168a14e4 rev=0x10 hdr=0x00 > none7@pci0:1:0:3: class=0x020000 card=0x1f671028 chip=0x168a14e4 rev=0x10 hdr=0x00 > > which appears to be these: > > Broadcom BCM57800 NetXtreme II 10 GigE 1f5c > Broadcom BCM57800 NetXtreme II 1 GigE 1f67 > > Does anyone have any experience with these? > > Thanks, > John John: Hey, I'm currently testing a patchset that enables the use of the 1Gig adapter via bge(4). I'm not sure about the 10Gig adapter though, is that bxe(4) At this time, there no functional version of bge(4) that works on a stable release. You'd have the best luck in compiling your own kernel from stable/9 and applying the following updates from > > http://people.freebsd.org/~yongari/bge/if_bge.c > > http://people.freebsd.org/~yongari/bge/if_bgereg.h > > http://people.freebsd.org/~yongari/bge/brgphy.c You'll need to overwrie brgphy.c in sys/dev/mii and move if_bge.c if_bgereg.h to sys/dev/bge and recompile your kernel. Sean From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 21:51:51 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6401065678; Fri, 7 Sep 2012 21:51:51 +0000 (UTC) (envelope-from jlott@averesystems.com) Received: from mail.averesystems.com (mail.averesystems.com [208.70.68.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5D38FC1C; Fri, 7 Sep 2012 21:51:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id 6919748089F; Fri, 7 Sep 2012 17:44:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX-t-RmBeYJP; Fri, 7 Sep 2012 17:44:50 -0400 (EDT) Received: from jlott-mac.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id 5E096480880; Fri, 7 Sep 2012 17:44:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jeremiah Lott In-Reply-To: <201204270607.q3R67TiO026862@freefall.freebsd.org> Date: Fri, 7 Sep 2012 17:44:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8339513D-6727-4343-A86E-4F5BB1F9827D@averesystems.com> References: <201204270607.q3R67TiO026862@freefall.freebsd.org> To: freebsd-net@FreeBSD.org X-Mailer: Apple Mail (2.1084) Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/167325: [netinet] [patch] sosend sometimes return EINVAL with TSO and VLAN on 82599 NIC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:51:51 -0000 On Apr 27, 2012, at 2:07 AM, linimon@FreeBSD.org wrote: > Old Synopsis: sosend sometimes return EINVAL with TSO and VLAN on = 82599 NIC > New Synopsis: [netinet] [patch] sosend sometimes return EINVAL with = TSO and VLAN on 82599 NIC > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D167325 I did an analysis of this pr a while back and I figured I'd share. = Definitely looks like a real problem here, but at least in 8.2 it is = difficult to hit it. First off, vlan tagging is not required to hit = this. The code is question does not account for any amount of = link-local header, so you can reproduce the bug even without vlans. In order to trigger it, the tcp stack must choose to send a tso "packet" = with a total size (including tcp+ip header and options, but not = link-local header) between 65522 and 65535 bytes (because adding 14 byte = link-local header will then exceed 64K limit). In 8.1, the tcp stack = only chooses to send tso bursts that will result in full mtu-size = on-wire packets. To achieve this, it will truncate the tso packet size = to be a multiple of mss, not including header and tcp options. The = check has been relaxed a little in head, but the same basic check is = still there. None of the "normal" mtus have multiples falling in this = range. To reproduce it I used an mtu of 1445. When timestamps are in = use, every packet has a 40 bytes tcp/ip header + 10 bytes for the = timestamp option + 2 bytes pad. You can get a packet length 65523 as = follows: 65523 - (40 + 10 + 2) =3D 65471 (size of tso packet data) 65471 / 47 =3D 1393 (size of data per on-wire packet) 1393 + (40 + 10 + 2) =3D 1445 (mtu is data + header + options + pad) Once you set your mtu to 1445, you need a program that can get the stack = to send a maximum sized packet. With the congestion window that can be = more difficult than it seems. I used some python that sends enough data = to open the window, sleeps long enough to drain all outstanding data, = but not long enough for the congestion window to go stale and close = again, then sends a bunch more data. It also helps to turn off delayed = acks on the receiver. Sometimes you will not drain the entire send = buffer because an ack for the final chunk is still delayed when you = start the second transmit. When the problem described in the pr hits, = the EINVAL from bus_dmamap_load_mbuf_sg bubbles right up to userspace. At first I thought this was a driver bug rather than stack bug. The = code in question does what it is commented to do (limit the tso packet = so that ip->ip_len does not overflow). However, it also seems = reasonable that the driver limit its dma tag at 64K (do we really want = it allocating another whole page just for the 14 byte link-local = header). Perhaps the tcp stack should ensure that the tso packet + = max_linkhdr is < 64K. Comments? As an aside, the patch attached to the pr is also slightly wrong. = Taking the max_linkhdr into account when rounding the packet to be a = multiple of mss does not make sense, it should only take it into account = when calculating the max tso length. Jeremiah Lott Avere Systems