From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 02:54:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5018E106566B; Sun, 9 Oct 2011 02:54:21 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id DE2A38FC14; Sun, 9 Oct 2011 02:54:20 +0000 (UTC) Received: by qyk10 with SMTP id 10so1588320qyk.13 for ; Sat, 08 Oct 2011 19:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qe1FJCm5UeMi8GMGi4sZiPC75OqL3cpjcsLbVJgvJMw=; b=WdNuq/tF/C0oZn1wlGKlM1RzHsalgaaHBZyK+9WRpb/CGAIRE+K3RnDF/FtS/JmRz7 JaGB6w0IPA/wuEsUgVmuozlwpzVoG8pfmQz7y922DozxOdpxI8Hl0QIxET5hc33V7gGe x1kgzP4nQPPQdjum0spM0VnZZbyPXjaqGPq3M= MIME-Version: 1.0 Received: by 10.229.195.105 with SMTP id eb41mr2741559qcb.182.1318128858350; Sat, 08 Oct 2011 19:54:18 -0700 (PDT) Received: by 10.229.26.18 with HTTP; Sat, 8 Oct 2011 19:54:18 -0700 (PDT) In-Reply-To: References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> <201110071936.50071.break19@gmail.com> Date: Sat, 8 Oct 2011 21:54:18 -0500 Message-ID: From: Chuck Burns To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 09 Oct 2011 02:54:21 -0000 Another crash image, this time at a much larger resolution. Also, as you can see, it still failed to dump, stopped at 1%, never went any higher than that. http://imageshack.us/photo/my-images/43/anothercrash.jpg/ I guess no one has any answers for this :( On 10/7/11, Adrian Chadd wrote: > On 8 October 2011 08:36, Chuck Burns wrote: > >> I don't know what that means really. =A0I consider myself a fairly advan= ced >> user, but nothing more, really. > > I'm going to need some help to help Chuck here. :) Any takers? > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 03:24:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F15A1065672; Sun, 9 Oct 2011 03:24:47 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7788FC13; Sun, 9 Oct 2011 03:24:46 +0000 (UTC) Received: by wyj26 with SMTP id 26so7078929wyj.13 for ; Sat, 08 Oct 2011 20:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DCebc6YSCGXTIerCbxEj7EGQxM4qRrMkfSJl8is2nv8=; b=wN8gZ+6PrxgRBqXRvWuwbIS6zL9fueSdPaZ0q5l7L8WXo90Mjmck1KBxMVkdv4cjVH KDuRFabJKegBgFRgOL8kf100ebzeMrrnPGoygiNoWUvrzLDluRmitzCW/2sWf1JI501E dpB/0gPP5w15+GOI7FDeyWttCnt4+cUn3IwAI= MIME-Version: 1.0 Received: by 10.227.195.13 with SMTP id ea13mr4312636wbb.36.1318130683356; Sat, 08 Oct 2011 20:24:43 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Sat, 8 Oct 2011 20:24:43 -0700 (PDT) In-Reply-To: References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> <201110071936.50071.break19@gmail.com> Date: Sat, 8 Oct 2011 23:24:43 -0400 Message-ID: From: Arnaud Lacombe To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 09 Oct 2011 03:24:47 -0000 Hi, On Sat, Oct 8, 2011 at 10:54 PM, Chuck Burns wrote: > Another crash image, this time at a much larger resolution. > > Also, as you can see, it still failed to dump, stopped at 1%, never > went any higher than that. > > http://imageshack.us/photo/my-images/43/anothercrash.jpg/ > > I guess no one has any answers for this :( > could you upload the compressed kernel and if_urtw.ko somewhere ? I'd like to inspect something. A. From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 04:49:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB72106566C; Sun, 9 Oct 2011 04:49:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD8A48FC08; Sun, 9 Oct 2011 04:49:50 +0000 (UTC) Received: by ywp17 with SMTP id 17so5789136ywp.13 for ; Sat, 08 Oct 2011 21:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IdlvL1sLXNT93S8rX0AAfu3pezA4D+bIuy8bPP6grbg=; b=QJQsWZqCGlzMF8DjYPA0qXkBTTozrxjH8ZQ+Seq/Wrztl3Dii2h3ZiNR9lVsjpHpm3 A6GRhv2I74EbOOJR3wGkEM4yYA/lSO8+yffYVbMfc9C9zuaHSP/kgrnHxN5Ux3xKwKfv 0ltO2P4keOlrodGUOlCzlzk/OBjliLiRYAycg= MIME-Version: 1.0 Received: by 10.236.187.70 with SMTP id x46mr17991756yhm.71.1318135790447; Sat, 08 Oct 2011 21:49:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Sat, 8 Oct 2011 21:49:50 -0700 (PDT) In-Reply-To: References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> <201110071936.50071.break19@gmail.com> Date: Sun, 9 Oct 2011 12:49:50 +0800 X-Google-Sender-Auth: V6uTlE1fL-uf5kNjVobgVFm-Pbs Message-ID: From: Adrian Chadd To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 09 Oct 2011 04:49:51 -0000 Hi Chuck, I could help you with it but I honestly have no time at the moment. :( Adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 05:38:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B79A1065672; Sun, 9 Oct 2011 05:38:13 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7D1D8FC0A; Sun, 9 Oct 2011 05:38:12 +0000 (UTC) Received: by qyk4 with SMTP id 4so5035684qyk.13 for ; Sat, 08 Oct 2011 22:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0K8o+sDRUd5t2MIIa8HcFBPnjwbI4tPI2LbN/CbKN0U=; b=KSd+ZfBh8CTgLiEZOLV/MkLJFohIAlAbCXwmzGUrcscYDPfTPoF6NQ+zXkQqYlZqjO iYYkoZl47yjgPOU3V02DAxQCl4JEyMcUNLybTqqwYYHXiRDYReKSE3uOk7JzJhe3h6sO A8tJz1TBQVx4HW1Z54yvX9nuywhZ67S2mS84A= MIME-Version: 1.0 Received: by 10.229.28.130 with SMTP id m2mr1638899qcc.30.1318138691807; Sat, 08 Oct 2011 22:38:11 -0700 (PDT) Received: by 10.229.26.18 with HTTP; Sat, 8 Oct 2011 22:38:11 -0700 (PDT) In-Reply-To: References: <201110042008.48915.break19@gmail.com> <201110071816.17335.break19@gmail.com> <201110071936.50071.break19@gmail.com> Date: Sun, 9 Oct 2011 00:38:11 -0500 Message-ID: From: Chuck Burns To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 09 Oct 2011 05:38:13 -0000 www.thesouthernlibertarian.com/kernel-urtw.tar.gz This has 4 files: /boot/kernel/kernel[.symbols] /boot/kernel/if_urtw.ko[.symbols] Thanks On Sat, Oct 8, 2011 at 10:24 PM, Arnaud Lacombe wrote: > Hi, > > On Sat, Oct 8, 2011 at 10:54 PM, Chuck Burns wrote: >> Another crash image, this time at a much larger resolution. >> >> Also, as you can see, it still failed to dump, stopped at 1%, never >> went any higher than that. >> >> http://imageshack.us/photo/my-images/43/anothercrash.jpg/ >> >> I guess no one has any answers for this :( >> > could you upload the compressed kernel and if_urtw.ko somewhere ? I'd > like to inspect something. > > A. > From owner-freebsd-net@FreeBSD.ORG Sun Oct 9 17:30:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2297D1065678 for ; Sun, 9 Oct 2011 17:30:00 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9038F8FC15 for ; Sun, 9 Oct 2011 17:29:59 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p99GwcNd019923; Sun, 9 Oct 2011 18:58:38 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p99GwcS1019922; Sun, 9 Oct 2011 18:58:38 +0200 (CEST) (envelope-from marius) Date: Sun, 9 Oct 2011 18:58:38 +0200 From: Marius Strobl To: dave jones Message-ID: <20111009165838.GA19886@alchemy.franken.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Question about GPIO bitbang MII 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, 09 Oct 2011 17:30:00 -0000 On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > Hi, > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > gpio-bitbang mii that I can refer to? Thanks. > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > and it's useful for porting embedded devices. > If what you are referring to is their mii_bitbang.[c,h] then I've a patch which (im)ports these and converts drivers to take advantage of it here: http://people.freebsd.org/~marius/mii_bitbang.diff You can also hook up that generic MII bitbang'ing code up to GPIO. Marius From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 04:55:45 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03E41065672; Mon, 10 Oct 2011 04:55:45 +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 B78698FC2A; Mon, 10 Oct 2011 04:55: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 p9A4tj8K053276; Mon, 10 Oct 2011 04:55:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9A4tjs7053272; Mon, 10 Oct 2011 04:55:45 GMT (envelope-from linimon) Date: Mon, 10 Oct 2011 04:55:45 GMT Message-Id: <201110100455.p9A4tjs7053272@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161123: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew 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, 10 Oct 2011 04:55:46 -0000 Old Synopsis: CARP - when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew New Synopsis: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 10 04:55:26 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 07:56:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D1161065674 for ; Mon, 10 Oct 2011 07:56:33 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0298FC16 for ; Mon, 10 Oct 2011 07:56:32 +0000 (UTC) Received: by vcbf13 with SMTP id f13so6180346vcb.13 for ; Mon, 10 Oct 2011 00:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JbVZ9regMgSPPWYNBmiVs5thWlhC56kgy9Fe76dM88w=; b=sMN/eaiSM6ybaLI7OW+sQlvv2QzCNdJ3ihNSZoLi1ADXlYCJwvYjN+hRM3zASVGt5d qBSwByqqgLyfckIBK69tjyPVdqoCFK4m5qtbcspGUFTQF6OBtmqXT784QHovL7tY8pxv ZwVrh8KRO5Xrp9+zLDijoAM6D7gYzFXf7H6js= MIME-Version: 1.0 Received: by 10.52.182.198 with SMTP id eg6mr12444067vdc.16.1318233392300; Mon, 10 Oct 2011 00:56:32 -0700 (PDT) Received: by 10.52.186.170 with HTTP; Mon, 10 Oct 2011 00:56:32 -0700 (PDT) In-Reply-To: <20111009165838.GA19886@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> Date: Mon, 10 Oct 2011 15:56:32 +0800 Message-ID: From: dave jones To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Question about GPIO bitbang MII 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, 10 Oct 2011 07:56:33 -0000 On Mon, Oct 10, 2011 at 12:58 AM, Marius Strobl wrote: > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: >> Hi, >> >> Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using >> gpio-bitbang mii that I can refer to? Thanks. >> It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, >> and it's useful for porting embedded devices. >> > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > which (im)ports these and converts drivers to take advantage of it here: > http://people.freebsd.org/~marius/mii_bitbang.diff > You can also hook up that generic MII bitbang'ing code up to GPIO. Awesome! This is what I want, thank you very much, Marius. > Marius Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 11:07:13 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25F6710656D7 for ; Mon, 10 Oct 2011 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1423D8FC1C for ; Mon, 10 Oct 2011 11:07: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 p9AB7D9g032455 for ; Mon, 10 Oct 2011 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9AB7Cqo032453 for freebsd-net@FreeBSD.org; Mon, 10 Oct 2011 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Oct 2011 11:07:12 GMT Message-Id: <201110101107.p9AB7Cqo032453@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, 10 Oct 2011 11:07:13 -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/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/161123 net [carp] [patch] when preemption is enabled carp interfa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159602 net [netinet] [patch] arp_ifscrub() is called even if IFF_ o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 389 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 16:42:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3D71065674; Mon, 10 Oct 2011 16:42:41 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 5DEE58FC0C; Mon, 10 Oct 2011 16:42:41 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9AGgNfe006584; Mon, 10 Oct 2011 09:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318264944; bh=a05E+aua+g8L898aoNIBcAVpGrFP5bP0q3DpTzC15dE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=OeV1gfUpCZBe7X+cundq7okK5QOQoXWrmeqLrTF3AZhyacgza4f2Dqp8nFK23iei9 evnrOP9FeALwU6NFKjZIiDtFRWaULKcpkWWtCPocTnxmsjWOHbs3dthrljJFUmugfD N6zO+OJH2C+DT5JHs/8Vccfr0P7oEyI0ilDJcMt8= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20111007205254.GC11808@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 10 Oct 2011 09:42:22 -0700 Message-ID: <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 10 Oct 2011 16:42:41 -0000 On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > Could you try attached patch? Yeah, this does work on the r410 ... however, I can't test the "negative" case here where the bce(4) driver runs across a chipset where sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 I tried disabling the Dell IPMI controller, but the h/w is still there doing "things". So, this may not be the flag you want to use. Sean From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 17:36:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1205) id 8A5741065676; Mon, 10 Oct 2011 17:36:40 +0000 (UTC) Date: Mon, 10 Oct 2011 17:36:40 +0000 From: Navdeep Parhar To: freebsd-net@freebsd.org Message-ID: <20111010173640.GA79248@hub.freebsd.org> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic in tcp_drop (and fix for it) 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, 10 Oct 2011 17:36:40 -0000 While stress testing a few systems, I encountered a panic in tcp_drop due to NULL tp->t_inpcb. tcp_drop had been called by tcp_timer_rexmt. The problem is that timer_rexmt lets go of the pcbinfo and inp locks and the inp could be dropped by the time it re-acquires the locks. The attached patch fixes the problem. I've observed the counter in the patch go up by 2-3 in 48 hours or so. If someone can review the patch I can push it (without the counter) to head. Regards, Navdeep --- a/sys/netinet/tcp_timer.c +++ b/sys/netinet/tcp_timer.c @@ -439,6 +439,8 @@ CURVNET_RESTORE(); } +static int tcp_rexmt_inpdrop_race = 0; + void tcp_timer_rexmt(void * xtp) { @@ -495,6 +497,14 @@ CURVNET_RESTORE(); return; } + if (inp->inp_flags & INP_DROPPED) { + tcp_rexmt_inpdrop_race++; + INP_WUNLOCK(inp); + INP_INFO_WUNLOCK(&V_tcbinfo); + CURVNET_RESTORE(); + return; + } + tp = tcp_drop(tp, tp->t_softerror ? tp->t_softerror : ETIMEDOUT); headlocked = 1; From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 17:49:39 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A645A106564A; Mon, 10 Oct 2011 17:49:39 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D539F8FC0C; Mon, 10 Oct 2011 17:49:38 +0000 (UTC) Received: by wyj26 with SMTP id 26so9562213wyj.13 for ; Mon, 10 Oct 2011 10:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=341ZnWmy8nKjRvLqrJiaJuaTucBqf0XkjO+fh/SCsag=; b=dor6mmRK2ffqA5+71db6OfjcXwr5lY47Pm6B9gHmzAXkUB0VyvLrB18WGW+rYfBxEW 4VNWN1AFxfKr5bo/16+UUEy4cBlA+fY88VQm6j5FVTuDd/Ys5uqIt/lw6bIv0tqzwPB9 28dcRm/5Jmpk/OJbTbtRQ0nckK8HvCukKDItE= Received: by 10.227.37.214 with SMTP id y22mr6727271wbd.76.1318268977633; Mon, 10 Oct 2011 10:49:37 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id e7sm1374247wbh.12.2011.10.10.10.49.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 10:49:35 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 10 Oct 2011 10:47:49 -0700 From: YongHyeon PYUN Date: Mon, 10 Oct 2011 10:47:49 -0700 To: Sean Bruno Message-ID: <20111010174749.GA1781@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:49:39 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote: > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > > > Could you try attached patch? > > Yeah, this does work on the r410 ... however, I can't test the > "negative" case here where the bce(4) driver runs across a chipset where > sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 > > I tried disabling the Dell IPMI controller, but the h/w is still there > doing "things". So, this may not be the flag you want to use. > Hmm, then could you try attached patch again? > Sean > --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bce.mfm.diff2" Index: sys/dev/bce/if_bce.c =================================================================== --- sys/dev/bce/if_bce.c (revision 226123) +++ sys/dev/bce/if_bce.c (working copy) @@ -761,7 +761,7 @@ bce_print_adapter_info(struct bce_softc *sc) printf("2.5G"); i++; } - if (sc->bce_flags & BCE_MFW_ENABLE_FLAG) { + if (sc->bce_flags & BCE_MFW_PRESENT_FLAG) { if (i > 0) printf("|"); printf("MFW); MFW (%s)\n", sc->bce_mfw_ver); } else { @@ -1221,7 +1221,7 @@ bce_attach(device_t dev) /* Check if any management firwmare is enabled. */ val = bce_shmem_rd(sc, BCE_PORT_FEATURE); if (val & BCE_PORT_FEATURE_ASF_ENABLED) { - sc->bce_flags |= BCE_MFW_ENABLE_FLAG; + sc->bce_flags |= BCE_MFW_PRESENT_FLAG; /* Allow time for firmware to enter the running state. */ for (int i = 0; i < 30; i++) { @@ -1246,6 +1246,7 @@ bce_attach(device_t dev) memcpy(&sc->bce_mfw_ver[i], &val, 4); i += 4; } + sc->bce_flags |= BCE_MFW_ENABLE_FLAG; } else { /* May cause firmware synchronization timeouts. */ BCE_PRINTF("%s(%d): Management firmware enabled " @@ -6158,7 +6159,8 @@ bce_ifmedia_sts(struct ifnet *ifp, struct ifmediar BCE_LOCK(sc); - if ((ifp->if_flags & IFF_UP) == 0) { + if ((ifp->if_flags & IFF_UP) == 0 && + (sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0) { BCE_UNLOCK(sc); return; } Index: sys/dev/bce/if_bcereg.h =================================================================== --- sys/dev/bce/if_bcereg.h (revision 226123) +++ sys/dev/bce/if_bcereg.h (working copy) @@ -6431,11 +6431,12 @@ struct bce_softc #define BCE_NO_WOL_FLAG 0x00000008 #define BCE_USING_DAC_FLAG 0x00000010 #define BCE_USING_MSI_FLAG 0x00000020 -#define BCE_MFW_ENABLE_FLAG 0x00000040 -#define BCE_ONE_SHOT_MSI_FLAG 0x00000080 -#define BCE_USING_MSIX_FLAG 0x00000100 -#define BCE_PCIE_FLAG 0x00000200 -#define BCE_USING_TX_FLOW_CONTROL 0x00000400 +#define BCE_MFW_PRESENT_FLAG 0x00000040 +#define BCE_MFW_ENABLE_FLAG 0x00000080 +#define BCE_ONE_SHOT_MSI_FLAG 0x00000100 +#define BCE_USING_MSIX_FLAG 0x00000200 +#define BCE_PCIE_FLAG 0x00000400 +#define BCE_USING_TX_FLOW_CONTROL 0x00000800 /* Controller capability flags. */ u32 bce_cap_flags; --YiEDa0DAkWCtVeE4-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 18:08:39 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F23871065670 for ; Mon, 10 Oct 2011 18:08:39 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 688C88FC16 for ; Mon, 10 Oct 2011 18:08:39 +0000 (UTC) Received: (qmail 43497 invoked from network); 10 Oct 2011 16:50:15 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 10 Oct 2011 16:50:15 -0000 Message-ID: <4E9334A6.2050907@freebsd.org> Date: Mon, 10 Oct 2011 20:08:38 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: np@FreeBSD.org References: <20111010173640.GA79248@hub.freebsd.org> In-Reply-To: <20111010173640.GA79248@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: panic in tcp_drop (and fix for it) 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, 10 Oct 2011 18:08:40 -0000 On 10.10.2011 19:36, Navdeep Parhar wrote: > While stress testing a few systems, I encountered a panic in tcp_drop > due to NULL tp->t_inpcb. tcp_drop had been called by tcp_timer_rexmt. > The problem is that timer_rexmt lets go of the pcbinfo and inp locks and > the inp could be dropped by the time it re-acquires the locks. > > The attached patch fixes the problem. I've observed the counter in the > patch go up by 2-3 in 48 hours or so. If someone can review the patch > I can push it (without the counter) to head. Looks good w/o the counter. > Regards, > Navdeep > > --- a/sys/netinet/tcp_timer.c > +++ b/sys/netinet/tcp_timer.c > @@ -439,6 +439,8 @@ > CURVNET_RESTORE(); > } > > +static int tcp_rexmt_inpdrop_race = 0; > + > void > tcp_timer_rexmt(void * xtp) > { > @@ -495,6 +497,14 @@ > CURVNET_RESTORE(); > return; > } > + if (inp->inp_flags& INP_DROPPED) { > + tcp_rexmt_inpdrop_race++; > + INP_WUNLOCK(inp); > + INP_INFO_WUNLOCK(&V_tcbinfo); > + CURVNET_RESTORE(); > + return; > + } > + > tp = tcp_drop(tp, tp->t_softerror ? > tp->t_softerror : ETIMEDOUT); > headlocked = 1; > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 18:24:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35945106566B; Mon, 10 Oct 2011 18:24:25 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id CE02D8FC14; Mon, 10 Oct 2011 18:24:24 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9AIO6Rh043410; Mon, 10 Oct 2011 11:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318271047; bh=FWzUS86K/UWGyKpKz0roospFWtBfXPNISe8rxg8HX3k=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=f857y4cybpjm5SEMtiy02XsDMdSTADODWStxsTflochcZCa4nZxnQrhYT/JNw3vyi RGYXLGRGQkZHlVeah/zZaifoVWAjZ5bOQnTUCPyjKDAAXnvHgLbA29UT1VnqcOVbpS GOzwjey1Sv3u/r0roIt5zw0m4ieS+72ZADR53sA0= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20111010174749.GA1781@michelle.cdnetworks.com> References: <1317315666.2777.8.camel@hitfishpass-lx.corp.yahoo.com> <1317323418.2777.14.camel@hitfishpass-lx.corp.yahoo.com> <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 10 Oct 2011 11:24:06 -0700 Message-ID: <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 10 Oct 2011 18:24:25 -0000 On Mon, 2011-10-10 at 10:47 -0700, YongHyeon PYUN wrote: > On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote: > > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > > > > > Could you try attached patch? > > > > Yeah, this does work on the r410 ... however, I can't test the > > "negative" case here where the bce(4) driver runs across a chipset where > > sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 > > > > I tried disabling the Dell IPMI controller, but the h/w is still there > > doing "things". So, this may not be the flag you want to use. > > > > Hmm, then could you try attached patch again? > > > Sean > > hrm indeed. I don't know that the Dell DRAC thing actually does anythign to the running IPMI controller on the host. Disabling the IPMI/DRAC completely in the BIOS of the DRAC does seem to have any effect on this flag. -bash-4.2$ dmesg |grep -i bce bce0: mem 0xd8000000-0xd9ffffff irq 36 at device 0.0 on pci1 bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xd8000000 bce0: attempting to allocate 1 MSI vectors (16 supported) bce0: using IRQ 256 for MSI miibus0: on bce0 bce0: bpf attached bce0: Ethernet address: a4:ba:db:2b:6d:58 bce0: [MPSAFE] bce0: [ITHREAD] bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Flags (MSI|MFW); MFW (NCSI 2.0.8) bce1: mem 0xdc000000-0xddffffff irq 48 at device 0.1 on pci1 bce1: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xdc000000 bce1: attempting to allocate 1 MSI vectors (16 supported) bce1: using IRQ 257 for MSI miibus1: on bce1 bce1: bpf attached bce1: Ethernet address: a4:ba:db:2b:6d:59 bce1: [MPSAFE] bce1: [ITHREAD] bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Flags (MSI|MFW); MFW (NCSI 2.0.8) bce1: link state changed to UP From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 19:07:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEC48106564A; Mon, 10 Oct 2011 19:07:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1B438FC08; Mon, 10 Oct 2011 19:07:57 +0000 (UTC) Received: by wyj26 with SMTP id 26so9677664wyj.13 for ; Mon, 10 Oct 2011 12:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IC1PTQIZd7r5xthNO7MrtRfTAY9G9VdJZCiDFlSp0+E=; b=pKlIExdD/GlbzV80L+2oapCUWHA3TyPlJlPD/oUgmcW8BjP8kgelk+B5At0iJY8sgq 1GVlSwyTRiU+JdZtTGmJ31hNZDDwAJym7HQH9PFDKE7TyOFWqQFFuitKd0aGyUMtXvYD OttxuhDRidpm86ZWhd1Mwi+s8LDSsowxiSIho= Received: by 10.227.195.77 with SMTP id eb13mr6751350wbb.79.1318273676776; Mon, 10 Oct 2011 12:07:56 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id o7sm34220093wbh.8.2011.10.10.12.07.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 12:07:55 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 10 Oct 2011 12:06:09 -0700 From: YongHyeon PYUN Date: Mon, 10 Oct 2011 12:06:09 -0700 To: Sean Bruno Message-ID: <20111010190609.GB1781@michelle.cdnetworks.com> References: <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 19:07:59 -0000 On Mon, Oct 10, 2011 at 11:24:06AM -0700, Sean Bruno wrote: > On Mon, 2011-10-10 at 10:47 -0700, YongHyeon PYUN wrote: > > On Mon, Oct 10, 2011 at 09:42:22AM -0700, Sean Bruno wrote: > > > On Fri, 2011-10-07 at 13:52 -0700, YongHyeon PYUN wrote: > > > > > > > > Could you try attached patch? > > > > > > Yeah, this does work on the r410 ... however, I can't test the > > > "negative" case here where the bce(4) driver runs across a chipset where > > > sc->bce_flags & BCE_MFW_ENABLE_FLAG == 0 > > > > > > I tried disabling the Dell IPMI controller, but the h/w is still there > > > doing "things". So, this may not be the flag you want to use. > > > > > > > Hmm, then could you try attached patch again? > > > > > Sean > > > > > hrm indeed. I don't know that the Dell DRAC thing actually does > anythign to the running IPMI controller on the host. Disabling the > IPMI/DRAC completely in the BIOS of the DRAC does seem to have any > effect on this flag. > > -bash-4.2$ dmesg |grep -i bce > bce0: mem > 0xd8000000-0xd9ffffff irq 36 at device 0.0 on pci1 > bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xd8000000 > bce0: attempting to allocate 1 MSI vectors (16 supported) > bce0: using IRQ 256 for MSI > miibus0: on bce0 > bce0: bpf attached > bce0: Ethernet address: a4:ba:db:2b:6d:58 > bce0: [MPSAFE] > bce0: [ITHREAD] > bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); > Flags (MSI|MFW); MFW (NCSI 2.0.8) > bce1: mem > 0xdc000000-0xddffffff irq 48 at device 0.1 on pci1 > bce1: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xdc000000 > bce1: attempting to allocate 1 MSI vectors (16 supported) > bce1: using IRQ 257 for MSI > miibus1: on bce1 > bce1: bpf attached > bce1: Ethernet address: a4:ba:db:2b:6d:59 > bce1: [MPSAFE] > bce1: [ITHREAD] > bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); > Flags (MSI|MFW); MFW (NCSI 2.0.8) > bce1: link state changed to UP > Did you capture this message generated after disabling IPMI/DRAC in BIOS? I thought you had to use Broadcom's separate program to disable management firmware. Does the last patch solve the problem? It's still not clear to me. The last patch allows accessing PHY status when there is a management firmware regardless of its running state. > From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 19:24:28 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05981106564A for ; Mon, 10 Oct 2011 19:24:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 896C78FC16 for ; Mon, 10 Oct 2011 19:24:27 +0000 (UTC) Received: by wyj26 with SMTP id 26so9699298wyj.13 for ; Mon, 10 Oct 2011 12:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=7gnUF7FajX3o/A11Jy4GFb6I/RfJKNE8asKAJHjfzg8=; b=ZMkYZR1T9D3BX+qDSgfR2m/ENb/6b0wWeVKOxJv/ENh+E/0ixuV4qlO5NWYfEyv7x8 sSviFjG8cxXW8w4Gs244FQdRzuNxxQ/FMF1O4ZdXqkO2/l5lHKY77wQHVaTBRcqLC8MX eHVM83nJOSTlegarke0zI0gTbt73Q0akS+4s4= Received: by 10.227.182.138 with SMTP id cc10mr6584801wbb.96.1318274666419; Mon, 10 Oct 2011 12:24:26 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id ei16sm34242804wbb.21.2011.10.10.12.24.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 12:24:25 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 10 Oct 2011 12:22:38 -0700 From: YongHyeon PYUN Date: Mon, 10 Oct 2011 12:22:38 -0700 To: Marius Strobl Message-ID: <20111010192238.GC1781@michelle.cdnetworks.com> References: <20111009165838.GA19886@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111009165838.GA19886@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 19:24:28 -0000 On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > Hi, > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > gpio-bitbang mii that I can refer to? Thanks. > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > and it's useful for porting embedded devices. > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > which (im)ports these and converts drivers to take advantage of it here: > http://people.freebsd.org/~marius/mii_bitbang.diff Patch looks good to me. What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) and xe(4))? > You can also hook up that generic MII bitbang'ing code up to GPIO. > > Marius From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 20:26:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB101065672; Mon, 10 Oct 2011 20:26:07 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from mailgate.jr-hosting.nl (mail.jr-hosting.nl [IPv6:2a01:4f8:141:5061::25]) by mx1.freebsd.org (Postfix) with ESMTP id 7D01A8FC14; Mon, 10 Oct 2011 20:26:06 +0000 (UTC) Received: from axantucar.elvandar.org (178-85-116-244.dynamic.upc.nl [178.85.116.244]) by mailgate.jr-hosting.nl (Postfix) with ESMTPSA id CF9A13F44F; Mon, 10 Oct 2011 22:26:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) From: Remko Lodder In-Reply-To: Date: Mon, 10 Oct 2011 22:26:04 +0200 Message-Id: References: To: Gi Dot X-Mailer: Apple Mail (2.1244.3) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Error - mysql_connect: Operation not permitted. 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, 10 Oct 2011 20:26:07 -0000 >=20 >=20 >=20 > Appreciate any advice offered. >=20 > Thanks. Dear "gi", Please do not cross post to different mailing lists. You ask something = about PF and not specifically about networking things at the moment. I didn't read the pf.conf and such, but if something tricks on pf you = can mostly see that either in your logs (tcpdump pflog0, read the documentation to see the advised settings = here!) and see whether that might cause things to fail. As I can read this from your current feedback, you didn't test that yet = and it would be great if you can see whether there are issues there. If you can look into this yourself this = will help you in your later queste. Thanks! Remko p.s Remove the -net mailing list when you reply! --=20 /"\ With kind regards, | remko@elvandar.org \ / Remko Lodder | remko@FreeBSD.org X FreeBSD | = http://www.evilcoder.org / \ The Power to Serve | Quis custodiet ipsos custodes From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 20:35:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96C741065670; Mon, 10 Oct 2011 20:35:14 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 488AA8FC1C; Mon, 10 Oct 2011 20:35:14 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9AKZ54M085035; Mon, 10 Oct 2011 13:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318278906; bh=d1fdjXI6wBM8RRNN3SwuTrHZEaysLR4V3AkgUY/sdYY=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=wmx/4HJJqupYEU3A2RiQ72Eggm104oW7h2LlzqsVXJQw/6Ur1aRNmCgzkYMNMiy9N vxETHfg5MInKbbXskqpvMu6SAVuWbt8rPg8j3L7ohWXxtHuyCekO26/aUDN1va+nQO urEniRneQVN+cv0tzeYBy9WC8uVrPQjr2t3y7zpE= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20111010190609.GB1781@michelle.cdnetworks.com> References: <1317343996.2777.33.camel@hitfishpass-lx.corp.yahoo.com> <1317346748.2777.36.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 10 Oct 2011 13:35:05 -0700 Message-ID: <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 10 Oct 2011 20:35:14 -0000 On Mon, 2011-10-10 at 12:06 -0700, YongHyeon PYUN wrote: > Did you capture this message generated after disabling IPMI/DRAC in > BIOS? I thought you had to use Broadcom's separate program to > disable management firmware. > > Does the last patch solve the problem? > It's still not clear to me. The last patch allows accessing PHY > status when there is a management firmware regardless of its > running state. The latest patchset you sent me does indeed allow IPMI to function. So, awesome! I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I couldn't see any driver detection of this status. So, when I add this: > if ((ifp->if_flags & IFF_UP) == 0 && > (sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){ > printf("%s: BCE detected MFW not present\n", __func__); I don't see any change in behavior with IPMI enabled or disabled via the Dell "DRAC" ROM Menu. Sean From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 20:46:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B940D1065670; Mon, 10 Oct 2011 20:46:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E33008FC0A; Mon, 10 Oct 2011 20:46:44 +0000 (UTC) Received: by wwe3 with SMTP id 3so8965401wwe.31 for ; Mon, 10 Oct 2011 13:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=2U2L3saMGk0Nl9VjF4uQpGwwDX7NrM5j/srGcAxxZEY=; b=VJfiLcW9gaP1O2nbgKH0dE1kHef0hg/ysMchtNZDxeecPKUX92rhIO76KcQkTndiFX PDaLsV1YRWzSISR9XrFBqbuqmJrroiDVCAW4VgBVgv0azyce7yjmAdT1dI1xXv5ITnXP 4CeYCXkG6m1MTmvg236dwKcqovXP0JRngDTa8= Received: by 10.227.147.84 with SMTP id k20mr27528wbv.71.1318279603849; Mon, 10 Oct 2011 13:46:43 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id gg21sm34646946wbb.15.2011.10.10.13.46.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 13:46:42 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 10 Oct 2011 13:44:56 -0700 From: YongHyeon PYUN Date: Mon, 10 Oct 2011 13:44:56 -0700 To: Sean Bruno Message-ID: <20111010204456.GD1781@michelle.cdnetworks.com> References: <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 20:46:45 -0000 On Mon, Oct 10, 2011 at 01:35:05PM -0700, Sean Bruno wrote: > On Mon, 2011-10-10 at 12:06 -0700, YongHyeon PYUN wrote: > > Did you capture this message generated after disabling IPMI/DRAC in > > BIOS? I thought you had to use Broadcom's separate program to > > disable management firmware. > > > > Does the last patch solve the problem? > > It's still not clear to me. The last patch allows accessing PHY > > status when there is a management firmware regardless of its > > running state. > > The latest patchset you sent me does indeed allow IPMI to function. So, > awesome! > Thanks for testing! :-) > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I couldn't > see any driver detection of this status. So, when I add this: > > > if ((ifp->if_flags & IFF_UP) == 0 && > > (sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){ > > printf("%s: BCE detected MFW not present\n", __func__); > > > I don't see any change in behavior with IPMI enabled or disabled via the > Dell "DRAC" ROM Menu. > I thought you may have seen "MFW(NOT RUNNING)" if management firmware is present and you disabled IPMI in device attach time. You may have to enable bootverbose to see it. If management firmware is present and running you may have seen actual management firmware version string. > Sean > From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 21:50:09 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E511065672 for ; Mon, 10 Oct 2011 21:50:09 +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 A3A998FC0A for ; Mon, 10 Oct 2011 21:50:09 +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 p9ALo9oN030184 for ; Mon, 10 Oct 2011 21:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9ALo9UU030183; Mon, 10 Oct 2011 21:50:09 GMT (envelope-from gnats) Date: Mon, 10 Oct 2011 21:50:09 GMT Message-Id: <201110102150.p9ALo9UU030183@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159601: 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: Mon, 10 Oct 2011 21:50:09 -0000 The following reply was made to PR kern/159601; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159601: commit references a PR Date: Mon, 10 Oct 2011 21:41:43 +0000 (UTC) Author: qingli Date: Mon Oct 10 21:41:34 2011 New Revision: 226237 URL: http://svn.freebsd.org/changeset/base/226237 Log: MFC 226114 Remove the reference held on the loopback route when the interface address is being deleted. Only the last reference holder deletes the loopback route. All other delete operations just clear the IFA_RTSELF flag. PR: kern/159601 Submitted by: pluknet Reviewed by: discussed on net@ Modified: stable/8/sys/netinet/in.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/in.c ============================================================================== --- stable/8/sys/netinet/in.c Mon Oct 10 21:38:19 2011 (r226236) +++ stable/8/sys/netinet/in.c Mon Oct 10 21:41:34 2011 (r226237) @@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target, RT_LOCK(ia_ro.ro_rt); if (ia_ro.ro_rt->rt_refcnt <= 1) freeit = 1; - else + else if (flags & LLE_STATIC) { RT_REMREF(ia_ro.ro_rt); + target->ia_flags &= ~IFA_RTSELF; + } RTFREE_LOCKED(ia_ro.ro_rt); } if (freeit && (flags & LLE_STATIC)) { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 21:50:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C653B106566B for ; Mon, 10 Oct 2011 21:50:11 +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 B74468FC08 for ; Mon, 10 Oct 2011 21:50:11 +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 p9ALoBXW030201 for ; Mon, 10 Oct 2011 21:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9ALoBFO030200; Mon, 10 Oct 2011 21:50:11 GMT (envelope-from gnats) Date: Mon, 10 Oct 2011 21:50:11 GMT Message-Id: <201110102150.p9ALoBFO030200@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159602: 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: Mon, 10 Oct 2011 21:50:11 -0000 The following reply was made to PR kern/159602; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159602: commit references a PR Date: Mon, 10 Oct 2011 21:44:10 +0000 (UTC) Author: qingli Date: Mon Oct 10 21:43:53 2011 New Revision: 226238 URL: http://svn.freebsd.org/changeset/base/226238 Log: MFC 226120 Do not try removing an ARP entry associated with a given interface address if that interface does not support ARP. Otherwise the system will generate error messages unnecessarily due to the missing entry. PR: kern/159602 Submitted by: pluknet Modified: stable/8/sys/netinet/in.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/in.c ============================================================================== --- stable/8/sys/netinet/in.c Mon Oct 10 21:41:34 2011 (r226237) +++ stable/8/sys/netinet/in.c Mon Oct 10 21:43:53 2011 (r226238) @@ -1138,7 +1138,8 @@ in_scrubprefix(struct in_ifaddr *target, if (error == 0) target->ia_flags &= ~IFA_RTSELF; } - if (flags & LLE_STATIC) + if ((flags & LLE_STATIC) && + !(target->ia_ifp->if_flags & IFF_NOARP)) /* remove arp cache */ arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 10 21:50:14 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06D19106566C for ; Mon, 10 Oct 2011 21:50:14 +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 EBD018FC18 for ; Mon, 10 Oct 2011 21:50: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 p9ALoDxm030220 for ; Mon, 10 Oct 2011 21:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9ALoDJ5030219; Mon, 10 Oct 2011 21:50:13 GMT (envelope-from gnats) Date: Mon, 10 Oct 2011 21:50:13 GMT Message-Id: <201110102150.p9ALoDJ5030219@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159603: 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: Mon, 10 Oct 2011 21:50:14 -0000 The following reply was made to PR kern/159603; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159603: commit references a PR Date: Mon, 10 Oct 2011 21:46:49 +0000 (UTC) Author: qingli Date: Mon Oct 10 21:46:37 2011 New Revision: 226239 URL: http://svn.freebsd.org/changeset/base/226239 Log: MFC 225223 When an interface address route is removed from the system, another route with the same prefix is searched for as a replacement. The current code did not bypass routes that have non-operational interfaces. This patch fixes that bug and will find a replacement route with an active interface. PR: kern/159603 Submitted by: pluknet, ambrisko at ambrisko dot com Reviewed by: discussed on net@ Modified: stable/8/sys/netinet/in.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/netinet/in.c ============================================================================== --- stable/8/sys/netinet/in.c Mon Oct 10 21:43:53 2011 (r226238) +++ stable/8/sys/netinet/in.c Mon Oct 10 21:46:37 2011 (r226239) @@ -1166,7 +1166,8 @@ in_scrubprefix(struct in_ifaddr *target, p.s_addr &= ia->ia_sockmask.sin_addr.s_addr; } - if (prefix.s_addr != p.s_addr) + if ((prefix.s_addr != p.s_addr) || + !(ia->ia_ifp->if_flags & IFF_UP)) continue; /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 00:48:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B747C1065680; Tue, 11 Oct 2011 00:48:59 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 7D17D8FC1E; Tue, 11 Oct 2011 00:48:59 +0000 (UTC) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 Oct 2011 17:53:24 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 10 Oct 2011 17:45:56 -0700 From: "David Christensen" To: "pyunyh@gmail.com" , "Sean Bruno" Date: Mon, 10 Oct 2011 17:46:18 -0700 Thread-Topic: bce(4) with IPMI Thread-Index: AcyHjcJQ5RLmGrXsTeufJT8Wo+bPoAAIAoGg Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> In-Reply-To: <20111010204456.GD1781@michelle.cdnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 628D4C0E3JW3653484-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI 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, 11 Oct 2011 00:48:59 -0000 > > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I > couldn't > > see any driver detection of this status. So, when I add this: > > > > > if ((ifp->if_flags & IFF_UP) =3D=3D 0 && > > > (sc->bce_flags & BCE_MFW_PRESENT_FLAG) =3D=3D 0){ > > > printf("%s: BCE detected MFW not present\n", > __func__); > > > > > > I don't see any change in behavior with IPMI enabled or disabled via > the > > Dell "DRAC" ROM Menu. > > >=20 > I thought you may have seen "MFW(NOT RUNNING)" if management > firmware is present and you disabled IPMI in device attach time. > You may have to enable bootverbose to see it. > If management firmware is present and running you may have seen > actual management firmware version string. The Broadcom MFW is configured to load/not load through an NVRAM=20 option that is likely not affected by the iDRAC BIOS settings. To disable MFW you'd need to run the user diagnostic utility (UXDIAG.EXE) with the following command line: C:\>uxdiag -mfw 0 To turn it back on run the following: C:\>uxdiag -mfw 1 You can find a bootable CD with the user diagnostic here: http://www.broadcom.com/support/license.php?file=3DNXII/Xdiag-5.2.2.iso Dave From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 05:21:00 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E560106566B for ; Tue, 11 Oct 2011 05:21:00 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 257688FC0A for ; Tue, 11 Oct 2011 05:20:59 +0000 (UTC) Received: by ywp17 with SMTP id 17so7712745ywp.13 for ; Mon, 10 Oct 2011 22:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition; bh=Wnakft8QjAdWDu9/vDmABzNOLsbubVM4oGbjck8UZl8=; b=MbYXTNGoBUk50E+5wOqnz8HF1aWk+yRe/JWDFpsnSJ/VoNv/0zX4mHHv5O8MQyml9T 3PwlztLkogNZMN+EQ33Y+quhB2rbmFmxWoAycLUmU++UcGKFmxSuAvAPi7h1kwR0EQ1q VWDwszFcSTYwzH+Ylclcld4lCz1PobOkaHmps= Received: by 10.236.73.130 with SMTP id v2mr5741456yhd.57.1318310459379; Mon, 10 Oct 2011 22:20:59 -0700 (PDT) Received: from DataIX.net (adsl-99-181-133-235.dsl.klmzmi.sbcglobal.net. [99.181.133.235]) by mx.google.com with ESMTPS id a2sm15782696ank.3.2011.10.10.22.20.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 22:20:58 -0700 (PDT) Sender: Jason Hellenthal Received: from DataIX.net (localhost.DataIX.local [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p9B5KsfQ057776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 01:20:55 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p9B5Kq4p057771; Tue, 11 Oct 2011 01:20:52 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 11 Oct 2011 01:20:52 -0400 From: Jason Hellenthal To: Qing Li Message-ID: <20111011052052.GA56976@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline Cc: net@freebsd.org Subject: RADIX_MPATH Documentation Feedback Request X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhell@DataIX.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 05:21:00 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Qing, Just checking in as I have been reading more lately about RADIX_MPATH and have seen some commits come accross my bow to the inet and inet6 areas of the kernel mentioning it. Are these commits prerequisits to the incoming docs ? Do you have a timeframe when these might be expected ? Should a PR be filed so this can be tracked ? Thank in Advance. --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJOk9IzAAoJEJBXh4mJ2FR+VRkH/2YkLs1ufoVZUxlOZfGbmWpy gNZb5iSAdzKOztyzfrTNDHqjiiv6IHn6x6DlKjC4pEI6rrI6YfdFejfNcCyV2AgJ eDcecHtXEtJpL6/V0/U3uWlNaP6Dgyz9BfKc3wAK40c1bb33QgqYE4T47c7usJXA IEpqCoAK0Pcx46LcYuvk4HNwiuJBKlRHezkgVy25W8fqOuC2DozXsJXZBJ3fsV+k 93hycq1avbiYYMO1g2cds6buU1MFklmA/+v/9hwBQIUZquX82caF7r/a37Bwv57j otKw9O1IflgSe4HqUhXreAPc+viImDxI95ExbI6xcdnyNwJdIUaeJDjwU8HE0H0= =YRN7 -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 06:24:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B9041065675 for ; Tue, 11 Oct 2011 06:24:46 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm23-vm0.bullet.mail.bf1.yahoo.com (nm23-vm0.bullet.mail.bf1.yahoo.com [98.139.212.191]) by mx1.freebsd.org (Postfix) with SMTP id B8C888FC0A for ; Tue, 11 Oct 2011 06:24:45 +0000 (UTC) Received: from [98.139.212.148] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 11 Oct 2011 06:11:20 -0000 Received: from [98.139.211.196] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 11 Oct 2011 06:11:20 -0000 Received: from [127.0.0.1] by smtp205.mail.bf1.yahoo.com with NNFMP; 11 Oct 2011 06:11:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1318313480; bh=8LzzhW5D5MVmQv3mByKyknn0umOWMHF8X44xJuVDqmk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=UjkkJrWMJQKAvQc5/YdAKyFPRM83zhlrIC0JSsb9suXWz+qZPmTV0HjcV/34+AyLn7L1855DJtvdTWrPY7De/ttUQluKzw7TwzTv3+Z3gmmtXr5SWVltu2+1OmLZmn9tp/8dUQHpNo1qMmGKrizBGzQKZGWJP5QOpfUCFbyeRfQ= X-Yahoo-Newman-Id: 203724.55708.bm@smtp205.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: D3I7FoIVM1n.EatIKy6rhfNxT76DxlerAOdTg5ev2_szKS_ xE_S38ShneDHpC..Pgf1nE4DJtUKHyBCRyJbhY7Es5zERW1Jenwbbh7q3ndU snAYiue_7KojAzprY9BGvX45Y3is3QK7x3cPbDZLP0zw.pj9i07ETv6oEusz UYsiDQuKShRkHHxiVHpXb3vDJP50b2taJrKuA6ErDnLTq6Zf1.lUI63ASf1v 0rVjm1wahZ3cwGZIyGWWyEEWp4KcQEBmD4Snxd.OEkh1aOcOtHMmXFWn7tjs ZVGhvQIVJx7jBmw4lUas9OntW_g2Np95mMANB6VtvwyDPE.QR_tSbg6V8Uv. RIIjB6oEA0Q82pZR7Qi0VAg5oiiVIYDncHJlwMCaJ7vEHZj4nrt9TMN89P2. 3uLm286Qq3.ElxfjIJ87i X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-iy0-f182.google.com (moonlightakkiy@209.85.210.182 with plain) by smtp205.mail.bf1.yahoo.com with SMTP; 10 Oct 2011 23:11:20 -0700 PDT Received: by iaby12 with SMTP id y12so4345080iab.13 for ; Mon, 10 Oct 2011 23:11:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.50.204 with SMTP id a12mr9838850ibg.11.1318313099216; Mon, 10 Oct 2011 23:04:59 -0700 (PDT) Received: by 10.231.12.139 with HTTP; Mon, 10 Oct 2011 23:04:59 -0700 (PDT) Date: Tue, 11 Oct 2011 00:04:59 -0600 Message-ID: From: PseudoCylon To: Chuck Burns , Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Adrian Chadd , Arnaud Lacombe Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 11 Oct 2011 06:24:46 -0000 > Date: Thu, 6 Oct 2011 19:02:15 -0500 > From: Chuck Burns > Subject: Re: [urtw] Wifi link dying randomly. reboot required to > =A0 =A0 =A0 =A0reconnect. > To: Gary Palmer > Cc: freebsd-net@freebsd.org > Message-ID: <201110061902.15838.break19@gmail.com> > Content-Type: Text/Plain; =A0charset=3D"iso-8859-1" > > > options =A0 =A0 =A0 =A0 KDB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Ker= nel debugger related code > options =A0 =A0 =A0 =A0 KDB_TRACE =A0 =A0 =A0 =A0 =A0 =A0 =A0 # Print a s= tack trace for a panic > #options =A0 =A0 =A0 =A0KDB_UNATTENDED =A0 =A0 =A0 =A0 =A0# Reboot on pan= ic > options WITNESS # add me With run(4) (another usb dangle), there is a LOR between node lock and driver lock in if_raw_xmit(). Maybe, stuck on sending mgmt frames -> hang/disconnected from AP? With run(4), the LOR hasn't caused dead lock in 11abg mode, but in 11n mode, it causes dead lock every time. You run it in 11g mode, but it might be having bad hair day occasionally. Next time, rather than unplugging the device to induce a panic, wait and see if the computer will completely be locked up. AK From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 06:45:49 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95BB4106564A for ; Tue, 11 Oct 2011 06:45:49 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 57AC48FC13 for ; Tue, 11 Oct 2011 06:45:49 +0000 (UTC) Received: by ywp17 with SMTP id 17so7786641ywp.13 for ; Mon, 10 Oct 2011 23:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ECufCn/av/iuxK7sBlFND2UM823ADLLExs5AwqxLglU=; b=ZSqI53nDBkcn6EQDqNmc1dmM9uWJFiVgSNCS79WLMKPCg6Hnx5RaiWYsnbuq8nhNJY u09GPfabKJu/7DUnGwLPmpcK3XmsSpXQBX66QBQCtLmZwSzBh4futer5UROOnxzjidYC gOqSLACDGIcvZbRpWJrw2m0pgNiWvvLf8jEiQ= MIME-Version: 1.0 Received: by 10.150.236.13 with SMTP id j13mr9127795ybh.82.1318314099709; Mon, 10 Oct 2011 23:21:39 -0700 (PDT) Sender: tomelite82@gmail.com Received: by 10.151.78.21 with HTTP; Mon, 10 Oct 2011 23:21:39 -0700 (PDT) In-Reply-To: <20111011052052.GA56976@DataIX.net> References: <20111011052052.GA56976@DataIX.net> Date: Mon, 10 Oct 2011 23:21:39 -0700 X-Google-Sender-Auth: zJNSBGoTxUqc66yFUGAyRvG9P_g Message-ID: From: Qing Li To: jhell@dataix.net, qingli@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: RADIX_MPATH Documentation Feedback Request 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, 11 Oct 2011 06:45:49 -0000 I am hoping to get the documentation, along with more enhancements completed within a month. The main reason for this delay is because I am suspending RADIX_MPATH related work at the moment, and focusing on fixing IPv6 code instead. The FreeBSD IPv6 implementation in -CURRENT, stable/8 and stable/9 are all failing the IPv6-Ready logo certification tests. I have been asked to get these failures fixed as soon as possible. --Qing On Mon, Oct 10, 2011 at 10:20 PM, Jason Hellenthal wrote: > > Qing, > > Just checking in as I have been reading more lately about RADIX_MPATH > and have seen some commits come accross my bow to the inet and inet6 > areas of the kernel mentioning it. > > Are these commits prerequisits to the incoming docs ? > > Do you have a timeframe when these might be expected ? > > Should a PR be filed so this can be tracked ? > > > Thank in Advance. > From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 06:54:52 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB20106566C; Tue, 11 Oct 2011 06:54:52 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id D33908FC12; Tue, 11 Oct 2011 06:54:51 +0000 (UTC) Received: by ywp17 with SMTP id 17so7794790ywp.13 for ; Mon, 10 Oct 2011 23:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=SLkaVuSt1jX33rhv+xavDfiQqenvhWUndMCtznqQrQA=; b=hkKiHwMB08zYPv0gFojSGw1Spt5XPltUfqQgz+0MuzlwkxMQbJMs8TYY0R61THBcDU kKv75htP8c4BKU9AMp1FRdLDxGmLs7+uEG4T58vnGQD3jgjSmRxER0t3DDKbl2VyKsKS bT/GjE193qtC9K3cGmyCPD6l/cCkMmP6np+JU= Received: by 10.236.85.242 with SMTP id u78mr22002701yhe.116.1318316091372; Mon, 10 Oct 2011 23:54:51 -0700 (PDT) Received: from DataIX.net (adsl-99-181-133-235.dsl.klmzmi.sbcglobal.net. [99.181.133.235]) by mx.google.com with ESMTPS id z15sm29951285yhg.21.2011.10.10.23.54.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Oct 2011 23:54:50 -0700 (PDT) Sender: Jason Hellenthal Received: from DataIX.net (localhost.DataIX.local [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id p9B6slaj093985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 02:54:47 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id p9B6skli093976; Tue, 11 Oct 2011 02:54:46 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Tue, 11 Oct 2011 02:54:46 -0400 From: Jason Hellenthal To: Qing Li Message-ID: <20111011065446.GA93684@DataIX.net> References: <20111011052052.GA56976@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: net@freebsd.org Subject: Re: RADIX_MPATH Documentation Feedback Request 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, 11 Oct 2011 06:54:52 -0000 Makes perfect sense. Thank you for the followup and if there is anyway that I could assist on direct tasks then feel free to give me a hollar and Ill do what I can to assist. On Mon, Oct 10, 2011 at 11:21:39PM -0700, Qing Li wrote: > I am hoping to get the documentation, along with more enhancements completed > within a month. > > The main reason for this delay is because I am suspending RADIX_MPATH related > work at the moment, and focusing on fixing IPv6 code instead. > > The FreeBSD IPv6 implementation in -CURRENT, stable/8 and stable/9 are > all failing > the IPv6-Ready logo certification tests. I have been asked to get these failures > fixed as soon as possible. > > --Qing > > > On Mon, Oct 10, 2011 at 10:20 PM, Jason Hellenthal wrote: > > > > Qing, > > > > Just checking in as I have been reading more lately about RADIX_MPATH > > and have seen some commits come accross my bow to the inet and inet6 > > areas of the kernel mentioning it. > > > > Are these commits prerequisits to the incoming docs ? > > > > Do you have a timeframe when these might be expected ? > > > > Should a PR be filed so this can be tracked ? > > > > > > Thank in Advance. > > From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 06:59:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89FF5106564A for ; Tue, 11 Oct 2011 06:59:50 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F05468FC14 for ; Tue, 11 Oct 2011 06:59:49 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so11101489bkb.13 for ; Mon, 10 Oct 2011 23:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jGJwUoyyYDF+ha06/LQJv3e9VF0I1qJukd3MrNBpD3g=; b=iyff7iQNFP9S9ibAO2zXqlGB4wwWIu763Vag9QY5XCF2G51hJcorLOPo5x2LmpGox0 25ZzBQE1NBXefNMrm9w7+FyQJ1uslKo5jWCcmzaSIqXtj0BJh5DK53z72ASsOP58FYLW KMFJpti0X3VxJYpAOEpnY0bAOOP/4HTejxjfk= MIME-Version: 1.0 Received: by 10.223.58.83 with SMTP id f19mr37651547fah.36.1318316388716; Mon, 10 Oct 2011 23:59:48 -0700 (PDT) Received: by 10.152.36.102 with HTTP; Mon, 10 Oct 2011 23:59:48 -0700 (PDT) In-Reply-To: References: <4E8F157A.40702@sentex.net> <4E8F51D4.1060509@sentex.net> Date: Mon, 10 Oct 2011 23:59:48 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled 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, 11 Oct 2011 06:59:50 -0000 On Fri, Oct 7, 2011 at 2:14 PM, Jason Wolfe wrote: > Bumping rx/tx descriptors to 2048 was actually for performance reasons and > not to try to get around the issue. I did some fairly in depth testing and > found under heavy load it performed the best with those settings. > > As mentioned on the other thread I'll re enable MSI-X on a few servers here > and collect uptime and the kernel msgbuf in addition. I'll bump the > descriptors down to 512 to try and increase our chances and compile the > driver with EM_MULTIQUEUE also. > > Jason > Hi again, I flipped MSI-X on across ~15 boxes, and I did manage to pick up a fresh report over the weekend. This server in particular was doing ~1.2Gb at the time of the hang, but within a few hours on each side of the issue it pushed 1.5Gb without a hiccup. I have a multiqueue driver/kernel ready to go out, but wanted to send a report over with the driver running in 'stock' form with the extra requested data to use as a baseline. I have the script pulling out libwrap denies, so it reported in blank with nothing of value. I'll send in the action again once I see the results of multiqueue. I bounced em0 because dropped packets incremented 485695 to 486120 and the interface is not incrementing packets out. 1:10PM up 2 days, 4:10, 0 users, load averages: 0.47, 0.58, 0.63 interrupt total rate irq3: uart1 2240 0 cpu0: timer 375578618 2000 irq256: em0:rx 0 19094110 101 irq257: em0:tx 0 1118621232 5956 irq258: em0:link 1 0 irq259: em1:rx 0 1349901405 7188 irq260: em1:tx 0 1118832931 5958 irq261: em1:link 6131 0 irq262: mps0 200567934 1068 cpu2: timer 375570455 2000 cpu1: timer 375570455 2000 cpu3: timer 375570447 2000 Total 5309315959 28273 54783/18267/73050 mbufs in use (current/cache/total) 6530/3470/10000/5602642 mbuf clusters in use (current/cache/total/max) 6530/1021 mbuf+clusters out of packet secondary zone in use (current/cache) 43733/1145/44878/2801320 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 201687K/16086K/217774K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop em0 1500 00:25:90:2b:d6:e5 20018958 0 0 5955729874 0 0 486980 em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 3 - - - em1 1500 00:25:90:2b:d6:e5 5310041739 29785 0 5896740880 0 0 291131 em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 2 - - - lagg0 1500 00:25:90:2b:d6:e5 5330031157 0 0 11850884004 778111 0 0 lagg0 1500 69.164.38.0/2 69.164.38.116 4999076547 - - 11852994906 - - - lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 4 - - 5 - - - lagg0 1500 2607:f4e8:310 2607:f4e8:310:12: 5331 - - 5334 - - - kern.msgbuf: Oct 10 13:10:04 cds1066 kernel: Interface is RUNNING and INACTIVE Oct 10 13:10:04 cds1066 kernel: em0: hw tdh = 944, hw tdt = 944 Oct 10 13:10:04 cds1066 kernel: em0: hw rdh = 1805, hw rdt = 1804 Oct 10 13:10:04 cds1066 kernel: em0: Tx Queue Status = 0 Oct 10 13:10:04 cds1066 kernel: em0: TX descriptors avail = 2048 Oct 10 13:10:04 cds1066 kernel: em0: Tx Descriptors avail failure = 0 Oct 10 13:10:04 cds1066 kernel: em0: RX discarded packets = 0 Oct 10 13:10:04 cds1066 kernel: em0: RX Next to Check = 1806 Oct 10 13:10:04 cds1066 kernel: em0: RX Next to Refresh = 1805 Oct 10 13:10:04 cds1066 kernel: Interface is RUNNING and INACTIVE Oct 10 13:10:04 cds1066 kernel: em1: hw tdh = 1329, hw tdt = 1329 Oct 10 13:10:04 cds1066 kernel: em1: hw rdh = 464, hw rdt = 463 Oct 10 13:10:04 cds1066 kernel: em1: Tx Queue Status = 1 Oct 10 13:10:04 cds1066 kernel: em1: TX descriptors avail = 1807 Oct 10 13:10:04 cds1066 kernel: em1: Tx Descriptors avail failure = 0 Oct 10 13:10:04 cds1066 kernel: em1: RX discarded packets = 0 Oct 10 13:10:04 cds1066 kernel: em1: RX Next to Check = 716 Oct 10 13:10:04 cds1066 kernel: em1: RX Next to Refresh = 749 net.inet.ip.intr_queue_maxlen: 512 net.inet.ip.intr_queue_drops: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.0.%parent: pci1 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.eee_control: 0 dev.em.0.link_irq: 1 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1074790984 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 18432 dev.em.0.fc_low_water: 16932 dev.em.0.queue0.txd_head: 944 dev.em.0.queue0.txd_tail: 944 dev.em.0.queue0.tx_irq: 1118621164 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 1970 dev.em.0.queue0.rxd_tail: 1969 dev.em.0.queue0.rx_irq: 19094262 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 20025749 dev.em.0.mac_stats.good_pkts_recvd: 20025749 dev.em.0.mac_stats.bcast_pkts_recvd: 20017848 dev.em.0.mac_stats.mcast_pkts_recvd: 958 dev.em.0.mac_stats.rx_frames_64: 20017879 dev.em.0.mac_stats.rx_frames_65_127: 1430 dev.em.0.mac_stats.rx_frames_128_255: 6324 dev.em.0.mac_stats.rx_frames_256_511: 115 dev.em.0.mac_stats.rx_frames_512_1023: 1 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 1282182184 dev.em.0.mac_stats.good_octets_txd: 8285874985788 dev.em.0.mac_stats.total_pkts_txd: 5955738931 dev.em.0.mac_stats.good_pkts_txd: 5955738931 dev.em.0.mac_stats.bcast_pkts_txd: 5 dev.em.0.mac_stats.mcast_pkts_txd: 1255 dev.em.0.mac_stats.tx_frames_64: 21396178 dev.em.0.mac_stats.tx_frames_65_127: 329580959 dev.em.0.mac_stats.tx_frames_128_255: 4571211 dev.em.0.mac_stats.tx_frames_256_511: 8152970 dev.em.0.mac_stats.tx_frames_512_1023: 50636253 dev.em.0.mac_stats.tx_frames_1024_1522: 5541401360 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 3 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x15d9 subdevice=0x10d3 class=0x020000 dev.em.1.%parent: pci2 dev.em.1.nvm: -1 dev.em.1.debug: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.em.1.flow_control: 3 dev.em.1.eee_control: 0 dev.em.1.link_irq: 6115 dev.em.1.mbuf_alloc_fail: 0 dev.em.1.cluster_alloc_fail: 0 dev.em.1.dropped: 0 dev.em.1.tx_dma_fail: 0 dev.em.1.rx_overruns: 0 dev.em.1.watchdog_timeouts: 0 dev.em.1.device_control: 1074790984 dev.em.1.rx_control: 67141634 dev.em.1.fc_high_water: 18432 dev.em.1.fc_low_water: 16932 dev.em.1.queue0.txd_head: 1873 dev.em.1.queue0.txd_tail: 1873 dev.em.1.queue0.tx_irq: 1118847525 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 1703 dev.em.1.queue0.rxd_tail: 1702 dev.em.1.queue0.rx_irq: 1344597485 dev.em.1.mac_stats.excess_coll: 0 dev.em.1.mac_stats.single_coll: 0 dev.em.1.mac_stats.multiple_coll: 0 dev.em.1.mac_stats.late_coll: 0 dev.em.1.mac_stats.collision_count: 0 dev.em.1.mac_stats.symbol_errors: 0 dev.em.1.mac_stats.sequence_errors: 0 dev.em.1.mac_stats.defer_count: 0 dev.em.1.mac_stats.missed_packets: 29780 dev.em.1.mac_stats.recv_no_buff: 3183 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 5 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 5310091665 dev.em.1.mac_stats.good_pkts_recvd: 5310061880 dev.em.1.mac_stats.bcast_pkts_recvd: 20016936 dev.em.1.mac_stats.mcast_pkts_recvd: 957 dev.em.1.mac_stats.rx_frames_64: 2266338548 dev.em.1.mac_stats.rx_frames_65_127: 2435691095 dev.em.1.mac_stats.rx_frames_128_255: 3776153 dev.em.1.mac_stats.rx_frames_256_511: 8561090 dev.em.1.mac_stats.rx_frames_512_1023: 26381841 dev.em.1.mac_stats.rx_frames_1024_1522: 569313153 dev.em.1.mac_stats.good_octets_recvd: 1204804170787 dev.em.1.mac_stats.good_octets_txd: 8179280664329 dev.em.1.mac_stats.total_pkts_txd: 5896783132 dev.em.1.mac_stats.good_pkts_txd: 5896783132 dev.em.1.mac_stats.bcast_pkts_txd: 779 dev.em.1.mac_stats.mcast_pkts_txd: 9 dev.em.1.mac_stats.tx_frames_64: 22403486 dev.em.1.mac_stats.tx_frames_65_127: 354651732 dev.em.1.mac_stats.tx_frames_128_255: 4629346 dev.em.1.mac_stats.tx_frames_256_511: 8217773 dev.em.1.mac_stats.tx_frames_512_1023: 47239698 dev.em.1.mac_stats.tx_frames_1024_1522: 5459641097 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 5493 dev.em.1.interrupts.rx_pkt_timer: 0 dev.em.1.interrupts.rx_abs_timer: 0 dev.em.1.interrupts.tx_pkt_timer: 0 dev.em.1.interrupts.tx_abs_timer: 0 dev.em.1.interrupts.tx_queue_empty: 0 dev.em.1.interrupts.tx_queue_min_thresh: 0 dev.em.1.interrupts.rx_desc_min_thresh: 0 dev.em.1.interrupts.rx_overrun: 4 Jason From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 12:21:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD50106566B; Tue, 11 Oct 2011 12:21:47 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6091E8FC14; Tue, 11 Oct 2011 12:21:47 +0000 (UTC) Received: by ywp17 with SMTP id 17so8127611ywp.13 for ; Tue, 11 Oct 2011 05:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=resent-from:resent-to:resent-date:resent-message-id:from:to:subject :date:user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=wZe6HTmTjXV+whEwPyHmcslwAHCd1S/XZq97LPSsqJw=; b=sm2vFUMkH+lu/JIKACRC9Y0VI6VUjA1zmBxSGTIAQn3/vUQ7M9nyML0HYiMfmSrbkU lkai5zFfQJvi/qzbkxExvvjSULAduwREBnlhizcsOtGbFyayi+7mLU8ifwbg1CmYAw1P +liIiwEp0X/IikfbqcDo6P1Gk8XaEBlUifmO4= Received: by 10.236.177.2 with SMTP id c2mr30082924yhm.102.1318335706696; Tue, 11 Oct 2011 05:21:46 -0700 (PDT) Received: from blackbeast.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id o50sm14960044yhl.9.2011.10.11.05.21.46 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 05:21:46 -0700 (PDT) Resent-From: Chuck Burns Resent-To: freebsd-net@freebsd.org, gpalmer@freebsd.org Resent-Date: Tue, 11 Oct 2011 07:21:45 -0500 Resent-Message-ID: <201110110721.45404.break19@gmail.com> From: Chuck Burns To: PseudoCylon Date: Tue, 11 Oct 2011 07:20:04 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110110720.04292.break19@gmail.com> Cc: Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 11 Oct 2011 12:21:47 -0000 On Tuesday, October 11, 2011 1:04:59 AM you wrote: > > Date: Thu, 6 Oct 2011 19:02:15 -0500 > > From: Chuck Burns > > Subject: Re: [urtw] Wifi link dying randomly. reboot required to > > reconnect. > > To: Gary Palmer > > Cc: freebsd-net@freebsd.org > > Message-ID: <201110061902.15838.break19@gmail.com> > > Content-Type: Text/Plain; charset="iso-8859-1" > > > > > > options KDB # Kernel debugger related code > > options KDB_TRACE # Print a stack trace for a panic > > #options KDB_UNATTENDED # Reboot on panic > > options WITNESS # add me > > > With run(4) (another usb dangle), there is a LOR between node lock and > driver lock in if_raw_xmit(). Maybe, stuck on sending mgmt frames -> > hang/disconnected from AP? > > With run(4), the LOR hasn't caused dead lock in 11abg mode, but in 11n > mode, it causes dead lock every time. You run it in 11g mode, but it > might be having bad hair day occasionally. Next time, rather than > unplugging the device to induce a panic, wait and see if the computer > will completely be locked up. > > > AK I've seen it completely lock up very seldomly.. But generally, if it hasn't locked up by the time I notice the connection is dead, it won't. I've added witness to options now. Chuck From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 12:47:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74A561065672 for ; Tue, 11 Oct 2011 12:47:53 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 158378FC19 for ; Tue, 11 Oct 2011 12:47:52 +0000 (UTC) Received: by wwe3 with SMTP id 3so9939761wwe.31 for ; Tue, 11 Oct 2011 05:47:52 -0700 (PDT) Received: by 10.227.151.200 with SMTP id d8mr5504901wbw.29.1318335741066; Tue, 11 Oct 2011 05:22:21 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id o7sm38243192wbh.8.2011.10.11.05.22.19 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 05:22:19 -0700 (PDT) Message-ID: <4E9434FA.5080402@my.gd> Date: Tue, 11 Oct 2011 14:22:18 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: CARP - immediate INIT-MASTER transition when preempt enabled , bug from openbsd38 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, 11 Oct 2011 12:47:53 -0000 Hello -net, Just following up on these 2 PRs, respectively for 8.x and 9.0-BETA3: 8.x: http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 9.0b3: http://www.freebsd.org/cgi/query-pr.cgi?pr=161483 There is a bug with CARP where a CARP interface will immediately transition from INIT to MASTER if net.inet.carp.preempt=1 even if there is a faster MASTER already present on the network. This is a bug from OpenBSD 3.8 and lower's implementation of CARP, which remains in 8.2 and 9.0 to this day. >From OBSD 3.9's changelog: http://www.openbsd.org/plus39.html "In carp(4), fix a bug where lower prioritized hosts would invalidly switch to MASTER for a short time at boot-up." I have provided patches in both PRs for sys/netinet/ip_carp.c and would like to ensure this gets looked at, and makes 9.0's release. We have tested the patch in production on 8.2 and that solved our problem. Is there anything I can do to help ? From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 13:47:30 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E445A106564A for ; Tue, 11 Oct 2011 13:47:30 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id C4FB28FC1A for ; Tue, 11 Oct 2011 13:47:30 +0000 (UTC) Received: by pzk32 with SMTP id 32so39906092pzk.3 for ; Tue, 11 Oct 2011 06:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=lcfuP+XaSa8uCjkseBGWKo/T1TcMgbblp6GPnPvptJc=; b=jhFX5l26HiChA4SVK9Yvy5iLp6Q/k1u/6yxisCYkPgF3u2RVGBF+t0Lig9oiop69sk RWDLIjLn/NCDwGECmVkSepCvO5GYF9al61jGjhx6u+YiZIVvNdgQZ4/WJszb1B0Qp0bI gL3JATmcIFqs/MjyTlonBKQK3FH6MlbLbe2Y0= Received: by 10.68.0.169 with SMTP id 9mr15904981pbf.23.1318339058128; Tue, 11 Oct 2011 06:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.83.8 with HTTP; Tue, 11 Oct 2011 06:16:58 -0700 (PDT) From: dikshie Date: Tue, 11 Oct 2011 22:16:58 +0900 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: strange ipv6 on 9.0-BETA3 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, 11 Oct 2011 13:47:31 -0000 Hi, My host has two interfaces em0 and em1. Both interfaces are connected to different switches. I have been deleted all ipv6 entries in /etc/rc.conf and rebooted the host. why the ifconfig shows ipv6 address on em1 like this: --------------- em0: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:30:39:d8 inet 202.249.25.27 netmask 0xffffffe0 broadcast 202.249.25.31 inet6 fe80::230:48ff:fe30:39d8%em0 prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=209b ether 00:30:48:30:39:d9 inet6 2001:d30:101:5:230:48ff:fe30:39d9 prefixlen 64 inet6 fe80::230:48ff:fe30:39d9%em1 prefixlen 64 scopeid 0x2 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active ----------------- sysctl shows: net.inet6.ip6.accept_rtadv: 0 ----------------- how come em1 has ipv6 address? it is very strange. any idea, how to debug/fix this? Sincerely, -- -dikshie- From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 14:22:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DF60106566B for ; Tue, 11 Oct 2011 14:22:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 530BE8FC15 for ; Tue, 11 Oct 2011 14:22:07 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p9BEM1kB093424; Tue, 11 Oct 2011 10:22:01 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E945104.6020801@sentex.net> Date: Tue, 11 Oct 2011 10:21:56 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: dikshie References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: strange ipv6 on 9.0-BETA3 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, 11 Oct 2011 14:22:07 -0000 On 10/11/2011 9:16 AM, dikshie wrote: > Hi, > My host has two interfaces em0 and em1. > Both interfaces are connected to different switches. > I have been deleted all ipv6 entries in /etc/rc.conf and rebooted the host. > > why the ifconfig shows ipv6 address on em1 like this: > ----------------- > how come em1 has ipv6 address? > it is very strange. any idea, how to debug/fix this? Do you have any other routing daemons like quagga ? Perhaps at boot up time, try and put the switch port into monitor mode and see what is going back and forth, and from who ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 14:31:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40431106564A for ; Tue, 11 Oct 2011 14:31:42 +0000 (UTC) (envelope-from dikshie@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id F11E78FC08 for ; Tue, 11 Oct 2011 14:31:41 +0000 (UTC) Received: by vcbf13 with SMTP id f13so7812960vcb.13 for ; Tue, 11 Oct 2011 07:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PAD7lZ6z8GOLJuWVt1nHivCmCh8OPAXI7X4H+GNjIdo=; b=fglc2XEmPrqVQSCXCrAenc8plc6+xRR+oIEvjCEf2JBIK5yLTDyqdADNJ9ztJUiqKn mnL0XLqnt6fqcGrSS9ojCPksiZ8ew8m4U70cFcONL2/AXTnfor63PFBAanQJhB/vDa2X ss4OpB5loQTAq2YoHv1SNwNfMrE6ofBxECcCs= Received: by 10.68.22.195 with SMTP id g3mr45496519pbf.108.1318343501135; Tue, 11 Oct 2011 07:31:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.83.8 with HTTP; Tue, 11 Oct 2011 07:31:01 -0700 (PDT) In-Reply-To: <4E945104.6020801@sentex.net> References: <4E945104.6020801@sentex.net> From: dikshie Date: Tue, 11 Oct 2011 23:31:01 +0900 Message-ID: To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: strange ipv6 on 9.0-BETA3 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, 11 Oct 2011 14:31:42 -0000 On Tue, Oct 11, 2011 at 11:21 PM, Mike Tancsa wrote: > Do you have any other routing daemons like quagga ? no, i dont have any routing daemon installed in this host. > Perhaps at boot up > time, try and put the switch port into monitor mode and see what is > going back and forth, and from who i'll check the switch tomorrow. -dikshie- From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 15:26:55 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F236D106566B for ; Tue, 11 Oct 2011 15:26:55 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 8B82F8FC0C for ; Tue, 11 Oct 2011 15:26:55 +0000 (UTC) Received: (qmail 4450 invoked by uid 1000); 11 Oct 2011 15:00:14 -0000 Date: 11 Oct 2011 15:00:14 -0000 Message-ID: <20111011150014.4449.qmail@mailgate.gta.com> From: Larry Baird To: freebsd-net@freebsd.org Organization: Global Technology Associates In-Reply-To: <111911.24641.10834@localhost> User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.3-PRERELEASE (i386)) Cc: Qing Li Subject: Re: RADIX_MPATH Documentation Feedback Request 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, 11 Oct 2011 15:26:56 -0000 In article <111911.24641.10834@localhost> you wrote: > I am hoping to get the documentation, along with more enhancements completed > within a month. > > The main reason for this delay is because I am suspending RADIX_MPATH related > work at the moment, and focusing on fixing IPv6 code instead. > > The FreeBSD IPv6 implementation in -CURRENT, stable/8 and stable/9 are > all failing > the IPv6-Ready logo certification tests. I have been asked to get these failures > fixed as soon as possible. Is there any place documenting what tests are passing/failing? Thanks for the information, Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 16:12:23 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA11D106564A for ; Tue, 11 Oct 2011 16:12:23 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C6DC8FC12 for ; Tue, 11 Oct 2011 16:12:23 +0000 (UTC) Received: by qadz30 with SMTP id z30so6469762qad.13 for ; Tue, 11 Oct 2011 09:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=L93af44lFmgxBgyb5ChzPIfMxqF0kjwczYNfoRVcApQ=; b=kKY5zEgDuI/yHK4o2Q5yINN4m1QihXz+NaCjAeKlBw3jewf/M7kkgycsPmfQDhqSOE E2Q6SpCXaf7S/gR9DEaNxB65Fqj7Tw/LFkVI64/DuuIuz5IQxVEPwi636btWNMLTcBGB Xiy44QxFV5VQ7G/kbRLFDU6ZuzeBn3TynKDSA= Received: by 10.224.185.145 with SMTP id co17mr15423298qab.1.1318347647428; Tue, 11 Oct 2011 08:40:47 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id du5sm27951665qab.14.2011.10.11.08.40.45 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 08:40:46 -0700 (PDT) Message-ID: <4E94637A.5090607@gmail.com> Date: Tue, 11 Oct 2011 11:40:42 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: if_msk.c link negotiation / packet drops 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, 11 Oct 2011 16:12:23 -0000 Hi List, Using a Marvell NIC plugged into a CISCO switch I see the auto-negotiation failing and even when forcing the device to full-duplex we sometimes see packet drops. Here is the device description from dmesg: mskc0: port 0xbe00-0xbeff mem 0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:03:2d:09:94:52 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow mskc0: [ITHREAD] The switch its plugged in (Cisco) is configured for 100baseTX full-duplex. ifconfig reports: msk0: flags=608843 metric 0 mtu 1500 options=40018 ether 00:03:2d:09:94:52 inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.122.255 media: Ethernet autoselect (100baseTX ) status: active I added a bit of debugging code in e1000phy_status in the hope to understand what was going on: bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); bmcr = PHY_READ(sc, E1000_CR); ssr = PHY_READ(sc, E1000_SSR); printf("%s ssr 0x%x bmsr 0x%x bmcr 0x%x\n", __func__, ssr, bmsr, bmcr); Which consistently gives: kernel: e1000phy_status ssr 0x4d00 bmsr 0x796d bmcr 0x1000 Now and then the system will report the device is going inactive and we can see packet drops when that happens. This repeat itself once in a while without being predictable. By the way on a 7.4 system this was happening every 10 min. Using a driver from FBSD9 back ported to 7.4 we see the issue at a much lower frequency (every 30 min) but the issue is still there. Cheers, Karim. From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 17:12:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B131065670 for ; Tue, 11 Oct 2011 17:12:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id EC27F8FC14 for ; Tue, 11 Oct 2011 17:12:17 +0000 (UTC) Received: by wwe3 with SMTP id 3so10407509wwe.31 for ; Tue, 11 Oct 2011 10:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=um8uD3sl7jhTA0qfuf1P2qkuNbwNdJzFQvg+frl5jgs=; b=OKZzdWnssQycCn3T9wVrJllzb+nGaTovCyogzqzxWjtm+2FukHtn51pPYs6GNdoF5H SXNarIkSm+CREMwlukxWmhS+67IrxPwho+R4QX61hoZT5FDi4+lQyESvZ28LDksPn67m jMU6J+U0hHGYgSQHFD8dfgkPu/sgSF3U65tGA= Received: by 10.216.203.79 with SMTP id e57mr1153245weo.12.1318353136927; Tue, 11 Oct 2011 10:12:16 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p2sm39559956wbo.17.2011.10.11.10.12.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 10:12:15 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Oct 2011 10:10:29 -0700 From: YongHyeon PYUN Date: Tue, 11 Oct 2011 10:10:29 -0700 To: Karim Message-ID: <20111011171029.GA5661@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E94637A.5090607@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops 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: Tue, 11 Oct 2011 17:12:18 -0000 On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote: > Hi List, > > Using a Marvell NIC plugged into a CISCO switch I see the > auto-negotiation failing and even when forcing the device to full-duplex > we sometimes see packet drops. > > Here is the device description from dmesg: > > mskc0: port 0xbe00-0xbeff mem > 0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 > msk0: on mskc0 > msk0: Ethernet address: 00:03:2d:09:94:52 > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > mskc0: [ITHREAD] > > The switch its plugged in (Cisco) is configured for 100baseTX full-duplex. > > ifconfig reports: > > msk0: > flags=608843 > metric 0 mtu 1500 > options=40018 The flags and options show that you're using very customized driver, right? > ether 00:03:2d:09:94:52 > inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.122.255 > media: Ethernet autoselect (100baseTX ) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Resolved duplex is half so I guess it would be normal to see dropped frames which may be triggered by collision. > status: active > > I added a bit of debugging code in e1000phy_status in the hope to > understand what was going on: > > bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > bmcr = PHY_READ(sc, E1000_CR); > ssr = PHY_READ(sc, E1000_SSR); > > printf("%s ssr 0x%x bmsr 0x%x bmcr 0x%x\n", __func__, ssr, bmsr, bmcr); > > Which consistently gives: > > kernel: e1000phy_status ssr 0x4d00 bmsr 0x796d bmcr 0x1000 > This register value is consistent with media status of ifconfig output. The real question is why auto-negotiation does not work against your switch. It could be a bug in switch side and if you have to manually set full-duplex with msk(4), please make sure your switch's duplex configuration also should be manually set to full-duplex. Otherwise resolved duplex is half. > Now and then the system will report the device is going inactive and we > can see packet drops when that happens. This repeat itself once in a > while without being predictable. > Check MAC H/W statistics counter and see any collisions(dev.msk.0.stats) > By the way on a 7.4 system this was happening every 10 min. Using a > driver from FBSD9 back ported to 7.4 we see the issue at a much lower > frequency (every 30 min) but the issue is still there. > > Cheers, > > Karim. From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 17:42:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 989DE1065670 for ; Tue, 11 Oct 2011 17:42:24 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 572018FC12 for ; Tue, 11 Oct 2011 17:42:24 +0000 (UTC) Received: by ggeq3 with SMTP id q3so7450512gge.13 for ; Tue, 11 Oct 2011 10:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BDGLG1AtFVUR1/4nnTfewIDU0fitxkJdjt8W7ndY8hA=; b=qHpRlS7VY62c6lUEPjUOmRprVOV3JEqg2XlGNklIChF+YYDQxIudg2nMDIfv1WwiRE xYYbS1rfhIhoshYZk8QiZKhHDIK2Q0hiU0VZBIKfiRINROAtUE7u+F1RIs9sYCJD6q8A 0zVMGxEvcSvOcnyoL2bGCNuAf94IhN/vk62R4= MIME-Version: 1.0 Received: by 10.150.73.38 with SMTP id v38mr11250311yba.97.1318353290930; Tue, 11 Oct 2011 10:14:50 -0700 (PDT) Sender: tomelite82@gmail.com Received: by 10.151.78.21 with HTTP; Tue, 11 Oct 2011 10:14:50 -0700 (PDT) In-Reply-To: <20111011150014.4449.qmail@mailgate.gta.com> References: <111911.24641.10834@localhost> <20111011150014.4449.qmail@mailgate.gta.com> Date: Tue, 11 Oct 2011 10:14:50 -0700 X-Google-Sender-Auth: 08oErPqJ2LCtdH9khjTnF_YiGME Message-ID: From: Qing Li To: Larry Baird Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: RADIX_MPATH Documentation Feedback Request 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, 11 Oct 2011 17:42:24 -0000 The failures are seen in basic Neighbor Discovery and Address Selection. The tests are not posted any where, but I can forward the report to you private once veri= fied. --Qing On Tue, Oct 11, 2011 at 8:00 AM, Larry Baird wrote: > In article <111911.24641.10834@localhost> you wrote: >> I am hoping to get the documentation, along with more enhancements compl= eted >> within a month. >> >> The main reason for this delay is because I am suspending RADIX_MPATH re= lated >> work at the moment, and focusing on fixing IPv6 code instead. >> >> The FreeBSD IPv6 implementation in -CURRENT, stable/8 and stable/9 are >> all failing >> the IPv6-Ready logo certification tests. I have been asked to get these = failures >> fixed as soon as possible. > Is there any place documenting what tests are passing/failing? > > Thanks for the information, > Larry > > -- > ------------------------------------------------------------------------ > Larry Baird =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| http://www.g= ta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | TEL 407-380-0220, FA= X 407-380-6080 > From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 17:56:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6AA51065679 for ; Tue, 11 Oct 2011 17:56:59 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 839298FC12 for ; Tue, 11 Oct 2011 17:56:59 +0000 (UTC) Received: by iaby12 with SMTP id y12so5295785iab.13 for ; Tue, 11 Oct 2011 10:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rw34+XnUM3FbjkDaXv5wE2LI/+lhlmfu0tsCGVpB9cI=; b=plvq/sNBooOOstd2c+a1teYrGsqgreIdXg50TMKLlCiCsc6Jw1G/i6VetmZyl78m2G EMzx3Gt5ZxMy/qrc8HW4oMlwIycsCThirkc2pIU8Vlym0XduX68cyJ6LAtzT9Gc7gC8L LCSPM7d/I0OAD9xYQVeQLoiQ1pD3bYqyJ+csg= MIME-Version: 1.0 Received: by 10.231.67.80 with SMTP id q16mr10579656ibi.86.1318354287507; Tue, 11 Oct 2011 10:31:27 -0700 (PDT) Received: by 10.231.36.69 with HTTP; Tue, 11 Oct 2011 10:31:27 -0700 (PDT) In-Reply-To: <20111011171029.GA5661@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> Date: Tue, 11 Oct 2011 10:31:27 -0700 Message-ID: From: Kevin Oberman To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Karim , freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops 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, 11 Oct 2011 17:56:59 -0000 On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote: > On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote: >> Hi List, >> >> Using a Marvell NIC plugged into a CISCO switch I see the >> auto-negotiation failing and even when forcing the device to full-duplex >> we sometimes see packet drops. >> >> Here is the device description from dmesg: >> >> mskc0: port 0xbe00-0xbeff mem >> 0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 >> msk0: on mskc0 >> msk0: Ethernet address: 00:03:2d:09:94:52 >> miibus0: on msk0 >> e1000phy0: PHY 0 on miibus0 >> e1000phy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> mskc0: [ITHREAD] >> >> The switch its plugged in (Cisco) is configured for 100baseTX full-duple= x. >> >> ifconfig reports: >> >> msk0: >> flags=3D608843 >> metric 0 mtu 1500 >> =A0 =A0 =A0 =A0 options=3D40018 > > The flags and options show that you're using very customized > driver, right? > >> =A0 =A0 =A0 =A0 ether 00:03:2d:09:94:52 >> =A0 =A0 =A0 =A0 inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.= 122.255 >> =A0 =A0 =A0 =A0 media: Ethernet autoselect (100baseTX ) > =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Resolved duplex is half so I guess it would be normal to see > dropped frames which may be triggered by collision. You have a duplex mis-match. If you are hard setting the remote end to full, the local end must also be configured o full. Auto-configuration of duplex requires that both ends run auto-config. When one end is set to not do auto-config, the other end SHOULD always set to half-duplex. This is part of 802.3 that is a carry-over from the days when hubs and coax dominated, so the default was declared to be half. Since so much hardware now exists with that default, changing it ill never happen. Either set your computer to full duplex or turn on auto-configuration on the Cisco. Very little hardware now in service fails to auto-config correctly, but the practice of lacking down the duplex setting became common in the early days of full-duplex when it was not yet a standard and many Ethernet chip-sets didn't play nice with others. Things would be much better if people would just stop hard-setting the duplex, but old, old habits and memes die hard. Also, contrary to common belief, collisions are NOT errors. They are a normal part of half-dulpex Ethernet operation and do NOT result in packets being dropped. Only "excessive collisions do and they ARE a real error and a clear indication that something is wrong. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 17:57:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8961106566B; Tue, 11 Oct 2011 17:57:10 +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 AFB6E8FC17; Tue, 11 Oct 2011 17:57:10 +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 p9BHvAcQ082571; Tue, 11 Oct 2011 17:57:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9BHvAOK082567; Tue, 11 Oct 2011 17:57:10 GMT (envelope-from linimon) Date: Tue, 11 Oct 2011 17:57:10 GMT Message-Id: <201110111757.p9BHvAOK082567@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161483: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew 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, 11 Oct 2011 17:57:10 -0000 Old Synopsis: net / [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew New Synopsis: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 11 17:56:56 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=161483 From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 18:00:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E83B106566B; Tue, 11 Oct 2011 18:00:47 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 13F658FC08; Tue, 11 Oct 2011 18:00:46 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9BI0V03093653; Tue, 11 Oct 2011 11:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318356031; bh=NTfJMltgNC91YFEJoZJlVv9UYVBBxm4n31Z+QB96nHg=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=I0cmnX02pdAex1xuKzCC51DXCmtVpXoTCW2TosE0nHmuVpb7aE0Wkm6Ng5nVSfqj/ FQY4N9ahIQPe3JhVGXykgA/uV912mk/x2uwR9lKeNB+BO8Kx3T+gyQr//JTQubexFn hOkJz3LN5yS9mUriKGlpOgpmqHzv4d3K4XYx/CTk= From: Sean Bruno To: David Christensen In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> References: <5D267A3F22FD854F8F48B3D2B523819385F35B4738@IRVEXCHCCR01.corp.ad.broadcom.com> <1317683178.15510.25.camel@hitfishpass-lx.corp.yahoo.com> <20111007191154.GB11808@michelle.cdnetworks.com> <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 Oct 2011 11:00:30 -0700 Message-ID: <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI 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, 11 Oct 2011 18:00:47 -0000 On Mon, 2011-10-10 at 17:46 -0700, David Christensen wrote: > > > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I > > couldn't > > > see any driver detection of this status. So, when I add this: > > > > > > > if ((ifp->if_flags & IFF_UP) == 0 && > > > > (sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){ > > > > printf("%s: BCE detected MFW not present\n", > > __func__); > > > > > > > > > I don't see any change in behavior with IPMI enabled or disabled via > > the > > > Dell "DRAC" ROM Menu. > > > > > > > I thought you may have seen "MFW(NOT RUNNING)" if management > > firmware is present and you disabled IPMI in device attach time. > > You may have to enable bootverbose to see it. > > If management firmware is present and running you may have seen > > actual management firmware version string. > > The Broadcom MFW is configured to load/not load through an NVRAM > option that is likely not affected by the iDRAC BIOS settings. > To disable MFW you'd need to run the user diagnostic utility > (UXDIAG.EXE) with the following command line: > > C:\>uxdiag -mfw 0 > > To turn it back on run the following: > > C:\>uxdiag -mfw 1 > > You can find a bootable CD with the user diagnostic here: > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso > > Dave > Ah, ok. Pyun: Should I do this on a host and validate your changes? Sean From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 18:14:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95F1106566C; Tue, 11 Oct 2011 18:14:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 28AC98FC13; Tue, 11 Oct 2011 18:14:07 +0000 (UTC) Received: by wwn22 with SMTP id 22so5568805wwn.1 for ; Tue, 11 Oct 2011 11:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=dqdyBGDfmK267wrrxAIALzcqekDwQmz/AnVO+9ZkPG8=; b=vqX1VQyv89UDk+tyyTV7kjXksCSdu9S9ypDnW3gBm8annyp4EAenvG3dCFUXKcPUBq aTby3C5QRiFkd4cHfVzITe9JriUPhocP1gu8lI5iy1ci0y5G7oBpjb7cYjs7K2PcVols K2Koi+aw3gDBhnHV5oh2NTqB8QcwPEfFSXxCw= Received: by 10.227.28.96 with SMTP id l32mr8136969wbc.50.1318356846859; Tue, 11 Oct 2011 11:14:06 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id ek13sm1249755wbb.3.2011.10.11.11.14.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 11:14:05 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Oct 2011 11:12:19 -0700 From: YongHyeon PYUN Date: Tue, 11 Oct 2011 11:12:19 -0700 To: Sean Bruno Message-ID: <20111011181219.GB5661@michelle.cdnetworks.com> References: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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: Tue, 11 Oct 2011 18:14:09 -0000 On Tue, Oct 11, 2011 at 11:00:30AM -0700, Sean Bruno wrote: > On Mon, 2011-10-10 at 17:46 -0700, David Christensen wrote: > > > > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I > > > couldn't > > > > see any driver detection of this status. So, when I add this: > > > > > > > > > if ((ifp->if_flags & IFF_UP) == 0 && > > > > > (sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){ > > > > > printf("%s: BCE detected MFW not present\n", > > > __func__); > > > > > > > > > > > > I don't see any change in behavior with IPMI enabled or disabled via > > > the > > > > Dell "DRAC" ROM Menu. > > > > > > > > > > I thought you may have seen "MFW(NOT RUNNING)" if management > > > firmware is present and you disabled IPMI in device attach time. > > > You may have to enable bootverbose to see it. > > > If management firmware is present and running you may have seen > > > actual management firmware version string. > > > > The Broadcom MFW is configured to load/not load through an NVRAM > > option that is likely not affected by the iDRAC BIOS settings. > > To disable MFW you'd need to run the user diagnostic utility > > (UXDIAG.EXE) with the following command line: > > > > C:\>uxdiag -mfw 0 > > > > To turn it back on run the following: > > > > C:\>uxdiag -mfw 1 > > > > You can find a bootable CD with the user diagnostic here: > > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso > > > > Dave > > > > Ah, ok. > > > Pyun: > > Should I do this on a host and validate your changes? > That would be great if you can. Because some part of code is not executed in my patch when firmware is not running. Previously bce(4) executed that code regardless of firmware running state. > Sean > > From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 19:52:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965A7106566C; Tue, 11 Oct 2011 19:52:37 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 47EBE8FC14; Tue, 11 Oct 2011 19:52:36 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9BJqQA2022839; Tue, 11 Oct 2011 12:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318362746; bh=92ExSYmk5qeid/sjUj6rgh6GUZKycVqGMikLUfE/LzI=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=GL6sJQTx7zB8nesY5MflZ0c7KOuTk3uZQHwgtokeUNTAlUemZib2gZHAy7kmtM4D9 pbWsWYex85EjrCN4ITCeNq3eRCZvyJzypJQbXJO+0+qkFEt5X2wssL/894y+i39hQh /CR01urMWTThhXRSMQscZEEUc4rPqR3lT1ZVC5cw= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20111011181219.GB5661@michelle.cdnetworks.com> References: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 Oct 2011 12:52:25 -0700 Message-ID: <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 11 Oct 2011 19:52:37 -0000 > > > The Broadcom MFW is configured to load/not load through an NVRAM > > > option that is likely not affected by the iDRAC BIOS settings. > > > To disable MFW you'd need to run the user diagnostic utility > > > (UXDIAG.EXE) with the following command line: > > > > > > C:\>uxdiag -mfw 0 > > > > > > To turn it back on run the following: > > > > > > C:\>uxdiag -mfw 1 > > > > > > You can find a bootable CD with the user diagnostic here: > > > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso > > > > > > Dave > > > > > > > Ah, ok. > > > > > > Pyun: > > > > Should I do this on a host and validate your changes? > > > > That would be great if you can. Because some part of code is not > executed in my patch when firmware is not running. Previously > bce(4) executed that code regardless of firmware running state. > > > Sean > > > > Ran this on my Dell R410. I can clearly see that the tool is "disabling" the MFW bit, and that the dell bios interface to the IPMI controller/DRAC is impaired, however ... The system still thinks that the MFW bit is "ON" and proceeds normally in this case. The code still fails to detect that MFW is disabled. In addition, the IPMI driver attaches to "something" and I can poke at it via ipmitool. So, from the driver perspective, the attempt to detect MFW enabled doesn't work as the chipset still thinks that its "on". I've commented out the code block that we're trying to work around in the yahoo code base for now. Sean From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 21:23:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D06B8106564A for ; Tue, 11 Oct 2011 21:23:19 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5283C8FC15 for ; Tue, 11 Oct 2011 21:23:18 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9BLNIrW033344; Tue, 11 Oct 2011 23:23:18 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9BLNIF6033343; Tue, 11 Oct 2011 23:23:18 +0200 (CEST) (envelope-from marius) Date: Tue, 11 Oct 2011 23:23:18 +0200 From: Marius Strobl To: YongHyeon PYUN Message-ID: <20111011212318.GC81376@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111010192238.GC1781@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII 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, 11 Oct 2011 21:23:19 -0000 On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > Hi, > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > gpio-bitbang mii that I can refer to? Thanks. > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > and it's useful for porting embedded devices. > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > which (im)ports these and converts drivers to take advantage of it here: > > http://people.freebsd.org/~marius/mii_bitbang.diff > > Patch looks good to me. > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > and xe(4))? > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally I've started with the drivers were the corresponding NetBSD one also uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm aware that these should also be convertible to the common code, I just didn't get around to it so far. As for lge(4) that driver has some remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've previously missed rl(4) as I was only grepping beneath sys/dev and I currently can't explain why I missed xe(4), so thanks for mentioning these. In my experience MII bitbang'ing is very fragile though and subtle changes may break it so I don't want to commit these without testing or in the case of smc(4) where at least the corresponding NetBSD driver already uses the common code. Unfortunately, I only have hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you happen to have hardware to test the remaining drivers, i.e. nge(4), sis(4), ste(4), wb(4) and xe(4)? Marius From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 22:51:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E272106564A; Tue, 11 Oct 2011 22:51:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 61A738FC08; Tue, 11 Oct 2011 22:51:24 +0000 (UTC) Received: by wwe3 with SMTP id 3so126935wwe.31 for ; Tue, 11 Oct 2011 15:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3gdZtiuUzw4LMhUxivperYXApxgW/5yhzz3npcC1wns=; b=DP0ygX1nqrMypLVxwn4/K4IhxKcuisVdyEtIJlSKMNP8cbbCmwcle+OTf4cWmdLFr/ 9CXSarYjjjazIo2amjk3mTMSOQXdQmskMOJ2QviPexgeOABhz7PLa855EOQfhjAkzuNv +qm3LfXAZ3bIDmGI7SkD6tLUhmK1oXJo3IZXs= Received: by 10.216.133.160 with SMTP id q32mr1447983wei.108.1318373482995; Tue, 11 Oct 2011 15:51:22 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id j18sm244052wbo.6.2011.10.11.15.51.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 15:51:21 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Oct 2011 15:49:35 -0700 From: YongHyeon PYUN Date: Tue, 11 Oct 2011 15:49:35 -0700 To: Sean Bruno Message-ID: <20111011224935.GC5661@michelle.cdnetworks.com> References: <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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: Tue, 11 Oct 2011 22:51:26 -0000 On Tue, Oct 11, 2011 at 12:52:25PM -0700, Sean Bruno wrote: > > > > > The Broadcom MFW is configured to load/not load through an NVRAM > > > > option that is likely not affected by the iDRAC BIOS settings. > > > > To disable MFW you'd need to run the user diagnostic utility > > > > (UXDIAG.EXE) with the following command line: > > > > > > > > C:\>uxdiag -mfw 0 > > > > > > > > To turn it back on run the following: > > > > > > > > C:\>uxdiag -mfw 1 > > > > > > > > You can find a bootable CD with the user diagnostic here: > > > > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso > > > > > > > > Dave > > > > > > > > > > Ah, ok. > > > > > > > > > Pyun: > > > > > > Should I do this on a host and validate your changes? > > > > > > > That would be great if you can. Because some part of code is not > > executed in my patch when firmware is not running. Previously > > bce(4) executed that code regardless of firmware running state. > > > > > Sean > > > > > > > > > Ran this on my Dell R410. I can clearly see that the tool is > "disabling" the MFW bit, and that the dell bios interface to the IPMI > controller/DRAC is impaired, however ... > > The system still thinks that the MFW bit is "ON" and proceeds normally > in this case. The code still fails to detect that MFW is disabled. > > In addition, the IPMI driver attaches to "something" and I can poke at > it via ipmitool. So, from the driver perspective, the attempt to detect > MFW enabled doesn't work as the chipset still thinks that its "on". > My patch relied on existing bce(4)'s logic for management firmware state since public data sheet does not mention anything about that. Probably David can give us more information. > I've commented out the code block that we're trying to work around in > the yahoo code base for now. > > Sean > From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 22:57:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904F8106566B for ; Tue, 11 Oct 2011 22:57:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 21FCC8FC0A for ; Tue, 11 Oct 2011 22:57:18 +0000 (UTC) Received: by wyj26 with SMTP id 26so157388wyj.13 for ; Tue, 11 Oct 2011 15:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Uy0MoJIT9OdCKOoxLxflN5LrJ8rFgRppu1tVjtYYkIQ=; b=U0pEv0g9ztnfkBrJSUrWurO0sFfBidcMAf5BJ56P3ermSGtpyjp/4z9BvIYqP0DEzL UYguIpkOwOLyJVrrQYWl3vMgoJLZeHCA5y/0PnotfRHGqfIlz0xm/jgOlWjY11PFqdGV 3kXzwNcj6WeIG5YxDYMx3yNKKy72rfn7xXmy4= Received: by 10.216.14.206 with SMTP id d56mr1688627wed.33.1318373837894; Tue, 11 Oct 2011 15:57:17 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id gd6sm281790wbb.1.2011.10.11.15.57.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 15:57:16 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Oct 2011 15:55:31 -0700 From: YongHyeon PYUN Date: Tue, 11 Oct 2011 15:55:31 -0700 To: Marius Strobl Message-ID: <20111011225531.GD5661@michelle.cdnetworks.com> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111011212318.GC81376@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII 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: Tue, 11 Oct 2011 22:57:19 -0000 On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > Hi, > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > and it's useful for porting embedded devices. > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > which (im)ports these and converts drivers to take advantage of it here: > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > Patch looks good to me. > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > and xe(4))? > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > I've started with the drivers were the corresponding NetBSD one also > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > aware that these should also be convertible to the common code, I just > didn't get around to it so far. As for lge(4) that driver has some > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've Ah, I just blindly grepped the string, sorry. > previously missed rl(4) as I was only grepping beneath sys/dev and I > currently can't explain why I missed xe(4), so thanks for mentioning > these. > In my experience MII bitbang'ing is very fragile though and subtle > changes may break it so I don't want to commit these without testing > or in the case of smc(4) where at least the corresponding NetBSD > driver already uses the common code. Unfortunately, I only have > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > happen to have hardware to test the remaining drivers, i.e. nge(4), > sis(4), ste(4), wb(4) and xe(4)? > I have access to sis(4) and ste(4). I also have a nge(4) but I'm not able to access to the hardware, at least in US. > Marius > From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 01:07:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D1301065676; Wed, 12 Oct 2011 01:07:40 +0000 (UTC) (envelope-from chuck@thesouthernlibertarian.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 CAD728FC0C; Wed, 12 Oct 2011 01:07:39 +0000 (UTC) Received: by gyf2 with SMTP id 2so218378gyf.13 for ; Tue, 11 Oct 2011 18:07:38 -0700 (PDT) Received: by 10.101.27.21 with SMTP id e21mr402064anj.0.1318381658410; Tue, 11 Oct 2011 18:07:38 -0700 (PDT) Received: from blackbeast.localnet (c-98-230-65-110.hsd1.al.comcast.net. [98.230.65.110]) by mx.google.com with ESMTPS id v20sm1200381anv.17.2011.10.11.18.07.35 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 18:07:36 -0700 (PDT) From: Chuck Burns Organization: The Southern Libertarian To: Arnaud Lacombe Date: Tue, 11 Oct 2011 20:07:30 -0500 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.6.5; amd64; ; ) References: <201110042008.48915.break19@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110112007.31025.chuck@thesouthernlibertarian.com> Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 12 Oct 2011 01:07:40 -0000 On Sunday, October 09, 2011 12:38:11 AM Chuck Burns wrote: > www.thesouthernlibertarian.com/kernel-urtw.tar.gz > > This has 4 files: > /boot/kernel/kernel[.symbols] > /boot/kernel/if_urtw.ko[.symbols] > > Thanks > Arnaud, Just following up to see if you grabbed the files yet, so I can remove them from the web host. Thanks, Chuck From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 01:53:36 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5944C106566C; Wed, 12 Oct 2011 01:53:36 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD8AA8FC1C; Wed, 12 Oct 2011 01:53:35 +0000 (UTC) Received: by vws11 with SMTP id 11so234821vws.13 for ; Tue, 11 Oct 2011 18:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X7b9vV9zOx7fBHScqHlmx9uQUS+zW5AXkt0rmI7QaMg=; b=WtW8G2hSZ4Sy1JcOy3iIjLBhtQFkSzmFI2OwBLE9y29tHVmD1VJDRz88F5ilIpPAhK IgMUhEsMdJ3z7AQasUueNajuUGsCiayjzcAV1wnXsfAqqjRnISz3uE/UKDIvuGQpdimO rcNZw+dVb0qKv13lmBznmbURXnAvPZztyoWWM= MIME-Version: 1.0 Received: by 10.52.26.81 with SMTP id j17mr21111321vdg.101.1318384414714; Tue, 11 Oct 2011 18:53:34 -0700 (PDT) Received: by 10.52.186.170 with HTTP; Tue, 11 Oct 2011 18:53:34 -0700 (PDT) In-Reply-To: References: <8662kcigif.fsf@kopusha.home.net> <86y5x0ooik.fsf@in138.ua3> Date: Wed, 12 Oct 2011 09:53:34 +0800 Message-ID: From: dave jones To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Robert Watson , "K. Macy" , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 12 Oct 2011 01:53:36 -0000 On Fri, Oct 7, 2011 at 9:12 AM, dave jones wrote: > 2011/10/4 Mikolaj Golub : >> >> On Sat, 1 Oct 2011 14:15:45 +0800 dave jones wrote: >> >> =A0dj> On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: >> =A0>> >> =A0>> On Wed, 28 Sep 2011, Mikolaj Golub wrote: >> =A0>> >> =A0>>> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: >> =A0>>> >> =A0>>> KM> Sorry, didn't look at the images (limited bw), I've seen some= thing KM> >> =A0>>> like this before in timewait. This "can't happen" with UDP so wil= l be KM> >> =A0>>> interested in learning more about the bug. >> =A0>>> >> =A0>>> The panic can be easily triggered by this: >> =A0>> >> =A0>> Hi: >> =A0>> >> =A0>> Just catching up on this thread. =A0I think the analysis here is g= enerally >> =A0>> right: in 9.0, you're much more likely to see an inpcb with its in= _socket >> =A0>> pointer cleared in the hash list than in prior releases, and >> =A0>> in_pcbbind_setup() trips over this. >> =A0>> >> =A0>> However, at least on first glance (and from the perspective of inv= ariants >> =A0>> here), I think the bug is actualy that in_pcbbind_setup() is askin= g >> =A0>> in_pcblookup_local() for an inpcb and then access the returned inp= cb's >> =A0>> in_socket pointer without acquiring a lock on the inpcb. =A0Struct= urally, it >> =A0>> can't acquire this lock for lock order reasons -- it already holds= the lock >> =A0>> on its own inpcb. =A0Therefore, we should only access fields that = are safe to >> =A0>> follow in an inpcb when you hold a reference via the hash lock and= not a >> =A0>> lock on the inpcb itself, which appears generally OK (+/-) for all= the >> =A0>> fields in that clause but the t->inp_socket->so_options dereferenc= e. >> =A0>> >> =A0>> A preferred fix would cache the SO_REUSEPORT flag in an inpcb-laye= r field, >> =A0>> such as inp_flags2, giving us access to its value without having t= o walk >> =A0>> into the attached (or not) socket. >> =A0>> >> =A0>> This raises another structural question, which is whether we need = a new >> =A0>> inp_foo flags field that is protected explicitly by the hash lock,= and not >> =A0>> by the inpcb lock, which could hold fields relevant to address bin= ding. =A0I >> =A0>> don't think we need to solve that problem in this context, as a sl= ightly >> =A0>> race on SO_REUSEPORT is likely acceptable. >> =A0>> >> =A0>> The suggested fix does perform the desired function of explicitly = detaching >> =A0>> the inpcb from the hash list before the socket is disconnected fro= m the >> =A0>> inpcb. However, it's incomplete in that the invariant that's being= broken is >> =A0>> also relied on for other protocols (such as raw sockets). =A0The c= orrect >> =A0>> invariant is that inp_socket is safe to follow unconditionally if = an inpcb >> =A0>> is locked and INP_DROPPED isn't set -- the bug is in "locked" not = in >> =A0>> "INP_DROPPED", which is why I think this is the wrong fix, even th= ough it >> =A0>> prevents a panic :-). >> >> =A0dj> Hello Robert, >> >> =A0dj> Thank you for taking your valuable time to find out the problem. >> =A0dj> Since I don't have idea about network internals, would you have a= patch >> =A0dj> about this? I'd be glad to test it, thanks again. >> >> Here is the patch that implements what Robert suggests. >> >> Dave, could you test it? > > Sure. Thanks for cooking the patch. > Machines have been running two days now without panic. Is there any plan to commit your fix? Thank you. I'd upgrade to 9.0-release from beta-2 once it's released. Best regards, Dave. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 06:11:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0511E1065670; Wed, 12 Oct 2011 06:11:13 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C0C978FC08; Wed, 12 Oct 2011 06:11:11 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so588564bkb.13 for ; Tue, 11 Oct 2011 23:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=Y1mz6a82WfybLwbKDsiSx0szRFFqlGSsQ6+NiPC7Q0c=; b=vieCtmasGGnY9251o5LxyaXqwCtTCD4OZwFsVstK/xCA52lONs3BQmVbpDqFxYl36T 3l6y5FDlARXRZukgaJVD3ym+Q+m3wMiQ+AUlEHBNAPesgTdsiK2474AX4LAJmu1I3HOU 5fpjXK/f8ILO2QHpOmHqJU0EHRS6NQyEbqAoA= Received: by 10.223.1.131 with SMTP id 3mr46054643faf.30.1318399870687; Tue, 11 Oct 2011 23:11:10 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id y8sm1937871faj.10.2011.10.11.23.11.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 23:11:09 -0700 (PDT) From: Mikolaj Golub To: dave jones Organization: TOA Ukraine References: <8662kcigif.fsf@kopusha.home.net> <86y5x0ooik.fsf@in138.ua3> Sender: Mikolaj Golub Date: Wed, 12 Oct 2011 09:11:05 +0300 In-Reply-To: (dave jones's message of "Wed, 12 Oct 2011 09:53:34 +0800") Message-ID: <86fwiy91ty.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: Adrian Chadd , "K. Macy" , "freebsd-net@freebsd.org" , bz@freebsd.org, Robert Watson , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 12 Oct 2011 06:11:13 -0000 --=-=-= Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit On Wed, 12 Oct 2011 09:53:34 +0800 dave jones wrote: dj> On Fri, Oct 7, 2011 at 9:12 AM, dave jones wrote: >> 2011/10/4 Mikolaj Golub : >>> >>> On Sat, 1 Oct 2011 14:15:45 +0800 dave jones wrote: >>> >>> šdj> On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: >>> š>> >>> š>> On Wed, 28 Sep 2011, Mikolaj Golub wrote: >>> š>> >>> š>>> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: >>> š>>> >>> š>>> KM> Sorry, didn't look at the images (limited bw), I've seen something KM> >>> š>>> like this before in timewait. This "can't happen" with UDP so will be KM> >>> š>>> interested in learning more about the bug. >>> š>>> >>> š>>> The panic can be easily triggered by this: >>> š>> >>> š>> Hi: >>> š>> >>> š>> Just catching up on this thread. šI think the analysis here is generally >>> š>> right: in 9.0, you're much more likely to see an inpcb with its in_socket >>> š>> pointer cleared in the hash list than in prior releases, and >>> š>> in_pcbbind_setup() trips over this. >>> š>> >>> š>> However, at least on first glance (and from the perspective of invariants >>> š>> here), I think the bug is actualy that in_pcbbind_setup() is asking >>> š>> in_pcblookup_local() for an inpcb and then access the returned inpcb's >>> š>> in_socket pointer without acquiring a lock on the inpcb. šStructurally, it >>> š>> can't acquire this lock for lock order reasons -- it already holds the lock >>> š>> on its own inpcb. šTherefore, we should only access fields that are safe to >>> š>> follow in an inpcb when you hold a reference via the hash lock and not a >>> š>> lock on the inpcb itself, which appears generally OK (+/-) for all the >>> š>> fields in that clause but the t->inp_socket->so_options dereference. >>> š>> >>> š>> A preferred fix would cache the SO_REUSEPORT flag in an inpcb-layer field, >>> š>> such as inp_flags2, giving us access to its value without having to walk >>> š>> into the attached (or not) socket. >>> š>> >>> š>> This raises another structural question, which is whether we need a new >>> š>> inp_foo flags field that is protected explicitly by the hash lock, and not >>> š>> by the inpcb lock, which could hold fields relevant to address binding. šI >>> š>> don't think we need to solve that problem in this context, as a slightly >>> š>> race on SO_REUSEPORT is likely acceptable. >>> š>> >>> š>> The suggested fix does perform the desired function of explicitly detaching >>> š>> the inpcb from the hash list before the socket is disconnected from the >>> š>> inpcb. However, it's incomplete in that the invariant that's being broken is >>> š>> also relied on for other protocols (such as raw sockets). šThe correct >>> š>> invariant is that inp_socket is safe to follow unconditionally if an inpcb >>> š>> is locked and INP_DROPPED isn't set -- the bug is in "locked" not in >>> š>> "INP_DROPPED", which is why I think this is the wrong fix, even though it >>> š>> prevents a panic :-). >>> >>> šdj> Hello Robert, >>> >>> šdj> Thank you for taking your valuable time to find out the problem. >>> šdj> Since I don't have idea about network internals, would you have a patch >>> šdj> about this? I'd be glad to test it, thanks again. >>> >>> Here is the patch that implements what Robert suggests. >>> >>> Dave, could you test it? >> >> Sure. Thanks for cooking the patch. >> Machines have been running two days now without panic. Thank you for testing it. dj> Is there any plan to commit your fix? Thank you. dj> I'd upgrade to 9.0-release from beta-2 once it's released. I have an upgraded version of the patch, which is under review now. I have been waiting for the response before asking you to test it, but it would be great if you try it not waiting :-). As it was pointed by Robert the previous version introduced a regression: SO_REUSEPORT was ignored if setsockopt was called after bind (the old cached value was still used). So the updated version fixes this and also contains several other fixes, the most important among them is that it fixes the panic for IPv6 bind case too. -- Mikolaj Golub --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=INP_REUSEPORT.patch Index: sys/netinet/in_pcb.c =================================================================== --- sys/netinet/in_pcb.c (revision 226165) +++ sys/netinet/in_pcb.c (working copy) @@ -575,8 +575,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockadd ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || - (t->inp_socket->so_options & - SO_REUSEPORT) == 0) && + (t->inp_flags2 & INP_REUSEPORT) == 0) && (inp->inp_cred->cr_uid != t->inp_cred->cr_uid)) return (EADDRINUSE); @@ -590,19 +589,19 @@ in_pcbbind_setup(struct inpcb *inp, struct sockadd * being in use (for now). This is better * than a panic, but not desirable. */ - tw = intotw(inp); + tw = intotw(t); if (tw == NULL || (reuseport & tw->tw_so_options) == 0) return (EADDRINUSE); - } else if (t && - (reuseport & t->inp_socket->so_options) == 0) { + } else if (t && (reuseport == 0 || + (t->inp_flags2 & INP_REUSEPORT) == 0)) { #ifdef INET6 if (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || ntohl(t->inp_laddr.s_addr) != INADDR_ANY || - INP_SOCKAF(so) == - INP_SOCKAF(t->inp_socket)) + (inp->inp_vflag & INP_IPV6PROTO) == 0 || + (t->inp_vflag & INP_IPV6PROTO) == 0) #endif return (EADDRINUSE); } Index: sys/netinet/in_pcb.h =================================================================== --- sys/netinet/in_pcb.h (revision 226165) +++ sys/netinet/in_pcb.h (working copy) @@ -540,6 +540,7 @@ void inp_4tuple_get(struct inpcb *inp, uint32_t * #define INP_LLE_VALID 0x00000001 /* cached lle is valid */ #define INP_RT_VALID 0x00000002 /* cached rtentry is valid */ #define INP_PCBGROUPWILD 0x00000004 /* in pcbgroup wildcard list */ +#define INP_REUSEPORT 0x00000008 /* socket SO_REUSEPORT option is set */ /* * Flags passed to in_pcblookup*() functions. Index: sys/netinet/ip_output.c =================================================================== --- sys/netinet/ip_output.c (revision 226165) +++ sys/netinet/ip_output.c (working copy) @@ -895,12 +895,43 @@ ip_ctloutput(struct socket *so, struct sockopt *so error = optval = 0; if (sopt->sopt_level != IPPROTO_IP) { - if ((sopt->sopt_level == SOL_SOCKET) && - (sopt->sopt_name == SO_SETFIB)) { - inp->inp_inc.inc_fibnum = so->so_fibnum; - return (0); + error = EINVAL; + + if (sopt->sopt_level == SOL_SOCKET && + sopt->sopt_dir == SOPT_SET) { + switch (sopt->sopt_name) { + case SO_REUSEADDR: + INP_WLOCK(inp); + if (IN_MULTICAST(ntohl(inp->inp_laddr.s_addr))) { + if ((so->so_options & + (SO_REUSEADDR | SO_REUSEPORT)) != 0) + inp->inp_flags2 |= INP_REUSEPORT; + else + inp->inp_flags2 &= ~INP_REUSEPORT; + } + INP_WUNLOCK(inp); + error = 0; + break; + case SO_REUSEPORT: + INP_WLOCK(inp); + if ((so->so_options & SO_REUSEPORT) != 0) + inp->inp_flags2 |= INP_REUSEPORT; + else + inp->inp_flags2 &= ~INP_REUSEPORT; + INP_WUNLOCK(inp); + error = 0; + break; + case SO_SETFIB: + INP_WLOCK(inp); + inp->inp_inc.inc_fibnum = so->so_fibnum; + INP_WUNLOCK(inp); + error = 0; + break; + default: + break; + } } - return (EINVAL); + return (error); } switch (sopt->sopt_dir) { Index: sys/netinet6/ip6_output.c =================================================================== --- sys/netinet6/ip6_output.c (revision 226145) +++ sys/netinet6/ip6_output.c (working copy) @@ -1421,7 +1421,38 @@ ip6_ctloutput(struct socket *so, struct sockopt *s optval = 0; uproto = (int)so->so_proto->pr_protocol; - if (level == IPPROTO_IPV6) { + if (level != IPPROTO_IPV6) { + error = EINVAL; + + if (sopt->sopt_level == SOL_SOCKET && + sopt->sopt_dir == SOPT_SET) { + switch (sopt->sopt_name) { + case SO_REUSEADDR: + INP_WLOCK(in6p); + if (IN_MULTICAST(ntohl(in6p->inp_laddr.s_addr))) { + if ((so->so_options & + (SO_REUSEADDR | SO_REUSEPORT)) != 0) + in6p->inp_flags2 |= INP_REUSEPORT; + else + in6p->inp_flags2 &= ~INP_REUSEPORT; + } + INP_WUNLOCK(in6p); + error = 0; + break; + case SO_REUSEPORT: + INP_WLOCK(in6p); + if ((so->so_options & SO_REUSEPORT) != 0) + in6p->inp_flags2 |= INP_REUSEPORT; + else + in6p->inp_flags2 &= ~INP_REUSEPORT; + INP_WUNLOCK(in6p); + error = 0; + break; + default: + break; + } + } + } else { /* level == IPPROTO_IPV6 */ switch (op) { case SOPT_SET: @@ -2044,8 +2075,6 @@ do { \ } break; } - } else { /* level != IPPROTO_IPV6 */ - error = EINVAL; } return (error); } Index: sys/netinet6/in6_pcb.c =================================================================== --- sys/netinet6/in6_pcb.c (revision 226145) +++ sys/netinet6/in6_pcb.c (working copy) @@ -187,6 +187,7 @@ in6_pcbbind(register struct inpcb *inp, struct soc } if (lport) { struct inpcb *t; + struct tcptw *tw; /* GROSS */ if (ntohs(lport) <= V_ipport_reservedhigh && @@ -206,8 +207,8 @@ in6_pcbbind(register struct inpcb *inp, struct soc IN6_IS_ADDR_UNSPECIFIED(&t->in6p_faddr)) && (!IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr) || !IN6_IS_ADDR_UNSPECIFIED(&t->in6p_laddr) || - (t->inp_socket->so_options & SO_REUSEPORT) - == 0) && (inp->inp_cred->cr_uid != + (t->inp_flags2 & INP_REUSEPORT) == 0) && + (inp->inp_cred->cr_uid != t->inp_cred->cr_uid)) return (EADDRINUSE); #ifdef INET @@ -233,10 +234,21 @@ in6_pcbbind(register struct inpcb *inp, struct soc } t = in6_pcblookup_local(pcbinfo, &sin6->sin6_addr, lport, lookupflags, cred); - if (t && (reuseport & ((t->inp_flags & INP_TIMEWAIT) ? - intotw(t)->tw_so_options : - t->inp_socket->so_options)) == 0) + if (t && (t->inp_flags & INP_TIMEWAIT)) { + /* + * XXXRW: If an incpb has had its timewait + * state recycled, we treat the address as + * being in use (for now). This is better + * than a panic, but not desirable. + */ + tw = intotw(t); + if (tw == NULL || + (reuseport & tw->tw_so_options) == 0) + return (EADDRINUSE); + } else if (t && (reuseport == 0 || + (t->inp_flags2 & INP_REUSEPORT) == 0)) { return (EADDRINUSE); + } #ifdef INET if ((inp->inp_flags & IN6P_IPV6_V6ONLY) == 0 && IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr)) { @@ -246,19 +258,19 @@ in6_pcbbind(register struct inpcb *inp, struct soc t = in_pcblookup_local(pcbinfo, sin.sin_addr, lport, lookupflags, cred); if (t && t->inp_flags & INP_TIMEWAIT) { - if ((reuseport & - intotw(t)->tw_so_options) == 0 && - (ntohl(t->inp_laddr.s_addr) != + tw = intotw(t); + if (tw == NULL) + return (EADDRINUSE); + if ((reuseport & tw->tw_so_options) == 0 + && (ntohl(t->inp_laddr.s_addr) != INADDR_ANY || ((inp->inp_vflag & INP_IPV6PROTO) == (t->inp_vflag & INP_IPV6PROTO)))) return (EADDRINUSE); - } - else if (t && - (reuseport & t->inp_socket->so_options) - == 0 && (ntohl(t->inp_laddr.s_addr) != - INADDR_ANY || INP_SOCKAF(so) == - INP_SOCKAF(t->inp_socket))) + } else if (t && (reuseport == 0 || + (t->inp_flags2 & INP_REUSEPORT) == 0) && + (ntohl(t->inp_laddr.s_addr) != INADDR_ANY || + (t->inp_vflag & INP_IPV6PROTO) == 0)) return (EADDRINUSE); } #endif --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 14:07:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12F64106564A for ; Wed, 12 Oct 2011 14:07:09 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id C2EDD8FC08 for ; Wed, 12 Oct 2011 14:07:08 +0000 (UTC) Received: by qyk10 with SMTP id 10so4895109qyk.13 for ; Wed, 12 Oct 2011 07:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5fNJ6ctOKZxfxK2rhzzza8vRx6LtXJNcZojV6xEstds=; b=q0PTsxjPXorecX9WQN6+/LXBLvN+hgiZGQP806ux8u/6tfKq7mNgu55aTwVwKjS2lc iRjNpY3IIgJQsOWmbHD3jWGTYeAvRCGqsThdWTIPaCY/owYCMZHmN1SW3YXrXnudEhNY Lm8IRyWk4zZyN63onXhD1d1iI1gTkJIfERODs= Received: by 10.229.87.137 with SMTP id w9mr5708493qcl.284.1318428427913; Wed, 12 Oct 2011 07:07:07 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id d20sm2988075qak.10.2011.10.12.07.07.06 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 07:07:07 -0700 (PDT) Message-ID: <4E959F06.6040906@gmail.com> Date: Wed, 12 Oct 2011 10:07:02 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kevin Oberman References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 14:07:09 -0000 On 11-10-11 01:31 PM, Kevin Oberman wrote: > On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote: >> On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote: >>> Hi List, >>> >>> Using a Marvell NIC plugged into a CISCO switch I see the >>> auto-negotiation failing and even when forcing the device to full-duplex >>> we sometimes see packet drops. >>> >>> Here is the device description from dmesg: >>> >>> mskc0: port 0xbe00-0xbeff mem >>> 0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 >>> msk0: on mskc0 >>> msk0: Ethernet address: 00:03:2d:09:94:52 >>> miibus0: on msk0 >>> e1000phy0: PHY 0 on miibus0 >>> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>> mskc0: [ITHREAD] >>> >>> The switch its plugged in (Cisco) is configured for 100baseTX full-duplex. >>> >>> ifconfig reports: >>> >>> msk0: >>> flags=608843 >>> metric 0 mtu 1500 >>> options=40018 >> The flags and options show that you're using very customized >> driver, right? >> >>> ether 00:03:2d:09:94:52 >>> inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.122.255 >>> media: Ethernet autoselect (100baseTX) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Resolved duplex is half so I guess it would be normal to see >> dropped frames which may be triggered by collision. > You have a duplex mis-match. If you are hard setting the remote end to > full, the local end must also be configured o full. Auto-configuration > of duplex requires that both ends run auto-config. When one end is set > to not do auto-config, the other end SHOULD always set to half-duplex. > This is part of 802.3 that is a carry-over from the days when hubs and > coax dominated, so the default was declared to be half. Since so much > hardware now exists with that default, changing it ill never happen. > > Either set your computer to full duplex or turn on auto-configuration > on the Cisco. > > Very little hardware now in service fails to auto-config correctly, > but the practice of lacking down the duplex setting became common in > the early days of full-duplex when it was not yet a standard and many > Ethernet chip-sets didn't play nice with others. Things would be much > better if people would just stop hard-setting the duplex, but old, old > habits and memes die hard. > > Also, contrary to common belief, collisions are NOT errors. They are a > normal part of half-dulpex Ethernet operation and do NOT result in > packets being dropped. Only "excessive collisions do and they ARE a > real error and a clear indication that something is wrong. Hi, Thanks for the feedback and detailed information. I have to clarify here; I get the issue even with forcing full duplex. The driver modifications are minor and shouldn't affect link negotiation or link state. Its also interesting that this problem only shows up with Cisco's switches and faced with other types of switches the issue does not come up. Also, nothing like collisions or missed/dropped packets can be found in msk_stats (see below) that somewhat relate to the issue I'm seeing. One thing interesting is the ifm_status value from msk_mediastatus. It often changes from (IFM_AVALID | IFM_ACTIVE) which is 0x3 to 0x1 (IFM_AVALID) for no reason I can tell. From the code in e1000phy_status: static void e1000phy_status(struct mii_softc *sc) { struct mii_data *mii = sc->mii_pdata; int bmcr, bmsr, ssr; mii->mii_media_status = IFM_AVALID; mii->mii_media_active = IFM_ETHER; bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); bmcr = PHY_READ(sc, E1000_CR); ssr = PHY_READ(sc, E1000_SSR); if (bmsr & E1000_SR_LINK_STATUS) mii->mii_media_status |= IFM_ACTIVE; I can see the bmsr & E1000_SR_LINK_STATUS check failing when the problem occurs. As a side note why are we ORing the same call twice isn't the same thing as calling it once: bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); As requested here is my msk0 stats output right after the problem showed up: dev.msk.0.stats.rx.ucast_frames: 58103886 dev.msk.0.stats.rx.bcast_frames: 0 dev.msk.0.stats.rx.pause_frames: 0 dev.msk.0.stats.rx.mcast_frames: 0 dev.msk.0.stats.rx.crc_errs: 0 dev.msk.0.stats.rx.good_octets: 5927739395 dev.msk.0.stats.rx.bad_octets: 0 dev.msk.0.stats.rx.frames_64: 53 dev.msk.0.stats.rx.frames_65_127: 58091128 dev.msk.0.stats.rx.frames_128_255: 12545 dev.msk.0.stats.rx.frames_256_511: 40 dev.msk.0.stats.rx.frames_512_1023: 89 dev.msk.0.stats.rx.frames_1024_1518: 31 dev.msk.0.stats.rx.frames_1519_max: 0 dev.msk.0.stats.rx.frames_too_long: 0 dev.msk.0.stats.rx.jabbers: 0 dev.msk.0.stats.rx.overflows: 0 dev.msk.0.stats.tx.ucast_frames: 58104799 dev.msk.0.stats.tx.bcast_frames: 53 dev.msk.0.stats.tx.pause_frames: 0 dev.msk.0.stats.tx.mcast_frames: 0 dev.msk.0.stats.tx.octets: 5927439760 dev.msk.0.stats.tx.frames_64: 547 dev.msk.0.stats.tx.frames_65_127: 58091680 dev.msk.0.stats.tx.frames_128_255: 12576 dev.msk.0.stats.tx.frames_256_511: 17 dev.msk.0.stats.tx.frames_512_1023: 1 dev.msk.0.stats.tx.frames_1024_1518: 32 dev.msk.0.stats.tx.frames_1519_max: 0 dev.msk.0.stats.tx.colls: 2 dev.msk.0.stats.tx.late_colls: 2 dev.msk.0.stats.tx.excess_colls: 0 dev.msk.0.stats.tx.multi_colls: 0 dev.msk.0.stats.tx.single_colls: 2 dev.msk.0.stats.tx.underflows: 0 The 2 collisions occurred before I forced the interface to full-duplex. Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 14:50:47 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53F80106566B; Wed, 12 Oct 2011 14:50:47 +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 2C1058FC08; Wed, 12 Oct 2011 14:50:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9CEolAg084354; Wed, 12 Oct 2011 14:50:47 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9CEolv1084345; Wed, 12 Oct 2011 14:50:47 GMT (envelope-from remko) Date: Wed, 12 Oct 2011 14:50:47 GMT Message-Id: <201110121450.p9CEolv1084345@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/145600: TCP/ECN behaves different to CE/CWR than ns2 reference 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, 12 Oct 2011 14:50:47 -0000 Synopsis: TCP/ECN behaves different to CE/CWR than ns2 reference Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Oct 12 14:50:09 UTC 2011 Responsible-Changed-Why: Reassign to networking team. Network people, this already had been committed and might be interesting to commit to 7-stable as well. If not please close the ticket. http://www.freebsd.org/cgi/query-pr.cgi?pr=145600 From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 15:08:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29842106564A for ; Wed, 12 Oct 2011 15:08:58 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AF0828FC27 for ; Wed, 12 Oct 2011 15:08:57 +0000 (UTC) Received: by wwe3 with SMTP id 3so171562wwe.31 for ; Wed, 12 Oct 2011 08:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h/klb2wpn3+jQ3HlBbecrQuzf8LTFc6h9MpfjPcOcgs=; b=g0171cq1Ac7AIiT032akYr0Hs4QIGOky9KXP4FSmI3VNal+OV4GNQtpo6wrJRy8+G+ P2MrZUGKSwjSylkWWjYrA5Txpk0E0M8JVkg40E5OjZuvZqp89HEbZX9IsjoSd2HDqY9a N85swGEofkllowHLMaq7pcPUKP8di4vA/Jx78= MIME-Version: 1.0 Received: by 10.227.166.69 with SMTP id l5mr9228462wby.34.1318432136455; Wed, 12 Oct 2011 08:08:56 -0700 (PDT) Received: by 10.180.103.33 with HTTP; Wed, 12 Oct 2011 08:08:56 -0700 (PDT) In-Reply-To: <4E959F06.6040906@gmail.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> Date: Wed, 12 Oct 2011 11:08:56 -0400 Message-ID: From: Arnaud Lacombe To: Karim Content-Type: text/plain; charset=ISO-8859-1 Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Kevin Oberman Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 15:08:58 -0000 Hi, On Wed, Oct 12, 2011 at 10:07 AM, Karim wrote: >> [...] > Hi, > > Thanks for the feedback and detailed information. > > I have to clarify here; I get the issue even with forcing full duplex. > > The driver modifications are minor and shouldn't affect link negotiation or > link state. [...] > FWIW, is that still (and only) the patch you sent once in: http://lists.freebsd.org/pipermail/freebsd-net/2010-November/026868.html or other have been added ? Thanks, - Arnaud From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 15:15:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2584B106566C for ; Wed, 12 Oct 2011 15:15:41 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D3FF78FC0A for ; Wed, 12 Oct 2011 15:15:40 +0000 (UTC) Received: by qadz30 with SMTP id z30so854751qad.13 for ; Wed, 12 Oct 2011 08:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DgSy3djtzM9zDhoL41w9u80m5sUctKtp71fsQ+s9bWw=; b=iRQJZJRJml/nD/KkKqxAd5PmRcOByJjGPCu7k4RNezLfg1cqZd8BbyzOWLFavFRMO1 CueJVS33JL4dxUBe0Ad6dU82GlKZKey0Ig4Ika+/GhBI2iXthNvFfN43kauYsbJUllD7 3oo69rUU/V8vJAifLN/GpvlVqY8oJKqSP2ixE= Received: by 10.224.206.132 with SMTP id fu4mr10345555qab.20.1318432540042; Wed, 12 Oct 2011 08:15:40 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id bh18sm3225775qab.8.2011.10.12.08.15.37 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 08:15:38 -0700 (PDT) Message-ID: <4E95AF15.3030405@gmail.com> Date: Wed, 12 Oct 2011 11:15:33 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Arnaud Lacombe References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com, freebsd-net@freebsd.org, Kevin Oberman Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 15:15:41 -0000 On 11-10-12 11:08 AM, Arnaud Lacombe wrote: > Hi, > > On Wed, Oct 12, 2011 at 10:07 AM, Karim wrote: >>> [...] >> Hi, >> >> Thanks for the feedback and detailed information. >> >> I have to clarify here; I get the issue even with forcing full duplex. >> >> The driver modifications are minor and shouldn't affect link negotiation or >> link state. [...] >> > FWIW, is that still (and only) the patch you sent once in: > > http://lists.freebsd.org/pipermail/freebsd-net/2010-November/026868.html > > or other have been added ? > > Thanks, > - Arnaud Hi Arnaud, Yes, that patch is in there and working great AFAIK. Cheers, Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 15:26:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B77D106564A for ; Wed, 12 Oct 2011 15:26:49 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 42F5A8FC14 for ; Wed, 12 Oct 2011 15:26:48 +0000 (UTC) Received: by qyk4 with SMTP id 4so178588qyk.13 for ; Wed, 12 Oct 2011 08:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DO6S/zgJ7+q8SZg47+Qw7cDHJNr0f2d2P2hGFeQuFho=; b=COVO1hmZ/ECFhGpBBVT4+2H3Nvk8uz5mlC/l7Faak5hDu+WGaQee+mKsdiDuUJs/Zz dr03Om7u3gWT3j3GJ5/ultsJjlGUHBsmaQnsJSa41tj92KTgyMNlsJJQhbgYwm4KnqBQ SsXCxGMM2Fa0lCHAj+i10tGZrkyAeHKAOUfG4= Received: by 10.229.61.99 with SMTP id s35mr5772710qch.229.1318433208323; Wed, 12 Oct 2011 08:26:48 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id ef8sm3279664qab.12.2011.10.12.08.26.43 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 08:26:44 -0700 (PDT) Message-ID: <4E95B1AF.5040906@gmail.com> Date: Wed, 12 Oct 2011 11:26:39 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <4E95AF15.3030405@gmail.com> In-Reply-To: <4E95AF15.3030405@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 15:26:49 -0000 On 11-10-12 11:15 AM, Karim wrote: > On 11-10-12 11:08 AM, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Oct 12, 2011 at 10:07 AM, Karim >> wrote: >>>> [...] >>> Hi, >>> >>> Thanks for the feedback and detailed information. >>> >>> I have to clarify here; I get the issue even with forcing full duplex. >>> >>> The driver modifications are minor and shouldn't affect link >>> negotiation or >>> link state. [...] >>> >> FWIW, is that still (and only) the patch you sent once in: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2010-November/026868.html >> >> or other have been added ? >> >> Thanks, >> - Arnaud > Hi Arnaud, > > Yes, that patch is in there and working great AFAIK. > Sorry I realise I did not answer the question :S. There are other patches in there but mainly to port the FBSD 9 driver to FBSD7 which includes some back conversions to QUADs from UINT64 sysctls and some other minor PCI macro names. Nothing I can think that would affect this type of behaviour. Moreover those patches have been proven to work for a while now without issues and this problem seems relatively new to me. Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 16:05:42 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B1C106566B for ; Wed, 12 Oct 2011 16:05:42 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 891758FC08 for ; Wed, 12 Oct 2011 16:05:42 +0000 (UTC) Received: by ggeq3 with SMTP id q3so1093867gge.13 for ; Wed, 12 Oct 2011 09:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZyhxfYfIemFnHNz2WcWn/o2WD/NYX7m4rnp7eZ6rlp8=; b=cHfRfMsIC+mHT0AZf9bIeDWmC0g29iDkz0QCxzgPaiupyr5ml+76DpWRRdtgl0b846 ooiR0FbPZum0HEKJTkqm0tu+FY2Rb8lq8aCV0h4qvodmeQe5P78lH2EvapiGLjwiX0Fk yiW0MkyzgaAH+dF2R/d1n8+eXzEP7bA/bNa9A= MIME-Version: 1.0 Received: by 10.236.197.104 with SMTP id s68mr38413895yhn.20.1318435542000; Wed, 12 Oct 2011 09:05:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.175.161 with HTTP; Wed, 12 Oct 2011 09:05:41 -0700 (PDT) In-Reply-To: <4E94637A.5090607@gmail.com> References: <4E94637A.5090607@gmail.com> Date: Thu, 13 Oct 2011 00:05:41 +0800 X-Google-Sender-Auth: PksbwPodKUyE8bzSZzK068vWiLI Message-ID: From: Adrian Chadd To: Karim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 16:05:42 -0000 Try "sysctl kern.eventtimer.idletick=1" . Someone has also reported an issue with packet loss and system freezes with idletick=0 (which is the default in -head now.) Adrian From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 17:05:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 731CB106566B for ; Wed, 12 Oct 2011 17:05:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F18CB8FC12 for ; Wed, 12 Oct 2011 17:05:36 +0000 (UTC) Received: by wyj26 with SMTP id 26so1389403wyj.13 for ; Wed, 12 Oct 2011 10:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Zi2slF/EAeE4kvVPdIUMWBMreOnll02m42oksI+SRBc=; b=DBna38dpVpnr/I/+H8aXmjfHQHDL8+c2mmVPpTVWGO5reHjraRRxDS/9PGkn9hld52 nR78Y05d98r7rXIH8NqkxPWzubN23rkIyzUxe4fsolxCMl688FC7voGYLhDoC7a0l1QO V6crDtiBJNH9IISZn7PZA3lVBsq64gK4MT3/o= Received: by 10.227.154.2 with SMTP id m2mr3219311wbw.39.1318439135473; Wed, 12 Oct 2011 10:05:35 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p2sm1043684wbo.17.2011.10.12.10.05.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 10:05:33 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Oct 2011 10:03:47 -0700 From: YongHyeon PYUN Date: Wed, 12 Oct 2011 10:03:47 -0700 To: Karim Message-ID: <20111012170347.GA9138@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E959F06.6040906@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Kevin Oberman Subject: Re: if_msk.c link negotiation / packet drops X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:05:37 -0000 On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > On 11-10-11 01:31 PM, Kevin Oberman wrote: > >On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote: > >>On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote: > >>>Hi List, > >>> > >>>Using a Marvell NIC plugged into a CISCO switch I see the > >>>auto-negotiation failing and even when forcing the device to full-duplex > >>>we sometimes see packet drops. > >>> > >>>Here is the device description from dmesg: > >>> > >>>mskc0: port 0xbe00-0xbeff mem > >>>0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 > >>>msk0: on mskc0 > >>>msk0: Ethernet address: 00:03:2d:09:94:52 > >>>miibus0: on msk0 > >>>e1000phy0: PHY 0 on miibus0 > >>>e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > >>>1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > >>>mskc0: [ITHREAD] > >>> > >>>The switch its plugged in (Cisco) is configured for 100baseTX > >>>full-duplex. > >>> > >>>ifconfig reports: > >>> > >>>msk0: > >>>flags=608843 > >>>metric 0 mtu 1500 > >>> options=40018 > >>The flags and options show that you're using very customized > >>driver, right? > >> > >>> ether 00:03:2d:09:94:52 > >>> inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.122.255 > >>> media: Ethernet autoselect (100baseTX) > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >>Resolved duplex is half so I guess it would be normal to see > >>dropped frames which may be triggered by collision. > >You have a duplex mis-match. If you are hard setting the remote end to > >full, the local end must also be configured o full. Auto-configuration > >of duplex requires that both ends run auto-config. When one end is set > >to not do auto-config, the other end SHOULD always set to half-duplex. > >This is part of 802.3 that is a carry-over from the days when hubs and > >coax dominated, so the default was declared to be half. Since so much > >hardware now exists with that default, changing it ill never happen. > > > >Either set your computer to full duplex or turn on auto-configuration > >on the Cisco. > > > >Very little hardware now in service fails to auto-config correctly, > >but the practice of lacking down the duplex setting became common in > >the early days of full-duplex when it was not yet a standard and many > >Ethernet chip-sets didn't play nice with others. Things would be much > >better if people would just stop hard-setting the duplex, but old, old > >habits and memes die hard. > > > >Also, contrary to common belief, collisions are NOT errors. They are a > >normal part of half-dulpex Ethernet operation and do NOT result in > >packets being dropped. Only "excessive collisions do and they ARE a > >real error and a clear indication that something is wrong. > Hi, > > Thanks for the feedback and detailed information. > > I have to clarify here; I get the issue even with forcing full duplex. > > The driver modifications are minor and shouldn't affect link negotiation > or link state. Its also interesting that this problem only shows up with > Cisco's switches and faced with other types of switches the issue does > not come up. > Right. It would be also interesting to see MAC statistics of Cisco switch and check both parties agree on resolved speed/duplex/flow-control. > Also, nothing like collisions or missed/dropped packets can be found in > msk_stats (see below) that somewhat relate to the issue I'm seeing. One > thing interesting is the ifm_status value from msk_mediastatus. It often > changes from (IFM_AVALID | IFM_ACTIVE) which is 0x3 to 0x1 (IFM_AVALID) > for no reason I can tell. > Hmm, that indicates driver lost established link. msk(4) will detect this condition and stop RX/TX MACs until it knows PHY re-established a link. This may be the reason why you see occasional packet drops. However I don't know why PHY loses established link in the middle of working. > From the code in e1000phy_status: > > static void > e1000phy_status(struct mii_softc *sc) > { > struct mii_data *mii = sc->mii_pdata; > int bmcr, bmsr, ssr; > > mii->mii_media_status = IFM_AVALID; > mii->mii_media_active = IFM_ETHER; > > bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > bmcr = PHY_READ(sc, E1000_CR); > ssr = PHY_READ(sc, E1000_SSR); > > if (bmsr & E1000_SR_LINK_STATUS) > mii->mii_media_status |= IFM_ACTIVE; > > > I can see the bmsr & E1000_SR_LINK_STATUS check failing when the problem > occurs. As a side note why are we ORing the same call twice isn't the > same thing as calling it once: > > bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > The E1000_SR_LINK_STATUS bit is latched low so it should be read twice. If you want to read once use E1000_SSR_LINK bit of E1000_SSR register but I remember that bit was not reliable on some PHY models. By chance, does your back-ported driver include r222219? If yes, did you cold boot after applying the change? Warm boot does have effect. > As requested here is my msk0 stats output right after the problem showed up: > > dev.msk.0.stats.rx.ucast_frames: 58103886 > dev.msk.0.stats.rx.bcast_frames: 0 > dev.msk.0.stats.rx.pause_frames: 0 > dev.msk.0.stats.rx.mcast_frames: 0 > dev.msk.0.stats.rx.crc_errs: 0 > dev.msk.0.stats.rx.good_octets: 5927739395 > dev.msk.0.stats.rx.bad_octets: 0 > dev.msk.0.stats.rx.frames_64: 53 > dev.msk.0.stats.rx.frames_65_127: 58091128 > dev.msk.0.stats.rx.frames_128_255: 12545 > dev.msk.0.stats.rx.frames_256_511: 40 > dev.msk.0.stats.rx.frames_512_1023: 89 > dev.msk.0.stats.rx.frames_1024_1518: 31 > dev.msk.0.stats.rx.frames_1519_max: 0 > dev.msk.0.stats.rx.frames_too_long: 0 > dev.msk.0.stats.rx.jabbers: 0 > dev.msk.0.stats.rx.overflows: 0 > dev.msk.0.stats.tx.ucast_frames: 58104799 > dev.msk.0.stats.tx.bcast_frames: 53 > dev.msk.0.stats.tx.pause_frames: 0 > dev.msk.0.stats.tx.mcast_frames: 0 > dev.msk.0.stats.tx.octets: 5927439760 > dev.msk.0.stats.tx.frames_64: 547 > dev.msk.0.stats.tx.frames_65_127: 58091680 > dev.msk.0.stats.tx.frames_128_255: 12576 > dev.msk.0.stats.tx.frames_256_511: 17 > dev.msk.0.stats.tx.frames_512_1023: 1 > dev.msk.0.stats.tx.frames_1024_1518: 32 > dev.msk.0.stats.tx.frames_1519_max: 0 > dev.msk.0.stats.tx.colls: 2 > dev.msk.0.stats.tx.late_colls: 2 > dev.msk.0.stats.tx.excess_colls: 0 > dev.msk.0.stats.tx.multi_colls: 0 > dev.msk.0.stats.tx.single_colls: 2 > dev.msk.0.stats.tx.underflows: 0 > > The 2 collisions occurred before I forced the interface to full-duplex. > > Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 18:35:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF71D1065676 for ; Wed, 12 Oct 2011 18:35:29 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A24158FC1B for ; Wed, 12 Oct 2011 18:35:29 +0000 (UTC) Received: by vws11 with SMTP id 11so1198666vws.13 for ; Wed, 12 Oct 2011 11:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3CGlwIJyewhYs/UWkdGZ5RKrTWCXoni1RkChKc/tyJI=; b=NwyMO++yBauBm1YjbIyRT5ukrS0bnufpi+RFIlRkDHS52heZsLgTwhoZRB7DAZ2MoO 5Ut3nEmd+7Gb/dlTa986gZpSFSKPN2ujI6ZgUdoBfO97R6hHmocD9o+1em8lEW8xnr98 RTObVzmdCvso9j+iwpMdXkrPwILHb10tja2j0= Received: by 10.52.27.66 with SMTP id r2mr235418vdg.79.1318444528837; Wed, 12 Oct 2011 11:35:28 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id bi11sm928433vdb.13.2011.10.12.11.35.27 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 11:35:28 -0700 (PDT) Message-ID: <4E95DDEB.1090500@gmail.com> Date: Wed, 12 Oct 2011 14:35:23 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> In-Reply-To: <20111012170347.GA9138@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 18:35:30 -0000 Hi, On 11-10-12 01:03 PM, YongHyeon PYUN wrote: > On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: >> On 11-10-11 01:31 PM, Kevin Oberman wrote: >>> On Tue, Oct 11, 2011 at 10:10 AM, YongHyeon PYUN wrote: >>>> On Tue, Oct 11, 2011 at 11:40:42AM -0400, Karim wrote: >>>>> Hi List, >>>>> >>>>> Using a Marvell NIC plugged into a CISCO switch I see the >>>>> auto-negotiation failing and even when forcing the device to full-duplex >>>>> we sometimes see packet drops. >>>>> >>>>> Here is the device description from dmesg: >>>>> >>>>> mskc0: port 0xbe00-0xbeff mem >>>>> 0xfdefc000-0xfdefffff irq 16 at device 0.0 on pci1 >>>>> msk0: on mskc0 >>>>> msk0: Ethernet address: 00:03:2d:09:94:52 >>>>> miibus0: on msk0 >>>>> e1000phy0: PHY 0 on miibus0 >>>>> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >>>>> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >>>>> mskc0: [ITHREAD] >>>>> >>>>> The switch its plugged in (Cisco) is configured for 100baseTX >>>>> full-duplex. >>>>> >>>>> ifconfig reports: >>>>> >>>>> msk0: >>>>> flags=608843 >>>>> metric 0 mtu 1500 >>>>> options=40018 >>>> The flags and options show that you're using very customized >>>> driver, right? >>>> >>>>> ether 00:03:2d:09:94:52 >>>>> inet 192.168.122.7 netmask 0xffffff00 broadcast 192.168.122.255 >>>>> media: Ethernet autoselect (100baseTX) >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>> Resolved duplex is half so I guess it would be normal to see >>>> dropped frames which may be triggered by collision. >>> You have a duplex mis-match. If you are hard setting the remote end to >>> full, the local end must also be configured o full. Auto-configuration >>> of duplex requires that both ends run auto-config. When one end is set >>> to not do auto-config, the other end SHOULD always set to half-duplex. >>> This is part of 802.3 that is a carry-over from the days when hubs and >>> coax dominated, so the default was declared to be half. Since so much >>> hardware now exists with that default, changing it ill never happen. >>> >>> Either set your computer to full duplex or turn on auto-configuration >>> on the Cisco. >>> >>> Very little hardware now in service fails to auto-config correctly, >>> but the practice of lacking down the duplex setting became common in >>> the early days of full-duplex when it was not yet a standard and many >>> Ethernet chip-sets didn't play nice with others. Things would be much >>> better if people would just stop hard-setting the duplex, but old, old >>> habits and memes die hard. >>> >>> Also, contrary to common belief, collisions are NOT errors. They are a >>> normal part of half-dulpex Ethernet operation and do NOT result in >>> packets being dropped. Only "excessive collisions do and they ARE a >>> real error and a clear indication that something is wrong. >> Hi, >> >> Thanks for the feedback and detailed information. >> >> I have to clarify here; I get the issue even with forcing full duplex. >> >> The driver modifications are minor and shouldn't affect link negotiation >> or link state. Its also interesting that this problem only shows up with >> Cisco's switches and faced with other types of switches the issue does >> not come up. >> > Right. It would be also interesting to see MAC statistics of Cisco > switch and check both parties agree on resolved > speed/duplex/flow-control. >> Also, nothing like collisions or missed/dropped packets can be found in >> msk_stats (see below) that somewhat relate to the issue I'm seeing. One >> thing interesting is the ifm_status value from msk_mediastatus. It often >> changes from (IFM_AVALID | IFM_ACTIVE) which is 0x3 to 0x1 (IFM_AVALID) >> for no reason I can tell. >> > Hmm, that indicates driver lost established link. msk(4) will > detect this condition and stop RX/TX MACs until it knows PHY > re-established a link. This may be the reason why you see occasional > packet drops. However I don't know why PHY loses established link > in the middle of working. > Yes, I am convinced this lost of link is related to the packet drops as well. At this point we can safely discard cabling issues or router issues (physical ones that is) since the same happens on a different network with different cables. >> From the code in e1000phy_status: >> >> static void >> e1000phy_status(struct mii_softc *sc) >> { >> struct mii_data *mii = sc->mii_pdata; >> int bmcr, bmsr, ssr; >> >> mii->mii_media_status = IFM_AVALID; >> mii->mii_media_active = IFM_ETHER; >> >> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >> bmcr = PHY_READ(sc, E1000_CR); >> ssr = PHY_READ(sc, E1000_SSR); >> >> if (bmsr& E1000_SR_LINK_STATUS) >> mii->mii_media_status |= IFM_ACTIVE; >> >> >> I can see the bmsr& E1000_SR_LINK_STATUS check failing when the problem >> occurs. As a side note why are we ORing the same call twice isn't the >> same thing as calling it once: >> >> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >> > The E1000_SR_LINK_STATUS bit is latched low so it should be read > twice. If you want to read once use E1000_SSR_LINK bit of > E1000_SSR register but I remember that bit was not reliable on some > PHY models. Thanks for the explanation and the alternative. The ssr register seems to give me the right bit (E1000_SSR_LINK) but it also gives me an extra bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit would be/means? > By chance, does your back-ported driver include r222219? > If yes, did you cold boot after applying the change? > Warm boot does have effect. I do have this patch in the back-ported driver and due to several reasons I didn't cold boot the appliance. We will give that a try and see. To be more precises I have included msk patches up to r222516. Thanks! Karim. >> As requested here is my msk0 stats output right after the problem showed up: >> >> dev.msk.0.stats.rx.ucast_frames: 58103886 >> dev.msk.0.stats.rx.bcast_frames: 0 >> dev.msk.0.stats.rx.pause_frames: 0 >> dev.msk.0.stats.rx.mcast_frames: 0 >> dev.msk.0.stats.rx.crc_errs: 0 >> dev.msk.0.stats.rx.good_octets: 5927739395 >> dev.msk.0.stats.rx.bad_octets: 0 >> dev.msk.0.stats.rx.frames_64: 53 >> dev.msk.0.stats.rx.frames_65_127: 58091128 >> dev.msk.0.stats.rx.frames_128_255: 12545 >> dev.msk.0.stats.rx.frames_256_511: 40 >> dev.msk.0.stats.rx.frames_512_1023: 89 >> dev.msk.0.stats.rx.frames_1024_1518: 31 >> dev.msk.0.stats.rx.frames_1519_max: 0 >> dev.msk.0.stats.rx.frames_too_long: 0 >> dev.msk.0.stats.rx.jabbers: 0 >> dev.msk.0.stats.rx.overflows: 0 >> dev.msk.0.stats.tx.ucast_frames: 58104799 >> dev.msk.0.stats.tx.bcast_frames: 53 >> dev.msk.0.stats.tx.pause_frames: 0 >> dev.msk.0.stats.tx.mcast_frames: 0 >> dev.msk.0.stats.tx.octets: 5927439760 >> dev.msk.0.stats.tx.frames_64: 547 >> dev.msk.0.stats.tx.frames_65_127: 58091680 >> dev.msk.0.stats.tx.frames_128_255: 12576 >> dev.msk.0.stats.tx.frames_256_511: 17 >> dev.msk.0.stats.tx.frames_512_1023: 1 >> dev.msk.0.stats.tx.frames_1024_1518: 32 >> dev.msk.0.stats.tx.frames_1519_max: 0 >> dev.msk.0.stats.tx.colls: 2 >> dev.msk.0.stats.tx.late_colls: 2 >> dev.msk.0.stats.tx.excess_colls: 0 >> dev.msk.0.stats.tx.multi_colls: 0 >> dev.msk.0.stats.tx.single_colls: 2 >> dev.msk.0.stats.tx.underflows: 0 >> >> The 2 collisions occurred before I forced the interface to full-duplex. >> >> Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 19:29:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B309B106566B for ; Wed, 12 Oct 2011 19:29:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 316F28FC14 for ; Wed, 12 Oct 2011 19:29:17 +0000 (UTC) Received: by wyj26 with SMTP id 26so1584525wyj.13 for ; Wed, 12 Oct 2011 12:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=fP1e2eFlTrWuy3c+gR5mQheGLBAND2l11OmBx3tk+dE=; b=qhPDl1fzS5qjNjrcMxiN2xo5BZ/qjl/1686GWev7iSnQZuIlTIUcT7JBO6wg0MLeyB io2n+gqaLirYqzWNp3bpUrPnzsL/YIs4efQB9gMMQ6nXmHmtxg1xNUGV6erIZD1O/44X LGljGNNx47H7HSkm/CC5Drva6Dstvb00hoFnE= Received: by 10.216.134.166 with SMTP id s38mr120354wei.71.1318447756825; Wed, 12 Oct 2011 12:29:16 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n21sm1782204wbp.2.2011.10.12.12.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 12:29:15 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Oct 2011 12:27:30 -0700 From: YongHyeon PYUN Date: Wed, 12 Oct 2011 12:27:30 -0700 To: Karim Message-ID: <20111012192730.GB9138@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E95DDEB.1090500@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 19:29:18 -0000 On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote: > Hi, > On 11-10-12 01:03 PM, YongHyeon PYUN wrote: > >On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: [...] > >Hmm, that indicates driver lost established link. msk(4) will > >detect this condition and stop RX/TX MACs until it knows PHY > >re-established a link. This may be the reason why you see occasional > >packet drops. However I don't know why PHY loses established link > >in the middle of working. > > > Yes, I am convinced this lost of link is related to the packet drops as > well. At this point we can safely discard cabling issues or router > issues (physical ones that is) since the same happens on a different > network with different cables. > >> From the code in e1000phy_status: > >> > >>static void > >>e1000phy_status(struct mii_softc *sc) > >>{ > >> struct mii_data *mii = sc->mii_pdata; > >> int bmcr, bmsr, ssr; > >> > >> mii->mii_media_status = IFM_AVALID; > >> mii->mii_media_active = IFM_ETHER; > >> > >> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >> bmcr = PHY_READ(sc, E1000_CR); > >> ssr = PHY_READ(sc, E1000_SSR); > >> > >> if (bmsr& E1000_SR_LINK_STATUS) > >> mii->mii_media_status |= IFM_ACTIVE; > >> > >> > >>I can see the bmsr& E1000_SR_LINK_STATUS check failing when the problem > >>occurs. As a side note why are we ORing the same call twice isn't the > >>same thing as calling it once: > >> > >>bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >> > >The E1000_SR_LINK_STATUS bit is latched low so it should be read > >twice. If you want to read once use E1000_SSR_LINK bit of > >E1000_SSR register but I remember that bit was not reliable on some > >PHY models. > Thanks for the explanation and the alternative. The ssr register seems > to give me the right bit (E1000_SSR_LINK) but it also gives me an extra > bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit > would be/means? > I guess it's related with advanced power saving. It would indicate current Energy detect status in PHY POV. Generally Marvell's PHY will enter into automatic power saving mode when it does not see any energy signal on the link. I don't know exact time when it enters into that mode but it would take less than 10 seconds if PHY do not see energy signal from link partner once it initiated auto-negotiation. However, e1000phy(4) always disables energy detect feature in e1000phy_reset() so it wouldn't affect your issue, I guess. One interesting thing is that 0x100 of E1000_SSR register indicates energy detect status is in "Sleep mode" which means it didn't detect energy signal(i.e. lost link). I'm not sure whether this bit report correct status when energy detect feature is disabled though. Can you check whether your switch supports energy detect feature? Or if your switch support EEE feature, try disabling it. > >By chance, does your back-ported driver include r222219? > >If yes, did you cold boot after applying the change? > >Warm boot does have effect. > I do have this patch in the back-ported driver and due to several > reasons I didn't cold boot the appliance. We will give that a try and see. > Ok, let me know whether that makes any difference or not. > To be more precises I have included msk patches up to r222516. > > Thanks! [...] From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:17:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63E211065675 for ; Wed, 12 Oct 2011 20:17:16 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17BBD8FC13 for ; Wed, 12 Oct 2011 20:17:15 +0000 (UTC) Received: by qyk4 with SMTP id 4so551522qyk.13 for ; Wed, 12 Oct 2011 13:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sSKVKHl/GMp+Jk6vNaElU2491bzDRhsIQ8PNYxI2URg=; b=QkTwVvroXFaUGLIQnSfe227Bk5Gth6XoctFHPQq1/8oqv9b+D/c8WbIRfFF5CJBBVV SCQ1dtaWJloZIbULr8qU55f79+2e2AIEfIc2ds/HraCtvHz+58K5LEBW7f1GURf8n/Lz Ti+NouUr4s8Jz7WhoE7G10UMVAqE1re0m4uuE= Received: by 10.229.66.29 with SMTP id l29mr138139qci.134.1318450635313; Wed, 12 Oct 2011 13:17:15 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id et6sm4259740qab.4.2011.10.12.13.17.13 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 13:17:14 -0700 (PDT) Message-ID: <4E95F5C5.5050609@gmail.com> Date: Wed, 12 Oct 2011 16:17:09 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> <20111012192730.GB9138@michelle.cdnetworks.com> In-Reply-To: <20111012192730.GB9138@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops 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, 12 Oct 2011 20:17:16 -0000 On 11-10-12 03:27 PM, YongHyeon PYUN wrote: > On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote: >> Hi, >> On 11-10-12 01:03 PM, YongHyeon PYUN wrote: >>> On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > [...] > >>> Hmm, that indicates driver lost established link. msk(4) will >>> detect this condition and stop RX/TX MACs until it knows PHY >>> re-established a link. This may be the reason why you see occasional >>> packet drops. However I don't know why PHY loses established link >>> in the middle of working. >>> >> Yes, I am convinced this lost of link is related to the packet drops as >> well. At this point we can safely discard cabling issues or router >> issues (physical ones that is) since the same happens on a different >> network with different cables. >>>> From the code in e1000phy_status: >>>> >>>> static void >>>> e1000phy_status(struct mii_softc *sc) >>>> { >>>> struct mii_data *mii = sc->mii_pdata; >>>> int bmcr, bmsr, ssr; >>>> >>>> mii->mii_media_status = IFM_AVALID; >>>> mii->mii_media_active = IFM_ETHER; >>>> >>>> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >>>> bmcr = PHY_READ(sc, E1000_CR); >>>> ssr = PHY_READ(sc, E1000_SSR); >>>> >>>> if (bmsr& E1000_SR_LINK_STATUS) >>>> mii->mii_media_status |= IFM_ACTIVE; >>>> >>>> >>>> I can see the bmsr& E1000_SR_LINK_STATUS check failing when the problem >>>> occurs. As a side note why are we ORing the same call twice isn't the >>>> same thing as calling it once: >>>> >>>> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >>>> >>> The E1000_SR_LINK_STATUS bit is latched low so it should be read >>> twice. If you want to read once use E1000_SSR_LINK bit of >>> E1000_SSR register but I remember that bit was not reliable on some >>> PHY models. >> Thanks for the explanation and the alternative. The ssr register seems >> to give me the right bit (E1000_SSR_LINK) but it also gives me an extra >> bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit >> would be/means? >> > I guess it's related with advanced power saving. It would indicate > current Energy detect status in PHY POV. > Generally Marvell's PHY will enter into automatic power saving mode > when it does not see any energy signal on the link. I don't know > exact time when it enters into that mode but it would take less > than 10 seconds if PHY do not see energy signal from link partner > once it initiated auto-negotiation. > However, e1000phy(4) always disables energy detect feature in > e1000phy_reset() so it wouldn't affect your issue, I guess. > > One interesting thing is that 0x100 of E1000_SSR register indicates > energy detect status is in "Sleep mode" which means it didn't > detect energy signal(i.e. lost link). I'm not sure whether this bit > report correct status when energy detect feature is disabled > though. > > Can you check whether your switch supports energy detect feature? > Or if your switch support EEE feature, try disabling it. > The way I understand this is EEE only works on GE ports and because this is set to 100MB it should be disabled. Moreover Cisco's has something called Green Ethernet which works on all ports but AFAIK the switch we're plugged in does not have those features. I find it disconcerting that the E1000_SSR register reports both E1000_SSR_LINK (0x400) and 'Sleep mode' (0x100) at the same time but I guess, as you mentioned, this might not be correctly reported. I will assume we can disregard that bit for now. >>> By chance, does your back-ported driver include r222219? >>> If yes, did you cold boot after applying the change? >>> Warm boot does have effect. >> I do have this patch in the back-ported driver and due to several >> reasons I didn't cold boot the appliance. We will give that a try and see. >> > Ok, let me know whether that makes any difference or not. So far so good, will have to give it the night to see. Again, thanks for all the help, Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:33:48 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4811065673 for ; Wed, 12 Oct 2011 20:33:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F409B8FC19 for ; Wed, 12 Oct 2011 20:33:47 +0000 (UTC) Received: by wyj26 with SMTP id 26so1671502wyj.13 for ; Wed, 12 Oct 2011 13:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=oGyh7bNPH+GwDDbj5MFDtcZfF5sSQd8q45b0AIgQn4U=; b=j2L+RHefW9HJyyR3mQpMx5VyurHUfuO96o0QDMtsopNBtJ7jzUX8jEMYkaMTYFsold ZVr0LO3RioqeUX41DKzGrk+3X8QtxLt9RBcJ3qznAfofm3acxTO55D2damdKKy82oDLM 2FgIrJCroXmUOFTEw4sDkfw31f7jm0dq+5dHc= Received: by 10.227.41.198 with SMTP id p6mr208183wbe.67.1318451627014; Wed, 12 Oct 2011 13:33:47 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n21sm2074451wbp.2.2011.10.12.13.33.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 13:33:46 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Oct 2011 13:32:00 -0700 From: YongHyeon PYUN Date: Wed, 12 Oct 2011 13:32:00 -0700 To: Karim Message-ID: <20111012203200.GC9138@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> <20111012192730.GB9138@michelle.cdnetworks.com> <4E95F5C5.5050609@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E95F5C5.5050609@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 20:33:48 -0000 On Wed, Oct 12, 2011 at 04:17:09PM -0400, Karim wrote: > On 11-10-12 03:27 PM, YongHyeon PYUN wrote: > >On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote: > >>Hi, > >>On 11-10-12 01:03 PM, YongHyeon PYUN wrote: > >>>On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > >[...] > > > >>>Hmm, that indicates driver lost established link. msk(4) will > >>>detect this condition and stop RX/TX MACs until it knows PHY > >>>re-established a link. This may be the reason why you see occasional > >>>packet drops. However I don't know why PHY loses established link > >>>in the middle of working. > >>> > >>Yes, I am convinced this lost of link is related to the packet drops as > >>well. At this point we can safely discard cabling issues or router > >>issues (physical ones that is) since the same happens on a different > >>network with different cables. > >>>> From the code in e1000phy_status: > >>>> > >>>>static void > >>>>e1000phy_status(struct mii_softc *sc) > >>>>{ > >>>> struct mii_data *mii = sc->mii_pdata; > >>>> int bmcr, bmsr, ssr; > >>>> > >>>> mii->mii_media_status = IFM_AVALID; > >>>> mii->mii_media_active = IFM_ETHER; > >>>> > >>>> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >>>> bmcr = PHY_READ(sc, E1000_CR); > >>>> ssr = PHY_READ(sc, E1000_SSR); > >>>> > >>>> if (bmsr& E1000_SR_LINK_STATUS) > >>>> mii->mii_media_status |= IFM_ACTIVE; > >>>> > >>>> > >>>>I can see the bmsr& E1000_SR_LINK_STATUS check failing when the > >>>>problem > >>>>occurs. As a side note why are we ORing the same call twice isn't the > >>>>same thing as calling it once: > >>>> > >>>>bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >>>> > >>>The E1000_SR_LINK_STATUS bit is latched low so it should be read > >>>twice. If you want to read once use E1000_SSR_LINK bit of > >>>E1000_SSR register but I remember that bit was not reliable on some > >>>PHY models. > >>Thanks for the explanation and the alternative. The ssr register seems > >>to give me the right bit (E1000_SSR_LINK) but it also gives me an extra > >>bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit > >>would be/means? > >> > >I guess it's related with advanced power saving. It would indicate > >current Energy detect status in PHY POV. > >Generally Marvell's PHY will enter into automatic power saving mode > >when it does not see any energy signal on the link. I don't know > >exact time when it enters into that mode but it would take less > >than 10 seconds if PHY do not see energy signal from link partner > >once it initiated auto-negotiation. > >However, e1000phy(4) always disables energy detect feature in > >e1000phy_reset() so it wouldn't affect your issue, I guess. > > > >One interesting thing is that 0x100 of E1000_SSR register indicates > >energy detect status is in "Sleep mode" which means it didn't > >detect energy signal(i.e. lost link). I'm not sure whether this bit > >report correct status when energy detect feature is disabled > >though. > > > >Can you check whether your switch supports energy detect feature? > >Or if your switch support EEE feature, try disabling it. > > > The way I understand this is EEE only works on GE ports and because this > is set to 100MB it should be disabled. Moreover Cisco's has something > called Green Ethernet which works on all ports but AFAIK the switch > we're plugged in does not have those features. > Well, if all works as advertised, the auto-negotiation would have worked. I don't know when the switch was manufactured but EEE was standardized last year so I wouldn't be surprised to see a couple of incompatibilities between EEE-aware switches and non-EEE PHYs. Also note, many vendors already implemented subset or a kind of EEE before the EEE standardization it's hard to say what they really do. > I find it disconcerting that the E1000_SSR register reports both > E1000_SSR_LINK (0x400) and 'Sleep mode' (0x100) at the same time but I > guess, as you mentioned, this might not be correctly reported. I will > assume we can disregard that bit for now. > >>>By chance, does your back-ported driver include r222219? > >>>If yes, did you cold boot after applying the change? > >>>Warm boot does have effect. > >>I do have this patch in the back-ported driver and due to several > >>reasons I didn't cold boot the appliance. We will give that a try and see. > >> > >Ok, let me know whether that makes any difference or not. > So far so good, will have to give it the night to see. > > Again, thanks for all the help, > > Karim. From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 20:42:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 107AA1065674 for ; Wed, 12 Oct 2011 20:42:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3198FC1B for ; Wed, 12 Oct 2011 20:42:23 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9CKgMDm042017; Wed, 12 Oct 2011 22:42:22 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9CKgMk5042016; Wed, 12 Oct 2011 22:42:22 +0200 (CEST) (envelope-from marius) Date: Wed, 12 Oct 2011 22:42:22 +0200 From: Marius Strobl To: YongHyeon PYUN Message-ID: <20111012204222.GC39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111011225531.GD5661@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII 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, 12 Oct 2011 20:42:24 -0000 On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote: > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > > Hi, > > > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > > and it's useful for porting embedded devices. > > > > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > > which (im)ports these and converts drivers to take advantage of it here: > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > > > Patch looks good to me. > > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > > and xe(4))? > > > > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > > I've started with the drivers were the corresponding NetBSD one also > > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > > aware that these should also be convertible to the common code, I just > > didn't get around to it so far. As for lge(4) that driver has some > > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've > > Ah, I just blindly grepped the string, sorry. > > > previously missed rl(4) as I was only grepping beneath sys/dev and I > > currently can't explain why I missed xe(4), so thanks for mentioning > > these. > > In my experience MII bitbang'ing is very fragile though and subtle > > changes may break it so I don't want to commit these without testing > > or in the case of smc(4) where at least the corresponding NetBSD > > driver already uses the common code. Unfortunately, I only have > > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > > happen to have hardware to test the remaining drivers, i.e. nge(4), > > sis(4), ste(4), wb(4) and xe(4)? > > > > I have access to sis(4) and ste(4). I also have a nge(4) but I'm > not able to access to the hardware, at least in US. > It would be great if you could test sis(4) and ste(4). Marius From owner-freebsd-net@FreeBSD.ORG Wed Oct 12 23:58:55 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FE2A1065673 for ; Wed, 12 Oct 2011 23:58:55 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 204AE8FC0C for ; Wed, 12 Oct 2011 23:58:54 +0000 (UTC) Received: by wwe3 with SMTP id 3so837803wwe.31 for ; Wed, 12 Oct 2011 16:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yajJfpvNPbwSr44rOP1KtdA/3j2kzCdILmn9RgDZJOA=; b=Rq1926sF7tFHCtOF0z80GRoeidu/cdt3BcnYYoNNLs/raBsddBHI16FF2AIyub4SEO 5+bA1ViN9jwoVPTLDUjtRCpk4owTUQ0BOXVRQoGztAs1qMI3JcaMi4z7PC6bH08+RUNY rnY4clGDC7xmWFUO/aMUvk/rFko/Bn56490DU= Received: by 10.216.9.134 with SMTP id 6mr3079871wet.110.1318463933878; Wed, 12 Oct 2011 16:58:53 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id z9sm2779528wbn.19.2011.10.12.16.58.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 16:58:52 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Oct 2011 16:57:07 -0700 From: YongHyeon PYUN Date: Wed, 12 Oct 2011 16:57:07 -0700 To: Marius Strobl Message-ID: <20111012235707.GD9138@michelle.cdnetworks.com> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111012204222.GC39118@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:58:55 -0000 On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote: > On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote: > > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > > > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > > > Hi, > > > > > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > > > and it's useful for porting embedded devices. > > > > > > > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > > > which (im)ports these and converts drivers to take advantage of it here: > > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > > > > > Patch looks good to me. > > > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > > > and xe(4))? > > > > > > > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > > > I've started with the drivers were the corresponding NetBSD one also > > > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > > > aware that these should also be convertible to the common code, I just > > > didn't get around to it so far. As for lge(4) that driver has some > > > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've > > > > Ah, I just blindly grepped the string, sorry. > > > > > previously missed rl(4) as I was only grepping beneath sys/dev and I > > > currently can't explain why I missed xe(4), so thanks for mentioning > > > these. > > > In my experience MII bitbang'ing is very fragile though and subtle > > > changes may break it so I don't want to commit these without testing > > > or in the case of smc(4) where at least the corresponding NetBSD > > > driver already uses the common code. Unfortunately, I only have > > > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > > > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > > > happen to have hardware to test the remaining drivers, i.e. nge(4), > > > sis(4), ste(4), wb(4) and xe(4)? > > > > > > > I have access to sis(4) and ste(4). I also have a nge(4) but I'm > > not able to access to the hardware, at least in US. > > > > It would be great if you could test sis(4) and ste(4). > Ok, will do in this week. > Marius > From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 01:13:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D57106564A for ; Thu, 13 Oct 2011 01:13:14 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 4443F8FC12 for ; Thu, 13 Oct 2011 01:13:14 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p9D1DCrk000270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Oct 2011 18:13:13 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p9D1DCFx000269; Wed, 12 Oct 2011 18:13:12 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA23391; Wed, 12 Oct 11 18:00:39 PDT Date: Thu, 13 Oct 2011 00:59:35 -0700 From: perryh@pluto.rain.com To: pyunyh@gmail.com Message-Id: <4e969a67.YJyWMt0xI7pFL+xJ%perryh@pluto.rain.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> In-Reply-To: <20111012170347.GA9138@michelle.cdnetworks.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: fodillemlinkarim@gmail.com, freebsd-net@freebsd.org, kob6558@gmail.com Subject: Re: if_msk.c link negotiation / packet drops 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, 13 Oct 2011 01:13:14 -0000 YongHyeon PYUN wrote: > On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > > ... why are we ORing the same call twice isn't the same thing > > as calling it once: > > > > bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > > The E1000_SR_LINK_STATUS bit is latched low so it should be read > twice. It might not be a bad idea to check the generated code to be sure that the read _is_ being done twice. An optimizer might well come to the same conclusion as Karim, and discard the "redundant" second instance (unless there's a "volatile" declaration somewhere in the expansion of PHY_READ, to explicitly indicate that it has side effects). From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 08:30:14 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DE610656B1 for ; Thu, 13 Oct 2011 08:30:14 +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 D38D28FC1A for ; Thu, 13 Oct 2011 08:30: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 p9D8UDEJ096839 for ; Thu, 13 Oct 2011 08:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9D8UDEk096833; Thu, 13 Oct 2011 08:30:13 GMT (envelope-from gnats) Date: Thu, 13 Oct 2011 08:30:13 GMT Message-Id: <201110130830.p9D8UDEk096833@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159601: 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, 13 Oct 2011 08:30:14 -0000 The following reply was made to PR kern/159601; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159601: commit references a PR Date: Thu, 13 Oct 2011 08:26:35 +0000 (UTC) Author: qingli Date: Thu Oct 13 08:26:23 2011 New Revision: 226333 URL: http://svn.freebsd.org/changeset/base/226333 Log: MFC 226114 Remove the reference held on the loopback route when the interface address is being deleted. Only the last reference holder deletes the loopback route. All other delete operations just clear the IFA_RTSELF flag. PR: kern/159601 Submitted by: pluknet Reviewed by: discussed on net@ Approved by: re (kib) Modified: stable/9/sys/netinet/in.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) Modified: stable/9/sys/netinet/in.c ============================================================================== --- stable/9/sys/netinet/in.c Thu Oct 13 03:21:48 2011 (r226332) +++ stable/9/sys/netinet/in.c Thu Oct 13 08:26:23 2011 (r226333) @@ -1126,8 +1126,10 @@ in_scrubprefix(struct in_ifaddr *target, RT_LOCK(ia_ro.ro_rt); if (ia_ro.ro_rt->rt_refcnt <= 1) freeit = 1; - else + else if (flags & LLE_STATIC) { RT_REMREF(ia_ro.ro_rt); + target->ia_flags &= ~IFA_RTSELF; + } RTFREE_LOCKED(ia_ro.ro_rt); } if (freeit && (flags & LLE_STATIC)) { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 08:45:12 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB81710656D2 for ; Thu, 13 Oct 2011 08:45:12 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AC868FC16 for ; Thu, 13 Oct 2011 08:45:12 +0000 (UTC) Received: by iaky10 with SMTP id y10so1360814iak.13 for ; Thu, 13 Oct 2011 01:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0q08Fkm21nCtGVuTDsqxUsHvaiEjPlZv19tHqUuvH8Y=; b=kH2OFeolT/rHGT+elS1DQgWkNO1wE7KWC6zcJw7vCKD1SMpdTusLeQVNU/a13Ysw/r cWj0GUNCbACAP3vgQhKRGKQbccj0nSEbcINIeibmBnSnEXHoGrRvzK3RAdUQIP26ilpp 6zrzrA5Rp7n2jZUdWO8hbheksrcJl4ifNvLuQ= MIME-Version: 1.0 Received: by 10.231.5.225 with SMTP id 33mr1272661ibw.3.1318495511796; Thu, 13 Oct 2011 01:45:11 -0700 (PDT) Received: by 10.231.13.69 with HTTP; Thu, 13 Oct 2011 01:45:11 -0700 (PDT) Date: Thu, 13 Oct 2011 10:45:11 +0200 Message-ID: From: Sami Halabi To: "Li, Qing" , bz@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: recoomendations to a box X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 08:45:12 -0000 Hi, I'm using a quagga 0.99.17 box with dual cpu with 6C each,with 6GB Memory running on FreeBSD 8.1-R-p6. i wonder what do you think about this box on term of DDoS handling, pps handling and so on. if you have recommendations on how to improve max pps I appreciate it. the Nics configuration is as follows: I have a dual-10G card 82599EB connected to a users switch and to an upstream native exchange pointo in our country which handle regularly 1-2GB daily and a BraodCam BCM5709 card connected to an upstream in which i exchange a full routing table and a 100MBit line to the world. more i have a Quad-82571EB card, in which one port connected to another switch and other port connected to a MPD server for home users. Moreover I want to enable ECMP (MRADIX_PATH?) but i really don't know how it works and how tocontrol it and there are barely documentation on this,only things i read on the mailing lists and its not that clear to me. IPFW and traffic sharing is enabled (dummynet). Any recommendation are appreciated, your opinion is extremly important to me. Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 09:30:15 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC96110656D8 for ; Thu, 13 Oct 2011 09:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AC6C98FC0A for ; Thu, 13 Oct 2011 09:30:15 +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 p9D9UFZd053833 for ; Thu, 13 Oct 2011 09:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9D9UFJn053830; Thu, 13 Oct 2011 09:30:15 GMT (envelope-from gnats) Date: Thu, 13 Oct 2011 09:30:15 GMT Message-Id: <201110130930.p9D9UFJn053830@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/159602: 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, 13 Oct 2011 09:30:15 -0000 The following reply was made to PR kern/159602; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159602: commit references a PR Date: Thu, 13 Oct 2011 09:21:58 +0000 (UTC) Author: qingli Date: Thu Oct 13 09:21:49 2011 New Revision: 226337 URL: http://svn.freebsd.org/changeset/base/226337 Log: MFC 226120 PR: kern/159602 Submitted by: pluknet Approved by: re (kib) Modified: stable/9/sys/netinet/in.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) Modified: stable/9/sys/netinet/in.c ============================================================================== --- stable/9/sys/netinet/in.c Thu Oct 13 08:36:11 2011 (r226336) +++ stable/9/sys/netinet/in.c Thu Oct 13 09:21:49 2011 (r226337) @@ -1138,7 +1138,8 @@ in_scrubprefix(struct in_ifaddr *target, if (error == 0) target->ia_flags &= ~IFA_RTSELF; } - if (flags & LLE_STATIC) + if ((flags & LLE_STATIC) && + !(target->ia_ifp->if_flags & IFF_NOARP)) /* remove arp cache */ arp_ifscrub(target->ia_ifp, IA_SIN(target)->sin_addr.s_addr); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 09:50:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A634010656F7 for ; Thu, 13 Oct 2011 09:50:11 +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 7C68C8FC15 for ; Thu, 13 Oct 2011 09:50:11 +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 p9D9oB8V073516 for ; Thu, 13 Oct 2011 09:50:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9D9oBZb073515; Thu, 13 Oct 2011 09:50:11 GMT (envelope-from gnats) Date: Thu, 13 Oct 2011 09:50:11 GMT Message-Id: <201110130950.p9D9oBZb073515@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Svatopluk Kraus Cc: Subject: Re: kern/159601: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Svatopluk Kraus List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 09:50:11 -0000 The following reply was made to PR kern/159601; it has been noted by GNATS. From: Svatopluk Kraus To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159601: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction Date: Thu, 13 Oct 2011 11:19:07 +0200 Thanks for commit. I think the PR can be closed. From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 09:50:15 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1F1A10656FB for ; Thu, 13 Oct 2011 09:50:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 97CC38FC08 for ; Thu, 13 Oct 2011 09:50:15 +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 p9D9oFkw073538 for ; Thu, 13 Oct 2011 09:50:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9D9oF9L073537; Thu, 13 Oct 2011 09:50:15 GMT (envelope-from gnats) Date: Thu, 13 Oct 2011 09:50:15 GMT Message-Id: <201110130950.p9D9oF9L073537@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Svatopluk Kraus Cc: Subject: Re: kern/159603: [netinet] [patch] in_ifscrubprefix() - network route can be installed for interfaces marked down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Svatopluk Kraus List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 09:50:15 -0000 The following reply was made to PR kern/159603; it has been noted by GNATS. From: Svatopluk Kraus To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159603: [netinet] [patch] in_ifscrubprefix() - network route can be installed for interfaces marked down Date: Thu, 13 Oct 2011 11:21:16 +0200 Thanks for commit. I think the PR can be closed. From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 10:00:24 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 073F310656B9 for ; Thu, 13 Oct 2011 10:00:23 +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 C72D18FC13 for ; Thu, 13 Oct 2011 10:00:23 +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 p9DA0Ne2081779 for ; Thu, 13 Oct 2011 10:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9DA0N1W081777; Thu, 13 Oct 2011 10:00:23 GMT (envelope-from gnats) Date: Thu, 13 Oct 2011 10:00:23 GMT Message-Id: <201110131000.p9DA0N1W081777@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Svatopluk Kraus Cc: Subject: Re: kern/159602: [netinet] [patch] arp_ifscrub() is called even if IFF_NOARP flag is set X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Svatopluk Kraus List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 10:00:24 -0000 The following reply was made to PR kern/159602; it has been noted by GNATS. From: Svatopluk Kraus To: bug-followup@freebsd.org Cc: Subject: Re: kern/159602: [netinet] [patch] arp_ifscrub() is called even if IFF_NOARP flag is set Date: Thu, 13 Oct 2011 11:20:18 +0200 Thanks for commit. I think the PR can be closed. From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 14:03:39 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8AE106566B; Thu, 13 Oct 2011 14:03:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E628E8FC08; Thu, 13 Oct 2011 14:03:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9DE3cqe015328; Thu, 13 Oct 2011 14:03:38 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9DE3coZ015324; Thu, 13 Oct 2011 14:03:38 GMT (envelope-from glebius) Date: Thu, 13 Oct 2011 14:03:38 GMT Message-Id: <201110131403.p9DE3coZ015324@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/161123: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew 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, 13 Oct 2011 14:03:39 -0000 Synopsis: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Thu Oct 13 14:03:27 UTC 2011 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=161123 From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 14:04:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D481065679; Thu, 13 Oct 2011 14:04:10 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A75B98FC1B; Thu, 13 Oct 2011 14:04:10 +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 p9DE4AvP015442; Thu, 13 Oct 2011 14:04:10 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9DE48GH015434; Thu, 13 Oct 2011 14:04:08 GMT (envelope-from glebius) Date: Thu, 13 Oct 2011 14:04:08 GMT Message-Id: <201110131404.p9DE48GH015434@freefall.freebsd.org> To: dam@my.gd, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/161483: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew 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, 13 Oct 2011 14:04:10 -0000 Synopsis: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew State-Changed-From-To: open->closed State-Changed-By: glebius State-Changed-When: Thu Oct 13 14:03:56 UTC 2011 State-Changed-Why: Dup of kern/161123 http://www.freebsd.org/cgi/query-pr.cgi?pr=161483 From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 14:59:58 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 118BC106564A; Thu, 13 Oct 2011 14:59:58 +0000 (UTC) (envelope-from break19@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5A58FC16; Thu, 13 Oct 2011 14:59:57 +0000 (UTC) Received: by qyk10 with SMTP id 10so123424qyk.13 for ; Thu, 13 Oct 2011 07:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AlIJ/UEF+zYABY/7VwNZhOOyTffkoSqiiyVPH2iT/vc=; b=GdvZ+NaBadya6v33l6YvgGY/Lzdq/ZGx7jqlsDODOgJOikOczqHteqw2GZEFW3m8Sj ZXsuwhYA801+qg+1Umt1wGJ8bNM8JMRk7xEmJMu3jRA4ScGOggnPGPbljU026ZyJw3yA PH0VzQv9WnUMQyXs/UrG2lnZNAni6gUlEn+uw= MIME-Version: 1.0 Received: by 10.229.90.140 with SMTP id i12mr869283qcm.106.1318517996575; Thu, 13 Oct 2011 07:59:56 -0700 (PDT) Received: by 10.229.26.18 with HTTP; Thu, 13 Oct 2011 07:59:56 -0700 (PDT) In-Reply-To: <201110110720.04292.break19@gmail.com> References: <201110110720.04292.break19@gmail.com> Date: Thu, 13 Oct 2011 09:59:56 -0500 Message-ID: From: Chuck Burns To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 13 Oct 2011 14:59:58 -0000 Some more information.. I had mentioned this issue to someone on the ##FreeBSD irc channel, and he said that his father uses the urtw driver, on an i386 system, also running 8.2, but has no issues with kernel panics, and the only drops that he knows is due to his router, and resetting the router solves (but not the box, nor unplugging/replugging the dongle, neither of those are necessary to restore service) My system on the other hand just reports "No Carrier" in ifconfig, even after resetting the router, and other devices in the home can see it, and connect to it fine. I am not sure if this information is pertinent or not, but seeing as we've appeared to reach an impasse, with no more suggestions, requests for info... I figure the more info we can gather, the better... Chuck Burns From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 16:02:18 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA5A8106566C for ; Thu, 13 Oct 2011 16:02:18 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 3C82A8FC14 for ; Thu, 13 Oct 2011 16:02:18 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p9DG2HRx035080 for ; Thu, 13 Oct 2011 20:02:17 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p9DG2G3e035079 for net@FreeBSD.org; Thu, 13 Oct 2011 20:02:16 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 13 Oct 2011 20:02:16 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20111013160216.GU94905@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20110810160526.GO43567@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: new CARP implementation 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, 13 Oct 2011 16:02:18 -0000 Hello networkers, I've updated patch & README here: http://people.freebsd.org/~glebius/newcarp/ Going to commit it to head/ soon. Then I'd like to make a run through carp-related PRs, update documentation, settle things a bit... and then make more hacking to restore the arpbalance feature, as well as bring in ipbalance feature. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 16:40:06 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C3791065677 for ; Thu, 13 Oct 2011 16:40: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 D082A8FC0A for ; Thu, 13 Oct 2011 16:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9DGe5wH054641 for ; Thu, 13 Oct 2011 16:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9DGe5Pk054637; Thu, 13 Oct 2011 16:40:05 GMT (envelope-from gnats) Date: Thu, 13 Oct 2011 16:40:05 GMT Message-Id: <201110131640.p9DGe5Pk054637@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Wojciech A. Koszek" Cc: Subject: Re: kern/157418: [em] em driver lockup during boot on Supermicro X9SCM-F X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Wojciech A. Koszek" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 16:40:06 -0000 The following reply was made to PR kern/157418; it has been noted by GNATS. From: "Wojciech A. Koszek" To: bug-followup@freebsd.org, tomas@tutus.se Cc: Subject: Re: kern/157418: [em] em driver lockup during boot on Supermicro X9SCM-F Date: Thu, 13 Oct 2011 17:59:31 +0200 Hello, Looks like this is still present in FreeBSD 9.0-BETA3. Doesn't seem to cause any damage. It just shows a warning. I did limited testing: pinging remote side of a point-to-point Ethernet connection works. Full dmesg: http://freebsd.czest.pl/~wkoszek/stuff/freebsd/9.0-BETA3/dmesg.txt Interesting part: acquiring duplicate lock of same type: "network driver" 1st &dev_spec->swflag_mutex @ /usr/src/sys/dev/e1000/e1000_ich8lan.c:785 2nd &dev_spec->nvm_mutex @ /usr/src/sys/dev/e1000/e1000_ich8lan.c:751 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x8de _mtx_lock_flags() at _mtx_lock_flags+0x79 e1000_acquire_nvm_ich8lan() at e1000_acquire_nvm_ich8lan+0x1e e1000_read_nvm_ich8lan() at e1000_read_nvm_ich8lan+0x76 e1000_post_phy_reset_ich8lan() at e1000_post_phy_reset_ich8lan+0x1b1 e1000_reset_hw_ich8lan() at e1000_reset_hw_ich8lan+0x4c1 em_attach() at em_attach+0x11bd device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a acpi_pci_attach() at acpi_pci_attach+0x14f device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a acpi_pcib_attach() at acpi_pcib_attach+0x1a7 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x231 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a acpi_attach() at acpi_attach+0xbc5 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_acpi_attach() at nexus_acpi_attach+0x69 device_attach() at device_attach+0x69 bus_generic_new_pass() at bus_generic_new_pass+0xd6 bus_set_pass() at bus_set_pass+0x7a configure() at configure+0xa mi_startup() at mi_startup+0x77 btext() at btext+0x2c em0: Ethernet address: 5c:ff:35:0d:2b:ed ehci0: mem 0xf2828000-0xf28283ff irq 23 at device 26.0 on pci0 -- Wojciech A. Koszek wkoszek@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 18:43:01 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC76D106566C for ; Thu, 13 Oct 2011 18:43:01 +0000 (UTC) (envelope-from jgarciaitlist@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4C38FC1B for ; Thu, 13 Oct 2011 18:43:01 +0000 (UTC) Received: by iaky10 with SMTP id y10so2169551iak.13 for ; Thu, 13 Oct 2011 11:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ouTEt5cKkS6VMqH1NYZtvSYGEZX1HZWVTGNfoyQRTlE=; b=Ilu17nW7qXLRFEMIJIE2aZbB0EE8zHkB5F14Dx3LEW5RlPaNDxo2BSvL/37OvY3xQL KmLXRArDf/QRvsavHfsgIw7wZRaElm3HJnnzb54w6XPRNNznUdU6SY+WATympykONHix FhS090lMhDzPQ6cCDc/Tvp8OzrAZcCKTfUSus= MIME-Version: 1.0 Received: by 10.42.149.132 with SMTP id w4mr9244376icv.49.1318529815565; Thu, 13 Oct 2011 11:16:55 -0700 (PDT) Received: by 10.42.172.194 with HTTP; Thu, 13 Oct 2011 11:16:55 -0700 (PDT) Date: Thu, 13 Oct 2011 14:16:55 -0400 Message-ID: From: justino garcia To: "Ubuntu user technical support, not for general discussions" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: father of unix and C dies 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, 13 Oct 2011 18:43:01 -0000 http://www.zdnet.com/news/dennis-ritchie-father-of-unix-and-c-dies/6314570 -- Justin IT-TECH From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 18:48:13 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8BC3106564A; Thu, 13 Oct 2011 18:48:13 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA678FC0C; Thu, 13 Oct 2011 18:48:12 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9DIlnh7009931; Thu, 13 Oct 2011 11:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318531670; bh=aNa/x0Xfiw18RF4OAUgPJyzyXfGv/goT+1DEvEQoqUE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=XwN7cPguoUDmtrEX6VGzHCVA7KTi1ACkjTMMIBoUjNUtlivLLGKXm9wJjC/QaJO7j zy/q/yrhae+hBkXnZMwn9NNYQ9e0pk+BSzukx/fBW4fJe2TT9rmFjpNQx2IEP4DEjE WJHdNOOBuYcNUmyebGaTpux1osuONn5F8T3jPVvo= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20111011224935.GC5661@michelle.cdnetworks.com> References: <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> <20111011224935.GC5661@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Oct 2011 11:47:48 -0700 Message-ID: <1318531668.2658.16.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI 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, 13 Oct 2011 18:48:13 -0000 On Tue, 2011-10-11 at 15:49 -0700, YongHyeon PYUN wrote: > On Tue, Oct 11, 2011 at 12:52:25PM -0700, Sean Bruno wrote: > > > > > > > The Broadcom MFW is configured to load/not load through an NVRAM > > > > > option that is likely not affected by the iDRAC BIOS settings. > > > > > To disable MFW you'd need to run the user diagnostic utility > > > > > (UXDIAG.EXE) with the following command line: > > > > > > > > > > C:\>uxdiag -mfw 0 > > > > > > > > > > To turn it back on run the following: > > > > > > > > > > C:\>uxdiag -mfw 1 > > > > > > > > > > You can find a bootable CD with the user diagnostic here: > > > > > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso > > > > > > > > > > Dave > > > > > > > > > > > > > Ah, ok. > > > > > > > > > > > > Pyun: > > > > > > > > Should I do this on a host and validate your changes? > > > > > > > > > > That would be great if you can. Because some part of code is not > > > executed in my patch when firmware is not running. Previously > > > bce(4) executed that code regardless of firmware running state. > > > > > > > Sean > > > > > > > > > > > > > > Ran this on my Dell R410. I can clearly see that the tool is > > "disabling" the MFW bit, and that the dell bios interface to the IPMI > > controller/DRAC is impaired, however ... > > > > The system still thinks that the MFW bit is "ON" and proceeds normally > > in this case. The code still fails to detect that MFW is disabled. > > > > In addition, the IPMI driver attaches to "something" and I can poke at > > it via ipmitool. So, from the driver perspective, the attempt to detect > > MFW enabled doesn't work as the chipset still thinks that its "on". > > > > My patch relied on existing bce(4)'s logic for management firmware > state since public data sheet does not mention anything about that. > Probably David can give us more information. > > > I've commented out the code block that we're trying to work around in > > the yahoo code base for now. > > > > Sean > > As a follow up to this, Yahoo has decided to put the Dell "DRAC" adapter into their machines to work around this issue. So, all of this will go away on our existing systems. Since this technically affects all O/S versions of *nix I'm dropping this message in to close the email thread so others can see that its not a thing that -net@ can fix. Sean From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 20:49:37 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BCF8106566C for ; Thu, 13 Oct 2011 20:49:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9EBC98FC08 for ; Thu, 13 Oct 2011 20:49:36 +0000 (UTC) Received: by wyj26 with SMTP id 26so3302420wyj.13 for ; Thu, 13 Oct 2011 13:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yB5b+1S6mAUBWQUDpIUeBiokNcyoW7IJrYNDomWxQM4=; b=wQxzML7Cru/HpbG54zXJJRsaHv4ga6h1ywBOKn21/hHLlkrmmF2lRLO/N/MMp9kLi/ i0yZ2gsjgRopjVvsfA0YycQkKjS+sYrnmCBnDVd88glqF8+23PpLb3C/mQYByy0V25r/ hHyaXHnEcR6Z+5Od2xIzVs1MvFucVUPrXPDg8= Received: by 10.216.135.145 with SMTP id u17mr449218wei.85.1318538975342; Thu, 13 Oct 2011 13:49:35 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id a12sm9150301wbo.9.2011.10.13.13.49.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 13:49:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 13 Oct 2011 13:47:47 -0700 From: YongHyeon PYUN Date: Thu, 13 Oct 2011 13:47:47 -0700 To: perryh@pluto.rain.com Message-ID: <20111013204747.GA13219@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4e969a67.YJyWMt0xI7pFL+xJ%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e969a67.YJyWMt0xI7pFL+xJ%perryh@pluto.rain.com> User-Agent: Mutt/1.4.2.3i Cc: fodillemlinkarim@gmail.com, freebsd-net@freebsd.org, kob6558@gmail.com Subject: Re: if_msk.c link negotiation / packet drops 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, 13 Oct 2011 20:49:37 -0000 On Thu, Oct 13, 2011 at 12:59:35AM -0700, perryh@pluto.rain.com wrote: > YongHyeon PYUN wrote: > > On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > > > ... why are we ORing the same call twice isn't the same thing > > > as calling it once: > > > > > > bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > > > > The E1000_SR_LINK_STATUS bit is latched low so it should be read > > twice. > > It might not be a bad idea to check the generated code to be sure > that the read _is_ being done twice. An optimizer might well come > to the same conclusion as Karim, and discard the "redundant" second > instance (unless there's a "volatile" declaration somewhere in the > expansion of PHY_READ, to explicitly indicate that it has side > effects). Last time I checked it, compiler generated correct code. Tried again on amd64 and I can still see the code is there. From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 21:02:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2D22106564A for ; Thu, 13 Oct 2011 21:02:59 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 487C88FC18 for ; Thu, 13 Oct 2011 21:02:58 +0000 (UTC) Received: by wyj26 with SMTP id 26so3318766wyj.13 for ; Thu, 13 Oct 2011 14:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SgSaRNBvp/857XTjjABXSKxdBr9nvGN8/nOJA6VTUn4=; b=LFAS0Pum9djFl4KFksIWXqjTNNtHJ56lQBs3PbB/miDtSGr2XZ8ylJoUqg4JlW01wC 64tRizVemx74374jA8hGvRJuz2OZM7M6pruvfeXmo7HYY6rZltvFaTIbQpQzT+6De+o7 leZqEan4aOi0mgvz10JpKnzzhkucVmVoZWDus= MIME-Version: 1.0 Received: by 10.227.166.69 with SMTP id l5mr1807424wby.34.1318539778068; Thu, 13 Oct 2011 14:02:58 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Thu, 13 Oct 2011 14:02:58 -0700 (PDT) In-Reply-To: <20111013204747.GA13219@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4e969a67.YJyWMt0xI7pFL+xJ%perryh@pluto.rain.com> <20111013204747.GA13219@michelle.cdnetworks.com> Date: Thu, 13 Oct 2011 17:02:58 -0400 Message-ID: From: Arnaud Lacombe To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fodillemlinkarim@gmail.com, freebsd-net@freebsd.org, perryh@pluto.rain.com, kob6558@gmail.com Subject: Re: if_msk.c link negotiation / packet drops 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, 13 Oct 2011 21:02:59 -0000 Hi, On Thu, Oct 13, 2011 at 4:47 PM, YongHyeon PYUN wrote: > On Thu, Oct 13, 2011 at 12:59:35AM -0700, perryh@pluto.rain.com wrote: >> YongHyeon PYUN wrote: >> > On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: >> > > ... why are we ORing the same call twice isn't the same thing >> > > as calling it once: >> > > >> > > bmsr =3D PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >> > >> > The E1000_SR_LINK_STATUS bit is latched low so it should be read >> > twice. >> >> It might not be a bad idea to check the generated code to be sure >> that the read _is_ being done twice. =A0An optimizer might well come >> to the same conclusion as Karim, and discard the "redundant" second >> instance (unless there's a "volatile" declaration somewhere in the >> expansion of PHY_READ, to explicitly indicate that it has side >> effects). > > Last time I checked it, compiler generated correct code. > Tried again on amd64 and I can still see the code is there. > What about other architecture (especially i386) ? which optimization level did you use ? which compiler version ? About the last question, I know for sure that there has been change in FreeBSD's gcc between 7-STABLE, and FreeBSD -CURRENT. I agree with perryh@ than such hardware requirement _requires_ being explicit in the code, ie proper `volatile' marking. - Arnaud From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 21:05:21 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8C6106564A; Thu, 13 Oct 2011 21:05:21 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 89D5B8FC15; Thu, 13 Oct 2011 21:05:21 +0000 (UTC) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 13 Oct 2011 14:05:40 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 13 Oct 2011 13:58:31 -0700 From: "David Christensen" To: "Sean Bruno" , "pyunyh@gmail.com" Date: Thu, 13 Oct 2011 13:58:30 -0700 Thread-Topic: bce(4) with IPMI Thread-Index: AcyIT1oMLPwVtPlAR1qoF9o5jGYjJgBmp91w Message-ID: <5D267A3F22FD854F8F48B3D2B523819385F366A48A@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 62898D2E3JW5100106-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI 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, 13 Oct 2011 21:05:21 -0000 PiBSYW4gdGhpcyBvbiBteSBEZWxsIFI0MTAuICBJIGNhbiBjbGVhcmx5IHNlZSB0aGF0IHRoZSB0 b29sIGlzDQo+ICJkaXNhYmxpbmciIHRoZSBNRlcgYml0LCBhbmQgdGhhdCB0aGUgZGVsbCBiaW9z IGludGVyZmFjZSB0byB0aGUgSVBNSQ0KPiBjb250cm9sbGVyL0RSQUMgaXMgaW1wYWlyZWQsIGhv d2V2ZXIgLi4uDQo+IA0KPiBUaGUgc3lzdGVtIHN0aWxsIHRoaW5rcyB0aGF0IHRoZSBNRlcgYml0 IGlzICJPTiIgYW5kIHByb2NlZWRzIG5vcm1hbGx5DQo+IGluIHRoaXMgY2FzZS4gIFRoZSBjb2Rl IHN0aWxsIGZhaWxzIHRvIGRldGVjdCB0aGF0IE1GVyBpcyBkaXNhYmxlZC4NCj4gDQo+IEluIGFk ZGl0aW9uLCB0aGUgSVBNSSBkcml2ZXIgYXR0YWNoZXMgdG8gInNvbWV0aGluZyIgYW5kIEkgY2Fu IHBva2UgYXQNCj4gaXQgdmlhIGlwbWl0b29sLiAgU28sIGZyb20gdGhlIGRyaXZlciBwZXJzcGVj dGl2ZSwgdGhlIGF0dGVtcHQgdG8gZGV0ZWN0DQo+IE1GVyBlbmFibGVkIGRvZXNuJ3Qgd29yayBh cyB0aGUgY2hpcHNldCBzdGlsbCB0aGlua3MgdGhhdCBpdHMgIm9uIi4NCj4gDQo+IEkndmUgY29t bWVudGVkIG91dCB0aGUgY29kZSBibG9jayB0aGF0IHdlJ3JlIHRyeWluZyB0byB3b3JrIGFyb3Vu ZCBpbg0KPiB0aGUgeWFob28gY29kZSBiYXNlIGZvciBub3cuDQoNCkkgaGF2ZSBhbiBSMjEwIGFu ZCBydW5uaW5nIHRoZSB1eGRpYWcgY29tbWFuZCBkZWZpbml0ZWx5IGRpc2FibGVkIA0KbWFuYWdl bWVudCBmaXJtd2FyZSBvbiBteSBzeXN0ZW06DQoNCj09PVtyb290XSB+ICMgZG1lc2cgfCBncmVw IGJjZQ0KYmNlMDogPEJyb2FkY29tIE5ldFh0cmVtZSBJSSBCQ001NzE2IDEwMDBCYXNlLVQgKEMw KT4gbWVtIDB4ZGEwMDAwMDAtMHhkYmZmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2ky DQptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmNlMA0KYmNlMDogRXRoZXJuZXQgYWRkcmVzczogYjg6 YWM6NmY6ODc6OTU6ZjENCmJjZTA6IEFTSUMgKDB4NTcwOTIwMDgpOyBSZXYgKEMwKTsgQnVzIChQ Q0llIHg0LCAyLjVHYnBzKTsgQi9DICg1LjIuMik7IEJ1ZnMgKFJYOjI7VFg6MjtQRzo4KTsgRmxh Z3MgKFNQTFR8TVNJKQ0KYmNlMTogPEJyb2FkY29tIE5ldFh0cmVtZSBJSSBCQ001NzE2IDEwMDBC YXNlLVQgKEMwKT4gbWVtIDB4ZGMwMDAwMDAtMHhkZGZmZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDAu MSBvbiBwY2kyDQptaWlidXMxOiA8TUlJIGJ1cz4gb24gYmNlMQ0KYmNlMTogRXRoZXJuZXQgYWRk cmVzczogYjg6YWM6NmY6ODc6OTU6ZjINCmJjZTE6IEFTSUMgKDB4NTcwOTIwMDgpOyBSZXYgKEMw KTsgQnVzIChQQ0llIHg0LCAyLjVHYnBzKTsgQi9DICg1LjIuMik7IEJ1ZnMgKFJYOjI7VFg6MjtQ Rzo4KTsgRmxhZ3MgKFNQTFR8TVNJKQ0KYmNlMDogR2lnYWJpdCBsaW5rIHVwIQ0KYmNlMDogR2ln YWJpdCBsaW5rIHVwIQ0KYmNlMTogR2lnYWJpdCBsaW5rIHVwIQ0KYmNlMTogR2lnYWJpdCBsaW5r IHVwIQ0KPT09W3Jvb3RdIH4gIw0KDQpEYXZlDQo= From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 21:49:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F836106564A for ; Thu, 13 Oct 2011 21:49:05 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id BF9888FC13 for ; Thu, 13 Oct 2011 21:49:04 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9DLn3VG049812; Thu, 13 Oct 2011 23:49:03 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9DLn37c049811; Thu, 13 Oct 2011 23:49:03 +0200 (CEST) (envelope-from marius) Date: Thu, 13 Oct 2011 23:49:03 +0200 From: Marius Strobl To: YongHyeon PYUN Message-ID: <20111013214903.GH39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111012235707.GD9138@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII 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, 13 Oct 2011 21:49:05 -0000 On Wed, Oct 12, 2011 at 04:57:07PM -0700, YongHyeon PYUN wrote: > On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote: > > On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote: > > > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > > > > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > > > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > > > > and it's useful for porting embedded devices. > > > > > > > > > > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > > > > which (im)ports these and converts drivers to take advantage of it here: > > > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > > > > > > > Patch looks good to me. > > > > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > > > > and xe(4))? > > > > > > > > > > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > > > > I've started with the drivers were the corresponding NetBSD one also > > > > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > > > > aware that these should also be convertible to the common code, I just > > > > didn't get around to it so far. As for lge(4) that driver has some > > > > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've > > > > > > Ah, I just blindly grepped the string, sorry. > > > > > > > previously missed rl(4) as I was only grepping beneath sys/dev and I > > > > currently can't explain why I missed xe(4), so thanks for mentioning > > > > these. > > > > In my experience MII bitbang'ing is very fragile though and subtle > > > > changes may break it so I don't want to commit these without testing > > > > or in the case of smc(4) where at least the corresponding NetBSD > > > > driver already uses the common code. Unfortunately, I only have > > > > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > > > > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > > > > happen to have hardware to test the remaining drivers, i.e. nge(4), > > > > sis(4), ste(4), wb(4) and xe(4)? > > > > > > > > > > I have access to sis(4) and ste(4). I also have a nge(4) but I'm > > > not able to access to the hardware, at least in US. > > > > > > > It would be great if you could test sis(4) and ste(4). > > > > Ok, will do in this week. > I just noticed that rl(4) only does MII bitbang'ing for the 8129 but I only have a 8139. Do you happen do have the former so you could test the patch with it? The patch is now complete as far as I'm willing to convert drivers. What's left is ed(4) and xe(4). The former has several chip specific things interwinded and I'm unsure whether it can be converted to use the common code; I'd at least like to have hardware for the special cases to give that a try. Xe(4) currently doesn't use miibus(4) (but should) so I don't see much point in adding a dependency on miibus(4) just for the bitbang'ing code on it (nor do I for not adding the common code to miibus(4)). Marius From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 21:55:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0EA106566B for ; Thu, 13 Oct 2011 21:55:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CADC88FC08 for ; Thu, 13 Oct 2011 21:55:52 +0000 (UTC) Received: by wyj26 with SMTP id 26so3377560wyj.13 for ; Thu, 13 Oct 2011 14:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IKruggogk1N0EZSvAoa0sUN1aghbkSJaIlVPEyVYjFA=; b=SUomTb/ewpejWsoltoyTLtXH8Hck6Z/RVEXGonKfJwj2QAnFMS+00cwbGbXln2F26I NOeWaSs/mHbzmYo6LyfASt14LrU/NYM6gPREUyf9R5gXwUoXlQy0hCUpQKY+Phm/fBq5 FtVyLcM+65oloWru+ZoSOo/TLL4VnfoIlXkw0= Received: by 10.216.230.83 with SMTP id i61mr2105263weq.54.1318542951682; Thu, 13 Oct 2011 14:55:51 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id ek13sm9633604wbb.3.2011.10.13.14.55.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Oct 2011 14:55:50 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 13 Oct 2011 14:54:05 -0700 From: YongHyeon PYUN Date: Thu, 13 Oct 2011 14:54:05 -0700 To: Arnaud Lacombe Message-ID: <20111013215405.GB13219@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4e969a67.YJyWMt0xI7pFL+xJ%perryh@pluto.rain.com> <20111013204747.GA13219@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: fodillemlinkarim@gmail.com, freebsd-net@freebsd.org, perryh@pluto.rain.com, kob6558@gmail.com Subject: Re: if_msk.c link negotiation / packet drops 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, 13 Oct 2011 21:55:53 -0000 On Thu, Oct 13, 2011 at 05:02:58PM -0400, Arnaud Lacombe wrote: > Hi, > > On Thu, Oct 13, 2011 at 4:47 PM, YongHyeon PYUN wrote: > > On Thu, Oct 13, 2011 at 12:59:35AM -0700, perryh@pluto.rain.com wrote: > >> YongHyeon PYUN wrote: > >> > On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > >> > > ... why are we ORing the same call twice isn't the same thing > >> > > as calling it once: > >> > > > >> > > bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >> > > >> > The E1000_SR_LINK_STATUS bit is latched low so it should be read > >> > twice. > >> > >> It might not be a bad idea to check the generated code to be sure > >> that the read _is_ being done twice. ?An optimizer might well come > >> to the same conclusion as Karim, and discard the "redundant" second > >> instance (unless there's a "volatile" declaration somewhere in the > >> expansion of PHY_READ, to explicitly indicate that it has side > >> effects). > > > > Last time I checked it, compiler generated correct code. > > Tried again on amd64 and I can still see the code is there. > > > What about other architecture (especially i386) ? which optimization Don't use i386 so I don't know. > level did you use ? which compiler version ? CURRENT, default optimization(O2). > > About the last question, I know for sure that there has been change in > FreeBSD's gcc between 7-STABLE, and FreeBSD -CURRENT. > > I agree with perryh@ than such hardware requirement _requires_ being > explicit in the code, ie proper `volatile' marking. > I'm not saying adding more safe belt is bad idea. If you have a patch please submit it. I don't like touching every PHY drivers. > - Arnaud > From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 22:11:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59E46106564A for ; Thu, 13 Oct 2011 22:11:51 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id E26178FC14 for ; Thu, 13 Oct 2011 22:11:49 +0000 (UTC) Received: by wwg7 with SMTP id 7so303006wwg.1 for ; Thu, 13 Oct 2011 15:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Fhw+NKNDevV1FHlJm+Xoxe99vLBzB7+qnu7fZ400utc=; b=DyX+K/dZOnxZXahkyWq7Bn8gRVCuAdTZDpliML/tMOb8I0Le67OhMg3xb123qtxeqI ShmJ06ynvj343OvrH4dDaP9/1MYNqvnfCRZFkkWfjCZ37iKC62OLbXK3VnId8Tk06Brw s6CMcWZPFk3SiyecPqMQy9iS5gewJmsGePLms= MIME-Version: 1.0 Received: by 10.216.210.216 with SMTP id u66mr127245weo.49.1318543908227; Thu, 13 Oct 2011 15:11:48 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Thu, 13 Oct 2011 15:11:48 -0700 (PDT) In-Reply-To: <20111013215405.GB13219@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4e969a67.YJyWMt0xI7pFL+xJ%perryh@pluto.rain.com> <20111013204747.GA13219@michelle.cdnetworks.com> <20111013215405.GB13219@michelle.cdnetworks.com> Date: Thu, 13 Oct 2011 18:11:48 -0400 Message-ID: From: Arnaud Lacombe To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fodillemlinkarim@gmail.com, freebsd-net@freebsd.org, perryh@pluto.rain.com, kob6558@gmail.com Subject: Re: if_msk.c link negotiation / packet drops 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, 13 Oct 2011 22:11:51 -0000 Hi, On Thu, Oct 13, 2011 at 5:54 PM, YongHyeon PYUN wrote: > On Thu, Oct 13, 2011 at 05:02:58PM -0400, Arnaud Lacombe wrote: >> Hi, >> >> On Thu, Oct 13, 2011 at 4:47 PM, YongHyeon PYUN wrote= : >> > On Thu, Oct 13, 2011 at 12:59:35AM -0700, perryh@pluto.rain.com wrote: >> >> YongHyeon PYUN wrote: >> >> > On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: >> >> > > ... why are we ORing the same call twice isn't the same thing >> >> > > as calling it once: >> >> > > >> >> > > bmsr =3D PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >> >> > >> >> > The E1000_SR_LINK_STATUS bit is latched low so it should be read >> >> > twice. >> >> >> >> It might not be a bad idea to check the generated code to be sure >> >> that the read _is_ being done twice. ?An optimizer might well come >> >> to the same conclusion as Karim, and discard the "redundant" second >> >> instance (unless there's a "volatile" declaration somewhere in the >> >> expansion of PHY_READ, to explicitly indicate that it has side >> >> effects). >> > >> > Last time I checked it, compiler generated correct code. >> > Tried again on amd64 and I can still see the code is there. >> > >> What about other architecture (especially i386) ? which optimization > > Don't use i386 so I don't know. > >> level did you use ? which compiler version ? > > CURRENT, default optimization(O2). > >> >> About the last question, I know for sure that there has been change in >> FreeBSD's gcc between 7-STABLE, and FreeBSD -CURRENT. >> >> I agree with perryh@ than such hardware requirement _requires_ being >> explicit in the code, ie proper `volatile' marking. >> > > I'm not saying adding more safe belt is bad idea. If you have a > patch please submit it. I don't like touching every PHY drivers. > Actually, it should not be needed, the generic implementation of PHY_READREG() is doing an MIIBUS_READREG() which is forwarded to the parent (miibusN here), then its parent (msk(4)). my bad, - Arnaud >> =A0- Arnaud >> > From owner-freebsd-net@FreeBSD.ORG Thu Oct 13 22:56:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42A54106564A; Thu, 13 Oct 2011 22:56:18 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id E23B68FC12; Thu, 13 Oct 2011 22:56:17 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p9DMtwMg019386; Thu, 13 Oct 2011 15:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1318546559; bh=1ydwHYJr5mLK/yxp+aFCLxeGIV2bQwoSmiNxpo92aFE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=MYVQ0vfFwtqKI4J5HdLEkVtWJtrdmvYFgyUldKxB2+V0YF70FjfyyAzDjlK8Mplm+ wWfmGdobVX59VTLwwvdpZaovQsOjqmX1ht4oTWfKS196bbOP4eb/nJkpJ++oBR24qQ 7skkDUMJdKKYeg1TK6N/5mOSp5kA1nYn159Ilmd8= From: Sean Bruno To: David Christensen In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819385F366A48A@IRVEXCHCCR01.corp.ad.broadcom.com> References: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111007205254.GC11808@michelle.cdnetworks.com> <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> <5D267A3F22FD854F8F48B3D2B523819385F366A48A@IRVEXCHCCR01.corp.ad.broadcom.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 13 Oct 2011 15:55:58 -0700 Message-ID: <1318546558.2658.18.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-1.fc14) Content-Transfer-Encoding: 7bit Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Pyun YongHyeon Subject: RE: bce(4) with IPMI 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, 13 Oct 2011 22:56:18 -0000 On Thu, 2011-10-13 at 13:58 -0700, David Christensen wrote: > > Ran this on my Dell R410. I can clearly see that the tool is > > "disabling" the MFW bit, and that the dell bios interface to the IPMI > > controller/DRAC is impaired, however ... > > > > The system still thinks that the MFW bit is "ON" and proceeds normally > > in this case. The code still fails to detect that MFW is disabled. > > > > In addition, the IPMI driver attaches to "something" and I can poke at > > it via ipmitool. So, from the driver perspective, the attempt to detect > > MFW enabled doesn't work as the chipset still thinks that its "on". > > > > I've commented out the code block that we're trying to work around in > > the yahoo code base for now. > > I have an R210 and running the uxdiag command definitely disabled > management firmware on my system: > > ===[root] ~ # dmesg | grep bce > bce0: mem 0xda000000-0xdbffffff irq 16 at device 0.0 on pci2 > miibus0: on bce0 > bce0: Ethernet address: b8:ac:6f:87:95:f1 > bce0: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI) > bce1: mem 0xdc000000-0xddffffff irq 17 at device 0.1 on pci2 > miibus1: on bce1 > bce1: Ethernet address: b8:ac:6f:87:95:f2 > bce1: ASIC (0x57092008); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (5.2.2); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI) > bce0: Gigabit link up! > bce0: Gigabit link up! > bce1: Gigabit link up! > bce1: Gigabit link up! > ===[root] ~ # > > Dave Yeah, that was my results as well. But when I ran Pyun's modifcations to detect this case, there was no change. (this was an r410 btw). Sean From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 08:49:45 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EEA2106564A; Fri, 14 Oct 2011 08:49:45 +0000 (UTC) (envelope-from s.dave.jones@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 525568FC1A; Fri, 14 Oct 2011 08:49:44 +0000 (UTC) Received: by vws11 with SMTP id 11so969809vws.13 for ; Fri, 14 Oct 2011 01:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I5ioUnKLu8HSczsHc3fuY99puN9Mk00LMkLPPG/NMIo=; b=Yu5BLKa+B4sPYFiIF3e5DltMRDaqBgSNalovrBQoXGv9qb1NcwbaJo6rewCJ+APFXt rQbTNCKYBqhsHRJv0OVvxGI+DjlBXUnZbbrSeRcU980Tns4JM2GDn/lNAzqn0SU0p0Td ZeGt6g9RbTmSoZTu8VaE369VHVR/+TQnkJUZ8= MIME-Version: 1.0 Received: by 10.52.94.97 with SMTP id db1mr7618000vdb.67.1318582183627; Fri, 14 Oct 2011 01:49:43 -0700 (PDT) Received: by 10.52.186.170 with HTTP; Fri, 14 Oct 2011 01:49:43 -0700 (PDT) In-Reply-To: <86fwiy91ty.fsf@in138.ua3> References: <8662kcigif.fsf@kopusha.home.net> <86y5x0ooik.fsf@in138.ua3> <86fwiy91ty.fsf@in138.ua3> Date: Fri, 14 Oct 2011 16:49:43 +0800 Message-ID: From: dave jones To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , "K. Macy" , "freebsd-net@freebsd.org" , bz@freebsd.org, Robert Watson , Arnaud Lacombe Subject: Re: Kernel panic on FreeBSD 9.0-beta2 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, 14 Oct 2011 08:49:45 -0000 2011/10/12 Mikolaj Golub wrote: > > On Wed, 12 Oct 2011 09:53:34 +0800 dave jones wrote: > > =A0dj> On Fri, Oct 7, 2011 at 9:12 AM, dave jones =A0wrote: > =A0>> 2011/10/4 Mikolaj Golub : > =A0>>> > =A0>>> On Sat, 1 Oct 2011 14:15:45 +0800 dave jones wrote: > =A0>>> > =A0>>> =A0dj> On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote: > =A0>>> =A0>> > =A0>>> =A0>> On Wed, 28 Sep 2011, Mikolaj Golub wrote: > =A0>>> =A0>> > =A0>>> =A0>>> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote: > =A0>>> =A0>>> > =A0>>> =A0>>> KM> Sorry, didn't look at the images (limited bw), I've see= n something KM> > =A0>>> =A0>>> like this before in timewait. This "can't happen" with UDP = so will be KM> > =A0>>> =A0>>> interested in learning more about the bug. > =A0>>> =A0>>> > =A0>>> =A0>>> The panic can be easily triggered by this: > =A0>>> =A0>> > =A0>>> =A0>> Hi: > =A0>>> =A0>> > =A0>>> =A0>> Just catching up on this thread. =A0I think the analysis her= e is generally > =A0>>> =A0>> right: in 9.0, you're much more likely to see an inpcb with = its in_socket > =A0>>> =A0>> pointer cleared in the hash list than in prior releases, and > =A0>>> =A0>> in_pcbbind_setup() trips over this. > =A0>>> =A0>> > =A0>>> =A0>> However, at least on first glance (and from the perspective = of invariants > =A0>>> =A0>> here), I think the bug is actualy that in_pcbbind_setup() is= asking > =A0>>> =A0>> in_pcblookup_local() for an inpcb and then access the return= ed inpcb's > =A0>>> =A0>> in_socket pointer without acquiring a lock on the inpcb. =A0= Structurally, it > =A0>>> =A0>> can't acquire this lock for lock order reasons -- it already= holds the lock > =A0>>> =A0>> on its own inpcb. =A0Therefore, we should only access fields= that are safe to > =A0>>> =A0>> follow in an inpcb when you hold a reference via the hash lo= ck and not a > =A0>>> =A0>> lock on the inpcb itself, which appears generally OK (+/-) f= or all the > =A0>>> =A0>> fields in that clause but the t->inp_socket->so_options dere= ference. > =A0>>> =A0>> > =A0>>> =A0>> A preferred fix would cache the SO_REUSEPORT flag in an inpc= b-layer field, > =A0>>> =A0>> such as inp_flags2, giving us access to its value without ha= ving to walk > =A0>>> =A0>> into the attached (or not) socket. > =A0>>> =A0>> > =A0>>> =A0>> This raises another structural question, which is whether we= need a new > =A0>>> =A0>> inp_foo flags field that is protected explicitly by the hash= lock, and not > =A0>>> =A0>> by the inpcb lock, which could hold fields relevant to addre= ss binding. =A0I > =A0>>> =A0>> don't think we need to solve that problem in this context, a= s a slightly > =A0>>> =A0>> race on SO_REUSEPORT is likely acceptable. > =A0>>> =A0>> > =A0>>> =A0>> The suggested fix does perform the desired function of expli= citly detaching > =A0>>> =A0>> the inpcb from the hash list before the socket is disconnect= ed from the > =A0>>> =A0>> inpcb. However, it's incomplete in that the invariant that's= being broken is > =A0>>> =A0>> also relied on for other protocols (such as raw sockets). = =A0The correct > =A0>>> =A0>> invariant is that inp_socket is safe to follow unconditional= ly if an inpcb > =A0>>> =A0>> is locked and INP_DROPPED isn't set -- the bug is in "locked= " not in > =A0>>> =A0>> "INP_DROPPED", which is why I think this is the wrong fix, e= ven though it > =A0>>> =A0>> prevents a panic :-). > =A0>>> > =A0>>> =A0dj> Hello Robert, > =A0>>> > =A0>>> =A0dj> Thank you for taking your valuable time to find out the pro= blem. > =A0>>> =A0dj> Since I don't have idea about network internals, would you = have a patch > =A0>>> =A0dj> about this? I'd be glad to test it, thanks again. > =A0>>> > =A0>>> Here is the patch that implements what Robert suggests. > =A0>>> > =A0>>> Dave, could you test it? > =A0>> > =A0>> Sure. Thanks for cooking the patch. > =A0>> Machines have been running two days now without panic. > > Thank you for testing it. > > =A0dj> Is there any plan to commit your fix? Thank you. > =A0dj> I'd upgrade to 9.0-release from beta-2 once it's released. > > I have an upgraded version of the patch, which is under review now. I hav= e > been waiting for the response before asking you to test it, but it would = be > great if you try it not waiting :-). > > As it was pointed by Robert the previous version introduced a regression: > SO_REUSEPORT was ignored if setsockopt was called after bind (the old cac= hed > value was still used). So the updated version fixes this and also contain= s > several other fixes, the most important among them is that it fixes the p= anic > for IPv6 bind case too. Thanks for cooking the patch. Machines have been running up days without any panic. > -- > Mikolaj Golub Regards, Dave. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 18:02:07 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB40106566B; Fri, 14 Oct 2011 18:02:07 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 247D18FC17; Fri, 14 Oct 2011 18:02:06 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p9EI25E1045240; Fri, 14 Oct 2011 22:02:06 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p9EI25BR045239; Fri, 14 Oct 2011 22:02:05 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Oct 2011 22:02:05 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20111014180205.GG94905@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> <4E9874C5.8070309@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4E9874C5.8070309@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 14 Oct 2011 18:02:07 -0000 On Fri, Oct 14, 2011 at 07:43:33PM +0200, Andre Oppermann wrote: A> On 13.10.2011 18:02, Gleb Smirnoff wrote: A> > Hello networkers, A> > A> > I've updated patch& README here: A> > A> > http://people.freebsd.org/~glebius/newcarp/ A> > A> > Going to commit it to head/ soon. Then I'd like to make A> > a run through carp-related PRs, update documentation, settle A> > things a bit... and then make more hacking to restore the A> > arpbalance feature, as well as bring in ipbalance feature. A> A> Excellent! Great work. Looks good. A> A> One minor nit: Carp is directly enabled by specifying the vhid. A> Would it be possible to introduce the keyword "carp" and "-carp" A> to actually enable/disable an interface for carp? We could add additional interface flag, but I don't see point in enabling/disabling CARP per-interface. btw, you can configure a VHID and don't attach any addresses to it. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 18:10:15 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577E6106568D for ; Fri, 14 Oct 2011 18:10:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id BF4458FC0C for ; Fri, 14 Oct 2011 18:10:14 +0000 (UTC) Received: (qmail 61761 invoked from network); 14 Oct 2011 16:24:24 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Oct 2011 16:24:24 -0000 Message-ID: <4E9874C5.8070309@freebsd.org> Date: Fri, 14 Oct 2011 19:43:33 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Gleb Smirnoff References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> In-Reply-To: <20111013160216.GU94905@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 14 Oct 2011 18:10:15 -0000 On 13.10.2011 18:02, Gleb Smirnoff wrote: > Hello networkers, > > I've updated patch& README here: > > http://people.freebsd.org/~glebius/newcarp/ > > Going to commit it to head/ soon. Then I'd like to make > a run through carp-related PRs, update documentation, settle > things a bit... and then make more hacking to restore the > arpbalance feature, as well as bring in ipbalance feature. Excellent! Great work. Looks good. One minor nit: Carp is directly enabled by specifying the vhid. Would it be possible to introduce the keyword "carp" and "-carp" to actually enable/disable an interface for carp? -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 18:14:35 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189CA1065676 for ; Fri, 14 Oct 2011 18:14:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 739DF8FC16 for ; Fri, 14 Oct 2011 18:14:33 +0000 (UTC) Received: (qmail 61929 invoked from network); 14 Oct 2011 16:55:25 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Oct 2011 16:55:25 -0000 Message-ID: <4E987C0A.2040600@freebsd.org> Date: Fri, 14 Oct 2011 20:14:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Gleb Smirnoff References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> <4E9874C5.8070309@freebsd.org> <20111014180205.GG94905@glebius.int.ru> In-Reply-To: <20111014180205.GG94905@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 14 Oct 2011 18:14:35 -0000 On 14.10.2011 20:02, Gleb Smirnoff wrote: > On Fri, Oct 14, 2011 at 07:43:33PM +0200, Andre Oppermann wrote: > A> On 13.10.2011 18:02, Gleb Smirnoff wrote: > A> > Hello networkers, > A> > > A> > I've updated patch& README here: > A> > > A> > http://people.freebsd.org/~glebius/newcarp/ > A> > > A> > Going to commit it to head/ soon. Then I'd like to make > A> > a run through carp-related PRs, update documentation, settle > A> > things a bit... and then make more hacking to restore the > A> > arpbalance feature, as well as bring in ipbalance feature. > A> > A> Excellent! Great work. Looks good. > A> > A> One minor nit: Carp is directly enabled by specifying the vhid. > A> Would it be possible to introduce the keyword "carp" and "-carp" > A> to actually enable/disable an interface for carp? > > We could add additional interface flag, but I don't see point in > enabling/disabling CARP per-interface. Suspending the interface from the group, but retaining the configuration could be one reason. > btw, you can configure a VHID and don't attach any addresses > to it. How does that work? What purpose does it serve? -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 18:48:45 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2187B106566B; Fri, 14 Oct 2011 18:48:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF768FC0C; Fri, 14 Oct 2011 18:48:44 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p9EImhsj045510; Fri, 14 Oct 2011 22:48:43 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p9EImhKD045509; Fri, 14 Oct 2011 22:48:43 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Oct 2011 22:48:43 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20111014184843.GI94905@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> <4E9874C5.8070309@freebsd.org> <20111014180205.GG94905@glebius.int.ru> <4E987C0A.2040600@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4E987C0A.2040600@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 14 Oct 2011 18:48:45 -0000 On Fri, Oct 14, 2011 at 08:14:34PM +0200, Andre Oppermann wrote: A> On 14.10.2011 20:02, Gleb Smirnoff wrote: A> > On Fri, Oct 14, 2011 at 07:43:33PM +0200, Andre Oppermann wrote: A> > A> On 13.10.2011 18:02, Gleb Smirnoff wrote: A> > A> > Hello networkers, A> > A> > A> > A> > I've updated patch& README here: A> > A> > A> > A> > http://people.freebsd.org/~glebius/newcarp/ A> > A> > A> > A> > Going to commit it to head/ soon. Then I'd like to make A> > A> > a run through carp-related PRs, update documentation, settle A> > A> > things a bit... and then make more hacking to restore the A> > A> > arpbalance feature, as well as bring in ipbalance feature. A> > A> A> > A> Excellent! Great work. Looks good. A> > A> A> > A> One minor nit: Carp is directly enabled by specifying the vhid. A> > A> Would it be possible to introduce the keyword "carp" and "-carp" A> > A> to actually enable/disable an interface for carp? A> > A> > We could add additional interface flag, but I don't see point in A> > enabling/disabling CARP per-interface. A> A> Suspending the interface from the group, but retaining the configuration A> could be one reason. Won't ifconfig it down work? A> > btw, you can configure a VHID and don't attach any addresses A> > to it. A> A> How does that work? What purpose does it serve? This is actually how it is configured: SIOCSVH, then SIOCAIFADDR. There is no practical use in addressless vhid now. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:06:58 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 536971065674 for ; Fri, 14 Oct 2011 19:06:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A01698FC14 for ; Fri, 14 Oct 2011 19:06:57 +0000 (UTC) Received: (qmail 62127 invoked from network); 14 Oct 2011 17:47:48 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Oct 2011 17:47:48 -0000 Message-ID: <4E988851.3040801@freebsd.org> Date: Fri, 14 Oct 2011 21:06:57 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Gleb Smirnoff References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> <4E9874C5.8070309@freebsd.org> <20111014180205.GG94905@glebius.int.ru> <4E987C0A.2040600@freebsd.org> <20111014184843.GI94905@glebius.int.ru> In-Reply-To: <20111014184843.GI94905@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 14 Oct 2011 19:06:58 -0000 On 14.10.2011 20:48, Gleb Smirnoff wrote: > On Fri, Oct 14, 2011 at 08:14:34PM +0200, Andre Oppermann wrote: > A> On 14.10.2011 20:02, Gleb Smirnoff wrote: > A> > On Fri, Oct 14, 2011 at 07:43:33PM +0200, Andre Oppermann wrote: > A> > A> On 13.10.2011 18:02, Gleb Smirnoff wrote: > A> > A> > Hello networkers, > A> > A> > > A> > A> > I've updated patch& README here: > A> > A> > > A> > A> > http://people.freebsd.org/~glebius/newcarp/ > A> > A> > > A> > A> > Going to commit it to head/ soon. Then I'd like to make > A> > A> > a run through carp-related PRs, update documentation, settle > A> > A> > things a bit... and then make more hacking to restore the > A> > A> > arpbalance feature, as well as bring in ipbalance feature. > A> > A> > A> > A> Excellent! Great work. Looks good. > A> > A> > A> > A> One minor nit: Carp is directly enabled by specifying the vhid. > A> > A> Would it be possible to introduce the keyword "carp" and "-carp" > A> > A> to actually enable/disable an interface for carp? > A> > > A> > We could add additional interface flag, but I don't see point in > A> > enabling/disabling CARP per-interface. > A> > A> Suspending the interface from the group, but retaining the configuration > A> could be one reason. > > Won't ifconfig it down work? Not if I want to continue to use the primary or other non-carp address. > A> > btw, you can configure a VHID and don't attach any addresses > A> > to it. > A> > A> How does that work? What purpose does it serve? > > This is actually how it is configured: SIOCSVH, then SIOCAIFADDR. > There is no practical use in addressless vhid now. If it can cause problems or non-standard behavior it should not be allowed and the carp status should be suspended until fully configured. One more question: Can one interface with multiple addresses become a member of different carp groups (with a different address each)? -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:12:48 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654A7106564A; Fri, 14 Oct 2011 19:12:48 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id C76E78FC1B; Fri, 14 Oct 2011 19:12:47 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p9EJCkDS045693; Fri, 14 Oct 2011 23:12:46 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p9EJCjjI045692; Fri, 14 Oct 2011 23:12:46 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 14 Oct 2011 23:12:45 +0400 From: Gleb Smirnoff To: Andre Oppermann Message-ID: <20111014191245.GL94905@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> <4E9874C5.8070309@freebsd.org> <20111014180205.GG94905@glebius.int.ru> <4E987C0A.2040600@freebsd.org> <20111014184843.GI94905@glebius.int.ru> <4E988851.3040801@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4E988851.3040801@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 14 Oct 2011 19:12:48 -0000 On Fri, Oct 14, 2011 at 09:06:57PM +0200, Andre Oppermann wrote: A> > Won't ifconfig it down work? A> A> Not if I want to continue to use the primary or other non-carp address. Well, the best idea for that case would be switch them to backup mode. In presense of active master, they won't show up any way either on wire, neither in the stack. A> > A> > btw, you can configure a VHID and don't attach any addresses A> > A> > to it. A> > A> A> > A> How does that work? What purpose does it serve? A> > A> > This is actually how it is configured: SIOCSVH, then SIOCAIFADDR. A> > There is no practical use in addressless vhid now. A> A> If it can cause problems or non-standard behavior it should not be A> allowed and the carp status should be suspended until fully configured. Status of such addressless vhid is always INIT, so it causes no activity either on wire or in stack :) A> One more question: Can one interface with multiple addresses become a A> member of different carp groups (with a different address each)? Sure. All imaginable options are configurable: arbitrary number of addresses on interface, arbitrary number of vhids on interface, arbitrary number of addresses configured to a particular vhid. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 19:29:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D173106566C for ; Fri, 14 Oct 2011 19:29:35 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA90B8FC16 for ; Fri, 14 Oct 2011 19:29:34 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so87834bkb.13 for ; Fri, 14 Oct 2011 12:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-cr-hashedpuzzle:x-cr-puzzleid; bh=8OQzlezcFlrbJbq423jvOiUxL0OZmoGiLs7II8JmIAo=; b=gQdl1eS6ModqpPsPYgFvT3NwwVlMXnFg0iEYV8Wgd7SE3v5ucih8iAIeeRTvgms97k 3YZWwYBcK2mE6SKRSK8E0z6ZBESoBrEOt8zlAD4/1lMaIN7Hi0kuRRSt1p069rn8F3wV disu5Mb99rhSGvJBEWOu9kWlyzawiAgd6GvC0= Received: by 10.204.140.206 with SMTP id j14mr7750010bku.55.1318619205015; Fri, 14 Oct 2011 12:06:45 -0700 (PDT) Received: from rimwks1x64 ([92.124.10.60]) by mx.google.com with ESMTPS id v16sm9367150bkd.6.2011.10.14.12.06.42 (version=SSLv3 cipher=OTHER); Fri, 14 Oct 2011 12:06:44 -0700 (PDT) From: rozhuk.im@gmail.com To: Date: Sat, 15 Oct 2011 04:06:40 +0900 Message-ID: <4e988844.1025cc0a.1e88.ffffb4b9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyKpGSMDXecgPCYSLqJMoGmDrfX0Q== Content-Language: ru x-cr-hashedpuzzle: yPs= AZWd BpEH C857 IFMp IqF7 Iurz JH9M J1Ro Lno+ MBAJ MnLX QyZv ThHs T5oF UaHM; 2; ZgByAGUAZQBiAHMAZAAtAG4AZQB0AEAAZgByAGUAZQBiAHMAZAAuAG8AcgBnADsAcgBvAHoAaAB1AGsALgBpAG0AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {2A6BAF07-A18B-4923-98A3-75073F6F8653}; cgBvAHoAaAB1AGsALgBpAG0AQABnAG0AYQBpAGwALgBjAG8AbQA=; Fri, 14 Oct 2011 19:06:35 GMT; UQBpAG4AUQAgAHMAdQBwAHAAbwByAHQAOgAgAGkAbQBwAGwAZQBtAGUAbgB0ACAAZABlAHQAYQBpAGwAcwAgAC0AIABuAGUAZQBkACAAaABlAGwAcAAhAA== x-cr-puzzleid: {2A6BAF07-A18B-4923-98A3-75073F6F8653} Cc: Rozhuk.IM@gmail.com Subject: QinQ support: implement details - need help! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:29:35 -0000 ... IEEE 802.1ad (802.1QinQ) specifies architecture and bridge protocols to provide separate instances of the MAC services to multiple independent = users of a Bridged Local Area Network in a manner that does not require cooperation among the users, and requires a minimum of cooperation = between the users and the provider of the MAC service. The idea is to provide, for example, the possibility for customers to = run their own VLANs inside service provider's provided VLAN. This way the service provider can just configure one VLAN for the customer and = customer can then treat that VLAN as if it was a trunk. ... http://en.wikipedia.org/wiki/802.1ad "Customer" VLAN - ether_type: 0x8100 Stored in: struct pkthdr { ... union { u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ u_int16_t vt_nrecs; /* # of IGMPv3 records in this chain */ } PH_vt; SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ }; #define ether_vtag PH_vt.vt_vtag "Service Provider" VLAN - ether_type: 0x88a8/0x8100/0x9100 How I can store it in packet? How to store tag for QinQinQ? VLAN tags store implementation (IMHO) Ethernet packet: | Dst_MAC | Src_MAC | 802.1Q_Tag2 | 802.1Q_Tag1 | 802.1Q_Tag0 | Ether_type/size | Payload | 802.1Q Tag0 =3D "Customer" VLAN - ether_type: 0x8100, stored in pkthdr.PH_vt.vt_vtag (now) (IEEE 802.1Q) 802.1Q Tag1 =3D "Service Provider" / MetroTag... (IEEE 802.1ad) 802.1Q Tag2 =3D SomeTag... (QinQinQ) I found part of old code in /usr/src/sys/dev/mxge/if_mxge.c: ... /* save the tag */ #ifdef MXGE_NEW_VLAN_API=09 m->m_pkthdr.ether_vtag =3D ntohs(evl->evl_tag); #else { struct m_tag *mtag; mtag =3D m_tag_alloc(MTAG_VLAN, MTAG_VLAN_TAG, sizeof(u_int), M_NOWAIT); if (mtag =3D=3D NULL) return; VLAN_TAG_VALUE(mtag) =3D ntohs(evl->evl_tag); m_tag_prepend(m, mtag); } #endif m->m_flags |=3D M_VLANTAG; ... 1. Compact scheme: #define MTAG_VLAN_T0 1035328035 /* m_tag_cookie */ #define MTAG_VLAN_T1 (MTAG_VLAN_T0 + 1) #define MTAG_VLAN_T2 (MTAG_VLAN_T1 + 1) #define MTAG_VLAN_T3 (MTAG_VLAN_T2 + 1) Store vt_vtag in m_tag_id ng_vlan / if_vlan will use for tag/untag one of MTAG_VLAN_Tx = m_tag_cookie and tunable ether_type for vlan encapsulation: lower <-> ng_vlan(MTAG_VLAN_T0) <-> ng_vlan(MTAG_VLAN_T1) <-> ng_vlan(MTAG_VLAN_T2) <-> upper 2. OpenBSD compatible #ifdef #define MTAG_VLAN MTAG_ABI_COMPAT /* cookie */ #define MTAG_VLAN_TAG0 1035328035 #else #define MTAG_VLAN 1035328035 /* m_tag_cookie */ #define MTAG_VLAN_TAG0 0 /* tag of VLAN interface */ #endif #define MTAG_VLAN_TAG1 (MTAG_VLAN_TAG0 + 1) #define MTAG_VLAN_TAG2 (MTAG_VLAN_TAG1 + 1) #define MTAG_VLAN_TAG3 (MTAG_VLAN_TAG2 + 1) struct mv_tag { struct m_tag tag; u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ }; ng_vlan / if_vlan will use for tag/untag one of MTAG_VLAN_TAGx m_tag_id = and tunable ether_type for vlan encapsulation: lower <-> ng_vlan(MTAG_VLAN_TAG0) <-> ng_vlan(MTAG_VLAN_TAG1) <-> ng_vlan(MTAG_VLAN_TAG2) <-> upper 3. Extended Same as 2, but struct mv_tag { struct m_tag tag; u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ u_int16_t ether_type; /* Ethernet type for TAG */ }; Major question is: were store 802.1Q Tag0 =3D "Customer" VLAN (ether_type: 0x8100, IEEE = 802.1Q): in pkthdr.PH_vt.vt_vtag or in struct m_tag? ng_vlan modifications (I can make): + tunable ether_type for vlan encapsulation + tunable on/off encapsulation (to prevent network adapter = encapsulation) + tunable m_tag identifier for VLAN tag ...??? Any comments before I start? PS: Trick: kern.ipc.max_linkhdr should be increased via sysctl: 20 - 1 VLAN tag (.Q) 24 - 2 VLAN tags (QinQ) 28 - 3 VLAN tags (QinQinQ) 32 - 4 VLAN tags (...) =A0 -- Rozhuk Ivan =A0=20 From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 20:34:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1979D106566C for ; Fri, 14 Oct 2011 20:34:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 99AC58FC12 for ; Fri, 14 Oct 2011 20:34:13 +0000 (UTC) Received: by wwi18 with SMTP id 18so697579wwi.31 for ; Fri, 14 Oct 2011 13:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WvytFAYczOz6th+m2H99ZqdXR7j1bbgg1bGZi+GntEY=; b=NIprZ7IsXky8P48h4tyr3BI27D/4HMD9e82vnev3mFii1na01tsaAziihODDxPPQgA jZDEtuwO/4yEDqDB+OcoZDaYhUwUgpUaaGr7tNxsIpkeRPZNivGeVK60+d7MU+SUpZmp TqhWxbPXabqL56aq8QJHW3TARiP2riEkeKfVk= Received: by 10.216.161.20 with SMTP id v20mr479736wek.12.1318624452639; Fri, 14 Oct 2011 13:34:12 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q30sm423380wbn.17.2011.10.14.13.34.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 13:34:11 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 14 Oct 2011 13:32:26 -0700 From: YongHyeon PYUN Date: Fri, 14 Oct 2011 13:32:26 -0700 To: Marius Strobl Message-ID: <20111014203226.GA16192@michelle.cdnetworks.com> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111013214903.GH39118@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII 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, 14 Oct 2011 20:34:14 -0000 On Thu, Oct 13, 2011 at 11:49:03PM +0200, Marius Strobl wrote: > On Wed, Oct 12, 2011 at 04:57:07PM -0700, YongHyeon PYUN wrote: > > On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote: > > > On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote: > > > > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > > > > > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > > > > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > > > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > > > > > and it's useful for porting embedded devices. > > > > > > > > > > > > > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > > > > > which (im)ports these and converts drivers to take advantage of it here: > > > > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > > > > > > > > > Patch looks good to me. > > > > > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > > > > > and xe(4))? > > > > > > > > > > > > > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > > > > > I've started with the drivers were the corresponding NetBSD one also > > > > > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > > > > > aware that these should also be convertible to the common code, I just > > > > > didn't get around to it so far. As for lge(4) that driver has some > > > > > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've > > > > > > > > Ah, I just blindly grepped the string, sorry. > > > > > > > > > previously missed rl(4) as I was only grepping beneath sys/dev and I > > > > > currently can't explain why I missed xe(4), so thanks for mentioning > > > > > these. > > > > > In my experience MII bitbang'ing is very fragile though and subtle > > > > > changes may break it so I don't want to commit these without testing > > > > > or in the case of smc(4) where at least the corresponding NetBSD > > > > > driver already uses the common code. Unfortunately, I only have > > > > > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > > > > > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > > > > > happen to have hardware to test the remaining drivers, i.e. nge(4), > > > > > sis(4), ste(4), wb(4) and xe(4)? > > > > > > > > > > > > > I have access to sis(4) and ste(4). I also have a nge(4) but I'm > > > > not able to access to the hardware, at least in US. > > > > > > > > > > It would be great if you could test sis(4) and ste(4). > > > > > > > Ok, will do in this week. > > > > I just noticed that rl(4) only does MII bitbang'ing for the 8129 but I > only have a 8139. Do you happen do have the former so you could test the > patch with it? Sorry, I don't have 8129 based controller. > The patch is now complete as far as I'm willing to convert drivers. What's > left is ed(4) and xe(4). The former has several chip specific things > interwinded and I'm unsure whether it can be converted to use the common > code; I'd at least like to have hardware for the special cases to give > that a try. Xe(4) currently doesn't use miibus(4) (but should) so I > don't see much point in adding a dependency on miibus(4) just for the > bitbang'ing code on it (nor do I for not adding the common code to > miibus(4)). > Ok. Both sis(4) and ste(4) seem to work without problems. Thanks for your work! > Marius > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 14 22:43:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C3C1065676; Fri, 14 Oct 2011 22:43:33 +0000 (UTC) (envelope-from tomelite82@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37C058FC1D; Fri, 14 Oct 2011 22:43:32 +0000 (UTC) Received: by ggeq3 with SMTP id q3so2054895gge.13 for ; Fri, 14 Oct 2011 15:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=PUzaCCs8jX0htHYKlH31lbAZ4VFbxZtcEDC+8cIsqjo=; b=GhMY2J7oRv24lDHWtXbLrCPlnZWa+Rf8MNmMYTa52uuo5hKlBu5/sCNtFtIz3WPsF8 0cQVQ4CfhtMZyV5HIJlDOJtB+U022jmc+tDz0CTo2o+kpylaKdFKgVdWjN9gClr1k/aa Ro/iLs1TRaHwNa5zBpo/XJWevca7XzAnFAu24= MIME-Version: 1.0 Received: by 10.150.8.14 with SMTP id 14mr10761653ybh.7.1318632212236; Fri, 14 Oct 2011 15:43:32 -0700 (PDT) Sender: tomelite82@gmail.com Received: by 10.151.78.21 with HTTP; Fri, 14 Oct 2011 15:43:32 -0700 (PDT) Date: Fri, 14 Oct 2011 15:43:32 -0700 X-Google-Sender-Auth: J5XhAlMGcKurx7xiAHqiXfGy8ps Message-ID: From: Qing Li To: freebsd-net@freebsd.org, src-committers@freebsd.org, Svatopluk Kraus Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: PR contributor mix-up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 22:43:33 -0000 Hi, I had mistaken Svatopluk Kraus for "pluknet", so my "Submitted by:" lines are wrong in my recent commits for the following PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=159601 http://www.freebsd.org/cgi/query-pr.cgi?pr=159602 http://www.freebsd.org/cgi/query-pr.cgi?pr=159603 The "Submitted by:" line should read "Svatopluk Kraus ". My apologies to Svatopluk Kraus, and Thank you for the PR submissions and your suggested patches. --Qing From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:15:17 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 273851065672 for ; Sat, 15 Oct 2011 08:15:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE7A8FC12 for ; Sat, 15 Oct 2011 08:15:16 +0000 (UTC) Received: (qmail 64098 invoked from network); 15 Oct 2011 06:56:00 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Oct 2011 06:56:00 -0000 Message-ID: <4E994114.3050403@freebsd.org> Date: Sat, 15 Oct 2011 10:15:16 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Gleb Smirnoff References: <20110810160526.GO43567@FreeBSD.org> <20111013160216.GU94905@glebius.int.ru> <4E9874C5.8070309@freebsd.org> <20111014180205.GG94905@glebius.int.ru> <4E987C0A.2040600@freebsd.org> <20111014184843.GI94905@glebius.int.ru> <4E988851.3040801@freebsd.org> <20111014191245.GL94905@glebius.int.ru> In-Reply-To: <20111014191245.GL94905@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 15 Oct 2011 08:15:17 -0000 On 14.10.2011 21:12, Gleb Smirnoff wrote: > On Fri, Oct 14, 2011 at 09:06:57PM +0200, Andre Oppermann wrote: > A> > Won't ifconfig it down work? > A> > A> Not if I want to continue to use the primary or other non-carp address. > > Well, the best idea for that case would be switch them to backup mode. > In presense of active master, they won't show up any way either on wire, > neither in the stack. Though you run the risk of getting a lot of traffic when the master fails while working on the backup. At the moment one can simply down the carp interface and be in the clear. Anyway, this enable/disable can be added later again if reality shows it to be necessary. > A> > A> > btw, you can configure a VHID and don't attach any addresses > A> > A> > to it. > A> > A> > A> > A> How does that work? What purpose does it serve? > A> > > A> > This is actually how it is configured: SIOCSVH, then SIOCAIFADDR. > A> > There is no practical use in addressless vhid now. > A> > A> If it can cause problems or non-standard behavior it should not be > A> allowed and the carp status should be suspended until fully configured. > > Status of such addressless vhid is always INIT, so it causes no activity > either on wire or in stack :) > > A> One more question: Can one interface with multiple addresses become a > A> member of different carp groups (with a different address each)? > > Sure. All imaginable options are configurable: arbitrary number of > addresses on interface, arbitrary number of vhids on interface, > arbitrary number of addresses configured to a particular vhid. Excellent. And much simpler to use as well. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:17:59 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 365C1106564A; Sat, 15 Oct 2011 08:17:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5D88FC08; Sat, 15 Oct 2011 08:17:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9F8HwjH082169; Sat, 15 Oct 2011 08:17:58 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8HweA082165; Sat, 15 Oct 2011 08:17:58 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 08:17:58 GMT Message-Id: <201110150817.p9F8HweA082165@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/117448: [carp] 6.2 kernel crash [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: Sat, 15 Oct 2011 08:17:59 -0000 Synopsis: [carp] 6.2 kernel crash [regression] Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 08:17:15 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=117448 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:29:28 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DB71106564A; Sat, 15 Oct 2011 08:29:28 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 25B908FC0A; Sat, 15 Oct 2011 08:29:28 +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 p9F8TSnU092482; Sat, 15 Oct 2011 08:29:28 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8TSYO092478; Sat, 15 Oct 2011 08:29:28 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 08:29:28 GMT Message-Id: <201110150829.p9F8TSYO092478@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/120130: [carp] [panic] carp causes kernel panics in any constellation 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, 15 Oct 2011 08:29:28 -0000 Synopsis: [carp] [panic] carp causes kernel panics in any constellation Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 08:19:31 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=120130 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:32:04 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAAB9106564A; Sat, 15 Oct 2011 08:32:04 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B207E8FC0C; Sat, 15 Oct 2011 08:32:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9F8W4Ub002165; Sat, 15 Oct 2011 08:32:04 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8W4ph002160; Sat, 15 Oct 2011 08:32:04 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 08:32:04 GMT Message-Id: <201110150832.p9F8W4ph002160@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/125442: [carp] [lagg] CARP combined with LAGG causes system panic - 7.0/amd64 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, 15 Oct 2011 08:32:04 -0000 Synopsis: [carp] [lagg] CARP combined with LAGG causes system panic - 7.0/amd64 Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 08:30:56 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. btw, did either patch from kern/124384 or upgrade to a newer FreeBSD version help? http://www.freebsd.org/cgi/query-pr.cgi?pr=125442 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:34:36 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17960106566B; Sat, 15 Oct 2011 08:34:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2FA28FC12; Sat, 15 Oct 2011 08:34:35 +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 p9F8YZ5c003048; Sat, 15 Oct 2011 08:34:35 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8YZV7003044; Sat, 15 Oct 2011 08:34:35 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 08:34:35 GMT Message-Id: <201110150834.p9F8YZV7003044@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 08:34:36 -0000 Synopsis: [carp] CARP interface renaming makes system no longer respond on the virtual IP address Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 08:32:41 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. I hope that all problems related to CARP being an interface are going to be fixed after my rewrite. http://www.freebsd.org/cgi/query-pr.cgi?pr=126714 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:35:15 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DF74106566C; Sat, 15 Oct 2011 08:35:15 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7586A8FC08; Sat, 15 Oct 2011 08:35:15 +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 p9F8ZFfs003179; Sat, 15 Oct 2011 08:35:15 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8ZFFa003175; Sat, 15 Oct 2011 08:35:15 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 08:35:15 GMT Message-Id: <201110150835.p9F8ZFFa003175@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/126945: [carp] CARP interface destruction with ifconfig destroy causes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 08:35:15 -0000 Synopsis: [carp] CARP interface destruction with ifconfig destroy causes kernel panic Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 08:34:57 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. I hope that all problems related to CARP being an interface are going to be fixed after my rewrite. http://www.freebsd.org/cgi/query-pr.cgi?pr=126945 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:41:30 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A4E7106564A; Sat, 15 Oct 2011 08:41:30 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 31C0F8FC12; Sat, 15 Oct 2011 08:41: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 p9F8fUPX011470; Sat, 15 Oct 2011 08:41:30 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8fTFt011466; Sat, 15 Oct 2011 08:41:29 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 08:41:29 GMT Message-Id: <201110150841.p9F8fTFt011466@freefall.freebsd.org> To: spawk@acm.poly.edu, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/129508: [carp] [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) 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, 15 Oct 2011 08:41:30 -0000 Synopsis: [carp] [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) State-Changed-From-To: open->feedback State-Changed-By: glebius State-Changed-When: Sat Oct 15 08:41:16 UTC 2011 State-Changed-Why: Feedback requeted. http://www.freebsd.org/cgi/query-pr.cgi?pr=129508 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 08:50:07 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D2F4106566C for ; Sat, 15 Oct 2011 08:50:07 +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 7C0BB8FC17 for ; Sat, 15 Oct 2011 08:50: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 p9F8o7pB012465 for ; Sat, 15 Oct 2011 08:50:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F8o71A012464; Sat, 15 Oct 2011 08:50:07 GMT (envelope-from gnats) Date: Sat, 15 Oct 2011 08:50:07 GMT Message-Id: <201110150850.p9F8o71A012464@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: kern/129508: [carp] [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 08:50:07 -0000 The following reply was made to PR kern/129508; it has been noted by GNATS. From: Gleb Smirnoff To: Boris Kochergin Cc: bug-followup@FreeBSD.org Subject: kern/129508: [carp] [panic] Kernel panic with EtherIP (may be related to SVN commit 178025) Date: Sat, 15 Oct 2011 12:41:07 +0400 Boris, I am now going through all carp-related PRs, since I'm working on major carp rewrite. Your PR doesn't look directly related to CARP, but anyway I am interested on status update for this PR. Did you manage to find workaround for your problem? Had you done any operating system upgrades since last report? Any additional info? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 09:01:03 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB3D106564A; Sat, 15 Oct 2011 09:01:03 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 172498FC12; Sat, 15 Oct 2011 09:01: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 p9F912FL023936; Sat, 15 Oct 2011 09:01:02 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F912Gu023927; Sat, 15 Oct 2011 09:01:02 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 09:01:02 GMT Message-Id: <201110150901.p9F912Gu023927@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface 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, 15 Oct 2011 09:01:03 -0000 Synopsis: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 09:00:31 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=132107 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 09:02:59 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF2A1065672; Sat, 15 Oct 2011 09:02:59 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 572008FC08; Sat, 15 Oct 2011 09:02:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9F92xTL029142; Sat, 15 Oct 2011 09:02:59 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F92xa1029138; Sat, 15 Oct 2011 09:02:59 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 09:02:59 GMT Message-Id: <201110150902.p9F92xa1029138@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/132285: [carp] alias gives incorrect hash in dmesg 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, 15 Oct 2011 09:02:59 -0000 Synopsis: [carp] alias gives incorrect hash in dmesg Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 09:02:28 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=132285 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 09:04:39 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49FE61065670; Sat, 15 Oct 2011 09:04:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2204D8FC19; Sat, 15 Oct 2011 09:04:39 +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 p9F94dpQ029427; Sat, 15 Oct 2011 09:04:39 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F94cr0029423; Sat, 15 Oct 2011 09:04:38 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 09:04:38 GMT Message-Id: <201110150904.p9F94cr0029423@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/133218: [carp] [hang] use of carp(4) causes system to freeze 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, 15 Oct 2011 09:04:39 -0000 Synopsis: [carp] [hang] use of carp(4) causes system to freeze Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 09:04:10 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=133218 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 09:09:35 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A691106566B; Sat, 15 Oct 2011 09:09:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21BFD8FC0A; Sat, 15 Oct 2011 09:09:35 +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 p9F99ZMY029789; Sat, 15 Oct 2011 09:09:35 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9F99Ysg029783; Sat, 15 Oct 2011 09:09:34 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 09:09:34 GMT Message-Id: <201110150909.p9F99Ysg029783@freefall.freebsd.org> To: alexey@kouznetsov.com, glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/141023: [carp] CARP arp replays with wrong src mac 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, 15 Oct 2011 09:09:35 -0000 Synopsis: [carp] CARP arp replays with wrong src mac State-Changed-From-To: open->analyzed State-Changed-By: glebius State-Changed-When: Sat Oct 15 09:08:48 UTC 2011 State-Changed-Why: Let's look at this closer. Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 09:08:48 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=141023 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 10:45:23 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB52D106564A for ; Sat, 15 Oct 2011 10:45:23 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm10.bullet.mail.bf1.yahoo.com (nm10.bullet.mail.bf1.yahoo.com [98.139.212.169]) by mx1.freebsd.org (Postfix) with SMTP id 6BE4F8FC21 for ; Sat, 15 Oct 2011 10:45:23 +0000 (UTC) Received: from [98.139.215.142] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2011 10:45:22 -0000 Received: from [98.139.211.194] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Oct 2011 10:45:22 -0000 Received: from [127.0.0.1] by smtp203.mail.bf1.yahoo.com with NNFMP; 15 Oct 2011 10:45:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1318675522; bh=dTOuCueiDfidpI3AdfXgUaVDwnvL4ZJ03kpd4VhheqM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=6XeMEKrOWKEtrVM60f8QaL6C5UrtG/ReIF3eSnLhp8mEOwsHw+Gsb+rTJobKjkJc7i7VwHlnQ2ruaG9+AVxWtUOomomLgoZl+N0LZYTLIH0z5QqpgcHqA5hWf02lqILhScAWatVVpm52TP2n2zrTUXnJE8NrAkkaT276h3uE3YM= X-Yahoo-Newman-Id: 493103.81307.bm@smtp203.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: l07gwkQVM1l_ejzojdnHrpdcIoF5.v2S4fTpGzoF9ns_8FV gKNPFB9iPiJ_j9quppxm5r1NTuz_jwLucXTN5C95mVWBUFtdUutX0UUEa36H Xo1DiDEzhQN16wXvrvfkARaICL239YMzh94BUqbbRnPPoqZmDewAHK0ywY7Q .UgMQjLzIXvWkEOf8VSt1TYzjJZa8NdoFSboABhKOJ0tqfsc3li0Q1phB27H jAH_6mnzv3HB15zb8wFsUoycJIkgNbyFazf.7cRora7x270uEqqCHmTBAuDx PXh.A10jnJ6nZaAsIs.BF80FH2Stmfx6u5a9.MXoxSKXy3Tp3o8Y3LS5laFy TwWTBEKM7yJTt6e.LXXxOhdpNna08EtXB6SBgpWStSJBNSu25x8x5ms0ngvq GxW8vdFg8wW8GQrK74v7zGw-- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-iy0-f182.google.com (moonlightakkiy@209.85.210.182 with plain) by smtp203.mail.bf1.yahoo.com with SMTP; 15 Oct 2011 03:45:22 -0700 PDT Received: by iaky10 with SMTP id y10so4749018iak.13 for ; Sat, 15 Oct 2011 03:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.50.204 with SMTP id a12mr5373176ibg.11.1318675521815; Sat, 15 Oct 2011 03:45:21 -0700 (PDT) Received: by 10.231.12.139 with HTTP; Sat, 15 Oct 2011 03:45:21 -0700 (PDT) In-Reply-To: References: <201110110720.04292.break19@gmail.com> Date: Sat, 15 Oct 2011 04:45:21 -0600 Message-ID: From: PseudoCylon To: Chuck Burns Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: [urtw] Wifi link dying randomly. reboot required to reconnect. 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, 15 Oct 2011 10:45:23 -0000 > My system on the other hand just reports "No Carrier" in ifconfig, > even after resetting the router, and other devices in the home can see > it, and connect to it fine. > Can you #wlandebug -i wlan0 crypto+assoc+auth+scan and re-run wpa_supplicant when the link is droped? I wonder what is failing. AK From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 14:20:09 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A297106566C for ; Sat, 15 Oct 2011 14:20:09 +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 D081B8FC12 for ; Sat, 15 Oct 2011 14:20: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 p9FEK8e2021611 for ; Sat, 15 Oct 2011 14:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9FEK8k1021610; Sat, 15 Oct 2011 14:20:08 GMT (envelope-from gnats) Date: Sat, 15 Oct 2011 14:20:08 GMT Message-Id: <201110151420.p9FEK8k1021610@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: kern/144572: [carp] CARP preemption mode traffic partially goes to backup node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 14:20:09 -0000 The following reply was made to PR kern/144572; it has been noted by GNATS. From: Gleb Smirnoff To: "Eugene M. Zheganin" Cc: bug-followup@FreeBSD.org Subject: kern/144572: [carp] CARP preemption mode traffic partially goes to backup node Date: Sat, 15 Oct 2011 18:17:49 +0400 Eugene, is the networking switch that connect both nodes a manageable one? Is it possible to look into its forwarding table or even log changes to it? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 14:23:26 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26260106566C; Sat, 15 Oct 2011 14:23:26 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F24F28FC08; Sat, 15 Oct 2011 14:23:25 +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 p9FENPBu029651; Sat, 15 Oct 2011 14:23:25 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9FENPTW029647; Sat, 15 Oct 2011 14:23:25 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 14:23:25 GMT Message-Id: <201110151423.p9FENPTW029647@freefall.freebsd.org> To: emz@norma.perm.ru, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/144572: [carp] CARP preemption mode traffic partially goes to backup node 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, 15 Oct 2011 14:23:26 -0000 Synopsis: [carp] CARP preemption mode traffic partially goes to backup node State-Changed-From-To: open->closed State-Changed-By: glebius State-Changed-When: Sat Oct 15 14:21:53 UTC 2011 State-Changed-Why: Submitter mail relay is not accepting a valid email. ----- The following addresses had permanent fatal errors ----- (reason: 550 5.0.0 ... Dropping e-mail from glebius@Fre eBSD.org, relay glebius.int.ru [81.19.64.117] that is sending the mail isn't accepting email it's trying to pass.) PR can be re-opened once submitter reports that problem is fixed, and we are able to communicate with him. http://www.freebsd.org/cgi/query-pr.cgi?pr=144572 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 14:25:56 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049D6106566B; Sat, 15 Oct 2011 14:25:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D0F9A8FC0A; Sat, 15 Oct 2011 14:25:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9FEPtsZ029735; Sat, 15 Oct 2011 14:25:55 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9FEPtxP029731; Sat, 15 Oct 2011 14:25:55 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 14:25:55 GMT Message-Id: <201110151425.p9FEPtxP029731@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/125816: [carp] [if_bridge] carp stuck in init when using bridge interface 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, 15 Oct 2011 14:25:56 -0000 Synopsis: [carp] [if_bridge] carp stuck in init when using bridge interface Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 14:25:17 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=125816 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 14:27:02 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFC2B1065672; Sat, 15 Oct 2011 14:27:02 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 880918FC1B; Sat, 15 Oct 2011 14:27:02 +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 p9FER25A029858; Sat, 15 Oct 2011 14:27:02 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9FER2Sp029854; Sat, 15 Oct 2011 14:27:02 GMT (envelope-from glebius) Date: Sat, 15 Oct 2011 14:27:02 GMT Message-Id: <201110151427.p9FER2Sp029854@freefall.freebsd.org> To: glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [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: Sat, 15 Oct 2011 14:27:02 -0000 Synopsis: [carp] ipv6 does not work on carp interfaces [regression] Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Sat Oct 15 14:26:48 UTC 2011 Responsible-Changed-Why: I'm now working on major rewrite of CARP for FreeBSD 10, and I'd like to take all related PRs. http://www.freebsd.org/cgi/query-pr.cgi?pr=127050 From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 14:40:12 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 235401065670 for ; Sat, 15 Oct 2011 14:40:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EE1998FC12 for ; Sat, 15 Oct 2011 14:40:11 +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 p9FEeBqi040746 for ; Sat, 15 Oct 2011 14:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9FEeB4R040745; Sat, 15 Oct 2011 14:40:11 GMT (envelope-from gnats) Date: Sat, 15 Oct 2011 14:40:11 GMT Message-Id: <201110151440.p9FEeB4R040745@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: kern/155030: [igb] igb(4) DEVICE_POLLING does not work with carp(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 14:40:12 -0000 The following reply was made to PR kern/155030; it has been noted by GNATS. From: Gleb Smirnoff To: Martin Matuska Cc: bug-followup@FreeBSD.org Subject: kern/155030: [igb] igb(4) DEVICE_POLLING does not work with carp(4) Date: Sat, 15 Oct 2011 18:31:25 +0400 Martin, it isn't clear from the PR text whether removing carp(4) fixes polling(4) on igb(4)? Can you confirm or disclaim that removing carp(4) address fixes polling operation? In the email that is pointed to, they have watchdog timeouts, and these timeouts bring interface down, and no suprise that CARP goes down to. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 20:47:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A88171065670 for ; Sat, 15 Oct 2011 20:47:41 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 15C268FC13 for ; Sat, 15 Oct 2011 20:47:40 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9FKldUK091090; Sat, 15 Oct 2011 22:47:39 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9FKldHE091089; Sat, 15 Oct 2011 22:47:39 +0200 (CEST) (envelope-from marius) Date: Sat, 15 Oct 2011 22:47:39 +0200 From: Marius Strobl To: YongHyeon PYUN Message-ID: <20111015204739.GJ39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014203226.GA16192@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII 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, 15 Oct 2011 20:47:41 -0000 On Fri, Oct 14, 2011 at 01:32:26PM -0700, YongHyeon PYUN wrote: > On Thu, Oct 13, 2011 at 11:49:03PM +0200, Marius Strobl wrote: > > On Wed, Oct 12, 2011 at 04:57:07PM -0700, YongHyeon PYUN wrote: > > > On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote: > > > > On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote: > > > > > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > > > > > > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > > > > > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > > > > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > > > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > > > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > > > > > > and it's useful for porting embedded devices. > > > > > > > > > > > > > > > > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > > > > > > which (im)ports these and converts drivers to take advantage of it here: > > > > > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > > > > > > > > > > > Patch looks good to me. > > > > > > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > > > > > > and xe(4))? > > > > > > > > > > > > > > > > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > > > > > > I've started with the drivers were the corresponding NetBSD one also > > > > > > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > > > > > > aware that these should also be convertible to the common code, I just > > > > > > didn't get around to it so far. As for lge(4) that driver has some > > > > > > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've > > > > > > > > > > Ah, I just blindly grepped the string, sorry. > > > > > > > > > > > previously missed rl(4) as I was only grepping beneath sys/dev and I > > > > > > currently can't explain why I missed xe(4), so thanks for mentioning > > > > > > these. > > > > > > In my experience MII bitbang'ing is very fragile though and subtle > > > > > > changes may break it so I don't want to commit these without testing > > > > > > or in the case of smc(4) where at least the corresponding NetBSD > > > > > > driver already uses the common code. Unfortunately, I only have > > > > > > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > > > > > > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > > > > > > happen to have hardware to test the remaining drivers, i.e. nge(4), > > > > > > sis(4), ste(4), wb(4) and xe(4)? > > > > > > > > > > > > > > > > I have access to sis(4) and ste(4). I also have a nge(4) but I'm > > > > > not able to access to the hardware, at least in US. > > > > > > > > > > > > > It would be great if you could test sis(4) and ste(4). > > > > > > > > > > Ok, will do in this week. > > > > > > > I just noticed that rl(4) only does MII bitbang'ing for the 8129 but I > > only have a 8139. Do you happen do have the former so you could test the > > patch with it? > > Sorry, I don't have 8129 based controller. > > > The patch is now complete as far as I'm willing to convert drivers. What's > > left is ed(4) and xe(4). The former has several chip specific things > > interwinded and I'm unsure whether it can be converted to use the common > > code; I'd at least like to have hardware for the special cases to give > > that a try. Xe(4) currently doesn't use miibus(4) (but should) so I > > don't see much point in adding a dependency on miibus(4) just for the > > bitbang'ing code on it (nor do I for not adding the common code to > > miibus(4)). > > > > Ok. > Both sis(4) and ste(4) seem to work without problems. > Thanks for your work! > Thanks for testing! While digging for test hardware I found a Intel 21143 based card I decided to give a try for fun (as dc(4) doesn't use MII bitbang'ing for these). Unfortunately, it turned out that some dc(4) changes between 8.2-RELEASE an what's in head broke it in that it no longer is able to establish a link (the link LED blinks periodically instead of being lit permanently) ... Marius From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 21:06:58 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075971065675 for ; Sat, 15 Oct 2011 21:06:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 7524F8FC12 for ; Sat, 15 Oct 2011 21:06:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9FKuG07091132; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9FKuGRK091131; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius) Date: Sat, 15 Oct 2011 22:56:16 +0200 From: Marius Strobl To: current@freebsd.org, net@freebsd.org, stable@freebsd.org Message-ID: <20111015205616.GL39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014203226.GA16192@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: Subject: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] 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, 15 Oct 2011 21:06:58 -0000 Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 21:13:22 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FF9B106566B for ; Sat, 15 Oct 2011 21:13:22 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from core.impulsive.hu (core.impulsive.hu [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id B171C8FC16 for ; Sat, 15 Oct 2011 21:13:21 +0000 (UTC) Received: by core.impulsive.hu (Postfix, from userid 143) id 7C652DC0F8; Sat, 15 Oct 2011 20:58:38 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by core.impulsive.hu (Postfix) with ESMTP id 39412DC0BC for ; Sat, 15 Oct 2011 20:58:36 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C9EFD16463C; Sat, 15 Oct 2011 20:56:32 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id D7B2C10657DF; Sat, 15 Oct 2011 20:56:31 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A6A106564A; Sat, 15 Oct 2011 20:56:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id BAE268FC08; Sat, 15 Oct 2011 20:56:17 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9FKuG07091132; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9FKuGRK091131; Sat, 15 Oct 2011 22:56:16 +0200 (CEST) (envelope-from marius) Date: Sat, 15 Oct 2011 22:56:16 +0200 From: Marius Strobl To: current@freebsd.org, net@freebsd.org, stable@freebsd.org Message-ID: <20111015205616.GL39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111014203226.GA16192@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: Subject: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 21:13:22 -0000 Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Oct 15 22:00:27 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1907C106564A for ; Sat, 15 Oct 2011 22:00:27 +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 F22F18FC13 for ; Sat, 15 Oct 2011 22:00:26 +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 p9FM0QYU044813 for ; Sat, 15 Oct 2011 22:00:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9FM0QUO044812; Sat, 15 Oct 2011 22:00:26 GMT (envelope-from gnats) Date: Sat, 15 Oct 2011 22:00:26 GMT Message-Id: <201110152200.p9FM0QUO044812@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Steven Chamberlain Cc: Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steven Chamberlain List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 22:00:27 -0000 The following reply was made to PR kern/149643; it has been noted by GNATS. From: Steven Chamberlain To: bug-followup@FreeBSD.org, nox@jelal.kn-bremen.de Cc: henry.hu.sh@gmail.com Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode Date: Sat, 15 Oct 2011 22:56:55 +0100 Hi! I was just trying to debug the same issue because I experienced it using the rum driver on OpenBSD. With this OpenBSD-specific ifconfig line I can force the adapter into 11b-only mode and the beacons (sniffed by another device) are then sent correctly: > # ifconfig rum0 media DS11 mode 11b mediaopt hostap up > 21:22:39.646991 00:19:5b:d3:00:56 > ff:ff:ff:ff:ff:ff, bssid 00:19:5b:d3:00:56: 802.11: beacon, ssid (TESTTEST), rates, ds, tim > 0000: 8000 0000 ffff ffff ffff 0019 5bd3 0056 ....������..[�.V > 0010: 0019 5bd3 0056 3001 b622 1c00 0000 0000 ..[�.V0.�"...... > 0020: 6400 2100 0008 5445 5354 5445 5354 0104 d.!...TESTTEST.. > 0030: 8284 0b16 0301 0105 0400 0100 00 ............. But after switching to 11g mode, the beacons either stop completely, or are sent malformed with wrong destination/subtype: > # ifconfig rum0 media OFDM54 mode 11g mediaopt hostap up > 21:21:14.864881 00:19:5b:d3:00:56 > 32:04:30:48:60:6c, bssid 00:19:5b:d3:00:56, DS >: 802.11: association request > 0000: 0022 0100 3204 3048 606c 0019 5bd3 0056 ."..2.0H`l..[�.V > 0010: 0019 5bd3 0056 408c ef3c b10d 0000 0000 ..[�.V@.�<�..... > 0020: 6400 2104 0008 5445 5354 5445 5354 0108 d.!...TESTTEST.. > 0030: 8284 8b96 0c12 1824 0301 0105 0400 0100 .......$........ > 0040: ef86 7703 d7b9 e937 f1e5 �.w.׹�7� The first 10 bytes of the beacon frame have been replaced with junk. Changing the length of the ESSID can affect what type of packet is sent instead of a beacon. The longer the ESSID, the more bytes from the destination address are overwritten with junk (should always be ff:ff:ff:ff:ff:ff). With ESSID set to "TESTTEST", tshark decoded one of the broken frame like this: > IEEE 802.11 Association Request, Flags: ........ > Type/Subtype: Association Request (0x00) > Frame Control: 0x0001 (Normal) > Version: 1 > Type: Management frame (0) > Subtype: 0 > Flags: 0x0 > Destination address: 30:48:60:6c:ff:ff (30:48:60:6c:ff:ff) > BSS Id: 00:19:5b:d3:00:56 (00:19:5b:d3:00:56) > Fragment number: 0 > IEEE 802.11 wireless LAN management frame > Fixed parameters (4 bytes) > Capability Information: 0xE5A8 > Tagged parameters (46 bytes) > SSID parameter set > Tag Number: 0 (SSID parameter set) > Tag length: 0 > Tag interpretation: : Broadcast > SSID parameter set > Tag Number: 0 (SSID parameter set) > Tag length: 0 > Reserved tag number: Tag 100 Len 0 > Tag Number: 100 (Reserved tag number) > Tag length: 0 > Tag interpretation: Not interpreted > Power Capability > Tag Number: 33 (Power Capability) > Tag length: 4 > Power Capability: Error: Tag length must be exactly 2 bytes long > Minimum Transmit Power: 0x00 > Maximum Transmit Power: 0x08 > Reserved tag number > Tag Number: 83 (Reserved tag number) > Tag length: 84 There are 8 stray bytes (0x0000000064002104) that should not be here, that have been decoded as information elements. Other wireless devices see the first SSID tag and interpret it as meaning 'no SSID'. The SSID tag should instead look like 0x00 = ESSID, 0x08 = length, then 0x54455354... = "TESTTEST", which you can above appeared in a broken 'Power Capability' tag (although 0x5354 became 0x8384). My absolute guess is that an OFDM rate is being chosen for mgmtrate. Maybe this happens if the channel type is wrongly detected as a 5GHz/802.11a one. rum_setup_tx_desc would generate a different result if it is thought to be an OFDM frame: > if_rum.c:1012 if (ieee80211_rate2phytype(ic->ic_rt, rate) == IEEE80211_T_OFDM) { The result would then probably not be what rum_prepare_beacon expects here: > if_rum.c:2139 rum_setup_tx_desc(sc, &desc, RT2573_TX_TIMESTAMP, RT2573_TX_HWSEQ, > if_rum.c:2140 m0->m_pkthdr.len, tp->mgmtrate); > if_rum.c:2142 /* copy the first 24 bytes of Tx descriptor into NIC memory */ > if_rum.c:2143 rum_write_multi(sc, RT2573_HW_BEACON_BASE0, (uint8_t *)&desc, 24); I will have to find some faster hardware to rebuild the driver and test my idea. Or hopefully I've given enough detail that someone else may realise the problem now. Thanks! Regards, -- Steven Chamberlain steven@pyro.eu.org