From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 00:48:57 2011 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 82900106566C; Sun, 3 Jul 2011 00:48:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C55218FC13; Sun, 3 Jul 2011 00:48:56 +0000 (UTC) Received: by vws18 with SMTP id 18so4185418vws.13 for ; Sat, 02 Jul 2011 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vV7eo2/xGIPgyWbzyLydVpZlEYPmxLpM5Mvyxm65X4M=; b=ZiWCNr1Asz65bdAFfMUKEPlTlQTZqw3WtHpArAEZTBHr19TZzQHHXqnFTyL7hTD9y4 Yfelc/FeSYP0ZzqBtGLwhyWxoUDWzHd1YUxNcBHuYlnKUCMZVyxJEkSntaezDV/Naz73 Sg+Gyy9pnbGH9Gfig4I22kJYGe9XG1xrEOpUU= MIME-Version: 1.0 Received: by 10.52.166.70 with SMTP id ze6mr2981165vdb.133.1309654136120; Sat, 02 Jul 2011 17:48:56 -0700 (PDT) Received: by 10.52.114.99 with HTTP; Sat, 2 Jul 2011 17:48:56 -0700 (PDT) In-Reply-To: <4E0F8C95.50507@freebsd.org> References: <4E0F8C95.50507@freebsd.org> Date: Sat, 2 Jul 2011 17:48:56 -0700 Message-ID: From: Jack Vogel To: Colin Percival Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack F Vogel , freebsd-net@freebsd.org Subject: Re: integer overflow in TCP LRO 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, 03 Jul 2011 00:48:57 -0000 Looks good to me, good work! Jack On Sat, Jul 2, 2011 at 2:24 PM, Colin Percival wrote: > Hi all, > > In tcp_lro_rx it's possible for lro->len to exceed 65536, resulting in an > integer overflow and 65536 bytes of TCP "packet loss" when tcp_lro_flush > stuffs lro->len back into an IP header. > > It's clear that an attempt was made to avoid overflow > 339: /* flush packet if required */ > 340: device_mtu = cntl->ifp->if_mtu; > 341: if (lro->len > (65535 - device_mtu)) { > but this doesn't work because incoming "packets" can be larger than > device_mtu bytes if LRO is turned on. > > I've attached a patch which fixes this and improves Linux->FreeBSD network > performance on EC2 cluster compute nodes from 13 Mbps to 4100 Mbps... any > objections to me committing this? > > -- > Colin Percival > Security Officer, FreeBSD | freebsd.org | The power to serve > Founder / author, Tarsnap | tarsnap.com | Online backups for the truly > paranoid > From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 05:37:40 2011 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 89B26106566B for ; Sun, 3 Jul 2011 05:37:40 +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 638838FC12 for ; Sun, 3 Jul 2011 05:37:40 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p635bWcb000914 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Jul 2011 22:37:35 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E100018.7090801@freebsd.org> Date: Sat, 02 Jul 2011 22:37:28 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Adrian Minta References: <6ecf4a8b9070592c8865ade7367d81c3.squirrel@mail.stsnet.ro> In-Reply-To: <6ecf4a8b9070592c8865ade7367d81c3.squirrel@mail.stsnet.ro> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 05:37:40 -0000 On 7/2/11 12:15 PM, Adrian Minta wrote: > Hi, > Without FLOWTABLE the system is stable an I was able to increase the > number of l2tp sessions. A major improvement came when I replaced the > network card with a multiqueue model (igb). The limit is now around 6300 > active sessions. If I try to go over this limit the mpd5 starts to loose > old sessions and the number quickly decrease. > I believe I encounter an internal mpd5 timing issue. Is anybody aware of > such thing ? !? 6300 ?! when I wrote netgraph and Archie wrote mpd I think we were thinking in terms of a few tens of sessions. of course others have done a lot of work on both since then... > The server is now a dual xeon E5520 and the load is around 6.8 at peak. > > The server has igb0 10.42.1.1/16 and 50 aliases. > My mpd.conf looks like this: > startup: > #configure mpd users > set user admin pass admin > set user foo bar > #configure the console > set console self 127.0.0.1 5005 > set console open > #configure the web server > set web self 10.42.1.1 5006 > set web open > > set global l2tptimeout 60 > > default: > load l2tp_server1 > load l2tp_server2 > load l2tp_server3 > load l2tp_server4 > load l2tp_server5 > load l2tp_server6 > load l2tp_server7 > load l2tp_server8 > load l2tp_server9 > load l2tp_server10 > load l2tp_server11 > load l2tp_server12 > load l2tp_server13 > load l2tp_server14 > load l2tp_server15 > load l2tp_server16 > load l2tp_server17 > load l2tp_server18 > load l2tp_server19 > load l2tp_server20 > load l2tp_server21 > load l2tp_server22 > load l2tp_server23 > load l2tp_server24 > load l2tp_server25 > load l2tp_server26 > load l2tp_server27 > load l2tp_server28 > load l2tp_server29 > load l2tp_server30 > load l2tp_server31 > load l2tp_server32 > load l2tp_server33 > load l2tp_server34 > load l2tp_server35 > load l2tp_server36 > load l2tp_server37 > load l2tp_server38 > load l2tp_server39 > load l2tp_server40 > load l2tp_server41 > load l2tp_server42 > load l2tp_server43 > load l2tp_server44 > load l2tp_server45 > load l2tp_server46 > load l2tp_server47 > load l2tp_server48 > load l2tp_server49 > load l2tp_server50 > > l2tp_server1: > set ippool add pool1 10.1.2.2 10.1.3.254 > create bundle template B1 > set iface disable proxy-arp > set iface idle 1800 > set iface enable tcpmssfix > set ipcp yes vjcomp > set ipcp ranges 10.1.2.1/23 ippool pool1 > set ipcp dns 10.42.0.1 8.8.4.4 > set bundle enable compression > set ccp yes mppc > set mppc yes e40 > set mppc yes e128 > set mppc yes stateless > create link template L1 l2tp > set link action bundle B1 > set link enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 60 180 > set auth max-logins 10000 > set link mtu 1460 > set l2tp self 10.42.1.1 > set link enable incoming > l2tp_server2: > set ippool add pool2 10.1.4.2 10.1.5.254 > create bundle template B2 > set iface disable proxy-arp > set iface idle 1800 > set iface enable tcpmssfix > set ipcp yes vjcomp > set ipcp ranges 10.1.4.1/23 ippool pool2 > set ipcp dns 10.42.0.1 8.8.4.4 > set bundle enable compression > set ccp yes mppc > set mppc yes e40 > set mppc yes e128 > set mppc yes stateless > create link template L2 l2tp > set link action bundle B2 > set link enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 60 180 > set auth max-logins 10000 > set link mtu 1460 > set l2tp self 10.42.1.2 > set link enable incoming > ..... > l2tp_server50: > set ippool add pool50 10.1.100.2 10.1.101.254 > create bundle template B50 > set iface disable proxy-arp > set iface idle 1800 > set iface enable tcpmssfix > set ipcp yes vjcomp > set ipcp ranges 10.1.100.1/23 ippool pool50 > set ipcp dns 10.42.0.1 8.8.4.4 > set bundle enable compression > set ccp yes mppc > set mppc yes e40 > set mppc yes e128 > set mppc yes stateless > create link template L50 l2tp > set link action bundle B50 > set link enable multilink > set link yes acfcomp protocomp > set link no pap chap > set link enable chap > set link keep-alive 60 180 > set auth max-logins 10000 > set link mtu 1460 > set l2tp self 10.42.1.50 > set link enable incoming > > > > > _______________________________________________ > 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 Jul 3 15:00:23 2011 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 21F51106568C; Sun, 3 Jul 2011 15:00:23 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by mx1.freebsd.org (Postfix) with ESMTP id DAC548FC12; Sun, 3 Jul 2011 15:00:13 +0000 (UTC) Received: by fxe6 with SMTP id 6so3709271fxe.17 for ; Sun, 03 Jul 2011 08:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:sender:date:message-id:user-agent:mime-version :content-type; bh=Ji0U38n0k/QJgxAWciSzBwjLh3W/5Kqi+TSb4HtxjaU=; b=K/REo8aCDIRt7jk/oFERdK6RXsdIHu173FrFgYkuFD+WKgprN73RqFG7lHgORgWxPG 5YKLSDEgoXUApcWFnKwwqDEjDU1QyMXQRxnv/p1LAs7dxNlkq7T5UfykC9fkwLwwz0Vk ZKwL0OxIsfXaJajrgSC5MOu6a5Gwot5NXsyBU= Received: by 10.223.4.136 with SMTP id 8mr1802397far.16.1309705212535; Sun, 03 Jul 2011 08:00:12 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id k17sm1233376fah.13.2011.07.03.08.00.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jul 2011 08:00:11 -0700 (PDT) From: Mikolaj Golub To: freebsd-net@freebsd.org Sender: Mikolaj Golub Date: Sun, 03 Jul 2011 18:00:09 +0300 Message-ID: <867h7zxvd2.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , Pawel Jakub Dawidek , Andre Oppermann Subject: soreceive_stream: issues with O_NONBLOCK 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, 03 Jul 2011 15:00:23 -0000 Hi, Trying soreceive_stream I found that many applications (like firefox, pidgin, gnus) might hang in soreceive_stream/sbwait. It was shown up that the issue was with O_NONBLOCK connections -- they blocked in recv() when should not have been. This can be checked with this simple test: http://people.freebsd.org/~trociny/test_nonblock.c In soreceive_stream we have the following code that looks wrong: 1968 /* Socket buffer is empty and we shall not block. */ 1969 if (sb->sb_cc == 0 && 1970 ((sb->sb_flags & SS_NBIO) || (flags & (MSG_DONTWAIT|MSG_NBIO)))) { 1971 error = EAGAIN; 1972 goto out; 1973 } It should check so->so_state agains SS_NBIO, not sb->sb_flags. But just changing this is not enough. This check is called too early -- before checking that socket state is not SBS_CANTRCVMORE. As a result, if the peer closes the connection recv() returns EAGAIN instead of 0. See this example: http://people.freebsd.org/~trociny/test_close.c So I moved the "nonblock" check below SBS_CANTRCVMORE check and ended up with this patch: http://people.freebsd.org/~trociny/uipc_socket.c.soreceive_stream.patch It works for me fine. Also, this part looks wrong: 1958 /* We will never ever get anything unless we are connected. */ 1959 if (!(so->so_state & (SS_ISCONNECTED|SS_ISDISCONNECTED))) { 1960 /* When disconnecting there may be still some data left. */ 1961 if (sb->sb_cc > 0) 1962 goto deliver; 1963 if (!(so->so_state & SS_ISDISCONNECTED)) 1964 error = ENOTCONN; 1965 goto out; 1966 } Why we check in 1959 that state is not SS_ISDISCONNECTED? If it is valid then the check at 1963 is useless becase it will be always true. Shouldn't it be something like below? if (!(so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING))) { /* When disconnecting there may be still some data left. */ if (sb->sb_cc > 0) goto deliver; error = ENOTCONN; goto out; } (I don't see why we souldn't set ENOTCONN if the state is SS_ISDISCONNECTED). And the last :-). Currently, to try soreceive_stream one need to rebuild kernel with TCP_SORECEIVE_STREAM and then set tunable net.inet.tcp.soreceive_stream. Why do we need TCP_SORECEIVE_STREAM option? Wouldn't tunable be enough? It would simplify trying soreceive_stream by users and we might have more testing/feedback. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 17:54:46 2011 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 AA31B106564A for ; Sun, 3 Jul 2011 17:54:46 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1ED8FC14 for ; Sun, 3 Jul 2011 17:54:46 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 3ECAD16DDA3; Sun, 3 Jul 2011 20:54:39 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Sun, 3 Jul 2011 20:54:39 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id 140AF16DDA0; Sun, 3 Jul 2011 20:54:39 +0300 (EEST) Received: from 188.26.159.54 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Sun, 3 Jul 2011 20:54:39 +0300 Message-ID: <3961e6ae9338557db669a86bcec03611.squirrel@mail.stsnet.ro> In-Reply-To: <4E100018.7090801@freebsd.org> References: <6ecf4a8b9070592c8865ade7367d81c3.squirrel@mail.stsnet.ro> <4E100018.7090801@freebsd.org> Date: Sun, 3 Jul 2011 20:54:39 +0300 From: "Adrian Minta" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168590, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 0(0), SQMD: bd31c8ba969f18459327f2e8d5232cf1.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38145 Cc: Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 17:54:46 -0000 > !? 6300 ?! > when I wrote netgraph and Archie wrote mpd I think we were thinking in > terms of a few tens of sessions. > of course others have done a lot of work on both since then... > > I'm a linux guy and I'm impressed. You did an excellent job ! -- Best regards, Adrian Minta MA3173-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 19:15:21 2011 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 8DE66106566B for ; Sun, 3 Jul 2011 19:15:21 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id 467DF8FC1B for ; Sun, 3 Jul 2011 19:15:21 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id D233D16DDA3 for ; Sun, 3 Jul 2011 22:15:14 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Sun, 3 Jul 2011 22:15:14 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id A6C4A16DDA0 for ; Sun, 3 Jul 2011 22:15:14 +0300 (EEST) Received: from 188.26.159.54 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Sun, 3 Jul 2011 22:15:14 +0300 Message-ID: Date: Sun, 3 Jul 2011 22:15:14 +0300 From: "Adrian Minta" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168604, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 0(0), SQMD: 38c20b0f483276173ffcfae5949ba053.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38145 Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 19:15:21 -0000 After looking in the mpd log file I found out that this message appear when calls are dropped: Jul 3 21:21:21 lns mpd: Daemon overloaded, ignoring request. Jul 3 21:21:22 lns mpd: Daemon overloaded, ignoring request. Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. Does anybody knows where this limit is set in mpd5 ? -- Best regards, Adrian Minta MA3173-RIPE From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 19:54:36 2011 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 B0B9E106564A for ; Sun, 3 Jul 2011 19:54:36 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2461A8FC12 for ; Sun, 3 Jul 2011 19:54:35 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p63JsWXp004586; Mon, 4 Jul 2011 02:54:32 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E10C8F3.2050006@rdtc.ru> Date: Mon, 04 Jul 2011 02:54:27 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 19:54:36 -0000 04.07.2011 02:15, Adrian Minta пишет: > After looking in the mpd log file I found out that this message appear > when calls are dropped: > Jul 3 21:21:21 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:22 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. > > Does anybody knows where this limit is set in mpd5 ? > There is internal queue of messages in the mpd-5.5 with length 8129. Messages are generated based on various events and enqueued there, then processed. Mpd uses GRED algorithm to prevent overload: it accepts all new L2TP connections when queue has 10 or less slots occupied (unprocessed events). It drops all connections then it has over 60 slots occupied. In between, it drops new message with probability equal to (q-10)*2 percents where q is number of occupied queue slots. These constants are hardcoded in its src/ppp.h Each time it decided to ignore incoming L2TP requests it notes that in the log, as you have already seen. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 19:56:50 2011 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 D15361065673 for ; Sun, 3 Jul 2011 19:56:50 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 45D248FC08 for ; Sun, 3 Jul 2011 19:56:50 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p63JungM004613; Mon, 4 Jul 2011 02:56:49 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E10C97C.2030200@rdtc.ru> Date: Mon, 04 Jul 2011 02:56:44 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: <4E10C8F3.2050006@rdtc.ru> In-Reply-To: <4E10C8F3.2050006@rdtc.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 19:56:50 -0000 >> After looking in the mpd log file I found out that this message appear >> when calls are dropped: >> Jul 3 21:21:21 lns mpd: Daemon overloaded, ignoring request. >> Jul 3 21:21:22 lns mpd: Daemon overloaded, ignoring request. >> Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. >> Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. >> Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. >> Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. >> >> Does anybody knows where this limit is set in mpd5 ? >> > > There is internal queue of messages in the mpd-5.5 with length 8129. > Messages are generated based on various events and enqueued there, then processed. > > Mpd uses GRED algorithm to prevent overload: it accepts all new L2TP connections > when queue has 10 or less slots occupied (unprocessed events). > > It drops all connections then it has over 60 slots occupied. s/all/new incoming/ > In between, it drops new message with probability equal to (q-10)*2 percents s/message/L2TP connection/ > where q is number of occupied queue slots. These constants are hardcoded in its src/ppp.h > > Each time it decided to ignore incoming L2TP requests it notes that in the log, > as you have already seen. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 20:02:38 2011 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 37149106564A for ; Sun, 3 Jul 2011 20:02:38 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 03BD98FC17 for ; Sun, 3 Jul 2011 20:02:37 +0000 (UTC) Received: by iyb11 with SMTP id 11so5384347iyb.13 for ; Sun, 03 Jul 2011 13:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eypS6IWP5n4hGcSf7AtPJxHT1RiAtnXJCnwnsePM04c=; b=iaRegzRxLf5u1/QCRk4HuSv1yfQNIyay4u3BWJT/g5M08qEP44xl1WaXpAb0rlaZ1p YG5P5d5K+tR+LOEn+L7pT3WV1Awb0nSS8/vYx6sEs/w+6qWS7Da9l5O1RoiH/KyI1V41 Gop1pN6XI3AmvlQVObIab0kdWAmX4tB27bd1Y= MIME-Version: 1.0 Received: by 10.231.114.92 with SMTP id d28mr4804055ibq.167.1309721963659; Sun, 03 Jul 2011 12:39:23 -0700 (PDT) Received: by 10.231.206.79 with HTTP; Sun, 3 Jul 2011 12:39:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Jul 2011 22:39:23 +0300 Message-ID: From: Sami Halabi To: Adrian Minta Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 20:02:38 -0000 maybe number of threads.... On Sun, Jul 3, 2011 at 10:15 PM, Adrian Minta wrote: > After looking in the mpd log file I found out that this message appear > when calls are dropped: > Jul 3 21:21:21 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:22 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:23 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. > Jul 3 21:21:24 lns mpd: Daemon overloaded, ignoring request. > > Does anybody knows where this limit is set in mpd5 ? > > -- > Best regards, > Adrian Minta MA3173-RIPE > > > > _______________________________________________ > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 20:04:19 2011 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 741CF1065672 for ; Sun, 3 Jul 2011 20:04:19 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0E3C88FC0A for ; Sun, 3 Jul 2011 20:04:18 +0000 (UTC) Received: by wyg24 with SMTP id 24so4248069wyg.13 for ; Sun, 03 Jul 2011 13:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ln/EDW9gGvYWuba1kUjIyPulNvIouVF8hWEx+DmbdXM=; b=hEIX9AXZXcT8GQeEkcC6W7JnDKM36UITmOxVWh71B2MWmh8OKO30uOxjg4AlGrYd7L MDU1vT6mQi/7NKwff2hjvBqFSd2uNGix3ePuk01HJTFVa/hlIt1JztIbmkj2MLLi7zZS htCR+QC7jGlctM45fpB52HVoeBMHfATk6ei+0= MIME-Version: 1.0 Received: by 10.216.55.196 with SMTP id k46mr2873597wec.91.1309722013795; Sun, 03 Jul 2011 12:40:13 -0700 (PDT) Received: by 10.216.237.210 with HTTP; Sun, 3 Jul 2011 12:40:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Jul 2011 14:40:13 -0500 Message-ID: From: Brandon Gooch To: Adrian Minta Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 03 Jul 2011 20:04:19 -0000 On Sun, Jul 3, 2011 at 2:15 PM, Adrian Minta wrote: > After looking in the mpd log file I found out that this message appear > when calls are dropped: > Jul =A03 21:21:21 lns mpd: Daemon overloaded, ignoring request. > Jul =A03 21:21:22 lns mpd: Daemon overloaded, ignoring request. > Jul =A03 21:21:23 lns mpd: Daemon overloaded, ignoring request. > Jul =A03 21:21:23 lns mpd: Daemon overloaded, ignoring request. > Jul =A03 21:21:24 lns mpd: Daemon overloaded, ignoring request. > Jul =A03 21:21:24 lns mpd: Daemon overloaded, ignoring request. > > Does anybody knows where this limit is set in mpd5 ? > > -- > Best regards, > Adrian Minta =A0 =A0MA3173-RIPE So it seems that the concept of overloading is set and controlled by a couple of macros, SETOVERLOAD and OVERLOAD defined in the mpd5 ppp.h source file. Read through the source and see if you can determine where you're hitting the error message and work back from there: brandon@m6500:/usr/ports/net/mpd5/work/mpd-5.5/src$ grep "Daemon overloaded= " * l2tp.c: Log(LG_PHYS, ("Daemon overloaded, ignoring request.")); pppoe.c: Log(LG_PHYS, ("Daemon overloaded, ignoring request.= ")); pptp.c: Log(LG_PHYS, ("Daemon overloaded, ignoring request.")); tcp.c: Log(LG_PHYS, ("Daemon overloaded, ignoring request.")); udp.c: Log(LG_PHYS, ("Daemon overloaded, ignoring request.")); You may have to mess around with setting values defined in the source, for example in the mpd5 source file msg.c, there is defined: #define MSG_QUEUE_LEN 8192 ...of course you should understand where and how this is applied before setting it to some arbitrary number -- it may not even be the correct value to change. That's not much help, but maybe it will point you in the direction... -Brandon From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 02:15:55 2011 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 29EFF106564A; Mon, 4 Jul 2011 02:15:55 +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 029328FC0C; Mon, 4 Jul 2011 02:15:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p642Fs7V069383; Mon, 4 Jul 2011 02:15:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p642Fs3j069379; Mon, 4 Jul 2011 02:15:54 GMT (envelope-from linimon) Date: Mon, 4 Jul 2011 02:15:54 GMT Message-Id: <201107040215.p642Fs3j069379@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158201: [re] re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) [regression] 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, 04 Jul 2011 02:15:55 -0000 Old Synopsis: re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) New Synopsis: [re] re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) [regression] Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 4 02:15:29 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=158201 From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 02:17:05 2011 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 359E0106566C; Mon, 4 Jul 2011 02:17:05 +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 0E9128FC12; Mon, 4 Jul 2011 02:17:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p642H4kD069603; Mon, 4 Jul 2011 02:17:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p642H4sB069599; Mon, 4 Jul 2011 02:17:04 GMT (envelope-from linimon) Date: Mon, 4 Jul 2011 02:17:04 GMT Message-Id: <201107040217.p642H4sB069599@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157785: amd64 + jail + ipfw + natd = very slow outbound traffic from jail (5KB/s) 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, 04 Jul 2011 02:17:05 -0000 Synopsis: amd64 + jail + ipfw + natd = very slow outbound traffic from jail (5KB/s) Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jul 4 02:16:25 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=157785 From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 08:30:58 2011 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 8BEA81065674 for ; Mon, 4 Jul 2011 08:30:58 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id 426418FC1B for ; Mon, 4 Jul 2011 08:30:58 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id DA04F16DDA3; Mon, 4 Jul 2011 11:30:51 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Mon, 4 Jul 2011 11:30:51 +0300 (EEST) Received: from [192.168.100.46] (PC46.ciurel100.stsnet.ro [192.168.100.46]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPSA id 9DD9D16DDA0; Mon, 4 Jul 2011 11:30:51 +0300 (EEST) Message-ID: <4E117A3B.4070400@stsnet.ro> Date: Mon, 04 Jul 2011 11:30:51 +0300 From: Adrian Minta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110522 Icedove/3.1.10 MIME-Version: 1.0 To: Eugene Grosbein References: <4E10C8F3.2050006@rdtc.ru> <4E10C97C.2030200@rdtc.ru> In-Reply-To: <4E10C97C.2030200@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168801, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 0(0), flags: [NN_SLOTS_IPX; NN_LENGTH], SQMD: aa11c5de4362b2d2b26249fd38d2352b.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38155 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 08:30:58 -0000 On 07/03/2011 10:56 PM, Eugene Grosbein wrote: >> >> There is internal queue of messages in the mpd-5.5 with length 8129. >> Messages are generated based on various events and enqueued there, then processed. >> >> Mpd uses GRED algorithm to prevent overload: it accepts all new L2TP connections >> when queue has 10 or less slots occupied (unprocessed events). >> >> It drops all connections then it has over 60 slots occupied. > s/all/new incoming/ > >> In between, it drops new message with probability equal to (q-10)*2 percents > s/message/L2TP connection/ > >> where q is number of occupied queue slots. These constants are hardcoded in its src/ppp.h >> >> Each time it decided to ignore incoming L2TP requests it notes that in the log, >> as you have already seen. > Eugene Grosbein > > Hi Eugene, if I undestand corectly, in order to increase the connection rate I need to replace 60 with 600 and 10 with 100 like this: #define SETOVERLOAD(q) do { \ int t = (q); \ if (t > 600) { \ gOverload = 100; \ } else if (t > 100) { \ gOverload = (t - 100) * 2; \ } else { \ gOverload = 0; \ } \ } while (0) Is this enough, or I need to modify something else ? -- Best regards, From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 11:07:07 2011 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 28FA7106564A for ; Mon, 4 Jul 2011 11:07:07 +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 160888FC1B for ; Mon, 4 Jul 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p64B77dU040503 for ; Mon, 4 Jul 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p64B76I2040501 for freebsd-net@FreeBSD.org; Mon, 4 Jul 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jul 2011 11:07:06 GMT Message-Id: <201107041107.p64B76I2040501@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, 04 Jul 2011 11:07:07 -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 -------------------------------------------------------------------------------- f kern/158426 net [e1000] [panic] _mtx_lock_sleep: recursed on non-recur o kern/158201 net [re] re0 driver quit working on Acer AO751h between 8. o kern/158156 net [bce] bce driver shows "no carrier" on IBM blade (HS22 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/156978 net [lagg][patch] Take lagg rlock before checking flags 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/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if 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/155004 net [bce] [panic] kernel panic in bce0 driver 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/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod 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/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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets 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 bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. 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 o kern/144572 net [carp] CARP preemption mode traffic partially goes to 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/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem 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/141023 net [carp] CARP arp replays with wrong src mac 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 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o 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 bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re 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 o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze 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/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us 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 o 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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation 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/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro 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/126714 net [carp] CARP interface renaming makes system no longer 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/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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 kern/120130 net [carp] [panic] carp causes kernel panics in any conste 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/117448 net [carp] 6.2 kernel crash [regression] 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 kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 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 o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 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 o kern/54383 net [nfs] [patch] NFS root configurations without dynamic 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 379 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 12:16:23 2011 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 B31831065676 for ; Mon, 4 Jul 2011 12:16:23 +0000 (UTC) (envelope-from ports@subnets.ru) Received: from mail.mega-net.ru (mail.mega-net.ru [91.217.137.1]) by mx1.freebsd.org (Postfix) with SMTP id C45CE8FC12 for ; Mon, 4 Jul 2011 12:16:22 +0000 (UTC) Received: (qmail 2003 invoked from network); 4 Jul 2011 15:49:38 +0400 Received: from unknown [172.16.10.37] (HELO work-book.lehis.ru) by mail.mega-net.ru with ESMTP; 4 Jul 2011 15:49:38 +0400 Message-ID: <4E11A8D3.40102@subnets.ru> Date: Mon, 04 Jul 2011 15:49:39 +0400 From: "Alexey V. Panfilov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru; rv:1.9.2.18) Gecko/20110622 Thunderbird/3.1.11 MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Netgraph udp tunneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ports@subnets.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 12:16:23 -0000 Hi! We've three servers, connected as S1 <-ng_tunnel-> S2 <-ng_tunnel-> S3. Over tunnels runs BGP with full-view. Sometimes on S2 occures fatal trap with automatic reboot or without reboot at all. It not depends of net loading (mbps or pps). If process of save a core was successfull, backtrace always shows that fatal trap occures because of large packet (size around 60Kbyte) was received. Any help are welcome. Thanks. ---------------------------------------------------------------------- Info about S2: smbios.system.maker="IBM" smbios.system.product="System x3250 M3 -[425232G]-" hw.model: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz hw.physmem: 4207792128 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x1014 subdevice=0x03bd class=0x020000 NOTE: On S2 used only em0 /etc/sysctl.conf: net.inet.icmp.icmplim=50 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=0 net.inet.ip.redirect=0 Netgraph's tunnels are configured such as it wrote at example (/usr/share/examples/netgraph/udp.tunnel): ngctl mkpeer iface dummy inet ngctl mkpeer ng0: ksocket inet inet/dgram/udp ngctl name ng0:inet to_S1 ngctl msg ng0:inet bind inet/1.1.1.1:60001 ngctl msg ng0:inet connect inet/5.5.5.5:60001 ifconfig ng0 10.0.0.1 10.0.0.2 netmask 255.255.255.252 ngctl mkpeer iface dummy inet ngctl mkpeer ng1: ksocket inet inet/dgram/udp ngctl name ng1:inet to_S3 ngctl msg ng1:inet bind inet/1.1.1.3:60002 ngctl msg ng1:inet connect inet/7.7.7.7:60002 ifconfig ng1 10.0.0.5 10.0.0.6 netmask 255.255.255.252 FreeBSD S2.line 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #1: Wed Jun 22 13:56:26 MSD 2011 root@S2.line:/usr/src/sys/amd64/compile/BGP amd64 Hardware and software configurations on S1 and S3 are identical to S2, but they runs without problem. ------------------------------------------------------------------------ backtrace: Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 05 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803f4a87 stack pointer = 0x28:0xffffff811c80a5a0 frame pointer = 0x28:0xffffff811c80a600 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 = 1478 (ng_queue0) trap number = 12 panic: page fault cpuid = 3 Uptime: 11d23h7m40s Physical memory: 4012 MB Dumping 674 MB: 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 115 99 83 67 51 35 19 3 Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done. done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from /boot/kernel/ng_iface.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_iface.ko Reading symbols from /boot/kernel/ng_ksocket.ko...Reading symbols from /boot/kernel/ng_ksocket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ksocket.ko #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:224 #1 0xffffffff80398d3e in boot (howto=260) at ../../../kern/kern_shutdown.c:419 #2 0xffffffff80399153 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:592 #3 0xffffffff8056f19d in trap_fatal (frame=0xffffff00070828c0, eva=Variable "eva" is not available. ) at ../../../amd64/amd64/trap.c:783 #4 0xffffffff8056f55f in trap_pfault (frame=0xffffff811c80a4f0, usermode=0) at ../../../amd64/amd64/trap.c:699 #5 0xffffffff8056f95f in trap (frame=0xffffff811c80a4f0) at ../../../amd64/amd64/trap.c:449 #6 0xffffffff80557ba4 in calltrap () at ../../../amd64/amd64/exception.S:224 #7 0xffffffff803f4a87 in m_copym (m=0x0, off0=2980, len=1480, wait=1) at ../../../kern/uipc_mbuf.c:542 #8 0xffffffff8047fc07 in ip_fragment (ip=0xffffff010e8d0558, m_frag=0xffffff811c80a718, mtu=Variable "mtu" is not available. ) at ../../../netinet/ip_output.c:819 #9 0xffffffff80480d1f in ip_output (m=0xffffff010e8d0500, opt=Variable "opt" is not available. ) at ../../../netinet/ip_output.c:650 #10 0xffffffff8047ca00 in ip_forward (m=0xffffff010e317600, srcrt=Variable "srcrt" is not available. ) at ../../../netinet/ip_input.c:1521 #11 0xffffffff8047e1cd in ip_input (m=0xffffff010e317600) at ../../../netinet/ip_input.c:729 #12 0xffffffff8044eebe in netisr_dispatch_src (proto=1, source=Variable "source" is not available. ) at ../../../net/netisr.c:917 #13 0xffffffff80a2dd76 in ng_linkinfo_type_fields () from /boot/kernel/netgraph.ko #14 0xffffffff80a26ae0 in ng_path2noderef (here=Variable "here" is not available. ) at netgraph.h:463 #15 0xffffffff80a25bee in ng_worklist_add (node=0xffffff016abda168) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3378 #16 0xffffffff80a30339 in ng_namehash_mtx () from /boot/kernel/netgraph.ko #17 0xffffffff80a26be0 in ng_path2noderef (here=0xffffff002dd93c00, address=Variable "address" is not available. ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1773 #18 0xffffffff80a27ceb in ng_apply_item (node=0x246, item=0xffffff002dd93c70, rw=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2613 #19 0xffffffff8036ff68 in fork_exit (callout=0xffffffff80a27b80 , arg=0x0, frame=0xffffff811c80ac40) at ../../../kern/kern_fork.c:845 #20 0xffffffff8055806e in fork_trampoline () at ../../../amd64/amd64/exception.S:565 #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000001 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 0x0000000000000000 in ?? () #43 0x0000000000000000 in ?? () #44 0x0000000000000000 in ?? () #45 0xffffffff807cce40 in affinity () #46 0x0000000000000000 in ?? () #47 0x0000000000000000 in ?? () #48 0xffffff0001efa000 in ?? () #49 0xffffff811c809c80 in ?? () #50 0xffffff811c809c28 in ?? () #51 0xffffff0001d20460 in ?? () #52 0xffffffff803be5f9 in sched_switch (td=0xffffffff80a27b80, newtd=0x0, flags=Variable "flags" is not available. ) at ../../../kern/sched_ule.c:1852 Previous frame inner to this frame (corrupt stack?) -- Simple Lehisnoe ;-) From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 12:30:41 2011 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 848C21065747 for ; Mon, 4 Jul 2011 12:30:41 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id EC08E8FC17 for ; Mon, 4 Jul 2011 12:30:40 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p64CUbDX010040; Mon, 4 Jul 2011 19:30:37 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E11B268.5090406@rdtc.ru> Date: Mon, 04 Jul 2011 19:30: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: Adrian Minta References: <4E10C8F3.2050006@rdtc.ru> <4E10C97C.2030200@rdtc.ru> <4E117A3B.4070400@stsnet.ro> In-Reply-To: <4E117A3B.4070400@stsnet.ro> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 12:30:41 -0000 04.07.2011 15:30, Adrian Minta пишет: > if I undestand corectly, in order to increase the connection rate I need > to replace 60 with 600 and 10 with 100 like this: > > #define SETOVERLOAD(q) do { \ > int t = (q); \ > if (t > 600) { \ > gOverload = 100; \ > } else if (t > 100) { \ > gOverload = (t - 100) * 2; \ > } else { \ > gOverload = 0; \ > } \ > } while (0) > > Is this enough, or I need to modify something else ? It seems, enough. But, are you sure your L2TP client will wait for overloaded daemon to complete connection? The change will proportionally increase responsiveness of mpd - it has not enough CPU horsepower to process requests timely. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 12:39:19 2011 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 D7413106564A for ; Mon, 4 Jul 2011 12:39:19 +0000 (UTC) (envelope-from freebsd@psconsult.nl) Received: from mx1.psconsult.nl (mx1.psconsult.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 60BC98FC17 for ; Mon, 4 Jul 2011 12:39:18 +0000 (UTC) Received: from mx1.psconsult.nl ([80.89.238.138]) by mx1.psconsult.nl (8.14.4/8.14.4) with ESMTP id p64COviN044031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Jul 2011 14:25:03 +0200 (CEST) (envelope-from freebsd@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.4/8.14.4/Submit) id p64COvM2044030 for freebsd-net@freebsd.org; Mon, 4 Jul 2011 14:24:57 +0200 (CEST) (envelope-from freebsd@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to freebsd@psconsult.nl using -f Date: Mon, 4 Jul 2011 14:24:57 +0200 From: Paul Schenkeveld To: freebsd-net@freebsd.org Message-ID: <20110704122457.GA43696@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) Subject: Multiple IPv6 ISPs 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, 04 Jul 2011 12:39:19 -0000 Hi, At one of my customers we have had 2 ISPs for a long time but now we have to support IPv6 too. In the IPv4 world I used ipfw for policy-based routing to separate traffic from the two public address ranges: ipfw add 1010 allow ip from any to MY_IP_RANGES ipfw add 1020 fwd ISP1_GW ip from ISP1_SUBNET to any ipfw add 1030 fwd ISP2_GW ip from ISP2_SUBNET to any When I try the same with IPv6, it appears that ipfw(8) does not support an IPv6 destination with the fwd statement, the packet matching part seems to work fine. This appears documented in bin/117214 (Oct 2007) but never solved. Before asking the list I went looking for other options, setfib came to mind but it appears that setfib only works on IPv4, is that correct or am I overlooking something? Pf is used for firewalling and doing both filtering and policy based routing in pf doesn't work. Anyway, how do other people solve this? I need to run services on both address ranges so flipping a default gateway when pinging the next hop fails does not solve it for me. Soon, having IPv6 is no longer an option but rather a necessity. Regards, Paul Schenkeveld From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 17:16:25 2011 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 CD281106566B for ; Mon, 4 Jul 2011 17:16:25 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3568FC12 for ; Mon, 4 Jul 2011 17:16:25 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 2F45A16DDA3 for ; Mon, 4 Jul 2011 20:16:19 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Mon, 4 Jul 2011 20:16:19 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id 05D2616DDA0 for ; Mon, 4 Jul 2011 20:16:19 +0300 (EEST) Received: from 188.26.158.192 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Mon, 4 Jul 2011 20:16:19 +0300 Message-ID: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> Date: Mon, 4 Jul 2011 20:16:19 +0300 From: "Adrian Minta" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168924, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 500(0), flags: [NN_LEGIT_SUMM_400_WORDS], SQMD: 217fbf0150d48e87f7278e4ce5939d36.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38158 Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 17:16:25 -0000 >It seems, enough. But, are you sure your L2TP client will wait >for overloaded daemon to complete connection? The change will >proportionally increase responsiveness of mpd - it has not enough CPU >horsepower to process requests timely. > >Eugene Grosbein Actually something else is happening. I increased the queue in msg.c #define MSG_QUEUE_LEN 65536 ... and in the ppp.h: #define SETOVERLOAD(q) do { \ int t = (q); \ if (t > 600) { \ gOverload = 100; \ } else if (t > 100) { \ gOverload = (t - 100) * 2; \ } else { \ gOverload = 0; \ } \ } while (0) Now the overload message is very rare, but the behaviour is the same. Around 5500 sessions the number don't grow anymore, but instead begin to decrease. The mpd log say something like this: #tail -f /var/log/mpd.log | grep -v "\[" Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.16 1701 Jul 4 19:56:46 lns mpd: L2TP: Incoming call #32 via connection 0x80ae96c10 received Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6310" Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6251" Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6250" Jul 4 19:56:46 lns mpd: L2TP: Control connection 0x80b06b710 10.42.1.48 1701 <-> 10.42.9.210 1701 connected Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.4 1701 Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.10 1701 Jul 4 19:56:46 lns mpd: L2TP: Incoming call #48 via connection 0x80b06b710 received Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6311" Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6312" Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6252" Jul 4 19:56:46 lns mpd: L2TP: Control connection 0x80ad99110 10.42.1.23 1701 <-> 10.42.9.244 1701 connected Jul 4 19:56:46 lns mpd: L2TP: Control connection 0x80ad99410 10.42.1.4 1701 <-> 10.42.10.16 1701 connected Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.9.234 1701 Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.2 1701 Jul 4 19:56:47 lns mpd: L2TP: Incoming call #4 via connection 0x80ad99410 received Jul 4 19:56:47 lns mpd: L2TP: Incoming call #23 via connection 0x80ad99110 received Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6253" Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ad99a10 10.42.1.7 1701 <-> 10.42.10.4 1701 connected Jul 4 19:56:47 lns mpd: Incoming L2TP packet from 10.42.9.214 1701 Jul 4 19:56:47 lns mpd: Incoming L2TP packet from 10.42.9.220 1701 Jul 4 19:56:47 lns mpd: L2TP: Incoming call #7 via connection 0x80ad99a10 received Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ad99d10 10.42.1.7 1701 <-> 10.42.10.10 1701 connected Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6254" Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6303" Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6302" Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ab22b10 10.42.1.32 1701 <-> 10.42.9.234 1701 connected Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ab22810 10.42.1.13 1701 <-> 10.42.10.2 1701 connected Jul 4 19:56:47 lns mpd: Incoming L2TP packet from 10.42.10.14 1701 A top command reveal that the server is around 50% free: last pid: 63542; load averages: 4.93, 2.98, 1.40 up 0+22:32:42 19:44:23 24 processes: 2 running, 22 sleeping CPU 0: 4.5% user, 0.0% nice, 5.6% system, 36.8% interrupt, 53.0% idle CPU 1: 2.6% user, 0.0% nice, 7.5% system, 48.5% interrupt, 41.4% idle CPU 2: 3.7% user, 0.0% nice, 7.9% system, 32.6% interrupt, 55.8% idle CPU 3: 3.0% user, 0.0% nice, 7.9% system, 33.5% interrupt, 55.6% idle CPU 4: 5.6% user, 0.0% nice, 13.9% system, 33.8% interrupt, 46.6% idle CPU 5: 2.3% user, 0.0% nice, 7.5% system, 36.1% interrupt, 54.1% idle CPU 6: 3.0% user, 0.0% nice, 9.8% system, 36.1% interrupt, 51.1% idle CPU 7: 0.8% user, 0.0% nice, 2.6% system, 43.2% interrupt, 53.4% idle Mem: 148M Active, 695M Inact, 753M Wired, 108K Cache, 417M Buf, 2342M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 75502 root 2 76 0 194M 168M select 4 4:32 63.57% mpd5 2131 root 1 46 0 7036K 1544K select 1 4:27 5.18% syslogd 1914 root 1 44 0 5248K 3176K select 2 0:17 0.00% devd 73229 root 1 44 0 16384K 8464K wait 1 0:02 0.00% bash 2434 root 1 44 0 12144K 4156K select 2 0:01 0.00% sendmail 73222 media 1 44 0 28500K 4360K select 6 0:00 0.00% sshd 2445 root 1 76 0 7964K 1624K nanslp 0 0:00 0.00% cron 1861 root 1 44 0 8060K 1372K select 0 0:00 0.00% moused 73219 root 1 44 0 28500K 4284K sbwait 4 0:00 0.00% sshd 2438 smmsp 1 44 0 12144K 3952K pause 1 0:00 0.00% sendmail 73225 root 1 45 0 10300K 2756K pause 5 0:00 0.00% csh 73224 media 1 44 0 21680K 2024K wait 0 0:00 0.00% su 2419 root 1 44 0 16532K 3768K select 0 0:00 0.00% sshd 2538 root 1 76 0 6904K 1284K ttyin 3 0:00 0.00% getty 2536 root 1 76 0 6904K 1284K ttyin 1 0:00 0.00% getty 2539 root 1 76 0 6904K 1284K ttyin 2 0:00 0.00% getty 63542 root 1 44 0 9368K 2444K CPU0 0 0:00 0.00% top 2533 root 1 76 0 6904K 1284K ttyin 0 0:00 0.00% getty 2537 root 1 76 0 6904K 1284K ttyin 6 0:00 0.00% getty 73223 media 1 45 0 8336K 1900K wait 4 0:00 0.00% sh 2535 root 1 76 0 6904K 1284K ttyin 5 0:00 0.00% getty 2540 root 1 76 0 6904K 1284K ttyin 7 0:00 0.00% getty 2534 root 1 76 0 6904K 1284K ttyin 4 0:00 0.00% getty The incoming calls rate is around 30/sec. If I lower this to 10/sec I'm able to achieve 7000 sessions. -- Best regards From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 17:21:27 2011 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 E9CA5106564A; Mon, 4 Jul 2011 17:21:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 803718FC0C; Mon, 4 Jul 2011 17:21:27 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p64HLPOc047055; Mon, 4 Jul 2011 13:21:25 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E11F680.6090401@sentex.net> Date: Mon, 04 Jul 2011 13:21:04 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> In-Reply-To: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 17:21:28 -0000 What do you have net.graph.threads set to ? With the load avg so high, perhaps you are just running into processing limits with so many connections ? amotin would know. ---Mike On 7/4/2011 1:16 PM, Adrian Minta wrote: >> It seems, enough. But, are you sure your L2TP client will wait >> for overloaded daemon to complete connection? The change will >> proportionally increase responsiveness of mpd - it has not enough CPU >> horsepower to process requests timely. >> >> Eugene Grosbein > > Actually something else is happening. > > I increased the queue in msg.c > #define MSG_QUEUE_LEN 65536 > ... and in the ppp.h: > #define SETOVERLOAD(q) do { \ > int t = (q); \ > if (t > 600) { \ > gOverload = 100; \ > } else if (t > 100) { \ > gOverload = (t - 100) * 2; \ > } else { \ > gOverload = 0; \ > } \ > } while (0) > > Now the overload message is very rare, but the behaviour is the same. > Around 5500 sessions the number don't grow anymore, but instead begin to > decrease. > > The mpd log say something like this: > #tail -f /var/log/mpd.log | grep -v "\[" > Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.16 1701 > Jul 4 19:56:46 lns mpd: L2TP: Incoming call #32 via connection > 0x80ae96c10 received > Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6310" > Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6251" > Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6250" > Jul 4 19:56:46 lns mpd: L2TP: Control connection 0x80b06b710 10.42.1.48 > 1701 <-> 10.42.9.210 1701 connected > Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.4 1701 > Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.10 1701 > Jul 4 19:56:46 lns mpd: L2TP: Incoming call #48 via connection > 0x80b06b710 received > Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6311" > Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6312" > Jul 4 19:56:46 lns mpd: Link: packet from unexisting link "6252" > Jul 4 19:56:46 lns mpd: L2TP: Control connection 0x80ad99110 10.42.1.23 > 1701 <-> 10.42.9.244 1701 connected > Jul 4 19:56:46 lns mpd: L2TP: Control connection 0x80ad99410 10.42.1.4 > 1701 <-> 10.42.10.16 1701 connected > Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.9.234 1701 > Jul 4 19:56:46 lns mpd: Incoming L2TP packet from 10.42.10.2 1701 > Jul 4 19:56:47 lns mpd: L2TP: Incoming call #4 via connection 0x80ad99410 > received > Jul 4 19:56:47 lns mpd: L2TP: Incoming call #23 via connection > 0x80ad99110 received > Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6253" > Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ad99a10 10.42.1.7 > 1701 <-> 10.42.10.4 1701 connected > Jul 4 19:56:47 lns mpd: Incoming L2TP packet from 10.42.9.214 1701 > Jul 4 19:56:47 lns mpd: Incoming L2TP packet from 10.42.9.220 1701 > Jul 4 19:56:47 lns mpd: L2TP: Incoming call #7 via connection 0x80ad99a10 > received > Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ad99d10 10.42.1.7 > 1701 <-> 10.42.10.10 1701 connected > Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6254" > Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6303" > Jul 4 19:56:47 lns mpd: Link: packet from unexisting link "6302" > Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ab22b10 10.42.1.32 > 1701 <-> 10.42.9.234 1701 connected > Jul 4 19:56:47 lns mpd: L2TP: Control connection 0x80ab22810 10.42.1.13 > 1701 <-> 10.42.10.2 1701 connected > Jul 4 19:56:47 lns mpd: Incoming L2TP packet from 10.42.10.14 1701 > > A top command reveal that the server is around 50% free: > > last pid: 63542; load averages: 4.93, 2.98, 1.40 up 0+22:32:42 19:44:23 > 24 processes: 2 running, 22 sleeping > CPU 0: 4.5% user, 0.0% nice, 5.6% system, 36.8% interrupt, 53.0% idle > CPU 1: 2.6% user, 0.0% nice, 7.5% system, 48.5% interrupt, 41.4% idle > CPU 2: 3.7% user, 0.0% nice, 7.9% system, 32.6% interrupt, 55.8% idle > CPU 3: 3.0% user, 0.0% nice, 7.9% system, 33.5% interrupt, 55.6% idle > CPU 4: 5.6% user, 0.0% nice, 13.9% system, 33.8% interrupt, 46.6% idle > CPU 5: 2.3% user, 0.0% nice, 7.5% system, 36.1% interrupt, 54.1% idle > CPU 6: 3.0% user, 0.0% nice, 9.8% system, 36.1% interrupt, 51.1% idle > CPU 7: 0.8% user, 0.0% nice, 2.6% system, 43.2% interrupt, 53.4% idle > Mem: 148M Active, 695M Inact, 753M Wired, 108K Cache, 417M Buf, 2342M Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 75502 root 2 76 0 194M 168M select 4 4:32 63.57% mpd5 > 2131 root 1 46 0 7036K 1544K select 1 4:27 5.18% syslogd > 1914 root 1 44 0 5248K 3176K select 2 0:17 0.00% devd > 73229 root 1 44 0 16384K 8464K wait 1 0:02 0.00% bash > 2434 root 1 44 0 12144K 4156K select 2 0:01 0.00% sendmail > 73222 media 1 44 0 28500K 4360K select 6 0:00 0.00% sshd > 2445 root 1 76 0 7964K 1624K nanslp 0 0:00 0.00% cron > 1861 root 1 44 0 8060K 1372K select 0 0:00 0.00% moused > 73219 root 1 44 0 28500K 4284K sbwait 4 0:00 0.00% sshd > 2438 smmsp 1 44 0 12144K 3952K pause 1 0:00 0.00% sendmail > 73225 root 1 45 0 10300K 2756K pause 5 0:00 0.00% csh > 73224 media 1 44 0 21680K 2024K wait 0 0:00 0.00% su > 2419 root 1 44 0 16532K 3768K select 0 0:00 0.00% sshd > 2538 root 1 76 0 6904K 1284K ttyin 3 0:00 0.00% getty > 2536 root 1 76 0 6904K 1284K ttyin 1 0:00 0.00% getty > 2539 root 1 76 0 6904K 1284K ttyin 2 0:00 0.00% getty > 63542 root 1 44 0 9368K 2444K CPU0 0 0:00 0.00% top > 2533 root 1 76 0 6904K 1284K ttyin 0 0:00 0.00% getty > 2537 root 1 76 0 6904K 1284K ttyin 6 0:00 0.00% getty > 73223 media 1 45 0 8336K 1900K wait 4 0:00 0.00% sh > 2535 root 1 76 0 6904K 1284K ttyin 5 0:00 0.00% getty > 2540 root 1 76 0 6904K 1284K ttyin 7 0:00 0.00% getty > 2534 root 1 76 0 6904K 1284K ttyin 4 0:00 0.00% getty > > > The incoming calls rate is around 30/sec. If I lower this to 10/sec I'm > able to achieve 7000 sessions. > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 17:33:12 2011 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 2F33E106564A for ; Mon, 4 Jul 2011 17:33:12 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id DA6968FC08 for ; Mon, 4 Jul 2011 17:33:11 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 6DB5B16DDA3; Mon, 4 Jul 2011 20:33:05 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Mon, 4 Jul 2011 20:33:05 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id 2720016DDA0; Mon, 4 Jul 2011 20:33:05 +0300 (EEST) Received: from 188.26.158.192 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Mon, 4 Jul 2011 20:33:05 +0300 Message-ID: <597b9fe9d85536b5400a58c85c5e5f17.squirrel@mail.stsnet.ro> In-Reply-To: <4E11F680.6090401@sentex.net> References: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> <4E11F680.6090401@sentex.net> Date: Mon, 4 Jul 2011 20:33:05 +0300 From: "Adrian Minta" To: "Mike Tancsa" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168924, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 0(0), SQMD: c380f2ec4fc4d988b02f56e0828b0053.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38158 Cc: freebsd-net@freebsd.org, Adrian Minta Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 17:33:12 -0000 > > What do you have net.graph.threads set to ? With the load avg so high, > perhaps you are just running into processing limits with so many > connections ? amotin would know. > > ---Mike > No, I didn't touch it. lns# sysctl net.graph.threads net.graph.threads: 8 How big should this be for my server (8 cores) ? -- Best regards, Adrian Minta MA3173-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 19:11:47 2011 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 A1BDA1065672; Mon, 4 Jul 2011 19:11:47 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 79DBE8FC16; Mon, 4 Jul 2011 19:11:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p64JBlsd091309; Mon, 4 Jul 2011 19:11:47 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p64JBk0h091305; Mon, 4 Jul 2011 19:11:46 GMT (envelope-from bz) Date: Mon, 4 Jul 2011 19:11:46 GMT Message-Id: <201107041911.p64JBk0h091305@freefall.freebsd.org> To: saper@SYSTEM.PL, bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address 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, 04 Jul 2011 19:11:47 -0000 Synopsis: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address State-Changed-From-To: open->patched State-Changed-By: bz State-Changed-When: Mon Jul 4 19:11:06 UTC 2011 State-Changed-Why: Seems I fixed it lately in r220463. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Mon Jul 4 19:11:06 UTC 2011 Responsible-Changed-Why: Take given it seems I fixed it so I can track MFCs. http://www.freebsd.org/cgi/query-pr.cgi?pr=127057 From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 19:15:00 2011 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 DEC21106566C for ; Mon, 4 Jul 2011 19:15:00 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4E06D8FC15 for ; Mon, 4 Jul 2011 19:14:59 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p64JEvNs013005; Tue, 5 Jul 2011 02:14:57 +0700 (NOVST) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.14.4/8.14.4/Submit) id p64JEpgK013004; Tue, 5 Jul 2011 02:14:51 +0700 (NOVST) (envelope-from eugen) Date: Tue, 5 Jul 2011 02:14:51 +0700 From: Eugene Grosbein To: Adrian Minta Message-ID: <20110704191451.GA12372@rdtc.ru> References: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 19:15:01 -0000 On Mon, Jul 04, 2011 at 08:16:19PM +0300, Adrian Minta wrote: > >It seems, enough. But, are you sure your L2TP client will wait > >for overloaded daemon to complete connection? The change will > >proportionally increase responsiveness of mpd - it has not enough CPU > >horsepower to process requests timely. > > > >Eugene Grosbein > > Actually something else is happening. > > I increased the queue in msg.c > #define MSG_QUEUE_LEN 65536 You can't do this blindly, without other changes. For example, there is MSG_QUEUE_MASK in the next line that must be equal to MSG_QUEUE_LEN-1 and effectively limits usage of this queue. > ... and in the ppp.h: > #define SETOVERLOAD(q) do { \ > int t = (q); \ > if (t > 600) { \ > gOverload = 100; \ > } else if (t > 100) { \ > gOverload = (t - 100) * 2; \ > } else { \ > gOverload = 0; \ > } \ > } while (0) > > Now the overload message is very rare, but the behaviour is the same. > Around 5500 sessions the number don't grow anymore, but instead begin to > decrease. You should study why existing connections break, do clients disconnect themselves or server disconnect them? You'll need turn off detailed logs, read mpd's documentation. Also, there are system-wide queues for NETGRAPH messages that can overflow and that's bad thing. Check them out with command: vmstat -z | egrep 'ITEM|NetGraph' FAILURES column shows how many times NETGRAPH queues have been overflowed. One may increase their LIMIT (second column in vmstat's output) with /boot/loader.conf: net.graph.maxdata=65536 net.graph.maxalloc=65536 Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 19:42:58 2011 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 9E4511065675; Mon, 4 Jul 2011 19:42:58 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DAD38FC0C; Mon, 4 Jul 2011 19:42:57 +0000 (UTC) Received: by yic13 with SMTP id 13so701008yic.13 for ; Mon, 04 Jul 2011 12:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lqXx4pebL+Yy+OBdDoPHpuDgYuJNgmenZb5Jrr3mXAY=; b=NSwBZEedTaRx1mmrfoGvtni/mSgUl5Xa/3DqTMpPcToF0TJwlH7dk1JXFWt04bCROQ kNpWzSvTm9bT5X4Mp69sef43qkatjEDSnaN8JVWN4k5DQa5yUz5l5PpSsMjktZyrBVO8 h8F6HZapCDgmEGLrupiUH8qYr1wiYX+pb4rgQ= Received: by 10.91.159.9 with SMTP id l9mr5396821ago.46.1309808577111; Mon, 04 Jul 2011 12:42:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.84.1 with HTTP; Mon, 4 Jul 2011 12:42:37 -0700 (PDT) In-Reply-To: <4E0ED1BA.40509@freebsd.org> References: <4E0D593B.7090206@freebsd.org> <4E0ED1BA.40509@freebsd.org> From: Michael MacLeod Date: Mon, 4 Jul 2011 15:42:37 -0400 Message-ID: To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Bridging Two Tunnel Interfaces For ALTQ 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, 04 Jul 2011 19:42:58 -0000 I merged both of your responses below, so that the thread doesn't get fragmented. On Sat, Jul 2, 2011 at 4:07 AM, Julian Elischer wrote: > ** > On 7/1/11 12:59 AM, Michael MacLeod wrote: > > On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer wrote: > >> On 6/29/11 11:28 AM, Michael MacLeod wrote: >> >>> I use pf+ALTQ to achieve some pretty decent traffic shaping results at >>> home. >>> However, recently signed up to be part of an IPv6 trial with my ISP, and >>> they've given me a second (dual-stacked) PPPoE login with which to test >>> with. The problem is that the second login lacks my static IP or my >>> routed >>> /29. I can have both tunnels up simultaneously, but that becomes a pain >>> to >>> traffic shape since I can't have them both assigned to the same ALTQ. >>> >>> ... unless there is some way for me to turn the ng interfaces (I'm using >>> mpd5) into ethernet interfaces that could be assigned to an if_bridge. I >>> could easily disable IPv4 on the IPv6 tunnel, which would clean up any >>> routing issues, assign both tunnels to the bridge, and put the ALTQ on >>> the >>> bridge. It just might have the effect I'm looking for. Bonus points if >>> the >>> solution can be extended to allow it to work with a gif tunnel as well, >>> so >>> that users of 6in4 tunnels could use it (my ISPs IPv6 beta won't let me >>> do >>> rDNS delegation, so I might want to try a tunnel from he.net instead). >>> >>> I spent some time this morning trying to make netgraph do this with the >>> two >>> ng interfaces, but didn't have any luck. Google didn't turn up anyone >>> trying >>> to do anything similar that I could find; closest I got was this: >>> http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html >>> >>> This is all assuming that the best way to use ALTQ on multiple outbound >>> connections is with a bridge. If there is another or more elegant >>> solution, >>> I'd love to hear it. >>> >> >> rather than trying to shoehorn ng into if_bridge, why not use the >> netgraph bridge itility, >> or maybe one of the many other netgraph nodes that can split traffic. >> fofr example the ng_bpf filter can filter traffic on an almost arbitrary >> manner that you program using >> the bpf filter language. > > > Julian, thanks for responding. I'm not particularly concerned about how I > accomplish my goal, so long as I can accomplish it. I was thinking about > using if_bridge or ng_bridge because I have past experience with software > bridges in BSD and linux. Unfortunately, ng_bridge requires a node that has > an ether hook. I spent a bit of time looking at the mpd5 documentation, and > there's actually a config option to have mpd generate an extra tee node > between the ppp and the iface nodes. These nodes are connected together > using inet hooks. If I could find a netgraph node that can take inet in one > side and ether on the other, I believe I'd be set. > > I think you need to draw a diagram.. > Alright, here's how the mpd daemon puts together a PPPoE interface by default: iface node (ng0)<-->ppp node<-->tee node<-->pppoe node<-->ether node(em1) Here's how it looks if I enable the option to add another tee: iface node (ng0)<-->tee node<-->ppp node<-->tee node<-->pppoe node<-->ether node(em1) The iface and ppp nodes are connected with inet hooks, which I believe means that they are straight IP packets, with no PPP or other layer 2 framing remaining (though I could be totally wrong about that). > The nice thing (near as I can tell) about using ethernet based nodes would > be that pretty much everything can talk to an ethernet interface (tcpdump, > etc) and that ethernet should be fairly easy to fake; just assign a fake MAC > to the ether nodes (which is what the ng_ether node does, pretty much) and > the bridge will take care of making sure traffic for tunnel 0 doesn't go to > tunnel 1, etc. > > I haven't read up very much about ng_bpf yet, but it seems like a pretty > heavy tool for the job, and wouldn't the data have to enter userspace for > parsing by the bpf script? > > no you download the filter program into the kernel module to program it. > Ah, okay. Also, I've never written anything in bpf. It's not a huge hurdle, I hope, > but it's certainly more involved than a six line ngctl incantation that > turns my iface nodes into eiface nodes suitable for bridging. > > read the ng_bpf man page and the tcpdump man page. > Having said that you may find many other ways to split traffic. > > actually you can do that in 1 ngctl command.. > I think you want the ng_eiface module. but I'm not sure...ngeiface presents > an interface in ifconfig and > produces ethernet frames which can be fed into the ng_bridge node teh > output of which can be fed into a real ethernet bottom end. > I already tried linking an eiface node to the tee interface I described above, between the iface and ppp nodes. I ran some traffic through the interface but didn't see any of it appear on the ngeth0 interface (I was watching it with tcpdump). According to the man page, ng_eiface nodes should be connected to the Ethernet downstream from another node, like the ng_vlan node. So I suspect that ng_eiface expects the packets received to already have ethernet framing. It just created an interface that man be used with ifconfig and the rest of the system. > As I said, I'm not particularly concerned with the means, just the end > itself really. If there were an elegant way to create a virtual ALTQ that I > could then build sub-queues that were actually attached to the tunnels in pf > that would also satisfy my end goal, without any netgraph mucking at all. I > just haven't found any evidence that ALTQ has any ability to do that. > > I just have two tunnels, one using IPv4 and one using IPv6, that share > the same bandwidth resource. I want a way to shape traffic based on the pool > of bandwidth, not the tunnels running through the pool. > > not quite sure what you mean by that,, > > an example would help. > I have two phone lines with DSL, and they both sync at 5000/768kbps. These each have a DSL modem in bridge mode, and are wired into em1 and em2 on my router. My ISP supports Multilink PPP, so I have a theoretical pipe of 10000/1536kbps. After network overhead, etc, I usually set my the upstream ALTQ to 1200kbps. My ISP has also given me two separate PPPoE logins, one for my regular IPv6 traffic, and one beta account for testing dual-stack IPv4/IPv6 (I can easily disable the IPv4 on this login, and use it as only IPv6). But both of these tunnels share the same pool of bandwidth. If I upload a file to my colo at 800kbps over IPv6, there will be 400kbps of bandwidth left for other outbound traffic, regardless of which tunnel it uses. The underlying DSL will only give me so much bandwidth. Because FreeBSD sees these as two distinct interfaces, I can't assign a single ALTQ to them. I could create two ALTQs, and assign 800kbps to the IPv4 one, and 400kbps to the IPv6 one, and share it that way, but that is pretty much guaranteed to not be the most efficient method. So I figured that if I could create a software bridge and assign both tunnels to the bridge, then I could assign the ALTQ to the bridge instead. My ALTQ and pf rules could be altered to treat the bridge as my "WAN", and once the traffic entered the bridge the routing table would take care of it (since all IPv4 traffic will go out one tunnel and all IPv6 traffic would go out the other). I may be completely wrong about this, but that was the direction I was thinking. Cheers, Mike From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 20:33:42 2011 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 744001065670 for ; Mon, 4 Jul 2011 20:33:42 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id E5C498FC13 for ; Mon, 4 Jul 2011 20:33:41 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 37FD816DDA3; Mon, 4 Jul 2011 23:33:35 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Mon, 4 Jul 2011 23:33:35 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id 096AD16DDA0; Mon, 4 Jul 2011 23:33:35 +0300 (EEST) Received: from 188.26.158.192 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Mon, 4 Jul 2011 23:33:35 +0300 Message-ID: In-Reply-To: <20110704191451.GA12372@rdtc.ru> References: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> <20110704191451.GA12372@rdtc.ru> Date: Mon, 4 Jul 2011 23:33:35 +0300 From: "Adrian Minta" To: "Eugene Grosbein" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168971, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 500(0), flags: [NN_LEGIT_SUMM_400_WORDS], SQMD: ca2a695e53dd054d805c5b76bb284c29.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38159 Cc: freebsd-net@freebsd.org, Adrian Minta Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 04 Jul 2011 20:33:42 -0000 > You should study why existing connections break, > do clients disconnect themselves or server disconnect them? > You'll need turn off detailed logs, read mpd's documentation. > > Also, there are system-wide queues for NETGRAPH messages that can overflow > and that's bad thing. Check them out with command: > > vmstat -z | egrep 'ITEM|NetGraph' > > FAILURES column shows how many times NETGRAPH queues have been overflowed. > One may increase their LIMIT (second column in vmstat's output) > with /boot/loader.conf: > > net.graph.maxdata=65536 > net.graph.maxalloc=65536 > > Eugene Grosbein > > Back to "default" mpd for now. --- /boot/loader.conf --- kern.maxusers=1024 net.graph.maxdata=65536 net.graph.maxalloc=65536 kern.ipc.maxpipekva=320000000 ###8 cores maxthreads=8 net.isr.maxthreads=8 net.isr.bindthreads=1 net.isr.defaultqlimit=8192 net.isr.maxqlimit=10240 console="comconsole,vidconsole" hw.igb.rxd=4096 # IGB Tuning hw.igb.txd=4096 # IGB Tuning if_lagg_load="YES" --- /etc/sysctl.conf --- kern.maxfiles=250000 net.inet.ip.intr_queue_maxlen=10240 kern.ipc.nmbclusters=1280000 kern.ipc.somaxconn=32768 kern.ipc.maxsockbuf=128000000 kern.ipc.maxsockets=128000000 net.local.stream.recvspace=65536 net.local.stream.sendspace=65536 net.local.dgram.recvspace=8000 net.inet.udp.recvspace=262144 net.graph.maxdgram=10240000 net.graph.recvspace=10240000 kern.random.sys.harvest.ethernet=0 net.isr.direct=1 net.isr.direct_force=0 --- When failures start (1 sec interval): --- sessions: 5697 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 14, 8512, 11679211, 0 NetGraph data items: 104, 65540, 0, 899, 18656500, 0 sessions: 5695 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 14, 8512, 11698144, 0 NetGraph data items: 104, 65540, 0, 899, 18690476, 0 sessions: 5696 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 14, 8512, 11717921, 0 NetGraph data items: 104, 65540, 0, 899, 18726539, 0 sessions: 5697 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 8, 8518, 11736938, 0 NetGraph data items: 104, 65540, 0, 899, 18760816, 0 sessions: 5697 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 14, 8512, 11756221, 0 NetGraph data items: 104, 65540, 0, 899, 18796218, 0 sessions: 5697 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 11, 8515, 11775151, 0 NetGraph data items: 104, 65540, 0, 899, 18830631, 0 sessions: 5696 ITEM SIZE LIMIT USED FREE REQUESTS FAILURES NetGraph items: 104, 65540, 9, 8517, 11794388, 0 NetGraph data items: 104, 65540, 0, 899, 18865673, 0 --- mpd.log (via "log -ccp -chat -lcp") --- Jul 4 23:23:37 lns mpd: L2TP: Control connection 0x80a2aaf10 terminated: 0 (no more sessions exist in this tunnel) Jul 4 23:23:37 lns mpd: L2TP: Control connection 0x80a2a8810 terminated: 0 (no more sessions exist in this tunnel) Jul 4 23:23:37 lns mpd: [L19-6291] L2TP: Call #19 connected Jul 4 23:23:37 lns mpd: [L19-6291] Link: UP event Jul 4 23:23:37 lns mpd: [L19-6291] LCP: Up event Jul 4 23:23:37 lns mpd: [L19-6291] LCP: state change Starting --> Req-Sent Jul 4 23:23:37 lns mpd: [L19-6291] LCP: SendConfigReq #1 Jul 4 23:23:37 lns mpd: [L50-6292] L2TP: Call #50 connected Jul 4 23:23:37 lns mpd: [L50-6292] Link: UP event Jul 4 23:23:37 lns mpd: [L50-6292] LCP: Up event Jul 4 23:23:37 lns mpd: [L50-6292] LCP: state change Starting --> Req-Sent Jul 4 23:23:37 lns mpd: [L50-6292] LCP: SendConfigReq #1 Jul 4 23:23:37 lns mpd: [L7-6161] LCP: rec'd Configure Reject #1 (Req-Sent) Jul 4 23:23:37 lns mpd: [L7-6161] Wrong id#, expecting 4 Jul 4 23:23:37 lns mpd: [L50-5752] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L50-5752] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L6-6107] LCP: rec'd Configure Request #1 (Req-Sent) Jul 4 23:23:37 lns mpd: [L6-6107] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L6-6107] LCP: state change Req-Sent --> Ack-Sent Jul 4 23:23:37 lns mpd: [L25-6047] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L25-6047] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L1-5754] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L1-5754] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L26-6108] LCP: rec'd Configure Request #1 (Req-Sent) Jul 4 23:23:37 lns mpd: [L26-6108] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L26-6108] LCP: state change Req-Sent --> Ack-Sent Jul 4 23:23:37 lns mpd: [L1-6109] LCP: rec'd Configure Request #1 (Req-Sent) Jul 4 23:23:37 lns mpd: [L1-6109] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L1-6109] LCP: state change Req-Sent --> Ack-Sent Jul 4 23:23:37 lns mpd: [L3-5880] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L3-5880] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L50-6048] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L50-6048] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L19-5921] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L19-5921] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L25-5753] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L25-5753] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L35-6049] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L35-6049] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L3-5923] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L3-5923] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: L2TP: Control connection 0x80b15f610 10.42.1.19 1701 <-> 10.42.10.4 1701 connected Jul 4 23:23:37 lns mpd: Incoming L2TP packet from 10.42.10.1 1701 Jul 4 23:23:37 lns mpd: [L41-6185] LCP: SendConfigReq #4 Jul 4 23:23:37 lns mpd: [L48-6184] LCP: SendConfigReq #4 Jul 4 23:23:37 lns mpd: [L49-6130] LCP: SendConfigReq #5 Jul 4 23:23:37 lns mpd: [L26-6131] LCP: SendConfigReq #5 Jul 4 23:23:37 lns mpd: [L41-6127] LCP: SendConfigReq #5 Jul 4 23:23:37 lns mpd: [L30-6128] LCP: SendConfigReq #5 Jul 4 23:23:37 lns mpd: [L6-6129] LCP: SendConfigReq #5 Jul 4 23:23:37 lns mpd: [L31-6091] LCP: SendConfigReq #6 Jul 4 23:23:37 lns mpd: [L10-6050] LCP: SendConfigReq #7 Jul 4 23:23:37 lns mpd: [L21-6051] LCP: SendConfigReq #7 Jul 4 23:23:37 lns mpd: [L17-6014] LCP: SendConfigReq #8 Jul 4 23:23:37 lns mpd: [L47-6016] LCP: SendConfigReq #8 Jul 4 23:23:37 lns mpd: [L29-6015] LCP: SendConfigReq #8 Jul 4 23:23:37 lns mpd: [L3-5858] LCP: SendConfigReq #11 Jul 4 23:23:37 lns mpd: [L15-5937] LCP: SendConfigReq #14 Jul 4 23:23:37 lns mpd: [L26-5942] LCP: SendConfigReq #14 Jul 4 23:23:37 lns mpd: [L30-5944] LCP: SendConfigReq #14 Jul 4 23:23:37 lns mpd: [L22-5822] LCP: SendConfigReq #12 Jul 4 23:23:37 lns mpd: [L2-5821] LCP: SendConfigReq #12 Jul 4 23:23:37 lns mpd: [L50-5943] LCP: SendConfigReq #14 Jul 4 23:23:37 lns mpd: [L35-5941] LCP: SendConfigReq #14 Jul 4 23:23:37 lns mpd: [L25-5760] LCP: SendConfigReq #13 Jul 4 23:23:37 lns mpd: [L11-5945] LCP: SendConfigReq #14 Jul 4 23:23:37 lns mpd: [L4-5963] LCP: SendConfigReq #10 Jul 4 23:23:37 lns mpd: [L13-5962] LCP: SendConfigReq #10 Jul 4 23:23:37 lns mpd: [L35-6089] LCP: SendConfigReq #6 Jul 4 23:23:37 lns mpd: [L10-6088] LCP: SendConfigReq #6 Jul 4 23:23:37 lns mpd: [L43-6216] LCP: SendConfigReq #3 Jul 4 23:23:37 lns mpd: [L41-6217] LCP: SendConfigReq #3 Jul 4 23:23:37 lns mpd: L2TP: Incoming call #19 via connection 0x80b15f610 received Jul 4 23:23:37 lns mpd: [L19-6294] L2TP: Incoming call #19 via control connection 0x80b15f610 accepted Jul 4 23:23:37 lns mpd: [L14-6293] L2TP: Call #14 connected Jul 4 23:23:37 lns mpd: [L14-6293] Link: UP event Jul 4 23:23:37 lns mpd: [L14-6293] LCP: Up event Jul 4 23:23:37 lns mpd: [L14-6293] LCP: state change Starting --> Req-Sent Jul 4 23:23:37 lns mpd: [L14-6293] LCP: SendConfigReq #1 Jul 4 23:23:37 lns mpd: [L49-5991] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L49-5991] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L10-6050] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L10-6050] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L8-5924] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L8-5924] LCP: SendConfigAck #1 Jul 4 23:23:37 lns mpd: [L37-6123] LCP: rec'd Configure Reject #2 (Req-Sent) Jul 4 23:23:37 lns mpd: [L37-6123] Wrong id#, expecting 5 Jul 4 23:23:37 lns mpd: [L47-5867] LCP: rec'd Configure Reject #7 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L47-5867] Wrong id#, expecting 10 Jul 4 23:23:37 lns mpd: [L38-5964] LCP: rec'd Configure Reject #6 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L38-5964] Wrong id#, expecting 9 Jul 4 23:23:37 lns mpd: [L29-5965] LCP: rec'd Configure Reject #6 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L29-5965] Wrong id#, expecting 9 Jul 4 23:23:37 lns mpd: [L1-5783] LCP: rec'd Configure Reject #9 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L1-5783] Wrong id#, expecting 12 Jul 4 23:23:37 lns mpd: [L7-5828] LCP: rec'd Configure Reject #8 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L7-5828] Wrong id#, expecting 11 Jul 4 23:23:37 lns mpd: [L13-5868] LCP: rec'd Configure Reject #7 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L13-5868] Wrong id#, expecting 10 Jul 4 23:23:37 lns mpd: [L14-6003] LCP: rec'd Configure Reject #5 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L14-6003] Wrong id#, expecting 8 Jul 4 23:23:37 lns mpd: [L34-5947] LCP: rec'd Configure Reject #10 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L34-5947] Wrong id#, expecting 13 Jul 4 23:23:37 lns mpd: [L1-5948] LCP: rec'd Configure Reject #10 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L1-5948] Wrong id#, expecting 13 Jul 4 23:23:37 lns mpd: [L32-5826] LCP: rec'd Configure Reject #8 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L32-5826] Wrong id#, expecting 11 Jul 4 23:23:37 lns mpd: [L45-5946] LCP: rec'd Configure Reject #10 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L45-5946] Wrong id#, expecting 13 Jul 4 23:23:37 lns mpd: [L43-5830] LCP: rec'd Configure Reject #8 (Ack-Sent) Jul 4 23:23:37 lns mpd: [L43-5830] Wrong id#, expecting 11 Jul 4 23:23:37 lns mpd: L2TP: Control connection 0x80b15f010 10.42.1.50 1701 <-> 10.42.9.221 1701 connected Jul 4 23:23:37 lns mpd: [L23-6254] LCP: SendConfigReq #2 Jul 4 23:23:37 lns mpd: Incoming L2TP packet from 10.42.9.244 1701 From owner-freebsd-net@FreeBSD.ORG Mon Jul 4 21:08:21 2011 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 53768106566B for ; Mon, 4 Jul 2011 21:08:21 +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 2AD128FC17 for ; Mon, 4 Jul 2011 21:08:21 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p64L8Gx5027698 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 4 Jul 2011 14:08:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E122BBE.5030809@freebsd.org> Date: Mon, 04 Jul 2011 14:08:14 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Paul Schenkeveld References: <20110704122457.GA43696@psconsult.nl> In-Reply-To: <20110704122457.GA43696@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multiple IPv6 ISPs 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, 04 Jul 2011 21:08:21 -0000 On 7/4/11 5:24 AM, Paul Schenkeveld wrote: > Hi, > > At one of my customers we have had 2 ISPs for a long time but now we > have to support IPv6 too. > > In the IPv4 world I used ipfw for policy-based routing to separate > traffic from the two public address ranges: > > ipfw add 1010 allow ip from any to MY_IP_RANGES > ipfw add 1020 fwd ISP1_GW ip from ISP1_SUBNET to any > ipfw add 1030 fwd ISP2_GW ip from ISP2_SUBNET to any > > When I try the same with IPv6, it appears that ipfw(8) does not support > an IPv6 destination with the fwd statement, the packet matching part > seems to work fine. This appears documented in bin/117214 (Oct 2007) > but never solved. > > Before asking the list I went looking for other options, setfib came to > mind but it appears that setfib only works on IPv4, is that correct or > am I overlooking something? no, setfib for IPV6 is not complete I know that work is underway to fix that, it may be possible to use netgraph and vnetjails to simulate it somehow as vnet supports ipv6. > Pf is used for firewalling and doing both filtering and policy based > routing in pf doesn't work. > > Anyway, how do other people solve this? I need to run services on both > address ranges so flipping a default gateway when pinging the next hop > fails does not solve it for me. > > Soon, having IPv6 is no longer an option but rather a necessity. > > Regards, > > Paul Schenkeveld > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 00:35:44 2011 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 42447106566B; Tue, 5 Jul 2011 00:35:44 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 19B5E8FC17; Tue, 5 Jul 2011 00:35:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p650ZhGt088472; Tue, 5 Jul 2011 00:35:43 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p650ZhjO088468; Tue, 5 Jul 2011 00:35:43 GMT (envelope-from yongari) Date: Tue, 5 Jul 2011 00:35:43 GMT Message-Id: <201107050035.p650ZhjO088468@freefall.freebsd.org> To: msa@latt.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/158201: [re] re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) [regression] 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, 05 Jul 2011 00:35:44 -0000 Synopsis: [re] re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) [regression] State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Tue Jul 5 00:34:34 UTC 2011 State-Changed-Why: There had been a lot of re(4) changes since 8.0-RELEASE so it's hard to know which commit broke your controller. I made a small patch with wild guess so I can't guarantee it would work but could you give it try? You can get the diff at the following URL. http://people.freebsd.org/~yongari/re/re.macsleep.diff http://www.freebsd.org/cgi/query-pr.cgi?pr=158201 From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 00:35:59 2011 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 2D4FD1065677; Tue, 5 Jul 2011 00:35:59 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 04D438FC0C; Tue, 5 Jul 2011 00:35:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p650Zww5088551; Tue, 5 Jul 2011 00:35:58 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p650Zwiu088547; Tue, 5 Jul 2011 00:35:58 GMT (envelope-from yongari) Date: Tue, 5 Jul 2011 00:35:58 GMT Message-Id: <201107050035.p650Zwiu088547@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/158201: [re] re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) [regression] 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, 05 Jul 2011 00:35:59 -0000 Synopsis: [re] re0 driver quit working on Acer AO751h between 8.0 and 8.2 (also 9.0) [regression] Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Tue Jul 5 00:35:48 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=158201 From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 01:32:13 2011 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 B47B0106564A for ; Tue, 5 Jul 2011 01:32:13 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 668C68FC0C for ; Tue, 5 Jul 2011 01:32:13 +0000 (UTC) Received: (qmail 81944 invoked by uid 0); 5 Jul 2011 01:32:12 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jul 2011 01:32:12 -0000 Received: (qmail 81940 invoked by uid 90); 5 Jul 2011 01:32:12 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jul 2011 01:32:12 -0000 Date: Mon, 4 Jul 2011 21:32:11 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: bce packet loss 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, 05 Jul 2011 01:32:13 -0000 Hello, We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) and I'm seeing occasional packet loss on them (enough that it trips nagios now and then). Cabling seems fine as neither the switch nor the sysctl info for the device show any errors/collisions/etc, however there is one odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below for full sysctl output. The switch shows no errors but for "Dropped packets 683868". pciconf output is also below. [2] By default, the switch had flow control set to "on". I also let it run with "auto". In both cases, the drops continued to increment. I'm now running with flow control off to see if that changes anything. I do see some correlation between cpu usage and drops - I have cpu usage graphed in nagios and cacti is graphing the drops on the dell switch. There's no signs of running out of mbufs or similar. So given that limited info, is there anything I can look at to track this down? Anything stand out in the stats sysctl exposes? Two things are standing out for me - the number of changes in bce regarding flow control that are not in 8.1, and the correlation between cpu load and the drops. What other information can I provide? Thanks, Charles [1] [root@h23 /home/spork]# sysctl -a |grep bce.1 dev.bce.1.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0) dev.bce.1.%driver: bce dev.bce.1.%location: slot=0 function=1 dev.bce.1.%pnpinfo: vendor=0x14e4 device=0x163b subvendor=0x1028 subdevice=0x02f1 class=0x020000 dev.bce.1.%parent: pci1 dev.bce.1.l2fhdr_error_count: 0 dev.bce.1.mbuf_alloc_failed_count: 282 dev.bce.1.fragmented_mbuf_count: 2748 dev.bce.1.dma_map_addr_rx_failed_count: 0 dev.bce.1.dma_map_addr_tx_failed_count: 5 dev.bce.1.unexpected_attention_count: 0 dev.bce.1.stat_IfHcInOctets: 62708651108 dev.bce.1.stat_IfHCInBadOctets: 539369 dev.bce.1.stat_IfHCOutOctets: 434264587173 dev.bce.1.stat_IfHCOutBadOctets: 0 dev.bce.1.stat_IfHCInUcastPkts: 533441918 dev.bce.1.stat_IfHCInMulticastPkts: 3108746 dev.bce.1.stat_IfHCInBroadcastPkts: 1314905 dev.bce.1.stat_IfHCOutUcastPkts: 640961970 dev.bce.1.stat_IfHCOutMulticastPkts: 26 dev.bce.1.stat_IfHCOutBroadcastPkts: 8909 dev.bce.1.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.1.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.1.stat_Dot3StatsFCSErrors: 0 dev.bce.1.stat_Dot3StatsAlignmentErrors: 0 dev.bce.1.stat_Dot3StatsSingleCollisionFrames: 0 dev.bce.1.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.1.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.1.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.1.stat_Dot3StatsLateCollisions: 0 dev.bce.1.stat_EtherStatsCollisions: 0 dev.bce.1.stat_EtherStatsFragments: 0 dev.bce.1.stat_EtherStatsJabbers: 0 dev.bce.1.stat_EtherStatsUndersizePkts: 0 dev.bce.1.stat_EtherStatsOversizePkts: 0 dev.bce.1.stat_EtherStatsPktsRx64Octets: 34048797 dev.bce.1.stat_EtherStatsPktsRx65Octetsto127Octets: 431844366 dev.bce.1.stat_EtherStatsPktsRx128Octetsto255Octets: 25946173 dev.bce.1.stat_EtherStatsPktsRx256Octetsto511Octets: 39936369 dev.bce.1.stat_EtherStatsPktsRx512Octetsto1023Octets: 2296565 dev.bce.1.stat_EtherStatsPktsRx1024Octetsto1522Octets: 3931392 dev.bce.1.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 dev.bce.1.stat_EtherStatsPktsTx64Octets: 60122571 dev.bce.1.stat_EtherStatsPktsTx65Octetsto127Octets: 221041349 dev.bce.1.stat_EtherStatsPktsTx128Octetsto255Octets: 40177071 dev.bce.1.stat_EtherStatsPktsTx256Octetsto511Octets: 24099944 dev.bce.1.stat_EtherStatsPktsTx512Octetsto1023Octets: 44493532 dev.bce.1.stat_EtherStatsPktsTx1024Octetsto1522Octets: 251036438 dev.bce.1.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 dev.bce.1.stat_XonPauseFramesReceived: 61778 dev.bce.1.stat_XoffPauseFramesReceived: 76315 dev.bce.1.stat_OutXonSent: 0 dev.bce.1.stat_OutXoffSent: 0 dev.bce.1.stat_FlowControlDone: 0 dev.bce.1.stat_MacControlFramesReceived: 0 dev.bce.1.stat_XoffStateEntered: 0 dev.bce.1.stat_IfInFramesL2FilterDiscards: 145832 dev.bce.1.stat_IfInRuleCheckerDiscards: 0 dev.bce.1.stat_IfInFTQDiscards: 0 dev.bce.1.stat_IfInMBUFDiscards: 0 dev.bce.1.stat_IfInRuleCheckerP4Hit: 4448215 dev.bce.1.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.1.stat_CatchupInFTQDiscards: 0 dev.bce.1.stat_CatchupInMBUFDiscards: 0 dev.bce.1.stat_CatchupInRuleCheckerP4Hit: 0 dev.bce.1.com_no_buffers: 0 [2] pciconf -lvb bce1@pci0:1:0:1: class=0x020000 card=0x02f11028 chip=0x163b14e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xdc000000, size 33554432, enabled From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 02:59:36 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D1305106566C for ; Tue, 5 Jul 2011 02:59:36 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 71FC915048B for ; Tue, 5 Jul 2011 02:59:36 +0000 (UTC) Message-ID: <4E127E18.6090509@FreeBSD.org> Date: Mon, 04 Jul 2011 19:59:36 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: carp for 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: Tue, 05 Jul 2011 02:59:36 -0000 If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I get an error using either /64 or /128 as the mask: ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 ifconfig 2001:a:b:c::2/64: bad value (width too large) There are no examples for IPv6 in the man page, or the handbook; and I can't find any on line. I'm interested in configuration for the command line, and rc.conf. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 03:26:49 2011 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 02F57106564A; Tue, 5 Jul 2011 03:26:49 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id E05E38FC13; Tue, 5 Jul 2011 03:26:48 +0000 (UTC) Received: from towanda.burnttofu.net ([IPv6:2001:470:1f05:17a6:219:d1ff:fe26:5246]) (authenticated bits=0) by malcolm.berkeley.edu (8.14.4/8.13.8m1) with ESMTP id p653QmDk030459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 4 Jul 2011 20:26:48 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at malcolm.berkeley.edu Message-ID: <4E128477.6030108@rancid.berkeley.edu> Date: Mon, 04 Jul 2011 20:26:47 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110622 Thunderbird/3.1.11 MIME-Version: 1.0 To: Doug Barton References: <4E127E18.6090509@FreeBSD.org> In-Reply-To: <4E127E18.6090509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp for 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: Tue, 05 Jul 2011 03:26:49 -0000 On 07/04/11 19:59, Doug Barton wrote: > If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I > get an error using either /64 or /128 as the mask: > > ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 > > ifconfig 2001:a:b:c::2/64: bad value (width too large) > > There are no examples for IPv6 in the man page, or the handbook; and I > can't find any on line. I'm interested in configuration for the command > line, and rc.conf. ifconfig_carp0="vhid 80 advskew 120 pass yomama 128.32.206.100/32" ipv6_ifconfig_carp0="2607:f140:ffff:ffff::80/128" Works on 8.2-STABLE (June 7, 2011). Note that I cannot get carp to work properly without configuring an IPv4 address. michael From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 04:20:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9CC2B106564A for ; Tue, 5 Jul 2011 04:20:46 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 3CE72152FCB; Tue, 5 Jul 2011 04:20:46 +0000 (UTC) Message-ID: <4E12911D.2060604@FreeBSD.org> Date: Mon, 04 Jul 2011 21:20:45 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael Sinatra References: <4E127E18.6090509@FreeBSD.org> <4E128477.6030108@rancid.berkeley.edu> In-Reply-To: <4E128477.6030108@rancid.berkeley.edu> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp for 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: Tue, 05 Jul 2011 04:20:46 -0000 On 07/04/2011 20:26, Michael Sinatra wrote: > On 07/04/11 19:59, Doug Barton wrote: >> If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I >> get an error using either /64 or /128 as the mask: >> >> ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 >> >> ifconfig 2001:a:b:c::2/64: bad value (width too large) >> >> There are no examples for IPv6 in the man page, or the handbook; and I >> can't find any on line. I'm interested in configuration for the command >> line, and rc.conf. > > ifconfig_carp0="vhid 80 advskew 120 pass yomama 128.32.206.100/32" > ipv6_ifconfig_carp0="2607:f140:ffff:ffff::80/128" > > Works on 8.2-STABLE (June 7, 2011). > > Note that I cannot get carp to work properly without configuring an IPv4 > address. Well that sucks. :-/ In the example you gave, how would you add the IPv6 address on the command line to an existing carp interface? 'ifconfig carp0 inet6 2607:f140:ffff:ffff::80/128 alias' ?? Thanks for the response, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 04:29:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id D8540106564A for ; Tue, 5 Jul 2011 04:29:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 23C881781D0; Tue, 5 Jul 2011 04:29:07 +0000 (UTC) Message-ID: <4E129312.4000709@FreeBSD.org> Date: Mon, 04 Jul 2011 21:29:06 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael Sinatra References: <4E127E18.6090509@FreeBSD.org> <4E128477.6030108@rancid.berkeley.edu> <4E12911D.2060604@FreeBSD.org> In-Reply-To: <4E12911D.2060604@FreeBSD.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp for 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: Tue, 05 Jul 2011 04:29:07 -0000 On 07/04/2011 21:20, Doug Barton wrote: > On 07/04/2011 20:26, Michael Sinatra wrote: >> On 07/04/11 19:59, Doug Barton wrote: >>> If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I >>> get an error using either /64 or /128 as the mask: >>> >>> ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 >>> >>> ifconfig 2001:a:b:c::2/64: bad value (width too large) >>> >>> There are no examples for IPv6 in the man page, or the handbook; and I >>> can't find any on line. I'm interested in configuration for the command >>> line, and rc.conf. >> >> ifconfig_carp0="vhid 80 advskew 120 pass yomama 128.32.206.100/32" >> ipv6_ifconfig_carp0="2607:f140:ffff:ffff::80/128" >> >> Works on 8.2-STABLE (June 7, 2011). >> >> Note that I cannot get carp to work properly without configuring an IPv4 >> address. I should point out that I was able to do the following: ifconfig carp2 *inet6* vhid 4 .... as above, and it "worked" in the sense that it configured the carp interface, but subsequently my IPv6 network went straight into the crapper. Hence, the statement that it won't work without an IPv4 address seems to be correct. This seems pretty sub-optimal given the world we currently live in ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 04:40:59 2011 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 2DE8D1065674; Tue, 5 Jul 2011 04:40:59 +0000 (UTC) (envelope-from lacombar@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 ECADF8FC0C; Tue, 5 Jul 2011 04:40:58 +0000 (UTC) Received: by pzk27 with SMTP id 27so3674157pzk.13 for ; Mon, 04 Jul 2011 21:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4QO5buCqh2PdFypZLbQtQcduJxSEF5exb2ECZjIgmPY=; b=BT+/wxkXJcGHYr5M7MjxTWo4K+wK9BCzcySzZDWjes5U/9DvNuq0jWl30fIVwNAIsw i/nYYsDfVOo5gIQSAO+XaaW/lwUMKrzH8jkadyMnKYDVeYck05jamutsizQf+H+EP1ME aWkjC/OOW3oUzUdVe8D7OjjeGThrbT6ifaxzI= MIME-Version: 1.0 Received: by 10.68.47.101 with SMTP id c5mr9200433pbn.206.1309840858384; Mon, 04 Jul 2011 21:40:58 -0700 (PDT) Received: by 10.68.64.200 with HTTP; Mon, 4 Jul 2011 21:40:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jul 2011 00:40:58 -0400 Message-ID: From: Arnaud Lacombe To: Emil Muratov Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, luigi@freebsd.org, Paolo Pisati Subject: Re: nfe taskq kernel panic 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, 05 Jul 2011 04:40:59 -0000 Hi, On Wed, Jun 8, 2011 at 1:24 AM, Arnaud Lacombe wrote: > Hi, > > [sorry for the delay] > > On Thu, May 5, 2011 at 2:22 PM, Arnaud Lacombe wrote= : >> Hi, >> >> On Thu, May 5, 2011 at 1:37 PM, Emil Muratov wrote: >>> >>> >>> Hi all. >>> >>> I have a small home router/nas running nvidia ion platform with onboard= nfe >>> LAN adapter. >>> About a month ago I changed ISP and setup pppoe client with mpd5.5. Sin= ce >>> that time my router >>> issues kernel panic once or twice a day with "Fatal trap 12: page fault >>> while in kernel mode" and (nfe0 taskq) is the current process. >>> Updating to the latest stable doesn't help. I don=92t know what to do n= ext, >>> any help would be much appreciated. Below is kgdb backtrace, dmesg outp= ut, >>> kernel config file, if anything is missing just let me know. >>> >> Your error looks like a nice use-after-free. Could you 'disassemble >> 0xffffffff8037d7bb' in gdb, and find the matching faulty dereference ? >> > For the record, this crash happen very early in LibAliasIn. The > disassembly gives the following result: > > Dump of assembler code for function LibAliasIn: > 0xffffffff8037d78f : =A0 =A0 =A0push =A0 %rbp > 0xffffffff8037d790 : =A0 =A0 =A0mov =A0 =A0%rsp,%rbp > 0xffffffff8037d793 : =A0 =A0 =A0push =A0 %r15 > 0xffffffff8037d795 : =A0 =A0 =A0push =A0 %r14 > 0xffffffff8037d797 : =A0 =A0 =A0push =A0 %r13 > 0xffffffff8037d799 : =A0 =A0 push =A0 %r12 > 0xffffffff8037d79b : =A0 =A0 push =A0 %rbx > 0xffffffff8037d79c : =A0 =A0 sub =A0 =A0$0x8,%rsp > 0xffffffff8037d7a0 : =A0 =A0 mov =A0 =A0%rdi,%rbx > 0xffffffff8037d7a3 : =A0 =A0 mov =A0 =A0%rsi,%r15 > 0xffffffff8037d7a6 : =A0 =A0 mov =A0 =A0%edx,%r14d > 0xffffffff8037d7a9 : =A0 =A0 mov =A0 =A0%gs:0x0,%r12 > 0xffffffff8037d7b2 : =A0 =A0 mov =A0 =A0$0x4,%r13d > 0xffffffff8037d7b8 : =A0 =A0 mov =A0 =A0%r13,%rax > 0xffffffff8037d7bb : =A0 =A0 lock cmpxchg %r12,0xfac8(%rdi= ) > ^^^ crash here > 0xffffffff8037d7c4 : =A0 =A0 sete =A0 %al > 0xffffffff8037d7c7 : =A0 =A0 test =A0 %al,%al > 0xffffffff8037d7c9 : =A0 =A0 je =A0 =A0 0xffffffff8037d813 > > > As LibAliasIn in _very_ trivial: > > int > LibAliasIn(struct libalias *la, char *ptr, int maxpacketsize) > { > =A0 =A0 =A0 =A0int res; > > =A0 =A0 =A0 =A0LIBALIAS_LOCK(la); > =A0 =A0 =A0 =A0res =3D LibAliasInLocked(la, ptr, maxpacketsize); > =A0 =A0 =A0 =A0LIBALIAS_UNLOCK(la); > =A0 =A0 =A0 =A0return (res); > } > > the crash certainly happens because the reference of libalias became inva= lid. > > Now the reason as of why it happens remain to be found. That part of > the code is pretty obscure to me, so I'll let piso@ or luigi@ handle > this issue for now. > As no body (even among the authors of the relevant code...) cares about this issue, I guess the best is to submit a new PR and hopefully, in a generation or two, it will get resolved. - Arnaud > =A0- Arnaud > >> I'd tend not to trust code relying on "big hack", as per the preamble >> of m_megapullup(): >> >> /* >> =A0* m_megapullup() - this function is a big hack. >> =A0* Thankfully, it's only used in ng_nat and ipfw+nat. >> =A0*... >> >> which look like a re-invention of m_copydata()... >> >> =A0- Arnaud >> >>> Thanx. >>> >>> >>> >>> =3D=3D=3D=3D=3D >>> epia.home.lan dumped core - see /crash/vmcore.15 >>> >>> Thu May =A05 18:29:58 MSD 2011 >>> >>> FreeBSD epia.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #1: Tue May =A03 22= :11:56 >>> MSD 2011 =A0 =A0 root@epia.home.lan:/usr/obj/usr/src/sys/ION4debug =A0a= md64 >>> >>> panic: page fault >>> >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and yo= u are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. =A0Type "show warranty" for de= tails. >>> This GDB was configured as "amd64-marcel-freebsd"... >>> >>> Unread portion of the kernel message buffer: >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid =3D 0; apic id =3D 00 >>> fault virtual address =A0 =3D 0xffffff800ff02ac8 >>> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page n= ot present >>> instruction pointer =A0 =A0 =3D 0x20:0xffffffff8037d7bb >>> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000fde20 >>> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000fde60 >>> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0= x1b >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long = 1, def32 0, gran 1 >>> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D= 0 >>> current process =A0 =A0 =A0 =A0 =3D 0 (nfe0 taskq) >>> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 >>> panic: page fault >>> cpuid =3D 0 >>> KDB: stack backtrace: >>> #0 0xffffffff802a97a3 at kdb_backtrace+0x5e >>> #1 0xffffffff8027aa98 at panic+0x182 >>> #2 0xffffffff804466d0 at trap_fatal+0x292 >>> #3 0xffffffff80446a85 at trap_pfault+0x286 >>> #4 0xffffffff80446f2f at trap+0x3cb >>> #5 0xffffffff8042ff54 at calltrap+0x8 >>> #6 0xffffffff8035ceb4 at ipfw_nat+0x20a >>> #7 0xffffffff803547e3 at ipfw_chk+0xbaf >>> #8 0xffffffff8035977c at ipfw_check_hook+0xf9 >>> #9 0xffffffff8032a221 at pfil_run_hooks+0x9c >>> #10 0xffffffff8035fe84 at ip_input+0x2d0 >>> #11 0xffffffff8032947f at netisr_dispatch_src+0x71 >>> #12 0xffffffff80c22cab at ng_iface_rcvdata+0xdc >>> #13 0xffffffff80c18964 at ng_apply_item+0x20a >>> #14 0xffffffff80c17afd at ng_snd_item+0x2a1 >>> #15 0xffffffff80c18964 at ng_apply_item+0x20a >>> #16 0xffffffff80c17afd at ng_snd_item+0x2a1 >>> #17 0xffffffff80c25305 at ng_ppp_rcvdata+0x202 >>> Uptime: 18h57m47s >>> Physical memory: 2005 MB >>> Dumping 1644 MB: 1629 1613 1597 1581 1565 1549 1533 1517 1501 1485 1469= 1453 >>> 1437 1421 1405 1389 1373 1357 1341 1325 1309 1293 1277 1261 1245 1229 1= 213 >>> 1197 1181 1165 1149 1133 1117 1101 1085 1069 1053 1037 1021 1005 989 97= 3 957 >>> 941 925 909 893 877 861 845 829 813 797 781 765 749 733 717 701 685 669= 653 >>> 637 621 605 589 573 557 541 525 509 493 477 461 445 429 413 397 381 365= 349 >>> 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45= 29 >>> 13 >>> >>> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from >>> /boot/kernel/zfs.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/zfs.ko >>> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from >>> /boot/kernel/opensolaris.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/opensolaris.ko >>> Reading symbols from /boot/kernel/krpc.ko...Reading symbols from >>> /boot/kernel/krpc.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/krpc.ko >>> Reading symbols from /boot/kernel/if_nfe.ko...Reading symbols from >>> /boot/kernel/if_nfe.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/if_nfe.ko >>> Reading symbols from /boot/kernel/aio.ko...Reading symbols from >>> /boot/kernel/aio.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/aio.ko >>> Reading symbols from /boot/kernel/alias_ftp.ko...Reading symbols from >>> /boot/kernel/alias_ftp.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/alias_ftp.ko >>> Reading symbols from /boot/kernel/if_stf.ko...Reading symbols from >>> /boot/kernel/if_stf.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/if_stf.ko >>> Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from >>> /boot/kernel/ng_socket.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_socket.ko >>> Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from >>> /boot/kernel/netgraph.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/netgraph.ko >>> Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from >>> /boot/kernel/ng_mppc.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_mppc.ko >>> Reading symbols from /boot/kernel/rc4.ko...Reading symbols from >>> /boot/kernel/rc4.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/rc4.ko >>> Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from >>> /boot/kernel/ng_iface.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_iface.ko >>> Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from >>> /boot/kernel/ng_ppp.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_ppp.ko >>> Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from >>> /boot/kernel/ng_tee.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_tee.ko >>> Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from >>> /boot/kernel/ng_ether.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_ether.ko >>> Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from >>> /boot/kernel/ng_pppoe.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_pppoe.ko >>> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from >>> /boot/kernel/accf_http.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/accf_http.ko >>> Reading symbols from /boot/kernel/accf_data.ko...Reading symbols from >>> /boot/kernel/accf_data.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/accf_data.ko >>> Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from >>> /boot/kernel/ng_tcpmss.ko.symbols...done. >>> done. >>> Loaded symbols for /boot/kernel/ng_tcpmss.ko >>> #0 =A0doadump () at pcpu.h:224 >>> 224 =A0 =A0 pcpu.h: No such file or directory. >>> =A0 =A0 =A0 =A0in pcpu.h >>> (kgdb) #0 =A0doadump () at pcpu.h:224 >>> #1 =A00xffffffff8027a615 in boot (howto=3D260) >>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:419 >>> #2 =A00xffffffff8027aa82 in panic (fmt=3DVariable "fmt" is not availabl= e.) >>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:592 >>> #3 =A00xffffffff804466d0 in trap_fatal (frame=3D0xc, eva=3DVariable "ev= a" is not >>> available.) >>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:811 >>> #4 =A00xffffffff80446a85 in trap_pfault (frame=3D0xffffff80000fe720, us= ermode=3D0) >>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:727 >>> #5 =A00xffffffff80446f2f in trap (frame=3D0xffffff80000fe720) >>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:477 >>> #6 =A00xffffffff8042ff54 in calltrap () >>> =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:228 >>> #7 =A00xffffffff80c2c8ce in pppoe_findsession (privp=3DVariable "privp"= is not >>> available.) >>> =A0 =A0at /usr/src/sys/modules/netgraph/pppoe/../../../netgraph/ng_pppo= e.c:566 >>> #8 =A00xffffffff80c2cfe7 in ng_pppoe_rcvdata_ether (hook=3DVariable "ho= ok" is >>> not available.) >>> =A0 =A0at /usr/src/sys/modules/netgraph/pppoe/../../../netgraph/ng_pppo= e.c:1613 >>> #9 =A00xffffffff80c18964 in ng_apply_item (node=3D0xffffff002105ec00, >>> =A0 =A0item=3D0xffffff0054a36500, rw=3D0) >>> =A0 =A0at >>> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2327 >>> #10 0xffffffff80c17afd in ng_snd_item (item=3D0xffffff0054a36500, flags= =3D0) >>> =A0 =A0at >>> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2244 >>> #11 0xffffffff80320b5a in ether_demux (ifp=3D0xffffff0006862800, >>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:911 >>> #12 0xffffffff80320f41 in ether_input (ifp=3D0xffffff0006862800, >>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:753 >>> #13 0xffffffff80320aa2 in ether_demux (ifp=3D0xffffff0001676800, >>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:803 >>> #14 0xffffffff80320f41 in ether_input (ifp=3D0xffffff0001676800, >>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:753 >>> #15 0xffffffff809eb76e in nfe_jrxeof (sc=3D0xffffff80003ae000, count=3D= 185, >>> =A0 =A0rx_npktsp=3D0x0) at /usr/src/sys/modules/nfe/../../dev/nfe/if_nf= e.c:2303 >>> #16 0xffffffff809effea in nfe_int_task (arg=3DVariable "arg" is not >>> available.) >>> =A0 =A0at /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:1899 >>> #17 0xffffffff802b3f7e in taskqueue_run_locked (queue=3D0xffffff0001722= 700) >>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:248 >>> #18 0xffffffff802b410c in taskqueue_thread_loop (arg=3DVariable "arg" i= s not >>> available.) >>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:385 >>> #19 0xffffffff80252d5d in fork_exit ( >>> =A0 =A0callout=3D0xffffffff802b40c4 , >>> =A0 =A0arg=3D0xffffff80003ae1b8, frame=3D0xffffff80000fec50) >>> =A0 =A0at /usr/src/sys/kern/kern_fork.c:865 >>> #20 0xffffffff8043049e in fork_trampoline () >>> =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:603 >>> #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 0x0000000000000000 in ?? () >>> #43 0x0000000000000000 in ?? () >>> #44 0x0000000000000000 in ?? () >>> #45 0xffffffff80665140 in affinity () >>> #46 0x0000000000000000 in ?? () >>> #47 0x0000000000000000 in ?? () >>> #48 0xffffff0001741460 in ?? () >>> #49 0xffffff80000fe380 in ?? () >>> #50 0xffffff80000fe328 in ?? () >>> #51 0xffffff00015b8000 in ?? () >>> #52 0xffffffff8029d819 in sched_switch (td=3D0xffffffff802b40c4, >>> =A0 =A0newtd=3D0xffffff80003ae1b8, flags=3DVariable "flags" is not avai= lable. >>> ) at /usr/src/sys/kern/sched_ule.c:1859 >>> Previous frame inner to this frame (corrupt stack?) >>> (kgdb) >>> >>> >>> DMESG >>> --- >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 >>> =A0 =A0 =A0 =A0The Regents of the University of California. All rights = reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.2-STABLE #1: Tue May =A03 22:11:56 MSD 2011 >>> =A0 =A0root@epia.home.lan:/usr/obj/usr/src/sys/ION4debug amd64 >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: Intel(R) Atom(TM) CPU =A0330 =A0 @ 1.60GHz (1600.01-MHz K8-class C= PU) >>> =A0Origin =3D "GenuineIntel" =A0Id =3D 0x106c2 =A0Family =3D 6 =A0Model= =3D 1c =A0Stepping =3D 2 >>> =A0Features=3D0xbfe9fbff >>> =A0Features2=3D0x40e31d >>> =A0AMD Features=3D0x20000800 >>> =A0AMD Features2=3D0x1 >>> =A0TSC: P-state invariant >>> real memory =A0=3D 2147483648 (2048 MB) >>> avail memory =3D 2025250816 (1931 MB) >>> ACPI APIC Table: <072310 APIC1353> >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads >>> =A0cpu0 (BSP): APIC ID: =A00 >>> =A0cpu1 (AP/HT): APIC ID: =A01 >>> =A0cpu2 (AP): APIC ID: =A02 >>> =A0cpu3 (AP/HT): APIC ID: =A03 >>> ioapic0: Changing APIC ID to 4 >>> ioapic0 irqs 0-23 on motherboard >>> kbd1 at kbdmux0 >>> cryptosoft0: on motherboard >>> acpi0: <072310 RSDT1353> on motherboard >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: reservation of fefe1000, 1000 (3) failed >>> acpi0: reservation of fee01000, ff000 (3) failed >>> acpi0: reservation of fec00000, 1000 (3) failed >>> acpi0: reservation of fee00000, 1000 (3) failed >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 7ff00000 (3) failed >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >>> cpu0: on acpi0 >>> cpu1: on acpi0 >>> cpu2: on acpi0 >>> cpu3: on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pci0: at device 0.1 (no driver attached) >>> isab0: port 0x4f00-0x4fff at device 3.0 on pci0 >>> isa0: on isab0 >>> pci0: at device 3.1 (no driver attached) >>> pci0: at device 3.2 (no driver attached) >>> pci0: at device 3.3 (no driver attached) >>> pci0: at device 3.5 (no driver attached) >>> ohci0: mem 0xfae7f000-0xfae7ffff i= rq 16 >>> at device 4.0 on pci0 >>> ohci0: [ITHREAD] >>> usbus0: on ohci0 >>> ehci0: mem 0xfae7ec00-0xfae7ec= ff >>> irq 18 at device 4.1 on pci0 >>> ehci0: [ITHREAD] >>> usbus1: EHCI version 1.0 >>> usbus1: on ehci0 >>> pcib1: at device 9.0 on pci0 >>> pci3: on pcib1 >>> nfe0: port 0xd080-0xd087 mem >>> 0xfae7d000-0xfae7dfff,0xfae7e800-0xfae7e8ff,0xfae7e400-0xfae7e40f irq 2= 2 at >>> device 10.0 on pci0 >>> miibus0: on nfe0 >>> rgephy0: PHY 3 on miibus0 >>> rgephy0: =A010baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, >>> 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, >>> 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, au= to, >>> auto-flow >>> nfe0: Ethernet address: 00:25:22:21:86:89 >>> nfe0: [FILTER] >>> ahci0: port >>> 0xd000-0xd007,0xcc00-0xcc03,0xc880-0xc887,0xc800-0xc803,0xc480-0xc48f m= em >>> 0xfae76000-0xfae77fff irq 23 at device 11.0 on pci0 >>> ahci0: [ITHREAD] >>> ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported >>> ahcich0: at channel 0 on ahci0 >>> ahcich0: [ITHREAD] >>> ahcich1: at channel 1 on ahci0 >>> ahcich1: [ITHREAD] >>> ahcich2: at channel 2 on ahci0 >>> ahcich2: [ITHREAD] >>> ahcich3: at channel 3 on ahci0 >>> ahcich3: [ITHREAD] >>> ahcich4: at channel 4 on ahci0 >>> ahcich4: [ITHREAD] >>> ahcich5: at channel 5 on ahci0 >>> ahcich5: [ITHREAD] >>> pcib2: irq 20 at device 12.0 on pci0 >>> pci2: on pcib2 >>> pcib3: at device 16.0 on pci0 >>> pci1: on pcib3 >>> vgapci0: port 0xec00-0xec7f mem >>> 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xf6000000-0xf7ffffff irq 2= 1 at >>> device 0.0 on pci1 >>> acpi_button0: on acpi0 >>> acpi_hpet0: iomem 0xfed00000-0xfed00fff ir= q 2,8 >>> on acpi0 >>> Timecounter "HPET" frequency 25000000 Hz quality 900 >>> atrtc0: port 0x70-0x71 on acpi0 >>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >>> uart0: [FILTER] >>> sc0: at flags 0x100 on isa0 >>> sc0: VGA <16 virtual consoles, flags=3D0x300> >>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is= a0 >>> atkbdc0: at port 0x60,0x64 on isa0 >>> atkbd0: irq 1 on atkbdc0 >>> kbd0 at atkbd0 >>> atkbd0: [GIANT-LOCKED] >>> atkbd0: [ITHREAD] >>> p4tcc0: on cpu0 >>> p4tcc1: on cpu1 >>> p4tcc2: on cpu2 >>> p4tcc3: on cpu3 >>> ZFS filesystem version 5 >>> ZFS storage pool version 28 >>> Timecounters tick every 1.000 msec >>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based >>> forwarding enabled, default to deny, logging disabled >>> load_dn_sched dn_sched FIFO loaded >>> load_dn_sched dn_sched PRIO loaded >>> load_dn_sched dn_sched QFQ loaded >>> load_dn_sched dn_sched RR loaded >>> load_dn_sched dn_sched WF2Q+ loaded >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on usbu= s0 >>> ugen1.1: at usbus1 >>> uhub1: on usbu= s1 >>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>> ada0: ATA-7 SATA 2.x device >>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada0: Command Queueing enabled >>> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 >>> ada1: ATA-8 SATA 2.x device >>> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada1: Command Queueing enabled >>> ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >>> ada2: ATA-8 SATA 2.x device >>> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada2: Command Queueing enabled >>> ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >>> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >>> ada3: ATA-7 SATA 2.x device >>> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>> ada3: Command Queueing enabled >>> ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>> SMP: AP CPU #3 Launched! >>> SMP: AP CPU #1 Launched! >>> SMP: AP CPU #2 Launched! >>> uhub0: 10 ports with 10 removable, self powered >>> Root mount waiting for: usbus1 >>> Root mount waiting for: usbus1 >>> Root mount waiting for: usbus1 >>> Root mount waiting for: usbus1 >>> uhub1: 10 ports with 10 removable, self powered >>> Trying to mount root from zfs:rz >>> >>> >>> KERNCONF >>> -------- >>>> >>>> grep -v -e "^#" /root/conf/ION4debug >>> >>> cpu =A0 =A0 =A0 =A0 =A0 =A0 HAMMER >>> ident =A0 =A0 =A0 =A0 =A0 ION4debug >>> >>> makeoptions =A0 =A0 DEBUG=3D-g =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Build k= ernel with gdb(1) debug >>> symbols >>> >>> options =A0 =A0 =A0 =A0 SCHED_ULE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # ULE sch= eduler >>> options =A0 =A0 =A0 =A0 PREEMPTION =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable = kernel thread preemption >>> options =A0 =A0 =A0 =A0 INET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# I= nterNETworking >>> options =A0 =A0 =A0 =A0 INET6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # IPv= 6 communications protocols >>> options =A0 =A0 =A0 =A0 FFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # B= erkeley Fast Filesystem >>> options =A0 =A0 =A0 =A0 SOFTUPDATES =A0 =A0 =A0 =A0 =A0 =A0 # Enable FF= S soft updates support >>> options =A0 =A0 =A0 =A0 UFS_ACL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Suppo= rt for access control lists >>> options =A0 =A0 =A0 =A0 UFS_DIRHASH =A0 =A0 =A0 =A0 =A0 =A0 # Improve p= erformance on big >>> directories >>> options =A0 =A0 =A0 =A0 UFS_GJOURNAL =A0 =A0 =A0 =A0 =A0 =A0# Enable gj= ournal-based UFS >>> journaling >>> options =A0 =A0 =A0 =A0 PROCFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Pro= cess filesystem (requires >>> PSEUDOFS) >>> options =A0 =A0 =A0 =A0 PSEUDOFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Pseud= o-filesystem framework >>> options =A0 =A0 =A0 =A0 GEOM_PART_GPT =A0 =A0 =A0 =A0 =A0 # GUID Partit= ion Tables. >>> options =A0 =A0 =A0 =A0 GEOM_LABEL =A0 =A0 =A0 =A0 =A0 =A0 =A0# Provide= s labelization >>> options =A0 =A0 =A0 =A0 COMPAT_43TTY =A0 =A0 =A0 =A0 =A0 =A0# BSD 4.3 T= TY compat (sgtty) >>> options =A0 =A0 =A0 =A0 SCSI_DELAY=3D5000 =A0 =A0 =A0 =A0 # Delay (in m= s) before probing SCSI >>> options =A0 =A0 =A0 =A0 KTRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# ktr= ace(1) support >>> options =A0 =A0 =A0 =A0 STACK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # sta= ck(9) support >>> options =A0 =A0 =A0 =A0 SYSVSHM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV-= style shared memory >>> options =A0 =A0 =A0 =A0 SYSVMSG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV-= style message queues >>> options =A0 =A0 =A0 =A0 SYSVSEM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV-= style semaphores >>> options =A0 =A0 =A0 =A0 P1003_1B_SEMAPHORES =A0 =A0 # POSIX-style semap= hores >>> options =A0 =A0 =A0 =A0 _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B re= al-time >>> extensions >>> options =A0 =A0 =A0 =A0 PRINTF_BUFR_SIZE=3D128 =A0 =A0# Prevent printf = output being >>> interspersed. >>> options =A0 =A0 =A0 =A0 KBD_INSTALL_CDEV =A0 =A0 =A0 =A0# install a CDE= V entry in /dev >>> options =A0 =A0 =A0 =A0 HWPMC_HOOKS =A0 =A0 =A0 =A0 =A0 =A0 # Necessary= kernel hooks for >>> hwpmc(4) >>> options =A0 =A0 =A0 =A0 AUDIT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Sec= urity event auditing >>> options =A0 =A0 =A0 =A0 MAC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # T= rustedBSD MAC Framework >>> options =A0 =A0 =A0 =A0 FLOWTABLE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # per-cpu= routing cache >>> options =A0 =A0 =A0 =A0 INCLUDE_CONFIG_FILE =A0 =A0 # Include this file= in kernel >>> >>> options =A0 =A0 =A0 =A0 KDB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # K= ernel debugger related code >>> options =A0 =A0 =A0 =A0 KDB_TRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Print a= stack trace for a panic >>> >>> options =A0 =A0 =A0 =A0 SMP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # S= ymmetric MultiProcessor Kernel >>> >>> device =A0 =A0 =A0 =A0 =A0cpufreq >>> >>> options =A0 =A0 =A0 =A0 DEVICE_POLLING >>> options =A0 =A0 =A0 =A0 IPFIREWALL >>> options =A0 =A0 =A0 =A0 IPDIVERT >>> options =A0 =A0 =A0 =A0 IPFIREWALL_FORWARD >>> options =A0 =A0 =A0 =A0 IPFIREWALL_NAT >>> options =A0 =A0 =A0 =A0 IPSTEALTH >>> options =A0 =A0 =A0 =A0 DUMMYNET >>> >>> options =A0 =A0 =A0 =A0 LIBALIAS >>> >>> device =A0 =A0 =A0 =A0 =A0crypto >>> >>> device =A0 =A0 =A0 =A0 =A0acpi >>> device =A0 =A0 =A0 =A0 =A0pci >>> >>> device =A0 =A0 =A0 =A0 =A0ahci >>> >>> device =A0 =A0 =A0 =A0 =A0scbus =A0 =A0 =A0 =A0 =A0 # SCSI bus (require= d for SCSI) >>> device =A0 =A0 =A0 =A0 =A0da =A0 =A0 =A0 =A0 =A0 =A0 =A0# Direct Access= (disks) >>> device =A0 =A0 =A0 =A0 =A0pass =A0 =A0 =A0 =A0 =A0 =A0# Passthrough dev= ice (direct SCSI access) >>> >>> device =A0 =A0 =A0 =A0 =A0atkbdc =A0 =A0 =A0 =A0 =A0# AT keyboard contr= oller >>> device =A0 =A0 =A0 =A0 =A0atkbd =A0 =A0 =A0 =A0 =A0 # AT keyboard >>> device =A0 =A0 =A0 =A0 =A0psm =A0 =A0 =A0 =A0 =A0 =A0 # PS/2 mouse >>> >>> device =A0 =A0 =A0 =A0 =A0kbdmux =A0 =A0 =A0 =A0 =A0# keyboard multiple= xer >>> >>> device =A0 =A0 =A0 =A0 =A0vga =A0 =A0 =A0 =A0 =A0 =A0 # VGA video card = driver >>> >>> device =A0 =A0 =A0 =A0 =A0sc >>> >>> device =A0 =A0 =A0 =A0 =A0uart =A0 =A0 =A0 =A0 =A0 =A0# Generic UART dr= iver >>> >>> device =A0 =A0 =A0 =A0 =A0miibus =A0 =A0 =A0 =A0 =A0# MII bus support >>> >>> device =A0 =A0 =A0 =A0 =A0loop =A0 =A0 =A0 =A0 =A0 =A0# Network loopbac= k >>> device =A0 =A0 =A0 =A0 =A0random =A0 =A0 =A0 =A0 =A0# Entropy device >>> device =A0 =A0 =A0 =A0 =A0ether =A0 =A0 =A0 =A0 =A0 # Ethernet support >>> device =A0 =A0 =A0 =A0 =A0vlan =A0 =A0 =A0 =A0 =A0 =A0# 802.1Q VLAN sup= port >>> device =A0 =A0 =A0 =A0 =A0tun =A0 =A0 =A0 =A0 =A0 =A0 # Packet tunnel. >>> device =A0 =A0 =A0 =A0 =A0pty =A0 =A0 =A0 =A0 =A0 =A0 # BSD-style compa= tibility pseudo ttys >>> device =A0 =A0 =A0 =A0 =A0md =A0 =A0 =A0 =A0 =A0 =A0 =A0# Memory "disks= " >>> device =A0 =A0 =A0 =A0 =A0gif =A0 =A0 =A0 =A0 =A0 =A0 # IPv6 and IPv4 t= unneling >>> device =A0 =A0 =A0 =A0 =A0faith =A0 =A0 =A0 =A0 =A0 # IPv6-to-IPv4 rela= ying (translation) >>> device =A0 =A0 =A0 =A0 =A0firmware =A0 =A0 =A0 =A0# firmware assist mod= ule >>> >>> device =A0 =A0 =A0 =A0 =A0bpf =A0 =A0 =A0 =A0 =A0 =A0 # Berkeley packet= filter >>> >>> device =A0 =A0 =A0 =A0 =A0uhci =A0 =A0 =A0 =A0 =A0 =A0# UHCI PCI->USB i= nterface >>> device =A0 =A0 =A0 =A0 =A0ohci =A0 =A0 =A0 =A0 =A0 =A0# OHCI PCI->USB i= nterface >>> device =A0 =A0 =A0 =A0 =A0ehci =A0 =A0 =A0 =A0 =A0 =A0# EHCI PCI->USB i= nterface (USB 2.0) >>> device =A0 =A0 =A0 =A0 =A0usb =A0 =A0 =A0 =A0 =A0 =A0 # USB Bus (requir= ed) >>> device =A0 =A0 =A0 =A0 =A0uhid =A0 =A0 =A0 =A0 =A0 =A0# "Human Interfac= e Devices" >>> device =A0 =A0 =A0 =A0 =A0ukbd =A0 =A0 =A0 =A0 =A0 =A0# Keyboard >>> device =A0 =A0 =A0 =A0 =A0umass =A0 =A0 =A0 =A0 =A0 # Disks/Mass storag= e - Requires scbus and da >>> device =A0 =A0 =A0 =A0 =A0ums =A0 =A0 =A0 =A0 =A0 =A0 # Mouse >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> > From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 04:57:52 2011 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 152CB106564A; Tue, 5 Jul 2011 04:57:52 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id CC6D98FC0A; Tue, 5 Jul 2011 04:57:51 +0000 (UTC) Received: by pvg11 with SMTP id 11so6882532pvg.13 for ; Mon, 04 Jul 2011 21:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FUOo9RBoxHrBhjD+eAXYODJtPuls4mjhBvSiJ4aczJc=; b=JIdgj7+kqi+z7/mblJfOSXSBZXoMm4tN5sWhFYIKv44jz1HPsZvpS7snPfk9X2vBS0 04Ju7lLhG8RANXBKQK8QcV5vENzAMW/751PVTTde5iNUdt7UlwD2kRKkqSNGGmfLcHgO I8unazVk/8SC8sluQXKD9Yj9o6R/PIE6HSkNY= MIME-Version: 1.0 Received: by 10.68.54.6 with SMTP id f6mr5366666pbp.139.1309841870971; Mon, 04 Jul 2011 21:57:50 -0700 (PDT) Received: by 10.68.64.200 with HTTP; Mon, 4 Jul 2011 21:57:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jul 2011 00:57:50 -0400 Message-ID: From: Arnaud Lacombe To: freebsd-current@freebsd.org, ae@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Emil Muratov , Paolo Pisati Subject: Re: nfe taskq kernel panic 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, 05 Jul 2011 04:57:52 -0000 Hi, [Moving thread to -current, added ae@freebsd.org to the Cc: list as he changed that code recently.] On Wed, Jun 8, 2011 at 1:25 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 2:49 PM, Arnaud Lacombe wrote= : >> Hi, >> >> On Thu, May 5, 2011 at 2:22 PM, Arnaud Lacombe wrot= e: >>> Hi, >>> >>> On Thu, May 5, 2011 at 1:37 PM, Emil Muratov wrote: >>>> >>>> >>>> Hi all. >>>> >>>> I have a small home router/nas running nvidia ion platform with onboar= d nfe >>>> LAN adapter. >>>> About a month ago I changed ISP and setup pppoe client with mpd5.5. Si= nce >>>> that time my router >>>> issues kernel panic once or twice a day with "Fatal trap 12: page faul= t >>>> while in kernel mode" and (nfe0 taskq) is the current process. >>>> Updating to the latest stable doesn't help. I don=92t know what to do = next, >>>> any help would be much appreciated. Below is kgdb backtrace, dmesg out= put, >>>> kernel config file, if anything is missing just let me know. >>>> >>> Your error looks like a nice use-after-free. Could you 'disassemble >>> 0xffffffff8037d7bb' in gdb, and find the matching faulty dereference ? >>> I'd tend not to trust code relying on "big hack", as per the preamble >>> of m_megapullup(): >>> >> There is a stale reference to the mbuf passed to, and freed in >> m_megapullup(); could you test the following patch ? >> >> diff --git a/sys/netinet/ipfw/ip_fw_nat.c b/sys/netinet/ipfw/ip_fw_nat.c >> index f8c3e63..80c13dc 100644 >> --- a/sys/netinet/ipfw/ip_fw_nat.c >> +++ b/sys/netinet/ipfw/ip_fw_nat.c >> @@ -263,7 +263,7 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat >> *t, struct mbuf *m) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0retval =3D LibAliasOut(t->lib, c, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mcl->m_len + M_TRAILINGSP= ACE(mcl)); >> =A0 =A0 =A0 =A0if (retval =3D=3D PKT_ALIAS_RESPOND) { >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 m->m_flags |=3D M_SKIP_FIREWALL; >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mcl->m_flags |=3D M_SKIP_FIREWALL; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0retval =3D PKT_ALIAS_OK; >> =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0if (retval !=3D PKT_ALIAS_OK && >> >> This was introduced in r188294 by piso@ (added to the CC: list). >> > piso@, could you please _fix_ that code ? > Can someone fix this obvious use-after-free, please ? the mbuf passed to m_megapullup() cannot be re-used as it might ends up being freed. This conditional is the sole conditional still using `m' after the call to m_megapullup(). diff --git a/sys/netinet/ipfw/ip_fw_nat.c b/sys/netinet/ipfw/ip_fw_nat.c index 1679a97..dbeb254 100644 --- a/sys/netinet/ipfw/ip_fw_nat.c +++ b/sys/netinet/ipfw/ip_fw_nat.c @@ -315,7 +315,7 @@ ipfw_nat(struct ip_fw_args *args, struct cfg_nat *t, struct mbuf *m) } if (retval =3D=3D PKT_ALIAS_RESPOND) - m->m_flags |=3D M_SKIP_FIREWALL; + mcl->m_flags |=3D M_SKIP_FIREWALL; mcl->m_pkthdr.len =3D mcl->m_len =3D ntohs(ip->ip_len); /* Thanks, - Arnaud > Thanks, > =A0- Arnaud > > >> =A0- Arnaud >> >> >>> /* >>> =A0* m_megapullup() - this function is a big hack. >>> =A0* Thankfully, it's only used in ng_nat and ipfw+nat. >>> =A0*... >>> >>> which look like a re-invention of m_copydata()... >>> >>> =A0- Arnaud >>> >>>> Thanx. >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D >>>> epia.home.lan dumped core - see /crash/vmcore.15 >>>> >>>> Thu May =A05 18:29:58 MSD 2011 >>>> >>>> FreeBSD epia.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #1: Tue May =A03 2= 2:11:56 >>>> MSD 2011 =A0 =A0 root@epia.home.lan:/usr/obj/usr/src/sys/ION4debug =A0= amd64 >>>> >>>> panic: page fault >>>> >>>> GNU gdb 6.1.1 [FreeBSD] >>>> Copyright 2004 Free Software Foundation, Inc. >>>> GDB is free software, covered by the GNU General Public License, and y= ou are >>>> welcome to change it and/or distribute copies of it under certain >>>> conditions. >>>> Type "show copying" to see the conditions. >>>> There is absolutely no warranty for GDB. =A0Type "show warranty" for d= etails. >>>> This GDB was configured as "amd64-marcel-freebsd"... >>>> >>>> Unread portion of the kernel message buffer: >>>> >>>> Fatal trap 12: page fault while in kernel mode >>>> cpuid =3D 0; apic id =3D 00 >>>> fault virtual address =A0 =3D 0xffffff800ff02ac8 >>>> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor write data, page = not present >>>> instruction pointer =A0 =A0 =3D 0x20:0xffffffff8037d7bb >>>> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000fde20 >>>> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff80000fde60 >>>> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type = 0x1b >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long= 1, def32 0, gran 1 >>>> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL = =3D 0 >>>> current process =A0 =A0 =A0 =A0 =3D 0 (nfe0 taskq) >>>> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 >>>> panic: page fault >>>> cpuid =3D 0 >>>> KDB: stack backtrace: >>>> #0 0xffffffff802a97a3 at kdb_backtrace+0x5e >>>> #1 0xffffffff8027aa98 at panic+0x182 >>>> #2 0xffffffff804466d0 at trap_fatal+0x292 >>>> #3 0xffffffff80446a85 at trap_pfault+0x286 >>>> #4 0xffffffff80446f2f at trap+0x3cb >>>> #5 0xffffffff8042ff54 at calltrap+0x8 >>>> #6 0xffffffff8035ceb4 at ipfw_nat+0x20a >>>> #7 0xffffffff803547e3 at ipfw_chk+0xbaf >>>> #8 0xffffffff8035977c at ipfw_check_hook+0xf9 >>>> #9 0xffffffff8032a221 at pfil_run_hooks+0x9c >>>> #10 0xffffffff8035fe84 at ip_input+0x2d0 >>>> #11 0xffffffff8032947f at netisr_dispatch_src+0x71 >>>> #12 0xffffffff80c22cab at ng_iface_rcvdata+0xdc >>>> #13 0xffffffff80c18964 at ng_apply_item+0x20a >>>> #14 0xffffffff80c17afd at ng_snd_item+0x2a1 >>>> #15 0xffffffff80c18964 at ng_apply_item+0x20a >>>> #16 0xffffffff80c17afd at ng_snd_item+0x2a1 >>>> #17 0xffffffff80c25305 at ng_ppp_rcvdata+0x202 >>>> Uptime: 18h57m47s >>>> Physical memory: 2005 MB >>>> Dumping 1644 MB: 1629 1613 1597 1581 1565 1549 1533 1517 1501 1485 146= 9 1453 >>>> 1437 1421 1405 1389 1373 1357 1341 1325 1309 1293 1277 1261 1245 1229 = 1213 >>>> 1197 1181 1165 1149 1133 1117 1101 1085 1069 1053 1037 1021 1005 989 9= 73 957 >>>> 941 925 909 893 877 861 845 829 813 797 781 765 749 733 717 701 685 66= 9 653 >>>> 637 621 605 589 573 557 541 525 509 493 477 461 445 429 413 397 381 36= 5 349 >>>> 333 317 301 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 4= 5 29 >>>> 13 >>>> >>>> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from >>>> /boot/kernel/zfs.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/zfs.ko >>>> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols fro= m >>>> /boot/kernel/opensolaris.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/opensolaris.ko >>>> Reading symbols from /boot/kernel/krpc.ko...Reading symbols from >>>> /boot/kernel/krpc.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/krpc.ko >>>> Reading symbols from /boot/kernel/if_nfe.ko...Reading symbols from >>>> /boot/kernel/if_nfe.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/if_nfe.ko >>>> Reading symbols from /boot/kernel/aio.ko...Reading symbols from >>>> /boot/kernel/aio.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/aio.ko >>>> Reading symbols from /boot/kernel/alias_ftp.ko...Reading symbols from >>>> /boot/kernel/alias_ftp.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/alias_ftp.ko >>>> Reading symbols from /boot/kernel/if_stf.ko...Reading symbols from >>>> /boot/kernel/if_stf.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/if_stf.ko >>>> Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from >>>> /boot/kernel/ng_socket.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_socket.ko >>>> Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from >>>> /boot/kernel/netgraph.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/netgraph.ko >>>> Reading symbols from /boot/kernel/ng_mppc.ko...Reading symbols from >>>> /boot/kernel/ng_mppc.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_mppc.ko >>>> Reading symbols from /boot/kernel/rc4.ko...Reading symbols from >>>> /boot/kernel/rc4.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/rc4.ko >>>> Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from >>>> /boot/kernel/ng_iface.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_iface.ko >>>> Reading symbols from /boot/kernel/ng_ppp.ko...Reading symbols from >>>> /boot/kernel/ng_ppp.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_ppp.ko >>>> Reading symbols from /boot/kernel/ng_tee.ko...Reading symbols from >>>> /boot/kernel/ng_tee.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_tee.ko >>>> Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from >>>> /boot/kernel/ng_ether.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_ether.ko >>>> Reading symbols from /boot/kernel/ng_pppoe.ko...Reading symbols from >>>> /boot/kernel/ng_pppoe.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_pppoe.ko >>>> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from >>>> /boot/kernel/accf_http.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/accf_http.ko >>>> Reading symbols from /boot/kernel/accf_data.ko...Reading symbols from >>>> /boot/kernel/accf_data.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/accf_data.ko >>>> Reading symbols from /boot/kernel/ng_tcpmss.ko...Reading symbols from >>>> /boot/kernel/ng_tcpmss.ko.symbols...done. >>>> done. >>>> Loaded symbols for /boot/kernel/ng_tcpmss.ko >>>> #0 =A0doadump () at pcpu.h:224 >>>> 224 =A0 =A0 pcpu.h: No such file or directory. >>>> =A0 =A0 =A0 =A0in pcpu.h >>>> (kgdb) #0 =A0doadump () at pcpu.h:224 >>>> #1 =A00xffffffff8027a615 in boot (howto=3D260) >>>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:419 >>>> #2 =A00xffffffff8027aa82 in panic (fmt=3DVariable "fmt" is not availab= le.) >>>> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:592 >>>> #3 =A00xffffffff804466d0 in trap_fatal (frame=3D0xc, eva=3DVariable "e= va" is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:811 >>>> #4 =A00xffffffff80446a85 in trap_pfault (frame=3D0xffffff80000fe720, u= sermode=3D0) >>>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:727 >>>> #5 =A00xffffffff80446f2f in trap (frame=3D0xffffff80000fe720) >>>> =A0 =A0at /usr/src/sys/amd64/amd64/trap.c:477 >>>> #6 =A00xffffffff8042ff54 in calltrap () >>>> =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:228 >>>> #7 =A00xffffffff80c2c8ce in pppoe_findsession (privp=3DVariable "privp= " is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/modules/netgraph/pppoe/../../../netgraph/ng_ppp= oe.c:566 >>>> #8 =A00xffffffff80c2cfe7 in ng_pppoe_rcvdata_ether (hook=3DVariable "h= ook" is >>>> not available.) >>>> =A0 =A0at /usr/src/sys/modules/netgraph/pppoe/../../../netgraph/ng_ppp= oe.c:1613 >>>> #9 =A00xffffffff80c18964 in ng_apply_item (node=3D0xffffff002105ec00, >>>> =A0 =A0item=3D0xffffff0054a36500, rw=3D0) >>>> =A0 =A0at >>>> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:232= 7 >>>> #10 0xffffffff80c17afd in ng_snd_item (item=3D0xffffff0054a36500, flag= s=3D0) >>>> =A0 =A0at >>>> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:224= 4 >>>> #11 0xffffffff80320b5a in ether_demux (ifp=3D0xffffff0006862800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:911 >>>> #12 0xffffffff80320f41 in ether_input (ifp=3D0xffffff0006862800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:753 >>>> #13 0xffffffff80320aa2 in ether_demux (ifp=3D0xffffff0001676800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:803 >>>> #14 0xffffffff80320f41 in ether_input (ifp=3D0xffffff0001676800, >>>> =A0 =A0m=3D0xffffff0039907700) at /usr/src/sys/net/if_ethersubr.c:753 >>>> #15 0xffffffff809eb76e in nfe_jrxeof (sc=3D0xffffff80003ae000, count= =3D185, >>>> =A0 =A0rx_npktsp=3D0x0) at /usr/src/sys/modules/nfe/../../dev/nfe/if_n= fe.c:2303 >>>> #16 0xffffffff809effea in nfe_int_task (arg=3DVariable "arg" is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:1899 >>>> #17 0xffffffff802b3f7e in taskqueue_run_locked (queue=3D0xffffff000172= 2700) >>>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:248 >>>> #18 0xffffffff802b410c in taskqueue_thread_loop (arg=3DVariable "arg" = is not >>>> available.) >>>> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:385 >>>> #19 0xffffffff80252d5d in fork_exit ( >>>> =A0 =A0callout=3D0xffffffff802b40c4 , >>>> =A0 =A0arg=3D0xffffff80003ae1b8, frame=3D0xffffff80000fec50) >>>> =A0 =A0at /usr/src/sys/kern/kern_fork.c:865 >>>> #20 0xffffffff8043049e in fork_trampoline () >>>> =A0 =A0at /usr/src/sys/amd64/amd64/exception.S:603 >>>> #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 0x0000000000000000 in ?? () >>>> #43 0x0000000000000000 in ?? () >>>> #44 0x0000000000000000 in ?? () >>>> #45 0xffffffff80665140 in affinity () >>>> #46 0x0000000000000000 in ?? () >>>> #47 0x0000000000000000 in ?? () >>>> #48 0xffffff0001741460 in ?? () >>>> #49 0xffffff80000fe380 in ?? () >>>> #50 0xffffff80000fe328 in ?? () >>>> #51 0xffffff00015b8000 in ?? () >>>> #52 0xffffffff8029d819 in sched_switch (td=3D0xffffffff802b40c4, >>>> =A0 =A0newtd=3D0xffffff80003ae1b8, flags=3DVariable "flags" is not ava= ilable. >>>> ) at /usr/src/sys/kern/sched_ule.c:1859 >>>> Previous frame inner to this frame (corrupt stack?) >>>> (kgdb) >>>> >>>> >>>> DMESG >>>> --- >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 >>>> =A0 =A0 =A0 =A0The Regents of the University of California. All rights= reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 8.2-STABLE #1: Tue May =A03 22:11:56 MSD 2011 >>>> =A0 =A0root@epia.home.lan:/usr/obj/usr/src/sys/ION4debug amd64 >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> CPU: Intel(R) Atom(TM) CPU =A0330 =A0 @ 1.60GHz (1600.01-MHz K8-class = CPU) >>>> =A0Origin =3D "GenuineIntel" =A0Id =3D 0x106c2 =A0Family =3D 6 =A0Mode= l =3D 1c =A0Stepping =3D 2 >>>> =A0Features=3D0xbfe9fbff >>>> =A0Features2=3D0x40e31d >>>> =A0AMD Features=3D0x20000800 >>>> =A0AMD Features2=3D0x1 >>>> =A0TSC: P-state invariant >>>> real memory =A0=3D 2147483648 (2048 MB) >>>> avail memory =3D 2025250816 (1931 MB) >>>> ACPI APIC Table: <072310 APIC1353> >>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads >>>> =A0cpu0 (BSP): APIC ID: =A00 >>>> =A0cpu1 (AP/HT): APIC ID: =A01 >>>> =A0cpu2 (AP): APIC ID: =A02 >>>> =A0cpu3 (AP/HT): APIC ID: =A03 >>>> ioapic0: Changing APIC ID to 4 >>>> ioapic0 irqs 0-23 on motherboard >>>> kbd1 at kbdmux0 >>>> cryptosoft0: on motherboard >>>> acpi0: <072310 RSDT1353> on motherboard >>>> acpi0: [ITHREAD] >>>> acpi0: Power Button (fixed) >>>> acpi0: reservation of fefe1000, 1000 (3) failed >>>> acpi0: reservation of fee01000, ff000 (3) failed >>>> acpi0: reservation of fec00000, 1000 (3) failed >>>> acpi0: reservation of fee00000, 1000 (3) failed >>>> acpi0: reservation of 0, a0000 (3) failed >>>> acpi0: reservation of 100000, 7ff00000 (3) failed >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >>>> cpu0: on acpi0 >>>> cpu1: on acpi0 >>>> cpu2: on acpi0 >>>> cpu3: on acpi0 >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> pci0: at device 0.1 (no driver attached) >>>> isab0: port 0x4f00-0x4fff at device 3.0 on pci0 >>>> isa0: on isab0 >>>> pci0: at device 3.1 (no driver attached) >>>> pci0: at device 3.2 (no driver attached) >>>> pci0: at device 3.3 (no driver attached) >>>> pci0: at device 3.5 (no driver attached) >>>> ohci0: mem 0xfae7f000-0xfae7ffff = irq 16 >>>> at device 4.0 on pci0 >>>> ohci0: [ITHREAD] >>>> usbus0: on ohci0 >>>> ehci0: mem 0xfae7ec00-0xfae7e= cff >>>> irq 18 at device 4.1 on pci0 >>>> ehci0: [ITHREAD] >>>> usbus1: EHCI version 1.0 >>>> usbus1: on ehci0 >>>> pcib1: at device 9.0 on pci0 >>>> pci3: on pcib1 >>>> nfe0: port 0xd080-0xd087 mem >>>> 0xfae7d000-0xfae7dfff,0xfae7e800-0xfae7e8ff,0xfae7e400-0xfae7e40f irq = 22 at >>>> device 10.0 on pci0 >>>> miibus0: on nfe0 >>>> rgephy0: PHY 3 on miibus0 >>>> rgephy0: =A010baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100base= TX-FDX, >>>> 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, >>>> 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, a= uto, >>>> auto-flow >>>> nfe0: Ethernet address: 00:25:22:21:86:89 >>>> nfe0: [FILTER] >>>> ahci0: port >>>> 0xd000-0xd007,0xcc00-0xcc03,0xc880-0xc887,0xc800-0xc803,0xc480-0xc48f = mem >>>> 0xfae76000-0xfae77fff irq 23 at device 11.0 on pci0 >>>> ahci0: [ITHREAD] >>>> ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported >>>> ahcich0: at channel 0 on ahci0 >>>> ahcich0: [ITHREAD] >>>> ahcich1: at channel 1 on ahci0 >>>> ahcich1: [ITHREAD] >>>> ahcich2: at channel 2 on ahci0 >>>> ahcich2: [ITHREAD] >>>> ahcich3: at channel 3 on ahci0 >>>> ahcich3: [ITHREAD] >>>> ahcich4: at channel 4 on ahci0 >>>> ahcich4: [ITHREAD] >>>> ahcich5: at channel 5 on ahci0 >>>> ahcich5: [ITHREAD] >>>> pcib2: irq 20 at device 12.0 on pci0 >>>> pci2: on pcib2 >>>> pcib3: at device 16.0 on pci0 >>>> pci1: on pcib3 >>>> vgapci0: port 0xec00-0xec7f mem >>>> 0xfb000000-0xfbffffff,0xe0000000-0xefffffff,0xf6000000-0xf7ffffff irq = 21 at >>>> device 0.0 on pci1 >>>> acpi_button0: on acpi0 >>>> acpi_hpet0: iomem 0xfed00000-0xfed00fff i= rq 2,8 >>>> on acpi0 >>>> Timecounter "HPET" frequency 25000000 Hz quality 900 >>>> atrtc0: port 0x70-0x71 on acpi0 >>>> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi= 0 >>>> uart0: [FILTER] >>>> sc0: at flags 0x100 on isa0 >>>> sc0: VGA <16 virtual consoles, flags=3D0x300> >>>> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on i= sa0 >>>> atkbdc0: at port 0x60,0x64 on isa0 >>>> atkbd0: irq 1 on atkbdc0 >>>> kbd0 at atkbd0 >>>> atkbd0: [GIANT-LOCKED] >>>> atkbd0: [ITHREAD] >>>> p4tcc0: on cpu0 >>>> p4tcc1: on cpu1 >>>> p4tcc2: on cpu2 >>>> p4tcc3: on cpu3 >>>> ZFS filesystem version 5 >>>> ZFS storage pool version 28 >>>> Timecounters tick every 1.000 msec >>>> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based >>>> forwarding enabled, default to deny, logging disabled >>>> load_dn_sched dn_sched FIFO loaded >>>> load_dn_sched dn_sched PRIO loaded >>>> load_dn_sched dn_sched QFQ loaded >>>> load_dn_sched dn_sched RR loaded >>>> load_dn_sched dn_sched WF2Q+ loaded >>>> usbus0: 12Mbps Full Speed USB v1.0 >>>> usbus1: 480Mbps High Speed USB v2.0 >>>> ugen0.1: at usbus0 >>>> uhub0: on usb= us0 >>>> ugen1.1: at usbus1 >>>> uhub1: on usb= us1 >>>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >>>> ada0: ATA-7 SATA 2.x device >>>> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada0: Command Queueing enabled >>>> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>>> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 >>>> ada1: ATA-8 SATA 2.x device >>>> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada1: Command Queueing enabled >>>> ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>>> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >>>> ada2: ATA-8 SATA 2.x device >>>> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada2: Command Queueing enabled >>>> ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >>>> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >>>> ada3: ATA-7 SATA 2.x device >>>> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada3: Command Queueing enabled >>>> ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >>>> SMP: AP CPU #3 Launched! >>>> SMP: AP CPU #1 Launched! >>>> SMP: AP CPU #2 Launched! >>>> uhub0: 10 ports with 10 removable, self powered >>>> Root mount waiting for: usbus1 >>>> Root mount waiting for: usbus1 >>>> Root mount waiting for: usbus1 >>>> Root mount waiting for: usbus1 >>>> uhub1: 10 ports with 10 removable, self powered >>>> Trying to mount root from zfs:rz >>>> >>>> >>>> KERNCONF >>>> -------- >>>>> >>>>> grep -v -e "^#" /root/conf/ION4debug >>>> >>>> cpu =A0 =A0 =A0 =A0 =A0 =A0 HAMMER >>>> ident =A0 =A0 =A0 =A0 =A0 ION4debug >>>> >>>> makeoptions =A0 =A0 DEBUG=3D-g =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Build = kernel with gdb(1) debug >>>> symbols >>>> >>>> options =A0 =A0 =A0 =A0 SCHED_ULE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # ULE sc= heduler >>>> options =A0 =A0 =A0 =A0 PREEMPTION =A0 =A0 =A0 =A0 =A0 =A0 =A0# Enable= kernel thread preemption >>>> options =A0 =A0 =A0 =A0 INET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# = InterNETworking >>>> options =A0 =A0 =A0 =A0 INET6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # IP= v6 communications protocols >>>> options =A0 =A0 =A0 =A0 FFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = Berkeley Fast Filesystem >>>> options =A0 =A0 =A0 =A0 SOFTUPDATES =A0 =A0 =A0 =A0 =A0 =A0 # Enable F= FS soft updates support >>>> options =A0 =A0 =A0 =A0 UFS_ACL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Supp= ort for access control lists >>>> options =A0 =A0 =A0 =A0 UFS_DIRHASH =A0 =A0 =A0 =A0 =A0 =A0 # Improve = performance on big >>>> directories >>>> options =A0 =A0 =A0 =A0 UFS_GJOURNAL =A0 =A0 =A0 =A0 =A0 =A0# Enable g= journal-based UFS >>>> journaling >>>> options =A0 =A0 =A0 =A0 PROCFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Pr= ocess filesystem (requires >>>> PSEUDOFS) >>>> options =A0 =A0 =A0 =A0 PSEUDOFS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# Pseu= do-filesystem framework >>>> options =A0 =A0 =A0 =A0 GEOM_PART_GPT =A0 =A0 =A0 =A0 =A0 # GUID Parti= tion Tables. >>>> options =A0 =A0 =A0 =A0 GEOM_LABEL =A0 =A0 =A0 =A0 =A0 =A0 =A0# Provid= es labelization >>>> options =A0 =A0 =A0 =A0 COMPAT_43TTY =A0 =A0 =A0 =A0 =A0 =A0# BSD 4.3 = TTY compat (sgtty) >>>> options =A0 =A0 =A0 =A0 SCSI_DELAY=3D5000 =A0 =A0 =A0 =A0 # Delay (in = ms) before probing SCSI >>>> options =A0 =A0 =A0 =A0 KTRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# kt= race(1) support >>>> options =A0 =A0 =A0 =A0 STACK =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # st= ack(9) support >>>> options =A0 =A0 =A0 =A0 SYSVSHM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV= -style shared memory >>>> options =A0 =A0 =A0 =A0 SYSVMSG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV= -style message queues >>>> options =A0 =A0 =A0 =A0 SYSVSEM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # SYSV= -style semaphores >>>> options =A0 =A0 =A0 =A0 P1003_1B_SEMAPHORES =A0 =A0 # POSIX-style sema= phores >>>> options =A0 =A0 =A0 =A0 _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B r= eal-time >>>> extensions >>>> options =A0 =A0 =A0 =A0 PRINTF_BUFR_SIZE=3D128 =A0 =A0# Prevent printf= output being >>>> interspersed. >>>> options =A0 =A0 =A0 =A0 KBD_INSTALL_CDEV =A0 =A0 =A0 =A0# install a CD= EV entry in /dev >>>> options =A0 =A0 =A0 =A0 HWPMC_HOOKS =A0 =A0 =A0 =A0 =A0 =A0 # Necessar= y kernel hooks for >>>> hwpmc(4) >>>> options =A0 =A0 =A0 =A0 AUDIT =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Se= curity event auditing >>>> options =A0 =A0 =A0 =A0 MAC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = TrustedBSD MAC Framework >>>> options =A0 =A0 =A0 =A0 FLOWTABLE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # per-cp= u routing cache >>>> options =A0 =A0 =A0 =A0 INCLUDE_CONFIG_FILE =A0 =A0 # Include this fil= e in kernel >>>> >>>> options =A0 =A0 =A0 =A0 KDB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = Kernel debugger related code >>>> options =A0 =A0 =A0 =A0 KDB_TRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Print = a stack trace for a panic >>>> >>>> options =A0 =A0 =A0 =A0 SMP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # = Symmetric MultiProcessor Kernel >>>> >>>> device =A0 =A0 =A0 =A0 =A0cpufreq >>>> >>>> options =A0 =A0 =A0 =A0 DEVICE_POLLING >>>> options =A0 =A0 =A0 =A0 IPFIREWALL >>>> options =A0 =A0 =A0 =A0 IPDIVERT >>>> options =A0 =A0 =A0 =A0 IPFIREWALL_FORWARD >>>> options =A0 =A0 =A0 =A0 IPFIREWALL_NAT >>>> options =A0 =A0 =A0 =A0 IPSTEALTH >>>> options =A0 =A0 =A0 =A0 DUMMYNET >>>> >>>> options =A0 =A0 =A0 =A0 LIBALIAS >>>> >>>> device =A0 =A0 =A0 =A0 =A0crypto >>>> >>>> device =A0 =A0 =A0 =A0 =A0acpi >>>> device =A0 =A0 =A0 =A0 =A0pci >>>> >>>> device =A0 =A0 =A0 =A0 =A0ahci >>>> >>>> device =A0 =A0 =A0 =A0 =A0scbus =A0 =A0 =A0 =A0 =A0 # SCSI bus (requir= ed for SCSI) >>>> device =A0 =A0 =A0 =A0 =A0da =A0 =A0 =A0 =A0 =A0 =A0 =A0# Direct Acces= s (disks) >>>> device =A0 =A0 =A0 =A0 =A0pass =A0 =A0 =A0 =A0 =A0 =A0# Passthrough de= vice (direct SCSI access) >>>> >>>> device =A0 =A0 =A0 =A0 =A0atkbdc =A0 =A0 =A0 =A0 =A0# AT keyboard cont= roller >>>> device =A0 =A0 =A0 =A0 =A0atkbd =A0 =A0 =A0 =A0 =A0 # AT keyboard >>>> device =A0 =A0 =A0 =A0 =A0psm =A0 =A0 =A0 =A0 =A0 =A0 # PS/2 mouse >>>> >>>> device =A0 =A0 =A0 =A0 =A0kbdmux =A0 =A0 =A0 =A0 =A0# keyboard multipl= exer >>>> >>>> device =A0 =A0 =A0 =A0 =A0vga =A0 =A0 =A0 =A0 =A0 =A0 # VGA video card= driver >>>> >>>> device =A0 =A0 =A0 =A0 =A0sc >>>> >>>> device =A0 =A0 =A0 =A0 =A0uart =A0 =A0 =A0 =A0 =A0 =A0# Generic UART d= river >>>> >>>> device =A0 =A0 =A0 =A0 =A0miibus =A0 =A0 =A0 =A0 =A0# MII bus support >>>> >>>> device =A0 =A0 =A0 =A0 =A0loop =A0 =A0 =A0 =A0 =A0 =A0# Network loopba= ck >>>> device =A0 =A0 =A0 =A0 =A0random =A0 =A0 =A0 =A0 =A0# Entropy device >>>> device =A0 =A0 =A0 =A0 =A0ether =A0 =A0 =A0 =A0 =A0 # Ethernet support >>>> device =A0 =A0 =A0 =A0 =A0vlan =A0 =A0 =A0 =A0 =A0 =A0# 802.1Q VLAN su= pport >>>> device =A0 =A0 =A0 =A0 =A0tun =A0 =A0 =A0 =A0 =A0 =A0 # Packet tunnel. >>>> device =A0 =A0 =A0 =A0 =A0pty =A0 =A0 =A0 =A0 =A0 =A0 # BSD-style comp= atibility pseudo ttys >>>> device =A0 =A0 =A0 =A0 =A0md =A0 =A0 =A0 =A0 =A0 =A0 =A0# Memory "disk= s" >>>> device =A0 =A0 =A0 =A0 =A0gif =A0 =A0 =A0 =A0 =A0 =A0 # IPv6 and IPv4 = tunneling >>>> device =A0 =A0 =A0 =A0 =A0faith =A0 =A0 =A0 =A0 =A0 # IPv6-to-IPv4 rel= aying (translation) >>>> device =A0 =A0 =A0 =A0 =A0firmware =A0 =A0 =A0 =A0# firmware assist mo= dule >>>> >>>> device =A0 =A0 =A0 =A0 =A0bpf =A0 =A0 =A0 =A0 =A0 =A0 # Berkeley packe= t filter >>>> >>>> device =A0 =A0 =A0 =A0 =A0uhci =A0 =A0 =A0 =A0 =A0 =A0# UHCI PCI->USB = interface >>>> device =A0 =A0 =A0 =A0 =A0ohci =A0 =A0 =A0 =A0 =A0 =A0# OHCI PCI->USB = interface >>>> device =A0 =A0 =A0 =A0 =A0ehci =A0 =A0 =A0 =A0 =A0 =A0# EHCI PCI->USB = interface (USB 2.0) >>>> device =A0 =A0 =A0 =A0 =A0usb =A0 =A0 =A0 =A0 =A0 =A0 # USB Bus (requi= red) >>>> device =A0 =A0 =A0 =A0 =A0uhid =A0 =A0 =A0 =A0 =A0 =A0# "Human Interfa= ce Devices" >>>> device =A0 =A0 =A0 =A0 =A0ukbd =A0 =A0 =A0 =A0 =A0 =A0# Keyboard >>>> device =A0 =A0 =A0 =A0 =A0umass =A0 =A0 =A0 =A0 =A0 # Disks/Mass stora= ge - Requires scbus and da >>>> device =A0 =A0 =A0 =A0 =A0ums =A0 =A0 =A0 =A0 =A0 =A0 # Mouse >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>>> >>> >> > From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 05:32:36 2011 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 8FAE1106566B; Tue, 5 Jul 2011 05:32:36 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 774E48FC0A; Tue, 5 Jul 2011 05:32:36 +0000 (UTC) Received: from towanda.burnttofu.net ([IPv6:2001:470:1f05:17a6:219:d1ff:fe26:5246]) (authenticated bits=0) by malcolm.berkeley.edu (8.14.4/8.13.8m1) with ESMTP id p655WZ0w045141 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 4 Jul 2011 22:32:36 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.2 at malcolm.berkeley.edu Message-ID: <4E12A1F3.1040302@rancid.berkeley.edu> Date: Mon, 04 Jul 2011 22:32:35 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110622 Thunderbird/3.1.11 MIME-Version: 1.0 To: Doug Barton References: <4E127E18.6090509@FreeBSD.org> <4E128477.6030108@rancid.berkeley.edu> <4E12911D.2060604@FreeBSD.org> <4E129312.4000709@FreeBSD.org> In-Reply-To: <4E129312.4000709@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp for 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: Tue, 05 Jul 2011 05:32:36 -0000 On 07/04/11 21:29, Doug Barton wrote: > On 07/04/2011 21:20, Doug Barton wrote: >> On 07/04/2011 20:26, Michael Sinatra wrote: >>> On 07/04/11 19:59, Doug Barton wrote: >>>> If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I >>>> get an error using either /64 or /128 as the mask: >>>> >>>> ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 >>>> >>>> ifconfig 2001:a:b:c::2/64: bad value (width too large) >>>> >>>> There are no examples for IPv6 in the man page, or the handbook; and I >>>> can't find any on line. I'm interested in configuration for the command >>>> line, and rc.conf. >>> >>> ifconfig_carp0="vhid 80 advskew 120 pass yomama 128.32.206.100/32" >>> ipv6_ifconfig_carp0="2607:f140:ffff:ffff::80/128" >>> >>> Works on 8.2-STABLE (June 7, 2011). >>> >>> Note that I cannot get carp to work properly without configuring an IPv4 >>> address. > > I should point out that I was able to do the following: > > ifconfig carp2 *inet6* vhid 4 .... > > as above, and it "worked" in the sense that it configured the carp > interface, but subsequently my IPv6 network went straight into the > crapper. Hence, the statement that it won't work without an IPv4 address > seems to be correct. This seems pretty sub-optimal given the world we > currently live in ... Sorry, I was watching fireworks or I would have tipped you off on that one earlier. I was setting that config up as part of a talk I gave on building a redundant IPv6 web reverse-proxy for World IPv6 Day, which has some of the config snippets I just gave you. This was at the Internet2/ESCC Joint Techs meeting: http://www.internet2.edu/presentations/jt2011winter/20110202-sinatra-world-IPv6-day-LT.pdf The video for the talk can be seen here: http://events.internet2.edu/2011/jt-clemson/agenda.cfm?go=session&id=10001572&event=1150 Anyway, I had some trouble getting carp to work correctly between 8.x hosts and 7.x hosts (both sides claimed to be master), in addition to the IPv6 issue. I had meant to do some more troubleshooting after I returned from the talk, but I was in the process of changing jobs and a couple of the test servers at UCB are currently down and I need to get them back up. In other words, I haven't had the chance to troubleshoot these issues further, but I do know that you definitely need to configure IPv4 on the interface. michael From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 08:58:54 2011 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 990C2106566B; Tue, 5 Jul 2011 08:58:54 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 559FC8FC14; Tue, 5 Jul 2011 08:58:54 +0000 (UTC) Received: by iyb11 with SMTP id 11so6708244iyb.13 for ; Tue, 05 Jul 2011 01:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=7j/5aosWJ8VQUfASc2n+dY9naYDOa7M0kwB6AOehUh0=; b=BrpQGJmK1lJrZgoEkUQWblUjvZWIYackAlliDwxgEaVRAYV86cNtq8Rf8+HmjxP1pn 0H2zModok+0ZvMiSU0nEqnCjtqTlmlgnuonDdVWhGnOyTeLh6rkPZFYDcdk90aqOqNRv u0RBCCo9sa/WZJyILOIkso0tRaeU3VZbcsKyI= MIME-Version: 1.0 Received: by 10.42.19.69 with SMTP id a5mr7460614icb.69.1309854879009; Tue, 05 Jul 2011 01:34:39 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.171.148 with HTTP; Tue, 5 Jul 2011 01:34:38 -0700 (PDT) In-Reply-To: <4E12A1F3.1040302@rancid.berkeley.edu> References: <4E127E18.6090509@FreeBSD.org> <4E128477.6030108@rancid.berkeley.edu> <4E12911D.2060604@FreeBSD.org> <4E129312.4000709@FreeBSD.org> <4E12A1F3.1040302@rancid.berkeley.edu> Date: Tue, 5 Jul 2011 10:34:38 +0200 X-Google-Sender-Auth: uzd_ifKsOCrwazvnc6b6ZGxYs0Q Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Michael Sinatra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Doug Barton Subject: Re: carp for 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: Tue, 05 Jul 2011 08:58:54 -0000 On Tue, Jul 5, 2011 at 7:32 AM, Michael Sinatra wrote: > On 07/04/11 21:29, Doug Barton wrote: >> >> On 07/04/2011 21:20, Doug Barton wrote: >>> >>> On 07/04/2011 20:26, Michael Sinatra wrote: >>>> >>>> On 07/04/11 19:59, Doug Barton wrote: >>>>> >>>>> If I try to set up a carp interface for IPv6 on a recent 8.2-STABLE I >>>>> get an error using either /64 or /128 as the mask: >>>>> >>>>> ifconfig carp2 vhid 4 advskew 0 pass mycleverpass 2001:a:b:c::2/64 >>>>> >>>>> ifconfig 2001:a:b:c::2/64: bad value (width too large) >>>>> >>>>> There are no examples for IPv6 in the man page, or the handbook; and = I >>>>> can't find any on line. I'm interested in configuration for the comma= nd >>>>> line, and rc.conf. >>>> >>>> ifconfig_carp0=3D"vhid 80 advskew 120 pass yomama 128.32.206.100/32" >>>> ipv6_ifconfig_carp0=3D"2607:f140:ffff:ffff::80/128" >>>> >>>> Works on 8.2-STABLE (June 7, 2011). >>>> >>>> Note that I cannot get carp to work properly without configuring an IP= v4 >>>> address. >> >> I should point out that I was able to do the following: >> >> ifconfig carp2 *inet6* vhid 4 .... >> >> as above, and it "worked" in the sense that it configured the carp >> interface, but subsequently my IPv6 network went straight into the >> crapper. Hence, the statement that it won't work without an IPv4 address >> seems to be correct. This seems pretty sub-optimal given the world we >> currently live in ... > The carp_* patches in this repository https://github.com/bsdperimeter/pfsense-tools/tree/master/patches/RELENG_8_= 1 especially the livelock and ipalias one make it work for pfSense. > Sorry, I was watching fireworks or I would have tipped you off on that on= e > earlier. =A0I was setting that config up as part of a talk I gave on buil= ding > a redundant IPv6 web reverse-proxy for World IPv6 Day, which has some of = the > config snippets I just gave you. =A0This was at the Internet2/ESCC Joint = Techs > meeting: > > http://www.internet2.edu/presentations/jt2011winter/20110202-sinatra-worl= d-IPv6-day-LT.pdf > > The video for the talk can be seen here: > > http://events.internet2.edu/2011/jt-clemson/agenda.cfm?go=3Dsession&id=3D= 10001572&event=3D1150 > > Anyway, I had some trouble getting carp to work correctly between 8.x hos= ts > and 7.x hosts (both sides claimed to be master), in addition to the IPv6 > issue. =A0I had meant to do some more troubleshooting after I returned fr= om > the talk, but I was in the process of changing jobs and a couple of the t= est > servers at UCB are currently down and I need to get them back up. =A0In o= ther > words, I haven't had the chance to troubleshoot these issues further, but= I > do know that you definitely need to configure IPv4 on the interface. > > michael > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 10:10:59 2011 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 6000810656A5 for ; Tue, 5 Jul 2011 10:10:59 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id E48148FC27 for ; Tue, 5 Jul 2011 10:10:58 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 2F34916DDA3; Tue, 5 Jul 2011 13:10:52 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Tue, 5 Jul 2011 13:10:52 +0300 (EEST) Received: from [192.168.100.46] (PC46.ciurel100.stsnet.ro [192.168.100.46]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPSA id 07E8316DDA0; Tue, 5 Jul 2011 13:10:52 +0300 (EEST) Message-ID: <4E12E32C.4030607@stsnet.ro> Date: Tue, 05 Jul 2011 13:10:52 +0300 From: Adrian Minta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110522 Icedove/3.1.10 MIME-Version: 1.0 To: Eugene Grosbein References: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> <20110704191451.GA12372@rdtc.ru> In-Reply-To: <20110704191451.GA12372@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.169158, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 500(0), flags: [NN_LEGIT_SUMM_400_WORDS], SQMD: a8ea39e0dea21ee149a109d54edf1098.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38164 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 05 Jul 2011 10:10:59 -0000 A deeper debug of a failure looks like this: # grep "L28-6225" /var/log/mpd.log Jul 5 13:06:39 lns mpd: [L28-6225] L2TP: Incoming call #70 via control connection 0x80b7bfc10 accepted Jul 5 13:06:39 lns mpd: [L28-6225] Link: OPEN event Jul 5 13:06:39 lns mpd: [L28-6225] LCP: Open event Jul 5 13:06:39 lns mpd: [L28-6225] LCP: state change Initial --> Starting Jul 5 13:06:39 lns mpd: [L28-6225] LCP: LayerStart Jul 5 13:06:40 lns mpd: [L28-6225] L2TP: Call #70 connected Jul 5 13:06:40 lns mpd: [L28-6225] Link: UP event Jul 5 13:06:40 lns mpd: [L28-6225] LCP: Up event Jul 5 13:06:40 lns mpd: [L28-6225] LCP: state change Starting --> Req-Sent Jul 5 13:06:40 lns mpd: [L28-6225] LCP: SendConfigReq #1 Jul 5 13:06:42 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 (Req-Sent) Jul 5 13:06:42 lns mpd: [L28-6225] LCP: SendConfigAck #1 Jul 5 13:06:42 lns mpd: [L28-6225] LCP: state change Req-Sent --> Ack-Sent Jul 5 13:06:42 lns mpd: [L28-6225] LCP: SendConfigReq #2 Jul 5 13:06:43 lns mpd: [L28-6225] LCP: rec'd Configure Reject #4 (Ack-Sent) Jul 5 13:06:43 lns mpd: [L28-6225] Wrong id#, expecting 2 Jul 5 13:06:44 lns mpd: [L28-6225] LCP: SendConfigReq #3 Jul 5 13:06:46 lns mpd: [L28-6225] LCP: SendConfigReq #4 Jul 5 13:06:48 lns mpd: [L28-6225] LCP: SendConfigReq #5 Jul 5 13:06:48 lns mpd: [L28-6225] LCP: rec'd Configure Reject #5 (Ack-Sent) Jul 5 13:06:48 lns mpd: [L28-6225] LCP: SendConfigReq #6 Jul 5 13:06:49 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 5 13:06:49 lns mpd: [L28-6225] LCP: SendConfigAck #1 Jul 5 13:06:50 lns mpd: [L28-6225] LCP: SendConfigReq #7 Jul 5 13:06:52 lns mpd: [L28-6225] LCP: SendConfigReq #8 Jul 5 13:06:52 lns mpd: [L28-6225] LCP: rec'd Configure Reject #6 (Ack-Sent) Jul 5 13:06:52 lns mpd: [L28-6225] Wrong id#, expecting 8 Jul 5 13:06:54 lns mpd: [L28-6225] LCP: SendConfigReq #9 Jul 5 13:06:55 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 5 13:06:55 lns mpd: [L28-6225] LCP: SendConfigAck #1 Jul 5 13:06:56 lns mpd: [L28-6225] LCP: SendConfigReq #10 Jul 5 13:06:57 lns mpd: [L28-6225] LCP: rec'd Configure Reject #7 (Ack-Sent) Jul 5 13:06:57 lns mpd: [L28-6225] Wrong id#, expecting 10 Jul 5 13:06:58 lns mpd: [L28-6225] LCP: SendConfigReq #11 Jul 5 13:07:00 lns mpd: [L28-6225] LCP: SendConfigReq #12 Jul 5 13:07:02 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 (Ack-Sent) Jul 5 13:07:02 lns mpd: [L28-6225] LCP: SendConfigAck #1 Jul 5 13:07:02 lns mpd: [L28-6225] LCP: rec'd Configure Reject #8 (Ack-Sent) Jul 5 13:07:02 lns mpd: [L28-6225] Wrong id#, expecting 12 Jul 5 13:07:02 lns mpd: [L28-6225] LCP: SendConfigReq #13 Jul 5 13:07:04 lns mpd: [L28-6225] LCP: SendConfigReq #14 Jul 5 13:07:07 lns mpd: [L28-6225] LCP: SendConfigReq #15 Jul 5 13:07:07 lns mpd: [L28-6225] LCP: rec'd Configure Reject #9 (Ack-Sent) Jul 5 13:07:07 lns mpd: [L28-6225] Wrong id#, expecting 15 Jul 5 13:07:09 lns mpd: [L28-6225] LCP: parameter negotiation failed Jul 5 13:07:09 lns mpd: [L28-6225] LCP: state change Ack-Sent --> Stopped Jul 5 13:07:09 lns mpd: [L28-6225] LCP: LayerFinish Jul 5 13:07:09 lns mpd: [L28-6225] L2TP: Call #70 terminated locally Jul 5 13:07:09 lns mpd: [L28-6225] Link: DOWN event Jul 5 13:07:09 lns mpd: [L28-6225] LCP: Close event Jul 5 13:07:09 lns mpd: [L28-6225] LCP: state change Stopped --> Closed Jul 5 13:07:09 lns mpd: [L28-6225] LCP: Down event Jul 5 13:07:09 lns mpd: [L28-6225] LCP: state change Closed --> Initial Jul 5 13:07:09 lns mpd: [L28-6225] Link: SHUTDOWN event Jul 5 13:07:09 lns mpd: [L28-6225] Link: Shutdown -- Best regards, From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 11:28:49 2011 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 0AA63106566B; Tue, 5 Jul 2011 11:28:49 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id F257C8FC17; Tue, 5 Jul 2011 11:28:47 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p65BShUp020220; Tue, 5 Jul 2011 18:28:43 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E12F566.6000400@rdtc.ru> Date: Tue, 05 Jul 2011 18:28:38 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: <813678a855c90c49bf66c7084f88b45d.squirrel@mail.stsnet.ro> <20110704191451.GA12372@rdtc.ru> <4E12E32C.4030607@stsnet.ro> In-Reply-To: <4E12E32C.4030607@stsnet.ro> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Alexander Motin Subject: Re: FreeBSD 8.2 and MPD5 stability issues - update 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, 05 Jul 2011 11:28:49 -0000 05.07.2011 17:10, Adrian Minta wrote: CC'ing Alexander Motin, perhaps he knows why this happens in case of very high volume and rate of incoming connections. > A deeper debug of a failure looks like this: > > # grep "L28-6225" /var/log/mpd.log > Jul 5 13:06:39 lns mpd: [L28-6225] L2TP: Incoming call #70 via control > connection 0x80b7bfc10 accepted > Jul 5 13:06:39 lns mpd: [L28-6225] Link: OPEN event > Jul 5 13:06:39 lns mpd: [L28-6225] LCP: Open event > Jul 5 13:06:39 lns mpd: [L28-6225] LCP: state change Initial --> Starting > Jul 5 13:06:39 lns mpd: [L28-6225] LCP: LayerStart > Jul 5 13:06:40 lns mpd: [L28-6225] L2TP: Call #70 connected > Jul 5 13:06:40 lns mpd: [L28-6225] Link: UP event > Jul 5 13:06:40 lns mpd: [L28-6225] LCP: Up event > Jul 5 13:06:40 lns mpd: [L28-6225] LCP: state change Starting --> Req-Sent > Jul 5 13:06:40 lns mpd: [L28-6225] LCP: SendConfigReq #1 > Jul 5 13:06:42 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 > (Req-Sent) > Jul 5 13:06:42 lns mpd: [L28-6225] LCP: SendConfigAck #1 > Jul 5 13:06:42 lns mpd: [L28-6225] LCP: state change Req-Sent --> Ack-Sent > Jul 5 13:06:42 lns mpd: [L28-6225] LCP: SendConfigReq #2 > Jul 5 13:06:43 lns mpd: [L28-6225] LCP: rec'd Configure Reject #4 > (Ack-Sent) > Jul 5 13:06:43 lns mpd: [L28-6225] Wrong id#, expecting 2 > Jul 5 13:06:44 lns mpd: [L28-6225] LCP: SendConfigReq #3 > Jul 5 13:06:46 lns mpd: [L28-6225] LCP: SendConfigReq #4 > Jul 5 13:06:48 lns mpd: [L28-6225] LCP: SendConfigReq #5 > Jul 5 13:06:48 lns mpd: [L28-6225] LCP: rec'd Configure Reject #5 > (Ack-Sent) > Jul 5 13:06:48 lns mpd: [L28-6225] LCP: SendConfigReq #6 > Jul 5 13:06:49 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 > (Ack-Sent) > Jul 5 13:06:49 lns mpd: [L28-6225] LCP: SendConfigAck #1 > Jul 5 13:06:50 lns mpd: [L28-6225] LCP: SendConfigReq #7 > Jul 5 13:06:52 lns mpd: [L28-6225] LCP: SendConfigReq #8 > Jul 5 13:06:52 lns mpd: [L28-6225] LCP: rec'd Configure Reject #6 > (Ack-Sent) > Jul 5 13:06:52 lns mpd: [L28-6225] Wrong id#, expecting 8 > Jul 5 13:06:54 lns mpd: [L28-6225] LCP: SendConfigReq #9 > Jul 5 13:06:55 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 > (Ack-Sent) > Jul 5 13:06:55 lns mpd: [L28-6225] LCP: SendConfigAck #1 > Jul 5 13:06:56 lns mpd: [L28-6225] LCP: SendConfigReq #10 > Jul 5 13:06:57 lns mpd: [L28-6225] LCP: rec'd Configure Reject #7 > (Ack-Sent) > Jul 5 13:06:57 lns mpd: [L28-6225] Wrong id#, expecting 10 > Jul 5 13:06:58 lns mpd: [L28-6225] LCP: SendConfigReq #11 > Jul 5 13:07:00 lns mpd: [L28-6225] LCP: SendConfigReq #12 > Jul 5 13:07:02 lns mpd: [L28-6225] LCP: rec'd Configure Request #1 > (Ack-Sent) > Jul 5 13:07:02 lns mpd: [L28-6225] LCP: SendConfigAck #1 > Jul 5 13:07:02 lns mpd: [L28-6225] LCP: rec'd Configure Reject #8 > (Ack-Sent) > Jul 5 13:07:02 lns mpd: [L28-6225] Wrong id#, expecting 12 > Jul 5 13:07:02 lns mpd: [L28-6225] LCP: SendConfigReq #13 > Jul 5 13:07:04 lns mpd: [L28-6225] LCP: SendConfigReq #14 > Jul 5 13:07:07 lns mpd: [L28-6225] LCP: SendConfigReq #15 > Jul 5 13:07:07 lns mpd: [L28-6225] LCP: rec'd Configure Reject #9 > (Ack-Sent) > Jul 5 13:07:07 lns mpd: [L28-6225] Wrong id#, expecting 15 > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: parameter negotiation failed > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: state change Ack-Sent --> Stopped > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: LayerFinish > Jul 5 13:07:09 lns mpd: [L28-6225] L2TP: Call #70 terminated locally > Jul 5 13:07:09 lns mpd: [L28-6225] Link: DOWN event > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: Close event > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: state change Stopped --> Closed > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: Down event > Jul 5 13:07:09 lns mpd: [L28-6225] LCP: state change Closed --> Initial > Jul 5 13:07:09 lns mpd: [L28-6225] Link: SHUTDOWN event > Jul 5 13:07:09 lns mpd: [L28-6225] Link: Shutdown > > Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 11:56:36 2011 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 CD1091065672 for ; Tue, 5 Jul 2011 11:56:36 +0000 (UTC) (envelope-from mitya@cabletv.dp.ua) Received: from mail.cabletv.dp.ua (mail.cabletv.dp.ua [193.34.20.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8494A8FC0A for ; Tue, 5 Jul 2011 11:56:36 +0000 (UTC) Received: from [193.34.20.2] (helo=m18.cabletv.dp.ua) by mail.cabletv.dp.ua with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qe3f7-000BZg-V7 for freebsd-net@freebsd.org; Tue, 05 Jul 2011 14:19:29 +0300 Message-ID: <4E12F228.6020800@cabletv.dp.ua> Date: Tue, 05 Jul 2011 14:14:48 +0300 From: Mitya User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: IFF_RENAMING interface flag 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, 05 Jul 2011 11:56:36 -0000 Where I can see IFF_RENAMING interface flag ? /usr/include/net/if.h [skipped...] #define IFF_MONITOR 0x40000 /* (n) user-requested monitor mode */ #define IFF_STATICARP 0x80000 /* (n) static ARP */ #define IFF_DYING 0x200000 /* (n) interface is winding down */ #define IFF_RENAMING 0x400000 /* (n) interface is being renamed */ /usr/src/sbin/ifconfig/ifconfig.c [skipped...] #define IFFBITS \ "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ "\20MULTICAST\22PPROMISC\23MONITOR\24STATICARP" From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 13:29:00 2011 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 3FDC3106566B for ; Tue, 5 Jul 2011 13:29:00 +0000 (UTC) (envelope-from ndenev@gmail.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 CB88B8FC1A for ; Tue, 5 Jul 2011 13:28:59 +0000 (UTC) Received: by wwe6 with SMTP id 6so5745364wwe.31 for ; Tue, 05 Jul 2011 06:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/gjS6Uex2fRAhO1zhswJHBSdQi6niltTLQjlzEJSYzc=; b=AAic+tIqLAj2DzHD15v3kx+mFWrgZ8KzXWI9uBgzG9KUog4PSNorlOTpQIcKksqMVs aCWLfPsGOffnOSS24RFhIlBXEq9yBOHLTj7RwHCZlXjWejfwzyucdwcEqtJ30IwUZhMg ODLVdG7OvjMlttaViiYhLB7oeBnxSyarq6h2Q= Received: by 10.216.176.76 with SMTP id a54mr831953wem.112.1309871068293; Tue, 05 Jul 2011 06:04:28 -0700 (PDT) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com [217.18.249.148]) by mx.google.com with ESMTPS id l53sm3646161weq.47.2011.07.05.06.04.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 06:04:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <4E12F228.6020800@cabletv.dp.ua> Date: Tue, 5 Jul 2011 16:04:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E12F228.6020800@cabletv.dp.ua> To: Mitya X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: IFF_RENAMING interface flag 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, 05 Jul 2011 13:29:00 -0000 On Jul 5, 2011, at 2:14 PM, Mitya wrote: > Where I can see IFF_RENAMING interface flag ? >=20 > /usr/include/net/if.h >=20 > [skipped...] > #define IFF_MONITOR 0x40000 /* (n) user-requested monitor = mode */ > #define IFF_STATICARP 0x80000 /* (n) static ARP */ > #define IFF_DYING 0x200000 /* (n) interface is winding = down */ > #define IFF_RENAMING 0x400000 /* (n) interface is being = renamed */ >=20 >=20 > /usr/src/sbin/ifconfig/ifconfig.c > [skipped...] > #define IFFBITS \ > "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \ > = "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2= " \ > "\20MULTICAST\22PPROMISC\23MONITOR\24STATICARP" >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" That's because it's for internal use, same as IFF_DYING, which also = can't be seen with ifconfig Regards, Nikolay=20= From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 17:11:49 2011 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 140401065670 for ; Tue, 5 Jul 2011 17:11:49 +0000 (UTC) (envelope-from ports@subnets.ru) Received: from mail.mega-net.ru (mail.mega-net.ru [91.217.137.1]) by mx1.freebsd.org (Postfix) with SMTP id 302058FC08 for ; Tue, 5 Jul 2011 17:11:47 +0000 (UTC) Received: (qmail 29665 invoked from network); 5 Jul 2011 21:11:44 +0400 Received: from unknown [172.16.10.37] (HELO work-book.lehis.ru) by mail.mega-net.ru with ESMTP; 5 Jul 2011 21:11:44 +0400 Message-ID: <4E1345D1.5080903@subnets.ru> Date: Tue, 05 Jul 2011 21:11:45 +0400 From: "Alexey V. Panfilov" User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110704 Thunderbird/5.0 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E11A8D3.40102@subnets.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Netgraph udp tunneling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ports@subnets.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 17:11:49 -0000 05.07.2011 20:57, Arnaud Lacombe wrote: > Hi, > > 2011/7/4 Alexey V. Panfilov: >> Hi! >> >> We've three servers, connected as S1<-ng_tunnel-> S2<-ng_tunnel-> S3. >> >> Over tunnels runs BGP with full-view. >> >> Sometimes on S2 occures fatal trap with automatic reboot or without reboot >> at all. It not depends of net loading (mbps or pps). >> >> If process of save a core was successfull, backtrace always shows that fatal >> trap occures because of large packet (size around 60Kbyte) was received. >> >> >> Any help are welcome. Thanks. >> >> ---------------------------------------------------------------------- >> >> Info about S2: >> >> smbios.system.maker="IBM" >> smbios.system.product="System x3250 M3 -[425232G]-" >> hw.model: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz >> hw.physmem: 4207792128 >> dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 >> dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x1014 >> subdevice=0x03bd class=0x020000 >> >> NOTE: On S2 used only em0 >> >> /etc/sysctl.conf: >> net.inet.icmp.icmplim=50 >> net.inet.tcp.blackhole=2 >> net.inet.udp.blackhole=1 >> net.inet.icmp.drop_redirect=1 >> net.inet.icmp.log_redirect=0 >> net.inet.ip.redirect=0 >> >> Netgraph's tunnels are configured such as it wrote at example >> (/usr/share/examples/netgraph/udp.tunnel): >> >> ngctl mkpeer iface dummy inet >> ngctl mkpeer ng0: ksocket inet inet/dgram/udp >> ngctl name ng0:inet to_S1 >> ngctl msg ng0:inet bind inet/1.1.1.1:60001 >> ngctl msg ng0:inet connect inet/5.5.5.5:60001 >> ifconfig ng0 10.0.0.1 10.0.0.2 netmask 255.255.255.252 >> >> ngctl mkpeer iface dummy inet >> ngctl mkpeer ng1: ksocket inet inet/dgram/udp >> ngctl name ng1:inet to_S3 >> ngctl msg ng1:inet bind inet/1.1.1.3:60002 >> ngctl msg ng1:inet connect inet/7.7.7.7:60002 >> ifconfig ng1 10.0.0.5 10.0.0.6 netmask 255.255.255.252 >> >> FreeBSD S2.line 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #1: Wed Jun 22 >> 13:56:26 MSD 2011 root@S2.line:/usr/src/sys/amd64/compile/BGP amd64 >> >> Hardware and software configurations on S1 and S3 are identical to S2, but >> they runs without problem. >> >> ------------------------------------------------------------------------ >> >> backtrace: >> >> Unread portion of the kernel message buffer: >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 3; apic id = 05 >> fault virtual address = 0x18 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff803f4a87 >> stack pointer = 0x28:0xffffff811c80a5a0 >> frame pointer = 0x28:0xffffff811c80a600 >> 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 = 1478 (ng_queue0) >> trap number = 12 >> panic: page fault >> cpuid = 3 >> Uptime: 11d23h7m40s >> Physical memory: 4012 MB >> Dumping 674 MB: 659 643 627 611 595 579 563 547 531 515 499 483 467 451 435 >> 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 131 >> 115 99 83 67 51 35 19 3 >> >> Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from >> /boot/kernel/coretemp.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/coretemp.ko >> Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from >> /boot/kernel/ng_socket.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/ng_socket.ko >> Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from >> /boot/kernel/netgraph.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/netgraph.ko >> Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from >> /boot/kernel/ng_iface.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/ng_iface.ko >> Reading symbols from /boot/kernel/ng_ksocket.ko...Reading symbols from >> /boot/kernel/ng_ksocket.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/ng_ksocket.ko >> #0 doadump () at pcpu.h:224 >> 224 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) bt >> #0 doadump () at pcpu.h:224 >> #1 0xffffffff80398d3e in boot (howto=260) at >> ../../../kern/kern_shutdown.c:419 >> #2 0xffffffff80399153 in panic (fmt=0x0) at >> ../../../kern/kern_shutdown.c:592 >> #3 0xffffffff8056f19d in trap_fatal (frame=0xffffff00070828c0, eva=Variable >> "eva" is not available. >> ) at ../../../amd64/amd64/trap.c:783 >> #4 0xffffffff8056f55f in trap_pfault (frame=0xffffff811c80a4f0, usermode=0) >> at ../../../amd64/amd64/trap.c:699 >> #5 0xffffffff8056f95f in trap (frame=0xffffff811c80a4f0) at >> ../../../amd64/amd64/trap.c:449 >> #6 0xffffffff80557ba4 in calltrap () at >> ../../../amd64/amd64/exception.S:224 >> #7 0xffffffff803f4a87 in m_copym (m=0x0, off0=2980, len=1480, wait=1) at >> ../../../kern/uipc_mbuf.c:542 > obviously enough, m_copym() does not like to be passed a NULL mbuf :) > Can you help detect why it happens? > - Arnaud > >> #8 0xffffffff8047fc07 in ip_fragment (ip=0xffffff010e8d0558, >> m_frag=0xffffff811c80a718, mtu=Variable "mtu" is not available. >> ) at ../../../netinet/ip_output.c:819 >> #9 0xffffffff80480d1f in ip_output (m=0xffffff010e8d0500, opt=Variable >> "opt" is not available. >> ) at ../../../netinet/ip_output.c:650 >> #10 0xffffffff8047ca00 in ip_forward (m=0xffffff010e317600, srcrt=Variable >> "srcrt" is not available. >> ) at ../../../netinet/ip_input.c:1521 >> #11 0xffffffff8047e1cd in ip_input (m=0xffffff010e317600) at >> ../../../netinet/ip_input.c:729 >> #12 0xffffffff8044eebe in netisr_dispatch_src (proto=1, source=Variable >> "source" is not available. >> ) at ../../../net/netisr.c:917 >> #13 0xffffffff80a2dd76 in ng_linkinfo_type_fields () from >> /boot/kernel/netgraph.ko >> #14 0xffffffff80a26ae0 in ng_path2noderef (here=Variable "here" is not >> available. >> ) at netgraph.h:463 >> #15 0xffffffff80a25bee in ng_worklist_add (node=0xffffff016abda168) at >> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3378 >> #16 0xffffffff80a30339 in ng_namehash_mtx () from /boot/kernel/netgraph.ko >> #17 0xffffffff80a26be0 in ng_path2noderef (here=0xffffff002dd93c00, >> address=Variable "address" is not available. >> ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1773 >> #18 0xffffffff80a27ceb in ng_apply_item (node=0x246, >> item=0xffffff002dd93c70, rw=0) at >> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2613 >> #19 0xffffffff8036ff68 in fork_exit (callout=0xffffffff80a27b80 >> , arg=0x0, frame=0xffffff811c80ac40) at >> ../../../kern/kern_fork.c:845 >> #20 0xffffffff8055806e in fork_trampoline () at >> ../../../amd64/amd64/exception.S:565 >> #21 0x0000000000000000 in ?? () >> #22 0x0000000000000000 in ?? () >> #23 0x0000000000000001 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 0x0000000000000000 in ?? () >> #43 0x0000000000000000 in ?? () >> #44 0x0000000000000000 in ?? () >> #45 0xffffffff807cce40 in affinity () >> #46 0x0000000000000000 in ?? () >> #47 0x0000000000000000 in ?? () >> #48 0xffffff0001efa000 in ?? () >> #49 0xffffff811c809c80 in ?? () >> #50 0xffffff811c809c28 in ?? () >> #51 0xffffff0001d20460 in ?? () >> #52 0xffffffff803be5f9 in sched_switch (td=0xffffffff80a27b80, newtd=0x0, >> flags=Variable "flags" is not available. >> ) at ../../../kern/sched_ule.c:1852 >> Previous frame inner to this frame (corrupt stack?) -- Simple Lehisnoe ;-) From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 17:26:54 2011 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 4E7FE106564A for ; Tue, 5 Jul 2011 17:26:54 +0000 (UTC) (envelope-from lacombar@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 2B87E8FC0C for ; Tue, 5 Jul 2011 17:26:53 +0000 (UTC) Received: by pzk27 with SMTP id 27so4396381pzk.13 for ; Tue, 05 Jul 2011 10:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mF6+tp/VoYIecvc3aTm9lQS78iOiRrP9qIUrLPuUD2M=; b=Vutdm2YOTo9Ab+ZLtG+hitZH7WgMU8jtotfansenc40vZDKsvNahxWhWU/z8iGhL1i 8D4xu4SLO773g+0L9gsx4pbmdk04rXJH6itIgVrbuFmRJ9Dw2DTjBplJEZAntMA1q4L/ x816C0DcrVuy7tq7fmKqiuMJpX15GbKajvXdQ= MIME-Version: 1.0 Received: by 10.68.48.68 with SMTP id j4mr3496677pbn.407.1309885040575; Tue, 05 Jul 2011 09:57:20 -0700 (PDT) Received: by 10.68.64.200 with HTTP; Tue, 5 Jul 2011 09:57:20 -0700 (PDT) In-Reply-To: <4E11A8D3.40102@subnets.ru> References: <4E11A8D3.40102@subnets.ru> Date: Tue, 5 Jul 2011 12:57:20 -0400 Message-ID: From: Arnaud Lacombe To: ports@subnets.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Netgraph udp tunneling 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, 05 Jul 2011 17:26:54 -0000 Hi, 2011/7/4 Alexey V. Panfilov : > Hi! > > We've three servers, connected as S1 <-ng_tunnel-> S2 <-ng_tunnel-> S3. > > Over tunnels runs BGP with full-view. > > Sometimes on S2 occures fatal trap with automatic reboot or without reboo= t > at all. It not depends of net loading (mbps or pps). > > If process of save a core was successfull, backtrace always shows that fa= tal > trap occures because of large packet (size around 60Kbyte) was received. > > > Any help are welcome. Thanks. > > ---------------------------------------------------------------------- > > Info about S2: > > smbios.system.maker=3D"IBM" > smbios.system.product=3D"System x3250 M3 -[425232G]-" > hw.model: Intel(R) Core(TM) i3 CPU =A0 =A0 =A0 =A0 530 =A0@ 2.93GHz > hw.physmem: 4207792128 > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.1.9 > dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x10d3 subvendor=3D0x1014 > subdevice=3D0x03bd class=3D0x020000 > > NOTE: On S2 used only em0 > > /etc/sysctl.conf: > net.inet.icmp.icmplim=3D50 > net.inet.tcp.blackhole=3D2 > net.inet.udp.blackhole=3D1 > net.inet.icmp.drop_redirect=3D1 > net.inet.icmp.log_redirect=3D0 > net.inet.ip.redirect=3D0 > > Netgraph's tunnels are configured such as it wrote at example > (/usr/share/examples/netgraph/udp.tunnel): > > ngctl mkpeer iface dummy inet > ngctl mkpeer ng0: ksocket inet inet/dgram/udp > ngctl name ng0:inet to_S1 > ngctl msg ng0:inet bind inet/1.1.1.1:60001 > ngctl msg ng0:inet connect inet/5.5.5.5:60001 > ifconfig ng0 10.0.0.1 10.0.0.2 netmask 255.255.255.252 > > ngctl mkpeer iface dummy inet > ngctl mkpeer ng1: ksocket inet inet/dgram/udp > ngctl name ng1:inet to_S3 > ngctl msg ng1:inet bind inet/1.1.1.3:60002 > ngctl msg ng1:inet connect inet/7.7.7.7:60002 > ifconfig ng1 10.0.0.5 10.0.0.6 netmask 255.255.255.252 > > FreeBSD S2.line 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #1: Wed Jun 22 > 13:56:26 MSD 2011 =A0 =A0 root@S2.line:/usr/src/sys/amd64/compile/BGP =A0= amd64 > > Hardware and software configurations on S1 and S3 are identical to S2, bu= t > they runs without problem. > > ------------------------------------------------------------------------ > > backtrace: > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 3; apic id =3D 05 > fault virtual address =A0 =3D 0x18 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not = present > instruction pointer =A0 =A0 =3D 0x20:0xffffffff803f4a87 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff811c80a5a0 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff811c80a600 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 1478 (ng_queue0) > trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 > panic: page fault > cpuid =3D 3 > Uptime: 11d23h7m40s > Physical memory: 4012 MB > Dumping 674 MB: 659 643 627 611 595 579 563 547 531 515 499 483 467 451 4= 35 > 419 403 387 371 355 339 323 307 291 275 259 243 227 211 195 179 163 147 1= 31 > 115 99 83 67 51 35 19 3 > > Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from > /boot/kernel/coretemp.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from > /boot/kernel/ng_socket.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ng_socket.ko > Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from > /boot/kernel/netgraph.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/netgraph.ko > Reading symbols from /boot/kernel/ng_iface.ko...Reading symbols from > /boot/kernel/ng_iface.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ng_iface.ko > Reading symbols from /boot/kernel/ng_ksocket.ko...Reading symbols from > /boot/kernel/ng_ksocket.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ng_ksocket.ko > #0 =A0doadump () at pcpu.h:224 > 224 =A0 =A0 pcpu.h: No such file or directory. > =A0 =A0 =A0 =A0in pcpu.h > (kgdb) bt > #0 =A0doadump () at pcpu.h:224 > #1 =A00xffffffff80398d3e in boot (howto=3D260) at > ../../../kern/kern_shutdown.c:419 > #2 =A00xffffffff80399153 in panic (fmt=3D0x0) at > ../../../kern/kern_shutdown.c:592 > #3 =A00xffffffff8056f19d in trap_fatal (frame=3D0xffffff00070828c0, eva= =3DVariable > "eva" is not available. > ) at ../../../amd64/amd64/trap.c:783 > #4 =A00xffffffff8056f55f in trap_pfault (frame=3D0xffffff811c80a4f0, user= mode=3D0) > at ../../../amd64/amd64/trap.c:699 > #5 =A00xffffffff8056f95f in trap (frame=3D0xffffff811c80a4f0) at > ../../../amd64/amd64/trap.c:449 > #6 =A00xffffffff80557ba4 in calltrap () at > ../../../amd64/amd64/exception.S:224 > #7 =A00xffffffff803f4a87 in m_copym (m=3D0x0, off0=3D2980, len=3D1480, wa= it=3D1) at > ../../../kern/uipc_mbuf.c:542 obviously enough, m_copym() does not like to be passed a NULL mbuf :) - Arnaud > #8 =A00xffffffff8047fc07 in ip_fragment (ip=3D0xffffff010e8d0558, > m_frag=3D0xffffff811c80a718, mtu=3DVariable "mtu" is not available. > ) at ../../../netinet/ip_output.c:819 > #9 =A00xffffffff80480d1f in ip_output (m=3D0xffffff010e8d0500, opt=3DVari= able > "opt" is not available. > ) at ../../../netinet/ip_output.c:650 > #10 0xffffffff8047ca00 in ip_forward (m=3D0xffffff010e317600, srcrt=3DVar= iable > "srcrt" is not available. > ) at ../../../netinet/ip_input.c:1521 > #11 0xffffffff8047e1cd in ip_input (m=3D0xffffff010e317600) at > ../../../netinet/ip_input.c:729 > #12 0xffffffff8044eebe in netisr_dispatch_src (proto=3D1, source=3DVariab= le > "source" is not available. > ) at ../../../net/netisr.c:917 > #13 0xffffffff80a2dd76 in ng_linkinfo_type_fields () from > /boot/kernel/netgraph.ko > #14 0xffffffff80a26ae0 in ng_path2noderef (here=3DVariable "here" is not > available. > ) at netgraph.h:463 > #15 0xffffffff80a25bee in ng_worklist_add (node=3D0xffffff016abda168) at > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3378 > #16 0xffffffff80a30339 in ng_namehash_mtx () from /boot/kernel/netgraph.k= o > #17 0xffffffff80a26be0 in ng_path2noderef (here=3D0xffffff002dd93c00, > address=3DVariable "address" is not available. > ) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1= 773 > #18 0xffffffff80a27ceb in ng_apply_item (node=3D0x246, > item=3D0xffffff002dd93c70, rw=3D0) at > /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2613 > #19 0xffffffff8036ff68 in fork_exit (callout=3D0xffffffff80a27b80 > , arg=3D0x0, frame=3D0xffffff811c80ac40) at > ../../../kern/kern_fork.c:845 > #20 0xffffffff8055806e in fork_trampoline () at > ../../../amd64/amd64/exception.S:565 > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000001 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 0x0000000000000000 in ?? () > #43 0x0000000000000000 in ?? () > #44 0x0000000000000000 in ?? () > #45 0xffffffff807cce40 in affinity () > #46 0x0000000000000000 in ?? () > #47 0x0000000000000000 in ?? () > #48 0xffffff0001efa000 in ?? () > #49 0xffffff811c809c80 in ?? () > #50 0xffffff811c809c28 in ?? () > #51 0xffffff0001d20460 in ?? () > #52 0xffffffff803be5f9 in sched_switch (td=3D0xffffffff80a27b80, newtd=3D= 0x0, > flags=3DVariable "flags" is not available. > ) at ../../../kern/sched_ule.c:1852 > Previous frame inner to this frame (corrupt stack?) > > -- > Simple Lehisnoe ;-) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 22:23:39 2011 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 F317C1065677; Tue, 5 Jul 2011 22:23:38 +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 CCBC78FC20; Tue, 5 Jul 2011 22:23:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p65MNcVQ030440; Tue, 5 Jul 2011 22:23:38 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p65MNcYm030436; Tue, 5 Jul 2011 22:23:38 GMT (envelope-from linimon) Date: Tue, 5 Jul 2011 22:23:38 GMT Message-Id: <201107052223.p65MNcYm030436@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158665: [ip6] [panic] kernel pagefault in in6_setscope() 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, 05 Jul 2011 22:23:39 -0000 Old Synopsis: kernel pagefault in in6_setscope() New Synopsis: [ip6] [panic] kernel pagefault in in6_setscope() Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jul 5 22:23:14 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158665 From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 22:41:49 2011 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 CE4491065674 for ; Tue, 5 Jul 2011 22:41:49 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 998B78FC0A for ; Tue, 5 Jul 2011 22:41:49 +0000 (UTC) Received: (qmail 32906 invoked by uid 0); 5 Jul 2011 22:41:48 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jul 2011 22:41:48 -0000 Received: (qmail 32900 invoked by uid 90); 5 Jul 2011 22:41:48 -0000 Received: from unknown (HELO freemac) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Jul 2011 22:41:48 -0000 Date: Tue, 5 Jul 2011 18:41:47 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: freebsd-net@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: bce packet loss 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, 05 Jul 2011 22:41:49 -0000 Just adding a bit more information inline: On Mon, 4 Jul 2011, Charles Sprickman wrote: > Hello, > > We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) > and I'm seeing occasional packet loss on them (enough that it trips nagios > now and then). Cabling seems fine as neither the switch nor the sysctl info > for the device show any errors/collisions/etc, however there is one odd one, > which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below for full > sysctl output. The switch shows no errors but for "Dropped packets 683868". > > pciconf output is also below. [2] > > By default, the switch had flow control set to "on". I also let it run with > "auto". In both cases, the drops continued to increment. I'm now running > with flow control off to see if that changes anything. With flow control set to "off" on the switch I am still seeing dropped packets. The number shown by the switch after resetting the counters tracks "dev.bce.1.stat_IfHCInBadOctets" very closely. Neither the switch nor the host (in netstat) are reporting any errors, collisions, etc. I'm seeing less correlation between cpu utilization and drops, which is unfortunate. In fact, looking at all the graphs I have, such as disk activity, system load, traffic on the interface and a handful of others, I'm seeing no strong correlation in the last 24 hours or so between any system activity and the drops. Google isn't turn up much more than source code hits on "stat_IfHCInBadOctets", and from what I can tell, this is something that's just reading something off the card, so I'm having little luck figuring out just what a "bad octet" is in this context. Thanks, Charles > I do see some correlation between cpu usage and drops - I have cpu usage > graphed in nagios and cacti is graphing the drops on the dell switch. There's > no signs of running out of mbufs or similar. > > So given that limited info, is there anything I can look at to track this > down? Anything stand out in the stats sysctl exposes? Two things are > standing out for me - the number of changes in bce regarding flow control > that are not in 8.1, and the correlation between cpu load and the drops. > > What other information can I provide? > > Thanks, > > Charles > > [1] [root@h23 /home/spork]# sysctl -a |grep bce.1 > dev.bce.1.%desc: Broadcom NetXtreme II BCM5716 1000Base-T (C0) > dev.bce.1.%driver: bce > dev.bce.1.%location: slot=0 function=1 > dev.bce.1.%pnpinfo: vendor=0x14e4 device=0x163b subvendor=0x1028 > subdevice=0x02f1 class=0x020000 > dev.bce.1.%parent: pci1 > dev.bce.1.l2fhdr_error_count: 0 > dev.bce.1.mbuf_alloc_failed_count: 282 > dev.bce.1.fragmented_mbuf_count: 2748 > dev.bce.1.dma_map_addr_rx_failed_count: 0 > dev.bce.1.dma_map_addr_tx_failed_count: 5 > dev.bce.1.unexpected_attention_count: 0 > dev.bce.1.stat_IfHcInOctets: 62708651108 > dev.bce.1.stat_IfHCInBadOctets: 539369 > dev.bce.1.stat_IfHCOutOctets: 434264587173 > dev.bce.1.stat_IfHCOutBadOctets: 0 > dev.bce.1.stat_IfHCInUcastPkts: 533441918 > dev.bce.1.stat_IfHCInMulticastPkts: 3108746 > dev.bce.1.stat_IfHCInBroadcastPkts: 1314905 > dev.bce.1.stat_IfHCOutUcastPkts: 640961970 > dev.bce.1.stat_IfHCOutMulticastPkts: 26 > dev.bce.1.stat_IfHCOutBroadcastPkts: 8909 > dev.bce.1.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 > dev.bce.1.stat_Dot3StatsCarrierSenseErrors: 0 > dev.bce.1.stat_Dot3StatsFCSErrors: 0 > dev.bce.1.stat_Dot3StatsAlignmentErrors: 0 > dev.bce.1.stat_Dot3StatsSingleCollisionFrames: 0 > dev.bce.1.stat_Dot3StatsMultipleCollisionFrames: 0 > dev.bce.1.stat_Dot3StatsDeferredTransmissions: 0 > dev.bce.1.stat_Dot3StatsExcessiveCollisions: 0 > dev.bce.1.stat_Dot3StatsLateCollisions: 0 > dev.bce.1.stat_EtherStatsCollisions: 0 > dev.bce.1.stat_EtherStatsFragments: 0 > dev.bce.1.stat_EtherStatsJabbers: 0 > dev.bce.1.stat_EtherStatsUndersizePkts: 0 > dev.bce.1.stat_EtherStatsOversizePkts: 0 > dev.bce.1.stat_EtherStatsPktsRx64Octets: 34048797 > dev.bce.1.stat_EtherStatsPktsRx65Octetsto127Octets: 431844366 > dev.bce.1.stat_EtherStatsPktsRx128Octetsto255Octets: 25946173 > dev.bce.1.stat_EtherStatsPktsRx256Octetsto511Octets: 39936369 > dev.bce.1.stat_EtherStatsPktsRx512Octetsto1023Octets: 2296565 > dev.bce.1.stat_EtherStatsPktsRx1024Octetsto1522Octets: 3931392 > dev.bce.1.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 > dev.bce.1.stat_EtherStatsPktsTx64Octets: 60122571 > dev.bce.1.stat_EtherStatsPktsTx65Octetsto127Octets: 221041349 > dev.bce.1.stat_EtherStatsPktsTx128Octetsto255Octets: 40177071 > dev.bce.1.stat_EtherStatsPktsTx256Octetsto511Octets: 24099944 > dev.bce.1.stat_EtherStatsPktsTx512Octetsto1023Octets: 44493532 > dev.bce.1.stat_EtherStatsPktsTx1024Octetsto1522Octets: 251036438 > dev.bce.1.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 > dev.bce.1.stat_XonPauseFramesReceived: 61778 > dev.bce.1.stat_XoffPauseFramesReceived: 76315 > dev.bce.1.stat_OutXonSent: 0 > dev.bce.1.stat_OutXoffSent: 0 > dev.bce.1.stat_FlowControlDone: 0 > dev.bce.1.stat_MacControlFramesReceived: 0 > dev.bce.1.stat_XoffStateEntered: 0 > dev.bce.1.stat_IfInFramesL2FilterDiscards: 145832 > dev.bce.1.stat_IfInRuleCheckerDiscards: 0 > dev.bce.1.stat_IfInFTQDiscards: 0 > dev.bce.1.stat_IfInMBUFDiscards: 0 > dev.bce.1.stat_IfInRuleCheckerP4Hit: 4448215 > dev.bce.1.stat_CatchupInRuleCheckerDiscards: 0 > dev.bce.1.stat_CatchupInFTQDiscards: 0 > dev.bce.1.stat_CatchupInMBUFDiscards: 0 > dev.bce.1.stat_CatchupInRuleCheckerP4Hit: 0 > dev.bce.1.com_no_buffers: 0 > > [2] pciconf -lvb > bce1@pci0:1:0:1: class=0x020000 card=0x02f11028 chip=0x163b14e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xdc000000, size 33554432, > enabled > From owner-freebsd-net@FreeBSD.ORG Tue Jul 5 23:48:44 2011 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 642ED106566C for ; Tue, 5 Jul 2011 23:48:44 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 4D8F08FC25 for ; Tue, 5 Jul 2011 23:48:44 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp029.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNV00KL4U0IE740@asmtp029.mac.com> for freebsd-net@freebsd.org; Tue, 05 Jul 2011 15:48:18 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-05_08:2011-07-05, 2011-07-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107050208 From: Chuck Swiger In-reply-to: Date: Tue, 05 Jul 2011 15:48:18 -0700 Message-id: References: To: Charles Sprickman X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: bce packet loss 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, 05 Jul 2011 23:48:44 -0000 On Jul 4, 2011, at 6:32 PM, Charles Sprickman wrote: > We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) and I'm seeing occasional packet loss on them (enough that it trips nagios now and then). Cabling seems fine as neither the switch nor the sysctl info for the device show any errors/collisions/etc, however there is one odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below for full sysctl output. The switch shows no errors but for "Dropped packets 683868". A quick check of the #'s is showing an error rate of 8.6e-6, or about one byte out of 100,000. That's much better than what TCP/IP and ethernet were designed for. At a guess, your box or the switch occasionally gets busy enough that it drops a few packets now and again. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 09:08:37 2011 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 4E3F9106566B; Wed, 6 Jul 2011 09:08:37 +0000 (UTC) (envelope-from fazaeli@sepehrs.com) Received: from sepehrs.com (sepehrs.com [213.217.59.98]) by mx1.freebsd.org (Postfix) with ESMTP id C578E8FC17; Wed, 6 Jul 2011 09:08:35 +0000 (UTC) Received: from [127.0.0.1] ([192.168.3.10]) by sepehrs.com (8.14.3/8.14.3) with ESMTP id p668Pufv033515; Wed, 6 Jul 2011 12:55:56 +0430 (IRDT) Message-ID: <4E141D01.3040203@sepehrs.com> Date: Wed, 06 Jul 2011 12:59:53 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mike Tancsa References: <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> <4D4F3497.6050505@sentex.net> In-Reply-To: <4D4F3497.6050505@sentex.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Sean Bruno , Jan Koum , Ivan Voras Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 06 Jul 2011 09:08:37 -0000 Can you pls. share the patch for freebsd 7? On 2/7/2011 3:23 AM, Mike Tancsa wrote: > So far so good. I would often get a hang on the level zero dumps to my > backup server Sunday AM, and it made it through! So a good sign, but > not a definitive sign. > > I have a PCIe em card that has this chipset as well and was showing the > same sort of problem in a customer's RELENG_7 box. I will see if I can > get the customer to try the card in their box with the patch for > RELENG_7 as it would show this issue at least once a day until I pulled > the card for an older version > > ---Mike > > > On 2/4/2011 1:12 PM, Jack Vogel wrote: >> Was curious too, but being more patient than you :) >> >> Jack >> >> >> On Fri, Feb 4, 2011 at 10:09 AM, Sean Bruno wrote: >> >>> Any more data on this problem or do we have to wait a while? >>> >>> Sean >>> >>> >>> On Wed, 2011-02-02 at 10:28 -0800, Mike Tancsa wrote: >>>> On 2/2/2011 12:37 PM, Jack Vogel wrote: >>>>> So has everyone that wanted to get something testing been able to do >>> so? >>>> I have been testing in the back and will deploy to my production box >>>> this afternoon. As I am not able to reproduce it easily, it will be a >>>> bit before I can say the issue is gone. Jan however, was able to >>>> trigger it with greater ease ? >>>> >>>> ---Mike >>>> >>>>> Jack >>>>> >>>>> >>>>> On Tue, Feb 1, 2011 at 7:03 PM, Mike Tancsa wrote: >>>>> >>>>>> On 2/1/2011 5:03 PM, Sean Bruno wrote: >>>>>>> On Tue, 2011-02-01 at 13:43 -0800, Jack Vogel wrote: >>>>>>>> To those who are going to test, here is the if_em.c, based on head, >>>>>>>> with my >>>>>>>> changes, I have to leave for the afternoon, and have not had a >>> chance >>>>>>>> to build >>>>>>>> this, but it should work. I will check back in the later evening. >>>>>>>> >>>>>>>> Any blatant problems Sean, feel free to fix them :) >>>>>>>> >>>>>>>> Jack >>>>>>>> >>>>>>> >>>>>>> I suspect that line 1490 should be: >>>>>>> if (more_rx || (ifp->if_drv_flags& IFF_DRV_OACTIVE)) { >>>>>>> >>>>>> >>>>>> I have hacked up a RELENG_8 version which I think is correct including >>>>>> the above change >>>>>> >>>>>> http://www.tancsa.com/if_em-8.c >>>>>> >>>>>> >>>>>> >>>>>> --- if_em.c.orig 2011-02-01 21:47:14.000000000 -0500 >>>>>> +++ if_em.c 2011-02-01 21:47:19.000000000 -0500 >>>>>> @@ -30,7 +30,7 @@ >>>>>> POSSIBILITY OF SUCH DAMAGE. >>>>>> >>>>>> >>>>>> >>> ******************************************************************************/ >>>>>> -/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.20 2011/01/22 01:37:53 >>>>>> jfv Exp $*/ >>>>>> +/*$FreeBSD$*/ >>>>>> >>>>>> #ifdef HAVE_KERNEL_OPTION_HEADERS >>>>>> #include "opt_device_polling.h" >>>>>> @@ -93,7 +93,7 @@ >>>>>> >>> /********************************************************************* >>>>>> * Driver version: >>>>>> >>> *********************************************************************/ >>>>>> -char em_driver_version[] = "7.1.9"; >>>>>> +char em_driver_version[] = "7.1.9-test"; >>>>>> >>>>>> >>> /********************************************************************* >>>>>> * PCI Device ID Table >>>>>> @@ -927,11 +927,10 @@ >>>>>> if (!adapter->link_active) >>>>>> return; >>>>>> >>>>>> - /* Call cleanup if number of TX descriptors low */ >>>>>> - if (txr->tx_avail<= EM_TX_CLEANUP_THRESHOLD) >>>>>> - em_txeof(txr); >>>>>> - >>>>>> while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { >>>>>> + /* First cleanup if TX descriptors low */ >>>>>> + if (txr->tx_avail<= EM_TX_CLEANUP_THRESHOLD) >>>>>> + em_txeof(txr); >>>>>> if (txr->tx_avail< EM_MAX_SCATTER) { >>>>>> ifp->if_drv_flags |= IFF_DRV_OACTIVE; >>>>>> break; >>>>>> @@ -1411,8 +1410,7 @@ >>>>>> if (!drbr_empty(ifp, txr->br)) >>>>>> em_mq_start_locked(ifp, txr, NULL); >>>>>> #else >>>>>> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>>>>> - em_start_locked(ifp, txr); >>>>>> + em_start_locked(ifp, txr); >>>>>> #endif >>>>>> EM_TX_UNLOCK(txr); >>>>>> >>>>>> @@ -1475,11 +1473,10 @@ >>>>>> struct ifnet *ifp = adapter->ifp; >>>>>> struct tx_ring *txr = adapter->tx_rings; >>>>>> struct rx_ring *rxr = adapter->rx_rings; >>>>>> - bool more; >>>>>> - >>>>>> >>>>>> if (ifp->if_drv_flags& IFF_DRV_RUNNING) { >>>>>> - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); >>>>>> + bool more_rx; >>>>>> + more_rx = em_rxeof(rxr, adapter->rx_process_limit, >>> NULL); >>>>>> EM_TX_LOCK(txr); >>>>>> em_txeof(txr); >>>>>> @@ -1487,12 +1484,10 @@ >>>>>> if (!drbr_empty(ifp, txr->br)) >>>>>> em_mq_start_locked(ifp, txr, NULL); >>>>>> #else >>>>>> - if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>>>>> - em_start_locked(ifp, txr); >>>>>> + em_start_locked(ifp, txr); >>>>>> #endif >>>>>> - em_txeof(txr); >>>>>> EM_TX_UNLOCK(txr); >>>>>> - if (more) { >>>>>> + if (more_rx || (ifp->if_drv_flags& IFF_DRV_OACTIVE)) >>> { >>>>>> taskqueue_enqueue(adapter->tq, >>> &adapter->que_task); >>>>>> return; >>>>>> } >>>>>> @@ -1604,7 +1599,6 @@ >>>>>> if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) >>>>>> em_start_locked(ifp, txr); >>>>>> #endif >>>>>> - em_txeof(txr); >>>>>> E1000_WRITE_REG(&adapter->hw, E1000_IMS, txr->ims); >>>>>> EM_TX_UNLOCK(txr); >>>>>> } >>>>>> @@ -3730,17 +3724,17 @@ >>>>>> txr->queue_status = EM_QUEUE_HUNG; >>>>>> >>>>>> /* >>>>>> - * If we have enough room, clear IFF_DRV_OACTIVE >>>>>> + * If we have a minimum free, clear IFF_DRV_OACTIVE >>>>>> * to tell the stack that it is OK to send packets. >>>>>> */ >>>>>> - if (txr->tx_avail> EM_TX_CLEANUP_THRESHOLD) { >>>>>> + if (txr->tx_avail> EM_MAX_SCATTER) >>>>>> ifp->if_drv_flags&= ~IFF_DRV_OACTIVE; >>>>>> - /* Disable watchdog if all clean */ >>>>>> - if (txr->tx_avail == adapter->num_tx_desc) { >>>>>> - txr->queue_status = EM_QUEUE_IDLE; >>>>>> - return (FALSE); >>>>>> - } >>>>>> - } >>>>>> + >>>>>> + /* Disable watchdog if all clean */ >>>>>> + if (txr->tx_avail == adapter->num_tx_desc) { >>>>>> + txr->queue_status = EM_QUEUE_IDLE; >>>>>> + return (FALSE); >>>>>> + } >>>>>> >>>>>> return (TRUE); >>>>>> } >>>>>> @@ -5064,8 +5058,8 @@ >>>>>> char namebuf[QUEUE_NAME_LEN]; >>>>>> >>>>>> /* Driver Statistics */ >>>>>> - SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", >>>>>> - CTLFLAG_RD,&adapter->link_irq, 0, >>>>>> + SYSCTL_ADD_UINT(ctx, child, OID_AUTO, "link_irq", >>>>>> + CTLFLAG_RD,&adapter->link_irq,0, >>>>>> "Link MSIX IRQ Handled"); >>>>>> SYSCTL_ADD_ULONG(ctx, child, OID_AUTO, "mbuf_alloc_fail", >>>>>> CTLFLAG_RD,&adapter->mbuf_alloc_failed, >>>>>> @@ -5108,11 +5102,13 @@ >>>>>> queue_list = SYSCTL_CHILDREN(queue_node); >>>>>> >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_head", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_TDH(txr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_TDH(txr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Transmit Descriptor Head"); >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "txd_tail", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_TDT(txr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_TDT(txr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Transmit Descriptor Tail"); >>>>>> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "tx_irq", >>>>>> @@ -5123,11 +5119,13 @@ >>>>>> "Queue No Descriptor Available"); >>>>>> >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_head", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_RDH(rxr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_RDH(rxr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Receive Descriptor Head"); >>>>>> SYSCTL_ADD_PROC(ctx, queue_list, OID_AUTO, "rxd_tail", >>>>>> - CTLFLAG_RD, adapter, >>> E1000_RDT(rxr->me), >>>>>> + CTLFLAG_RD, adapter, >>>>>> + E1000_RDT(rxr->me), >>>>>> em_sysctl_reg_handler, "IU", >>>>>> "Receive Descriptor Tail"); >>>>>> SYSCTL_ADD_ULONG(ctx, queue_list, OID_AUTO, "rx_irq", >>>>>> @@ -5141,19 +5139,19 @@ >>>>>> CTLFLAG_RD, NULL, "Statistics"); >>>>>> stat_list = SYSCTL_CHILDREN(stat_node); >>>>>> >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "excess_coll", >>>>>> CTLFLAG_RD,&stats->ecol, >>>>>> "Excessive collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "single_coll", >>>>>> CTLFLAG_RD,&stats->scc, >>>>>> "Single collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "multiple_coll", >>>>>> CTLFLAG_RD,&stats->mcc, >>>>>> "Multiple collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "late_coll", >>>>>> CTLFLAG_RD,&stats->latecol, >>>>>> "Late collisions"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "collision_count", >>>>>> CTLFLAG_RD,&stats->colc, >>>>>> "Collision Count"); >>>>>> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "symbol_errors", >>>>>> @@ -5240,12 +5238,12 @@ >>>>>> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, >>> "rx_frames_1024_1522", >>>>>> CTLFLAG_RD,&adapter->stats.prc1522, >>>>>> "1023-1522 byte frames received"); >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_recvd", >>>>>> CTLFLAG_RD,&adapter->stats.gorc, >>>>>> "Good Octets Received"); >>>>>> >>>>>> /* Packet Transmission Stats */ >>>>>> - SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", >>>>>> + SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "good_octets_txd", >>>>>> CTLFLAG_RD,&adapter->stats.gotc, >>>>>> "Good Octets Transmitted"); >>>>>> SYSCTL_ADD_QUAD(ctx, stat_list, OID_AUTO, "total_pkts_txd", >>>>>> >>>>>> -- >>>>>> ------------------- >>>>>> Mike Tancsa, tel +1 519 651 3400 >>>>>> Sentex Communications, mike@sentex.net >>>>>> Providing Internet services since 1994 www.sentex.net >>>>>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>>>> >>>> >>>> -- >>>> ------------------- >>>> Mike Tancsa, tel +1 519 651 3400 >>>> Sentex Communications, mike@sentex.net >>>> Providing Internet services since 1994 www.sentex.net >>>> Cambridge, Ontario Canada http://www.tancsa.com/ >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> > From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 10:28:39 2011 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 979AB1065672 for ; Wed, 6 Jul 2011 10:28:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 468D58FC0A for ; Wed, 6 Jul 2011 10:28:39 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p66ASW2o087645; Wed, 6 Jul 2011 06:28:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E1438B8.9000409@sentex.net> Date: Wed, 06 Jul 2011 06:28:08 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hooman Fazaeli References: <4D2C636B.5040003@sentex.net> <4D3C4795.40205@sentex.net> <4D42EA74.4090807@sentex.net> <1296590190.2326.6.camel@hitfishpass-lx.corp.yahoo.com> <1296591565.2326.7.camel@hitfishpass-lx.corp.yahoo.com> <1296597827.2326.12.camel@hitfishpass-lx.corp.yahoo.com> <4D48C973.7080503@sentex.net> <4D49A26B.5050803@sentex.net> <1296842996.2233.0.camel@hitfishpass-lx.corp.yahoo.com> <4D4F3497.6050505@sentex.net> <4E141D01.3040203@sepehrs.com> In-Reply-To: <4E141D01.3040203@sepehrs.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM 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, 06 Jul 2011 10:28:39 -0000 On 7/6/2011 4:29 AM, Hooman Fazaeli wrote: > Can you pls. share the patch for freebsd 7? Its in the tree. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/ ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 12:17:11 2011 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 8BF24106566B for ; Wed, 6 Jul 2011 12:17:11 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from email.aon.at (nat-warsl417-01.aon.at [195.3.96.119]) by mx1.freebsd.org (Postfix) with ESMTP id CDF158FC0C for ; Wed, 6 Jul 2011 12:17:09 +0000 (UTC) Received: (qmail 10699 invoked from network); 6 Jul 2011 11:50:28 -0000 Received: from smarthub94.highway.telekom.at (HELO email.aon.at) ([172.18.5.236]) (envelope-sender ) by fallback44.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 6 Jul 2011 11:50:28 -0000 Received: (qmail 366 invoked from network); 6 Jul 2011 11:50:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL602.highway.telekom.at X-Spam-Level: Received: from 188-23-47-140.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([188.23.47.140]) (envelope-sender ) by smarthub94.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 6 Jul 2011 11:50:24 -0000 Received: from atpcdvvc.xyzzy (atpcdvvc.xyzzy [IPv6:fec0:0:0:4d42::84]) by gandalf.xyzzy (8.14.4/8.14.4) with ESMTP id p66BoOR7021710; Wed, 6 Jul 2011 13:50:24 +0200 (CEST) (envelope-from la5lbtyi@aon.at) Message-ID: <4E144C00.9020804@aon.at> Date: Wed, 06 Jul 2011 13:50:24 +0200 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: art@freebsd.org Subject: Re: amd + NFS reconnect = ICMP storm + unkillable process. 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, 06 Jul 2011 12:17:11 -0000 Hi Artem, I have exactly the same problem as you are describing below, also with quite a number of amd mounts. In addition to the scenario you describe, another way this happens here is when downloading a file via firefox to a directory currently open in dolphin (KDE file manager). This will almost surely trigger the symptoms you describe. I've had 7.4 running on the box before, now with 8.2 this has started to happen. Alas, I don't have a solution. We should probably file a PR, but I don't even know where to assign it to. Amd does not seem much maintained, it's probably using some old-style mounts (it never mounts anything via IPv6, for example). Regards, Martin > Hi, > > I wonder if someone else ran into this issue before and, maybe, have a solution. > > I've been running into a problem where access to filesystems mouted > with amd wedges processes in an unkillable state and produces ICMP > storm on loopback interface.I've managed to narrow down to NFS > reconnect, but that's when I ran out of ideas. > > Usually the problem happens when I abort a parallel build job in an > i386 jail on FreeBSD-8/amd64 (r223055). When the build job is killed > now and then I end up with one process consuming 100% of CPU time on > one of the cores. At the same time I get a lot of messages on the > console saying "Limiting icmp unreach response from 49837 to 200 > packets/sec" and the loopback traffic goes way up. > > As far as I can tell here's what's happening: > > * My setup uses a lot of filesystems mounted by amd. > * amd itself pretends to be an NFS server running on the localhost and > serving requests for amd mounts. > * Now and then amd seems to change the ports it uses. Beats me why. > * the problem seems to happen when some process is about to access amd > mountpoint when amd instance disappears from the port it used to > listen on. In my case it does correlate with interrupted builds, but I > have no clue why. > * NFS client detects disconnect and tries to reconnect using the same > destination port. > * That generates ICMP response as port is unreachable and it reconnect > call returns almost immediatelly. > * We try to reconnect again, and again, and again.... > * the process in this state is unkillable > > Here's what the stack of the 'stuck' process looks like in those rare > moments when it gets to sleep: > 18779 100511 collect2 - mi_switch+0x176 > turnstile_wait+0x1cb _mtx_lock_sleep+0xe1 sleepq_catch_signals+0x386 > sleepq_timedwait_sig+0x19 _sleep+0x1b1 clnt_dg_call+0x7e6 > clnt_reconnect_call+0x12e nfs_request+0x212 nfs_getattr+0x2e4 > VOP_GETATTR_APV+0x44 nfs_bioread+0x42a VOP_READLINK_APV+0x4a > namei+0x4f9 kern_statat_vnhook+0x92 kern_statat+0x15 > freebsd32_stat+0x2e syscallenter+0x23d > > * Usually some timeout expires in few minutes, the process dies, ICMP > storm stops and the system is usable again. > * On occasion the process is stuck forever and I have to reboot the box. > > I'm not sure who's to blame here. > > Is the automounter at fault for disappearing from the port it was > supposed to listen to? > If NFS guilty of trying blindly to reconnect on the same port and not > giving up sooner? > Should I flog the operator (ALA myself) for misconfiguring something > (what?) in amd or NFS? > > More importantly -- how do I fix it? > Any suggestions on fixing/debugging this issue? > > --Artem From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 15:28:47 2011 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 CAE25106566C for ; Wed, 6 Jul 2011 15:28:47 +0000 (UTC) (envelope-from igor.anishchuk@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 814578FC16 for ; Wed, 6 Jul 2011 15:28:47 +0000 (UTC) Received: by qwc9 with SMTP id 9so5439qwc.13 for ; Wed, 06 Jul 2011 08:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w8J23lQXwCyt05to0D/8rnJ1J9Uf+4JpArAzDKUgz+Q=; b=Yn4IsFRWcKOIOO041RRdprkHiNJgcEnoV+jJ4HA/Ttj02FbVKapZZQDaMhGWu8NvXr dRrMhbkqJPD5xvMrbnoEuG7mbU5X7RqHusBigzUC2EAF1uvof1XQtjRAoHX5gYtm4ihp RKdVAAiBm6BTpA4B4BONFlSY0bG8a1VKwpmlw= MIME-Version: 1.0 Received: by 10.224.45.71 with SMTP id d7mr6323276qaf.187.1309966126598; Wed, 06 Jul 2011 08:28:46 -0700 (PDT) Received: by 10.224.54.84 with HTTP; Wed, 6 Jul 2011 08:28:46 -0700 (PDT) In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D018D603544@orsmsx508.amr.corp.intel.com> References: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> <6E5D6CF9-E197-44E8-835A-ABD9F5969DBE@averesystems.com> <1DB50624F8348F48840F2E2CF6040A9D018D603544@orsmsx508.amr.corp.intel.com> Date: Wed, 6 Jul 2011 18:28:46 +0300 Message-ID: From: Igor Anishchuk To: "Vogel, Jack" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Andrew Boyer Subject: Re: ixgbe> vlan addition and removal brings the interfaces down and up 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, 06 Jul 2011 15:28:47 -0000 Hi Jack, many thanks for your work. I'm still interested in hearing back from you. Is there anything I can do to help? Also I would not mind losing hardware VLAN assistance should it be the only= way. BTW, what about MAC addresses? Is the card reset when a MAC address changed= ? Thanks! Igor On Wed, Jun 29, 2011 at 12:18 AM, Vogel, Jack wrote: > Hmmm, I'll have to take a look at the code, and if I hadn't done it by no= w there might be some reason I couldn't, or hell, maybe I just forgot :) = =C2=A0Will let you know. > > Jack > > > -----Original Message----- > From: Andrew Boyer [mailto:aboyer@averesystems.com] > Sent: Tuesday, June 28, 2011 1:32 PM > To: Igor Anishchuk; Vogel, Jack > Cc: freebsd-net@freebsd.org > Subject: Re: ixgbe> vlan addition and removal brings the interfaces down = and up > > Hello Igor, > Sorry for the delay. =C2=A0I'm a little hesitant to share our ixgbe patch= to change this behavior because Jack has checked in changes to igb that ma= ke me think that our change is not correct. =C2=A0Or, at least, that he's p= robably working on fixing ixgbe the right way. =C2=A0Jack, are you planning= to copy the reorganization of igb_setup_vlan_hw_support() over to ixgbe_se= tup_vlan_hw_support? > > -Andrew > > On Jun 28, 2011, at 4:02 PM, Igor Anishchuk wrote: > >> Hi Andrew, >> >> could you please share the patch as I'm dying with this problem. >> >> What makes it worse is that on a busy router the DOWN/UP of the >> interfaces causes the ixgbe card to lose all network access until the >> box is rebooted. I can reproduce it easily on a variety of hosts from >> both HP and Dell. Therefore a patch that would not cause the card to >> reset would help a lot. >> >> -- Igor >> >> On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer = wrote: >>> I have a patch that will fix this. =C2=A0Please give me a little while = to clean it up, and I will send it out on the list. >>> >>> -Andrew >>> >>> On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: >>> >>>> Hi All, >>>> >>>> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >>>> with direct attach cables and there is one thing keeps bothering me. >>>> I've been searching the Internet for any information with no luck. I >>>> would also assume that the problem is widely known, and I found one >>>> related PR kern/141285 but that one was closed unsolved. >>>> >>>> When a VLAN interface is added or removed to from the ix interfaces >>>> the parent interface is briefly brought down and up. This event is >>>> visible for all applications and the switches. With my use case I add >>>> and remove VLAN interfaces on the fly and the described behavior >>>> causes undesired effects, especially for BGP daemons that are >>>> configured to monitor one of permanent VLAN interfaces. >>>> >>>> I use FreeBSD 7-STABLE and the behavior is the same with stock >>>> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >>>> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >>>> -vlanhwtso with no effect. >>>> >>>> Could someone help me to stop the cards behaving this way? I do not >>>> mind some performance penalties, nor running in permanent promiscuous >>>> mode. I just want the card to stay up all the time regardless of the >>>> vlan interfaces attached to it. >>>> >>>> Any help, links, patches are much appreciated. >>>> >>>> Regards, >>>> >>>> Igor Anishchuk >>>> _______________________________________________ >>>> 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" >>> >>> -------------------------------------------------- >>> Andrew Boyer =C2=A0 =C2=A0aboyer@averesystems.com >>> >>> >>> >>> >>> > > -------------------------------------------------- > Andrew Boyer =C2=A0 =C2=A0aboyer@averesystems.com > > > > > From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 15:46:58 2011 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 006A2106564A for ; Wed, 6 Jul 2011 15:46:58 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id A19A68FC14 for ; Wed, 6 Jul 2011 15:46:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id AF2B18BC023; Wed, 6 Jul 2011 11:49:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYr8fIwnNE4l; Wed, 6 Jul 2011 11:49:10 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id CDCE28BC01F; Wed, 6 Jul 2011 11:49:09 -0400 (EDT) From: Andrew Boyer Date: Wed, 6 Jul 2011 11:46:55 -0400 References: <201105121436.p4CEaQWK028630@freefall.freebsd.org> To: freebsd-net@freebsd.org, John Baldwin Message-Id: <0A13D545-693E-44B6-B3FA-BCBDF2F6CC99@averesystems.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fwd: kern/156978: [lagg][patch] Take lagg rlock before checking flags 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, 06 Jul 2011 15:46:58 -0000 Can someone please review this and check in the patch? (And MFC it to = stable/8?) Thank you, Andrew Begin forwarded message: > From: linimon@FreeBSD.org > Date: May 12, 2011 10:36:26 AM EDT > To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, = freebsd-net@FreeBSD.org > Subject: Re: kern/156978: [lagg][patch] Take lagg rlock before = checking flags >=20 > Synopsis: [lagg][patch] Take lagg rlock before checking flags >=20 > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Thu May 12 14:36:20 UTC 2011 > Responsible-Changed-Why:=20 > Over to maintainer(s). >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D156978 > _______________________________________________ > 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" -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 18:27:59 2011 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 6BBDE106564A for ; Wed, 6 Jul 2011 18:27:59 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id E59C98FC12 for ; Wed, 6 Jul 2011 18:27:58 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 22089 invoked from network); 6 Jul 2011 20:01:17 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1309975277; bh=4QNbJiLLX7pgE5b/1ASnMOSlfj6Vpgg2cQek4qbYaWE=; h=From:To:Subject; b=SZeTgolpgoUXWUcumQ3DqHKWHtB8shpjvAcTbZjyv3hrbPYRf0BZrsJQPqY7XNmjk 9ZBsh/S9zKWypLQ+PmxCg3/bYOSvjcmglydCLdjtd34UvXSt8xyCM/i8+W9xU2WTs5 7kkHFYmiHbxf7bhW4DdssBn7u/gUrfGrkbmAty74= Received: from out.poczta.wp.pl (HELO localhost) ([212.77.101.240]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 6 Jul 2011 20:01:17 +0200 Date: Wed, 06 Jul 2011 20:01:17 +0200 From: "Marek Salwerowicz" To: freebsd-net@freebsd.org Message-ID: <4e14a2ed555a94.24022420@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Mailer: Interfejs WWW nowej poczty Wirtualnej Polski X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.2.18) Gecko/20110614 Firefox/3.6.18 Organization: Poznaj Poczte WP http://poczta.wp.pl/info-start.html X-WP-IP: 83.19.131.170 X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [MYM0] Subject: ipfw + 2 LANs 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, 06 Jul 2011 18:27:59 -0000 Hi all, I have two separate LANs (one 10.0.1.0/24 and the other 10.0.2.0/24). Both are connected to FreeBSD 8.2 router (ifaces em1 and em2). To em0 I have my ISP (10.0.0.0/24) connected. The idea is to share the Internet connection to both networks, and block any traffic between them. I was trying to set up the firewall like this: #!/bin/sh cmd="ipfw -q" $cmd flush $cmd add 50 check-state $cmd add 80 divert natd ip from any to any via em0 $cmd add 100 allow ip from any to me $cmd add 101 allow ip from me to any $cmd add 200 allow ip from 10.0.1.0/24 to 10.0.0.0/24 keep-state $cmd add 300 allow ip from 10.0.2.0/24 to 10.0.0.0/24 keep-state But it doesn't really work for me when I set at the end: $cmd add 500 allow ip from any to any It works but it allows also traffic between LANs. Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 18:44:38 2011 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 A4028106564A for ; Wed, 6 Jul 2011 18:44:38 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7648FC0A for ; Wed, 6 Jul 2011 18:44:38 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp021.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNX00IBFDD7VT10@asmtp021.mac.com> for freebsd-net@freebsd.org; Wed, 06 Jul 2011 11:43:55 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-06_06:2011-07-06, 2011-07-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107060130 From: Chuck Swiger In-reply-to: <4e14a2ed555a94.24022420@wp.pl> Date: Wed, 06 Jul 2011 11:43:54 -0700 Message-id: <669B9148-C9D2-41F3-B050-F4C9DE928380@mac.com> References: <4e14a2ed555a94.24022420@wp.pl> To: Marek Salwerowicz X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ipfw + 2 LANs 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, 06 Jul 2011 18:44:38 -0000 On Jul 6, 2011, at 11:01 AM, Marek Salwerowicz wrote: > The idea is to share the Internet connection to both networks, and block any traffic between them. > > I was trying to set up the firewall like this: > > #!/bin/sh > > cmd="ipfw -q" > > $cmd flush > > $cmd add 50 check-state > > $cmd add 80 divert natd ip from any to any via em0 > > $cmd add 100 allow ip from any to me > $cmd add 101 allow ip from me to any > > $cmd add 200 allow ip from 10.0.1.0/24 to 10.0.0.0/24 keep-state > $cmd add 300 allow ip from 10.0.2.0/24 to 10.0.0.0/24 keep-state > > But it doesn't really work for me These rules don't provide any means for LAN traffic to pass outside, just traffic to and from the firewall and to and from the 10.0.1.0/24 & 10.0.2.0/24 subnets. > when I set at the end: > > $cmd add 500 allow ip from any to any Yes, but that's too broad. Try more like: $cmd add 500 deny ip from 10.0.1.0/24 to 10.0.2.0/24 $cmd add 510 deny ip from 10.0.2.0/24 to 10.0.1.0/24 $cmd add 520 allow ip from any to any Again, rule 520 is also too broad, but you can test and confirm this is allowing NAT traffic to and from the Internet, but blocking the subnets from communicating. If that is working, replace 520 with more narrowly tailored allow and deny rules. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 19:02:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CE4901065670 for ; Wed, 6 Jul 2011 19:02:35 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 4CCF414DF12 for ; Wed, 6 Jul 2011 19:02:34 +0000 (UTC) Received: (qmail 16082 invoked from network); 6 Jul 2011 19:02:33 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 6 Jul 2011 19:02:33 -0000 Message-ID: <4E14B149.6030307@freebsd.org> Date: Wed, 06 Jul 2011 12:02:33 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101220 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org, "freebsd-xen@freebsd.org" X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------060605090108080700050202" Cc: Subject: how to get "max # of mbufs in a packet" from xn to the tcp stack? 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, 06 Jul 2011 19:02:35 -0000 This is a multi-part message in MIME format. --------------060605090108080700050202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, I've attached a patch which fixes the "nfrags > 18, netback won't be able to handle it" problem with xen netfront when TSO is enabled. It's not finished, though: + int max_mbuf_chain_len = 16; /* XXX Set this based on interface? */ I'm not sure what the right way is to feed a value from the interface up into tcp_output; can someone advise? -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid --------------060605090108080700050202 Content-Type: text/x-diff; name="tcp_mbuf_chain_limit.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcp_mbuf_chain_limit.patch" Index: kern/uipc_mbuf.c =================================================================== --- kern/uipc_mbuf.c (revision 223824) +++ kern/uipc_mbuf.c (working copy) @@ -525,12 +525,14 @@ * only their reference counts are incremented. */ struct mbuf * -m_copym(struct mbuf *m, int off0, int len, int wait) +m_copy_nbufs(struct mbuf *m, int off0, int len, int wait, long * outlen, + int nbufmax) { struct mbuf *n, **np; int off = off0; struct mbuf *top; int copyhdr = 0; + int len_orig = len; KASSERT(off >= 0, ("m_copym, negative off %d", off)); KASSERT(len >= 0, ("m_copym, negative len %d", len)); @@ -546,7 +548,7 @@ } np = ⊤ top = 0; - while (len > 0) { + while (len > 0 && nbufmax-- > 0) { if (m == NULL) { KASSERT(len == M_COPYALL, ("m_copym, length > size of mbuf chain")); @@ -584,6 +586,9 @@ if (top == NULL) mbstat.m_mcfail++; /* XXX: No consistency. */ + if (outlen) + *outlen = len_orig - len; + return (top); nospace: m_freem(top); @@ -591,6 +596,13 @@ return (NULL); } +struct mbuf * +m_copym(struct mbuf *m, int off0, int len, int wait) +{ + + return (m_copy_nbufs(m, off0, len, wait, NULL, INT_MAX)); +} + /* * Returns mbuf chain with new head for the prepending case. * Copies from mbuf (chain) n from off for len to mbuf (chain) m Index: netinet/tcp_output.c =================================================================== --- netinet/tcp_output.c (revision 223824) +++ netinet/tcp_output.c (working copy) @@ -183,6 +183,7 @@ int sack_rxmit, sack_bytes_rxmt; struct sackhole *p; int tso; + int max_mbuf_chain_len = 16; /* XXX Set this based on interface? */ struct tcpopt to; #if 0 int maxburst = TCP_MAXBURST; @@ -806,16 +807,6 @@ struct mbuf *mb; u_int moff; - if ((tp->t_flags & TF_FORCEDATA) && len == 1) - TCPSTAT_INC(tcps_sndprobe); - else if (SEQ_LT(tp->snd_nxt, tp->snd_max) || sack_rxmit) { - tp->t_sndrexmitpack++; - TCPSTAT_INC(tcps_sndrexmitpack); - TCPSTAT_ADD(tcps_sndrexmitbyte, len); - } else { - TCPSTAT_INC(tcps_sndpack); - TCPSTAT_ADD(tcps_sndbyte, len); - } MGETHDR(m, M_DONTWAIT, MT_DATA); if (m == NULL) { SOCKBUF_UNLOCK(&so->so_snd); @@ -847,7 +838,8 @@ mtod(m, caddr_t) + hdrlen); m->m_len += len; } else { - m->m_next = m_copy(mb, moff, (int)len); + m->m_next = m_copy_nbufs(mb, moff, len, M_DONTWAIT, + &len, max_mbuf_chain_len); if (m->m_next == NULL) { SOCKBUF_UNLOCK(&so->so_snd); (void) m_free(m); @@ -856,6 +848,18 @@ } } + /* Update stats here as m_copy_nbufs may have adjusted len. */ + if ((tp->t_flags & TF_FORCEDATA) && len == 1) + TCPSTAT_INC(tcps_sndprobe); + else if (SEQ_LT(tp->snd_nxt, tp->snd_max) || sack_rxmit) { + tp->t_sndrexmitpack++; + TCPSTAT_INC(tcps_sndrexmitpack); + TCPSTAT_ADD(tcps_sndrexmitbyte, len); + } else { + TCPSTAT_INC(tcps_sndpack); + TCPSTAT_ADD(tcps_sndbyte, len); + } + /* * If we're sending everything we've got, set PUSH. * (This will keep happy those implementations which only Index: sys/mbuf.h =================================================================== --- sys/mbuf.h (revision 223824) +++ sys/mbuf.h (working copy) @@ -849,6 +849,7 @@ int, int, int, int); struct mbuf *m_copypacket(struct mbuf *, int); void m_copy_pkthdr(struct mbuf *, struct mbuf *); +struct mbuf *m_copy_nbufs(struct mbuf *, int, int, int, long *, int); struct mbuf *m_copyup(struct mbuf *n, int len, int dstoff); struct mbuf *m_defrag(struct mbuf *, int); void m_demote(struct mbuf *, int); --------------060605090108080700050202-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 19:19:47 2011 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 0499C106566B; Wed, 6 Jul 2011 19:19:47 +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 D12A28FC14; Wed, 6 Jul 2011 19:19:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p66JJkQH019988; Wed, 6 Jul 2011 19:19:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p66JJk2a019984; Wed, 6 Jul 2011 19:19:46 GMT (envelope-from linimon) Date: Wed, 6 Jul 2011 19:19:46 GMT Message-Id: <201107061919.p66JJk2a019984@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158686: [patch] [tap] Add VIMAGE support to if_tap 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, 06 Jul 2011 19:19:47 -0000 Old Synopsis: [PATCH] [if_tap] Add VIMAGE support to if_tap New Synopsis: [patch] [tap] Add VIMAGE support to if_tap Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 6 19:19:24 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158686 From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 19:49:31 2011 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 1580E1065673 for ; Wed, 6 Jul 2011 19:49:31 +0000 (UTC) (envelope-from kob6558@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 C6BD28FC17 for ; Wed, 6 Jul 2011 19:49:30 +0000 (UTC) Received: by yxl31 with SMTP id 31so161469yxl.13 for ; Wed, 06 Jul 2011 12:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U2CsmY0wMYStuQmhi2ATHyx67LQJKYbKo/pEsJrQqXw=; b=ur/U1uxFzh5PBN2SmrBEg8kCLgivwsO9akgVWIj5dU41GDI43sZ9FICa5doEs+6KG4 1ZmJmQCqQsEzYvUvaeUtkRbb94oVH7PGXdgiHkeKRQI/eNJRXzmDgd6bAFOBWvwPw2T8 AXVxsbTzu97Ymq/dHrMkJAbU2PQsNwUDco3ks= MIME-Version: 1.0 Received: by 10.150.251.9 with SMTP id y9mr181176ybh.371.1309980465402; Wed, 06 Jul 2011 12:27:45 -0700 (PDT) Received: by 10.151.111.7 with HTTP; Wed, 6 Jul 2011 12:27:45 -0700 (PDT) Received: by 10.151.111.7 with HTTP; Wed, 6 Jul 2011 12:27:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Jul 2011 09:27:45 -1000 Message-ID: From: Kevin Oberman To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Charles Sprickman Subject: Re: bce packet loss 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, 06 Jul 2011 19:49:31 -0000 On Jul 5, 2011 4:49 PM, "Chuck Swiger" wrote: > > On Jul 4, 2011, at 6:32 PM, Charles Sprickman wrote: > > We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) and I'm seeing occasional packet loss on them (enough that it trips nagios now and then). Cabling seems fine as neither the switch nor the sysctl info for the device show any errors/collisions/etc, however there is one odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below for full sysctl output. The switch shows no errors but for "Dropped packets 683868". > > A quick check of the #'s is showing an error rate of 8.6e-6, or about one byte out of 100,000. That's much better than what TCP/IP and ethernet were designed for. At a guess, your box or the switch occasionally gets busy enough that it drops a few packets now and again. > > Regards, > -- > -Chuck > 1 in 10**6? That is totally excessive. The Ethernet spec requires no worse than 10**13 and that is far worse than should ever be seen in the real world. At one in a million, any remotely high volume transfer will crawl, especially over a long path. If dropped packets ate being reported, the most common cause is fan-in. If two input ports are both trying to talk a line rate to a single output port, the buffer will fill an packets will be dropped. Most switches do tail drop, so queue management is terrible, compounding the effects. R. Kevin Oberman, Network Engineer Retired kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 20:05:01 2011 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 CF446106566C for ; Wed, 6 Jul 2011 20:05:01 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id B59D98FC12 for ; Wed, 6 Jul 2011 20:05:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNX00860H4BKB90@asmtp026.mac.com> for freebsd-net@freebsd.org; Wed, 06 Jul 2011 13:05:01 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-06_06:2011-07-06, 2011-07-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107060145 From: Chuck Swiger In-reply-to: Date: Wed, 06 Jul 2011 13:04:59 -0700 Message-id: <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> References: To: Kevin Oberman X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Charles Sprickman Subject: Re: bce packet loss 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, 06 Jul 2011 20:05:01 -0000 On Jul 6, 2011, at 12:27 PM, Kevin Oberman wrote: > 1 in 10**6? That is totally excessive. It's high for a switched LAN, but I'd imagine you remember collision rates on hubs, which might well exceed 1% of the packets when the network is under load. > The Ethernet spec requires no worse than 10**13 and that is far worse than should ever be seen in the real world. At one in a million, any remotely high volume transfer will crawl, especially over a long path. 10 Gigabit ethernet wants cabling spec'ed to a BER of 10e-13; standard gigabit ethernet cabling (Cat 5e) supposedly is rated for 10e-10. However, the BER of the cabling doesn't translate directly into octet error count per the NIC statistics, since a bad bit anywhere in a packet causes the entire packet to be dropped with a failed checksum. > If dropped packets ate being reported, the most common cause is fan-in. If two input ports are both trying to talk a line rate to a single output port, the buffer will fill an packets will be dropped. Most switches do tail drop, so queue management is terrible, compounding the effects. Yes, I agree with this as a likely cause. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 20:16:43 2011 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 CC8061065670; Wed, 6 Jul 2011 20:16:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88AFD8FC1B; Wed, 6 Jul 2011 20:16:43 +0000 (UTC) Received: by iyb11 with SMTP id 11so349972iyb.13 for ; Wed, 06 Jul 2011 13:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Dzp54JO664nLD0sSLDS5RGMQgjXC4lYgQcZCLYIkDnE=; b=W5X4wzcpDaHLCCB7vpQlt8Z/gQfwlnL5jSJ17ejhLgr9vsYSJEw+9AqQ9X+YFUAANX fm9VwkAJ0VDQiwyt2qO11xogKFnTBLv3cAHnNGTS4iNKdKt0KvYdD8O9jVfdDUC6H/fb QVLWH4MaMx1vu5mbD2kKJ+WzSbESEpmsfTJAA= Received: by 10.42.178.137 with SMTP id bm9mr8467197icb.313.1309983402759; Wed, 06 Jul 2011 13:16:42 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id s2sm9087876icw.17.2011.07.06.13.16.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 13:16:41 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 06 Jul 2011 13:15:09 -0700 From: YongHyeon PYUN Date: Wed, 6 Jul 2011 13:15:09 -0700 To: Charles Sprickman Message-ID: <20110706201509.GA5559@michelle.cdnetworks.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.3i Cc: freebsd-net@freebsd.org, David Christensen Subject: Re: bce packet loss 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, 06 Jul 2011 20:16:44 -0000 On Mon, Jul 04, 2011 at 09:32:11PM -0400, Charles Sprickman wrote: > Hello, > > We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) > and I'm seeing occasional packet loss on them (enough that it trips nagios > now and then). Cabling seems fine as neither the switch nor the sysctl > info for the device show any errors/collisions/etc, however there is one > odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below > for full sysctl output. The switch shows no errors but for "Dropped > packets 683868". > > pciconf output is also below. [2] > > By default, the switch had flow control set to "on". I also let it run > with "auto". In both cases, the drops continued to increment. I'm now > running with flow control off to see if that changes anything. > > I do see some correlation between cpu usage and drops - I have cpu usage > graphed in nagios and cacti is graphing the drops on the dell switch. > There's no signs of running out of mbufs or similar. > > So given that limited info, is there anything I can look at to track this > down? Anything stand out in the stats sysctl exposes? Two things are > standing out for me - the number of changes in bce regarding flow control > that are not in 8.1, and the correlation between cpu load and the drops. > > What other information can I provide? > You had 282 RX buffer shortages and these frames were dropped. This may explain why you see occasional packet loss. 'netstat -m' will show which size of cluster allocation were failed. However it seems you have 0 com_no_buffers which indicates controller was able to receive all packets destined for this host. You may host lost some packets(i.e. non-zero mbuf_alloc_failed_count) but your controller and system was still responsive to the network traffic. Data sheet says IfHCInBadOctets indicates number of octets received on the interface, including framing characters for packets that were dropped in the MAC for any reason. I'm not sure this counter includes packets IfInFramesL2FilterDiscards which indicates number of good frames that have been dropped due to the L2 perfect match, broadcast, multicast or MAC control frame filters. If your switch runs STP it would periodically sends BPDU packets to destination address of STP multicast address 01:80:C2:00:00:00. Not sure this is the reason though. Probably David can explain more details on IfHCInBadOctets counter(CCed). From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 21:41:50 2011 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 BA7BF106564A; Wed, 6 Jul 2011 21:41:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 745AD8FC14; Wed, 6 Jul 2011 21:41:50 +0000 (UTC) Received: by iyb11 with SMTP id 11so427272iyb.13 for ; Wed, 06 Jul 2011 14:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=x8GcH1B6zaS3PetC9UCM9aiRNYqtgxPIobyhOUwCSDA=; b=b4Yi7Dk0gHnxm/fAAXXfi68GD9sSABnBwhdLppxHJSmVJ7IM0Uii6Wo65MW7adIi7K 8EETZWiMi2jiJFyRHylbfjsRQdTx08tekWUqlvQgSonX3cIj7E8Z+FPKYSZe1YKraqGv HAqB/cL/pCzcn1gnUOUp+oQ00ozNVgLCyIqzo= Received: by 10.43.59.80 with SMTP id wn16mr92504icb.67.1309988509456; Wed, 06 Jul 2011 14:41:49 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c2sm2696479ibd.5.2011.07.06.14.41.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 14:41:49 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 06 Jul 2011 14:40:16 -0700 From: YongHyeon PYUN Date: Wed, 6 Jul 2011 14:40:16 -0700 To: David Christensen Message-ID: <20110706214016.GB5559@michelle.cdnetworks.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D9115@IRVEXCHCCR01.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385C32D9115@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: Charles Sprickman , David Christensen , "freebsd-net@freebsd.org" Subject: Re: bce packet loss 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, 06 Jul 2011 21:41:50 -0000 On Wed, Jul 06, 2011 at 02:28:19PM -0700, David Christensen wrote: > > You had 282 RX buffer shortages and these frames were dropped. This > > may explain why you see occasional packet loss. 'netstat -m' will > > show which size of cluster allocation were failed. > > However it seems you have 0 com_no_buffers which indicates > > controller was able to receive all packets destined for this host. > > You may host lost some packets(i.e. non-zero mbuf_alloc_failed_count) > > but your controller and system was still responsive to the network > > traffic. > > > > Data sheet says IfHCInBadOctets indicates number of octets received > > on the interface, including framing characters for packets that > > were dropped in the MAC for any reason. > > The IfHcInBadOctets counter says the controller received X bytes > that were bad on the wire (collisions, FCS errors, etc.). A value I thought that too. But other counters such as FCS, FAE, Collisions, Jabbers were all zero. > of 539,369 would equal about 355 frames @ 1518 bytes per frame. > How bad that is really depends on the amount of time the server > was running. The minimum bit-error rate (BER) for 1000Base-T is > 10^-12, so running at line rate you'd expect to see an error very > 1000 seconds according to the following link: > > http://de.brand-rex.com/LinkClick.aspx?fileticket=TFxnnLPedAg%3D&tabid=1956&mid=5686 > > Most vendors design to greater than 10^-12 and you're probably not > running at line rate all the time so you should see fewer errors. > In my testing I can go for days without seeing any errors, but if > you run long enough or have marginal interconnects/cabling the > error rate will rise. > > Dave > > From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 21:45:56 2011 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 18857106566C for ; Wed, 6 Jul 2011 21:45:56 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id A32658FC08 for ; Wed, 6 Jul 2011 21:45:55 +0000 (UTC) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 06 Jul 2011 14:33:21 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 6 Jul 2011 14:28:37 -0700 From: "David Christensen" To: "pyunyh@gmail.com" , "Charles Sprickman" Date: Wed, 6 Jul 2011 14:28:19 -0700 Thread-Topic: bce packet loss Thread-Index: Acw8GaxfxFCHGfSjSemBIXP1BbFGjgABvtbg Message-ID: <5D267A3F22FD854F8F48B3D2B523819385C32D9115@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> In-Reply-To: <20110706201509.GA5559@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: FG5c Hi8J MKlk NMvS No35 QSxs QgPT UnG9 VJom ZzMJ Z3oH iUeo i0zn jwGf lnOB mKd4; 4; ZABhAHYAaQBkAGMAaABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AGYAcgBlAGUAYgBzAGQALQBuAGUAdABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AHAAeQB1AG4AeQBoAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBzAHAAbwByAGsAQABiAHcAYQB5AC4AbgBlAHQA; Sosha1_v1; 7; {C1215C4F-1ECB-49AA-8A0B-D5696DA98E5E}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Wed, 06 Jul 2011 21:28:19 GMT;UgBFADoAIABiAGMAZQAgAHAAYQBjAGsAZQB0ACAAbABvAHMAcwA= x-cr-puzzleid: {C1215C4F-1ECB-49AA-8A0B-D5696DA98E5E} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 620A0B2B62O20343336-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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, 06 Jul 2011 21:45:56 -0000 > You had 282 RX buffer shortages and these frames were dropped. This > may explain why you see occasional packet loss. 'netstat -m' will > show which size of cluster allocation were failed. > However it seems you have 0 com_no_buffers which indicates > controller was able to receive all packets destined for this host. > You may host lost some packets(i.e. non-zero mbuf_alloc_failed_count) > but your controller and system was still responsive to the network > traffic. >=20 > Data sheet says IfHCInBadOctets indicates number of octets received > on the interface, including framing characters for packets that > were dropped in the MAC for any reason.=20 The IfHcInBadOctets counter says the controller received X bytes=20 that were bad on the wire (collisions, FCS errors, etc.). A value of 539,369 would equal about 355 frames @ 1518 bytes per frame. How bad that is really depends on the amount of time the server was running. The minimum bit-error rate (BER) for 1000Base-T is=20 10^-12, so running at line rate you'd expect to see an error very 1000 seconds according to the following link: http://de.brand-rex.com/LinkClick.aspx?fileticket=3DTFxnnLPedAg%3D&tabid=3D= 1956&mid=3D5686 Most vendors design to greater than 10^-12 and you're probably not running at line rate all the time so you should see fewer errors. In my testing I can go for days without seeing any errors, but if you run long enough or have marginal interconnects/cabling the=20 error rate will rise. Dave From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 21:47:46 2011 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 A77CC1065670 for ; Wed, 6 Jul 2011 21:47:46 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 666FA8FC13 for ; Wed, 6 Jul 2011 21:47:46 +0000 (UTC) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 06 Jul 2011 14:52:19 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 6 Jul 2011 14:47:35 -0700 From: "David Christensen" To: "pyunyh@gmail.com" Date: Wed, 6 Jul 2011 14:47:24 -0700 Thread-Topic: bce packet loss Thread-Index: Acw8JYlqG+cpsl5GQESfGwNh3KE5lwAAE8lg Message-ID: <5D267A3F22FD854F8F48B3D2B523819385C32D912B@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D9115@IRVEXCHCCR01.corp.ad.broadcom.com> <20110706214016.GB5559@michelle.cdnetworks.com> In-Reply-To: <20110706214016.GB5559@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AYMA DXBL FujJ IECB JPNI JYy9 Mpjt OJ9+ O9p/ Prdt Wky7 Xgxy b7R+ hPFc jpaF qmaK; 4; ZABhAHYAaQBkAGMAaABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AGYAcgBlAGUAYgBzAGQALQBuAGUAdABAAGYAcgBlAGUAYgBzAGQALgBvAHIAZwA7AHAAeQB1AG4AeQBoAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBzAHAAbwByAGsAQABiAHcAYQB5AC4AbgBlAHQA; Sosha1_v1; 7; {45DA51BE-6966-479E-97CC-E853A6819681}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Wed, 06 Jul 2011 21:47:24 GMT;UgBFADoAIABiAGMAZQAgAHAAYQBjAGsAZQB0ACAAbABvAHMAcwA= x-cr-puzzleid: {45DA51BE-6966-479E-97CC-E853A6819681} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 620A069962O20352548-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Charles Sprickman , David Christensen , "freebsd-net@freebsd.org" Subject: RE: bce packet loss 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, 06 Jul 2011 21:47:46 -0000 > > > Data sheet says IfHCInBadOctets indicates number of octets received > > > on the interface, including framing characters for packets that > > > were dropped in the MAC for any reason. > > > > The IfHcInBadOctets counter says the controller received X bytes > > that were bad on the wire (collisions, FCS errors, etc.). A value >=20 > I thought that too. But other counters such as FCS, FAE, Collisions, > Jabbers were all zero. >=20 Also includes frames dropped due to an incorrect destination MAC address (i.e. perfect MAC filter mismatch). This means the NIC=20 received a unicast frame for a MAC address that doesn't match the NIC's MAC address. Very common on a hub and occurs occasionally on switches as well. Dave From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 21:54:37 2011 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 B95A0106564A; Wed, 6 Jul 2011 21:54:37 +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 917B88FC08; Wed, 6 Jul 2011 21:54:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p66LsbvT064921; Wed, 6 Jul 2011 21:54:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p66Lsbni064917; Wed, 6 Jul 2011 21:54:37 GMT (envelope-from linimon) Date: Wed, 6 Jul 2011 21:54:37 GMT Message-Id: <201107062154.p66Lsbni064917@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158635: [em] TSO breaks BPF packet captures with em driver 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, 06 Jul 2011 21:54:37 -0000 Old Synopsis: TSO breaks BPF packet captures with em driver New Synopsis: [em] TSO breaks BPF packet captures with em driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 6 21:53:02 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158635 From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 21:55:54 2011 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 5983A106564A; Wed, 6 Jul 2011 21:55:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 11DC18FC17; Wed, 6 Jul 2011 21:55:53 +0000 (UTC) Received: by iwr19 with SMTP id 19so415862iwr.13 for ; Wed, 06 Jul 2011 14:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=vsudQOi0U7YIL/GKpV7baqVnuWZl3V/y2+Cs/AJRvks=; b=VKudPXx3R6L9zj+XzTGrDSq/A9ulUkU58gIxUDvhFCLA9gS1niV3qK/xH2bQ4vcpQv e2yTFqRL6tEOKEBd93Ggo3oU7ZDkfL6PF2+E0M+LGL1LgEqenzZOOspg8PpZyD9d34QJ uI1hTVZoCKbkjCtnQ/NwwLgcKwzPO+yZW6Xko= Received: by 10.42.162.198 with SMTP id z6mr92557icx.233.1309989353346; Wed, 06 Jul 2011 14:55:53 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id fw9sm5084163ibb.30.2011.07.06.14.55.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 14:55:52 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 06 Jul 2011 14:54:21 -0700 From: YongHyeon PYUN Date: Wed, 6 Jul 2011 14:54:21 -0700 To: David Christensen Message-ID: <20110706215421.GC5559@michelle.cdnetworks.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D9115@IRVEXCHCCR01.corp.ad.broadcom.com> <20110706214016.GB5559@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D912B@IRVEXCHCCR01.corp.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385C32D912B@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Mutt/1.4.2.3i Cc: Charles Sprickman , David Christensen , "freebsd-net@freebsd.org" Subject: Re: bce packet loss 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, 06 Jul 2011 21:55:54 -0000 On Wed, Jul 06, 2011 at 02:47:24PM -0700, David Christensen wrote: > > > > Data sheet says IfHCInBadOctets indicates number of octets received > > > > on the interface, including framing characters for packets that > > > > were dropped in the MAC for any reason. > > > > > > The IfHcInBadOctets counter says the controller received X bytes > > > that were bad on the wire (collisions, FCS errors, etc.). A value > > > > I thought that too. But other counters such as FCS, FAE, Collisions, > > Jabbers were all zero. > > > > Also includes frames dropped due to an incorrect destination MAC > address (i.e. perfect MAC filter mismatch). This means the NIC Thanks, that explains it. :-) > received a unicast frame for a MAC address that doesn't match the > NIC's MAC address. Very common on a hub and occurs occasionally > on switches as well. > > Dave > > From owner-freebsd-net@FreeBSD.ORG Wed Jul 6 22:25:35 2011 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 865FD1065670 for ; Wed, 6 Jul 2011 22:25:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 426358FC18 for ; Wed, 6 Jul 2011 22:25:34 +0000 (UTC) Received: by vws18 with SMTP id 18so439475vws.13 for ; Wed, 06 Jul 2011 15:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Eou4W6ty7hMx7a712PX6lrkNzJgF12aqCvZjXsp2qSI=; b=EF+hNsNgn/L3RTfjOrcuMXDIkWD5DBsjvute3QqpS2A6kk4xBFa7B3BS+aqw+Em46f 2zybOH0RJQX20p43lL7Cg/NRlHjx3ezDBlTw+PHWlO7u5cDBLp/DCaqhtiWQbTDpbKlM xlI1vmRFR5L8Eq+QSJqujCVpSsswK2DNtujEM= MIME-Version: 1.0 Received: by 10.52.178.195 with SMTP id da3mr130203vdc.179.1309991134153; Wed, 06 Jul 2011 15:25:34 -0700 (PDT) Received: by 10.52.107.137 with HTTP; Wed, 6 Jul 2011 15:25:34 -0700 (PDT) Date: Wed, 6 Jul 2011 15:25:34 -0700 Message-ID: From: Jack Vogel To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Any experiences with lagg and ixgbe 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, 06 Jul 2011 22:25:35 -0000 Have a customer reporting problems with ixgbe, but investigation has suggested that lagg is the real issue, or the two combined. If anyone out there is using the ixgbe driver with lagg I'd like to hear from you. Thanks all, Jack From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 00:50:27 2011 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 CC3511065670 for ; Thu, 7 Jul 2011 00:50:27 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB348FC1B for ; Thu, 7 Jul 2011 00:50:27 +0000 (UTC) Received: by gwb15 with SMTP id 15so258053gwb.13 for ; Wed, 06 Jul 2011 17:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RoLqT0OYtwxun1jjZx0KiiVUaX/crNPkNoretmQxEv8=; b=FvtgyT5s3dhGZJZWf9ZonRG2HokBSuZMrXFM9XCHyrZuwcihCNFdU0lA3GrPbDGSPy /Nk8NwrhnqBmfqzRDPH96jrV5RClLYj+IkPmd+Xk8SszkTqG+dEoB8ZWjFlAXvcNziKo vwlFtRveXHDcCXqL6LFQfpJSO/yD/xtJhHCIU= MIME-Version: 1.0 Received: by 10.150.180.14 with SMTP id c14mr402817ybf.200.1309999826606; Wed, 06 Jul 2011 17:50:26 -0700 (PDT) Received: by 10.151.111.7 with HTTP; Wed, 6 Jul 2011 17:50:26 -0700 (PDT) In-Reply-To: <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> References: <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> Date: Wed, 6 Jul 2011 17:50:26 -0700 Message-ID: From: Kevin Oberman To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Charles Sprickman Subject: Re: bce packet loss 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, 07 Jul 2011 00:50:27 -0000 On Wed, Jul 6, 2011 at 1:04 PM, Chuck Swiger wrote: > On Jul 6, 2011, at 12:27 PM, Kevin Oberman wrote: >> 1 in 10**6? That is totally excessive. > > It's high for a switched LAN, but I'd imagine you remember collision rate= s on hubs, which might well exceed 1% of the packets when the network is un= der load. > >> The Ethernet spec requires no worse than 10**13 and that is far worse th= an should ever be seen in the real world. At one in a million, any remotely= high volume transfer will crawl, especially over a long path. > > 10 Gigabit ethernet wants cabling spec'ed to a BER of 10e-13; standard gi= gabit ethernet cabling (Cat 5e) supposedly is rated for 10e-10. =A0However,= the BER of the cabling doesn't translate directly into octet error count p= er the NIC statistics, since a bad bit anywhere in a packet causes the enti= re packet to be dropped with a failed checksum. > >> If dropped packets ate being reported, the most common cause is fan-in. = If two input ports are both trying to talk a line rate to a single output p= ort, the buffer will fill an packets will be dropped. Most switches do tail= drop, so queue management is terrible, compounding the effects. > > Yes, I agree with this as a likely cause. Just to try to stamp out old Ethernet myths... Any modern Ethernet should be running full-duplex. The only cases where half-duplex should ever happen is with ancient hardware that does not support full-duplex and when an old hub (not a switch) is used to connect multiple systems. Neither is going to be the case for almost all users. If you are running full-duplex, there are NO collisions, by definition of full-duplex. If you ever see a collision, your end of the link IS half duplex and the other end might well be run full-duplex which produces many errors on the full-duplex end and lots of collisions as well as errors on the half-duplex end. Performance WILL suck, but this does not match the reported symptoms. I am not aware of any switch, router, not NIC that counts FCS (checksum) errors as "drops". Drops are not errors according to 802.The term is normally reserved for clean packets which are thrown away due to the lack of resources to retain them or due to policy (policer, RED, or other queue management technique). I erred in my statement that the Ethernet spec is a BER of 10**-13. It is 10*-12. There was a significant push by several committee members to raise it to 10**-13, but it failed. 10GWE is still 10**-12. I assure your that any WAN link my former network (ESnet) used that exceeded 10**-15 was considered bad and unacceptable. We required continuous transmission for at least 24 hours at a data rate of over 50% of the link speed (e.g. 500Mbps for a 1 Gbps circuit) before a link is accepted. 10**-10 would be rejected in a matter of minutes. Links (often over a thousand miles in length) were seldom rejected. These are, of course, fiber circuits, not twisted-pair. Finally, collisions are simply not errors. They are not counted as errors and do not result in any packet loss. They are simply a normal part of half-duplex operation. Years ago, when coaxial Ethernet the norm, Van Jacobson wrote a short article describing the lack of impact of collisions. He pointed out that in a common pathological case involving the ACK in an FTP transfer always colliding with the transmit of the of the next packet. He measured good-put of over 9Mbps with 100% collisions. (Collision rate is non-intuitive because the maximum collision rate is not 100%, but 1600% because a maximum of 16 collisions are allowed before the transmission attempt stops and an error of excessive collisions is declared. Again, this is just backgound information, not relevant to the issue at hand. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 02:29:22 2011 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 DBF11106564A; Thu, 7 Jul 2011 02:29:22 +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 B53A68FC16; Thu, 7 Jul 2011 02:29:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p672TMBA015420; Thu, 7 Jul 2011 02:29:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p672TMx0015416; Thu, 7 Jul 2011 02:29:22 GMT (envelope-from linimon) Date: Thu, 7 Jul 2011 02:29:22 GMT Message-Id: <201107070229.p672TMx0015416@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158694: [ix] [lagg] ix0 is not working within lagg(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 02:29:23 -0000 Old Synopsis: ix0 is not working within lagg(4) New Synopsis: [ix] [lagg] ix0 is not working within lagg(4) Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jul 7 02:29:04 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=158694 From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 06:00:28 2011 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 4E323106564A for ; Thu, 7 Jul 2011 06:00:28 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 16C2A8FC0A for ; Thu, 7 Jul 2011 06:00:27 +0000 (UTC) Received: (qmail 35306 invoked by uid 0); 7 Jul 2011 06:00:27 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Jul 2011 06:00:27 -0000 Received: (qmail 35298 invoked by uid 90); 7 Jul 2011 06:00:27 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Jul 2011 06:00:27 -0000 Date: Thu, 7 Jul 2011 02:00:26 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: YongHyeon PYUN In-Reply-To: <20110706201509.GA5559@michelle.cdnetworks.com> Message-ID: References: <20110706201509.GA5559@michelle.cdnetworks.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, David Christensen Subject: Re: bce packet loss 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, 07 Jul 2011 06:00:28 -0000 More inline, including a bigger picture of what I'm seeing on some other hosts, but I wanted to thank everyone for all the fascinating ethernet BER info and the final explanation of what the "IfHCInBadOctets" counter represents. Interesting stuff. On Wed, 6 Jul 2011, YongHyeon PYUN wrote: > On Mon, Jul 04, 2011 at 09:32:11PM -0400, Charles Sprickman wrote: >> Hello, >> >> We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) >> and I'm seeing occasional packet loss on them (enough that it trips nagios >> now and then). Cabling seems fine as neither the switch nor the sysctl >> info for the device show any errors/collisions/etc, however there is one >> odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below >> for full sysctl output. The switch shows no errors but for "Dropped >> packets 683868". >> >> pciconf output is also below. [2] >> >> By default, the switch had flow control set to "on". I also let it run >> with "auto". In both cases, the drops continued to increment. I'm now >> running with flow control off to see if that changes anything. >> >> I do see some correlation between cpu usage and drops - I have cpu usage >> graphed in nagios and cacti is graphing the drops on the dell switch. >> There's no signs of running out of mbufs or similar. >> >> So given that limited info, is there anything I can look at to track this >> down? Anything stand out in the stats sysctl exposes? Two things are >> standing out for me - the number of changes in bce regarding flow control >> that are not in 8.1, and the correlation between cpu load and the drops. >> >> What other information can I provide? >> > > You had 282 RX buffer shortages and these frames were dropped. This > may explain why you see occasional packet loss. 'netstat -m' will > show which size of cluster allocation were failed. Nothing of note: 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 > However it seems you have 0 com_no_buffers which indicates > controller was able to receive all packets destined for this host. > You may host lost some packets(i.e. non-zero mbuf_alloc_failed_count) > but your controller and system was still responsive to the network > traffic. OK. I recall seeing a thread in the -net archives where some folks had the "com_no_buffers" incrementing, but I'm not seeing that at all. > Data sheet says IfHCInBadOctets indicates number of octets received > on the interface, including framing characters for packets that > were dropped in the MAC for any reason. I'm not sure this counter > includes packets IfInFramesL2FilterDiscards which indicates number > of good frames that have been dropped due to the L2 perfect match, > broadcast, multicast or MAC control frame filters. If your switch > runs STP it would periodically sends BPDU packets to destination > address of STP multicast address 01:80:C2:00:00:00. Not sure this > is the reason though. Probably David can explain more details on > IfHCInBadOctets counter(CCed). Again, thanks for that. If I could just ask for a bit more assistance, it would be greatly appreciated. I collected a fair bit of data and it's done nothing but complicate the issue for me so far. -If I'm reading the switch stats correctly, most of my drops are host->switch, although I'm not certain of that, these Dell 2848s have no real cli interface to speak of. -I'm seeing similar drops, but not quite so bad, on other hosts. They all use the em interface but for one other with bge. This particular host (with the bce interface) just seems to get bad enough to trigger nagios alerts (simple ping check from a host on the same switch/subnet). All these hosts are forced to 100/FD as is the switch. The switch is our external (internet facing) switch with a 100Mb connection to our upstream. At *peak* our aggregate bandwidth on this switch is maybe 45Mb/s, most of it outbound. We are nowhere near saturating the switching fabric (I hope). -There are three reasons I set the ports at 100baseTX - the old Cisco that lost a few ports was a 10/100 switch and the hosts were already hard-coded for 100/FD, I figured if the Dell craps out I can toss the Cisco back without changing the speed/duplex on all the hosts, and lastly our uplink is only 100/FD so why bother. Also maybe some vague notion that I'd not use up some kind of buffers in the switch by matching the speed on all ports... -We have an identical switch (same model, same hardware rev, same firmware) for our internal network (lots of log analysis over nfs mounts, a ton of internal dns (upwards of 10K queries/sec at peak), and occasional large file transfers. On this host and all others, the dropped packet count on the switch ports is at worst around 5000 packets. The counters have not been reset on it and it's been up for 460 days. -A bunch of legacy servers that have fxp interfaces on the external switch and em on the internal switch show *no* significant drops nor do the switch ports they are connected to. -To see if forcing the ports to 100/FD was causing a problem, I set the host and switch to 1000/FD. Over roughly 24 hours, the switch is reporting 197346 dropped packets of 52166986 packets received. -Tonight's change was to turn off spanning tree. This is a long shot based on some Dell bug I saw discussed on their forums. Given our simple network layout, I don't really see spanning tree as being at all necessary. One of the first replies I got to my original post was private and amounted to "Dell is garbage". That may be true, but the excellent performance on the more heavily loaded internal network makes me doubt there's a fundamental shortcoming in the switch. It would have to be real garbage to crap out with a combined load of 45Mb/s. I am somewhat curious if some weird buffering issue is possible with a mix of 100/FD and 1000/FD ports. Any thoughts on that? It's the only thing that differs between the two switches. Before replacing the switch I'm also going to cycle through turning off TSO, rxcsum, and txcsum since it seems that has been a fix for some people with otherwise unexplained network issues. I assume those features all depend on the firmware of the NIC being bug-free, and I'm not quite ready to accept that. Thanks, Charles From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 07:07:20 2011 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 E876E106566C; Thu, 7 Jul 2011 07:07:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C0EB98FC14; Thu, 7 Jul 2011 07:07:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p6777Krc079787; Thu, 7 Jul 2011 07:07:20 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p6777JrO079783; Thu, 7 Jul 2011 07:07:20 GMT (envelope-from dougb) Date: Thu, 7 Jul 2011 07:07:20 GMT Message-Id: <201107070707.p6777JrO079783@freefall.freebsd.org> To: msl@procergs.rs.gov.br, dougb@FreeBSD.org, freebsd-net@FreeBSD.org, dougb@FreeBSD.org From: dougb@FreeBSD.org Cc: Subject: Re: kern/54383: [nfs] [patch] NFS root configurations without dynamic protocols: dhcp, bootp, etc... 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, 07 Jul 2011 07:07:21 -0000 Synopsis: [nfs] [patch] NFS root configurations without dynamic protocols: dhcp, bootp, etc... State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Thu Jul 7 07:06:58 UTC 2011 State-Changed-Why: 1. Old, unsupported FreeBSD version 2. Likely OBE Responsible-Changed-From-To: freebsd-net->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Thu Jul 7 07:06:58 UTC 2011 Responsible-Changed-Why: I closed it http://www.freebsd.org/cgi/query-pr.cgi?pr=54383 From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 07:32:30 2011 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 8E923106566C; Thu, 7 Jul 2011 07:32:30 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 674B58FC08; Thu, 7 Jul 2011 07:32:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p677WUGe021997; Thu, 7 Jul 2011 07:32:30 GMT (envelope-from dougb@freefall.freebsd.org) Received: (from dougb@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p677WUlU021985; Thu, 7 Jul 2011 07:32:30 GMT (envelope-from dougb) Date: Thu, 7 Jul 2011 07:32:30 GMT Message-Id: <201107070732.p677WUlU021985@freefall.freebsd.org> To: j.witteveen@gmail.com, dougb@FreeBSD.org, freebsd-net@FreeBSD.org, dougb@FreeBSD.org From: dougb@FreeBSD.org Cc: Subject: Re: conf/128334: [request] use wpa_cli in the "WPA DHCP" situation 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, 07 Jul 2011 07:32:30 -0000 Synopsis: [request] use wpa_cli in the "WPA DHCP" situation State-Changed-From-To: open->closed State-Changed-By: dougb State-Changed-When: Thu Jul 7 07:31:57 UTC 2011 State-Changed-Why: Originator reports this is fixed Responsible-Changed-From-To: freebsd-net->dougb Responsible-Changed-By: dougb Responsible-Changed-When: Thu Jul 7 07:31:57 UTC 2011 Responsible-Changed-Why: I closed it http://www.freebsd.org/cgi/query-pr.cgi?pr=128334 From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 09:01:04 2011 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 32E8D106564A for ; Thu, 7 Jul 2011 09:01:04 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 14E958FC15 for ; Thu, 7 Jul 2011 09:01:04 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p6790xw8080788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2011 02:01:00 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p6790xS7080787; Thu, 7 Jul 2011 02:00:59 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA23423; Thu, 7 Jul 11 01:51:27 PDT Date: Thu, 07 Jul 2011 08:52:12 -0700 From: perryh@pluto.rain.com To: kob6558@gmail.com Message-Id: <4e15d62c.nkl6i2oVCMDWLBPl%perryh@pluto.rain.com> References: <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> In-Reply-To: User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, spork@bway.net Subject: size-dependent packet loss (Re: bce packet loss) 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, 07 Jul 2011 09:01:04 -0000 Kevin Oberman wrote: > ... Years ago, when coaxial Ethernet the norm ... Aha! Another old-timer who has been around long enough to remember 10Mb Ethernet! Maybe something in the following will ring a bell? I have a (to me) very strange problem, for which I have a usable workaround but no actual solution, when I try to send "large" packets from an ancient Sun-3/50 (or 3/60, the same thing happens with either) through any hub I have ever tried to connect it to: * Packets up to about 750 or 800 bytes get through just fine, but the loss rate goes up sharply as size increases beyond that and reaches 100% somewhere around 900 or 950 bytes. (A hub that is smart enough to show such things logs a "late collision" error when it drops one of these large-ish packets.) * The problem does not seem to be related to high overall data rate: it arises even sending only one packet per second (e.g. ping). The obvious explanation is "physical layer problems", e.g. bad 10Base2 termination, but that does not hold up under investigation: * There is no problem _receiving_ large packets via the same connection: I can FTP an arbitrarily large file from an i386 (running either FreeBSD or Windows) through the hub _to_ the Sun box, but an attempt to FTP a 1KB file _from_ the Sun through the hub will never complete because the data packet is always dropped (unless I arrange to set the MTU to, say, 640 bytes so that large packets aren't used). It does not matter which end is controlling the FTP session: a "put" issued from the Sun or a "get" issued from the i386 -- either of which transfers the file from the Sun to the i386 -- will fail; a "get" from the Sun or a "put" from the i386 will work (transferring the file in the other direction). * If I move the 10Base2 tee connector from the hub to a 10Base2 port on the i386, so that the Sun and i386 boxes are connected directly by 10Base2 and no hub is involved, everything works properly in both directions. This pretty well eliminates cabling/termination as a factor. (Of course, this approach requires the i386 to have a 10Base2 connection; most of mine are new enough that they don't.) * It does not matter if the connection from the Sun-3 to the hub is made via coax using the built-in 10Base2 transceiver, coax using an external transceiver, or 10BaseT (necessarily using an external transceiver, since these Suns have only AUI and 10Base2 built in); nor does it seem to matter what brand of hub is used or even whether it is 10Mb-only or 10/100. Nor does it seem possible to blame the hub: I've tried several, of different brands, and all behave the same way; and there's no problem communicating among i386 systems through any of these hubs. Restricting the MTU to 640, and the NFS read and write data sizes (which must be a power of 2) to 512, is a usable workaround, but I would really like to understand what is going on! From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 10:47:14 2011 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 982751065678 for ; Thu, 7 Jul 2011 10:47:14 +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 EE5218FC14 for ; Thu, 7 Jul 2011 10:47:13 +0000 (UTC) Received: (qmail 59084 invoked from network); 7 Jul 2011 09:46:43 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Jul 2011 09:46:43 -0000 Message-ID: <4E158EB3.80203@freebsd.org> Date: Thu, 07 Jul 2011 12:47:15 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mikolaj Golub References: <867h7zxvd2.fsf@kopusha.home.net> In-Reply-To: <867h7zxvd2.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: issues with O_NONBLOCK 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, 07 Jul 2011 10:47:14 -0000 On 03.07.2011 17:00, Mikolaj Golub wrote: > Hi, Hi Mikolaj, > Trying soreceive_stream I found that many applications (like firefox, pidgin, > gnus) might hang in soreceive_stream/sbwait. Many thanks for testing soreceive_stream. > It was shown up that the issue was with O_NONBLOCK connections -- they blocked > in recv() when should not have been. > > This can be checked with this simple test: > > http://people.freebsd.org/~trociny/test_nonblock.c > > In soreceive_stream we have the following code that looks wrong: > > 1968 /* Socket buffer is empty and we shall not block. */ > 1969 if (sb->sb_cc == 0&& > 1970 ((sb->sb_flags& SS_NBIO) || (flags& (MSG_DONTWAIT|MSG_NBIO)))) { > 1971 error = EAGAIN; > 1972 goto out; > 1973 } > > It should check so->so_state agains SS_NBIO, not sb->sb_flags. But just Indeed. > changing this is not enough. This check is called too early -- before checking > that socket state is not SBS_CANTRCVMORE. As a result, if the peer closes the > connection recv() returns EAGAIN instead of 0. See this example: > > http://people.freebsd.org/~trociny/test_close.c > > So I moved the "nonblock" check below SBS_CANTRCVMORE check and ended up with > this patch: > > http://people.freebsd.org/~trociny/uipc_socket.c.soreceive_stream.patch > > It works for me fine. OK. > Also, this part looks wrong: > > 1958 /* We will never ever get anything unless we are connected. */ > 1959 if (!(so->so_state& (SS_ISCONNECTED|SS_ISDISCONNECTED))) { > 1960 /* When disconnecting there may be still some data left. */ > 1961 if (sb->sb_cc> 0) > 1962 goto deliver; > 1963 if (!(so->so_state& SS_ISDISCONNECTED)) > 1964 error = ENOTCONN; > 1965 goto out; > 1966 } > > Why we check in 1959 that state is not SS_ISDISCONNECTED? If it is valid then > the check at 1963 is useless becase it will be always true. Shouldn't it be > something like below? > > if (!(so->so_state& (SS_ISCONNECTED|SS_ISCONNECTING))) { > /* When disconnecting there may be still some data left. */ > if (sb->sb_cc> 0) > goto deliver; > error = ENOTCONN; > goto out; > } > > (I don't see why we souldn't set ENOTCONN if the state is SS_ISDISCONNECTED). ENOTCONN is only valid in the beginning of the connection. When we reach SS_INDISCONNECTED the connection was connected before and we have to return a 0-read to signal EOF. It can be simplified by immediately setting the error and going out. The other cases can't ever be true. Please try this patch: http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 I can't fully test it myself due to being 1000km from my development machine and having only limited hw access for rebooting. > And the last :-). Currently, to try soreceive_stream one need to rebuild kernel > with TCP_SORECEIVE_STREAM and then set tunable net.inet.tcp.soreceive_stream. > Why do we need TCP_SORECEIVE_STREAM option? Wouldn't tunable be enough? It > would simplify trying soreceive_stream by users and we might have more > testing/feedback. Done. See r223839. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 12:00:51 2011 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 3D08D1065672; Thu, 7 Jul 2011 12:00:51 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 15A688FC23; Thu, 7 Jul 2011 12:00:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p67C0o89075978; Thu, 7 Jul 2011 12:00:50 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p67C0oiY075971; Thu, 7 Jul 2011 12:00:50 GMT (envelope-from ae) Date: Thu, 7 Jul 2011 12:00:50 GMT Message-Id: <201107071200.p67C0oiY075971@freefall.freebsd.org> To: aboyer@averesystems.com, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/154831: [arp] [patch] arp sysctl setting log_arp_permanent_modify has no effect 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, 07 Jul 2011 12:00:51 -0000 Synopsis: [arp] [patch] arp sysctl setting log_arp_permanent_modify has no effect State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Thu Jul 7 12:00:18 UTC 2011 State-Changed-Why: Committed to head/. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=154831 From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 12:05:33 2011 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 344E0106566C for ; Thu, 7 Jul 2011 12:05:33 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront4.g2host.com [208.42.184.242]) by mx1.freebsd.org (Postfix) with ESMTP id E291C8FC14 for ; Thu, 7 Jul 2011 12:05:32 +0000 (UTC) Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 18847190 for freebsd-net@freebsd.org; Thu, 07 Jul 2011 06:45:31 -0500 Message-ID: <4E159C5A.5090702@visi.com> Date: Thu, 07 Jul 2011 06:45:30 -0500 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Is-From-Me: yes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Debugging dropped shell connections over a VPN 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, 07 Jul 2011 12:05:33 -0000 Hello, I am having problems with dropped shell connections over a VPN and I need help diagnosing the problem. My setup is something like this: - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines running various OS versions. - My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw, nat and racoon for the firewall and VPN. The problem is that rlogin, ssh and telnet connections over the VPN get dropped after some period of inactivity. My initial thought was that the disconnect was being caused by an idle timeout on the remote side of the VPN but I checked with the administrator and that is not the case. The idle timeout is set to something like 8 hours. The amount of idle time before a shell connection is dropped seems to vary from less than five minutes to more than half an hour more or less randomly or at best depending on prevailing winds. It is difficult to determine exactly when the connection is dropped because I don't know it has been dropped until I try to type something into the remote shell and then I get an error message and the connection is closed. The error message depends on the type of connection: rlogin: Read error from network: Connection reset by peer ssh: Write failed: Broken pipe telnet: Connection to ilt1000.eur.ad.sag closed by foreign host. Running a script to generate output every 60 seconds on the remote shell will keep the connection up most of the time but connections do get dropped even with the script running. I am pretty sure this is a VPN related issue. I have not had problems with shell connections that don't go over the VPN. When my ISP still had a UNIX shell host available, I used to leave shell sessions open to it for weeks at a time. I have had these same problems with two separate employers and three different remote VPN setups. So, what I'm looking for is some way to figure out what the cause of the disconnects is and a way to fix it. Any suggestions gladly accepted. -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 12:10:12 2011 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 AD3981065675 for ; Thu, 7 Jul 2011 12:10: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 9DDBB8FC13 for ; Thu, 7 Jul 2011 12:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p67CACfZ083462 for ; Thu, 7 Jul 2011 12:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p67CACUZ083461; Thu, 7 Jul 2011 12:10:12 GMT (envelope-from gnats) Date: Thu, 7 Jul 2011 12:10:12 GMT Message-Id: <201107071210.p67CACUZ083461@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/154831: 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: Thu, 07 Jul 2011 12:10:12 -0000 The following reply was made to PR kern/154831; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154831: commit references a PR Date: Thu, 7 Jul 2011 12:00:34 +0000 (UTC) Author: ae Date: Thu Jul 7 11:59:51 2011 New Revision: 223840 URL: http://svn.freebsd.org/changeset/base/223840 Log: Add again the checking for log_arp_permanent_modify that was by accident removed in the r186119. PR: kern/154831 MFC after: 1 week Modified: head/sys/netinet/if_ether.c Modified: head/sys/netinet/if_ether.c ============================================================================== --- head/sys/netinet/if_ether.c Thu Jul 7 10:37:14 2011 (r223839) +++ head/sys/netinet/if_ether.c Thu Jul 7 11:59:51 2011 (r223840) @@ -694,11 +694,13 @@ match: bcmp(ar_sha(ah), &la->ll_addr, ifp->if_addrlen)) { if (la->la_flags & LLE_STATIC) { LLE_WUNLOCK(la); - log(LOG_ERR, - "arp: %*D attempts to modify permanent " - "entry for %s on %s\n", - ifp->if_addrlen, (u_char *)ar_sha(ah), ":", - inet_ntoa(isaddr), ifp->if_xname); + if (log_arp_permanent_modify) + log(LOG_ERR, + "arp: %*D attempts to modify " + "permanent entry for %s on %s\n", + ifp->if_addrlen, + (u_char *)ar_sha(ah), ":", + inet_ntoa(isaddr), ifp->if_xname); goto reply; } if (log_arp_movements) { _______________________________________________ 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 Thu Jul 7 12:34:34 2011 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 8119A1065673; Thu, 7 Jul 2011 12:34:34 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 59B0A8FC0A; Thu, 7 Jul 2011 12:34:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p67CYYlq013370; Thu, 7 Jul 2011 12:34:34 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p67CYYnS013351; Thu, 7 Jul 2011 12:34:34 GMT (envelope-from ae) Date: Thu, 7 Jul 2011 12:34:34 GMT Message-Id: <201107071234.p67CYYnS013351@freefall.freebsd.org> To: morganw@chemikals.org, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: bin/137841: [patch] wpa_supplicant(8) cannot verify SHA256 signed certificates 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, 07 Jul 2011 12:34:34 -0000 Synopsis: [patch] wpa_supplicant(8) cannot verify SHA256 signed certificates State-Changed-From-To: open->patched State-Changed-By: ae State-Changed-When: Thu Jul 7 12:31:23 UTC 2011 State-Changed-Why: This issue was fixed in head/ with r214734. http://www.freebsd.org/cgi/query-pr.cgi?pr=137841 From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 15:38:02 2011 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 9369C1065670 for ; Thu, 7 Jul 2011 15:38:02 +0000 (UTC) (envelope-from adrian.minta@gmail.com) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx1.freebsd.org (Postfix) with ESMTP id 221E08FC08 for ; Thu, 7 Jul 2011 15:38:01 +0000 (UTC) Received: by bwb17 with SMTP id 17so1735956bwb.17 for ; Thu, 07 Jul 2011 08:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mnkP4vU94YZhe7yIQiKobu/JcEqYGBDDUhwbEyihiFw=; b=rVrujmTd354jKpCp/HrF8orH9Yg3JyaA+ONBa5OteS+MJ0JX92RcPBUXo65JtdD7W2 70BjNxBKw4EFlJDapnVmQyCyYwofRd+OWKxsdd2e5UrqyCbPlMLNcpt14imuBApCdmbg 2kfPcK6GyvsxMH2YhKialYSwLK5HwJCuwc8sE= Received: by 10.204.75.71 with SMTP id x7mr821189bkj.22.1310051283903; Thu, 07 Jul 2011 08:08:03 -0700 (PDT) Received: from [192.168.10.10] ([188.26.159.147]) by mx.google.com with ESMTPS id t9sm8628428bkn.8.2011.07.07.08.08.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 08:08:02 -0700 (PDT) Message-ID: <4E15CBD1.2060607@gmail.com> Date: Thu, 07 Jul 2011 18:08:01 +0300 From: Adrian Minta User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20110706201509.GA5559@michelle.cdnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: bce packet loss 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, 07 Jul 2011 15:38:04 -0000 Broadcom bce nics are trash. I see the same packet loss on linux as weel. The best solution is add/replace with another brand. From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 17:44:07 2011 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 C11E11065672; Thu, 7 Jul 2011 17:44:07 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9628FC15; Thu, 7 Jul 2011 17:44:07 +0000 (UTC) Received: by iyb11 with SMTP id 11so1421160iyb.13 for ; Thu, 07 Jul 2011 10:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=KjgrOEfUPL+PWOK5Rnw25V5fEH9rbaWVjBIMnY5BUdI=; b=l2Fn5ymJUQoPk5YlyRqvDXrN4neZrDn4tb6uCmTSxkrS6VRbnzyzjYEl/PO4JLZcEV BO7xyXofOP2Ej3Q2tdYs4ihtUMosyITeLLfYVPb3E7CHkbjhLHiAKDTLiCz3WYgoIiZx cPaW3cJ5CqxwZSG5THep8YrsVNqFEUWOhEt9w= Received: by 10.231.124.167 with SMTP id u39mr885719ibr.103.1310060646472; Thu, 07 Jul 2011 10:44:06 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b6sm2827515ibg.14.2011.07.07.10.44.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 10:44:05 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 07 Jul 2011 10:42:33 -0700 From: YongHyeon PYUN Date: Thu, 7 Jul 2011 10:42:33 -0700 To: Charles Sprickman Message-ID: <20110707174233.GB8702@michelle.cdnetworks.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, David Christensen Subject: Re: bce packet loss 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, 07 Jul 2011 17:44:07 -0000 On Thu, Jul 07, 2011 at 02:00:26AM -0400, Charles Sprickman wrote: > More inline, including a bigger picture of what I'm seeing on some other > hosts, but I wanted to thank everyone for all the fascinating ethernet BER > info and the final explanation of what the "IfHCInBadOctets" counter > represents. Interesting stuff. > > On Wed, 6 Jul 2011, YongHyeon PYUN wrote: > > >On Mon, Jul 04, 2011 at 09:32:11PM -0400, Charles Sprickman wrote: > >>Hello, > >> > >>We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) > >>and I'm seeing occasional packet loss on them (enough that it trips nagios > >>now and then). Cabling seems fine as neither the switch nor the sysctl > >>info for the device show any errors/collisions/etc, however there is one > >>odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below > >>for full sysctl output. The switch shows no errors but for "Dropped > >>packets 683868". > >> > >>pciconf output is also below. [2] > >> > >>By default, the switch had flow control set to "on". I also let it run > >>with "auto". In both cases, the drops continued to increment. I'm now > >>running with flow control off to see if that changes anything. > >> > >>I do see some correlation between cpu usage and drops - I have cpu usage > >>graphed in nagios and cacti is graphing the drops on the dell switch. > >>There's no signs of running out of mbufs or similar. > >> > >>So given that limited info, is there anything I can look at to track this > >>down? Anything stand out in the stats sysctl exposes? Two things are > >>standing out for me - the number of changes in bce regarding flow control > >>that are not in 8.1, and the correlation between cpu load and the drops. > >> > >>What other information can I provide? > >> > > > >You had 282 RX buffer shortages and these frames were dropped. This > >may explain why you see occasional packet loss. 'netstat -m' will > >show which size of cluster allocation were failed. > > Nothing of note: > > 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 > Hmm... it's strange, I can't explain how you have non-zero mbuf_alloc_failed_count. > >However it seems you have 0 com_no_buffers which indicates > >controller was able to receive all packets destined for this host. > >You may host lost some packets(i.e. non-zero mbuf_alloc_failed_count) > >but your controller and system was still responsive to the network > >traffic. > > OK. I recall seeing a thread in the -net archives where some folks had > the "com_no_buffers" incrementing, but I'm not seeing that at all. > > >Data sheet says IfHCInBadOctets indicates number of octets received > >on the interface, including framing characters for packets that > >were dropped in the MAC for any reason. I'm not sure this counter > >includes packets IfInFramesL2FilterDiscards which indicates number > >of good frames that have been dropped due to the L2 perfect match, > >broadcast, multicast or MAC control frame filters. If your switch > >runs STP it would periodically sends BPDU packets to destination > >address of STP multicast address 01:80:C2:00:00:00. Not sure this > >is the reason though. Probably David can explain more details on > >IfHCInBadOctets counter(CCed). > > Again, thanks for that. > > If I could just ask for a bit more assistance, it would be greatly > appreciated. I collected a fair bit of data and it's done nothing but > complicate the issue for me so far. > > -If I'm reading the switch stats correctly, most of my drops are > host->switch, although I'm not certain of that, these Dell 2848s have no IfHCInBadOctets is counter for RX(i.e. switch->host). And TX hardware MAC counters showed no error at all. > real cli interface to speak of. > > -I'm seeing similar drops, but not quite so bad, on other hosts. They all > use the em interface but for one other with bge. This particular host > (with the bce interface) just seems to get bad enough to trigger nagios > alerts (simple ping check from a host on the same switch/subnet). All > these hosts are forced to 100/FD as is the switch. The switch is our > external (internet facing) switch with a 100Mb connection to our upstream. > At *peak* our aggregate bandwidth on this switch is maybe 45Mb/s, most of > it outbound. We are nowhere near saturating the switching fabric (I > hope). > > -There are three reasons I set the ports at 100baseTX - the old Cisco that > lost a few ports was a 10/100 switch and the hosts were already hard-coded > for 100/FD, I figured if the Dell craps out I can toss the Cisco back > without changing the speed/duplex on all the hosts, and lastly our uplink > is only 100/FD so why bother. Also maybe some vague notion that I'd not > use up some kind of buffers in the switch by matching the speed on all > ports... > > -We have an identical switch (same model, same hardware rev, same > firmware) for our internal network (lots of log analysis over nfs mounts, > a ton of internal dns (upwards of 10K queries/sec at peak), and occasional > large file transfers. On this host and all others, the dropped packet > count on the switch ports is at worst around 5000 packets. The counters > have not been reset on it and it's been up for 460 days. > > -A bunch of legacy servers that have fxp interfaces on the external switch > and em on the internal switch show *no* significant drops nor do > the switch ports they are connected to. > > -To see if forcing the ports to 100/FD was causing a problem, I set the > host and switch to 1000/FD. Over roughly 24 hours, the switch is > reporting 197346 dropped packets of 52166986 packets received. > > -Tonight's change was to turn off spanning tree. This is a long shot > based on some Dell bug I saw discussed on their forums. Given our simple > network layout, I don't really see spanning tree as being at all > necessary. > > One of the first replies I got to my original post was private and > amounted to "Dell is garbage". That may be true, but the excellent > performance on the more heavily loaded internal network makes me doubt > there's a fundamental shortcoming in the switch. It would have to be real > garbage to crap out with a combined load of 45Mb/s. I am somewhat curious > if some weird buffering issue is possible with a mix of 100/FD and 1000/FD > ports. > > Any thoughts on that? It's the only thing that differs between the two > switches. > This makes me think possibility of duplex mismatch between bce(4) and link partner. You should not use forced media configuration on 1000baseT link. If you used manual media configuration on bce(4) and link partner used auto-negotiation, resolved duplex would be half-duplex. It's standard behavior and Duplex mismatch can cause strange problems. I would check whether link partner also agrees on the resolved speed/duplex of bce(4). > Before replacing the switch I'm also going to cycle through turning off > TSO, rxcsum, and txcsum since it seems that has been a fix for some people > with otherwise unexplained network issues. I assume those features all > depend on the firmware of the NIC being bug-free, and I'm not quite ready > to accept that. > It's worth to try but I wonder how it can explain ICMP ECHO request packet loss. > Thanks, > > Charles From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 18:05:07 2011 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 12069106566C for ; Thu, 7 Jul 2011 18:05:07 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id E685C8FC0C for ; Thu, 7 Jul 2011 18:05:06 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LNZ00M6U67A6DA0@asmtp024.mac.com> for freebsd-net@freebsd.org; Thu, 07 Jul 2011 11:04:22 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-07_07:2011-07-07, 2011-07-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107070140 From: Chuck Swiger In-reply-to: Date: Thu, 07 Jul 2011 11:04:22 -0700 Message-id: References: <7575C8FD-4E99-4A27-833F-312230078E9E@mac.com> To: Kevin Oberman X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Charles Sprickman Subject: Re: bce packet loss 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, 07 Jul 2011 18:05:07 -0000 On Jul 6, 2011, at 5:50 PM, Kevin Oberman wrote: [ ... ] > Any modern Ethernet should be running full-duplex. Sure. With a price point of ~$10 per port for unmanaged gigabit switches nowadays, this is cheap enough that it's widely deployed even for SOHO and small offices. Also, I don't believe many vendors are even making ethernet hubs anymore.... > I am not aware of any switch, router, not NIC that counts FCS > (checksum) errors as "drops". Drops are not errors > according to 802. When a packet is received by the network stack and the various checksums at the ethernet frame (ie, the FCS field), IP header, and higher level protocol like UDP/TCP/etc are checked, the packet is dropped if the various checksums doesn't validate. A checksum error is not the same thing as dropping a packet due to resource constraints, as you mention: > The term is normally reserved for clean packets which > are thrown away due to the lack of > resources to retain them or due to policy (policer, RED, or other > queue management technique). ...so I gather you would prefer the phrase "the packet is discarded if a checksum doesn't validate"? [ ... ] > Finally, collisions are simply not errors. They are not counted as > errors and do not result in any packet loss. They are simply a normal > part of half-duplex operation. Normal collisions are an expected part of half-duplex operation, and the NIC takes responsibility for retransmitting the packet after a randomized delay without involving higher parts of the network stack. Late collisions aren't expected, however, and the NIC doesn't take responsibility for retransmitting the packet. > Years ago, when coaxial Ethernet the > norm, Van Jacobson wrote a short article describing the lack of impact > of collisions. He pointed out that in a common pathological case > involving the ACK in an FTP transfer always colliding with the > transmit of the of the next packet. He measured good-put of over 9Mbps > with 100% collisions. (Collision rate is non-intuitive because the > maximum collision rate is not 100%, but 1600% because a maximum of 16 > collisions are allowed before the transmission attempt stops and an > error of excessive collisions is declared. Again, this is just > backgound information, not relevant to the issue at hand. Yes, although the impact of collisions against an FTP data stream is a best-case scenario, as the FTP data packets are almost all going to be at the size of the MTU. If there's a collision, it should noticed during the first 64 octets as expected, whereas a clean transmission gets 1500 bytes of data through. Even with 10 collisions for each 1500 byte data packet going though, you'd probably still get around 7Mbps. Redo the experiment with 64-byte ICMP flood ping (or 84 bytes if you want to count the 802.3 preamble and frame gap), and such a high collision rate will have a much more noticeable impact. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 18:11:44 2011 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 65FEA106566B; Thu, 7 Jul 2011 18:11:44 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by mx1.freebsd.org (Postfix) with ESMTP id 372B08FC08; Thu, 7 Jul 2011 18:11:43 +0000 (UTC) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 07 Jul 2011 11:14:19 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 7 Jul 2011 11:09:31 -0700 From: "David Christensen" To: "pyunyh@gmail.com" , "Charles Sprickman" Date: Thu, 7 Jul 2011 11:09:30 -0700 Thread-Topic: bce packet loss Thread-Index: Acw8zX/W9Qq7wyF4Q+2VJIhJOlMN2AAAb8eA Message-ID: <5D267A3F22FD854F8F48B3D2B523819385C32D9347@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> In-Reply-To: <20110707174233.GB8702@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 620B28F162O20917716-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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, 07 Jul 2011 18:11:44 -0000 > > Any thoughts on that? It's the only thing that differs between the > two > > switches. > > >=20 > This makes me think possibility of duplex mismatch between bce(4) > and link partner. You should not use forced media configuration on > 1000baseT link. If you used manual media configuration on bce(4) > and link partner used auto-negotiation, resolved duplex would be > half-duplex. It's standard behavior and Duplex mismatch can cause > strange problems. > I would check whether link partner also agrees on the resolved > speed/duplex of bce(4). Forced link speed at 1000Mbps is not supported by the IEEE specification, you MUST use auto-negotiation at 1000Mbps (though you can advertise support for 1000Mb only to simulate forced operation). =20 Duplex mismatch usually manifests with collision/deferred=20 transmission errors on the link partner configured for=20 half-duplex. The bce(4) driver does support those statistics. Dave From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 19:25:00 2011 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 CC39B106566B; Thu, 7 Jul 2011 19:25:00 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C7EE08FC1C; Thu, 7 Jul 2011 19:24:59 +0000 (UTC) Received: by bwa20 with SMTP id 20so1607680bwa.13 for ; Thu, 07 Jul 2011 12:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=BZbWk4kPnSr3ekaSvmU5Y9V7JDoO3937rU1TWdwa8lk=; b=nXEHNtYJjUUKEaif42RwM1j0b4oU/DnqiVCyEe9imiVPA8OVMM+xTzgxWorUZ5PlF1 gVnd23Igy4pwW11t0jIELJca4rLmWWOtyVt/jBjsSuvMG8fPzlOyc+eQcpLJyMc/OApK rZtoESlS2kjTZzr51ETRF43xa11UQsqiQcDK8= Received: by 10.204.14.130 with SMTP id g2mr695bka.152.1310066698296; Thu, 07 Jul 2011 12:24:58 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id m6sm4899794fac.1.2011.07.07.12.24.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 12:24:56 -0700 (PDT) From: Mikolaj Golub To: Andre Oppermann References: <867h7zxvd2.fsf@kopusha.home.net> <4E158EB3.80203@freebsd.org> X-Comment-To: Andre Oppermann Date: Thu, 07 Jul 2011 22:24:53 +0300 In-Reply-To: <4E158EB3.80203@freebsd.org> (Andre Oppermann's message of "Thu, 07 Jul 2011 12:47:15 +0200") Message-ID: <86iprd99mi.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (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: issues with O_NONBLOCK 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, 07 Jul 2011 19:25:00 -0000 On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: AO> Please try this patch: AO> http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 It works for me. No issues detected so far. Thanks. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 19:40:05 2011 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 0E0E1106564A for ; Thu, 7 Jul 2011 19:40:05 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id DFF828FC0C for ; Thu, 7 Jul 2011 19:40:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNZ007ATAM7RI20@asmtp028.mac.com> for freebsd-net@freebsd.org; Thu, 07 Jul 2011 12:39:43 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-07_08:2011-07-07, 2011-07-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107070160 From: Chuck Swiger In-reply-to: <4E159C5A.5090702@visi.com> Date: Thu, 07 Jul 2011 12:39:42 -0700 Message-id: <13D65A4C-F874-4970-A070-AA0392416680@mac.com> References: <4E159C5A.5090702@visi.com> To: Paul Keusemann X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Debugging dropped shell connections over a VPN 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, 07 Jul 2011 19:40:05 -0000 On Jul 7, 2011, at 4:45 AM, Paul Keusemann wrote: > My setup is something like this: > - My local network is a mix of AIX, HP-UX, Linux, FreeBSD and Solaris machines running various OS versions. > - My gateway / firewall machine is running FreeBSD-8.1-RELEASE-p1 with ipfw, nat and racoon for the firewall and VPN. > > The problem is that rlogin, ssh and telnet connections over the VPN get dropped after some period of inactivity. You're probably getting NAT timeouts against the VPN connection if it is left idle. racoon ought to have a config setting called natt_keepalive which sends periodic keepalives-- see whether that's disabled. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Jul 7 20:10:03 2011 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 894241065676 for ; Thu, 7 Jul 2011 20:10:03 +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 75CFC8FC22 for ; Thu, 7 Jul 2011 20:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p67KA3s1026555 for ; Thu, 7 Jul 2011 20:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p67KA3k6026554; Thu, 7 Jul 2011 20:10:03 GMT (envelope-from gnats) Date: Thu, 7 Jul 2011 20:10:03 GMT Message-Id: <201107072010.p67KA3k6026554@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/156978: 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: Thu, 07 Jul 2011 20:10:03 -0000 The following reply was made to PR kern/156978; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/156978: commit references a PR Date: Thu, 7 Jul 2011 20:02:22 +0000 (UTC) Author: thompsa Date: Thu Jul 7 20:02:09 2011 New Revision: 223846 URL: http://svn.freebsd.org/changeset/base/223846 Log: Grab the rlock before checking if our interface is enabled, it could be possible to hit a dead pointer when changing interfaces. PR: kern/156978 Submitted by: Andrew Boyer MFC after: 1 week Modified: head/sys/net/if_lagg.c Modified: head/sys/net/if_lagg.c ============================================================================== --- head/sys/net/if_lagg.c Thu Jul 7 18:07:03 2011 (r223845) +++ head/sys/net/if_lagg.c Thu Jul 7 20:02:09 2011 (r223846) @@ -1221,14 +1221,15 @@ lagg_input(struct ifnet *ifp, struct mbu struct lagg_softc *sc = lp->lp_softc; struct ifnet *scifp = sc->sc_ifp; + LAGG_RLOCK(sc); if ((scifp->if_drv_flags & IFF_DRV_RUNNING) == 0 || (lp->lp_flags & LAGG_PORT_DISABLED) || sc->sc_proto == LAGG_PROTO_NONE) { + LAGG_RUNLOCK(sc); m_freem(m); return (NULL); } - LAGG_RLOCK(sc); ETHER_BPF_MTAP(scifp, m); m = (*sc->sc_input)(sc, lp, m); _______________________________________________ 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 Thu Jul 7 22:09:05 2011 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 1C038106564A; Thu, 7 Jul 2011 22:09:05 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E8CE98FC08; Thu, 7 Jul 2011 22:09:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p67M94Co039378; Thu, 7 Jul 2011 22:09:04 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p67M94JJ039374; Thu, 7 Jul 2011 22:09:04 GMT (envelope-from bz) Date: Thu, 7 Jul 2011 22:09:04 GMT Message-Id: <201107072209.p67M94JJ039374@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-virtualization@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/158686: [patch] [tap] Add VIMAGE support to if_tap 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, 07 Jul 2011 22:09:05 -0000 Synopsis: [patch] [tap] Add VIMAGE support to if_tap Responsible-Changed-From-To: freebsd-net->freebsd-virtualization Responsible-Changed-By: bz Responsible-Changed-When: Thu Jul 7 22:08:42 UTC 2011 Responsible-Changed-Why: Re-assign http://www.freebsd.org/cgi/query-pr.cgi?pr=158686 From owner-freebsd-net@FreeBSD.ORG Fri Jul 8 01:51:07 2011 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 34E45106566C for ; Fri, 8 Jul 2011 01:51:07 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id EEBE78FC15 for ; Fri, 8 Jul 2011 01:51:06 +0000 (UTC) Received: (qmail 67281 invoked by uid 0); 8 Jul 2011 01:51:06 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jul 2011 01:51:06 -0000 Received: (qmail 67265 invoked by uid 90); 8 Jul 2011 01:51:05 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Jul 2011 01:51:05 -0000 Date: Thu, 7 Jul 2011 21:51:05 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: YongHyeon PYUN In-Reply-To: <20110707174233.GB8702@michelle.cdnetworks.com> Message-ID: References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, David Christensen Subject: Re: bce packet loss 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, 08 Jul 2011 01:51:07 -0000 On Thu, 7 Jul 2011, YongHyeon PYUN wrote: > On Thu, Jul 07, 2011 at 02:00:26AM -0400, Charles Sprickman wrote: >> More inline, including a bigger picture of what I'm seeing on some other >> hosts, but I wanted to thank everyone for all the fascinating ethernet BER >> info and the final explanation of what the "IfHCInBadOctets" counter >> represents. Interesting stuff. >> >> On Wed, 6 Jul 2011, YongHyeon PYUN wrote: >> >>> On Mon, Jul 04, 2011 at 09:32:11PM -0400, Charles Sprickman wrote: >>>> Hello, >>>> >>>> We're running a few 8.1-R servers with Broadcom bce interfaces (Dell R510) >>>> and I'm seeing occasional packet loss on them (enough that it trips nagios >>>> now and then). Cabling seems fine as neither the switch nor the sysctl >>>> info for the device show any errors/collisions/etc, however there is one >>>> odd one, which is "dev.bce.1.stat_IfHCInBadOctets: 539369". See [1] below >>>> for full sysctl output. The switch shows no errors but for "Dropped >>>> packets 683868". >>>> >>>> pciconf output is also below. [2] >>>> >>>> By default, the switch had flow control set to "on". I also let it run >>>> with "auto". In both cases, the drops continued to increment. I'm now >>>> running with flow control off to see if that changes anything. >>>> >>>> I do see some correlation between cpu usage and drops - I have cpu usage >>>> graphed in nagios and cacti is graphing the drops on the dell switch. >>>> There's no signs of running out of mbufs or similar. >>>> >>>> So given that limited info, is there anything I can look at to track this >>>> down? Anything stand out in the stats sysctl exposes? Two things are >>>> standing out for me - the number of changes in bce regarding flow control >>>> that are not in 8.1, and the correlation between cpu load and the drops. >>>> >>>> What other information can I provide? >>>> >>> >>> You had 282 RX buffer shortages and these frames were dropped. This >>> may explain why you see occasional packet loss. 'netstat -m' will >>> show which size of cluster allocation were failed. >> >> Nothing of note: >> >> 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 >> > > Hmm... it's strange, I can't explain how you have non-zero > mbuf_alloc_failed_count. Odd, but probably a red herring. It's not really climbing much, it's at 288 right now. >>> However it seems you have 0 com_no_buffers which indicates >>> controller was able to receive all packets destined for this host. >>> You may host lost some packets(i.e. non-zero mbuf_alloc_failed_count) >>> but your controller and system was still responsive to the network >>> traffic. >> >> OK. I recall seeing a thread in the -net archives where some folks had >> the "com_no_buffers" incrementing, but I'm not seeing that at all. >> >>> Data sheet says IfHCInBadOctets indicates number of octets received >>> on the interface, including framing characters for packets that >>> were dropped in the MAC for any reason. I'm not sure this counter >>> includes packets IfInFramesL2FilterDiscards which indicates number >>> of good frames that have been dropped due to the L2 perfect match, >>> broadcast, multicast or MAC control frame filters. If your switch >>> runs STP it would periodically sends BPDU packets to destination >>> address of STP multicast address 01:80:C2:00:00:00. Not sure this >>> is the reason though. Probably David can explain more details on >>> IfHCInBadOctets counter(CCed). >> >> Again, thanks for that. >> >> If I could just ask for a bit more assistance, it would be greatly >> appreciated. I collected a fair bit of data and it's done nothing but >> complicate the issue for me so far. >> >> -If I'm reading the switch stats correctly, most of my drops are >> host->switch, although I'm not certain of that, these Dell 2848s have no > > IfHCInBadOctets is counter for RX(i.e. switch->host). And TX > hardware MAC counters showed no error at all. Thanks. Also of note is that if I look at the stats for the Dell via SNMP, the OID that the web interface labels as "dropped packets" is actually labelled "discards". Don't know if that's an important distinction, but "discard" seems to suggest a drop with a purpose (like "oh some buffer is full, sorry!"). >> real cli interface to speak of. >> >> -I'm seeing similar drops, but not quite so bad, on other hosts. They all >> use the em interface but for one other with bge. This particular host >> (with the bce interface) just seems to get bad enough to trigger nagios >> alerts (simple ping check from a host on the same switch/subnet). All >> these hosts are forced to 100/FD as is the switch. The switch is our >> external (internet facing) switch with a 100Mb connection to our upstream. >> At *peak* our aggregate bandwidth on this switch is maybe 45Mb/s, most of >> it outbound. We are nowhere near saturating the switching fabric (I >> hope). >> >> -There are three reasons I set the ports at 100baseTX - the old Cisco that >> lost a few ports was a 10/100 switch and the hosts were already hard-coded >> for 100/FD, I figured if the Dell craps out I can toss the Cisco back >> without changing the speed/duplex on all the hosts, and lastly our uplink >> is only 100/FD so why bother. Also maybe some vague notion that I'd not >> use up some kind of buffers in the switch by matching the speed on all >> ports... >> >> -We have an identical switch (same model, same hardware rev, same >> firmware) for our internal network (lots of log analysis over nfs mounts, >> a ton of internal dns (upwards of 10K queries/sec at peak), and occasional >> large file transfers. On this host and all others, the dropped packet >> count on the switch ports is at worst around 5000 packets. The counters >> have not been reset on it and it's been up for 460 days. >> >> -A bunch of legacy servers that have fxp interfaces on the external switch >> and em on the internal switch show *no* significant drops nor do >> the switch ports they are connected to. >> >> -To see if forcing the ports to 100/FD was causing a problem, I set the >> host and switch to 1000/FD. Over roughly 24 hours, the switch is >> reporting 197346 dropped packets of 52166986 packets received. >> >> -Tonight's change was to turn off spanning tree. This is a long shot >> based on some Dell bug I saw discussed on their forums. Given our simple >> network layout, I don't really see spanning tree as being at all >> necessary. >> >> One of the first replies I got to my original post was private and >> amounted to "Dell is garbage". That may be true, but the excellent >> performance on the more heavily loaded internal network makes me doubt >> there's a fundamental shortcoming in the switch. It would have to be real >> garbage to crap out with a combined load of 45Mb/s. I am somewhat curious >> if some weird buffering issue is possible with a mix of 100/FD and 1000/FD >> ports. >> >> Any thoughts on that? It's the only thing that differs between the two >> switches. >> > > This makes me think possibility of duplex mismatch between bce(4) > and link partner. You should not use forced media configuration on > 1000baseT link. If you used manual media configuration on bce(4) > and link partner used auto-negotiation, resolved duplex would be > half-duplex. It's standard behavior and Duplex mismatch can cause > strange problems. > I would check whether link partner also agrees on the resolved > speed/duplex of bce(4). Many, many years ago I developed the habit of always locking speed and duplex at both ends. This is the case here, and both ends agree on it whether it's at the original 100/FD or the current 1000/FD. >> Before replacing the switch I'm also going to cycle through turning off >> TSO, rxcsum, and txcsum since it seems that has been a fix for some people >> with otherwise unexplained network issues. I assume those features all >> depend on the firmware of the NIC being bug-free, and I'm not quite ready >> to accept that. >> > > It's worth to try but I wonder how it can explain ICMP ECHO request > packet loss. Ah, yes. Thank you for that. :) I think this is turning into a Dell thread though. I had noted that the internal network, which is all 1000/FD hosts but for a few hosts (dns resolvers) that only send sizable traffic to faster hosts, was running totally clean. I was able to reproduce the drops in very large numbers on the internal network today. I simply scp'd some large files from 1000/FD hosts to a 100/FD host (ie: scp bigfile.tgz oldhost.i:/dev/null). Immediately the 1000/FD hosts sending the files showed massive amounts of drops on the switch. This makes me suspect that this switch might be garbage in that it doesn't have enough buffer space to handle sending large amounts of traffic from the GigE ports to the FE ports without randomly dropping packets. Granted, I don't really understand how a "good" switch does this either, I would have thought tcp just took care of throttling itself. Bear in mind that on the external switch our port to our ISP, which is the destination of almost all the traffic, is 100/FD and not 1000/FD. This of course does not explain why the original setup where I'd locked the switch ports and the host ports to 100/FD showed the same behavior. I'm stumped. We are running 8.1, am I correct in that flow control is not implemented there? We do have an 8.2-STABLE image from a month or so ago that we are testing with zfs v28, might that implement flow control? Although reading this: http://en.wikipedia.org/wiki/Ethernet_flow_control It sounds like flow control is not terribly optimal since it forces the host to block all traffic. Not sure if this means drops are eliminated, reduced or shuffled around. That's the last thing (host-side) I can think of... Oh, and to Mr. Swiger, my apologies for brushing off your early suggestion that this may all be due to the switch being something of a piece of junk. Thanks, Charles >> Thanks, >> >> Charles > From owner-freebsd-net@FreeBSD.ORG Fri Jul 8 10:51:33 2011 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 831FD1065675 for ; Fri, 8 Jul 2011 10:51:33 +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 152358FC1A for ; Fri, 8 Jul 2011 10:51:32 +0000 (UTC) Received: (qmail 62535 invoked from network); 8 Jul 2011 09:50:51 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2011 09:50:51 -0000 Message-ID: <4E16E136.7030509@freebsd.org> Date: Fri, 08 Jul 2011 12:51:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mikolaj Golub References: <867h7zxvd2.fsf@kopusha.home.net> <4E158EB3.80203@freebsd.org> <86iprd99mi.fsf@kopusha.home.net> In-Reply-To: <86iprd99mi.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: issues with O_NONBLOCK 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, 08 Jul 2011 10:51:33 -0000 On 07.07.2011 21:24, Mikolaj Golub wrote: > > On Thu, 07 Jul 2011 12:47:15 +0200 Andre Oppermann wrote: > > AO> Please try this patch: > AO> http://people.freebsd.org/~andre/soreceive_stream.diff-20110707 > > It works for me. No issues detected so far. Thanks. Committed in r223863. Many thanks for testing! -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Jul 8 18:07:13 2011 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 8F9C81065673; Fri, 8 Jul 2011 18:07:13 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 652C68FC17; Fri, 8 Jul 2011 18:07:13 +0000 (UTC) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 08 Jul 2011 11:05:28 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 8 Jul 2011 11:00:11 -0700 From: "David Christensen" To: "Charles Sprickman" , "YongHyeon PYUN" Date: Fri, 8 Jul 2011 11:00:23 -0700 Thread-Topic: bce packet loss Thread-Index: Acw9EYeqMMNh5VAMSjOb2D/OBpbEcwAhUvgw Message-ID: <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 620999623B416804050-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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, 08 Jul 2011 18:07:13 -0000 > I was able to reproduce the drops in very large numbers on the internal > network today. I simply scp'd some large files from 1000/FD hosts to a > 100/FD host (ie: scp bigfile.tgz oldhost.i:/dev/null). Immediately the > 1000/FD hosts sending the files showed massive amounts of drops on the > switch. This makes me suspect that this switch might be garbage in that > it doesn't have enough buffer space to handle sending large amounts of > traffic from the GigE ports to the FE ports without randomly dropping > packets. Granted, I don't really understand how a "good" switch does > this > either, I would have thought tcp just took care of throttling itself. If you have flow control enabled end-to-end I wouldn't expect to see such behavior, frames should not be dropped. If you're seeing drops at the switch then I'd suspect that the traffic source connected to that switch doesn't honor flow control. Check if either the switch or traffic source keeps statistics on flow control frames generated/received. > Bear in mind that on the external switch our port to our ISP, which is > the > destination of almost all the traffic, is 100/FD and not 1000/FD. >=20 > This of course does not explain why the original setup where I'd locked > the switch ports and the host ports to 100/FD showed the same behavior. >=20 > I'm stumped. >=20 > We are running 8.1, am I correct in that flow control is not implemented > there? We do have an 8.2-STABLE image from a month or so ago that we > are > testing with zfs v28, might that implement flow control? Flow control will depend on the NIC driver implementation. Older versions of the bce(4) firmware will rarely generate pause frames (frames would be dropped by firmware but statistics should show the frame drop occurring) and should always honor pause frames from the link partner when flow control is enabled. >=20 > Although reading this: >=20 > http://en.wikipedia.org/wiki/Ethernet_flow_control >=20 > It sounds like flow control is not terribly optimal since it forces the > host to block all traffic. Not sure if this means drops are eliminated, > reduced or shuffled around. When congestion is detected the switch should buffer up to a certain limit (say 80% of full) and then start sending pause frames to avoid dropping frames. This will affect all hosts connecting through the switch so congestion at one host can spread to other hosts (see http://www.ieee802.org/3/cm_study/public/september04/thaler_3_0904.pdf). Small networks with a few hosts should be OK with flow control but if you have dozens of switches and hundreds of hosts then it's not a good idea. Dave From owner-freebsd-net@FreeBSD.ORG Fri Jul 8 19:15:19 2011 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 410EB106566C; Fri, 8 Jul 2011 19:15:19 +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 174628FC12; Fri, 8 Jul 2011 19:15:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p68JFIcX066655; Fri, 8 Jul 2011 19:15:18 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p68JFI2w066651; Fri, 8 Jul 2011 19:15:18 GMT (envelope-from linimon) Date: Fri, 8 Jul 2011 19:15:18 GMT Message-Id: <201107081915.p68JFI2w066651@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158726: [ip6] [patch] ICMPv6 Router Announcement flooding limit route number patch 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, 08 Jul 2011 19:15:19 -0000 Old Synopsis: ICMPv6 Router Announcement flooding limit route number patch New Synopsis: [ip6] [patch] ICMPv6 Router Announcement flooding limit route number patch Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 8 19:14:52 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158726 From owner-freebsd-net@FreeBSD.ORG Sat Jul 9 00:40:09 2011 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 A16B61065674 for ; Sat, 9 Jul 2011 00:40:05 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id AFA458FC15 for ; Sat, 9 Jul 2011 00:40:04 +0000 (UTC) Received: (qmail 39950 invoked by uid 0); 9 Jul 2011 00:40:03 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Jul 2011 00:40:03 -0000 Received: (qmail 39939 invoked by uid 90); 9 Jul 2011 00:40:03 -0000 Received: from unknown (HELO freemac) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Jul 2011 00:40:03 -0000 Date: Fri, 8 Jul 2011 20:39:59 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@freemac To: David Christensen In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: References: <20110706201509.GA5559@michelle.cdnetworks.com> <20110707174233.GB8702@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385C32D96B7@IRVEXCHCCR01.corp.ad.broadcom.com> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: YongHyeon PYUN , "freebsd-net@freebsd.org" , David Christensen Subject: RE: bce packet loss 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, 09 Jul 2011 00:40:09 -0000 On Fri, 8 Jul 2011, David Christensen wrote: >> I was able to reproduce the drops in very large numbers on the internal >> network today. I simply scp'd some large files from 1000/FD hosts to a >> 100/FD host (ie: scp bigfile.tgz oldhost.i:/dev/null). Immediately the >> 1000/FD hosts sending the files showed massive amounts of drops on the >> switch. This makes me suspect that this switch might be garbage in that >> it doesn't have enough buffer space to handle sending large amounts of >> traffic from the GigE ports to the FE ports without randomly dropping >> packets. Granted, I don't really understand how a "good" switch does >> this >> either, I would have thought tcp just took care of throttling itself. > > If you have flow control enabled end-to-end I wouldn't expect to see > such behavior, frames should not be dropped. If you're seeing drops > at the switch then I'd suspect that the traffic source connected to > that switch doesn't honor flow control. Check if either the switch or > traffic source keeps statistics on flow control frames generated/received. I'm running 8.1 and at least on the bce hosts, it looks like flow control isn't supported, it was added on 4/30/2010: http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=206268&r2=207411 In my 8.1 sources I still see this comment, which was removed in the above commit: /* ToDo: Enable flow control support in brgphy and bge. */ So at least on the bce hosts (and bge it seems), I do not have flow control available on the NIC. The sysctl stats do show that it's received "XON/XOFF" frames, which I assume are flow control messages, but there's no indication that the NIC does anything with them. It also looks like on 11/14/2010 a major change was made where flow control was brought to the mii layer. I believe this made it into 8.2. On my em interfaces, I can't tell if they support flow control or not, and sysctl has little info. There's a sysctl that suggest the availability of more info, but I'm probably misunderstanding it, as it cannot be changed: [root@h15 /home/spork]# sysctl dev.em.0.stats=1 dev.em.0.stats: -1 -> -1 If anyone can clarify the flow control status on em(4) in 8.1, I'd really appreciate it. The source for the Intel drivers is a bit hard to poke around in since it supports so many variations. >> Bear in mind that on the external switch our port to our ISP, which is >> the >> destination of almost all the traffic, is 100/FD and not 1000/FD. >> >> This of course does not explain why the original setup where I'd locked >> the switch ports and the host ports to 100/FD showed the same behavior. >> >> I'm stumped. >> >> We are running 8.1, am I correct in that flow control is not implemented >> there? We do have an 8.2-STABLE image from a month or so ago that we >> are >> testing with zfs v28, might that implement flow control? > > Flow control will depend on the NIC driver implementation. Older > versions of the bce(4) firmware will rarely generate pause frames > (frames would be dropped by firmware but statistics should show > the frame drop occurring) and should always honor pause frames > from the link partner when flow control is enabled. I think my nics probably lack it. I am also guessing that if any high-traffic host ignores flow control frames, that's going to screw up other hosts as well since the one causing the buffers to fill is not going to throttle and the overflow will continue, correct? >> >> Although reading this: >> >> http://en.wikipedia.org/wiki/Ethernet_flow_control >> >> It sounds like flow control is not terribly optimal since it forces the >> host to block all traffic. Not sure if this means drops are eliminated, >> reduced or shuffled around. > When congestion is detected the switch should buffer up to a certain > limit (say 80% of full) and then start sending pause frames to avoid > dropping frames. This will affect all hosts connecting through the > switch so congestion at one host can spread to other hosts (see > http://www.ieee802.org/3/cm_study/public/september04/thaler_3_0904.pdf). Wow. I did not catch that. I do recall something about the flow control frames being multicast - so every host gets them and pauses. That's... interesting, isn't it? > Small networks with a few hosts should be OK with flow control but > if you have dozens of switches and hundreds of hosts then it's not a > good idea. We only have 2/3 of a cabinet of hosts, and we've been further consolidating that down as we replace old hardware (ie: 3 physical hosts go to 1 physical host w/3 jails). If anyone is aware of whether the bce driver for 8.2 would port cleanly to 8.1, let me know. Those are my highest traffic hosts and I'd like to see what happens here when the NICs support flow control. Another stopgap I'm looking at is having our upstream put us on a GigE port - I imagine that would help us if the switch is running out of buffer space. Thanks again all, Charles > Dave > >