From owner-freebsd-net@FreeBSD.ORG  Sun Sep  2 16:57:01 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <pi@opsec.eu>)
	id 1T8DTo-0005gW-A5; Sun, 02 Sep 2012 18:57:00 +0200
Date: Sun, 2 Sep 2012 18:57:00 +0200
From: Kurt Jaeger <pi@opsec.eu>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <pi@opsec.eu>)
	id 1T8Dim-0005v1-SX; Sun, 02 Sep 2012 19:12:28 +0200
Date: Sun, 2 Sep 2012 19:12:28 +0200
From: Kurt Jaeger <pi@opsec.eu>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <peter@rulingia.com>
To: Lev Serebryakov <lev@freebsd.org>
Message-ID: <20120902204329.GA2654@aspire.rulingia.com>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<1807373989.20120829223125@serebryakov.spb.ru>
	<20120830152726.A33776@sola.nimnet.asn.au>
	<534292400.20120830131158@serebryakov.spb.ru>
	<CAJ-Vmomcq188wU0mHen-=hJHNQvxzMR+fAGLVbvnM5zWLZ+EDg@mail.gmail.com>
	<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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <lev@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <peter@rulingia.com>
To: Adrian Chadd <adrian@freebsd.org>
Message-ID: <20120902212952.GB2654@aspire.rulingia.com>
References: <20120830215147.GA2383@-> <20120831104532.GA1758@->
	<CAJ-VmoneEMvCpNotru+ws9NdcyExnkGfxnx2W=z7e-Myb1RWRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1"
Content-Disposition: inline
In-Reply-To: <CAJ-VmoneEMvCpNotru+ws9NdcyExnkGfxnx2W=z7e-Myb1RWRQ@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <adrian@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <list_freebsd@bluerosetech.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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@->
	<CAJ-VmoneEMvCpNotru+ws9NdcyExnkGfxnx2W=z7e-Myb1RWRQ@mail.gmail.com>
	<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 <sergv326@gmail.com>
Date: Mon, 03 Sep 2012 02:25:57 +0400
To: Peter Jeremy <peter@rulingia.com>,Adrian Chadd <adrian@freebsd.org>
Message-ID: <a464a34a-5a4d-4b8d-8864-d16c89106bfd@email.android.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Sep 2012 22:26:05 -0000

Peter Jeremy <peter@rulingia.com> написал(а):

>Adrian,
>
>On 2012-Aug-31 04:29:53 -0700, Adrian Chadd <adrian@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <emailbulletin@mail.mycustomer.com>
To: <freebsd-net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 &copy; 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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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 <pyunyh@gmail.com>
Date: Mon, 3 Sep 2012 11:40:49 -0700
To: Eugene Grosbein <egrosbein@rdtc.ru>
Message-ID: <20120903184049.GB3730@michelle.cdnetworks.com>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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 <lev@freebsd.org>,
	Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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<FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CLFLUSH,MMX>
>   AMD Features=0xc0400000<MMX+,3DNow!+,3DNow!>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <egrosbein@rdtc.ru>
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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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 <lev@freebsd.org>,
	Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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 <pyunyh@gmail.com>
Date: Mon, 3 Sep 2012 14:43:33 -0700
To: Eugene Grosbein <egrosbein@rdtc.ru>
Message-ID: <20120903214333.GC3730@michelle.cdnetworks.com>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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 <lev@freebsd.org>,
	Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <ray@dlink.ua>
To: Gleb Smirnoff <glebius@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Sep 2012 08:27:42 -0000

On Thu, 30 Aug 2012 17:10:57 +0400
Gleb Smirnoff <glebius@FreeBSD.org> 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 <ray@dlink.ua> 
aka Alex RAY <ray@ddteam.net>

From owner-freebsd-net@FreeBSD.ORG  Mon Sep  3 09:24:01 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <egrosbein@rdtc.ru>
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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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 <lev@freebsd.org>,
	Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <bugmaster@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <ipv6_addr> -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 <host> -iface <nic> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <glebius@FreeBSD.org>
To: Kurt Jaeger <pi@opsec.eu>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <auryn@zirakzigil.org>
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" <freebsd-stable@freebsd.org>
References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org>
	<FF06542A-9507-4C8C-99EC-8275B04D4CF1@my.gd>
	<E183609A-19E1-4EF4-B08D-FAA55779E193@my.gd>
	<503BC8F5.3040208@zirakzigil.org>
	<CAE63ME6oi_5Yam5wXuJzYBhhv+N6MnQPOXReXo2Ugo1hjvv25Q@mail.gmail.com>
	<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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <auryn@zirakzigil.org> wrote:
>>> Hi, thanks for the answer
>>>
>>> Here is what you asked for:
>>>
>>> # ifconfig igb0
>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>>> 1500
>>>
>>> options=4401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
>>>
>>> ether ...
>>> inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255
>>>          inet6 .... prefixlen 64 scopeid 0x1
>>>          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>>          media: Ethernet autoselect (1000baseT <full-duplex>)
>>>          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 <ml@my.gd> 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 <auryn@zirakzigil.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <krassi@bulinfo.net>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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
<ithread_loop>, 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: <HP NC382i DP Multifunction Gigabit
> Server Adapter (C0)> mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci2
> Sep  3 14:19:54 m kernel: miibus0: <MII bus> on bce0
> Sep  3 14:19:54 m kernel: brgphy0: <BCM5709C 10/100/1000baseTX PHY> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <silby@silby.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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 <pyunyh@gmail.com>
Date: Wed, 5 Sep 2012 13:56:54 -0700
To: Mike Silbersack <silby@silby.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <silby@silby.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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 <pyunyh@gmail.com>
Date: Wed, 5 Sep 2012 15:05:41 -0700
To: Mike Silbersack <silby@silby.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAL8FXqxh7M0CXrsRy-kKkCFTgf70wWjp1Mq3UXtVmg3aFmDfZA@mail.gmail.com>
	<5046640E.10806@FreeBSD.org>
Date: Wed, 5 Sep 2012 08:53:46 +0200
Message-ID: <CAL8FXqyqJk2RE4M4K8wmyae7LC2ztpxFqepXjT7MjL3znfRczQ@mail.gmail.com>
From: Brian Stivala <brianstivala@gmail.com>
To: Matthew Seaman <matthew@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CM=
OV,PAT,PSE36,PN,MMX,FXSR,SSE>
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: <software crypto> on motherboard
padlock0: No ACE support.
pcib0: <Intel 82443BX host to PCI bridge (AGP disabled)> pcibus 0 on
motherboard
pci0: <PCI bus> on pcib0
fxp0: <Intel 82559ER Embedded 10/100 Ethernet> port 0xfc00-0xfc3f mem
0xc0000000-0xc0000fff,0xc0020000-0xc003ffff irq 9 at device 5.0 on pci0
fxp0: Enabling Rx lock-up workaround
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: [ITHREAD]
fxp1: <Intel 82559ER Embedded 10/100 Ethernet> port 0xf800-0xf83f mem
0xc0040000-0xc0040fff,0xc0060000-0xc007ffff irq 6 at device 6.0 on pci0
fxp1: Enabling Rx lock-up workaround
miibus1: <MII bus> on fxp1
inphy1: <i82555 10/100 media interface> PHY 1 on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1: [ITHREAD]
isab0: <PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 UDMA33 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 7.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xf000-0xf01f irq 11
at device 7.2 on pci0
uhci0: [ITHREAD]
usbus0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
piix0: <PIIX Timecounter> port 0x10a0-0x10af at device 7.3 on pci0
Timecounter "PIIX" frequency 3579545 Hz quality 0
pci0: <processor> at device 8.0 (no driver attached)
pci0: <network, ethernet> at device 9.0 (no driver attached)
cpu0 on motherboard
atrtc0: <AT Real Time Clock> 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<ROM_cksum>
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 <CF Card Ver1.27> at ata0-master PIO4
ugen0.1: <Intel> at usbus0
uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> 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 <matthew@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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: <CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Eugene Grosbein <egrosbein@rdtc.ru>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <egrosbein@rdtc.ru> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmomzY1TFjwPdZWGStb9wBZ1RZrk3QZnJMGkxvftWGKPCHQ@mail.gmail.com>
	<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: <CAJ-VmokR3YvKUQxCVef_tqYoXtw01T9gO=eLxa4Lq27=owDiCA@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Eugene Grosbein <egrosbein@rdtc.ru>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <egrosbein@rdtc.ru> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <egrosbein@rdtc.ru>
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 <adrian@freebsd.org>
References: <1865271844.20120829131610@serebryakov.spb.ru>	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>	<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>	<CAJ-VmomzY1TFjwPdZWGStb9wBZ1RZrk3QZnJMGkxvftWGKPCHQ@mail.gmail.com>	<5040DE1D.7040700@rdtc.ru>	<5040E749.9070200@rdtc.ru>
	<CAJ-VmokR3YvKUQxCVef_tqYoXtw01T9gO=eLxa4Lq27=owDiCA@mail.gmail.com>
In-Reply-To: <CAJ-VmokR3YvKUQxCVef_tqYoXtw01T9gO=eLxa4Lq27=owDiCA@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <egrosbein@rdtc.ru>
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 <adrian@freebsd.org>
References: <1865271844.20120829131610@serebryakov.spb.ru>	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
In-Reply-To: <CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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" <melifaro@FreeBSD.org>
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 <glebius@FreeBSD.org>,
	Luigi Rizzo <rizzo@iet.unipi.it>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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" <melifaro@ipfw.ru>
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" <melifaro@ipfw.ru>
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 <net/route.h>
 #include <net/pf_mtag.h>
 #include <net/vnet.h>
+#include <net/pfil.h>
 
 #include <netinet/in.h>
 #include <netinet/in_var.h>
@@ -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 <netinet/libalias/alias_local.h>
 
 #include <net/if.h>
+#include <net/pfil.h>
 #include <netinet/in.h>
 #include <netinet/ip.h>
 #include <netinet/ip_var.h>
@@ -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 <net/if.h>
 #include <net/route.h>
 #include <net/vnet.h>
+#include <net/pfil.h>
 
 #include <netinet/in.h>
 #include <netinet/ip_var.h> /* 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 <sys/socket.h>
 #include <net/if.h>	/* ip_fw.h requires IFNAMSIZ */
 #include <net/radix.h>
+#include <net/pfil.h>
 #include <net/route.h>
 #include <net/vnet.h>
 
-- 
1.7.9.4


--------------000105030205080004040409--

From owner-freebsd-net@FreeBSD.ORG  Wed Sep  5 11:51:52 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <glebius@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>;
	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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <longwitz@incore.de>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 Lübeck, HRB 318 BS
Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau


From owner-freebsd-net@FreeBSD.ORG  Wed Sep  5 13:45:09 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <vanhu@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <longwitz@incore.de>
User-Agent: Thunderbird 2.0.0.19 (X11/20090113)
MIME-Version: 1.0
To: VANHULLEBUS Yvan <vanhu@FreeBSD.org>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAPBZQG0KHs_ckvn0TPr38Z_vPokziZH=1xx1NG53Ld8rkV_JJg@mail.gmail.com>
From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>
To: Gleb Smirnoff <glebius@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <glebius@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <gnn@neville-neil.com>)
	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 <gnn@neville-neil.com>
In-Reply-To: <CC5C760E.18207%anshukla@juniper.net>
Date: Wed, 5 Sep 2012 16:15:39 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com>
References: <CC5C760E.18207%anshukla@juniper.net>
To: Anuranjan Shukla <anshukla@juniper.net>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Sep 2012 20:15:43 -0000


On Aug 25, 2012, at 00:11 , Anuranjan Shukla <anshukla@juniper.net> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <gnn@neville-neil.com>)
	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 <gnn@neville-neil.com>
In-Reply-To: <CC5C760E.18207%anshukla@juniper.net>
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: <CC5C760E.18207%anshukla@juniper.net>
To: Anuranjan Shukla <anshukla@juniper.net>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu,  6 Sep 2012 04:46:53 +0000 (UTC)
Received: by pbbrp2 with SMTP id rp2so2067406pbb.13
	for <freebsd-net@freebsd.org>; 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 <pyunyh@gmail.com>
Date: Thu, 6 Sep 2012 13:46:43 -0700
To: Jason Wolfe <nitroboost@gmail.com>
Message-ID: <20120906204643.GC3160@michelle.cdnetworks.com>
References: <CAAAm0r2=_VbmHop7WMmg7UW7u0D+JGZn2BO1D7E96BFuGPs=8w@mail.gmail.com>
	<4FFFBA0D.7080505@norma.perm.ru>
	<CAAAm0r0h4-9knuxyVZmYHSmkqaaYzYax+ZCwwikBAKipZynAmQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAAm0r0h4-9knuxyVZmYHSmkqaaYzYax+ZCwwikBAKipZynAmQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: freebsd-net@freebsd.org, "Eugene M. Zheganin" <emz@norma.perm.ru>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <emz@norma.perm.ru> wrote:
> > Hi.
> >
> >
> > On 13.07.2012 04:39, Jason Wolfe wrote:
> >>
> >> bge0:<Broadcom unknown BCM5719, ASIC rev 0x5719001>  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:<MII bus>  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: <owner-freebsd-net@FreeBSD.ORG>
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 <glebius@FreeBSD.org>
To: Ermal Lu?i <eri@FreeBSD.org>
Message-ID: <20120906070806.GM15915@glebius.int.ru>
References: <20120905115140.GF15915@FreeBSD.org>
	<CAPBZQG0KHs_ckvn0TPr38Z_vPokziZH=1xx1NG53Ld8rkV_JJg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <CAPBZQG0KHs_ckvn0TPr38Z_vPokziZH=1xx1NG53Ld8rkV_JJg@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
Date: Thu, 6 Sep 2012 10:00:45 -0700
X-Google-Sender-Auth: 8Zc5goz7b_ufRlncHOnX8b8__Gs
Message-ID: <CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Eugene Grosbein <egrosbein@rdtc.ru>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 17:00:46 -0000

On 5 September 2012 00:25, Eugene Grosbein <egrosbein@rdtc.ru> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <egrosbein@rdtc.ru>
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 <adrian@freebsd.org>
References: <1865271844.20120829131610@serebryakov.spb.ru>	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>	<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>	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
In-Reply-To: <CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <egrosbein@rdtc.ru> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
Date: Thu, 6 Sep 2012 10:34:05 -0700
X-Google-Sender-Auth: SdUW-ZR9C1s2ahLl6sdb4XGYyEY
Message-ID: <CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Eugene Grosbein <egrosbein@rdtc.ru>, Alexander Motin <mav@freebsd.org>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, freebsd-net@freebsd.org,
	Lev Serebryakov <lev@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <egrosbein@rdtc.ru> wrote:
> 07.09.2012 00:00, Adrian Chadd =D0=C9=DB=C5=D4:
>> On 5 September 2012 00:25, Eugene Grosbein <egrosbein@rdtc.ru> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; Thu,  6 Sep 2012 17:38:58 +0000 (UTC)
Received: by dadr6 with SMTP id r6so1281621dad.13
	for <net@freebsd.org>; 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@->
	<CAJ-VmoneEMvCpNotru+ws9NdcyExnkGfxnx2W=z7e-Myb1RWRQ@mail.gmail.com>
	<20120902212952.GB2654@aspire.rulingia.com>
Date: Thu, 6 Sep 2012 10:38:57 -0700
X-Google-Sender-Auth: a3SEljVlT9BHijBQCjSVKguHP4g
Message-ID: <CAJ-VmokYqne9DY_BR56m7w6s8Xcz=JLxqCR1GfjR+a8fnyW_8A@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Peter Jeremy <peter@rulingia.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 17:38:58 -0000

On 2 September 2012 14:29, Peter Jeremy <peter@rulingia.com> wrote:
> Adrian,
>
> On 2012-Aug-31 04:29:53 -0700, Adrian Chadd <adrian@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <flo@smeets.im>
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 <adrian@freebsd.org>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
In-Reply-To: <CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
X-Enigmail-Version: 1.5a1pre
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigCEF70C40F6E02478251ABB40"
Cc: pyunyh@gmail.com, Lev Serebryakov <lev@freebsd.org>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
Date: Thu, 6 Sep 2012 10:41:39 -0700
X-Google-Sender-Auth: mN7eiG-YwPAR9AoqZbmfDxGGSt4
Message-ID: <CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: Florian Smeets <flo@smeets.im>
Content-Type: text/plain; charset=ISO-8859-1
Cc: pyunyh@gmail.com, Lev Serebryakov <lev@freebsd.org>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 17:41:40 -0000

On 6 September 2012 10:40, Florian Smeets <flo@smeets.im> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <lev@FreeBSD.org>
Organization: FreeBSD
X-Priority: 3 (Normal)
Message-ID: <10710514011.20120906220055@serebryakov.spb.ru>
To: Adrian Chadd <adrian@freebsd.org>
In-Reply-To: <CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, Florian Smeets <flo@smeets.im>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <lev@FreeBSD.org>


From owner-freebsd-net@FreeBSD.ORG  Thu Sep  6 18:02:51 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
	<10710514011.20120906220055@serebryakov.spb.ru>
Date: Thu, 6 Sep 2012 11:02:50 -0700
X-Google-Sender-Auth: 5s7W7yoJymqXNfavI5FFkBPkpd4
Message-ID: <CAJ-Vmokiwh9PtF7f2UnhO==ZbAKvTn+rRd3Lp5oBD0+9nH+LQg@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: lev@freebsd.org
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, Florian Smeets <flo@smeets.im>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 18:02:51 -0000

Hiya,

On 6 September 2012 11:00, Lev Serebryakov <lev@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <lev@FreeBSD.org>
Organization: FreeBSD Project
X-Priority: 3 (Normal)
Message-ID: <143885439.20120906220554@serebryakov.spb.ru>
To: Adrian Chadd <adrian@freebsd.org>
In-Reply-To: <CAJ-Vmokiwh9PtF7f2UnhO==ZbAKvTn+rRd3Lp5oBD0+9nH+LQg@mail.gmail.com>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
	<10710514011.20120906220055@serebryakov.spb.ru>
	<CAJ-Vmokiwh9PtF7f2UnhO==ZbAKvTn+rRd3Lp5oBD0+9nH+LQg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, Florian Smeets <flo@smeets.im>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <lev@FreeBSD.org>


From owner-freebsd-net@FreeBSD.ORG  Thu Sep  6 18:07:09 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
	<10710514011.20120906220055@serebryakov.spb.ru>
	<CAJ-Vmokiwh9PtF7f2UnhO==ZbAKvTn+rRd3Lp5oBD0+9nH+LQg@mail.gmail.com>
	<143885439.20120906220554@serebryakov.spb.ru>
Date: Thu, 6 Sep 2012 11:07:08 -0700
X-Google-Sender-Auth: Am5y8UY7_t7AaoxGND8YSvCpU6I
Message-ID: <CAJ-Vmom6J0vThMocLj1Xm+2f0ekKWE8mNoB7ZvYts6kY4yEN5g@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: lev@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: pyunyh@gmail.com, Florian Smeets <flo@smeets.im>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <lev@FreeBSD.org>
Organization: FreeBSD Project
X-Priority: 3 (Normal)
Message-ID: <1828371828.20120906221136@serebryakov.spb.ru>
To: Adrian Chadd <adrian@freebsd.org>
In-Reply-To: <CAJ-Vmom6J0vThMocLj1Xm+2f0ekKWE8mNoB7ZvYts6kY4yEN5g@mail.gmail.com>
References: <1865271844.20120829131610@serebryakov.spb.ru>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
	<10710514011.20120906220055@serebryakov.spb.ru>
	<CAJ-Vmokiwh9PtF7f2UnhO==ZbAKvTn+rRd3Lp5oBD0+9nH+LQg@mail.gmail.com>
	<143885439.20120906220554@serebryak ov.spb.ru>
	<CAJ-Vmom6J0vThMocLj1Xm+2f0ekKWE8mNoB7ZvYts6kY4yEN5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, Florian Smeets <flo@smeets.im>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <lev@FreeBSD.org>


From owner-freebsd-net@FreeBSD.ORG  Thu Sep  6 18:12:05 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
	<10710514011.20120906220055@serebryakov.spb.ru>
	<CAJ-Vmokiwh9PtF7f2UnhO==ZbAKvTn+rRd3Lp5oBD0+9nH+LQg@mail.gmail.com>
	<CAJ-Vmom6J0vThMocLj1Xm+2f0ekKWE8mNoB7ZvYts6kY4yEN5g@mail.gmail.com>
	<1828371828.20120906221136@serebryakov.spb.ru>
Date: Thu, 6 Sep 2012 11:12:04 -0700
X-Google-Sender-Auth: 4Wyv21EcSQGcyPTDJYLEFzjqyhU
Message-ID: <CAJ-Vmom-QQv54P24KahdzNfwhVmYKL-G8CpginQvyEQ-JFaZrQ@mail.gmail.com>
From: Adrian Chadd <adrian@freebsd.org>
To: lev@freebsd.org
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
Cc: pyunyh@gmail.com, Florian Smeets <flo@smeets.im>,
	Eugene Grosbein <egrosbein@rdtc.ru>, freebsd-net@freebsd.org,
	Alexander Motin <mav@freebsd.org>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 18:12:05 -0000

On 6 September 2012 11:11, Lev Serebryakov <lev@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <avg@FreeBSD.org>
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>
	<CAHu1Y70MynCMQTrJUMwTZ0+LrM1JiZFt_B77028XHfoiRgzmaA@mail.gmail.com>
	<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>
	<CAJ-VmonQhGShMASEkrxnrDU8xOQBJU+GnV0Nmeg4Lz2xACBRpw@mail.gmail.com>
	<5046FE57.3050903@rdtc.ru>
	<CAJ-Vmomedv-mEV3D1WHR9_eLirE=ORSVndeJJgpFweCuRPuyoA@mail.gmail.com>
	<5048D7A7.1030708@rdtc.ru>
	<CAJ-Vmon-CuAi0RBsfp+QB3k6GvpNiCSts7baa_jRN2tbnwVrtA@mail.gmail.com>
	<5048DFF8.50405@smeets.im>
	<CAJ-VmonvH97sk8xvMrMwX7=0zi=LhhCo8NnfwHxhtggBJ_NE=w@mail.gmail.com>
	<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 <adrian@FreeBSD.org>, lev@FreeBSD.org,
	Eugene Grosbein <egrosbein@rdtc.ru>, Alexander Motin <mav@FreeBSD.org>,
	Florian Smeets <flo@smeets.im>, Ian Smith <smithi@nimnet.asn.au>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri,  7 Sep 2012 05:22:30 +0000 (UTC)
Received: by vbmv11 with SMTP id v11so3412543vbm.13
	for <freebsd-net@freebsd.org>; 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: <CAL8FXqyqJk2RE4M4K8wmyae7LC2ztpxFqepXjT7MjL3znfRczQ@mail.gmail.com>
References: <CAL8FXqxh7M0CXrsRy-kKkCFTgf70wWjp1Mq3UXtVmg3aFmDfZA@mail.gmail.com>
	<5046640E.10806@FreeBSD.org>
	<CAL8FXqyqJk2RE4M4K8wmyae7LC2ztpxFqepXjT7MjL3znfRczQ@mail.gmail.com>
Date: Fri, 7 Sep 2012 07:22:29 +0200
Message-ID: <CAL8FXqzHQEnETVvfM1=FN0urra-Zi5wjVF5BTELQ6v82+pY=dw@mail.gmail.com>
From: Brian Stivala <brianstivala@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <brianstivala@gmail.com>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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,=
CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
> 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: <software crypto> on motherboard
> padlock0: No ACE support.
> pcib0: <Intel 82443BX host to PCI bridge (AGP disabled)> pcibus 0 on
> motherboard
> pci0: <PCI bus> on pcib0
> fxp0: <Intel 82559ER Embedded 10/100 Ethernet> port 0xfc00-0xfc3f mem
> 0xc0000000-0xc0000fff,0xc0020000-0xc003ffff irq 9 at device 5.0 on pci0
> fxp0: Enabling Rx lock-up workaround
> miibus0: <MII bus> on fxp0
> inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
> inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> fxp0: [ITHREAD]
> fxp1: <Intel 82559ER Embedded 10/100 Ethernet> port 0xf800-0xf83f mem
> 0xc0040000-0xc0040fff,0xc0060000-0xc007ffff irq 6 at device 6.0 on pci0
> fxp1: Enabling Rx lock-up workaround
> miibus1: <MII bus> on fxp1
> inphy1: <i82555 10/100 media interface> PHY 1 on miibus1
> inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> fxp1: [ITHREAD]
> isab0: <PCI-ISA bridge> at device 7.0 on pci0
> isa0: <ISA bus> on isab0
> atapci0: <Intel PIIX4 UDMA33 controller> port
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 7.1 on pci0
> ata0: <ATA channel 0> on atapci0
> ata0: [ITHREAD]
> ata1: <ATA channel 1> on atapci0
> ata1: [ITHREAD]
> uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xf000-0xf01f irq 1=
1
> at device 7.2 on pci0
> uhci0: [ITHREAD]
> usbus0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
> piix0: <PIIX Timecounter> port 0x10a0-0x10af at device 7.3 on pci0
> Timecounter "PIIX" frequency 3579545 Hz quality 0
> pci0: <processor> at device 8.0 (no driver attached)
> pci0: <network, ethernet> at device 9.0 (no driver attached)
> cpu0 on motherboard
> atrtc0: <AT Real Time Clock> 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<ROM_cksum>
> 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 <CF Card Ver1.27> at ata0-master PIO4
> ugen0.1: <Intel> at usbus0
> uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> 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 <matthew@freebsd.org>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: <owner-freebsd-net@FreeBSD.ORG>
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 <seanbru@yahoo-inc.com>
To: "freebsd-net@freebsd.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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.

<boot snippet>
igb0: <Intel(R) PRO/1000 Network Connection version - 2.3.4> 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: <Intel(R) PRO/1000 Network Connection version - 2.3.4> 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


<panic>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <seanbru@yahoo-inc.com>
To: "freebsd-net@freebsd.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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.

<boot snippet>
igb0: <Intel(R) PRO/1000 Network Connection version - 2.3.4> 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: <Intel(R) PRO/1000 Network Connection version - 2.3.4> 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


<panic>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <anshukla@juniper.net>
To: George Neville-Neil <gnn@neville-neil.com>
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: <CC6EF6B2.1917A%anshukla@juniper.net>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri,  7 Sep 2012 10:01:35 +0000 (UTC)
Received: by lbbgg13 with SMTP id gg13so2396341lbb.13
	for <freebsd-net@freebsd.org>; 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>
	<FF06542A-9507-4C8C-99EC-8275B04D4CF1@my.gd>
	<E183609A-19E1-4EF4-B08D-FAA55779E193@my.gd>
	<503BC8F5.3040208@zirakzigil.org>
	<CAE63ME6oi_5Yam5wXuJzYBhhv+N6MnQPOXReXo2Ugo1hjvv25Q@mail.gmail.com>
	<503E7A16.6030600@zirakzigil.org> <5044F62E.8030001@zirakzigil.org>
Date: Fri, 7 Sep 2012 11:01:34 +0100
Message-ID: <CAPyG9gMaNnLJOE00bH66qpAoJfdU=YtpUvz24fj+1nyvjDDCAg@mail.gmail.com>
From: Simon Dick <simond@irrelevant.org>
To: Giulio Ferro <auryn@zirakzigil.org>
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQnuGJ+lSFyjIYvrFaE0TRfPw2CrHjKrgysmLILpZD4dfT9MJ1dl1NeYaz9m/lVfTY1m2w4X
Cc: freebsd-net@freebsd.org,
	"freebsd-stable@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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <auryn@zirakzigil.org> 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 <auryn@zirakzigil.org> wrote:
>>>>
>>>> Hi, thanks for the answer
>>>>
>>>> Here is what you asked for:
>>>>
>>>> # ifconfig igb0
>>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>>>> 1500
>>>>
>>>>
>>>> options=4401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
>>>>
>>>> ether ...
>>>> inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255
>>>>          inet6 .... prefixlen 64 scopeid 0x1
>>>>          nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>>>          media: Ethernet autoselect (1000baseT <full-duplex>)
>>>>          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 <ml@my.gd> 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 <auryn@zirakzigil.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <vince@unsane.co.uk>
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 <brianstivala@gmail.com>
References: <CAL8FXqxh7M0CXrsRy-kKkCFTgf70wWjp1Mq3UXtVmg3aFmDfZA@mail.gmail.com>
	<5046640E.10806@FreeBSD.org>
	<CAL8FXqyqJk2RE4M4K8wmyae7LC2ztpxFqepXjT7MjL3znfRczQ@mail.gmail.com>
	<CAL8FXqzHQEnETVvfM1=FN0urra-Zi5wjVF5BTELQ6v82+pY=dw@mail.gmail.com>
In-Reply-To: <CAL8FXqzHQEnETVvfM1=FN0urra-Zi5wjVF5BTELQ6v82+pY=dw@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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 <brianstivala@gmail.com>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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
>> 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: <software crypto> on motherboard
>> padlock0: No ACE support.
>> pcib0: <Intel 82443BX host to PCI bridge (AGP disabled)> pcibus 0 on
>> motherboard
>> pci0: <PCI bus> on pcib0
>> fxp0: <Intel 82559ER Embedded 10/100 Ethernet> port 0xfc00-0xfc3f mem
>> 0xc0000000-0xc0000fff,0xc0020000-0xc003ffff irq 9 at device 5.0 on pci0
>> fxp0: Enabling Rx lock-up workaround
>> miibus0: <MII bus> on fxp0
>> inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
>> inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> fxp0: [ITHREAD]
>> fxp1: <Intel 82559ER Embedded 10/100 Ethernet> port 0xf800-0xf83f mem
>> 0xc0040000-0xc0040fff,0xc0060000-0xc007ffff irq 6 at device 6.0 on pci0
>> fxp1: Enabling Rx lock-up workaround
>> miibus1: <MII bus> on fxp1
>> inphy1: <i82555 10/100 media interface> PHY 1 on miibus1
>> inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> fxp1: [ITHREAD]
>> isab0: <PCI-ISA bridge> at device 7.0 on pci0
>> isa0: <ISA bus> on isab0
>> atapci0: <Intel PIIX4 UDMA33 controller> port
>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 7.1 on pci0
>> ata0: <ATA channel 0> on atapci0
>> ata0: [ITHREAD]
>> ata1: <ATA channel 1> on atapci0
>> ata1: [ITHREAD]
>> uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xf000-0xf01f irq 11
>> at device 7.2 on pci0
>> uhci0: [ITHREAD]
>> usbus0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
>> piix0: <PIIX Timecounter> port 0x10a0-0x10af at device 7.3 on pci0
>> Timecounter "PIIX" frequency 3579545 Hz quality 0
>> pci0: <processor> at device 8.0 (no driver attached)
>> pci0: <network, ethernet> at device 9.0 (no driver attached)
>> cpu0 on motherboard
>> atrtc0: <AT Real Time Clock> 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<ROM_cksum>
>> 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 <CF Card Ver1.27> at ata0-master PIO4
>> ugen0.1: <Intel> at usbus0
>> uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> 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 <matthew@freebsd.org>wrote:
>>
>>> On 04/09/2012 19:33, Brian Stivala wrote:
>>>> I have a watchguard firewall v80 which I’ve decided to amend it to
>>> PFSense
>>>> based on freebsd. So far I’ve 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: <owner-freebsd-net@FreeBSD.ORG>
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 <glebius@FreeBSD.org>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <julian@freebsd.org>
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 <anshukla@juniper.net>
References: <CC6EF6B2.1917A%anshukla@juniper.net>
In-Reply-To: <CC6EF6B2.1917A%anshukla@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "freebsd-net@freebsd.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <gnn@neville-neil.com>)
	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 <anshukla@juniper.net>
In-Reply-To: <CC6EF6B2.1917A%anshukla@juniper.net>
References: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com>
	<CC6EF6B2.1917A%anshukla@juniper.net>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <seanbru@yahoo-inc.com>
To: John <jwd@freebsd.org>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <jlott@averesystems.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=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