From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 10:47:16 2010 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 B271F10656C9; Sun, 5 Sep 2010 10:47:16 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 896868FC12; Sun, 5 Sep 2010 10:47:16 +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 o85AlGCO064266; Sun, 5 Sep 2010 10:47:16 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o85AlGHW064262; Sun, 5 Sep 2010 10:47:16 GMT (envelope-from remko) Date: Sun, 5 Sep 2010 10:47:16 GMT Message-Id: <201009051047.o85AlGHW064262@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: bin/150224: ppp does not reassign static IP after kill -KILL command 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, 05 Sep 2010 10:47:16 -0000 Synopsis: ppp does not reassign static IP after kill -KILL command Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Sep 5 10:46:48 UTC 2010 Responsible-Changed-Why: I am not entirely sure whether this is known/default behaviour of ppp, but anyway, it's a networking thing, assign it there. http://www.freebsd.org/cgi/query-pr.cgi?pr=150224 From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 10:50:46 2010 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 0E31C106567A; Sun, 5 Sep 2010 10:50:46 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DAC258FC19; Sun, 5 Sep 2010 10:50:45 +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 o85AojdL069686; Sun, 5 Sep 2010 10:50:45 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o85Aoj0c069676; Sun, 5 Sep 2010 10:50:45 GMT (envelope-from remko) Date: Sun, 5 Sep 2010 10:50:45 GMT Message-Id: <201009051050.o85Aoj0c069676@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/149373: [realtek/atheros]: None of my network card working 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, 05 Sep 2010 10:50:46 -0000 Old Synopsis: None of my network card working New Synopsis: [realtek/atheros]: None of my network card working Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sun Sep 5 10:50:10 UTC 2010 Responsible-Changed-Why: This is more networkish then i386-ish http://www.freebsd.org/cgi/query-pr.cgi?pr=149373 From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 16:04:26 2010 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 87B571065694 for ; Sun, 5 Sep 2010 16:04:26 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from honeysuckle.london.02.net (honeysuckle.london.02.net [87.194.255.144]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8A08FC1A for ; Sun, 5 Sep 2010 16:04:26 +0000 (UTC) Received: from unknown (94.193.93.212) by honeysuckle.london.02.net (8.5.124.10) id 4C655360009D7421 for freebsd-net@freebsd.org; Sun, 5 Sep 2010 16:53:17 +0100 Date: Sun, 5 Sep 2010 16:53:08 +0100 From: Bruce Cran To: freebsd-net@freebsd.org Message-ID: <20100905165308.00000d99@unknown> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: mwl(4) depends on non-existant mwlfw_fw (mwlfw doesn't implement mwlfw_fw) 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, 05 Sep 2010 16:04:27 -0000 Hi, I was trying to help someone on IRC with a card that should be supported by the mwl(4) driver, but it seems it's broken: mwlfw(4) doesn't implement mwlfw_fw which if_mwl depends on ("MODULE_DEPEND(mwl, mwlfw_fw, 1, 1, 1);"). Should it be trying to load mw88W8363fw dynamically instead? The same error appears to be in malo(4) too - and neither mwlfw(4) or malofw(4) are installed during an installkernel despite mwl(4) and malo(4) being installed. malo(4) should also be updated to list "device malofw" in the top section. malofw(4) doesn't exist yet. -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 17:13:14 2010 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 4872010656A5 for ; Sun, 5 Sep 2010 17:13:14 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AABEA8FC0A for ; Sun, 5 Sep 2010 17:13:13 +0000 (UTC) Received: by fxm4 with SMTP id 4so2510152fxm.13 for ; Sun, 05 Sep 2010 10:13:12 -0700 (PDT) Received: by 10.223.115.79 with SMTP id h15mr1541970faq.18.1283706792474; Sun, 05 Sep 2010 10:13:12 -0700 (PDT) Received: from julie.lab.techwires.net (dslb-088-065-215-079.pools.arcor-ip.net [88.65.215.79]) by mx.google.com with ESMTPS id b11sm1954912faq.6.2010.09.05.10.13.10 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 10:13:11 -0700 (PDT) From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Sun, 5 Sep 2010 19:11:59 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <20100905165308.00000d99@unknown> <201009051852.05469.bschmidt@techwires.net> In-Reply-To: <201009051852.05469.bschmidt@techwires.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009051911.59912.bschmidt@techwires.net> Cc: Bruce Cran , brueffer@freebsd.org Subject: Re: mwl(4) depends on non-existant mwlfw_fw (mwlfw doesn't implement mwlfw_fw) 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, 05 Sep 2010 17:13:14 -0000 On Sunday 05 September 2010 18:52:05 Bernhard Schmidt wrote: > On Sunday 05 September 2010 17:53:08 Bruce Cran wrote: > > Hi, > > > > I was trying to help someone on IRC with a card that should be > > supported by the mwl(4) driver, but it seems it's broken: mwlfw(4) > > doesn't implement mwlfw_fw which if_mwl depends on > > ("MODULE_DEPEND(mwl, mwlfw_fw, 1, 1, 1);"). > > This is wrong. It should depend on firmware(9), which also takes care of > loading the adequate firmware modules. > > > Should it be trying to load mw88W8363fw dynamically instead? > > Yes, firmware(9) does that. > > > The same error appears to be in malo(4) too - and neither mwlfw(4) or > > malofw(4) are installed during an installkernel despite mwl(4) and > > malo(4) being installed. > > Seems like there is a MFC missing those get installed on HEAD. http://www.freebsd.org/cgi/query-pr.cgi?pr=144494 > > malo(4) should also be updated to list "device malofw" in the top > > section. malofw(4) doesn't exist yet. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 17:21:09 2010 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 4D29A10656A8 for ; Sun, 5 Sep 2010 17:21:09 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD3F68FC0A for ; Sun, 5 Sep 2010 17:21:08 +0000 (UTC) Received: by fxm4 with SMTP id 4so2512376fxm.13 for ; Sun, 05 Sep 2010 10:21:08 -0700 (PDT) Received: by 10.223.125.131 with SMTP id y3mr741730far.9.1283705598330; Sun, 05 Sep 2010 09:53:18 -0700 (PDT) Received: from julie.lab.techwires.net (dslb-088-065-215-079.pools.arcor-ip.net [88.65.215.79]) by mx.google.com with ESMTPS id m17sm723971fag.2.2010.09.05.09.53.16 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 09:53:16 -0700 (PDT) From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Sun, 5 Sep 2010 18:52:05 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.1; amd64; ; ) References: <20100905165308.00000d99@unknown> In-Reply-To: <20100905165308.00000d99@unknown> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009051852.05469.bschmidt@techwires.net> Cc: Bruce Cran Subject: Re: mwl(4) depends on non-existant mwlfw_fw (mwlfw doesn't implement mwlfw_fw) 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, 05 Sep 2010 17:21:09 -0000 On Sunday 05 September 2010 17:53:08 Bruce Cran wrote: > Hi, > > I was trying to help someone on IRC with a card that should be > supported by the mwl(4) driver, but it seems it's broken: mwlfw(4) > doesn't implement mwlfw_fw which if_mwl depends on > ("MODULE_DEPEND(mwl, mwlfw_fw, 1, 1, 1);"). This is wrong. It should depend on firmware(9), which also takes care of loading the adequate firmware modules. > Should it be trying to load mw88W8363fw dynamically instead? Yes, firmware(9) does that. > The same error appears to be in malo(4) too - and neither mwlfw(4) or > malofw(4) are installed during an installkernel despite mwl(4) and > malo(4) being installed. Seems like there is a MFC missing those get installed on HEAD. > malo(4) should also be updated to list "device malofw" in the top > section. malofw(4) doesn't exist yet. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 06:56:08 2010 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 C0C7E1065694; Mon, 6 Sep 2010 06:56:08 +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 961AF8FC14; Mon, 6 Sep 2010 06:56:08 +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 o866u8TY020618; Mon, 6 Sep 2010 06:56:08 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o866u8gM020614; Mon, 6 Sep 2010 06:56:08 GMT (envelope-from linimon) Date: Mon, 6 Sep 2010 06:56:08 GMT Message-Id: <201009060656.o866u8gM020614@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/150148: [ath] Atheros 5424/2424 - AR2425 stopped working with WPA2-PSK(AES) in 8.1-RELEASE [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, 06 Sep 2010 06:56:08 -0000 Synopsis: [ath] Atheros 5424/2424 - AR2425 stopped working with WPA2-PSK(AES) in 8.1-RELEASE [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 6 06:55:54 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150148 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 07:24:52 2010 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 2529010656B2; Mon, 6 Sep 2010 07:24:50 +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 A0C9D8FC0C; Mon, 6 Sep 2010 07:24:50 +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 o867OoJY055142; Mon, 6 Sep 2010 07:24:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o867OoDY055138; Mon, 6 Sep 2010 07:24:50 GMT (envelope-from linimon) Date: Mon, 6 Sep 2010 07:24:50 GMT Message-Id: <201009060724.o867OoDY055138@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/150247: [patch] [ixgbe] Version in -current won't build on 7.x systems 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, 06 Sep 2010 07:24:52 -0000 Synopsis: [patch] [ixgbe] Version in -current won't build on 7.x systems Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 6 07:24:31 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150247 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 11:07:00 2010 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 DA7DF106570C for ; Mon, 6 Sep 2010 11:07:00 +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 C7E758FC16 for ; Mon, 6 Sep 2010 11:07:00 +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 o86B70K8011840 for ; Mon, 6 Sep 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86B70LP011838 for freebsd-net@FreeBSD.org; Mon, 6 Sep 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Sep 2010 11:07:00 GMT Message-Id: <201009061107.o86B70LP011838@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, 06 Sep 2010 11:07:00 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/150257 net [msk] watchdog timeout o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp does not reassign static IP after kill -KILL comma o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net wi(4) driver does not work with wlan(4) driver for Luc 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/149804 net [icmp] [panic] ICMP redirect on causes "panic: rtqkill o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall 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/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147985 net [alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re 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/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using 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/144642 net [rum] [panic] Enabling rum interface causes panic 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/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun 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/143595 net [wpi] [panic] Creating virtual interface over wpi0 in 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 conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir 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 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI 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/140796 net [ath] [panic] privileged instruction fault 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/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on 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 o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) 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/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/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/138427 net [wpi] [panic] Kernel panic after trying set monitor wl 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 o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e 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/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho 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/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver 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/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) 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 kern/132885 net [wlan] 802.1x broken after SVN rev 189592 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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I 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 bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw 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 o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa 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 kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic 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 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/127102 net [wpi] Intel 3945ABG low throughput 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/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card 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/125502 net [ral] ifconfig ral0 scan produces no output unless in 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/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets 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. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans 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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported 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 o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit 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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS 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 s kern/117717 net [panic] Kernel panic with Bittorrent client. 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 kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 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/111457 net [ral] ral(4) freeze 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/105348 net [ath] ath device stopps TX 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 f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed 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 o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate 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 f kern/88082 net [ath] [panic] cts protection for ath0 causes panic 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 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 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 bin/79228 net [patch] extend arp(8) to be able to create blackhole r 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/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/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 o conf/23063 net [arp] [patch] for static ARP tables in rc.network 363 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 12:00:30 2010 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 EED0F1065801 for ; Mon, 6 Sep 2010 12:00:30 +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 85E988FC13 for ; Mon, 6 Sep 2010 12:00: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 o86C0U17067526 for ; Mon, 6 Sep 2010 12:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86C0UWr067504; Mon, 6 Sep 2010 12:00:30 GMT (envelope-from gnats) Date: Mon, 6 Sep 2010 12:00:30 GMT Message-Id: <201009061200.o86C0UWr067504@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Vladislav V. Prodan" Cc: Subject: Re: kern/124021: [ip6] [panic] page fault in nd6_output() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Vladislav V. Prodan" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 12:00:31 -0000 The following reply was made to PR kern/124021; it has been noted by GNATS. From: "Vladislav V. Prodan" To: bug-followup@FreeBSD.org, janos.mohacsi@bsd.hu Cc: Subject: Re: kern/124021: [ip6] [panic] page fault in nd6_output() Date: Mon, 06 Sep 2010 14:58:11 +0300 After ping the internal network system hung # ping6 2001:470:ZZ:140::10 PING6(56=40+8+8 bytes) 2001:470:ZZ:140::5 --> 2001:470:ZZ:140::10 http://img834.imageshack.us/img834/5016/dsc00523qw.jpg # uname -a FreeBSD mary-teresa.XXXXX.ua 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sun Aug 29 19:00:25 EEST 2010 vlad11@mary-teresa.XXXXX.ua:/usr/obj/usr/src/sys/mary-teresa.24 amd64 # ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:e0:4d:7b:69:0c inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::2e0:4dff:fe7b:690c%re0 prefixlen 64 scopeid 0x1 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 2001:470:ZZ:140::5 prefixlen 64 inet6 2001:5c0:1503:XXXX::1 prefixlen 64 inet6 2001:5c0:1503:XXXX::84 prefixlen 64 inet6 2001:470:ZZXX::5 prefixlen 48 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 22:36:03 2010 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 4EBE810656DB; Mon, 6 Sep 2010 22:36:03 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2542C8FC14; Mon, 6 Sep 2010 22:36: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 o86Ma3gp029225; Mon, 6 Sep 2010 22:36:03 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86Ma2sx029221; Mon, 6 Sep 2010 22:36:02 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 22:36:02 GMT Message-Id: <201009062236.o86Ma2sx029221@freefall.freebsd.org> To: zzerver@gmail.com, arundel@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/129750: [ath] Atheros AR5006 exits on "cannot map register space" & "ath0 attach returned 6" 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, 06 Sep 2010 22:36:03 -0000 Synopsis: [ath] Atheros AR5006 exits on "cannot map register space" & "ath0 attach returned 6" State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Mon Sep 6 22:31:52 UTC 2010 State-Changed-Why: Support for the Atheros AR5424 chip was added in FreeBSD 7.x. Could you please check if this PR is still reproducable on a supported branch? Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=129750 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 22:40:07 2010 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 7002B1065673; Mon, 6 Sep 2010 22:40:07 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 471BF8FC12; Mon, 6 Sep 2010 22:40: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 o86Me7OI029374; Mon, 6 Sep 2010 22:40:07 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86Me6Dm029367; Mon, 6 Sep 2010 22:40:06 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 22:40:06 GMT Message-Id: <201009062240.o86Me6Dm029367@freefall.freebsd.org> To: kerneljake@hotmail.com, arundel@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/88082: [ath] [panic] cts protection for ath0 causes 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: Mon, 06 Sep 2010 22:40:07 -0000 Synopsis: [ath] [panic] cts protection for ath0 causes panic State-Changed-From-To: feedback->closed State-Changed-By: arundel State-Changed-When: Mon Sep 6 22:38:18 UTC 2010 State-Changed-Why: No feedback was received for over a year. Also it's very unlikely that this PR is still valid on a supported branch. http://www.freebsd.org/cgi/query-pr.cgi?pr=88082 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 22:47:36 2010 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 4F40C10656A4; Mon, 6 Sep 2010 22:47:36 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 25AF48FC18; Mon, 6 Sep 2010 22:47:36 +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 o86Mlaj5038621; Mon, 6 Sep 2010 22:47:36 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86MlZdU038617; Mon, 6 Sep 2010 22:47:36 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 22:47:36 GMT Message-Id: <201009062247.o86MlZdU038617@freefall.freebsd.org> To: Stephen.Liss@gmail.com, arundel@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/93886: [ath] Atheros/D-Link DWL-G650 long delay to associate on 6.1-PRERELEASE 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, 06 Sep 2010 22:47:36 -0000 Synopsis: [ath] Atheros/D-Link DWL-G650 long delay to associate on 6.1-PRERELEASE State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Mon Sep 6 22:46:15 UTC 2010 State-Changed-Why: Could you please verify, if this issue still applies on a supported branch? Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=93886 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 22:56:54 2010 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 E68E710656B2; Mon, 6 Sep 2010 22:56:54 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BD40D8FC0A; Mon, 6 Sep 2010 22:56:54 +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 o86MusSw047915; Mon, 6 Sep 2010 22:56:54 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86MusBd047911; Mon, 6 Sep 2010 22:56:54 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 22:56:54 GMT Message-Id: <201009062256.o86MusBd047911@freefall.freebsd.org> To: amura@tomato.sakura.ne.jp, arundel@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/140567: [ath] [patch] ath is not worked on my notebook PC 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, 06 Sep 2010 22:56:55 -0000 Synopsis: [ath] [patch] ath is not worked on my notebook PC State-Changed-From-To: open->patched State-Changed-By: arundel State-Changed-When: Mon Sep 6 22:55:01 UTC 2010 State-Changed-Why: This issue was fixed in HEAD (r199491) and stable/8 (r199800). Still missing in stable/7. http://www.freebsd.org/cgi/query-pr.cgi?pr=140567 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 22:59:41 2010 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 6C917106567A; Mon, 6 Sep 2010 22:59:41 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 42B138FC08; Mon, 6 Sep 2010 22:59:41 +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 o86MxfJ0048000; Mon, 6 Sep 2010 22:59:41 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86Mxepe047996; Mon, 6 Sep 2010 22:59:40 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 22:59:40 GMT Message-Id: <201009062259.o86Mxepe047996@freefall.freebsd.org> To: andrea+freebsd@webcom.it, arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/107279: [ath] [panic] ath_start: attempted use of a free mbuf! 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, 06 Sep 2010 22:59:41 -0000 Old Synopsis: [ath] panic: ath_start: attempted use of a free mbuf! New Synopsis: [ath] [panic] ath_start: attempted use of a free mbuf! State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Mon Sep 6 22:58:24 UTC 2010 State-Changed-Why: Could you please verify, if this issue still occurs on a supported branch? Thanks. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arundel Responsible-Changed-When: Mon Sep 6 22:58:24 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=107279 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 23:02:45 2010 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 36FAA10656D3; Mon, 6 Sep 2010 23:02:45 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0CF268FC12; Mon, 6 Sep 2010 23:02:45 +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 o86N2iCh060278; Mon, 6 Sep 2010 23:02:44 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86N2iwG060274; Mon, 6 Sep 2010 23:02:44 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 23:02:44 GMT Message-Id: <201009062302.o86N2iwG060274@freefall.freebsd.org> To: mnd999@gmail.com, arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/125332: [ath] [panic] crash under any non-tiny networking under amd64 7-STABLE with ath 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, 06 Sep 2010 23:02:45 -0000 Old Synopsis: [ath] [hang] crash under any non-tiny networking under amd64 7-STABLE with ath New Synopsis: [ath] [panic] crash under any non-tiny networking under amd64 7-STABLE with ath State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Mon Sep 6 23:01:07 UTC 2010 State-Changed-Why: Does this panic still occur, if you update your kernel/world to a more recent stable/7 version? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arundel Responsible-Changed-When: Mon Sep 6 23:01:07 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125332 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 23:04:13 2010 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 3C23F1065696; Mon, 6 Sep 2010 23:04:13 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 139098FC1D; Mon, 6 Sep 2010 23:04:13 +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 o86N4CPB060337; Mon, 6 Sep 2010 23:04:12 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86N4CKt060333; Mon, 6 Sep 2010 23:04:12 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 23:04:12 GMT Message-Id: <201009062304.o86N4CKt060333@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/125501: [ath] atheros cardbus driver hangs 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, 06 Sep 2010 23:04:13 -0000 Synopsis: [ath] atheros cardbus driver hangs Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arundel Responsible-Changed-When: Mon Sep 6 23:03:33 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125501 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 23:05:31 2010 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 C3889106564A; Mon, 6 Sep 2010 23:05:31 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7068FC18; Mon, 6 Sep 2010 23:05:31 +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 o86N5VC5060400; Mon, 6 Sep 2010 23:05:31 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86N5Vs1060396; Mon, 6 Sep 2010 23:05:31 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 23:05:31 GMT Message-Id: <201009062305.o86N5Vs1060396@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/125721: [ath] Terrible throughput/high ping latency with Ubiquiti SR9/XR9 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, 06 Sep 2010 23:05:31 -0000 Synopsis: [ath] Terrible throughput/high ping latency with Ubiquiti SR9/XR9 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arundel Responsible-Changed-When: Mon Sep 6 23:05:10 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125721 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 23:07:46 2010 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 5A3B01065698; Mon, 6 Sep 2010 23:07:46 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 318778FC18; Mon, 6 Sep 2010 23:07: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 o86N7kqU060706; Mon, 6 Sep 2010 23:07:46 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86N7kpB060702; Mon, 6 Sep 2010 23:07:46 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 23:07:46 GMT Message-Id: <201009062307.o86N7kpB060702@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/125617: [ath] [panic] ath(4) related 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: Mon, 06 Sep 2010 23:07:46 -0000 Old Synopsis: [ath] ath(4) related panic New Synopsis: [ath] [panic] ath(4) related panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: arundel Responsible-Changed-When: Mon Sep 6 23:07:02 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=125617 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 23:25:25 2010 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 1430810656E3; Mon, 6 Sep 2010 23:25:25 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DF6BC8FC08; Mon, 6 Sep 2010 23:25:24 +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 o86NPOer080653; Mon, 6 Sep 2010 23:25:24 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86NPOkt080649; Mon, 6 Sep 2010 23:25:24 GMT (envelope-from arundel) Date: Mon, 6 Sep 2010 23:25:24 GMT Message-Id: <201009062325.o86NPOkt080649@freefall.freebsd.org> To: eng@prowip.com.br, arundel@FreeBSD.org, freebsd-net@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/105348: [ath] ath device stopps TX 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, 06 Sep 2010 23:25:25 -0000 Synopsis: [ath] ath device stopps TX State-Changed-From-To: open->feedback State-Changed-By: arundel State-Changed-When: Mon Sep 6 23:24:38 UTC 2010 State-Changed-Why: Does this issue still occur on a supported branch? Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=105348 From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 23:49:16 2010 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 97FDD10656AB for ; Mon, 6 Sep 2010 23:49:16 +0000 (UTC) (envelope-from milu@dat.pl) Received: from jab.dat.pl (dat.pl [80.51.155.34]) by mx1.freebsd.org (Postfix) with ESMTP id 107408FC14 for ; Mon, 6 Sep 2010 23:49:15 +0000 (UTC) Received: from jab.dat.pl (jsrv.dat.pl [127.0.0.1]) by jab.dat.pl (Postfix) with ESMTP id 84D8351 for ; Tue, 7 Sep 2010 01:31:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at dat.pl Received: from jab.dat.pl ([127.0.0.1]) by jab.dat.pl (jab.dat.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5AI+n4Wtlym4 for ; Tue, 7 Sep 2010 01:31:45 +0200 (CEST) Received: from snifi.laptop (87-205-38-31.adsl.inetia.pl [87.205.38.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jab.dat.pl (Postfix) with ESMTPSA id C56DA48 for ; Tue, 7 Sep 2010 01:31:44 +0200 (CEST) To: freebsd-net@freebsd.org From: Maciej Milewski Date: Tue, 7 Sep 2010 01:31:42 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009070131.42522.milu@dat.pl> Subject: ath wpa_supplicant timeouts on AR5416 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, 06 Sep 2010 23:49:16 -0000 Hi, I have problem with card based on AR5416 (TL-WN861N) on 9-CURRENT. wpa_supplicant timeouts while connecting to 11g WPA/WPA2 network: #wpa_supplicant -iwlan1 -c /etc/wpa_supplicant.conf Trying to associate with 00:14:6c:6a:xx:xx (SSID='NET5' freq=2462 MHz) Authentication with 00:14:6c:6a:xx:xx timed out. and so on. I'm sure that network is working because I can complete the negotiation on my two other atheros based cards. Only the AR5416 has issues. #wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf Trying to associate with 00:14:6c:6a:xx:xx (SSID='NET5' freq=2462 MHz) Associated with 00:14:6c:6a:xx:xx WPA: Key negotiation completed with 00:14:6c:6a:xx:xx [PTK=CCMP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:14:6c:6a:xx:xx completed (auth) [id=0 id_str=] The one which is problematic is: ath1: irq 1 at device 18.0 on pci0 ath1: [ITHREAD] ath1: AR5416 mac 13.10 RF2122 phy 8.1 The rest which is working: ath0: irq 0 at device 17.0 on pci0 ath0: [ITHREAD] ath0: AR5212 mac 5.6 RF5111 phy 4.1 ath2: irq 2 at device 19.0 on pci0 ath2: [ITHREAD] ath2: AR2413 mac 7.8 RF2413 phy 4.5 The wpa_supplicant.conf isn't complicated: network={ ssid="NET5" psk=thelongpskphrase } AFAIR this card was working fine in hostap mode. How can I help in fixing the issue? Regards, Maciej Milewski From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 07:20:06 2010 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 5725610656B7 for ; Tue, 7 Sep 2010 07:20:06 +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 2B8E58FC08 for ; Tue, 7 Sep 2010 07:20:06 +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 o877K6Xm073907 for ; Tue, 7 Sep 2010 07:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o877K62N073906; Tue, 7 Sep 2010 07:20:06 GMT (envelope-from gnats) Date: Tue, 7 Sep 2010 07:20:06 GMT Message-Id: <201009070720.o877K62N073906@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Mark Dixon Cc: Subject: Re: kern/125332: [ath] [panic] crash under any non-tiny networking under amd64 7-STABLE with ath X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Dixon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:20:06 -0000 The following reply was made to PR kern/125332; it has been noted by GNATS. From: Mark Dixon To: bug-followup@FreeBSD.org, mnd999@gmail.com Cc: Subject: Re: kern/125332: [ath] [panic] crash under any non-tiny networking under amd64 7-STABLE with ath Date: Tue, 7 Sep 2010 07:56:48 +0100 Don't know, I don't have this PC anymore. From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 09:06:32 2010 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 1526710656D9; Tue, 7 Sep 2010 09:06:32 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E04648FC19; Tue, 7 Sep 2010 09:06:31 +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 o8796VkN012807; Tue, 7 Sep 2010 09:06:31 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8796VEH012803; Tue, 7 Sep 2010 09:06:31 GMT (envelope-from arundel) Date: Tue, 7 Sep 2010 09:06:31 GMT Message-Id: <201009070906.o8796VEH012803@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-net@FreeBSD.org, rpaulo@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: kern/140567: [ath] [patch] ath is not worked on my notebook PC 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, 07 Sep 2010 09:06:32 -0000 Synopsis: [ath] [patch] ath is not worked on my notebook PC Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: arundel Responsible-Changed-When: Tue Sep 7 09:05:59 UTC 2010 Responsible-Changed-Why: Assign to committer as MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=140567 From owner-freebsd-net@FreeBSD.ORG Tue Sep 7 19:16:12 2010 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 6426C1065672 for ; Tue, 7 Sep 2010 19:16:12 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1temp.jnielsen.net (ns1temp.jnielsen.net [69.55.230.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A5A88FC13 for ; Tue, 7 Sep 2010 19:16:12 +0000 (UTC) Received: from jnielsen.socialserve.com ([12.53.251.10]) (authenticated bits=0) by ns1temp.jnielsen.net (8.14.3/8.14.3) with ESMTP id o87IfbAj069259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 7 Sep 2010 14:41:40 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Sep 2010 14:41:31 -0400 Message-Id: <1F563B4F-B1DF-4829-966D-63264EC8AB61@jnielsen.net> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-DCC-sonic.net-Metrics: ns1temp.jnielsen.net; whitelist X-Virus-Scanned: clamav-milter 0.96.2 at ns1temp.jnielsen.net X-Virus-Status: Clean Subject: Is 802.11n rate control being worked on? 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, 07 Sep 2010 19:16:12 -0000 I am working on a network scenario which would benefit greatly from the = MIMO features and higher bandwidth of 802.11n. It's my understanding = that 11n is not fully supported in FreeBSD since there is no appropriate = rate control algorithm in the tree. Is that still the case? I would _really_ like to run FreeBSD for this project, and I believe the = Atheros wireless cards I plan to use are supported by ath(4). I'd like = to find out what else needs to happen to complete the picture. I may = even go so far as to write some code myself. :) Is anyone working on this at the moment? Is it just the rate control that needs to be done or are there other = parts involved? Is MIMO separate? Is there a detailed description of the missing pieces somewhere? Or a = not-very-detailed summary of where to look and what to read to get = started? Thanks, JN From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 12:32:54 2010 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 7F12810656C3 for ; Wed, 8 Sep 2010 12:32:54 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 595CF8FC13 for ; Wed, 8 Sep 2010 12:32:54 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id B503011B85B; Wed, 8 Sep 2010 07:32:53 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id V0N2E3ST513C; Wed, 08 Sep 2010 07:32:53 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <1F563B4F-B1DF-4829-966D-63264EC8AB61@jnielsen.net> Date: Wed, 8 Sep 2010 13:32:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB9CCE4-2F4A-4653-BF11-066E3490F3AF@FreeBSD.org> References: <1F563B4F-B1DF-4829-966D-63264EC8AB61@jnielsen.net> To: John Nielsen X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Is 802.11n rate control being worked on? 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, 08 Sep 2010 12:32:54 -0000 On 7 Sep 2010, at 19:41, John Nielsen wrote: > I am working on a network scenario which would benefit greatly from = the MIMO features and higher bandwidth of 802.11n. It's my understanding = that 11n is not fully supported in FreeBSD since there is no appropriate = rate control algorithm in the tree. Is that still the case? I've worked on supporting 11n on ath_rate_sample but it's incomplete. >=20 > I would _really_ like to run FreeBSD for this project, and I believe = the Atheros wireless cards I plan to use are supported by ath(4). I'd = like to find out what else needs to happen to complete the picture. I = may even go so far as to write some code myself. :) >=20 > Is anyone working on this at the moment? Not really, I did some work in the past, but it's incomplete. >=20 > Is it just the rate control that needs to be done or are there other = parts involved? Is MIMO separate? We have MIMO on some non-Atheros drivers, but one of these drivers = (Ralink 11n) is not yet in the tree. >=20 > Is there a detailed description of the missing pieces somewhere? Or a = not-very-detailed summary of where to look and what to read to get = started? Not really. There's some interest from other FreeBSD committers to get = this going, so I'll let them chime in. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 18:03:22 2010 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 284A610656A6 for ; Wed, 8 Sep 2010 18:03:22 +0000 (UTC) (envelope-from marcosvbuzo@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D03C98FC13 for ; Wed, 8 Sep 2010 18:03:21 +0000 (UTC) Received: by gyg4 with SMTP id 4so221532gyg.13 for ; Wed, 08 Sep 2010 11:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ZNzJn2LVamtxfMI6ohz1yOJdzH5ay5VQy7WKqA7ixzU=; b=Xhv4kTi0HTobk93kNjKGcpDi1RVhMfPKwn3hHx62wOTsIOGllckmZJHVdf65QcED1G M2BBHIbyA+JICO8InbA4YVKUoURMFrt067xZqBsUjnPycYgFnIctyDUKwrJVzquR4nsD wy4y5DmwfASSMA/cyOb9aaJXSS6/uS2SOO4Y4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HJjZr3uWaN/sUvG8DW0OqFfQCPDpJQOrYrl/gKCi3Hrz5ErZg85jH5ol4pz1CU348T lWeRmRv1mlFo4ZhX3oR8Rw1brXIDumMeMaE2QO0GlD3EekZmF8FyEzKYwJOrfNGn7HU9 3Pg8sBfuODPBDinQ7y5G6RMusGg6xseJUj2nA= MIME-Version: 1.0 Received: by 10.150.200.6 with SMTP id x6mr366901ybf.349.1283967513412; Wed, 08 Sep 2010 10:38:33 -0700 (PDT) Received: by 10.231.205.193 with HTTP; Wed, 8 Sep 2010 10:38:33 -0700 (PDT) Date: Wed, 8 Sep 2010 14:38:33 -0300 Message-ID: From: =?ISO-8859-1?Q?Marcos_Vin=EDcius_Buzo?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: MPD5 + DUMMYNET + PF HIGH CPU USAGE 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, 08 Sep 2010 18:03:22 -0000 Hi all. I just started working in a small WISP in a place of a friend that unfortunatelly is not between us anymore :( _ We're running FreeBSD 8.1 64bits with MPD5 for pppoe, IPFW+Dummynet for Traffic Shaping and PF for NAT and firewall. _ Our hardware is a Dell PowerEdge R210, X3430 Intel Xeon, 4GB 1066Mhz and a two ports Broadcom NetXtreme II BCM5716. _ Our WAN Link is 60mbps down/up. When we have 450+ pppoe connections and link usage is about 30mbps, things get strange. CPU usage goes to 80%+(Im using cacti+snmp to see this); we have high latency pings, sometimes it goes to 300ms+ and sometimes mpd5 stops doing its service. I did setup another server to work together, it solves the problem just for now, in this server i disabled flowtable (sysctl net.inet.flowtable.enable=0), because in the old server, when i run top -ISH, I see the following: 22 root 44 - 0K 16K CPU2 2 236:19 100.00% flowcleaner Is this a bug ? Are the following customizations right ? Here are the custom kernel flags: #NETGRAPH options HZ=2000 options NETGRAPH options NETGRAPH_PPPOE options NETGRAPH_SOCKET options NETGRAPH_CISCO options NETGRAPH_ECHO options NETGRAPH_FRAME_RELAY options NETGRAPH_HOLE #options NETGRAPH_KSOCKET options NETGRAPH_LMI options NETGRAPH_RFC1490 options NETGRAPH_TTY options NETGRAPH_ASYNC options NETGRAPH_BPF options NETGRAPH_ETHER options NETGRAPH_IFACE options NETGRAPH_KSOCKET options NETGRAPH_L2TP options NETGRAPH_MPPC_ENCRYPTION options NETGRAPH_PPP options NETGRAPH_PPTPGRE options NETGRAPH_TEE options NETGRAPH_UI options NETGRAPH_VJC # bridge support, device polling support, other security features #options BRIDGE options DEVICE_POLLING options IPSTEALTH # support for ALTQ traffic shaping options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ # options ALTQ_NOPCC # support for pf firewall #device mem device pf device pflog device pfsync # IPFW options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET /boot/loader.conf: kern.maxusers=1024 net.graph.maxdata=8192 net.graph.maxalloc=16384 # this rule help you to support more than 800 ng devices, when mpd starts kern.ipc.maxpipekva=62000000 net.inet.tcp.tcbhashsize=4096 /etc/sysctl.conf: net.inet.ip.portrange.last=65535 net.inet.ip.portrange.first=1024 #kern.maxfilesperproc=32768 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 #compat.linux.osrelease=2.6.16 net.inet.ip.fastforwarding=1 net.inet.tcp.rfc1323=1 net.graph.maxdgram=128000 net.graph.recvspace=128000 kern.maxvnodes=100000000 kern.ipc.somaxconn=65535 kern.ipc.nmbclusters=262140 net.inet.tcp.maxtcptw=280960 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.msl=1460 net.inet.icmp.icmplim=0 kern.ipc.maxsockbuf=16777216 kern.ipc.maxsockets=232000 #net.inet.tcp.recvspace=16772216 #net.inet.tcp.sendspace=16772216 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.recvbuf_max=16777216 kern.ipc.shmmax=2147483648 net.inet.tcp.fast_finwait2_recycle=1 net.inet.tcp.ecn.enable=1 kern.maxvnodes=100000000 kern.ipc.somaxconn=65535 kern.ipc.nmbclusters=262140 net.inet.tcp.maxtcptw=80960 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.msl=5000 net.inet.icmp.icmplim=0 Thanks in advance. From owner-freebsd-net@FreeBSD.ORG Wed Sep 8 18:53:12 2010 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 A892C10656E6 for ; Wed, 8 Sep 2010 18:53:12 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9978FC20 for ; Wed, 8 Sep 2010 18:53:12 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 08 Sep 2010 14:20:43 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::5228 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-net@freebsd.org X-SMFBL: ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc= Message-ID: <4C87D80C.3020200@comcast.net> Date: Wed, 08 Sep 2010 14:38:04 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.7) Gecko/20100805 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marcos_Vin=EDcius_Buzo?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: MPD5 + DUMMYNET + PF HIGH CPU USAGE 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, 08 Sep 2010 18:53:12 -0000 On 09/08/10 13:38, Marcos Vinícius Buzo wrote: > Hi all. > > I just started working in a small WISP in a place of a friend that > unfortunatelly is not between us anymore :( > _ We're running FreeBSD 8.1 64bits with MPD5 for pppoe, IPFW+Dummynet for > Traffic Shaping and PF for NAT and firewall. > _ Our hardware is a Dell PowerEdge R210, X3430 Intel Xeon, 4GB 1066Mhz and a > two ports Broadcom NetXtreme II BCM5716. > _ Our WAN Link is 60mbps down/up. > > When we have 450+ pppoe connections and link usage is about 30mbps, things > get strange. > CPU usage goes to 80%+(Im using cacti+snmp to see this); we have high > latency pings, sometimes it goes to 300ms+ and sometimes mpd5 stops doing > its service. > > I did setup another server to work together, it solves the problem just for > now, in this server i disabled flowtable (sysctl > net.inet.flowtable.enable=0), because in the old server, when i run top > -ISH, I see the following: > > 22 root 44 - 0K 16K CPU2 2 236:19 100.00% flowcleaner > > Is this a bug ? > > Are the following customizations right ? > > Here are the custom kernel flags: > ... > kern.maxvnodes=100000000 > ... 100 million vnodes sounds like a lot for a system that is not doing IO with lots of files. I guess the worst it's going to do is sucking up some extra memory. I can't speak much for the flowtable, but with 450+ clients, you are surely hitting the limits of the default number of entries there. $ sysctl net.inet.ip.output_flowtable_size net.inet.ip.output_flowtable_size: 32768 $ sysctl -d net.inet.ip.output_flowtable_size net.inet.ip.output_flowtable_size: number of entries in the per-cpu output flow caches With 4 CPUs, that tracks a maximum of 128k flows. With 450 clients behind, I could see you easily exceeding that rapidly. You may want to try doubling (or tripling) this value via loader.conf on the main system and seeing if that helps a lot (the flowcleaner may not have to constantly work if you are not always close to the maximum number of flows). I'm not sure of the specifics of the flow table, so someone else could probably chime in with some more information on it (I can't find any real documentation on the feature). With such a high number of flows, you may just be better turning it off anyways. From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 08:24:02 2010 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 4E49A10656E5; Thu, 9 Sep 2010 08:24:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 241248FC16; Thu, 9 Sep 2010 08:24:02 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8411846B09; Thu, 9 Sep 2010 04:24:01 -0400 (EDT) Date: Thu, 9 Sep 2010 09:24:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Garrett Wollman In-Reply-To: <201008311830.o7VIUBig022098@hergotha.csail.mit.edu> Message-ID: References: <4C7A7B25.9040300@freebsd.org> <4C7D02BB.40300@freebsd.org> <7B42D7FB-B782-4EE9-8813-BF7D3ED3274B@lurchi.franken.de> <201008311830.o7VIUBig022098@hergotha.csail.mit.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: andre@freebsd.org, net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP 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, 09 Sep 2010 08:24:02 -0000 On Tue, 31 Aug 2010, Garrett Wollman wrote: > In article <4C7D02BB.40300@freebsd.org> andre@freebsd.org writes: > >> sendto() will not be touched or modified. It's just that on a TCP socket >> the tcp protocol will not perform an implied connect anymore. The only >> thing that changes is TCP dropping a deprecated and experimental extension >> and behaving like every other UNIXy OS. > > That's a little bit disingenuous, methinks. Support for the "deprecated and > experimental extension" -- RFC 1644 -- was dropped a number of years ago. > (Longer ago than I can easily recall.) The implict open/close mechanism is > orthogonal to the long-gone support for RFC 1644. There may be good reasons > to remove it anyway, but please don't claim that the status of RFC 1644 has > anyting to do with it. This is very much my opinion: the protocol feature and the API feature are independent, killing the protocol feature doesn't mean that we can or should remove the API feature. I suspect removing implied connect from other protocols *would* break things, and I would much rather we continued to implement the API consistently across all protocols than that it become mix-and-match. One thing that is on my plate for the next year or two is continuing the migration from the socket layer driving certain state transitions to the socket layer acting as a library for protocols in managing state transitions. This would help address some rarely-triggered race conditions that result from doing a socket-level test-and-set on so_state (and similar) before entering the protocol to propagate the change down. In general, our lock order has protocol locks before socket locks, and so it makes more sense to drive things the other way (a change I've made for the listen transitions but not for general socket state management). This sort of change might help reduce redundancy between socket and protocol code in the send / connect path as well. (My intent is not to take this as far as Linux has taken that philosophy: they share very little socket-level code between protocols, whereas I want to continue to provide an extensive library of common socket code -- on the other hand, I do want the protocol code to drive calls to the socket library, rather than having a lot of code in the socket layer driving things). Robert From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 10:37:42 2010 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 EEA1510656BB for ; Thu, 9 Sep 2010 10:37:42 +0000 (UTC) (envelope-from igor@sysoev.ru) Received: from sysoev.ru (sysoev.ru [81.19.68.137]) by mx1.freebsd.org (Postfix) with ESMTP id AB9EF8FC08 for ; Thu, 9 Sep 2010 10:37:42 +0000 (UTC) Received: from sysoev.ru ([81.19.68.137] helo=localhost) by sysoev.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OteFK-000ElL-OR for freebsd-net@FreeBSD.org; Thu, 09 Sep 2010 14:20:46 +0400 Date: Thu, 9 Sep 2010 14:20:46 +0400 From: Igor Sysoev To: freebsd-net@FreeBSD.org Message-ID: <20100909102046.GA53812@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: bge hangs on recent 7.3-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 10:37:43 -0000 Hi, I have several hosts running FreeBSD/amd64 7.2-STABLE updated on 11.01.2010 and 25.02.2010. Hosts process about 10K input and 10K output packets/s without issues. One of them, however, is loaded more than others, so it processes 20K/20K packets/s. Recently, I have upgraded one host to 7.3-STABLE, 24.08.2010. Then bge on this host hung two times. I was able to restart it from console using: /etc/rc.d/netif restart bge0 Then I have upgraded the most loaded (20K/20K) host to 7.3-STABLE, 07.09.2010. After reboot bge hung every several seconds. I was able to restart it, but bge hung after several seconds. Then I have downgraded this host to 7.3-STABLE, 14.08.2010, since there were several if_bge.c commits on 15.08.2010. The same hangs. Then I have downgraded this host to 7.3-STABLE, 17.03.2010, before the first if_bge.c commit after 25.02.2010. Now it runs without hangs. The hosts are amd64 dual core SMP with 4G machines. bge information: bge0@pci0:4:0:0: class=0x020000 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:e0:81:5f:6e:8a bge has 3 vlans: bge0: flags=8943 metric 0 mtu 15 00 options=9b ether 00:e0:81:5f:6e:8a media: Ethernet autoselect (1000baseTX ) status: active vlan173: flags=8843 metric 0 mtu 1500 options=3 ether 00:e0:81:5f:6e:8a inet 192.168.173.101 netmask 0xffffff00 broadcast 192.168.173.255 media: Ethernet autoselect (1000baseTX ) status: active vlan: 173 parent interface: bge0 [ ... ] -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 10:43:30 2010 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 18B2110656A4 for ; Thu, 9 Sep 2010 10:43:30 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id CA6758FC13 for ; Thu, 9 Sep 2010 10:43:29 +0000 (UTC) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 02E27192DCAF for ; Thu, 9 Sep 2010 14:28:26 +0400 (MSD) Date: Thu, 9 Sep 2010 14:28:26 +0400 From: Igor Sysoev To: freebsd-net@FreeBSD.org Message-ID: <20100909102826.GB53812@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: bge hangs on recent 7.3-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 10:43:30 -0000 Hi, I have several hosts running FreeBSD/amd64 7.2-STABLE updated on 11.01.2010 and 25.02.2010. Hosts process about 10K input and 10K output packets/s without issues. One of them, however, is loaded more than others, so it processes 20K/20K packets/s. Recently, I have upgraded one host to 7.3-STABLE, 24.08.2010. Then bge on this host hung two times. I was able to restart it from console using: /etc/rc.d/netif restart bge0 Then I have upgraded the most loaded (20K/20K) host to 7.3-STABLE, 07.09.2010. After reboot bge hung every several seconds. I was able to restart it, but bge hung again after several seconds. Then I have downgraded this host to 7.3-STABLE, 14.08.2010, since there were several if_bge.c commits on 15.08.2010. The same hangs. Then I have downgraded this host to 7.3-STABLE, 17.03.2010, before the first if_bge.c commit after 25.02.2010. Now it runs without hangs. The hosts are amd64 dual core SMP with 4G machines. bge information: bge0@pci0:4:0:0: class=0x020000 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:e0:81:5f:6e:8a bge has 3 vlans: bge0: flags=8943 metric 0 mtu 15 00 options=9b ether 00:e0:81:5f:6e:8a media: Ethernet autoselect (1000baseTX ) status: active vlan173: flags=8843 metric 0 mtu 1500 options=3 ether 00:e0:81:5f:6e:8a inet 192.168.173.101 netmask 0xffffff00 broadcast 192.168.173.255 media: Ethernet autoselect (1000baseTX ) status: active vlan: 173 parent interface: bge0 [ ... ] -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 10:55:10 2010 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 7773510656B2 for ; Thu, 9 Sep 2010 10:55:10 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 373028FC12 for ; Thu, 9 Sep 2010 10:55:09 +0000 (UTC) Received: by qwg5 with SMTP id 5so285808qwg.13 for ; Thu, 09 Sep 2010 03:55:09 -0700 (PDT) Received: by 10.229.87.134 with SMTP id w6mr1075535qcl.297.1284029709292; Thu, 09 Sep 2010 03:55:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.38.83 with HTTP; Thu, 9 Sep 2010 03:54:29 -0700 (PDT) In-Reply-To: <20100909102826.GB53812@rambler-co.ru> References: <20100909102826.GB53812@rambler-co.ru> From: Vlad Galu Date: Thu, 9 Sep 2010 13:54:29 +0300 Message-ID: To: Igor Sysoev Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: bge hangs on recent 7.3-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 10:55:10 -0000 2010/9/9 Igor Sysoev : > Hi, > > I have several hosts running FreeBSD/amd64 7.2-STABLE updated on 11.01.20= 10 > and 25.02.2010. Hosts process about 10K input and 10K output packets/s > without issues. One of them, however, is loaded more than others, so it > processes 20K/20K packets/s. > > Recently, I have upgraded one host to 7.3-STABLE, 24.08.2010. > Then bge on this host hung two times. I was able to restart it from > console using: > =9A/etc/rc.d/netif restart bge0 > > Then I have upgraded the most loaded (20K/20K) host to 7.3-STABLE, 07.09.= 2010. > After reboot bge hung every several seconds. I was able to restart it, > but bge hung again after several seconds. > > Then I have downgraded this host to 7.3-STABLE, 14.08.2010, since there > were several if_bge.c commits on 15.08.2010. The same hangs. > Then I have downgraded this host to 7.3-STABLE, 17.03.2010, before > the first if_bge.c commit after 25.02.2010. Now it runs without hangs. > > The hosts are amd64 dual core SMP with 4G machines. bge information: > > bge0@pci0:4:0:0: =9A =9A =9A =9Aclass=3D0x020000 card=3D0x165914e4 chip= =3D0x165914e4 rev=3D0x11 hdr=3D0x00 > =9A =9Avendor =9A =9A =3D 'Broadcom Corporation' > =9A =9Adevice =9A =9A =3D 'NetXtreme Gigabit Ethernet PCI Express (BCM572= 1)' > > bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 > miibus1: on bge0 > brgphy0: PHY 1 on miibus1 > brgphy0: =9A10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10= 00baseT-FDX, auto > bge0: Ethernet address: 00:e0:81:5f:6e:8a > > bge has 3 vlans: > > bge0: flags=3D8943 metric= 0 mtu 15 > 00 > =9A =9A =9A =9Aoptions=3D9b > =9A =9A =9A =9Aether 00:e0:81:5f:6e:8a > =9A =9A =9A =9Amedia: Ethernet autoselect (1000baseTX ) > =9A =9A =9A =9Astatus: active > > vlan173: flags=3D8843 metric 0 mt= u 1500 > =9A =9A =9A =9Aoptions=3D3 > =9A =9A =9A =9Aether 00:e0:81:5f:6e:8a > =9A =9A =9A =9Ainet 192.168.173.101 netmask 0xffffff00 broadcast 192.168.= 173.255 > =9A =9A =9A =9Amedia: Ethernet autoselect (1000baseTX ) > =9A =9A =9A =9Astatus: active > =9A =9A =9A =9Avlan: 173 parent interface: bge0 > > [ ... ] I've been having the same issues with this exact adapter on two RELENG_8 machines. Howevery, my traffic isn't as intense as yours, so the issue occurs far less often. I'll downgrade the bge(4) driver to the revision that works for you and I'll report back in a few days. --=20 Good, fast & cheap. Pick any two. From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 13:45:47 2010 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 56CEF10656D6 for ; Thu, 9 Sep 2010 13:45:47 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1temp.jnielsen.net (ns1temp.jnielsen.net [69.55.230.42]) by mx1.freebsd.org (Postfix) with ESMTP id DD5A48FC1E for ; Thu, 9 Sep 2010 13:45:46 +0000 (UTC) Received: from [192.168.2.43] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1temp.jnielsen.net (8.14.3/8.14.3) with ESMTP id o89DjjXV045298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 9 Sep 2010 09:45:45 -0400 (EDT) (envelope-from lists@jnielsen.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Nielsen In-Reply-To: <9EB9CCE4-2F4A-4653-BF11-066E3490F3AF@FreeBSD.org> Date: Thu, 9 Sep 2010 09:45:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F563B4F-B1DF-4829-966D-63264EC8AB61@jnielsen.net> <9EB9CCE4-2F4A-4653-BF11-066E3490F3AF@FreeBSD.org> To: Rui Paulo X-Mailer: Apple Mail (2.1081) X-DCC-x.dcc-servers-Metrics: ns1temp.jnielsen.net; whitelist Cc: freebsd-net@freebsd.org Subject: Re: Is 802.11n rate control being worked on? 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, 09 Sep 2010 13:45:47 -0000 On Sep 8, 2010, at 8:32 AM, Rui Paulo wrote: > On 7 Sep 2010, at 19:41, John Nielsen wrote: >=20 >> I am working on a network scenario which would benefit greatly from = the MIMO features and higher bandwidth of 802.11n. It's my understanding = that 11n is not fully supported in FreeBSD since there is no appropriate = rate control algorithm in the tree. Is that still the case? >=20 > I've worked on supporting 11n on ath_rate_sample but it's incomplete. >=20 >>=20 >> I would _really_ like to run FreeBSD for this project, and I believe = the Atheros wireless cards I plan to use are supported by ath(4). I'd = like to find out what else needs to happen to complete the picture. I = may even go so far as to write some code myself. :) >>=20 >> Is anyone working on this at the moment? >=20 > Not really, I did some work in the past, but it's incomplete. >=20 >>=20 >> Is it just the rate control that needs to be done or are there other = parts involved? Is MIMO separate? >=20 > We have MIMO on some non-Atheros drivers, but one of these drivers = (Ralink 11n) is not yet in the tree. That would be interesting to look at. Is the code somewhere publicly = available? Is it slated to hit the tree soon? >> Is there a detailed description of the missing pieces somewhere? Or a = not-very-detailed summary of where to look and what to read to get = started? >=20 > Not really. There's some interest from other FreeBSD committers to get = this going, so I'll let them chime in. Surprisingly silent so far. Is there a better list to post this to? Thanks, JN From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 17:37:15 2010 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 96B7B1065694 for ; Thu, 9 Sep 2010 17:37:15 +0000 (UTC) (envelope-from marcosvbuzo@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 5D8258FC15 for ; Thu, 9 Sep 2010 17:37:15 +0000 (UTC) Received: by iwn34 with SMTP id 34so1489220iwn.13 for ; Thu, 09 Sep 2010 10:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Pm7JtfObAhzV+7US+qZ5i5XR1zGuaCub1y80Cm9OqOM=; b=YA27tlegujDNWzC5LOvOM1+Oimiv/bGgdC5ZlbnpJM41jMt7fWviZdG4P9ampC+Il1 J8fVdZ2Ltqcc4Q1FX0uK5OARMvBdPyrGYrGPixPXOqYtwM0jPci0mdoIB8kJ1TCuVBIy Dhbm/UCUrXZrQlzoTwpClKxoljzXBt5DAB8k8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IpEDzW+WxcsPXXXx/EUqdq3kQwU9Z+hmduNiLbdVr7ILSX271cEwA7271EsqpJTZsN 0q8u0AvxqXISV/Ls8gf20QRH3QL/VikoskuULVwraeCCKJltFracqhpbs5baac0IOIg/ vimN+nwEDQTc0PdzivC4MtxvRcuSXZdtqg5g4= MIME-Version: 1.0 Received: by 10.231.149.12 with SMTP id r12mr12033957ibv.185.1284053834493; Thu, 09 Sep 2010 10:37:14 -0700 (PDT) Received: by 10.231.205.193 with HTTP; Thu, 9 Sep 2010 10:37:14 -0700 (PDT) In-Reply-To: <4C87D80C.3020200@comcast.net> References: <4C87D80C.3020200@comcast.net> Date: Thu, 9 Sep 2010 14:37:14 -0300 Message-ID: From: =?ISO-8859-1?Q?Marcos_Vin=EDcius_Buzo?= To: Steve Polyack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: MPD5 + DUMMYNET + PF HIGH CPU USAGE 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, 09 Sep 2010 17:37:15 -0000 > > Thank you guys. Im going to try disablling PF and let only IPFW + Dummynet > working, i will also disable flowtable. > What do you think about net.isr ? Could it help in my situation ? Thanks From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:11:10 2010 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 75839106571F for ; Thu, 9 Sep 2010 20:11:10 +0000 (UTC) (envelope-from pyunyh@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 44C9F8FC0A for ; Thu, 9 Sep 2010 20:11:10 +0000 (UTC) Received: by pvc21 with SMTP id 21so142236pvc.13 for ; Thu, 09 Sep 2010 13:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=NnqBt8is6LWy75kxo9pIyM9RaithddIDwVGj4WL5dqY=; b=BK9TYcTJ68yRFq1DpZQEiqtlWkyH8ZgO4eDQEqlqFMChcjrO8Kv+x4vbkyA9aamNWr Vdj4d6TdZXLy5LRel+eTZtRQBt7opru5EgB923/ISIrPV0f0fz2Y0RDicA4JpKCo4U+7 2Pb/q+TNbDU/+szvZXYNLYJIBPLsSz1bVajCA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=TR50Xh8/njCPUk4RR1BaeZb55FJ47yWXBx24q51QMcdzXzNzj5HpbmMDBNZOXc5M8w L90K9rVLh33D9WOl4an84pLaPt2CvpOWH2Bd40ExfZN3YocNCEc7fyK+q0IWgfBbIptr 9BfowrRk9K/Qgko4ROeRNmMzkrvpX+DszFd98= Received: by 10.114.172.2 with SMTP id u2mr144068wae.198.1284063069727; Thu, 09 Sep 2010 13:11:09 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id r37sm2897418wak.11.2010.09.09.13.11.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 13:11:07 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 9 Sep 2010 13:10:50 -0700 From: Pyun YongHyeon Date: Thu, 9 Sep 2010 13:10:50 -0700 To: Igor Sysoev Message-ID: <20100909201050.GG7203@michelle.cdnetworks.com> References: <20100909102826.GB53812@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100909102826.GB53812@rambler-co.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge hangs on recent 7.3-STABLE 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, 09 Sep 2010 20:11:10 -0000 On Thu, Sep 09, 2010 at 02:28:26PM +0400, Igor Sysoev wrote: > Hi, > > I have several hosts running FreeBSD/amd64 7.2-STABLE updated on 11.01.2010 > and 25.02.2010. Hosts process about 10K input and 10K output packets/s > without issues. One of them, however, is loaded more than others, so it > processes 20K/20K packets/s. > > Recently, I have upgraded one host to 7.3-STABLE, 24.08.2010. > Then bge on this host hung two times. I was able to restart it from > console using: > /etc/rc.d/netif restart bge0 > > Then I have upgraded the most loaded (20K/20K) host to 7.3-STABLE, 07.09.2010. > After reboot bge hung every several seconds. I was able to restart it, > but bge hung again after several seconds. > > Then I have downgraded this host to 7.3-STABLE, 14.08.2010, since there > were several if_bge.c commits on 15.08.2010. The same hangs. > Then I have downgraded this host to 7.3-STABLE, 17.03.2010, before > the first if_bge.c commit after 25.02.2010. Now it runs without hangs. > > The hosts are amd64 dual core SMP with 4G machines. bge information: > > bge0@pci0:4:0:0: class=0x020000 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' > > bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 > miibus1: on bge0 > brgphy0: PHY 1 on miibus1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge0: Ethernet address: 00:e0:81:5f:6e:8a > Could you show me verbose boot message(bge part only)? Also show me the output of "pciconf -lcbv". > bge has 3 vlans: > > bge0: flags=8943 metric 0 mtu 15 > 00 > options=9b > ether 00:e0:81:5f:6e:8a > media: Ethernet autoselect (1000baseTX ) > status: active > > vlan173: flags=8843 metric 0 mtu 1500 > options=3 > ether 00:e0:81:5f:6e:8a > inet 192.168.173.101 netmask 0xffffff00 broadcast 192.168.173.255 > media: Ethernet autoselect (1000baseTX ) > status: active > vlan: 173 parent interface: bge0 > > [ ... ] From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 20:58:41 2010 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 A818410656E7 for ; Thu, 9 Sep 2010 20:58:41 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com [207.126.144.111]) by mx1.freebsd.org (Postfix) with SMTP id 2B7298FC23 for ; Thu, 9 Sep 2010 20:58:39 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob101.postini.com ([207.126.147.11]) with SMTP ID DSNKTIlKfVEStNdnNCC9vyVjrS5lAiE1adxg@postini.com; Thu, 09 Sep 2010 20:58:40 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id EE458FD01A; Thu, 9 Sep 2010 20:58:36 +0000 (UTC) Message-ID: <4C894A76.5040200@tomjudge.com> Date: Thu, 09 Sep 2010 15:58:30 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org, davidch@broadcom.com, yongari@FreeBSD.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: bce(4) - com_no_buffers (Again) 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, 09 Sep 2010 20:58:41 -0000 Hi, I am just following up on the thread from March (I think) about this issue. We are seeing this issue on a number of systems running 7.1. The systems in question are all Dell: * R710 R610 R410 * PE2950 The latter do not show the issue as much as the R series systems. The cards in one of the R610's that I am testing with are: bce0@pci0:1:0:0: class=0x020000 card=0x02361028 chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II BCM5709 Gigabit Ethernet' class = network subclass = ethernet They are connected to Dell PowerConnect 5424 switches. uname -a: FreeBSD bandor.chi-dc.mintel.ad 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #3: Wed Sep 8 08:19:03 UTC 2010 tj@dev-tj-7-1-amd64.chicago.mintel.ad:/usr/obj/usr/src/sys/MINTELv10 amd64 We are also using 8192 byte jumbo frames, if_lagg and if_vlan in the configuration (the nics are in promisc as we are currently capturing netflow data on another vlan for diagnostic purposes. ): tj@bandor '20:51:17' '~' > $ ifconfig bce0 bce0: flags=8943 metric 0 mtu 8192 options=400bb ether 00:21:9b:95:7a:b8 media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 tj@bandor '20:51:22' '~' > $ ifconfig bce1 bce1: flags=8943 metric 0 mtu 8192 options=400bb ether 00:21:9b:95:7a:b8 media: Ethernet autoselect (1000baseTX ) status: active lagg: laggdev lagg0 tj@bandor '20:51:35' '~' > $ ifconfig lagg0 lagg0: flags=8943 metric 0 mtu 8192 options=400bb ether 00:21:9b:95:7a:b8 media: Ethernet autoselect status: active laggproto failover laggport: bce1 flags=0<> laggport: bce0 flags=5 tj@bandor '20:51:40' '~' > $ ifconfig vlan2 vlan2: flags=8943 metric 0 mtu 8192 options=3 ether 00:21:9b:95:7a:b8 inet 172.30.XX.XX netmask 0xfffffe00 broadcast 172.30.XX.XX media: Ethernet autoselect status: active vlan: 2 parent interface: lagg0 I have updated the bce driver and the Broadcomm MII driver to the version from stable/7 and am still seeing the issue. This morning I did a test with increasing the RX_PAGES to 8 but the system just hung starting the network. The route command got stuck in a zone state (Sorry can't remember exactly which). The real question is, how do we go about increasing the number of RX BDs? I guess we have to bump more that just RX_PAGES... The cause for us, from what we can see, is the openldap server sending large group search results back to nss_ldap or pam_ldap. When it does this it seems to send each of the 600 results in its own TCP segment creating a small packet storm (600*~100byte PDU's) at the destination host. The kernel then retransmits 2 blocks of 100 results each after SACK kicks in for the data that was dropped by the NIC. Thanks in advance Tom tj@bandor '20:57:33' '~' > $ sysctl -a dev.bce.0 dev.bce.0.%desc: Broadcom NetXtreme II BCM5709 1000Base-T (C0) dev.bce.0.%driver: bce dev.bce.0.%location: slot=0 function=0 dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x1639 subvendor=0x1028 subdevice=0x0236 class=0x020000 dev.bce.0.%parent: pci1 dev.bce.0.l2fhdr_error_count: 0 dev.bce.0.mbuf_alloc_failed_count: 0 dev.bce.0.mbuf_frag_count: 0 dev.bce.0.dma_map_addr_rx_failed_count: 0 dev.bce.0.dma_map_addr_tx_failed_count: 0 dev.bce.0.unexpected_attention_count: 0 dev.bce.0.stat_IfHcInOctets: 439779802 dev.bce.0.stat_IfHCInBadOctets: 0 dev.bce.0.stat_IfHCOutOctets: 108341440 dev.bce.0.stat_IfHCOutBadOctets: 0 dev.bce.0.stat_IfHCInUcastPkts: 2341369 dev.bce.0.stat_IfHCInMulticastPkts: 26065 dev.bce.0.stat_IfHCInBroadcastPkts: 9191 dev.bce.0.stat_IfHCOutUcastPkts: 1230052 dev.bce.0.stat_IfHCOutMulticastPkts: 2870 dev.bce.0.stat_IfHCOutBroadcastPkts: 45 dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 dev.bce.0.stat_Dot3StatsFCSErrors: 0 dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 dev.bce.0.stat_Dot3StatsLateCollisions: 0 dev.bce.0.stat_EtherStatsCollisions: 0 dev.bce.0.stat_EtherStatsFragments: 0 dev.bce.0.stat_EtherStatsJabbers: 0 dev.bce.0.stat_EtherStatsUndersizePkts: 0 dev.bce.0.stat_EtherStatsOversizePkts: 0 dev.bce.0.stat_EtherStatsPktsRx64Octets: 3381 dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 98883 dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 2255959 dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 12508 dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 4247 dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 522 dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 1125 dev.bce.0.stat_EtherStatsPktsTx64Octets: 496 dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 1176041 dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 29079 dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 2933 dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 23898 dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 234 dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 286 dev.bce.0.stat_XonPauseFramesReceived: 0 dev.bce.0.stat_XoffPauseFramesReceived: 0 dev.bce.0.stat_OutXonSent: 0 dev.bce.0.stat_OutXoffSent: 0 dev.bce.0.stat_FlowControlDone: 0 dev.bce.0.stat_MacControlFramesReceived: 0 dev.bce.0.stat_XoffStateEntered: 0 dev.bce.0.stat_IfInFramesL2FilterDiscards: 0 dev.bce.0.stat_IfInRuleCheckerDiscards: 0 dev.bce.0.stat_IfInFTQDiscards: 0 dev.bce.0.stat_IfInMBUFDiscards: 0 dev.bce.0.stat_IfInRuleCheckerP4Hit: 35256 dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 dev.bce.0.stat_CatchupInFTQDiscards: 0 dev.bce.0.stat_CatchupInMBUFDiscards: 0 dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 dev.bce.0.com_no_buffers: 13021 -- TJU13-ARIN From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 21:00:31 2010 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 C85AA10657C4 for ; Thu, 9 Sep 2010 21:00:31 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8D0E48FC14 for ; Thu, 9 Sep 2010 21:00:31 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id 0959911B922; Thu, 9 Sep 2010 16:00:31 -0500 (CDT) Received: from 10.0.10.2 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id HIUU4THMPV0T; Thu, 09 Sep 2010 16:00:31 -0500 References: <1F563B4F-B1DF-4829-966D-63264EC8AB61@jnielsen.net> <9EB9CCE4-2F4A-4653-BF11-066E3490F3AF@FreeBSD.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Thu, 9 Sep 2010 22:00:27 +0100 To: John Nielsen X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org Subject: Re: Is 802.11n rate control being worked on? 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, 09 Sep 2010 21:00:31 -0000 On 9 Sep 2010, at 14:45, John Nielsen wrote: > On Sep 8, 2010, at 8:32 AM, Rui Paulo wrote: >=20 >> On 7 Sep 2010, at 19:41, John Nielsen wrote: >>=20 >>> I am working on a network scenario which would benefit greatly from = the MIMO features and higher bandwidth of 802.11n. It's my understanding = that 11n is not fully supported in FreeBSD since there is no appropriate = rate control algorithm in the tree. Is that still the case? >>=20 >> I've worked on supporting 11n on ath_rate_sample but it's incomplete. >>=20 >>>=20 >>> I would _really_ like to run FreeBSD for this project, and I believe = the Atheros wireless cards I plan to use are supported by ath(4). I'd = like to find out what else needs to happen to complete the picture. I = may even go so far as to write some code myself. :) >>>=20 >>> Is anyone working on this at the moment? >>=20 >> Not really, I did some work in the past, but it's incomplete. >>=20 >>>=20 >>> Is it just the rate control that needs to be done or are there other = parts involved? Is MIMO separate? >>=20 >> We have MIMO on some non-Atheros drivers, but one of these drivers = (Ralink 11n) is not yet in the tree. >=20 > That would be interesting to look at. Is the code somewhere publicly = available? Is it slated to hit the tree soon? There's a git repo somewhere on the net; can't remember where. This = information should be in the FreeBSD forums. The driver is for the = rt2860. >=20 >>> Is there a detailed description of the missing pieces somewhere? Or = a not-very-detailed summary of where to look and what to read to get = started? >>=20 >> Not really. There's some interest from other FreeBSD committers to = get this going, so I'll let them chime in. >=20 > Surprisingly silent so far. Is there a better list to post this to? There aren't many folks working on this. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 21:18:35 2010 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 767E310656AB for ; Thu, 9 Sep 2010 21:18:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4302E8FC1C for ; Thu, 9 Sep 2010 21:18:35 +0000 (UTC) Received: by pwi8 with SMTP id 8so828649pwi.13 for ; Thu, 09 Sep 2010 14:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=JKyFu6rm3dpyzOp2+gXvXGACMqrbUilVcp+GegEddaI=; b=CchE5CeYJVnNwgdVyg4DEYGIhCgieRyfEswRB7p7UUYAl3Yopc/lC6tWfkby525lo9 0Enmg4hQfXYVJZkfCLslWLe5XgXh/1HDTLgA31zjO6EY/FksaFUifUefDI18fxB4HfYL NSSD192wnMaURN+5pUoEqoL4inf68jaAIo9Ws= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ic2Lb9B7V70XctEHHx8tRYkalAJVFhZACQJTEMd0Ake8cgWqFqzMthKAf/NjWBLNXD heQr1SX54L2KVjAFOMwwW921jYzyxrSRFs1kxsMfLjXCCZIQiTK2zd2mbFQJZkhkjTwB Tn2R/UAjHyrT/SshVbLTdPfxacFhwIT7JNes0= Received: by 10.114.110.16 with SMTP id i16mr85698wac.208.1284067107829; Thu, 09 Sep 2010 14:18:27 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id k23sm3003290waf.17.2010.09.09.14.18.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 14:18:26 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 9 Sep 2010 14:18:08 -0700 From: Pyun YongHyeon Date: Thu, 9 Sep 2010 14:18:08 -0700 To: Igor Sysoev Message-ID: <20100909211808.GJ7203@michelle.cdnetworks.com> References: <20100909102826.GB53812@rambler-co.ru> <20100909201050.GG7203@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <20100909201050.GG7203@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge hangs on recent 7.3-STABLE 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, 09 Sep 2010 21:18:35 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 09, 2010 at 01:10:50PM -0700, Pyun YongHyeon wrote: > On Thu, Sep 09, 2010 at 02:28:26PM +0400, Igor Sysoev wrote: > > Hi, > > > > I have several hosts running FreeBSD/amd64 7.2-STABLE updated on 11.01.2010 > > and 25.02.2010. Hosts process about 10K input and 10K output packets/s > > without issues. One of them, however, is loaded more than others, so it > > processes 20K/20K packets/s. > > > > Recently, I have upgraded one host to 7.3-STABLE, 24.08.2010. > > Then bge on this host hung two times. I was able to restart it from > > console using: > > /etc/rc.d/netif restart bge0 > > > > Then I have upgraded the most loaded (20K/20K) host to 7.3-STABLE, 07.09.2010. > > After reboot bge hung every several seconds. I was able to restart it, > > but bge hung again after several seconds. > > > > Then I have downgraded this host to 7.3-STABLE, 14.08.2010, since there > > were several if_bge.c commits on 15.08.2010. The same hangs. > > Then I have downgraded this host to 7.3-STABLE, 17.03.2010, before > > the first if_bge.c commit after 25.02.2010. Now it runs without hangs. > > > > The hosts are amd64 dual core SMP with 4G machines. bge information: > > > > bge0@pci0:4:0:0: class=0x020000 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' > > > > bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 > > miibus1: on bge0 > > brgphy0: PHY 1 on miibus1 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > bge0: Ethernet address: 00:e0:81:5f:6e:8a > > > > Could you show me verbose boot message(bge part only)? > Also show me the output of "pciconf -lcbv". > Forgot to send a patch. Let me know whether attached patch fixes the issue or not. --w7PDEPdKQumQfZlR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.rx.patch" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 212341) +++ sys/dev/bge/if_bge.c (working copy) @@ -3386,9 +3386,11 @@ sc->bge_rx_saved_considx = rx_cons; bge_writembx(sc, BGE_MBX_RX_CONS0_LO, sc->bge_rx_saved_considx); if (stdcnt) - bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, sc->bge_std); + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, (sc->bge_std + + BGE_STD_RX_RING_CNT - 1) % BGE_STD_RX_RING_CNT); if (jumbocnt) - bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, sc->bge_jumbo); + bge_writembx(sc, BGE_MBX_RX_JUMBO_PROD_LO, (sc->bge_jumbo + + BGE_JUMBO_RX_RING_CNT - 1) % BGE_JUMBO_RX_RING_CNT); #ifdef notyet /* * This register wraps very quickly under heavy packet drops. --w7PDEPdKQumQfZlR-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 21:40:54 2010 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 3DFBB10656AA for ; Thu, 9 Sep 2010 21:40:54 +0000 (UTC) (envelope-from chris@brueffer.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id C08DF8FC1B for ; Thu, 9 Sep 2010 21:40:53 +0000 (UTC) Received: from brueffer.de (84-73-206-110.dclient.hispeed.ch [84.73.206.110]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LaHYA-1OT3Ty3wzO-00lVGR; Thu, 09 Sep 2010 23:28:09 +0200 Received: by brueffer.de (Postfix, from userid 1001) id 125A617025; Thu, 9 Sep 2010 21:28:07 +0200 (CEST) Date: Thu, 9 Sep 2010 21:28:06 +0200 From: Christian Brueffer To: Bernhard Schmidt Message-ID: <20100909192806.GD2338@serenity> References: <20100905165308.00000d99@unknown> <201009051852.05469.bschmidt@techwires.net> <201009051911.59912.bschmidt@techwires.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8TaQrIeukR7mmbKf" Content-Disposition: inline In-Reply-To: <201009051911.59912.bschmidt@techwires.net> X-Operating-System: FreeBSD 9.0-CURRENT X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.19 (2009-01-05) X-Provags-ID: V02:K0:BIioQJ+I2XKBNVJ0yKLFb9C3szP+0ZO14l4Tt4XyAvB EbCryfFKjg9pd5eM5rXfrLqwnaOEcfICc2fJyAz9zLoFhVnkxQ 7zQs0T+XD2o8S23g9D+HcDfFL2/1QVW1ELltoC1XJ3xVDFcUGy QIviwSY0/GEZBmcoNeda5m8G0F+Kni8pifOngYHgtswk5xrtBN VBM5HxnoXnv59BRHiEmYzAcIOyOxrmI87k0mxgT+ak= Cc: Bruce Cran , freebsd-net@freebsd.org Subject: Re: mwl(4) depends on non-existant mwlfw_fw (mwlfw doesn't implement mwlfw_fw) 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, 09 Sep 2010 21:40:54 -0000 --8TaQrIeukR7mmbKf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 05, 2010 at 07:11:59PM +0200, Bernhard Schmidt wrote: > On Sunday 05 September 2010 18:52:05 Bernhard Schmidt wrote: > > On Sunday 05 September 2010 17:53:08 Bruce Cran wrote: > > > Hi, > > >=20 > > > I was trying to help someone on IRC with a card that should be > > > supported by the mwl(4) driver, but it seems it's broken: mwlfw(4) > > > doesn't implement mwlfw_fw which if_mwl depends on > > > ("MODULE_DEPEND(mwl, mwlfw_fw, 1, 1, 1);"). > >=20 > > This is wrong. It should depend on firmware(9), which also takes care of > > loading the adequate firmware modules. > >=20 > > > Should it be trying to load mw88W8363fw dynamically instead? > >=20 > > Yes, firmware(9) does that. > >=20 > > > The same error appears to be in malo(4) too - and neither mwlfw(4) or > > > malofw(4) are installed during an installkernel despite mwl(4) and > > > malo(4) being installed. > >=20 > > Seems like there is a MFC missing those get installed on HEAD. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D144494 >=20 Oops, this fell through the cracks due to the missing MFC reminder trigger. Fixed! - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --8TaQrIeukR7mmbKf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkyJNUYACgkQbHYXjKDtmC0hzgCgucIBypofh+QJt+otEWFVLbl9 4WQAn3+JDsIh1nZleAv376uNv3bGzBg6 =PqkJ -----END PGP SIGNATURE----- --8TaQrIeukR7mmbKf-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 9 22:30:20 2010 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 983E21065694 for ; Thu, 9 Sep 2010 22:30:20 +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 6AC118FC08 for ; Thu, 9 Sep 2010 22:30: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 o89MUKNZ014808 for ; Thu, 9 Sep 2010 22:30:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o89MUKPd014802; Thu, 9 Sep 2010 22:30:20 GMT (envelope-from gnats) Date: Thu, 9 Sep 2010 22:30:20 GMT Message-Id: <201009092230.o89MUKPd014802@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/148322: 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, 09 Sep 2010 22:30:20 -0000 The following reply was made to PR kern/148322; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/148322: commit references a PR Date: Thu, 9 Sep 2010 22:28:07 +0000 (UTC) pgollucci 2010-09-09 22:28:03 UTC FreeBSD ports repository Modified files: devel Makefile Added files: devel/pecl-xhprof Makefile distinfo pkg-descr Log: XHProf is a function-level hierarchical profiler for PHP and has a simple HTML based navigational interface. The raw data collection component is implemented in C (as a PHP extension). The reporting/UI layer is all in PHP. It is capable of reporting function-level inclusive and exclusive wall times, memory usage, CPU times and number of calls for each function. Additionally, it supports ability to compare two runs (hierarchical DIFF reports), or aggregate results from multiple runs. WWW: http://pecl.php.net/package/xhprof/ PR: ports/148322 Submitted by: Conor McDermottroe Revision Changes Path 1.4037 +1 -0 ports/devel/Makefile 1.1 +24 -0 ports/devel/pecl-xhprof/Makefile (new) 1.1 +3 -0 ports/devel/pecl-xhprof/distinfo (new) 1.1 +9 -0 ports/devel/pecl-xhprof/pkg-descr (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 00:24:59 2010 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 A7DCB106566B; Fri, 10 Sep 2010 00:24:59 +0000 (UTC) (envelope-from pyunyh@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 6FCE48FC20; Fri, 10 Sep 2010 00:24:59 +0000 (UTC) Received: by pvc21 with SMTP id 21so235305pvc.13 for ; Thu, 09 Sep 2010 17:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=HTvSQPX7GM1XdxjIXZf/TPHQBUptDcjN1Kc2+et7sSQ=; b=A+nYoC5alKCIwpw8gdxt4OZ388IBAbr4F9xCcQYEjWK/bbs3DYRPAIZZGfZvkyjo08 NhJzJ1PG3OyoUhM+oq6t2bZV9DGbcVeLMRodL46cEP5num7aEBAnt7SNqrMazQHaOABs J6M/97veyKqcHRDjYLZjZLpbVegKraFQjxLZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Z34tIhud63GOvfe4VAtzLtLFkuETVi0wkPN0y+DtrBhFAsxu98b9Rhy2j61jzQjKbg oNvk3ANzelDRxjzyUf9mWO2Ove3o24wSRoQky6CxGces6OB2e0HEKVxToJ4KkN4sU6Bv NxSVaZ2yxhIxlCbSCVJHO5J8PBr2hC4xzmg0Y= Received: by 10.114.92.17 with SMTP id p17mr72046wab.226.1284078298624; Thu, 09 Sep 2010 17:24:58 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id o17sm3284287wal.9.2010.09.09.17.24.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 17:24:57 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 9 Sep 2010 17:24:39 -0700 From: Pyun YongHyeon Date: Thu, 9 Sep 2010 17:24:39 -0700 To: Tom Judge Message-ID: <20100910002439.GO7203@michelle.cdnetworks.com> References: <4C894A76.5040200@tomjudge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C894A76.5040200@tomjudge.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, davidch@broadcom.com, yongari@freebsd.org Subject: Re: bce(4) - com_no_buffers (Again) 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: Fri, 10 Sep 2010 00:24:59 -0000 On Thu, Sep 09, 2010 at 03:58:30PM -0500, Tom Judge wrote: > Hi, > > I am just following up on the thread from March (I think) about this issue. > > We are seeing this issue on a number of systems running 7.1. > > The systems in question are all Dell: > > * R710 R610 R410 > * PE2950 > > The latter do not show the issue as much as the R series systems. > > The cards in one of the R610's that I am testing with are: > > bce0@pci0:1:0:0: class=0x020000 card=0x02361028 chip=0x163914e4 > rev=0x20 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme II BCM5709 Gigabit Ethernet' > class = network > subclass = ethernet > > They are connected to Dell PowerConnect 5424 switches. > > uname -a: > FreeBSD bandor.chi-dc.mintel.ad 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 > #3: Wed Sep 8 08:19:03 UTC 2010 > tj@dev-tj-7-1-amd64.chicago.mintel.ad:/usr/obj/usr/src/sys/MINTELv10 amd64 > > We are also using 8192 byte jumbo frames, if_lagg and if_vlan in the > configuration (the nics are in promisc as we are currently capturing > netflow data on another vlan for diagnostic purposes. ): > > tj@bandor '20:51:17' '~' > > $ ifconfig bce0 > bce0: flags=8943 metric > 0 mtu 8192 > > options=400bb > ether 00:21:9b:95:7a:b8 > media: Ethernet autoselect (1000baseTX ) > status: active > lagg: laggdev lagg0 > tj@bandor '20:51:22' '~' > > $ ifconfig bce1 > bce1: flags=8943 metric > 0 mtu 8192 > > options=400bb > ether 00:21:9b:95:7a:b8 > media: Ethernet autoselect (1000baseTX ) > status: active > lagg: laggdev lagg0 > tj@bandor '20:51:35' '~' > > $ ifconfig lagg0 > lagg0: flags=8943 metric > 0 mtu 8192 > > options=400bb > ether 00:21:9b:95:7a:b8 > media: Ethernet autoselect > status: active > laggproto failover > laggport: bce1 flags=0<> > laggport: bce0 flags=5 > tj@bandor '20:51:40' '~' > > $ ifconfig vlan2 > vlan2: flags=8943 metric > 0 mtu 8192 > options=3 > ether 00:21:9b:95:7a:b8 > inet 172.30.XX.XX netmask 0xfffffe00 broadcast 172.30.XX.XX > media: Ethernet autoselect > status: active > vlan: 2 parent interface: lagg0 > > > I have updated the bce driver and the Broadcomm MII driver to the > version from stable/7 and am still seeing the issue. > > This morning I did a test with increasing the RX_PAGES to 8 but the > system just hung starting the network. The route command got stuck in a > zone state (Sorry can't remember exactly which). > > The real question is, how do we go about increasing the number of RX > BDs? I guess we have to bump more that just RX_PAGES... > > > The cause for us, from what we can see, is the openldap server sending > large group search results back to nss_ldap or pam_ldap. When it does > this it seems to send each of the 600 results in its own TCP segment > creating a small packet storm (600*~100byte PDU's) at the destination > host. The kernel then retransmits 2 blocks of 100 results each after > SACK kicks in for the data that was dropped by the NIC. > > > Thanks in advance > > Tom > > tj@bandor '20:57:33' '~' > > $ sysctl -a dev.bce.0 > dev.bce.0.%desc: Broadcom NetXtreme II BCM5709 1000Base-T (C0) > dev.bce.0.%driver: bce > dev.bce.0.%location: slot=0 function=0 > dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x1639 subvendor=0x1028 > subdevice=0x0236 class=0x020000 > dev.bce.0.%parent: pci1 > dev.bce.0.l2fhdr_error_count: 0 > dev.bce.0.mbuf_alloc_failed_count: 0 > dev.bce.0.mbuf_frag_count: 0 > dev.bce.0.dma_map_addr_rx_failed_count: 0 > dev.bce.0.dma_map_addr_tx_failed_count: 0 > dev.bce.0.unexpected_attention_count: 0 > dev.bce.0.stat_IfHcInOctets: 439779802 > dev.bce.0.stat_IfHCInBadOctets: 0 > dev.bce.0.stat_IfHCOutOctets: 108341440 > dev.bce.0.stat_IfHCOutBadOctets: 0 > dev.bce.0.stat_IfHCInUcastPkts: 2341369 > dev.bce.0.stat_IfHCInMulticastPkts: 26065 > dev.bce.0.stat_IfHCInBroadcastPkts: 9191 > dev.bce.0.stat_IfHCOutUcastPkts: 1230052 > dev.bce.0.stat_IfHCOutMulticastPkts: 2870 > dev.bce.0.stat_IfHCOutBroadcastPkts: 45 > dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 > dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 > dev.bce.0.stat_Dot3StatsFCSErrors: 0 > dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 > dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 > dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 > dev.bce.0.stat_Dot3StatsLateCollisions: 0 > dev.bce.0.stat_EtherStatsCollisions: 0 > dev.bce.0.stat_EtherStatsFragments: 0 > dev.bce.0.stat_EtherStatsJabbers: 0 > dev.bce.0.stat_EtherStatsUndersizePkts: 0 > dev.bce.0.stat_EtherStatsOversizePkts: 0 > dev.bce.0.stat_EtherStatsPktsRx64Octets: 3381 > dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 98883 > dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 2255959 > dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 12508 > dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 4247 > dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 522 > dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 1125 > dev.bce.0.stat_EtherStatsPktsTx64Octets: 496 > dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 1176041 > dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 29079 > dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 2933 > dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 23898 > dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 234 > dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 286 > dev.bce.0.stat_XonPauseFramesReceived: 0 > dev.bce.0.stat_XoffPauseFramesReceived: 0 > dev.bce.0.stat_OutXonSent: 0 > dev.bce.0.stat_OutXoffSent: 0 > dev.bce.0.stat_FlowControlDone: 0 > dev.bce.0.stat_MacControlFramesReceived: 0 > dev.bce.0.stat_XoffStateEntered: 0 > dev.bce.0.stat_IfInFramesL2FilterDiscards: 0 > dev.bce.0.stat_IfInRuleCheckerDiscards: 0 > dev.bce.0.stat_IfInFTQDiscards: 0 > dev.bce.0.stat_IfInMBUFDiscards: 0 > dev.bce.0.stat_IfInRuleCheckerP4Hit: 35256 > dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 > dev.bce.0.stat_CatchupInFTQDiscards: 0 > dev.bce.0.stat_CatchupInMBUFDiscards: 0 > dev.bce.0.stat_CatchupInRuleCheckerP4Hit: 0 > dev.bce.0.com_no_buffers: 13021 > FW may drop incoming frames when it does not see available RX buffers. Increasing number of RX buffers slightly reduce the possibility of dropping frames but it wouldn't completely fix it. Alternatively driver may tell available RX buffers in the middle of RX ring processing instead of giving updated buffers at the end of RX processing. This way FW may see available RX buffers while driver/upper stack is busy to process received frames. But this may introduce coherency issues because the RX ring is shared between host and FW. If FreeBSD has way to sync partial region of a DMA map, this could be implemented without fear of coherency issue. Another way to improve RX performance would be switching to multi-RX queue with RSS but that would require a lot of work and I had no time to implement it. BTW, given that you've updated to bce(4)/mii(4) of stable/7, I wonder why TX/RX flow controls were not kicked in. From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 03:39:18 2010 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 2C069106566C for ; Fri, 10 Sep 2010 03:39:18 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id DD13F8FC19 for ; Fri, 10 Sep 2010 03:39:17 +0000 (UTC) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 06428192DCB1; Fri, 10 Sep 2010 07:39:15 +0400 (MSD) Date: Fri, 10 Sep 2010 07:39:15 +0400 From: Igor Sysoev To: Pyun YongHyeon Message-ID: <20100910033915.GA93982@rambler-co.ru> References: <20100909102826.GB53812@rambler-co.ru> <20100909201050.GG7203@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20100909201050.GG7203@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: bge hangs on recent 7.3-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 03:39:18 -0000 On Thu, Sep 09, 2010 at 01:10:50PM -0700, Pyun YongHyeon wrote: > On Thu, Sep 09, 2010 at 02:28:26PM +0400, Igor Sysoev wrote: > > Hi, > > > > I have several hosts running FreeBSD/amd64 7.2-STABLE updated on 11.01.2010 > > and 25.02.2010. Hosts process about 10K input and 10K output packets/s > > without issues. One of them, however, is loaded more than others, so it > > processes 20K/20K packets/s. > > > > Recently, I have upgraded one host to 7.3-STABLE, 24.08.2010. > > Then bge on this host hung two times. I was able to restart it from > > console using: > > /etc/rc.d/netif restart bge0 > > > > Then I have upgraded the most loaded (20K/20K) host to 7.3-STABLE, 07.09.2010. > > After reboot bge hung every several seconds. I was able to restart it, > > but bge hung again after several seconds. > > > > Then I have downgraded this host to 7.3-STABLE, 14.08.2010, since there > > were several if_bge.c commits on 15.08.2010. The same hangs. > > Then I have downgraded this host to 7.3-STABLE, 17.03.2010, before > > the first if_bge.c commit after 25.02.2010. Now it runs without hangs. > > > > The hosts are amd64 dual core SMP with 4G machines. bge information: > > > > bge0@pci0:4:0:0: class=0x020000 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' > > > > bge0: mem 0xfe5f0000-0xfe5fffff irq 19 at device 0.0 on pci4 > > miibus1: on bge0 > > brgphy0: PHY 1 on miibus1 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > bge0: Ethernet address: 00:e0:81:5f:6e:8a > > > > Could you show me verbose boot message(bge part only)? > Also show me the output of "pciconf -lcbv". Here is "pciconf -lcbv", I will send the "boot -v" part later. bge0@pci0:4:0:0: class=0x020000 card=0x165914e4 chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' class = network subclass = ethernet bar [10] = type Memory, range 64, base 0xfe5f0000, size 65536, enabled cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 04:48:49 2010 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 3208E106566C for ; Fri, 10 Sep 2010 04:48:48 +0000 (UTC) (envelope-from alphancedong@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C3F9E8FC18 for ; Fri, 10 Sep 2010 04:48:48 +0000 (UTC) Received: by pxi17 with SMTP id 17so947669pxi.13 for ; Thu, 09 Sep 2010 21:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=px249lc1g30BAPqSX7iWuB9ReMIcebYrze8eOuxvve8=; b=Ox2jDqx20qRrIxkrzrZ1uL1tgQDhlHiYE6agkHfteMOVvDHKRaJq4G0H5wQe9KuVQc aP/+vx0EQhtYC5v2tSptDwzgIBmV2e/SdMQ0zT/JAuMOEmYZohgCclkuaq/r942GKKxv ksXW2WUDRcAvsNcsKWc394qQ89I22EBmQlIf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=jSPyfVyC+IqsKWEjgKCRAR4QC9EpUQLydZD6htMx6IFscg32LOMQw/z89dKQOv6tn+ n0C32VsjqFJMA9aCghICYGaFpQfcy36yuQDUDRB6BkolfKdx+dfjEP/wJMcTypnQeZbI 2E8MmVmPPzFQ2UH9SIg6uEwCx0gyJNc6+5yws= Received: by 10.114.15.11 with SMTP id 11mr290659wao.121.1284092701958; Thu, 09 Sep 2010 21:25:01 -0700 (PDT) Received: from [114.101.96.65] ([114.101.96.65]) by mx.google.com with ESMTPS id x9sm3635722waj.15.2010.09.09.21.24.55 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 21:25:00 -0700 (PDT) Message-ID: <4C89B315.7020501@gmail.com> Date: Fri, 10 Sep 2010 12:24:53 +0800 From: alphancedong User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: how to use freebsd8 dial the adsl for shuffering? 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, 10 Sep 2010 04:48:49 -0000 hello,all guys.I'm a newer for using bsd,I come from china. I have no ideal now because i setup the ppp.conf and resolv.conf(add the dns server),but ppp is still not work!I delete all the things in ppp.conf ,then add a label adsl and authname key ,but when i ppp -auto adsl ,it can link lan but not intenet(my modem can work like route ,suppot create a lan,but computer stiil need dial for intenet).i really need help,thanks.oh this is the my ppp.conf : ADSL: set device PPPoE:fx0 set authname ** set authkey ** set dial set speed sync set mru 1492 set mtu 1492 set ctsrts off set login add adsl HISADDR From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 08:14:30 2010 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 2A87C106566C for ; Fri, 10 Sep 2010 08:14:30 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B48D58FC13 for ; Fri, 10 Sep 2010 08:14:29 +0000 (UTC) Received: by bwz20 with SMTP id 20so2340285bwz.13 for ; Fri, 10 Sep 2010 01:14:28 -0700 (PDT) Received: by 10.204.15.148 with SMTP id k20mr318394bka.74.1284106468587; Fri, 10 Sep 2010 01:14:28 -0700 (PDT) Received: from jessie.localnet (p5B0E3D6C.dip0.t-ipconnect.de [91.14.61.108]) by mx.google.com with ESMTPS id y2sm1785461bkx.20.2010.09.10.01.14.26 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 01:14:27 -0700 (PDT) From: Bernhard Schmidt To: Christian Brueffer Date: Fri, 10 Sep 2010 10:14:24 +0200 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <20100905165308.00000d99@unknown> <201009051911.59912.bschmidt@techwires.net> <20100909192806.GD2338@serenity> In-Reply-To: <20100909192806.GD2338@serenity> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201009101014.25068.bschmidt@techwires.net> Cc: Bruce Cran , freebsd-net@freebsd.org Subject: Re: mwl(4) depends on non-existant mwlfw_fw (mwlfw doesn't implement mwlfw_fw) 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, 10 Sep 2010 08:14:30 -0000 On Thursday, September 09, 2010 21:28:06 Christian Brueffer wrote: > On Sun, Sep 05, 2010 at 07:11:59PM +0200, Bernhard Schmidt wrote: > > On Sunday 05 September 2010 18:52:05 Bernhard Schmidt wrote: > > > On Sunday 05 September 2010 17:53:08 Bruce Cran wrote: > > > > Hi, > > > > > > > > I was trying to help someone on IRC with a card that should be > > > > supported by the mwl(4) driver, but it seems it's broken: mwlfw(4) > > > > doesn't implement mwlfw_fw which if_mwl depends on > > > > ("MODULE_DEPEND(mwl, mwlfw_fw, 1, 1, 1);"). > > > > > > This is wrong. It should depend on firmware(9), which also takes care > > > of loading the adequate firmware modules. I committed a fix for the firmware module dependencies. Thanks for pointing this out! > > > > Should it be trying to load mw88W8363fw dynamically instead? > > > > > > Yes, firmware(9) does that. > > > > > > > The same error appears to be in malo(4) too - and neither mwlfw(4) or > > > > malofw(4) are installed during an installkernel despite mwl(4) and > > > > malo(4) being installed. > > > > > > Seems like there is a MFC missing those get installed on HEAD. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=144494 > > Oops, this fell through the cracks due to the missing MFC reminder > trigger. Fixed! Thanks! -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 07:54:22 2010 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 0F2F01065698 for ; Fri, 10 Sep 2010 07:54:22 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2158FC21 for ; Fri, 10 Sep 2010 07:54:21 +0000 (UTC) Received: by ewy4 with SMTP id 4so1710196ewy.13 for ; Fri, 10 Sep 2010 00:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:x-priority :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=iQI1HEkhpj0clyzFMGCndIvyDRqQ35alzUabeXiomik=; b=SIrZ8QIijACW14hjQCrSrkC+xj4RwslFmrAtRgnKWOIh8qa/tNukvvpksyawOXPdQH YHsdQlx7xQFuwO2HX7lIWxABLsjAD5K5rmEXp9ovYw2XavvMq3diPkCnfXhSmDm0f1EO GN241gwIH6vhkcByrngNvVzsP15nyd8GLnMVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:x-priority:message-id:to:cc:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=fQhwPnxIbkklmgP0plPqEsB6F0fazBs6SUJGG8NULbifou1WX+xZ60TcZ/3fdNfDnZ 9GEDoWI++wmFeDr8KKTvhDhrIgmqVLXRmTovEDPPuJyFiQt6j5n2yr1XjZ4OO8fk1dW1 ie9EOCDcmG7aXlUwTfZ0v87oM5VfZu+GUU3s8= Received: by 10.213.35.77 with SMTP id o13mr738305ebd.11.1284105260583; Fri, 10 Sep 2010 00:54:20 -0700 (PDT) Received: from 55.dynamic-n194.in72.ru ([91.211.194.55]) by mx.google.com with ESMTPS id u9sm3455677eeh.11.2010.09.10.00.54.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Sep 2010 00:54:19 -0700 (PDT) Date: Fri, 10 Sep 2010 13:54:10 +0600 From: =?gb2312?B?p6Wn3qfap+Sn4qfap9sgp6mn0afep+Wn4qfRp9an0yAoRG1pdHJpeSBaYW11cmFldik=?= X-Priority: 3 (Normal) Message-ID: <1401014603.20100910135410@gmail.com> To: alphancedong In-Reply-To: <4C89B315.7020501@gmail.com> References: <4C89B315.7020501@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 10 Sep 2010 11:14:25 +0000 Cc: freebsd-net@freebsd.org Subject: Re: how to use freebsd8 dial the adsl for shuffering? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?gb2312?B?p6Wn3qfap+Sn4qfap9sgp6mn0afep+Wn4qfRp9an0yAoRG1pdHJpeSBaYW11cmFldik=?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 07:54:22 -0000 > set device PPPoE:fx0 is this correct ? maybe fxp0 From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 19:02:11 2010 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 EEACE1065670 for ; Fri, 10 Sep 2010 19:02:11 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id C2A508FC0A for ; Fri, 10 Sep 2010 19:02:11 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Ou8rR-000P9v-Ky; Fri, 10 Sep 2010 15:02:09 -0400 Date: Fri, 10 Sep 2010 15:02:09 -0400 From: Gary Palmer To: "?????????????? ???????????????? (Dmitriy Zamuraev)" Message-ID: <20100910190209.GA381@in-addr.com> References: <4C89B315.7020501@gmail.com> <1401014603.20100910135410@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401014603.20100910135410@gmail.com> Cc: alphancedong , freebsd-net@freebsd.org Subject: Re: how to use freebsd8 dial the adsl for shuffering? 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, 10 Sep 2010 19:02:12 -0000 On Fri, Sep 10, 2010 at 01:54:10PM +0600, ?????????????? ???????????????? (Dmitriy Zamuraev) wrote: > > set device PPPoE:fx0 > > is this correct ? maybe fxp0 If they have an ethernet to ADSL bridge on fxp0 then that is correct. I have a Linksys ADSL modem in brdiging mode and that syntax works for me. In my case it says: set device PPPoE:vr1 Regards, Gary From owner-freebsd-net@FreeBSD.ORG Fri Sep 10 22:06:36 2010 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 DEA6A106566C for ; Fri, 10 Sep 2010 22:06:35 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp171.iad.emailsrvr.com (smtp171.iad.emailsrvr.com [207.97.245.171]) by mx1.freebsd.org (Postfix) with ESMTP id 971CD8FC0A for ; Fri, 10 Sep 2010 22:06:35 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp37.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 23D7C3B026D; Fri, 10 Sep 2010 17:51:24 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp37.relay.iad1a.emailsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id DEB763B01C2; Fri, 10 Sep 2010 17:51:23 -0400 (EDT) Message-ID: <4C8AA863.4060908@xiplink.com> Date: Fri, 10 Sep 2010 17:51:31 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Robert Watson References: <4C7A7B25.9040300@freebsd.org> <4C7D0089.1020104@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: Removal of deprecated implied connect for TCP 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, 10 Sep 2010 22:06:36 -0000 On 31/08/2010 5:32 PM, Robert Watson wrote: > > On Tue, 31 Aug 2010, Andre Oppermann wrote: > >>> I'm not entirely comfortable with this change, and would like a >>> chance to cogitate on it a bit more. While I'm not aware of any >>> applications depending on the semantic for TCP, I know that we do >>> use it for UNIX domain sockets. >> >> I don't have any plans to remove the implied connect support from the >> socket layer or other protocols, only from TCP. > > Right -- the implicit question is: why should TCP be the only stream > protocol in our stack *not* to support implied connection, when we > plan to continue to support it for all other protocols? > >> For deprecating this part of the TCP API there is no documentation to >> the implied connect in tcp(4). In sendto(2) it doesn't differentiate >> between protocols and simply says: "... sendto() and sendmsg() may be >> used at any time." For MSG_EOF it says that is only supported for >> SOCK_STREAM sockets in the PF_INET protocol family. These sentences >> have to be corrected. > > In general, deprecating is taken to mean providing significant and > explicit advance warning of removal -- for example, updating the 8.x > man page to point out that the feature is deprecated and it will not > appear in future releases of FreeBSD. > > Robert > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Hi, For what its worth, we at Xiphos (now XipLink), are still using sendto and T/TCP and is one of the reasons we've chosen FreeBSD more then 10 years ago! Best regards, Karim. From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 03:05:26 2010 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 9E6E41065673 for ; Sat, 11 Sep 2010 03:05:26 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 63E8D8FC1B for ; Sat, 11 Sep 2010 03:05:24 +0000 (UTC) Received: (qmail 4069 invoked from network); 11 Sep 2010 05:05:21 +0200 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Sep 2010 05:05:21 +0200 Date: Sat, 11 Sep 2010 05:05:20 +0200 (CEST) From: Ingo Flaschberger To: "Li, Qing" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168430090-52481847-1284174321=:5369" Cc: Qing Li , net@freebsd.org Subject: RE: funny ECMP 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, 11 Sep 2010 03:05:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --168430090-52481847-1284174321=:5369 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Dear Li, attached latest version of ecmp patch. Kind regards, Ingo Flaschberger --168430090-52481847-1284174321=:5369 Content-Type: TEXT/plain; name=mpath_patch_if_v3.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=mpath_patch_if_v3.txt ZGlmZiAtciAtdSAvdXNyX2RpZmYvc3JjL3N5cy9jb250cmliL2lwZmlsdGVy L25ldGluZXQvaXBfcG9vbC5jIC91c3Ivc3JjL3N5cy9jb250cmliL2lwZmls dGVyL25ldGluZXQvaXBfcG9vbC5jDQotLS0gL3Vzcl9kaWZmL3NyYy9zeXMv Y29udHJpYi9pcGZpbHRlci9uZXRpbmV0L2lwX3Bvb2wuYwkyMDA3LTEwLTE4 IDIxOjQyOjM4LjAwMDAwMDAwMCArMDAwMA0KKysrIC91c3Ivc3JjL3N5cy9j b250cmliL2lwZmlsdGVyL25ldGluZXQvaXBfcG9vbC5jCTIwMTAtMDktMDYg MTE6MjI6MzkuMDAwMDAwMDAwICswMDAwDQpAQCAtNjIwLDcgKzYyMCw3IEBA DQogDQogCVJBRElYX05PREVfSEVBRF9MT0NLKGlwby0+aXBvX2hlYWQpOw0K IAlpcG8tPmlwb19oZWFkLT5ybmhfZGVsYWRkcigmaXBlLT5pcG5fYWRkciwg JmlwZS0+aXBuX21hc2ssDQotCQkJCSAgIGlwby0+aXBvX2hlYWQpOw0KKwkJ CQkgICBpcG8tPmlwb19oZWFkLCBOVUxMKTsNCiAJUkFESVhfTk9ERV9IRUFE X1VOTE9DSyhpcG8tPmlwb19oZWFkKTsNCiANCiAJaXBfcG9vbF9ub2RlX2Rl cmVmKGlwZSk7DQpAQCAtNzUxLDcgKzc1MSw3IEBADQogCVJBRElYX05PREVf SEVBRF9MT0NLKGlwby0+aXBvX2hlYWQpOw0KIAl3aGlsZSAoKG4gPSBpcG8t Pmlwb19saXN0KSAhPSBOVUxMKSB7DQogCQlpcG8tPmlwb19oZWFkLT5ybmhf ZGVsYWRkcigmbi0+aXBuX2FkZHIsICZuLT5pcG5fbWFzaywNCi0JCQkJCSAg IGlwby0+aXBvX2hlYWQpOw0KKwkJCQkJICAgaXBvLT5pcG9faGVhZCwgTlVM TCk7DQogDQogCQkqbi0+aXBuX3BuZXh0ID0gbi0+aXBuX25leHQ7DQogCQlp ZiAobi0+aXBuX25leHQpDQpAQCAtOTYzLDcgKzk2Myw3IEBADQogCXN0cnVj dCByYWRpeF9ub2RlX2hlYWQgKnJuaCA9IHA7DQogCXN0cnVjdCByYWRpeF9u b2RlICpkOw0KIA0KLQlkID0gcm5oLT5ybmhfZGVsYWRkcihuLT5ybl9rZXks IE5VTEwsIHJuaCk7DQorCWQgPSBybmgtPnJuaF9kZWxhZGRyKG4tPnJuX2tl eSwgTlVMTCwgcm5oLCBOVUxMKTsNCiAJaWYgKGQgIT0gTlVMTCkgew0KIAkJ RnJlZVMoZCwgbWF4X2tleWxlbiArIDIgKiBzaXplb2YgKCpkKSk7DQogCX0N CmRpZmYgLXIgLXUgL3Vzcl9kaWZmL3NyYy9zeXMvY29udHJpYi9wZi9uZXQv cGYuYyAvdXNyL3NyYy9zeXMvY29udHJpYi9wZi9uZXQvcGYuYw0KLS0tIC91 c3JfZGlmZi9zcmMvc3lzL2NvbnRyaWIvcGYvbmV0L3BmLmMJMjAxMC0wMS0y MyAwMDozMjoxOS4wMDAwMDAwMDAgKzAwMDANCisrKyAvdXNyL3NyYy9zeXMv Y29udHJpYi9wZi9uZXQvcGYuYwkyMDEwLTA5LTA2IDExOjIyOjM5LjAwMDAw MDAwMCArMDAwMA0KQEAgLTk5LDkgKzk5LDcgQEANCiAjaW5jbHVkZSA8bmV0 L2lmX3R5cGVzLmg+DQogI2luY2x1ZGUgPG5ldC9icGYuaD4NCiAjaW5jbHVk ZSA8bmV0L3JvdXRlLmg+DQotI2lmbmRlZiBfX0ZyZWVCU0RfXw0KICNpbmNs dWRlIDxuZXQvcmFkaXhfbXBhdGguaD4NCi0jZW5kaWYNCiANCiAjaW5jbHVk ZSA8bmV0aW5ldC9pbi5oPg0KICNpbmNsdWRlIDxuZXRpbmV0L2luX3Zhci5o Pg0KQEAgLTYxNjYsOSArNjE2NCw5IEBADQogCQkJaWYgKGtpZi0+cGZpa19p ZnAgPT0gaWZwKQ0KIAkJCQlyZXQgPSAxOw0KICNpZmRlZiBfX0ZyZWVCU0Rf XyAvKiBNVUxUSVBBVEhfUk9VVElORyAqLw0KLQkJCXJuID0gTlVMTDsNCisJ CQlybiA9IHJuX21wYXRoX25leHQocm4pOyAvKiBYWFggd2FzIGJlZm9yZTog cm4gPSBOVUxMOyAqLw0KICNlbHNlDQotCQkJcm4gPSBybl9tcGF0aF9uZXh0 KHJuKTsNCisJCQlybiA9IHJuX21wYXRoX25leHQocm4sIDApOw0KICNlbmRp Zg0KIAkJfSB3aGlsZSAoY2hlY2tfbXBhdGggPT0gMSAmJiBybiAhPSBOVUxM ICYmIHJldCA9PSAwKTsNCiAJfSBlbHNlDQpkaWZmIC1yIC11IC91c3JfZGlm Zi9zcmMvc3lzL2NvbnRyaWIvcGYvbmV0L3BmX3RhYmxlLmMgL3Vzci9zcmMv c3lzL2NvbnRyaWIvcGYvbmV0L3BmX3RhYmxlLmMNCi0tLSAvdXNyX2RpZmYv c3JjL3N5cy9jb250cmliL3BmL25ldC9wZl90YWJsZS5jCTIwMDktMDgtMDMg MDg6MTM6MDYuMDAwMDAwMDAwICswMDAwDQorKysgL3Vzci9zcmMvc3lzL2Nv bnRyaWIvcGYvbmV0L3BmX3RhYmxlLmMJMjAxMC0wOS0wNiAxMToyMjozOS4w MDAwMDAwMDAgKzAwMDANCkBAIC0xMTE0LDE3ICsxMTE0LDkgQEANCiAjZW5k aWYNCiAJaWYgKEtFTlRSWV9ORVRXT1JLKGtlKSkgew0KIAkJcGZyX3ByZXBh cmVfbmV0d29yaygmbWFzaywga2UtPnBmcmtlX2FmLCBrZS0+cGZya2VfbmV0 KTsNCi0jaWZkZWYgX19GcmVlQlNEX18NCi0JCXJuID0gcm5fZGVsZXRlKCZr ZS0+cGZya2Vfc2EsICZtYXNrLCBoZWFkKTsNCi0jZWxzZQ0KIAkJcm4gPSBy bl9kZWxldGUoJmtlLT5wZnJrZV9zYSwgJm1hc2ssIGhlYWQsIE5VTEwpOw0K LSNlbmRpZg0KIAl9IGVsc2UNCi0jaWZkZWYgX19GcmVlQlNEX18NCi0JCXJu ID0gcm5fZGVsZXRlKCZrZS0+cGZya2Vfc2EsIE5VTEwsIGhlYWQpOw0KLSNl bHNlDQogCQlybiA9IHJuX2RlbGV0ZSgma2UtPnBmcmtlX3NhLCBOVUxMLCBo ZWFkLCBOVUxMKTsNCi0jZW5kaWYNCiAJc3BseChzKTsNCiANCiAJaWYgKHJu ID09IE5VTEwpIHsNCmRpZmYgLXIgLXUgL3Vzcl9kaWZmL3NyYy9zeXMvbmV0 L3JhZGl4LmMgL3Vzci9zcmMvc3lzL25ldC9yYWRpeC5jDQotLS0gL3Vzcl9k aWZmL3NyYy9zeXMvbmV0L3JhZGl4LmMJMjAxMC0wNC0wMiAwNTowMjo1MC4w MDAwMDAwMDAgKzAwMDANCisrKyAvdXNyL3NyYy9zeXMvbmV0L3JhZGl4LmMJ MjAxMC0wOS0xMSAwMTozOTo0MC4wMDAwMDAwMDAgKzAwMDANCkBAIC02MTQs NyArNjE0LDcgQEANCiAJc3RydWN0IHJhZGl4X25vZGUgdHJlZW5vZGVzWzJd Ow0KIHsNCiAJY2FkZHJfdCB2ID0gKGNhZGRyX3Qpdl9hcmcsIG5ldG1hc2sg PSAoY2FkZHJfdCluX2FyZzsNCi0JcmVnaXN0ZXIgc3RydWN0IHJhZGl4X25v ZGUgKnQsICp4ID0gMCwgKnR0Ow0KKwlyZWdpc3RlciBzdHJ1Y3QgcmFkaXhf bm9kZSAqdCwgKnggPSAwLCAqeHggPSAwLCAqdHQ7DQogCXN0cnVjdCByYWRp eF9ub2RlICpzYXZlZF90dCwgKnRvcCA9IGhlYWQtPnJuaF90cmVldG9wOw0K IAlzaG9ydCBiID0gMCwgYl9sZWFmID0gMDsNCiAJaW50IGtleWR1cGxpY2F0 ZWQ7DQpAQCAtNzIzLDEyICs3MjMsMTkgQEANCiAJCXggPSB0LT5ybl9yaWdo dDsNCiAJLyogUHJvbW90ZSBnZW5lcmFsIHJvdXRlcyBmcm9tIGJlbG93ICov DQogCWlmICh4LT5ybl9iaXQgPCAwKSB7DQotCSAgICBmb3IgKG1wID0gJnQt PnJuX21rbGlzdDsgeDsgeCA9IHgtPnJuX2R1cGVka2V5KQ0KKwkgICAgZm9y IChtcCA9ICZ0LT5ybl9ta2xpc3Q7IHg7IHh4ID0geCwgeCA9IHgtPnJuX2R1 cGVka2V5KSB7DQorCQlpZiAoeHggJiYgeHgtPnJuX21rbGlzdCAmJiB4eC0+ cm5fbWFzayA9PSB4LT5ybl9tYXNrICYmDQorCQkJCXgtPnJuX21rbGlzdCA9 PSAwKSB7DQorCQkJLyogbXVsdGlwYXRoIHJvdXRlLCBidW1wIHJlZmNvdW50 IG9uIGZpcnN0IG1rbGlzdCAqLw0KKwkJCXgtPnJuX21rbGlzdCA9IHh4LT5y bl9ta2xpc3Q7DQorCQkJeC0+cm5fbWtsaXN0LT5ybV9yZWZzKys7DQorCQl9 DQogCQlpZiAoeC0+cm5fbWFzayAmJiAoeC0+cm5fYml0ID49IGJfbGVhZikg JiYgeC0+cm5fbWtsaXN0ID09IDApIHsNCiAJCQkqbXAgPSBtID0gcm5fbmV3 X3JhZGl4X21hc2soeCwgMCk7DQogCQkJaWYgKG0pDQogCQkJCW1wID0gJm0t PnJtX21rbGlzdDsNCiAJCX0NCisJICAgIH0NCiAJfSBlbHNlIGlmICh4LT5y bl9ta2xpc3QpIHsNCiAJCS8qDQogCQkgKiBTa2lwIG92ZXIgbWFza3Mgd2hv c2UgaW5kZXggaXMgPiB0aGF0IG9mIG5ldyBub2RlDQpAQCAtNzYwLDExICs3 NjcsMzAgQEANCiAJCQlicmVhazsNCiAJCWlmIChtLT5ybV9mbGFncyAmIFJO Rl9OT1JNQUwpIHsNCiAJCQltbWFzayA9IG0tPnJtX2xlYWYtPnJuX21hc2s7 DQotCQkJaWYgKHR0LT5ybl9mbGFncyAmIFJORl9OT1JNQUwpIHsNCi0jaWYg IWRlZmluZWQoUkFESVhfTVBBVEgpDQotCQkJICAgIGxvZyhMT0dfRVJSLA0K LQkJCSAgICAgICAgIk5vbi11bmlxdWUgbm9ybWFsIHJvdXRlLCBtYXNrIG5v dCBlbnRlcmVkXG4iKTsNCisgICAgICAgICAgICAgICAgICAgICAgICBpZiAo a2V5ZHVwbGljYXRlZCkgew0KKwkJCQlpZiAobS0+cm1fbGVhZi0+cm5fcGFy ZW50ID09IHR0KQ0KKwkJCQkJLyogbmV3IHJvdXRlIGlzIGJldHR0ZXIgKi8N CisJCQkJCW0tPnJtX2xlYWYgPSB0dDsNCisjaWZkZWYgRElBR05PU1RJQw0K KwkJCQllbHNlIHsNCisJCQkJCWZvciAodCA9IG0tPnJtX2xlYWY7IHQ7DQor CQkJCQkJdCA9IHQtPnJuX2R1cGVka2V5KSB7DQorCQkJCQkJCWJyZWFrOw0K KwkJCQkJfQ0KKwkJCQkJaWYgKHQgPT0gTlVMTCkgew0KKwkJCQkJCWxvZyhM T0dfRVJSLCAiTm9uLXVuaXF1ZSAiDQorCQkJCQkJCSJub3JtYWwgcm91dGUg b24gZHVwZWRrZXksICINCisJCQkJCQkJIm1hc2sgbm90IGVudGVyZWRcbiIp Ow0KKwkJCQkJCXJldHVybiB0dDsNCisJCQkJCX0NCisJCQkJfQ0KICNlbmRp Zg0KKwkJCQltLT5ybV9yZWZzKys7DQorCQkJCXR0LT5ybl9ta2xpc3QgPSBt Ow0KKwkJCQlyZXR1cm4gdHQ7DQorCQkJIH0gZWxzZSBpZiAodHQtPnJuX2Zs YWdzICYgUk5GX05PUk1BTCkgew0KKwkJCQlsb2coTE9HX0VSUiwgIk5vbi11 bmlxdWUgbm9ybWFsIHJvdXRlLCINCisJCQkJCSIgbWFzayBub3QgZW50ZXJl ZFxuIik7DQogCQkJCXJldHVybiB0dDsNCiAJCQl9DQogCQl9IGVsc2UNCkBA IC03ODMsOSArODA5LDEwIEBADQogfQ0KIA0KIHN0cnVjdCByYWRpeF9ub2Rl ICoNCi1ybl9kZWxldGUodl9hcmcsIG5ldG1hc2tfYXJnLCBoZWFkKQ0KK3Ju X2RlbGV0ZSh2X2FyZywgbmV0bWFza19hcmcsIGhlYWQsIHJuKQ0KIAl2b2lk ICp2X2FyZywgKm5ldG1hc2tfYXJnOw0KIAlzdHJ1Y3QgcmFkaXhfbm9kZV9o ZWFkICpoZWFkOw0KKwlzdHJ1Y3QgcmFkaXhfbm9kZSAqcm47DQogew0KIAly ZWdpc3RlciBzdHJ1Y3QgcmFkaXhfbm9kZSAqdCwgKnAsICp4LCAqdHQ7DQog CXN0cnVjdCByYWRpeF9tYXNrICptLCAqc2F2ZWRfbSwgKiptcDsNCkBAIC04 MTUsMTMgKzg0MiwzOCBAQA0KIAkJCWlmICgodHQgPSB0dC0+cm5fZHVwZWRr ZXkpID09IDApDQogCQkJCXJldHVybiAoMCk7DQogCX0NCisjaWZkZWYgUkFE SVhfTVBBVEgNCisJaWYgKHJuKSB7DQorCQl3aGlsZSAodHQgIT0gcm4pDQor CQkJaWYgKCh0dCA9IHR0LT5ybl9kdXBlZGtleSkgPT0gMCkNCisJCQkJcmV0 dXJuICgwKTsNCisJfQ0KKyNlbmRpZg0KKwkNCiAJaWYgKHR0LT5ybl9tYXNr ID09IDAgfHwgKHNhdmVkX20gPSBtID0gdHQtPnJuX21rbGlzdCkgPT0gMCkN CiAJCWdvdG8gb24xOw0KIAlpZiAodHQtPnJuX2ZsYWdzICYgUk5GX05PUk1B TCkgew0KLQkJaWYgKG0tPnJtX2xlYWYgIT0gdHQgfHwgbS0+cm1fcmVmcyA+ IDApIHsNCisJCWlmIChtLT5ybV9sZWFmICE9IHR0ICYmIG0tPnJtX3JlZnMg PT0gMCkgew0KIAkJCWxvZyhMT0dfRVJSLCAicm5fZGVsZXRlOiBpbmNvbnNp c3RlbnQgYW5ub3RhdGlvblxuIik7DQogCQkJcmV0dXJuIDA7ICAvKiBkYW5n bGluZyByZWYgY291bGQgY2F1c2UgZGlzYXN0ZXIgKi8NCiAJCX0NCisJCWlm IChtLT5ybV9sZWFmICE9IHR0KSB7DQorCQkJaWYgKC0tbS0+cm1fcmVmcyA+ PSAwKQ0KKwkJCQlnb3RvIG9uMTsNCisgICAgICAgICAgICAgICAgfQ0KKwkJ LyogdHQgaXMgY3VycmVudGx5IHRoZSBoZWFkIG9mIHRoZSBwb3NzaWJsZSBt dWx0aXBhdGggY2hhaW4gKi8NCisJCWlmIChtLT5ybV9yZWZzID4gMCkgew0K KwkJCWlmICh0dC0+cm5fZHVwZWRrZXkgPT0gTlVMTCB8fA0KKwkJCSAgICB0 dC0+cm5fZHVwZWRrZXktPnJuX21rbGlzdCAhPSBtKSB7DQorCQkJCWxvZyhM T0dfRVJSLCAicm5fZGVsZXRlOiBpbmNvbnNpc3RlbnQgIg0KKwkJCQkgICAg ImR1cGVka2V5IGxpc3RcbiIpOw0KKwkJCQlyZXR1cm4gKDApOw0KKwkJCX0N CisJCQltLT5ybV9sZWFmID0gdHQtPnJuX2R1cGVka2V5Ow0KKwkJCS0tbS0+ cm1fcmVmczsNCisJCQlnb3RvIG9uMTsNCisJCX0NCisJCS8qIGVsc2UgdHQg aXMgbGFzdCBhbmQgb25seSByb3V0ZSAqLw0KIAl9IGVsc2Ugew0KIAkJaWYg KG0tPnJtX21hc2sgIT0gdHQtPnJuX21hc2spIHsNCiAJCQlsb2coTE9HX0VS UiwgInJuX2RlbGV0ZTogaW5jb25zaXN0ZW50IGFubm90YXRpb25cbiIpOw0K QEAgLTg2OSwyMSArOTIxLDE3IEBADQogCQkgKi8NCiAJCWlmICh0dCA9PSBz YXZlZF90dCkgew0KIAkJCS8qIHJlbW92ZSBmcm9tIGhlYWQgb2YgY2hhaW4g Ki8NCi0JCQl4ID0gZHVwZWRrZXk7IHgtPnJuX3BhcmVudCA9IHQ7DQorCQkJ eCA9IGR1cGVka2V5OyANCisJCQl4LT5ybl9wYXJlbnQgPSB0Ow0KIAkJCWlm ICh0LT5ybl9sZWZ0ID09IHR0KQ0KIAkJCQl0LT5ybl9sZWZ0ID0geDsNCiAJ CQllbHNlDQogCQkJCXQtPnJuX3JpZ2h0ID0geDsNCiAJCX0gZWxzZSB7DQot CQkJLyogZmluZCBub2RlIGluIGZyb250IG9mIHR0IG9uIHRoZSBjaGFpbiAq Lw0KLQkJCWZvciAoeCA9IHAgPSBzYXZlZF90dDsgcCAmJiBwLT5ybl9kdXBl ZGtleSAhPSB0dDspDQotCQkJCXAgPSBwLT5ybl9kdXBlZGtleTsNCi0JCQlp ZiAocCkgew0KLQkJCQlwLT5ybl9kdXBlZGtleSA9IHR0LT5ybl9kdXBlZGtl eTsNCi0JCQkJaWYgKHR0LT5ybl9kdXBlZGtleSkJCS8qIHBhcmVudCAqLw0K LQkJCQkJdHQtPnJuX2R1cGVka2V5LT5ybl9wYXJlbnQgPSBwOw0KLQkJCQkJ CQkJLyogcGFyZW50ICovDQotCQkJfSBlbHNlIGxvZyhMT0dfRVJSLCAicm5f ZGVsZXRlOiBjb3VsZG4ndCBmaW5kIHVzXG4iKTsNCisJCQl4ID0gc2F2ZWRf dHQ7DQorCQkJdC0+cm5fZHVwZWRrZXkgPSB0dC0+cm5fZHVwZWRrZXk7DQor CQkJaWYgKHR0LT5ybl9kdXBlZGtleSkNCisJCQkJdHQtPnJuX2R1cGVka2V5 LT5ybl9wYXJlbnQgPSB0Ow0KIAkJfQ0KIAkJdCA9IHR0ICsgMTsNCiAJCWlm ICAodC0+cm5fZmxhZ3MgJiBSTkZfQUNUSVZFKSB7DQpAQCAtOTMxLDE0ICs5 NzksMjEgQEANCiAJCQkJaWYgKG0gPT0geC0+cm5fbWtsaXN0KSB7DQogCQkJ CQlzdHJ1Y3QgcmFkaXhfbWFzayAqbW0gPSBtLT5ybV9ta2xpc3Q7DQogCQkJ CQl4LT5ybl9ta2xpc3QgPSAwOw0KLQkJCQkJaWYgKC0tKG0tPnJtX3JlZnMp IDwgMCkNCisJCQkJCWlmICgtLShtLT5ybV9yZWZzKSA8IDApIHsNCiAJCQkJ CQlNS0ZyZWUobSk7DQorCQkJCQl9IGVsc2UgaWYgKG0tPnJtX2ZsYWdzICYg Uk5GX05PUk1BTCkgew0KKwkJCQkJCS8qDQorCQkJCQkJICogZG9uJ3QgcHJv Z3Jlc3MgYmVjYXVzZSB0aGlzDQorCQkJCQkJICogYSBtdWx0aXBhdGggcm91 dGUuIE5leHQNCisJCQkJCQkgKiByb3V0ZSB3aWxsIHVzZSB0aGUgc2FtZSBt Lg0KKwkJCQkJCSAqLw0KKwkJCQkJCW1tID0gbTsNCisJCQkJCX0NCiAJCQkJ CW0gPSBtbTsNCiAJCQkJfQ0KIAkJCWlmIChtKQ0KIAkJCQlsb2coTE9HX0VS UiwNCi0JCQkJICAgICJybl9kZWxldGU6IE9ycGhhbmVkIE1hc2sgJXAgYXQg JXBcbiIsDQotCQkJCSAgICBtLCB4KTsNCisJCQkJICAgICJybl9kZWxldGU6 IE9ycGhhbmVkIE1hc2sgJXAgYXQgJXBcbiIsIG0sIHgpOw0KIAkJfQ0KIAl9 DQogCS8qDQpAQCAtOTkwLDExICsxMDQ1LDggQEANCiAJICogcm5fc2VhcmNo X20gaXMgc29ydC1vZi1vcGVuLWNvZGVkIGhlcmUuIFdlIGNhbm5vdCB1c2Ug dGhlDQogCSAqIGZ1bmN0aW9uIGJlY2F1c2Ugd2UgbmVlZCB0byBrZWVwIHRy YWNrIG9mIHRoZSBsYXN0IG5vZGUgc2Vlbi4NCiAJICovDQotCS8qIHByaW50 ZigiYWJvdXQgdG8gc2VhcmNoXG4iKTsgKi8NCiAJZm9yIChybiA9IGgtPnJu aF90cmVldG9wOyBybi0+cm5fYml0ID49IDA7ICkgew0KIAkJbGFzdCA9IHJu Ow0KLQkJLyogcHJpbnRmKCJybl9iaXQgJWQsIHJuX2JtYXNrICV4LCB4bVty bl9vZmZzZXRdICV4XG4iLA0KLQkJICAgICAgIHJuLT5ybl9iaXQsIHJuLT5y bl9ibWFzaywgeG1bcm4tPnJuX29mZnNldF0pOyAqLw0KIAkJaWYgKCEocm4t PnJuX2JtYXNrICYgeG1bcm4tPnJuX29mZnNldF0pKSB7DQogCQkJYnJlYWs7 DQogCQl9DQpAQCAtMTAwNCw3ICsxMDU2LDYgQEANCiAJCQlybiA9IHJuLT5y bl9sZWZ0Ow0KIAkJfQ0KIAl9DQotCS8qIHByaW50ZigiZG9uZSBzZWFyY2hp bmdcbiIpOyAqLw0KIA0KIAkvKg0KIAkgKiBUd28gY2FzZXM6IGVpdGhlciB3 ZSBzdGVwcGVkIG9mZiB0aGUgZW5kIG9mIG91ciBtYXNrLA0KQEAgLTEwMTUs OCArMTA2Niw2IEBADQogCXJuID0gbGFzdDsNCiAJbGFzdGIgPSBybi0+cm5f Yml0Ow0KIA0KLQkvKiBwcmludGYoInJuICVwLCBsYXN0YiAlZFxuIiwgcm4s IGxhc3RiKTsqLw0KLQ0KIAkvKg0KIAkgKiBUaGlzIGdldHMgY29tcGxpY2F0 ZWQgYmVjYXVzZSB3ZSBtYXkgZGVsZXRlIHRoZSBub2RlDQogCSAqIHdoaWxl IGFwcGx5aW5nIHRoZSBmdW5jdGlvbiBmIHRvIGl0LCBzbyB3ZSBuZWVkIHRv IGNhbGN1bGF0ZQ0KQEAgLTEwMjYsNyArMTA3NSw2IEBADQogCQlybiA9IHJu LT5ybl9sZWZ0Ow0KIA0KIAl3aGlsZSAoIXN0b3BwaW5nKSB7DQotCQkvKiBw cmludGYoIm5vZGUgJXAgKCVkKVxuIiwgcm4sIHJuLT5ybl9iaXQpOyAqLw0K IAkJYmFzZSA9IHJuOw0KIAkJLyogSWYgYXQgcmlnaHQgY2hpbGQgZ28gYmFj ayB1cCwgb3RoZXJ3aXNlLCBnbyByaWdodCAqLw0KIAkJd2hpbGUgKHJuLT5y bl9wYXJlbnQtPnJuX3JpZ2h0ID09IHJuDQpAQCAtMTAzNiw3ICsxMDg0LDYg QEANCiAJCQkvKiBpZiB3ZW50IHVwIGJleW9uZCBsYXN0LCBzdG9wICovDQog CQkJaWYgKHJuLT5ybl9iaXQgPD0gbGFzdGIpIHsNCiAJCQkJc3RvcHBpbmcg PSAxOw0KLQkJCQkvKiBwcmludGYoInVwIHRvbyBmYXJcbiIpOyAqLw0KIAkJ CQkvKg0KIAkJCQkgKiBYWFggd2Ugc2hvdWxkIGp1bXAgdG8gdGhlICdQcm9j ZXNzIGxlYXZlcycNCiAJCQkJICogcGFydCwgYmVjYXVzZSB0aGUgdmFsdWVz IG9mICdybicgYW5kICduZXh0Jw0KQEAgLTEwNjIsNyArMTEwOSw2IEBADQog CQkvKiBQcm9jZXNzIGxlYXZlcyAqLw0KIAkJd2hpbGUgKChybiA9IGJhc2Up ICE9IDApIHsNCiAJCQliYXNlID0gcm4tPnJuX2R1cGVka2V5Ow0KLQkJCS8q IHByaW50ZigibGVhZiAlcFxuIiwgcm4pOyAqLw0KIAkJCWlmICghKHJuLT5y bl9mbGFncyAmIFJORl9ST09UKQ0KIAkJCSAgICAmJiAoZXJyb3IgPSAoKmYp KHJuLCB3KSkpDQogCQkJCXJldHVybiAoZXJyb3IpOw0KQEAgLTEwNzAsNyAr MTExNiw2IEBADQogCQlybiA9IG5leHQ7DQogDQogCQlpZiAocm4tPnJuX2Zs YWdzICYgUk5GX1JPT1QpIHsNCi0JCQkvKiBwcmludGYoInJvb3QsIHN0b3Bw aW5nIik7ICovDQogCQkJc3RvcHBpbmcgPSAxOw0KIAkJfQ0KIA0KZGlmZiAt ciAtdSAvdXNyX2RpZmYvc3JjL3N5cy9uZXQvcmFkaXguaCAvdXNyL3NyYy9z eXMvbmV0L3JhZGl4LmgNCi0tLSAvdXNyX2RpZmYvc3JjL3N5cy9uZXQvcmFk aXguaAkyMDEwLTAzLTIzIDA5OjU4OjU5LjAwMDAwMDAwMCArMDAwMA0KKysr IC91c3Ivc3JjL3N5cy9uZXQvcmFkaXguaAkyMDEwLTA5LTA2IDExOjIyOjM5 LjAwMDAwMDAwMCArMDAwMA0KQEAgLTExNCw3ICsxMTQsNyBAQA0KIAkJKHZv aWQgKnYsIHZvaWQgKm1hc2ssDQogCQkgICAgIHN0cnVjdCByYWRpeF9ub2Rl X2hlYWQgKmhlYWQsIHN0cnVjdCByYWRpeF9ub2RlIG5vZGVzW10pOw0KIAlz dHJ1Y3QJcmFkaXhfbm9kZSAqKCpybmhfZGVsYWRkcikJLyogcmVtb3ZlIGJh c2VkIG9uIHNvY2thZGRyICovDQotCQkodm9pZCAqdiwgdm9pZCAqbWFzaywg c3RydWN0IHJhZGl4X25vZGVfaGVhZCAqaGVhZCk7DQorCQkodm9pZCAqdiwg dm9pZCAqbWFzaywgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAqaGVhZCwgc3Ry dWN0IHJhZGl4X25vZGUgKnJuKTsNCiAJc3RydWN0CXJhZGl4X25vZGUgKigq cm5oX2RlbHBrdCkJLyogcmVtb3ZlIGJhc2VkIG9uIHBhY2tldCBoZHIgKi8N CiAJCSh2b2lkICp2LCB2b2lkICptYXNrLCBzdHJ1Y3QgcmFkaXhfbm9kZV9o ZWFkICpoZWFkKTsNCiAJc3RydWN0CXJhZGl4X25vZGUgKigqcm5oX21hdGNo YWRkcikJLyogbG9jYXRlIGJhc2VkIG9uIHNvY2thZGRyICovDQpAQCAtMTY4 LDcgKzE2OCw3IEBADQogCSAqcm5fYWRkbWFzayh2b2lkICosIGludCwgaW50 KSwNCiAJICpybl9hZGRyb3V0ZSAodm9pZCAqLCB2b2lkICosIHN0cnVjdCBy YWRpeF9ub2RlX2hlYWQgKiwNCiAJCQlzdHJ1Y3QgcmFkaXhfbm9kZSBbMl0p LA0KLQkgKnJuX2RlbGV0ZSh2b2lkICosIHZvaWQgKiwgc3RydWN0IHJhZGl4 X25vZGVfaGVhZCAqKSwNCisJICpybl9kZWxldGUodm9pZCAqLCB2b2lkICos IHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKiwgc3RydWN0IHJhZGl4X25vZGUg KiksDQogCSAqcm5fbG9va3VwICh2b2lkICp2X2FyZywgdm9pZCAqbV9hcmcs DQogCQkgICAgICAgIHN0cnVjdCByYWRpeF9ub2RlX2hlYWQgKmhlYWQpLA0K IAkgKnJuX21hdGNoKHZvaWQgKiwgc3RydWN0IHJhZGl4X25vZGVfaGVhZCAq KTsNCmRpZmYgLXIgLXUgL3Vzcl9kaWZmL3NyYy9zeXMvbmV0L3JhZGl4X21w YXRoLmMgL3Vzci9zcmMvc3lzL25ldC9yYWRpeF9tcGF0aC5jDQotLS0gL3Vz cl9kaWZmL3NyYy9zeXMvbmV0L3JhZGl4X21wYXRoLmMJMjAxMC0wNC0wMiAw NTowMjo1MC4wMDAwMDAwMDAgKzAwMDANCisrKyAvdXNyL3NyYy9zeXMvbmV0 L3JhZGl4X21wYXRoLmMJMjAxMC0wOS0wNiAxMToyMjozOS4wMDAwMDAwMDAg KzAwMDANCkBAIC0xMjUsMzMgKzEyNSw2IEBADQogCXJldHVybiAoc3RydWN0 IHJ0ZW50cnkgKilybjsNCiB9DQogDQotLyogDQotICogZ28gdGhyb3VnaCB0 aGUgY2hhaW4gYW5kIHVubGluayAicnQiIGZyb20gdGhlIGxpc3QNCi0gKiB0 aGUgY2FsbGVyIHdpbGwgZnJlZSAicnQiDQotICovDQotaW50DQotcnRfbXBh dGhfZGVsZHVwKHN0cnVjdCBydGVudHJ5ICpoZWFkcnQsIHN0cnVjdCBydGVu dHJ5ICpydCkNCi17DQotICAgICAgICBzdHJ1Y3QgcmFkaXhfbm9kZSAqdCwg KnR0Ow0KLQ0KLSAgICAgICAgaWYgKCFoZWFkcnQgfHwgIXJ0KQ0KLSAgICAg ICAgICAgIHJldHVybiAoMCk7DQotICAgICAgICB0ID0gKHN0cnVjdCByYWRp eF9ub2RlICopaGVhZHJ0Ow0KLSAgICAgICAgdHQgPSBybl9tcGF0aF9uZXh0 KHQpOw0KLSAgICAgICAgd2hpbGUgKHR0KSB7DQotICAgICAgICAgICAgaWYg KHR0ID09IChzdHJ1Y3QgcmFkaXhfbm9kZSAqKXJ0KSB7DQotICAgICAgICAg ICAgICAgIHQtPnJuX2R1cGVka2V5ID0gdHQtPnJuX2R1cGVka2V5Ow0KLSAg ICAgICAgICAgICAgICB0dC0+cm5fZHVwZWRrZXkgPSBOVUxMOw0KLSAgICAJ ICAgICAgICB0dC0+cm5fZmxhZ3MgJj0gflJORl9BQ1RJVkU7DQotCSAgICAg ICAgdHRbMV0ucm5fZmxhZ3MgJj0gflJORl9BQ1RJVkU7DQotICAgICAgICAg ICAgICAgIHJldHVybiAoMSk7DQotICAgICAgICAgICAgfQ0KLSAgICAgICAg ICAgIHQgPSB0dDsNCi0gICAgICAgICAgICB0dCA9IHJuX21wYXRoX25leHQo KHN0cnVjdCByYWRpeF9ub2RlICopdCk7DQotICAgICAgICB9DQotICAgICAg ICByZXR1cm4gKDApOw0KLX0NCi0NCiAvKg0KICAqIGNoZWNrIGlmIHdlIGhh dmUgdGhlIHNhbWUga2V5L21hc2svZ2F0ZXdheSBvbiB0aGUgdGFibGUgYWxy ZWFkeS4NCiAgKi8NCkBAIC0yNjIsOSArMjM1LDEwIEBADQogcnRhbGxvY19t cGF0aF9maWIoc3RydWN0IHJvdXRlICpybywgdWludDMyX3QgaGFzaCwgdV9p bnQgZmlibnVtKQ0KIHsNCiAJc3RydWN0IHJhZGl4X25vZGUgKnJuMCwgKnJu Ow0KLQl1X2ludDMyX3QgbjsNCisJdV9pbnQzMl90IG4gPSAwOw0KIAlzdHJ1 Y3QgcnRlbnRyeSAqcnQ7DQogCWludDY0X3Qgd2VpZ2h0Ow0KKwlpbnQ2NF90 IGxvd2VzdF93ZWlnaHQ7DQogDQogCS8qDQogCSAqIFhYWCB3ZSBkb24ndCBh dHRlbXB0IHRvIGxvb2t1cCBjYWNoZWQgcm91dGUgYWdhaW47IHdoYXQgc2hv dWxkDQpAQCAtMjcyLDcgKzI0Niw3IEBADQogCSAqLw0KIAlpZiAocm8tPnJv X3J0ICYmIHJvLT5yb19ydC0+cnRfaWZwICYmIChyby0+cm9fcnQtPnJ0X2Zs YWdzICYgUlRGX1VQKQ0KIAkgICAgJiYgUlRfTElOS19JU19VUChyby0+cm9f cnQtPnJ0X2lmcCkpDQotCQlyZXR1cm47CQkJCSANCisJCXJldHVybjsNCiAJ cm8tPnJvX3J0ID0gcnRhbGxvYzFfZmliKCZyby0+cm9fZHN0LCAxLCAwLCBm aWJudW0pOw0KIA0KIAkvKiBpZiB0aGUgcm91dGUgZG9lcyBub3QgZXhpc3Qg b3IgaXQgaXMgbm90IG11bHRpcGF0aCwgZG9uJ3QgY2FyZSAqLw0KQEAgLTI4 NSwyMCArMjU5LDM0IEBADQogDQogCS8qIGJleW9uZCBoZXJlLCB3ZSB1c2Ug cm4gYXMgdGhlIG1hc3RlciBjb3B5ICovDQogCXJuMCA9IHJuID0gKHN0cnVj dCByYWRpeF9ub2RlICopcm8tPnJvX3J0Ow0KLQluID0gcm5fbXBhdGhfY291 bnQocm4wKTsNCi0NCisJDQorCS8qIGZpbmQgbG93ZXN0IHdlaWdodCByb3V0 ZSAqLw0KKwlmb3IgKCBydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKXJuLCB3ZWln aHQgPSBydC0+cnRfcm14LnJteF93ZWlnaHQ7IHJuICE9IE5VTEw7IHJuID0g cm5fbXBhdGhfbmV4dCggcm4pKSB7DQorCQkvKiBYWFggY2hlY2sgaWYgcm91 dGUgaXMgdXA/ICovDQorCQlydCA9IChzdHJ1Y3QgcnRlbnRyeSAqKXJuOw0K KwkJaWYocnQtPnJ0X2ZsYWdzICYgUlRGX1VQKSB7IA0KKwkJCWlmICh3ZWln aHQgPiBydC0+cnRfcm14LnJteF93ZWlnaHQpIHsNCisJCQkJd2VpZ2h0ID0g cnQtPnJ0X3JteC5ybXhfd2VpZ2h0Ow0KKwkJCQluID0gMTsNCisJCQl9IGVs c2UgaWYgKHdlaWdodCA9PSBydC0+cnRfcm14LnJteF93ZWlnaHQpDQorCQkJ CW4rKzsNCisJCX0NCisJfQ0KKwlsb3dlc3Rfd2VpZ2h0ID0gd2VpZ2h0Ow0K KwkNCisJLyogc2VsZWN0IG5vdyBvbmUgb2YgdGhlIGxvd2VzdCB3ZWlnaHQg cm91dGVzICovDQogCS8qIGd3IHNlbGVjdGlvbiBieSBNb2R1bG8tTiBIYXNo IChSRkMyOTkxKSBYWFggbmVlZCBpbXByb3ZlbWVudD8gKi8NCiAJaGFzaCAr PSBoYXNoaml0dGVyOw0KIAloYXNoICU9IG47DQotCWZvciAod2VpZ2h0ID0g YWJzKChpbnQzMl90KWhhc2gpLCBydCA9IHJvLT5yb19ydDsNCi0JICAgICB3 ZWlnaHQgPj0gcnQtPnJ0X3JteC5ybXhfd2VpZ2h0ICYmIHJuOyANCi0JICAg ICB3ZWlnaHQgLT0gcnQtPnJ0X3JteC5ybXhfd2VpZ2h0KSB7DQotCQkNCi0J CS8qIHN0YXkgd2l0aGluIHRoZSBtdWx0aXBhdGggcm91dGVzICovDQotCQlp ZiAocm4tPnJuX2R1cGVka2V5ICYmIHJuLT5ybl9tYXNrICE9IHJuLT5ybl9k dXBlZGtleS0+cm5fbWFzaykNCi0JCQlicmVhazsNCi0JCXJuID0gcm4tPnJu X2R1cGVka2V5Ow0KKwlmb3IgKCBybiA9IHJuMCwgbiA9IDA7IHJuICE9IE5V TEw7IHJuID0gcm5fbXBhdGhfbmV4dCggcm4pKSB7DQogCQlydCA9IChzdHJ1 Y3QgcnRlbnRyeSAqKXJuOw0KKwkJaWYocnQtPnJ0X2ZsYWdzICYgUlRGX1VQ KSB7IA0KKwkJCWlmICggcnQtPnJ0X3JteC5ybXhfd2VpZ2h0ID09IGxvd2Vz dF93ZWlnaHQpIHsNCisJCQkJaWYgKG4gPT0gaGFzaCkNCisJCQkJCWJyZWFr Ow0KKwkJCQluKys7DQorCQkJfQ0KKwkJfQ0KIAl9DQogCS8qIFhYWCB0cnkg ZmlsbGluZyBydF9nd3JvdXRlIGFuZCBhdm9pZCB1bnJlYWNoYWJsZSBndyAg Ki8NCiANCmRpZmYgLXIgLXUgL3Vzcl9kaWZmL3NyYy9zeXMvbmV0L3JvdXRl LmMgL3Vzci9zcmMvc3lzL25ldC9yb3V0ZS5jDQotLS0gL3Vzcl9kaWZmL3Ny Yy9zeXMvbmV0L3JvdXRlLmMJMjAxMC0wNi0xOCAwMzozMTozMy4wMDAwMDAw MDAgKzAwMDANCisrKyAvdXNyL3NyYy9zeXMvbmV0L3JvdXRlLmMJMjAxMC0w OS0wNiAxMToyMjozOS4wMDAwMDAwMDAgKzAwMDANCkBAIC04NzUsNyArODc1 LDcgQEANCiAJICogUmVtb3ZlIHRoZSBpdGVtIGZyb20gdGhlIHRyZWU7IGl0 IHNob3VsZCBiZSB0aGVyZSwNCiAJICogYnV0IHdoZW4gY2FsbGVycyBpbnZv a2UgdXMgYmxpbmRseSBpdCBtYXkgbm90IChzaWdoKS4NCiAJICovDQotCXJu ID0gcm5oLT5ybmhfZGVsYWRkcihydF9rZXkocnQpLCBydF9tYXNrKHJ0KSwg cm5oKTsNCisJcm4gPSBybmgtPnJuaF9kZWxhZGRyKHJ0X2tleShydCksIHJ0 X21hc2socnQpLCBybmgsIE5VTEwpOw0KIAlpZiAocm4gPT0gTlVMTCkgew0K IAkJZXJyb3IgPSBFU1JDSDsNCiAJCWdvdG8gYmFkOw0KQEAgLTkxMywxMTIg KzkxMyw2IEBADQogCXJldHVybiAoZXJyb3IpOw0KIH0NCiANCi0jaWZkZWYg UkFESVhfTVBBVEgNCi1zdGF0aWMgaW50DQotcm5fbXBhdGhfdXBkYXRlKGlu dCByZXEsIHN0cnVjdCBydF9hZGRyaW5mbyAqaW5mbywNCi0gICAgc3RydWN0 IHJhZGl4X25vZGVfaGVhZCAqcm5oLCBzdHJ1Y3QgcnRlbnRyeSAqKnJldF9u cnQpDQotew0KLQkvKg0KLQkgKiBpZiB3ZSBnb3QgbXVsdGlwYXRoIHJvdXRl cywgd2UgcmVxdWlyZSB1c2VycyB0byBzcGVjaWZ5DQotCSAqIGEgbWF0Y2hp bmcgUlRBWF9HQVRFV0FZLg0KLQkgKi8NCi0Jc3RydWN0IHJ0ZW50cnkgKnJ0 LCAqcnRvID0gTlVMTDsNCi0JcmVnaXN0ZXIgc3RydWN0IHJhZGl4X25vZGUg KnJuOw0KLQlpbnQgZXJyb3IgPSAwOw0KLQ0KLQlybiA9IHJuaC0+cm5oX21h dGNoYWRkcihkc3QsIHJuaCk7DQotCWlmIChybiA9PSBOVUxMKQ0KLQkJcmV0 dXJuIChFU1JDSCk7DQotCXJ0byA9IHJ0ID0gUk5UT1JUKHJuKTsNCi0JcnQg PSBydF9tcGF0aF9tYXRjaGdhdGUocnQsIGdhdGV3YXkpOw0KLQlpZiAocnQg PT0gTlVMTCkNCi0JCXJldHVybiAoRVNSQ0gpOw0KLQkvKg0KLQkgKiB0aGlz IGlzIHRoZSBmaXJzdCBlbnRyeSBpbiB0aGUgY2hhaW4NCi0JICovDQotCWlm IChydG8gPT0gcnQpIHsNCi0JCXJuID0gcm5fbXBhdGhfbmV4dCgoc3RydWN0 IHJhZGl4X25vZGUgKilydCk7DQotCQkvKg0KLQkJICogdGhlcmUgaXMgYW5v dGhlciBlbnRyeSwgbm93IGl0J3MgYWN0aXZlDQotCQkgKi8NCi0JCWlmIChy bikgew0KLQkJCXJ0byA9IFJOVE9SVChybik7DQotCQkJUlRfTE9DSyhydG8p Ow0KLQkJCXJ0by0+cnRfZmxhZ3MgfD0gUlRGX1VQOw0KLQkJCVJUX1VOTE9D SyhydG8pOw0KLQkJfSBlbHNlIGlmIChydC0+cnRfZmxhZ3MgJiBSVEZfR0FU RVdBWSkgew0KLQkJCS8qDQotCQkJICogRm9yIGdhdGV3YXkgcm91dGVzLCB3 ZSBuZWVkIHRvIA0KLQkJCSAqIG1ha2Ugc3VyZSB0aGF0IHdlIHdlIGFyZSBk ZWxldGluZw0KLQkJCSAqIHRoZSBjb3JyZWN0IGdhdGV3YXkuIA0KLQkJCSAq IHJ0X21wYXRoX21hdGNoZ2F0ZSgpIGRvZXMgbm90IA0KLQkJCSAqIGNoZWNr IHRoZSBjYXNlIHdoZW4gdGhlcmUgaXMgb25seQ0KLQkJCSAqIG9uZSByb3V0 ZSBpbiB0aGUgY2hhaW4uICANCi0JCQkgKi8NCi0JCQlpZiAoZ2F0ZXdheSAm Jg0KLQkJCSAgICAocnQtPnJ0X2dhdGV3YXktPnNhX2xlbiAhPSBnYXRld2F5 LT5zYV9sZW4gfHwNCi0JCQkJbWVtY21wKHJ0LT5ydF9nYXRld2F5LCBnYXRl d2F5LCBnYXRld2F5LT5zYV9sZW4pKSkNCi0JCQkJZXJyb3IgPSBFU1JDSDsN Ci0JCQllbHNlIHsNCi0JCQkJLyoNCi0JCQkJICogcmVtb3ZlIGZyb20gdHJl ZSBiZWZvcmUgcmV0dXJuaW5nIGl0DQotCQkJCSAqIHRvIHRoZSBjYWxsZXIN Ci0JCQkJICovDQotCQkJCXJuID0gcm5oLT5ybmhfZGVsYWRkcihkc3QsIG5l dG1hc2ssIHJuaCk7DQotCQkJCUtBU1NFUlQocnQgPT0gUk5UT1JUKHJuKSwg KCJyYWRpeCBub2RlIGRpc2FwcGVhcmVkIikpOw0KLQkJCQlnb3RvIGd3ZGVs ZXRlOw0KLQkJCX0NCi0JCQkNCi0JCX0NCi0JCS8qDQotCQkgKiB1c2UgdGhl IG5vcm1hbCBkZWxldGUgY29kZSB0byByZW1vdmUNCi0JCSAqIHRoZSBmaXJz dCBlbnRyeQ0KLQkJICovDQotCQlpZiAocmVxICE9IFJUTV9ERUxFVEUpIA0K LQkJCWdvdG8gbm9uZGVsZXRlOw0KLQ0KLQkJZXJyb3IgPSBFTk9FTlQ7DQot CQlnb3RvIGRvbmU7DQotCX0NCi0JCQ0KLQkvKg0KLQkgKiBpZiB0aGUgZW50 cnkgaXMgMm5kIGFuZCBvbiB1cA0KLQkgKi8NCi0JaWYgKChyZXEgPT0gUlRN X0RFTEVURSkgJiYgIXJ0X21wYXRoX2RlbGR1cChydG8sIHJ0KSkNCi0JCXBh bmljICgicnRyZXF1ZXN0MTogcnRfbXBhdGhfZGVsZHVwIik7DQotZ3dkZWxl dGU6DQotCVJUX0xPQ0socnQpOw0KLQlSVF9BRERSRUYocnQpOw0KLQlpZiAo cmVxID09IFJUTV9ERUxFVEUpIHsNCi0JCXJ0LT5ydF9mbGFncyAmPSB+UlRG X1VQOw0KLQkJLyoNCi0JCSAqIE9uZSBtb3JlIHJ0ZW50cnkgZmxvYXRpbmcg YXJvdW5kIHRoYXQgaXMgbm90DQotCQkgKiBsaW5rZWQgdG8gdGhlIHJvdXRp bmcgdGFibGUuIHJ0dHJhc2ggd2lsbCBiZSBkZWNyZW1lbnRlZA0KLQkJICog d2hlbiBSVEZSRUUocnQpIGlzIGV2ZW50dWFsbHkgY2FsbGVkLg0KLQkJICov DQotCQlWX3J0dHJhc2grKzsNCi0JfQ0KLQkNCi1ub25kZWxldGU6DQotCWlm IChyZXEgIT0gUlRNX0RFTEVURSkNCi0JCXBhbmljKCJ1bnJlY29nbml6ZWQg cmVxdWVzdCAlZCIsIHJlcSk7DQotCQ0KLQ0KLQkvKg0KLQkgKiBJZiB0aGUg Y2FsbGVyIHdhbnRzIGl0LCB0aGVuIGl0IGNhbiBoYXZlIGl0LA0KLQkgKiBi dXQgaXQncyB1cCB0byBpdCB0byBmcmVlIHRoZSBydGVudHJ5IGFzIHdlIHdv bid0IGJlDQotCSAqIGRvaW5nIGl0Lg0KLQkgKi8NCi0JaWYgKHJldF9ucnQp IHsNCi0JCSpyZXRfbnJ0ID0gcnQ7DQotCQlSVF9VTkxPQ0socnQpOw0KLQl9 IGVsc2UNCi0JCVJURlJFRV9MT0NLRUQocnQpOw0KLWRvbmU6DQotCXJldHVy biAoZXJyb3IpOw0KLX0NCi0jZW5kaWYNCi0NCiBpbnQNCiBydHJlcXVlc3Qx X2ZpYihpbnQgcmVxLCBzdHJ1Y3QgcnRfYWRkcmluZm8gKmluZm8sIHN0cnVj dCBydGVudHJ5ICoqcmV0X25ydCwNCiAJCQkJdV9pbnQgZmlibnVtKQ0KQEAg LTEwNTgsMjggKzk1MiwzMCBAQA0KIA0KIAlzd2l0Y2ggKHJlcSkgew0KIAlj YXNlIFJUTV9ERUxFVEU6DQorCSAgICAgICAgaWYgKChybiA9IHJuaC0+cm5o X2xvb2t1cChkc3QsIG5ldG1hc2ssIHJuaCkpID09IE5VTEwpDQorCSAgICAg ICAgICAgICAgICBzZW5kZXJyKEVTUkNIKTsNCisJCXJ0ID0gUk5UT1JUKHJu KTsNCiAjaWZkZWYgUkFESVhfTVBBVEgNCi0JCWlmIChybl9tcGF0aF9jYXBh YmxlKHJuaCkpIHsNCi0JCQllcnJvciA9IHJuX21wYXRoX3VwZGF0ZShyZXEs IGluZm8sIHJuaCwgcmV0X25ydCk7DQotCQkJLyoNCi0JCQkgKiAiYmFkIiBo b2xkcyB0cnVlIGZvciB0aGUgc3VjY2VzcyBjYXNlDQotCQkJICogYXMgd2Vs bA0KLQkJCSAqLw0KLQkJCWlmIChlcnJvciAhPSBFTk9FTlQpDQotCQkJCWdv dG8gYmFkOw0KLQkJCWVycm9yID0gMDsNCi0JCX0NCisgICAgICAgICAgICAg ICAgLyoNCisgICAgICAgICAgICAgICAgICogaWYgd2UgZ290IG11bHRpcGF0 aCByb3V0ZXMsIHdlIHJlcXVpcmUgdXNlcnMgdG8gc3BlY2lmeQ0KKyAgICAg ICAgICAgICAgICAgKiBhIG1hdGNoaW5nIFJUQVhfR0FURVdBWS4NCisgICAg ICAgICAgICAgICAgICovDQorICAgICAgICAgICAgICAgIGlmIChybl9tcGF0 aF9jYXBhYmxlKHJuaCkpIHsNCisgICAgICAgICAgICAgICAgICAgICAgICBy dCA9IHJ0X21wYXRoX21hdGNoZ2F0ZSggcnQsIGdhdGV3YXkpOw0KKyAgICAg ICAgICAgICAgICAgICAgICAgIHJuID0gKHN0cnVjdCByYWRpeF9ub2RlICop cnQ7DQorICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCFydCkNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbmRlcnIoRVNSQ0gpOw0K KyAgICAgICAgICAgICAgICB9DQogI2VuZGlmDQogCQkvKg0KIAkJICogUmVt b3ZlIHRoZSBpdGVtIGZyb20gdGhlIHRyZWUgYW5kIHJldHVybiBpdC4NCiAJ CSAqIENvbXBsYWluIGlmIGl0IGlzIG5vdCB0aGVyZSBhbmQgZG8gbm8gbW9y ZSBwcm9jZXNzaW5nLg0KIAkJICovDQotCQlybiA9IHJuaC0+cm5oX2RlbGFk ZHIoZHN0LCBuZXRtYXNrLCBybmgpOw0KKwkJcm4gPSBybmgtPnJuaF9kZWxh ZGRyKGRzdCwgbmV0bWFzaywgcm5oLCBybik7DQogCQlpZiAocm4gPT0gTlVM TCkNCiAJCQlzZW5kZXJyKEVTUkNIKTsNCiAJCWlmIChybi0+cm5fZmxhZ3Mg JiAoUk5GX0FDVElWRSB8IFJORl9ST09UKSkNCiAJCQlwYW5pYyAoInJ0cmVx dWVzdCBkZWxldGUiKTsNCi0JCXJ0ID0gUk5UT1JUKHJuKTsNCiAJCVJUX0xP Q0socnQpOw0KIAkJUlRfQUREUkVGKHJ0KTsNCiAJCXJ0LT5ydF9mbGFncyAm PSB+UlRGX1VQOw0KQEAgLTE0NzQsMTAgKzEzNzAsOSBAQA0KIAkJCSAgICBS TlRPUlQocm4pLT5ydF9pZmEgIT0gaWZhIHx8DQogCQkJICAgICFzYV9lcXVh bCgoc3RydWN0IHNvY2thZGRyICopcm4tPnJuX2tleSwgZHN0KSk7DQogCQkJ UkFESVhfTk9ERV9IRUFEX1VOTE9DSyhybmgpOw0KLQkJCWlmIChlcnJvcikg ew0KKwkJCWlmIChlcnJvcikNCiAJCQkJLyogdGhpcyBpcyBvbmx5IGFuIGVy cm9yIGlmIGJhZCBvbiBBTEwgdGFibGVzICovDQogCQkJCWNvbnRpbnVlOw0K LQkJCX0NCiAJCX0NCiAJCS8qDQogCQkgKiBEbyB0aGUgYWN0dWFsIHJlcXVl c3QNCmRpZmYgLXIgLXUgL3Vzcl9kaWZmL3NyYy9zeXMvbmV0aW5ldC9pbi5j IC91c3Ivc3JjL3N5cy9uZXRpbmV0L2luLmMNCi0tLSAvdXNyX2RpZmYvc3Jj L3N5cy9uZXRpbmV0L2luLmMJMjAxMC0wOS0wNyAxMzoxMDo0Ni4wMDAwMDAw MDAgKzAwMDANCisrKyAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pbi5jCTIwMTAt MDktMTEgMDI6MjA6NTguMDAwMDAwMDAwICswMDAwDQpAQCAtMTM3NCwxMiAr MTM3NCw0NSBAQA0KIGluX2xsdGFibGVfcnRjaGVjayhzdHJ1Y3QgaWZuZXQg KmlmcCwgdV9pbnQgZmxhZ3MsIGNvbnN0IHN0cnVjdCBzb2NrYWRkciAqbDNh ZGRyKQ0KIHsNCiAJc3RydWN0IHJ0ZW50cnkgKnJ0Ow0KKyNpZmRlZiBSQURJ WF9NUEFUSA0KKwlpbnQ2NF90IHdlaWdodDsNCisJc3RydWN0IHJ0ZW50cnkg KnJ0MDsNCisJaW50MzJfdCBmb3VuZCA9IDA7DQorI2VuZGlmDQogDQogCUtB U1NFUlQobDNhZGRyLT5zYV9mYW1pbHkgPT0gQUZfSU5FVCwNCiAJICAgICgi c2luX2ZhbWlseSAlZCIsIGwzYWRkci0+c2FfZmFtaWx5KSk7DQogDQogCS8q IFhYWCBydGFsbG9jMSBzaG91bGQgdGFrZSBhIGNvbnN0IHBhcmFtICovDQog CXJ0ID0gcnRhbGxvYzEoX19ERUNPTlNUKHN0cnVjdCBzb2NrYWRkciAqLCBs M2FkZHIpLCAwLCAwKTsNCisNCisjaWZkZWYgUkFESVhfTVBBVEgNCisJcnQw ID0gcnQ7DQorICAgICAgICBpZiAoKHJ0ICE9IE5VTEwpICYmICggcm5fbXBh dGhfbmV4dCgoc3RydWN0IHJhZGl4X25vZGUgKilydCkgIT0gTlVMTCkpIHsN CisJCS8qIGNoZWNrIGlmIHRoZXJlIGFyZSBvdGhlciwgbWF0Y2hpbmcgcm91 dGVzICovDQorCQkvKiBmaW5kIGxvd2VzdCB3ZWlnaHQgcm91dGUgKi8NCisJ CWZvciAoIHdlaWdodCA9IHJ0LT5ydF9ybXgucm14X3dlaWdodDsgcnQgIT0g TlVMTDsgcnQgPSAoc3RydWN0IHJ0ZW50cnkgKilybl9tcGF0aF9uZXh0KCAo c3RydWN0IHJhZGl4X25vZGUgKilydCkpIHsNCisJCQlpZihydC0+cnRfZmxh Z3MgJiBSVEZfVVApIHsNCisJCQkJaWYgKHdlaWdodCA+IHJ0LT5ydF9ybXgu cm14X3dlaWdodCkNCisJCQkJCXdlaWdodCA9IHJ0LT5ydF9ybXgucm14X3dl aWdodDsNCisJCQl9DQorCQl9DQorDQorCQkvKiBmaW5kIG5vdyBvbmUgbm9u IGdhdGV3YXkgcm91dGUgd2l0aCBsb3dlc3Qgd2VpZ2h0ICovDQorCQlmb3Ig KCBydCA9IHJ0MDsgcnQgIT0gTlVMTDsgcnQgPSAoc3RydWN0IHJ0ZW50cnkg Kilybl9tcGF0aF9uZXh0KCAoc3RydWN0IHJhZGl4X25vZGUgKilydCkpIHsN CisJCQlpZihydC0+cnRfZmxhZ3MgJiBSVEZfVVApIHsNCisJCQkJaWYgKCh3 ZWlnaHQgPT0gcnQtPnJ0X3JteC5ybXhfd2VpZ2h0KSAmJiAhKHJ0LT5ydF9m bGFncyAmIFJURl9HQVRFV0FZKSkgew0KKwkJCQkJZm91bmQgPSAxOw0KKwkJ CQkJYnJlYWs7DQorCQkJCX0NCisJCQl9DQorCQl9DQorCQlpZiAoZm91bmQg PT0gMCkNCisJCQlydCA9IE5VTEw7DQorCX0NCisJDQorI2VuZGlmCQ0KKw0K IAlpZiAocnQgPT0gTlVMTCB8fCAoIShmbGFncyAmIExMRV9QVUIpICYmDQog CQkJICAgKChydC0+cnRfZmxhZ3MgJiBSVEZfR0FURVdBWSkgfHwgDQogCQkJ ICAgIChydC0+cnRfaWZwICE9IGlmcCkpKSkgew0KQEAgLTEzODcsMTEgKzE0 MjAsMjEgQEANCiAJCWxvZyhMT0dfSU5GTywgIklQdjQgYWRkcmVzczogXCIl c1wiIGlzIG5vdCBvbiB0aGUgbmV0d29ya1xuIiwNCiAJCSAgICBpbmV0X250 b2EoKChjb25zdCBzdHJ1Y3Qgc29ja2FkZHJfaW4gKilsM2FkZHIpLT5zaW5f YWRkcikpOw0KICNlbmRpZg0KKyNpZmRlZiBSQURJWF9NUEFUSA0KKwkJaWYg KHJ0MCAhPSBOVUxMKQ0KKwkJCVJURlJFRV9MT0NLRUQocnQwKTsNCisjZWxz ZQ0KIAkJaWYgKHJ0ICE9IE5VTEwpDQogCQkJUlRGUkVFX0xPQ0tFRChydCk7 DQorI2VuZGlmDQogCQlyZXR1cm4gKEVJTlZBTCk7DQogCX0NCisjaWZkZWYg UkFESVhfTVBBVEgNCisJUlRGUkVFX0xPQ0tFRChydDApOw0KKyNlbHNlDQog CVJURlJFRV9MT0NLRUQocnQpOw0KKyNlbmRpZg0KKw0KIAlyZXR1cm4gMDsN CiB9DQogDQpAQCAtMTQyNCw3ICsxNDY3LDcgQEANCiAJaWYgKGxsZSA9PSBO VUxMKSB7DQogI2lmZGVmIERJQUdOT1NUSUMNCiAJCWlmIChmbGFncyAmIExM RV9ERUxFVEUpDQotCQkJbG9nKExPR19JTkZPLCAiaW50ZXJmYWNlIGFkZHJl c3MgaXMgbWlzc2luZyBmcm9tIGNhY2hlID0gJXAgIGluIGRlbGV0ZVxuIiwg bGxlKTsJDQorCQkJbG9nKExPR19JTkZPLCAiaW50ZXJmYWNlIGFkZHJlc3Mg aXMgbWlzc2luZyBmcm9tIGNhY2hlID0gJXAgIGluIGRlbGV0ZVxuIiwgbGxl KTsNCiAjZW5kaWYNCiAJCWlmICghKGZsYWdzICYgTExFX0NSRUFURSkpDQog CQkJcmV0dXJuIChOVUxMKTsNCmRpZmYgLXIgLXUgL3Vzcl9kaWZmL3NyYy9z eXMvbmV0aW5ldC9pcGZ3L2lwX2Z3X3RhYmxlLmMgL3Vzci9zcmMvc3lzL25l dGluZXQvaXBmdy9pcF9md190YWJsZS5jDQotLS0gL3Vzcl9kaWZmL3NyYy9z eXMvbmV0aW5ldC9pcGZ3L2lwX2Z3X3RhYmxlLmMJMjAxMC0wMy0yMyAwOTo1 ODo1OS4wMDAwMDAwMDAgKzAwMDANCisrKyAvdXNyL3NyYy9zeXMvbmV0aW5l dC9pcGZ3L2lwX2Z3X3RhYmxlLmMJMjAxMC0wOS0wNiAxMToyMjozOS4wMDAw MDAwMDAgKzAwMDANCkBAIC0xMzcsNyArMTM3LDcgQEANCiAJbWFzay5zaW5f YWRkci5zX2FkZHIgPSBodG9ubChtbGVuID8gfigoMSA8PCAoMzIgLSBtbGVu KSkgLSAxKSA6IDApOw0KIAlzYS5zaW5fYWRkci5zX2FkZHIgPSBhZGRyICYg bWFzay5zaW5fYWRkci5zX2FkZHI7DQogCUlQRldfV0xPQ0soY2gpOw0KLQll bnQgPSAoc3RydWN0IHRhYmxlX2VudHJ5ICopcm5oLT5ybmhfZGVsYWRkcigm c2EsICZtYXNrLCBybmgpOw0KKwllbnQgPSAoc3RydWN0IHRhYmxlX2VudHJ5 ICopcm5oLT5ybmhfZGVsYWRkcigmc2EsICZtYXNrLCBybmgsIE5VTEwpOw0K IAlpZiAoZW50ID09IE5VTEwpIHsNCiAJCUlQRldfV1VOTE9DSyhjaCk7DQog CQlyZXR1cm4gKEVTUkNIKTsNCkBAIC0xNTQsNyArMTU0LDcgQEANCiAJc3Ry dWN0IHRhYmxlX2VudHJ5ICplbnQ7DQogDQogCWVudCA9IChzdHJ1Y3QgdGFi bGVfZW50cnkgKikNCi0JICAgIHJuaC0+cm5oX2RlbGFkZHIocm4tPnJuX2tl eSwgcm4tPnJuX21hc2ssIHJuaCk7DQorCSAgICBybmgtPnJuaF9kZWxhZGRy KHJuLT5ybl9rZXksIHJuLT5ybl9tYXNrLCBybmgsIE5VTEwpOw0KIAlpZiAo ZW50ICE9IE5VTEwpDQogCQlmcmVlKGVudCwgTV9JUEZXX1RCTCk7DQogCXJl dHVybiAoMCk7DQpkaWZmIC1yIC11IC91c3JfZGlmZi9zcmMvc3lzL25ldGlu ZXQvcmF3X2lwLmMgL3Vzci9zcmMvc3lzL25ldGluZXQvcmF3X2lwLmMNCi0t LSAvdXNyX2RpZmYvc3JjL3N5cy9uZXRpbmV0L3Jhd19pcC5jCTIwMTAtMDgt MjcgMTg6NTA6MTIuMDAwMDAwMDAwICswMDAwDQorKysgL3Vzci9zcmMvc3lz L25ldGluZXQvcmF3X2lwLmMJMjAxMC0wOS0xMSAwMjozNzoyNi4wMDAwMDAw MDAgKzAwMDANCkBAIC03NTUsNiArNzU1LDggQEANCiAJCWlmIChlcnIgPT0g MCkNCiAJCQlpYS0+aWFfZmxhZ3MgfD0gSUZBX1JPVVRFOw0KIAkJZXJyID0g aWZhX2FkZF9sb29wYmFja19yb3V0ZSgoc3RydWN0IGlmYWRkciAqKWlhLCBz YSk7DQorCQlpZiAoZXJyID09IDApDQorCQkgICAgICAgIGlhLT5pYV9mbGFn cyB8PSBJRkFfUlRTRUxGOw0KIAkJaWZhX2ZyZWUoJmlhLT5pYV9pZmEpOw0K IAkJYnJlYWs7DQogCX0NCg== --168430090-52481847-1284174321=:5369-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 09:23:03 2010 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 A24D9106564A; Sat, 11 Sep 2010 09:23:03 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 78FD48FC13; Sat, 11 Sep 2010 09:23: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 o8B9N3Es037448; Sat, 11 Sep 2010 09:23:03 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8B9N3Cj037444; Sat, 11 Sep 2010 09:23:03 GMT (envelope-from remko) Date: Sat, 11 Sep 2010 09:23:03 GMT Message-Id: <201009110923.o8B9N3Cj037444@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/150481: IFA_RTSELF: freebsd 8.1 - ifdown - ifup - loopback route keeps 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, 11 Sep 2010 09:23:03 -0000 Old Synopsis: freebsd 8.1 - ifdown - ifup - loopback route keeps New Synopsis: IFA_RTSELF: freebsd 8.1 - ifdown - ifup - loopback route keeps Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Sep 11 09:22:40 UTC 2010 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=150481 From owner-freebsd-net@FreeBSD.ORG Sat Sep 11 15:38:43 2010 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 D5F30106566B; Sat, 11 Sep 2010 15:38:43 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 1678D8FC0C; Sat, 11 Sep 2010 15:38:42 +0000 (UTC) Received: from [10.1.1.53] ([10.1.1.53]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id o8BFcdeo058861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 11 Sep 2010 11:38:39 -0400 (EDT) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: Karim Fodil-Lemelin In-Reply-To: <4C8AA863.4060908@xiplink.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 11 Sep 2010 08:38:39 -0700 References: <4C7A7B25.9040300@freebsd.org> <4C7D0089.1020104@freebsd.org> <4C8AA863.4060908@xiplink.com> X-Mailer: Apple Mail (2.936) Cc: freebsd-net@freebsd.org, Andre Oppermann , Robert Watson Subject: Re: Removal of deprecated implied connect for TCP 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, 11 Sep 2010 15:38:44 -0000 All: One thing to note.. when you can do an implied connection setup, the 3-way hand shake has the potential to carry data (don't know if tcp does in FreeBSD) on the third leg of the 3-way handshake. This is one of the reasons SCTP uses this.. since we often will carry data an the third and even possibly the 4th leg of the handshake (we have one extra leg). Taking this feature out of TCP will make it so we will be like all other o/s's and the socket semantic will prevent you from doing data on the third leg.. ----SYN----> <----SYN-ACK--- ----ACK---> instead of ----SYN--> <---SYN-ACk-- ---ACK+DATA--> In the past I have mentioned in classes I teach that TCP is capable of this but the O/S's of the world do not allow this later behavior.. Just thoughts and ramblings ;-) R On Sep 10, 2010, at 2:51 PM, Karim Fodil-Lemelin wrote: > On 31/08/2010 5:32 PM, Robert Watson wrote: >> >> On Tue, 31 Aug 2010, Andre Oppermann wrote: >> >>>> I'm not entirely comfortable with this change, and would like a >>>> chance to cogitate on it a bit more. While I'm not aware of any >>>> applications depending on the semantic for TCP, I know that we do >>>> use it for UNIX domain sockets. >>> >>> I don't have any plans to remove the implied connect support from >>> the socket layer or other protocols, only from TCP. >> >> Right -- the implicit question is: why should TCP be the only >> stream protocol in our stack *not* to support implied connection, >> when we plan to continue to support it for all other protocols? >> >>> For deprecating this part of the TCP API there is no documentation >>> to the implied connect in tcp(4). In sendto(2) it doesn't >>> differentiate between protocols and simply says: "... sendto() and >>> sendmsg() may be used at any time." For MSG_EOF it says that is >>> only supported for SOCK_STREAM sockets in the PF_INET protocol >>> family. These sentences have to be corrected. >> >> In general, deprecating is taken to mean providing significant and >> explicit advance warning of removal -- for example, updating the >> 8.x man page to point out that the feature is deprecated and it >> will not appear in future releases of FreeBSD. >> >> Robert >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net- >> unsubscribe@freebsd.org" > Hi, > > For what its worth, we at Xiphos (now XipLink), are still using > sendto and T/TCP and is one of the reasons we've chosen FreeBSD more > then 10 years ago! > > Best regards, > > Karim. > _______________________________________________ > 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" > ------------------------------ Randall Stewart 803-317-4952 (cell)