From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 02:36:01 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18CAF1065675; Sun, 4 Mar 2012 02:36:01 +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 E1A7E8FC08; Sun, 4 Mar 2012 02:36:00 +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 q242a0rg050583; Sun, 4 Mar 2012 02:36:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q242a09x050579; Sun, 4 Mar 2012 02:36:00 GMT (envelope-from linimon) Date: Sun, 4 Mar 2012 02:36:00 GMT Message-Id: <201203040236.q242a09x050579@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165643: [net] [patch] Missing vnet restores in net/if_ethersubr.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 02:36:01 -0000 Old Synopsis: Missing vnet restores in net/if_ethersubr.c New Synopsis: [net] [patch] Missing vnet restores in net/if_ethersubr.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 4 02:35:34 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165643 From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 06:31:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2A3F1065674 for ; Sun, 4 Mar 2012 06:31:15 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 04D4F8FC0A for ; Sun, 4 Mar 2012 06:31:14 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3257321bkc.13 for ; Sat, 03 Mar 2012 22:31:08 -0800 (PST) Received-SPF: pass (google.com: domain of bagadeh@gmail.com designates 10.204.156.12 as permitted sender) client-ip=10.204.156.12; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bagadeh@gmail.com designates 10.204.156.12 as permitted sender) smtp.mail=bagadeh@gmail.com; dkim=pass header.i=bagadeh@gmail.com Received: from mr.google.com ([10.204.156.12]) by 10.204.156.12 with SMTP id u12mr1750675bkw.33.1330842668063 (num_hops = 1); Sat, 03 Mar 2012 22:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HzhvnwI6il6Z7mcSxhAVO4IHEMkiL43GfoGLBkn1MRQ=; b=sHxFuuXzu6q7KW2eI+abKfUKJ32CA3joR+zKTXEq+TJFwse59LbmMSwfFqkwF5a3fP 16V/1jtwmNpwjyqc1tu8rUddWEUfhX7X7I0QC0BHbrsirrqZ7KGQQrgOTzcj3ahP5l2V dYvjFLwM6rGWrAC8GFR7vwKm2mA0TAwKsv7O89eh1mNMDszm9LlBGZTWmxbZWdfTW3bA X9HkkdHXq7zNh5t6dfv/O+iSOKdv6umqybXkxWfSQAcrzfhDLTz5QBCOMxa47ySMZF1d Nto6g8AOO6m6/nV6B1eaStbZgNkqyGLGdD2TZ/KCz+DIwYnfTKjSjKPdbn6F9mxBYBpc DfDg== MIME-Version: 1.0 Received: by 10.204.156.12 with SMTP id u12mr1380912bkw.33.1330842667946; Sat, 03 Mar 2012 22:31:07 -0800 (PST) Received: by 10.204.167.139 with HTTP; Sat, 3 Mar 2012 22:31:07 -0800 (PST) Date: Sun, 4 Mar 2012 10:01:07 +0330 Message-ID: From: h bagade To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 06:31:16 -0000 Hi all, I have problems with vlan interfaces on freebsd. I want to make my system like a switch with vlan ports and also a trunk port in conjuction with other switches. I thought that vlan interfaces would help me tagging traffic when traffic is going out the trunk port(or when it receives on vlan ports). The problem, I've encountered is that vlan interafaces on freebsd do tagging/untagging when the traffic is sourced/destined from/to them which in this case they should be assigned IP addresses. In other words they won't tag the traffic passing through their parent interface which I need to. In my case to be acting like a switch, interfaces on system won't have ip addresses and I need to tag the traffic coming from for example interface1 when passing through interfaceN(acting as trunk port). How could I reach this? would it be possible to use vlan interfaces to do so? I've tried many many ways to simulate the case but no success achieved! I'm really interested to find the proper solution for my config. Any comments or hints are really apperciated. From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 10:32:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AA59106564A for ; Sun, 4 Mar 2012 10:32:47 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE42B8FC12 for ; Sun, 4 Mar 2012 10:32:46 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3329305bkc.13 for ; Sun, 04 Mar 2012 02:32:45 -0800 (PST) Received-SPF: pass (google.com: domain of rozhuk.im@gmail.com designates 10.204.155.154 as permitted sender) client-ip=10.204.155.154; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rozhuk.im@gmail.com designates 10.204.155.154 as permitted sender) smtp.mail=rozhuk.im@gmail.com; dkim=pass header.i=rozhuk.im@gmail.com Received: from mr.google.com ([10.204.155.154]) by 10.204.155.154 with SMTP id s26mr8596968bkw.24.1330857165787 (num_hops = 1); Sun, 04 Mar 2012 02:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=c2tTSqgmNCz8i83NDwURPpZlhx+t9jr4ANrPmXRkxgE=; b=CYD13gvMRh54LN6JeVFDy5hGD6GvJyBTw96w3sqaXHcumuyFBoOgF5gS4wIA47gEuE hu8B7BQnRV8kp82g+m5c87ZClbRQP/ixleyZ0qoTkZyXyfZ+Vr53upM9P8oku/ETZ+Z9 v5V9jIyV2n0c/goacFbxKM4ZniwFa/Jd4sbnf+LKPFXjmdPAVpQ6Tu0Aco7QvKz7ncr7 tRBS0IN7NRjlHAk9SERuCejZxHfIitSI6A+KuZwkz1EjMZJ3+Axuwy1J2A7xv+F5Pp6/ B32PvltFWBTsdSKSIMOZRoiio+wyIglwU0IgELd4gLoM5pEn210nJVwKKmgW7hDDskiv aKAQ== Received: by 10.204.155.154 with SMTP id s26mr6860745bkw.24.1330857165715; Sun, 04 Mar 2012 02:32:45 -0800 (PST) Received: from rimwks1w7x64 ([141.105.54.13]) by mx.google.com with ESMTPS id jd17sm19008356bkb.4.2012.03.04.02.32.43 (version=SSLv3 cipher=OTHER); Sun, 04 Mar 2012 02:32:44 -0800 (PST) From: rozhuk.im@gmail.com To: "'h bagade'" , "'freebsd-net'" References: In-Reply-To: Date: Sun, 4 Mar 2012 19:32:41 +0900 Message-ID: <4f5344cc.51e4cc0a.522a.1a15@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz50Hd7bDBKC6knSkOz5dXyb4DV6AAIZuAA Content-Language: ru Cc: Subject: RE: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 10:32:47 -0000 Use netgraph nodes. > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of h bagade > Sent: Sunday, March 04, 2012 3:31 PM > To: freebsd-net > Subject: problem with vlan interfaces tagging/untagging in a simulated > switch box > > Hi all, > > I have problems with vlan interfaces on freebsd. I want to make my > system like a switch with vlan ports and also a trunk port in > conjuction with other switches. I thought that vlan interfaces would > help me tagging traffic when traffic is going out the trunk port(or > when it receives on vlan ports). > The problem, I've encountered is that vlan interafaces on freebsd do > tagging/untagging when the traffic is sourced/destined from/to them > which in this case they should be assigned IP addresses. In other words > they won't tag the traffic passing through their parent interface which > I need to. > > In my case to be acting like a switch, interfaces on system won't have > ip addresses and I need to tag the traffic coming from for example > interface1 when passing through interfaceN(acting as trunk port). > How could I reach this? would it be possible to use vlan interfaces to > do so? > > I've tried many many ways to simulate the case but no success achieved! > I'm really interested to find the proper solution for my config. > > Any comments or hints are really apperciated. > _______________________________________________ > 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 Sun Mar 4 11:20:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7928106566B for ; Sun, 4 Mar 2012 11:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CE6C98FC08 for ; Sun, 4 Mar 2012 11:20:04 +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 q24BK4A7070837 for ; Sun, 4 Mar 2012 11:20:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q24BK4Db070836; Sun, 4 Mar 2012 11:20:04 GMT (envelope-from gnats) Date: Sun, 4 Mar 2012 11:20:04 GMT Message-Id: <201203041120.q24BK4Db070836@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165643: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 11:20:05 -0000 The following reply was made to PR kern/165643; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165643: commit references a PR Date: Sun, 4 Mar 2012 11:11:45 +0000 (UTC) Author: zec Date: Sun Mar 4 11:11:03 2012 New Revision: 232487 URL: http://svn.freebsd.org/changeset/base/232487 Log: Properly restore curvnet context when returning early from ether_input_internal(). This change only affects options VIMAGE kernel builds. PR: kern/165643 Submitted by: Vijay Singh MFC after: 3 days Modified: head/sys/net/if_ethersubr.c Modified: head/sys/net/if_ethersubr.c ============================================================================== --- head/sys/net/if_ethersubr.c Sun Mar 4 10:37:26 2012 (r232486) +++ head/sys/net/if_ethersubr.c Sun Mar 4 11:11:03 2012 (r232487) @@ -661,8 +661,10 @@ ether_input_internal(struct ifnet *ifp, m = (*lagg_input_p)(ifp, m); if (m != NULL) ifp = m->m_pkthdr.rcvif; - else + else { + CURVNET_RESTORE(); return; + } } /* @@ -681,6 +683,7 @@ ether_input_internal(struct ifnet *ifp, #endif ifp->if_ierrors++; m_freem(m); + CURVNET_RESTORE(); return; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 18:45:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9023106564A; Sun, 4 Mar 2012 18:45:35 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 45C758FC12; Sun, 4 Mar 2012 18:45:35 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.iaf.psconsult.nl [80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id q24IjTEr057509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Mar 2012 19:45:34 +0100 (CET) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id q24IjTX2057508; Sun, 4 Mar 2012 19:45:29 +0100 (CET) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Sun, 4 Mar 2012 19:45:29 +0100 From: Paul Schenkeveld To: freebsd-emulation@freebsd.org, freebsd-net@freebsd.org Message-ID: <20120304184529.GA57370@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: if_bridge stops when running virtualbox 4.1.8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 18:45:35 -0000 Hi, I just noticed that when running Virtualbox 4.1.8 with a bridged network interface, I loose connectivity to another virtual host running in qemu whose network interface is bridged to my ethernet interface. After stopping the Virtualbox instance, I regain connection to the virtual host under qemu. Ifconfig doesn't give a clue. Has anyone seen this behaviour or, even better, have a solution? My host is running 8.2-RELEASE, here's the relevant ifconfig output: em0: flags=8943 metric 0 mtu +1500 options=2098 ether 00:1f:16:xx:xx:xx inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active tap0: flags=8943 metric 0 mtu +1500 options=80000 ether 00:bd:32:xx:xx:xx nd6 options=3 Opened by PID 13433 bridge0: flags=8843 metric 0 mtu 1500 ether 8a:55:3f:xx:xx:xx id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 2000000 member: em0 flags=143 ifmaxaddr 0 port 1 priority 128 path cost 20000 vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 Thanks! Paul Schenkeveld From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 20:08:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB511065670; Sun, 4 Mar 2012 20:08:45 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward20.mail.yandex.net (forward20.mail.yandex.net [IPv6:2a02:6b8:0:1402::5]) by mx1.freebsd.org (Postfix) with ESMTP id 487448FC14; Sun, 4 Mar 2012 20:08:44 +0000 (UTC) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [95.108.252.18]) by forward20.mail.yandex.net (Yandex) with ESMTP id 5AF071041877; Mon, 5 Mar 2012 00:08:42 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1330891722; bh=xWH91kltiZeU2ZmcATlOWoy9qRzKJCNrf05xARxBzno=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pFrMoo5k7+vT8psMIqMBjLRFEY9GSSK93DxYtmkomZjf3T1j/2Hjxz23MZ5abhB6C H3SbRataz2YR4fXZ3H0X4WVWJyY3/t3e+Npu2/6XBETx0Dkt9bmz11OLGekkhyntZQ 9svnGMw5wiVatUGz7DunfMIXmpcEMpy8AqqImwUw= Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 1A1E418A0199; Mon, 5 Mar 2012 00:08:42 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1330891722; bh=xWH91kltiZeU2ZmcATlOWoy9qRzKJCNrf05xARxBzno=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pFrMoo5k7+vT8psMIqMBjLRFEY9GSSK93DxYtmkomZjf3T1j/2Hjxz23MZ5abhB6C H3SbRataz2YR4fXZ3H0X4WVWJyY3/t3e+Npu2/6XBETx0Dkt9bmz11OLGekkhyntZQ 9svnGMw5wiVatUGz7DunfMIXmpcEMpy8AqqImwUw= Received: from unknown (unknown [77.93.52.20]) by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 8fmGkHes-8fmSABtP; Mon, 5 Mar 2012 00:08:41 +0400 X-Yandex-Spam: 1 Date: Sun, 4 Mar 2012 22:08:50 +0200 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <71478795.20120304220850@yandex.ru> To: rozhuk.im@gmail.com In-Reply-To: <4f53444e.d12acc0a.3131.1f1c@mx.google.com> References: <292119122.20120228212137@yandex.ru> <755733674.20120303231429@yandex.ru> <4f53444e.d12acc0a.3131.1f1c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re[2]: netisr traffic bad distribution between CPUs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:08:45 -0000 # sysctl net.isr net.isr.numthreads: 4 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 and as you see in "netstat -Q" >> Direct dispatch disabled n/a >> Forced direct dispatch disabled n/a >> Threads bound to CPUs disabled n/a rigc> net.isr.dispatch: deferred? >> >> >> # netstat -Q >> Configuration: >> Setting Current Limit >> Thread count 4 4 >> Default queue limit 256 10240 >> Direct dispatch disabled n/a >> Forced direct dispatch disabled n/a >> Threads bound to CPUs disabled n/a >> >> Protocols: >> Name Proto QLimit Policy Flags >> ip 1 1024 flow --- >> igmp 2 256 source --- >> rtsock 3 256 source --- >> arp 7 256 source --- >> ip6 10 256 flow --- >> >> Workstreams: >> WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued >> Handled >> 0 0 ip 606 1024 0 0 2930711 2377098505 >> 2377097226 >> 0 0 igmp 0 0 0 0 0 0 >> 0 >> 0 0 rtsock 0 251 0 0 0 108579 >> 108579 >> 0 0 arp 0 17 0 0 0 205271 >> 205271 >> 0 0 ip6 0 1 0 0 0 1111 >> 1111 >> 1 1 ip 16 536 0 0 0 758322101 >> 758322085 >> 1 1 igmp 0 0 0 0 0 0 >> 0 >> 1 1 rtsock 0 0 0 0 0 0 >> 0 >> 1 1 arp 0 3 0 0 0 106860 >> 106860 >> 1 1 ip6 0 2 0 0 0 1254 >> 1254 >> 2 2 ip 155 1024 0 0 414966 2378645792 >> 2378645336 >> 2 2 igmp 0 0 0 0 0 0 >> 0 >> 2 2 rtsock 0 0 0 0 0 0 >> 0 >> 2 2 arp 0 11 0 0 0 320116 >> 320116 >> 2 2 ip6 0 1 0 0 0 3557 >> 3557 >> 3 3 ip 0 1024 0 0 5774 2108548645 >> 2108548645 >> 3 3 igmp 0 0 0 0 0 0 >> 0 >> 3 3 rtsock 0 0 0 0 0 0 >> 0 >> 3 3 arp 0 12 0 0 0 672284 >> 672284 >> 3 3 ip6 0 3 0 0 0 13870 >> 13870 >> -- С уважением, Коньков mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Sun Mar 4 21:58:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D79E2106566C for ; Sun, 4 Mar 2012 21:58:34 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5516A8FC17 for ; Sun, 4 Mar 2012 21:58:34 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3602658bkc.13 for ; Sun, 04 Mar 2012 13:58:33 -0800 (PST) Received-SPF: pass (google.com: domain of hiren.panchasara@gmail.com designates 10.204.150.88 as permitted sender) client-ip=10.204.150.88; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hiren.panchasara@gmail.com designates 10.204.150.88 as permitted sender) smtp.mail=hiren.panchasara@gmail.com; dkim=pass header.i=hiren.panchasara@gmail.com Received: from mr.google.com ([10.204.150.88]) by 10.204.150.88 with SMTP id x24mr9494588bkv.82.1330898313454 (num_hops = 1); Sun, 04 Mar 2012 13:58:33 -0800 (PST) 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=1/0+6SVoJmMvTOiVoGItKuDSJDuA020sMAd4MQc7Mwk=; b=QLY5EWnbajaHb+GjTvCRlzqNIZYKBBOOPZgAGughCRXJB0slLZxXLEEKHsYbpdM1/p Fi343QjZ2opNF697Bw6C8WOpeGjLDizHrU5wOJuOPvf7d1XcfI5yrlWxhbEXF5iTKCLw yswJo//z9Mkgc3cQGyT9i9u3lNxzLX/NNNWBXAzQ8qabjdexwl2zB0+U+xhWw4VsVteu 4qKZFh9n7l9CiqPoJv7bJ3ipnbA5yzQFCxtF9R1KPcQZ4JsdQkeBYG7sjm8Sy0ugDg0o dTbDYGme2EEJ0smMDTQm7YImNp5hlVX0/3L8Co9gFn2Z5jLfI34u5p8TZAbtEe9jaxSG ORRA== MIME-Version: 1.0 Received: by 10.204.150.88 with SMTP id x24mr7562198bkv.82.1330896984523; Sun, 04 Mar 2012 13:36:24 -0800 (PST) Received: by 10.204.230.5 with HTTP; Sun, 4 Mar 2012 13:36:24 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Mar 2012 13:36:24 -0800 Message-ID: From: hiren panchasara To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: bridge interface type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:58:34 -0000 Is this the correct mailer for such questions? ---------- Forwarded message ---------- From: hiren panchasara Date: Sat, Mar 3, 2012 at 12:47 AM Subject: bridge interface type To: freebsd-hackers@freebsd.org I created bridge1 this way: $ sudo ifconfig bridge create Password: bridge1 $ ifconfig bridge1 bridge1: flags=8802 metric 0 mtu 1500 ether 02:32:c8:92:b6:01 nd6 options=29 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 but when I try to look at the interface via "struct sockaddr_dl", sdl = (struct sockaddr_dl *) ifa->ifa_addr; sdl->sdl_type is "IFT_ETHER" for that interface. Shouldn't it be "IFT_BRIDGE"? What am I missing here? Thanks in advance, Hiren From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 04:31:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 239FD106564A for ; Mon, 5 Mar 2012 04:31:47 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2538FC13 for ; Mon, 5 Mar 2012 04:31:46 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3767525bkc.13 for ; Sun, 04 Mar 2012 20:31:45 -0800 (PST) Received-SPF: pass (google.com: domain of bagadeh@gmail.com designates 10.205.132.141 as permitted sender) client-ip=10.205.132.141; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bagadeh@gmail.com designates 10.205.132.141 as permitted sender) smtp.mail=bagadeh@gmail.com; dkim=pass header.i=bagadeh@gmail.com Received: from mr.google.com ([10.205.132.141]) by 10.205.132.141 with SMTP id hu13mr9455944bkc.87.1330921905409 (num_hops = 1); Sun, 04 Mar 2012 20:31:45 -0800 (PST) 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=iQQgolIzsHF37ildfVzv//TfABs07Z7dMnoE4UPj3uU=; b=VGzqiendUcecmaPJJ4FiuXt0g+Q6OyYJnrg3uP5/qhTVnLe7XfB3b2SlTNaDQv1knd f4S0xcjcBWjtr70QVF7AIvbJeG3arjjN3uTRcH5Hw6hOP+7Y8D8osutI1EgIle+C5LuV V4LpPMfOMf3LeCZ+hjux4gXPEHZ1Dy0Z8TY6FnoRYRAg3HrJkdx3/48cXqXdVSxV8WfQ 362lqVu3AI+knLZDYBxKNJh54PvoHxfL0Fb1T6eaGuh0PxtcAyDwrbrxg54U+yZ9J96I vR/iM7LZk+txcSCroLu7Tmi5pHwZW/DlE6KOtG9YEIZR44ZfyToIAblDqqYCKGdTgA/J eu+w== MIME-Version: 1.0 Received: by 10.205.132.141 with SMTP id hu13mr7509095bkc.87.1330921905199; Sun, 04 Mar 2012 20:31:45 -0800 (PST) Received: by 10.204.167.139 with HTTP; Sun, 4 Mar 2012 20:31:44 -0800 (PST) In-Reply-To: <4f5344cc.51e4cc0a.522a.1a15@mx.google.com> References: <4f5344cc.51e4cc0a.522a.1a15@mx.google.com> Date: Mon, 5 Mar 2012 08:01:44 +0330 Message-ID: From: h bagade To: Rozhuk.IM@gmail.com Content-Type: multipart/mixed; boundary=000e0cdfd620621a5304ba7767f4 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 04:31:47 -0000 --000e0cdfd620621a5304ba7767f4 Content-Type: text/plain; charset=ISO-8859-1 I've tried netgraph nodes too! but stuck on the next step and asked the problem on this forum and received no answer:( my netgraph scenario is described below: I have designed a topology(attached) using netgraph to add vlan2 tag to the frames coming from eth0(vlan port) and send it to eth1(trunk port) to go out of the box. it works fine. Then I tried to add another interface like eth0 which named eth2(vlan port) to be tagged vlan2 too. After that, I bridged eth0 and eth2 using ifconfig(as vlan ports are connected to each other on same vlan id). When traffic comes from eth0(system1) to the destination eth2(system2), all traffic also sent out eth1 which is not suitable! In the mentioned scenario, I don't want the traffic pass to the eth1. Is there any way that eth1 recognize which mac addresses don't belong to this box then sends the traffic out? I mean I want to send taraffic out of eth1 when the destination is not accessible via FreeBSD box so it should be sent out to be find out. On 3/4/12, rozhuk.im@gmail.com wrote: > > Use netgraph nodes. > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of h bagade >> Sent: Sunday, March 04, 2012 3:31 PM >> To: freebsd-net >> Subject: problem with vlan interfaces tagging/untagging in a simulated >> switch box >> >> Hi all, >> >> I have problems with vlan interfaces on freebsd. I want to make my >> system like a switch with vlan ports and also a trunk port in >> conjuction with other switches. I thought that vlan interfaces would >> help me tagging traffic when traffic is going out the trunk port(or >> when it receives on vlan ports). >> The problem, I've encountered is that vlan interafaces on freebsd do >> tagging/untagging when the traffic is sourced/destined from/to them >> which in this case they should be assigned IP addresses. In other words >> they won't tag the traffic passing through their parent interface which >> I need to. >> >> In my case to be acting like a switch, interfaces on system won't have >> ip addresses and I need to tag the traffic coming from for example >> interface1 when passing through interfaceN(acting as trunk port). >> How could I reach this? would it be possible to use vlan interfaces to >> do so? >> >> I've tried many many ways to simulate the case but no success achieved! >> I'm really interested to find the proper solution for my config. >> >> Any comments or hints are really apperciated. >> _______________________________________________ >> 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" > > --000e0cdfd620621a5304ba7767f4-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 04:51:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 175361065674 for ; Mon, 5 Mar 2012 04:51:06 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 89E358FC0A for ; Mon, 5 Mar 2012 04:51:05 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3777293bkc.13 for ; Sun, 04 Mar 2012 20:51:04 -0800 (PST) Received-SPF: pass (google.com: domain of bagadeh@gmail.com designates 10.204.133.196 as permitted sender) client-ip=10.204.133.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bagadeh@gmail.com designates 10.204.133.196 as permitted sender) smtp.mail=bagadeh@gmail.com; dkim=pass header.i=bagadeh@gmail.com Received: from mr.google.com ([10.204.133.196]) by 10.204.133.196 with SMTP id g4mr9936551bkt.0.1330923064621 (num_hops = 1); Sun, 04 Mar 2012 20:51:04 -0800 (PST) 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=wI4gqkuUozdQv1vQTX5LpHASqtbUuv17v1HJcEkIk34=; b=nmCSUyeGI46BWOsuF7I88k0RFQ4BoGuR9tn5baHi4VY98tFSGL3jKgUbMEFP47rkls pJ8Rv/AqH01Cle6bAfIqrb5cBuEaJal+JXmVTV/VleAJAk85p47k1oXCsBVAxwFRTTIF kSEMXWekbmpDJ8ZUup3Ahq+0pGaOopEwFBygUMaL6SMixYAdzm8tErpp0/R82om2DNRa rx7oj8s/GqJ83M6b7Zxo6u85KjTgmSTh6bFyy44MlhczjTyRfHBPh72kjJm6jjBpb/Pq 8cFlR013HoyvIQWnJwoK2ufhGfEXcks/KGG8KPzfK27BqIO+satIn06EAHTSAY1j04ku OPoQ== MIME-Version: 1.0 Received: by 10.204.133.196 with SMTP id g4mr7910792bkt.0.1330923064496; Sun, 04 Mar 2012 20:51:04 -0800 (PST) Received: by 10.204.167.139 with HTTP; Sun, 4 Mar 2012 20:51:04 -0800 (PST) In-Reply-To: References: <4f5344cc.51e4cc0a.522a.1a15@mx.google.com> Date: Mon, 5 Mar 2012 08:21:04 +0330 Message-ID: From: h bagade To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 04:51:06 -0000 if you can not get the image, I've tried to draw text form here with commands: ###################### [system 1]------#--[eth0]---- # # |-- [hub0]------[vlan2] # [system 2]------#--[eth2]---- | # # | # # [eth1] # #################|##### | netgraph commands are: ncgtl mkpeer eth0: hub lower lower0 ngctl name eth0:lower hub0 ngctl connect eth2: hub0: lower lower2 ngct mkpeer hub0: vlan vlan2 vlan2 ngctl name hub0:vlan2 vlan2 ngct connect vlan2: eth1: downstream lower ngctl msg vlan2: addfilter '{vlan=2 hook="vlan2"}' ifconfig commands: ifconfig bridge0 create ifconfig bridge0 addm eth0 addm eth2 On 3/5/12, h bagade wrote: > I've tried netgraph nodes too! but stuck on the next step and asked > the problem on this forum and received no answer:( my netgraph > scenario is described below: > > I have designed a topology(attached) using netgraph to add vlan2 > tag to the frames coming from eth0(vlan port) and send it to > eth1(trunk port) to go out of the box. it works fine. > > Then I tried to add another interface like eth0 which named eth2(vlan > port) to be > tagged vlan2 too. After that, I bridged eth0 and eth2 using > ifconfig(as vlan ports are connected to each other on same vlan id). > When traffic comes from eth0(system1) to the destination > eth2(system2), all traffic also sent out eth1 which is not suitable! > > In the mentioned scenario, I don't want the traffic pass to the eth1. Is > there any way that eth1 recognize which mac addresses don't belong to this > box then sends the traffic out? I mean I want to send taraffic out of eth1 > when the destination is not accessible via FreeBSD box so it should be sent > out to be find out. > > On 3/4/12, rozhuk.im@gmail.com wrote: >> >> Use netgraph nodes. >> >> >>> -----Original Message----- >>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>> net@freebsd.org] On Behalf Of h bagade >>> Sent: Sunday, March 04, 2012 3:31 PM >>> To: freebsd-net >>> Subject: problem with vlan interfaces tagging/untagging in a simulated >>> switch box >>> >>> Hi all, >>> >>> I have problems with vlan interfaces on freebsd. I want to make my >>> system like a switch with vlan ports and also a trunk port in >>> conjuction with other switches. I thought that vlan interfaces would >>> help me tagging traffic when traffic is going out the trunk port(or >>> when it receives on vlan ports). >>> The problem, I've encountered is that vlan interafaces on freebsd do >>> tagging/untagging when the traffic is sourced/destined from/to them >>> which in this case they should be assigned IP addresses. In other words >>> they won't tag the traffic passing through their parent interface which >>> I need to. >>> >>> In my case to be acting like a switch, interfaces on system won't have >>> ip addresses and I need to tag the traffic coming from for example >>> interface1 when passing through interfaceN(acting as trunk port). >>> How could I reach this? would it be possible to use vlan interfaces to >>> do so? >>> >>> I've tried many many ways to simulate the case but no success achieved! >>> I'm really interested to find the proper solution for my config. >>> >>> Any comments or hints are really apperciated. >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> > From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 05:46:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70F25106566B for ; Mon, 5 Mar 2012 05:46:18 +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 3FCA28FC14 for ; Mon, 5 Mar 2012 05:46:18 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q255kFaC035112 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 4 Mar 2012 21:46:17 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F545332.7060305@freebsd.org> Date: Sun, 04 Mar 2012 21:46:26 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: hiren panchasara References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Fwd: bridge interface type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 05:46:18 -0000 On 3/4/12 1:36 PM, hiren panchasara wrote: > Is this the correct mailer for such questions? probably net@freebsd.org would be better. I do not understand why a bridge needs an interface type at all it seems a very odd way to implement it to me.. see how ng_bridge is done.. that makes a lot more sense to me. > ---------- Forwarded message ---------- > From: hiren panchasara > Date: Sat, Mar 3, 2012 at 12:47 AM > Subject: bridge interface type > To: freebsd-hackers@freebsd.org > > > > I created bridge1 this way: > > $ sudo ifconfig bridge create > Password: > bridge1 > > $ ifconfig bridge1 > bridge1: flags=8802 metric 0 mtu 1500 > ether 02:32:c8:92:b6:01 > nd6 options=29 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 > > but when I try to look at the interface via "struct sockaddr_dl", > sdl = (struct sockaddr_dl *) ifa->ifa_addr; > > sdl->sdl_type is "IFT_ETHER" for that interface. > > Shouldn't it be "IFT_BRIDGE"? What am I missing here? > > Thanks in advance, > Hiren > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 07:26:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA79E106566C for ; Mon, 5 Mar 2012 07:26:34 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4638FC18 for ; Mon, 5 Mar 2012 07:26:34 +0000 (UTC) Received: by iahk25 with SMTP id k25so7050265iah.13 for ; Sun, 04 Mar 2012 23:26:34 -0800 (PST) Received-SPF: pass (google.com: domain of andy@fud.org.nz designates 10.42.168.197 as permitted sender) client-ip=10.42.168.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andy@fud.org.nz designates 10.42.168.197 as permitted sender) smtp.mail=andy@fud.org.nz Received: from mr.google.com ([10.42.168.197]) by 10.42.168.197 with SMTP id x5mr12662901icy.6.1330932394135 (num_hops = 1); Sun, 04 Mar 2012 23:26:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.168.197 with SMTP id x5mr10430607icy.6.1330932032092; Sun, 04 Mar 2012 23:20:32 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.231.28.225 with HTTP; Sun, 4 Mar 2012 23:20:31 -0800 (PST) In-Reply-To: <4F545332.7060305@freebsd.org> References: <4F545332.7060305@freebsd.org> Date: Mon, 5 Mar 2012 20:20:31 +1300 X-Google-Sender-Auth: hvttLyGzezQatIgfNymDxwwvLJQ Message-ID: From: Andrew Thompson To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlANYmR0zGOWSgbIYNHZ8OSr8lOTLFXh98vJ1wxhkXrPHOd8NOm/iAZaV+JRUMw8W2k8wsF Cc: freebsd-net@freebsd.org, hiren panchasara Subject: Re: Fwd: bridge interface type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 07:26:34 -0000 On 5 March 2012 18:46, Julian Elischer wrote: > On 3/4/12 1:36 PM, hiren panchasara wrote: >> >> Is this the correct mailer for such questions? > > > probably net@freebsd.org would be better. > > I do not understand why a bridge needs an interface type at all > it seems a very odd way to implement it to me.. =A0see how ng_bridge is d= one.. > that makes a lot more sense to me. The bridge interface type is used in a few places of the network code. (eg in_arpinput(), in6_ifattach()). It is needed. Andrew From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 07:38:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 605C5106566B for ; Mon, 5 Mar 2012 07:38:01 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 291078FC12 for ; Mon, 5 Mar 2012 07:38:00 +0000 (UTC) Received: by iahk25 with SMTP id k25so7063835iah.13 for ; Sun, 04 Mar 2012 23:38:00 -0800 (PST) Received-SPF: pass (google.com: domain of andy@fud.org.nz designates 10.50.34.164 as permitted sender) client-ip=10.50.34.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andy@fud.org.nz designates 10.50.34.164 as permitted sender) smtp.mail=andy@fud.org.nz Received: from mr.google.com ([10.50.34.164]) by 10.50.34.164 with SMTP id a4mr5869898igj.14.1330933080707 (num_hops = 1); Sun, 04 Mar 2012 23:38:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.34.164 with SMTP id a4mr4833630igj.14.1330931662336; Sun, 04 Mar 2012 23:14:22 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.231.28.225 with HTTP; Sun, 4 Mar 2012 23:14:22 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Mar 2012 20:14:22 +1300 X-Google-Sender-Auth: 8wqdXqO8OcJrtT8sRGahvsS-UoQ Message-ID: From: Andrew Thompson To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmJhGdH0i4i2psyVonp6N1Mh5Vu5xYoKLqT4JQbtIItJAGu1iKu20gy/AMNEO+AP5HUUk3K Cc: freebsd-net@freebsd.org Subject: Re: bridge interface type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 07:38:01 -0000 > From: hiren panchasara > > I created bridge1 this way: > > $ sudo ifconfig bridge create > Password: > bridge1 > > $ ifconfig bridge1 > bridge1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0ether 02:32:c8:92:b6:01 > =A0 =A0nd6 options=3D29 > =A0 =A0id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > =A0 =A0maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > =A0 =A0root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 > > but when I try to look at the interface via "struct sockaddr_dl", > sdl =3D (struct sockaddr_dl *) ifa->ifa_addr; > > sdl->sdl_type is "IFT_ETHER" for that interface. > > Shouldn't it be "IFT_BRIDGE"? What am I missing here? The address type is set in ether_ifattach() and the bridge does not overwrite it, this means sdl_type will always be IFT_ETHER (see if_ethersubr.c line 1003). Here is a patch that changes it but I do not know what may break. Index: if_bridge.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_bridge.c (revision 232321) +++ if_bridge.c (working copy) @@ -568,6 +568,7 @@ bridge_clone_create(struct if_clone *ifc, int unit { struct bridge_softc *sc, *sc2; struct ifnet *bifp, *ifp; + struct sockaddr_dl *sdl; int fb, retry; unsigned long hostid; @@ -642,6 +643,8 @@ bridge_clone_create(struct if_clone *ifc, int unit /* Now undo some of the damage... */ ifp->if_baudrate =3D 0; ifp->if_type =3D IFT_BRIDGE; + sdl =3D (struct sockaddr_dl *)ifp->if_addr->ifa_addr; + sdl->sdl_type =3D IFT_BRIDGE; mtx_lock(&bridge_list_mtx); LIST_INSERT_HEAD(&bridge_list, sc, sc_list); From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 10:00:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 537AF1065675 for ; Mon, 5 Mar 2012 10:00:45 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC3488FC2B for ; Mon, 5 Mar 2012 10:00:43 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3992275bkc.13 for ; Mon, 05 Mar 2012 02:00:36 -0800 (PST) Received-SPF: pass (google.com: domain of bagadeh@gmail.com designates 10.204.129.8 as permitted sender) client-ip=10.204.129.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bagadeh@gmail.com designates 10.204.129.8 as permitted sender) smtp.mail=bagadeh@gmail.com; dkim=pass header.i=bagadeh@gmail.com Received: from mr.google.com ([10.204.129.8]) by 10.204.129.8 with SMTP id m8mr9908560bks.69.1330941636705 (num_hops = 1); Mon, 05 Mar 2012 02:00:36 -0800 (PST) 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=cdNjvJ0Hpv+E7Ytc89qVDpJF0TtZX6PoobRyQgXynvk=; b=q+3TXXkPXmsYenZ1BY2LUdgbR+8AP6QWe2CBhkjmYn7iKEwbXP/HsmqYvqtxy/9xeE JLr+rSVCExDV5ZHMT8h6bw6C7zq2C2FbLHnf0SC2JJ/Opud+7oEk30dhUgmlazCw9G7f aMcLSF2AImkcr9zWTKCkqzdkggu8Cu7XvEspqzDKjVzzn3v0eunRsOf4WIs7BsRPmq1o 40v9WreZc0Sl/mvoPM+PGCVxS8uZ8jPQPQj7is1EdRNnt5mfAdGjF4pMxBPPe3LkhJxt 7Hmvfm/Q8RB+r/0By7dYpUQaAxgJB1NqAcbbsotd+kfWulhLiLsEYtEVeR2ax3NDkTOV aPZw== MIME-Version: 1.0 Received: by 10.204.129.8 with SMTP id m8mr7845597bks.69.1330941636600; Mon, 05 Mar 2012 02:00:36 -0800 (PST) Received: by 10.204.167.139 with HTTP; Mon, 5 Mar 2012 02:00:36 -0800 (PST) In-Reply-To: <20120305084359.GA56606@server.vk2pj.dyndns.org> References: <20120305084359.GA56606@server.vk2pj.dyndns.org> Date: Mon, 5 Mar 2012 13:30:36 +0330 Message-ID: From: h bagade To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 10:00:45 -0000 on layer 2 switch, ports doesn't have ip addresses and traffic comming from a vlan port is tagged and pass through trunk port. this means that in our freebsd box which plays the role of switch, no interfaces should have ip addresses. In your topology the em0 which plays the role of trunk port has ip address and also vlan interfaces under its support. if we assume that em0 is the trunk port of our switch, and em1 the port assigned to vlan 2, which doesn't have any ip address too; then all traffic comes from em1 should be labled vlan 2 tag and send out the em0. I want to achieve this. besides if anoth On 3/5/12, Peter Jeremy wrote: > On 2012-Mar-04 10:01:07 +0330, h bagade wrote: >>I have problems with vlan interfaces on freebsd. I want to make my >>system like a switch with vlan ports and also a trunk port in >>conjuction with other switches. I thought that vlan interfaces would >>help me tagging traffic when traffic is going out the trunk port(or >>when it receives on vlan ports). >>The problem, I've encountered is that vlan interafaces on freebsd do >>tagging/untagging when the traffic is sourced/destined from/to them >>which in this case they should be assigned IP addresses. In other >>words they won't tag the traffic passing through their parent >>interface which I need to. > > I am doing this with no problems so I suspect you are doing something > wrong. As an example, the following creates a IEEE802.1Q trunk on > em0 with 192.168.1.0/24 untagged and the remaining subnett tagged: > > ifconfig em0 inet 192.168.1.123/24 > ifconfig vlan10 inet 192.168.10.123/24 vlandev em0 vlan 10 > ifconfig vlan11 inet 192.168.11.123/24 vlandev em0 vlan 11 > ifconfig vlan12 inet 192.168.12.123/24 vlandev em0 vlan 12 > ifconfig vlan13 inet 192.168.13.123/24 vlandev em0 vlan 13 > > Can you post the rc.conf etc entries that you are using and a > description of what you are trying to achieve. > > -- > Peter Jeremy > From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 11:07:13 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E641065676 for ; Mon, 5 Mar 2012 11:07:13 +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 D4D618FC1D for ; Mon, 5 Mar 2012 11:07:13 +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 q25B7D3U034951 for ; Mon, 5 Mar 2012 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q25B7CjX034948 for freebsd-net@FreeBSD.org; Mon, 5 Mar 2012 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Mar 2012 11:07:12 GMT Message-Id: <201203051107.q25B7CjX034948@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:07:14 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub 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 bin/165413 net [netgraph]: ngctl(8) does not work as advertised 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/164569 net [msk] [hang] msk network driver cause freeze in FreeBS 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/164400 net [ipsec] immediate crash after the start of ipsec proce 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/162509 net [re] [panic] Kernel panic may be related to if_re.c (r 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/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/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/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/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 o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o 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 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/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/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 s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 392 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 11:30:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CECD11065677 for ; Mon, 5 Mar 2012 11:30:36 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4BEEB8FC19 for ; Mon, 5 Mar 2012 11:30:36 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q258i9Gl006543 for ; Mon, 5 Mar 2012 19:44:09 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q258i05l006049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 19:44:01 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q258hxaw056694; Mon, 5 Mar 2012 19:43:59 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q258hx5j056693; Mon, 5 Mar 2012 19:43:59 +1100 (EST) (envelope-from peter) Date: Mon, 5 Mar 2012 19:43:59 +1100 From: Peter Jeremy To: h bagade Message-ID: <20120305084359.GA56606@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:30:36 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Mar-04 10:01:07 +0330, h bagade wrote: >I have problems with vlan interfaces on freebsd. I want to make my >system like a switch with vlan ports and also a trunk port in >conjuction with other switches. I thought that vlan interfaces would >help me tagging traffic when traffic is going out the trunk port(or >when it receives on vlan ports). >The problem, I've encountered is that vlan interafaces on freebsd do >tagging/untagging when the traffic is sourced/destined from/to them >which in this case they should be assigned IP addresses. In other >words they won't tag the traffic passing through their parent >interface which I need to. I am doing this with no problems so I suspect you are doing something wrong. As an example, the following creates a IEEE802.1Q trunk on em0 with 192.168.1.0/24 untagged and the remaining subnett tagged: ifconfig em0 inet 192.168.1.123/24 ifconfig vlan10 inet 192.168.10.123/24 vlandev em0 vlan 10 ifconfig vlan11 inet 192.168.11.123/24 vlandev em0 vlan 11 ifconfig vlan12 inet 192.168.12.123/24 vlandev em0 vlan 12 ifconfig vlan13 inet 192.168.13.123/24 vlandev em0 vlan 13 Can you post the rc.conf etc entries that you are using and a description of what you are trying to achieve. --=20 Peter Jeremy --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9UfM8ACgkQ/opHv/APuIdWlQCfRbDLOPmXVLrOXZ3OogtT8x2Q 4GwAnRdgo1CLRYDzReCORWCwOwJZi2Cd =RLYN -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 17:58:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F2C6106566B for ; Mon, 5 Mar 2012 17:58:44 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CF0B08FC12 for ; Mon, 5 Mar 2012 17:58:43 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so4631565bkc.13 for ; Mon, 05 Mar 2012 09:58:42 -0800 (PST) Received-SPF: pass (google.com: domain of hiren.panchasara@gmail.com designates 10.205.127.130 as permitted sender) client-ip=10.205.127.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hiren.panchasara@gmail.com designates 10.205.127.130 as permitted sender) smtp.mail=hiren.panchasara@gmail.com; dkim=pass header.i=hiren.panchasara@gmail.com Received: from mr.google.com ([10.205.127.130]) by 10.205.127.130 with SMTP id ha2mr11355618bkc.28.1330970322616 (num_hops = 1); Mon, 05 Mar 2012 09:58:42 -0800 (PST) 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=da3LbADkVGD9nZaWiQ1f8tYXZUnDVzUzQnxf2/J4css=; b=jpr3PXSinNUddEG6o7JqWYoBh8XQpkNSOvhmAk5BzV0knpazDmED7L/MLyIjFiStQA IgHEIFfJ+B+K/aoNHscoQ5sUz5okW0KbRnUXR0yO5/PHsYayQCDdW2cCh7yxKAt/P+6z 7wK6S3NKa6djS9y61fAUYF4YQ3knKwVtPpaz26r52Gw5BCgQRD0436QzIIOAqfhuGX2/ lcfgowzhBjtR0RX96sp9i3pYejqx89fq3gu/21crEjcmaw2l+F7XvMY04cb92Tis7rTR /HQU8LK531AnR+u9ghk7kr0B6iJ/sh6fZzSYuyc84GCPeBfkwc7UpP2lySNNJ3PXYjpF /tMA== MIME-Version: 1.0 Received: by 10.205.127.130 with SMTP id ha2mr9013486bkc.28.1330970322518; Mon, 05 Mar 2012 09:58:42 -0800 (PST) Received: by 10.204.230.5 with HTTP; Mon, 5 Mar 2012 09:58:42 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Mar 2012 09:58:42 -0800 Message-ID: From: hiren panchasara To: Andrew Thompson Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: bridge interface type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:58:44 -0000 On Sun, Mar 4, 2012 at 11:14 PM, Andrew Thompson wrote: > Here is a patch that changes it but I do not know what may break. > Thanks a lot Andrew. So, someone might be relying on interface type of bridge being IFT_ETHER? Who can confirm if this is a good patch? > > Index: if_bridge.c > =================================================================== > --- if_bridge.c (revision 232321) > +++ if_bridge.c (working copy) > @@ -568,6 +568,7 @@ bridge_clone_create(struct if_clone *ifc, int unit > { > struct bridge_softc *sc, *sc2; > struct ifnet *bifp, *ifp; > + struct sockaddr_dl *sdl; > int fb, retry; > unsigned long hostid; > > @@ -642,6 +643,8 @@ bridge_clone_create(struct if_clone *ifc, int unit > /* Now undo some of the damage... */ > ifp->if_baudrate = 0; > ifp->if_type = IFT_BRIDGE; > + sdl = (struct sockaddr_dl *)ifp->if_addr->ifa_addr; > + sdl->sdl_type = IFT_BRIDGE; > > mtx_lock(&bridge_list_mtx); > LIST_INSERT_HEAD(&bridge_list, sc, sc_list); > Appreciate your help, Hiren From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 18:26:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E25EC106566C for ; Mon, 5 Mar 2012 18:26:44 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D5D28FC17 for ; Mon, 5 Mar 2012 18:26:43 +0000 (UTC) Received: by qcsg15 with SMTP id g15so2409363qcs.13 for ; Mon, 05 Mar 2012 10:26:43 -0800 (PST) Received-SPF: pass (google.com: domain of ozkan.kirik@gmail.com designates 10.229.135.19 as permitted sender) client-ip=10.229.135.19; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ozkan.kirik@gmail.com designates 10.229.135.19 as permitted sender) smtp.mail=ozkan.kirik@gmail.com; dkim=pass header.i=ozkan.kirik@gmail.com Received: from mr.google.com ([10.229.135.19]) by 10.229.135.19 with SMTP id l19mr1411297qct.65.1330972003585 (num_hops = 1); Mon, 05 Mar 2012 10:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=78KtEvWfwGoYrn1/GhtTperF6ZsKJmuKK1OXA4bWd6A=; b=cUSJgt6tfT7Bmn7TP/a/XC1nYLMulpf52lesSEa81SxH3fT/JIRYo3RHFJRzL0OLSu VRJgxIKdSLxNELslN6IzjE3c8nRnM7G4jhl0yv7QNb0Tz4rZFKSuKVrDkMU/aM36NLYK 9idriwSehdwKzxqr8jbvdpVeM/atqAqCwHm1eqxZQvt+K4HkoSeKiRssmoE1WQEdag9l FLYtGnmVxdWEw9slG/Ylv4UY42RSSMMllWuATmesOgX5ioRN3dOq/5RuhwkeigeShs0U kaZqvd5PduB82mHhTVkv2xMt8OBSxbcIpmBsD0n5/x6wTO+PMrw0FwJpWzBRZnaTj2ym yrSg== MIME-Version: 1.0 Received: by 10.229.135.19 with SMTP id l19mr1214521qct.65.1330970351772; Mon, 05 Mar 2012 09:59:11 -0800 (PST) Received: by 10.229.6.2 with HTTP; Mon, 5 Mar 2012 09:59:11 -0800 (PST) Date: Mon, 5 Mar 2012 19:59:11 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: net@freebsd.org, Jack Vogel Content-Type: multipart/mixed; boundary=00248c7680720623d704ba82af2f X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: igbX: could not setup receive structures X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:26:45 -0000 --00248c7680720623d704ba82af2f Content-Type: text/plain; charset=ISO-8859-1 Hi, I am using FreeBSD 8.2-STABLE-201105 amd64 snapshot. System has about 200 ipfw rules. There is 78 vlans assigned on igb3. igb3 interface asserts as "igb3: Could not setup receive structures" once a day and then nic stops working. Even ifconfig down && ifconfig up doesnt help. What the problem can be ? Thanks --------------------------- igb3: flags=8943 metric 0 mtu 1500 options=1bb ether 00:1e:67:06:c5:45 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active ---------------------------- pciconf -lv: igb0@pci0:3:0:0: class=0x020000 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:3:0:1: class=0x020000 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb2@pci0:6:0:0: class=0x020000 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb3@pci0:6:0:1: class=0x020000 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet ------------------------------ #sysctl dev.igb.3. dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 dev.igb.3.%driver: igb dev.igb.3.%location: slot=0 function=1 handle=\_SB_.PCI0.MRP1.GRP1.G2P2.G2K4 dev.igb.3.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0x34f2 class=0x020000 dev.igb.3.%parent: pci6 dev.igb.3.nvm: -1 dev.igb.3.enable_aim: 1 dev.igb.3.flow_control: 3 dev.igb.3.rx_processing_limit: 100 dev.igb.3.link_irq: 26 dev.igb.3.dropped: 0 dev.igb.3.tx_dma_fail: 0 dev.igb.3.rx_overruns: 0 dev.igb.3.watchdog_timeouts: 0 dev.igb.3.device_control: 1490027073 dev.igb.3.rx_control: 67141658 dev.igb.3.interrupt_mask: 4 dev.igb.3.extended_int_mask: 2147484159 dev.igb.3.tx_buf_alloc: 0 dev.igb.3.rx_buf_alloc: 0 dev.igb.3.fc_high_water: 58976 dev.igb.3.fc_low_water: 58960 dev.igb.3.queue0.interrupt_rate: 125000 dev.igb.3.queue0.txd_head: 20 dev.igb.3.queue0.txd_tail: 20 dev.igb.3.queue0.no_desc_avail: 0 dev.igb.3.queue0.tx_packets: 1136 dev.igb.3.queue0.rxd_head: 0 dev.igb.3.queue0.rxd_tail: 1023 dev.igb.3.queue0.rx_packets: 0 dev.igb.3.queue0.rx_bytes: 0 dev.igb.3.queue0.lro_queued: 0 dev.igb.3.queue0.lro_flushed: 0 dev.igb.3.queue1.interrupt_rate: 8000 dev.igb.3.queue1.txd_head: 0 dev.igb.3.queue1.txd_tail: 0 dev.igb.3.queue1.no_desc_avail: 0 dev.igb.3.queue1.tx_packets: 0 dev.igb.3.queue1.rxd_head: 0 dev.igb.3.queue1.rxd_tail: 1023 dev.igb.3.queue1.rx_packets: 0 dev.igb.3.queue1.rx_bytes: 0 dev.igb.3.queue1.lro_queued: 0 dev.igb.3.queue1.lro_flushed: 0 dev.igb.3.queue2.interrupt_rate: 8000 dev.igb.3.queue2.txd_head: 0 dev.igb.3.queue2.txd_tail: 0 dev.igb.3.queue2.no_desc_avail: 0 dev.igb.3.queue2.tx_packets: 0 dev.igb.3.queue2.rxd_head: 0 dev.igb.3.queue2.rxd_tail: 1023 dev.igb.3.queue2.rx_packets: 0 dev.igb.3.queue2.rx_bytes: 0 dev.igb.3.queue2.lro_queued: 0 dev.igb.3.queue2.lro_flushed: 0 dev.igb.3.queue3.interrupt_rate: 8000 dev.igb.3.queue3.txd_head: 0 dev.igb.3.queue3.txd_tail: 0 dev.igb.3.queue3.no_desc_avail: 0 dev.igb.3.queue3.tx_packets: 0 dev.igb.3.queue3.rxd_head: 0 dev.igb.3.queue3.rxd_tail: 1023 dev.igb.3.queue3.rx_packets: 0 dev.igb.3.queue3.rx_bytes: 0 dev.igb.3.queue3.lro_queued: 0 dev.igb.3.queue3.lro_flushed: 0 dev.igb.3.queue4.interrupt_rate: 8000 dev.igb.3.queue4.txd_head: 0 dev.igb.3.queue4.txd_tail: 0 dev.igb.3.queue4.no_desc_avail: 0 dev.igb.3.queue4.tx_packets: 0 dev.igb.3.queue4.rxd_head: 0 dev.igb.3.queue4.rxd_tail: 1023 dev.igb.3.queue4.rx_packets: 0 dev.igb.3.queue4.rx_bytes: 0 dev.igb.3.queue4.lro_queued: 0 dev.igb.3.queue4.lro_flushed: 0 dev.igb.3.queue5.interrupt_rate: 8000 dev.igb.3.queue5.txd_head: 0 dev.igb.3.queue5.txd_tail: 0 dev.igb.3.queue5.no_desc_avail: 0 dev.igb.3.queue5.tx_packets: 0 dev.igb.3.queue5.rxd_head: 0 dev.igb.3.queue5.rxd_tail: 1023 dev.igb.3.queue5.rx_packets: 0 dev.igb.3.queue5.rx_bytes: 0 dev.igb.3.queue5.lro_queued: 0 dev.igb.3.queue5.lro_flushed: 0 dev.igb.3.queue6.interrupt_rate: 8000 dev.igb.3.queue6.txd_head: 0 dev.igb.3.queue6.txd_tail: 0 dev.igb.3.queue6.no_desc_avail: 0 dev.igb.3.queue6.tx_packets: 0 dev.igb.3.queue6.rxd_head: 0 dev.igb.3.queue6.rxd_tail: 1023 dev.igb.3.queue6.rx_packets: 0 dev.igb.3.queue6.rx_bytes: 0 dev.igb.3.queue6.lro_queued: 0 dev.igb.3.queue6.lro_flushed: 0 dev.igb.3.queue7.interrupt_rate: 8000 dev.igb.3.queue7.txd_head: 0 dev.igb.3.queue7.txd_tail: 0 dev.igb.3.queue7.no_desc_avail: 0 dev.igb.3.queue7.tx_packets: 0 dev.igb.3.queue7.rxd_head: 0 dev.igb.3.queue7.rxd_tail: 1023 dev.igb.3.queue7.rx_packets: 0 dev.igb.3.queue7.rx_bytes: 0 dev.igb.3.queue7.lro_queued: 0 dev.igb.3.queue7.lro_flushed: 0 dev.igb.3.mac_stats.excess_coll: 0 dev.igb.3.mac_stats.single_coll: 0 dev.igb.3.mac_stats.multiple_coll: 0 dev.igb.3.mac_stats.late_coll: 0 dev.igb.3.mac_stats.collision_count: 0 dev.igb.3.mac_stats.symbol_errors: 0 dev.igb.3.mac_stats.sequence_errors: 0 dev.igb.3.mac_stats.defer_count: 0 dev.igb.3.mac_stats.missed_packets: 0 dev.igb.3.mac_stats.recv_no_buff: 0 dev.igb.3.mac_stats.recv_undersize: 0 dev.igb.3.mac_stats.recv_fragmented: 0 dev.igb.3.mac_stats.recv_oversize: 0 dev.igb.3.mac_stats.recv_jabber: 0 dev.igb.3.mac_stats.recv_errs: 0 dev.igb.3.mac_stats.crc_errs: 0 dev.igb.3.mac_stats.alignment_errs: 0 dev.igb.3.mac_stats.coll_ext_errs: 0 dev.igb.3.mac_stats.xon_recvd: 0 dev.igb.3.mac_stats.xon_txd: 0 dev.igb.3.mac_stats.xoff_recvd: 0 dev.igb.3.mac_stats.xoff_txd: 0 dev.igb.3.mac_stats.total_pkts_recvd: 0 dev.igb.3.mac_stats.good_pkts_recvd: 0 dev.igb.3.mac_stats.bcast_pkts_recvd: 0 dev.igb.3.mac_stats.mcast_pkts_recvd: 0 dev.igb.3.mac_stats.rx_frames_64: 0 dev.igb.3.mac_stats.rx_frames_65_127: 0 dev.igb.3.mac_stats.rx_frames_128_255: 0 dev.igb.3.mac_stats.rx_frames_256_511: 0 dev.igb.3.mac_stats.rx_frames_512_1023: 0 dev.igb.3.mac_stats.rx_frames_1024_1522: 0 dev.igb.3.mac_stats.good_octets_recvd: 0 dev.igb.3.mac_stats.good_octets_txd: 72064 dev.igb.3.mac_stats.total_pkts_txd: 1126 dev.igb.3.mac_stats.good_pkts_txd: 1126 dev.igb.3.mac_stats.bcast_pkts_txd: 1126 dev.igb.3.mac_stats.mcast_pkts_txd: 0 dev.igb.3.mac_stats.tx_frames_64: 1126 dev.igb.3.mac_stats.tx_frames_65_127: 0 dev.igb.3.mac_stats.tx_frames_128_255: 0 dev.igb.3.mac_stats.tx_frames_256_511: 0 dev.igb.3.mac_stats.tx_frames_512_1023: 0 dev.igb.3.mac_stats.tx_frames_1024_1522: 0 dev.igb.3.mac_stats.tso_txd: 0 dev.igb.3.mac_stats.tso_ctx_fail: 0 dev.igb.3.interrupts.asserts: 1245 dev.igb.3.interrupts.rx_pkt_timer: 0 dev.igb.3.interrupts.rx_abs_timer: 0 dev.igb.3.interrupts.tx_pkt_timer: 0 dev.igb.3.interrupts.tx_abs_timer: 0 dev.igb.3.interrupts.tx_queue_empty: 1126 dev.igb.3.interrupts.tx_queue_min_thresh: 0 dev.igb.3.interrupts.rx_desc_min_thresh: 0 dev.igb.3.interrupts.rx_overrun: 0 dev.igb.3.host.breaker_tx_pkt: 0 dev.igb.3.host.host_tx_pkt_discard: 0 dev.igb.3.host.rx_pkt: 0 dev.igb.3.host.breaker_rx_pkts: 0 dev.igb.3.host.breaker_rx_pkt_drop: 0 dev.igb.3.host.tx_good_pkt: 0 dev.igb.3.host.breaker_tx_pkt_drop: 0 dev.igb.3.host.rx_good_bytes: 0 dev.igb.3.host.tx_good_bytes: 72064 dev.igb.3.host.length_errors: 0 dev.igb.3.host.serdes_violation_pkt: 0 dev.igb.3.host.header_redir_missed: 0 --00248c7680720623d704ba82af2f-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 18:35:59 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FCB2106566B for ; Mon, 5 Mar 2012 18:35:59 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA5B8FC12 for ; Mon, 5 Mar 2012 18:35:58 +0000 (UTC) Received: by qcsg15 with SMTP id g15so2418207qcs.13 for ; Mon, 05 Mar 2012 10:35:58 -0800 (PST) Received-SPF: pass (google.com: domain of ozkan.kirik@gmail.com designates 10.229.135.141 as permitted sender) client-ip=10.229.135.141; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ozkan.kirik@gmail.com designates 10.229.135.141 as permitted sender) smtp.mail=ozkan.kirik@gmail.com; dkim=pass header.i=ozkan.kirik@gmail.com Received: from mr.google.com ([10.229.135.141]) by 10.229.135.141 with SMTP id n13mr2622883qct.25.1330972558508 (num_hops = 1); Mon, 05 Mar 2012 10:35:58 -0800 (PST) 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:content-transfer-encoding; bh=zsYCQ7dyF5WS9Zr+r145mkUrsR0oz1L8GfT7JEu6htA=; b=av3tXtXC5AifflGCu1oD8Dq/s2vPDVLtvaF5tmyxVwHIbgasV4iyD2TP6K9pQjq3X1 uoHZ7P7kW0UV3N1heySws1EzNzs5XVHMAAY/ErjaML4ku24GoYcOn+5l9qeGsGJenwFb BpKWViOmLowThsKoXV020/FX8hsceOgHLIczCQG4+AehU/CzpjjghiRLSoItAhhRNesD gtk4ngbMl4xYsxJBQgvggpE85oCIvwrg/ZfIBcM/6KpgrXgyboUSWVcaRX+g0IbQZOaP fa/o4NZUWh1KMM0upfmriqu5Ic4VOXHvBnAXjFudLlHNvT/xCUPQF69FPQuT0XH4tkZ9 xnEQ== MIME-Version: 1.0 Received: by 10.229.135.141 with SMTP id n13mr2246039qct.25.1330972558127; Mon, 05 Mar 2012 10:35:58 -0800 (PST) Received: by 10.229.6.2 with HTTP; Mon, 5 Mar 2012 10:35:58 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Mar 2012 20:35:58 +0200 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: igbX: could not setup receive structures X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:35:59 -0000 thank you On Mon, Mar 5, 2012 at 8:28 PM, Jack Vogel wrote: > Increase the number of nmbclusters via sysctl, internally we set it to > 262144. > > Jack > > > > 2012/3/5 =D6zkan KIRIK >> >> Hi, >> >> I am using FreeBSD =A08.2-STABLE-201105 amd64 snapshot. >> System has about 200 ipfw rules. >> There is 78 vlans assigned on igb3. >> >> igb3 interface asserts as "igb3: Could not setup receive structures" >> once a day and then nic stops working. >> Even ifconfig down && ifconfig up doesnt help. >> >> What the problem can be ? >> Thanks >> >> >> --------------------------- >> igb3: flags=3D8943 >> metric 0 mtu 1500 >> >> =A0options=3D1bb >> =A0 =A0 =A0 =A0ether 00:1e:67:06:c5:45 >> =A0 =A0 =A0 =A0inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.2= 55 >> =A0 =A0 =A0 =A0media: Ethernet autoselect (1000baseT ) >> =A0 =A0 =A0 =A0status: active >> >> ---------------------------- >> >> pciconf -lv: >> >> igb0@pci0:3:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x34f28086 chip= =3D0x10c98086 >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> igb1@pci0:3:0:1: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x34f28086 chip= =3D0x10c98086 >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> igb2@pci0:6:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x34f28086 chip= =3D0x10c98086 >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> igb3@pci0:6:0:1: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x34f28086 chip= =3D0x10c98086 >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> >> >> ------------------------------ >> >> #sysctl dev.igb.3. >> dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 >> dev.igb.3.%driver: igb >> dev.igb.3.%location: slot=3D0 function=3D1 >> handle=3D\_SB_.PCI0.MRP1.GRP1.G2P2.G2K4 >> dev.igb.3.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8086 >> subdevice=3D0x34f2 class=3D0x020000 >> dev.igb.3.%parent: pci6 >> dev.igb.3.nvm: -1 >> dev.igb.3.enable_aim: 1 >> dev.igb.3.flow_control: 3 >> dev.igb.3.rx_processing_limit: 100 >> dev.igb.3.link_irq: 26 >> dev.igb.3.dropped: 0 >> dev.igb.3.tx_dma_fail: 0 >> dev.igb.3.rx_overruns: 0 >> dev.igb.3.watchdog_timeouts: 0 >> dev.igb.3.device_control: 1490027073 >> dev.igb.3.rx_control: 67141658 >> dev.igb.3.interrupt_mask: 4 >> dev.igb.3.extended_int_mask: 2147484159 >> dev.igb.3.tx_buf_alloc: 0 >> dev.igb.3.rx_buf_alloc: 0 >> dev.igb.3.fc_high_water: 58976 >> dev.igb.3.fc_low_water: 58960 >> dev.igb.3.queue0.interrupt_rate: 125000 >> dev.igb.3.queue0.txd_head: 20 >> dev.igb.3.queue0.txd_tail: 20 >> dev.igb.3.queue0.no_desc_avail: 0 >> dev.igb.3.queue0.tx_packets: 1136 >> dev.igb.3.queue0.rxd_head: 0 >> dev.igb.3.queue0.rxd_tail: 1023 >> dev.igb.3.queue0.rx_packets: 0 >> dev.igb.3.queue0.rx_bytes: 0 >> dev.igb.3.queue0.lro_queued: 0 >> dev.igb.3.queue0.lro_flushed: 0 >> dev.igb.3.queue1.interrupt_rate: 8000 >> dev.igb.3.queue1.txd_head: 0 >> dev.igb.3.queue1.txd_tail: 0 >> dev.igb.3.queue1.no_desc_avail: 0 >> dev.igb.3.queue1.tx_packets: 0 >> dev.igb.3.queue1.rxd_head: 0 >> dev.igb.3.queue1.rxd_tail: 1023 >> dev.igb.3.queue1.rx_packets: 0 >> dev.igb.3.queue1.rx_bytes: 0 >> dev.igb.3.queue1.lro_queued: 0 >> dev.igb.3.queue1.lro_flushed: 0 >> dev.igb.3.queue2.interrupt_rate: 8000 >> dev.igb.3.queue2.txd_head: 0 >> dev.igb.3.queue2.txd_tail: 0 >> dev.igb.3.queue2.no_desc_avail: 0 >> dev.igb.3.queue2.tx_packets: 0 >> dev.igb.3.queue2.rxd_head: 0 >> dev.igb.3.queue2.rxd_tail: 1023 >> dev.igb.3.queue2.rx_packets: 0 >> dev.igb.3.queue2.rx_bytes: 0 >> dev.igb.3.queue2.lro_queued: 0 >> dev.igb.3.queue2.lro_flushed: 0 >> dev.igb.3.queue3.interrupt_rate: 8000 >> dev.igb.3.queue3.txd_head: 0 >> dev.igb.3.queue3.txd_tail: 0 >> dev.igb.3.queue3.no_desc_avail: 0 >> dev.igb.3.queue3.tx_packets: 0 >> dev.igb.3.queue3.rxd_head: 0 >> dev.igb.3.queue3.rxd_tail: 1023 >> dev.igb.3.queue3.rx_packets: 0 >> dev.igb.3.queue3.rx_bytes: 0 >> dev.igb.3.queue3.lro_queued: 0 >> dev.igb.3.queue3.lro_flushed: 0 >> dev.igb.3.queue4.interrupt_rate: 8000 >> dev.igb.3.queue4.txd_head: 0 >> dev.igb.3.queue4.txd_tail: 0 >> dev.igb.3.queue4.no_desc_avail: 0 >> dev.igb.3.queue4.tx_packets: 0 >> dev.igb.3.queue4.rxd_head: 0 >> dev.igb.3.queue4.rxd_tail: 1023 >> dev.igb.3.queue4.rx_packets: 0 >> dev.igb.3.queue4.rx_bytes: 0 >> dev.igb.3.queue4.lro_queued: 0 >> dev.igb.3.queue4.lro_flushed: 0 >> dev.igb.3.queue5.interrupt_rate: 8000 >> dev.igb.3.queue5.txd_head: 0 >> dev.igb.3.queue5.txd_tail: 0 >> dev.igb.3.queue5.no_desc_avail: 0 >> dev.igb.3.queue5.tx_packets: 0 >> dev.igb.3.queue5.rxd_head: 0 >> dev.igb.3.queue5.rxd_tail: 1023 >> dev.igb.3.queue5.rx_packets: 0 >> dev.igb.3.queue5.rx_bytes: 0 >> dev.igb.3.queue5.lro_queued: 0 >> dev.igb.3.queue5.lro_flushed: 0 >> dev.igb.3.queue6.interrupt_rate: 8000 >> dev.igb.3.queue6.txd_head: 0 >> dev.igb.3.queue6.txd_tail: 0 >> dev.igb.3.queue6.no_desc_avail: 0 >> dev.igb.3.queue6.tx_packets: 0 >> dev.igb.3.queue6.rxd_head: 0 >> dev.igb.3.queue6.rxd_tail: 1023 >> dev.igb.3.queue6.rx_packets: 0 >> dev.igb.3.queue6.rx_bytes: 0 >> dev.igb.3.queue6.lro_queued: 0 >> dev.igb.3.queue6.lro_flushed: 0 >> dev.igb.3.queue7.interrupt_rate: 8000 >> dev.igb.3.queue7.txd_head: 0 >> dev.igb.3.queue7.txd_tail: 0 >> dev.igb.3.queue7.no_desc_avail: 0 >> dev.igb.3.queue7.tx_packets: 0 >> dev.igb.3.queue7.rxd_head: 0 >> dev.igb.3.queue7.rxd_tail: 1023 >> dev.igb.3.queue7.rx_packets: 0 >> dev.igb.3.queue7.rx_bytes: 0 >> dev.igb.3.queue7.lro_queued: 0 >> dev.igb.3.queue7.lro_flushed: 0 >> dev.igb.3.mac_stats.excess_coll: 0 >> dev.igb.3.mac_stats.single_coll: 0 >> dev.igb.3.mac_stats.multiple_coll: 0 >> dev.igb.3.mac_stats.late_coll: 0 >> dev.igb.3.mac_stats.collision_count: 0 >> dev.igb.3.mac_stats.symbol_errors: 0 >> dev.igb.3.mac_stats.sequence_errors: 0 >> dev.igb.3.mac_stats.defer_count: 0 >> dev.igb.3.mac_stats.missed_packets: 0 >> dev.igb.3.mac_stats.recv_no_buff: 0 >> dev.igb.3.mac_stats.recv_undersize: 0 >> dev.igb.3.mac_stats.recv_fragmented: 0 >> dev.igb.3.mac_stats.recv_oversize: 0 >> dev.igb.3.mac_stats.recv_jabber: 0 >> dev.igb.3.mac_stats.recv_errs: 0 >> dev.igb.3.mac_stats.crc_errs: 0 >> dev.igb.3.mac_stats.alignment_errs: 0 >> dev.igb.3.mac_stats.coll_ext_errs: 0 >> dev.igb.3.mac_stats.xon_recvd: 0 >> dev.igb.3.mac_stats.xon_txd: 0 >> dev.igb.3.mac_stats.xoff_recvd: 0 >> dev.igb.3.mac_stats.xoff_txd: 0 >> dev.igb.3.mac_stats.total_pkts_recvd: 0 >> dev.igb.3.mac_stats.good_pkts_recvd: 0 >> dev.igb.3.mac_stats.bcast_pkts_recvd: 0 >> dev.igb.3.mac_stats.mcast_pkts_recvd: 0 >> dev.igb.3.mac_stats.rx_frames_64: 0 >> dev.igb.3.mac_stats.rx_frames_65_127: 0 >> dev.igb.3.mac_stats.rx_frames_128_255: 0 >> dev.igb.3.mac_stats.rx_frames_256_511: 0 >> dev.igb.3.mac_stats.rx_frames_512_1023: 0 >> dev.igb.3.mac_stats.rx_frames_1024_1522: 0 >> dev.igb.3.mac_stats.good_octets_recvd: 0 >> dev.igb.3.mac_stats.good_octets_txd: 72064 >> dev.igb.3.mac_stats.total_pkts_txd: 1126 >> dev.igb.3.mac_stats.good_pkts_txd: 1126 >> dev.igb.3.mac_stats.bcast_pkts_txd: 1126 >> dev.igb.3.mac_stats.mcast_pkts_txd: 0 >> dev.igb.3.mac_stats.tx_frames_64: 1126 >> dev.igb.3.mac_stats.tx_frames_65_127: 0 >> dev.igb.3.mac_stats.tx_frames_128_255: 0 >> dev.igb.3.mac_stats.tx_frames_256_511: 0 >> dev.igb.3.mac_stats.tx_frames_512_1023: 0 >> dev.igb.3.mac_stats.tx_frames_1024_1522: 0 >> dev.igb.3.mac_stats.tso_txd: 0 >> dev.igb.3.mac_stats.tso_ctx_fail: 0 >> dev.igb.3.interrupts.asserts: 1245 >> dev.igb.3.interrupts.rx_pkt_timer: 0 >> dev.igb.3.interrupts.rx_abs_timer: 0 >> dev.igb.3.interrupts.tx_pkt_timer: 0 >> dev.igb.3.interrupts.tx_abs_timer: 0 >> dev.igb.3.interrupts.tx_queue_empty: 1126 >> dev.igb.3.interrupts.tx_queue_min_thresh: 0 >> dev.igb.3.interrupts.rx_desc_min_thresh: 0 >> dev.igb.3.interrupts.rx_overrun: 0 >> dev.igb.3.host.breaker_tx_pkt: 0 >> dev.igb.3.host.host_tx_pkt_discard: 0 >> dev.igb.3.host.rx_pkt: 0 >> dev.igb.3.host.breaker_rx_pkts: 0 >> dev.igb.3.host.breaker_rx_pkt_drop: 0 >> dev.igb.3.host.tx_good_pkt: 0 >> dev.igb.3.host.breaker_tx_pkt_drop: 0 >> dev.igb.3.host.rx_good_bytes: 0 >> dev.igb.3.host.tx_good_bytes: 72064 >> dev.igb.3.host.length_errors: 0 >> dev.igb.3.host.serdes_violation_pkt: 0 >> dev.igb.3.host.header_redir_missed: 0 > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 18:53:25 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EBAB1065670 for ; Mon, 5 Mar 2012 18:53:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 11D398FC13 for ; Mon, 5 Mar 2012 18:53:24 +0000 (UTC) Received: by werl4 with SMTP id l4so3378053wer.13 for ; Mon, 05 Mar 2012 10:53:24 -0800 (PST) Received-SPF: pass (google.com: domain of jfvogel@gmail.com designates 10.180.104.65 as permitted sender) client-ip=10.180.104.65; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jfvogel@gmail.com designates 10.180.104.65 as permitted sender) smtp.mail=jfvogel@gmail.com; dkim=pass header.i=jfvogel@gmail.com Received: from mr.google.com ([10.180.104.65]) by 10.180.104.65 with SMTP id gc1mr17348151wib.13.1330973604071 (num_hops = 1); Mon, 05 Mar 2012 10:53:24 -0800 (PST) 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=S1OQ0YHUh02kZ0LWzbtTjkadg296fm3LQa9JHqm6pak=; b=CyuakLKDzj/yaZYwTXkh/lC4qxnbfoO2QE4uHkcrnUOTB75qC6spwiCxXb5k+0FqPd +Hu46MBiqg5xYkT1c1GaI1o8TC1IGQh31YkinGIDQz1eShztMXftxoceY3nUyKfbE2bj I/aGPbDNYOiEONPoHLbL1bnOnbQyh4fkticpZNL5gBC2MpxU/9lNkX8cNkVHGYVHsGgO DJsu/WEXLosNYuwmPInp6cjR1pCN16K2WqH38ub5xSdXQdTkodlwu9epxjCUVdg5rUtf 6ZhK2vDsI5c4NFUTCHAjKi31C22R+FOiu8KIvvGJ72sg4LJwLq8kVzdH70IImMAYpMPk CXbg== MIME-Version: 1.0 Received: by 10.180.104.65 with SMTP id gc1mr13697106wib.13.1330972084368; Mon, 05 Mar 2012 10:28:04 -0800 (PST) Received: by 10.180.82.168 with HTTP; Mon, 5 Mar 2012 10:28:04 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Mar 2012 10:28:04 -0800 Message-ID: From: Jack Vogel To: =?ISO-8859-1?Q?=D6zkan_KIRIK?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: igbX: could not setup receive structures X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:53:25 -0000 Increase the number of nmbclusters via sysctl, internally we set it to 262144. Jack 2012/3/5 =D6zkan KIRIK > Hi, > > I am using FreeBSD 8.2-STABLE-201105 amd64 snapshot. > System has about 200 ipfw rules. > There is 78 vlans assigned on igb3. > > igb3 interface asserts as "igb3: Could not setup receive structures" > once a day and then nic stops working. > Even ifconfig down && ifconfig up doesnt help. > > What the problem can be ? > Thanks > > > --------------------------- > igb3: flags=3D8943 > metric 0 mtu 1500 > > options=3D1bb > ether 00:1e:67:06:c5:45 > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (1000baseT ) > status: active > > ---------------------------- > > pciconf -lv: > > igb0@pci0:3:0:0: class=3D0x020000 card=3D0x34f28086 chip=3D0x10c98= 086 > rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > class =3D network > subclass =3D ethernet > igb1@pci0:3:0:1: class=3D0x020000 card=3D0x34f28086 chip=3D0x10c98= 086 > rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > class =3D network > subclass =3D ethernet > igb2@pci0:6:0:0: class=3D0x020000 card=3D0x34f28086 chip=3D0x10c98= 086 > rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > class =3D network > subclass =3D ethernet > igb3@pci0:6:0:1: class=3D0x020000 card=3D0x34f28086 chip=3D0x10c98= 086 > rev=3D0x01 hdr=3D0x00 > vendor =3D 'Intel Corporation' > class =3D network > subclass =3D ethernet > > > ------------------------------ > > #sysctl dev.igb.3. > dev.igb.3.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.3 > dev.igb.3.%driver: igb > dev.igb.3.%location: slot=3D0 function=3D1 > handle=3D\_SB_.PCI0.MRP1.GRP1.G2P2.G2K4 > dev.igb.3.%pnpinfo: vendor=3D0x8086 device=3D0x10c9 subvendor=3D0x8086 > subdevice=3D0x34f2 class=3D0x020000 > dev.igb.3.%parent: pci6 > dev.igb.3.nvm: -1 > dev.igb.3.enable_aim: 1 > dev.igb.3.flow_control: 3 > dev.igb.3.rx_processing_limit: 100 > dev.igb.3.link_irq: 26 > dev.igb.3.dropped: 0 > dev.igb.3.tx_dma_fail: 0 > dev.igb.3.rx_overruns: 0 > dev.igb.3.watchdog_timeouts: 0 > dev.igb.3.device_control: 1490027073 > dev.igb.3.rx_control: 67141658 > dev.igb.3.interrupt_mask: 4 > dev.igb.3.extended_int_mask: 2147484159 > dev.igb.3.tx_buf_alloc: 0 > dev.igb.3.rx_buf_alloc: 0 > dev.igb.3.fc_high_water: 58976 > dev.igb.3.fc_low_water: 58960 > dev.igb.3.queue0.interrupt_rate: 125000 > dev.igb.3.queue0.txd_head: 20 > dev.igb.3.queue0.txd_tail: 20 > dev.igb.3.queue0.no_desc_avail: 0 > dev.igb.3.queue0.tx_packets: 1136 > dev.igb.3.queue0.rxd_head: 0 > dev.igb.3.queue0.rxd_tail: 1023 > dev.igb.3.queue0.rx_packets: 0 > dev.igb.3.queue0.rx_bytes: 0 > dev.igb.3.queue0.lro_queued: 0 > dev.igb.3.queue0.lro_flushed: 0 > dev.igb.3.queue1.interrupt_rate: 8000 > dev.igb.3.queue1.txd_head: 0 > dev.igb.3.queue1.txd_tail: 0 > dev.igb.3.queue1.no_desc_avail: 0 > dev.igb.3.queue1.tx_packets: 0 > dev.igb.3.queue1.rxd_head: 0 > dev.igb.3.queue1.rxd_tail: 1023 > dev.igb.3.queue1.rx_packets: 0 > dev.igb.3.queue1.rx_bytes: 0 > dev.igb.3.queue1.lro_queued: 0 > dev.igb.3.queue1.lro_flushed: 0 > dev.igb.3.queue2.interrupt_rate: 8000 > dev.igb.3.queue2.txd_head: 0 > dev.igb.3.queue2.txd_tail: 0 > dev.igb.3.queue2.no_desc_avail: 0 > dev.igb.3.queue2.tx_packets: 0 > dev.igb.3.queue2.rxd_head: 0 > dev.igb.3.queue2.rxd_tail: 1023 > dev.igb.3.queue2.rx_packets: 0 > dev.igb.3.queue2.rx_bytes: 0 > dev.igb.3.queue2.lro_queued: 0 > dev.igb.3.queue2.lro_flushed: 0 > dev.igb.3.queue3.interrupt_rate: 8000 > dev.igb.3.queue3.txd_head: 0 > dev.igb.3.queue3.txd_tail: 0 > dev.igb.3.queue3.no_desc_avail: 0 > dev.igb.3.queue3.tx_packets: 0 > dev.igb.3.queue3.rxd_head: 0 > dev.igb.3.queue3.rxd_tail: 1023 > dev.igb.3.queue3.rx_packets: 0 > dev.igb.3.queue3.rx_bytes: 0 > dev.igb.3.queue3.lro_queued: 0 > dev.igb.3.queue3.lro_flushed: 0 > dev.igb.3.queue4.interrupt_rate: 8000 > dev.igb.3.queue4.txd_head: 0 > dev.igb.3.queue4.txd_tail: 0 > dev.igb.3.queue4.no_desc_avail: 0 > dev.igb.3.queue4.tx_packets: 0 > dev.igb.3.queue4.rxd_head: 0 > dev.igb.3.queue4.rxd_tail: 1023 > dev.igb.3.queue4.rx_packets: 0 > dev.igb.3.queue4.rx_bytes: 0 > dev.igb.3.queue4.lro_queued: 0 > dev.igb.3.queue4.lro_flushed: 0 > dev.igb.3.queue5.interrupt_rate: 8000 > dev.igb.3.queue5.txd_head: 0 > dev.igb.3.queue5.txd_tail: 0 > dev.igb.3.queue5.no_desc_avail: 0 > dev.igb.3.queue5.tx_packets: 0 > dev.igb.3.queue5.rxd_head: 0 > dev.igb.3.queue5.rxd_tail: 1023 > dev.igb.3.queue5.rx_packets: 0 > dev.igb.3.queue5.rx_bytes: 0 > dev.igb.3.queue5.lro_queued: 0 > dev.igb.3.queue5.lro_flushed: 0 > dev.igb.3.queue6.interrupt_rate: 8000 > dev.igb.3.queue6.txd_head: 0 > dev.igb.3.queue6.txd_tail: 0 > dev.igb.3.queue6.no_desc_avail: 0 > dev.igb.3.queue6.tx_packets: 0 > dev.igb.3.queue6.rxd_head: 0 > dev.igb.3.queue6.rxd_tail: 1023 > dev.igb.3.queue6.rx_packets: 0 > dev.igb.3.queue6.rx_bytes: 0 > dev.igb.3.queue6.lro_queued: 0 > dev.igb.3.queue6.lro_flushed: 0 > dev.igb.3.queue7.interrupt_rate: 8000 > dev.igb.3.queue7.txd_head: 0 > dev.igb.3.queue7.txd_tail: 0 > dev.igb.3.queue7.no_desc_avail: 0 > dev.igb.3.queue7.tx_packets: 0 > dev.igb.3.queue7.rxd_head: 0 > dev.igb.3.queue7.rxd_tail: 1023 > dev.igb.3.queue7.rx_packets: 0 > dev.igb.3.queue7.rx_bytes: 0 > dev.igb.3.queue7.lro_queued: 0 > dev.igb.3.queue7.lro_flushed: 0 > dev.igb.3.mac_stats.excess_coll: 0 > dev.igb.3.mac_stats.single_coll: 0 > dev.igb.3.mac_stats.multiple_coll: 0 > dev.igb.3.mac_stats.late_coll: 0 > dev.igb.3.mac_stats.collision_count: 0 > dev.igb.3.mac_stats.symbol_errors: 0 > dev.igb.3.mac_stats.sequence_errors: 0 > dev.igb.3.mac_stats.defer_count: 0 > dev.igb.3.mac_stats.missed_packets: 0 > dev.igb.3.mac_stats.recv_no_buff: 0 > dev.igb.3.mac_stats.recv_undersize: 0 > dev.igb.3.mac_stats.recv_fragmented: 0 > dev.igb.3.mac_stats.recv_oversize: 0 > dev.igb.3.mac_stats.recv_jabber: 0 > dev.igb.3.mac_stats.recv_errs: 0 > dev.igb.3.mac_stats.crc_errs: 0 > dev.igb.3.mac_stats.alignment_errs: 0 > dev.igb.3.mac_stats.coll_ext_errs: 0 > dev.igb.3.mac_stats.xon_recvd: 0 > dev.igb.3.mac_stats.xon_txd: 0 > dev.igb.3.mac_stats.xoff_recvd: 0 > dev.igb.3.mac_stats.xoff_txd: 0 > dev.igb.3.mac_stats.total_pkts_recvd: 0 > dev.igb.3.mac_stats.good_pkts_recvd: 0 > dev.igb.3.mac_stats.bcast_pkts_recvd: 0 > dev.igb.3.mac_stats.mcast_pkts_recvd: 0 > dev.igb.3.mac_stats.rx_frames_64: 0 > dev.igb.3.mac_stats.rx_frames_65_127: 0 > dev.igb.3.mac_stats.rx_frames_128_255: 0 > dev.igb.3.mac_stats.rx_frames_256_511: 0 > dev.igb.3.mac_stats.rx_frames_512_1023: 0 > dev.igb.3.mac_stats.rx_frames_1024_1522: 0 > dev.igb.3.mac_stats.good_octets_recvd: 0 > dev.igb.3.mac_stats.good_octets_txd: 72064 > dev.igb.3.mac_stats.total_pkts_txd: 1126 > dev.igb.3.mac_stats.good_pkts_txd: 1126 > dev.igb.3.mac_stats.bcast_pkts_txd: 1126 > dev.igb.3.mac_stats.mcast_pkts_txd: 0 > dev.igb.3.mac_stats.tx_frames_64: 1126 > dev.igb.3.mac_stats.tx_frames_65_127: 0 > dev.igb.3.mac_stats.tx_frames_128_255: 0 > dev.igb.3.mac_stats.tx_frames_256_511: 0 > dev.igb.3.mac_stats.tx_frames_512_1023: 0 > dev.igb.3.mac_stats.tx_frames_1024_1522: 0 > dev.igb.3.mac_stats.tso_txd: 0 > dev.igb.3.mac_stats.tso_ctx_fail: 0 > dev.igb.3.interrupts.asserts: 1245 > dev.igb.3.interrupts.rx_pkt_timer: 0 > dev.igb.3.interrupts.rx_abs_timer: 0 > dev.igb.3.interrupts.tx_pkt_timer: 0 > dev.igb.3.interrupts.tx_abs_timer: 0 > dev.igb.3.interrupts.tx_queue_empty: 1126 > dev.igb.3.interrupts.tx_queue_min_thresh: 0 > dev.igb.3.interrupts.rx_desc_min_thresh: 0 > dev.igb.3.interrupts.rx_overrun: 0 > dev.igb.3.host.breaker_tx_pkt: 0 > dev.igb.3.host.host_tx_pkt_discard: 0 > dev.igb.3.host.rx_pkt: 0 > dev.igb.3.host.breaker_rx_pkts: 0 > dev.igb.3.host.breaker_rx_pkt_drop: 0 > dev.igb.3.host.tx_good_pkt: 0 > dev.igb.3.host.breaker_tx_pkt_drop: 0 > dev.igb.3.host.rx_good_bytes: 0 > dev.igb.3.host.tx_good_bytes: 72064 > dev.igb.3.host.length_errors: 0 > dev.igb.3.host.serdes_violation_pkt: 0 > dev.igb.3.host.header_redir_missed: 0 > From owner-freebsd-net@FreeBSD.ORG Mon Mar 5 22:28:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F748106564A for ; Mon, 5 Mar 2012 22:28:23 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.freebsd.org (Postfix) with ESMTP id F14158FC0C for ; Mon, 5 Mar 2012 22:28:22 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail26.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q25MSDpQ016172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2012 09:28:13 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q25MSCYk064542; Tue, 6 Mar 2012 09:28:12 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q25MSBa8064540; Tue, 6 Mar 2012 09:28:11 +1100 (EST) (envelope-from peter) Date: Tue, 6 Mar 2012 09:28:11 +1100 From: Peter Jeremy To: h bagade Message-ID: <20120305222811.GA64183@server.vk2pj.dyndns.org> References: <20120305084359.GA56606@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:28:23 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please don't top-post. On 2012-Mar-05 13:30:36 +0330, h bagade wrote: >on layer 2 switch, ports doesn't have ip addresses and traffic comming >from a vlan port is tagged and pass through trunk port. this means >that in our freebsd box which plays the role of switch, no interfaces >should have ip addresses. OK. Sorry, I misunderstood what you were trying to achieve. I am using FreeBSD as a router rather than a switch. That said, I suspect your problem is that you are misunderstanding how VLAN tagging is applied. If a packet flows through a vlan(4) device, the appropriate tag is removed from incoming (from the network) packets and added to outgoing (to the network) packets. Packets flowing through normal ethernet devies (your ethX) without also flowing through a vlan(4) are not tagged (and so will appear in the default vlan as far as an external switch is concerned). Internally (ie as seen by bridge(4) instances), packets are not tagged. The following example diagram shows 3 distinct packet flows: - packets tagged 5 in trunk1 and 6 in trunk0 - packets tagged 7 in trunk1 and 9 in trunk0 - packets tagged 8 in trunk0 and 10 in trunk2 +-- vlan5 --- bridge1 --- vlan6 --+ | | trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 | =20 bridge3 --- vlan8 --+ | =20 trunk2 -- eth2 --- vlan10 This would be configured as: ifconfig vlan5 vlan 5 vlandev eth1 ifconfig vlan6 vlan 6 vlandev eth0 ifconfig vlan7 vlan 7 vlandev eth1 ifconfig vlan8 vlan 8 vlandev eth0 ifconfig vlan9 vlan 9 vlandev eth0 ifconfig vlan10 vlan 10 vlandev eth2 ifconfig bridge1 addm vlan5 addm vlan6 ifconfig bridge2 addm vlan7 addm vlan9 ifconfig bridge3 addm vlan8 addm vlan10 --=20 Peter Jeremy --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9VPfsACgkQ/opHv/APuIcLpACdHBv1TdsiTfqc9BFsZSfIhFKy oQQAoKRhOOevjhZZuGKXyA1tPKdWgB98 =Kb5u -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 02:05:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D9D41065672 for ; Tue, 6 Mar 2012 02:05:09 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8458FC13 for ; Tue, 6 Mar 2012 02:05:08 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5100355bkc.13 for ; Mon, 05 Mar 2012 18:05:07 -0800 (PST) Received-SPF: pass (google.com: domain of hiren.panchasara@gmail.com designates 10.204.150.86 as permitted sender) client-ip=10.204.150.86; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hiren.panchasara@gmail.com designates 10.204.150.86 as permitted sender) smtp.mail=hiren.panchasara@gmail.com; dkim=pass header.i=hiren.panchasara@gmail.com Received: from mr.google.com ([10.204.150.86]) by 10.204.150.86 with SMTP id x22mr11994185bkv.136.1330999507566 (num_hops = 1); Mon, 05 Mar 2012 18:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MenzTcgKYgBpOKUPbrx4m9iDSiteWn9Uza8KdIpNXis=; b=cJva78sIevWmTjnBe58w7YWVcajp3lvKF7ouhkylhKgzST0koyjgysugUPvm+ASRvc t57KF6q1zJzfIIV1rO73zPGG+VEtw/YyzOh29l+/BdJQZVWPy10RSS+SXGrB4CWWia+1 ASc2tRz1RqdPY9ARdiNZTuKVCGBMqsmfb26LGm1BsG06O2uflpEKOg4VZDtwowEWDwmf 5rQwVTYtBfecgIfnbnSI0CBAEAVSdhA1qjY5eFgjcsHcogsLNzJDCs0t/KKHoUo8q7Mg IGcojHFcivAwmcBzIMOpImSwTSPTOiL9r6qg+dl3CR7ugAWTHmlxXWSm0/XtDvfSaPzx Qk0w== MIME-Version: 1.0 Received: by 10.204.150.86 with SMTP id x22mr9505907bkv.136.1330999507388; Mon, 05 Mar 2012 18:05:07 -0800 (PST) Received: by 10.204.230.5 with HTTP; Mon, 5 Mar 2012 18:05:07 -0800 (PST) Date: Mon, 5 Mar 2012 18:05:07 -0800 Message-ID: From: hiren panchasara To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Difference between "struct addr" and "struct addrs" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 02:05:09 -0000 What is the difference between following 2 structs? /src/sys/net/if_var.h: struct ifaddr (from the comments seems like it contains a particular address (of probably many) information for an interface.) /src/include/ifaddrs.h: struct ifaddrs Thanks in advance, Hiren From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 05:45:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB1F106564A for ; Tue, 6 Mar 2012 05:45:58 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 551F78FC08 for ; Tue, 6 Mar 2012 05:45:57 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5214471bkc.13 for ; Mon, 05 Mar 2012 21:45:57 -0800 (PST) Received-SPF: pass (google.com: domain of bagadeh@gmail.com designates 10.204.141.10 as permitted sender) client-ip=10.204.141.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bagadeh@gmail.com designates 10.204.141.10 as permitted sender) smtp.mail=bagadeh@gmail.com; dkim=pass header.i=bagadeh@gmail.com Received: from mr.google.com ([10.204.141.10]) by 10.204.141.10 with SMTP id k10mr12324521bku.51.1331012757272 (num_hops = 1); Mon, 05 Mar 2012 21:45:57 -0800 (PST) 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=lIBWh6vIJfarO3tXehLHv+Lp4ctg8OlL3mD7catDoFo=; b=JuRxeQNthlpqvjsVGIa7zvmq+dsf4B9hgoGlAIdnvYSSroVgib6IPZhRxpw1uLhdAZ H0geKN5nqgsBA8eChLBVosMvSk0BDMTzUEwoullFoA+GoMtFZu677QuImyQYKiaitVW2 nWx2X4vGnBipJpmYQheWq+bdKMVwoAWlgda3BloaA7ouvja2CcYMPhuoQEToOzPn17W6 GMRfGOBf1wwNEV2TsVF4YCy3AL8XO1tBCHPhzupIyYy3m5RRNClPFlx289Sxd8WwPTmC UmXaivD6jeyAz9PpxPxvvDo08dyvflUvCwP/gfi1dNJvWN5h7/tYgPsh+hZ4TeGGNKWn zYqA== MIME-Version: 1.0 Received: by 10.204.141.10 with SMTP id k10mr9728430bku.51.1331012757186; Mon, 05 Mar 2012 21:45:57 -0800 (PST) Received: by 10.204.167.139 with HTTP; Mon, 5 Mar 2012 21:45:57 -0800 (PST) In-Reply-To: <20120305222811.GA64183@server.vk2pj.dyndns.org> References: <20120305084359.GA56606@server.vk2pj.dyndns.org> <20120305222811.GA64183@server.vk2pj.dyndns.org> Date: Tue, 6 Mar 2012 09:15:57 +0330 Message-ID: From: h bagade To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 05:45:59 -0000 On 3/6/12, Peter Jeremy wrote: > Please don't top-post. > > > OK. Sorry, I misunderstood what you were trying to achieve. I am > using FreeBSD as a router rather than a switch. That said, I suspect > your problem is that you are misunderstanding how VLAN tagging is > applied. If a packet flows through a vlan(4) device, the appropriate > tag is removed from incoming (from the network) packets and added to > outgoing (to the network) packets. Packets flowing through normal > ethernet devies (your ethX) without also flowing through a vlan(4) are > not tagged (and so will appear in the default vlan as far as an > external switch is concerned). Internally (ie as seen by bridge(4) > instances), packets are not tagged. > > The following example diagram shows 3 distinct packet flows: > - packets tagged 5 in trunk1 and 6 in trunk0 > - packets tagged 7 in trunk1 and 9 in trunk0 > - packets tagged 8 in trunk0 and 10 in trunk2 > > +-- vlan5 --- bridge1 --- vlan6 --+ > | | > trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 > | > bridge3 --- vlan8 --+ > | > trunk2 -- eth2 --- vlan10 > > This would be configured as: > ifconfig vlan5 vlan 5 vlandev eth1 > ifconfig vlan6 vlan 6 vlandev eth0 > ifconfig vlan7 vlan 7 vlandev eth1 > ifconfig vlan8 vlan 8 vlandev eth0 > ifconfig vlan9 vlan 9 vlandev eth0 > ifconfig vlan10 vlan 10 vlandev eth2 > ifconfig bridge1 addm vlan5 addm vlan6 > ifconfig bridge2 addm vlan7 addm vlan9 > ifconfig bridge3 addm vlan8 addm vlan10 > > -- > Peter Jeremy > I've described the function of Cisco switches in vlan tagging/untagging. In your topology, packets should be tagged when recieved on real interfaces to be send out to vlan interfaces. It would be fine when two trunks are communicating because on both side packets are tagged. But as I mentioned before, Cisco switches receive packets on an interface untagged and then sending packets tagged out of trunk port, based on which interface it receives, From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 07:08:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F01B9106564A for ; Tue, 6 Mar 2012 07:08:32 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7798FC0C for ; Tue, 6 Mar 2012 07:08:32 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5259516bkc.13 for ; Mon, 05 Mar 2012 23:08:31 -0800 (PST) Received-SPF: pass (google.com: domain of hiren.panchasara@gmail.com designates 10.204.150.88 as permitted sender) client-ip=10.204.150.88; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hiren.panchasara@gmail.com designates 10.204.150.88 as permitted sender) smtp.mail=hiren.panchasara@gmail.com; dkim=pass header.i=hiren.panchasara@gmail.com Received: from mr.google.com ([10.204.150.88]) by 10.204.150.88 with SMTP id x24mr12472833bkv.82.1331017711404 (num_hops = 1); Mon, 05 Mar 2012 23:08:31 -0800 (PST) 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=97UZffYJGpfZpelKNLjk7fIX7FDcK05GL6R6c09vmQU=; b=eMeDUjad0sVLx1bzk34Mh5Pa6Ppudv7iyd2yOoREtBhT5UwWSkqA1l3c7IpK4n27Uc JGVDpBwxCYhlUYSdC5MdmIRZPBVOlyOMFvD7FGIWF2UB4SWbEBkXsFqdY/TrJmiaGfO0 FmTwQ3VVU59YzqUWROcXOezxH2n4QunweEyfTuptG7St8eFCZaPdqH4WU+WtiK8EA1/0 Njq3VXqe4VRhWoSY3leQoPm7unprpausY/HS/sb/Cla2oZ2yu2TeGJX2Q0IC3iza7hBm YIsX0WuSNQbnYhWCAdhH3OWmhwI3whHSOADPQKRJ87WwM/HJ2rf7V9on+avy3OY0o+vq twWQ== MIME-Version: 1.0 Received: by 10.204.150.88 with SMTP id x24mr9855896bkv.82.1331017711234; Mon, 05 Mar 2012 23:08:31 -0800 (PST) Received: by 10.204.230.5 with HTTP; Mon, 5 Mar 2012 23:08:31 -0800 (PST) In-Reply-To: References: Date: Mon, 5 Mar 2012 23:08:31 -0800 Message-ID: From: hiren panchasara To: Sergey Kandaurov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Difference between "struct addr" and "struct addrs" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:08:33 -0000 On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov wrote: > struct ifaddr is the in-kernel representation of the interface address. > In kernel each network interface consists of a linked list of interface > addresses, described by ifaddr structures. > See man ifnet(9): http://man.freebsd.org/ifnet > > struct ifaddrs is used in the userland BSD API getifaddrs(3). This > interface > is used to get interface addresses in userland programs. See how it is > used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c > See man getifaddrs(3): http://man.freebsd.org/getifaddrs > Thanks Sergey, appreciate your help. Are they connected in any way? Can I get one if I have another? Hiren From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 07:24:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B27106566C for ; Tue, 6 Mar 2012 07:24:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1B86B8FC08 for ; Tue, 6 Mar 2012 07:24:33 +0000 (UTC) Received: by lagv3 with SMTP id v3so7991798lag.13 for ; Mon, 05 Mar 2012 23:24:32 -0800 (PST) Received-SPF: pass (google.com: domain of pluknet@gmail.com designates 10.112.102.161 as permitted sender) client-ip=10.112.102.161; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pluknet@gmail.com designates 10.112.102.161 as permitted sender) smtp.mail=pluknet@gmail.com; dkim=pass header.i=pluknet@gmail.com Received: from mr.google.com ([10.112.102.161]) by 10.112.102.161 with SMTP id fp1mr10078193lbb.71.1331018672864 (num_hops = 1); Mon, 05 Mar 2012 23:24:32 -0800 (PST) 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=vS8DxgxpaR8DFCN2QSjVcx3MCUIY8eOEy5irv8x/St4=; b=QX0e15Y7l59/X/NO2AHhSkM6PV7KODzSvQwKcXu1D3NtiQfyBmpRIG1XaYlY0cfnhc byEfrLlVYw0PfROCH4iRjiYyV9y5hpsHMroNW3DAvqmVNte83cQkIw9aLmP9As7ySxup LZ4EFjYPhIxW19Bnymd57bV7pBcEtZEpvafi6sjPhT2vjcz98bWJ4H/PdUoxjlL8GemC LVN+W18Np14VYLn5VXgIPc1tJk3YEx4ZRoUp6p03g/L+cBFu0aP1kTHXBKVJlzyguKfK nxCCbNyhOT8HkAYGCKBFugrKVfczKHiymz0oy9v2Kh8s6PmjFuRSk9X7DbsmQ0bku7TB m+fw== MIME-Version: 1.0 Received: by 10.112.102.161 with SMTP id fp1mr8193945lbb.71.1331017045061; Mon, 05 Mar 2012 22:57:25 -0800 (PST) Received: by 10.152.21.73 with HTTP; Mon, 5 Mar 2012 22:57:25 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 09:57:25 +0300 Message-ID: From: Sergey Kandaurov To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Difference between "struct addr" and "struct addrs" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:24:34 -0000 On 6 March 2012 06:05, hiren panchasara wrote: > What is the difference between following 2 structs? > > /src/sys/net/if_var.h: struct ifaddr (from the comments seems like it > contains a particular address (of probably many) information for an > interface.) > > /src/include/ifaddrs.h: struct ifaddrs > struct ifaddr is the in-kernel representation of the interface address. In kernel each network interface consists of a linked list of interface addresses, described by ifaddr structures. See man ifnet(9): http://man.freebsd.org/ifnet struct ifaddrs is used in the userland BSD API getifaddrs(3). This interface is used to get interface addresses in userland programs. See how it is used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c See man getifaddrs(3): http://man.freebsd.org/getifaddrs -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 07:46:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95088106566B for ; Tue, 6 Mar 2012 07:46:59 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 16D658FC13 for ; Tue, 6 Mar 2012 07:46:58 +0000 (UTC) Received: from IMP (mailscan02.syd.optusnet.com.au [211.29.133.115]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q267Lphu029875 for ; Tue, 6 Mar 2012 18:46:57 +1100 Received: from server.vk2pj.dyndns.org ([220.239.116.103]) by IMP with bizsmtp id i7mw1i00k2DvjZo017mx0r; Tue, 06 Mar 2012 18:46:57 +1100 X-Optus-Cloudmark-Seen: 1 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q267kubx072328; Tue, 6 Mar 2012 18:46:56 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q267kuSf072327; Tue, 6 Mar 2012 18:46:56 +1100 (EST) (envelope-from peter) Date: Tue, 6 Mar 2012 18:46:55 +1100 From: Peter Jeremy To: h bagade Message-ID: <20120306074655.GA71641@server.vk2pj.dyndns.org> References: <20120305084359.GA56606@server.vk2pj.dyndns.org> <20120305222811.GA64183@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net Subject: Re: problem with vlan interfaces tagging/untagging in a simulated switch box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:46:59 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Mar-06 09:15:57 +0330, h bagade wrote: >On 3/6/12, Peter Jeremy wrote: >> The following example diagram shows 3 distinct packet flows: >> - packets tagged 5 in trunk1 and 6 in trunk0 >> - packets tagged 7 in trunk1 and 9 in trunk0 >> - packets tagged 8 in trunk0 and 10 in trunk2 >> >> +-- vlan5 --- bridge1 --- vlan6 --+ >> | | >> trunk1 --- eth1 -+- vlan7 --- bridge2 --- vlan9 --+-- eth0 --- trunk0 >> | >> bridge3 --- vlan8 --+ >> | >> trunk2 -- eth2 --- vlan10 >> >I've described the function of Cisco switches in vlan >tagging/untagging. Real switches typically have everything tagged internally, with the native VLAN tags added/removed at the ingress/egress ports. This simplifies the internal switch logic (at the expense of meaning that tags have to be consistent across all trunks). FreeBSD works differently. Packets are _untagged_ internally and you need a separate bridge(4) device for each broadcast domain (vlan). > In your topology, packets should be tagged when >recieved on real interfaces to be send out to vlan interfaces. Packets are never tagged by real interfaces and always have tags added/removed by vlan devices. > It >would be fine when two trunks are communicating because on both side >packets are tagged. But as I mentioned before, Cisco switches receive >packets on an interface untagged and then sending packets tagged out >of trunk port, based on which interface it receives, You can connect a physical interface (ethX) directly to a bridge device to access untagged packets. Note that I'm not sure whether it is safe to access the native VLAN in a trunk in this way. To continue the above example, ifconfig bridge1 addm eth3 would result in packets arriving on eth3 leaving tagged as vlan 5 in trunk1, vlan 6 in trunk0 and vice versa. --=20 Peter Jeremy --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9VwO8ACgkQ/opHv/APuIf0AgCfdHk8QgourJiU8Grqo/zL+uIp ADQAoIz4C1eoIBmqle03WXcDuXpfJW1N =LmpB -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 08:03:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 386901065675 for ; Tue, 6 Mar 2012 08:03:58 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9F83D8FC13 for ; Tue, 6 Mar 2012 08:03:57 +0000 (UTC) Received: by lagv3 with SMTP id v3so8045166lag.13 for ; Tue, 06 Mar 2012 00:03:56 -0800 (PST) Received-SPF: pass (google.com: domain of pluknet@gmail.com designates 10.152.132.132 as permitted sender) client-ip=10.152.132.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pluknet@gmail.com designates 10.152.132.132 as permitted sender) smtp.mail=pluknet@gmail.com; dkim=pass header.i=pluknet@gmail.com Received: from mr.google.com ([10.152.132.132]) by 10.152.132.132 with SMTP id ou4mr14552438lab.26.1331021036443 (num_hops = 1); Tue, 06 Mar 2012 00:03:56 -0800 (PST) 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=NfSBJcwTzI9sDULMKfY51Bg2E15i30e/0/Yt4HmHIBU=; b=blT/xYwlS484wJ292gPHSoagyX7nDIis+JMZaFSp8eSRI4WO9LmcWibfsvIBUa74bv BUSSoB6ffsO0uMPAicLW9RcHQTPMXQJoNmj07879wnYGZLHsd83BRo6VuJzFT2iqbvm+ +MZ8em3l2S8vZHLcdQtlRWcuyujCvTG7F7ssqpLOuOx5X+wbFJiTlgsSOWZ9pk9soVP2 THxjRpiYUsz8sOsUmmxrgjhzbZq7eS87B9w3fmAAJjzbIIMbyckxbn8zbwGwkCnDJV4w Lb6bAJmSOqNei7sQjx4CahIL7Yn3/iiIppxd6W8QKRxGAUQP354z+KvZ5HEdoYQic5U0 NZOA== MIME-Version: 1.0 Received: by 10.152.132.132 with SMTP id ou4mr11942191lab.26.1331021036381; Tue, 06 Mar 2012 00:03:56 -0800 (PST) Received: by 10.152.21.73 with HTTP; Tue, 6 Mar 2012 00:03:56 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 11:03:56 +0300 Message-ID: From: Sergey Kandaurov To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Difference between "struct addr" and "struct addrs" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:03:58 -0000 On 6 March 2012 11:08, hiren panchasara wrote: > > > On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov wrote: >> >> struct ifaddr is the in-kernel representation of the interface address. >> In kernel each network interface consists of a linked list of interface >> addresses, described by ifaddr structures. >> See man ifnet(9): http://man.freebsd.org/ifnet >> >> struct ifaddrs is used in the userland BSD API getifaddrs(3). This >> interface >> is used to get interface addresses in userland programs. See how it is >> used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c >> See man getifaddrs(3): http://man.freebsd.org/getifaddrs > > Thanks Sergey, appreciate your help. > > Are they connected in any way? Can I get one if I have another? Well, not strictly. getifaddrs() collects addresses on all network interfaces using sysctl interface to the routine table with NET_RT_IFLIST[L] argument. NET_RT_IFLIST[L] does what you would expect: it runs through the linked list of network interfaces and gathers all struct ifaddr on each of them. You can see how that works in /usr/src/sys/net/rtsock.c:sysctl_iflist(). See also man sysctl(3) w.r.t. NET_RT_IFLIST / NET_RT_IFLISTL. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 11:06:58 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D39CD1065674 for ; Tue, 6 Mar 2012 11:06:58 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9308FC17 for ; Tue, 6 Mar 2012 11:06:58 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5451613bkc.13 for ; Tue, 06 Mar 2012 03:06:57 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.204.174.206 as permitted sender) client-ip=10.204.174.206; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.204.174.206 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.204.174.206]) by 10.204.174.206 with SMTP id u14mr13074489bkz.88.1331032017570 (num_hops = 1); Tue, 06 Mar 2012 03:06:57 -0800 (PST) Received: by 10.204.174.206 with SMTP id u14mr10250174bkz.88.1331030195390; Tue, 06 Mar 2012 02:36:35 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ew15sm30988059bkc.10.2012.03.06.02.36.33 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 02:36:34 -0800 (PST) Message-ID: <4F55E8B0.8010104@my.gd> Date: Tue, 06 Mar 2012 11:36:32 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Doug Barton , Attila Nagy , hrs@FreeBSD.org References: <4F51F74A.1010403@fsn.hu> <4F527D08.9040206@FreeBSD.org> In-Reply-To: <4F527D08.9040206@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkt2tbQ06VLTI11sykgz57jNakaODXnQFkLd47tJrGWCRkJ9PnHLLd+EfVVfdOllB39lYDs Cc: net@freebsd.org Subject: Re: IPv6 and CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:06:58 -0000 Hello guys, Are there any news on the topic ? Trying to push IP6 at work for our firewalls and struggling with CARP interfaces with inet6 addresses at boot like OP. I could probably just set the address with a script in /usr/local/etc/rc.d/ but I'd rather get it working out of the box, that'll increase the credibility. On 3/3/12 9:20 PM, Doug Barton wrote: > Looping in hrs@ since he's responsible for that area. > > > On 03/03/2012 02:49, Attila Nagy wrote: >> Hi, >> >> On a recently built stable/9 I have these lines in rc.conf: >> ifconfig_em0_name="admin" >> vlans_admin="pub" >> create_args_pub="vlan 20" >> ifconfig_admin="inet 192.168.2.20 netmask 255.255.255.0" >> ifconfig_pub="inet 1.1.1.1 netmask 255.255.255.224" >> ifconfig_pub_ipv6="inet6 accept_rtadv" >> ifconfig_carp0="vhid 1 pass beef 1.1.1.2/27" >> ifconfig_carp0_ipv6="inet6 2001::beef/64" >> >> When the machine boots up, it has every interfaces configured with the >> right addresses, except carp0, which has the IPv4, but no the IPv6 address. >> However if I specify: >> ifconfig carp0 inet6 2001::beef/64 >> carp0 gets the IPv6 address and I get >> carp0: 2 link states coalesced >> log entry. >> >> What is the problem with the above configuration, why doesn't carp0 get >> the IPv6 address during boot? > From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 11:46:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4A6E5106566C for ; Tue, 6 Mar 2012 11:46:52 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD5578FC0A for ; Tue, 6 Mar 2012 11:46:51 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5490736bkc.13 for ; Tue, 06 Mar 2012 03:46:50 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.204.156.23 as permitted sender) client-ip=10.204.156.23; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.204.156.23 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.204.156.23]) by 10.204.156.23 with SMTP id u23mr12922056bkw.18.1331034410803 (num_hops = 1); Tue, 06 Mar 2012 03:46:50 -0800 (PST) Received: by 10.204.156.23 with SMTP id u23mr10080228bkw.18.1331034410601; Tue, 06 Mar 2012 03:46:50 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id d5sm31475660bkb.3.2012.03.06.03.46.49 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 03:46:49 -0800 (PST) Message-ID: <4F55F928.7030208@my.gd> Date: Tue, 06 Mar 2012 12:46:48 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk6ZFSqQYZVGn6JHzYD0jvNGqDu6CLlZBj/ANXKI7GK7+d+r2BphydxAZryPZ5yW88FOGvg Cc: ml@my.gd Subject: IPV6 + CARP - page fault while in kernel mode on 8.3-PRERELEASE amd64 (17/02/12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:46:52 -0000 Hello -net, I was experimenting with ipv6 and CARP on a backup firewall running the following: 8.3-PRERELEASE #0: Fri Feb 17 11:20:28 CET 2012 I tried (and succeeded) to reproduce the bug from kern/153848 where a CARP BACKUP host connects to itself instead of the MASTER for ipv6. Shortly afterwards, the box crashed with a "page fault while in kernel mode". Aside from some info below, I've got the following files available in /var/crash and can submit them as well if requested: bounds core.txt.0 info.0 minfree vmcore.0 The kernel itself is very lightweight and configured with: makeoptions DEBUG=-g options KDTRACE_FRAME options KDTRACE_HOOKS options KDB options KDB_TRACE options SMP Networking is as follows: VLANs (over failover LAGG) + CARP + PF Relevant snippets from rc.conf: ifconfig_bce0="up" ifconfig_bce1="up" ifconfig_lagg0="laggproto failover laggport bce0 laggport bce1" ipv6_enable="YES" ipv6_gateway_enable="YES" ipv6_network_interfaces="vlan17 carp66" # IPv6 test CARP ipv4_addrs_carp66="192.168.98.166/32" ifconfig_carp66="vhid 166 pass ipv6pass advskew 40" ipv6_ifconfig_carp66="2a02:24a8:0020:0600::5 prefixlen 64" I manually assigned 2a02:24a8:0020:0600::4/64 to vlan17 pciconf: bce0@pci0:2:0:0: class=0x020000 card=0x02a31028 chip=0x163b14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xda000000, size 33554432, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 16 messages, 64 bit enabled with 1 message cap 11[a0] = MSI-X supports 9 messages in map 0x10 cap 10[ac] = PCI-Express 2 endpoint max data 128(512) link x4(x4) ecap 0003[100] = Serial 1 782bcbfffe00ed56 ecap 0001[110] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] = unknown 1 ecap 0002[160] = VC 1 max VC0 bce1@pci0:2:0:1: class=0x020000 card=0x02a31028 chip=0x163b14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xdc000000, size 33554432, enabled cap 01[48] = powerspec 3 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 16 messages, 64 bit enabled with 1 message cap 11[a0] = MSI-X supports 9 messages in map 0x10 cap 10[ac] = PCI-Express 2 endpoint max data 128(512) link x4(x4) ecap 0003[100] = Serial 1 782bcbfffe00ed57 ecap 0001[110] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0004[150] = unknown 1 ecap 0002[160] = VC 1 max VC0 Also posting the excerpt from kgdb in core.txt.0 : Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8047aac2 stack pointer = 0x28:0xffffff81208338a0 frame pointer = 0x28:0xffffff8120833920 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq257: bce0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff803dde1e at kdb_backtrace+0x5e #1 0xffffffff803a9a97 at panic+0x187 #2 0xffffffff805cde90 at trap_fatal+0x290 #3 0xffffffff805ce4b0 at trap+0x180 #4 0xffffffff805b5718 at calltrap+0x8 #5 0xffffffff80488fdc at ip_input+0xac #6 0xffffffff8046678e at netisr_dispatch_src+0x7e #7 0xffffffff8045d8ad at ether_demux+0x14d #8 0xffffffff8045dcb7 at ether_input+0x197 #9 0xffffffff8045d7cf at ether_demux+0x6f #10 0xffffffff8045dcb7 at ether_input+0x197 #11 0xffffffff8025097a at bce_intr+0x43a #12 0xffffffff8037f5c4 at intr_event_execute_handlers+0x104 #13 0xffffffff80380c55 at ithread_loop+0x95 #14 0xffffffff8037c1ff at fork_exit+0x11f #15 0xffffffff805b5c5e at fork_trampoline+0xe Uptime: 17d22h36m12s Dumping 492 out of 4075 MB: ..4%..13%..23%..33%..43%..52%..62%..72%..82%..91% [snip irrelevant symbols (geom, linux...)] Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_lagg.ko #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0xffffffff803a95e0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:441 #2 0xffffffff803a9a81 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:614 #3 0xffffffff805cde90 in trap_fatal (frame=0x9, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:825 #4 0xffffffff805ce4b0 in trap (frame=0xffffff81208337f0) at /usr/src/sys/amd64/amd64/trap.c:621 #5 0xffffffff805b5718 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #6 0xffffffff8047aac2 in carp_input_c (m=0xffffff0003c4e800, ch=0xffffff0003c4e86c, af=2 '\002') at /usr/src/sys/netinet/ip_carp.c:710 #7 0xffffffff80488fdc in ip_input (m=0xffffff0003c50e00) at /usr/src/sys/netinet/ip_input.c:787 #8 0xffffffff8046678e in netisr_dispatch_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:859 #9 0xffffffff8045d8ad in ether_demux (ifp=0xffffff0003503800, m=0xffffff0003c50e00) at /usr/src/sys/net/if_ethersubr.c:896 #10 0xffffffff8045dcb7 in ether_input (ifp=0xffffff0003503800, m=0xffffff0003c50e00) at /usr/src/sys/net/if_ethersubr.c:755 #11 0xffffffff8045d7cf in ether_demux (ifp=0xffffff00032a3800, m=0xffffff0003c50e00) at /usr/src/sys/net/if_ethersubr.c:805 #12 0xffffffff8045dcb7 in ether_input (ifp=0xffffff00032a3800, m=0xffffff0003c50e00) at /usr/src/sys/net/if_ethersubr.c:755 #13 0xffffffff8025097a in bce_intr (xsc=Variable "xsc" is not available. ) at /usr/src/sys/dev/bce/if_bce.c:6586 #14 0xffffffff8037f5c4 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1216 #15 0xffffffff80380c55 in ithread_loop (arg=0xffffff0001b58840) at /usr/src/sys/kern/kern_intr.c:1229 #16 0xffffffff8037c1ff in fork_exit ( callout=0xffffffff80380bc0 , arg=0xffffff0001b58840, frame=0xffffff8120833c50) at /usr/src/sys/kern/kern_fork.c:876 #17 0xffffffff805b5c5e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000001 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0xffffffff8089fc00 in affinity () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0xffffff0001c008c0 in ?? () #46 0xffffff81208330e0 in ?? () #47 0xffffff8120833088 in ?? () #48 0xffffff000367b8c0 in ?? () #49 0xffffffff803d0f30 in sched_switch (td=0xffffffff80380bc0, newtd=0xffffff0001b58840, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1861 Previous frame inner to this frame (corrupt stack?) (kgdb) I notice steps 8 (netisr) 13 and 14 (bce) where the kernel complains about variables not being available. Let me know how I can be of further assistance to track the problem down. This is a backup host, I can do whatever it takes on it. From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 11:47:49 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73AF11065678; Tue, 6 Mar 2012 11:47:49 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id B91168FC14; Tue, 6 Mar 2012 11:47:48 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q26BlZwp079110; Tue, 6 Mar 2012 20:47:45 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q26BlTST086539; Tue, 6 Mar 2012 20:47:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 06 Mar 2012 20:47:21 +0900 (JST) Message-Id: <20120306.204721.558524904102202616.hrs@allbsd.org> To: ml@my.gd From: Hiroki Sato In-Reply-To: <4F55E8B0.8010104@my.gd> References: <4F51F74A.1010403@fsn.hu> <4F527D08.9040206@FreeBSD.org> <4F55E8B0.8010104@my.gd> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Mar__6_20_47_21_2012_550)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Tue, 06 Mar 2012 20:47:46 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: dougb@FreeBSD.org, net@FreeBSD.org Subject: Re: IPv6 and CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:47:49 -0000 ----Security_Multipart(Tue_Mar__6_20_47_21_2012_550)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Damien Fleuriot wrote in <4F55E8B0.8010104@my.gd>: ml> Hello guys, ml> ml> ml> Are there any news on the topic ? ml> ml> Trying to push IP6 at work for our firewalls and struggling with CARP ml> interfaces with inet6 addresses at boot like OP. ml> ml> I could probably just set the address with a script in ml> /usr/local/etc/rc.d/ but I'd rather get it working out of the box, ml> that'll increase the credibility. I am investigating it. Please give me some more time. -- Hiroki ----Security_Multipart(Tue_Mar__6_20_47_21_2012_550)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk9V+UkACgkQTyzT2CeTzy2iMACfWYUoebohfkX1rAXP5sMc4BQb LNAAoM8h3oXdlkl0n7kZy81qjwGJUjGt =N5IF -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Mar__6_20_47_21_2012_550)---- From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 11:48:53 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B4411065679 for ; Tue, 6 Mar 2012 11:48:53 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 242368FC18 for ; Tue, 6 Mar 2012 11:48:52 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5492865bkc.13 for ; Tue, 06 Mar 2012 03:48:52 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.204.9.194 as permitted sender) client-ip=10.204.9.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.204.9.194 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.204.9.194]) by 10.204.9.194 with SMTP id m2mr12528842bkm.92.1331034532253 (num_hops = 1); Tue, 06 Mar 2012 03:48:52 -0800 (PST) Received: by 10.204.9.194 with SMTP id m2mr9811122bkm.92.1331034532077; Tue, 06 Mar 2012 03:48:52 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id h16sm29499270bkk.12.2012.03.06.03.48.50 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 03:48:51 -0800 (PST) Message-ID: <4F55F9A2.9040206@my.gd> Date: Tue, 06 Mar 2012 12:48:50 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Hiroki Sato References: <4F51F74A.1010403@fsn.hu> <4F527D08.9040206@FreeBSD.org> <4F55E8B0.8010104@my.gd> <20120306.204721.558524904102202616.hrs@allbsd.org> In-Reply-To: <20120306.204721.558524904102202616.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmnoZDUpcBykWgXyZVJSnSdW7Kup2v4AtH73ZzoykURlPS0m1nX3mRVQ2xAtPYl6xB3/yus Cc: dougb@FreeBSD.org, net@FreeBSD.org Subject: Re: IPv6 and CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:48:53 -0000 On 3/6/12 12:47 PM, Hiroki Sato wrote: > Damien Fleuriot wrote > in <4F55E8B0.8010104@my.gd>: > > ml> Hello guys, > ml> > ml> > ml> Are there any news on the topic ? > ml> > ml> Trying to push IP6 at work for our firewalls and struggling with CARP > ml> interfaces with inet6 addresses at boot like OP. > ml> > ml> I could probably just set the address with a script in > ml> /usr/local/etc/rc.d/ but I'd rather get it working out of the box, > ml> that'll increase the credibility. > > I am investigating it. Please give me some more time. > > -- Hiroki Sure, don't hesitate to ping if you need any testing done. From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 12:54:06 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12813106566C; Tue, 6 Mar 2012 12:54:06 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 74F458FC1D; Tue, 6 Mar 2012 12:54:04 +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 q26Cs2r4031181; Tue, 6 Mar 2012 19:54:02 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F5608EA.6080705@rdtc.ru> Date: Tue, 06 Mar 2012 19:54:02 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marius@freebsd.org, yongari@freebsd.org Subject: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 12:54:06 -0000 Hi! Yesterday I've updated old HP ProLiant DL360 G4p to 8.3-PRELELEASE/amd64 running busy icecast2 server in hope it can saturate 1G bge(4) link. This server has PCI-X connected HP NC7782 Gigabit Server Adapter (BCM5704). Is it supposed to emit more than 540Mbit/s with average packet size equal to 1300? netstat shows increasing "Drop" counters: # netstat -id Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop bge0 1500 00:18:fe:86:ab:f4 635577217 0 0 1047897138 0 0 454509 vmstat shows relatively high but pretty sane interrupt rate: # vmstat -i | grep bge irq25: bge0 232949783 10149 Input traffic is less than 20Mbit/s meantime, output does not go above 540Mbit/s. Its mbufs usage is normal (server has 2G RAM): # netstat -m 13459/15986/29445 mbufs in use (current/cache/total) 13322/13112/26434/262144 mbuf clusters in use (current/cache/total/max) 13322/13046 mbuf+clusters out of packet secondary zone in use (current/cache) 0/104/104/131072 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) 30008K/30636K/60645K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I've glanced at bge(4) code and see it uses lots of hardcoded constants for rx/tx descriptor rings, for interrupt moderation and for interface FIFO queue. And no loader tunnables/sysctls like em/igb have. Should I try to play with constants in the code and if so, what are limits of this chip? Or it will never be capable of utilizing full gigabit speed? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 16:23:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A11AF106564A for ; Tue, 6 Mar 2012 16:23:12 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2377B8FC14 for ; Tue, 6 Mar 2012 16:23:11 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5857182bkc.13 for ; Tue, 06 Mar 2012 08:23:11 -0800 (PST) Received-SPF: pass (google.com: domain of hiren.panchasara@gmail.com designates 10.205.127.130 as permitted sender) client-ip=10.205.127.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hiren.panchasara@gmail.com designates 10.205.127.130 as permitted sender) smtp.mail=hiren.panchasara@gmail.com; dkim=pass header.i=hiren.panchasara@gmail.com Received: from mr.google.com ([10.205.127.130]) by 10.205.127.130 with SMTP id ha2mr13718281bkc.28.1331050991144 (num_hops = 1); Tue, 06 Mar 2012 08:23:11 -0800 (PST) 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=zIYgPO+URz2zOz5Pif+pgSVQYP8I7O7NgP+sDycXEyY=; b=tplkjekjR5+OmO7kcWmxhtHsYyARtW2zOe+hFS19+NXHU+sHiPSogZBe1cMLsoyC2a AZOewhNFp1Aky4GM6Z8PTWSv5hKXd+ngSSYUoVWxfnJJyG3e/junk4K/qtOXrF0XOwX3 TBousIgTBTQyS8fBz+lTYLlRgBdYbHfVgd0VhCu+x4kwQ+brgMTUrawK7vDEGmwg6BHm GrxAfC7wRDeNtTyRk168KnQzG2wZFu/kznpL4+KlmgD1POhOTqMXlkbyULbCP2O///4n nnUur6g1JvsBHJsRaZAq/9Nf5LTL58TOtb2CyWJTYmcyqMxQO85/fOebn/CzzA24tLlL 0MOA== MIME-Version: 1.0 Received: by 10.205.127.130 with SMTP id ha2mr10755225bkc.28.1331050991046; Tue, 06 Mar 2012 08:23:11 -0800 (PST) Received: by 10.204.230.5 with HTTP; Tue, 6 Mar 2012 08:23:10 -0800 (PST) In-Reply-To: References: Date: Tue, 6 Mar 2012 08:23:10 -0800 Message-ID: From: hiren panchasara To: Sergey Kandaurov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Difference between "struct addr" and "struct addrs" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:23:12 -0000 On Tue, Mar 6, 2012 at 12:03 AM, Sergey Kandaurov wrote: > On 6 March 2012 11:08, hiren panchasara > wrote: > > > > > > On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov > wrote: > >> > >> struct ifaddr is the in-kernel representation of the interface address. > >> In kernel each network interface consists of a linked list of interface > >> addresses, described by ifaddr structures. > >> See man ifnet(9): http://man.freebsd.org/ifnet > >> > >> struct ifaddrs is used in the userland BSD API getifaddrs(3). This > >> interface > >> is used to get interface addresses in userland programs. See how it is > >> used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c > >> See man getifaddrs(3): http://man.freebsd.org/getifaddrs > > > > Thanks Sergey, appreciate your help. > > > > Are they connected in any way? Can I get one if I have another? > > Well, not strictly. > getifaddrs() collects addresses on all network interfaces using > sysctl interface to the routine table with NET_RT_IFLIST[L] argument. > NET_RT_IFLIST[L] does what you would expect: it runs through the linked > list of network interfaces and gathers all struct ifaddr on each of them. > You can see how that works in /usr/src/sys/net/rtsock.c:sysctl_iflist(). > See also man sysctl(3) w.r.t. NET_RT_IFLIST / NET_RT_IFLISTL. > Thanks a bunch, Sergey! This is *exactly* what I was looking for. :-) Hiren From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 19:50:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F8FF1065676 for ; Tue, 6 Mar 2012 19:50:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7C48FC1B for ; Tue, 6 Mar 2012 19:50:38 +0000 (UTC) Received: (qmail 90697 invoked from network); 6 Mar 2012 18:04:27 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Mar 2012 18:04:27 -0000 Message-ID: <4F566A8A.3080607@freebsd.org> Date: Tue, 06 Mar 2012 20:50:34 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mikolaj Golub References: <86ehzwwt6a.fsf@kopusha.home.net> <86r53uhibq.fsf@kopusha.home.net> In-Reply-To: <86r53uhibq.fsf@kopusha.home.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:50:39 -0000 On 05.09.2011 21:58, Mikolaj Golub wrote: > > On Sun, 04 Sep 2011 12:30:53 +0300 Mikolaj Golub wrote: > > MG> Apparently soreceive_stream() has an issue if it is called to receive data as a > MG> mbuf chain (by supplying an non zero mbuf **mp0) and with MSG_WAITALL set. > > MG> I ran into this issue with smbfs, which uses soreceive() exactly in this way > MG> (see netsmb/smb_trantcp.c:nbssn_recv()). > > Stressing smbfs a little I also observed the following soreceive_stream() > related panic: Hi Mikolaj, thank you very much for testing, reporting and fixing bugs in soreceive_stream(). I've altered your proposed patches a bit and committed them into my workqueue with the following revisions: http://svn.freebsd.org/changeset/base/232617 http://svn.freebsd.org/changeset/base/232618 Would you mind testing them again before they go into HEAD? -- Andre > #9 0x80a28c80 in panic (fmt=0x80f4b4a4 "sbappendstream 1") > at /usr/src/sys/kern/kern_shutdown.c:606 > #10 0x80a9746b in sbappendstream_locked (sb=0x8bff1874, m=0x8885a600) > at /usr/src/sys/kern/uipc_sockbuf.c:527 > #11 0x80bcef62 in tcp_do_segment (m=0x8885a600, th=0x8885a674, so=0x8bff1820, tp=0x8bb4f560, > drop_hdrlen=52, tlen=51, iptos=0 '\0', ti_locked=1) > at /usr/src/sys/netinet/tcp_input.c:2854 > #12 0x80bd091d in tcp_input (m=0x8885a600, off0=20) at /usr/src/sys/netinet/tcp_input.c:1382 > #13 0x80b5b4fe in ip_input (m=0x8885a600) at /usr/src/sys/netinet/ip_input.c:765 > #14 0x80af504b in swi_net (arg=0x81825880) at /usr/src/sys/net/netisr.c:806 > #15 0x809fd535 in intr_event_execute_handlers (p=0x86ddc588, ie=0x86d37200) > at /usr/src/sys/kern/kern_intr.c:1257 > #16 0x809fe419 in ithread_loop (arg=0x86d39bb0) at /usr/src/sys/kern/kern_intr.c:1270 > #17 0x809fa7a8 in fork_exit (callout=0x809fe370, arg=0x86d39bb0, > frame=0x86926d28) at /usr/src/sys/kern/kern_fork.c:1029 > #18 0x80d68914 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 > (kgdb) fr 10 > #10 0x80a9746b in sbappendstream_locked (sb=0x8bff1874, m=0x8885a600) > at /usr/src/sys/kern/uipc_sockbuf.c:527 > 527 KASSERT(sb->sb_mb == sb->sb_lastrecord,("sbappendstream 1")); > (kgdb) l > 522 sbappendstream_locked(struct sockbuf *sb, struct mbuf *m) > 523 { > 524 SOCKBUF_LOCK_ASSERT(sb); > 525 > 526 KASSERT(m->m_nextpkt == NULL,("sbappendstream 0")); > 527 KASSERT(sb->sb_mb == sb->sb_lastrecord,("sbappendstream 1")); > 528 > 529 SBLASTMBUFCHK(sb); > 530 > 531 sbcompress(sb, m, sb->sb_mbtail); > (kgdb) p m > $1 = (struct mbuf *) 0x8885a600 > (kgdb) p m->m_hdr.mh_next > $2 = (struct mbuf *) 0x0 > (kgdb) p sb->sb_mb > $3 = (struct mbuf *) 0x93965e00 > (kgdb) p sb->sb_lastrecord > $4 = (struct mbuf *) 0x88cb0200 > (kgdb) p sb > $5 = (struct sockbuf *) 0x8bff1874 > > This sb belonged to smb_iod_thread which at that time was in > soreceive_stream(), notifying the protocol that buffer had been drained: > > #1 0x80d74cb7 in ipi_nmi_handler () at /usr/src/sys/i386/i386/mp_machdep.c:1478 > #2 0x80d7f383 in trap (frame=0xdc33ea58) at /usr/src/sys/i386/i386/trap.c:219 > #3 0x80d6886c in calltrap () at /usr/src/sys/i386/i386/exception.s:168 > #4 0x80a26955 in _rw_wlock_hard (rw=0x8d18fac0, tid=2285360576, > file=0x80f68ceb "/usr/src/sys/netinet/tcp_usrreq.c", line=732) at cpufunc.h:294 > #5 0x80a274d6 in _rw_wlock (rw=0x8d18fac0, > file=0x80f68ceb "/usr/src/sys/netinet/tcp_usrreq.c", line=732) > at /usr/src/sys/kern/kern_rwlock.c:240 > #6 0x80bdf585 in tcp_usr_rcvd (so=0x8bff1820, flags=64) > at /usr/src/sys/netinet/tcp_usrreq.c:732 > #7 0x80a9cf63 in soreceive_stream (so=0x8bff1820, psa=0x0, uio=0xdc33ec10, mp0=0xdc33ec44, > controlp=0x0, flagsp=0xdc33ec40) at /usr/src/sys/kern/uipc_socket.c:2097 > #8 0x80a9a6c9 in soreceive (so=0x8bff1820, psa=0x0, uio=0xdc33ec10, mp0=0xdc33ec44, > controlp=0x0, flagsp=0xdc33ec40) at /usr/src/sys/kern/uipc_socket.c:2309 > #9 0x91165e14 in nbssn_recv (nbp=0x874a49c0, mpp=0xdc33ec98, lenp=0xdc33ec64, > rpcodep=0xdc33ec6b "", td=0x8837d5c0) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_trantcp.c:378 > #10 0x91165fee in smb_nbst_recv (vcp=0x8961ae00, mpp=0xdc33ec98, td=0x8837d5c0) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_trantcp.c:598 > #11 0x9116bda1 in smb_iod_recvall (iod=0x88c64980) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:305 > #12 0x9116c82c in smb_iod_thread (arg=0x88c64980) > at /usr/src/sys/modules/smbfs/../../netsmb/smb_iod.c:645 > #13 0x809fa7a8 in fork_exit (callout=0x9116c600, arg=0x88c64980, > frame=0xdc33ed28) at /usr/src/sys/kern/kern_fork.c:1029 > #14 0x80d68914 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:275 > (kgdb) fr 7 > #7 0x80a9cf63 in soreceive_stream (so=0x8bff1820, psa=0x0, uio=0xdc33ec10, mp0=0xdc33ec44, > controlp=0x0, flagsp=0xdc33ec40) at /usr/src/sys/kern/uipc_socket.c:2097 > 2097 (*so->so_proto->pr_usrreqs->pru_rcvd)(so, flags); > (kgdb) l > 2092 if ((so->so_proto->pr_flags& PR_WANTRCVD)&& > 2093 (((flags& MSG_WAITALL)&& uio->uio_resid> 0) || > 2094 !(flags& MSG_SOCALLBCK))) { > 2095 SOCKBUF_UNLOCK(sb); > 2096 VNET_SO_ASSERT(so); > 2097 (*so->so_proto->pr_usrreqs->pru_rcvd)(so, flags); > 2098 SOCKBUF_LOCK(sb); > 2099 } > 2100 } > 2101 > (kgdb) p sb > $6 = (struct sockbuf *) 0x8bff1874 > (kgdb) p uio->uio_resid > $7 = 0 > > I think that after draining mbufs in the "Dequeue as many mbufs as possible" > part, and if there is still data in the socket buffer, we have to update > sb_lastrecord (as it is done in soreceive_generic). See the attached patch. > From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 19:55:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC581106564A; Tue, 6 Mar 2012 19:55:31 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF818FC17; Tue, 6 Mar 2012 19:55:31 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q26Jt5bX024079; Tue, 6 Mar 2012 11:55:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1331063706; bh=WJQj6FVfk2z+ziHA6SF3V1oUsTBLXkl0/6u1u+AToiU=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=wbQws/xFjZ9hHSRFUs4x27DpbBXhjy1CNu8gNExonQap40gmPHDNttAu9YSWGzFay Vcyes5zOT9/k1ncAYCD3FxGXi3Zd7twCVhW5wNkjhK+D7V0ugQ/QODG8jEj6PNWy+a Q/BbEjwOqCLEO0uijMfeqo4h1n7VfXBq28lC8cl4= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20120224180653.GA18456@michelle.cdnetworks.com> References: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> <20120223213344.GC13815@michelle.cdnetworks.com> <1330021403.3443.11.camel@powernoodle-l7.corp.yahoo.com> <20120224180653.GA18456@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 06 Mar 2012 11:55:05 -0800 Message-ID: <1331063705.2782.5.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bge(4) failure, Dell 12G hardware, BCM5720C X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:55:31 -0000 On Fri, 2012-02-24 at 10:06 -0800, YongHyeon PYUN wrote: > On Thu, Feb 23, 2012 at 10:23:23AM -0800, Sean Bruno wrote: > > > > > As you see ukphy(4) was attached to bge2 so it may cause various > > > issues. > > > Is bge2 ASF/IPMI enabled interface? It seems ASF handling in > > > bge(4) causes more trouble on recent controllers. Unfortunately > > > disabling ASF may also trigger other problems like NMI. > > > I believe bge(4) should always honor ASF/IMPI firmware instead of > > > relying on hw.bge.allow_asf tunable and have to strictly follow > > > firmware handshake sequence. Just ignoring ASF/IMPI firmware seems > > > to confuse firmware. > > > Unfortunately all these information is undocumented and fixing it > > > requires real hardware access. > > > > ASF/IPMI -- I've tried disabling things, but it just fails miserably. I > > can at least get the host to a login via serial console and poke at > > things. > > > > Do you want me to rig up a test for you on this box? I suspect I can do > > something temporarily in the freebsd cluster with this box. > > > > Hmm, I still have to understand what is correct handshake sequence > for ASF/IPMI firmware. This handshake may be related with suspend/ > resume as well as WOL. I'll let you know when I have experimental > patch. > > > Sean > > As a point of interest, we installed red hat's 6.2 release and it appears to understand and be able to talk to this controller without any issue. I guess I can try to get more documents out of my Dell contacts. Sean From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 21:54:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A147106566C for ; Tue, 6 Mar 2012 21:54:36 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 9ED248FC0A for ; Tue, 6 Mar 2012 21:54:35 +0000 (UTC) Received: (qmail invoked by alias); 06 Mar 2012 21:54:22 -0000 Received: from g230070013.adsl.alicedsl.de (EHLO [192.168.178.28]) [92.230.70.13] by mail.gmx.com (mp-eu002) with SMTP; 06 Mar 2012 22:54:22 +0100 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX18UB58vRUcUe5EzBEu72KpiBRZMYz2pqZngbqnIOz rWjMA7203pKdVW Message-ID: <4F56877E.5000608@gmx.com> Date: Tue, 06 Mar 2012 22:54:06 +0100 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: panic using ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:54:36 -0000 Hi, I got this kernel panic while playing around with IPsec: > Unread portion of the kernel message buffer: > 0x26 > kdb_backtrace(c0a5da40,1,ffffffff,c124f67c,c4bc15a4,...) at kdb_backtrace+0x2a > _witness_debugger(c0f7c8d0,c4bc15b8,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0fcd403,c4bc15dc,c78e2b30,...) at witness_warn+0x1fe > trap(c4bc1644) at trap+0x1a4 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0c06985, esp = 0xc4bc1684, ebp = 0xc4bc16ac --- > ipsec_process_done(c76e2800,c4f43c80,399,8,8,...) at ipsec_process_done+0x195 > esp_output_cb(c7b24000,c76e2800,c7386d40,c4bc1714,c0c2500e,...) at esp_output_cb+0x1aa > crypto_done(c7b24000,c76e2800,6c,c,c4bc1880,...) at crypto_done+0xb7 > swcr_process(c4d48700,c7b24000,0,2,c7378840,...) at swcr_process+0x12ce > crypto_invoke(101,0,c10b52e0,c7413500,c7b28000,...) at crypto_invoke+0x141 > crypto_dispatch(c7b24000,c0fa6385,367,c4bc198b,c73c2e00,...) at crypto_dispatch+0x64 > esp_output(c76e2800,c4f43c80,0,14,9,...) at esp_output+0x5a6 > ipsec4_process_packet(c76e2800,c4f43c80,20,0,c78f6000,...) at ipsec4_process_packet+0x29f > ip_ipsec_output(c4bc1a94,c78f6000,c4bc1ae4,c4bc1a9c,4,...) at ip_ipsec_output+0x1e0 > ip_output(c76e2800,0,0,20,0,...) at ip_output+0x804 > rip_output(c76e2800,c7ab9b60,6400000a,c4bc1b78,c0a9714d,...) at rip_output+0x2ff > rip_send(c7ab9b60,0,c76e2800,c743d170,0,...) at rip_send+0x76 > sosend_generic(c7ab9b60,c743d170,c4bc1bd0,0,0,...) at sosend_generic+0x50d > sosend(c7ab9b60,c743d170,c4bc1bd0,0,0,...) at sosend+0x3f > kern_sendit(c7471000,3,c4bc1c44,0,0,...) at kern_sendit+0x1d4 > sendit(0,c743d170,10,c4bc1c60,1,...) at sendit+0xce > sys_sendto(c7471000,c4bc1cec,c0fcd336,c0f7df79,246,...) at sys_sendto+0x48 > syscall(c4bc1d28) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (133, FreeBSD ELF32, sys_sendto), eip = 0x28199003, esp = 0xbfbee71c, ebp = 0xbfbee758 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x60 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0c06985 > stack pointer = 0x28:0xc4bc1684 > frame pointer = 0x28:0xc4bc16ac > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1264 (ping) I was using the following configuration files and did a ping to initiate the IPsec SA. > lab# cat setkey_router.conf > flush; > spdflush; > > spdadd 10.0.0.0/24 10.0.0.0/24 any -P out ipsec > esp/transport//require > ah/transport//require; > > spdadd 10.0.0.0/24 10.0.0.0/24 any -P in ipsec > esp/transport//require > ah/transport//require; > lab# > lab# cat router_psk.txt > 10.0.0.10 beef > 10.0.0.100 beef > 10.0.0.1 beef > 10.0.0.2 beef > 10.0.0.3 beef > lab# cat racoon_router.conf > path pre_shared_key "/root/router_psk.txt"; > > remote anonymous { > exchange_mode main; > proposal { > encryption_algorithm 3des; > hash_algorithm md5; > authentication_method pre_shared_key; > dh_group modp1024; > } > } > > sainfo anonymous { > pfs_group modp768; > encryption_algorithm 3des; > authentication_algorithm hmac_md5; > compression_algorithm deflate; > } > lab# Should I better file a PR? Thanks in advance, Nikos From owner-freebsd-net@FreeBSD.ORG Tue Mar 6 22:35:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9216D106567C for ; Tue, 6 Mar 2012 22:35:38 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 234558FC12 for ; Tue, 6 Mar 2012 22:35:38 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 67A7C25D3A47; Tue, 6 Mar 2012 22:35:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 969FDBDCD79; Tue, 6 Mar 2012 22:35:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 25aTz3gpginM; Tue, 6 Mar 2012 22:35:34 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CE7CCBDCD7C; Tue, 6 Mar 2012 22:35:34 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F56877E.5000608@gmx.com> Date: Tue, 6 Mar 2012 22:35:33 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1A541A79-9730-4EAA-8118-D421B5A8BF05@lists.zabbadoz.net> References: <4F56877E.5000608@gmx.com> To: Nikos Vassiliadis X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: panic using ipsec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:35:38 -0000 On 6. Mar 2012, at 21:54 , Nikos Vassiliadis wrote: > Hi, > > I got this kernel panic while playing around with IPsec: > ... > Should I better file a PR? Best follow-up on kern/164400 /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 03:29:25 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0C21106566B; Wed, 7 Mar 2012 03:29:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 834E98FC18; Wed, 7 Mar 2012 03:29:25 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so147217pbc.13 for ; Tue, 06 Mar 2012 19:29:19 -0800 (PST) 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=sV0+F5hLPGrlTaYd6HCfeyhi4RWYXMSIVREOzXuHTko=; b=iGRPvG0nHq0YMsJ8RpLTgHYa1QP9wke/oueBA2K1P+hz39uzuiBABKrfUn1SvQJuy5 UlAcK8fJpwChbwG1YZCeUJvqdAhZyJeQ2vUvShJBbiBhld8go4lWKf20yZTZQbHnFRNP WBDWE5hH2fe1aBsekXofN954HeRw1TpL358Wh01KGyaIOrZUdxmn0KJYcLH66obxwdoF T/AmmUvfqJitkNrVhymN2Q2gyWmdAr6vcSkQTeKf5tUyDfkmoa3P/lM9lk9qBmjWXlgo bseJzInYKnswVcvgE5cuupKNTCBMgGmUXXUIA39ddog4yuyKAvg6u8Vf0Yzr1qoBXIvZ k7vQ== Received: by 10.68.130.72 with SMTP id oc8mr1374668pbb.115.1331090959407; Tue, 06 Mar 2012 19:29:19 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id j3sm16046pbb.29.2012.03.06.19.29.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 19:29:18 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 07 Mar 2012 12:29:14 -0800 From: YongHyeon PYUN Date: Wed, 7 Mar 2012 12:29:14 -0800 To: Eugene Grosbein Message-ID: <20120307202914.GB9436@michelle.cdnetworks.com> References: <4F5608EA.6080705@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5608EA.6080705@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:29:25 -0000 On Tue, Mar 06, 2012 at 07:54:02PM +0700, Eugene Grosbein wrote: > Hi! > > Yesterday I've updated old HP ProLiant DL360 G4p to 8.3-PRELELEASE/amd64 > running busy icecast2 server in hope it can saturate 1G bge(4) link. > > This server has PCI-X connected HP NC7782 Gigabit Server Adapter (BCM5704). Would you show me the output of dmesg(bge(4) and brgphy(4) related ones)? > Is it supposed to emit more than 540Mbit/s with average packet size equal to 1300? > Yes. > netstat shows increasing "Drop" counters: > > # netstat -id > Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop > bge0 1500 00:18:fe:86:ab:f4 635577217 0 0 1047897138 0 0 454509 > > vmstat shows relatively high but pretty sane interrupt rate: > > # vmstat -i | grep bge > irq25: bge0 232949783 10149 > > Input traffic is less than 20Mbit/s meantime, output does not go above 540Mbit/s. > Its mbufs usage is normal (server has 2G RAM): > > # netstat -m > 13459/15986/29445 mbufs in use (current/cache/total) > 13322/13112/26434/262144 mbuf clusters in use (current/cache/total/max) > 13322/13046 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/104/104/131072 4k (page size) jumbo clusters in use (current/cache/total/max) > 0/0/0/65536 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/32768 16k jumbo clusters in use (current/cache/total/max) > 30008K/30636K/60645K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > I've glanced at bge(4) code and see it uses lots of hardcoded constants > for rx/tx descriptor rings, for interrupt moderation and for interface FIFO queue. Firmware has a fixed number of descriptors so increasing them wouldn't give better numbers. > And no loader tunnables/sysctls like em/igb have. > Show me the output of "sysctl dev.bge.0.stats". > Should I try to play with constants in the code and if so, what are limits of this chip? > Or it will never be capable of utilizing full gigabit speed? BCM5704 is old controller but it should have no problems to saturate the link. I suspect it could be related with DMA configuration but needs more information. > > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 03:51:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6971B106564A for ; Wed, 7 Mar 2012 03:51:47 +0000 (UTC) (envelope-from leschnik@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 275168FC18 for ; Wed, 7 Mar 2012 03:51:46 +0000 (UTC) Received: by yhgm50 with SMTP id m50so3067245yhg.13 for ; Tue, 06 Mar 2012 19:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gQ+J2FZcHLvrxx1fGj++ZbhNCra9lOdonwFG4+tus4c=; b=x5thAUUdHOavpHBW1ex2O7PJFsGzoYnKX1XI0E6nExGSmRUUGEXF+hZPlKcJrTNvkv QHCi2JxJR1VE23o6L5cBYr9qxkTXZwiJGk2kVYVH45VeaLQKcQ7FiHsF/QmwH/7LuXz8 JY7O6FHk19QAVEeNHqRPvIYowKV1aDhdBX4w4lSTXd0jUtiYGbxN/imFdFvl1Uh/56sn cW+yQDz1yp7TdK85LdSrIiHbkZUWG1kD6eQEVQHgAX/zCGwnCVquJBG61Mo6Q9NF4ekK bbW8PV+0RpBMrnvSkxTPBHc7v9Snz86XXv7LI1IDkd00M4MaRoCcvXKee51pxVhe78q2 Bq8A== MIME-Version: 1.0 Received: by 10.236.46.134 with SMTP id r6mr541065yhb.106.1331090912509; Tue, 06 Mar 2012 19:28:32 -0800 (PST) Received: by 10.100.11.7 with HTTP; Tue, 6 Mar 2012 19:28:32 -0800 (PST) Date: Wed, 7 Mar 2012 14:28:32 +1100 Message-ID: From: Jason Leschnik To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Lagg failover does not announce the failover to switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:51:47 -0000 Lagg failover does not gratuitous ARP on the new interface to announce the link failover - This leaves clients trying to access the failed link and never making it to the up'd link. Bug ID: 156226 Found on this todo list: http://wiki.freebsd.org/EdMaste/ToDo I was wondering if i could offer a donation Hardware/Money to get this fixed, in my opinion this is a very important feature for the platform. I understand there are other ways to correct the behavior but one would expect this to be solved in the driver. I think as a server platform with many users just taking for granted that this works, but it does not :( Any workarounds or offers? ARP aging? Thankyou. --=20 Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@]=A0jml974@uow.edu.au From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 07:10:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C415B1065674 for ; Wed, 7 Mar 2012 07:10:41 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2AA8FC19 for ; Wed, 7 Mar 2012 07:10:41 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so9424561obb.13 for ; Tue, 06 Mar 2012 23:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YkXAJjZnznu9QgEPf2RvRiooR3l7TcCCaPIr3qSH2AE=; b=YrZsD5Z+xf0taNUMbglvJbW8ukt2dyf4lpWfe+dcsQ56me8ZWr/TIwA+710t0ZWz1H 1PWgLf7WdAZguUd9fWpQbcAOPt+uRneUlR0DxOxvybwIpLkl1JQNa8NkgsQU7yQWy9xg pwMVI9BqXCUG4t+mkOAUjx0N38MQLZrB/kj1x+//Yk8y4W6YVdizxz7d2VyZXL0PBQMK QFWaSnVzZOmyIX9UT7R7D/sFShhy2+9Hs2BFMoUd2Nj1v0hmtf5FC1wnAvABgmVDuYwc wEMDjFELUIJSs9q/2ar0V9ECVeTGUgIJhrGKS3X2ol/XKgOoHqia9bgyCw+7Tzsp18p4 HDQQ== MIME-Version: 1.0 Received: by 10.60.7.7 with SMTP id f7mr394878oea.19.1331104241087; Tue, 06 Mar 2012 23:10:41 -0800 (PST) Received: by 10.182.11.101 with HTTP; Tue, 6 Mar 2012 23:10:40 -0800 (PST) Date: Tue, 6 Mar 2012 23:10:40 -0800 Message-ID: From: hiren panchasara To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:10:41 -0000 Do we store network interfaces configuration information in any file that survives reboots? (as Linux does it in /etc/network/interfaces) Only thing I could find was when an interface needs address from DHCP, rc.conf says ifconfig_em0="DHCP". I know getifaddrs() can get you list of interfaces but I wanted to know if there is any such file. Thanks, Hiren From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 08:09:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03045106566B for ; Wed, 7 Mar 2012 08:09:23 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8BBCA8FC0C for ; Wed, 7 Mar 2012 08:09:22 +0000 (UTC) Received: by werl4 with SMTP id l4so4745560wer.13 for ; Wed, 07 Mar 2012 00:09:21 -0800 (PST) Received: by 10.180.84.164 with SMTP id a4mr2008505wiz.2.1331107761577; Wed, 07 Mar 2012 00:09:21 -0800 (PST) Received: from [192.168.0.12] (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id dw7sm34075497wib.4.2012.03.07.00.09.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 00:09:20 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Wed, 7 Mar 2012 09:08:30 +0100 To: hiren panchasara X-Gm-Message-State: ALoCoQn3hPK7+Fg9O21hCy2QRbY5XQQGvah1YS/9nFqmhVg7wwM4qxsgT4JE/37BYvPv0/qnTH6d Cc: "freebsd-net@freebsd.org" Subject: Re: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:09:23 -0000 On 7 Mar 2012, at 08:10, hiren panchasara wrote: > Do we store network interfaces configuration information in any file that > survives reboots? (as Linux does it in /etc/network/interfaces) > > Only thing I could find was when an interface needs address from DHCP, > rc.conf says ifconfig_em0="DHCP". > > I know getifaddrs() can get you list of interfaces but I wanted to know if > there is any such file. > > Thanks, > Hiren > _______________________________________________ > 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" In /etc/rc.conf See the man page for rc.conf for a more detailed use. See the small example bellow: ifconfig_re0="inet 192.168.0.30/24 up" defaultrouter="192.168.0.254" These are the very basics ;) From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 08:12:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E402C106564A; Wed, 7 Mar 2012 08:12:36 +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 1573E8FC16; Wed, 7 Mar 2012 08:12:35 +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 q278CW9O004159; Wed, 7 Mar 2012 15:12:33 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F571870.3090902@rdtc.ru> Date: Wed, 07 Mar 2012 15:12:32 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> In-Reply-To: <20120307202914.GB9436@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:12:37 -0000 08.03.2012 03:29, YongHyeon PYUN РЙЫЕФ: > On Tue, Mar 06, 2012 at 07:54:02PM +0700, Eugene Grosbein wrote: >> Hi! >> >> Yesterday I've updated old HP ProLiant DL360 G4p to 8.3-PRELELEASE/amd64 >> running busy icecast2 server in hope it can saturate 1G bge(4) link. >> >> This server has PCI-X connected HP NC7782 Gigabit Server Adapter (BCM5704). > > Would you show me the output of dmesg(bge(4) and brgphy(4) related > ones)? # egrep 'bge|brgphy' /var/run/dmesg.boot bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:18:fe:86:ab:f4 bge0: [ITHREAD] bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:18:fe:86:ab:f3 bge1: [ITHREAD] There are bge0 and bge1 but bge1 is not used and is down. >> Is it supposed to emit more than 540Mbit/s with average packet size equal to 1300? >> > > Yes. [skip] >> I've glanced at bge(4) code and see it uses lots of hardcoded constants >> for rx/tx descriptor rings, for interrupt moderation and for interface FIFO queue. > > Firmware has a fixed number of descriptors so increasing them > wouldn't give better numbers. What it the limit? >> And no loader tunnables/sysctls like em/igb have. > > Show me the output of "sysctl dev.bge.0.stats". # sysctl dev.bge.0.stats dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 84072 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 30 dev.bge.0.stats.RecvThresholdHit: 745400662 dev.bge.0.stats.DmaReadQueueFull: 2020586592 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 2832885493 dev.bge.0.stats.RingStatusUpdate: 899990835 dev.bge.0.stats.Interrupts: 899990835 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.ifHCInOctets: 491268800 dev.bge.0.stats.rx.Fragments: 234 dev.bge.0.stats.rx.UnicastPkts: 1977202324 dev.bge.0.stats.rx.MulticastPkts: 0 dev.bge.0.stats.rx.FCSErrors: 341 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.ifHCOutOctets: 683592718 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UnicastPkts: 3292778353 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 147 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 >> Should I try to play with constants in the code and if so, what are limits of this chip? >> Or it will never be capable of utilizing full gigabit speed? > > BCM5704 is old controller but it should have no problems to > saturate the link. I suspect it could be related with DMA > configuration but needs more information. I'll supply any information. It's also possible to try kernel patches, if any :-) Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 08:21:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D85A31065670 for ; Wed, 7 Mar 2012 08:21:54 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF778FC1D for ; Wed, 7 Mar 2012 08:21:54 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so9519357obb.13 for ; Wed, 07 Mar 2012 00:21:54 -0800 (PST) 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=/yWJJZAuZVp+ULCWdHOR1s5Ss212lM4N5mrTyJJzQxo=; b=uRB+s5yBcP6Bhd7xXf1kmLQfaR0rHKrfReFWTTeq5cPz1Rgpli/HMnyXKXmr2yninz U2nXB3sRoee91zU2/Clkp8Fb5TNzn4OnwBokmZKAZWwk4Hz1HRZb4sBE8zSw3tYZ78dn 6id54V3l9cO+jiuqJws1rzZMg0JgWXUiDe5gGqhhWiJPmW3Y8ONcbRWTb4dMHPrA4POZ osLLu/NDQlIqgetxUR9SIBuMxjUn8SzRFPZxXlx8p2Fj7DyWA5EO5Y7xRCx6ZBYLXNDM p9BtnciftjTTg7AV6OdX4Dth6iBxDYkNuUhGgwbRRSfUu9fCi5YSQ/ybn/7mTCuXqs8M gTrA== MIME-Version: 1.0 Received: by 10.182.193.73 with SMTP id hm9mr471044obc.29.1331108514085; Wed, 07 Mar 2012 00:21:54 -0800 (PST) Received: by 10.182.11.101 with HTTP; Wed, 7 Mar 2012 00:21:54 -0800 (PST) In-Reply-To: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> References: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> Date: Wed, 7 Mar 2012 00:21:54 -0800 Message-ID: From: hiren panchasara To: Damien Fleuriot Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: Re: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:21:54 -0000 On Wed, Mar 7, 2012 at 12:08 AM, Damien Fleuriot wrote: > > In /etc/rc.conf > > See the man page for rc.conf for a more detailed use. > See the small example bellow: > > ifconfig_re0="inet 192.168.0.30/24 up" > defaultrouter="192.168.0.254" > > These are the very basics ;) > Thanks Damien. I looked at the man page. I did "ifconfig" on my box and found an interface named fwe0. I do not see any entry for that in any /etc/rc.conf or /etc/defaults/rc.conf Where is that coming from? Am I missing anything? Appreciate your help, Hiren From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 08:49:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1F31106564A for ; Wed, 7 Mar 2012 08:49:25 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 735AC8FC14 for ; Wed, 7 Mar 2012 08:49:24 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so5159055wgb.31 for ; Wed, 07 Mar 2012 00:49:24 -0800 (PST) Received: by 10.180.104.137 with SMTP id ge9mr2124778wib.20.1331110164182; Wed, 07 Mar 2012 00:49:24 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Wed, 7 Mar 2012 00:49:04 -0800 (PST) In-Reply-To: References: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> From: Juli Mallett Date: Wed, 7 Mar 2012 00:49:04 -0800 X-Google-Sender-Auth: fu-sa8G0LDn0kcj3zd9uHxtHRao Message-ID: To: hiren panchasara Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmZJOIrePvDcaIAo+LP4ZgNMi058WwFC8awXiNVQZY5s9t54EL0HNPAPIGTUQvV5ojhXdIN Cc: "freebsd-net@freebsd.org" , Damien Fleuriot Subject: Re: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:49:26 -0000 On Wed, Mar 7, 2012 at 00:21, hiren panchasara wrote: > On Wed, Mar 7, 2012 at 12:08 AM, Damien Fleuriot wrote: >> In /etc/rc.conf >> >> See the man page for rc.conf for a more detailed use. >> See the small example bellow: >> >> ifconfig_re0="inet 192.168.0.30/24 up" >> defaultrouter="192.168.0.254" >> >> These are the very basics ;) >> > > Thanks Damien. > > I looked at the man page. I did "ifconfig" on my box and found an interface > named fwe0. I do not see any entry for that in any /etc/rc.conf or > /etc/defaults/rc.conf > > Where is that coming from? > > Am I missing anything? Interfaces are created based on what is present in the kernel and what hardware is present on your system. The configuration of those interfaces (e.g. associated IP addresses, media options, etc.) is done at runtime by scripts in /etc. Those scripts use rc.conf to determine how to configure the interfaces. So if you do: ifconfig_bge0="inet 192.168.0.1/24" Then your bge0 interface will be configured with those settings on boot (or when you do /etc/rc.d/netif restart). If there is no bge0 interface on your system, however, because the hardware is not present or the driver is not in your kernel (or loaded as a module), then nothing will happen. That interface will not be created. You can create some kinds of interfaces dynamically, and you can rename interfaces, but those things are probably a distraction from what you want and excessively confusing. In general, interfaces do not come from the configuration files like rc.conf, however the way that those interfaces are set up on boot is configured by files like rc.conf. From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 09:05:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 735411065673 for ; Wed, 7 Mar 2012 09:05:40 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F28888FC0C for ; Wed, 7 Mar 2012 09:05:38 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6694995bkc.13 for ; Wed, 07 Mar 2012 01:05:38 -0800 (PST) Received: by 10.204.15.205 with SMTP id l13mr502496bka.99.1331111138013; Wed, 07 Mar 2012 01:05:38 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id je3sm36959199bkb.15.2012.03.07.01.05.36 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 01:05:37 -0800 (PST) Message-ID: <4F5724E2.3080309@my.gd> Date: Wed, 07 Mar 2012 10:05:38 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: hiren panchasara References: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkoH1yTh5JEfM7Hpo9XNg57I0s05TSVuyMKb8xnueRxIaP+O0PTxUfGEjD66tJarczZg7hU Cc: "freebsd-net@freebsd.org" Subject: Re: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 09:05:40 -0000 On 3/7/12 9:21 AM, hiren panchasara wrote: > > > On Wed, Mar 7, 2012 at 12:08 AM, Damien Fleuriot > wrote: > > > In /etc/rc.conf > > See the man page for rc.conf for a more detailed use. > See the small example bellow: > > ifconfig_re0="inet 192.168.0.30/24 up" > defaultrouter="192.168.0.254" > > These are the very basics ;) > > > Thanks Damien. > > I looked at the man page. I did "ifconfig" on my box and found an > interface named fwe0. I do not see any entry for that in any > /etc/rc.conf or /etc/defaults/rc.conf > > Where is that coming from? > > Am I missing anything? > > Appreciate your help, > Hiren > The specific parts you'll want to look for, in rc.conf's man page are: ifconfig_ These describe how to permanently setup your network cards. Notice that unlike linux where cards share the same name (ethX), in freebsd your cards are named after the driver that is used. For example, most Intel cards use either "em" or "igb". Regarding your setup, you'll want to use "ifconfig_fwe0" instead of "ifconfig_re0". From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 09:24:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 845BC106564A; Wed, 7 Mar 2012 09:24:07 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35CFA8FC18; Wed, 7 Mar 2012 09:24:07 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so9613120obb.13 for ; Wed, 07 Mar 2012 01:24:06 -0800 (PST) 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=Ys2fNoJ0U3RgoPMUcjT9tDs65roVBUOi6JpCtXidKfU=; b=MCI5ADPbExpzO2F5m4UU0ckviWdoRa6qh3P1bXyP2+BUsaOekzWu1wTf0iRwX7SC6j ZVaGpvuyNDHLr5V+zViZoZSo7z9/lNi6nW7ZwcGQRBvphSEKtfRAMQKoZnjaqEa3ftNc 63z6oMLmYcy9NpbBQ5ZXOLre1ClrpUJ/ntlV55Apkfr7FD2OYYBK0u6reNtt8+1Tzd9d vBQfAYPvz7jhwy+IZLWSIU2CYaER+FNKOQhOXUkB3iPOzL5PfLg+Z4kKAA2YDy4Ixxi7 1jClQdxMDaZRkQz81NpHwBunDReLSy4cM4RFtXwoWAx1dj2ZHkO1DIABCNql7axXny4I E0RA== MIME-Version: 1.0 Received: by 10.60.4.105 with SMTP id j9mr518215oej.29.1331112246882; Wed, 07 Mar 2012 01:24:06 -0800 (PST) Received: by 10.182.11.101 with HTTP; Wed, 7 Mar 2012 01:24:06 -0800 (PST) In-Reply-To: References: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> Date: Wed, 7 Mar 2012 01:24:06 -0800 Message-ID: From: hiren panchasara To: Juli Mallett Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Damien Fleuriot Subject: Re: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 09:24:07 -0000 On Wed, Mar 7, 2012 at 12:49 AM, Juli Mallett wrote: > In general, interfaces do > not come from the configuration files like rc.conf, however the way > that those interfaces are set up on boot is configured by files like > rc.conf. > Thanks Juli. So, does it mean that looking at getifaddrs() is the best way (as ifconfig is doing) to get the correct state of network interfaces at any point in time? And for the interface of your interest, you can check if rc.conf is specifying any persistent configuration or not. Hiren From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 10:43:51 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7B7D106566B; Wed, 7 Mar 2012 10:43:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 859978FC13; Wed, 7 Mar 2012 10:43:51 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so459857pbc.13 for ; Wed, 07 Mar 2012 02:43:51 -0800 (PST) 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=8ehLhCQTJB76OtrijVWxX37IFQyaifVogoa86jti9d0=; b=XbgP///JMDHigzDhgkXQ37L4fHMBWbVASdPRW0LESDeDM2S/zk7xdaqEti7JkpeYk/ tXdyh6t9ESDYUQcBRGlktO9fTOCp0j9bxbJZSZ6sxMIqALhLVdUbiIP8TqDG6xoa0ZGl 35R2MPX8PehwQSzaOebc+RShlq1M3aL6rlkeGAiToFWjzDM1vggiyESKHizDsclG1GyF l2uBe3N3JNTYy3Te92SSSgwQ8NnTa7fpYe5dupQo2IIhwJmCU/zH8lC6vcSrdqvhdV0K 2uNGtAuJ9ULj9zWsDuzLBu6yZNbDmDCwGqqHytMb321h+kNBNVq447h3lqihBUlDT6u2 Lq+w== Received: by 10.68.235.34 with SMTP id uj2mr3085099pbc.74.1331117031049; Wed, 07 Mar 2012 02:43:51 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id ko12sm564312pbb.52.2012.03.07.02.43.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 02:43:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 07 Mar 2012 19:43:45 -0800 From: YongHyeon PYUN Date: Wed, 7 Mar 2012 19:43:45 -0800 To: Eugene Grosbein Message-ID: <20120308034345.GD9436@michelle.cdnetworks.com> References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F571870.3090902@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:43:51 -0000 On Wed, Mar 07, 2012 at 03:12:32PM +0700, Eugene Grosbein wrote: > 08.03.2012 03:29, YongHyeon PYUN пишет: > > On Tue, Mar 06, 2012 at 07:54:02PM +0700, Eugene Grosbein wrote: > >> Hi! > >> > >> Yesterday I've updated old HP ProLiant DL360 G4p to 8.3-PRELELEASE/amd64 > >> running busy icecast2 server in hope it can saturate 1G bge(4) link. > >> > >> This server has PCI-X connected HP NC7782 Gigabit Server Adapter (BCM5704). > > > > Would you show me the output of dmesg(bge(4) and brgphy(4) related > > ones)? > > # egrep 'bge|brgphy' /var/run/dmesg.boot > bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 > bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: Ethernet address: 00:18:fe:86:ab:f4 > bge0: [ITHREAD] > bge1: mem 0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2 > bge1: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge1: Ethernet address: 00:18:fe:86:ab:f3 > bge1: [ITHREAD] > It seems your controller is BCM5704 B2 and it is running in PCI-X mode. There is one known BCM5704 issue but I don't think you're seeing this one. To confirm that could you show me both the output of "pciconf -lcbv" and "devinfo -rv"? > There are bge0 and bge1 but bge1 is not used and is down. > > >> Is it supposed to emit more than 540Mbit/s with average packet size equal to 1300? > >> > > > > Yes. > > [skip] > > >> I've glanced at bge(4) code and see it uses lots of hardcoded constants > >> for rx/tx descriptor rings, for interrupt moderation and for interface FIFO queue. > > > > Firmware has a fixed number of descriptors so increasing them > > wouldn't give better numbers. > > What it the limit? > Both TX and RX have 512 descriptors. > >> And no loader tunnables/sysctls like em/igb have. > > > > Show me the output of "sysctl dev.bge.0.stats". > > # sysctl dev.bge.0.stats > dev.bge.0.stats.FramesDroppedDueToFilters: 0 > dev.bge.0.stats.DmaWriteQueueFull: 84072 > dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 > dev.bge.0.stats.NoMoreRxBDs: 0 > dev.bge.0.stats.InputDiscards: 0 > dev.bge.0.stats.InputErrors: 30 > dev.bge.0.stats.RecvThresholdHit: 745400662 > dev.bge.0.stats.DmaReadQueueFull: 2020586592 > dev.bge.0.stats.DmaReadHighPriQueueFull: 0 > dev.bge.0.stats.SendDataCompQueueFull: 0 > dev.bge.0.stats.RingSetSendProdIndex: 2832885493 > dev.bge.0.stats.RingStatusUpdate: 899990835 > dev.bge.0.stats.Interrupts: 899990835 > dev.bge.0.stats.AvoidedInterrupts: 0 > dev.bge.0.stats.SendThresholdHit: 0 > dev.bge.0.stats.rx.ifHCInOctets: 491268800 > dev.bge.0.stats.rx.Fragments: 234 > dev.bge.0.stats.rx.UnicastPkts: 1977202324 > dev.bge.0.stats.rx.MulticastPkts: 0 > dev.bge.0.stats.rx.FCSErrors: 341 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You have multiple FCS and Input errors. Check signal quality(i.e. UTP cable). > dev.bge.0.stats.rx.AlignmentErrors: 0 > dev.bge.0.stats.rx.xonPauseFramesReceived: 0 > dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 > dev.bge.0.stats.rx.ControlFramesReceived: 0 > dev.bge.0.stats.rx.xoffStateEntered: 0 > dev.bge.0.stats.rx.FramesTooLong: 0 > dev.bge.0.stats.rx.Jabbers: 0 > dev.bge.0.stats.rx.UndersizePkts: 0 > dev.bge.0.stats.rx.inRangeLengthError: 0 > dev.bge.0.stats.rx.outRangeLengthError: 0 > dev.bge.0.stats.tx.ifHCOutOctets: 683592718 > dev.bge.0.stats.tx.Collisions: 0 > dev.bge.0.stats.tx.XonSent: 0 > dev.bge.0.stats.tx.XoffSent: 0 > dev.bge.0.stats.tx.flowControlDone: 0 > dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 > dev.bge.0.stats.tx.SingleCollisionFrames: 0 > dev.bge.0.stats.tx.MultipleCollisionFrames: 0 > dev.bge.0.stats.tx.DeferredTransmissions: 0 > dev.bge.0.stats.tx.ExcessiveCollisions: 0 > dev.bge.0.stats.tx.LateCollisions: 0 > dev.bge.0.stats.tx.UnicastPkts: 3292778353 > dev.bge.0.stats.tx.MulticastPkts: 0 > dev.bge.0.stats.tx.BroadcastPkts: 147 > dev.bge.0.stats.tx.CarrierSenseErrors: 0 > dev.bge.0.stats.tx.Discards: 0 > dev.bge.0.stats.tx.Errors: 0 > > >> Should I try to play with constants in the code and if so, what are limits of this chip? > >> Or it will never be capable of utilizing full gigabit speed? > > > > BCM5704 is old controller but it should have no problems to > > saturate the link. I suspect it could be related with DMA > > configuration but needs more information. > > I'll supply any information. It's also possible to try kernel patches, if any :-) Does netperf benchmark also show 540Mbps on bge(4)? > > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 10:59:21 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AC24106566C; Wed, 7 Mar 2012 10:59:21 +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 693168FC18; Wed, 7 Mar 2012 10:59:18 +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 q27AxFib006603; Wed, 7 Mar 2012 17:59:15 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F573F83.5090502@rdtc.ru> Date: Wed, 07 Mar 2012 17:59:15 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> In-Reply-To: <20120308034345.GD9436@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: marius@freebsd.org, "net@freebsd.org" , yongari@freebsd.org Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:59:21 -0000 08.03.2012 10:43, YongHyeon PYUN РЙЫЕФ: >>>> Yesterday I've updated old HP ProLiant DL360 G4p to 8.3-PRELELEASE/amd64 >>>> running busy icecast2 server in hope it can saturate 1G bge(4) link. >>>> >>>> This server has PCI-X connected HP NC7782 Gigabit Server Adapter (BCM5704). >>> >>> Would you show me the output of dmesg(bge(4) and brgphy(4) related >>> ones)? [skip] > > It seems your controller is BCM5704 B2 and it is running in PCI-X > mode. There is one known BCM5704 issue but I don't think you're > seeing this one. To confirm that could you show me both the output > of "pciconf -lcbv" and "devinfo -rv"? # pciconf -lcbv hostb0@pci0:0:0:0: class=0x060000 card=0x32000e11 chip=0x35908086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = 'E7520 Server Memory Controller Hub' class = bridge subclass = HOST-PCI cap 09[40] = vendor (length 5) Intel cap 4 version 1 pcib1@pci0:0:2:0: class=0x060400 card=0x00000000 chip=0x35958086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCIe Port A0' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[64] = PCI-Express 1 root port max data 256(256) link x0(x8) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected pcib2@pci0:0:4:0: class=0x060400 card=0x00000000 chip=0x35978086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCIe Port B0' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[64] = PCI-Express 1 root port max data 256(256) link x8(x8) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected pcib5@pci0:0:6:0: class=0x060400 card=0x00000000 chip=0x35998086 rev=0x0c hdr=0x01 vendor = 'Intel Corporation' device = 'E752x Memory Controller Hub PCIe Port C0' class = bridge subclass = PCI-PCI cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[64] = PCI-Express 1 root port max data 256(256) link x0(x8) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected pcib6@pci0:0:28:0: class=0x060400 card=0x00000000 chip=0x25ae8086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = 'Hub Interface to PCI-X Bridge (6300ESB)' class = bridge subclass = PCI-PCI cap 07[50] = PCI-X 64-bit bridge uhci0@pci0:0:29:0: class=0x0c0300 card=0x32010e11 chip=0x25a98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'USB 1.1 UHCI Controller *1 (6300ESB)' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x2000, size 32, enabled uhci1@pci0:0:29:1: class=0x0c0300 card=0x32010e11 chip=0x25aa8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'USB 1.1 UHCI Controller *2 (6300ESB)' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0x2020, size 32, enabled none0@pci0:0:29:4: class=0x088000 card=0x32010e11 chip=0x25ab8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Watchdog Timer (6300ESB)' class = base peripheral bar [10] = type Memory, range 32, base 0xfbef0000, size 16, enabled ioapic0@pci0:0:29:5: class=0x080020 card=0x32010e11 chip=0x25ac8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '6300ESB I/O Advanced Programmable Interrupt Controller' class = base peripheral subclass = interrupt controller cap 07[50] = PCI-X 64-bit supports 512 burst read, 1 split transaction ehci0@pci0:0:29:7: class=0x0c0320 card=0x32010e11 chip=0x25ad8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'USB 2.0 EHCI Controller (6300ESB)' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xfbee0000, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0x80 in map 0x14 pcib7@pci0:0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x0a hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x00000000 chip=0x25a18086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '6300ESB LPC Inteface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1: class=0x01018a card=0x32010e11 chip=0x25a28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'IDE Controller (6300ESB)' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled bar [20] = type I/O Port, range 32, base 0x500, size 16, enabled pcib3@pci0:6:0:0: class=0x060400 card=0x00000000 chip=0x03298086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express-to-PCI Express Bridge A (6700PXH)' class = bridge subclass = PCI-PCI cap 10[44] = PCI-Express 1 PCI bridge max data 256(256) link x8(x8) cap 05[5c] = MSI supports 1 message, 64 bit cap 01[6c] = powerspec 2 supports D0 D3 current D0 cap 07[d8] = PCI-X bridge ecap 0001[100] = AER 1 1 fatal 0 non-fatal 0 corrected ecap 0004[300] = unknown 1 pcib4@pci0:6:0:2: class=0x060400 card=0x00000000 chip=0x032a8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express-to-PCI Express Bridge B (6700PXH)' class = bridge subclass = PCI-PCI cap 10[44] = PCI-Express 1 PCI bridge max data 256(256) link x8(x8) cap 05[5c] = MSI supports 1 message, 64 bit cap 01[6c] = powerspec 2 supports D0 D3 current D0 cap 07[d8] = PCI-X bridge ecap 0001[100] = AER 1 1 fatal 0 non-fatal 0 corrected ecap 0004[300] = unknown 1 ciss0@pci0:2:1:0: class=0x010400 card=0x40910e11 chip=0x00460e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Smart Array 6400 Controller (N/A)' class = mass storage subclass = RAID bar [10] = type Memory, range 64, base 0xfdff0000, size 8192, enabled bar [18] = type I/O Port, range 32, base 0x4000, size 256, enabled bar [1c] = type Memory, range 64, base 0xfdf80000, size 262144, enabled cap 01[d0] = powerspec 2 supports D0 D1 D3 current D0 cap 07[dc] = PCI-X 64-bit supports 133MHz, 2048 burst read, 8 split transactions cap 03[f0] = VPD bge0@pci0:2:2:0: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfdf70000, size 65536, enabled cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit bge1@pci0:2:2:1: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfdf60000, size 65536, enabled cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit vgapci0@pci0:1:3:0: class=0x030000 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA bar [10] = type Memory, range 32, base 0xfc000000, size 16777216, enabled bar [14] = type I/O Port, range 32, base 0x3000, size 256, enabled bar [18] = type Memory, range 32, base 0xfbff0000, size 4096, enabled cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0 none1@pci0:1:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral bar [10] = type I/O Port, range 32, base 0x1800, size 256, enabled bar [14] = type Memory, range 32, base 0xfbfe0000, size 512, enabled cap 01[f0] = powerspec 2 supports D0 D3 current D0 none2@pci0:1:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral bar [10] = type I/O Port, range 32, base 0x3400, size 256, enabled bar [14] = type Memory, range 32, base 0xfbfd0000, size 2048, enabled bar [18] = type Memory, range 32, base 0xfbfc0000, size 8192, enabled bar [1c] = type Memory, range 32, base 0xfbf00000, size 524288, enabled cap 01[f0] = powerspec 2 supports D0 D3 current D0 # devinfo -rv nexus0 cryptosoft0 apic0 I/O memory addresses: 0xfec00000-0xfec0001f 0xfec10000-0xfec1001f 0xfec82000-0xfec8201f 0xfec82400-0xfec8241f 0xfee00000-0xfee003ff ram0 I/O memory addresses: 0x0-0x9f3ff 0x100000-0x7fff2fff acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x20-0x3f 0x50-0x53 0x70-0x77 0x90-0x9f 0xa0-0xbf 0x2f8-0x2ff 0x408-0x40f 0x4d0-0x4d1 0x700-0x71f 0x800-0x83f 0x900-0x97f 0xc80-0xc83 0xcd4-0xcd7 0xf50-0xf58 I/O memory addresses: 0xe0000000-0xefffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 p4tcc0 cpufreq0 cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 p4tcc1 cpufreq1 cpu2 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2 p4tcc2 cpufreq2 cpu3 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU3 p4tcc3 cpufreq3 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU4 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU5 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU6 unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU7 pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0 pci0 I/O memory addresses: 0xfbef0000-0xfbef000f hostb0 pnpinfo vendor=0x8086 device=0x3590 subvendor=0x0e11 subdevice=0x3200 class=0x060000 at slot=0 function=0 handle=\_SB_.PCI0.CFG0 pcib1 pnpinfo vendor=0x8086 device=0x3595 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=2 function=0 handle=\_SB_.PCI0.PTA0 pci13 pcib2 pnpinfo vendor=0x8086 device=0x3597 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=4 function=0 handle=\_SB_.PCI0.PTB0 pci6 pcib3 pnpinfo vendor=0x8086 device=0x0329 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=0 function=0 handle=\_SB_.PCI0.PTB0.PCXA pci7 pcib4 pnpinfo vendor=0x8086 device=0x032a subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=0 function=2 handle=\_SB_.PCI0.PTB0.PCXB pci10 pcib5 pnpinfo vendor=0x8086 device=0x3599 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=6 function=0 handle=\_SB_.PCI0.PTC0 pci3 pcib6 pnpinfo vendor=0x8086 device=0x25ae subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=28 function=0 handle=\_SB_.PCI0.ICHR pci2 I/O ports: 0x4000-0x40ff I/O memory addresses: 0xfdf80000-0xfdfbffff ciss0 pnpinfo vendor=0x0e11 device=0x0046 subvendor=0x0e11 subdevice=0x4091 class=0x010400 at slot=1 function=0 Interrupt request lines: 24 I/O memory addresses: 0xfdff0000-0xfdff1fff bge0 pnpinfo vendor=0x14e4 device=0x1648 subvendor=0x0e11 subdevice=0x00d0 class=0x020000 at slot=2 function=0 Interrupt request lines: 25 I/O memory addresses: 0xfdf70000-0xfdf7ffff miibus0 brgphy0 pnpinfo oui=0x818 model=0x19 rev=0x0 at phyno=1 bge1 pnpinfo vendor=0x14e4 device=0x1648 subvendor=0x0e11 subdevice=0x00d0 class=0x020000 at slot=2 function=1 Interrupt request lines: 26 I/O memory addresses: 0xfdf60000-0xfdf6ffff miibus1 brgphy1 pnpinfo oui=0x818 model=0x19 rev=0x0 at phyno=1 uhci0 pnpinfo vendor=0x8086 device=0x25a9 subvendor=0x0e11 subdevice=0x3201 class=0x0c0300 at slot=29 function=0 Interrupt request lines: 16 I/O ports: 0x2000-0x201f usbus0 uhub0 uhci1 pnpinfo vendor=0x8086 device=0x25aa subvendor=0x0e11 subdevice=0x3201 class=0x0c0300 at slot=29 function=1 Interrupt request lines: 19 I/O ports: 0x2020-0x203f usbus1 uhub1 unknown pnpinfo vendor=0x8086 device=0x25ab subvendor=0x0e11 subdevice=0x3201 class=0x088000 at slot=29 function=4 ioapic0 pnpinfo vendor=0x8086 device=0x25ac subvendor=0x0e11 subdevice=0x3201 class=0x080020 at slot=29 function=5 ehci0 pnpinfo vendor=0x8086 device=0x25ad subvendor=0x0e11 subdevice=0x3201 class=0x0c0320 at slot=29 function=7 Interrupt request lines: 23 I/O memory addresses: 0xfbee0000-0xfbee03ff usbus2 uhub2 pcib7 pnpinfo vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=30 function=0 handle=\_SB_.PCI0.IP2P pci1 I/O ports: 0x1800-0x18ff 0x3000-0x30ff 0x3400-0x34ff I/O memory addresses: 0xfbf00000-0xfbf7ffff 0xfbfc0000-0xfbfc1fff 0xfbfd0000-0xfbfd07ff 0xfbfe0000-0xfbfe01ff 0xfbff0000-0xfbff0fff 0xfc000000-0xfcffffff vgapci0 pnpinfo vendor=0x1002 device=0x4752 subvendor=0x0e11 subdevice=0x001e class=0x030000 at slot=3 function=0 drm0 unknown pnpinfo vendor=0x0e11 device=0xb203 subvendor=0x0e11 subdevice=0xb206 class=0x088000 at slot=4 function=0 handle=\_SB_.PCI0.IP2P.ASMD unknown pnpinfo vendor=0x0e11 device=0xb204 subvendor=0x0e11 subdevice=0xb206 class=0x088000 at slot=4 function=2 isab0 pnpinfo vendor=0x8086 device=0x25a1 subvendor=0x0000 subdevice=0x0000 class=0x060100 at slot=31 function=0 handle=\_SB_.PCI0.IBRG isa0 orm0 I/O memory addresses: 0xc0000-0xc7fff 0xc8000-0xcbfff 0xee000-0xeffff ichwd0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff atrtc0 Interrupt request lines: 8 ACPI I/O ports: 0x70-0x71 ppc0 uart1 Interrupt request lines: 3 ACPI I/O ports: 0x2f8-0x2ff atapci0 pnpinfo vendor=0x8086 device=0x25a2 subvendor=0x0e11 subdevice=0x3201 class=0x01018a at slot=31 function=1 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0x500-0x50f ata0 at channel=0 Interrupt request lines: 14 acd0 ata1 at channel=1 Interrupt request lines: 15 acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=0 at handle=\_SB_.PCI0.IBRG.MOMB attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle=\_SB_.PCI0.IBRG.TIME atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle=\_SB_.PCI0.IBRG.DMA0 unknown pnpinfo _HID=PNP0800 _UID=0 at handle=\_SB_.PCI0.IBRG.BEEP atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.IBRG.KBD_ I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 psm0 Interrupt request lines: 12 psmcpnp0 pnpinfo _HID=PNP0F13 _UID=0 at handle=\_SB_.PCI0.IBRG.PS2M unknown pnpinfo _HID=PNP0A06 _UID=0 at handle=\_SB_.PCI0.IBRG.S417 uart0 pnpinfo _HID=PNP0501 _UID=0 at handle=\_SB_.PCI0.IBRG.S417.COMA Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff fdc0 pnpinfo _HID=PNP0700 _UID=0 at handle=\_SB_.PCI0.IBRG.S417.FDC0 Interrupt request lines: 6 DMA request lines: 2 I/O ports: 0x3f2-0x3f5 0x3f7 fd0 pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.LNKA pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.LNKB pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.LNKC pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.LNKD pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.LNKE pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.LNKF pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.LNKG pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.LNKH acpi_tz0 pnpinfo _HID=none _UID=0 at handle=\_TZ_.THM0 acpi_timer0 pnpinfo unknown at unknown ACPI I/O ports: 0x908-0x90b >> # sysctl dev.bge.0.stats >> dev.bge.0.stats.FramesDroppedDueToFilters: 0 >> dev.bge.0.stats.DmaWriteQueueFull: 84072 >> dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 >> dev.bge.0.stats.NoMoreRxBDs: 0 >> dev.bge.0.stats.InputDiscards: 0 >> dev.bge.0.stats.InputErrors: 30 >> dev.bge.0.stats.RecvThresholdHit: 745400662 >> dev.bge.0.stats.DmaReadQueueFull: 2020586592 >> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 >> dev.bge.0.stats.SendDataCompQueueFull: 0 >> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 >> dev.bge.0.stats.RingStatusUpdate: 899990835 >> dev.bge.0.stats.Interrupts: 899990835 >> dev.bge.0.stats.AvoidedInterrupts: 0 >> dev.bge.0.stats.SendThresholdHit: 0 >> dev.bge.0.stats.rx.ifHCInOctets: 491268800 >> dev.bge.0.stats.rx.Fragments: 234 >> dev.bge.0.stats.rx.UnicastPkts: 1977202324 >> dev.bge.0.stats.rx.MulticastPkts: 0 >> dev.bge.0.stats.rx.FCSErrors: 341 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > You have multiple FCS and Input errors. Check signal > quality(i.e. UTP cable). Thanks, I'll check. > Does netperf benchmark also show 540Mbps on bge(4)? I'll try to run benchmarks if I find a peer for netperf. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 16:42:14 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B97106566C; Wed, 7 Mar 2012 16:42:14 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4518FC20; Wed, 7 Mar 2012 16:42:13 +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 q27Gg9YF017028; Wed, 7 Mar 2012 23:42:10 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F578FE1.1000808@rdtc.ru> Date: Wed, 07 Mar 2012 23:42:09 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> In-Reply-To: <20120308034345.GD9436@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: marius@freebsd.org, "net@freebsd.org" , yongari@freebsd.org Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:42:14 -0000 08.03.2012 10:43, YongHyeon PYUN РЙЫЕФ: >>> Show me the output of "sysctl dev.bge.0.stats". >> >> # sysctl dev.bge.0.stats >> dev.bge.0.stats.FramesDroppedDueToFilters: 0 >> dev.bge.0.stats.DmaWriteQueueFull: 84072 >> dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 >> dev.bge.0.stats.NoMoreRxBDs: 0 >> dev.bge.0.stats.InputDiscards: 0 >> dev.bge.0.stats.InputErrors: 30 >> dev.bge.0.stats.RecvThresholdHit: 745400662 >> dev.bge.0.stats.DmaReadQueueFull: 2020586592 >> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 >> dev.bge.0.stats.SendDataCompQueueFull: 0 >> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 >> dev.bge.0.stats.RingStatusUpdate: 899990835 >> dev.bge.0.stats.Interrupts: 899990835 >> dev.bge.0.stats.AvoidedInterrupts: 0 >> dev.bge.0.stats.SendThresholdHit: 0 >> dev.bge.0.stats.rx.ifHCInOctets: 491268800 >> dev.bge.0.stats.rx.Fragments: 234 >> dev.bge.0.stats.rx.UnicastPkts: 1977202324 >> dev.bge.0.stats.rx.MulticastPkts: 0 >> dev.bge.0.stats.rx.FCSErrors: 341 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > You have multiple FCS and Input errors. Check signal > quality(i.e. UTP cable). OTOH, should not bge(4) for such errors increase "Ierrs" counters that shows netstat -i? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 17:30:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ACDA6106566C for ; Wed, 7 Mar 2012 17:30:05 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C57B8FC12 for ; Wed, 7 Mar 2012 17:30:04 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so4661734wib.13 for ; Wed, 07 Mar 2012 09:30:04 -0800 (PST) Received: by 10.180.92.165 with SMTP id cn5mr7120496wib.1.1331141404211; Wed, 07 Mar 2012 09:30:04 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Wed, 7 Mar 2012 09:29:44 -0800 (PST) In-Reply-To: References: <63821C69-16E5-4483-8307-69DCF2865E99@my.gd> From: Juli Mallett Date: Wed, 7 Mar 2012 09:29:44 -0800 X-Google-Sender-Auth: R3VyegnvyndMSQpGexq4wE5bgDg Message-ID: To: hiren panchasara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkQ7ITjgQBMeu02LrWImmlaZ0IoKDRL+skzgA/3KsT1oWCgVyjMC1CJZW2pCxNWivTx1ouG Cc: "freebsd-net@freebsd.org" , Damien Fleuriot Subject: Re: Network Interface configuration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:30:05 -0000 On Wed, Mar 7, 2012 at 01:24, hiren panchasara wrote: > On Wed, Mar 7, 2012 at 12:49 AM, Juli Mallett wrot= e: >> =C2=A0In general, interfaces do >> not come from the configuration files like rc.conf, however the way >> that those interfaces are set up on boot is configured by files like >> rc.conf. > > > Thanks Juli. > So, does it mean that looking at getifaddrs() is the best way (as ifconfi= g > is doing) to get the correct state of network interfaces at any point in > time? Yes. > And for the interface of your interest, you can check if rc.conf is > specifying any persistent configuration or not. Pretty much. There are other ways one could configure the interfaces persistently (for example, a series of ifconfig commands in rc.local) but in general rc.conf is the way to go, unless you decide to build your own configuration system. From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 20:57:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D27B106566B for ; Wed, 7 Mar 2012 20:57:35 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 560328FC0A for ; Wed, 7 Mar 2012 20:57:35 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so10595795obb.13 for ; Wed, 07 Mar 2012 12:57:35 -0800 (PST) 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:content-transfer-encoding; bh=BGvQNGJED9c5475gwXoB++ir24Od5jQHpVmtOLYS46Q=; b=claH0EQpQd7bjfVHv4/5xpBlEbZa0GY0dztDHgfo7HVV0amdFmHGYqzORI5dtep37H OwoQzXmQALz9I05DlLIPJJ1ulmSK+vtE6BPsAYDjTZyKqLxyWeRVdkIFjptlF8WqU7yN aOElOtN/n7BipzZULZV+gFI5M0eaPQD1Sco+Nq0Q6UQUtxdnfv4z1zBI9tT2AZ13IMdM jkVkCcXohwZ5ZSQlgnJSZBUHSznWCzcuBu/ynIN29PmDqPfVCbr+v8YGFgp1y56D5re9 n42fG+EyhnXCnOJS4kF1OO69+9n8aleve7mt0XOlwejVf4ZfRjShWn3eN07SBQsUX8/W DXXg== MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr1377788obc.35.1331153854789; Wed, 07 Mar 2012 12:57:34 -0800 (PST) Received: by 10.182.171.7 with HTTP; Wed, 7 Mar 2012 12:57:34 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 13:57:34 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:57:35 -0000 On Thu, Mar 1, 2012 at 12:31 PM, Jason Wolfe wrote: > So since the 7.3.0/7.3.2 code released out of the "Intel 82574L > interface wedging on em 7.1.9/7.2.3 when MSIX enabled" thread I've > been having some good results in 8.2-STABLE, and 'wedges' are much > less common. =A0I am however still seeing them rarely, using some fuzzy > math based on uptime on the new code and number of boxes, about once > every 250 days. =A0MUCH better than prior, but wondering if there is > something else still lingering? =A0It appears to have the same symptoms > as before with a full buffer, where dropped packets start climbing and > packets out stall. =A0These servers have MSI-X enabled. > > ... > > Jason I'm sure it's getting old with all of the recent work put into the e1000 driver, but this is still ongoing with MSI-X enabled. Most machines are running an 8.2-STABLE from early Feb, though it appears there have been no relevant changes in RELENG_8 since then. I've disabled all possible em options on the devices also to rule that out and am still seeing the issue. I guess reverting back to MSI-X disabled is the next step if nothing is spotted. This box had been doing between 1 and 1.5Gb/s steady for the 26 days before the network hang. These are probably the points of interest? dev.em.1.mac_stats.missed_packets: 123241 dev.em.1.mac_stats.recv_no_buff: 29951 dev.em.1.interrupts.rx_overrun: 14 I bounced em1 because dropped packets incremented 653814 to 653916 and the interface is not incrementing packets out. 12:00PM up 26 days, 19:52, 0 users, load averages: 1.31, 1.43, 1.55 em0: flags=3D8843 metric 0 mtu 1500 options=3D88 ether 00:25:90:2c:c3:a5 inet6 X%em0 prefixlen 64 scopeid 0x1 nd6 options=3D1 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8843 metric 0 mtu 1500 options=3D88 ether 00:25:90:2c:c3:a5 inet6 X%em1 prefixlen 64 scopeid 0x2 nd6 options=3D3 media: Ethernet autoselect (1000baseT ) status: active ipfw0: flags=3D8801 metric 0 mtu 65536 lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff nd6 options=3D3 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D88 ether 00:25:90:2c:c3:a5 inet X.X.X.X netmask 0xffffff80 broadcast X.X.X.X inet6 fe80::225:90ff:fe2c:c3a5%lagg0 prefixlen 64 scopeid 0x5 inet6 2607:f4e8:320:14:225:90ff:fe2c:c3a5 prefixlen 64 autoconf nd6 options=3D3 media: Ethernet autoselect status: active laggproto loadbalance laggport: em0 flags=3D4 laggport: em1 flags=3D4 interrupt total rate irq3: uart1 13987 0 cpu0: timer 4635919565 2000 irq256: em0:rx 0 145695212 62 irq257: em0:tx 0 12311594799 5311 irq258: em0:link 4 0 irq259: em1:rx 0 14488041284 6250 irq260: em1:tx 0 12316161706 5313 irq261: em1:link 28369 0 irq262: mps0 1806741441 779 cpu2: timer 4635903792 2000 cpu3: timer 4635903694 2000 cpu1: timer 4635903765 2000 Total 59611907618 25718 25737/12138/37875 mbufs in use (current/cache/total) 4947/4053/9000/5956826 mbuf clusters in use (current/cache/total/max) 4947/887 mbuf+clusters out of packet secondary zone in use (current/cache) 14038/914/14952/2978413 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) 72480K/14796K/87276K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 223077 requests for I/O initiated by sendfile 0 calls to protocol drain routines Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:2c:c3:a5 144343665 0 0 77957281762 0 0 1163360 em0 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 5 - - - em1 1500 00:25:90:2c:c3:a5 72087463889 123241 0 77376157120 0 0 654252 em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 1 - - - lagg0 1500 00:25:90:2c:c3:a5 72231348146 0 0 155301336362 1819909 0 0 lagg0 1500 X.X.X.X X.X.X.X 68503722172 - - 155283480109 - - - lagg0 1500 fe80::225:90f fe80::225:90ff:fe 5059 - - 5150 - - - lagg0 1500 2607:f4e8:320 2607:f4e8:320:14: 44545526 - - 46097056 - - - kern.msgbuf: <6>arp: X.X.X.X moved from 00:25:90:0e:ab:c7 to 00:25:90:0e:ab:c6 on lagg0 <6>arp: X.X.X.X moved from 00:25:90:0e:ab:c6 to 00:25:90:0e:ab:c7 on lagg0 <6>arp: X.X.X.X moved from 00:25:90:0e:ae:50 to 00:25:90:0e:ae:51 on lagg0 <6>arp: X.X.X.X moved from 00:25:90:0e:ad:7c to 00:25:90:0e:ad:7d on lagg0 Interface is RUNNING and ACTIVE em0: hw tdh =3D 1385, hw tdt =3D 1385 em0: hw rdh =3D 452, hw rdt =3D 451 em0: Tx Queue Status =3D 0 em0: TX descriptors avail =3D 2048 em0: Tx Descriptors avail failure =3D 0 em0: RX discarded packets =3D 0 em0: RX Next to Check =3D 452 em0: RX Next to Refresh =3D 451 Interface is RUNNING and ACTIVE em1: hw tdh =3D 221, hw tdt =3D 342 em1: hw rdh =3D 335, hw rdt =3D 233 em1: Tx Queue Status =3D 0 em1: TX descriptors avail =3D 2048 em1: Tx Descriptors avail failure =3D 0 em1: RX discarded packets =3D 0 em1: RX Next to Check =3D 832 em1: RX Next to Refresh =3D 838 Mar 7 12:00:07 cds447 kernel: Interface is RUNNING and ACTIVE Mar 7 12:00:07 cds447 kernel: em0: hw tdh =3D 80, hw tdt =3D 83 Mar 7 12:00:07 cds447 kernel: em0: hw rdh =3D 1871, hw rdt =3D 1870 Mar 7 12:00:07 cds447 kernel: em0: Tx Queue Status =3D 1 Mar 7 12:00:07 cds447 kernel: em0: TX descriptors avail =3D 2039 Mar 7 12:00:07 cds447 kernel: em0: Tx Descriptors avail failure =3D 0 Mar 7 12:00:07 cds447 kernel: em0: RX discarded packets =3D 0 Mar 7 12:00:07 cds447 kernel: em0: RX Next to Check =3D 1872 Mar 7 12:00:07 cds447 kernel: em0: RX Next to Refresh =3D 1871 Mar 7 12:00:07 cds447 kernel: Interface is RUNNING and ACTIVE Mar 7 12:00:07 cds447 kernel: em1: hw tdh =3D 1897, hw tdt =3D 1897 Mar 7 12:00:07 cds447 kernel: em1: hw rdh =3D 627, hw rdt =3D 625 Mar 7 12:00:07 cds447 kernel: em1: Tx Queue Status =3D 0 Mar 7 12:00:07 cds447 kernel: em1: TX descriptors avail =3D 2048 Mar 7 12:00:07 cds447 kernel: em1: Tx Descriptors avail failure =3D 0 Mar 7 12:00:07 cds447 kernel: em1: RX discarded packets =3D 0 Mar 7 12:00:07 cds447 kernel: em1: RX Next to Check =3D 740 Mar 7 12:00:07 cds447 kernel: em1: RX Next to Refresh =3D 758 net.inet.ip.intr_queue_maxlen: 512 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 subdevice=3D0x10d3 class=3D0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.fc: 3 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.eee_control: 0 dev.em.0.link_irq: 4 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1049160 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 1678 dev.em.0.queue0.txd_tail: 1678 dev.em.0.queue0.tx_irq: 12311601270 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 1911 dev.em.0.queue0.rxd_tail: 1910 dev.em.0.queue0.rx_irq: 145694826 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 144436808 dev.em.0.mac_stats.good_pkts_recvd: 144436808 dev.em.0.mac_stats.bcast_pkts_recvd: 143716731 dev.em.0.mac_stats.mcast_pkts_recvd: 80138 dev.em.0.mac_stats.rx_frames_64: 143870227 dev.em.0.mac_stats.rx_frames_65_127: 359642 dev.em.0.mac_stats.rx_frames_128_255: 78152 dev.em.0.mac_stats.rx_frames_256_511: 10711 dev.em.0.mac_stats.rx_frames_512_1023: 7660 dev.em.0.mac_stats.rx_frames_1024_1522: 110416 dev.em.0.mac_stats.good_octets_recvd: 9421229514 dev.em.0.mac_stats.good_octets_txd: 104885010774599 dev.em.0.mac_stats.total_pkts_txd: 77957411708 dev.em.0.mac_stats.good_pkts_txd: 77957411708 dev.em.0.mac_stats.bcast_pkts_txd: 36 dev.em.0.mac_stats.mcast_pkts_txd: 15464 dev.em.0.mac_stats.tx_frames_64: 296356748 dev.em.0.mac_stats.tx_frames_65_127: 7232947896 dev.em.0.mac_stats.tx_frames_128_255: 58936912 dev.em.0.mac_stats.tx_frames_256_511: 118196124 dev.em.0.mac_stats.tx_frames_512_1023: 763686823 dev.em.0.mac_stats.tx_frames_1024_1522: 69487287205 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 6 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 dev.em.1.%driver: em dev.em.1.%location: slot=3D0 function=3D0 dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 subdevice=3D0x10d3 class=3D0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.fc: 3 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.eee_control: 0 dev.em.1.link_irq: 26412 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1049160 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 1897 dev.em.1.queue0.txd_tail: 1897 dev.em.1.queue0.tx_irq: 12316157844 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 1065 dev.em.1.queue0.rxd_tail: 1064 dev.em.1.queue0.rx_irq: 14386949031 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 123241 <--------- dev.em.1.mac_stats.recv_no_buff: 29951 <---------- dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 72087571174 dev.em.1.mac_stats.good_pkts_recvd: 72087447931 dev.em.1.mac_stats.bcast_pkts_recvd: 143701030 dev.em.1.mac_stats.mcast_pkts_recvd: 80133 dev.em.1.mac_stats.rx_frames_64: 22231874204 dev.em.1.mac_stats.rx_frames_65_127: 36577432236 dev.em.1.mac_stats.rx_frames_128_255: 63194749 dev.em.1.mac_stats.rx_frames_256_511: 181871202 dev.em.1.mac_stats.rx_frames_512_1023: 249092520 dev.em.1.mac_stats.rx_frames_1024_1522: 12783983019 dev.em.1.mac_stats.good_octets_recvd: 23699741522520 dev.em.1.mac_stats.good_octets_txd: 104452730965535 dev.em.1.mac_stats.total_pkts_txd: 77376109147 dev.em.1.mac_stats.good_pkts_txd: 77376109142 dev.em.1.mac_stats.bcast_pkts_txd: 15732 dev.em.1.mac_stats.mcast_pkts_txd: 12 dev.em.1.mac_stats.tx_frames_64: 261580498 dev.em.1.mac_stats.tx_frames_65_127: 6970447634 dev.em.1.mac_stats.tx_frames_128_255: 57377612 dev.em.1.mac_stats.tx_frames_256_511: 113729872 dev.em.1.mac_stats.tx_frames_512_1023: 753508328 dev.em.1.mac_stats.tx_frames_1024_1522: 69219465205 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 21011 dev.em.1.interrupts.rx_pkt_timer: 1 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 1 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 14 <------ hw.em.eee_setting: 0 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 2048 hw.em.rxd: 2048 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 Jason From owner-freebsd-net@FreeBSD.ORG Wed Mar 7 21:37:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66AA2106566C for ; Wed, 7 Mar 2012 21:37:37 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 21F7E8FC0A for ; Wed, 7 Mar 2012 21:37:36 +0000 (UTC) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 07 Mar 2012 13:26:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="74865560" Received: from orsmsx606.amr.corp.intel.com ([10.22.226.128]) by AZSMGA002.ch.intel.com with ESMTP; 07 Mar 2012 13:26:43 -0800 Received: from orsmsx105.amr.corp.intel.com (10.22.225.132) by orsmsx606.amr.corp.intel.com (10.22.226.128) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Mar 2012 13:26:42 -0800 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.188]) by ORSMSX105.amr.corp.intel.com ([169.254.4.233]) with mapi id 14.01.0355.002; Wed, 7 Mar 2012 13:26:43 -0800 From: "Pieper, Jeffrey E" To: Jason Wolfe , "freebsd-net@freebsd.org" Thread-Topic: Intel 82574L interface wedging - em7.3.2/8.2-STABLE Thread-Index: AQHM/KT/2dBbMbEa3UyNjc5U1jBsgpZfV61g Date: Wed, 7 Mar 2012 21:26:41 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65683CED5D11@ORSMSX101.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:37:37 -0000 I noticed that your FC counters aren't incrementing either...which is odd i= f you're missing packets and the rx buffers are full. Jeff -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Jason Wolfe Sent: Wednesday, March 07, 2012 12:58 PM To: freebsd-net@freebsd.org Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE On Thu, Mar 1, 2012 at 12:31 PM, Jason Wolfe wrote: > So since the 7.3.0/7.3.2 code released out of the "Intel 82574L > interface wedging on em 7.1.9/7.2.3 when MSIX enabled" thread I've > been having some good results in 8.2-STABLE, and 'wedges' are much > less common. =A0I am however still seeing them rarely, using some fuzzy > math based on uptime on the new code and number of boxes, about once > every 250 days. =A0MUCH better than prior, but wondering if there is > something else still lingering? =A0It appears to have the same symptoms > as before with a full buffer, where dropped packets start climbing and > packets out stall. =A0These servers have MSI-X enabled. > > ... > > Jason I'm sure it's getting old with all of the recent work put into the e1000 driver, but this is still ongoing with MSI-X enabled. Most machines are running an 8.2-STABLE from early Feb, though it appears there have been no relevant changes in RELENG_8 since then. I've disabled all possible em options on the devices also to rule that out and am still seeing the issue. I guess reverting back to MSI-X disabled is the next step if nothing is spotted. This box had been doing between 1 and 1.5Gb/s steady for the 26 days before the network hang. These are probably the points of interest? dev.em.1.mac_stats.missed_packets: 123241 dev.em.1.mac_stats.recv_no_buff: 29951 dev.em.1.interrupts.rx_overrun: 14 I bounced em1 because dropped packets incremented 653814 to 653916 and the interface is not incrementing packets out. 12:00PM up 26 days, 19:52, 0 users, load averages: 1.31, 1.43, 1.55 em0: flags=3D8843 metric 0 mtu 1500 options=3D88 ether 00:25:90:2c:c3:a5 inet6 X%em0 prefixlen 64 scopeid 0x1 nd6 options=3D1 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8843 metric 0 mtu 1500 options=3D88 ether 00:25:90:2c:c3:a5 inet6 X%em1 prefixlen 64 scopeid 0x2 nd6 options=3D3 media: Ethernet autoselect (1000baseT ) status: active ipfw0: flags=3D8801 metric 0 mtu 65536 lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff inet X.X.X.X netmask 0xffffffff nd6 options=3D3 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D88 ether 00:25:90:2c:c3:a5 inet X.X.X.X netmask 0xffffff80 broadcast X.X.X.X inet6 fe80::225:90ff:fe2c:c3a5%lagg0 prefixlen 64 scopeid 0x5 inet6 2607:f4e8:320:14:225:90ff:fe2c:c3a5 prefixlen 64 autoconf nd6 options=3D3 media: Ethernet autoselect status: active laggproto loadbalance laggport: em0 flags=3D4 laggport: em1 flags=3D4 interrupt total rate irq3: uart1 13987 0 cpu0: timer 4635919565 2000 irq256: em0:rx 0 145695212 62 irq257: em0:tx 0 12311594799 5311 irq258: em0:link 4 0 irq259: em1:rx 0 14488041284 6250 irq260: em1:tx 0 12316161706 5313 irq261: em1:link 28369 0 irq262: mps0 1806741441 779 cpu2: timer 4635903792 2000 cpu3: timer 4635903694 2000 cpu1: timer 4635903765 2000 Total 59611907618 25718 25737/12138/37875 mbufs in use (current/cache/total) 4947/4053/9000/5956826 mbuf clusters in use (current/cache/total/max) 4947/887 mbuf+clusters out of packet secondary zone in use (current/cache) 14038/914/14952/2978413 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) 72480K/14796K/87276K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 223077 requests for I/O initiated by sendfile 0 calls to protocol drain routines Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:2c:c3:a5 144343665 0 0 77957281762 0 0 1163360 em0 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 5 - - - em1 1500 00:25:90:2c:c3:a5 72087463889 123241 0 77376157120 0 0 654252 em1 1500 fe80::225:90f fe80::225:90ff:fe 0 - - 1 - - - lagg0 1500 00:25:90:2c:c3:a5 72231348146 0 0 155301336362 1819909 0 0 lagg0 1500 X.X.X.X X.X.X.X 68503722172 - - 155283480109 - - - lagg0 1500 fe80::225:90f fe80::225:90ff:fe 5059 - - 5150 - - - lagg0 1500 2607:f4e8:320 2607:f4e8:320:14: 44545526 - - 46097056 - - - kern.msgbuf: <6>arp: X.X.X.X moved from 00:25:90:0e:ab:c7 to 00:25:90:0e:ab:c6 on lagg0 <6>arp: X.X.X.X moved from 00:25:90:0e:ab:c6 to 00:25:90:0e:ab:c7 on lagg0 <6>arp: X.X.X.X moved from 00:25:90:0e:ae:50 to 00:25:90:0e:ae:51 on lagg0 <6>arp: X.X.X.X moved from 00:25:90:0e:ad:7c to 00:25:90:0e:ad:7d on lagg0 Interface is RUNNING and ACTIVE em0: hw tdh =3D 1385, hw tdt =3D 1385 em0: hw rdh =3D 452, hw rdt =3D 451 em0: Tx Queue Status =3D 0 em0: TX descriptors avail =3D 2048 em0: Tx Descriptors avail failure =3D 0 em0: RX discarded packets =3D 0 em0: RX Next to Check =3D 452 em0: RX Next to Refresh =3D 451 Interface is RUNNING and ACTIVE em1: hw tdh =3D 221, hw tdt =3D 342 em1: hw rdh =3D 335, hw rdt =3D 233 em1: Tx Queue Status =3D 0 em1: TX descriptors avail =3D 2048 em1: Tx Descriptors avail failure =3D 0 em1: RX discarded packets =3D 0 em1: RX Next to Check =3D 832 em1: RX Next to Refresh =3D 838 Mar 7 12:00:07 cds447 kernel: Interface is RUNNING and ACTIVE Mar 7 12:00:07 cds447 kernel: em0: hw tdh =3D 80, hw tdt =3D 83 Mar 7 12:00:07 cds447 kernel: em0: hw rdh =3D 1871, hw rdt =3D 1870 Mar 7 12:00:07 cds447 kernel: em0: Tx Queue Status =3D 1 Mar 7 12:00:07 cds447 kernel: em0: TX descriptors avail =3D 2039 Mar 7 12:00:07 cds447 kernel: em0: Tx Descriptors avail failure =3D 0 Mar 7 12:00:07 cds447 kernel: em0: RX discarded packets =3D 0 Mar 7 12:00:07 cds447 kernel: em0: RX Next to Check =3D 1872 Mar 7 12:00:07 cds447 kernel: em0: RX Next to Refresh =3D 1871 Mar 7 12:00:07 cds447 kernel: Interface is RUNNING and ACTIVE Mar 7 12:00:07 cds447 kernel: em1: hw tdh =3D 1897, hw tdt =3D 1897 Mar 7 12:00:07 cds447 kernel: em1: hw rdh =3D 627, hw rdt =3D 625 Mar 7 12:00:07 cds447 kernel: em1: Tx Queue Status =3D 0 Mar 7 12:00:07 cds447 kernel: em1: TX descriptors avail =3D 2048 Mar 7 12:00:07 cds447 kernel: em1: Tx Descriptors avail failure =3D 0 Mar 7 12:00:07 cds447 kernel: em1: RX discarded packets =3D 0 Mar 7 12:00:07 cds447 kernel: em1: RX Next to Check =3D 740 Mar 7 12:00:07 cds447 kernel: em1: RX Next to Refresh =3D 758 net.inet.ip.intr_queue_maxlen: 512 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 subdevice=3D0x10d3 class=3D0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.fc: 3 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.eee_control: 0 dev.em.0.link_irq: 4 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1049160 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 1678 dev.em.0.queue0.txd_tail: 1678 dev.em.0.queue0.tx_irq: 12311601270 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 1911 dev.em.0.queue0.rxd_tail: 1910 dev.em.0.queue0.rx_irq: 145694826 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 144436808 dev.em.0.mac_stats.good_pkts_recvd: 144436808 dev.em.0.mac_stats.bcast_pkts_recvd: 143716731 dev.em.0.mac_stats.mcast_pkts_recvd: 80138 dev.em.0.mac_stats.rx_frames_64: 143870227 dev.em.0.mac_stats.rx_frames_65_127: 359642 dev.em.0.mac_stats.rx_frames_128_255: 78152 dev.em.0.mac_stats.rx_frames_256_511: 10711 dev.em.0.mac_stats.rx_frames_512_1023: 7660 dev.em.0.mac_stats.rx_frames_1024_1522: 110416 dev.em.0.mac_stats.good_octets_recvd: 9421229514 dev.em.0.mac_stats.good_octets_txd: 104885010774599 dev.em.0.mac_stats.total_pkts_txd: 77957411708 dev.em.0.mac_stats.good_pkts_txd: 77957411708 dev.em.0.mac_stats.bcast_pkts_txd: 36 dev.em.0.mac_stats.mcast_pkts_txd: 15464 dev.em.0.mac_stats.tx_frames_64: 296356748 dev.em.0.mac_stats.tx_frames_65_127: 7232947896 dev.em.0.mac_stats.tx_frames_128_255: 58936912 dev.em.0.mac_stats.tx_frames_256_511: 118196124 dev.em.0.mac_stats.tx_frames_512_1023: 763686823 dev.em.0.mac_stats.tx_frames_1024_1522: 69487287205 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 6 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.3.2 dev.em.1.%driver: em dev.em.1.%location: slot=3D0 function=3D0 dev.em.1.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x15d9 subdevice=3D0x10d3 class=3D0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.fc: 3 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.eee_control: 0 dev.em.1.link_irq: 26412 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1049160 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 1897 dev.em.1.queue0.txd_tail: 1897 dev.em.1.queue0.tx_irq: 12316157844 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 1065 dev.em.1.queue0.rxd_tail: 1064 dev.em.1.queue0.rx_irq: 14386949031 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 123241 <--------- dev.em.1.mac_stats.recv_no_buff: 29951 <---------- dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 72087571174 dev.em.1.mac_stats.good_pkts_recvd: 72087447931 dev.em.1.mac_stats.bcast_pkts_recvd: 143701030 dev.em.1.mac_stats.mcast_pkts_recvd: 80133 dev.em.1.mac_stats.rx_frames_64: 22231874204 dev.em.1.mac_stats.rx_frames_65_127: 36577432236 dev.em.1.mac_stats.rx_frames_128_255: 63194749 dev.em.1.mac_stats.rx_frames_256_511: 181871202 dev.em.1.mac_stats.rx_frames_512_1023: 249092520 dev.em.1.mac_stats.rx_frames_1024_1522: 12783983019 dev.em.1.mac_stats.good_octets_recvd: 23699741522520 dev.em.1.mac_stats.good_octets_txd: 104452730965535 dev.em.1.mac_stats.total_pkts_txd: 77376109147 dev.em.1.mac_stats.good_pkts_txd: 77376109142 dev.em.1.mac_stats.bcast_pkts_txd: 15732 dev.em.1.mac_stats.mcast_pkts_txd: 12 dev.em.1.mac_stats.tx_frames_64: 261580498 dev.em.1.mac_stats.tx_frames_65_127: 6970447634 dev.em.1.mac_stats.tx_frames_128_255: 57377612 dev.em.1.mac_stats.tx_frames_256_511: 113729872 dev.em.1.mac_stats.tx_frames_512_1023: 753508328 dev.em.1.mac_stats.tx_frames_1024_1522: 69219465205 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 21011 dev.em.1.interrupts.rx_pkt_timer: 1 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 1 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 14 <------ hw.em.eee_setting: 0 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 2048 hw.em.rxd: 2048 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 Jason _______________________________________________ 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 Thu Mar 8 02:06:42 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73484106564A; Thu, 8 Mar 2012 02:06:42 +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 3222A8FC12; Thu, 8 Mar 2012 02:06:41 +0000 (UTC) Received: by dald2 with SMTP id d2so3630dal.13 for ; Wed, 07 Mar 2012 18:06:41 -0800 (PST) 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=5SCmV/iV4N5w3eUp5QHz15kUI4K8ZzMaVscMn/DEMCA=; b=rggQ+5eMFMj/q4N4r/33xOmAMq7tP5ApU+1Whq0CWylGvwqWMIRgZ5/GdCTgspMPCl dUgVQPUBfnuJT1sTpfLPsaPj4j1QM7ZA2R+lP5UUY1J1di8i/QW+pijsS2xp9QbXHyYm AAhOLTEXctkbrordPfJRGxmY4eA/UiY53w6js1HsHBTjIxGhvKfjbQPaQ5TmUauJVB46 r+kj6yKEv1NzuOmkOQ2OGtqi5is80WZn0YEBMkeOshx9t4NE9T7XCQtbZEKEPeN0Pjcy r6HAw/vgjJhaxQqN5vTKRqCgsMtdD3E4CoqxWGPk7MnwJG4O0i9RuBtwcGaUMR981ZE3 i5ZQ== Received: by 10.68.233.98 with SMTP id tv2mr6732430pbc.51.1331172401682; Wed, 07 Mar 2012 18:06:41 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id y9sm1752930pbu.40.2012.03.07.18.06.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 18:06:38 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 08 Mar 2012 11:06:28 -0800 From: YongHyeon PYUN Date: Thu, 8 Mar 2012 11:06:28 -0800 To: Eugene Grosbein Message-ID: <20120308190628.GB13138@michelle.cdnetworks.com> References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> <4F578FE1.1000808@rdtc.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F578FE1.1000808@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: marius@freebsd.org, "net@freebsd.org" , yongari@freebsd.org Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:06:42 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Mar 07, 2012 at 11:42:09PM +0700, Eugene Grosbein wrote: > 08.03.2012 10:43, YongHyeon PYUN пишет: > > >>> Show me the output of "sysctl dev.bge.0.stats". > >> > >> # sysctl dev.bge.0.stats > >> dev.bge.0.stats.FramesDroppedDueToFilters: 0 > >> dev.bge.0.stats.DmaWriteQueueFull: 84072 > >> dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 > >> dev.bge.0.stats.NoMoreRxBDs: 0 > >> dev.bge.0.stats.InputDiscards: 0 > >> dev.bge.0.stats.InputErrors: 30 > >> dev.bge.0.stats.RecvThresholdHit: 745400662 > >> dev.bge.0.stats.DmaReadQueueFull: 2020586592 > >> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 > >> dev.bge.0.stats.SendDataCompQueueFull: 0 > >> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 > >> dev.bge.0.stats.RingStatusUpdate: 899990835 > >> dev.bge.0.stats.Interrupts: 899990835 > >> dev.bge.0.stats.AvoidedInterrupts: 0 > >> dev.bge.0.stats.SendThresholdHit: 0 > >> dev.bge.0.stats.rx.ifHCInOctets: 491268800 > >> dev.bge.0.stats.rx.Fragments: 234 > >> dev.bge.0.stats.rx.UnicastPkts: 1977202324 > >> dev.bge.0.stats.rx.MulticastPkts: 0 > >> dev.bge.0.stats.rx.FCSErrors: 341 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You have multiple FCS and Input errors. Check signal > > quality(i.e. UTP cable). > > OTOH, should not bge(4) for such errors increase "Ierrs" counters > that shows netstat -i? > You're right. I checked the code and noticed that old controllers(BCM570[0-4]) do not report these errors. Would you try attached patch and let me know whether it corrects statistics counter? The patch also will show more information like whether the controller runs in PCI mode or not as well as showing frequency of PCI clock speed. > Eugene Grosbein --EVF5PPMfhYS0aIcm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.570x.stats.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 232655) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -1989,7 +1989,9 @@ /* Misc. config register */ #define BGE_MISCCFG_RESET_CORE_CLOCKS 0x00000001 #define BGE_MISCCFG_TIMER_PRESCALER 0x000000FE -#define BGE_MISCCFG_BOARD_ID 0x0001E000 +#define BGE_MISCCFG_BOARD_ID_MASK 0x0001E000 +#define BGE_MISCCFG_BOARD_ID_5704 0x00000000 +#define BGE_MISCCFG_BOARD_ID_5704CIOBE 0x00004000 #define BGE_MISCCFG_BOARD_ID_5788 0x00010000 #define BGE_MISCCFG_BOARD_ID_5788M 0x00018000 #define BGE_MISCCFG_EPHY_IDDQ 0x00200000 @@ -2868,6 +2870,8 @@ struct bge_softc { int bge_csum_features; struct callout bge_stat_ch; uint32_t bge_rx_discards; + uint32_t bge_rx_inerrs; + uint32_t bge_rx_nobds; uint32_t bge_tx_discards; uint32_t bge_tx_collisions; #ifdef DEVICE_POLLING Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 232655) +++ sys/dev/bge/if_bge.c (working copy) @@ -380,6 +380,8 @@ static void bge_dma_free(struct bge_softc *); static int bge_dma_ring_alloc(struct bge_softc *, bus_size_t, bus_size_t, bus_dma_tag_t *, uint8_t **, bus_dmamap_t *, bus_addr_t *, const char *); +static void bge_devinfo(struct bge_softc *); + static int bge_get_eaddr_fw(struct bge_softc *sc, uint8_t ether_addr[]); static int bge_get_eaddr_mem(struct bge_softc *, uint8_t[]); static int bge_get_eaddr_nvram(struct bge_softc *, uint8_t[]); @@ -2774,6 +2776,59 @@ bge_can_use_msi(struct bge_softc *sc) return (can_use_msi); } +static void +bge_devinfo(struct bge_softc *sc) +{ + uint32_t cfg, clk; + + device_printf(sc->bge_dev, + "CHIP ID 0x%08x; ASIC REV 0x%02x; CHIP REV 0x%02x; ", + sc->bge_chipid, sc->bge_asicrev, sc->bge_chiprev); + if (sc->bge_flags & BGE_FLAG_PCIE) + printf("PCI-E\n"); + else if (sc->bge_flags & BGE_FLAG_PCIX) { + printf("PCI-X "); + cfg = CSR_READ_4(sc, BGE_MISC_CFG) & BGE_MISCCFG_BOARD_ID_MASK; + if (cfg == BGE_MISCCFG_BOARD_ID_5704CIOBE) + clk = 133; + else { + clk = CSR_READ_4(sc, BGE_PCI_CLKCTL) & 0x1F; + switch (clk) { + case 0: + clk = 33; + break; + case 2: + clk = 50; + break; + case 4: + clk = 66; + break; + case 6: + clk = 100; + break; + case 7: + clk = 133; + break; + } + } + printf("%u MHz\n", clk); + } else { + if (sc->bge_pcixcap != 0) + printf("PCI on PCI-X "); + else + printf("PCI "); + cfg = pci_read_config(sc->bge_dev, BGE_PCI_PCISTATE, 4); + if (cfg & BGE_PCISTATE_PCI_BUSSPEED) + clk = 66; + else + clk = 33; + if (cfg & BGE_PCISTATE_32BIT_BUS) + printf("%u MHz; 32bit\n", clk); + else + printf("%u MHz; 64bit\n", clk); + } +} + static int bge_attach(device_t dev) { @@ -3002,7 +3057,7 @@ bge_attach(device_t dev) if (sc->bge_asicrev == BGE_ASICREV_BCM5719) sc->bge_flags |= BGE_FLAG_4K_RDMA_BUG; - misccfg = CSR_READ_4(sc, BGE_MISC_CFG) & BGE_MISCCFG_BOARD_ID; + misccfg = CSR_READ_4(sc, BGE_MISC_CFG) & BGE_MISCCFG_BOARD_ID_MASK; if (sc->bge_asicrev == BGE_ASICREV_BCM5705) { if (misccfg == BGE_MISCCFG_BOARD_ID_5788 || misccfg == BGE_MISCCFG_BOARD_ID_5788M) @@ -3132,11 +3187,7 @@ bge_attach(device_t dev) goto fail; } - device_printf(dev, - "CHIP ID 0x%08x; ASIC REV 0x%02x; CHIP REV 0x%02x; %s\n", - sc->bge_chipid, sc->bge_asicrev, sc->bge_chiprev, - (sc->bge_flags & BGE_FLAG_PCIX) ? "PCI-X" : - ((sc->bge_flags & BGE_FLAG_PCIE) ? "PCI-E" : "PCI")); + bge_devinfo(sc); BGE_LOCK_INIT(sc, device_get_nameunit(dev)); @@ -4400,6 +4451,12 @@ bge_stats_update(struct bge_softc *sc) ifp->if_collisions += (uint32_t)(cnt - sc->bge_tx_collisions); sc->bge_tx_collisions = cnt; + cnt = READ_STAT(sc, stats, nicNoMoreRxBDs.bge_addr_lo); + ifp->if_ierrors += (uint32_t)(cnt - sc->bge_rx_nobds); + sc->bge_rx_nobds = cnt; + cnt = READ_STAT(sc, stats, ifInErrors.bge_addr_lo); + ifp->if_ierrors += (uint32_t)(cnt - sc->bge_rx_inerrs); + sc->bge_rx_inerrs = cnt; cnt = READ_STAT(sc, stats, ifInDiscards.bge_addr_lo); ifp->if_ierrors += (uint32_t)(cnt - sc->bge_rx_discards); sc->bge_rx_discards = cnt; --EVF5PPMfhYS0aIcm-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 02:19:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E4531065674 for ; Thu, 8 Mar 2012 02:19:08 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id F2D108FC14 for ; Thu, 8 Mar 2012 02:19:07 +0000 (UTC) Received: by yenl9 with SMTP id l9so6157yen.13 for ; Wed, 07 Mar 2012 18:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=++mftdXNMuQaLmvlTnXE2Ki93QZwZjTk3DYzeR5F7Ec=; b=Lko1Zp+YRIPozmakX01QCH9WCpvX2rjqVudppn39+NXuGsUtxAbv31AoTdvPvMYJxK bcMeFWDtv69rVUEH+ldwk33WvFKPfD2StMwwGk/KBSZls2SXWBPbfi/4Allqf+wmRcro SuhgkbRfUSxqv/dXOk/EQVzM6eSvisPLcYKX8D56O2Y54I+Jgrru5RYdI65j35hlD43K FJysqwyU59UQEqw1d1bOyp0JXkqErLkax5mmutBZP+aGrsbWZjXlXR/zYdLDYJD5cxwh BCtmzhNdjR0qlGOyRg61MolRPDrAwurt5IRxV+O1MIMct7Jk9KYKYY+HiE77DmLtJi5P 6MOg== MIME-Version: 1.0 Received: by 10.236.192.230 with SMTP id i66mr8206139yhn.116.1331171512486; Wed, 07 Mar 2012 17:51:52 -0800 (PST) Received: by 10.101.61.11 with HTTP; Wed, 7 Mar 2012 17:51:52 -0800 (PST) Date: Wed, 7 Mar 2012 17:51:52 -0800 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Doubt regarding IPv6 DAD detection code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:19:08 -0000 Hi, I was puzzled to look at DAD detection code in FreeBSD. We check for counters for any received NA/NS for DAD in nd6_dad_timer: if (dp->dad_na_icount) { 1326 /* 1327 * the check is in nd6_dad_na_input(), 1328 * but just in case 1329 */ 1330 duplicate++; 1331 } 1332 1333 if (dp->dad_ns_icount) { 1334 /* We've seen NS, means DAD has failed. */ 1335 duplicate++; 1336 } 1337 1338 if (duplicate) { 1339 /* (*dp) will be freed in nd6_dad_duplicated() */ 1340 dp = NULL; 1341 nd6_dad_duplicated(ifa); the function later calls nd6_dad_duplicated to perform the remaining work if the address is detected duplicate. nd6_dad_duplicated also gets called from nd6_dad_na_input and nd6_dad_ns_input, both the functions are the only places which increment the input NA/NS counters respectively. 1505 static void 1506 nd6_dad_na_input(struct ifaddr *ifa) 1507 { 1508 struct dadq *dp; 1509 1510 if (ifa == NULL) 1511 panic("ifa == NULL in nd6_dad_na_input"); 1512 1513 dp = nd6_dad_find(ifa); 1514 if (dp) 1515 dp->dad_na_icount++; 1516 1517 /* remove the address. */ 1518 nd6_dad_duplicated(ifa); 1519 } nd6_dad_duplicated stops the timer among other things. Why nd6_dad_timer need check on these counters if we stop the timer on DAD failure anyways? Ok.. may be just an optimization which just "hopes" that the counters have been updated but the nd6_dad_*_input has not yet called nd6_dad_duplicated. Can the this timer and na packet processing ever run in parallel, I don;t see dp being protected by any locks, nor does it seem that it's been reference counted. Any explanation will be highly appreciated. Best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 04:17:09 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00747106566B; Thu, 8 Mar 2012 04:17:09 +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 5D1D78FC0A; Thu, 8 Mar 2012 04:17:08 +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 q284H4FK020539; Thu, 8 Mar 2012 11:17:04 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F5832C0.8070409@rdtc.ru> Date: Thu, 08 Mar 2012 11:17:04 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> <4F578FE1.1000808@rdtc.ru> <20120308190628.GB13138@michelle.cdnetworks.com> In-Reply-To: <20120308190628.GB13138@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 04:17:09 -0000 09.03.2012 02:06, YongHyeon PYUN РЙЫЕФ: >>>>> Show me the output of "sysctl dev.bge.0.stats". >>>> >>>> # sysctl dev.bge.0.stats >>>> dev.bge.0.stats.FramesDroppedDueToFilters: 0 >>>> dev.bge.0.stats.DmaWriteQueueFull: 84072 >>>> dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 >>>> dev.bge.0.stats.NoMoreRxBDs: 0 >>>> dev.bge.0.stats.InputDiscards: 0 >>>> dev.bge.0.stats.InputErrors: 30 >>>> dev.bge.0.stats.RecvThresholdHit: 745400662 >>>> dev.bge.0.stats.DmaReadQueueFull: 2020586592 >>>> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 >>>> dev.bge.0.stats.SendDataCompQueueFull: 0 >>>> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 >>>> dev.bge.0.stats.RingStatusUpdate: 899990835 >>>> dev.bge.0.stats.Interrupts: 899990835 >>>> dev.bge.0.stats.AvoidedInterrupts: 0 >>>> dev.bge.0.stats.SendThresholdHit: 0 >>>> dev.bge.0.stats.rx.ifHCInOctets: 491268800 >>>> dev.bge.0.stats.rx.Fragments: 234 >>>> dev.bge.0.stats.rx.UnicastPkts: 1977202324 >>>> dev.bge.0.stats.rx.MulticastPkts: 0 >>>> dev.bge.0.stats.rx.FCSErrors: 341 >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> You have multiple FCS and Input errors. Check signal >>> quality(i.e. UTP cable). >> >> OTOH, should not bge(4) for such errors increase "Ierrs" counters >> that shows netstat -i? >> > > You're right. I checked the code and noticed that old > controllers(BCM570[0-4]) do not report these errors. > Would you try attached patch and let me know whether it corrects > statistics counter? The patch also will show more information like > whether the controller runs in PCI mode or not as well as showing > frequency of PCI clock speed. I've applied the patch. Now dmesg shows: bge0: mem 0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2 bge0: CHIP ID 0x00002100; ASIC REV 0x02; CHIP REV 0x21; PCI-X 66 MHz I'll watch on Ierrs counter. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 05:50:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 391E3106566B; Thu, 8 Mar 2012 05:50:19 +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 8DAE78FC14; Thu, 8 Mar 2012 05:50:18 +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 q285oEji020797; Thu, 8 Mar 2012 12:50:15 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F584896.5010807@rdtc.ru> Date: Thu, 08 Mar 2012 12:50:14 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> <4F578FE1.1000808@rdtc.ru> <20120308190628.GB13138@michelle.cdnetworks.com> In-Reply-To: <20120308190628.GB13138@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:50:19 -0000 09.03.2012 02:06, YongHyeon PYUN РЙЫЕФ: > On Wed, Mar 07, 2012 at 11:42:09PM +0700, Eugene Grosbein wrote: >> 08.03.2012 10:43, YongHyeon PYUN РЙЫЕФ: >> >>>>> Show me the output of "sysctl dev.bge.0.stats". >>>> >>>> # sysctl dev.bge.0.stats >>>> dev.bge.0.stats.FramesDroppedDueToFilters: 0 >>>> dev.bge.0.stats.DmaWriteQueueFull: 84072 >>>> dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 >>>> dev.bge.0.stats.NoMoreRxBDs: 0 >>>> dev.bge.0.stats.InputDiscards: 0 >>>> dev.bge.0.stats.InputErrors: 30 >>>> dev.bge.0.stats.RecvThresholdHit: 745400662 >>>> dev.bge.0.stats.DmaReadQueueFull: 2020586592 >>>> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 >>>> dev.bge.0.stats.SendDataCompQueueFull: 0 >>>> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 >>>> dev.bge.0.stats.RingStatusUpdate: 899990835 >>>> dev.bge.0.stats.Interrupts: 899990835 >>>> dev.bge.0.stats.AvoidedInterrupts: 0 >>>> dev.bge.0.stats.SendThresholdHit: 0 >>>> dev.bge.0.stats.rx.ifHCInOctets: 491268800 >>>> dev.bge.0.stats.rx.Fragments: 234 >>>> dev.bge.0.stats.rx.UnicastPkts: 1977202324 >>>> dev.bge.0.stats.rx.MulticastPkts: 0 >>>> dev.bge.0.stats.rx.FCSErrors: 341 >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> You have multiple FCS and Input errors. Check signal >>> quality(i.e. UTP cable). Btw, I still think these errors are pretty seldom and cannot explain why I can't get full output gigabit speed. And what do these DmaWriteQueueFull/DmaReadQueueFull mean? Will it help to increase interface FIFO queue to eliminate output drops? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 06:23:57 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80CFA106566B; Thu, 8 Mar 2012 06:23:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE6A8FC0C; Thu, 8 Mar 2012 06:23:57 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1397396pbc.13 for ; Wed, 07 Mar 2012 22:23:56 -0800 (PST) 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=i9ke112cSqHghvbfrOnAgi/ga4/pIEIWOAVa2j6HrTk=; b=Ozm7WUnTPzWBIqCuGeQqiLl/snpo+tH3x2+UA4buxvn5yKoRIt3nrG2XR2yUvSCCbA gATSD3FHp1x++RMXBCDLoy820gCOjuAAPKPuaX4to5g3ZnQDilIv5pWNTUJRnuJjqpHR sB80q81FNhDuFlZin4kZ9oOtA9J1U5XqslgkbOZtfLdWEcGmj2EkYYH31YN3BVkal8ED Tz4DcpfRfY/cVxh4Q7MvDNWhlgxK71B9aWvYfgXSxPOh+ooDcG8snptZq34Z1sH/TUWy jOp4/22keBi3kbkpCRmdA31oKg5wYAYk2MxCpXdOU8hgqKgL56ytB+G1Yb3bwg5hCq4g IZMg== Received: by 10.68.191.168 with SMTP id gz8mr7636119pbc.37.1331187836915; Wed, 07 Mar 2012 22:23:56 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id o7sm2094893pbq.8.2012.03.07.22.23.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 22:23:56 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 08 Mar 2012 15:23:46 -0800 From: YongHyeon PYUN Date: Thu, 8 Mar 2012 15:23:46 -0800 To: Eugene Grosbein Message-ID: <20120308232346.GA15604@michelle.cdnetworks.com> References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> <4F578FE1.1000808@rdtc.ru> <20120308190628.GB13138@michelle.cdnetworks.com> <4F584896.5010807@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F584896.5010807@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:23:57 -0000 On Thu, Mar 08, 2012 at 12:50:14PM +0700, Eugene Grosbein wrote: > 09.03.2012 02:06, YongHyeon PYUN пишет: > > On Wed, Mar 07, 2012 at 11:42:09PM +0700, Eugene Grosbein wrote: > >> 08.03.2012 10:43, YongHyeon PYUN пишет: > >> > >>>>> Show me the output of "sysctl dev.bge.0.stats". > >>>> > >>>> # sysctl dev.bge.0.stats > >>>> dev.bge.0.stats.FramesDroppedDueToFilters: 0 > >>>> dev.bge.0.stats.DmaWriteQueueFull: 84072 > >>>> dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 > >>>> dev.bge.0.stats.NoMoreRxBDs: 0 > >>>> dev.bge.0.stats.InputDiscards: 0 > >>>> dev.bge.0.stats.InputErrors: 30 > >>>> dev.bge.0.stats.RecvThresholdHit: 745400662 > >>>> dev.bge.0.stats.DmaReadQueueFull: 2020586592 > >>>> dev.bge.0.stats.DmaReadHighPriQueueFull: 0 > >>>> dev.bge.0.stats.SendDataCompQueueFull: 0 > >>>> dev.bge.0.stats.RingSetSendProdIndex: 2832885493 > >>>> dev.bge.0.stats.RingStatusUpdate: 899990835 > >>>> dev.bge.0.stats.Interrupts: 899990835 > >>>> dev.bge.0.stats.AvoidedInterrupts: 0 > >>>> dev.bge.0.stats.SendThresholdHit: 0 > >>>> dev.bge.0.stats.rx.ifHCInOctets: 491268800 > >>>> dev.bge.0.stats.rx.Fragments: 234 > >>>> dev.bge.0.stats.rx.UnicastPkts: 1977202324 > >>>> dev.bge.0.stats.rx.MulticastPkts: 0 > >>>> dev.bge.0.stats.rx.FCSErrors: 341 > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>> You have multiple FCS and Input errors. Check signal > >>> quality(i.e. UTP cable). > > Btw, I still think these errors are pretty seldom and cannot explain > why I can't get full output gigabit speed. And what do these Right. > DmaWriteQueueFull/DmaReadQueueFull mean? Will it help to increase State machine in controller will add DMA descriptors to DMA engine whenever controller send/receive frames. These numbers indicate how many times the state machine sees DMA write/read queue full. And the state machine will have to retry the operation once it see a queue full. > interface FIFO queue to eliminate output drops? > These queues reside in internal RISC processors and I don't think there is an interface that changes the queue length. It's not normal FIFO which is used to send/receive a frame. I don't see any abnormal DMA configuration for PCI-X 5704 so I'm still interested in knowing netperf benchmark result. > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 06:36:58 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E6E4106564A; Thu, 8 Mar 2012 06:36:58 +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 8922D8FC14; Thu, 8 Mar 2012 06:36:57 +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 q286atVB020945; Thu, 8 Mar 2012 13:36:56 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F585387.7010706@rdtc.ru> Date: Thu, 08 Mar 2012 13:36:55 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> <4F578FE1.1000808@rdtc.ru> <20120308190628.GB13138@michelle.cdnetworks.com> <4F584896.5010807@rdtc.ru> <20120308232346.GA15604@michelle.cdnetworks.com> In-Reply-To: <20120308232346.GA15604@michelle.cdnetworks.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:36:58 -0000 09.03.2012 06:23, YongHyeon PYUN РЙЫЕФ: >> Btw, I still think these errors are pretty seldom and cannot explain >> why I can't get full output gigabit speed. And what do these > > Right. > >> DmaWriteQueueFull/DmaReadQueueFull mean? Will it help to increase > > State machine in controller will add DMA descriptors to DMA engine > whenever controller send/receive frames. These numbers indicate > how many times the state machine sees DMA write/read queue full. > And the state machine will have to retry the operation once it see > a queue full. > >> interface FIFO queue to eliminate output drops? >> > > These queues reside in internal RISC processors and I don't think > there is an interface that changes the queue length. It's not > normal FIFO which is used to send/receive a frame. Every ethernet network interface in FreeBSD has its own interface FIFO queue used by higher levels of our TCP/IP stack to place outgouing packets to. >From if_bge.c: ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > > I don't see any abnormal DMA configuration for PCI-X 5704 so I'm > still interested in knowing netperf benchmark result. Performing netperf benchmark would be a bit problematic in this case because the box lives in hoster's datacenter and netperf needs a peer to work with... But I'll try, it only matter of time. Meantime I have setup dummynet pipe for outgoing traffic having 875Mbit/s bandwidth and 72916 slots so it can take up to 1 second of traffic. I hope this will help to deal with traffic spikes and eliminate mentioned FIFO overflows and packet drops at cost of small extra delays. For TCP, drops are much worse than delays. Delays may be compensated with increased TCP windows and for icecast2 audio over tcp with some extra buffering at clients side. Drops make TCP flow control think the channel is overloaded when it's not. And many TCP peers do not use SACK. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 07:45:08 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 593AD1065672; Thu, 8 Mar 2012 07:45:08 +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 03E4A8FC12; Thu, 8 Mar 2012 07:45:07 +0000 (UTC) Received: by dald2 with SMTP id d2so226781dal.13 for ; Wed, 07 Mar 2012 23:45:07 -0800 (PST) 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=FA1pWPAEp07NSxdY6LjgpvnZd5k3XkvkRX91taz/W2c=; b=KHXwBW02wDJB5LX8G1teRmbFrmiSnC4rAvMKH3HBIN+kcf8dgiaxs6ZdFF0S7AHmhr AgAbIc0LMFdtMHMa0hS2M1DY3tvPbiQbgfevkQbFRaSwPjUR5Qi7uoj3xnalYaSVHEJ5 mt1+cMQo41p6ghll1mgI0wSojZtt6/JKfOBkk3GSwXe4nUjRPFH5gDJ2/iS5YrQjxFwT wLD+nNKr9RMPA7xtEU1FHaH9hfYJmhbDa0M9vgBvs8K3CXAHYcYfpVckK8bQskoF3nES ux9+mfmVQw6P7jUIB1bEXTVmYL1M4K2DnqCoUyER9DwWRVtu44dmpFkFU95na7eqaCQ8 Girw== Received: by 10.68.241.201 with SMTP id wk9mr2728429pbc.136.1331192707376; Wed, 07 Mar 2012 23:45:07 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id c9sm2176736pbr.65.2012.03.07.23.45.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Mar 2012 23:45:06 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 08 Mar 2012 16:45:01 -0800 From: YongHyeon PYUN Date: Thu, 8 Mar 2012 16:45:01 -0800 To: Eugene Grosbein Message-ID: <20120309004501.GB15604@michelle.cdnetworks.com> References: <4F5608EA.6080705@rdtc.ru> <20120307202914.GB9436@michelle.cdnetworks.com> <4F571870.3090902@rdtc.ru> <20120308034345.GD9436@michelle.cdnetworks.com> <4F578FE1.1000808@rdtc.ru> <20120308190628.GB13138@michelle.cdnetworks.com> <4F584896.5010807@rdtc.ru> <20120308232346.GA15604@michelle.cdnetworks.com> <4F585387.7010706@rdtc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F585387.7010706@rdtc.ru> User-Agent: Mutt/1.4.2.3i Cc: marius@freebsd.org, yongari@freebsd.org, "net@freebsd.org" Subject: Re: suboptimal bge(4) BCM5704 performance in RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 07:45:08 -0000 On Thu, Mar 08, 2012 at 01:36:55PM +0700, Eugene Grosbein wrote: > 09.03.2012 06:23, YongHyeon PYUN пишет: > > >> Btw, I still think these errors are pretty seldom and cannot explain > >> why I can't get full output gigabit speed. And what do these > > > > Right. > > > >> DmaWriteQueueFull/DmaReadQueueFull mean? Will it help to increase > > > > State machine in controller will add DMA descriptors to DMA engine > > whenever controller send/receive frames. These numbers indicate > > how many times the state machine sees DMA write/read queue full. > > And the state machine will have to retry the operation once it see > > a queue full. > > > >> interface FIFO queue to eliminate output drops? > >> > > > > These queues reside in internal RISC processors and I don't think > > there is an interface that changes the queue length. It's not > > normal FIFO which is used to send/receive a frame. > > Every ethernet network interface in FreeBSD has its own interface FIFO queue > used by higher levels of our TCP/IP stack to place outgouing packets to. > From if_bge.c: > > ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > The FIFO I said above is controller's internal DMA request queue. > > > > I don't see any abnormal DMA configuration for PCI-X 5704 so I'm > > still interested in knowing netperf benchmark result. > > Performing netperf benchmark would be a bit problematic > in this case because the box lives in hoster's datacenter and > netperf needs a peer to work with... But I'll try, it only matter of time. > Ok, thanks. > Meantime I have setup dummynet pipe for outgoing traffic having 875Mbit/s bandwidth > and 72916 slots so it can take up to 1 second of traffic. > > I hope this will help to deal with traffic spikes and eliminate mentioned FIFO > overflows and packet drops at cost of small extra delays. For TCP, drops are much worse > than delays. Delays may be compensated with increased TCP windows and for icecast2 > audio over tcp with some extra buffering at clients side. Drops make TCP flow control > think the channel is overloaded when it's not. And many TCP peers do not use SACK. Before digging deeper into TCP stack it would be easier to know which is the bottleneck(i.e. controller, driver etc) and simple netperf network benchmark in same network segment can tell whether bge(4) is bottleneck or not. > > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 11:15:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1097D1065674; Thu, 8 Mar 2012 11:15:39 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5419E8FC12; Thu, 8 Mar 2012 11:15:37 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so324546bkc.13 for ; Thu, 08 Mar 2012 03:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=bow8ZcdnYvoRJP0gR3ULI+bWSTEGLREIYgBC6bfeleE=; b=bBEosz/WFD4MObk1I28wO/1UhgoZ8ZqIjfogKNigzXcYpXKRKuilqRZ2CDCX6GeA5z HwJJBRk8spVPOYgTLJnj7b/9dw/E67xWb1ttT/gh5TEgN4pN/NbHxRH2CgwBH4Nb3hgX eL16gMlurEhHlNXZS1D7gIAmzFtuwbUhhCc435f88vWddt1cERFhRYjfg1kRRSiwvTuM 51KQuykHrANbNcyAIKKdj+VmxGWrPHkq3+MC6fn4mNRZ/IQe2qiF5AMYkF8PXk491u2b zhNgeewxV77aMIxRIsUqxPiQiD/eIZxViI/x7xUBXCz2HVtxPNc5LRcp93H7V+7tO/u+ 4CZQ== Received: by 10.204.143.151 with SMTP id v23mr2637219bku.63.1331204026145; Thu, 08 Mar 2012 02:53:46 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id m3sm2489006bkz.0.2012.03.08.02.53.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 02:53:44 -0800 (PST) From: Mikolaj Golub To: Andre Oppermann References: <86ehzwwt6a.fsf@kopusha.home.net> <86r53uhibq.fsf@kopusha.home.net> <4F566A8A.3080607@freebsd.org> X-Comment-To: Andre Oppermann Sender: Mikolaj Golub Date: Thu, 08 Mar 2012 12:53:41 +0200 In-Reply-To: <4F566A8A.3080607@freebsd.org> (Andre Oppermann's message of "Tue, 06 Mar 2012 20:50:34 +0100") Message-ID: <86boo78itm.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: soreceive_stream: mbuf leak if called with mp0 and MSG_WAITALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 11:15:39 -0000 Hi, On Tue, 06 Mar 2012 20:50:34 +0100 Andre Oppermann wrote: AO> On 05.09.2011 21:58, Mikolaj Golub wrote: >> >> On Sun, 04 Sep 2011 12:30:53 +0300 Mikolaj Golub wrote: >> >> MG> Apparently soreceive_stream() has an issue if it is called to receive data as a >> MG> mbuf chain (by supplying an non zero mbuf **mp0) and with MSG_WAITALL set. >> >> MG> I ran into this issue with smbfs, which uses soreceive() exactly in this way >> MG> (see netsmb/smb_trantcp.c:nbssn_recv()). >> >> Stressing smbfs a little I also observed the following soreceive_stream() >> related panic: AO> Hi Mikolaj, AO> thank you very much for testing, reporting and fixing bugs in soreceive_stream(). AO> I've altered your proposed patches a bit and committed them into my workqueue AO> with the following revisions: AO> http://svn.freebsd.org/changeset/base/232617 AO> http://svn.freebsd.org/changeset/base/232618 AO> Would you mind testing them again before they go into HEAD? With this patch smb mount fails with the error: smb_iod_recvall: tran return NULL without error AO> Index: sys/kern/uipc_socket.c AO> =================================================================== AO> --- sys/kern/uipc_socket.c (revision 232616) AO> +++ sys/kern/uipc_socket.c (revision 232617) AO> @@ -2044,7 +2044,7 @@ deliver: AO> if (mp0 != NULL) { AO> /* Dequeue as many mbufs as possible. */ AO> if (!(flags & MSG_PEEK) && len >= sb->sb_mb->m_len) { AO> - for (*mp0 = m = sb->sb_mb; AO> + for (m = sb->sb_mb; AO> m != NULL && m->m_len <= len; AO> m = m->m_next) { AO> len -= m->m_len; AO> @@ -2052,10 +2052,15 @@ deliver: AO> sbfree(sb, m); AO> n = m; AO> } AO> + n->m_next = NULL; AO> sb->sb_mb = m; AO> + sb->sb_lastrecord = sb->sb_mb; AO> if (sb->sb_mb == NULL) AO> SB_EMPTY_FIXUP(sb); AO> - n->m_next = NULL; AO> + if (*mp0 != NULL) AO> + m_cat(*mp0, m); AO> + else AO> + *mp0 = m; AO> } At that moment m points to the end of the chain. Shouldn't *mp0 be set to sb->sb_mb before the "for" loop? AO> /* Copy the remainder. */ AO> if (len > 0) { AO> @@ -2066,9 +2071,9 @@ deliver: AO> if (m == NULL) AO> len = 0; /* Don't flush data from sockbuf. */ AO> else AO> - uio->uio_resid -= m->m_len; AO> + uio->uio_resid -= len; AO> if (*mp0 != NULL) AO> - n->m_next = m; AO> + m_cat(*mp0, m); AO> else AO> *mp0 = m; AO> if (*mp0 == NULL) { AO> -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 12:47:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB3B106564A for ; Thu, 8 Mar 2012 12:47:56 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 82A628FC13 for ; Thu, 8 Mar 2012 12:47:56 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S5cl6-0005jK-L0 for freebsd-net@freebsd.org; Thu, 08 Mar 2012 13:47:52 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2012 13:47:52 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2012 13:47:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 08 Mar 2012 13:47:34 +0100 Lines: 38 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB0266DA8881B747D8598E15" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 X-Enigmail-Version: 1.3.5 Subject: Multiqueue support, igb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:47:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB0266DA8881B747D8598E15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, What is the current state of support for multithreaded TCP processing in CURRENT? If a NIC supports multiple queues, will they be used automatically or net.isr.numthreads needs to be increased? I have this situation on a machine with an igb card: irq256: igb0:que 0 103573 11 irq257: igb0:que 1 10094 1 irq258: igb0:que 2 18231 2 irq259: igb0:que 3 18186 2 This looks like the first queue is used ~~ 10x more often than the others. Is this a problem? --------------enigFB0266DA8881B747D8598E15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9YqmcACgkQldnAQVacBcgAJwCfQl9c0+XHf62gcDf1Ucco3ljO CQkAoL5my4Klw0cmykDp6v1Itb116V3q =MjoA -----END PGP SIGNATURE----- --------------enigFB0266DA8881B747D8598E15-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 13:22:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9969A106564A for ; Thu, 8 Mar 2012 13:22:32 +0000 (UTC) (envelope-from tejak85@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5318D8FC0A for ; Thu, 8 Mar 2012 13:22:32 +0000 (UTC) Received: by qcsg15 with SMTP id g15so427403qcs.13 for ; Thu, 08 Mar 2012 05:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UYDZys6rR1iZi7MFFzmUT3ppqOWHamKYloFb2r3kMsU=; b=sSgls+M+ZnSg4HBoThSsQMgj/IFefcuqZWtXnjYZT6L6tZbYVrwsPFipBi8eLycqBf 3U4JgUcNZSY0fD1Gr27h1n2gSdOr9VMsouWZYEtdTBfR1FO3vbXmBv7Zg7H6mTCOpoWv AJLLIuCP/MCfnMpWgpXpMzmN4fskfzLihRDzE5whjAaxp1lxye1X26tBcyvpM8SYpXJh 0etvpOTmaTmPNEvRc60YkUYcE8LjP6uvN9q5fY8VKyxyZ3PBfOMxTJxaJBGvW5E9OsOy U7q4K8vdoh1GHqkdF3hqILbqTpABPn9KZWZsugy5X9zLdMCaXhY2BGfDpCRPAp2jq6lM 2Ymw== MIME-Version: 1.0 Received: by 10.224.173.66 with SMTP id o2mr3615999qaz.89.1331211107787; Thu, 08 Mar 2012 04:51:47 -0800 (PST) Received: by 10.229.79.75 with HTTP; Thu, 8 Mar 2012 04:51:47 -0800 (PST) Date: Thu, 8 Mar 2012 07:51:47 -0500 Message-ID: From: Teja K To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: gsoc X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:22:32 -0000 hi i am teja,student.i am good in c, operating system internals and network programming. i am trying to develop a protocol by synchronizing between raw sockets and libpcap library. i have an idea of developing a transport layer protocol that could provide a secure communication between 2 systems where the data need not be encripted(avoid overhead) and with small payload.i am working on this by creating a private protocol which can only be detected by source and destination systems. can i do it as a gsoc project .i need some advice can anyone help me? thankyou From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 13:51:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83417106566C for ; Thu, 8 Mar 2012 13:51:07 +0000 (UTC) (envelope-from zec@fer.hr) Received: from munja.zvne.fer.hr (munja.zvne.fer.hr [161.53.66.248]) by mx1.freebsd.org (Postfix) with ESMTP id 116F88FC0C for ; Thu, 8 Mar 2012 13:51:06 +0000 (UTC) Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:38:54 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:38:54 +0100 From: Marko Zec To: freebsd-net@freebsd.org Date: Thu, 8 Mar 2012 14:38:19 +0100 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201203081438.19995.zec@fer.hr> X-OriginalArrivalTime: 08 Mar 2012 13:38:54.0278 (UTC) FILETIME=[CDF89660:01CCFD30] Cc: Teja K Subject: Re: gsoc X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:51:07 -0000 On Thursday 08 March 2012 13:51:47 Teja K wrote: > hi i am teja,student.i am good in c, operating system internals and network > programming. i am trying to develop a protocol by synchronizing between raw > sockets and libpcap library. > i have an idea of developing a transport layer protocol that could provide > a secure communication between 2 systems where the data need not be > encripted(avoid overhead) and with small payload.i am working on this by > creating a private protocol which can only be detected by source and > destination systems. can i do it as a gsoc project .i need some advice can > anyone help me? thankyou Have you thrown a look at tcpcrypt.org which has roughly the same goal, and already has a working userland implementation? Maybe you could get some idea on how this could be done by dissecting and / or reusing portions of their code? Or perhaps porting tcpcrypt to fbsd kernel may be a good candidate for a gsoc project? Marko From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 17:21:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9386A1065674 for ; Thu, 8 Mar 2012 17:21:24 +0000 (UTC) (envelope-from adrian.minta@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 213078FC12 for ; Thu, 8 Mar 2012 17:21:23 +0000 (UTC) Received: by eaaf13 with SMTP id f13so227372eaa.13 for ; Thu, 08 Mar 2012 09:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uPFgLKBIKibWWlYw+pJnOt0JvnVlXtYbiGEiiBfNC+k=; b=L4cn/mPeHnuyhGDENdkypVbhta+/2NhbCxZoEx2TLiuVkAQGqsfigjmA689rZzI4Iq XEMqpJSKZnOI5zgeeNFt7X77Zht1xzyL0uXfhhfbXhGGV9Wwctlk/Vg+FnD0e+Kx+pER 1bb0+pEnCYniuMjay60dY+JOeVU5q/k0vK7jJAAoFOqS9mbRHwGUWwirJK7YT9tHXJhb fnXMw2OEjSLZkjq4Esh7zMwUFfQZSQ7K8BxAGGYr/xQjGJW2Cold5A6p3Ax6FQrtwEYB 1LqWuUUdrj+ZqwQZN1aukASAUYd3GS9uIvZUbpgNplFFp7PsYTzrdvy/qddMQ19PAbPc +MTQ== Received: by 10.213.26.8 with SMTP id b8mr1351442ebc.289.1331227283019; Thu, 08 Mar 2012 09:21:23 -0800 (PST) Received: from [192.168.10.10] ([188.26.158.206]) by mx.google.com with ESMTPS id w9sm8202817eei.8.2012.03.08.09.21.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 09:21:21 -0800 (PST) Message-ID: <4F58EA90.2040300@gmail.com> Date: Thu, 08 Mar 2012 19:21:20 +0200 From: Adrian Minta User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Multiqueue support, igb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:21:24 -0000 On 03/08/12 14:47, Ivan Voras wrote: > Hello, > > What is the current state of support for multithreaded TCP processing in > CURRENT? If a NIC supports multiple queues, will they be used > automatically or net.isr.numthreads needs to be increased? > > I have this situation on a machine with an igb card: > > irq256: igb0:que 0 103573 11 > irq257: igb0:que 1 10094 1 > irq258: igb0:que 2 18231 2 > irq259: igb0:que 3 18186 2 > > This looks like the first queue is used ~~ 10x more often than the > others. Is this a problem? > > I believe that the card do internally some sort of ether-channel. This may explain your findings. -- Best regards, Adrian Minta From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 18:10:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A960F106564A; Thu, 8 Mar 2012 18:10:35 +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 11EF88FC17; Thu, 8 Mar 2012 18:10:34 +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 q28IAUjA023353; Fri, 9 Mar 2012 01:10:31 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F58F616.3020703@rdtc.ru> Date: Fri, 09 Mar 2012 01:10:30 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Multiqueue support, igb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:10:35 -0000 08.03.2012 19:47, Ivan Voras РЙЫЕФ: > Hello, > > What is the current state of support for multithreaded TCP processing in > CURRENT? If a NIC supports multiple queues, will they be used > automatically or net.isr.numthreads needs to be increased? > > I have this situation on a machine with an igb card: > > irq256: igb0:que 0 103573 11 > irq257: igb0:que 1 10094 1 > irq258: igb0:que 2 18231 2 > irq259: igb0:que 3 18186 2 > > This looks like the first queue is used ~~ 10x more often than the > others. Is this a problem? It seems you have lots of non-TCP and non-UDP traffic like PPPoE or GRE. igb(4) uses Microsoft Receive Side Scaling, so it cannot compute a hash for such ethernet frames and they all go to queue zero. That is unavoidable with those cards. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Mar 8 23:05:29 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A705A106566B; Thu, 8 Mar 2012 23:05:29 +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 7E1AA8FC12; Thu, 8 Mar 2012 23:05:29 +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 q28N5TcW006224; Thu, 8 Mar 2012 23:05:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q28N5TOH006220; Thu, 8 Mar 2012 23:05:29 GMT (envelope-from linimon) Date: Thu, 8 Mar 2012 23:05:29 GMT Message-Id: <201203082305.q28N5TOH006220@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165863: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:05:29 -0000 Old Synopsis: [panic] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() New Synopsis: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 8 23:05:11 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165863 From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 00:20:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63F27106566C for ; Fri, 9 Mar 2012 00:20:02 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from mail.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9868FC16 for ; Fri, 9 Mar 2012 00:20:02 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by mail.incore.de (Postfix) with ESMTP id 95FAE5CE69 for ; Fri, 9 Mar 2012 01:01:28 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from mail.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id FI_H4_8meniA for ; Fri, 9 Mar 2012 01:01:27 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by mail.incore.de (Postfix) with ESMTP id AC84C5CE61 for ; Fri, 9 Mar 2012 01:01:27 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 5E515450A7 for ; Fri, 9 Mar 2012 01:01:27 +0100 (CET) Message-ID: <4F594856.3030303@incore.de> Date: Fri, 09 Mar 2012 01:01:26 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:20:02 -0000 Hi, recently I installed FreeBSD 8.2 Stable on some older machines with Intel 82550 and 82550C and found that the loading of microcode with the parameter link0 in the ifconfig command did not work anymore. The reason for this is the commit r223608 for if_fxp.c with the comment: Disable microcode loading for 82550 and 82550C controllers. Loading the microcode caused SCB timeouts. I do not agree with this motivation and try to explain why. Without loading the microcode on 82550(C) there is a problem with mount_nfs -U server:/bigdisk /mnt cp /mnt/bigfile bigfile NFS with UDP works with 8 KB blocks and the cp hangs after some seconds and you see SCB messages on the console. The reason is the TCO bug of the hardware mentioned in rcvbundl.h. This old hardware bug disappears after loading the microcode. All my hardware run without problems in FreeBSD 4.11, loading of microcode is done by the function fxp_load_ucode(). Later there was trouble with the loading of microcode, see kern/103332 and kern/118909. I have posted my solution for the problem to kern/103332 but unfortunately this PR is not online anymore and so I repeat my considerations here. The difference of the function fxp_load_ucode() of FreeBSD 4.11 and later versions is that this function in 4.11 has an own private memory buffer for construction of the microcode message. In later versions fxp_load_ucode() must use a memory buffer that is shared with other parts of the driver and these other parts of the driver have problems if the shared memory buffer was used by fxp_load_ucode() before. Thats the reason for "Loading microcode caused SCB timeouts". Therefore my proposal is to revert r223608 and to clean the used shared buffer at the end of the function fxp_load_ucode(). The following patch works for me for years now: --- if_fxp.c.orig 2012-01-26 12:43:09.000000000 +0100 +++ if_fxp.c 2012-03-08 23:41:32.000000000 +0100 @@ -3085,6 +3081,7 @@ sc->tunable_int_delay, uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); sc->flags |= FXP_FLAG_UCODE; + bzero(cbp, (uc->length + 2) * sizeof(uint32_t)); } -- 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 Fri Mar 9 02:30:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4875D1065672; Fri, 9 Mar 2012 02:30:39 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by mx1.freebsd.org (Postfix) with ESMTP id E91D88FC13; Fri, 9 Mar 2012 02:30:38 +0000 (UTC) Received: from mail68-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Fri, 9 Mar 2012 02:30:32 +0000 Received: from mail68-ch1 (localhost [127.0.0.1]) by mail68-ch1-R.bigfish.com (Postfix) with ESMTP id 33D7B4003FD; Fri, 9 Mar 2012 02:30:32 +0000 (UTC) X-SpamScore: -7 X-BigFish: VPS-7(zzc85fh14ffOzz1202hzz8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI Received-SPF: pass (mail68-ch1: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=david.somayajulu@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail68-ch1 (localhost.localdomain [127.0.0.1]) by mail68-ch1 (MessageSwitch) id 1331260230652200_30570; Fri, 9 Mar 2012 02:30:30 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail68-ch1.bigfish.com (Postfix) with ESMTP id 9B4C0460048; Fri, 9 Mar 2012 02:30:30 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 9 Mar 2012 02:30:30 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Thu, 8 Mar 2012 18:30:29 -0800 From: David Somayajulu To: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org (freebsd-current@FreeBSD.org)" , "freebsd-drivers@freebsd.org" Date: Thu, 8 Mar 2012 18:30:28 -0800 Thread-Topic: iSCSI Target For Freebsd Thread-Index: Acz9m89nQdm8MQa0Sfur2ULjivGDSA== Message-ID: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: iSCSI Target For Freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:30:39 -0000 Hi All, Is there are an iSCSI Software Target that you can recommend. I have tried = using istgt ( on Freebsd7.2) with Windows iSCSI Software Initiator. The ini= tiator is able to discover the target however it is unable to login to the = target. The login Response shows that the =3D <0203>= indicating that "the requested ITN does not exist at this address" Thanks David S. ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 02:50:15 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8C2C106566B for ; Fri, 9 Mar 2012 02:50:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4568FC12 for ; Fri, 9 Mar 2012 02:50:15 +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 q292oFFO039419 for ; Fri, 9 Mar 2012 02:50:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q292oFnX039418; Fri, 9 Mar 2012 02:50:15 GMT (envelope-from gnats) Date: Fri, 9 Mar 2012 02:50:15 GMT Message-Id: <201203090250.q292oFnX039418@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eric van Gyzen Cc: Subject: Re: kern/165863: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric van Gyzen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 02:50:15 -0000 The following reply was made to PR kern/165863; it has been noted by GNATS. From: Eric van Gyzen To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165863: [panic] [netinet] [patch] in_lltable_prefix_free() races with lla_lookup() and arptimer() Date: Thu, 08 Mar 2012 20:23:14 -0600 I just realized that the first two paragraphs in the How-To-Repeat section are interchanged. I apologize for the confusion. From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 09:30:12 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D63DD106566C for ; Fri, 9 Mar 2012 09:30:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C22908FC18 for ; Fri, 9 Mar 2012 09:30:12 +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 q299UCH2057953 for ; Fri, 9 Mar 2012 09:30:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q299UCPX057950; Fri, 9 Mar 2012 09:30:12 GMT (envelope-from gnats) Date: Fri, 9 Mar 2012 09:30:12 GMT Message-Id: <201203090930.q299UCPX057950@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:30:12 -0000 The following reply was made to PR kern/165863; it has been noted by GNATS. From: Gleb Smirnoff To: Eric van Gyzen , Eric van Gyzen , emaste@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: kern/165863 Date: Fri, 9 Mar 2012 13:20:56 +0400 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hello, Eric and Ed. Can you look at this patch? I decided to utilize newer callout API, that allows to delegate lock retrieval to the callout subsystem, and this makes things simplier. Hope that should work. Patch is against head. Eric, can you please send me your test programs, that you use to reproduce the bug? -- Totus tuus, Glebius. --BXVAT5kNtrzKuDFl Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="kern165863.diff" Index: in.c =================================================================== --- in.c (revision 232689) +++ in.c (working copy) @@ -1279,11 +1279,12 @@ { struct in_llentry *lle; - lle = malloc(sizeof(struct in_llentry), M_LLTABLE, M_DONTWAIT | M_ZERO); + lle = malloc(sizeof(struct in_llentry), M_LLTABLE, M_NOWAIT | M_ZERO); if (lle == NULL) /* NB: caller generates msg */ return NULL; - callout_init(&lle->base.la_timer, CALLOUT_MPSAFE); + LLE_LOCK_INIT(&lle->base); + callout_init_rw(&lle->base.la_timer, &lle->base.lle_lock, 0); /* * For IPv4 this will trigger "arpresolve" to generate * an ARP request. @@ -1292,46 +1293,44 @@ lle->l3_addr4 = *(const struct sockaddr_in *)l3addr; lle->base.lle_refcnt = 1; lle->base.lle_free = in_lltable_free; - LLE_LOCK_INIT(&lle->base); - return &lle->base; + + return (&lle->base); } #define IN_ARE_MASKED_ADDR_EQUAL(d, a, m) ( \ (((ntohl((d)->sin_addr.s_addr) ^ (a)->sin_addr.s_addr) & (m)->sin_addr.s_addr)) == 0 ) static void -in_lltable_prefix_free(struct lltable *llt, - const struct sockaddr *prefix, - const struct sockaddr *mask, - u_int flags) +in_lltable_prefix_free(struct lltable *llt, const struct sockaddr *prefix, + const struct sockaddr *mask, u_int flags) { const struct sockaddr_in *pfx = (const struct sockaddr_in *)prefix; const struct sockaddr_in *msk = (const struct sockaddr_in *)mask; struct llentry *lle, *next; - register int i; + int i; size_t pkts_dropped; - for (i=0; i < LLTBL_HASHTBL_SIZE; i++) { + IF_AFDATA_WLOCK(llt->llt_ifp); + for (i = 0; i < LLTBL_HASHTBL_SIZE; i++) { LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) { /* * (flags & LLE_STATIC) means deleting all entries - * including static ARP entries + * including static ARP entries. */ - if (IN_ARE_MASKED_ADDR_EQUAL((struct sockaddr_in *)L3_ADDR(lle), - pfx, msk) && - ((flags & LLE_STATIC) || !(lle->la_flags & LLE_STATIC))) { - int canceled; + if (IN_ARE_MASKED_ADDR_EQUAL(satosin(L3_ADDR(lle)), + pfx, msk) && ((flags & LLE_STATIC) || + !(lle->la_flags & LLE_STATIC))) { - canceled = callout_drain(&lle->la_timer); LLE_WLOCK(lle); - if (canceled) + if (callout_stop(&lle->la_timer)) LLE_REMREF(lle); pkts_dropped = llentry_free(lle); ARPSTAT_ADD(dropped, pkts_dropped); } } } + IF_AFDATA_WUNLOCK(llt->llt_ifp); } Index: if_ether.c =================================================================== --- if_ether.c (revision 232689) +++ if_ether.c (working copy) @@ -163,38 +163,23 @@ static void arptimer(void *arg) { + struct llentry *lle = (struct llentry *)arg; struct ifnet *ifp; - struct llentry *lle; - int pkts_dropped; + size_t pkts_dropped; - KASSERT(arg != NULL, ("%s: arg NULL", __func__)); - lle = (struct llentry *)arg; + LLE_WLOCK_ASSERT(lle); + + if (lle->la_flags & LLE_STATIC) + return; + ifp = lle->lle_tbl->llt_ifp; CURVNET_SET(ifp->if_vnet); - IF_AFDATA_LOCK(ifp); - LLE_WLOCK(lle); - if (lle->la_flags & LLE_STATIC) - LLE_WUNLOCK(lle); - else { - if (!callout_pending(&lle->la_timer) && - callout_active(&lle->la_timer)) { - callout_stop(&lle->la_timer); - LLE_REMREF(lle); - pkts_dropped = llentry_free(lle); - ARPSTAT_ADD(dropped, pkts_dropped); - ARPSTAT_INC(timeouts); - } else { -#ifdef DIAGNOSTIC - struct sockaddr *l3addr = L3_ADDR(lle); - log(LOG_INFO, - "arptimer issue: %p, IPv4 address: \"%s\"\n", lle, - inet_ntoa( - ((const struct sockaddr_in *)l3addr)->sin_addr)); -#endif - LLE_WUNLOCK(lle); - } - } - IF_AFDATA_UNLOCK(ifp); + + LLE_REMREF(lle); + pkts_dropped = llentry_free(lle); + ARPSTAT_ADD(dropped, pkts_dropped); + ARPSTAT_INC(timeouts); + CURVNET_RESTORE(); } --BXVAT5kNtrzKuDFl-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 09:36:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4E21065672 for ; Fri, 9 Mar 2012 09:36:24 +0000 (UTC) (envelope-from adrian.chadd@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 D219C8FC18 for ; Fri, 9 Mar 2012 09:36:23 +0000 (UTC) Received: by lboi15 with SMTP id i15so361480lbo.13 for ; Fri, 09 Mar 2012 01:36:22 -0800 (PST) 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=Sq/jY0aDOMdSClKlsGV5R/4qRYM0q2/rHwlez9QlteY=; b=GluJiZTeo6cYnL6+WykJNM2G1Q7tWj14S/RuxLIudecr2LG6R+L3DDQE+w3fddKEIu 8cV7K750RHuyRCAL8slDdbWIGX57tAA6uxv4BMC8oNl7i7QzXOmDH9+G2Ki/eZx5fvgf 9CbeunkG6Fkk2D21QsFPGZvl9FXLGsdXynDXGms2zjOb3N57HawL3Nixg59xLuMAQA+X Fj80/7iSHh+QuTU+DNq3BypXqg81mTroxFOwcFQmWCA4J5rsod6WpAHNvWnVkYpFJxhk 6cbSbVl7GYpdxQAhRlyGiKOAeLNBCNhUsOHequFg38kvMd/YgBeMpc/TSoGogpmiAVte 9U4A== MIME-Version: 1.0 Received: by 10.152.132.132 with SMTP id ou4mr1107305lab.26.1331285782209; Fri, 09 Mar 2012 01:36:22 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.112.13.18 with HTTP; Fri, 9 Mar 2012 01:36:22 -0800 (PST) In-Reply-To: <4F594856.3030303@incore.de> References: <4F594856.3030303@incore.de> Date: Fri, 9 Mar 2012 01:36:22 -0800 X-Google-Sender-Auth: jypPmw8Oir_YRbdTudFmO3jsMPY Message-ID: From: Adrian Chadd To: Andreas Longwitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jfv@freebsd.org, freebsd-net@freebsd.org, Pyun YongHyeon Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:36:24 -0000 Hi! That's actually a really good catch! yongari/jfv, what do you think? Adrian On 8 March 2012 16:01, Andreas Longwitz wrote: > Hi, > > recently I installed FreeBSD 8.2 Stable on some older machines with > Intel 82550 and 82550C and found that the loading of microcode with the > parameter link0 in the ifconfig command did not work anymore. The reason > for this is the commit r223608 for if_fxp.c with the comment: > > Disable microcode loading for 82550 and 82550C controllers. Loading > the microcode caused SCB timeouts. > > I do not agree with this motivation and try to explain why. > > Without loading the microcode on 82550(C) there is a problem with > =A0 mount_nfs -U server:/bigdisk /mnt > =A0 cp /mnt/bigfile bigfile > > NFS with UDP works with 8 KB blocks and the cp hangs after some seconds > and you see SCB messages on the console. The reason is the TCO bug of > the hardware mentioned in rcvbundl.h. This old hardware bug disappears > after loading the microcode. > > All my hardware run without problems in FreeBSD 4.11, loading of > microcode is done by the function fxp_load_ucode(). Later there was > trouble with the loading of microcode, see kern/103332 and kern/118909. > I have posted my solution for the problem to kern/103332 but > unfortunately this PR is not online anymore and so I repeat my > considerations here. > > The difference of the function fxp_load_ucode() of FreeBSD 4.11 and > later versions is that this function in 4.11 has an own private memory > buffer for construction of the microcode message. In later versions > fxp_load_ucode() must use a memory buffer that is shared with other > parts of the driver and these other parts of the driver have problems if > the shared memory buffer was used by fxp_load_ucode() before. Thats the > reason for "Loading microcode caused SCB timeouts". > > Therefore my proposal is to revert r223608 and to clean the used shared > buffer at the end of the function fxp_load_ucode(). The following patch > works for me for years now: > > --- if_fxp.c.orig =A0 =A0 =A0 2012-01-26 12:43:09.000000000 +0100 > +++ if_fxp.c =A0 =A02012-03-08 23:41:32.000000000 +0100 > @@ -3085,6 +3081,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0sc->tunable_int_delay, > =A0 =A0 =A0 =A0 =A0 =A0uc->bundle_max_offset =3D=3D 0 ? 0 : sc->tunable_b= undle_max); > =A0 =A0 =A0 =A0sc->flags |=3D FXP_FLAG_UCODE; > + =A0 =A0 =A0 bzero(cbp, (uc->length + 2) * sizeof(uint32_t)); > =A0} > > > -- > Dr. Andreas Longwitz > > Data Service GmbH > Beethovenstr. 2A > 23617 Stockelsdorf > Amtsgericht L=FCbeck, HRB 318 BS > Gesch=E4ftsf=FChrer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau > _______________________________________________ > 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 Mar 9 12:06:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13EC7106566B for ; Fri, 9 Mar 2012 12:06:31 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from lazy.aws-net.org.ua (lazy.aws-net.org.ua [IPv6:2a00:1db0:20::828:140]) by mx1.freebsd.org (Postfix) with ESMTP id 87EA28FC0C for ; Fri, 9 Mar 2012 12:06:30 +0000 (UTC) Received: from [IPv6:2a00:1db0:5f:32:216:6fff:fec8:7253] ([IPv6:2a00:1db0:5f:32:216:6fff:fec8:7253]) (authenticated bits=0) by lazy.aws-net.org.ua (8.14.4/8.14.4) with ESMTP id q29C6Pmx035638 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 9 Mar 2012 14:06:29 +0200 (EET) (envelope-from artem@aws-net.org.ua) Message-ID: <4F59F243.7020600@aws-net.org.ua> Date: Fri, 09 Mar 2012 14:06:27 +0200 From: Artyom Viklenko Organization: Art&Co. User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110802 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (lazy.aws-net.org.ua [IPv6:2a00:1db0:20::828:140]); Fri, 09 Mar 2012 14:06:29 +0200 (EET) Subject: Re: iSCSI Target For Freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:06:31 -0000 09.03.2012 04:30, David Somayajulu пишет: > Hi All, > Is there are an iSCSI Software Target that you can recommend. I have tried using istgt ( on Freebsd7.2) with Windows iSCSI Software Initiator. The initiator is able to discover the target however it is unable to login to the target. > net/iscsi-target is in ports and seems to be working one. some times use it with windows initiator and all is ok. > The login Response shows that the =<0203> indicating that "the requested ITN does not exist at this address" > > Thanks > David S. > > ________________________________ > This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. > _______________________________________________ > 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" > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | ================================ FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 13:18:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F16BD106566C for ; Fri, 9 Mar 2012 13:18:39 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A85788FC08 for ; Fri, 9 Mar 2012 13:18:39 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1618942vcm.13 for ; Fri, 09 Mar 2012 05:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rZ1FTIVal+6S5DeqDoFr4azXITDvcW/OsVa2AZM3teQ=; b=KeXUQrTiEkr7mHj/DhW0bUNJcijqKfiSV8UoIEpUVmtzYYyJsu+B1PPnCIkJNvtdOc 68vnZuJfp9N4FUUGvIpO8ng+N782X7psc1e0au5ZrZ5V2BFSU0daY+cd3N/l9wmS/hYA EULLB8qh51nxgf5TspzK0WG1N9hpRM9TFPYIIMBFIS2gSJACJ/R5p0IuNq30vZ46z80s ZSq89AWjJ9hWDf7/USPb8VM6GQP2KalVJKI/wVbO7PrZh0c9lVkhSqbvwn2DW48CuPQc 2rySCTmPks8NvRpXuBgb9MbIeGLJjo2xtaqLY02rXhoRRlsJfiGDEPuljYpkKbml8H08 rS9w== Received: by 10.52.76.7 with SMTP id g7mr3129165vdw.104.1331297682221; Fri, 09 Mar 2012 04:54:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.153.198 with HTTP; Fri, 9 Mar 2012 04:54:12 -0800 (PST) In-Reply-To: <4F59F243.7020600@aws-net.org.ua> References: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> <4F59F243.7020600@aws-net.org.ua> From: Matthias Gamsjager Date: Fri, 9 Mar 2012 13:54:12 +0100 Message-ID: To: Artyom Viklenko Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: iSCSI Target For Freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:18:40 -0000 Or try net/istgt. This one gets an update once in a while where the other one is from 2008. From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 14:45:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8865106566B for ; Fri, 9 Mar 2012 14:45:25 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 751EB8FC0C for ; Fri, 9 Mar 2012 14:45:25 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.1.339.1; Fri, 9 Mar 2012 09:34:36 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 9CB9E33C02; Fri, 9 Mar 2012 09:34:34 -0500 (EST) Date: Fri, 9 Mar 2012 09:34:34 -0500 From: Ed Maste To: Jason Leschnik Message-ID: <20120309143434.GB91986@sandvine.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: Lagg failover does not announce the failover to switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:45:25 -0000 On Wed, Mar 07, 2012 at 02:28:32PM +1100, Jason Leschnik wrote: > Lagg failover does not gratuitous ARP on the new interface to announce > the link failover - This leaves clients trying to access the failed > link and never making it to the up'd link. > > Bug ID: 156226 > Found on this todo list: http://wiki.freebsd.org/EdMaste/ToDo > > I was wondering if i could offer a donation Hardware/Money to get this > fixed, in my opinion this is a very important feature for the > platform. I understand there are other ways to correct the behavior > but one would expect this to be solved in the driver. We've posted a prototype patch for comments: http://lists.freebsd.org/pipermail/freebsd-net/2012-February/031328.html Gleb raised some concerns that we'll look to address before this is ready to be committed to the tree, but any testing you can provide on the patch in its current state would be appreciated. The (externally visible) functionality should remain unchanged. I appreciate your offer of a hardware or monetary donation, although at this point we're not being held up by either. You can send your donation to the FreeBSD Foundation instead to help support the FreeBSD project in general. Regards, Ed Maste From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 15:40:12 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CB361065673 for ; Fri, 9 Mar 2012 15:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D31C8FC17 for ; Fri, 9 Mar 2012 15:40:12 +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 q29FeCMx016171 for ; Fri, 9 Mar 2012 15:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q29FeCqR016170; Fri, 9 Mar 2012 15:40:12 GMT (envelope-from gnats) Date: Fri, 9 Mar 2012 15:40:12 GMT Message-Id: <201203091540.q29FeCqR016170@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Eric van Gyzen Cc: Subject: Re: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric van Gyzen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:40:12 -0000 The following reply was made to PR kern/165863; it has been noted by GNATS. From: Eric van Gyzen To: Gleb Smirnoff Cc: Eric van Gyzen , , , Subject: Re: kern/165863 Date: Fri, 9 Mar 2012 09:26:51 -0600 --------------000307010007030804050405 Content-Type: text/plain; charset="KOI8-R"; format=flowed Content-Transfer-Encoding: 7bit On 03/09/12 03:20, Gleb Smirnoff wrote: > Hello, Eric and Ed. > > Can you look at this patch? I decided to utilize newer callout API, > that allows to delegate lock retrieval to the callout subsystem, and > this makes things simplier. Hope that should work. > > Patch is against head. Doesn't arptimer() still need to acquire the if_afdata_lock in order to free the entry in the normal case (when the llentry is still in the hash bucket list)? With this patch, in_lltable_prefix_free() no longer guarantees that all the relevant llentries will be freed when it returns. I don't see any immediate breakage, but it's a notable change in behavior. > Eric, can you please send me your test programs, that you use to > reproduce the bug? Attached is a C program to add and remove the interface address. To drive traffic, I just used "ping -f". Thanks for your help. Eric --------------000307010007030804050405 Content-Type: text/plain; name="ifconf.set.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ifconf.set.c" /*- * Copyright (c) 2012 Dell, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include int sockfd = -1; struct ifreq ifr; struct sockaddr_in * const sin4 = (struct sockaddr_in *) &ifr.ifr_addr; const char *ifname; struct in_addr addr, mask, brdaddr; unsigned int iterations = 0; bool sigint_received = false; static void report(void) { printf("%u iterations\n", iterations); } static void __dead2 usage() { errx(1, "usage: ifconf [1]"); } static void ifconf(void) { bzero(&ifr, sizeof ifr); strlcpy(ifr.ifr_name, ifname, sizeof ifr.ifr_name); sin4->sin_family = AF_INET; sin4->sin_len = sizeof (*sin4); sin4->sin_addr = addr; if (ioctl(sockfd, SIOCDIFADDR, &ifr)) { if (iterations == 0 && errno == EADDRNOTAVAIL) { // OK, it wasn't there when we started. } else { err(1, "SIOCDIFADDR"); } } if (ioctl(sockfd, SIOCSIFADDR, &ifr)) { err(1, "SIOCSIFADDR"); } #if 0 sin4->sin_addr = mask; if (ioctl(sockfd, SIOCSIFNETMASK, &ifr)) { err(1, "SIOCSIFNETMASK"); } sin4->sin_addr = brdaddr; if (ioctl(sockfd, SIOCSIFBRDADDR, &ifr)) { err(1, "SIOCSIFBRDADDR"); } #endif } static void sigint_handler(int signo __unused) { sigint_received = true; } int main(int argc, const char *argv[]) { if (argc != 5 && argc != 6) { usage(); } ifname = argv[1]; if (inet_pton(AF_INET, argv[2], &addr) != 1) { err(1, "inet_pton(%s)", argv[2]); } if (inet_pton(AF_INET, argv[3], &mask) != 1) { err(1, "inet_pton(%s)", argv[3]); } if (inet_pton(AF_INET, argv[4], &brdaddr) != 1) { err(1, "inet_pton(%s)", argv[4]); } sockfd = socket(AF_INET, SOCK_DGRAM, 0); if (sockfd < 0) { err(1, "socket"); } if (argc == 6 && atoi(argv[5]) == 1) { ifconf(); return (0); } atexit(report); signal(SIGINT, sigint_handler); while (!sigint_received) { ifconf(); iterations++; } putchar('\n'); return (0); } --------------000307010007030804050405-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 16:00:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C54106564A for ; Fri, 9 Mar 2012 16:00:02 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 4683D8FC12 for ; Fri, 9 Mar 2012 16:00:01 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id q29FmjPX025331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 09:48:45 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id q29FmjlG039517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 09:48:45 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id q29Fmjfc039516; Fri, 9 Mar 2012 09:48:45 -0600 (CST) (envelope-from dan) Date: Fri, 9 Mar 2012 09:48:44 -0600 From: Dan Nelson To: David Somayajulu Message-ID: <20120309154844.GD42750@dan.emsphone.com> References: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75E1A2A7D185F841A975979B0906BBA67C79E3F37F@AVEXMB1.qlogic.org> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Fri, 09 Mar 2012 09:48:45 -0600 (CST) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-net@freebsd.org Subject: Re: iSCSI Target For Freebsd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:00:03 -0000 In the last episode (Mar 08), David Somayajulu said: > Is there are an iSCSI Software Target that you can recommend. I have tried > using istgt ( on Freebsd7.2) with Windows iSCSI Software Initiator. The > initiator is able to discover the target however it is unable to login to > the target. > > The login Response shows that the = <0203> > indicating that "the requested ITN does not exist at this address" I have been using istgt for quite a while with no problems, both as a regular drive attachment and a full diskless iSCSI boot of Windows. Check istgt's entries in /var/log/messages and see if it logs something useful about why it refused the login. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 17:34:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11158106564A; Fri, 9 Mar 2012 17:34:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2B48FC13; Fri, 9 Mar 2012 17:34:34 +0000 (UTC) Received: by werl4 with SMTP id l4so1612417wer.13 for ; Fri, 09 Mar 2012 09:34:34 -0800 (PST) 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=n1KDRDtAB9QgdncM/obEWLbrzA3g9afbCPSxwYxN2Lo=; b=xraQUZCsdLjSWrUDkvg7osMP/QSV+Z6mIJb2NgPWP5QM6tUN2j8BUcoRsIvpDg8TQ5 L+Luox7v5EM5sl/QsbBDmBHTbo6BwONOg56CTJjQokFEwFT/AXv07fAZVTFVDNRUgiSy KMImJM7fdnjBT6FI2nuAelPDKoi7EZ7TBQwMtHYbpDvOrS/IXcnGL4mactj5u56SvFEe D1tCjlDTeJOMfCONs3z0/Bt3fEKEdkx4ZVFfAgTQsPW8NsHIa/FyRJ8wDPaxY9pD/1zV 2IXVYUjVNR3P0ryODSor9ZwX/qP0it4CvdcgBFoz187NMTZXRu7OXKSgD+tx4lz8xs9l DU8A== MIME-Version: 1.0 Received: by 10.216.134.19 with SMTP id r19mr1932912wei.66.1331314474065; Fri, 09 Mar 2012 09:34:34 -0800 (PST) Received: by 10.180.82.168 with HTTP; Fri, 9 Mar 2012 09:34:33 -0800 (PST) In-Reply-To: References: <4F594856.3030303@incore.de> Date: Fri, 9 Mar 2012 09:34:33 -0800 Message-ID: From: Jack Vogel To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv@freebsd.org, freebsd-net@freebsd.org, Andreas Longwitz , Pyun YongHyeon Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:34:36 -0000 I do not own, nor have ever touched the fxp driver, so don't really have an opinion. Jack On Fri, Mar 9, 2012 at 1:36 AM, Adrian Chadd wrote: > Hi! > > That's actually a really good catch! > > yongari/jfv, what do you think? > > > Adrian > > On 8 March 2012 16:01, Andreas Longwitz wrote: > > Hi, > > > > recently I installed FreeBSD 8.2 Stable on some older machines with > > Intel 82550 and 82550C and found that the loading of microcode with the > > parameter link0 in the ifconfig command did not work anymore. The reaso= n > > for this is the commit r223608 for if_fxp.c with the comment: > > > > Disable microcode loading for 82550 and 82550C controllers. Loading > > the microcode caused SCB timeouts. > > > > I do not agree with this motivation and try to explain why. > > > > Without loading the microcode on 82550(C) there is a problem with > > mount_nfs -U server:/bigdisk /mnt > > cp /mnt/bigfile bigfile > > > > NFS with UDP works with 8 KB blocks and the cp hangs after some seconds > > and you see SCB messages on the console. The reason is the TCO bug of > > the hardware mentioned in rcvbundl.h. This old hardware bug disappears > > after loading the microcode. > > > > All my hardware run without problems in FreeBSD 4.11, loading of > > microcode is done by the function fxp_load_ucode(). Later there was > > trouble with the loading of microcode, see kern/103332 and kern/118909. > > I have posted my solution for the problem to kern/103332 but > > unfortunately this PR is not online anymore and so I repeat my > > considerations here. > > > > The difference of the function fxp_load_ucode() of FreeBSD 4.11 and > > later versions is that this function in 4.11 has an own private memory > > buffer for construction of the microcode message. In later versions > > fxp_load_ucode() must use a memory buffer that is shared with other > > parts of the driver and these other parts of the driver have problems i= f > > the shared memory buffer was used by fxp_load_ucode() before. Thats the > > reason for "Loading microcode caused SCB timeouts". > > > > Therefore my proposal is to revert r223608 and to clean the used shared > > buffer at the end of the function fxp_load_ucode(). The following patch > > works for me for years now: > > > > --- if_fxp.c.orig 2012-01-26 12:43:09.000000000 +0100 > > +++ if_fxp.c 2012-03-08 23:41:32.000000000 +0100 > > @@ -3085,6 +3081,7 @@ > > sc->tunable_int_delay, > > uc->bundle_max_offset =3D=3D 0 ? 0 : sc->tunable_bundle_max)= ; > > sc->flags |=3D FXP_FLAG_UCODE; > > + bzero(cbp, (uc->length + 2) * sizeof(uint32_t)); > > } > > > > > > -- > > Dr. Andreas Longwitz > > > > Data Service GmbH > > Beethovenstr. 2A > > 23617 Stockelsdorf > > Amtsgericht L=FCbeck, HRB 318 BS > > Gesch=E4ftsf=FChrer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flat= au > > _______________________________________________ > > 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 Mar 9 23:32:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B866106566C; Fri, 9 Mar 2012 23:32:58 +0000 (UTC) (envelope-from leschnik@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 190788FC16; Fri, 9 Mar 2012 23:32:57 +0000 (UTC) Received: by ggnk4 with SMTP id k4so1510990ggn.13 for ; Fri, 09 Mar 2012 15:32:57 -0800 (PST) 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:content-transfer-encoding; bh=TbW2hpKbOAmiLza23aTW7jb5Q7j9v+Ey3SeEoEa8NvA=; b=wx36EUqcqpcD62P7fZCCGChijeiGnIltcq7woar6CP+HB9DINe9024s5OXvdQa/v3r ClYTOb/UWTSZG8p0Y4lNLabnIv3mx7wOOjX1zEbCyqHEcFUp41uFjyBoXTV2FXO8vFXx OcUmTZKh5SOVcxt17NR1ztFKQFk7nuRFbgS5OoMvo1tcyrfcAmoEt5rTHcakb1SYcY14 HIf8uZxitc6Pqil3n0LYyc5gQuDS2fkeLgPAI3Ifvc+fMe/DMmgx9KfYsKAqgB5XqVU3 ETowS2D2qYDtThH99yLjDNA223DI5cNJu++C9FLKvKG6jh1mf6LC8BkY9CDbTbg+tXui kS0w== MIME-Version: 1.0 Received: by 10.236.46.134 with SMTP id r6mr4743083yhb.106.1331335977444; Fri, 09 Mar 2012 15:32:57 -0800 (PST) Received: by 10.100.11.7 with HTTP; Fri, 9 Mar 2012 15:32:57 -0800 (PST) In-Reply-To: <20120309143434.GB91986@sandvine.com> References: <20120309143434.GB91986@sandvine.com> Date: Sat, 10 Mar 2012 10:32:57 +1100 Message-ID: From: Jason Leschnik To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Lagg failover does not announce the failover to switch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:32:58 -0000 So much win, Thanks Ed I will get some boxes up to test it and report back the results. Where is the best place to report results beside the forum? Would you like then back in this thread of mail? Cheers :) On Sat, Mar 10, 2012 at 1:34 AM, Ed Maste wrote: > On Wed, Mar 07, 2012 at 02:28:32PM +1100, Jason Leschnik wrote: > >> Lagg failover does not gratuitous ARP on the new interface to announce >> the link failover - This leaves clients trying to access the failed >> link and never making it to the up'd link. >> >> Bug ID: 156226 >> Found on this todo list: http://wiki.freebsd.org/EdMaste/ToDo >> >> I was wondering if i could offer a donation Hardware/Money to get this >> fixed, in my opinion this is a very important feature for the >> platform. I understand there are other ways to correct the behavior >> but one would expect this to be solved in the driver. > > We've posted a prototype patch for comments: > http://lists.freebsd.org/pipermail/freebsd-net/2012-February/031328.html > > Gleb raised some concerns that we'll look to address before this is > ready to be committed to the tree, but any testing you can provide on > the patch in its current state would be appreciated. =A0The (externally > visible) functionality should remain unchanged. > > I appreciate your offer of a hardware or monetary donation, although at > this point we're not being held up by either. =A0You can send your > donation to the FreeBSD Foundation instead to help support the FreeBSD > project in general. > > Regards, > Ed Maste --=20 Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@]=A0jml974@uow.edu.au From owner-freebsd-net@FreeBSD.ORG Fri Mar 9 23:54:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12773106566B for ; Fri, 9 Mar 2012 23:54:26 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB09A8FC08 for ; Fri, 9 Mar 2012 23:54:25 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2367639vcm.13 for ; Fri, 09 Mar 2012 15:54:25 -0800 (PST) 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:content-type; bh=4NAlBrj5Dil6fCaUQ03ULrGGQaJu7hh2uwThmr+wc4Q=; b=hWl5l2DuvfqQT7CRpbbqsO1sXW/2nu3E4JGnsrg6EjJozZVXieCKfii39yY/65TwZc 1bSUwUoLfs6/Qyq2DTPEld/flDchH71tu/fizOy80OVXhlocG3s+s8vC6yVm6F8AynTc SOIrGSkNBCCu/rt2yLiHD/Sf2x7OqXV0jf1HypoVrHbdeAeOqVnPzHLhYq9RWHsVl7hJ CKoI1qfTgrGnzBKAV8jOqzh7MEA9dAnLj1cGaNJxYnGvqhcTKM8ZwEzA8drpXedpKwMb 7gJ9Bwyzl2V0MLbiGudo9RLP8JVAIn+ycEbOYeWWmPrKV5BhSaXdXZGRuZx0yMvsBSkK IP7Q== MIME-Version: 1.0 Received: by 10.52.27.1 with SMTP id p1mr7044702vdg.17.1331335561793; Fri, 09 Mar 2012 15:26:01 -0800 (PST) Sender: annonymouse@gmail.com Received: by 10.220.118.19 with HTTP; Fri, 9 Mar 2012 15:26:01 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 23:26:01 +0000 X-Google-Sender-Auth: q9P38ejw-v7-PwUD24FoSUI3uSA Message-ID: From: Alex Yong To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strong host model in IPv6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:54:26 -0000 (Originally posted on freebsd-hackers@ - sorry) Hi all, I've been playing around with IPv6 networking on FreeBSD release 8.2 and found that there seems to be no strong incoming host model as specified in RFC 1122. I've spotted that in IPv4 there is the sysctl "net.inet.ip.check_interface" which defaults to set, but I've been unable to find any guarantees that strong host model is enforced in v6 in the comments or internet. According to the IPv6 Core Protocols Implementation book (3.7 "Input processing: ip6_input() Function") the incoming network packet processing in ip6_input should use the routing table to look up whether packets are of relevance for an interface - but the code base has diverged significantly since then including vnets for jails which makes me wonder if this is a bug. However before going into the long grass and trying to fix it I thought I'd ask here to see if there's anything I could try first, if I'm making some horrific mistakes, or if somebody had come across this already (I had a quick look at svn but didn't see anything of concern). My recipe for reproducing is thus: One FreeBSD 8.2 machine (the box under test), with 2 network interfaces (interface 0 and interface 1). interface 0 is connected to a subnet with routes to the outside world on v4 and v6. Interface 1 is connected directly via ethernet cable to the interface of a testing machine, with v4 disabled and a static v6 address for an unroutable subnet via the other interface. A route is configured for this subnet out of interface 1 (to allow for communications with the testing machine). The testing machine (which happens to be running FreeBSD) has 2 network interfaces (interface A and B). Interface A is connected to the same subnet as interface 0 (this is for my administration prodding of the testing device), and interface B is directly connected to interface 1 on the machine under test. Interface B has a staticly configured IPv6 address that matches the subnet of interface 1. It has a route to allow traffic to flow this way, *and* a route configured to route traffic for the box under tests interface 0 IPv6 address via interface B. If I ping interface 0 from box 1, I get a response. To prove that the response isn't coming in via the other links I used tcpdump on that interface on the testing machine *and* the machine under test and showed packets entering and responses leaving those interfaces. My expectation here would be to see packets entering (as the bpf hook is below the IP layer) but see no response. I checked sysctl net.inet6.ip6.forwarding is set to 0 (on both machines). Many thanks for any help AlexY From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 00:02:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 260E2106564A for ; Sat, 10 Mar 2012 00:02:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E0BA414D81A; Sat, 10 Mar 2012 00:02:58 +0000 (UTC) Message-ID: <4F5A9A34.8080303@FreeBSD.org> Date: Fri, 09 Mar 2012 16:03:00 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alex Yong References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Strong host model in IPv6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:02:59 -0000 So I guess I'll re-ask the question here: According to https://tools.ietf.org/html/rfc1122 that RFC has been updated quite a bit over the last 23 years. Have you followed that chain upwards to make sure that your concerns are still valid? Doug On 3/9/2012 3:26 PM, Alex Yong wrote: > (Originally posted on freebsd-hackers@ - sorry) > > Hi all, > > I've been playing around with IPv6 networking on FreeBSD release 8.2 and > found that there seems to be no strong incoming host model as specified in > RFC 1122. > > I've spotted that in IPv4 there is the sysctl "net.inet.ip.check_interface" > which defaults to set, but I've been unable to find any guarantees that > strong host model is enforced in v6 in the comments or internet. According > to the IPv6 Core Protocols Implementation book (3.7 "Input processing: > ip6_input() Function") the incoming network packet processing in ip6_input > should use the routing table to look up whether packets are of relevance > for an interface - but the code base has diverged significantly since then > including vnets for jails which makes me wonder if this is a bug. However > before going into the long grass and trying to fix it I thought I'd ask > here to see if there's anything I could try first, if I'm making some > horrific mistakes, or if somebody had come across this already (I had a > quick look at svn but didn't see anything of concern). > > My recipe for reproducing is thus: > > One FreeBSD 8.2 machine (the box under test), with 2 network interfaces > (interface 0 and interface 1). interface 0 is connected to a subnet with > routes to the outside world on v4 and v6. Interface 1 is connected > directly via ethernet cable to the interface of a testing machine, with v4 > disabled and a static v6 address for an unroutable subnet via the other > interface. A route is configured for this subnet out of interface 1 (to > allow for communications with the testing machine). > > The testing machine (which happens to be running FreeBSD) has 2 network > interfaces (interface A and B). Interface A is connected to the same > subnet as interface 0 (this is for my administration prodding of the > testing device), and interface B is directly connected to interface 1 on > the machine under test. Interface B has a staticly configured IPv6 address > that matches the subnet of interface 1. It has a route to allow traffic to > flow this way, *and* a route configured to route traffic for the box under > tests interface 0 IPv6 address via interface B. > > If I ping interface 0 from box 1, I get a response. To prove that the > response isn't coming in via the other links I used tcpdump on that > interface on the testing machine *and* the machine under test and showed > packets entering and responses leaving those interfaces. My expectation > here would be to see packets entering (as the bpf hook is below the IP > layer) but see no response. > > I checked sysctl net.inet6.ip6.forwarding is set to 0 (on both machines). > > Many thanks for any help > > AlexY -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 00:41:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53774106564A for ; Sat, 10 Mar 2012 00:41:22 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B59C8FC15 for ; Sat, 10 Mar 2012 00:41:21 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2408972vcm.13 for ; Fri, 09 Mar 2012 16:41:21 -0800 (PST) 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=YWiMALv5f7m1scMLSrK1XVMcBt8fXX+84a7mWVFKRUM=; b=qcvM4KYjJoQLjbv6TPvqegXAVVBmCLlTaQ84gG+lD+0u7ADnV7rBclbkzgrNdyUnO+ U/2vXeAHKXw8TxD8DAQI9CFfF0zhhs9OJIXAI7R5eiQ+e37fOYCA04/KYBiIhPWf90Xt G/wVwpd5UgwvAwwTIrBVMG4Y2rQJmtjeIE9fuAex6kABi/JcIUx0FGoH0UFCjzfYPZkV i31bmIsp+qgz8YFLgzzW8NRpseRGvdF9ZCEPb5rCcvciPSGysoh/ZjUMgzXholiL1e3x GkWcD95vGy5X1MnK93izU0BuI8nnjBgREsjGYKTLL7OY/F5A03tMJis1vhT1D0cjuQ+2 W8+Q== MIME-Version: 1.0 Received: by 10.52.27.1 with SMTP id p1mr7328933vdg.17.1331340081449; Fri, 09 Mar 2012 16:41:21 -0800 (PST) Sender: annonymouse@gmail.com Received: by 10.220.118.19 with HTTP; Fri, 9 Mar 2012 16:41:20 -0800 (PST) In-Reply-To: <4F5A9A34.8080303@FreeBSD.org> References: <4F5A9A34.8080303@FreeBSD.org> Date: Sat, 10 Mar 2012 00:41:20 +0000 X-Google-Sender-Auth: b9QLoFa39_9UFuwn3v1VBARbzYo Message-ID: From: Alex Yong To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Strong host model in IPv6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:41:22 -0000 On 10 March 2012 00:03, Doug Barton wrote: > So I guess I'll re-ask the question here: According to > https://tools.ietf.org/html/rfc1122 that RFC has been updated quite a > bit over the last 23 years. Have you followed that chain upwards to make > sure that your concerns are still valid? > > > Doug > My question is perhaps not phrased brilliantly. I shouldn't have used the word "specified" when talking about the RFC and maybe re-written my question so apologies - it's late here. To sum up, is FreeBSD intended to support the strong host model for IPv6 as described in that RFC? As my tests don't seem to show it as not doing so, which seems contrary to what the KAME book suggests. However I can't find any specific wording on this on the internet or freebsd site. If this is so, is there any sysctl or other mechanism which I've missed which enables said strong host model - or am I stuck? As you have pointed out, RFC 1122 is 23 years old and covers a lot of the basics of what IP networking is and as a result has a significant number of updating RFCs. I simply point to it for the definition of strong ES model which is not redefined, and is referenced in the FreeBSD code base for at least IPv4 in ip_input.c. Next time I'll just say "strong host model". AlexY From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 00:59:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C4EB106566B for ; Sat, 10 Mar 2012 00:59:33 +0000 (UTC) (envelope-from prabhakar.lakhera@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2DB8FC25 for ; Sat, 10 Mar 2012 00:59:33 +0000 (UTC) Received: by yenl9 with SMTP id l9so1552540yen.13 for ; Fri, 09 Mar 2012 16:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t23+TuW2yxlKvnFP4PvarBxCNG828M/6HjeYhc++lzw=; b=x0rov2uGbZllML0YhKSvD/wZ9/FjTxSyx6+cc1SckW7tBMsgaF2px2FdcmjM4Yh3r6 96iNgREWIJXl36s7sPdP4Sxrby+xLcAEKw44RAPE9TtoPuGz2wiySjmjb/d7cMY2/xoN 7IPUxWF8l2eUfSTtS9FmkTiemHRol+FqFefoOonMsXjIQNCwP/N2eq6K0I9Efg0RWZk6 WRc8xAvDVQb9Pp7r2mQ+B65ySflLH1/dVBGuahFeg2BYZImyi2y3cQx/j0R/26UB/l/m VfnyY0PPV3ZwvmOaNhnURG21vuwVJgHdDRoWmOAq0opjmAYJW03pQMjde8P2DGSSRVFw FjJg== MIME-Version: 1.0 Received: by 10.236.118.131 with SMTP id l3mr334033yhh.82.1331341172674; Fri, 09 Mar 2012 16:59:32 -0800 (PST) Received: by 10.101.61.11 with HTTP; Fri, 9 Mar 2012 16:59:32 -0800 (PST) Date: Fri, 9 Mar 2012 16:59:32 -0800 Message-ID: From: prabhakar lakhera 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: Race condition in IPv6 DAD detection code? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:59:33 -0000 Hi, I had sent a mail sometime back regarding some queries/concern regarding v6 DAD detection code. Here's what my concern is, drawing tables for the whole sequence in hopes of getting some replies: *CPU1* *CPU2* In nd6_dad_na_input... struct dadq *dp; if (ifa =3D=3D NULL) panic("ifa =3D=3D NULL in nd6_dad_na_input"); dp =3D nd6_dad_find(ifa); if (dp) nd6_dad_timer.. last attempt and NA counter not yet incremented by the thread on CPU1, therefore address considered to be not duplicated. if (dp->dad_ns_ocount < dp->dad_count) { =85.. } else { /* * We have transmitted sufficient number of DAD packets. * See what we've got. */ int duplicate; duplicate =3D 0; if (dp->dad_na_icount) { /* * the check is in nd6_dad_na_input(), * but just in case */ duplicate++; } if (dp->dad_ns_icount) { /* We've seen NS, means DAD has failed. */ duplicate++; } if (duplicate) { =DF----- Duplicate 0 here /* (*dp) will be freed in nd6_dad_duplicated() */ dp =3D NULL; nd6_dad_duplicated(ifa); } else { In nd6_dad_na_input... dp->dad_na_icount++; /* remove the address. */ nd6_dad_duplicated(ifa); Inside nd6_dad_duplicated=85 nd6_dad_duplicated(struct ifaddr *ifa) { struct in6_ifaddr *ia =3D (struct in6_ifaddr *)ifa; struct ifnet *ifp; struct dadq *dp; char ip6buf[INET6_ADDRSTRLEN]; dp =3D nd6_dad_find(ifa); if (dp =3D=3D NULL) { log(LOG_ERR, "nd6_dad_duplicated: DAD structure not found\n"); return; } =85. --=E0 dp is not NULL as has not yet been removed from queue. Nd6_dad_timer executing else=85. /* * We are done with DAD. No NA came, no NS came. * No duplicate address found. */ ia->ia6_flags &=3D ~IN6_IFF_TENTATIVE; nd6log((LOG_DEBUG, "%s: DAD complete for %s - no duplicates found\n", if_name(ifa->ifa_ifp), ip6_sprintf(ip6buf, &ia->ia_addr.sin6_addr))); TAILQ_REMOVE(&V_dadq, (struct dadq *)dp, dad_list); free(dp, M_IP6NDP); dp =3D NULL; ifa_free(ifa); } In nd6_dad_duplicated(struct ifaddr *ifa) =85 *Working on freed pointer??? * * log(LOG_ERR, "%s: DAD detected duplicate IPv6 address %s: "* * "NS in/out=3D%d/%d, NA in=3D%d\n",* * if_name(ifa->ifa_ifp), ip6_sprintf(ip6buf, &ia->ia_addr.sin6_addr),* * dp->dad_ns_icount, dp->dad_ns_ocount, dp->dad_na_icount);* On Wed, Mar 7, 2012 at 5:51 PM, prabhakar lakhera < prabhakar.lakhera@gmail.com> wrote: > Hi, > > I was puzzled to look at DAD detection code in FreeBSD. We check for > counters for any received NA/NS for DAD in nd6_dad_timer: > > if (dp->dad_na_icount) { > 1326 /* > 1327 * the check is in nd6_dad_na_input(), > 1328 * but just in case > 1329 */ > 1330 duplicate++; > 1331 } > 1332 > 1333 if (dp->dad_ns_icount) { > 1334 /* We've seen NS, means DAD has failed. */ > 1335 duplicate++; > 1336 } > 1337 > 1338 if (duplicate) { > 1339 /* (*dp) will be freed in > nd6_dad_duplicated() */ > 1340 dp =3D NULL; > 1341 nd6_dad_duplicated(ifa); > > the function later calls nd6_dad_duplicated to perform the remaining work > if the address is detected duplicate. > > nd6_dad_duplicated also gets called from nd6_dad_na_input > and nd6_dad_ns_input, both the functions are the only places which > increment the input NA/NS counters respectively. > > 1505 static void > 1506 nd6_dad_na_input(struct ifaddr *ifa) > 1507 { > 1508 struct dadq *dp; > 1509 > 1510 if (ifa =3D=3D NULL) > 1511 panic("ifa =3D=3D NULL in nd6_dad_na_input"); > 1512 > 1513 dp =3D nd6_dad_find(ifa); > 1514 if (dp) > 1515 dp->dad_na_icount++; > 1516 > 1517 /* remove the address. */ > 1518 nd6_dad_duplicated(ifa); > 1519 } > > nd6_dad_duplicated stops the timer among other things. > > Why nd6_dad_timer need check on these counters if we stop the timer on DA= D > failure anyways? > Ok.. may be just an optimization which just "hopes" that the counters hav= e > been updated but the nd6_dad_*_input has not yet called nd6_dad_duplicate= d. > > Can the this timer and na packet processing ever run in parallel, I don;t > see dp being protected by any locks, nor does it seem that it's been > reference counted. > Any explanation will be highly appreciated. > > Best, > > Prabhakar > > > > > > From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 06:05:46 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC3441065670; Sat, 10 Mar 2012 06:05:46 +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 A38A68FC18; Sat, 10 Mar 2012 06:05: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 q2A65kJg019375; Sat, 10 Mar 2012 06:05:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2A65kVm019371; Sat, 10 Mar 2012 06:05:46 GMT (envelope-from linimon) Date: Sat, 10 Mar 2012 06:05:46 GMT Message-Id: <201203100605.q2A65kVm019371@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165879: [tcp] Syncache syncache.count overflow X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 06:05:46 -0000 Old Synopsis: Syncache syncache.count overflow New Synopsis: [tcp] Syncache syncache.count overflow Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 10 06:05:20 UTC 2012 Responsible-Changed-Why: tcp-related. http://www.freebsd.org/cgi/query-pr.cgi?pr=165879 From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 06:29:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29EE8106566C; Sat, 10 Mar 2012 06:29:05 +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 DABD08FC12; Sat, 10 Mar 2012 06:29:04 +0000 (UTC) Received: by dald2 with SMTP id d2so2622182dal.13 for ; Fri, 09 Mar 2012 22:29:04 -0800 (PST) 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=HEhtIkysrWzYsZLr5tz0wLxtypqPda5GsXqwMh1Agig=; b=iJ2USSZnfIv4fylwjkK4dMSD80ATVeXISxlF1XF2tdwmSFQN+Z/jAZiVXptF/zX5tF MFAvOW3x2g/BiQXAO1+Yo50mudaV4yXOTeBHlkbBmgfi99o8xiNxjtU73UWgMzVkueJY 0ngbLA6dRPiXDwr426mqbA2sS7uS7uHaZ7q3QF2zz4fQ00fp3fVRxHWhDzdwEIyhFKfc dz156/RU08Kwb8CWmO7WNblsMfAiYFSN6Ifk5PHmbIcdBnaqtQnm3dKJGLJ22N35/RRL a5aGIh+A+Wgum/0/8GWIo/hNEjewpI6KrqGn7rFQbCkOnK4mn7z9tiqAprf62AI+jM1k ATcQ== Received: by 10.68.224.225 with SMTP id rf1mr7539507pbc.133.1331360944605; Fri, 09 Mar 2012 22:29:04 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id l1sm5743596pbe.54.2012.03.09.22.29.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 22:29:03 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 10 Mar 2012 15:29:02 -0800 From: YongHyeon PYUN Date: Sat, 10 Mar 2012 15:29:02 -0800 To: Adrian Chadd Message-ID: <20120310232902.GA4566@michelle.cdnetworks.com> References: <4F594856.3030303@incore.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: jfv@freebsd.org, freebsd-net@freebsd.org, Andreas Longwitz , Pyun YongHyeon Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 06:29:05 -0000 On Fri, Mar 09, 2012 at 01:36:22AM -0800, Adrian Chadd wrote: > Hi! > > That's actually a really good catch! > > yongari/jfv, what do you think? > Give me some more time to verify it on one of i82550 controller I have. > > Adrian > > On 8 March 2012 16:01, Andreas Longwitz wrote: > > Hi, > > > > recently I installed FreeBSD 8.2 Stable on some older machines with > > Intel 82550 and 82550C and found that the loading of microcode with the > > parameter link0 in the ifconfig command did not work anymore. The reason > > for this is the commit r223608 for if_fxp.c with the comment: > > > > Disable microcode loading for 82550 and 82550C controllers. Loading > > the microcode caused SCB timeouts. > > > > I do not agree with this motivation and try to explain why. > > > > Without loading the microcode on 82550(C) there is a problem with > > ? mount_nfs -U server:/bigdisk /mnt > > ? cp /mnt/bigfile bigfile > > > > NFS with UDP works with 8 KB blocks and the cp hangs after some seconds > > and you see SCB messages on the console. The reason is the TCO bug of > > the hardware mentioned in rcvbundl.h. This old hardware bug disappears > > after loading the microcode. > > > > All my hardware run without problems in FreeBSD 4.11, loading of > > microcode is done by the function fxp_load_ucode(). Later there was > > trouble with the loading of microcode, see kern/103332 and kern/118909. > > I have posted my solution for the problem to kern/103332 but > > unfortunately this PR is not online anymore and so I repeat my > > considerations here. > > > > The difference of the function fxp_load_ucode() of FreeBSD 4.11 and > > later versions is that this function in 4.11 has an own private memory > > buffer for construction of the microcode message. In later versions > > fxp_load_ucode() must use a memory buffer that is shared with other > > parts of the driver and these other parts of the driver have problems if > > the shared memory buffer was used by fxp_load_ucode() before. Thats the > > reason for "Loading microcode caused SCB timeouts". > > > > Therefore my proposal is to revert r223608 and to clean the used shared > > buffer at the end of the function fxp_load_ucode(). The following patch > > works for me for years now: > > > > --- if_fxp.c.orig ? ? ? 2012-01-26 12:43:09.000000000 +0100 > > +++ if_fxp.c ? ?2012-03-08 23:41:32.000000000 +0100 > > @@ -3085,6 +3081,7 @@ > > ? ? ? ? ? ?sc->tunable_int_delay, > > ? ? ? ? ? ?uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); > > ? ? ? ?sc->flags |= FXP_FLAG_UCODE; > > + ? ? ? bzero(cbp, (uc->length + 2) * sizeof(uint32_t)); > > ?} > > > > > > -- > > 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 Sat Mar 10 10:34:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D60D106566B for ; Sat, 10 Mar 2012 10:34:00 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id BADE68FC08 for ; Sat, 10 Mar 2012 10:33:59 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so1174366wib.13 for ; Sat, 10 Mar 2012 02:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2Z2Mo0/iGEab1Xw2RA3xgqMcZcBKlYb4Mar8cTSqcAw=; b=BX5mlBUBTCJGN6wy569y9u5oZUlFRaCGVWGlsL7G6P41RdtyyiAC34RpbK3DIDZvn8 jzAscMPLLRNGucrPpwAHoMpOF9gnx5jnuPmzNNenX3k2azXX1YmY91RdfrfS5IYhb2zu SPPx1Qioky6rtVQHd1ggBdqgrzGGKLx6gvSs7S6vxFCsGgAlcmzGqQ6Tivca+HfZt48J aYi01o6IzwlwV/KHbtqAMgQhyj/UoqhIHqf9LFPxsIS3z/G9yS18RVJPDIVh4EPN+W1D jAJqh3IRFoxdUqLXd4SdAQGEnUpTQBmOvpwL1KdyNce6MrnX2B6Wq4nu0tM9xe/7jBoA 9AgA== Received: by 10.180.24.166 with SMTP id v6mr12220205wif.10.1331375638606; Sat, 10 Mar 2012 02:33:58 -0800 (PST) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id bg3sm13086529wib.10.2012.03.10.02.33.56 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 02:33:57 -0800 (PST) Message-ID: <4F5B2E0E.10201@gmail.com> Date: Sat, 10 Mar 2012 14:03:50 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Jason Wolfe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:34:00 -0000 Dear Jason With a link_irq of 4, I still guess your problem is snd_buf filling up during a temporary link_loss (see: http://lists.freebsd.org/pipermail/freebsd-net/2011-November/030424.html). I use a patched version of e1000 which addresses this issue and works good for me but it is based on 7.2.3 and I have just tested in on 7.3-RELEASE. If interested, I can send you the sources for test. You may also port my changes to 7.3.2 and roll your own version. On 3/8/2012 12:27 AM, Jason Wolfe wrote: > > I'm sure it's getting old with all of the recent work put into the > e1000 driver, but this is still ongoing with MSI-X enabled. Most > machines are running an 8.2-STABLE from early Feb, though it appears > there have been no relevant changes in RELENG_8 since then. I've > disabled all possible em options on the devices also to rule that out > and am still seeing the issue. I guess reverting back to MSI-X > disabled is the next step if nothing is spotted. This box had been > doing between 1 and 1.5Gb/s steady for the 26 days before the network > hang. > > From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 15:45:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F7E9106566C for ; Sat, 10 Mar 2012 15:45:38 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap.istanbul.net (spamtrap.istanbul.net [85.111.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id 2CB0E8FC0A for ; Sat, 10 Mar 2012 15:45:37 +0000 (UTC) X-ASG-Debug-ID: 1331393453-0426ae63028b020001-QdxwpM Received: from yuhanna.magnetdigital.local (yuhanna.magnetdigital.local [192.168.131.243]) by spamtrap.istanbul.net with ESMTP id 3DCTUSfNRxBX8wh8 for ; Sat, 10 Mar 2012 17:30:53 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.243 Received: from GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb]) by yuhanna.magnetdigital.local ([fe80::1058:3088:f9b1:1346%17]) with mapi id 14.01.0218.012; Sat, 10 Mar 2012 17:30:06 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::3cca:d6ef:febb:fafb To: "freebsd-net@freebsd.org" Thread-Topic: FreeBSD 9.0 some tuning for Best performance for 85598 intel controller X-ASG-Orig-Subj: FreeBSD 9.0 some tuning for Best performance for 85598 intel controller Thread-Index: Acz4XMjfcq97x+GiQLa5stvdo/Y5EgESYQ43AInCxyAAAVJ6UA== Date: Sat, 10 Mar 2012 15:30:05 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C044A49@GAMMA.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C030DB5@yuhanna.magnetdigital.local> <3807CE6F3BF4B04EB897F4EBF2D258CE5C038290@yuhanna.magnetdigital.local> Accept-Language: en-US, tr-TR Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.28.11.161] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01CCFEE3.6C5EDF90" MIME-Version: 1.0 X-Barracuda-Connect: yuhanna.magnetdigital.local[192.168.131.243] X-Barracuda-Start-Time: 1331393453 X-Barracuda-URL: http://10.10.140.221:8000/cgi-mod/mark.cgi X-ASG-Whitelist: Body =?UTF-8?B?Ll9ldmVudHM=?= X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 9.0 some tuning for Best performance for 85598 intel controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 15:45:38 -0000 ------=_NextPart_000_001A_01CCFEE3.6C5EDF90 Content-Type: multipart/related; boundary="----=_NextPart_001_001B_01CCFEE3.6C5EDF90" ------=_NextPart_001_001B_01CCFEE3.6C5EDF90 Content-Type: multipart/alternative; boundary="----=_NextPart_002_001C_01CCFEE3.6C5EDF90" ------=_NextPart_002_001C_01CCFEE3.6C5EDF90 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable =20 Hello, =20 I try to build server for syn flood rezist.. i buy IBM x3650 with 24 = core xeon cpu, 64 gbit Ram, SSD disk.. Also i plug in 52598 intel Intel=AE 10 Gigabit XF SR Server Adapter CARD on it. I install FreeBSD 9.0 Release version. And i find ixbge-2.4.4.tar.gz = driver and i install on FreeBSD =20 I checked document and support pages for intel.. i didnt find any = improve performance document for FreeBSD..=20 Like this http://www.intel.com/content/www/us/en/ethernet-controllers/82575-82576-8= 259 8-82599-ethernet-controllers-latency-appl-note.html (this is good for = linux) But i dont see any freebsd documentation.. I need to improve more better for performance.. Can you help me about = this case ? .. Because i know this network card can handle more pps.. (i = noticed 600.000 pps without input error with this configuration with 46 byte syn packets my best performance at this moment on open port). but i want to build for 2.000.000 pps syn flood rezisting ...=20 =20 I see only 8 irq rx queues for handling.. but i got 24 core cpu.. how = can assign more cpu for better performance. (i attached screen for 8 queue) = ( how can i assign more then 8 core.. ) Also Finally i need tuning for ixgbe-2.4.4 driver or change freebsd = kernel params for better performance ? Can anybody knows about that =20 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.no_tx_dma_setup: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.tso_tx: 0 dev.ix.0.link_irq: 0 dev.ix.0.queue0.interrupt_rate: 0 dev.ix.0.queue0.txd_head: 0 dev.ix.0.queue0.txd_tail: 0 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 0 dev.ix.0.queue0.rxd_head: 0 dev.ix.0.queue0.rxd_tail: 0 dev.ix.0.queue0.rx_packets: 0 dev.ix.0.queue0.rx_bytes: 0 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 0 dev.ix.0.queue1.txd_head: 0 dev.ix.0.queue1.txd_tail: 0 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 0 dev.ix.0.queue1.rxd_head: 0 dev.ix.0.queue1.rxd_tail: 0 dev.ix.0.queue1.rx_packets: 0 dev.ix.0.queue1.rx_bytes: 0 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 0 dev.ix.0.queue2.txd_head: 0 dev.ix.0.queue2.txd_tail: 0 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 0 dev.ix.0.queue2.rxd_head: 0 dev.ix.0.queue2.rxd_tail: 0 dev.ix.0.queue2.rx_packets: 0 dev.ix.0.queue2.rx_bytes: 0 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 0 dev.ix.0.queue3.txd_head: 0 dev.ix.0.queue3.txd_tail: 0 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 0 dev.ix.0.queue3.rxd_head: 0 dev.ix.0.queue3.rxd_tail: 0 dev.ix.0.queue3.rx_packets: 0 dev.ix.0.queue3.rx_bytes: 0 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 0 dev.ix.0.queue4.txd_head: 0 dev.ix.0.queue4.txd_tail: 0 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 0 dev.ix.0.queue4.rxd_head: 0 dev.ix.0.queue4.rxd_tail: 0 dev.ix.0.queue4.rx_packets: 0 dev.ix.0.queue4.rx_bytes: 0 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 0 dev.ix.0.queue5.txd_head: 0 dev.ix.0.queue5.txd_tail: 0 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 0 dev.ix.0.queue5.rxd_head: 0 dev.ix.0.queue5.rxd_tail: 0 dev.ix.0.queue5.rx_packets: 0 dev.ix.0.queue5.rx_bytes: 0 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 0 dev.ix.0.queue6.txd_head: 0 dev.ix.0.queue6.txd_tail: 0 dev.ix.0.queue6.no_desc_avail: 0 dev.ix.0.queue6.tx_packets: 0 dev.ix.0.queue6.rxd_head: 0 dev.ix.0.queue6.rxd_tail: 0 dev.ix.0.queue6.rx_packets: 0 dev.ix.0.queue6.rx_bytes: 0 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 0 dev.ix.0.queue7.txd_head: 0 dev.ix.0.queue7.txd_tail: 0 dev.ix.0.queue7.no_desc_avail: 0 dev.ix.0.queue7.tx_packets: 0 dev.ix.0.queue7.rxd_head: 0 dev.ix.0.queue7.rxd_tail: 0 dev.ix.0.queue7.rx_packets: 0 dev.ix.0.queue7.rx_bytes: 0 dev.ix.0.queue7.lro_queued: 0 dev.ix.0.queue7.lro_flushed: 0 =20 Here my driver,=20 =20 bsd# dmesg | grep ix module_register: module pci/ixgbe already exists! Module pci/ixgbe failed to register: 17 module_register: module pci/ixv already exists! Module pci/ixv failed to register: 17 acpi0: Power Button (fixed) ix0: = port 0x2000-0x201f mem 0x9ba40000-0x9ba5ffff,0x9ba00000-0x9ba3ffff,0x9ba60000-0x9ba63fff irq 30 = at device 0.0 on pci31 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: Ethernet address: 00:1b:21:cb:57:96 ix0: PCI Express Bus: Speed 2.5Gb/s Width x8 =20 Also here my /boot/loader.conf =20 gaze# cat /boot/loader.conf=20 #Useful when your software uses select() instead of kevent/kqueue or = when you under DDoS # DNS accf available on 8.0+ accf_data_load=3D"YES"=20 accf_http_load=3D"YES" =20 # Async IO system calls aio_load=3D"YES" =20 # Intel 52598 load driver ixgbe_load=3D"YES" =20 # Load cubic cubic_load=3D"YES" =20 #hw.bce.rxd=3D2048 #hw.igb.rxd=3D2048 #hw.bce.tso_enable=3D0 #hw.pci.enable_msix=3D0 #net.isr.direct_force=3D1 #net.isr.direct=3D1 #net.isr.maxthreads=3D12 # Max number of threads for NIC = IRQ balancing (4 cores in box) #net.isr.numthread=3D12 =20 =20 autoboot_delay=3D"3" # reduce boot menu delay from 10 = to 3 seconds #if_bce_load=3D"YES" # load the Myri10GE kernel = module on boot loader_logo=3D"beastie" # old FreeBSD logo menu #net.inet.tcp.syncache.hashsize=3D1024 # syncache hash size #net.inet.tcp.syncache.bucketlimit=3D100 # syncache bucket limit #net.inet.tcp.tcbhashsize=3D4096 # tcb hash size net.isr.bindthreads=3D0 # do not bind threads to CPUs net.isr.direct=3D1 # interrupt handling via = multiple CPU net.isr.direct_force=3D1 # " net.isr.maxthreads=3D16 # Max number of threads for NIC IRQ balancing (4 cores in box) hw.pci.enable_msix=3D1 hw.ix.rx_process_limit=3D1000000 hw.igb.rx_process_limit=3D1000000 hw.em.rxd=3D2048 hw.igb.rxd=3D2048 =20 And my /etc/sysctl.conf =20 # release/9.0.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped = thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for = details. # =20 # Uncomment this to prevent users from seeing information about = processes that # are being run under another UID. #security.bsd.see_other_uids=3D0 =20 # INCREASE BUFFER SIZE OF CONNECTIONS kern.ipc.nmbclusters=3D2560000 =20 # Increase Storm control hw.intr_storm_threshold=3D40000 =20 # Descrease ACK, SYN-ACK, FIN-ACK wait time net.inet.tcp.msl=3D5000 =20 # DROP TCP CONNECTION IF ON CLOSED PORT net.inet.tcp.blackhole=3D2 =20 # DROP UDP CONNECT=DDON IF ON CLOSED PORT net.inet.udp.blackhole=3D1 =20 # ICMP RESPONSE LIMITING Max : 50 after 50 dont RESPONSE net.inet.icmp.icmplim=3D50 =20 # BACKLOG QUEUE kern.ipc.somaxconn=3D65535 =20 # Increase Sockets kern.ipc.maxsockets=3D20480000 =20 # Increase Socket Buffer kern.ipc.maxsockbuf=3D104857600 =20 # For lower latency you can decrease scheluer's maximum time slice kern.sched.slice=3D1 =20 # Every socket is a life, so increase them kern.maxfiles=3D20480000 kern.maxfilesperproc=3D200000000 kern.maxvnodes=3D20000000 =20 # Incrase buffers net.inet.tcp.recvspace=3D65536000 net.inet.tcp.recvbuf_max=3D1048576000 net.inet.tcp.recvbuf_inc=3D6553500 net.inet.tcp.sendspace=3D32768000 net.inet.tcp.sendbuf_max=3D2097152000 net.inet.tcp.sendbuf_inc=3D8192000 =20 # Also timestamp field is useful when using syncookies net.inet.tcp.rfc1323=3D1 =20 # If you set it there is no need in TCP_NODELAY sockopt (see man tcp) net.inet.tcp.delayed_ack=3D0 =20 # Turn off receive autotuning # You can play with it. #net.inet.tcp.recvbuf_auto=3D0 #net.inet.tcp.sendbuf_auto=3D0 =20 # We assuming we have very fast clients #net.inet.tcp.slowstart_flightsize=3D100 #net.inet.tcp.local_slowstart_flightsize=3D100 =20 =20 # For outgoing connections only. Good for seed-boxes and ftp servers. net.inet.ip.portrange.first=3D1024 net.inet.ip.portrange.last=3D65535 =20 =20 # stops route cache degregation during a high-bandwidth flood #net.inet.ip.rtexpire=3D2 net.inet.ip.rtminexpire=3D2 net.inet.ip.rtmaxcache=3D1024 =20 # Security net.inet.ip.sourceroute=3D0 net.inet.ip.accept_sourceroute=3D0 net.inet.icmp.maskrepl=3D0 net.inet.icmp.log_redirect=3D0 net.inet.tcp.drop_synfin=3D1 =20 # Security net.inet.ip.redirect=3D0 net.inet.ip.sourceroute=3D0 net.inet.ip.accept_sourceroute=3D0 net.inet.icmp.log_redirect=3D0 =20 # Max number of timewait sockets (Maximum number of compressed TCP = TIME_WAIT entries) net.inet.tcp.maxtcptw=3D20000000 =20 =20 # FIN_WAIT_2 state fast recycle net.inet.tcp.fast_finwait2_recycle=3D1 =20 # Time before tcp keepalive probe is sent # default is 2 hours (7200000) net.inet.tcp.keepidle=3D60000 =20 # Should be increased until net.inet.ip.intr_queue_drops is zero net.inet.ip.intr_queue_maxlen=3D4096 =20 =20 # enable send/recv autotuning net.inet.tcp.sendbuf_auto=3D1 net.inet.tcp.recvbuf_auto=3D1 =20 # increase autotuning step size=20 net.inet.tcp.sendbuf_inc=3D16384=20 net.inet.tcp.recvbuf_inc=3D524288=20 =20 # turn off inflight limitting #net.inet.tcp.inflight.enable=3D0 =20 # set this on test/measurement hosts net.inet.tcp.hostcache.expire=3D1 =20 # Randomized proccess id's kern.randompid=3D348 =20 # do not processes any TCP options in the TCP headers net.inet.ip.process_options=3D0 =20 # disable MTU path discovery net.inet.tcp.path_mtu_discovery=3D0 =20 # Disable SACK net.inet.tcp.sack.enable=3D0 =20 kern.ipc.shmmax=3D5368709120 kern.ipc.shmall=3D13107200 kern.ipc.semmsl=3D1024 =20 net.inet6.ip6.auto_linklocal=3D0 net.inet.tcp.syncookies=3D0 =20 # BPF increase buffer size net.bpf.maxbufsize=3D1048576 =20 kern.ipc.nmbjumbop=3D262144 kern.ipc.nmbjumbo16=3D32000 kern.ipc.nmbjumbo9=3D64000 =20 dev.ix.0.fc=3D0 =20 =20 Best Regards.. =20 =20 =20 Seyit =D6zg=FCr Network Y=F6neticisi=20 =09 Description: Magnet A.=DE. =09 =09 Eski =DCsk=FCdar Cad. No:10 VIP Center Kat:7 =DD=E7erenk=F6y Ata=FEehir =DDstanbul t: 0216 577 33 11 | f: 0216 469 52 43 www.magnetdigital.com=20 =09 =09 =09 =20 ------=_NextPart_002_001C_01CCFEE3.6C5EDF90 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" Hello, I try to build server for = syn flood rezist.. i buy IBM x3650 with 24 core xeon cpu, 64 gbit Ram, = SSD disk.. Also i plug in 52598 intel Intel=AE 10 Gigabit XF SR Server = Adapter CARD on it. I install FreeBSD 9.0 Release version. And i find = ixbge-2.4.4.tar.gz driver and i install on = FreeBSD I checked document = and support pages for = intel.. i didnt find any improve = performance document for FreeBSD.. Like this [1]http://www.intel.com/content/www/us/en/ethernet-control= lers/82575-82576-82598-82599-ethernet-controllers-latency-appl-note.ht ml<= /a> (this is good for linux) But i dont see any freebsd = documentation.. I need to improve more better for performance.. = Can you help me about this case ? .. Because i know this network card = can handle more pps.. (i noticed 600.000 pps without input error with = this configuration with 46 byte syn packets my best performance at this = moment on open port). but i want to build for 2.000.000 pps syn flood = rezisting ... I see only 8 irq rx queues = for handling.. but i got 24 core cpu.. how can assign more cpu for = better performance. (i attached screen for 8 queue) ( how can i assign = more then 8 core.. ) Also Finally = i need tuning for ixgbe-2.4.4 driver or change freebsd kernel params for = better performance ? Can anybody = knows about that dev.ix.0.dropped: = 0 dev.ix.0.mbuf_defrag_failed: = 0 dev.ix.0.no_tx_dma_setup: = 0 dev.ix.0.watchdog_events: = 0 dev.ix.0.tso_tx: 0 dev.ix.0.link_irq: = 0 dev.ix.0.queue0.interrupt_rate: = 0 dev.ix.0.queue0.txd_head: = 0 dev.ix.0.queue0.txd_tail: = 0 dev.ix.0.queue0.no_desc_avail: = 0 dev.ix.0.queue0.tx_packets: = 0 dev.ix.0.queue0.rxd_head: = 0 dev.ix.0.queue0.rxd_tail: = 0 dev.ix.0.queue0.rx_packets: = 0 dev.ix.0.queue0.rx_bytes: = 0 dev.ix.0.queue0.lro_queued: = 0 dev.ix.0.queue0.lro_flushed: = 0 dev.ix.0.queue1.interrupt_rate: = 0 dev.ix.0.queue1.txd_head: = 0 dev.ix.0.queue1.txd_tail: = 0 dev.ix.0.queue1.no_desc_avail: = 0 dev.ix.0.queue1.tx_packets: = 0 dev.ix.0.queue1.rxd_head: = 0 dev.ix.0.queue1.rxd_tail: = 0 dev.ix.0.queue1.rx_packets: = 0 dev.ix.0.queue1.rx_bytes: = 0 dev.ix.0.queue1.lro_queued: = 0 dev.ix.0.queue1.lro_flushed: = 0 dev.ix.0.queue2.interrupt_rate: = 0 dev.ix.0.queue2.txd_head: = 0 dev.ix.0.queue2.txd_tail: = 0 dev.ix.0.queue2.no_desc_avail: = 0 dev.ix.0.queue2.tx_packets: = 0 dev.ix.0.queue2.rxd_head: = 0 dev.ix.0.queue2.rxd_tail: = 0 dev.ix.0.queue2.rx_packets: = 0 dev.ix.0.queue2.rx_bytes: = 0 dev.ix.0.queue2.lro_queued: = 0 dev.ix.0.queue2.lro_flushed: = 0 dev.ix.0.queue3.interrupt_rate: = 0 dev.ix.0.queue3.txd_head: = 0 dev.ix.0.queue3.txd_tail: = 0 dev.ix.0.queue3.no_desc_avail: = 0 dev.ix.0.queue3.tx_packets: = 0 dev.ix.0.queue3.rxd_head: = 0 dev.ix.0.queue3.rxd_tail: = 0 dev.ix.0.queue3.rx_packets: = 0 dev.ix.0.queue3.rx_bytes: = 0 dev.ix.0.queue3.lro_queued: = 0 dev.ix.0.queue3.lro_flushed: = 0 dev.ix.0.queue4.interrupt_rate: = 0 dev.ix.0.queue4.txd_head: = 0 dev.ix.0.queue4.txd_tail: = 0 dev.ix.0.queue4.no_desc_avail: = 0 dev.ix.0.queue4.tx_packets: = 0 dev.ix.0.queue4.rxd_head: = 0 dev.ix.0.queue4.rxd_tail: = 0 dev.ix.0.queue4.rx_packets: = 0 dev.ix.0.queue4.rx_bytes: = 0 dev.ix.0.queue4.lro_queued: = 0 dev.ix.0.queue4.lro_flushed: = 0 dev.ix.0.queue5.interrupt_rate: = 0 dev.ix.0.queue5.txd_head: = 0 dev.ix.0.queue5.txd_tail: = 0 dev.ix.0.queue5.no_desc_avail: = 0 dev.ix.0.queue5.tx_packets: = 0 dev.ix.0.queue5.rxd_head: = 0 dev.ix.0.queue5.rxd_tail: = 0 dev.ix.0.queue5.rx_packets: = 0 dev.ix.0.queue5.rx_bytes: = 0 dev.ix.0.queue5.lro_queued: = 0 dev.ix.0.queue5.lro_flushed: = 0 dev.ix.0.queue6.interrupt_rate: = 0 dev.ix.0.queue6.txd_head: = 0 dev.ix.0.queue6.txd_tail: = 0 dev.ix.0.queue6.no_desc_avail: = 0 dev.ix.0.queue6.tx_packets: = 0 dev.ix.0.queue6.rxd_head: = 0 dev.ix.0.queue6.rxd_tail: = 0 dev.ix.0.queue6.rx_packets: = 0 dev.ix.0.queue6.rx_bytes: = 0 dev.ix.0.queue6.lro_queued: = 0 dev.ix.0.queue6.lro_flushed: = 0 dev.ix.0.queue7.interrupt_rate: = 0 dev.ix.0.queue7.txd_head: = 0 dev.ix.0.queue7.txd_tail: = 0 dev.ix.0.queue7.no_desc_avail: = 0 dev.ix.0.queue7.tx_packets: = 0 dev.ix.0.queue7.rxd_head: = 0 dev.ix.0.queue7.rxd_tail: = 0 dev.ix.0.queue7.rx_packets: = 0 dev.ix.0.queue7.rx_bytes: = 0 dev.ix.0.queue7.lro_queued: = 0 dev.ix.0.queue7.lro_flushed: = 0 Here my driver, = bsd# dmesg | grep = ix module_register: module pci/ixgbe already = exists! Module pci/ixgbe failed to register: = 17 module_register: module pci/ixv already = exists! Module pci/ixv failed to register: = 17 acpi0: Power Button = (fixed) ix0: port 0x2000-0x201f mem = 0x9ba40000-0x9ba5ffff,0x9ba00000-0x9ba3ffff,0x9ba60000-0x9ba63fff irq 30 = at device 0.0 on pci31 ix0: Using MSIX interrupts with 9 = vectors ix0: RX Descriptors exceed system mbuf max, using = default instead! ix0: Ethernet address: = 00:1b:21:cb:57:96 ix0: PCI Express Bus: Speed 2.5Gb/s Width = x8 Also here my = /boot/loader.conf gaze# cat = /boot/loader.conf #Useful when your software uses select() instead = of kevent/kqueue or when you under DDoS # DNS accf available on = 8.0+ accf_data_load=3D"YES" = accf_http_load=3D"YES"<= /p> # Async IO system = calls aio_load=3D"YES" # Intel 52598 load = driver ixgbe_load=3D"YES" <= p class=3DMsoNormal> # Load = cubic cubic_load=3D"YES" <= p class=3DMsoNormal> #hw.bce.rxd=3D2048 #hw.igb.rxd=3D2048 #hw.bce.tso_enable=3D0 #hw.pci.enable_msix=3D0 #net.isr.direct_force=3D1 #net.isr.direct=3D1 #net.isr.maxthreads=3D12 &nb= sp; # Max number of = threads for NIC IRQ balancing (4 cores in box) #net.isr.numthread=3D12 autoboot_delay=3D"3" &nb= sp; &nbs= p; # reduce boot menu delay from 10 to 3 = seconds #if_bce_load=3D"YES" &nb= sp; &nbs= p; # load the Myri10GE kernel module on = boot loader_logo=3D"beastie" = &= nbsp; # old FreeBSD logo menu #net.inet.tcp.syncache.hashsize=3D1024 = # syncache hash size #net.inet.tcp.syncache.bucketlimit=3D100 # = syncache bucket limit #net.inet.tcp.tcbhashsize=3D4096 &= nbsp; # tcb hash size net.isr.bindthreads=3D0 &nbs= p; # = do not bind threads to CPUs net.isr.direct=3D1 &nb= sp; &nbs= p; # interrupt handling via multiple = CPU net.isr.direct_force=3D1 &nb= sp; # = " net.isr.maxthreads=3D16 &nbs= p; # Max number of = threads for NIC IRQ balancing (4 cores in box) hw.pci.enable_msix=3D1 hw.ix.rx_process_limit=3D1000000<= /p> hw.igb.rx_process_limit=3D1000000= hw.em.rxd=3D2048 hw.igb.rxd=3D2048 And my = /etc/sysctl.conf # = release/9.0.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux = $ # # This file is read when going to multi-user = and its contents piped thru # ``sysctl'' to = adjust kernel values. ``man 5 sysctl.conf'' for = details. # # Uncomment this to = prevent users from seeing information about processes = that # are being run under another = UID. #security.bsd.see_other_uids=3D0<= /p> # INCREASE BUFFER SIZE OF = CONNECTIONS kern.ipc.nmbclusters=3D2560000 # Increase Storm = control hw.intr_storm_threshold=3D40000 # Descrease ACK, SYN-ACK, = FIN-ACK wait time net.inet.tcp.msl=3D5000 # DROP TCP CONNECTION IF = ON CLOSED PORT net.inet.tcp.blackhole=3D2 # DROP UDP CONNECT=DDON IF = ON CLOSED PORT net.inet.udp.blackhole=3D1 # ICMP RESPONSE LIMITING = Max : 50 after 50 dont RESPONSE net.inet.icmp.icmplim=3D50 # BACKLOG = QUEUE kern.ipc.somaxconn=3D65535 # Increase = Sockets kern.ipc.maxsockets=3D20480000 # Increase Socket = Buffer kern.ipc.maxsockbuf=3D104857600 # For lower latency you = can decrease scheluer's maximum time slice kern.sched.slice=3D1 # Every socket is a life, = so increase them kern.maxfiles=3D20480000 kern.maxfilesperproc=3D200000000<= /p> kern.maxvnodes=3D20000000 # Incrase = buffers net.inet.tcp.recvspace=3D65536000= net.inet.tcp.recvbuf_max=3D1048576000 net.inet.tcp.recvbuf_inc=3D6553500 net.inet.tcp.sendspace=3D32768000= net.inet.tcp.sendbuf_max=3D2097152000 net.inet.tcp.sendbuf_inc=3D8192000 # Also timestamp field is = useful when using syncookies net.inet.tcp.rfc1323=3D1 # If you set it there is = no need in TCP_NODELAY sockopt (see man tcp) net.inet.tcp.delayed_ack=3D0 <= p class=3DMsoNormal> # Turn off receive = autotuning # You can play with it. #net.inet.tcp.recvbuf_auto=3D0 #net.inet.tcp.sendbuf_auto=3D0 # We assuming we have very = fast clients #net.inet.tcp.slowstart_flightsize=3D100= #net.inet.tcp.local_slowstart_flightsize=3D100= # For outgoing connections = only. Good for seed-boxes and ftp servers. net.inet.ip.portrange.first=3D1024 net.inet.ip.portrange.last=3D65535 # stops route cache = degregation during a high-bandwidth flood #net.inet.ip.rtexpire=3D2 net.inet.ip.rtminexpire=3D2 net.inet.ip.rtmaxcache=3D1024 = # = Security net.inet.ip.sourceroute=3D0 net.inet.ip.accept_sourceroute=3D0 net.inet.icmp.maskrepl=3D0 net.inet.icmp.log_redirect=3D0 net.inet.tcp.drop_synfin=3D1 <= p class=3DMsoNormal> # = Security net.inet.ip.redirect=3D0 net.inet.ip.sourceroute=3D0 net.inet.ip.accept_sourceroute=3D0 net.inet.icmp.log_redirect=3D0 # Max number of timewait = sockets (Maximum number of compressed TCP TIME_WAIT = entries) net.inet.tcp.maxtcptw=3D20000000<= /p> # FIN_WAIT_2 state fast = recycle net.inet.tcp.fast_finwait2_recycle=3D1 # Time before tcp = keepalive probe is sent # default is 2 hours = (7200000) net.inet.tcp.keepidle=3D60000 = # Should be increased = until net.inet.ip.intr_queue_drops is zero net.inet.ip.intr_queue_maxlen=3D4096 # enable send/recv = autotuning net.inet.tcp.sendbuf_auto=3D1 = net.inet.tcp.recvbuf_auto=3D1 = # increase autotuning step = size net.inet.tcp.sendbuf_inc=3D16384 = net.inet.tcp.recvbuf_inc=3D524288 = # turn off inflight = limitting #net.inet.tcp.inflight.enable=3D0= # set this on = test/measurement hosts net.inet.tcp.hostcache.expire=3D1= # Randomized proccess = id's kern.randompid=3D348 # do not processes any TCP = options in the TCP headers net.inet.ip.process_options=3D0 # disable MTU path = discovery net.inet.tcp.path_mtu_discovery=3D0 # Disable = SACK net.inet.tcp.sack.enable=3D0 <= p class=3DMsoNormal> kern.ipc.shmmax=3D5368709120 <= p class=3DMsoNormal>kern.ipc.shmall=3D13107200 kern.ipc.semmsl=3D1024 net.inet6.ip6.auto_linklocal=3D0<= /p> net.inet.tcp.syncookies=3D0 # BPF increase buffer = size net.bpf.maxbufsize=3D1048576 <= p class=3DMsoNormal> kern.ipc.nmbjumbop=3D262144 kern.ipc.nmbjumbo16=3D32000 kern.ipc.nmbjumbo9=3D64000 dev.ix.0.fc=3D0 Best = Regards.. S= eyit = =D6zg=FCr = Netw= ork Y=F6neticisi = [2]3D"Description: = Eski =DCsk=FCdar Cad. No:10 VIP Center Kat:7 = =DD=E7erenk=F6y Ata=FEehir =DDstanbul t:= 0216 577 33 11= | f:= 0216 469 52 43= [3]www.magnetdigital.com= References 1. 3D"http://www.intel.com/content/www/us/en/ethernet-controllers/82575= 2. 3D"http://www.magnetdigital.com/" 3. 3D"http://www.magnetdigital.com"/ ------=_NextPart_002_001C_01CCFEE3.6C5EDF90-- ------=_NextPart_001_001B_01CCFEE3.6C5EDF90-- ------=_NextPart_000_001A_01CCFEE3.6C5EDF90-- From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 18:27:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43B39106566B for ; Sat, 10 Mar 2012 18:27:27 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 23BA18FC19 for ; Sat, 10 Mar 2012 18:27:27 +0000 (UTC) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id A7FF6C9424; Sat, 10 Mar 2012 18:27:18 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 39142216C33; Sat, 10 Mar 2012 18:27:18 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Sat, 10 Mar 2012 10:27:16 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Alex Yong In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-net@freebsd.org Subject: Re: Strong host model in IPv6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 18:27:27 -0000 At Fri, 9 Mar 2012 23:26:01 +0000, Alex Yong wrote: > I've spotted that in IPv4 there is the sysctl "net.inet.ip.check_interface" > which defaults to set, but I've been unable to find any guarantees that > strong host model is enforced in v6 in the comments or internet. According > to the IPv6 Core Protocols Implementation book (3.7 "Input processing: > ip6_input() Function") the incoming network packet processing in ip6_input > should use the routing table to look up whether packets are of relevance > for an interface - but the code base has diverged significantly since then > including vnets for jails which makes me wonder if this is a bug. However I've not closely followed the most recent version of FreeBSD IPv6 code, but the use of the routing table in ip6_input in the original KAME implementation had nothing to do with the strong host model. It was just for faster determination of whether an incoming packet is destined to *any* of host's IPv6 addresses (on any interface, which may or may not be identical to the receiving interface). --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Sat Mar 10 19:46:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25ACD106564A for ; Sat, 10 Mar 2012 19:46:18 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8A028FC08 for ; Sat, 10 Mar 2012 19:46:17 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3323873vcm.13 for ; Sat, 10 Mar 2012 11:46:17 -0800 (PST) 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=bsF+uCer6mtUmGE6yd8+wTH2pf53QKodN8wde/t/f88=; b=nVONVammRvz7Pu/T/Vf6kmP5GTh8qMMtthr2Ya3LdXHScCeDqDnDv99XrMfsEPH4A6 HYMwzYx6iHwKVBfSxLbo09nTz8GJNM4swIC1PmrDDndmGdONJxW6Y8ATpJZwcN2KRgbu l3NU7P1OZPlfXyaaEOoUan6Sk6vIi/dLKFA44frqTUyy1b4s+Yw2ojicZBRI8XeJjjrR BYzrz+hKcoxtHN25wjNUQDns6De52ClLYOeyV7+z/Vamfsm/XR4VV5BvY/33wFMx4lkV j54isvmC6fNBGG08OMiAT8pG4k8T2VrjRCBRAVE/rFcXlZZmoILQglnikmB8sLBDx6Kj dKzA== MIME-Version: 1.0 Received: by 10.52.88.235 with SMTP id bj11mr10683740vdb.119.1331407380390; Sat, 10 Mar 2012 11:23:00 -0800 (PST) Sender: annonymouse@gmail.com Received: by 10.220.118.19 with HTTP; Sat, 10 Mar 2012 11:23:00 -0800 (PST) In-Reply-To: References: Date: Sat, 10 Mar 2012 19:23:00 +0000 X-Google-Sender-Auth: xE445ev6ST51KTKOTUhyAI_DYMY Message-ID: From: Alex Yong To: =?ISO-2022-JP?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhC?= Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Strong host model in IPv6? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 19:46:18 -0000 On 10 March 2012 18:27, JINMEI Tatuya / $B?@L@C#:H(B wrote: > I've not closely followed the most recent version of FreeBSD IPv6 > code, but the use of the routing table in ip6_input in the original > KAME implementation had nothing to do with the strong host model. It > was just for faster determination of whether an incoming packet is > destined to *any* of host's IPv6 addresses (on any interface, which > may or may not be identical to the receiving interface). > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > Ah! That route lookup indeed doesn't ever actually compare the interface that route is configured for. For some reason I convinced myself rtalloc filters by interface - which is clearly wrong... Sorry for misquoting your text -- that's what I get for trying to be well prepared. My question still stands though, am I crazy in trying to have a strong model for v6 (does this for some reason not make sense?), does KAME already do this and I've just missed it, or (least likely) am I right in thinking it doesn't support it and this wouldn't be crazy? Many thanks for the help so far. AlexY