From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 03:00:21 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 64A20106564A for ; Sun, 9 Jan 2011 03:00:21 +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 3A09B8FC13 for ; Sun, 9 Jan 2011 03:00:21 +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 p0930KZN059545 for ; Sun, 9 Jan 2011 03:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0930KoE059527; Sun, 9 Jan 2011 03:00:20 GMT (envelope-from gnats) Date: Sun, 9 Jan 2011 03:00:20 GMT Message-Id: <201101090300.p0930KoE059527@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Pawel Tyll Cc: Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel Tyll List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 03:00:21 -0000 The following reply was made to PR kern/152360; it has been noted by GNATS. From: Pawel Tyll To: bug-followup@FreeBSD.org Cc: Brandon Gooch Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. Date: Sun, 9 Jan 2011 03:14:09 +0100 As per Brandon Gooch's suggestion system was updated today to FreeBSD 8.2-PRERELEASE #1: Fri Jan 7 17:19:28 CET 2011 due to bug that has been fixed with http://svn.freebsd.org/viewvc/base?view=3Drevision&sortby=3Ddate&revision= =3D216440 Should the system not crash in next 30 days, I'll consider the problem solved and will report back accordingly. Thanks Brandon! From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 05:10: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 44118106566C for ; Sun, 9 Jan 2011 05:10:28 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0CCB48FC0C for ; Sun, 9 Jan 2011 05:10:27 +0000 (UTC) Received: by gyf3 with SMTP id 3so7570611gyf.13 for ; Sat, 08 Jan 2011 21:10:27 -0800 (PST) Received: by 10.100.6.15 with SMTP id 15mr7305052anf.189.1294548166817; Sat, 08 Jan 2011 20:42:46 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id i10sm35726680anh.12.2011.01.08.20.42.45 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 20:42:46 -0800 (PST) Date: Sat, 8 Jan 2011 18:45:37 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: vlan changes to support ipoib X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 05:10:28 -0000 Hi Folks, I have made some changes to vlans and I was wondering if anyone would care to review or test. Especially current vlan users. The diff is here: http://people.freebsd.org/~jeff/vlan.diff I can't say that I like adding all of the function pointers but with vlan support available as a loadable module I have little choice. The new functions allow a driver to fetch the virtual interface associated with a tag, cache and fetch a cookie pointer in a virtual interface, and fetch the tag of a virtual interface. Additionally, the driver was changed to make no assumptions about address size unless the type is IFT_ETHER. This means for multicast entries we store a full sockaddr_dl rather than an ethernet address. It actually simplifies the code here. I also simplified the VLAN_ARRAY stuff by moving it into functions that match the hash names so there aren't ifdef's everywhere. I've tested both hash and array. I also changed the global mtx to an sx lock so the vlan_config event handlers can allocate memory. The way ipoib works requires a full new ipoib softc when a vlan is created. I didn't want to duplicate the vlan config logic so I store that softc using the cookie field and fetch it when necessary. As a result ipoib also doesn't need the weird vlan_input() recursion since the packets appear on the correct device as they are received. I am committing this to my infiniband tree immediately but I would like some review before I merge to current. Thanks, Jeff From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 10:30:08 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 09476106566C for ; Sun, 9 Jan 2011 10:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id B95B28FC08 for ; Sun, 9 Jan 2011 10:30:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id E3F4641C7A6; Sun, 9 Jan 2011 11:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id JfmvE0V672pc; Sun, 9 Jan 2011 11:30:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id F1F2E41C7A5; Sun, 9 Jan 2011 11:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id AFD9E4448F3; Sun, 9 Jan 2011 10:29:42 +0000 (UTC) Date: Sun, 9 Jan 2011 10:29:42 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jeff Roberson In-Reply-To: Message-ID: <20110109102339.K14966@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: vlan changes to support ipoib X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:30:08 -0000 On Sat, 8 Jan 2011, Jeff Roberson wrote: > Hi Folks, > > I have made some changes to vlans and I was wondering if anyone would care to > review or test. Especially current vlan users. The diff is here: > > http://people.freebsd.org/~jeff/vlan.diff > > I can't say that I like adding all of the function pointers but with vlan > support available as a loadable module I have little choice. The new > functions allow a driver to fetch the virtual interface associated with a > tag, cache and fetch a cookie pointer in a virtual interface, and fetch the > tag of a virtual interface. > > Additionally, the driver was changed to make no assumptions about address > size unless the type is IFT_ETHER. This means for multicast entries we store > a full sockaddr_dl rather than an ethernet address. It actually simplifies > the code here. I also simplified the VLAN_ARRAY stuff by moving it into > functions that match the hash names so there aren't ifdef's everywhere. I've > tested both hash and array. > > I also changed the global mtx to an sx lock so the vlan_config event handlers > can allocate memory. The way ipoib works requires a full new ipoib softc > when a vlan is created. I didn't want to duplicate the vlan config logic so > I store that softc using the cookie field and fetch it when necessary. As a > result ipoib also doesn't need the weird vlan_input() recursion since the > packets appear on the correct device as they are received. > > I am committing this to my infiniband tree immediately but I would like some > review before I merge to current. May I ask you to split the diff up into logical junks for both review and commit? Otherwise possible errors not caught with by review will just be a lot harder to track down later. Some of the stuff like "Initialize from parent" seems to be simple enough to be possibly merged just upfront leaving the real beef. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 14:53:40 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 C03A0106566B; Sun, 9 Jan 2011 14:53:40 +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 972C78FC08; Sun, 9 Jan 2011 14:53:40 +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 p09Ere7b068767; Sun, 9 Jan 2011 14:53:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p09EreFt068763; Sun, 9 Jan 2011 14:53:40 GMT (envelope-from linimon) Date: Sun, 9 Jan 2011 14:53:40 GMT Message-Id: <201101091453.p09EreFt068763@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153816: [ixgbe] ixgbe doesn't work properly with the Intel 10gigabit CX4 Dual Port network card X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 14:53:40 -0000 Old Synopsis: ixgbe doesn't work properly with the Intel 10gigabit CX4 Dual Port network card New Synopsis: [ixgbe] ixgbe doesn't work properly with the Intel 10gigabit CX4 Dual Port network card Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 9 14:53:21 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153816 From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 20:00:44 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6405E106566C for ; Sun, 9 Jan 2011 20:00:44 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from manuel.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6098FC12 for ; Sun, 9 Jan 2011 20:00:43 +0000 (UTC) Received: from shelca (zoraida.natserv.net [66.114.65.147]) by manuel.natserv.net (Postfix) with ESMTP id 294A3F497 for ; Sun, 9 Jan 2011 14:42:37 -0500 (EST) Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Francisco Reyes To: freebsd-net@freebsd.org Date: Sun, 09 Jan 2011 14:42:37 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: Lagg questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 20:00:44 -0000 Found a couple of good lagg tutorials http://www.cyberciti.biz/faq/freebsd-network-link-aggregation-trunking/ http://wisekuma.net/linux-bsd/freebsd-lagg/ But there are a few things that I can't find so far... Does one need a third card to reach the machine where one runs lagg? Say I have em0 and em1, do I assign actual IPs to the cards before adding them to lagg or they can't have IPs of their own? Other than lacp protocol do the other options work without having to change anything at the switch? My situation is as follows: Have two connections, 1 T1 and a cable connection. Need to, temporarily, allow outbound traffic between both. In a month or so the office will be moving to a new location and the appropriate bandwith will be allocated, but during the month or so need to do something about the T1 not handling the current load. I will be getting a machine to do the lagg setup and so far ordered 2 NICs, but wondering if I will need a third to access the machine itself. Any links/pointers greatly appreciated. From owner-freebsd-net@FreeBSD.ORG Sun Jan 9 23:27:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72820106566C for ; Sun, 9 Jan 2011 23:27:11 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 31EE88FC0C for ; Sun, 9 Jan 2011 23:27:11 +0000 (UTC) Received: by qyk36 with SMTP id 36so18345821qyk.13 for ; Sun, 09 Jan 2011 15:27:10 -0800 (PST) Received: by 10.224.37.139 with SMTP id x11mr26643185qad.152.1294615629678; Sun, 09 Jan 2011 15:27:09 -0800 (PST) Received: from [10.0.1.198] ([72.253.42.56]) by mx.google.com with ESMTPS id l12sm16992741qcu.43.2011.01.09.15.27.07 (version=SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 15:27:08 -0800 (PST) Date: Sun, 9 Jan 2011 13:29:59 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: "Bjoern A. Zeeb" In-Reply-To: <20110109102339.K14966@maildrop.int.zabbadoz.net> Message-ID: References: <20110109102339.K14966@maildrop.int.zabbadoz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: vlan changes to support ipoib X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 23:27:11 -0000 On Sun, 9 Jan 2011, Bjoern A. Zeeb wrote: > On Sat, 8 Jan 2011, Jeff Roberson wrote: > >> Hi Folks, >> >> I have made some changes to vlans and I was wondering if anyone would care >> to review or test. Especially current vlan users. The diff is here: >> >> http://people.freebsd.org/~jeff/vlan.diff >> >> I can't say that I like adding all of the function pointers but with vlan >> support available as a loadable module I have little choice. The new >> functions allow a driver to fetch the virtual interface associated with a >> tag, cache and fetch a cookie pointer in a virtual interface, and fetch the >> tag of a virtual interface. >> >> Additionally, the driver was changed to make no assumptions about address >> size unless the type is IFT_ETHER. This means for multicast entries we >> store a full sockaddr_dl rather than an ethernet address. It actually >> simplifies the code here. I also simplified the VLAN_ARRAY stuff by moving >> it into functions that match the hash names so there aren't ifdef's >> everywhere. I've tested both hash and array. >> >> I also changed the global mtx to an sx lock so the vlan_config event >> handlers can allocate memory. The way ipoib works requires a full new >> ipoib softc when a vlan is created. I didn't want to duplicate the vlan >> config logic so I store that softc using the cookie field and fetch it when >> necessary. As a result ipoib also doesn't need the weird vlan_input() >> recursion since the packets appear on the correct device as they are >> received. >> >> I am committing this to my infiniband tree immediately but I would like >> some review before I merge to current. > > May I ask you to split the diff up into logical junks for both review > and commit? Otherwise possible errors not caught with by review will > just be a lot harder to track down later. Most if not all of the chunks are interdependent or useless without each other. When I commit to current it will probably be a merge from my branch anyway. What would you like to see separated? > > Some of the stuff like "Initialize from parent" seems to be simple > enough to be possibly merged just upfront leaving the real beef. I notice that I don't have many comments. Perhaps if I documented better what I have done it would be sufficient? Thanks, Jeff > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Going to jail sucks -- All my daemons like it! > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html > From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 10:18: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 4BA0A1065670 for ; Mon, 10 Jan 2011 10:18:25 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2002:d596:2a92:2:155::]) by mx1.freebsd.org (Postfix) with ESMTP id 07FE08FC12 for ; Mon, 10 Jan 2011 10:18:25 +0000 (UTC) Received: from [10.32.67.75] (fw.int.webpartner.dk [213.150.34.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 1C1AA63A95B; Mon, 10 Jan 2011 11:18:21 +0100 (CET) X-DKIM: OpenDKIM Filter v2.1.3 mail.tyknet.dk 1C1AA63A95B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1294654703; bh=e49y9SDDdQuXh82nY4VOSDkzjGs5HaJwWJUvs3oqmOg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=p21TWOtL3+Knmo9DwxnO8JzEybkRF7Ku2eWg2tOaNg/VkORzr1g+SF57/HPbgVeSj tqmyltb0O5sINAez+X/CQQbtngdAG3wVDUngnUsl86Mzof3Ph3sAeM1uzjTuobA7AW 0lun7ILnlaTphuPAUmZdN17trDe2mGeIjm8feFbU= Message-ID: <4D2ADCED.8060809@gibfest.dk> Date: Mon, 10 Jan 2011 11:18:21 +0100 From: Thomas Steen Rasmussen 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: Francisco Reyes References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Lagg questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:18:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09-01-2011 20:42, Francisco Reyes wrote: > Found a couple of good lagg tutorials > http://www.cyberciti.biz/faq/freebsd-network-link-aggregation-trunking/ > http://wisekuma.net/linux-bsd/freebsd-lagg/ > > But there are a few things that I can't find so far... > > Does one need a third card to reach the machine where one runs lagg? > Say I have em0 and em1, do I assign actual IPs to the cards before > adding them to lagg or they can't have IPs of their own? > > Other than lacp protocol do the other options work without having to > change anything at the switch? > > My situation is as follows: > Have two connections, 1 T1 and a cable connection. > Need to, temporarily, allow outbound traffic between both. > Hello, I'm afraid you've misunderstood how lagg works. lagg is for bundling _layer 2_ links. This basically means you can use two or more physical cables to the same switch, to get better speed and/or redundancy. Using lagg to bundle two uplinks to two different providers will not work as you intend. You need to look into using pf or something similar to balance layer 3 traffic across two uplinks. I have had this running at home for years with pf, and it works great. Best regards Thomas Steen Rasmussen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0q3OwACgkQGjEBQafC9MB+4ACggVWVlUCFt25rJTUwBJewA/BA dswAnjVM0Bo84DBAWJila0+NlivtxOxo =B0j2 -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 11:07:07 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8769F10656B6 for ; Mon, 10 Jan 2011 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 74D158FC25 for ; Mon, 10 Jan 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0AB772h001831 for ; Mon, 10 Jan 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0AB76CF001829 for freebsd-net@FreeBSD.org; Mon, 10 Jan 2011 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Jan 2011 11:07:06 GMT Message-Id: <201101101107.p0AB76CF001829@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 Jan 2011 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- 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/153671 net [em] [panic] 8.2-PRERELEASE repeatable kernel in if_em o kern/153610 net [nfe] nfe0 malfunction at boot time 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/153255 net [panic] 8.2-PRERELEASE repeatable kernel panic under h 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/152411 net [re] network card works only on 1000M o kern/152360 net [dummynet] [panic] Crash related to dummynet. o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] encapsulate vlan in ng_ether before output to i o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x 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/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/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 o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout 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 conf/143079 net hostapd(8) startup missing multi wlan functionality 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/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/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 amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/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/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network 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/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic o kern/125501 net [ath] atheros cardbus driver hangs f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/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/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw 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 p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! 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] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working 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/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if 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 bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 360 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 11:10: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 728ED1065696 for ; Mon, 10 Jan 2011 11:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id F22608FC2A for ; Mon, 10 Jan 2011 11:10:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 06E6F41C7C3; Mon, 10 Jan 2011 12:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 28dIqrQnwH9p; Mon, 10 Jan 2011 12:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 5033541C7C9; Mon, 10 Jan 2011 12:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 04A844448F3; Mon, 10 Jan 2011 11:08:52 +0000 (UTC) Date: Mon, 10 Jan 2011 11:08:52 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jeff Roberson In-Reply-To: Message-ID: <20110110103329.W14966@maildrop.int.zabbadoz.net> References: <20110109102339.K14966@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: vlan changes to support ipoib X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 11:10:07 -0000 On Sun, 9 Jan 2011, Jeff Roberson wrote: > On Sun, 9 Jan 2011, Bjoern A. Zeeb wrote: > >> On Sat, 8 Jan 2011, Jeff Roberson wrote: >> >>> Hi Folks, >>> >>> I have made some changes to vlans and I was wondering if anyone would care >>> to review or test. Especially current vlan users. The diff is here: >>> >>> http://people.freebsd.org/~jeff/vlan.diff >>> >>> I can't say that I like adding all of the function pointers but with vlan >>> support available as a loadable module I have little choice. The new >>> functions allow a driver to fetch the virtual interface associated with a >>> tag, cache and fetch a cookie pointer in a virtual interface, and fetch >>> the tag of a virtual interface. >>> >>> Additionally, the driver was changed to make no assumptions about address >>> size unless the type is IFT_ETHER. This means for multicast entries we >>> store a full sockaddr_dl rather than an ethernet address. It actually >>> simplifies the code here. I also simplified the VLAN_ARRAY stuff by >>> moving it into functions that match the hash names so there aren't ifdef's >>> everywhere. I've tested both hash and array. >>> >>> I also changed the global mtx to an sx lock so the vlan_config event >>> handlers can allocate memory. The way ipoib works requires a full new >>> ipoib softc when a vlan is created. I didn't want to duplicate the vlan >>> config logic so I store that softc using the cookie field and fetch it >>> when necessary. As a result ipoib also doesn't need the weird >>> vlan_input() recursion since the packets appear on the correct device as >>> they are received. >>> >>> I am committing this to my infiniband tree immediately but I would like >>> some review before I merge to current. >> >> May I ask you to split the diff up into logical junks for both review >> and commit? Otherwise possible errors not caught with by review will >> just be a lot harder to track down later. > > Most if not all of the chunks are interdependent or useless without each > other. When I commit to current it will probably be a merge from my branch > anyway. > > What would you like to see separated? - the noise (ifp initialization, ..) - the address size changes in preparation for .. - locking can maybe come with the rest of the (*f) for ipoib I think as that's what needs it. You could go by the paragraphs you have above as well. >> >> Some of the stuff like "Initialize from parent" seems to be simple >> enough to be possibly merged just upfront leaving the real beef. > > I notice that I don't have many comments. Perhaps if I documented better > what I have done it would be sufficient? I fear the one "large" commit that in 16 month from now someone will have no idea about. Been there. I know it's additional work but it sometimes really helps. Having debugged too many network stack bugs from corner cases the last 2 years, I'd really appreciate it. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 13:21:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFFA5106564A for ; Mon, 10 Jan 2011 13:21:31 +0000 (UTC) (envelope-from lists@stringsutils.com) Received: from manuel.natserv.net (p65-147.acedsl.com [66.114.65.147]) by mx1.freebsd.org (Postfix) with ESMTP id 9023A8FC15 for ; Mon, 10 Jan 2011 13:21:31 +0000 (UTC) Received: from shelca (zoraida.natserv.net [66.114.65.147]) by manuel.natserv.net (Postfix) with ESMTP id ADE21F497; Mon, 10 Jan 2011 08:21:30 -0500 (EST) References: <4D2ADCED.8060809@gibfest.dk> Message-ID: X-Mailer: http://www.courier-mta.org/cone/ From: Francisco Reyes To: Thomas Steen Rasmussen Date: Mon, 10 Jan 2011 08:21:30 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Lagg questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 13:21:31 -0000 Thomas Steen Rasmussen writes: > Using lagg to bundle two uplinks to two different providers will not work > as you intend. You need to look into using pf or something similar to > balance layer 3 traffic across two uplinks. I have had this running at > home for years with pf, and it works great. Is this along the lines of what I need? http://www.openbsd.org/faq/pf/pools.html Address pools can be used in combination with the route-to filter option to load balance two or more Internet connections when a proper multi-path routing protocol (like BGP4) is unavailable. By using route-to with a round-robin address pool, outbound connections can be evenly distributed among multiple outbound paths From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 13:56: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 27F27106564A for ; Mon, 10 Jan 2011 13:56:42 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2002:d596:2a92:2:155::]) by mx1.freebsd.org (Postfix) with ESMTP id D745B8FC08 for ; Mon, 10 Jan 2011 13:56:41 +0000 (UTC) Received: from [10.20.90.16] (out8.hq.siminn.dk [195.184.109.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 20983638DAC; Mon, 10 Jan 2011 14:56:41 +0100 (CET) X-DKIM: OpenDKIM Filter v2.1.3 mail.tyknet.dk 20983638DAC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1294667801; bh=YNNfep7sQhxUDobhpKFaSrCKn2aoWrpihOjwOH+qks0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XsZwvs/xECxSbQO2ZhDY/rXQCwsfM3Y37ykUqQzVn9EL56PV7u1ebAD8/XUr6i/Ep kyhx9dsRwHn/HCD+MPbqiXjI7WuVh36fxJ58j/kvPjXo7ap+7efPtvMiklOot97DRj mf0JWx5o95UyR/iI1G4r3LWgLDHBDiE16RXmVYT8= Message-ID: <4D2B1018.4020500@gibfest.dk> Date: Mon, 10 Jan 2011 14:56:40 +0100 From: Thomas Steen Rasmussen 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: Francisco Reyes , freebsd-net@freebsd.org References: <4D2ADCED.8060809@gibfest.dk> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Lagg questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 13:56:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-01-2011 14:21, Francisco Reyes wrote: > Thomas Steen Rasmussen writes: > >> Using lagg to bundle two uplinks to two different providers will >> not work as you intend. You need to look into using pf or >> something similar to balance layer 3 traffic across two uplinks. >> I have had this running at home for years with pf, and it works >> great. > > Is this along the lines of what I need? > http://www.openbsd.org/faq/pf/pools.html > > Address pools can be used in combination with the route-to filter > option to load balance two or more Internet connections when a > proper multi-path routing protocol (like BGP4) is unavailable. By > using route-to with a round-robin address pool, outbound > connections can be evenly distributed among multiple outbound > paths Hello, Yes, my setup is based on "route-to" and reply-to, although my setup is less "automatic" since there is a considerable speed difference between my two uplinks (DSL and 50meg fiber). I manually pick the DSL uplink using SSH or a webinterface, if I need to do something from the DSL. If you go with fully automated load balancing across the two uplinks: Be aware that the lack of "proper multipath routing" will be a problem when accessing some sites/applications/systems - like websites with load balancing across different IP addresses. Example: - - Client 1 connects to service X, uplink A is chosen (for the full session due to the state). - - At some point service X redirects client 1 to another mirror, and uplink B is chosen. - - If service X for security reasons checks the client IP address, client 1 will receive an error saying something like "session ip mismatch" or whatever. I've been able to work around these problems when they popped up, not too often fortunately. The solutions are not pretty, though. Good luck with it, Thomas Steen Rasmussen ps. Additional pf questions may be more suitable to post on the freebsd-pf list :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0rEBgACgkQGjEBQafC9MBWZgCggM+82VQPg+ATDO+raTt7dwVa Qq0An3aL/TPfZV/v5ctsptKVypHHps4F =XVBc -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 16:43: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 19061106564A for ; Mon, 10 Jan 2011 16:43:35 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id ABC8B8FC27 for ; Mon, 10 Jan 2011 16:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:Mime-Version:To:Message-Id:Date:Content-Transfer-Encoding:Content-Type:From; bh=wD/4oj7VFvPrUOdv1ghtaVy8Sz+Qd4Kmtyz8s7VsDuE=; b=jc9vE3CUIjyJLPRUMJzIfPwwCeffb4YRfDr4o8mvdIlx9LkNocOX5RAZFONvx4dLJn2DHXUWJFwrbAdqmzOWHKyxd0dYoLhU+hvhtWXV+L89JGhAeOtzmtcW3xFMwIPO; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.59]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PcKYT-0008RJ-SM for freebsd-net@freebsd.org; Mon, 10 Jan 2011 16:25:16 +0000 From: Melissa Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 16:25:08 +0000 Message-Id: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Subject: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 16:43:35 -0000 I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD = 8.1. The server is configured using PopTop (from ports) and PPP = (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we = can't because it doesn't inject packets into the kernel in the same way = and it's not possible to filter on them correctly) Basic PPTP connection works properly. =20 The fun happens when I have two simultaneous users. The first one to = DISCONNECT deletes the routes for both of them and all PPTP traffic = ceases. I believe this is because of the third RTM_DELETE message in the route = monitor output below (=46rom FreeBSD 8.1): got message of size 304 on Mon Jan 10 15:48:40 2011 RTM_CHANGE: Change Metrics or flags: len 304, pid: 7871, seq 3, errno 0, = flags: locks: inits: sockaddrs: 10.0.0.31 tun0 (255) ffff ffff ffff tun0 10.0.5.1 got message of size 232 on Mon Jan 10 15:48:40 2011 RTM_DELETE: Delete Route: len 232, pid: 7871, seq 4, errno 0, = flags: locks: inits: sockaddrs: 10.0.0.31 tun0 (255) ffff ffff ffff got message of size 168 on Mon Jan 10 15:48:40 2011 RTM_IFINFO: iface status change: len 168, if# 11, link: up, = flags: got message of size 192 on Mon Jan 10 15:48:40 2011 RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, = flags: locks: inits: sockaddrs: default 10.0.5.1 default got message of size 116 on Mon Jan 10 15:48:40 2011 RTM_DELADDR: address being removed from iface: len 116, metric 0, flags: sockaddrs: 255.255.255.255 tun0 10.0.5.1 10.0.0.31 On FreeBSD 7.1 the output is as follows: got message of size 232 on Mon Jan 10 16:18:11 2011 RTM_CHANGE: Change Metrics or flags: len 232, pid: 43773, seq 3, errno = 0, flags: locks: inits: sockaddrs: 10.0.0.31 tun14 (255) ffff ffff ffff got message of size 232 on Mon Jan 10 16:18:11 2011 RTM_DELETE: Delete Route: len 232, pid: 43773, seq 4, errno 0, = flags: locks: inits:=20 sockaddrs: 10.0.0.31 tun14 (255) ffff ffff ffff got message of size 168 on Mon Jan 10 16:18:11 2011 RTM_IFINFO: iface status change: len 168, if# 23, link: unknown, = flags: There are quite a few additional messages on connect as well but I don't = believe they are impacting on my issue. Looking in usr.sbin/ppp/route.c = I can't see any changes that would obviously impact on this :( My ppp config for both 7.1 & 8.x is as follows: default: set log Chat LCP IPCP CCP tun command pptp: set timeout 0 set login set ifaddr 10.0.5.1/24 HISADDR 255.255.255.255 disable deflate pred1 deny deflate pred1 enable MPPE accept MPPE enable chap81=20 set mppe 128 stateless I have also confirmed the same behaviour on 8.0 Any ideas?? Mel= From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 16:50:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 186D0106566C for ; Mon, 10 Jan 2011 16:50:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id C80428FC1B for ; Mon, 10 Jan 2011 16:50:26 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:356c:daf:ee13:13d1] ([IPv6:2607:f3e0:0:4:356c:daf:ee13:13d1]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0AGoOMQ028144 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 11:50:24 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D2B38CD.4050707@sentex.net> Date: Mon, 10 Jan 2011 11:50:21 -0500 From: Mike Tancsa 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: Melissa Jenkins References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> In-Reply-To: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 16:50:27 -0000 > > I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we can't because it doesn't inject packets into the kernel in the same way and it's not possible to filter on them correctly) I use mpd a lot. Can you expand on the problem you have with it ? I am not sure what you mean by cant filter on it. ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 18:16: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 E58A8106566C for ; Mon, 10 Jan 2011 18:16:29 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9D5138FC17 for ; Mon, 10 Jan 2011 18:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version; bh=UlM3ghy3m7vqe0nJPfDUX3f7M9G03tx4lWIEmMCL+og=; b=xybRLNDgaWGakXQEpON9iXShXY9CWc/vLTcX+/m9ULLAjjaSaUObHeGB3HABsloP0keUEDks/wdo5zcP8loVwe6qDcDbz4fw/QigofqoaKTsr4oZio9Vu4pzupQbGcBe; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.59]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PcMI4-000ANv-Uc; Mon, 10 Jan 2011 18:16:26 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Melissa Jenkins In-Reply-To: <4D2B38CD.4050707@sentex.net> Date: Mon, 10 Jan 2011 18:16:18 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9B789DC8-365B-4513-840A-1C0A3CFE4A44@littlebluecar.co.uk> References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> <4D2B38CD.4050707@sentex.net> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Cc: Mike Tancsa Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:16:30 -0000 >> I've been working on migrating a PPTP server from FreeBSD 7.1 to = FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP = (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we = can't because it doesn't inject packets into the kernel in the same way = and it's not possible to filter on them correctly) >=20 > I use mpd a lot. Can you expand on the problem you have with it ? I am = not sure what you mean by cant filter on it. Packets sent over a VPN to mpd didn't enter PF at the same point as they = do from PPP - i couldn't get RDR or BINAT to redirect on anything = inbound over the VPN. I haven't tried MPD in almost two years so this may have changed. Mel= From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 18:30:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A1F4106566B for ; Mon, 10 Jan 2011 18:30:57 +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 1282A8FC19 for ; Mon, 10 Jan 2011 18:30:56 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:356c:daf:ee13:13d1] ([IPv6:2607:f3e0:0:4:356c:daf:ee13:13d1]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0AIUsQJ047455 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 13:30:55 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D2B505B.3070703@sentex.net> Date: Mon, 10 Jan 2011 13:30:51 -0500 From: Mike Tancsa 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: Melissa Jenkins References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> <4D2B38CD.4050707@sentex.net> <9B789DC8-365B-4513-840A-1C0A3CFE4A44@littlebluecar.co.uk> In-Reply-To: <9B789DC8-365B-4513-840A-1C0A3CFE4A44@littlebluecar.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:30:57 -0000 On 1/10/2011 1:16 PM, Melissa Jenkins wrote: >>> I've been working on migrating a PPTP server from FreeBSD 7.1 to FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we can't because it doesn't inject packets into the kernel in the same way and it's not possible to filter on them correctly) >> >> I use mpd a lot. Can you expand on the problem you have with it ? I am not sure what you mean by cant filter on it. > > Packets sent over a VPN to mpd didn't enter PF at the same point as they do from PPP - i couldn't get RDR or BINAT to redirect on anything inbound over the VPN. > > I haven't tried MPD in almost two years so this may have changed. When netgraph interfaces come and go, you might need to do a reload of your rules, or dynamically add/delete them if your rule set specifically references ng interfaces. If thats all it was, its easy enough to hook into using something like set iface up-script /usr/local/etc/mpd5/up.sh mpd5.5 is worth checking out for other reasons. It can do a lot and is well supported for pptp stuff. ---Mike From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 20:03: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 42BB310657B2 for ; Mon, 10 Jan 2011 20:03:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D5C778FC0A for ; Mon, 10 Jan 2011 20:03:28 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 899BE46B0D; Mon, 10 Jan 2011 15:03:28 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8070F8A009; Mon, 10 Jan 2011 15:03:27 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 10 Jan 2011 14:55:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101101455.17577.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 10 Jan 2011 15:03:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Jeff Roberson Subject: Re: vlan changes to support ipoib X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 20:03:30 -0000 On Saturday, January 08, 2011 11:45:37 pm Jeff Roberson wrote: > Hi Folks, > > I have made some changes to vlans and I was wondering if anyone would care > to review or test. Especially current vlan users. The diff is here: > > http://people.freebsd.org/~jeff/vlan.diff The devat hook I'm glad to see. I already have a local change that is very similar so that a parent ifnet can find child interfaces via vlan tag ID. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 21:45:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9A3510656AB; Mon, 10 Jan 2011 21:45:54 +0000 (UTC) (envelope-from jack.vogel@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 883F18FC1F; Mon, 10 Jan 2011 21:45:54 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 10 Jan 2011 13:17:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.60,303,1291622400"; d="scan'208";a="645391387" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by fmsmga002.fm.intel.com with ESMTP; 10 Jan 2011 13:17:29 -0800 Received: from orsmsx508.amr.corp.intel.com ([10.22.226.46]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Mon, 10 Jan 2011 13:17:29 -0800 From: "Vogel, Jack" To: TAKAHASHI Yoshihiro , "jfvogel@gmail.com" Date: Mon, 10 Jan 2011 13:17:29 -0800 Thread-Topic: Supermicro Bladeserver Thread-Index: Acuu5cvMyZ5NemA1SYe02R9/WkZ0agCJaEbQ Message-ID: <1DB50624F8348F48840F2E2CF6040A9D014BC5519A@orsmsx508.amr.corp.intel.com> References: <20110108.124018.59640143160055980.nyan@FreeBSD.org> In-Reply-To: <20110108.124018.59640143160055980.nyan@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: RE: Supermicro Bladeserver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:45:54 -0000 We attempted to repro this problem with the 82566DM (ich8 btw) in house and= failed, it worked correctly for my testers. Oh, and just so the mailing lists have an update, the SM Blade problem was = not an issue in the driver, it was a local change in the loader.conf that c= aused the problem. Regards, Jack -----Original Message----- From: TAKAHASHI Yoshihiro [mailto:nyan@FreeBSD.org]=20 Sent: Friday, January 07, 2011 7:40 PM To: jfvogel@gmail.com Cc: freebsd-net@freebsd.org; freebsd-stable@freebsd.org; Vogel, Jack Subject: Re: Supermicro Bladeserver In article Jack Vogel writes: > I am trying to track down a problem being experienced at icir.org using > SuperMicro > bladeservers, the SERDES 82575 interfaces are having connectivity or perh= aps > autoneg problems, resulting in link transitions and watchdog resets. >=20 > The closest hardware my org at Intel has is a Fujitsu server who's blades > also have > this device, but testing on that has failed to repro the problem. >=20 > I was wondering if anyone else out there has this hardware, if so could y= ou > let me > know your experience, have you had problems or not, etc etc? My machine has the following em(4) device and it has a autoneg problem. When I was using 8-stable kernel at 2010/11/01, it has no problem. But I update to 8-stable at 2010/12/01, the kernel is only linked up as 10M. em0@pci0:0:25:0: class=3D0x020000 card=3D0x13d510cf chip=3D0x104a8086 re= v=3D0x02 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82566DM Gigabit Network Connection' class =3D network subclass =3D ethernet --- TAKAHASHI Yoshihiro From owner-freebsd-net@FreeBSD.ORG Mon Jan 10 23: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 EF39D106564A for ; Mon, 10 Jan 2011 23:23:18 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id ABA098FC0C for ; Mon, 10 Jan 2011 23:23:18 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PcQGX-0002wV-7e; Mon, 10 Jan 2011 17:31:05 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <4cfe88b6.1cedd80a.33f5.119d@mx.google.com> Date: Mon, 10 Jan 2011 17:31:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5B47152C-9076-4E54-BCD8-A66FF3E00A42@neville-neil.com> References: <4cfe88b6.1cedd80a.33f5.119d@mx.google.com> To: Rozhuk.IM@gmail.com X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-net@freebsd.org Subject: Re: [arp] possible DoS, fixes and improvements X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 23:23:19 -0000 On Dec 7, 2010, at 14:19 , rozhuk.im@gmail.com wrote: > Hi! >=20 >=20 Hi, Sorry it has taken me a while to test this. In the first two cases I = cannot reproduce your results on HEAD. I have attempted to test this with a modified arpwhohas.py = script using PCS (ports/net/pcs). I can send very large requests and I see them arrive with tcpdump but = the kernel just throws them away. I do not disagree that the code might be wrong, in particular in case 1, = but I cannot reproduce your results. If you wish to share your test code with me that would be fine, or you = can try your test against HEAD and let me know your result. > 1. ah->ar_hln - is depend from ar_hrd? > Yes, and for ARPHRD_ETHER is 6 (ETHER_ADDR_LEN) > For ARPHRD_IEEE1394 - sizeof(struct fw_hwaddr) > ah->ar_hln ignored in ether_output: bcopy(ar_tha(ah), edst, = ETHER_ADDR_LEN); >=20 > check in in_arpinput: > if (ifp->if_addrlen !=3D ah->ar_hln) { > LLE_WUNLOCK(la); > log(LOG_WARNING, > "arp from %*D: addr len: new %d, i/f %d > (ignored)", > ifp->if_addrlen, (u_char *) ar_sha(ah), ":", > ah->ar_hln, ifp->if_addrlen); > goto reply; > } > NO DROP!!!! > In reply we get: > (void)memcpy(ar_tha(ah), ar_sha(ah), ah->ar_hln); > (void)memcpy(ar_sha(ah), enaddr, ah->ar_hln); > Or=20 > (void)memcpy(ar_tha(ah), ar_sha(ah), = ah->ar_hln); > (void)memcpy(ar_sha(ah), &lle->ll_addr, = ah->ar_hln); >=20 > How to use it see below. >=20 >=20 > 2. ah->ar_pln - does not checked! > We can make big arp request (512 nulls after struct arphdr + 2*6 + = 2*4) , > valid for host, set ar_plt =3D 255 > And in reply will receive part of stack or core panic: > in_arpinput: > (void)memcpy(ar_spa(ah), &itaddr, ah->ar_pln); > ... > m->m_len =3D sizeof(*ah) + (2 * ah->ar_pln) + (2 * ah->ar_hln); > ( eq arphdr_len(ah) ) >=20 >=20 >=20 > 3. ar_sha(ah) - does not checked for multicast! > Answers to request my be send to multicast addrs > Only broadcast and host addr are checked. > No check is ar_sha(ah) equal to Ethernet.ether_shost > As result: > arp -an > ? (172.16.0.2) at 01:80:c2:00:00:01 on em0 expires in 118 seconds = [ethernet] >=20 >=20 >=20 > 4. holded packet my be sended without any locks >=20 > Current: > if (la->la_hold !=3D NULL) { > struct mbuf *m_hold, *m_hold_next; >=20 > bcopy(L3_ADDR(la), &sa, sizeof(sa)); > LLE_WUNLOCK(la); > for (m_hold =3D la->la_hold, la->la_hold =3D = NULL; > m_hold !=3D NULL; m_hold =3D m_hold_next) { > m_hold_next =3D m_hold->m_nextpkt; > m_hold->m_nextpkt =3D NULL; > (*ifp->if_output)(ifp, m_hold, &sa, = NULL); > } > } else > LLE_WUNLOCK(la); > la->la_hold =3D NULL; > la->la_numheld =3D 0; >=20 > Here we unlock la and then modify them - this is bad idea! > Patched - see in attached patch. >=20 This is now fixed in HEAD. Thanks! Best, George From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 07:40: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 08F661065670 for ; Tue, 11 Jan 2011 07:40:35 +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 6C8A88FC0A for ; Tue, 11 Jan 2011 07:40:34 +0000 (UTC) Received: by wyf19 with SMTP id 19so20591476wyf.13 for ; Mon, 10 Jan 2011 23:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=dGmhYF7sHxvygItOliX5sKJXiqqbJrNeTByxmCTa+NM=; b=MyEpCotl8SgMI5nNvmA2BaW2l2HgxloZpLiWIGyFPFNlk8r9x4+YK6dx97NGkdLJwL eVkbSj5bLLs4g13uu1lYiMMj4KYs2wDLm2Mn9DDwDhiUH/cDnhG1JLy9IjPfRiF3RlAV TVndMokxMMFDiCe8tACrRB9EQz0Vj+xtyZEs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=VLAHAmaIFNaBOPTjqXyd6IUgcPmpLqmUYRTE7+P95yCZXizYr/t4FU6+hqeGXzOaj2 Cx3NHoCP0nuG8QIbtkm6oii29XfQ6TuoogoeESQBEGvW1CYDNAb6aMInRtCi/XUQW7zI UgmdohUjDylqyfqg1ei4HTO5Qj0meTwig2IVo= MIME-Version: 1.0 Received: by 10.216.180.77 with SMTP id i55mr4108387wem.76.1294731633281; Mon, 10 Jan 2011 23:40:33 -0800 (PST) Received: by 10.216.254.194 with HTTP; Mon, 10 Jan 2011 23:40:33 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 23:40:33 -0800 Message-ID: From: Pyun YongHyeon To: fbsdmail@dnswatch.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204 - is this a new feature? 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 Jan 2011 07:40:35 -0000 On Mon, Jan 10, 2011 at 11:10 PM, wrote: > Greetings, > =A0I have been receiving these messages on a recent 8.1/AMD64 install. > src/ports && world/kern about a week ago. Here is a block from the most > recent output: > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > nfe0: tx v2 error 0x6204 > > It appears to only occur when transmitting largish amounts of data > across an NFS mount. I'm not sure where the MIN-threshold lies. But > appears to be >=3D1.5Mb. > This fresh 8.1/AMD64 is part of a largish server farm comprised of > 7+ - 8.0 i386 servers. This one is the only AMD64. It is also the > only AMD64. I experience this when mounting an 8.0/i386 server from > this 8.1/AMD64. The i386 also has mounts on this 8.1/AMD64. > relevant info: > ### 8.0/i386 > 8.0-STABLE FreeBSD 8.0-STABLE #0: /usr/obj/usr/src/sys/UDNS01 =A0i386 > Tyan 2-CPU MB > 2 NIC's: fxp0 (only one in use) > ### 8.1/AMD64 > FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 > MSI K9N4 Ultra > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz K8-class > CPU) > 1 NIC nfe0 > ### common to both: > rc.conf > nfs_client_enable=3D"YES" > nfs_reserved_port_only=3D"YES" > nfs_server_enable=3D"YES" > > NIC's on both boards are 10/100's @100mbps > > Can anyone provide any insight as to why I should be receiving these > messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible with > earlier versions? > No, I guess you're seeing one of unresolved nfe(4) issues. By chance, are you using forced media configuration instead of auto-negotiation? Posting both dmesg and "ifconfig nfe0" output would be useful. > Thank you for all your time and consideration. > > --Chris From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 07:41: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 59866106566C for ; Tue, 11 Jan 2011 07:41:28 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4D08FC19 for ; Tue, 11 Jan 2011 07:41:27 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0B7Anq5009784; Mon, 10 Jan 2011 23:10:58 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Mon, 10 Jan 2011 23:10:58 -0800 (PST) Message-ID: Date: Mon, 10 Jan 2011 23:10:58 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 07:41:28 -0000 Greetings, I have been receiving these messages on a recent 8.1/AMD64 install. src/ports && world/kern about a week ago. Here is a block from the most recent output: nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 nfe0: tx v2 error 0x6204 It appears to only occur when transmitting largish amounts of data across an NFS mount. I'm not sure where the MIN-threshold lies. But appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a largish server farm comprised of 7+ - 8.0 i386 servers. This one is the only AMD64. It is also the only AMD64. I experience this when mounting an 8.0/i386 server from this 8.1/AMD64. The i386 also has mounts on this 8.1/AMD64. relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: /usr/obj/usr/src/sys/UDNS01 i386 Tyan 2-CPU MB 2 NIC's: fxp0 (only one in use) ### 8.1/AMD64 FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 MSI K9N4 Ultra CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz K8-class CPU) 1 NIC nfe0 ### common to both: rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" nfs_server_enable="YES" NIC's on both boards are 10/100's @100mbps Can anyone provide any insight as to why I should be receiving these messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible with earlier versions? Thank you for all your time and consideration. --Chris From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 09:41:15 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 0EBE0106564A for ; Tue, 11 Jan 2011 09:41:15 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B9EAC8FC19 for ; Tue, 11 Jan 2011 09:41:14 +0000 (UTC) Received: by gwj21 with SMTP id 21so9438406gwj.13 for ; Tue, 11 Jan 2011 01:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Rdryj0HT4epIig+gRE2is9KBOy51pYLsK2i1ga3OFSc=; b=rKOS5WEdW3O8Fx2LHf84902DCPc9a7maFmvnu8A6BUXoap8stlt+lzjICBPZDrgDLE +V7b+mFCtoGzviZIksn735K6DfsSReLHFqD/dEFL10oRZlzqcVFv/XuTOiiGDJtfuMJy 8S0EM6CAGhqzSGn2qi0LicgV9hmBkvh4LrKvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=JR6kqota01bLZiPnioptYi+dXkW/QgR3vnZsBjU0U7vOzKif2xm2roLbBnn9yKKws7 69JivzHY5pEiVz9Cp0HR3lKDnzTdlLURqFUFLNMfimnNlxeN/sMz3F2y+6txn5OjgDIh dbAp2tL5wCutPv3HP9526+tzfhKo4j1MidpMU= Received: by 10.90.30.3 with SMTP id d3mr7389318agd.43.1294737236415; Tue, 11 Jan 2011 01:13:56 -0800 (PST) Received: from [192.168.0.16] ([187.39.27.246]) by mx.google.com with ESMTPS id x31sm38695787ana.9.2011.01.11.01.13.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 01:13:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> Date: Tue, 11 Jan 2011 07:13:50 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> To: Melissa Jenkins X-Mailer: Apple Mail (2.1082) Cc: freebsd-net@freebsd.org Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:41:15 -0000 On Jan 10, 2011, at 2:25 PM, Melissa Jenkins wrote: >=20 > I've been working on migrating a PPTP server from FreeBSD 7.1 to = FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP = (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we = can't because it doesn't inject packets into the kernel in the same way = and it's not possible to filter on them correctly) >=20 > Basic PPTP connection works properly. =20 >=20 > The fun happens when I have two simultaneous users. The first one to = DISCONNECT deletes the routes for both of them and all PPTP traffic = ceases. >=20 > I believe this is because of the third RTM_DELETE message in the route = monitor output below (=46rom FreeBSD 8.1): I believe it's the second call... but probably doesn't matter... >=20 > got message of size 304 on Mon Jan 10 15:48:40 2011 > RTM_CHANGE: Change Metrics or flags: len 304, pid: 7871, seq 3, errno = 0, flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun0 (255) ffff ffff ffff tun0 10.0.5.1 >=20 > got message of size 232 on Mon Jan 10 15:48:40 2011 > RTM_DELETE: Delete Route: len 232, pid: 7871, seq 4, errno 0, = flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun0 (255) ffff ffff ffff >=20 > got message of size 168 on Mon Jan 10 15:48:40 2011 > RTM_IFINFO: iface status change: len 168, if# 11, link: up, = flags: >=20 > got message of size 192 on Mon Jan 10 15:48:40 2011 > RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, = flags: > locks: inits: > sockaddrs: > default 10.0.5.1 default >=20 > got message of size 116 on Mon Jan 10 15:48:40 2011 > RTM_DELADDR: address being removed from iface: len 116, metric 0, = flags: > sockaddrs: > 255.255.255.255 tun0 10.0.5.1 10.0.0.31 >=20 > On FreeBSD 7.1 the output is as follows: >=20 > got message of size 232 on Mon Jan 10 16:18:11 2011 > RTM_CHANGE: Change Metrics or flags: len 232, pid: 43773, seq 3, errno = 0, flags: > locks: inits: > sockaddrs: > 10.0.0.31 tun14 (255) ffff ffff ffff >=20 > got message of size 232 on Mon Jan 10 16:18:11 2011 > RTM_DELETE: Delete Route: len 232, pid: 43773, seq 4, errno 0, = flags: > locks: inits:=20 > sockaddrs: > 10.0.0.31 tun14 (255) ffff ffff ffff >=20 > got message of size 168 on Mon Jan 10 16:18:11 2011 > RTM_IFINFO: iface status change: len 168, if# 23, link: unknown, = flags: >=20 >=20 > There are quite a few additional messages on connect as well but I = don't believe they are impacting on my issue. Looking in = usr.sbin/ppp/route.c I can't see any changes that would obviously impact = on this :( >=20 > My ppp config for both 7.1 & 8.x is as follows: >=20 > default: > set log Chat LCP IPCP CCP tun command >=20 > pptp: > set timeout 0 > set login > set ifaddr 10.0.5.1/24 HISADDR 255.255.255.255 > disable deflate pred1 > deny deflate pred1 > enable MPPE > accept MPPE > enable chap81=20 > set mppe 128 stateless >=20 > I have also confirmed the same behaviour on 8.0 >=20 > Any ideas?? How are you setting the IP address for vpn connections (radius?) ? I'm also using poptop with ppp without any problem, here is my ppp.conf = (look at differences on 'set ifaddr'): default: set log Phase Chat LCP IPCP CCP tun command Warning Error ident user-ppp VERSION (built COMPILATIONDATE) pptp: set ifaddr 10.10.0.1 10.10.3.100-10.10.3.104 255.255.255.255 set timeout 0 enable chap81 disable deflate pred1 deny deflate pred1 enable proxy accept dns set dns 10.10.0.1 set nbns 10.10.0.11 set mtu max 1490 set mru 1490 disable echo set echoperiod 5 disable ipv6cp set mppe 128 stateless Some details: 10.10.0.1 is the internal IP on the pptp server; 10.10.3.100-10.10.3.104 is my range of IPs used for vpn purposes (i'm = using 10.10.0.0/22 as internal network). Regards, Luiz= From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 09:47:34 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 002CA106566C for ; Tue, 11 Jan 2011 09:47:33 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id B251D8FC0A for ; Tue, 11 Jan 2011 09:47:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 7114313DF5F for ; Tue, 11 Jan 2011 12:47:31 +0300 (MSK) Date: Tue, 11 Jan 2011 12:47:29 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1512738982.20110111124729@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:47:34 -0000 Hello, Freebsd-net. Very large and famous (due to very attractive prices) hosting provider Hetzner.de discards FreeBSD support on dedicated servers, because these servers can niot negotiate 100Mbit/DUPLEX when switches' ports are limited to 100Mbit (1Gbit connection costs additional money) only under FreeBSD. Linux works fine. Switches known to be Juniper e3k series. MoBos of servers are different assortment of MSI MoBos with Realtek (re driver) network-on-board. Symptjms are: NIC can not negotiate/set duplex when switch port is limited to 100Mbit/Duplex. Duplex can not be set even manually via "ifconfig": media: Ethernet 100baseTX (100baseTX ) Is it know problem? Maybe, -CURRENT driver has fix for it? Unfortunately, I can not provide more information, as I don't have server at Hetzner (I'm planning to order one, but due to these problems, I'm not sure now, as I need FreeBSD), and all this information is collected in communication with people who HAVE servers with FreeBSD installed. Again, I know, that Realtek NICs are crap, but "everybody says" that Linux doesn't have THIS problem with THESE boards and switches. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 09:47: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 DEEF01065705 for ; Tue, 11 Jan 2011 09:47:48 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id 969908FC1C for ; Tue, 11 Jan 2011 09:47:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version; bh=shXt8FTx06YCLU2jJ7YlZ0K/5MKgpRx/ZVgQWPyarec=; b=S3u46RM+cVu6OZnMN5KmUihg4biXV5+HXCjfUE1xtb/7iGkdPsq11TVY2kMSzeOct+AoQCELb2ZE0hEfuNSNqYqQYsQzHq8OV1JamFxkMgJu23aDrNONFaQ+dot8xcTr; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.59]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PcapM-0001sI-9j; Tue, 11 Jan 2011 09:47:46 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Melissa Jenkins In-Reply-To: <01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> Date: Tue, 11 Jan 2011 09:47:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> <01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Cc: Luiz Otavio O Souza Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:47:49 -0000 On 11 Jan 2011, at 09:13, Luiz Otavio O Souza wrote: > On Jan 10, 2011, at 2:25 PM, Melissa Jenkins wrote: >>=20 >> I've been working on migrating a PPTP server from FreeBSD 7.1 to = FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP = (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we = can't because it doesn't inject packets into the kernel in the same way = and it's not possible to filter on them correctly) >>=20 >> Basic PPTP connection works properly. =20 >>=20 >> The fun happens when I have two simultaneous users. The first one to = DISCONNECT deletes the routes for both of them and all PPTP traffic = ceases. >>=20 >> I believe this is because of the third RTM_DELETE message in the = route monitor output below (=46rom FreeBSD 8.1): >=20 >=20 > I believe it's the second call... but probably doesn't matter... Yes - I must have switched programming languages and ended up starting = at 1 :( >=20 > How are you setting the IP address for vpn connections (radius?) ? >=20 I've got them configured in the third column in the secret file: eg: ...=20 melissa dummypw 10.0.0.31 john dummypw 10.0.0.32 > I'm also using poptop with ppp without any problem, here is my = ppp.conf (look at differences on 'set ifaddr'): >=20 > default: > set log Phase Chat LCP IPCP CCP tun command Warning Error > ident user-ppp VERSION (built COMPILATIONDATE) >=20 > pptp: > set ifaddr 10.10.0.1 10.10.3.100-10.10.3.104 255.255.255.255 > [snip] > Some details: >=20 > 10.10.0.1 is the internal IP on the pptp server; > 10.10.3.100-10.10.3.104 is my range of IPs used for vpn purposes (i'm = using 10.10.0.0/22 as internal network). I've just tried it configured as set ifaddr 10.0.5.1 HISADDR 255.255.255.255 It still sends the route delete: got message of size 192 on Mon Jan 10 23:35:03 2011 RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, = flags: locks: inits: sockaddrs: default 10.0.5.1 default with set ifaddr 10.0.5.1 10.0.0.1-10.0.0.255 255.255.255.255 got message of size 192 on Mon Jan 10 23:37:02 2011 RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0, = flags: locks: inits: sockaddrs: default 10.0.5.1 default :( Going to spend some time looking at the PPP code and see if I can figure = out what triggers it. Mel= From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 10:30: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 141E11065670 for ; Tue, 11 Jan 2011 10:30:37 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id A0C428FC22 for ; Tue, 11 Jan 2011 10:30:36 +0000 (UTC) Received: from [2001:6f8:108a:1:21b:21ff:fe07:b562] (unknown [IPv6:2001:6f8:108a:1:21b:21ff:fe07:b562]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id 624EC1666579; Tue, 11 Jan 2011 11:30:30 +0100 (CET) Date: Tue, 11 Jan 2011 11:30:23 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@saya.home.yamagi.org To: Lev Serebryakov In-Reply-To: <1512738982.20110111124729@serebryakov.spb.ru> Message-ID: References: <1512738982.20110111124729@serebryakov.spb.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:30:37 -0000 On Tue, 11 Jan 2011, Lev Serebryakov wrote: > Very large and famous (due to very attractive prices) hosting > provider Hetzner.de discards FreeBSD support on dedicated servers, > because these servers can niot negotiate 100Mbit/DUPLEX when > switches' ports are limited to 100Mbit (1Gbit connection costs > additional money) only under FreeBSD. Linux works fine. > > Switches known to be Juniper e3k series. > > MoBos of servers are different assortment of MSI MoBos with Realtek > (re driver) network-on-board. > > Symptjms are: NIC can not negotiate/set duplex when switch port is > limited to 100Mbit/Duplex. Duplex can not be set even manually via > "ifconfig": > > > media: Ethernet 100baseTX (100baseTX ) > > Is it know problem? Maybe, -CURRENT driver has fix for it? > > Unfortunately, I can not provide more information, as I don't have > server at Hetzner (I'm planning to order one, but due to these > problems, I'm not sure now, as I need FreeBSD), and all this > information is collected in communication with people who HAVE servers > with FreeBSD installed. Hi, I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs just fine. I've never seen this strange negotiation problem myself. But maybe I was just lucky and got working mainboard and nic combinations. So if further information is needed, I'm happy to provide it. Some data: % ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b [snip] nd6 options=3 media: Ethernet autoselect (100baseTX ) status: active $ dmesg re0: port 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xf6ff0000-0xf6ffffff irq 16 at device 0.0 on pci6 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 40:61:86:f3:d7:20 re0: [FILTER] Also have a look at the FreeBSD section in the Hetzner Wiki: http://wiki.hetzner.de/index.php/FreeBSD It's in german but Google can translate it :) Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 10:53:34 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 218EF1065672 for ; Tue, 11 Jan 2011 10:53:34 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id D08008FC16 for ; Tue, 11 Jan 2011 10:53:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 9019213DF5F; Tue, 11 Jan 2011 13:53:32 +0300 (MSK) Date: Tue, 11 Jan 2011 13:53:30 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <122467803.20110111135330@serebryakov.spb.ru> To: Yamagi Burmeister In-Reply-To: References: <1512738982.20110111124729@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:53:34 -0000 Hello, Yamagi. You wrote 11 =FF=ED=E2=E0=F0=FF 2011 =E3., 13:30:23: > Hi, > I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs > just fine. I've never seen this strange negotiation problem myself. But > maybe I was just lucky and got working mainboard and nic combinations. > So if further information is needed, I'm happy to provide it. It is known, that problems are in DC 13 and everything wotrks fine in DC 11 and DC 12. I've discussed this problem in local (Russian-speaking) FreeBSD community, and there are several people in DC 13 who HAVE these problems and found different solutions, but all non-technical ones: order gigabit connectivity, or pay for moving servers to other (old) DCs... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 11:00: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 2AD0C1065672 for ; Tue, 11 Jan 2011 11:00:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id C33138FC18 for ; Tue, 11 Jan 2011 11:00:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 2369C41C7AA; Tue, 11 Jan 2011 12:00:08 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id OCQPaFj5qUJP; Tue, 11 Jan 2011 12:00:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 52E3A41C7A9; Tue, 11 Jan 2011 12:00:06 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id DB9354448F3; Tue, 11 Jan 2011 10:56:12 +0000 (UTC) Date: Tue, 11 Jan 2011 10:56:12 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Yamagi Burmeister In-Reply-To: Message-ID: <20110111105012.X14966@maildrop.int.zabbadoz.net> References: <1512738982.20110111124729@serebryakov.spb.ru> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 11:00:09 -0000 On Tue, 11 Jan 2011, Yamagi Burmeister wrote: >> Very large and famous (due to very attractive prices) hosting >> provider Hetzner.de discards FreeBSD support on dedicated servers, >> because these servers can niot negotiate 100Mbit/DUPLEX when >> switches' ports are limited to 100Mbit (1Gbit connection costs >> additional money) only under FreeBSD. Linux works fine. >> >> Switches known to be Juniper e3k series. ... > I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs > just fine. I've never seen this strange negotiation problem myself. But > maybe I was just lucky and got working mainboard and nic combinations. > So if further information is needed, I'm happy to provide it. A lot of us do. There is a problem with the re(4) setup as well in that if you do not send packets out yourself the port takes a very long time to come up and unblocked. I haven't discussed that with them or tested with an updated HEAD (since end of October). But yes, I am running HEAD on an EQ4 as well. If you have problems and a personal email contact at Hetzner feel free to talk to me. I am "local" (a couple of 100km away in the same country) and a FreeBSD committer and I can probably figure things out with them or properly proxy requests. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 11:34: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 A117A106564A for ; Tue, 11 Jan 2011 11:34:28 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id 595D38FC0A for ; Tue, 11 Jan 2011 11:34:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Mime-Version:Content-Type; bh=KCMOBE39rj1MtA6/F/nZ6+W+vTj7iOQpvBdQTFiw1uo=; b=KNTRtAZAluLSSFTd1/LpENBqqkg1QMPT85QuQoEdqNYMfysV9ImyTh+XctMnL4Mx4i+oyuOHzPUjKweMhMUYR/P2UX1kWhxZTYqFnp2/Sn9e0EMrgGFpyeNPP6Dy8bdc; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.59]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PccUa-0003oE-QR for freebsd-net@freebsd.org; Tue, 11 Jan 2011 11:34:27 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Melissa Jenkins In-Reply-To: <01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> Date: Tue, 11 Jan 2011 11:34:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk> <01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 11:34:28 -0000 > I've been working on migrating a PPTP server from FreeBSD 7.1 to = FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP = (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we = can't because it doesn't inject packets into the kernel in the same way = and it's not possible to filter on them correctly) >=20 > Basic PPTP connection works properly. =20 >=20 > The fun happens when I have two simultaneous users. The first one to = DISCONNECT deletes the routes for both of them and all PPTP traffic = ceases. Just been working my way through the PPP code - which doesn't actually = appear to have changed. However, the netinet/in.c does have some comments in the SVN history = about deleting the loopback address, this appears to have been merged in = as part of the 8 release cycle (r197231 perhaps) (though I'm not an = expert at SVN etc) What should happen when there are multiple interfaces with the same = address. When I have two tunnels configured they show up as (eg)=20 tun0: flags=3D8051 metric 0 mtu 1398 options=3D80000 inet 10.0.5.1 --> 10.0.0.31 netmask 0xffffffff=20 Opened by PID 12616 tun1: flags=3D8051 metric 0 mtu 1398 options=3D80000 inet 10.0.5.1 --> 10.0.0.32 netmask 0xffffffff=20 Opened by PID 12630 If the loop back address is 10.0.5.1 and closing one of them deletes the = loopback what should happen? Should it delete all routes that refer to = 10.0.5.1? Mel From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 14:04: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 408F3106566B; Tue, 11 Jan 2011 14:04:35 +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 B93F68FC0C; Tue, 11 Jan 2011 14:04:34 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:356c:daf:ee13:13d1] ([IPv6:2607:f3e0:0:4:356c:daf:ee13:13d1]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0BE4Wwk098681 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 09:04:32 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D2C636B.5040003@sentex.net> Date: Tue, 11 Jan 2011 09:04:27 -0500 From: Mike Tancsa 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: Jan Koum References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> 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.67 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Sean Bruno , Jack Vogel , Ivan Voras , "freebsd-hardware@freebsd.org" Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 14:04:35 -0000 On 12/24/2010 5:44 PM, Jan Koum wrote: > hi Ivan and Mike, > > wanted to follow up and see if you found a solid long-term solution to this > bug. we are still seeing this problem in our 8.2 environment with ASPM > already disabled. here is what we have: > > 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: > Hi Jack, Looks like this problem is not completely gone :( I have seen it now on 2 different machines. On the RELENG_7, ASPM was enabled in the BIOS (INTEL DH55TC MB), so I have disabled that for now to see what happens. On the RELENG_8 machine, its been a LOT better since 7.1.8, but again it happened last night during a backup dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.8 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PEX4.HART dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0x34ec class=0x020000 dev.em.1.%parent: pci10 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.link_irq: 346 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: 1209008712 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: 231 dev.em.1.queue0.txd_tail: 231 dev.em.1.queue0.tx_irq: 828804317 dev.em.1.queue0.no_desc_avail: 0 dev.em.1.queue0.rxd_head: 692 dev.em.1.queue0.rxd_tail: 691 dev.em.1.queue0.rx_irq: 1035962009 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: 395 dev.em.1.mac_stats.recv_no_buff: 22 dev.em.1.mac_stats.recv_undersize: 0 dev.em.1.mac_stats.recv_fragmented: 0 dev.em.1.mac_stats.recv_oversize: 0 dev.em.1.mac_stats.recv_jabber: 0 dev.em.1.mac_stats.recv_errs: 0 dev.em.1.mac_stats.crc_errs: 0 dev.em.1.mac_stats.alignment_errs: 0 dev.em.1.mac_stats.coll_ext_errs: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.total_pkts_recvd: 2374779279 dev.em.1.mac_stats.good_pkts_recvd: 2374778884 dev.em.1.mac_stats.bcast_pkts_recvd: 91866 dev.em.1.mac_stats.mcast_pkts_recvd: 14709 dev.em.1.mac_stats.rx_frames_64: 3694217 dev.em.1.mac_stats.rx_frames_65_127: 42644392 dev.em.1.mac_stats.rx_frames_128_255: 52724116 dev.em.1.mac_stats.rx_frames_256_511: 768263 dev.em.1.mac_stats.rx_frames_512_1023: 28549934 dev.em.1.mac_stats.rx_frames_1024_1522: 2246397962 dev.em.1.mac_stats.good_octets_recvd: 3420561094673 dev.em.1.mac_stats.good_octets_txd: 130129757787 dev.em.1.mac_stats.total_pkts_txd: 1553568635 dev.em.1.mac_stats.good_pkts_txd: 1553568635 dev.em.1.mac_stats.bcast_pkts_txd: 13131 dev.em.1.mac_stats.mcast_pkts_txd: 9 dev.em.1.mac_stats.tx_frames_64: 564243380 dev.em.1.mac_stats.tx_frames_65_127: 864123029 dev.em.1.mac_stats.tx_frames_128_255: 119250324 dev.em.1.mac_stats.tx_frames_256_511: 240369 dev.em.1.mac_stats.tx_frames_512_1023: 554247 dev.em.1.mac_stats.tx_frames_1024_1522: 5157286 dev.em.1.mac_stats.tso_txd: 1216433 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.interrupts.asserts: 51 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: 0 em1: flags=8843 metric 0 mtu 1500 options=219b ether 00:15:17:ed:68:a4 inet xx.yy.13.254 netmask 0xffffff00 broadcast zz.yy.13.255 inet6 fe80::215:17ff:feed:68a4%em1 prefixlen 64 scopeid 0x3 inet xx.zz.1.1 netmask 0xffffff00 broadcast xx.zz.1.255 inet6 2607:f3e0:xxxxxxxxxx prefixlen 64 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active em1@pci0:10:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffffed68a4 The MB is an INTEL S3420GPX ---Mike From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 14:42:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DDBE1065670 for ; Tue, 11 Jan 2011 14:42:31 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id A56FD8FC0C for ; Tue, 11 Jan 2011 14:42:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PcfQX-0001Gf-GM for freebsd-net@freebsd.org; Tue, 11 Jan 2011 15:42:25 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Jan 2011 15:42:25 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Jan 2011 15:42:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Tue, 11 Jan 2011 15:42:13 +0100 Lines: 70 Message-ID: References: <1290533941.3173.50.camel@home-yahoo> <4CEC0548.1080801@sentex.net> <4D2C636B.5040003@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4D2C636B.5040003@sentex.net> X-Enigmail-Version: 1.1.2 Cc: freebsd-hardware@freebsd.org Subject: Re: em driver, 82574L chip, and possibly ASPM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 14:42:31 -0000 On 11/01/2011 15:04, Mike Tancsa wrote: > On 12/24/2010 5:44 PM, Jan Koum wrote: >> hi Ivan and Mike, >> >> wanted to follow up and see if you found a solid long-term solution to this >> bug. we are still seeing this problem in our 8.2 environment with ASPM >> already disabled. here is what we have: >> >> 1. motherboard is SuperMicro X8SIE-LN4F Intel Xeon: >> > > Hi Jack, > Looks like this problem is not completely gone :( I have seen it now on 2 different machines. On the RELENG_7, ASPM was enabled in the BIOS (INTEL DH55TC MB), so I have disabled that for now to see what happens. On the RELENG_8 machine, its been a LOT better since 7.1.8, but again it happened last night during a backup My machine is still holding up but it doesn't yet handle full traffic. I've just noticed something strange: both em0 and em1 are marked "active" in ifconfig even though there's no cable in em1 port :( em0: flags=8843 metric 0 mtu 1500 options=219b ether 00:25:90:0b:77:5c inet 10.10.0.33 netmask 0xffffff00 broadcast 10.10.0.255 media: Ethernet autoselect (100baseTX ) status: active em1: flags=8802 metric 0 mtu 1500 options=219b ether 00:25:90:0b:77:5d media: Ethernet autoselect (100baseTX ) status: active (100 mbit is expected) Note "AER 1 0 fatal 0 non-fatal 1 corrected" in my output - I don't know if it's significant. em0@pci0:3:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfb5e0000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xdc00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfb5dc000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 002590ffff0b775c em1@pci0:4:0:0: class=0x020000 card=0x040d15d9 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xfb6e0000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0xec00, size 32, enabled bar [1c] = type Memory, range 32, base 0xfb6dc000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 002590ffff0b775d From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 14:43:22 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 AFB501065674; Tue, 11 Jan 2011 14:43:22 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 455308FC17; Tue, 11 Jan 2011 14:43:22 +0000 (UTC) Received: from [2001:6f8:108a:1:21b:21ff:fe07:b562] (unknown [IPv6:2001:6f8:108a:1:21b:21ff:fe07:b562]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id E7D68166657A; Tue, 11 Jan 2011 15:43:20 +0100 (CET) Date: Tue, 11 Jan 2011 15:43:14 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@saya.home.yamagi.org To: "Bjoern A. Zeeb" In-Reply-To: <20110111105012.X14966@maildrop.int.zabbadoz.net> Message-ID: References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111105012.X14966@maildrop.int.zabbadoz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Lev Serebryakov , Yamagi Burmeister Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 14:43:22 -0000 On Tue, 11 Jan 2011, Bjoern A. Zeeb wrote: >> I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs >> just fine. I've never seen this strange negotiation problem myself. But >> maybe I was just lucky and got working mainboard and nic combinations. >> So if further information is needed, I'm happy to provide it. > A lot of us do. There is a problem with the re(4) setup as well in > that if you do not send packets out yourself the port takes a very > long time to come up and unblocked. I haven't discussed that with > them or tested with an updated HEAD (since end of October). I never said that this problems doesn't exists. :) Lev Serebryakov said that everythings works fine in DC11 and DC12, my servers are in DC12. so I was just lucky... > But yes, I am running HEAD on an EQ4 as well. If you have problems > and a personal email contact at Hetzner feel free to talk to me. > I am "local" (a couple of 100km away in the same country) and a FreeBSD > committer and I can probably figure things out with them or properly > proxy requests. Sadly no. My only contact to Hetzner is the service e-mail adress and the phone number for business clients. They are for all customers and probably can't help with such problems. There are special technical contacts for each DC, but those are only available for customers with hardware in that DC and with specific problems. So someone with a server in DC13 could write a service request in which the problem is explained and ask for help. Maybe they're willing ton assistent in tracking down and solving the problem. Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 15:54: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 86C171065697 for ; Tue, 11 Jan 2011 15:54:00 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFBC8FC13 for ; Tue, 11 Jan 2011 15:53:59 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p0BFdkts001403; Tue, 11 Jan 2011 07:39:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2011 07:36:26 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Route Delete Thread-Index: Acuxg5CmIsBm4OTGSiik8ND+TXtJqgAIb6/V References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk><01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> From: "Li, Qing" To: "Melissa Jenkins" , Cc: Subject: RE: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 15:54:00 -0000 The self-pointing route 10.0.5.1 should have multiple references set on it, and that route won't be deleted from the routing table until the=20 last reference is removed. =20 You can verify that by checking the "netstat" output, the "Ref" column after tun1 has been created. =20 The above has been verified with both mpd and other tests. =20 -- Qing ________________________________ From: owner-freebsd-net@freebsd.org on behalf of Melissa Jenkins Sent: Tue 1/11/2011 3:34 AM To: freebsd-net@freebsd.org Subject: Re: PPP and Route Delete > I've been working on migrating a PPTP server from FreeBSD 7.1 to = FreeBSD 8.1. The server is configured using PopTop (from ports) and PPP = (/usr/sbin) rather than MPD. (Before anybody tells me to use MPD we = can't because it doesn't inject packets into the kernel in the same way = and it's not possible to filter on them correctly) > > Basic PPTP connection works properly.=20 > > The fun happens when I have two simultaneous users. The first one to = DISCONNECT deletes the routes for both of them and all PPTP traffic = ceases. Just been working my way through the PPP code - which doesn't actually = appear to have changed. However, the netinet/in.c does have some comments in the SVN history = about deleting the loopback address, this appears to have been merged in = as part of the 8 release cycle (r197231 perhaps) (though I'm not an = expert at SVN etc) What should happen when there are multiple interfaces with the same = address. When I have two tunnels configured they show up as (eg) tun0: flags=3D8051 metric 0 mtu 1398 options=3D80000 inet 10.0.5.1 --> 10.0.0.31 netmask 0xffffffff Opened by PID 12616 tun1: flags=3D8051 metric 0 mtu 1398 options=3D80000 inet 10.0.5.1 --> 10.0.0.32 netmask 0xffffffff Opened by PID 12630 If the loop back address is 10.0.5.1 and closing one of them deletes the = loopback what should happen? Should it delete all routes that refer to = 10.0.5.1? Mel _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 17:05:08 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 A0F521065673 for ; Tue, 11 Jan 2011 17:05:08 +0000 (UTC) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.freebsd.org (Postfix) with SMTP id 1F8958FC18 for ; Tue, 11 Jan 2011 17:05:07 +0000 (UTC) Received: (qmail 89214 invoked by uid 1001); 11 Jan 2011 16:38:26 -0000 Date: Tue, 11 Jan 2011 11:38:25 -0500 From: Brian Reichert To: Lev Serebryakov Message-ID: <20110111163825.GF7511@numachi.com> References: <1512738982.20110111124729@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512738982.20110111124729@serebryakov.spb.ru> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 17:05:08 -0000 On Tue, Jan 11, 2011 at 12:47:29PM +0300, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Very large and famous (due to very attractive prices) hosting > provider Hetzner.de discards FreeBSD support on dedicated servers, > because these servers can niot negotiate 100Mbit/DUPLEX when > switches' ports are limited to 100Mbit (1Gbit connection costs > additional money) only under FreeBSD. Linux works fine. How are the switches being forced to 100/full? If they're doing so by disabling autonegotiation, then that's where some grief may come from. If it's not, then ignore the rest of this email. :) For certain hardware combos, I've seen even Linux servers (on Dell hardware) fail to autonegotiate properly. Here's the set of litany I trot out when I have to deal with customer's issues surrounding gigabit and autonegotiation: ------------- With the advent of 1000T networking, the specs says that autonegotation needs to be enabled: http://etherealmind.com/2008/07/15/ethernet-autonegotiation-works-why-how-standard-should-be-set/ " A major problem is that many people are also hard setting Gigabit Ethernet, and this is causing major problems. Gigabit Ethernet must have auto-negotiation ENABLED to allow negotiation of master / slave PHY relationship for clocking at the physical layer. Without negotiation the line clock will not establish correctly and physical layers problems can result." Further, this doc from Dell: http://www.dell.com/content/topics/global.aspx/power/en/ps1q01_hernan?c=us&cs=555&l=en&s=biz Cites: "In addition, the 1999 standard for Gigabit over copper cabling, IEEE Std 802.3ab, added the following enhancements to the Auto-Negotiation standard:" * Mandatory auto-negotiation for 1000BaseT * Configure master and slave modes for the PHY Further: http://en.wikipedia.org/wiki/Autonegotiation "The debatable portions of the autonegotiation specifications were eliminated by the 1998 version of IEEE 802.3. In 1999, the negotiation protocol was significantly extended by IEEE 802.3ab, which specified the protocol for gigabit Ethernet, making autonegotiation mandatory for 1000BASE-T gigabit Ethernet over copper." > _______________________________________________ > 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" -- Brian Reichert 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 18:00: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 18A531065675 for ; Tue, 11 Jan 2011 18:00:49 +0000 (UTC) (envelope-from melissa-freebsd@littlebluecar.co.uk) Received: from filter.blacknosugar.com (filter.blacknosugar.com [212.13.204.214]) by mx1.freebsd.org (Postfix) with ESMTP id BF97C8FC0C for ; Tue, 11 Jan 2011 18:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=littlebluecar.co.uk; s=dkim; h=Subject:To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version; bh=H+6jnXtcuc0u5ewCrLoPix9RiNXeAhjNaFTE+N0SbtQ=; b=gbiSZwSy54YBj+V3mdLa56jnUS+M2Jfb/0vj/am9VEv/UdIHwRXLJtfLxQKnWmWBWpOAQRE25BJLz+PV5yN3wXA6RW67PlwmnffURh5n4Qy7ANtRKOsyR/Ke/AyPy7MJ; Received: from bowser.blacknosugar.com ([78.86.203.16] helo=[192.168.1.59]) by filter.blacknosugar.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PciWS-000ASs-DB; Tue, 11 Jan 2011 18:00:46 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Melissa Jenkins In-Reply-To: Date: Tue, 11 Jan 2011 18:00:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2F834993-9338-4D1A-B71A-2166EB427629@littlebluecar.co.uk> References: <63A5C79A-B4C3-42C3-9B76-1F2EB04DB871@littlebluecar.co.uk><01EE1F52-3393-4A43-882F-C35677CB0754@gmail.com> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1082) X-SA-Exim-Connect-IP: 78.86.203.16 X-SA-Exim-Mail-From: melissa-freebsd@littlebluecar.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on filter X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on filter.blacknosugar.com) Cc: "Li, Qing" Subject: Re: PPP and Route Delete X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:00:49 -0000 > The self-pointing route 10.0.5.1 should have multiple references set = on > it, and that route won't be deleted from the routing table until the=20= > last reference is removed. >=20 > You can verify that by checking the "netstat" output, the "Ref" column > after tun1 has been created. >=20 > The above has been verified with both mpd and other tests. Thank you! The bit I had neglected to mention (as the bug report suggested it was a = problem with the local route table) was that we are re-distributing = routes using openbgpd. I have confirmed that the openbgpd code has no = concept of this reference counting and simply removes the route from the = table that is being sent out. =20 Sorry for the noise - I should have spotted that myself :( Mel=20= From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:29:17 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 8B524106564A for ; Tue, 11 Jan 2011 19:29:17 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 468928FC12 for ; Tue, 11 Jan 2011 19:29:17 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 6424113DF5F; Tue, 11 Jan 2011 22:29:15 +0300 (MSK) Date: Tue, 11 Jan 2011 22:29:13 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <76226157.20110111222913@serebryakov.spb.ru> To: Brian Reichert In-Reply-To: <20110111163825.GF7511@numachi.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:29:17 -0000 Hello, Brian. You wrote 11 =FF=ED=E2=E0=F0=FF 2011 =E3., 19:38:25: >> Very large and famous (due to very attractive prices) hosting >> provider Hetzner.de discards FreeBSD support on dedicated servers, >> because these servers can niot negotiate 100Mbit/DUPLEX when >> switches' ports are limited to 100Mbit (1Gbit connection costs >> additional money) only under FreeBSD. Linux works fine. > How are the switches being forced to 100/full? I don't know, I never work with Juniper e3k switches (And any other Juniper products at all). All I know, that older Juniper Switches in not-so-new DCs of same provider doesn't have this problem, and, on other hand, Linux and Windows 2008 don't have problems with new ones too. > If they're doing so by disabling autonegotiation, then that's where > some grief may come from. Linux work with autonegotiation, as I can see (It is outpuit from Rescue Linux system on SAME my server, where FreeBSD shows half-duplex even if forced to full-duplex): root@rescue ~ # mii-tool -v eth0 eth0: 100 Mbit, full duplex, link ok product info: vendor 00:07:32, model 17 rev 2 basic mode: 100 Mbit, full duplex basic status: link ok capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT= -FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-HD root@rescue ~ # ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes root@rescue ~ # So, it seems, that autonegotiation is disabled, but it works for Linux, and manual setting of media and mediaopt doesn't help FreeBSD. Also, please note, that when port is in 1Gib mode (which can be buyed for additional money, which I can not afford) FreeBSD works fine. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:37:34 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 7368A1065672 for ; Tue, 11 Jan 2011 19:37:34 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F3A08FC0A for ; Tue, 11 Jan 2011 19:37:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3214813DF61; Tue, 11 Jan 2011 22:37:33 +0300 (MSK) Date: Tue, 11 Jan 2011 22:37:31 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <773123481.20110111223731@serebryakov.spb.ru> To: Brian Reichert , freebsd-net@freebsd.org In-Reply-To: <76226157.20110111222913@serebryakov.spb.ru> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:37:34 -0000 Hello, Brian. You wrote 11 =FF=ED=E2=E0=F0=FF 2011 =E3., 22:29:13: > basic mode: 100 Mbit, full duplex > link partner: 100baseTx-HD It looks VERY strange. How could id be? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:39:43 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A985106564A for ; Tue, 11 Jan 2011 19:39:43 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from lazy.aws-net.org.ua (lazy.aws-net.org.ua [IPv6:2a00:1db0:20::828:140]) by mx1.freebsd.org (Postfix) with ESMTP id 852118FC15 for ; Tue, 11 Jan 2011 19:39:42 +0000 (UTC) Received: from [192.168.32.4] (alf.aws-net.org.ua [85.90.196.192]) (authenticated bits=0) by lazy.aws-net.org.ua (8.14.3/8.14.3) with ESMTP id p0BJdWCO083255 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 11 Jan 2011 21:39:40 +0200 (EET) (envelope-from artem@aws-net.org.ua) Message-ID: <4D2CB1F5.6080106@aws-net.org.ua> Date: Tue, 11 Jan 2011 21:39:33 +0200 From: Artyom Viklenko Organization: Art&Co. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> In-Reply-To: <76226157.20110111222913@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (lazy.aws-net.org.ua [188.230.120.140]); Tue, 11 Jan 2011 21:39:40 +0200 (EET) Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:39:43 -0000 11.01.2011 21:29, Lev Serebryakov ïèøåò: > Hello, Brian. > You wrote 11 ÿíâàðÿ 2011 ã., 19:38:25: > > >>> Very large and famous (due to very attractive prices) hosting >>> provider Hetzner.de discards FreeBSD support on dedicated servers, >>> because these servers can niot negotiate 100Mbit/DUPLEX when >>> switches' ports are limited to 100Mbit (1Gbit connection costs >>> additional money) only under FreeBSD. Linux works fine. >> How are the switches being forced to 100/full? > I don't know, I never work with Juniper e3k switches (And any other > Juniper products at all). > > All I know, that older Juniper Switches in not-so-new DCs of same > provider doesn't have this problem, and, on other hand, Linux and > Windows 2008 don't have problems with new ones too. > >> If they're doing so by disabling autonegotiation, then that's where >> some grief may come from. > Linux work with autonegotiation, as I can see (It is outpuit from > Rescue Linux system on SAME my server, where FreeBSD shows > half-duplex even if forced to full-duplex): > > root@rescue ~ # mii-tool -v eth0 > eth0: 100 Mbit, full duplex, link ok > product info: vendor 00:07:32, model 17 rev 2 > basic mode: 100 Mbit, full duplex > basic status: link ok > capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control > link partner: 100baseTx-HD ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Looks very strange for me... 'HD' means half-duplex? May be linux driver defaults to full-duplex if autoneg fails?.. > root@rescue ~ # ethtool eth0 > Settings for eth0: > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Supports auto-negotiation: Yes > Advertised link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Advertised auto-negotiation: No > Speed: 100Mb/s > Duplex: Full > Port: MII > PHYAD: 0 > Transceiver: internal > Auto-negotiation: off > Supports Wake-on: pumbg > Wake-on: g > Current message level: 0x00000033 (51) > Link detected: yes > root@rescue ~ # > > So, it seems, that autonegotiation is disabled, but it works for > Linux, and manual setting of media and mediaopt doesn't help FreeBSD. > > Also, please note, that when port is in 1Gib mode (which can be buyed > for additional money, which I can not afford) FreeBSD works fine. > -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | JID: artem@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:41: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 E32EC106564A for ; Tue, 11 Jan 2011 19:41:42 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6B30D8FC17 for ; Tue, 11 Jan 2011 19:41:42 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 73D7B13DF5F; Tue, 11 Jan 2011 22:41:41 +0300 (MSK) Date: Tue, 11 Jan 2011 22:41:39 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <510035228.20110111224139@serebryakov.spb.ru> To: Marius Strobl In-Reply-To: <20110111193644.GA38072@alchemy.franken.de> References: <1512738982.20110111124729@serebryakov.spb.ru> <122467803.20110111135330@serebryakov.spb.ru> <20110111193644.GA38072@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:41:43 -0000 Hello, Marius. You wrote 11 =FF=ED=E2=E0=F0=FF 2011 =E3., 22:36:44: >> I've discussed this problem in local (Russian-speaking) FreeBSD >> community, and there are several people in DC 13 who HAVE these >> problems and found different solutions, but all non-technical ones: >> order gigabit connectivity, or pay for moving servers to other (old) >> DCs... > If the latter means that the servers are physically moved as opposed > to a new one being allocated this implies that re(4)/rgephy(4) isn't > the sole factor responsible for this problem. In any case it would be It is known, that DC 13 has new Juniper e3k switches, and older DCs have older Juniper equipment. > helpful to have the corresponding dmesg bits as the Linux counterpart > does some black magic for certain hardware versions when setting the > media manually but re(4) doesn't which might be relevant in this > scenario. Here it is from Rescue FreeBSD system: re0: port 0xe800-0x= e8ff mem 0xfbeff000-0xfbefffff,0xf8ff0000-0xf8ffffff irq 16 at device 0.0 o= n pci6 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX,= 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-= FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 6c:62:6d:a7:bb:37 re0: [FILTER] And, please note very strange output from Linux's mii-tool and ethtool in previous my message to list: mismatch between "basic mode" and "link partner". --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:50: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 3D29B106564A for ; Tue, 11 Jan 2011 19:50:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id E517E8FC08 for ; Tue, 11 Jan 2011 19:50:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 4833841C707; Tue, 11 Jan 2011 20:50:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id R5W6M0vnx-Pb; Tue, 11 Jan 2011 20:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id B191B41C6FC; Tue, 11 Jan 2011 20:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7E8E24448F3; Tue, 11 Jan 2011 19:48:40 +0000 (UTC) Date: Tue, 11 Jan 2011 19:48:40 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Artyom Viklenko In-Reply-To: <4D2CB1F5.6080106@aws-net.org.ua> Message-ID: <20110111194533.J14966@maildrop.int.zabbadoz.net> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:50:07 -0000 On Tue, 11 Jan 2011, Artyom Viklenko wrote: > 11.01.2011 21:29, Lev Serebryakov ?????: >> >> root@rescue ~ # mii-tool -v eth0 >> eth0: 100 Mbit, full duplex, link ok >> product info: vendor 00:07:32, model 17 rev 2 >> basic mode: 100 Mbit, full duplex >> basic status: link ok >> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD >> 10baseT-FD 10baseT-HD >> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD >> flow-control > > >> link partner: 100baseTx-HD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Looks very strange for me... 'HD' means half-duplex? > > May be linux driver defaults to full-duplex if autoneg fails?.. That's probably just because it cannot tell what the peer really uses (autoneg disabled) and prints the sane fall-back but I don't know the code. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:50:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B03F61065673 for ; Tue, 11 Jan 2011 19:50:52 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6548FC1D for ; Tue, 11 Jan 2011 19:50:52 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 662F913DF61; Tue, 11 Jan 2011 22:50:51 +0300 (MSK) Date: Tue, 11 Jan 2011 22:50:49 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <98602823.20110111225049@serebryakov.spb.ru> To: Artyom Viklenko In-Reply-To: <4D2CB1F5.6080106@aws-net.org.ua> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:50:52 -0000 Hello, Artyom. You wrote 11 =FF=ED=E2=E0=F0=FF 2011 =E3., 22:39:33: >> link partner: 100baseTx-HD > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Looks very strange for me... 'HD' means half-duplex? Yep, I've noticed that too... > May be linux driver defaults to full-duplex if autoneg fails?.. Or disabled... And it works -- very strange. And FreeBSD uses half-duplex even with given "media-opt" and network is dramatically slow -- NFS from DC-local server is about 150KiB/s (from FreeBSD installer). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:57:20 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 852061065670 for ; Tue, 11 Jan 2011 19:57:20 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from lazy.aws-net.org.ua (lazy.aws-net.org.ua [IPv6:2a00:1db0:20::828:140]) by mx1.freebsd.org (Postfix) with ESMTP id C25778FC08 for ; Tue, 11 Jan 2011 19:57:19 +0000 (UTC) Received: from [192.168.32.4] (alf.aws-net.org.ua [85.90.196.192]) (authenticated bits=0) by lazy.aws-net.org.ua (8.14.3/8.14.3) with ESMTP id p0BJvGNS083311 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Tue, 11 Jan 2011 21:57:18 +0200 (EET) (envelope-from artem@aws-net.org.ua) Message-ID: <4D2CB61D.2040906@aws-net.org.ua> Date: Tue, 11 Jan 2011 21:57:17 +0200 From: Artyom Viklenko Organization: Art&Co. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> <20110111194533.J14966@maildrop.int.zabbadoz.net> In-Reply-To: <20110111194533.J14966@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (lazy.aws-net.org.ua [188.230.120.140]); Tue, 11 Jan 2011 21:57:18 +0200 (EET) Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:57:20 -0000 11.01.2011 21:48, Bjoern A. Zeeb пишет: > On Tue, 11 Jan 2011, Artyom Viklenko wrote: > >> 11.01.2011 21:29, Lev Serebryakov ?????: >>> >>> root@rescue ~ # mii-tool -v eth0 >>> eth0: 100 Mbit, full duplex, link ok >>> product info: vendor 00:07:32, model 17 rev 2 >>> basic mode: 100 Mbit, full duplex >>> basic status: link ok >>> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD >>> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control >> >> >>> link partner: 100baseTx-HD >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Looks very strange for me... 'HD' means half-duplex? >> >> May be linux driver defaults to full-duplex if autoneg fails?.. > > That's probably just because it cannot tell what the peer really uses > (autoneg disabled) and prints the sane fall-back but I don't know the code. > Is it possible to see status from corresponding port on Juniper switch? Config part for this port on the switch would be also very interesting. -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | JID: artem@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 19:58:15 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 9660C1065672 for ; Tue, 11 Jan 2011 19:58:15 +0000 (UTC) (envelope-from reichert@numachi.com) Received: from meisai.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.freebsd.org (Postfix) with SMTP id 0440D8FC19 for ; Tue, 11 Jan 2011 19:58:14 +0000 (UTC) Received: (qmail 92685 invoked by uid 1001); 11 Jan 2011 19:58:10 -0000 Date: Tue, 11 Jan 2011 14:58:10 -0500 From: Brian Reichert To: Artyom Viklenko Message-ID: <20110111195810.GH7511@numachi.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D2CB1F5.6080106@aws-net.org.ua> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:58:15 -0000 On Tue, Jan 11, 2011 at 09:39:33PM +0200, Artyom Viklenko wrote: > 11.01.2011 21:29, Lev Serebryakov ?????: > Looks very strange for me... 'HD' means half-duplex? > > May be linux driver defaults to full-duplex if autoneg fails?.. I've seen some Linux drivers fail back to half-duplex under these circumstances. It may very well depend on driver version and hardware (firmware)? I admit, I don't know what layer is responsible for handling autonegotiation... > _______________________________________________ > 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" -- Brian Reichert 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 20:00:44 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAAEC1065673 for ; Tue, 11 Jan 2011 20:00:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id A8A338FC08 for ; Tue, 11 Jan 2011 20:00:44 +0000 (UTC) Received: by pvc22 with SMTP id 22so4264467pvc.13 for ; Tue, 11 Jan 2011 12:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=8A6N5AL9LRvUYxfwRr7XNZloK/7tRDmEsSG6eAZECwg=; b=aUGhQiVTCdnDs9rZgU+kTU55jTddApfNnn2iJHXvCAfI9F9shBFqjqOSaSU6qBVvXK Kq8lLydutD/b7aX164J4Zo36yfwXI4rs0VHpBrwPEYe116YQ4Y9kQyfFo5iYeQatr80R dmbXHOTpy5A8b+OFqonU1Q2iYLfXqPNj14sk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=jP3HF5l2icUr0D83mg3r5M7Q2SFbFFJrxjttVxCALFICl4BOMGlD3/11q/W4dz7w8K xNecNA9LwVSjw7fETqlmDYdEoMaVV9ANYWgafAXMrIdC3/FYf9kA7sj1yaqt+yNZzgle fZBZbuReP9dHJ9n+JhZP7EU8fMj74csGaH4CI= Received: by 10.142.81.3 with SMTP id e3mr186614wfb.131.1294776043918; Tue, 11 Jan 2011 12:00:43 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b11sm9627035wff.9.2011.01.11.12.00.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 12:00:41 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jan 2011 12:00:07 -0800 From: Pyun YongHyeon Date: Tue, 11 Jan 2011 12:00:07 -0800 To: Lev Serebryakov Message-ID: <20110111200007.GC6278@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512738982.20110111124729@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) 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 Jan 2011 20:00:45 -0000 On Tue, Jan 11, 2011 at 12:47:29PM +0300, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Very large and famous (due to very attractive prices) hosting > provider Hetzner.de discards FreeBSD support on dedicated servers, > because these servers can niot negotiate 100Mbit/DUPLEX when > switches' ports are limited to 100Mbit (1Gbit connection costs > additional money) only under FreeBSD. Linux works fine. > > Switches known to be Juniper e3k series. > > MoBos of servers are different assortment of MSI MoBos with Realtek > (re driver) network-on-board. > > Symptjms are: NIC can not negotiate/set duplex when switch port is > limited to 100Mbit/Duplex. Duplex can not be set even manually via > "ifconfig": > > > media: Ethernet 100baseTX (100baseTX ) > > Is it know problem? Maybe, -CURRENT driver has fix for it? > > Unfortunately, I can not provide more information, as I don't have > server at Hetzner (I'm planning to order one, but due to these > problems, I'm not sure now, as I need FreeBSD), and all this > information is collected in communication with people who HAVE servers > with FreeBSD installed. > > Again, I know, that Realtek NICs are crap, but "everybody says" that > Linux doesn't have THIS problem with THESE boards and switches. > I can see what's going on here. Link partner used forced media configuration, probably 100baseTX/full-duplex, and re(4)'s resolved link is 100baseTX/half-duplex. rgephy(4) currently always use auto-negotiation to work-around link establishment issues reported in past. I don't know how Linux managed to address link establishment issues for non-autonegotiation case though. Perhaps a lot of vendor supplied DSP fixups addressed that issue but I'm not sure. For your case, the only way to address the issue at this moment is to use auto-negotiation but that would establish 1000baseT link which would add cost for you. Alternatively request half-duplex configuration to the provider to get a agreed link duplex. See http://lists.freebsd.org/pipermail/freebsd-amd64/2011-January/013589.html for details on parallel detection. From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 20:05:08 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 C444E10656A6 for ; Tue, 11 Jan 2011 20:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 62A6D8FC24 for ; Tue, 11 Jan 2011 20:05:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BC6A341C7A5; Tue, 11 Jan 2011 21:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 4D1wDqy-vPNj; Tue, 11 Jan 2011 21:05:06 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id E099E41C7AC; Tue, 11 Jan 2011 21:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D40764448F3; Tue, 11 Jan 2011 20:03:10 +0000 (UTC) Date: Tue, 11 Jan 2011 20:03:10 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Artyom Viklenko In-Reply-To: <4D2CB61D.2040906@aws-net.org.ua> Message-ID: <20110111200202.A14966@maildrop.int.zabbadoz.net> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> <20110111194533.J14966@maildrop.int.zabbadoz.net> <4D2CB61D.2040906@aws-net.org.ua> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 20:05:08 -0000 On Tue, 11 Jan 2011, Artyom Viklenko wrote: > 11.01.2011 21:48, Bjoern A. Zeeb : >> On Tue, 11 Jan 2011, Artyom Viklenko wrote: >> >>> 11.01.2011 21:29, Lev Serebryakov ?????: >>>> >>>> root@rescue ~ # mii-tool -v eth0 >>>> eth0: 100 Mbit, full duplex, link ok >>>> product info: vendor 00:07:32, model 17 rev 2 >>>> basic mode: 100 Mbit, full duplex >>>> basic status: link ok >>>> capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD >>>> 10baseT-FD 10baseT-HD >>>> advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control >>> >>> >>>> link partner: 100baseTx-HD >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> Looks very strange for me... 'HD' means half-duplex? >>> >>> May be linux driver defaults to full-duplex if autoneg fails?.. >> >> That's probably just because it cannot tell what the peer really uses >> (autoneg disabled) and prints the sane fall-back but I don't know the code. >> > > Is it possible to see status from corresponding port on Juniper switch? > Config part for this port on the switch would be also very interesting. No but I think we are not getting anywhere; I contacted them this afternoon and will see if they'll get back to me. /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 20:16: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 67A261065698 for ; Tue, 11 Jan 2011 20:16: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 CC7BA8FC1A for ; Tue, 11 Jan 2011 20:16: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 p0BJai3U038162; Tue, 11 Jan 2011 20:36:44 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p0BJai0p038161; Tue, 11 Jan 2011 20:36:44 +0100 (CET) (envelope-from marius) Date: Tue, 11 Jan 2011 20:36:44 +0100 From: Marius Strobl To: Lev Serebryakov Message-ID: <20110111193644.GA38072@alchemy.franken.de> References: <1512738982.20110111124729@serebryakov.spb.ru> <122467803.20110111135330@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <122467803.20110111135330@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 20:16:24 -0000 On Tue, Jan 11, 2011 at 01:53:30PM +0300, Lev Serebryakov wrote: > Hello, Yamagi. > You wrote 11 ?????? 2011 ?., 13:30:23: > > > Hi, > > I've got several Hetzner EQ4 and on all these machines FreeBSD 8.1 runs > > just fine. I've never seen this strange negotiation problem myself. But > > maybe I was just lucky and got working mainboard and nic combinations. > > So if further information is needed, I'm happy to provide it. > It is known, that problems are in DC 13 and everything wotrks fine > in DC 11 and DC 12. > > I've discussed this problem in local (Russian-speaking) FreeBSD > community, and there are several people in DC 13 who HAVE these > problems and found different solutions, but all non-technical ones: > order gigabit connectivity, or pay for moving servers to other (old) > DCs... > If the latter means that the servers are physically moved as opposed to a new one being allocated this implies that re(4)/rgephy(4) isn't the sole factor responsible for this problem. In any case it would be helpful to have the corresponding dmesg bits as the Linux counterpart does some black magic for certain hardware versions when setting the media manually but re(4) doesn't which might be relevant in this scenario. Marius From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 21:27: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 0BCB8106564A for ; Tue, 11 Jan 2011 21:27:48 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id B908E8FC12 for ; Tue, 11 Jan 2011 21:27:47 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 59C9113DF5F; Wed, 12 Jan 2011 00:27:46 +0300 (MSK) Date: Wed, 12 Jan 2011 00:27:44 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <834383247.20110112002744@serebryakov.spb.ru> To: Artyom Viklenko In-Reply-To: <4D2CB61D.2040906@aws-net.org.ua> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> <20110111194533.J14966@maildrop.int.zabbadoz.net> <4D2CB61D.2040906@aws-net.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:27:48 -0000 Hello, Artyom. You wrote 11 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2011 =D0=B3., 22:57:17: > Is it possible to see status from corresponding port on Juniper switch? > Config part for this port on the switch would be also very interesting. I (as customer with server which has problem) could ask techsupport tomorrow. But, maybe, they didn't answer, because I already have answer that FreeBSD is not supported :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 21:31: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 44B80106564A for ; Tue, 11 Jan 2011 21:31:13 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id DF2FB8FC16 for ; Tue, 11 Jan 2011 21:31:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id EEEA813DF5F; Wed, 12 Jan 2011 00:31:11 +0300 (MSK) Date: Wed, 12 Jan 2011 00:31:10 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <149076940.20110112003110@serebryakov.spb.ru> To: Pyun YongHyeon In-Reply-To: <20110111200007.GC6278@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:31:13 -0000 Hello, Pyun. You wrote 11 =FF=ED=E2=E0=F0=FF 2011 =E3., 23:00:07: > rgephy(4) currently always use auto-negotiation to work-around link > establishment issues reported in past. I think, it is the root of the problem. Autonegotiation is DISABLED on these ports. I think, some additional mediaopt (like force-half-duplex) for rgephy(4) will be solution. > For your case, the only way to address the issue at this moment is > to use auto-negotiation but that would establish 1000baseT link > which would add cost for you. Alternatively request half-duplex > configuration to the provider to get a agreed link duplex. Maybe, adding new mediaopt is not very hard? Or is it? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 22:37: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 B17421065679 for ; Tue, 11 Jan 2011 22:37:23 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1FD198FC0C for ; Tue, 11 Jan 2011 22:37:22 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p0BM3L9r026035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jan 2011 23:03:21 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p0BM3F8K031746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 23:03:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p0BM3F3D048003; Tue, 11 Jan 2011 23:03:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p0BM3EVf048002; Tue, 11 Jan 2011 23:03:14 +0100 (CET) (envelope-from ticso) Date: Tue, 11 Jan 2011 23:03:14 +0100 From: Bernd Walter To: Lev Serebryakov Message-ID: <20110111220314.GZ39356@cicely7.cicely.de> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> <98602823.20110111225049@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98602823.20110111225049@serebryakov.spb.ru> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-net@freebsd.org, Artyom Viklenko Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 22:37:23 -0000 On Tue, Jan 11, 2011 at 10:50:49PM +0300, Lev Serebryakov wrote: > Hello, Artyom. > You wrote 11 ?????? 2011 ?., 22:39:33: > > >> link partner: 100baseTx-HD > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Looks very strange for me... 'HD' means half-duplex? > Yep, I've noticed that too... > > > May be linux driver defaults to full-duplex if autoneg fails?.. > Or disabled... And it works -- very strange. And FreeBSD uses > half-duplex even with given "media-opt" and network is dramatically > slow -- NFS from DC-local server is about 150KiB/s (from FreeBSD > installer). > I'm not surprised that it doesn't work with autonegotian if autonegotian is disabled. If Linux does full-duplex without autonegotiation then _they_ do it wrong and Hetzner shouldn't rely on wrong behavour. However since you seem to have access it might be interesting to know the exact network device and debug why hard setting is broken. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 22:37: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 8BD3F10656A4 for ; Tue, 11 Jan 2011 22:37:39 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 151908FC15 for ; Tue, 11 Jan 2011 22:37:38 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p0BM0IX6025996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Jan 2011 23:00:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p0BM0FUg031730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 23:00:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p0BM0EQg047994; Tue, 11 Jan 2011 23:00:14 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p0BM0E9g047993; Tue, 11 Jan 2011 23:00:14 +0100 (CET) (envelope-from ticso) Date: Tue, 11 Jan 2011 23:00:14 +0100 From: Bernd Walter To: Lev Serebryakov Message-ID: <20110111220014.GY39356@cicely7.cicely.de> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <773123481.20110111223731@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <773123481.20110111223731@serebryakov.spb.ru> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 22:37:39 -0000 On Tue, Jan 11, 2011 at 10:37:31PM +0300, Lev Serebryakov wrote: > Hello, Brian. > You wrote 11 ?????? 2011 ?., 22:29:13: > > > basic mode: 100 Mbit, full duplex > > link partner: 100baseTx-HD > It looks VERY strange. How could id be? This is normal if the link partner doesn't do autonegotiation. The system has to assume a simple repeater hub and do half duplex. If on the other hand the switch is hard set to full-duplex then they can't expect autonegotiation to do it right. However hard setting under FreeBSD as well should work. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 22:46:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787DE1065670 for ; Tue, 11 Jan 2011 22:46:04 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28EE58FC0C for ; Tue, 11 Jan 2011 22:46:03 +0000 (UTC) Received: by yie19 with SMTP id 19so6356676yie.13 for ; Tue, 11 Jan 2011 14:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ZPQrTMEM55YpGnGgRbxNbe3nb0MPds1oN+soA824H+w=; b=KnCTfvwXR/eLZICqc9vKk5Hu7FZGiEZ0EgO6ObC+B+nooGGvDIBlTZlWYErQOpZv9H V+p6cJMUgT4PJ701q508Jz8ADyhQV7QFDU9caBqpk+n/ug25EdywSg7iKDqMA96hcXep WFy9dfb4BqOI2VkzTWv/G9EKpMaxpmdE6oZyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=USkzG+ZjR6VM5EPGalhTvtydBihMabfZvr0IKR4i3kmajCALNCWh1q4D+GbgsZ+W9z 8QgC5WlCc4m/X9FDaIyQoOkf8lIH4TxjQsG4lhlYRU8UYODd54g7SDmXmPjzp7hfHmny 5AVYYfSnCMTis/8GcR9XY6Hk+IwQ96wRCum2g= Received: by 10.91.196.17 with SMTP id y17mr764727agp.207.1294785963280; Tue, 11 Jan 2011 14:46:03 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w4sm31777960anw.16.2011.01.11.14.46.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 14:46:02 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jan 2011 14:45:26 -0800 From: Pyun YongHyeon Date: Tue, 11 Jan 2011 14:45:26 -0800 To: Lev Serebryakov Message-ID: <20110111224526.GD6278@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> <149076940.20110112003110@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <149076940.20110112003110@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) 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 Jan 2011 22:46:04 -0000 On Wed, Jan 12, 2011 at 12:31:10AM +0300, Lev Serebryakov wrote: > Hello, Pyun. > You wrote 11 ÑÐ½Ð²Ð°Ñ€Ñ 2011 г., 23:00:07: > > > rgephy(4) currently always use auto-negotiation to work-around link > > establishment issues reported in past. > I think, it is the root of the problem. Autonegotiation is DISABLED on > these ports. I think, some additional mediaopt (like > force-half-duplex) for rgephy(4) will be solution. > > > For your case, the only way to address the issue at this moment is > > to use auto-negotiation but that would establish 1000baseT link > > which would add cost for you. Alternatively request half-duplex > > configuration to the provider to get a agreed link duplex. > Maybe, adding new mediaopt is not very hard? Or is it? > That had been supported for long time. Just remove full-duplex media option in your manual configuration. From owner-freebsd-net@FreeBSD.ORG Tue Jan 11 23:31:24 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 CF4DB1065670 for ; Tue, 11 Jan 2011 23:31:24 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5AE8FC17 for ; Tue, 11 Jan 2011 23:31:24 +0000 (UTC) Received: (from brett@localhost) by lariat.net (8.9.3/8.9.3) id QAA29979; Tue, 11 Jan 2011 16:06:14 -0700 (MST) Date: Tue, 11 Jan 2011 16:06:14 -0700 (MST) From: Brett Glass Message-Id: <201101112306.QAA29979@lariat.net> To: net@freebsd.org Cc: Subject: IPFW firewall NAT and active FTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 23:31:24 -0000 I'm working with a customer who has a FreeBSD 8.0 firewall, set up with firewall NAT in IPFW. It uses one-to-one static NAT to redirect FTP sessions originating on the outside to an FTP server on the inside. The FTP server is accessible via text-based FTP clients, but not via Web-based clients such as Mozilla Firefox or Internet Explorer. The internal FTP server is also a FreeBSD machine. He's wondering if the problem has to do with the lack of a "firewall punching" setting (which exists in natd but not in IPFW's built-in NAT). Can anyone suggest what might be causing the problem? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 03:24: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 AEF60106566B; Wed, 12 Jan 2011 03:24:47 +0000 (UTC) (envelope-from prvs=19938927b1=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id EC14E8FC13; Wed, 12 Jan 2011 03:24:46 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 12 Jan 2011 03:13:40 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 12 Jan 2011 03:13:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50011959913.msg; Wed, 12 Jan 2011 03:13:40 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=19938927b1=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <97E367EFBB774F9BA06B0D6DFF14039D@multiplay.co.uk> From: "Steven Hartland" To: "Vogel, Jack" , "TAKAHASHI Yoshihiro" , References: <20110108.124018.59640143160055980.nyan@FreeBSD.org> <1DB50624F8348F48840F2E2CF6040A9D014BC5519A@orsmsx508.amr.corp.intel.com> Date: Wed, 12 Jan 2011 03:13:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Supermicro Bladeserver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 03:24:48 -0000 Out of interest what change was that? ----- Original Message ----- From: "Vogel, Jack" To: "TAKAHASHI Yoshihiro" ; Cc: ; Sent: Monday, January 10, 2011 9:17 PM Subject: RE: Supermicro Bladeserver We attempted to repro this problem with the 82566DM (ich8 btw) in house and failed, it worked correctly for my testers. Oh, and just so the mailing lists have an update, the SM Blade problem was not an issue in the driver, it was a local change in the loader.conf that caused the problem. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 05:37: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 8FFA9106564A for ; Wed, 12 Jan 2011 05:37:13 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id 769628FC27 for ; Wed, 12 Jan 2011 05:37:13 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p0C5bCvc020421; Tue, 11 Jan 2011 21:37:12 -0800 (PST) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id B0DDF4193862; Tue, 11 Jan 2011 21:37:11 -0800 (PST) Date: Tue, 11 Jan 2011 21:37:11 -0800 From: Robin Sommer To: Steven Hartland Message-ID: <20110112053711.GC34444@icir.org> References: <20110108.124018.59640143160055980.nyan@FreeBSD.org> <1DB50624F8348F48840F2E2CF6040A9D014BC5519A@orsmsx508.amr.corp.intel.com> <97E367EFBB774F9BA06B0D6DFF14039D@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97E367EFBB774F9BA06B0D6DFF14039D@multiplay.co.uk> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-net@freebsd.org, jfvogel@gmail.com, freebsd-stable@freebsd.org, "Vogel, Jack" , TAKAHASHI Yoshihiro Subject: Re: Supermicro Bladeserver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 05:37:13 -0000 On Wed, Jan 12, 2011 at 03:13 -0000, you wrote: > Out of interest what change was that? As what seems to have been a left-over from a debugging session a long time ago, I had MSI disabled in loader.conf. That's not supported by the driver. So simply reenabling that solved my problem. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 06:15:02 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 6326D106566C for ; Wed, 12 Jan 2011 06:15:02 +0000 (UTC) (envelope-from artem@aws-net.org.ua) Received: from lazy.aws-net.org.ua (lazy.aws-net.org.ua [IPv6:2a00:1db0:20::828:140]) by mx1.freebsd.org (Postfix) with ESMTP id BF3428FC16 for ; Wed, 12 Jan 2011 06:15:01 +0000 (UTC) Received: from rainbow.vl.net.ua (rainbow.vl.net.ua [188.230.120.215]) (authenticated bits=0) by lazy.aws-net.org.ua (8.14.3/8.14.3) with ESMTP id p0C6Es74085301 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 12 Jan 2011 08:14:59 +0200 (EET) (envelope-from artem@aws-net.org.ua) Message-ID: <4D2D46DE.70101@aws-net.org.ua> Date: Wed, 12 Jan 2011 08:14:54 +0200 From: Artyom Viklenko Organization: Art&Co. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.11) Gecko/20101025 Thunderbird/3.1.5 MIME-Version: 1.0 To: Brett Glass References: <201101112306.QAA29979@lariat.net> In-Reply-To: <201101112306.QAA29979@lariat.net> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (lazy.aws-net.org.ua [188.230.120.140]); Wed, 12 Jan 2011 08:14:59 +0200 (EET) Cc: net@freebsd.org Subject: Re: IPFW firewall NAT and active FTP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 06:15:02 -0000 12.01.2011 01:06, Brett Glass ÐÉÛÅÔ: > I'm working with a customer who has a FreeBSD 8.0 firewall, set up with firewall > NAT in IPFW. It uses one-to-one static NAT to redirect FTP sessions > originating on the outside to an FTP server on the inside. The FTP server is > accessible via text-based FTP clients, but not via Web-based clients such as > Mozilla Firefox or Internet Explorer. The internal FTP server is also a FreeBSD > machine. > Does FTP server enforces any limits for sessions per ip? In past I saw that IE can open up to four concurrent sessions. If plain text ftp clients works, IMHO it's not a NAT problem. Also check config of ipfw is it supports both active and passive FTP transfers. > He's wondering if the problem has to do with the lack of a "firewall punching" > setting (which exists in natd but not in IPFW's built-in NAT). Can anyone > suggest what might be causing the problem? > > --Brett Glass > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | JID: artem@jabber.aws-net.org.ua FreeBSD: The Power to Serve - http://www.freebsd.org From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 07:44:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D4F2106566B for ; Wed, 12 Jan 2011 07:44:52 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B16048FC13 for ; Wed, 12 Jan 2011 07:44:51 +0000 (UTC) Received: (qmail 84489 invoked from network); 12 Jan 2011 07:18:08 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Jan 2011 07:18:08 -0000 Date: Wed, 12 Jan 2011 08:18:08 +0100 (CET) Message-Id: <20110112.081808.74670677.sthaug@nethelp.no> To: reichert@numachi.com From: sthaug@nethelp.no In-Reply-To: <20110111195810.GH7511@numachi.com> References: <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> <20110111195810.GH7511@numachi.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, artem@aws-net.org.ua Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 07:44:52 -0000 > > May be linux driver defaults to full-duplex if autoneg fails?.. > > I've seen some Linux drivers fail back to half-duplex under these > circumstances. > > It may very well depend on driver version and hardware (firmware)? > > I admit, I don't know what layer is responsible for handling > autonegotiation... It should be noted that fallback to half-duplex when autoneg fail is actually *required* by the IEEE Ethernet standards. We may not like it, but there it is... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 08:52: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 4F5EE106564A for ; Wed, 12 Jan 2011 08:52:13 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 086B88FC1B for ; Wed, 12 Jan 2011 08:52:12 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3D13613DF5F; Wed, 12 Jan 2011 11:52:11 +0300 (MSK) Date: Wed, 12 Jan 2011 11:52:08 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <165642603.20110112115208@serebryakov.spb.ru> To: Bernd Walter In-Reply-To: <20110111220314.GZ39356@cicely7.cicely.de> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111163825.GF7511@numachi.com> <76226157.20110111222913@serebryakov.spb.ru> <4D2CB1F5.6080106@aws-net.org.ua> <98602823.20110111225049@serebryakov.spb.ru> <20110111220314.GZ39356@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Artyom Viklenko , ticso@cicely.de Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 08:52:13 -0000 Hello, Bernd. You wrote 12 =FF=ED=E2=E0=F0=FF 2011 =E3., 1:03:14: > I'm not surprised that it doesn't work with autonegotian if autonegotian > is disabled. > If Linux does full-duplex without autonegotiation then _they_ do it wrong > and Hetzner shouldn't rely on wrong behavour. As far as I understand, Linux does full-duplex without autonegotiation because it is say to do full-duplex (like FreeBSD's "ifconfig re0 media 100baseTX mediaopt full-duplex"). Is it violation of standard too -- manual configuration of FD? > However since you seem to have access it might be interesting to know the > exact network device and debug why hard setting is broken. As far as I understand, again, it is not broken, but disabled, because cause problems on some devices... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 09:03:06 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 D14FC106564A for ; Wed, 12 Jan 2011 09:03:06 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5108FC19 for ; Wed, 12 Jan 2011 09:03:06 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 9AFF613DF61; Wed, 12 Jan 2011 12:03:05 +0300 (MSK) Date: Wed, 12 Jan 2011 12:03:03 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <751614742.20110112120303@serebryakov.spb.ru> To: Pyun YongHyeon In-Reply-To: <20110111224526.GD6278@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> <149076940.20110112003110@serebryakov.spb.ru> <20110111224526.GD6278@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:03:06 -0000 Hello, Pyun. You wrote 12 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2011 =D0=B3., 1:45:26: > That had been supported for long time. Just remove full-duplex > media option in your manual configuration. What do you mean by this? Without this media options it will be 100Mbit half-duplex when switch port want 100Mbit full-duplex. With this media option result is the same because refphy(4) ignores user requests, if I understand right. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 09:14: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 8BF831065696 for ; Wed, 12 Jan 2011 09:14:16 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id BEA078FC1C for ; Wed, 12 Jan 2011 09:14:15 +0000 (UTC) Received: (qmail 1197 invoked from network); 12 Jan 2011 09:14:14 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 12 Jan 2011 09:14:14 -0000 Date: Wed, 12 Jan 2011 10:14:14 +0100 (CET) Message-Id: <20110112.101414.41710948.sthaug@nethelp.no> To: lev@serebryakov.spb.ru From: sthaug@nethelp.no In-Reply-To: <165642603.20110112115208@serebryakov.spb.ru> References: <98602823.20110111225049@serebryakov.spb.ru> <20110111220314.GZ39356@cicely7.cicely.de> <165642603.20110112115208@serebryakov.spb.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, ticso@cicely7.cicely.de, artem@aws-net.org.ua, ticso@cicely.de Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:14:16 -0000 > > I'm not surprised that it doesn't work with autonegotian if autonegotian > > is disabled. > > If Linux does full-duplex without autonegotiation then _they_ do it wrong > > and Hetzner shouldn't rely on wrong behavour. > As far as I understand, Linux does full-duplex without > autonegotiation because it is say to do full-duplex (like FreeBSD's > "ifconfig re0 media 100baseTX mediaopt full-duplex"). Is it violation > of standard too -- manual configuration of FD? Manual configuration of FD for 100 Mbps is not in violation of the standards. What the standards say (for 100 Mbps) is that *if* you have one end configured for autonegotiation *and* the other end is manually configured for full duplex, the autoneg end should end up as half duplex (with the inevitable errors as a result). This may be counterintuitive, but it's the way the standard is written. For Gigabit Ethernet autonegotiation is *required* by the standard, as other people already have pointed out. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 09:18:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADA71106566B for ; Wed, 12 Jan 2011 09:18:04 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 683CF8FC15 for ; Wed, 12 Jan 2011 09:18:03 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id DED0F13DF62; Wed, 12 Jan 2011 12:18:02 +0300 (MSK) Date: Wed, 12 Jan 2011 12:18:00 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <7010235325.20110112121800@serebryakov.spb.ru> To: sthaug@nethelp.no In-Reply-To: <20110112.101414.41710948.sthaug@nethelp.no> References: <98602823.20110111225049@serebryakov.spb.ru> <20110111220314.GZ39356@cicely7.cicely.de> <165642603.20110112115208@serebryakov.spb.ru> <20110112.101414.41710948.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, ticso@cicely7.cicely.de, artem@aws-net.org.ua, ticso@cicely.de Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:18:04 -0000 Hello, Sthaug. You wrote 12 =FF=ED=E2=E0=F0=FF 2011 =E3., 12:14:14: > Manual configuration of FD for 100 Mbps is not in violation of the > standards. What the standards say (for 100 Mbps) is that *if* you have > one end configured for autonegotiation *and* the other end is manually > configured for full duplex, the autoneg end should end up as half duplex > (with the inevitable errors as a result). This may be counterintuitive, > but it's the way the standard is written. Ok, and according to output of Linux's tools, autonegotiation is disabled on port, and full-duplex is set manually. And FreeBSD ignmore manual settings for re(4)/regphy(4) adapters. Here is a problem :( > For Gigabit Ethernet autonegotiation is *required* by the standard, as > other people already have pointed out. Yes, and it works, but cost additional money, which is comparable to price of server itself :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 10:40:08 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 F3818106566B for ; Wed, 12 Jan 2011 10:40:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id A649F8FC12 for ; Wed, 12 Jan 2011 10:40:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A1D7841C7C7; Wed, 12 Jan 2011 11:40:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id xTXeFwyKx2Uu; Wed, 12 Jan 2011 11:40:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 823A541C7C3; Wed, 12 Jan 2011 11:40:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id D1A944448F3; Wed, 12 Jan 2011 10:36:09 +0000 (UTC) Date: Wed, 12 Jan 2011 10:36:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Pyun YongHyeon In-Reply-To: <20110111200007.GC6278@michelle.cdnetworks.com> Message-ID: <20110112102248.F14966@maildrop.int.zabbadoz.net> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:40:08 -0000 On Tue, 11 Jan 2011, Pyun YongHyeon wrote: > On Tue, Jan 11, 2011 at 12:47:29PM +0300, Lev Serebryakov wrote: >> >> media: Ethernet 100baseTX (100baseTX ) > > I can see what's going on here. Link partner used forced media > configuration, probably 100baseTX/full-duplex, and re(4)'s > resolved link is 100baseTX/half-duplex. I can confirm that the switch port should be (manually) set to 100/FD. It's documented on their support wiki (in German). > rgephy(4) currently always use auto-negotiation to work-around link > establishment issues reported in past. I don't know how Linux > managed to address link establishment issues for > non-autonegotiation case though. Perhaps a lot of vendor supplied As I read your reply, there had been a time when manually setting 100/FD was possible but it didn't quite work? > DSP fixups addressed that issue but I'm not sure. > For your case, the only way to address the issue at this moment is > to use auto-negotiation but that would establish 1000baseT link > which would add cost for you. Alternatively request half-duplex > configuration to the provider to get a agreed link duplex. We should still try to fix it somehow. Also it would be nice if re(4), or rephy(4) if we had that, would document the issue properly in BUGS. > See > http://lists.freebsd.org/pipermail/freebsd-amd64/2011-January/013589.html > for details on parallel detection. As someone from Hetzner has pointed out to me the original discussion seemd to have been here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059894.html While I can understand the problem, has anyone contacted RealTek for documentation to solve that matter, so that we could equally fix the things as other major OSes have done by now (either themselves or by a vendor update)? /bz -- Bjoern A. Zeeb You have to have visions! Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 13:59: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 905F9106564A for ; Wed, 12 Jan 2011 13:59:42 +0000 (UTC) (envelope-from monthadar@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 4A1178FC0C for ; Wed, 12 Jan 2011 13:59:41 +0000 (UTC) Received: by qyk36 with SMTP id 36so593576qyk.13 for ; Wed, 12 Jan 2011 05:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=/ZS3A0z6joSNrKDn9l+Jr9sYhKo6iKbFNGndXGYrRfo=; b=sHgGAVfTQKi0a5gnIYvuTVbdz6dSeh2WXWlj0K875IXpIq/ATg/BkiwBHU3a/i6/B9 da3kbBugIGy0CHpWMi0HAb6oeuhMnraxKSViutK4fIigqXI3YoihROuQBCq5bgeApvYZ 4mPOqu2N+ZbwA+xe7LKnXINhgG7HXF/ukHauQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HtPhCVH3eKkxoyyta8V5oByESfXywrrMPZKWrDL7XLy2rHdd9roTyUkj9CuUXT5Mzu h06Tn47HzNmdqlhjFrJCQmPUghGApMYx0y6zaje78+RvW3xjz98+EbJYbn6TR0H454lN YuQfGbYbO6eWjaz9rpe1HR4xbltArGmfEs45c= MIME-Version: 1.0 Received: by 10.229.240.85 with SMTP id kz21mr907229qcb.2.1294840781322; Wed, 12 Jan 2011 05:59:41 -0800 (PST) Received: by 10.229.249.14 with HTTP; Wed, 12 Jan 2011 05:59:41 -0800 (PST) Date: Wed, 12 Jan 2011 14:59:41 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: How hard is it to write a dummy wireless driver? (wtap??) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 13:59:42 -0000 Hi, I am thinking about writing a wireless driver that simulates a wifi device (a very simple one). I am interested in only testing 11s mesh. After reading man page for NET80211 http://www.unix.com/man-page/freebsd/9/NET80211/ I see that there are only 5 functions in struct ieee80211com that must be implemented by me, ic_vap_create* ic_vap_delete* ic_scan_start* ic_scan_end* ic_set_channel* and I imagine these would be also usefull too ic_newassoc ic_raw_xmit So, how hard is it? Any advice, guidelines is much appreciated. I have hacked a driver and this is the output I get (I seem to be able to send out data, but not receive it): A modified output from running FreeBSD Current one VBox with two of "myath" devices wlan0: Ethernet address: 00:98:9a:98:9a:98 wlan1: Ethernet address: 00:98:9a:98:9a:99 wlan0: ieee80211_init wlan0: start running, 0 vaps running wlan0: ieee80211_new_state_locked: INIT -> SCAN (nrunning 0 nscanning 0) wlan0: ieee80211_newstate_cb: INIT -> INIT arg 0 wlan0: mesh_newstate: INIT -> INIT (0) wlan0: hwmp_newstate: INIT -> INIT (0) wlan0: ieee80211_newstate_cb: INIT -> SCAN arg 0 wlan0: mesh_newstate: INIT -> SCAN (0) wlan0: ieee80211_check_scan: active scan, append wlan0: scan_update_locked: current scanner is , switch to wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, flush wlan0: scan set 1g dwell min 200ms max 200ms wlan0: hwmp_newstate: INIT -> SCAN (0) wlan0: scan_task: chan 1g -> 1g [active, dwell min 200ms max 200ms] wlan0: ieee80211_ref_node (ieee80211_send_probereq:1731) 0xc411b000<00:98:9a:98:9a:98> refcnt 3 wlan0: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: ieee80211_start: ignore queue, in SCAN state wlan1: ieee80211_init wlan1: start running, 0 vaps running wlan1: ieee80211_new_state_locked: INIT -> SCAN (nrunning 0 nscanning 0) wlan1: ieee80211_newstate_cb: INIT -> INIT arg 0 wlan1: mesh_newstate: INIT -> INIT (0) wlan1: hwmp_newstate: INIT -> INIT (0) wlan1: ieee80211_newstate_cb: INIT -> SCAN arg 0 wlan1: mesh_newstate: INIT -> SCAN (0) wlan1: ieee80211_check_scan: active scan, append wlan1: scan_update_locked: current scanner is , switch to wlan1: start_scan_locked: active scan, duration 2147483647 mindwell 0 maxdwell 0, desired mode auto, flush wlan1: scan set 1g dwell min 200ms max 200ms wlan1: hwmp_newstate: INIT -> SCAN (0) wlan1: scan_task: chan 1g -> 1g [active, dwell min 200ms max 200ms] wlan1: ieee80211_ref_node (ieee80211_send_probereq:1731) 0xc4121000<00:98:9a:98:9a:99> refcnt 3 wlan1: send probe req on channel 1 bssid ff:ff:ff:ff:ff:ff ssid "" wlan0: received probe_req from 00:98:9a:98:9a:99 rssi 128 wlan0: [00:98:9a:98:9a:99] discard probe_req frame, wrong state SCAN wlan1: ieee80211_start: ignore queue, in SCAN state wlan0: mesh_pick_bss: no scan candidate wlan0: ieee80211_create_ibss: creating MBSS on channel 1 wlan0: ieee80211_alloc_node 0xc4125000<00:98:9a:98:9a:98> in station table wlan0: ieee80211_new_state_locked: SCAN -> RUN (nrunning 0 nscanning 0) wlan0: scan_task: done, [ticks 2427, dwell min 20 scanend 2147486054] wlan0: notify scan done wlan0: ieee80211_newstate_cb: SCAN -> RUN arg -1 wlan0: mesh_newstate: SCAN -> RUN (-1) wlan0: synchronized with 6d:79:6d:65:73:68 meshid "mymesh" channel 1 wlan0: hwmp_newstate: SCAN -> RUN (-1) wlan1: mesh_pick_bss: no scan candidate wlan1: ieee80211_create_ibss: creating MBSS on channel 1 wlan1: ieee80211_alloc_node 0xc412b000<00:98:9a:98:9a:99> in station table wlan1: ieee80211_new_state_locked: SCAN -> RUN (nrunning 0 nscanning 0) wlan1: scan_task: done, [ticks 2432, dwell min 20 scanend 2147486059] wlan1: notify scan done wlan1: ieee80211_newstate_cb: SCAN -> RUN arg -1 wlan1: mesh_newstate: SCAN -> RUN (-1) wlan1: synchronized with 6d:79:6d:65:73:68 meshid "mymesh" channel 1 wlan1: hwmp_newstate: SCAN -> RUN (-1) wlan0: [00:98:9a:98:9a:98] station timed out due to inactivity (refcnt 1) wlan0: [00:98:9a:98:9a:98] station with aid 0 leaves wlan0: node_reclaim: remove 0xc411b000<00:98:9a:98:9a:98> from station table, refcnt 1 wlan1: [00:98:9a:98:9a:99] station timed out due to inactivity (refcnt 1) wlan1: [00:98:9a:98:9a:99] station with aid 0 leaves wlan1: node_reclaim: remove 0xc4121000<00:98:9a:98:9a:99> from station table, refcnt 1 When I try to ping the other wlan IFQ_DEQUEUE(&ifp->if_snd, m) inside myath_start (stripped down version of ath_start) always returns null... I can share my code if you think it helps. thnx -- //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 16:20: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 C4BCE106566B for ; Wed, 12 Jan 2011 16:20:13 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6149B8FC0A for ; Wed, 12 Jan 2011 16:20:13 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id C2C3D13DF5F for ; Wed, 12 Jan 2011 19:20:11 +0300 (MSK) Date: Wed, 12 Jan 2011 19:20:09 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <36074996.20110112192009@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------7D1CC93EC99850" Subject: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 16:20:13 -0000 ------------7D1CC93EC99850 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hello, Freebsd-net. Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used with re(4) does autonegotiation always and all other, who helps me diagnose problem! I've prepared patch, which adds tunable/sysctl for rgephy(4) which allows not to sue autonegotiation by this PHY (at user responsibility, as here is PHYs which CAN NOT live without autonegotiation). It is OFF by default, and in such case behavior of driver IS NOT CHANGED. But if it is set ON (non-zero value) before "media / mediopt" changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit settings. I've documented this new tunable in re(4) manpage, as here is no rgephy(4) manpage. Tunable is per-device, not global one. Sysctl can be set after boot, but will affect only future ifconfig calls, it doesn't change anything in PHY settings by itself. It allows fully manual setup on non-buggy hardware, which allows to use Hetzner dedicated servers with FreeBSD without additional NIC or gigabit connection. I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it allows me to get full-duplex 100Mbit connection and I got 11MiB/s from local NFS with it. Without this patch FreeBSD is unusable on Hetzner dedicated servers in newer DCs (DC 13 and DC 14). Patch is attached. I think, it worths to include it to base system, as it allows use FreeBSD at least on one very large and popular hosting provider without additional costs :) --=20 // Black Lion AKA Lev Serebryakov ------------7D1CC93EC99850 Content-Type: application/octet-stream; name="rgephy.patch" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="rgephy.patch" ZGlmZiAtcnVOIC9tbnQvc3JjL3NoYXJlL21hbi9tYW40L3JlLjQgc2hhcmUvbWFuL21hbjQv cmUuNAotLS0gL21udC9zcmMvc2hhcmUvbWFuL21hbjQvcmUuNAkyMDExLTAxLTEyIDE2OjE0 OjI4LjAwMDAwMDAwMCArMDMwMAorKysgc2hhcmUvbWFuL21hbjQvcmUuNAkyMDExLTAxLTEy IDE5OjAwOjExLjAwMDAwMDAwMCArMDMwMApAQCAtMTc4LDYgKzE3OCwyNiBAQAogLkl0IFZh IGh3LnJlLm1zaV9kaXNhYmxlCiBUaGlzIHR1bmFibGUgZGlzYWJsZXMgTVNJIHN1cHBvcnQg b24gdGhlIEV0aGVybmV0IGhhcmR3YXJlLgogVGhlIGRlZmF1bHQgdmFsdWUgaXMgMC4KKy5J dCBWYSBkZXYucmdlcGh5LiVkLmF1dG9uZWdfY2FuX2JlX2Rpc2FibGVkCitCeSBkZWZhdWx0 LCByZ2VwaHksIFBIWSB1c2VkIHdpdGggc3VwcG9ydGVkIFJlYWx0ZWsgY29udHJvbGxlcnMs IGFsd2F5cwordXNlcyBhdXRvbmVnb3RpYXRpb24sIGV2ZW4gaWYKKy5DbSBtZWRpYQorb3IK Ky5DbSBtZGVpYW9wdAorYXJlIHNwZWNpZmllZCBieSB1c2VyLiBJdCBpcyBkb25lIHRvIGF2 b2lkIGJ1ZyBpbiBzb21lIFBIWQoraW1wbGVtZW50YXRpb25zLiBTb21ldGltZXMgeW91IG5l ZWQgdG8gZGlzYWJsZSBhdXRvbmVnb3RpYXRpb24gYW55d2hlcmUuCitUaGlzIHR1bmFibGUs IGlmIHNldCB0byBub24temVybyB2YWx1ZSwgZW5hYmxlcyB0byB1c2UgbWFudWFsIG1lZGlh IHNldHRpbmdzCit3aXRob3V0IGF1dG9uZWdvdGVhdGlvbiBhdCBhbGwuIElmIAorLkNtIG1l ZGlhCitpcyBzZXQgYXMgCisuQ20gYXV0b3NlbGVjdAorYXV0b25lZ290aWF0aW9uIHdpbGwg bm90IGRlcGVuZCBvbiB0aGlzIHR1bmFibGUuIFRoaXMgdHVuYWJsZSBpcyBhY2Nlc3NpYmxl CithcyBzeXNjdGwgdG9vLCBidXQgYWZmZWN0cyBvbmx5IGZ1dHVyZSB1c2luZyBvZiAKKy5D bSBtZWRpYQorYW5kCisuQ20gbWVkaWFvcHQKK29wdGlvbnMgb2YKKy5YciBpZmNvbmZpZyA4 CiAuRWwKIC5TaCBESUFHTk9TVElDUwogLkJsIC1kaWFnCmRpZmYgLXJ1TiAvbW50L3NyYy9z eXMvZGV2L21paS9yZ2VwaHkuYyBzeXMvZGV2L21paS9yZ2VwaHkuYwotLS0gL21udC9zcmMv c3lzL2Rldi9taWkvcmdlcGh5LmMJMjAxMS0wMS0xMiAxNjoxNDoyNi4wMDAwMDAwMDAgKzAz MDAKKysrIHN5cy9kZXYvbWlpL3JnZXBoeS5jCTIwMTEtMDEtMTIgMTg6NTI6MDYuMDAwMDAw MDAwICswMzAwCkBAIC00Miw2ICs0Miw3IEBACiAjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgog I2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KICNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CisjaW5j bHVkZSA8c3lzL3N5c2N0bC5oPgogI2luY2x1ZGUgPHN5cy9idXMuaD4KIAogI2luY2x1ZGUg PG5ldC9pZi5oPgpAQCAtNjYsNiArNjcsNyBAQAogCXN0cnVjdCBtaWlfc29mdGMgbWlpX3Nj OwogCWludCBtaWlfbW9kZWw7CiAJaW50IG1paV9yZXZpc2lvbjsKKwlpbnQgbWlpX2F1dG9u ZWdfY2FuX2JlX2Rpc2FibGVkOwogfTsKIAogc3RhdGljIGRldmljZV9tZXRob2RfdCByZ2Vw aHlfbWV0aG9kc1tdID0gewpAQCAtMTEzLDYgKzExNSw3IEBACiAJc3RydWN0IG1paV9zb2Z0 YyAqc2M7CiAJc3RydWN0IG1paV9hdHRhY2hfYXJncyAqbWE7CiAJc3RydWN0IG1paV9kYXRh ICptaWk7CisJY2hhciB0bls2NF07CiAKIAlyc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 CiAJc2MgPSAmcnNjLT5taWlfc2M7CkBAIC0xMjksNiArMTMyLDE2IEBACiAKIAlyc2MtPm1p aV9tb2RlbCA9IE1JSV9NT0RFTChtYS0+bWlpX2lkMik7CiAJcnNjLT5taWlfcmV2aXNpb24g PSBNSUlfUkVWKG1hLT5taWlfaWQyKTsKKwkKKwlyc2MtPm1paV9hdXRvbmVnX2Nhbl9iZV9k aXNhYmxlZCA9IDA7CisJc25wcmludGYodG4sIHNpemVvZih0biksICJkZXYuJXMuJWQuYXV0 b25lZ19jYW5fYmVfZGlzYWJsZWQiLAorCSAgICBkZXZpY2VfZ2V0X25hbWUoZGV2KSwgZGV2 aWNlX2dldF91bml0KGRldikpOworCVRVTkFCTEVfSU5UX0ZFVENIKHRuLCAmcnNjLT5taWlf YXV0b25lZ19jYW5fYmVfZGlzYWJsZWQpOworCVNZU0NUTF9BRERfSU5UKGRldmljZV9nZXRf c3lzY3RsX2N0eChkZXYpLAorCSAgICBTWVNDVExfQ0hJTERSRU4oZGV2aWNlX2dldF9zeXNj dGxfdHJlZShkZXYpKSwKKwkgICAgT0lEX0FVVE8sICJhdXRvbmVnX2Nhbl9iZV9kaXNhYmxl ZCIsIENUTEZMQUdfUlcsCisJICAgICZyc2MtPm1paV9hdXRvbmVnX2Nhbl9iZV9kaXNhYmxl ZCwgMCwKKwkgICAgIkF1dG9uZWdhdGlvbiBjYW4gYmUgZGlzYWJsZWQgb24gYWRhcHRlciIp OwogCiAjZGVmaW5lCUFERChtLCBjKQlpZm1lZGlhX2FkZCgmbWlpLT5taWlfbWVkaWEsICht KSwgKGMpLCBOVUxMKQogCkBAIC0yMTMsMTEgKzIyNiwxMiBAQAogCQkJfQogCiAJCQlpZiAo SUZNX1NVQlRZUEUoaWZlLT5pZm1fbWVkaWEpICE9IElGTV8xMDAwX1QpIHsKKwkJCQlpZiAo IXJzYy0+bWlpX2F1dG9uZWdfY2FuX2JlX2Rpc2FibGVkKQorCQkJCQlzcGVlZCB8PSBSR0VQ SFlfQk1DUl9BVVRPRU4gfAorCQkJCQkgICAgUkdFUEhZX0JNQ1JfU1RBUlRORUc7CiAJCQkJ UEhZX1dSSVRFKHNjLCBSR0VQSFlfTUlJXzEwMDBDVEwsIDApOwogCQkJCVBIWV9XUklURShz YywgUkdFUEhZX01JSV9BTkFSLCBhbmFyKTsKLQkJCQlQSFlfV1JJVEUoc2MsIFJHRVBIWV9N SUlfQk1DUiwgc3BlZWQgfAotCQkJCSAgICBSR0VQSFlfQk1DUl9BVVRPRU4gfAotCQkJCSAg ICBSR0VQSFlfQk1DUl9TVEFSVE5FRyk7CisJCQkJUEhZX1dSSVRFKHNjLCBSR0VQSFlfTUlJ X0JNQ1IsIHNwZWVkKTsKIAkJCQlicmVhazsKIAkJCX0KIAo= ------------7D1CC93EC99850-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 17:33: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 8C6CF1065673 for ; Wed, 12 Jan 2011 17:33:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C11A8FC14 for ; Wed, 12 Jan 2011 17:33:20 +0000 (UTC) Received: by gyf3 with SMTP id 3so315873gyf.13 for ; Wed, 12 Jan 2011 09:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=IkHw/4d3a2kLmFvw3zE7OdWiXLcTNSOkJN1VjEJC6MQ=; b=T4DjMQJkj0wY0o22g+yFrGjoE0FQVpaLr9ptqduFqdKlZMr9c8OHJuIcGCHhMxkGa5 7ublJ1tY4FmSUb900ih/ooZ1V4vZ2kQTB4ZM9zHB3QLhLrKPSK50aut08VQQLo3ji9cE +d+61uvev7fa0DzMkXGmIptVETcryC1mB+mUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=xJkbTruhZmwTeBU0uHzLwnWmU90K4i8ZtLUcsN/PjsUn4+I4mV1nYjHEq3pToQRZfI zyy303ADQNPWZkYTrovviE+unQ6rxkdnuWKpGKSDjW3mEmE66YvPRbwwPozT13nN+FMT FLw/YXOjRFw6mfMg055bdIqTJI8VJP6gu6s9I= Received: by 10.90.63.6 with SMTP id l6mr1932159aga.125.1294853600486; Wed, 12 Jan 2011 09:33:20 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x36sm1063910anx.34.2011.01.12.09.33.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 09:33:17 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Jan 2011 09:32:42 -0800 From: Pyun YongHyeon Date: Wed, 12 Jan 2011 09:32:42 -0800 To: Lev Serebryakov Message-ID: <20110112173242.GA12920@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> <149076940.20110112003110@serebryakov.spb.ru> <20110111224526.GD6278@michelle.cdnetworks.com> <751614742.20110112120303@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <751614742.20110112120303@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) 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 Jan 2011 17:33:21 -0000 On Wed, Jan 12, 2011 at 12:03:03PM +0300, Lev Serebryakov wrote: > Hello, Pyun. > You wrote 12 ÑÐ½Ð²Ð°Ñ€Ñ 2011 г., 1:45:26: > > > > That had been supported for long time. Just remove full-duplex > > media option in your manual configuration. > What do you mean by this? Without this media options it will be > 100Mbit half-duplex when switch port want 100Mbit full-duplex. With Because you have to rely on parallel detection the end result would be half-duplex. So switch port could be configured to 100Mbps/half-duplex and you can still use auto-negotiation. This way re(4) may be able to establish 100Mbps half-duplex. Full-duplex would be better but it seems there is no way at this moment. > this media option result is the same because refphy(4) ignores user > requests, if I understand right. > > -- > // Black Lion AKA Lev Serebryakov > From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 17:43: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 DACC61065670 for ; Wed, 12 Jan 2011 17:43:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B2818FC0C for ; Wed, 12 Jan 2011 17:43:30 +0000 (UTC) Received: by gwj21 with SMTP id 21so320637gwj.13 for ; Wed, 12 Jan 2011 09:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=siZ/vhPmojqp2bqj7I/TqFpg7NpeDVkzBqCVshFSp7I=; b=FcFXqlNa66FtmdJTqSVoESpPrbl+o0eKkkkTnFYaTNcS+KckolWFAERuuKRFhYSza+ 3uSaCtdvtkQUDNr46lZ/TYWRpU0QXHP/M7JVn2/hZ5GcsVNTWrdwIPjwOy/hfJKHkSny 6r5i5erw3LUCUMFianjG0h0AcdwTAIQolsgmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=LC5WxrpLpyel0KmXY9QGCYilLTQJeZTdswYDvw8IJ0u5yrjqBhnq6vrTvatYJ7S8cz 2r9fCNGCvVOMcji9U1ZxvjoQDb/YU0iZ8tz8Xvqln2DOVn4LmlTWeoydt4Tv6Bx+w42C hKWyjtdqNhwPurMZoR12Ulvfo7ErBNnKXyLzs= Received: by 10.100.139.20 with SMTP id m20mr771940and.138.1294854209430; Wed, 12 Jan 2011 09:43:29 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c28sm1077452ana.21.2011.01.12.09.43.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 09:43:27 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Jan 2011 09:42:52 -0800 From: Pyun YongHyeon Date: Wed, 12 Jan 2011 09:42:52 -0800 To: "Bjoern A. Zeeb" Message-ID: <20110112174252.GB12920@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> <20110112102248.F14966@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110112102248.F14966@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) 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 Jan 2011 17:43:31 -0000 On Wed, Jan 12, 2011 at 10:36:09AM +0000, Bjoern A. Zeeb wrote: > On Tue, 11 Jan 2011, Pyun YongHyeon wrote: > > >On Tue, Jan 11, 2011 at 12:47:29PM +0300, Lev Serebryakov wrote: > >> > >> media: Ethernet 100baseTX (100baseTX ) > > > >I can see what's going on here. Link partner used forced media > >configuration, probably 100baseTX/full-duplex, and re(4)'s > >resolved link is 100baseTX/half-duplex. > > I can confirm that the switch port should be (manually) set to 100/FD. > It's documented on their support wiki (in German). > > > >rgephy(4) currently always use auto-negotiation to work-around link > >establishment issues reported in past. I don't know how Linux > >managed to address link establishment issues for > >non-autonegotiation case though. Perhaps a lot of vendor supplied > > As I read your reply, there had been a time when manually setting > 100/FD was possible but it didn't quite work? > Correct. Many cases(probably old controllers) it worked but some revision of PHY did not like manual configuration. I don't remember details. > > >DSP fixups addressed that issue but I'm not sure. > >For your case, the only way to address the issue at this moment is > >to use auto-negotiation but that would establish 1000baseT link > >which would add cost for you. Alternatively request half-duplex > >configuration to the provider to get a agreed link duplex. > > We should still try to fix it somehow. Also it would be nice if re(4), > or rephy(4) if we had that, would document the issue properly in BUGS. > > > >See > >http://lists.freebsd.org/pipermail/freebsd-amd64/2011-January/013589.html > >for details on parallel detection. > > As someone from Hetzner has pointed out to me the original discussion > seemd to have been here: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059894.html > > > While I can understand the problem, has anyone contacted RealTek for > documentation to solve that matter, so that we could equally fix the > things as other major OSes have done by now (either themselves or by > a vendor update)? > Recently I got contact point to the vendor. The vendor is not willing to provide data sheet but they are generous enough to donate bunch of engineering sample boards to me. I'll ask some specific questions to the vendor. Let's see how it goes. From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 17:56: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 37446106566B for ; Wed, 12 Jan 2011 17:56:24 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id E27A78FC17 for ; Wed, 12 Jan 2011 17:56:23 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id B074413DF5F; Wed, 12 Jan 2011 20:56:22 +0300 (MSK) Date: Wed, 12 Jan 2011 20:56:19 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1982630028.20110112205619@serebryakov.spb.ru> To: Pyun YongHyeon In-Reply-To: <20110112173242.GA12920@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> <149076940.20110112003110@serebryakov.spb.ru> <20110111224526.GD6278@michelle.cdnetworks.com> <751614742.20110112120303@serebryakov.spb.ru> <20110112173242.GA12920@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 17:56:24 -0000 Hello, Pyun. You wrote 12 =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2011 =D0=B3., 20:32:42: >> > That had been supported for long time. Just remove full-duplex >> > media option in your manual configuration. >> What do you mean by this? Without this media options it will be >> 100Mbit half-duplex when switch port want 100Mbit full-duplex. With > Because you have to rely on parallel detection the end result would > be half-duplex. So switch port could be configured to > 100Mbps/half-duplex and you can still use auto-negotiation. This What if I CAN NOT configure switch port? It is 100Mbps/full-duplex/no-autonegotiation and it is not under my control! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 18:13: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 0AB1E106564A for ; Wed, 12 Jan 2011 18:13:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD8A98FC16 for ; Wed, 12 Jan 2011 18:13:32 +0000 (UTC) Received: by yie19 with SMTP id 19so338147yie.13 for ; Wed, 12 Jan 2011 10:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=4Yn44oErfzowYDujp9jJYQbheIe22HzJynBXbLiGD+4=; b=tswmGNGfqy+1zFuCoQsCgNd9Z9qpilOU0EjxO0oIZTh4/wnVnfnYoQupqyTMx3QTpq lzAel6DyoGQ5kqmc6qrGRfkeLQhqvtJ5lzLP5UZSoJOJd+M8hdqYKe6ZdAQz6naYHys+ jqDdNDiCIrH+fMTIfJ2BE0MIEaulyZPk/3CQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=GvfKFEo/QUav3XRkbzbxK6QcyrSL9J0MfmEHnEdmYuK2HW7t8QEH/HvBfnUNWOa+Dz xYeuKH8NiTx9uuR+ZLqHwSDQh4mvDuOdIZOCWQaQ+ff0rIsaZ6UwuRfr6ZXKT2pQ5NeC i4TNpMRuYgSytpyIe+1VLybNAFWtL8RHJPcWU= Received: by 10.90.249.31 with SMTP id w31mr124023agh.169.1294856011925; Wed, 12 Jan 2011 10:13:31 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b27sm1110283ana.8.2011.01.12.10.13.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 10:13:30 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Jan 2011 10:12:55 -0800 From: Pyun YongHyeon Date: Wed, 12 Jan 2011 10:12:55 -0800 To: Lev Serebryakov Message-ID: <20110112181255.GC12920@michelle.cdnetworks.com> References: <1512738982.20110111124729@serebryakov.spb.ru> <20110111200007.GC6278@michelle.cdnetworks.com> <149076940.20110112003110@serebryakov.spb.ru> <20110111224526.GD6278@michelle.cdnetworks.com> <751614742.20110112120303@serebryakov.spb.ru> <20110112173242.GA12920@michelle.cdnetworks.com> <1982630028.20110112205619@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1982630028.20110112205619@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug) 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 Jan 2011 18:13:33 -0000 On Wed, Jan 12, 2011 at 08:56:19PM +0300, Lev Serebryakov wrote: > Hello, Pyun. > You wrote 12 ÑÐ½Ð²Ð°Ñ€Ñ 2011 г., 20:32:42: > > > >> > That had been supported for long time. Just remove full-duplex > >> > media option in your manual configuration. > >> What do you mean by this? Without this media options it will be > >> 100Mbit half-duplex when switch port want 100Mbit full-duplex. With > > Because you have to rely on parallel detection the end result would > > be half-duplex. So switch port could be configured to > > 100Mbps/half-duplex and you can still use auto-negotiation. This > What if I CAN NOT configure switch port? It is > 100Mbps/full-duplex/no-autonegotiation and it is not under my control! > Of course that kind of workaround would not be available if you have no reachability to the switch. I thought service provider can do that by your request. > -- > // Black Lion AKA Lev Serebryakov > From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 20:16: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 4B72F1065674; Wed, 12 Jan 2011 20:16:05 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9B0338FC17; Wed, 12 Jan 2011 20:16:03 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 5B0CA1E000C6; Wed, 12 Jan 2011 20:58:11 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p0CJu024078590; Wed, 12 Jan 2011 20:56:00 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p0CJtx5B078589; Wed, 12 Jan 2011 20:55:59 +0100 (CET) (envelope-from nox) Date: Wed, 12 Jan 2011 20:55:59 +0100 (CET) Message-Id: <201101121955.p0CJtx5B078589@triton8.kn-bremen.de> To: FreeBSD-gnats-submit@freebsd.org From: Juergen Lock X-send-pr-version: 3.113 X-GNATS-Notify: Cc: freebsd-net@freebsd.org, moonlightakkiy@yahoo.ca Subject: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen Lock List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 20:16:05 -0000 >Submitter-Id: current-users >Originator: Juergen Lock >Organization: me? organized?? >Confidential: no >Synopsis: [run] [panic] [patch] Workaround for use-after-free panic >Severity: >Priority: >Category: kern >Class: sw-bug >Release: FreeBSD 8.1-RC2 amd64 >Environment: System: FreeBSD triton8.kn-bremen.de 8.1-RC2 FreeBSD 8.1-RC2 #9: Wed Sep 1 21:53:36 CEST 2010 nox@triton8.kn-bremen.de:/usr/obj/data2v/home/nox/src-r81/src/sys/TRITON8U amd64 Yes this is an older stable/8 checkout but if_run(4) is checked out from head. >Description: Running the nic in hostap mode with wpa2 I once every few weeks got the following crash: #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff805f0719 in boot (howto=260) at /data2v/home/nox/src-r81/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805f0b6c in panic (fmt=Variable "fmt" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/kern_shutdown.c:590 #3 0xffffffff808e4e0d in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:777 #4 0xffffffff808e51f4 in trap_pfault (frame=0xffffff80ec121aa0, usermode=0) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:693 #5 0xffffffff808e5a7e in trap (frame=0xffffff80ec121aa0) at /data2v/home/nox/src-r81/src/sys/amd64/amd64/trap.c:451 #6 0xffffffff808ca953 in calltrap () at /data2v/home/nox/src-r81/src/sys/amd64/amd64/exception.S:223 #7 0xffffffff81072ac6 in run_drain_fifo (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2245 #8 0xffffffff81072bc3 in run_ratectl_cb (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2210 #9 0xffffffff8062e543 in taskqueue_run (queue=0xffffff0005f42380) at /data2v/home/nox/src-r81/src/sys/kern/subr_taskqueue.c:239 #10 0xffffffff8062e7c6 in taskqueue_thread_loop (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/subr_taskqueue.c:360 ---Type to continue, or q to quit--- #11 0xffffffff805c64a8 in fork_exit ( callout=0xffffffff8062e780 , arg=0xffffff8000b130b8, frame=0xffffff80ec121c80) at /data2v/home/nox/src-r81/src/sys/kern/kern_fork.c:844 #12 0xffffffff808cae2e in fork_trampoline () at /data2v/home/nox/src-r81/src/sys/amd64/amd64/exception.S:562 #13 0x0000000000000000 in ?? () #14 0x0000000000000000 in ?? () #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000f37000 in ?? () #38 0x0000000000000000 in ?? () #39 0xffffff00078c47c0 in ?? () #40 0xffffffff80cac9c0 in affinity () #41 0xffffff00018837c0 in ?? () #42 0xffffff80ec121710 in ?? () #43 0xffffff80ec1216c8 in ?? () #44 0xffffff00078c47c0 in ?? () #45 0xffffffff8061471a in sched_switch (td=0xffffff8000b130b8, newtd=0xffffffff8062e780, flags=Variable "flags" is not available. ) at /data2v/home/nox/src-r81/src/sys/kern/sched_ule.c:1844 Previous frame inner to this frame (corrupt stack?) (kgdb) fr 7 #7 0xffffffff81072ac6 in run_drain_fifo (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2245 2245 ni = sc->sc_ni[wcid]; (kgdb) p wcid $1 = 1 '\001' (kgdb) p sc->sc_ni $2 = {0x0, 0xffffff8001676000, 0x0 } (kgdb) p sc->sc_ni[1] $3 = (struct ieee80211_node *) 0xffffff8001676000 (kgdb) p *sc->sc_ni[1] Cannot access memory at address 0xffffff8001676000 (kgdb) up #8 0xffffffff81072bc3 in run_ratectl_cb (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2210 2210 run_drain_fifo(sc); (kgdb) p sc->sc_ni $4 = {0x0, 0xffffff8001676000, 0x0 } (kgdb) l run_drain_fifo 2216 usb_callout_reset(&sc->ratectl_ch, hz, run_ratectl_to, sc); 2217 } 2218 2219 static void 2220 run_drain_fifo(void *arg) 2221 { 2222 struct run_softc *sc = arg; 2223 struct ifnet *ifp = sc->sc_ifp; 2224 struct ieee80211_node *ni = sc->sc_ni[0]; /* make compiler happy */ 2225 uint32_t stat; (kgdb) l 2226 int retrycnt = 0; 2227 uint8_t wcid, mcs, pid; 2228 2229 RUN_LOCK_ASSERT(sc, MA_OWNED); 2230 2231 for (;;) { 2232 /* drain Tx status FIFO (maxsize = 16) */ 2233 run_read(sc, RT2860_TX_STAT_FIFO, &stat); 2234 DPRINTFN(4, "tx stat 0x%08x\n", stat); 2235 if (!(stat & RT2860_TXQ_VLD)) (kgdb) 2236 break; 2237 2238 wcid = (stat >> RT2860_TXQ_WCID_SHIFT) & 0xff; 2239 2240 /* if no ACK was requested, no feedback is available */ 2241 if (!(stat & RT2860_TXQ_ACKREQ) || wcid > RT2870_WCID_MAX || 2242 wcid == 0) 2243 continue; 2244 2245 ni = sc->sc_ni[wcid]; (kgdb) 2246 if (ni->ni_rctls == NULL) 2247 continue; 2248 2249 /* update per-STA AMRR stats */ 2250 if (stat & RT2860_TXQ_OK) { 2251 /* 2252 * Check if there were retries, ie if the Tx 2253 * success rate is different from the requested 2254 * rate. Note that it works only because we do 2255 * not allow rate fallback from OFDM to CCK. (kgdb) 2256 */ 2257 mcs = (stat >> RT2860_TXQ_MCS_SHIFT) & 0x7f; 2258 pid = (stat >> RT2860_TXQ_PID_SHIFT) & 0xf; 2259 if (mcs + 1 != pid) 2260 retrycnt = 1; 2261 ieee80211_ratectl_tx_complete(ni->ni_vap, ni, 2262 IEEE80211_RATECTL_TX_SUCCESS, 2263 &retrycnt, NULL); 2264 } else { 2265 retrycnt = 1; (kgdb) 2266 ieee80211_ratectl_tx_complete(ni->ni_vap, ni, 2267 IEEE80211_RATECTL_TX_FAILURE, 2268 &retrycnt, NULL); 2269 ifp->if_oerrors++; 2270 } 2271 } 2272 DPRINTFN(3, "count=%d\n", sc->fifo_cnt); 2273 2274 sc->fifo_cnt = 0; 2275 } (kgdb) up #9 0xffffffff8062e543 in taskqueue_run (queue=0xffffff0005f42380) at /data2v/home/nox/src-r81/src/sys/kern/subr_taskqueue.c:239 239 task->ta_func(task->ta_context, pending); (kgdb) p task $5 = (struct task *) 0xffffff8000a8be38 (kgdb) p *task $6 = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xffffffff81072b60 , ta_context = 0xffffff8000a89000} (kgdb) l run_ratectl_cb 2184 } 2185 2186 /* ARGSUSED */ 2187 static void 2188 run_ratectl_cb(void *arg, int pending) 2189 { 2190 struct run_softc *sc = arg; 2191 struct ieee80211com *ic = sc->sc_ifp->if_l2com; 2192 struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); 2193 (kgdb) down #8 0xffffffff81072bc3 in run_ratectl_cb (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2210 2210 run_drain_fifo(sc); (kgdb) l run_ratectl_cb 2184 } 2185 2186 /* ARGSUSED */ 2187 static void 2188 run_ratectl_cb(void *arg, int pending) 2189 { 2190 struct run_softc *sc = arg; 2191 struct ieee80211com *ic = sc->sc_ifp->if_l2com; 2192 struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); 2193 (kgdb) l 2194 if (vap == NULL) 2195 return; 2196 2197 if (sc->rvp_cnt <= 1 && vap->iv_opmode == IEEE80211_M_STA) 2198 run_iter_func(sc, vap->iv_bss); 2199 else { 2200 /* 2201 * run_reset_livelock() doesn't do anything with AMRR, 2202 * but Ralink wants us to call it every 1 sec. So, we 2203 * piggyback here rather than creating another callout. (kgdb) p sc->rvp_cnt $7 = 1 '\001' (kgdb) l 2204 * Livelock may occur only in HOSTAP or IBSS mode 2205 * (when h/w is sending beacons). 2206 */ 2207 RUN_LOCK(sc); 2208 run_reset_livelock(sc); 2209 /* just in case, there are some stats to drain */ 2210 run_drain_fifo(sc); 2211 RUN_UNLOCK(sc); 2212 ieee80211_iterate_nodes(&ic->ic_sta, run_iter_func, sc); 2213 } (kgdb) down #7 0xffffffff81072ac6 in run_drain_fifo (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2245 2245 ni = sc->sc_ni[wcid]; (kgdb) up #8 0xffffffff81072bc3 in run_ratectl_cb (arg=Variable "arg" is not available. ) at /data2v/home/nox/src-r81/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2210 2210 run_drain_fifo(sc); (kgdb) l 2205 * (when h/w is sending beacons). 2206 */ 2207 RUN_LOCK(sc); 2208 run_reset_livelock(sc); 2209 /* just in case, there are some stats to drain */ 2210 run_drain_fifo(sc); 2211 RUN_UNLOCK(sc); 2212 ieee80211_iterate_nodes(&ic->ic_sta, run_iter_func, sc); 2213 } 2214 (kgdb) l 2215 if(sc->ratectl_run != RUN_RATECTL_OFF) 2216 usb_callout_reset(&sc->ratectl_ch, hz, run_ratectl_to, sc); 2217 } 2218 2219 static void 2220 run_drain_fifo(void *arg) 2221 { 2222 struct run_softc *sc = arg; 2223 struct ifnet *ifp = sc->sc_ifp; 2224 struct ieee80211_node *ni = sc->sc_ni[0]; /* make compiler happy */ (kgdb) 2225 uint32_t stat; 2226 int retrycnt = 0; 2227 uint8_t wcid, mcs, pid; 2228 2229 RUN_LOCK_ASSERT(sc, MA_OWNED); 2230 2231 for (;;) { 2232 /* drain Tx status FIFO (maxsize = 16) */ 2233 run_read(sc, RT2860_TX_STAT_FIFO, &stat); 2234 DPRINTFN(4, "tx stat 0x%08x\n", stat); (kgdb) p sc->fifo_cnt $8 = 1 '\001' (kgdb) l 2235 if (!(stat & RT2860_TXQ_VLD)) 2236 break; 2237 2238 wcid = (stat >> RT2860_TXQ_WCID_SHIFT) & 0xff; 2239 2240 /* if no ACK was requested, no feedback is available */ 2241 if (!(stat & RT2860_TXQ_ACKREQ) || wcid > RT2870_WCID_MAX || 2242 wcid == 0) 2243 continue; 2244 (kgdb) l 2245 ni = sc->sc_ni[wcid]; 2246 if (ni->ni_rctls == NULL) 2247 continue; 2248 2249 /* update per-STA AMRR stats */ 2250 if (stat & RT2860_TXQ_OK) { 2251 /* 2252 * Check if there were retries, ie if the Tx 2253 * success rate is different from the requested 2254 * rate. Note that it works only because we do (kgdb) p vap->iv_opmode Variable "vap" is not available. (kgdb) p ic->ic_vaps $9 = {tqh_first = 0xffffff0007800000, tqh_last = 0xffffff0007800048} (kgdb) p ic->ic_vaps->tqh_first $10 = (struct ieee80211vap *) 0xffffff0007800000 (kgdb) p ic->ic_vaps->tqh_first->iv_opmode $11 = IEEE80211_M_HOSTAP (kgdb) p ic->ic_vaps->tqh_last->iv_opmode Cannot access memory at address 0x2f0 (kgdb) p ic->ic_vaps->tqh_last $12 = (struct ieee80211vap **) 0xffffff0007800048 (kgdb) p *ic->ic_vaps->tqh_last $13 = (struct ieee80211vap *) 0x0 (kgdb) q Script done on Tue Jan 4 09:23:48 2011 >How-To-Repeat: Setup if_run(4) in hostap mode, wait a few weeks... (I only have one smartphone using the wifi, maybe if you have a bigger network it'll happen more often?) >Fix: I don't really know the wifi code so the following patch is likely not the `proper' fix (and it also still has diagnostic code that shouldn't be committed as is), but at least it fixed the panic for me, I just finally got the run0: drain_fifo ni=NULL wcid=1 message I added for the condition that previously caused the panic, and the nic kept working. (The panic happened when sc->sc_ni[wcid] was accessed by run_drain_fifo() after it had been free'd, so I hooked into ic->ic_node_cleanup to set it to NULL before it gets free'd and added a check for NULL with the above message to run_drain_fifo().) Index: src/sys/dev/usb/wlan/if_run.c =================================================================== RCS file: /home/scvs/src/sys/dev/usb/wlan/if_run.c,v retrieving revision 1.17 diff -u -p -r1.17 if_run.c --- src/sys/dev/usb/wlan/if_run.c 6 Nov 2010 18:17:20 -0000 1.17 +++ src/sys/dev/usb/wlan/if_run.c 7 Jan 2011 00:58:35 -0000 @@ -341,6 +341,7 @@ static const char *run_get_rf(int); static int run_read_eeprom(struct run_softc *); static struct ieee80211_node *run_node_alloc(struct ieee80211vap *, const uint8_t mac[IEEE80211_ADDR_LEN]); +static void run_node_cleanup(struct ieee80211_node *ni); static int run_media_change(struct ifnet *); static int run_newstate(struct ieee80211vap *, enum ieee80211_state, int); static int run_wme_update(struct ieee80211com *); @@ -673,6 +674,8 @@ run_attach(device_t self) ic->ic_scan_end = run_scan_end; ic->ic_set_channel = run_set_channel; ic->ic_node_alloc = run_node_alloc; + sc->sc_node_cleanup = ic->ic_node_cleanup; + ic->ic_node_cleanup = run_node_cleanup; ic->ic_newassoc = run_newassoc; //ic->ic_updateslot = run_updateslot; ic->ic_update_mcast = run_update_mcast; @@ -2243,7 +2246,14 @@ run_drain_fifo(void *arg) continue; ni = sc->sc_ni[wcid]; - if (ni->ni_rctls == NULL) +#if 1 + static struct ieee80211_node *lastni; + if (ni == NULL && lastni) + device_printf(sc->sc_dev, "drain_fifo ni=NULL wcid=%d\n", + wcid); + lastni = ni; +#endif + if (ni == NULL || ni->ni_rctls == NULL) continue; /* update per-STA AMRR stats */ @@ -2373,10 +2383,12 @@ run_newassoc(struct ieee80211_node *ni, ieee80211_runtask(ic, &sc->cmdq_task); } - DPRINTF("new assoc isnew=%d associd=%x addr=%s\n", - isnew, ni->ni_associd, ether_sprintf(ni->ni_macaddr)); + //DPRINTF("new assoc isnew=%d associd=%x addr=%s\n", + device_printf(sc->sc_dev, "new assoc isnew=%d associd=%x addr=%s ni=%p\n", + isnew, ni->ni_associd, ether_sprintf(ni->ni_macaddr), ni); ieee80211_ratectl_node_init(ni); + rn->wcid = wcid; sc->sc_ni[wcid] = ni; for (i = 0; i < rs->rs_nrates; i++) { @@ -2412,6 +2424,39 @@ run_newassoc(struct ieee80211_node *ni, usb_callout_reset(&sc->ratectl_ch, hz, run_ratectl_to, sc); } +static void +run_node_cleanup(struct ieee80211_node *ni) +{ + struct run_node *rn = (void *)ni; + struct ieee80211vap *vap = ni->ni_vap; + struct ieee80211com *ic = vap->iv_ic; + struct run_softc *sc = ic->ic_ifp->if_softc; + uint8_t wcid = RUN_AID2WCID(ni->ni_associd); + + if (wcid == 0) + wcid = rn->wcid; + if (wcid > RT2870_WCID_MAX) { + device_printf(sc->sc_dev, "wcid=%d out of range\n", wcid); + sc->sc_node_cleanup(ni); + return; + } + + //DPRINTF("node_cleanup wcid=%d addr=%s\n", + device_printf(sc->sc_dev, "node_cleanup wcid=%d addr=%s ni=%p\n", + wcid, ether_sprintf(vap->iv_opmode == IEEE80211_M_STA ? + vap->iv_myaddr : ni->ni_macaddr), ni); + + if (wcid > 0 && sc->sc_ni[wcid]) { + if (sc->sc_ni[wcid] != ni) { + device_printf(sc->sc_dev, "node_cleanup sc->sc_ni[wcid] %p != ni\n", + sc->sc_ni[wcid]); + } else { + sc->sc_ni[wcid] = NULL; + } + } + sc->sc_node_cleanup(ni); +} + /* * Return the Rx chain with the highest RSSI for a given frame. */ Index: src/sys/dev/usb/wlan/if_runvar.h =================================================================== RCS file: /home/scvs/src/sys/dev/usb/wlan/if_runvar.h,v retrieving revision 1.6 diff -u -p -r1.6 if_runvar.h --- src/sys/dev/usb/wlan/if_runvar.h 14 Jun 2010 00:40:23 -0000 1.6 +++ src/sys/dev/usb/wlan/if_runvar.h 4 Jan 2011 08:48:13 -0000 @@ -106,6 +106,7 @@ struct run_node { uint8_t amrr_ridx; uint8_t mgt_ridx; uint8_t fix_ridx; + uint8_t wcid; }; struct run_cmdq { @@ -164,6 +165,8 @@ struct run_softc { int (*sc_srom_read)(struct run_softc *, uint16_t, uint16_t *); + void (*sc_node_cleanup)(struct ieee80211_node *); + uint16_t mac_ver; uint16_t mac_rev; uint8_t rf_rev; From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 21:28:20 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 4098D1065672 for ; Wed, 12 Jan 2011 21:28:20 +0000 (UTC) (envelope-from artemb@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 C0A298FC22 for ; Wed, 12 Jan 2011 21:28:19 +0000 (UTC) Received: by bwz12 with SMTP id 12so891675bwz.13 for ; Wed, 12 Jan 2011 13:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pvog0ARtSInK7tQpn23oBdpalUSyblNyacQToKU4YO0=; b=NyfLICHIGoOdJC4KReLlaSoxp/04xkERAM+NRGDp7pH3s/ZrC7Tq7SxFpEbRUQIY8v 8UuaAoWSKQCvYt228vNk+mpHzFErBHdSIwm6bmf9vFIYiGCzZK3r5zFLfDXVO6lfDI/9 EhWwhYbyT0iQZnS7e99fTpQopQdTHcyQIjdA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fhDly7szMZgTc16W+l7B2AKkRzt6hugtHoJ6Hi5F850uSHWh6pn5F+RFTHOo2VMbhp YlphK64cKI9EzFs04ruVjNAkrE5sfSYErpTI5zF3CHiPd5cYn434v5dF0C9zKANa3w84 n5CBtykhSP6D+DIaZwg4/hYWOs8vQrZDrElBE= MIME-Version: 1.0 Received: by 10.204.122.65 with SMTP id k1mr1108891bkr.80.1294865998558; Wed, 12 Jan 2011 12:59:58 -0800 (PST) Received: by 10.204.22.18 with HTTP; Wed, 12 Jan 2011 12:59:58 -0800 (PST) In-Reply-To: <36074996.20110112192009@serebryakov.spb.ru> References: <36074996.20110112192009@serebryakov.spb.ru> Date: Wed, 12 Jan 2011 12:59:58 -0800 Message-ID: From: Artem Belevich To: Lev Serebryakov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:28:20 -0000 2011/1/12 Lev Serebryakov : > Hello, Freebsd-net. > > =A0Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > with re(4) does autonegotiation always and all other, who helps me > diagnose problem! > > =A0I've prepared patch, which adds tunable/sysctl for rgephy(4) which > allows not to sue autonegotiation by this PHY (at user responsibility, > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > by default, and in such case behavior of driver IS NOT CHANGED. > > =A0But if it is set ON (non-zero value) before "media / mediopt" > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > settings. > > =A0I've documented this new tunable in re(4) manpage, as here is no > rgephy(4) manpage. I wonder if we could make autonegotiation another media option. This may solve the problem at hand in a more generic way. In case someone specifies speed/duplex settings but want autonegotiation on, we can advertise only that particular speed/duplex capability (as opposed to advertising everything we support). This would force remote end to either establish the link with the parameters we want or keep the link down which would be better than keeping the link up with mismatched duplex settings. --Artem From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 21:32: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 5F006106566C for ; Wed, 12 Jan 2011 21:32:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 11E018FC0A for ; Wed, 12 Jan 2011 21:32:44 +0000 (UTC) Received: by pxi1 with SMTP id 1so162803pxi.13 for ; Wed, 12 Jan 2011 13:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=hpTjJch7v7QM5+OjMLOUw4tISCG+kMLu6tZWKow+P1I=; b=CEIMtEep1Xk8cUbANSorY4w7iw2un4X5pVS/VGRWJgNpx6qtg7m7giKWQU9mLQR2VG 50kCB/Ow9CYcpg3OO7rIfYZUOF/EaE0IyRUlqdS0H7F1DrHdwox4tU7xeHasdY6jy4FE 5dXhKDf/MU38/6PCLGf+mx/TFwWQCuCCWaQUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=EbcUkrPeBN6B4d5ROb19k1zY/wEJwsgXo4nLhUt6x4H3oq04DgGuINWa199+pNjVZN PDgfbigtOb1RiUnV1/i2AFlh7xLZq6j/B9dyPfrLRYeBEOup6NzDmJJ/SHZmWFNfbU34 oZ4yXc5eOm9kY3oX+T/H0Fgdi7pl18gtErwCs= Received: by 10.142.213.18 with SMTP id l18mr228459wfg.192.1294867964581; Wed, 12 Jan 2011 13:32:44 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q13sm1352919wfc.17.2011.01.12.13.32.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 13:32:42 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Jan 2011 13:32:08 -0800 From: Pyun YongHyeon Date: Wed, 12 Jan 2011 13:32:08 -0800 To: Lev Serebryakov Message-ID: <20110112213208.GD12920@michelle.cdnetworks.com> References: <36074996.20110112192009@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36074996.20110112192009@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW 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 Jan 2011 21:32:45 -0000 On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote: > Hello, Freebsd-net. > > Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > with re(4) does autonegotiation always and all other, who helps me > diagnose problem! > > I've prepared patch, which adds tunable/sysctl for rgephy(4) which > allows not to sue autonegotiation by this PHY (at user responsibility, > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > by default, and in such case behavior of driver IS NOT CHANGED. > > But if it is set ON (non-zero value) before "media / mediopt" > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > settings. > > I've documented this new tunable in re(4) manpage, as here is no > rgephy(4) manpage. > > Tunable is per-device, not global one. > > Sysctl can be set after boot, but will affect only future ifconfig > calls, it doesn't change anything in PHY settings by itself. > > It allows fully manual setup on non-buggy hardware, which allows to > use Hetzner dedicated servers with FreeBSD without additional NIC or > gigabit connection. > > I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it > allows me to get full-duplex 100Mbit connection and I got 11MiB/s from > local NFS with it. > > Without this patch FreeBSD is unusable on Hetzner dedicated servers > in newer DCs (DC 13 and DC 14). > > Patch is attached. I think, it worths to include it to base system, > as it allows use FreeBSD at least on one very large and popular > hosting provider without additional costs :) > Thanks for your work. After reading commit log of rgephy(4) I now refreshed my memory. The issue came from the reverse usage case. Suppose link partner announces auto-negotiation but you want to use 100baseTX/full-duplex. As you know this results in duplex mismatch and sometimes it couldn't establish a link on some RealTek PHYs. (Now I'm not entirely sure it was caused by the specific switch or rgephy(4) or both) And frequently, link partner(switch) is out of control from your domain and most switches are configured to use auto-negotiation by default. Using auto-negotiation in manual media configuration seemed to address the issue at that time. 1000baseT link always requires auto-negotiation but too many switches were broken with auto-negotiation so some switches are forced to use manual media configuration even in 1000baseT mode. Using auto-negotiation on rgephy(4) will also solve that case. So I have mixed feelings on how to handle both cases. Traditional way, which your patch does, used in manual configuration was to strictly honor specified manual media configuration even if it can break in some edge cases. Programming PHYs with traditional way shall also trigger other problems to drivers which correctly keep track of valid link state changes. Normally speed/duplex/flow-control changes require MAC reprogramming such that monitoring PHY's state change is essential to modern ethernet controllers. Forcing manual media configuration can make PHY drivers fail to report link state changes which in turn shall make ethernet controller not to work due to speed/duplex mismatches between PHY and MAC of ethernet controller. re(4) does not require MAC reprogramming but many other drivers that use regephy(4) may not work. However regphy(4) hardware I have still seem to correctly report link state change with manual link configuration. Not sure about old controllers though. I'm under the impression that rgephy(4)'s behavior seem to confuse users a lot since it unconditionally use auto-negotiation so I think it's better not to use auto-negotiation at all during manual media configuration and provides a way to use auto-negotiation in manual media configuration if administrator want to do that. From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 21:38: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 ABFCE1065679 for ; Wed, 12 Jan 2011 21:38:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 797508FC27 for ; Wed, 12 Jan 2011 21:38:41 +0000 (UTC) Received: by pxi1 with SMTP id 1so163919pxi.13 for ; Wed, 12 Jan 2011 13:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=GrsHOiqMjyYuKGS/lhCMgZjsPBN1tpUlYpGoSsRzA10=; b=SK8CSWR1YVG32xSwFv58ecasPkNgYy4plMz14BY+czQnY0+aVYA7Qf3cqYJFJRZKDK 7wv/pIq2HVjT6mY+ByQQhC+jP0KfOsS+D0igLFDqqsRhtyc3blt4CleWBR1BgOkvMdru oRPMYvzba0gyY5re8gkTYTuDQrHCSAccnT8+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=rgnhub4sKeIz9B3YLbfIz4axv4dIzbJkLu0/0W+7nSYder2Z71JLFwebaMWPRHmTq0 IGIXi2X9VVZHczuILDKSWKDtHVWsP44cvVAH7k+dmF8sGOrG0muJfrgXfkfvg6BOTBll gDNFw3L67TzJEjT7NCceRcPIXpM9n97bSs2UY= Received: by 10.142.172.3 with SMTP id u3mr230369wfe.374.1294868320872; Wed, 12 Jan 2011 13:38:40 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x18sm1354885wfa.23.2011.01.12.13.38.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 13:38:39 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Jan 2011 13:38:05 -0800 From: Pyun YongHyeon Date: Wed, 12 Jan 2011 13:38:05 -0800 To: Artem Belevich Message-ID: <20110112213805.GE12920@michelle.cdnetworks.com> References: <36074996.20110112192009@serebryakov.spb.ru> 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, Lev Serebryakov Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW 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 Jan 2011 21:38:41 -0000 On Wed, Jan 12, 2011 at 12:59:58PM -0800, Artem Belevich wrote: > 2011/1/12 Lev Serebryakov : > > Hello, Freebsd-net. > > > > ?Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > > with re(4) does autonegotiation always and all other, who helps me > > diagnose problem! > > > > ?I've prepared patch, which adds tunable/sysctl for rgephy(4) which > > allows not to sue autonegotiation by this PHY (at user responsibility, > > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > > by default, and in such case behavior of driver IS NOT CHANGED. > > > > ?But if it is set ON (non-zero value) before "media / mediopt" > > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > > settings. > > > > ?I've documented this new tunable in re(4) manpage, as here is no > > rgephy(4) manpage. > > I wonder if we could make autonegotiation another media option. > This may solve the problem at hand in a more generic way. > > In case someone specifies speed/duplex settings but want > autonegotiation on, we can advertise only that particular speed/duplex > capability (as opposed to advertising everything we support). This > would force remote end to either establish the link with the > parameters we want or keep the link down which would be better than > keeping the link up with mismatched duplex settings. > Yeah, that would be good option. However, it's not trivial to implement these things on all PHY drivers. Some PHY hardwares do not have a capability which can tell it successfully resolved speed/duplex with manual media configuration. From owner-freebsd-net@FreeBSD.ORG Wed Jan 12 22:59:10 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 616D7106564A for ; Wed, 12 Jan 2011 22:59:10 +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 B7B028FC15 for ; Wed, 12 Jan 2011 22:59:09 +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 p0CMx829044385; Wed, 12 Jan 2011 23:59:08 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p0CMx7S0044384; Wed, 12 Jan 2011 23:59:07 +0100 (CET) (envelope-from marius) Date: Wed, 12 Jan 2011 23:59:07 +0100 From: Marius Strobl To: Pyun YongHyeon Message-ID: <20110112225907.GA44318@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110112213208.GD12920@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 22:59:10 -0000 On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote: > On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote: > > Hello, Freebsd-net. > > > > Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > > with re(4) does autonegotiation always and all other, who helps me > > diagnose problem! > > > > I've prepared patch, which adds tunable/sysctl for rgephy(4) which > > allows not to sue autonegotiation by this PHY (at user responsibility, > > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > > by default, and in such case behavior of driver IS NOT CHANGED. > > > > But if it is set ON (non-zero value) before "media / mediopt" > > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > > settings. > > > > I've documented this new tunable in re(4) manpage, as here is no > > rgephy(4) manpage. > > > > Tunable is per-device, not global one. > > > > Sysctl can be set after boot, but will affect only future ifconfig > > calls, it doesn't change anything in PHY settings by itself. > > > > It allows fully manual setup on non-buggy hardware, which allows to > > use Hetzner dedicated servers with FreeBSD without additional NIC or > > gigabit connection. > > > > I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it > > allows me to get full-duplex 100Mbit connection and I got 11MiB/s from > > local NFS with it. > > > > Without this patch FreeBSD is unusable on Hetzner dedicated servers > > in newer DCs (DC 13 and DC 14). > > > > Patch is attached. I think, it worths to include it to base system, > > as it allows use FreeBSD at least on one very large and popular > > hosting provider without additional costs :) > > > > Thanks for your work. After reading commit log of rgephy(4) I now > refreshed my memory. The issue came from the reverse usage case. > Suppose link partner announces auto-negotiation but you want to use > 100baseTX/full-duplex. As you know this results in duplex mismatch > and sometimes it couldn't establish a link on some RealTek PHYs. > (Now I'm not entirely sure it was caused by the specific switch or > rgephy(4) or both) > And frequently, link partner(switch) is out of control from your > domain and most switches are configured to use auto-negotiation by > default. Using auto-negotiation in manual media configuration > seemed to address the issue at that time. 1000baseT link always > requires auto-negotiation but too many switches were broken with > auto-negotiation so some switches are forced to use manual media > configuration even in 1000baseT mode. Using auto-negotiation on > rgephy(4) will also solve that case. > > So I have mixed feelings on how to handle both cases. Traditional > way, which your patch does, used in manual configuration was to > strictly honor specified manual media configuration even if it can > break in some edge cases. Programming PHYs with traditional way > shall also trigger other problems to drivers which correctly keep > track of valid link state changes. Normally speed/duplex/flow-control > changes require MAC reprogramming such that monitoring PHY's state > change is essential to modern ethernet controllers. Forcing manual > media configuration can make PHY drivers fail to report link state > changes which in turn shall make ethernet controller not to work > due to speed/duplex mismatches between PHY and MAC of ethernet > controller. re(4) does not require MAC reprogramming but many other > drivers that use regephy(4) may not work. However regphy(4) > hardware I have still seem to correctly report link state change > with manual link configuration. Not sure about old controllers > though. > > I'm under the impression that rgephy(4)'s behavior seem to confuse > users a lot since it unconditionally use auto-negotiation so I > think it's better not to use auto-negotiation at all during manual > media configuration and provides a way to use auto-negotiation in > manual media configuration if administrator want to do that. Note that even the RealTek supplied driver always triggers an auto-negotiation when manually setting the media though. However, at the same time it also comes with tons of uncommented PHY fix-up code which might be relevant for this or the previous issue. Unfortunately, I didn't get to checking whether the MAC versions in question are amongst the ones that get patched so far. In any case I don't think we can easily change this (default) behavior after such a relatively long time as it would break POLA for an unknown number of users, even if it probably shouldn't have been made the default in the first place (but again on the other hand that's what RealTek themselves also chose to do). Also apart from edges cases like the current issue the present behavior should result in a setup that "just works" so I doubt it actually results in confusion. Marius From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 03:23: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 4D5A910656AC for ; Thu, 13 Jan 2011 03:23:18 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 04CD18FC1F for ; Thu, 13 Jan 2011 03:23:17 +0000 (UTC) Received: from jack.bspruce.com ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Wed, 12 Jan 2011 21:43:15 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4D2E66C4.5090607@greatbaysoftware.com> Date: Wed, 12 Jan 2011 21:43:16 -0500 From: Charles Owens MIME-Version: 1.0 To: Robin Sommer References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> In-Reply-To: <20110103210209.GA13091@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Cc: freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 03:23:18 -0000 I'd like to report that we're running into this issue also, in our case on systems that are based on the Intel S5520UR Server Board, running 8.1-RELEASE. If the ichwd driver is loaded we see the same messages, and network communication via the igb nics is non-functional. Have you had any luck? Thanks, Charles Charles Owens Great Bay Software, Inc. On 1/3/11 4:02 PM, Robin Sommer wrote: > Hello all, > > quite a while ago I asked about the problem below. Unfortunately, I > haven't found a solution yet and I'm actually still seeing these > timeouts after just upgrading to 8.2-RC1. Any further ideas on what > could be triggering them, or how I could track down the cause? > > Thanks, > > Robin > > On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: > >> Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots of messages >> like those below on all my SuperMicro SBI-7425C-T3 blades. There's >> almost no traffic on those interfaces. >> >> Any idea? >> >> Thanks, >> >> Robin >> >> Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout -- resetting >> Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256, hw tdt = 266 >> Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail = 1013,Next TX to Clean = 255 >> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to DOWN >> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP >> Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout -- resetting >> Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >> Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to Clean = 0 >> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to DOWN >> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP >> Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout -- resetting >> Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw tdt = 33 >> Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail = 1022,Next TX to Clean = 31 >> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to DOWN >> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP >> Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout -- resetting >> Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >> Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to Clean = 0 >> Jul 29 13:01:57 blade0 kernel: igb1: link state changed to DOWN >> Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP >> Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout -- resetting >> >>> grep igb /var/run/dmesg.boot >> igb0: port 0x2000-0x201f mem 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff irq 16 at device 0.0 on pci4 >> igb0: [FILTER] >> igb0: Ethernet address: 00:30:48:9e:22:00 >> igb1: port 0x2020-0x203f mem 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff irq 17 at device 0.1 on pci4 >> igb1: [FILTER] >> igb1: Ethernet address: 00:30:48:9e:22:01 >> >>> pciconf -lv >> [...] >> igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 >> chip=0x10a98086 rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82575EB Gigabit Backplane Connection' >> class = network >> subclass = ethernet >> igb1@pci0:4:0:1: class=0x020000 card=0x10a915d9 >> chip=0x10a98086 rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82575EB Gigabit Backplane Connection' >> class = network >> subclass = ethernet >> [...] From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 04:14: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 CCA69106566C for ; Thu, 13 Jan 2011 04:14:47 +0000 (UTC) (envelope-from ulsanrub@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 8D2DB8FC13 for ; Thu, 13 Jan 2011 04:14:47 +0000 (UTC) Received: by qwj9 with SMTP id 9so1338928qwj.13 for ; Wed, 12 Jan 2011 20:14:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=T6bIsCZz1/aHQ9YXih9Jq3HPqpKm4UhVIS5Jy8mI/o4=; b=TjWOWpvwjL+z/1vt759iAdc78f9ThgWTtCSJmDm5SJbHiiGoq5XY/IFLGD771PtmbN 4b4OCXljPme6B0iD2dTU/zlUH6ht8ZMHl2AGzgNwdGNhTuvnMpIw9hh/i8eTPqUoqH6O EXjY2bijDitag0O2TnaX9sUsfBlNQQqKPUuSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=s+4efNd8H1uAh3Tj8YjGIsTOvU4nP/o1woN97B1M2ou9igh7OBeAlzASA5ao+4k9aO z3TFF2wFswArvKUiu3fPBUTVeqI6qdlbDyT48zdCxuypplSehQ2EEkthWGCHU9vrBWIh 6eyhdbKiy2kbchfWivqAOiRf/VYE4/qiG2R6s= MIME-Version: 1.0 Received: by 10.224.28.213 with SMTP id n21mr1700055qac.64.1294890243527; Wed, 12 Jan 2011 19:44:03 -0800 (PST) Received: by 10.220.84.83 with HTTP; Wed, 12 Jan 2011 19:44:03 -0800 (PST) Date: Wed, 12 Jan 2011 22:44:03 -0500 Message-ID: From: Kyungsoo Lee To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: What is recommended wireless LAN card for FreeBSD TDMA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 04:14:47 -0000 Hello guys, I have used Proxim 8470 LAN cards. But I realized that this card is too old to use TDMA on FreeBSD. I need new wireless LAN cards which are supported by TDMA on FreeBSD and with an external port to connect directional antenna. Do you recommend any cards? Actually, it is hard to find wireless LAN cards with the conditions. Thanks, keiran From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 05:07: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 AFB921065670 for ; Thu, 13 Jan 2011 05:07:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 661A78FC0A for ; Thu, 13 Jan 2011 05:07:19 +0000 (UTC) Received: by gyf3 with SMTP id 3so538709gyf.13 for ; Wed, 12 Jan 2011 21:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ws7T771joSxGFli91bX3ljCDY0tRQ4ZrkbH0j5CJ+u0=; b=HWYK+zivubvGxZINFnXnj3Z6C4G9yCMwH2cxNbOG2i5odIgBuqBpFgnvzP7mZdrPeD Yp3YtdG6DKvvEhPaBiBaCg5ZArIykp1F4dXYz8TnnQ4PPzn+zVSm+6V9X8xcHA8dlpaX x3rD6Ea7PbqgF1ThTKdZy2sM9bVK1YfBLKkHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qu9x5bqS4Hvpp6JTFXrhCADJh+ftlwEKe/gjEiFjkwjTXsLcB5NZ01iH9jEbybKadQ 47aqic5ZCRUdE1n9W1IXuMsPcWMPxAO58NfBiW03FmlA/YJb20RwC/aABaMsKYxj40Ws 3SO6RdaGHQlYOUasOZEzRuUPZh1PciqVrVGn4= MIME-Version: 1.0 Received: by 10.236.109.1 with SMTP id r1mr4007918yhg.1.1294895238579; Wed, 12 Jan 2011 21:07:18 -0800 (PST) Received: by 10.147.182.20 with HTTP; Wed, 12 Jan 2011 21:07:18 -0800 (PST) In-Reply-To: <4D2E66C4.5090607@greatbaysoftware.com> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> Date: Wed, 12 Jan 2011 21:07:18 -0800 Message-ID: From: Jack Vogel To: Charles Owens Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Robin Sommer Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 05:07:19 -0000 The problem that Robin saw was due to having MSIX interrupts disabled on the system, I doubt that is going to be the "issue" for others. Get the latest version of the igb code and see if that helps you as a first step. Jack On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens wrote: > I'd like to report that we're running into this issue also, in our case on > systems that are based on the Intel S5520UR Server Board, running > 8.1-RELEASE. If the ichwd driver is loaded we see the same messages, and > network communication via the igb nics is non-functional. > > Have you had any luck? > > Thanks, > Charles > > Charles Owens > Great Bay Software, Inc. > > > > > On 1/3/11 4:02 PM, Robin Sommer wrote: > >> Hello all, >> >> quite a while ago I asked about the problem below. Unfortunately, I >> haven't found a solution yet and I'm actually still seeing these >> timeouts after just upgrading to 8.2-RC1. Any further ideas on what >> could be triggering them, or how I could track down the cause? >> >> Thanks, >> >> Robin >> >> On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: >> >> Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots of messages >>> like those below on all my SuperMicro SBI-7425C-T3 blades. There's >>> almost no traffic on those interfaces. >>> >>> Any idea? >>> >>> Thanks, >>> >>> Robin >>> >>> Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout -- resetting >>> Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256, hw tdt = 266 >>> Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail = 1013,Next TX to >>> Clean = 255 >>> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to DOWN >>> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP >>> Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout -- resetting >>> Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >>> Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to >>> Clean = 0 >>> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to DOWN >>> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP >>> Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout -- resetting >>> Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw tdt = 33 >>> Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail = 1022,Next TX to >>> Clean = 31 >>> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to DOWN >>> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP >>> Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout -- resetting >>> Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >>> Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to >>> Clean = 0 >>> Jul 29 13:01:57 blade0 kernel: igb1: link state changed to DOWN >>> Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP >>> Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout -- resetting >>> >>> grep igb /var/run/dmesg.boot >>>> >>> igb0: port >>> 0x2000-0x201f mem >>> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff irq 16 at >>> device 0.0 on pci4 >>> igb0: [FILTER] >>> igb0: Ethernet address: 00:30:48:9e:22:00 >>> igb1: port >>> 0x2020-0x203f mem >>> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff irq 17 at >>> device 0.1 on pci4 >>> igb1: [FILTER] >>> igb1: Ethernet address: 00:30:48:9e:22:01 >>> >>> pciconf -lv >>>> >>> [...] >>> igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 >>> chip=0x10a98086 rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82575EB Gigabit Backplane Connection' >>> class = network >>> subclass = ethernet >>> igb1@pci0:4:0:1: class=0x020000 card=0x10a915d9 >>> chip=0x10a98086 rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82575EB Gigabit Backplane Connection' >>> class = network >>> subclass = ethernet >>> [...] >>> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 05:38:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F58B106564A for ; Thu, 13 Jan 2011 05:38:52 +0000 (UTC) (envelope-from adrian.chadd@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 706F58FC08 for ; Thu, 13 Jan 2011 05:38:51 +0000 (UTC) Received: by wyf19 with SMTP id 19so1361984wyf.13 for ; Wed, 12 Jan 2011 21:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SdAvGgKUapZ8WXmq80OyN+q/vSmkcUk9TOEzPtvUWJs=; b=BzgdZKzNvzpG10EG7pL0ieOT9dCZsvTvMlOG0vSlWYVuq/DWgcrc+QeZgacjsiz6zs QELlFbjyywjmK59NfSch9vNmdKUeVwOhnIrlMjdvmYXBB7TtTAeF/Z10UJk26lIp3/E1 ncrexvHQkmuPvXjUjhXd6IhpNiuIX8lyhLOXc= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=mFTXKfZ2ZBiwVQ51e5nK8qRyijRtdkHt7Ay4pGUVFZjcEXiTmlEsr5194fLg+Ib2m6 lT9vGkcWu8KSPsuA3gMe1tVQL8TNBLu6N/G1Vjq3Ff08SzwVaOC5VboOQeEfyxHRhRLZ 5My1ZpIFcd7zE7ZG4fxnNTaPUDVxd33vbfRes= MIME-Version: 1.0 Received: by 10.216.182.212 with SMTP id o62mr251721wem.52.1294897130150; Wed, 12 Jan 2011 21:38:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.159.201 with HTTP; Wed, 12 Jan 2011 21:38:50 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 13:38:50 +0800 X-Google-Sender-Auth: DWVF2-wHMvL1RETDMobOO3sKJ1k Message-ID: From: Adrian Chadd To: Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-mips@freebsd.org Subject: Re: capturing packet from wlan0 with netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 05:38:52 -0000 Find out what the address is that's causing the problem. There's plenty of places where unaligned mbuf's exist in the IP code and aren't correctly realigned before being touched. MIPS people - is "address error" an alignment problem? Adrian On 30 December 2010 21:47, Monthadar Al Jaberi wrote: > Hi, > > I have an idea in my head and would like to know if it is possible. > > I want to simulate and test the net80211 mesh code in FreeBSD Current. > I have an RSPRO board with 3 atheros cards. > > My =A0basic idea is to run three jails each having its own network > stack, and redirect all data packets coming out/in of the wlan driver > to a Server running a home brew application that simulates the medium. > That would be great, right? Realtime unchanged code to test, running > different application in their own jails. > > So first I started to test netgraph with a simple test case, I want to > receive all packets from one wireless card and see the data in > wireshark or tcpdump... > > This is my netgraph code: > mkpeer wlan0: hub lower hook0 > name wlan0:lower hub > connect hub: wlan0: hook1 upper > connect hub: arge0: hook2 lower > > > So if I understood man ng_ether correct, this should capture > everything from wlan and redirect to ethernet cable. > > But I get a panic after a couple of seconds: > Trap cause =3D 4 (address error (load or I-fetch) - kernel mode) > [ thread pid 11 tid 100037 ] > Stopped at =A0 =A0 =A0ip_input+0xd8: =A0lw =A0 =A0 =A0v0,0(s0) > > I suspect that data flows to all hooks of the hub, and that is a bad > thing right? Need to create a special hub node to filter data? Or > maybe use two ethernet cables for out resp. in? > > Is it even possible to do what I want? Or am I thinking wrong? And is > there a simpler way? > > What I want is to test mesh code in a bunch of FreeBSD systems without > moving the hardware, one could just stack RSPROs and connected them a > big switch and a PC. > Hope was I clear in my thoughts. > > Best regards, > -- > //Monthadar Al Jaberi > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 06:45:03 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 DF5D0106564A; Thu, 13 Jan 2011 06:45:02 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 442C58FC08; Thu, 13 Jan 2011 06:45:01 +0000 (UTC) Received: by eyf6 with SMTP id 6so675821eyf.13 for ; Wed, 12 Jan 2011 22:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6SwdGsCOE3P16w/XiaUaju4YeDZtV5/eM8Qr+j904IU=; b=rLWGdF3NdViDNEWnzH9SK/wYRAZSfGHm5XCsImM6X10Dmdr4O/xwmo8tkDpHImnoUE q92Yy23D9QVKIKmctUkleFZn275H5FobmddkwUhoNn/goARFeF0l4mB0nMeG8O+9MpAT ZoD+cT8RtIP0xKhaMbjhB2QB+BmDjRYD2S8Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YYB5F+uRUGVcaOYz4HRw1UHtHbmx0SguC1H0B6GTJqo70Q9s8OJwCemwi+mHAGZ1SD Dr5qJGm/Jn2DcdLjJv9df7Bot4Bcmu+zMTH+C7V+8Y2QT5wuwcEf7YWzvP8NtBvnq3RG bMeV7O/RfoMl8e+p+GbAd9z5LeRQS3QGC0TeY= MIME-Version: 1.0 Received: by 10.213.104.136 with SMTP id p8mr1995934ebo.59.1294899444922; Wed, 12 Jan 2011 22:17:24 -0800 (PST) Received: by 10.213.36.17 with HTTP; Wed, 12 Jan 2011 22:17:24 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 11:47:24 +0530 Message-ID: From: "Jayachandran C." To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org, freebsd-mips@freebsd.org Subject: Re: capturing packet from wlan0 with netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 06:45:03 -0000 On Thu, Jan 13, 2011 at 11:08 AM, Adrian Chadd wrote: > Find out what the address is that's causing the problem. There's > plenty of places where unaligned mbuf's exist in the IP code and > aren't correctly realigned before being touched. > > MIPS people - is "address error" an alignment problem? Address error can be an alignment problem (or some other cases like accessing kernel address from userspace). But looking at the crash, it certainly seems like in ip_input, the line 435 if (ip->ip_v !=3D IPVERSION) { got a bad address for the ip pointer. The output of 'show registers' at the ddb prompt would be useful to debug further. > On 30 December 2010 21:47, Monthadar Al Jaberi wrot= e: >> Hi, >> >> I have an idea in my head and would like to know if it is possible. >> >> I want to simulate and test the net80211 mesh code in FreeBSD Current. >> I have an RSPRO board with 3 atheros cards. >> >> My =A0basic idea is to run three jails each having its own network >> stack, and redirect all data packets coming out/in of the wlan driver >> to a Server running a home brew application that simulates the medium. >> That would be great, right? Realtime unchanged code to test, running >> different application in their own jails. >> >> So first I started to test netgraph with a simple test case, I want to >> receive all packets from one wireless card and see the data in >> wireshark or tcpdump... >> >> This is my netgraph code: >> mkpeer wlan0: hub lower hook0 >> name wlan0:lower hub >> connect hub: wlan0: hook1 upper >> connect hub: arge0: hook2 lower >> >> >> So if I understood man ng_ether correct, this should capture >> everything from wlan and redirect to ethernet cable. >> >> But I get a panic after a couple of seconds: >> Trap cause =3D 4 (address error (load or I-fetch) - kernel mode) >> [ thread pid 11 tid 100037 ] >> Stopped at =A0 =A0 =A0ip_input+0xd8: =A0lw =A0 =A0 =A0v0,0(s0) >> >> I suspect that data flows to all hooks of the hub, and that is a bad >> thing right? Need to create a special hub node to filter data? Or >> maybe use two ethernet cables for out resp. in? >> >> Is it even possible to do what I want? Or am I thinking wrong? And is >> there a simpler way? >> >> What I want is to test mesh code in a bunch of FreeBSD systems without >> moving the hardware, one could just stack RSPROs and connected them a >> big switch and a PC. >> Hope was I clear in my thoughts. >> >> Best regards, >> -- >> //Monthadar Al Jaberi JC. From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 06: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 9E464106564A; Thu, 13 Jan 2011 06:53:36 +0000 (UTC) (envelope-from adrian.chadd@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 D86528FC15; Thu, 13 Jan 2011 06:53:35 +0000 (UTC) Received: by wyf19 with SMTP id 19so1403376wyf.13 for ; Wed, 12 Jan 2011 22:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NJn/IvrZfXUx2B0AXsFAhm4MlpGNT5zkzhUTqRgJjqA=; b=OjKLzfrTI2jl4XXsaWPa+nDW9bmhgXosqcBNy+ghTT7BpVJe8ihBee6ZPJwAcniKP4 bxpfvST4WdJ3yEkukDbH9/wzSxOeZOrLN0/2WuQqbzRLVdKqu6jB6iqaXYpi3kjF8Yz/ M1kGF5AN3ammss9L/sZC1KwVo7dgP8ZJUzHJs= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=fJqJl9U++kOpR9kJ84Kog+vP859eo/8KmwBTh6rbNrXwEvDfayux/NGU4Cm4eTIf7/ Mm18jS1n0Lk8rR3AhoFyDa3IapETffFo/sQl0I4lnadyGqdxxV/ziF8sfVzZ7xpR2HUI MUAZYy2XOfntc0NgYrY9bohNInYbU9l6LRSmI= MIME-Version: 1.0 Received: by 10.216.170.213 with SMTP id p63mr303558wel.37.1294901614574; Wed, 12 Jan 2011 22:53:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.159.201 with HTTP; Wed, 12 Jan 2011 22:53:34 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 14:53:34 +0800 X-Google-Sender-Auth: lkuBx-KCQ2qB8oqOx87nR5nbxpQ Message-ID: From: Adrian Chadd To: "Jayachandran C." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org, freebsd-mips@freebsd.org Subject: Re: capturing packet from wlan0 with netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 06:53:36 -0000 I've encountered this before. The mbuf's there aren't always aligned at this point. Adrian On 13 January 2011 14:17, Jayachandran C. wrote: > On Thu, Jan 13, 2011 at 11:08 AM, Adrian Chadd wrote= : >> Find out what the address is that's causing the problem. There's >> plenty of places where unaligned mbuf's exist in the IP code and >> aren't correctly realigned before being touched. >> >> MIPS people - is "address error" an alignment problem? > > Address error can be an alignment problem (or some other cases like > accessing kernel address from userspace). > > But looking at the crash, it certainly seems like in ip_input, the line > =A0 =A0 435 =A0 =A0 =A0 =A0 if (ip->ip_v !=3D IPVERSION) { > > got a bad address for the ip pointer. > > The output of 'show registers' at the ddb prompt would be useful to > debug further. > > >> On 30 December 2010 21:47, Monthadar Al Jaberi wro= te: >>> Hi, >>> >>> I have an idea in my head and would like to know if it is possible. >>> >>> I want to simulate and test the net80211 mesh code in FreeBSD Current. >>> I have an RSPRO board with 3 atheros cards. >>> >>> My =A0basic idea is to run three jails each having its own network >>> stack, and redirect all data packets coming out/in of the wlan driver >>> to a Server running a home brew application that simulates the medium. >>> That would be great, right? Realtime unchanged code to test, running >>> different application in their own jails. >>> >>> So first I started to test netgraph with a simple test case, I want to >>> receive all packets from one wireless card and see the data in >>> wireshark or tcpdump... >>> >>> This is my netgraph code: >>> mkpeer wlan0: hub lower hook0 >>> name wlan0:lower hub >>> connect hub: wlan0: hook1 upper >>> connect hub: arge0: hook2 lower >>> >>> >>> So if I understood man ng_ether correct, this should capture >>> everything from wlan and redirect to ethernet cable. >>> >>> But I get a panic after a couple of seconds: >>> Trap cause =3D 4 (address error (load or I-fetch) - kernel mode) >>> [ thread pid 11 tid 100037 ] >>> Stopped at =A0 =A0 =A0ip_input+0xd8: =A0lw =A0 =A0 =A0v0,0(s0) >>> >>> I suspect that data flows to all hooks of the hub, and that is a bad >>> thing right? Need to create a special hub node to filter data? Or >>> maybe use two ethernet cables for out resp. in? >>> >>> Is it even possible to do what I want? Or am I thinking wrong? And is >>> there a simpler way? >>> >>> What I want is to test mesh code in a bunch of FreeBSD systems without >>> moving the hardware, one could just stack RSPROs and connected them a >>> big switch and a PC. >>> Hope was I clear in my thoughts. >>> >>> Best regards, >>> -- >>> //Monthadar Al Jaberi > > JC. > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 07:23: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 84E6910656A6 for ; Thu, 13 Jan 2011 07:23:12 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1DD0C8FC0A for ; Thu, 13 Jan 2011 07:23:11 +0000 (UTC) Received: by fxm16 with SMTP id 16so1463245fxm.13 for ; Wed, 12 Jan 2011 23:23:11 -0800 (PST) Received: by 10.223.106.129 with SMTP id x1mr1989582fao.13.1294903391008; Wed, 12 Jan 2011 23:23:11 -0800 (PST) Received: from jessie.localnet (p5B2EC422.dip0.t-ipconnect.de [91.46.196.34]) by mx.google.com with ESMTPS id o17sm510210fal.1.2011.01.12.23.23.08 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 23:23:09 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Kyungsoo Lee Date: Thu, 13 Jan 2011 08:23:10 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-27-generic; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101130823.10782.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: What is recommended wireless LAN card for FreeBSD TDMA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bschmidt@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 07:23:12 -0000 On Thursday, January 13, 2011 04:44:03 Kyungsoo Lee wrote: > Hello guys, > > I have used Proxim 8470 LAN cards. But I realized that this card is too old > to use TDMA on FreeBSD. I need new wireless LAN cards which are supported > by TDMA on FreeBSD and with an external port to connect directional > antenna. Do you recommend any cards? Actually, it is hard to find wireless > LAN cards with the conditions. Afaik TDMA was implemented on and for ath(4) only. You might want to try to obtain either a Ubiquiti SR2 or a Wistron CM9, those should do. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 08:25: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 D75FC1065726; Thu, 13 Jan 2011 08:25:18 +0000 (UTC) (envelope-from monthadar@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 565438FC12; Thu, 13 Jan 2011 08:25:18 +0000 (UTC) Received: by qyk8 with SMTP id 8so4412805qyk.13 for ; Thu, 13 Jan 2011 00:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D6gqHNjCF05Pgg0I+JuVuC4Wr2iBk5kDJIRE8cq+l2o=; b=VVsHv+tlspkkc85D9BAFG4zfrlNi/ESUWWFuYm1zm9IzWs3YHbTQu4xbgWiuq49oLz +rDaDWc1xry+H9Y5j6d3V+n1VsERM5QJLWAhi6czdNCeTMLST9HAt1oi6cAMXdlYvdS0 5v2QS82RQ7jBYfoA8CU+rMd7YhJB39SdIBnhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j0fe2TpZMERICYwh/Ud6DAaceUpfzMhHtKeV83H02UN6sXafyjutl51UCQL1QzIbRQ s2SzykP4R3cBUf8C931+TsNUpa553Ik5qiJcZ/S8Ehf13qZDm+YL+J9lLpixcz+vwJq/ MmL2fGvl2Rn4qBtroDawGpEIjpfXM5vq8QXBI= MIME-Version: 1.0 Received: by 10.229.212.133 with SMTP id gs5mr1734391qcb.192.1294907117417; Thu, 13 Jan 2011 00:25:17 -0800 (PST) Received: by 10.229.249.14 with HTTP; Thu, 13 Jan 2011 00:25:17 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 09:25:17 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-mips@freebsd.org, "Jayachandran C." Subject: Re: capturing packet from wlan0 with netgraph? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 08:25:18 -0000 sorry but I have not worked with this for a while now, After some thoughts I dont think using netgraph will do me any good, because traffic can still flow through the antennas of the cards. If you think it would still be useful to see more ddb prompt for other scenarios I am happy to try and supply that, but I won't have some free time until late tomorrow :) thnx again! On Thu, Jan 13, 2011 at 7:53 AM, Adrian Chadd wrote: > I've encountered this before. > > The mbuf's there aren't always aligned at this point. > > > > Adrian > > On 13 January 2011 14:17, Jayachandran C. wrot= e: >> On Thu, Jan 13, 2011 at 11:08 AM, Adrian Chadd wrot= e: >>> Find out what the address is that's causing the problem. There's >>> plenty of places where unaligned mbuf's exist in the IP code and >>> aren't correctly realigned before being touched. >>> >>> MIPS people - is "address error" an alignment problem? >> >> Address error can be an alignment problem (or some other cases like >> accessing kernel address from userspace). >> >> But looking at the crash, it certainly seems like in ip_input, the line >> =A0 =A0 435 =A0 =A0 =A0 =A0 if (ip->ip_v !=3D IPVERSION) { >> >> got a bad address for the ip pointer. >> >> The output of 'show registers' at the ddb prompt would be useful to >> debug further. >> >> >>> On 30 December 2010 21:47, Monthadar Al Jaberi wr= ote: >>>> Hi, >>>> >>>> I have an idea in my head and would like to know if it is possible. >>>> >>>> I want to simulate and test the net80211 mesh code in FreeBSD Current. >>>> I have an RSPRO board with 3 atheros cards. >>>> >>>> My =A0basic idea is to run three jails each having its own network >>>> stack, and redirect all data packets coming out/in of the wlan driver >>>> to a Server running a home brew application that simulates the medium. >>>> That would be great, right? Realtime unchanged code to test, running >>>> different application in their own jails. >>>> >>>> So first I started to test netgraph with a simple test case, I want to >>>> receive all packets from one wireless card and see the data in >>>> wireshark or tcpdump... >>>> >>>> This is my netgraph code: >>>> mkpeer wlan0: hub lower hook0 >>>> name wlan0:lower hub >>>> connect hub: wlan0: hook1 upper >>>> connect hub: arge0: hook2 lower >>>> >>>> >>>> So if I understood man ng_ether correct, this should capture >>>> everything from wlan and redirect to ethernet cable. >>>> >>>> But I get a panic after a couple of seconds: >>>> Trap cause =3D 4 (address error (load or I-fetch) - kernel mode) >>>> [ thread pid 11 tid 100037 ] >>>> Stopped at =A0 =A0 =A0ip_input+0xd8: =A0lw =A0 =A0 =A0v0,0(s0) >>>> >>>> I suspect that data flows to all hooks of the hub, and that is a bad >>>> thing right? Need to create a special hub node to filter data? Or >>>> maybe use two ethernet cables for out resp. in? >>>> >>>> Is it even possible to do what I want? Or am I thinking wrong? And is >>>> there a simpler way? >>>> >>>> What I want is to test mesh code in a bunch of FreeBSD systems without >>>> moving the hardware, one could just stack RSPROs and connected them a >>>> big switch and a PC. >>>> Hope was I clear in my thoughts. >>>> >>>> Best regards, >>>> -- >>>> //Monthadar Al Jaberi >> >> JC. >> > --=20 //Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 09:40: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 89CD41065672 for ; Thu, 13 Jan 2011 09:40:50 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 465108FC0A for ; Thu, 13 Jan 2011 09:40:49 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 4B42F13DF5F; Thu, 13 Jan 2011 12:40:48 +0300 (MSK) Date: Thu, 13 Jan 2011 12:40:45 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1902620205.20110113124045@serebryakov.spb.ru> To: Artem Belevich In-Reply-To: References: <36074996.20110112192009@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:40:50 -0000 Hello, Artem. You wrote 12 =FF=ED=E2=E0=F0=FF 2011 =E3., 23:59:58: >> =A0I've documented this new tunable in re(4) manpage, as here is no >> rgephy(4) manpage. > I wonder if we could make autonegotiation another media option. > This may solve the problem at hand in a more generic way. It is better way, of course, but I'm not feel competent enough for such changes. > In case someone specifies speed/duplex settings but want > autonegotiation on, we can advertise only that particular speed/duplex > capability (as opposed to advertising everything we support). This It is exactly as re/rgephy wroks now -- autonegotiation with limited capabilities. > would force remote end to either establish the link with the > parameters we want or keep the link down which would be better than > keeping the link up with mismatched duplex settings. In case, when remote end SUPPORTS autonegotiation ;-) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 09:49:06 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 79DBB1065674 for ; Thu, 13 Jan 2011 09:49:06 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 37A778FC15 for ; Thu, 13 Jan 2011 09:49:06 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 4A06113DF61; Thu, 13 Jan 2011 12:49:05 +0300 (MSK) Date: Thu, 13 Jan 2011 12:49:02 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <109705248.20110113124902@serebryakov.spb.ru> To: Pyun YongHyeon In-Reply-To: <20110112213208.GD12920@michelle.cdnetworks.com> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:49:06 -0000 Hello, Pyun. You wrote 13 =FF=ED=E2=E0=F0=FF 2011 =E3., 0:32:08: > seemed to address the issue at that time. 1000baseT link always > requires auto-negotiation but too many switches were broken with > auto-negotiation so some switches are forced to use manual media > configuration even in 1000baseT mode. Using auto-negotiation on > rgephy(4) will also solve that case. Please note, my patch doesn't affect 1Gig case at all, I understand, that 1Gig REQUIRES autonegotiation. > I'm under the impression that rgephy(4)'s behavior seem to confuse > users a lot since it unconditionally use auto-negotiation so I > think it's better not to use auto-negotiation at all during manual > media configuration and provides a way to use auto-negotiation in > manual media configuration if administrator want to do that. So, invert meaning (and name) of tunable? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 09:54:34 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 1136B106564A for ; Thu, 13 Jan 2011 09:54:34 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id C12F48FC0C for ; Thu, 13 Jan 2011 09:54:33 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id CB5BF13DF5F; Thu, 13 Jan 2011 12:54:32 +0300 (MSK) Date: Thu, 13 Jan 2011 12:54:29 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <86656486.20110113125429@serebryakov.spb.ru> To: Marius Strobl In-Reply-To: <20110112225907.GA44318@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Pyun YongHyeon , freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:54:34 -0000 Hello, Marius. You wrote 13 =FF=ED=E2=E0=F0=FF 2011 =E3., 1:59:07: > Note that even the RealTek supplied driver always triggers an > auto-negotiation when manually setting the media though. However, > at the same time it also comes with tons of uncommented PHY fix-up > code which might be relevant for this or the previous issue. One think I'm sure, that "mii-tool" on Linux helps now, and "ifconfig media / mediaopt" doesn't (without this patch & turned on option), so it seems, that Linux turn autonegotiation off when media is set manually. And, yes, without manual setting media (with autonegatiotion) Linux has same problem -- half/full duplex mismatch. > Unfortunately, I didn't get to checking whether the MAC versions > in question are amongst the ones that get patched so far. > In any case I don't think we can easily change this (default) > behavior after such a relatively long time as it would break POLA > for an unknown number of users, even if it probably shouldn't have > been made the default in the first place (but again on the other It is why I do option in such way, that old users, for whom current implementation works, doesn't notice any difference -- rgephy works exactly the same way as usual untill you set option. And, yes, I think, that additional media option will be better, but it looks like major feature and not small patch :) --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 10:06: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 84A9F106566C; Thu, 13 Jan 2011 10:06:26 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6148FC0A; Thu, 13 Jan 2011 10:06: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 p0DA6QZd098206; Thu, 13 Jan 2011 10:06:26 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0DA6QC0098202; Thu, 13 Jan 2011 10:06:26 GMT (envelope-from linimon) Date: Thu, 13 Jan 2011 10:06:26 GMT Message-Id: <201101131006.p0DA6QC0098202@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153936: [ixgbe] [patch] MPRC workaround incorrectly applied to 82599 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:06:26 -0000 Synopsis: [ixgbe] [patch] MPRC workaround incorrectly applied to 82599 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 13 10:06:05 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153936 From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 10:07:22 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB8F1065693; Thu, 13 Jan 2011 10:07:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C13B48FC1A; Thu, 13 Jan 2011 10:07:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0DA7Mdi098306; Thu, 13 Jan 2011 10:07:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0DA7Mx9098302; Thu, 13 Jan 2011 10:07:22 GMT (envelope-from linimon) Date: Thu, 13 Jan 2011 10:07:22 GMT Message-Id: <201101131007.p0DA7Mx9098302@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153937: [ral] ralink panics the system (amd64 freeBSDD 8.X) when in hostap or adhoc. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:07:23 -0000 Old Synopsis: ralink (if_ral) panics the sistem (amd64 freeBSDd 8.X) when in hostap or adhoc. New Synopsis: [ral] ralink panics the system (amd64 freeBSDD 8.X) when in hostap or adhoc. Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 13 10:06:50 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153937 From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 10:07:57 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 6EDE51065675; Thu, 13 Jan 2011 10:07:57 +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 45CE38FC17; Thu, 13 Jan 2011 10:07:57 +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 p0DA7vQk098362; Thu, 13 Jan 2011 10:07:57 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0DA7vqO098358; Thu, 13 Jan 2011 10:07:57 GMT (envelope-from linimon) Date: Thu, 13 Jan 2011 10:07:57 GMT Message-Id: <201101131007.p0DA7vqO098358@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free 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: Thu, 13 Jan 2011 10:07:57 -0000 Synopsis: [run] [panic] [patch] Workaround for use-after-free panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 13 10:07:38 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153938 From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 12:51: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 5AFBA1065670 for ; Thu, 13 Jan 2011 12:51:47 +0000 (UTC) (envelope-from ulsanrub@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 0BF4E8FC12 for ; Thu, 13 Jan 2011 12:51:46 +0000 (UTC) Received: by qwj9 with SMTP id 9so1677333qwj.13 for ; Thu, 13 Jan 2011 04:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FQYK689u95yUmIWnKIdFlkkA8u4r/UxFx54gPLsG2Zc=; b=JjJigKwqadjk0ST5kXqNhJgo/PjQn+xyDX+ib6xuA5Q6d9jiMbp8EOBS7j0/+PXdnv m/bE4VnZhF1AXeqihw4Zc9mVSisuJljgkN11TvsIIgNo3bNoTQ4IfB2Ktc9fqxSbq/sA ffnlQwzgVhyCEUdnJ02jZy2x9FGhqXL2Ytn0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wgc8ZkYQLzeH79+w5Me0tgeqdYx/qQ/N8TEcWeZaU9h7nw8JLA5eO1ja6DJYhRdAkR GyRSRif3ovDqY1VlGi7bLYGHFd4WF+dqU+ftv13R/b+dh00QH2Sem0dR8xsnelSmDnsa p+TG1x8asjB0owAfymX8ghifOXNuqlTGQXFq8= MIME-Version: 1.0 Received: by 10.229.79.12 with SMTP id n12mr1944945qck.129.1294923106170; Thu, 13 Jan 2011 04:51:46 -0800 (PST) Received: by 10.220.84.83 with HTTP; Thu, 13 Jan 2011 04:51:46 -0800 (PST) In-Reply-To: <201101130823.10782.bschmidt@freebsd.org> References: <201101130823.10782.bschmidt@freebsd.org> Date: Thu, 13 Jan 2011 07:51:46 -0500 Message-ID: From: Kyungsoo Lee To: bschmidt@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: Re: What is recommended wireless LAN card for FreeBSD TDMA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 12:51:47 -0000 Thank you for your responses. I'm sorry that I forgot another condition. I need PCMCIA cards for laptops. Could you recommend any PCMCIA cards with external port supported by FreeBSD TDMA? Keiran On Thu, Jan 13, 2011 at 2:23 AM, Bernhard Schmidt wrote: > On Thursday, January 13, 2011 04:44:03 Kyungsoo Lee wrote: > > Hello guys, > > > > I have used Proxim 8470 LAN cards. But I realized that this card is too > old > > to use TDMA on FreeBSD. I need new wireless LAN cards which are supported > > by TDMA on FreeBSD and with an external port to connect directional > > antenna. Do you recommend any cards? Actually, it is hard to find > wireless > > LAN cards with the conditions. > > Afaik TDMA was implemented on and for ath(4) only. > You might want to try to obtain either a Ubiquiti SR2 or a Wistron CM9, > those > should do. > > -- > Bernhard > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 13:52: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 472CE106566C; Thu, 13 Jan 2011 13:52:30 +0000 (UTC) (envelope-from batcilla@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 DB7BD8FC14; Thu, 13 Jan 2011 13:52:29 +0000 (UTC) Received: by qyk36 with SMTP id 36so1719403qyk.13 for ; Thu, 13 Jan 2011 05:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5TS54wXOhxfvdq7BzuQjYKWsaYeWyciyuzmhnNxLz5E=; b=GeAiqGFgiKv9E6Trl3dhRTgj5ogRoEn0s56Foiyr+EAJ1SkcWUsm0IZ7aCbr3Pc5Uo A8HBezdq8Mkw9c2kSGimQyyVC8MvfhDJPygrcOn6NmD7MIswdeOSZP8d9zxomlInYtxr QphjPeTsFnSYWitWEqUKRUYFtpiyVjWV9S4gA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Qrb0zlCrfl5AFVc6aMUphFL9A/oPeMwCcRL6wrHQi4rKg72KGnhrufkwK/SPOe4WPF mzcOp5NlxIF++aYPHoKZBvYUbmTEpwvkldSA6O5zFQ0WX3VaofWleNAQINxoIhhZviqS fARPZIeXPZgz6W2UvxYqBCOhdGMet1eb4n+1Y= MIME-Version: 1.0 Received: by 10.229.229.203 with SMTP id jj11mr1987923qcb.160.1294924866865; Thu, 13 Jan 2011 05:21:06 -0800 (PST) Received: by 10.229.239.8 with HTTP; Thu, 13 Jan 2011 05:21:06 -0800 (PST) In-Reply-To: References: <201101130823.10782.bschmidt@freebsd.org> Date: Thu, 13 Jan 2011 15:21:06 +0200 Message-ID: From: batcilla itself To: Kyungsoo Lee Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, bschmidt@freebsd.org Subject: Re: What is recommended wireless LAN card for FreeBSD TDMA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 13:52:30 -0000 Greetings Both XR2 and CM9 are old card and not supported by TDMA. I believe there is no option for PCMCIA at all, for the miniPCI - you can use DCMA-82, Mikrotik R52, anything atheros 5414 and more recent chipsets. In Sam Leffler's presentations mentioned, that DCMA-82 was used. //batcilla 2011/1/13 Kyungsoo Lee > Thank you for your responses. > > I'm sorry that I forgot another condition. I need PCMCIA cards for laptops. > Could you recommend any PCMCIA cards with external port supported by > FreeBSD > TDMA? > > Keiran > > On Thu, Jan 13, 2011 at 2:23 AM, Bernhard Schmidt >wrote: > > > On Thursday, January 13, 2011 04:44:03 Kyungsoo Lee wrote: > > > Hello guys, > > > > > > I have used Proxim 8470 LAN cards. But I realized that this card is too > > old > > > to use TDMA on FreeBSD. I need new wireless LAN cards which are > supported > > > by TDMA on FreeBSD and with an external port to connect directional > > > antenna. Do you recommend any cards? Actually, it is hard to find > > wireless > > > LAN cards with the conditions. > > > > Afaik TDMA was implemented on and for ath(4) only. > > You might want to try to obtain either a Ubiquiti SR2 or a Wistron CM9, > > those > > should do. > > > > -- > > Bernhard > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 14:16: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 8745D1065694 for ; Thu, 13 Jan 2011 14:16:55 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id D93318FC1A for ; Thu, 13 Jan 2011 14:16:54 +0000 (UTC) Received: (qmail 33948 invoked from network); 13 Jan 2011 14:16:52 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Jan 2011 14:16:52 -0000 Date: Thu, 13 Jan 2011 15:16:52 +0100 (CET) Message-Id: <20110113.151652.104127547.sthaug@nethelp.no> To: freebsd-net@freebsd.org, freebsd-current@freebsd.org From: sthaug@nethelp.no X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 14:16:55 -0000 I have a server with an Intel X520-LR1 Ethernet card, which is a 10GBase-LR card: http://ark.intel.com/Product.aspx?id=41164 The card contains the Intel 82599ES controller: http://ark.intel.com/Product.aspx?id=41282 pciconf -lv shows: ix0@pci0:28:0:0: class=0x020000 card=0x00068086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet where /sys/dev/ixgbe/ixgbe_type.h has the PCI ID definition: #define IXGBE_DEV_ID_82599_SFP 0x10FB The problem is that this card is shown by ifconfig as a 10GBase-SR card: % ifconfig ix0 ix0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1b:21:7c:7b:94 media: Ethernet autoselect (10Gbase-SR ) status: active I believe this is due to the following code in /sys/dev/ixgbe/ixgbe.c line 423, routine ixgbe_attach(): case IXGBE_DEV_ID_82599_SFP: adapter->optics = IFM_10G_SR; I'm looking at version 1.17.2.12.2.1, from 8.2-RC1, but I see this code is the same in version 1.45, from HEAD: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.45;content-type=text/plain I made a 1-line patch to the 8.2-RC1 code, enclosed below, and now have ifconfig showing the expected value: y% ifconfig ix0 ix0: flags=8843 metric 0 mtu 1500 options=1bb ether 00:1b:21:7c:7b:94 media: Ethernet autoselect (10Gbase-LR ) status: active Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- --- ixgbe.c.orig 2010-12-21 18:09:25.000000000 +0100 +++ ixgbe.c 2011-01-13 14:31:14.000000000 +0100 @@ -421,7 +421,7 @@ adapter->optics = IFM_10G_LR; break; case IXGBE_DEV_ID_82599_SFP: - adapter->optics = IFM_10G_SR; + adapter->optics = IFM_10G_LR; ixgbe_num_segs = IXGBE_82599_SCATTER; break; case IXGBE_DEV_ID_82598_DA_DUAL_PORT : From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 14:36:32 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 3E3401065672 for ; Thu, 13 Jan 2011 14:36:32 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 761BA8FC26 for ; Thu, 13 Jan 2011 14:36:30 +0000 (UTC) Received: (qmail 37815 invoked from network); 13 Jan 2011 14:36:29 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Jan 2011 14:36:29 -0000 Date: Thu, 13 Jan 2011 15:36:29 +0100 (CET) Message-Id: <20110113.153629.78802000.sthaug@nethelp.no> To: freebsd-net@freebsd.org, freebsd-current@freebsd.org From: sthaug@nethelp.no In-Reply-To: <20110113.151652.104127547.sthaug@nethelp.no> References: <20110113.151652.104127547.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 14:36:32 -0000 > I have a server with an Intel X520-LR1 Ethernet card, which is a > 10GBase-LR card: ... > The problem is that this card is shown by ifconfig as a 10GBase-SR card: ... > I made a 1-line patch to the 8.2-RC1 code, enclosed below, and now have > ifconfig showing the expected value: Problem report and patch now available as kern/153951. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 15:56:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0D810656AD for ; Thu, 13 Jan 2011 15:56:56 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id DB9A98FC41 for ; Thu, 13 Jan 2011 15:56:48 +0000 (UTC) Received: from jack.bspruce.com ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Thu, 13 Jan 2011 10:56:43 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4D2F20BB.5080204@greatbaysoftware.com> Date: Thu, 13 Jan 2011 10:56:43 -0500 From: Charles Owens MIME-Version: 1.0 To: Jack Vogel References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> In-Reply-To: X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Robin Sommer Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 15:56:56 -0000 Ok... I got my wires crossed: our first time testing 8.1 on this particular platform was with a kernel that had ichwd enabled (a new thing for us) and so when igb started complaining about "watchdog" we thought it was related. We've tested again and clearly the real story is that we're simply seeing igb issues, symptoms similar to those described. Does 8.2-RC1 have sufficiently "latest" code, or should I be looking to load up something else? (8-stable, maybe?) Thanks, Charles On 1/13/11 12:07 AM, Jack Vogel wrote: > The problem that Robin saw was due to having MSIX interrupts disabled > on the system, I doubt that > is going to be the "issue" for others. > > Get the latest version of the igb code and see if that helps you as a > first step. > > Jack > > > On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens > > wrote: > > I'd like to report that we're running into this issue also, in our > case on systems that are based on the Intel S5520UR Server Board, > running 8.1-RELEASE. If the ichwd driver is loaded we see the > same messages, and network communication via the igb nics is > non-functional. > > Have you had any luck? > > Thanks, > Charles > > Charles Owens > Great Bay Software, Inc. > > > > > On 1/3/11 4:02 PM, Robin Sommer wrote: > > Hello all, > > quite a while ago I asked about the problem below. > Unfortunately, I > haven't found a solution yet and I'm actually still seeing these > timeouts after just upgrading to 8.2-RC1. Any further ideas on > what > could be triggering them, or how I could track down the cause? > > Thanks, > > Robin > > On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: > > Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots > of messages > like those below on all my SuperMicro SBI-7425C-T3 blades. > There's > almost no traffic on those interfaces. > > Any idea? > > Thanks, > > Robin > > Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout -- > resetting > Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256, > hw tdt = 266 > Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail = > 1013,Next TX to Clean = 255 > Jul 29 13:01:18 blade0 kernel: igb1: link state changed to > DOWN > Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP > Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout -- > resetting > Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw > tdt = 10 > Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail = > 1014,Next TX to Clean = 0 > Jul 29 13:01:29 blade0 kernel: igb1: link state changed to > DOWN > Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP > Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout -- > resetting > Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw > tdt = 33 > Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail = > 1022,Next TX to Clean = 31 > Jul 29 13:01:46 blade0 kernel: igb1: link state changed to > DOWN > Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP > Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout -- > resetting > Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw > tdt = 10 > Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail = > 1014,Next TX to Clean = 0 > Jul 29 13:01:57 blade0 kernel: igb1: link state changed to > DOWN > Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP > Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout -- > resetting > > grep igb /var/run/dmesg.boot > > igb0: 1.9.5> port 0x2000-0x201f mem > 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff > irq 16 at device 0.0 on pci4 > igb0: [FILTER] > igb0: Ethernet address: 00:30:48:9e:22:00 > igb1: 1.9.5> port 0x2020-0x203f mem > 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff > irq 17 at device 0.1 on pci4 > igb1: [FILTER] > igb1: Ethernet address: 00:30:48:9e:22:01 > > pciconf -lv > > [...] > igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 > chip=0x10a98086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Backplane Connection' > class = network > subclass = ethernet > igb1@pci0:4:0:1: class=0x020000 card=0x10a915d9 > chip=0x10a98086 rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82575EB Gigabit Backplane Connection' > class = network > subclass = ethernet > [...] > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org > " > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 17:39: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 0F3CE1065670 for ; Thu, 13 Jan 2011 17:39:28 +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 618888FC16 for ; Thu, 13 Jan 2011 17:39:26 +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 p0DHdPWe049419; Thu, 13 Jan 2011 18:39:26 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p0DHdP5r049418; Thu, 13 Jan 2011 18:39:25 +0100 (CET) (envelope-from marius) Date: Thu, 13 Jan 2011 18:39:25 +0100 From: Marius Strobl To: Pyun YongHyeon Message-ID: <20110113173925.GA49356@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110112225907.GA44318@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 17:39:28 -0000 On Wed, Jan 12, 2011 at 11:59:07PM +0100, Marius Strobl wrote: > On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote: > > On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote: > > > Hello, Freebsd-net. > > > > > > Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > > > with re(4) does autonegotiation always and all other, who helps me > > > diagnose problem! > > > > > > I've prepared patch, which adds tunable/sysctl for rgephy(4) which > > > allows not to sue autonegotiation by this PHY (at user responsibility, > > > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > > > by default, and in such case behavior of driver IS NOT CHANGED. > > > > > > But if it is set ON (non-zero value) before "media / mediopt" > > > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > > > settings. > > > > > > I've documented this new tunable in re(4) manpage, as here is no > > > rgephy(4) manpage. > > > > > > Tunable is per-device, not global one. > > > > > > Sysctl can be set after boot, but will affect only future ifconfig > > > calls, it doesn't change anything in PHY settings by itself. > > > > > > It allows fully manual setup on non-buggy hardware, which allows to > > > use Hetzner dedicated servers with FreeBSD without additional NIC or > > > gigabit connection. > > > > > > I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it > > > allows me to get full-duplex 100Mbit connection and I got 11MiB/s from > > > local NFS with it. > > > > > > Without this patch FreeBSD is unusable on Hetzner dedicated servers > > > in newer DCs (DC 13 and DC 14). > > > > > > Patch is attached. I think, it worths to include it to base system, > > > as it allows use FreeBSD at least on one very large and popular > > > hosting provider without additional costs :) > > > > > > > Thanks for your work. After reading commit log of rgephy(4) I now > > refreshed my memory. The issue came from the reverse usage case. > > Suppose link partner announces auto-negotiation but you want to use > > 100baseTX/full-duplex. As you know this results in duplex mismatch > > and sometimes it couldn't establish a link on some RealTek PHYs. > > (Now I'm not entirely sure it was caused by the specific switch or > > rgephy(4) or both) > > And frequently, link partner(switch) is out of control from your > > domain and most switches are configured to use auto-negotiation by > > default. Using auto-negotiation in manual media configuration > > seemed to address the issue at that time. 1000baseT link always > > requires auto-negotiation but too many switches were broken with > > auto-negotiation so some switches are forced to use manual media > > configuration even in 1000baseT mode. Using auto-negotiation on > > rgephy(4) will also solve that case. > > > > So I have mixed feelings on how to handle both cases. Traditional > > way, which your patch does, used in manual configuration was to > > strictly honor specified manual media configuration even if it can > > break in some edge cases. Programming PHYs with traditional way > > shall also trigger other problems to drivers which correctly keep > > track of valid link state changes. Normally speed/duplex/flow-control > > changes require MAC reprogramming such that monitoring PHY's state > > change is essential to modern ethernet controllers. Forcing manual > > media configuration can make PHY drivers fail to report link state > > changes which in turn shall make ethernet controller not to work > > due to speed/duplex mismatches between PHY and MAC of ethernet > > controller. re(4) does not require MAC reprogramming but many other > > drivers that use regephy(4) may not work. However regphy(4) > > hardware I have still seem to correctly report link state change > > with manual link configuration. Not sure about old controllers > > though. > > > > I'm under the impression that rgephy(4)'s behavior seem to confuse > > users a lot since it unconditionally use auto-negotiation so I > > think it's better not to use auto-negotiation at all during manual > > media configuration and provides a way to use auto-negotiation in > > manual media configuration if administrator want to do that. > > Note that even the RealTek supplied driver always triggers an > auto-negotiation when manually setting the media though. However, > at the same time it also comes with tons of uncommented PHY fix-up > code which might be relevant for this or the previous issue. > Unfortunately, I didn't get to checking whether the MAC versions > in question are amongst the ones that get patched so far. > In any case I don't think we can easily change this (default) > behavior after such a relatively long time as it would break POLA > for an unknown number of users, even if it probably shouldn't have > been made the default in the first place (but again on the other > hand that's what RealTek themselves also chose to do). Also apart > from edges cases like the current issue the present behavior should > result in a setup that "just works" so I doubt it actually results > in confusion. > Independently of DSP fixes that might or might not fixes these issues I agree that there should be a way to turn off the use of auto-negotiation along with manual media configuration in rgephy(4) though. IMO there are some bugs and issues with the patch provided by Lev however: - It fails to reject enabling of PAUSE advertisement when not using auto-negotiation. - It has no effect on 1000base-T; as you pointed out some switches also require manual selection (without auto-negotiation) here as a workaround. - I don't like the idea of growing a tunable when the same can be achieved via ifmedia support. Therefore I'd like to commit the following patch (requires sources from head and stable branches), unless there's an objection or it doesn't work as expected: http://people.freebsd.org/~marius/rgephy.c.diff With this in place you should be able to manually set full-duplex with auto-negotiation turned off via: ifconfig re0 media 100baseTX mediaopt full-duplex,flag0 A full list of what that patch does is: - Allow IFM_FLAG0 to be set indicating that auto-negotiation with manual configuration, which is used to work around issues with certain setups (see r161237) by default, should not be triggered as it may in turn cause harm in some edge cases. - Even after masking the media with IFM_GMASK the result may have bits besides the duplex ones set so just comparing it with IFM_FDX may lead to false negatives. - Announce PAUSE support also for manually selected 1000BASE-T, but for all manually selected media types only in full-duplex mode. Announce asymmetric PAUSE support only for manually selected 1000BASE-T. - Simplify setting the manual configuration bits to only once after we have figured them all out. This also means we no longer unnecessarily update the hardware along the road. - Remove a stale comment. Marius From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 17:41: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 A3305106564A for ; Thu, 13 Jan 2011 17:41:26 +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 1C14A8FC1A for ; Thu, 13 Jan 2011 17:41:25 +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 p0DHfPlX049446; Thu, 13 Jan 2011 18:41:25 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p0DHfOh4049445; Thu, 13 Jan 2011 18:41:24 +0100 (CET) (envelope-from marius) Date: Thu, 13 Jan 2011 18:41:24 +0100 From: Marius Strobl To: Lev Serebryakov Message-ID: <20110113174124.GJ97101@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <86656486.20110113125429@serebryakov.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86656486.20110113125429@serebryakov.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Pyun YongHyeon , freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 17:41:26 -0000 On Thu, Jan 13, 2011 at 12:54:29PM +0300, Lev Serebryakov wrote: > Hello, Marius. > You wrote 13 ?????? 2011 ?., 1:59:07: > > > Note that even the RealTek supplied driver always triggers an > > auto-negotiation when manually setting the media though. However, > > at the same time it also comes with tons of uncommented PHY fix-up > > code which might be relevant for this or the previous issue. > One think I'm sure, that "mii-tool" on Linux helps now, and > "ifconfig media / mediaopt" doesn't (without this patch & turned on > option), so it seems, that Linux turn autonegotiation off when media > is set manually. > And, yes, without manual setting media (with autonegatiotion) Linux > has same problem -- half/full duplex mismatch. I was talking about the driver RealTek provides on their homepage for FreeBSD, not Linux. > > > Unfortunately, I didn't get to checking whether the MAC versions > > in question are amongst the ones that get patched so far. > > In any case I don't think we can easily change this (default) > > behavior after such a relatively long time as it would break POLA > > for an unknown number of users, even if it probably shouldn't have > > been made the default in the first place (but again on the other > It is why I do option in such way, that old users, for whom > current implementation works, doesn't notice any difference -- rgephy > works exactly the same way as usual untill you set option. > > And, yes, I think, that additional media option will be better, but > it looks like major feature and not small patch :) > That's no reason to not implement it properly :) Marius From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 18:27: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 C9CCD106564A for ; Thu, 13 Jan 2011 18:27:24 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7F7438FC17 for ; Thu, 13 Jan 2011 18:27:24 +0000 (UTC) Received: by yxh35 with SMTP id 35so832721yxh.13 for ; Thu, 13 Jan 2011 10:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=//ulTo0pIh4XSuzIDjQDR/jCIwAg9/BQRbv7stpeEYA=; b=BPtSKzioAwayTRleXy1tD8kMxI71Z8jVwFI1UsR7GWyycPIE5Zo9wJ4jNOBJvcjHx5 WvOkjtfpHXoyGyrb4bVcKTpvRp3iu6sBdA4MvtY72ijeVTlUJDeq5yphN5c9jei6VF5l ksc5R+pu7DPKzh+pDLNXBn8lKUztkCCVJe7AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QC6EmSRISj6xXyWPneKHR5w7K4T1H8OudxH0thN0gYk3IGLnfnF8GRwR3xhtQc1QDa qfgi1lvLX0AGo9JZBfMd9kizmesW/zo9HmSgE/rlJ29MrsF5AMHTZmUuRF/yhX2FOKPd cdRJgivJyB/bbSEXcrwm0UdGFJplVuAWJOc4E= MIME-Version: 1.0 Received: by 10.100.144.11 with SMTP id r11mr1696373and.24.1294943243566; Thu, 13 Jan 2011 10:27:23 -0800 (PST) Received: by 10.147.182.20 with HTTP; Thu, 13 Jan 2011 10:27:23 -0800 (PST) In-Reply-To: <4D2F20BB.5080204@greatbaysoftware.com> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> Date: Thu, 13 Jan 2011 10:27:23 -0800 Message-ID: From: Jack Vogel To: Charles Owens Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Robin Sommer Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:27:24 -0000 The 8.2 latest does have the latest igb, so using that should be indicative... Jack On Thu, Jan 13, 2011 at 7:56 AM, Charles Owens wrote: > Ok... I got my wires crossed: our first time testing 8.1 on this > particular platform was with a kernel that had ichwd enabled (a new thing > for us) and so when igb started complaining about "watchdog" we thought it > was related. > > We've tested again and clearly the real story is that we're simply seeing > igb issues, symptoms similar to those described. > > Does 8.2-RC1 have sufficiently "latest" code, or should I be looking to > load up something else? (8-stable, maybe?) > > Thanks, > Charles > > > > On 1/13/11 12:07 AM, Jack Vogel wrote: > > The problem that Robin saw was due to having MSIX interrupts disabled on > the system, I doubt that > is going to be the "issue" for others. > > Get the latest version of the igb code and see if that helps you as a first > step. > > Jack > > > On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens < > cowens@greatbaysoftware.com> wrote: > >> I'd like to report that we're running into this issue also, in our case on >> systems that are based on the Intel S5520UR Server Board, running >> 8.1-RELEASE. If the ichwd driver is loaded we see the same messages, and >> network communication via the igb nics is non-functional. >> >> Have you had any luck? >> >> Thanks, >> Charles >> >> Charles Owens >> Great Bay Software, Inc. >> >> >> >> >> On 1/3/11 4:02 PM, Robin Sommer wrote: >> >>> Hello all, >>> >>> quite a while ago I asked about the problem below. Unfortunately, I >>> haven't found a solution yet and I'm actually still seeing these >>> timeouts after just upgrading to 8.2-RC1. Any further ideas on what >>> could be triggering them, or how I could track down the cause? >>> >>> Thanks, >>> >>> Robin >>> >>> On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: >>> >>> Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots of messages >>>> like those below on all my SuperMicro SBI-7425C-T3 blades. There's >>>> almost no traffic on those interfaces. >>>> >>>> Any idea? >>>> >>>> Thanks, >>>> >>>> Robin >>>> >>>> Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout -- resetting >>>> Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256, hw tdt = 266 >>>> Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail = 1013,Next TX to >>>> Clean = 255 >>>> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to DOWN >>>> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP >>>> Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout -- resetting >>>> Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >>>> Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to >>>> Clean = 0 >>>> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to DOWN >>>> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP >>>> Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout -- resetting >>>> Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw tdt = 33 >>>> Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail = 1022,Next TX to >>>> Clean = 31 >>>> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to DOWN >>>> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP >>>> Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout -- resetting >>>> Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >>>> Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to >>>> Clean = 0 >>>> Jul 29 13:01:57 blade0 kernel: igb1: link state changed to DOWN >>>> Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP >>>> Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout -- resetting >>>> >>>> grep igb /var/run/dmesg.boot >>>>> >>>> igb0: port >>>> 0x2000-0x201f mem >>>> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff irq 16 at >>>> device 0.0 on pci4 >>>> igb0: [FILTER] >>>> igb0: Ethernet address: 00:30:48:9e:22:00 >>>> igb1: port >>>> 0x2020-0x203f mem >>>> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff irq 17 at >>>> device 0.1 on pci4 >>>> igb1: [FILTER] >>>> igb1: Ethernet address: 00:30:48:9e:22:01 >>>> >>>> pciconf -lv >>>>> >>>> [...] >>>> igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 >>>> chip=0x10a98086 rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82575EB Gigabit Backplane Connection' >>>> class = network >>>> subclass = ethernet >>>> igb1@pci0:4:0:1: class=0x020000 card=0x10a915d9 >>>> chip=0x10a98086 rev=0x02 hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> device = '82575EB Gigabit Backplane Connection' >>>> class = network >>>> subclass = ethernet >>>> [...] >>>> >>> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 18:46:20 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 D32E2106564A for ; Thu, 13 Jan 2011 18:46:20 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5DE6D8FC0C for ; Thu, 13 Jan 2011 18:46:19 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id CEEC613DF5F; Thu, 13 Jan 2011 21:46:18 +0300 (MSK) Date: Thu, 13 Jan 2011 21:46:15 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <135703454.20110113214615@serebryakov.spb.ru> To: Marius Strobl In-Reply-To: <20110113173925.GA49356@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <20110113173925.GA49356@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Pyun YongHyeon , freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:46:20 -0000 Hello, Marius. You wrote 13 =FF=ED=E2=E0=F0=FF 2011 =E3., 20:39:25: > Therefore I'd like to commit the following patch (requires sources > from head and stable branches), unless there's an objection or it > doesn't work as expected: > http://people.freebsd.org/~marius/rgephy.c.diff It doesn't work for me. It allows to set "flag0" but without any effect, ifconfig shows half-duplex and speed is about 180KiB/s... onlyone# ifconfig re0 media auto onlyone# ifconfig re0 re0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether 6c:62:6d:a7:bb:37 inet 46.4.40.135 netmask 0xffffffc0 broadcast 46.4.40.191 media: Ethernet autoselect (100baseTX ) status: active onlyone# ifconfig re0 media 100baseTX mediaopt full-duplex,flag0 onlyone# ifconfig re0 re0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether 6c:62:6d:a7:bb:37 inet 46.4.40.135 netmask 0xffffffc0 broadcast 46.4.40.191 media: Ethernet 100baseTX (100baseTX ) status: active onlyone# --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 18:58: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 42E05106564A for ; Thu, 13 Jan 2011 18:58:09 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 7B1888FC0C for ; Thu, 13 Jan 2011 18:58:08 +0000 (UTC) Received: (qmail 65190 invoked from network); 13 Jan 2011 18:58:06 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Jan 2011 18:58:06 -0000 Date: Thu, 13 Jan 2011 19:58:06 +0100 (CET) Message-Id: <20110113.195806.74699536.sthaug@nethelp.no> To: rysto32@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20110113.151652.104127547.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:58:09 -0000 > If it has an SFP+, won't the it be LR or SR depending on the type of > SFP+ installed? The card is *sold* and *advertised* by Intel as a 10GBase-LR card. It may well be the case that it would also work with a 10GBase-SR SFP+. I don't have one of these lying around to test, unfortunately. But I have indeed verified that the SFP+ in the card is a 1310 nm 10GBase-LR unit (specifically it's a Finisar FTLX1471D3BCV). As such, I believe the ixgbe code should either set the card type as 10GBase-LR (statically), since that's how the card is sold/delivered. Or it should include code to read the optics type from the SFP+. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:09:22 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 AE752106566B for ; Thu, 13 Jan 2011 19:09:22 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41DD08FC1B for ; Thu, 13 Jan 2011 19:09:21 +0000 (UTC) Received: by eyf6 with SMTP id 6so1047201eyf.13 for ; Thu, 13 Jan 2011 11:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jZEWNqS5/y3N5qRH110kzukUxWJw1aytUyCZKIKXB2w=; b=aiRFMPjKdNxaoJBkq+2USLI1dhfOhOvqzlx4Mq3DjIyVpixeyajHVV9iel2E2v0Gq9 C6GruL10OsYBVEU16BBxNf9SFUfiM98AEDfN8d9/dVnrEoNWv5PJnMKHW/f2uGgkXIYq g9lbGZnVQaQRV2GbUArjmXNZ45SYKKyDeIapI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ior77w0TqCgO02aqjj9I2o+0lL6QV6zcI92j2AtN+35tdZmvcTJvqtS2l7Kj8jsKzj BjaFejYwZeReUnEtSJ1Ssm4T/+PlRVcX2PbamZq2ZwjLEq4fdi+toOJfm6flWmB+JwHU 5dtdotEw3kaulCQEfF188OnwAMkl+aHUlfpj0= MIME-Version: 1.0 Received: by 10.213.10.143 with SMTP id p15mr49705ebp.0.1294945761159; Thu, 13 Jan 2011 11:09:21 -0800 (PST) Received: by 10.213.22.14 with HTTP; Thu, 13 Jan 2011 11:09:21 -0800 (PST) In-Reply-To: <20110113.195806.74699536.sthaug@nethelp.no> References: <20110113.151652.104127547.sthaug@nethelp.no> <20110113.195806.74699536.sthaug@nethelp.no> Date: Thu, 13 Jan 2011 14:09:21 -0500 Message-ID: From: Ryan Stone To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:09:22 -0000 As near as I can tell, the SR version of the X520 is going to be the same card, only with an SR SFP+ installed. From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:12: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 6A2651065673 for ; Thu, 13 Jan 2011 19:12:48 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 00EA48FC2C for ; Thu, 13 Jan 2011 19:12:47 +0000 (UTC) Received: by ewy24 with SMTP id 24so1049028ewy.13 for ; Thu, 13 Jan 2011 11:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H8oQBYi4R/9qsCfkGcxVwJFb5gqxJIOlMYLTDMAq9TE=; b=onTRhrMPOmBDn2srH1NXi7q1Z39r/ER3dSuuCqXYNmb70xnYmdu6+bMIRTosgrcDcz c1i4eZ7xyQNfISWkojehY+C4j8bN64eHj+iiAwiucfogCY/ikDkpl1gidcysofoZjdAk 6VGlvkq7me7XjsbZ+BGJeKCNNnknihj9sbBmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cUXA+r1NYLC2q2hOlbRupr97XRlPqSs0CLmvs42BS3HTS9vRsZDKGsfg/lftBDKdIb V3HiG4l2cIQFhj+4LaKZtXG4osvjHSAHJ4eKJSfuP6JGw5n4eRNpCPZQ4zW5r9RuP05u grtRHXf2k1YkNR0aXpcGSvJlnsmfJVDxgH+p0= MIME-Version: 1.0 Received: by 10.213.10.143 with SMTP id p15mr34514ebp.0.1294944585509; Thu, 13 Jan 2011 10:49:45 -0800 (PST) Received: by 10.213.22.14 with HTTP; Thu, 13 Jan 2011 10:49:45 -0800 (PST) In-Reply-To: <20110113.151652.104127547.sthaug@nethelp.no> References: <20110113.151652.104127547.sthaug@nethelp.no> Date: Thu, 13 Jan 2011 13:49:45 -0500 Message-ID: From: Ryan Stone To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:12:48 -0000 If it has an SFP+, won't the it be LR or SR depending on the type of SFP+ installed? From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:49:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9661106566B for ; Thu, 13 Jan 2011 19:49:57 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 0AA938FC14 for ; Thu, 13 Jan 2011 19:49:56 +0000 (UTC) Received: (qmail 83668 invoked from network); 13 Jan 2011 19:49:55 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Jan 2011 19:49:55 -0000 Date: Thu, 13 Jan 2011 20:49:55 +0100 (CET) Message-Id: <20110113.204955.41688285.sthaug@nethelp.no> To: rysto32@gmail.com From: sthaug@nethelp.no In-Reply-To: <20110113.195806.74699536.sthaug@nethelp.no> References: <20110113.151652.104127547.sthaug@nethelp.no> <20110113.195806.74699536.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:49:57 -0000 > > If it has an SFP+, won't the it be LR or SR depending on the type of > > SFP+ installed? > > The card is *sold* and *advertised* by Intel as a 10GBase-LR card. It > may well be the case that it would also work with a 10GBase-SR SFP+. > I don't have one of these lying around to test, unfortunately. But I > have indeed verified that the SFP+ in the card is a 1310 nm 10GBase-LR > unit (specifically it's a Finisar FTLX1471D3BCV). > > As such, I believe the ixgbe code should either set the card type as > 10GBase-LR (statically), since that's how the card is sold/delivered. > Or it should include code to read the optics type from the SFP+. Thinking about this some more - I see there are also SR variants of the same card: http://ark.intel.com/Product.aspx?id=39773 http://ark.intel.com/Product.aspx?id=39774 In which case reading the optics type from the SFP, or having some kind of config setting, is the only thing that makes sense IMHO. Having a 10GBase-LR card report 10GBase-SR is guaranteed to result in misunderstandings... Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:55: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 B427A1065674 for ; Thu, 13 Jan 2011 19:55:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A8978FC14 for ; Thu, 13 Jan 2011 19:55:25 +0000 (UTC) Received: by gyf3 with SMTP id 3so854418gyf.13 for ; Thu, 13 Jan 2011 11:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7gslrYWHrBPbOX8gHuP/jkuZbS8KR/geK0Y23gmwiAk=; b=R8oTmXJSzTnDxG8fnDZq3jePc9A+RWQGPmUt/hL60cKzN8RIep52bkrG4wkyTwyPn2 vZReg0ibHgl2/33CmSTyynV/81vHAY9BsgbbP7kpPNSBOHPJCt2d1PovRxBPdYK268Gr x63c84CtPOg0kC8+H6FcAEaBWvVucwE52b6Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=P2gcGzaEBTN9drMdrLPxpXjzdBpBtwFD9W0Zcp0jp16WmYrv5msKnqNd32BsXdw3I+ tWqIFA7zqI+8QJF1CGqqdtdG/7OgH8FyjsRn/LHJfGcPYyElJ/Gp08kd3KoGlVEshCce PsegpScTuy0J12b72JcMc+nM9hT5exKhKAhqU= MIME-Version: 1.0 Received: by 10.147.167.12 with SMTP id u12mr4187692yao.13.1294948524569; Thu, 13 Jan 2011 11:55:24 -0800 (PST) Received: by 10.147.182.20 with HTTP; Thu, 13 Jan 2011 11:55:24 -0800 (PST) In-Reply-To: <20110113.204955.41688285.sthaug@nethelp.no> References: <20110113.151652.104127547.sthaug@nethelp.no> <20110113.195806.74699536.sthaug@nethelp.no> <20110113.204955.41688285.sthaug@nethelp.no> Date: Thu, 13 Jan 2011 11:55:24 -0800 Message-ID: From: Jack Vogel To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, rysto32@gmail.com Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:55:25 -0000 The problem is that there is no mechanism right now to report on the fly which optics the adapter actually has. So for the ones that can differ I had just chosen the most likely value. If it REALLY bothers you you can change your local code :) When I get some higher priority issues off my plate I can look again at doing something dynamic. Jack On Thu, Jan 13, 2011 at 11:49 AM, wrote: > > > If it has an SFP+, won't the it be LR or SR depending on the type of > > > SFP+ installed? > > > > The card is *sold* and *advertised* by Intel as a 10GBase-LR card. It > > may well be the case that it would also work with a 10GBase-SR SFP+. > > I don't have one of these lying around to test, unfortunately. But I > > have indeed verified that the SFP+ in the card is a 1310 nm 10GBase-LR > > unit (specifically it's a Finisar FTLX1471D3BCV). > > > > As such, I believe the ixgbe code should either set the card type as > > 10GBase-LR (statically), since that's how the card is sold/delivered. > > Or it should include code to read the optics type from the SFP+. > > Thinking about this some more - I see there are also SR variants of the > same card: > > http://ark.intel.com/Product.aspx?id=39773 > http://ark.intel.com/Product.aspx?id=39774 > > In which case reading the optics type from the SFP, or having some kind > of config setting, is the only thing that makes sense IMHO. > > Having a 10GBase-LR card report 10GBase-SR is guaranteed to result in > misunderstandings... > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 19:59: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 02FA51065674 for ; Thu, 13 Jan 2011 19:59:51 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 394338FC14 for ; Thu, 13 Jan 2011 19:59:49 +0000 (UTC) Received: (qmail 84843 invoked from network); 13 Jan 2011 19:59:48 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 Jan 2011 19:59:48 -0000 Date: Thu, 13 Jan 2011 20:59:48 +0100 (CET) Message-Id: <20110113.205948.71141539.sthaug@nethelp.no> To: jfvogel@gmail.com From: sthaug@nethelp.no In-Reply-To: References: <20110113.195806.74699536.sthaug@nethelp.no> <20110113.204955.41688285.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, rysto32@gmail.com Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:59:51 -0000 > The problem is that there is no mechanism right now to report on the > fly which optics the adapter actually has. So for the ones that can > differ I had just chosen the most likely value. Yup, guessed as much. > If it REALLY bothers you you can change your local code :) Which is exactly what I did. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 21:27: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 D5D02106566B for ; Thu, 13 Jan 2011 21:27:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A161A8FC31 for ; Thu, 13 Jan 2011 21:27:50 +0000 (UTC) Received: by pwi10 with SMTP id 10so388069pwi.13 for ; Thu, 13 Jan 2011 13:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=0nb+Eevtste7VaqewzIKhUayoXq6ApBhRBx6FosJKZM=; b=wv3SmYI6IIihzKQoETKpW1K/fTSg+UrWW1BGPzCnrNp2Ee0KGVjALeyJR50ueW+Vt9 /u0lE8+BL29OTl26SnHpydeXGHuzX/rI3LAY+i6ey6i466LhmO5eNboXfG6l/yCWm/eR Lb4gHwkYLSeNmiKfy6JjJsz5iKArJmTQyl+f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=N2U6M0hEbqkkagOHu9IzOHUJymYZM2u/SsjZLcjJbcIU9IVTNQQdruhDZCmCKLiSiy u7MOOQi+RYAUGZlXEaTyk/30m/IpT67SuKVsQ/GGYetefaGwX3VpJgSaeWSs8A8VPTO5 w4E4vpaCRyS09G2WGB3zb/HUGN63ED0scJamU= Received: by 10.142.157.9 with SMTP id f9mr49524wfe.272.1294954069039; Thu, 13 Jan 2011 13:27:49 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w22sm611594wfd.7.2011.01.13.13.27.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 13:27:47 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 13 Jan 2011 13:27:13 -0800 From: Pyun YongHyeon Date: Thu, 13 Jan 2011 13:27:13 -0800 To: Marius Strobl Message-ID: <20110113212713.GC17502@michelle.cdnetworks.com> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <20110113173925.GA49356@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110113173925.GA49356@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW 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 Jan 2011 21:27:50 -0000 On Thu, Jan 13, 2011 at 06:39:25PM +0100, Marius Strobl wrote: > On Wed, Jan 12, 2011 at 11:59:07PM +0100, Marius Strobl wrote: > > On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote: > > > On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote: > > > > Hello, Freebsd-net. > > > > > > > > Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > > > > with re(4) does autonegotiation always and all other, who helps me > > > > diagnose problem! > > > > > > > > I've prepared patch, which adds tunable/sysctl for rgephy(4) which > > > > allows not to sue autonegotiation by this PHY (at user responsibility, > > > > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > > > > by default, and in such case behavior of driver IS NOT CHANGED. > > > > > > > > But if it is set ON (non-zero value) before "media / mediopt" > > > > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > > > > settings. > > > > > > > > I've documented this new tunable in re(4) manpage, as here is no > > > > rgephy(4) manpage. > > > > > > > > Tunable is per-device, not global one. > > > > > > > > Sysctl can be set after boot, but will affect only future ifconfig > > > > calls, it doesn't change anything in PHY settings by itself. > > > > > > > > It allows fully manual setup on non-buggy hardware, which allows to > > > > use Hetzner dedicated servers with FreeBSD without additional NIC or > > > > gigabit connection. > > > > > > > > I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it > > > > allows me to get full-duplex 100Mbit connection and I got 11MiB/s from > > > > local NFS with it. > > > > > > > > Without this patch FreeBSD is unusable on Hetzner dedicated servers > > > > in newer DCs (DC 13 and DC 14). > > > > > > > > Patch is attached. I think, it worths to include it to base system, > > > > as it allows use FreeBSD at least on one very large and popular > > > > hosting provider without additional costs :) > > > > > > > > > > Thanks for your work. After reading commit log of rgephy(4) I now > > > refreshed my memory. The issue came from the reverse usage case. > > > Suppose link partner announces auto-negotiation but you want to use > > > 100baseTX/full-duplex. As you know this results in duplex mismatch > > > and sometimes it couldn't establish a link on some RealTek PHYs. > > > (Now I'm not entirely sure it was caused by the specific switch or > > > rgephy(4) or both) > > > And frequently, link partner(switch) is out of control from your > > > domain and most switches are configured to use auto-negotiation by > > > default. Using auto-negotiation in manual media configuration > > > seemed to address the issue at that time. 1000baseT link always > > > requires auto-negotiation but too many switches were broken with > > > auto-negotiation so some switches are forced to use manual media > > > configuration even in 1000baseT mode. Using auto-negotiation on > > > rgephy(4) will also solve that case. > > > > > > So I have mixed feelings on how to handle both cases. Traditional > > > way, which your patch does, used in manual configuration was to > > > strictly honor specified manual media configuration even if it can > > > break in some edge cases. Programming PHYs with traditional way > > > shall also trigger other problems to drivers which correctly keep > > > track of valid link state changes. Normally speed/duplex/flow-control > > > changes require MAC reprogramming such that monitoring PHY's state > > > change is essential to modern ethernet controllers. Forcing manual > > > media configuration can make PHY drivers fail to report link state > > > changes which in turn shall make ethernet controller not to work > > > due to speed/duplex mismatches between PHY and MAC of ethernet > > > controller. re(4) does not require MAC reprogramming but many other > > > drivers that use regephy(4) may not work. However regphy(4) > > > hardware I have still seem to correctly report link state change > > > with manual link configuration. Not sure about old controllers > > > though. > > > > > > I'm under the impression that rgephy(4)'s behavior seem to confuse > > > users a lot since it unconditionally use auto-negotiation so I > > > think it's better not to use auto-negotiation at all during manual > > > media configuration and provides a way to use auto-negotiation in > > > manual media configuration if administrator want to do that. > > > > Note that even the RealTek supplied driver always triggers an > > auto-negotiation when manually setting the media though. However, > > at the same time it also comes with tons of uncommented PHY fix-up > > code which might be relevant for this or the previous issue. > > Unfortunately, I didn't get to checking whether the MAC versions > > in question are amongst the ones that get patched so far. > > In any case I don't think we can easily change this (default) > > behavior after such a relatively long time as it would break POLA > > for an unknown number of users, even if it probably shouldn't have > > been made the default in the first place (but again on the other > > hand that's what RealTek themselves also chose to do). Also apart > > from edges cases like the current issue the present behavior should > > result in a setup that "just works" so I doubt it actually results > > in confusion. > > > > Independently of DSP fixes that might or might not fixes these > issues I agree that there should be a way to turn off the use of > auto-negotiation along with manual media configuration in rgephy(4) > though. IMO there are some bugs and issues with the patch provided > by Lev however: > - It fails to reject enabling of PAUSE advertisement when not > using auto-negotiation. > - It has no effect on 1000base-T; as you pointed out some switches > also require manual selection (without auto-negotiation) here as > a workaround. > - I don't like the idea of growing a tunable when the same can be > achieved via ifmedia support. > > Therefore I'd like to commit the following patch (requires sources > from head and stable branches), unless there's an objection or it > doesn't work as expected: > http://people.freebsd.org/~marius/rgephy.c.diff > > With this in place you should be able to manually set full-duplex > with auto-negotiation turned off via: > ifconfig re0 media 100baseTX mediaopt full-duplex,flag0 > > A full list of what that patch does is: > - Allow IFM_FLAG0 to be set indicating that auto-negotiation with manual > configuration, which is used to work around issues with certain setups > (see r161237) by default, should not be triggered as it may in turn > cause harm in some edge cases. > - Even after masking the media with IFM_GMASK the result may have bits > besides the duplex ones set so just comparing it with IFM_FDX may lead > to false negatives. > - Announce PAUSE support also for manually selected 1000BASE-T, but for > all manually selected media types only in full-duplex mode. Announce > asymmetric PAUSE support only for manually selected 1000BASE-T. > - Simplify setting the manual configuration bits to only once after we > have figured them all out. This also means we no longer unnecessarily > update the hardware along the road. > - Remove a stale comment. > Looks good to me except one thing about IFM_FLAG0 handling. It seems we don't have a way to register IFM_FLAG0 with mii_phy_add_media() such that flag0 option is not passed to MII_MEDIACHG handler which in turn makes rgephy4) think IFM_FLAG0 was not specified. Adding IFM_FLAG0 after registering available media with mii_phy_add_mdia() seems to have no effect. Do we have to use IFM_MAKEWIRD to handle this case? From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 21:42: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 CDE0B106566B for ; Thu, 13 Jan 2011 21:42:26 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 55B508FC12 for ; Thu, 13 Jan 2011 21:42:25 +0000 (UTC) Received: from jack.bspruce.com ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Thu, 13 Jan 2011 16:42:22 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4D2F71BE.2080801@greatbaysoftware.com> Date: Thu, 13 Jan 2011 16:42:22 -0500 From: Charles Owens MIME-Version: 1.0 To: Jack Vogel References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> In-Reply-To: X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Robin Sommer Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:42:26 -0000 So we went back to basics (stock 8.1-RELEASE) and found no issue! We then added in our kernel mods one by one and ultimately discovered that device-polling is the culprit (the kernel config was simply GENERIC + PAE + polling). Immediately upon running "ifconfig igb0 polling" the symptoms appear. This is very good news overall, in that we can certainly disable polling for igb. This begs the question, though, as to whether polling is recommended these days at all for em/igb NICs... or even in general. From other conversations we've seen there seems to be some general debate about this. In testing we've done in the past (circa 7.0) there certainly seemed to be benefit to using this feature. What are your thoughts about this? For our product releases we'd like stay with RELENG_8_1. Would you recommend the driver in 8.2 as being preferable? In case it's of interest: igb0@pci0:1:0:0: class=0x020000 card=0x34de8086 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet Thanks, Charles On 1/13/11 1:27 PM, Jack Vogel wrote: > The 8.2 latest does have the latest igb, so using that should be > indicative... > > Jack > > > On Thu, Jan 13, 2011 at 7:56 AM, Charles Owens > > wrote: > > Ok... I got my wires crossed: our first time testing 8.1 on this > particular platform was with a kernel that had ichwd enabled (a > new thing for us) and so when igb started complaining about > "watchdog" we thought it was related. > > We've tested again and clearly the real story is that we're simply > seeing igb issues, symptoms similar to those described. > > Does 8.2-RC1 have sufficiently "latest" code, or should I be > looking to load up something else? (8-stable, maybe?) > > Thanks, > Charles > > > > On 1/13/11 12:07 AM, Jack Vogel wrote: >> The problem that Robin saw was due to having MSIX interrupts >> disabled on the system, I doubt that >> is going to be the "issue" for others. >> >> Get the latest version of the igb code and see if that helps you >> as a first step. >> >> Jack >> >> >> On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens >> > > wrote: >> >> I'd like to report that we're running into this issue also, >> in our case on systems that are based on the Intel S5520UR >> Server Board, running 8.1-RELEASE. If the ichwd driver is >> loaded we see the same messages, and network communication >> via the igb nics is non-functional. >> >> Have you had any luck? >> >> Thanks, >> Charles >> >> Charles Owens >> Great Bay Software, Inc. >> >> >> >> >> On 1/3/11 4:02 PM, Robin Sommer wrote: >> >> Hello all, >> >> quite a while ago I asked about the problem below. >> Unfortunately, I >> haven't found a solution yet and I'm actually still >> seeing these >> timeouts after just upgrading to 8.2-RC1. Any further >> ideas on what >> could be triggering them, or how I could track down the >> cause? >> >> Thanks, >> >> Robin >> >> On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: >> >> Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing >> lots of messages >> like those below on all my SuperMicro SBI-7425C-T3 >> blades. There's >> almost no traffic on those interfaces. >> >> Any idea? >> >> Thanks, >> >> Robin >> >> Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout >> -- resetting >> Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = >> 256, hw tdt = 266 >> Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail >> = 1013,Next TX to Clean = 255 >> Jul 29 13:01:18 blade0 kernel: igb1: link state >> changed to DOWN >> Jul 29 13:01:18 blade0 kernel: igb1: link state >> changed to UP >> Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout >> -- resetting >> Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = >> 0, hw tdt = 10 >> Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail >> = 1014,Next TX to Clean = 0 >> Jul 29 13:01:29 blade0 kernel: igb1: link state >> changed to DOWN >> Jul 29 13:01:29 blade0 kernel: igb1: link state >> changed to UP >> Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout >> -- resetting >> Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = >> 32, hw tdt = 33 >> Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail >> = 1022,Next TX to Clean = 31 >> Jul 29 13:01:46 blade0 kernel: igb1: link state >> changed to DOWN >> Jul 29 13:01:46 blade0 kernel: igb1: link state >> changed to UP >> Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout >> -- resetting >> Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = >> 0, hw tdt = 10 >> Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail >> = 1014,Next TX to Clean = 0 >> Jul 29 13:01:57 blade0 kernel: igb1: link state >> changed to DOWN >> Jul 29 13:01:58 blade0 kernel: igb1: link state >> changed to UP >> Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout >> -- resetting >> >> grep igb /var/run/dmesg.boot >> >> igb0:> 1.9.5> port 0x2000-0x201f mem >> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff >> irq 16 at device 0.0 on pci4 >> igb0: [FILTER] >> igb0: Ethernet address: 00:30:48:9e:22:00 >> igb1:> 1.9.5> port 0x2020-0x203f mem >> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff >> irq 17 at device 0.1 on pci4 >> igb1: [FILTER] >> igb1: Ethernet address: 00:30:48:9e:22:01 >> >> pciconf -lv >> >> [...] >> igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 >> chip=0x10a98086 rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82575EB Gigabit Backplane Connection' >> class = network >> subclass = ethernet >> igb1@pci0:4:0:1: class=0x020000 card=0x10a915d9 >> chip=0x10a98086 rev=0x02 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82575EB Gigabit Backplane Connection' >> class = network >> subclass = ethernet >> [...] >> >> >> _______________________________________________ >> freebsd-net@freebsd.org >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org >> " >> >> > From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 21:47: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 04F321065694 for ; Thu, 13 Jan 2011 21:47:36 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id DD1038FC1E for ; Thu, 13 Jan 2011 21:47:35 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LEZ00L32DV71G40@asmtp026.mac.com> for freebsd-net@freebsd.org; Thu, 13 Jan 2011 13:47:32 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1101130140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-13_09:2011-01-13, 2011-01-13, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <4D2F71BE.2080801@greatbaysoftware.com> Date: Thu, 13 Jan 2011 13:47:31 -0800 Message-id: <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> To: Charles Owens X-Mailer: Apple Mail (2.1082) Cc: freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:47:36 -0000 On Jan 13, 2011, at 1:42 PM, Charles Owens wrote: > This is very good news overall, in that we can certainly disable polling for igb. This begs the question, though, as to whether polling is recommended these days at all for em/igb NICs... or even in general. From other conversations we've seen there seems to be some general debate about this. In testing we've done in the past (circa 7.0) there certainly seemed to be benefit to using this feature. What are your thoughts about this? To quote an earlier post: "Polling mode operation generally performs better when using older 100Mbs ethernet NICs which do not support interrupt mitigation and various capabilities like TSO4; gigabit ethernet NICs are smarter hardware and can generally outperform polling mode." Polling is well-suited for dedicated routers, firewalls, and other boxes which have a constant flow of traffic and for which you are looking for well-bounded latency. End-user machines, servers, and the like which have bursty traffic tend to do better using normal NIC operation, especially if you have decent gigabit NICs which support interrupt mitigation and have larger buffers than the old 100Mbs NICs had. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Jan 13 21:49: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 3D9341065670 for ; Thu, 13 Jan 2011 21:49:59 +0000 (UTC) (envelope-from jfvogel@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 E51C48FC1F for ; Thu, 13 Jan 2011 21:49:58 +0000 (UTC) Received: by ywp6 with SMTP id 6so648304ywp.13 for ; Thu, 13 Jan 2011 13:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+xNkd/gDBY/N7mLM4ou2m90gy1xONwCrPz0Axu5qVtc=; b=c9CLt57FsuBFw6EB4nRmRsocdhq8kmU9bvqxTm3FokZH3zMvHMsgJcqfTcF6HxEtVd o0kvDpq7wP/ZzZFcHzb18aLZP4oalRd1TmYyfhpE4a/Ocz5g6X4glHSD/Q3yXqF0Y89I zcCP4eyW5CQXkiTA+o4pRuvIGLT0JDgjt+CXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dltwn2lu4ghGb2we6bJJPkHO0RN8qYAGd70evSagYENDx48WUSTDYB4l9ubOu+4IkO xKMRYSthw2+hDVgrEJ0S7Vo/nC1r9tx+AZ7FOijNgb4SsCcB5Xp4+7aCcyBj2/Ms9DNF Jcs08y5wzoimrlab70usuwlRXcWZY9omvqq8k= MIME-Version: 1.0 Received: by 10.150.212.14 with SMTP id k14mr354082ybg.73.1294955397995; Thu, 13 Jan 2011 13:49:57 -0800 (PST) Received: by 10.147.182.20 with HTTP; Thu, 13 Jan 2011 13:49:57 -0800 (PST) In-Reply-To: <4D2F71BE.2080801@greatbaysoftware.com> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> Date: Thu, 13 Jan 2011 13:49:57 -0800 Message-ID: From: Jack Vogel To: Charles Owens Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net , Robin Sommer Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:49:59 -0000 Polling has seemed to me to be a way around other problems, problems that these days no longer exist. I remember back in the FreeBSD 6 days having interrupt problems which of course also led to watchdogs. Polling got rid of that. But now there are dedicated MULTIPLE interrupts by using MSIX, so that reason for polling is gone. Of course there can still be advantages, reducing interrupts and hence context switches, which is why the Linux approach does what it does. I have not spent time with that issue, its good to know that there could be problems lurking with it. But if you can simply go with MSIX I would do that for now. Jack On Thu, Jan 13, 2011 at 1:42 PM, Charles Owens wrote: > So we went back to basics (stock 8.1-RELEASE) and found no issue! We > then added in our kernel mods one by one and ultimately discovered that > device-polling is the culprit (the kernel config was simply GENERIC + PAE + > polling). > > Immediately upon running "ifconfig igb0 polling" the symptoms appear. > > This is very good news overall, in that we can certainly disable polling > for igb. This begs the question, though, as to whether polling is > recommended these days at all for em/igb NICs... or even in general. From > other conversations we've seen there seems to be some general debate about > this. In testing we've done in the past (circa 7.0) there certainly seemed > to be benefit to using this feature. What are your thoughts about this? > > For our product releases we'd like stay with RELENG_8_1. Would you > recommend the driver in 8.2 as being preferable? > > In case it's of interest: > > igb0@pci0:1:0:0: class=0x020000 card=0x34de8086 chip=0x10a78086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > > > > Thanks, > Charles > > > > On 1/13/11 1:27 PM, Jack Vogel wrote: > > The 8.2 latest does have the latest igb, so using that should be > indicative... > > Jack > > > On Thu, Jan 13, 2011 at 7:56 AM, Charles Owens < > cowens@greatbaysoftware.com> wrote: > >> Ok... I got my wires crossed: our first time testing 8.1 on this >> particular platform was with a kernel that had ichwd enabled (a new thing >> for us) and so when igb started complaining about "watchdog" we thought it >> was related. >> >> We've tested again and clearly the real story is that we're simply seeing >> igb issues, symptoms similar to those described. >> >> Does 8.2-RC1 have sufficiently "latest" code, or should I be looking to >> load up something else? (8-stable, maybe?) >> >> Thanks, >> Charles >> >> >> >> On 1/13/11 12:07 AM, Jack Vogel wrote: >> >> The problem that Robin saw was due to having MSIX interrupts disabled on >> the system, I doubt that >> is going to be the "issue" for others. >> >> Get the latest version of the igb code and see if that helps you as a >> first step. >> >> Jack >> >> >> On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens < >> cowens@greatbaysoftware.com> wrote: >> >>> I'd like to report that we're running into this issue also, in our case >>> on systems that are based on the Intel S5520UR Server Board, running >>> 8.1-RELEASE. If the ichwd driver is loaded we see the same messages, and >>> network communication via the igb nics is non-functional. >>> >>> Have you had any luck? >>> >>> Thanks, >>> Charles >>> >>> Charles Owens >>> Great Bay Software, Inc. >>> >>> >>> >>> >>> On 1/3/11 4:02 PM, Robin Sommer wrote: >>> >>>> Hello all, >>>> >>>> quite a while ago I asked about the problem below. Unfortunately, I >>>> haven't found a solution yet and I'm actually still seeing these >>>> timeouts after just upgrading to 8.2-RC1. Any further ideas on what >>>> could be triggering them, or how I could track down the cause? >>>> >>>> Thanks, >>>> >>>> Robin >>>> >>>> On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: >>>> >>>> Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots of messages >>>>> like those below on all my SuperMicro SBI-7425C-T3 blades. There's >>>>> almost no traffic on those interfaces. >>>>> >>>>> Any idea? >>>>> >>>>> Thanks, >>>>> >>>>> Robin >>>>> >>>>> Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout -- resetting >>>>> Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256, hw tdt = 266 >>>>> Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail = 1013,Next TX to >>>>> Clean = 255 >>>>> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to DOWN >>>>> Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP >>>>> Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout -- resetting >>>>> Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >>>>> Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to >>>>> Clean = 0 >>>>> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to DOWN >>>>> Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP >>>>> Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout -- resetting >>>>> Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw tdt = 33 >>>>> Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail = 1022,Next TX to >>>>> Clean = 31 >>>>> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to DOWN >>>>> Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP >>>>> Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout -- resetting >>>>> Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 >>>>> Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to >>>>> Clean = 0 >>>>> Jul 29 13:01:57 blade0 kernel: igb1: link state changed to DOWN >>>>> Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP >>>>> Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout -- resetting >>>>> >>>>> grep igb /var/run/dmesg.boot >>>>>> >>>>> igb0: port >>>>> 0x2000-0x201f mem >>>>> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff irq 16 at >>>>> device 0.0 on pci4 >>>>> igb0: [FILTER] >>>>> igb0: Ethernet address: 00:30:48:9e:22:00 >>>>> igb1: port >>>>> 0x2020-0x203f mem >>>>> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff irq 17 at >>>>> device 0.1 on pci4 >>>>> igb1: [FILTER] >>>>> igb1: Ethernet address: 00:30:48:9e:22:01 >>>>> >>>>> pciconf -lv >>>>>> >>>>> [...] >>>>> igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 >>>>> chip=0x10a98086 rev=0x02 hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = '82575EB Gigabit Backplane Connection' >>>>> class = network >>>>> subclass = ethernet >>>>> igb1@pci0:4:0:1: class=0x020000 card=0x10a915d9 >>>>> chip=0x10a98086 rev=0x02 hdr=0x00 >>>>> vendor = 'Intel Corporation' >>>>> device = '82575EB Gigabit Backplane Connection' >>>>> class = network >>>>> subclass = ethernet >>>>> [...] >>>>> >>>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >> >> > From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 00: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 0C395106564A for ; Fri, 14 Jan 2011 00:35:29 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web39304.mail.mud.yahoo.com (web39304.mail.mud.yahoo.com [66.94.238.171]) by mx1.freebsd.org (Postfix) with SMTP id BA35D8FC0C for ; Fri, 14 Jan 2011 00:35:28 +0000 (UTC) Received: (qmail 95622 invoked by uid 60001); 14 Jan 2011 00:08:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1294963728; bh=uLpvUgmXpkqc3QFKozYG/5PoIpurA5f3DcmfSrj/abc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=wImrkyhXkaoCv9B464GCc2rWl9B8F8Wu+WXiAFOmVLLJexrfpdZAfw8GQomuwuWSlyQ24IrJ9gNY3SLwa2reFybM1WDMhQR+rSi2iadrRsm5C07hrhTCAvu+ZZ/OpFmxLembupOuV2odQBRRIQYjSui7Nghe+O+CHJrGoefSQvU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hFw02YL3KMeY3dJozhyZ+47+ImNMa3NEZV5yb2X9HPSC+EHeHOM+2AZXGkFe5uPRNYZUNcZuCL/CDjCRIDEI4oy3CJG8OfpEDKPA0VYbI27fV19e4Y+wH+pwH8FEgAyk3tCXuYOUKQ9Fc+8oRbStnvVGESi9ixM/9GgsnolGhlk=; Message-ID: <795250.95347.qm@web39304.mail.mud.yahoo.com> X-YMail-OSG: tjtVgSUVM1nTHhsCGGKwGjjxyi9uG1n5nRKYpGxukYP0fxW johtJyrdkEYB8K.WMQ9kCbPXVqlKonV2_w8PYnLcEUGE.CrXx74Gim6RX_cE y4AZRoz3Q6PEYDkI2JEO6utplcAUVSB7EyL1Zxe4ZeU44FtYvcJiu4Dpgtjk yuLRUOjce0BV6kiMjkfQg87rSa37b_PEUPDT1vVQ.yXPVe4Aazj8yqpaPLIs dBWnAKP1hO46Jh.V5yVVF1cTISw7PP85tzu5GO0.a7ZNI6N_rjNRUf6IW6_H zZuJGCctFs4sR8adPNLDpXVxA5zYV0FyqHxJW6.LTRljcPuSlycuMfpzMray LgwepYOyRLiKF3e0VfEwYP6QBFsVnHD8BNdQ4Qh2F.FIQiNXcURq2c2CyfX8 B2HyuV8DwgyKspjcp Received: from [206.75.146.55] by web39304.mail.mud.yahoo.com via HTTP; Thu, 13 Jan 2011 16:08:48 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259 References: <201101121955.p0CJtx5B078589@triton8.kn-bremen.de> Date: Thu, 13 Jan 2011 16:08:48 -0800 (PST) From: PseudoCylon To: Juergen Lock , FreeBSD-gnats-submit@freebsd.org In-Reply-To: <201101121955.p0CJtx5B078589@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: [run] [panic] [patch] Workaround for use-after-free 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: Fri, 14 Jan 2011 00:35:29 -0000 ----- Original Message ---- > From: Juergen Lock > To: FreeBSD-gnats-submit@freebsd.org > Cc: moonlightakkiy@yahoo.ca; freebsd-net@freebsd.org > Sent: Wed, January 12, 2011 12:55:59 PM > Subject: [run] [panic] [patch] Workaround for use-after-free panic > > > >Submitter-Id: current-users > >Originator: Juergen Lock > >Organization: me? organized?? > >Confidential: no > >Synopsis: [run] [panic] [patch] Workaround for use-after-free panic > >Severity: > >Priority: > >Category: kern > >Class: sw-bug > >Release: FreeBSD 8.1-RC2 amd64 > >Environment: > System: FreeBSD triton8.kn-bremen.de 8.1-RC2 FreeBSD 8.1-RC2 #9: Wed Sep 1 >21:53:36 CEST 2010 >nox@triton8.kn-bremen.de:/usr/obj/data2v/home/nox/src-r81/src/sys/TRITON8U >amd64 > > Yes this is an older stable/8 checkout but if_run(4) is > checked out from head. > > >Description: > Running the nic in hostap mode with wpa2 I once every few > weeks got the following crash: > Hello, Thank you for the patch. I have applied it. Please try patched driver out. http://gitorious.org/run/run/trees/ratectl_fix/dev/usb/wlan Basically, I added locks to your patch, so saved pointers are more reliable. AK From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 01:20: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 9E6DA1065675 for ; Fri, 14 Jan 2011 01:20:10 +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 CCDAE8FC1C for ; Fri, 14 Jan 2011 01:20:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0E1K6WJ075705 for ; Fri, 14 Jan 2011 01:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0E1K6H4075702; Fri, 14 Jan 2011 01:20:06 GMT (envelope-from gnats) Date: Fri, 14 Jan 2011 01:20:06 GMT Message-Id: <201101140120.p0E1K6H4075702@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: PseudoCylon Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: PseudoCylon List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 01:20:10 -0000 The following reply was made to PR kern/153938; it has been noted by GNATS. From: PseudoCylon To: bug-followup@freebsd.org, nox@jelal.kn-bremen.de Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Thu, 13 Jan 2011 16:47:21 -0800 (PST) ----- Original Message ---- > From: Juergen Lock > To: FreeBSD-gnats-submit@freebsd.org > Cc: moonlightakkiy@yahoo.ca; freebsd-net@freebsd.org > Sent: Wed, January 12, 2011 12:55:59 PM > Subject: [run] [panic] [patch] Workaround for use-after-free panic > > > >Submitter-Id: current-users > >Originator: Juergen Lock > >Organization: me? organized?? > >Confidential: no > >Synopsis: [run] [panic] [patch] Workaround for use-after-free panic > >Severity: > >Priority: > >Category: kern > >Class: sw-bug > >Release: FreeBSD 8.1-RC2 amd64 > >Environment: > System: FreeBSD triton8.kn-bremen.de 8.1-RC2 FreeBSD 8.1-RC2 #9: Wed Sep 1 >21:53:36 CEST 2010 >nox@triton8.kn-bremen.de:/usr/obj/data2v/home/nox/src-r81/src/sys/TRITON8U >amd64 > > Yes this is an older stable/8 checkout but if_run(4) is > checked out from head. > > >Description: > Running the nic in hostap mode with wpa2 I once every few > weeks got the following crash: > Hello, Thank you for the patch. I have applied it. Please try patched driver out. http://gitorious.org/run/run/trees/ratectl_fix/dev/usb/wlan I added locks to your patch, so saved pointers are more reliable. AK From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 01:24:15 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 0122A106564A for ; Fri, 14 Jan 2011 01:24:15 +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 70A038FC19 for ; Fri, 14 Jan 2011 01:24:14 +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 p0E1OCuT051108; Fri, 14 Jan 2011 02:24:12 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p0E1OCGQ051107; Fri, 14 Jan 2011 02:24:12 +0100 (CET) (envelope-from marius) Date: Fri, 14 Jan 2011 02:24:12 +0100 From: Marius Strobl To: Pyun YongHyeon Message-ID: <20110114012412.GK97101@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <20110113173925.GA49356@alchemy.franken.de> <20110113212713.GC17502@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110113212713.GC17502@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 01:24:15 -0000 On Thu, Jan 13, 2011 at 01:27:13PM -0800, Pyun YongHyeon wrote: > On Thu, Jan 13, 2011 at 06:39:25PM +0100, Marius Strobl wrote: > > On Wed, Jan 12, 2011 at 11:59:07PM +0100, Marius Strobl wrote: > > > On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote: > > > > On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote: > > > > > Hello, Freebsd-net. > > > > > > > > > > Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > > > > > with re(4) does autonegotiation always and all other, who helps me > > > > > diagnose problem! > > > > > > > > > > I've prepared patch, which adds tunable/sysctl for rgephy(4) which > > > > > allows not to sue autonegotiation by this PHY (at user responsibility, > > > > > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > > > > > by default, and in such case behavior of driver IS NOT CHANGED. > > > > > > > > > > But if it is set ON (non-zero value) before "media / mediopt" > > > > > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > > > > > settings. > > > > > > > > > > I've documented this new tunable in re(4) manpage, as here is no > > > > > rgephy(4) manpage. > > > > > > > > > > Tunable is per-device, not global one. > > > > > > > > > > Sysctl can be set after boot, but will affect only future ifconfig > > > > > calls, it doesn't change anything in PHY settings by itself. > > > > > > > > > > It allows fully manual setup on non-buggy hardware, which allows to > > > > > use Hetzner dedicated servers with FreeBSD without additional NIC or > > > > > gigabit connection. > > > > > > > > > > I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it > > > > > allows me to get full-duplex 100Mbit connection and I got 11MiB/s from > > > > > local NFS with it. > > > > > > > > > > Without this patch FreeBSD is unusable on Hetzner dedicated servers > > > > > in newer DCs (DC 13 and DC 14). > > > > > > > > > > Patch is attached. I think, it worths to include it to base system, > > > > > as it allows use FreeBSD at least on one very large and popular > > > > > hosting provider without additional costs :) > > > > > > > > > > > > > Thanks for your work. After reading commit log of rgephy(4) I now > > > > refreshed my memory. The issue came from the reverse usage case. > > > > Suppose link partner announces auto-negotiation but you want to use > > > > 100baseTX/full-duplex. As you know this results in duplex mismatch > > > > and sometimes it couldn't establish a link on some RealTek PHYs. > > > > (Now I'm not entirely sure it was caused by the specific switch or > > > > rgephy(4) or both) > > > > And frequently, link partner(switch) is out of control from your > > > > domain and most switches are configured to use auto-negotiation by > > > > default. Using auto-negotiation in manual media configuration > > > > seemed to address the issue at that time. 1000baseT link always > > > > requires auto-negotiation but too many switches were broken with > > > > auto-negotiation so some switches are forced to use manual media > > > > configuration even in 1000baseT mode. Using auto-negotiation on > > > > rgephy(4) will also solve that case. > > > > > > > > So I have mixed feelings on how to handle both cases. Traditional > > > > way, which your patch does, used in manual configuration was to > > > > strictly honor specified manual media configuration even if it can > > > > break in some edge cases. Programming PHYs with traditional way > > > > shall also trigger other problems to drivers which correctly keep > > > > track of valid link state changes. Normally speed/duplex/flow-control > > > > changes require MAC reprogramming such that monitoring PHY's state > > > > change is essential to modern ethernet controllers. Forcing manual > > > > media configuration can make PHY drivers fail to report link state > > > > changes which in turn shall make ethernet controller not to work > > > > due to speed/duplex mismatches between PHY and MAC of ethernet > > > > controller. re(4) does not require MAC reprogramming but many other > > > > drivers that use regephy(4) may not work. However regphy(4) > > > > hardware I have still seem to correctly report link state change > > > > with manual link configuration. Not sure about old controllers > > > > though. > > > > > > > > I'm under the impression that rgephy(4)'s behavior seem to confuse > > > > users a lot since it unconditionally use auto-negotiation so I > > > > think it's better not to use auto-negotiation at all during manual > > > > media configuration and provides a way to use auto-negotiation in > > > > manual media configuration if administrator want to do that. > > > > > > Note that even the RealTek supplied driver always triggers an > > > auto-negotiation when manually setting the media though. However, > > > at the same time it also comes with tons of uncommented PHY fix-up > > > code which might be relevant for this or the previous issue. > > > Unfortunately, I didn't get to checking whether the MAC versions > > > in question are amongst the ones that get patched so far. > > > In any case I don't think we can easily change this (default) > > > behavior after such a relatively long time as it would break POLA > > > for an unknown number of users, even if it probably shouldn't have > > > been made the default in the first place (but again on the other > > > hand that's what RealTek themselves also chose to do). Also apart > > > from edges cases like the current issue the present behavior should > > > result in a setup that "just works" so I doubt it actually results > > > in confusion. > > > > > > > Independently of DSP fixes that might or might not fixes these > > issues I agree that there should be a way to turn off the use of > > auto-negotiation along with manual media configuration in rgephy(4) > > though. IMO there are some bugs and issues with the patch provided > > by Lev however: > > - It fails to reject enabling of PAUSE advertisement when not > > using auto-negotiation. > > - It has no effect on 1000base-T; as you pointed out some switches > > also require manual selection (without auto-negotiation) here as > > a workaround. > > - I don't like the idea of growing a tunable when the same can be > > achieved via ifmedia support. > > > > Therefore I'd like to commit the following patch (requires sources > > from head and stable branches), unless there's an objection or it > > doesn't work as expected: > > http://people.freebsd.org/~marius/rgephy.c.diff > > > > With this in place you should be able to manually set full-duplex > > with auto-negotiation turned off via: > > ifconfig re0 media 100baseTX mediaopt full-duplex,flag0 > > > > A full list of what that patch does is: > > - Allow IFM_FLAG0 to be set indicating that auto-negotiation with manual > > configuration, which is used to work around issues with certain setups > > (see r161237) by default, should not be triggered as it may in turn > > cause harm in some edge cases. > > - Even after masking the media with IFM_GMASK the result may have bits > > besides the duplex ones set so just comparing it with IFM_FDX may lead > > to false negatives. > > - Announce PAUSE support also for manually selected 1000BASE-T, but for > > all manually selected media types only in full-duplex mode. Announce > > asymmetric PAUSE support only for manually selected 1000BASE-T. > > - Simplify setting the manual configuration bits to only once after we > > have figured them all out. This also means we no longer unnecessarily > > update the hardware along the road. > > - Remove a stale comment. > > > > Looks good to me except one thing about IFM_FLAG0 handling. > It seems we don't have a way to register IFM_FLAG0 with > mii_phy_add_media() such that flag0 option is not passed to > MII_MEDIACHG handler which in turn makes rgephy4) think IFM_FLAG0 > was not specified. > Adding IFM_FLAG0 after registering available media with > mii_phy_add_mdia() seems to have no effect. Do we have to use > IFM_MAKEWIRD to handle this case? Err, no, actually that's the way the "don't care mask" of ifmedia is intended to work, i.e. when looking for a match the bits set there are ignored so it's possible to combine flags set in the "don't care mask" with all other media types and options added via IFM_MAKEWORD() when setting media. The downside is that given that f.e. in this case IFM_FLAG0 isn't added via IFM_MAKEWORD() it doesn't show up as a media option in the output of `ifconfig -m` (but ifconfig(8) probably could be made to list it somewhere). However, the problem of the previous patch was that one has to check for the flags additionally allowed via the "don't care mask" in mii_media.ifm_media rather than in mii_media.ifm_cur.ifm_media as the latter only contains the "resolved" media, i.e. the match found by ignoring the bits set in the "don't care mask". I've updated the patch at the above URL accordingly and based on my testing it now should actually work as expected. Sorry for the glitch. Marius setting From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 01:27:55 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BED991065695; Fri, 14 Jan 2011 01:27:55 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 94EAE8FC1A; Fri, 14 Jan 2011 01:27: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 p0E1Rt0Q085476; Fri, 14 Jan 2011 01:27:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0E1RtYM085472; Fri, 14 Jan 2011 01:27:55 GMT (envelope-from linimon) Date: Fri, 14 Jan 2011 01:27:55 GMT Message-Id: <201101140127.p0E1RtYM085472@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/153951: [ixgbe] Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 01:27:55 -0000 Old Synopsis: Intel 10GBase-LR Ethernet card detected as 10GBase-SR New Synopsis: [ixgbe] Intel 10GBase-LR Ethernet card detected as 10GBase-SR Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 14 01:27:27 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=153951 From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 01:30: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 CF797106566C for ; Fri, 14 Jan 2011 01:30:23 +0000 (UTC) (envelope-from jfvogel@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 8854E8FC0A for ; Fri, 14 Jan 2011 01:30:23 +0000 (UTC) Received: by gxk8 with SMTP id 8so961754gxk.13 for ; Thu, 13 Jan 2011 17:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=phJCkzS41ODsyr2Jcyem7erzVJyoHvsgC0wPPyNWWmg=; b=XRWgu+zxX53c/Rjtao+st7vkxAdRvkpeGSFFNYHHKwTGzod71MYqWMGokhQqtrJYKn CoOYlU1yDLayvh0FKcX5/+2Mu7vKvmn+Q1/nGgyWHwVJS1pOBEvYf47QWp17TYmOG5kv H4NTsPY51JiKukPdIqn9Ad8CRNW+zsbEPNs2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ftRSrY2LfXLUpyUL3irIgMtya6uEurW1bIlIa76LZqfHkHXEnzCTp7CEVOdi7jbUwW IeJblKkBBCV5EXl/TL7RAC8ajoPdW5FqJrGlH7f4BgNpz1MINJTNrA7mtZhc8obwS6s8 9Lc87eAv83kicikh8HSjfgjY0w/vlkrogsfn4= MIME-Version: 1.0 Received: by 10.151.149.13 with SMTP id b13mr597842ybo.16.1294968622519; Thu, 13 Jan 2011 17:30:22 -0800 (PST) Received: by 10.147.182.20 with HTTP; Thu, 13 Jan 2011 17:30:22 -0800 (PST) In-Reply-To: <20110113.205948.71141539.sthaug@nethelp.no> References: <20110113.195806.74699536.sthaug@nethelp.no> <20110113.204955.41688285.sthaug@nethelp.no> <20110113.205948.71141539.sthaug@nethelp.no> Date: Thu, 13 Jan 2011 17:30:22 -0800 Message-ID: From: Jack Vogel To: sthaug@nethelp.no Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, rysto32@gmail.com Subject: Re: Intel 10GBase-LR Ethernet card detected as 10GBase-SR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 01:30:24 -0000 You should be happy to know, you goaded me into doing a bit of investigation this afternoon, and I've discovered there is a way to do this on the fly... So stay tuned, I have some other issues I must handle tomorrow, but shortly I will update HEAD with updated code that will finally make this happen as it should :) Jack On Thu, Jan 13, 2011 at 11:59 AM, wrote: > > The problem is that there is no mechanism right now to report on the > > fly which optics the adapter actually has. So for the ones that can > > differ I had just chosen the most likely value. > > Yup, guessed as much. > > > If it REALLY bothers you you can change your local code :) > > Which is exactly what I did. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 01:44:15 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 283CA106566C for ; Fri, 14 Jan 2011 01:44:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D79218FC15 for ; Fri, 14 Jan 2011 01:44:14 +0000 (UTC) Received: by iyb26 with SMTP id 26so2177812iyb.13 for ; Thu, 13 Jan 2011 17:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=VHAILw6lgEAhgzpDUZlHXfDKBYAvUGt6sloB9lbsdXI=; b=ULAf9JWsXxJ3Tf+uxuD6DJ3fhMhChRhXcAj8uz26QxUpVkXDH7wcBNI9dwVcN1UX5v YVylE1JwtwPV32SM4ij0hLNwdN2tyNE/jvZvlFMMg+Yj3cfet/ocOHILNAs+LLsqYp5m dbbP9sHkyEb5RrDcWDJZBPu9TZ5KI3ZepADRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=m3sy7wmlB2XqWeZhqLF1QYw9GAWSUJJN9QyOhYI0+Kj0BglUc+GmxKzfLhgG1HqQC/ Hk2lS8VufmdyO2zJJlT/Wd+ND5mh9sjedDCiYPmuwEchi01ZB9mqU8wrJ+jJJm+8q/5z T0J5n2Q4Ij5DJYMNtuizP+B75se/OxlB+rB9Q= Received: by 10.42.176.199 with SMTP id bf7mr191125icb.82.1294969454315; Thu, 13 Jan 2011 17:44:14 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y8sm429514ica.2.2011.01.13.17.44.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Jan 2011 17:44:13 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 13 Jan 2011 17:43:39 -0800 From: Pyun YongHyeon Date: Thu, 13 Jan 2011 17:43:39 -0800 To: Marius Strobl Message-ID: <20110114014339.GF17502@michelle.cdnetworks.com> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <20110113173925.GA49356@alchemy.franken.de> <20110113212713.GC17502@michelle.cdnetworks.com> <20110114012412.GK97101@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110114012412.GK97101@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW 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 Jan 2011 01:44:15 -0000 On Fri, Jan 14, 2011 at 02:24:12AM +0100, Marius Strobl wrote: > On Thu, Jan 13, 2011 at 01:27:13PM -0800, Pyun YongHyeon wrote: > > On Thu, Jan 13, 2011 at 06:39:25PM +0100, Marius Strobl wrote: > > > On Wed, Jan 12, 2011 at 11:59:07PM +0100, Marius Strobl wrote: > > > > On Wed, Jan 12, 2011 at 01:32:08PM -0800, Pyun YongHyeon wrote: > > > > > On Wed, Jan 12, 2011 at 07:20:09PM +0300, Lev Serebryakov wrote: > > > > > > Hello, Freebsd-net. > > > > > > > > > > > > Thanks to Pyun YongHyeon, who point me at fact, that rgephy(4) used > > > > > > with re(4) does autonegotiation always and all other, who helps me > > > > > > diagnose problem! > > > > > > > > > > > > I've prepared patch, which adds tunable/sysctl for rgephy(4) which > > > > > > allows not to sue autonegotiation by this PHY (at user responsibility, > > > > > > as here is PHYs which CAN NOT live without autonegotiation). It is OFF > > > > > > by default, and in such case behavior of driver IS NOT CHANGED. > > > > > > > > > > > > But if it is set ON (non-zero value) before "media / mediopt" > > > > > > changes via "ifconfig" autonegotiation IS NOT set with 10/100Mbit > > > > > > settings. > > > > > > > > > > > > I've documented this new tunable in re(4) manpage, as here is no > > > > > > rgephy(4) manpage. > > > > > > > > > > > > Tunable is per-device, not global one. > > > > > > > > > > > > Sysctl can be set after boot, but will affect only future ifconfig > > > > > > calls, it doesn't change anything in PHY settings by itself. > > > > > > > > > > > > It allows fully manual setup on non-buggy hardware, which allows to > > > > > > use Hetzner dedicated servers with FreeBSD without additional NIC or > > > > > > gigabit connection. > > > > > > > > > > > > I've tested this patch on FreeBSD 8-STABLE on Hetzner server and it > > > > > > allows me to get full-duplex 100Mbit connection and I got 11MiB/s from > > > > > > local NFS with it. > > > > > > > > > > > > Without this patch FreeBSD is unusable on Hetzner dedicated servers > > > > > > in newer DCs (DC 13 and DC 14). > > > > > > > > > > > > Patch is attached. I think, it worths to include it to base system, > > > > > > as it allows use FreeBSD at least on one very large and popular > > > > > > hosting provider without additional costs :) > > > > > > > > > > > > > > > > Thanks for your work. After reading commit log of rgephy(4) I now > > > > > refreshed my memory. The issue came from the reverse usage case. > > > > > Suppose link partner announces auto-negotiation but you want to use > > > > > 100baseTX/full-duplex. As you know this results in duplex mismatch > > > > > and sometimes it couldn't establish a link on some RealTek PHYs. > > > > > (Now I'm not entirely sure it was caused by the specific switch or > > > > > rgephy(4) or both) > > > > > And frequently, link partner(switch) is out of control from your > > > > > domain and most switches are configured to use auto-negotiation by > > > > > default. Using auto-negotiation in manual media configuration > > > > > seemed to address the issue at that time. 1000baseT link always > > > > > requires auto-negotiation but too many switches were broken with > > > > > auto-negotiation so some switches are forced to use manual media > > > > > configuration even in 1000baseT mode. Using auto-negotiation on > > > > > rgephy(4) will also solve that case. > > > > > > > > > > So I have mixed feelings on how to handle both cases. Traditional > > > > > way, which your patch does, used in manual configuration was to > > > > > strictly honor specified manual media configuration even if it can > > > > > break in some edge cases. Programming PHYs with traditional way > > > > > shall also trigger other problems to drivers which correctly keep > > > > > track of valid link state changes. Normally speed/duplex/flow-control > > > > > changes require MAC reprogramming such that monitoring PHY's state > > > > > change is essential to modern ethernet controllers. Forcing manual > > > > > media configuration can make PHY drivers fail to report link state > > > > > changes which in turn shall make ethernet controller not to work > > > > > due to speed/duplex mismatches between PHY and MAC of ethernet > > > > > controller. re(4) does not require MAC reprogramming but many other > > > > > drivers that use regephy(4) may not work. However regphy(4) > > > > > hardware I have still seem to correctly report link state change > > > > > with manual link configuration. Not sure about old controllers > > > > > though. > > > > > > > > > > I'm under the impression that rgephy(4)'s behavior seem to confuse > > > > > users a lot since it unconditionally use auto-negotiation so I > > > > > think it's better not to use auto-negotiation at all during manual > > > > > media configuration and provides a way to use auto-negotiation in > > > > > manual media configuration if administrator want to do that. > > > > > > > > Note that even the RealTek supplied driver always triggers an > > > > auto-negotiation when manually setting the media though. However, > > > > at the same time it also comes with tons of uncommented PHY fix-up > > > > code which might be relevant for this or the previous issue. > > > > Unfortunately, I didn't get to checking whether the MAC versions > > > > in question are amongst the ones that get patched so far. > > > > In any case I don't think we can easily change this (default) > > > > behavior after such a relatively long time as it would break POLA > > > > for an unknown number of users, even if it probably shouldn't have > > > > been made the default in the first place (but again on the other > > > > hand that's what RealTek themselves also chose to do). Also apart > > > > from edges cases like the current issue the present behavior should > > > > result in a setup that "just works" so I doubt it actually results > > > > in confusion. > > > > > > > > > > Independently of DSP fixes that might or might not fixes these > > > issues I agree that there should be a way to turn off the use of > > > auto-negotiation along with manual media configuration in rgephy(4) > > > though. IMO there are some bugs and issues with the patch provided > > > by Lev however: > > > - It fails to reject enabling of PAUSE advertisement when not > > > using auto-negotiation. > > > - It has no effect on 1000base-T; as you pointed out some switches > > > also require manual selection (without auto-negotiation) here as > > > a workaround. > > > - I don't like the idea of growing a tunable when the same can be > > > achieved via ifmedia support. > > > > > > Therefore I'd like to commit the following patch (requires sources > > > from head and stable branches), unless there's an objection or it > > > doesn't work as expected: > > > http://people.freebsd.org/~marius/rgephy.c.diff > > > > > > With this in place you should be able to manually set full-duplex > > > with auto-negotiation turned off via: > > > ifconfig re0 media 100baseTX mediaopt full-duplex,flag0 > > > > > > A full list of what that patch does is: > > > - Allow IFM_FLAG0 to be set indicating that auto-negotiation with manual > > > configuration, which is used to work around issues with certain setups > > > (see r161237) by default, should not be triggered as it may in turn > > > cause harm in some edge cases. > > > - Even after masking the media with IFM_GMASK the result may have bits > > > besides the duplex ones set so just comparing it with IFM_FDX may lead > > > to false negatives. > > > - Announce PAUSE support also for manually selected 1000BASE-T, but for > > > all manually selected media types only in full-duplex mode. Announce > > > asymmetric PAUSE support only for manually selected 1000BASE-T. > > > - Simplify setting the manual configuration bits to only once after we > > > have figured them all out. This also means we no longer unnecessarily > > > update the hardware along the road. > > > - Remove a stale comment. > > > > > > > Looks good to me except one thing about IFM_FLAG0 handling. > > It seems we don't have a way to register IFM_FLAG0 with > > mii_phy_add_media() such that flag0 option is not passed to > > MII_MEDIACHG handler which in turn makes rgephy4) think IFM_FLAG0 > > was not specified. > > Adding IFM_FLAG0 after registering available media with > > mii_phy_add_mdia() seems to have no effect. Do we have to use > > IFM_MAKEWIRD to handle this case? > > Err, no, actually that's the way the "don't care mask" of ifmedia > is intended to work, i.e. when looking for a match the bits set > there are ignored so it's possible to combine flags set in the > "don't care mask" with all other media types and options added > via IFM_MAKEWORD() when setting media. The downside is that given > that f.e. in this case IFM_FLAG0 isn't added via IFM_MAKEWORD() it > doesn't show up as a media option in the output of `ifconfig -m` > (but ifconfig(8) probably could be made to list it somewhere). > However, the problem of the previous patch was that one has to > check for the flags additionally allowed via the "don't care mask" > in mii_media.ifm_media rather than in mii_media.ifm_cur.ifm_media > as the latter only contains the "resolved" media, i.e. the match > found by ignoring the bits set in the "don't care mask". I've Hmm, that's confusing but I see your point. :-) > updated the patch at the above URL accordingly and based on my > testing it now should actually work as expected. Sorry for the > glitch. I can confirm your latest patch works as expected. Thanks for the patch! > > Marius > > setting From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 05:04: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 4A2071065670 for ; Fri, 14 Jan 2011 05:04:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id BDE0D8FC1D for ; Fri, 14 Jan 2011 05:04:49 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0E54jxW011153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jan 2011 16:04:45 +1100 Date: Fri, 14 Jan 2011 16:04:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jack Vogel In-Reply-To: Message-ID: <20110114155704.D27511@besplex.bde.org> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Charles Owens , Robin Sommer , freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 05:04:50 -0000 On Thu, 13 Jan 2011, Jack Vogel wrote: > Polling has seemed to me to be a way around other problems, problems that > these days > no longer exist. I remember back in the FreeBSD 6 days having interrupt > problems which > of course also led to watchdogs. Polling got rid of that. But now there are > dedicated > MULTIPLE interrupts by using MSIX, so that reason for polling is gone. > > Of course there can still be advantages, reducing interrupts and hence > context switches, > which is why the Linux approach does what it does. Polling helps, if at all, mainly by reducing interrupts and otherwise dropping packets (or for tx, not sending packets promptly, so that the system doesn't become overloaded attempting to not drop packets and to send packets promptly, according to interrupts). The last thing an overloaded system wants is MORE interrupts to tell it that it is overloaded :-). Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 06:39:15 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 78611106564A for ; Fri, 14 Jan 2011 06:39:15 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2148FC1A for ; Fri, 14 Jan 2011 06:39:15 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [10.1.2.24] ([173.200.187.194]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LF0004PE2HD1U20@asmtp028.mac.com> for freebsd-net@freebsd.org; Thu, 13 Jan 2011 22:39:14 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-14_03:2011-01-14, 2011-01-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=2 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1101130233 From: Chuck Swiger In-reply-to: <20110114154326.E27511@besplex.bde.org> Date: Thu, 13 Jan 2011 22:39:13 -0800 Message-id: <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1082) Cc: freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 06:39:15 -0000 On Jan 13, 2011, at 8:54 PM, Bruce Evans wrote: >> To quote an earlier post: >> >> "Polling mode operation generally performs better when using older 100Mbs ethernet NICs which do not support interrupt mitigation and various capabilities like TSO4; gigabit ethernet NICs are smarter hardware and can generally outperform polling mode." > > I think "older 100Mbs" means "low-end 100Mbps". Mega-bit-seconds are > strange units, and 100Mbps NICs with enough buffers don't benefit much > from polling mode. Insert a "/" into "Mbs" to get "Mb/s" if it makes you happier; I understand that some folks insist upon adding a hyphen to "anal-retentive" for similarly pedantic reasons. > They even avoid dropping the *nix newline character On a good day, my MUA sends "Content-type: text/plain; format=flowed" and should contain line breaks following the 80-character-per-line Usenet conventions, which modern MUAs might well reassemble based upon the user's window size. If it is being re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well, that lies beyond my control. >> Polling is well-suited for dedicated routers, firewalls, and other boxes which have a constant flow of traffic and for which you are looking for well-bounded latency. End-user machines, servers, and the like which have bursty traffic tend to do better using normal NIC operation, especially if you have decent gigabit NICs which support interrupt mitigation and have larger buffers than the old 100Mbs NICs had. > > I never saw any problem with interrupt mode fxp 100 Mbps NICs. Agreed, but fxp's were among the very best of that era of NICs; some of them even supported firmware which implemented an early form of interrupt moderation. For other NICs of that era, the benefits of polling mode compared to interrupt-based operation tended to be greater than they were for fxp's. > They have enough buffers (128 for each of tx and rx IIRC). The only thing > polling mode gave for them was lower latency, but this cost enabling > polling in the idle loop, which wastes 100% of at least 1 CPU and some > power. Without polling in idle, polling gives very high latency (even > worse than low-quality interrupt moderation does). Sure-- there are circumstances where a machine would always have traffic to process, for which idle polling was beneficial to enable. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 07:02: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 16807106566C for ; Fri, 14 Jan 2011 07:02:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 231D58FC16 for ; Fri, 14 Jan 2011 07:02:07 +0000 (UTC) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0E4sgt8000524 for ; Fri, 14 Jan 2011 15:54:42 +1100 Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0E4sbL9004858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jan 2011 15:54:38 +1100 Date: Fri, 14 Jan 2011 15:54:37 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Chuck Swiger In-Reply-To: <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> Message-ID: <20110114154326.E27511@besplex.bde.org> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Charles Owens , freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 07:02:09 -0000 On Thu, 13 Jan 2011, Chuck Swiger wrote: > On Jan 13, 2011, at 1:42 PM, Charles Owens wrote: >> This is very good news overall, in that we can certainly disable polling for igb. This begs the question, though, as to whether polling is recommended these days at all for em/igb NICs... or even in general. From other conversations we've seen there seems to be some general debate about this. In testing we've done in the past (circa 7.0) there certainly seemed to be benefit to using this feature. What are your thoughts about this? > > To quote an earlier post: > > "Polling mode operation generally performs better when using older 100Mbs ethernet NICs which do not support interrupt mitigation and various capabilities like TSO4; gigabit ethernet NICs are smarter hardware and can generally outperform polling mode." I think "older 100Mbs" means "low-end 100Mbps". Mega-bit-seconds are strange units, and 100Mbps NICs with enough buffers don't benefit much from polling mode. They even avoid dropping the *nix newline character. > Polling is well-suited for dedicated routers, firewalls, and other boxes which have a constant flow of traffic and for which you are looking for well-bounded latency. End-user machines, servers, and the like which have bursty traffic tend to do better using normal NIC operation, especially if you have decent gigabit NICs which support interrupt mitigation and have larger buffers than the old 100Mbs NICs had. I never saw any problem with interrupt mode fxp 100 Mbps NICs. They have enough buffers (128 for each of tx and rx IIRC). The only thing polling mode gave for them was lower latency, but this cost enabling polling in the idle loop, which wastes 100% of at least 1 CPU and some power. Without polling in idle, polling gives very high latency (even worse than low-quality interrupt moderation does). Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 08:39: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 1E190106564A for ; Fri, 14 Jan 2011 08:39:40 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 54E018FC19 for ; Fri, 14 Jan 2011 08:39:38 +0000 (UTC) Received: (qmail 91561 invoked from network); 14 Jan 2011 08:39:36 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 14 Jan 2011 08:39:36 -0000 Date: Fri, 14 Jan 2011 09:39:36 +0100 (CET) Message-Id: <20110114.093936.74681829.sthaug@nethelp.no> To: cswiger@mac.com From: sthaug@nethelp.no In-Reply-To: <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> References: <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org> <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 08:39:40 -0000 > > They have enough buffers (128 for each of tx and rx IIRC). The only thing > > polling mode gave for them was lower latency, but this cost enabling > > polling in the idle loop, which wastes 100% of at least 1 CPU and some > > power. Without polling in idle, polling gives very high latency (even > > worse than low-quality interrupt moderation does). > > Sure-- there are circumstances where a machine would always have traffic to process, for which idle polling was beneficial to enable. I have a couple of servers with Broadcom (bge) GigE interfaces. These servers became completely unresponsive/unusable at high network traffic (presumably due to the interrupt processing) but were able to handle the same traffic with no problems after switching to polling. This was in the 7.0 timeframe. I still have the same servers/interfaces running with polling, but now at 7.3. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 09:05:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7186E1065697 for ; Fri, 14 Jan 2011 09:05:33 +0000 (UTC) (envelope-from przemyslaw@frasunek.com) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFBE8FC1B for ; Fri, 14 Jan 2011 09:05:32 +0000 (UTC) Received: from [IPv6:2a02:2928:a:ffff:5099:2f2e:7034:e41e] (unknown [IPv6:2a02:2928:a:ffff:5099:2f2e:7034:e41e]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id D357E23944C for ; Fri, 14 Jan 2011 10:05:30 +0100 (CET) Message-ID: <4D3011DB.9050900@frasunek.com> Date: Fri, 14 Jan 2011 10:05:31 +0100 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pl; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:05:33 -0000 Hello, I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and runs FreeBSD 7.3-RELEASE. I'm experiencing stability issues related to Netgraph. None of above routers can survive more than 20-30 days of uptime under typical load. There are different flavors of kernel panics, but all are somehow related to netgraph. Typical backtraces follow: (kgdb) bt #1 0xc0836ac7 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc0836d99 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:574 #3 0xc0b5ef1c in trap_fatal (frame=0xe7ce6820, eva=152) at ../../../i386/i386/trap.c:950 #4 0xc0b5f1a0 in trap_pfault (frame=0xe7ce6820, usermode=0, eva=152) at ../../../i386/i386/trap.c:863 #5 0xc0b5fb95 in trap (frame=0xe7ce6820) at ../../../i386/i386/trap.c:541 #6 0xc0b42e7b in calltrap () at ../../../i386/i386/exception.s:166 #7 0xc5f486b9 in ng_name2noderef (here=0xc62a0b80, name=0xe7ce6894 "ng366") at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:896 #8 0xc5f488cc in ng_path2noderef (here=0xc62a0b80, address=0xcc4c2110 "ng366:", destp=0xe7ce6ac8, lasthook=0xe7ce6ac4) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1673 #9 0xc5f48cc0 in ng_address_path (here=0xc62a0b80, item=0xc5e42ae0, address=0xcc4c2110 "ng366:", retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3488 #10 0xc5f431d3 in ngc_send (so=0xc5b53340, flags=0, m=0xd4c6cb00, addr=0xccac9780, control=0x0, td=0xc65a2b40) at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:288 #11 0xc0894bfa in sosend_generic (so=0xc5b53340, addr=0xccac9780, uio=0xe7ce6be8, top=0xd4c6cb00, control=0x0, flags=0, td=0xc65a2b40) at ../../../kern/uipc_socket.c:1243 #12 0xc0890a3f in sosend (so=0xc5b53340, addr=0xccac9780, uio=0xe7ce6be8, top=0x0, control=0x0, flags=0, td=0xc65a2b40) at ../../../kern/uipc_socket.c:1285 #13 0xc0897fa6 in kern_sendit (td=0xc65a2b40, s=5, mp=0xe7ce6c64, flags=0, control=0x0, segflg=UIO_USERSPACE) at ../../../kern/uipc_syscalls.c:805 #14 0xc089b181 in sendit (td=0xc65a2b40, s=5, mp=0xe7ce6c64, flags=0) at ../../../kern/uipc_syscalls.c:742 #15 0xc089b298 in sendto (td=0xc65a2b40, uap=0xe7ce6cfc) at ../../../kern/uipc_syscalls.c:857 #16 0xc0b5f4f5 in syscall (frame=0xe7ce6d38) at ../../../i386/i386/trap.c:1101 #17 0xc0b42ee0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:262 #18 0x00000033 in ?? () (kgdb) frame 7 #7 0xc5f486b9 in ng_name2noderef (here=0xc62a0b80, name=0xe7ce6894 "ng366") at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:896 896 LIST_FOREACH(node, &ng_name_hash[hash], nd_nodes) { (kgdb) list 891 } 892 893 /* Find node by name */ 894 NG_NAMEHASH(name, hash); 895 mtx_lock(&ng_namehash_mtx); 896 LIST_FOREACH(node, &ng_name_hash[hash], nd_nodes) { 897 if (NG_NODE_IS_VALID(node) && 898 (strcmp(NG_NODE_NAME(node), name) == 0)) { 899 break; 900 } (kgdb) print node $1 = 0x74 (kgdb) print ng_name_hash $3 = {{lh_first = 0xcbab6200}, {lh_first = 0x0}, {lh_first = 0xc6538300}, { lh_first = 0xc67e6400}, {lh_first = 0xc6538700}, {lh_first = 0xca2abc00}, { lh_first = 0xc66d5000}, {lh_first = 0xca8f9200}, {lh_first = 0xca815580}, { lh_first = 0xc62a2180}, {lh_first = 0xca2ab180}, {lh_first = 0xc6af7d00}, { lh_first = 0xcbe09a00}, {lh_first = 0xca81b800}, {lh_first = 0xc5b4e980}, { lh_first = 0xcbc1f080}, {lh_first = 0xca2a5480}, {lh_first = 0xc672b580}, { lh_first = 0xcbdb1e80}, {lh_first = 0xcc772c00}, {lh_first = 0xc6a99980}, { lh_first = 0xc629d600}, {lh_first = 0xc6733000}, {lh_first = 0xca967800}, { lh_first = 0xc5b3b780}, {lh_first = 0xc629c280}, {lh_first = 0xc6396980}, { lh_first = 0xc6a5f300}, {lh_first = 0xc5bf2280}, {lh_first = 0xcc5ebe80}, { lh_first = 0xc5e0a400}, {lh_first = 0xc6608100}, {lh_first = 0xc6520e00}, { lh_first = 0xc6642680}, {lh_first = 0xca8f7b80}, {lh_first = 0xcbd9ce80}, { lh_first = 0xca81b380}, {lh_first = 0x0} , { lh_first = 0xc67b8080}, {lh_first = 0xc6455c80}, {lh_first = 0xc652a380}, { lh_first = 0xc6a74780}, {lh_first = 0xc62d8400}, {lh_first = 0xcc154400}, { lh_first = 0xca852b80}, {lh_first = 0xcc351580}, {lh_first = 0xc6396a80}, { lh_first = 0xc66f9580}, {lh_first = 0xc58c8e00}, {lh_first = 0xcc01a000}, { lh_first = 0xc6614e80}, {lh_first = 0xc6750800}, {lh_first = 0xcc154e80}, { lh_first = 0xcc32f080}, {lh_first = 0xcbb10e80}, {lh_first = 0xcc1e3700}, { lh_first = 0xcc020280}, {lh_first = 0xcc75ad00}, {lh_first = 0xca901b00}, { lh_first = 0xcc3c8380}, {lh_first = 0xcbd90580}, {lh_first = 0xcbb0c480}, { lh_first = 0xcbed1300}, {lh_first = 0xc6644480}, {lh_first = 0xcc02ca80}, { lh_first = 0xcc0d1980}, {lh_first = 0xcc35e200}, {lh_first = 0xcc0dc200}, { lh_first = 0xca9dc200}, {lh_first = 0xcbecf880}, {lh_first = 0xcc065080}, { lh_first = 0xcc47b280}, {lh_first = 0xcc722a80}, {lh_first = 0xcc28cd80}, { lh_first = 0xcbd73400}, {lh_first = 0xcbf76b00}, {lh_first = 0xcbbfc280}, { lh_first = 0xc629c800}, {lh_first = 0xc6700200}, {lh_first = 0x0}, { lh_first = 0x0}, {lh_first = 0xc5e0b700}, {lh_first = 0xc672a200}, { lh_first = 0xc62a2080}, {lh_first = 0x0}, {lh_first = 0xc673fc80}, { lh_first = 0xc5bf2600}, {lh_first = 0xca969800}, {lh_first = 0xc6aa6700}, { lh_first = 0xc6750b80}, {lh_first = 0xcc0bc200}, {lh_first = 0xcbeead80}, { lh_first = 0xcc484e00}, {lh_first = 0xcbae6900}, {lh_first = 0xcbbef800}, { lh_first = 0xcc797500}, {lh_first = 0xc65f3d80}, {lh_first = 0xcbe95900}, { lh_first = 0xcba8fb80}, {lh_first = 0xcbdb1580}, {lh_first = 0xcc75b080}, { lh_first = 0xcbd7fb80}, {lh_first = 0xcc75db80}, {lh_first = 0xc5e59500}, { lh_first = 0xcbd6fb00}, {lh_first = 0xc6a7ed00}, {lh_first = 0xcbe0bc80}, { lh_first = 0xcc3c1180}, {lh_first = 0xc7486d00}, {lh_first = 0xcba93880}, { lh_first = 0xcc0c6000}, {lh_first = 0x0}, {lh_first = 0x0}, { lh_first = 0x0}, {lh_first = 0x0}, {lh_first = 0x0}} Another one: (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0836ac7 in boot (howto=260) at ../../../kern/kern_shutdown.c:418 #2 0xc0836d99 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:574 #3 0xc0b5ef1c in trap_fatal (frame=0xc53dbaac, eva=36) at ../../../i386/i386/trap.c:950 #4 0xc0b5f1a0 in trap_pfault (frame=0xc53dbaac, usermode=0, eva=36) at ../../../i386/i386/trap.c:863 #5 0xc0b5fb95 in trap (frame=0xc53dbaac) at ../../../i386/i386/trap.c:541 #6 0xc0b42e7b in calltrap () at ../../../i386/i386/exception.s:166 #7 0xc5f39d95 in ng_address_hook (here=0x0, item=0xc66619f0, hook=0xcc87f680, retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3456 #8 0xc5f339ff in ngd_send (so=0xc5b68680, flags=0, m=0xd58aec00, addr=0xc666d870, control=0x0, td=0xc5910000) at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:445 #9 0xc0894bfa in sosend_generic (so=0xc5b68680, addr=0xc666d870, uio=0xc53dbbe8, top=0xd58aec00, control=0x0, flags=0, td=0xc5910000) at ../../../kern/uipc_socket.c:1243 #10 0xc0890a3f in sosend (so=0xc5b68680, addr=0xc666d870, uio=0xc53dbbe8, top=0x0, control=0x0, flags=0, td=0xc5910000) at ../../../kern/uipc_socket.c:1285 #11 0xc0897fa6 in kern_sendit (td=0xc5910000, s=6, mp=0xc53dbc64, flags=0, control=0x0, segflg=UIO_USERSPACE) at ../../../kern/uipc_syscalls.c:805 #12 0xc089b181 in sendit (td=0xc5910000, s=6, mp=0xc53dbc64, flags=0) at ../../../kern/uipc_syscalls.c:742 #13 0xc089b298 in sendto (td=0xc5910000, uap=0xc53dbcfc) at ../../../kern/uipc_syscalls.c:857 #14 0xc0b5f4f5 in syscall (frame=0xc53dbd38) at ../../../i386/i386/trap.c:1101 #15 0xc0b42ee0 in Xint0x80_syscall () at ../../../i386/i386/exception.s:262 #16 0x00000033 in ?? () (kgdb) frame 7 #7 0xc5f39d95 in ng_address_hook (here=0x0, item=0xc66619f0, hook=0xcc87f680, retaddr=0) at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3456 3456 if ((hook == NULL) || (kgdb) list 3451 * Quick sanity check.. 3452 * Since a hook holds a reference on it's node, once we know 3453 * that the peer is still connected (even if invalid,) we know 3454 * that the peer node is present, though maybe invalid. 3455 */ 3456 if ((hook == NULL) || 3457 NG_HOOK_NOT_VALID(hook) || 3458 NG_HOOK_NOT_VALID(peer = NG_HOOK_PEER(hook)) || 3459 NG_NODE_NOT_VALID(peernode = NG_PEER_NODE(hook))) { 3460 NG_FREE_ITEM(item); (kgdb) x/i $eip 0xc5f39d95 : testb $0x1,0x24(%edi) (kgdb) info reg edi edi 0x0 0 (kgdb) print *hook $2 = {hk_name = "b99", '\0' , hk_private = 0xc5b27140, hk_flags = 0, hk_refs = 2, hk_type = 0, hk_peer = 0xc647bc00, hk_node = 0xc592d500, hk_hooks = {le_next = 0xc69a1b00, le_prev = 0xc6991238}, hk_rcvmsg = 0, hk_rcvdata = 0} Besides of that, I had interesting issue, when one of misconfigured customer's router tried to establish several PPPoE sessions per second. Such "stress test" caused multiple kernel panics, each occuring after few minutes of uptime. I have no backtrace, but I can remember, that it was similar to one of above. I'll be grateful for any advices. From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 09:28:44 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 788B41065670 for ; Fri, 14 Jan 2011 09:28:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 161278FC1E for ; Fri, 14 Jan 2011 09:28:43 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0E9Se0g018217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jan 2011 20:28:42 +1100 Date: Fri, 14 Jan 2011 20:28:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: sthaug@nethelp.no In-Reply-To: <20110114.093936.74681829.sthaug@nethelp.no> Message-ID: <20110114195049.I28551@besplex.bde.org> References: <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org> <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> <20110114.093936.74681829.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 09:28:44 -0000 On Fri, 14 Jan 2011 sthaug@nethelp.no wrote: >>> They have enough buffers (128 for each of tx and rx IIRC). The only thing >>> polling mode gave for them was lower latency, but this cost enabling >>> polling in the idle loop, which wastes 100% of at least 1 CPU and some >>> power. Without polling in idle, polling gives very high latency (even >>> worse than low-quality interrupt moderation does). >> >> Sure-- there are circumstances where a machine would always have traffic to process, for which idle polling was beneficial to enable. > > I have a couple of servers with Broadcom (bge) GigE interfaces. These > servers became completely unresponsive/unusable at high network traffic > (presumably due to the interrupt processing) but were able to handle the > same traffic with no problems after switching to polling. This was in > the 7.0 timeframe. > > I still have the same servers/interfaces running with polling, but now > at 7.3. I had the opposite experience with a Broadcom 5701 (old but not low-end bge for PCI-X on PCI-33). Some mostly-uncommitted work on its interrupt handling improved its latency from 100uS to 50uS (average for best case) and its throughput from 240000 to 640000 tiny packets/second. -current should be at least 2/3 as good. Its polling mode saturated at 400000 tiny packets/second for tx with poll-in-idle and at about half that without. Rx started dropping packets at about the same thresholds that tx saturated. The reasons for more than 240kpps not working with polling are especially easy to understand for rx. Most bge's have a 512 entry rx ring, and FreBSD bge only enables 256 entries in it. Poll this at 1 KHz and you are sure to drop packets above 256 kpps, and likely to above 240 kpps. Higher polling rates and polling in idle allow higher packet rates without loss, but for some reason polling saturates before interrupt handling. Since I don't believe in polling, I didn't try to fix this (except to use the whole rx ring). I think polling consumes resources which are better used for doing work. Always CPU resources, but here also NIC resources. This bge works even better with larger packets (1500 bytes; not so good with 9000). Interrupt load is significant at 640 kpps but not at the 81 kpps which is the maximum for 1500-byte packets. OTOH, with a Broadcon 5705+ (not so old but low-end bge for PCI-33), interrupt moderation (host coelescing in bge-speak) is broken. It interrupts immediately (?) once per packet despite accepting the programming to interrupt once per many packets or after many microseconds. This results in about 1/6 of the performance of the 5701 (1/3 of the performance to saturate twice as many CPUs). Polling might help, but I tried it even less on this NIC than the other. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 10:12:22 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 6C01F106564A for ; Fri, 14 Jan 2011 10:12:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 050B28FC08 for ; Fri, 14 Jan 2011 10:12:21 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0EACISA025113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Jan 2011 21:12:19 +1100 Date: Fri, 14 Jan 2011 21:12:18 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Chuck Swiger In-Reply-To: <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> Message-ID: <20110114204810.Y28741@besplex.bde.org> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org> <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:12:22 -0000 On Thu, 13 Jan 2011, Chuck Swiger wrote: > On Jan 13, 2011, at 8:54 PM, Bruce Evans wrote: >>> To quote an earlier post: >>> >>> "Polling mode operation generally performs better when using older 100Mbs ethernet NICs which do not support interrupt mitigation and various capabilities like TSO4; gigabit ethernet NICs are smarter hardware and can generally outperform polling mode." >> >> I think "older 100Mbs" means "low-end 100Mbps". Mega-bit-seconds are >> strange units, and 100Mbps NICs with enough buffers don't benefit much >> from polling mode. > > Insert a "/" into "Mbs" to get "Mb/s" if it makes you happier; I understand that some folks insist upon adding a hyphen to "anal-retentive" for similarly pedantic reasons. > >> They even avoid dropping the *nix newline character > > On a good day, my MUA sends "Content-type: text/plain; format=flowed" and should contain line breaks following the 80-character-per-line Usenet conventions, which modern MUAs might well reassemble based upon the user's window size. If it is being re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well, that lies beyond my control. Strangely, my MUA is sending format=flowed, etc., but mails received from you don't have it. So when I reply to you and Cc me, then there are enough newlines in the now-doubly-quoted original in the Cc. format=flowed apparently even fixes up the quotes, so there are enough quotes too. But I don't like this. Letting the MUA change the format will mangle source code, diffs and some types of quotes. It would take large markup to keep source code separate, and larger MUAs to understand the difference between it and natural language. I normally manually quote source code and diffs using "% ", but cvs commit mail generators are not so careful and this causes problems with some MUAs. [fxp's best of 100 Mbps NICs] >> They have enough buffers (128 for each of tx and rx IIRC). The only thing >> polling mode gave for them was lower latency, but this cost enabling >> polling in the idle loop, which wastes 100% of at least 1 CPU and some >> power. Without polling in idle, polling gives very high latency (even >> worse than low-quality interrupt moderation does). > Here I can see some quote mangling, but mostly by my mailer: - replies from you have my single ">" quoting preserved for adding one ">", giving ">>". I think newlines line structure is preserved too. - the Cc comes back with ">>" expanded to "> >" and another "> " for another level. A few levels and there is no space for anything but quotes. - something is not removing empty quoted lines at the end of quoted material. One is visible in the above if it doesn't get mangled in the reply. This is not as bad as adding extra empty lines between quotes. > Sure-- there are circumstances where a machine would always have traffic to process, for which idle polling was beneficial to enable. Yes, although polling was designed more to do the opposite -- to reduce overheads by handling larger number of packets at time. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 10:41: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 CD2D91065693 for ; Fri, 14 Jan 2011 10:41:14 +0000 (UTC) (envelope-from lev@serebryakov.spb.ru) Received: from ftp.translate.ru (ftp.translate.ru [80.249.188.42]) by mx1.freebsd.org (Postfix) with ESMTP id 876D78FC18 for ; Fri, 14 Jan 2011 10:41:14 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 79D6313DF5F; Fri, 14 Jan 2011 13:41:13 +0300 (MSK) Date: Fri, 14 Jan 2011 13:41:09 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <178613186.20110114134109@serebryakov.spb.ru> To: Marius Strobl In-Reply-To: <20110114012412.GK97101@alchemy.franken.de> References: <36074996.20110112192009@serebryakov.spb.ru> <20110112213208.GD12920@michelle.cdnetworks.com> <20110112225907.GA44318@alchemy.franken.de> <20110113173925.GA49356@alchemy.franken.de> <20110113212713.GC17502@michelle.cdnetworks.com> <20110114012412.GK97101@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Pyun YongHyeon , freebsd-net@freebsd.org Subject: Re: [patch] re(4) problems on networks with disabled autonegotiation "solver" (WAS: Juniper e3k with ports limitied to...) -- REQUEST FOR REVIEW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 10:41:14 -0000 Hello, Marius. You wrote 14 =FF=ED=E2=E0=F0=FF 2011 =E3., 4:24:12: > found by ignoring the bits set in the "don't care mask". I've > updated the patch at the above URL accordingly and based on my > testing it now should actually work as expected. Sorry for the > glitch. Yes, it works for me. Only one note: I think, it is good idea to document this flag in re(4). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 11:05: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 8DBB2106566C for ; Fri, 14 Jan 2011 11:05:29 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B36F08FC0C for ; Fri, 14 Jan 2011 11:05:28 +0000 (UTC) Received: (qmail 13001 invoked from network); 14 Jan 2011 11:05:26 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 14 Jan 2011 11:05:26 -0000 Date: Fri, 14 Jan 2011 12:05:26 +0100 (CET) Message-Id: <20110114.120526.41705579.sthaug@nethelp.no> To: brde@optusnet.com.au From: sthaug@nethelp.no In-Reply-To: <20110114195049.I28551@besplex.bde.org> References: <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> <20110114.093936.74681829.sthaug@nethelp.no> <20110114195049.I28551@besplex.bde.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 11:05:29 -0000 > > I have a couple of servers with Broadcom (bge) GigE interfaces. These > > servers became completely unresponsive/unusable at high network traffic > > (presumably due to the interrupt processing) but were able to handle the > > same traffic with no problems after switching to polling. This was in > > the 7.0 timeframe. > > > > I still have the same servers/interfaces running with polling, but now > > at 7.3. > > I had the opposite experience with a Broadcom 5701 (old but not low-end > bge for PCI-X on PCI-33). ... > OTOH, with a Broadcon 5705+ (not so old but low-end bge for PCI-33), > interrupt moderation (host coelescing in bge-speak) is broken. It > interrupts immediately (?) once per packet despite accepting the > programming to interrupt once per many packets or after many microseconds. > This results in about 1/6 of the performance of the 5701 (1/3 of the > performance to saturate twice as many CPUs). Polling might help, but > I tried it even less on this NIC than the other. In my case this is Broadcom BCM5721: bge0@pci0:4:0:0: class=0x020000 card=0x01b61028 chip=0x165914e4 rev=0x11 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Gigabit Ethernet PCI Express (BCM5721)' class = network subclass = ethernet I have no idea whether there are known bugs in interrupt moderation for this controller. The change in behavior when switching from interrupts to polling was extremely noticeable. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 12:46: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 03270106566B for ; Fri, 14 Jan 2011 12:46:12 +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 B4BCE8FC14 for ; Fri, 14 Jan 2011 12:46:11 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:6d90:8d21:568f:4366] ([IPv6:2607:f3e0:0:4:6d90:8d21:568f:4366]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p0ECk6Fw022393 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 14 Jan 2011 07:46:07 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4D30458D.30007@sentex.net> Date: Fri, 14 Jan 2011 07:46:05 -0500 From: Mike Tancsa 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: Przemyslaw Frasunek References: <4D3011DB.9050900@frasunek.com> In-Reply-To: <4D3011DB.9050900@frasunek.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 12:46:12 -0000 On 1/14/2011 4:05 AM, Przemyslaw Frasunek wrote: > Hello, > > I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE > concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and > runs FreeBSD 7.3-RELEASE. > > I'm experiencing stability issues related to Netgraph. None of above routers can > survive more than 20-30 days of uptime under typical load. There are different > flavors of kernel panics, but all are somehow related to netgraph. Typical > backtraces follow I also have stability issues on RELENG_8. http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 ---Mike From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 13:21: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 9ECA5106564A for ; Fri, 14 Jan 2011 13:21:01 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [IPv6:2a01:238:42c7:9a00::2]) by mx1.freebsd.org (Postfix) with ESMTP id 270308FC20 for ; Fri, 14 Jan 2011 13:21:01 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 3EC9A5C47; Fri, 14 Jan 2011 14:21:00 +0100 (CET) X-Virus-Scanned: amavisd-new at solomo.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kGS+qQFkDxj3; Fri, 14 Jan 2011 14:20:57 +0100 (CET) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 47FDE5C3D; Fri, 14 Jan 2011 14:20:57 +0100 (CET) Message-ID: <4D304DB8.8080904@smeets.im> Date: Fri, 14 Jan 2011 14:20:56 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kevin Lo References: <200912071020.nB7AK77I023054@freefall.freebsd.org> <4B1CDEE5.6080507@incunabulum.net> <3e2b8dd90912070305t6ffc08a6gf7acd8890d028854@mail.gmail.com> <4B1D07C3.6090005@incunabulum.net> <3e2b8dd90912080114x31d962acqf2c8a360e7b5a83d@mail.gmail.com> <4B1E1EF0.8040503@incunabulum.net> <3e2b8dd90912080155s544a7a50j17882b35f1343750@mail.gmail.com> <4B1E2574.8010704@incunabulum.net> <3e2b8dd90912080247s247bd878ud9fe4b234ff83f84@mail.gmail.com> <3e2b8dd90912090037v6c8e13e1v869471d4e03ecfd5@mail.gmail.com> <1293809938.2126.12.camel@nsl> <4D1E002C.4080300@smeets.im> In-Reply-To: <4D1E002C.4080300@smeets.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Bruce Simpson , serg vasilyev , Andriy Syrovenko Subject: Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 13:21:01 -0000 On 31.12.10 17:09, Florian Smeets wrote: > On 31.12.10 16:38, Kevin Lo wrote: >> This issue is easily reproduced on 9.0 -CURRENT as well. >> I got kernel panic after running mrouted, igmpproxy, or xorp. > > My router is still running r215262 from mid November, without problems > when watching IPTV using igmpproxy (latest git version). > > I'll try updating this week and report back. > I finally found some time to update my router. It is now running a kernel and world from Jan. 10. and i still do not have any issues watching TV, i tried igmpproxy from ports and the latest git version, both work fine. My upstream interface is a vlan interface, perhaps that makes a difference? -- Florian Smeets From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 13:48: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 C950F10656A7 for ; Fri, 14 Jan 2011 13:48:37 +0000 (UTC) (envelope-from pch-b6B5344D9@u-1.phicoh.com) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by mx1.freebsd.org (Postfix) with ESMTP id 24BCF8FC19 for ; Fri, 14 Jan 2011 13:48:35 +0000 (UTC) Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1PdjrL-0001UiC; Fri, 14 Jan 2011 14:38 +0100 Message-Id: To: freebsd-net@freebsd.org From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com Date: Fri, 14 Jan 2011 14:38:25 +0100 Subject: Added AI_V4MAPPED and AI_ALL to getaddrinfo.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 13:48:37 -0000 Hi, I'm using FreeBSD library code for some other project and I needed AI_V4MAPPED and AI_ALL for getaddrinfo. So I wrote some code to support these features. Is anybody interested in this? I can give you patch to an older version of getaddrinfo.c. It needs some work, in particular restoring some partial support for AI_V4MAPPED and AI_ALL that was removed a couple of years ago. From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 14:56: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 91B57106564A for ; Fri, 14 Jan 2011 14:56:45 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id BAA6E8FC08 for ; Fri, 14 Jan 2011 14:56:44 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0EEucpg002884; Fri, 14 Jan 2011 20:56:38 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D306421.1050501@rdtc.ru> Date: Fri, 14 Jan 2011 20:56:33 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> In-Reply-To: <4D30458D.30007@sentex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek Subject: Re: Netgraph/mpd5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 14:56:45 -0000 On 14.01.2011 18:46, Mike Tancsa wrote: >> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE >> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and >> runs FreeBSD 7.3-RELEASE. >> >> I'm experiencing stability issues related to Netgraph. None of above routers can >> survive more than 20-30 days of uptime under typical load. There are different >> flavors of kernel panics, but all are somehow related to netgraph. Typical >> backtraces follow > > I also have stability issues on RELENG_8. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 I also have very loaded mpd/PPPoE servers that panic all the time: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/153255 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/153671 From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 15:28: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 CD3C81065670 for ; Fri, 14 Jan 2011 15:28:50 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer.dco.penx.com [174.46.214.114]) by mx1.freebsd.org (Postfix) with ESMTP id A67E18FC1B for ; Fri, 14 Jan 2011 15:28:50 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.4/8.14.4) with ESMTP id p0EEYRCU045439 for ; Fri, 14 Jan 2011 07:34:27 -0700 (MST) (envelope-from freebsd@penx.com) Date: Fri, 14 Jan 2011 07:34:27 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Looking for hints re 802.1X wired X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 15:28:50 -0000 I am trouble with 802.1x wired and I am wondering whether there is some required characteristic of the Ethernet driver. AFAICT, I have my wap_supplicant running correctly and I do have wireless interfaces that work both AP and supplicant. My Ethernet is: Bart# dmesg|grep em0 em0: port 0x4000-0x401f mem 0xfdbe0000-0xfdbfffff,0xfdb00000-0xfdb7ffff irq 16 at device 0.0 on pci11 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:26:55:d8:47:b5 Bart# ifconfig em0 em0: flags=8802 metric 0 mtu 1500 options=19b ether 00:26:55:d8:47:b5 media: Ethernet autoselect (100baseTX ) status: active The command I run is: wpa_supplicant -ddd -iem0 -Dwired -c wpa.conf My conf file has changed many times but its present content is: Bart# cat wpa.conf ctrl_interface=/var/run/wpa_eth1 ap_scan=no network={ # bssid=00:17:8b:05:39:8f key_mgmt=IEEE8021X eap=TLS eapol_flags=0 # pairwise=CCMP TKIP # group=CCMP TKIP identity="foo" ca_cert="/root/ml.test.06Jan2011/CAd.cert.cer" client_cert="/root/ml.test.06Jan2011/CAd.ml.cert.pem" private_key="/root/ml.test.06Jan2011/CAd.ml.priv.pem" private_key_passwd="frogger" } From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 15:28: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 244631065672 for ; Fri, 14 Jan 2011 15:28:51 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer.dco.penx.com [174.46.214.114]) by mx1.freebsd.org (Postfix) with ESMTP id F03BC8FC12 for ; Fri, 14 Jan 2011 15:28:50 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.4/8.14.4) with ESMTP id p0EEeIIU046159 for ; Fri, 14 Jan 2011 07:40:18 -0700 (MST) (envelope-from freebsd@penx.com) Date: Fri, 14 Jan 2011 07:40:18 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Looking for hints re 802.1X wired (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 15:28:51 -0000 I forgot to mention an important data point. I see via WireShark the EAPOL from the supplicant to the server and the server requesting identity but the supplicant doesn't appear to see the request. ---------- Forwarded message ---------- Date: Fri, 14 Jan 2011 07:34:27 -0700 (MST) From: Dennis Glatting To: freebsd-net@freebsd.org Subject: Looking for hints re 802.1X wired I am trouble with 802.1x wired and I am wondering whether there is some required characteristic of the Ethernet driver. AFAICT, I have my wap_supplicant running correctly and I do have wireless interfaces that work both AP and supplicant. My Ethernet is: Bart# dmesg|grep em0 em0: port 0x4000-0x401f mem 0xfdbe0000-0xfdbfffff,0xfdb00000-0xfdb7ffff irq 16 at device 0.0 on pci11 em0: Using an MSI interrupt em0: [FILTER] em0: Ethernet address: 00:26:55:d8:47:b5 Bart# ifconfig em0 em0: flags=8802 metric 0 mtu 1500 options=19b ether 00:26:55:d8:47:b5 media: Ethernet autoselect (100baseTX ) status: active The command I run is: wpa_supplicant -ddd -iem0 -Dwired -c wpa.conf My conf file has changed many times but its present content is: Bart# cat wpa.conf ctrl_interface=/var/run/wpa_eth1 ap_scan=no network={ # bssid=00:17:8b:05:39:8f key_mgmt=IEEE8021X eap=TLS eapol_flags=0 # pairwise=CCMP TKIP # group=CCMP TKIP identity="foo" ca_cert="/root/ml.test.06Jan2011/CAd.cert.cer" client_cert="/root/ml.test.06Jan2011/CAd.ml.cert.pem" private_key="/root/ml.test.06Jan2011/CAd.ml.priv.pem" private_key_passwd="frogger" } From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 17:37: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 EACC01065670 for ; Fri, 14 Jan 2011 17:37:37 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 87B2E8FC13 for ; Fri, 14 Jan 2011 17:37:34 +0000 (UTC) Received: by eyf6 with SMTP id 6so1526777eyf.13 for ; Fri, 14 Jan 2011 09:37:34 -0800 (PST) Received: by 10.103.215.2 with SMTP id s2mr120718muq.38.1295026653779; Fri, 14 Jan 2011 09:37:33 -0800 (PST) Received: from julie.lab.techwires.net (dslb-088-067-196-180.pools.arcor-ip.net [88.67.196.180]) by mx.google.com with ESMTPS id l3sm201457fan.2.2011.01.14.09.37.31 (version=SSLv3 cipher=RC4-MD5); Fri, 14 Jan 2011 09:37:32 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Dennis Glatting Date: Fri, 14 Jan 2011 18:35:35 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.1-RELEASE; KDE/4.5.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101141835.35915.bschmidt@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Looking for hints re 802.1X wired (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 17:37:38 -0000 On Friday 14 January 2011 15:40:18 Dennis Glatting wrote: > I forgot to mention an important data point. I see via WireShark the > EAPOL from the supplicant to the server and the server requesting > identity but the supplicant doesn't appear to see the request. Which FreeBSD version are you running? -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 18: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 06913106566C for ; Fri, 14 Jan 2011 18:00:24 +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 CE5B28FC15 for ; Fri, 14 Jan 2011 18: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 p0EI0NIr056873 for ; Fri, 14 Jan 2011 18: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 p0EI0Nv6056850; Fri, 14 Jan 2011 18:00:23 GMT (envelope-from gnats) Date: Fri, 14 Jan 2011 18:00:23 GMT Message-Id: <201101141800.p0EI0Nv6056850@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Juergen Lock Cc: Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Juergen Lock List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:00:24 -0000 The following reply was made to PR kern/153938; it has been noted by GNATS. From: Juergen Lock To: PseudoCylon Cc: bug-followup@freebsd.org, nox@jelal.kn-bremen.de Subject: Re: kern/153938: [run] [panic] [patch] Workaround for use-after-free panic Date: Fri, 14 Jan 2011 18:36:50 +0100 On Thu, Jan 13, 2011 at 04:47:21PM -0800, PseudoCylon wrote: > Hello, Hi! > > Thank you for the patch. > You're welcome! :) > I have applied it. Please try patched driver out. > http://gitorious.org/run/run/trees/ratectl_fix/dev/usb/wlan > > I added locks to your patch, so saved pointers are more reliable. I see you removed the rn->wcid code, I guess I should have explained what it's for: ni->ni_associd already gets zeroed before run_node_cleanup() is called so with your version no sc->sc_ni[wcid] ever gets set to NULL. New patch against git, this time with all the diagnostic code in #if 1: diff -upr run-run/dev/usb/wlan/if_run.c src/sys/dev/usb/wlan/if_run.c --- run-run/dev/usb/wlan/if_run.c 2011-01-14 00:35:23.000000000 +0100 +++ src/sys/dev/usb/wlan/if_run.c 2011-01-14 17:17:50.000000000 +0100 @@ -1694,12 +1694,12 @@ static void run_node_cleanup(struct ieee80211_node *ni) { struct run_softc *sc = ni->ni_vap->iv_ic->ic_ifp->if_softc; + struct run_node *rn = (void *)ni; uint8_t wcid; wcid = RUN_AID2WCID(ni->ni_associd); - /* sc_ni[0] is not used */ - if ((wcid == 0) || (wcid > RT2870_WCID_MAX)) + if (wcid > RT2870_WCID_MAX) goto done; /* @@ -1707,13 +1707,27 @@ run_node_cleanup(struct ieee80211_node * * so lock conditionally */ if (mtx_owned(&sc->sc_mtx)) - sc->sc_ni[wcid] = NULL; + if (wcid == 0) + wcid = rn->wcid; + /* sc_ni[0] is not used */ + if (wcid != 0 && wcid <= RT2870_WCID_MAX) + sc->sc_ni[wcid] = NULL; else { RUN_LOCK(sc); - sc->sc_ni[wcid] = NULL; + if (wcid == 0) + wcid = rn->wcid; + /* sc_ni[0] is not used */ + if (wcid != 0 && wcid <= RT2870_WCID_MAX) + sc->sc_ni[wcid] = NULL; RUN_UNLOCK(sc); } +#if 1 + device_printf(sc->sc_dev, "node_cleanup wcid=%d addr=%s ni=%p\n", + wcid, ether_sprintf(ni->ni_vap->iv_opmode == IEEE80211_M_STA ? + ni->ni_vap->iv_myaddr : ni->ni_macaddr), ni); +#endif + done: sc->sc_node_cleanup(ni); } @@ -2279,6 +2293,13 @@ run_drain_fifo(void *arg) wcid == 0) continue; +#if 1 + static struct ieee80211_node *lastni; + if ((ni = sc->sc_ni[wcid]) == NULL && lastni) + device_printf(sc->sc_dev, "drain_fifo ni=NULL wcid=%d\n", + wcid); + lastni = ni; +#endif if ((sc->sc_ni[wcid] == NULL) || (sc->sc_ni[wcid]->ni_rctls == NULL)) continue; @@ -2371,6 +2392,7 @@ run_newassoc_cb(void *arg) { struct run_cmdq *cmdq = arg; struct ieee80211_node *ni = cmdq->arg1; + struct run_node *rn = (void *)ni; struct run_softc *sc = ni->ni_vap->iv_ic->ic_ifp->if_softc; uint8_t wcid = cmdq->wcid; @@ -2379,6 +2401,7 @@ run_newassoc_cb(void *arg) run_write_region_1(sc, RT2860_WCID_ENTRY(wcid), ni->ni_macaddr, IEEE80211_ADDR_LEN); + rn->wcid = wcid; sc->sc_ni[wcid] = ni; } @@ -2416,8 +2439,13 @@ run_newassoc(struct ieee80211_node *ni, ieee80211_runtask(ic, &sc->cmdq_task); } +#if 1 + device_printf(sc->sc_dev, "new assoc isnew=%d associd=%x addr=%s ni=%p\n", + isnew, ni->ni_associd, ether_sprintf(ni->ni_macaddr), ni); +#else DPRINTF("new assoc isnew=%d associd=%x addr=%s\n", isnew, ni->ni_associd, ether_sprintf(ni->ni_macaddr)); +#endif ieee80211_ratectl_node_init(ni); diff -upr run-run/dev/usb/wlan/if_runvar.h src/sys/dev/usb/wlan/if_runvar.h --- run-run/dev/usb/wlan/if_runvar.h 2011-01-14 00:35:23.000000000 +0100 +++ src/sys/dev/usb/wlan/if_runvar.h 2011-01-14 16:56:41.000000000 +0100 @@ -106,6 +106,7 @@ struct run_node { uint8_t amrr_ridx; uint8_t mgt_ridx; uint8_t fix_ridx; + uint8_t wcid; }; struct run_cmdq { From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 18:44:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A20D1065674 for ; Fri, 14 Jan 2011 18:44:31 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF1A8FC19 for ; Fri, 14 Jan 2011 18:44:30 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0EIiOJI003665; Sat, 15 Jan 2011 00:44:25 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D309983.70709@rdtc.ru> Date: Sat, 15 Jan 2011 00:44:19 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Tancsa References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> In-Reply-To: <4D30458D.30007@sentex.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek Subject: panic: bufwrite: buffer is not busy??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 18:44:31 -0000 On 14.01.2011 18:46, Mike Tancsa wrote: >> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE >> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and >> runs FreeBSD 7.3-RELEASE. >> >> I'm experiencing stability issues related to Netgraph. None of above routers can >> survive more than 20-30 days of uptime under typical load. There are different >> flavors of kernel panics, but all are somehow related to netgraph. Typical >> backtraces follow > > I also have stability issues on RELENG_8. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot obtain crashdump, it cannot finish to write it. For example, it happened an hour ago: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 04 fault virtual address = 0x200000040 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803cc979 stack pointer = 0x28:0xffffff80ec09c630 frame pointer = 0x28:0xffffff80ec09c6b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 32220 (mpd5) trap number = 12 panic: page fault cpuid = 2 Uptime: 23h45m12s Physical memory: 4080 MB Dumping 564 MB:panic: bufwrite: buffer is not busy??? cpuid = 2 Uptime: 23h45m13s Automatic reboot in 15 seconds - press a key on the console to abort Another time it panices and could not finish to write crashdump another way: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x60 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803e4baf stack pointer = 0x28:0xffffff80e96d1a20 frame pointer = 0x28:0xffffff80e96d1a30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (dummynet) trap number = 12 panic: page fault cpuid = 3 Uptime: 2d2h33m4s Dumping 4087 MB (3 chunks) chunk 0: 1MB (150 pages)Sleeping thread (tid 100100, pid 0) owns a non-sleepable lock From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 19:38:31 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A0F1106567A for ; Fri, 14 Jan 2011 19:38:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2218FC14 for ; Fri, 14 Jan 2011 19:38:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B051846B03; Fri, 14 Jan 2011 14:38:30 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C93728A009; Fri, 14 Jan 2011 14:38:29 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 14 Jan 2011 14:37:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> In-Reply-To: <4D309983.70709@rdtc.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101141437.55421.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 14 Jan 2011 14:38:29 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Przemyslaw Frasunek , Eugene Grosbein , Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:38:31 -0000 On Friday, January 14, 2011 1:44:19 pm Eugene Grosbein wrote: > On 14.01.2011 18:46, Mike Tancsa wrote: > > >> I'm using mpd 5.5 on three PPPoE routers, each servicing about 300 PPPoE > >> concurrent sessions. Routers are based on Intel SR1630GP hardware platforms and > >> runs FreeBSD 7.3-RELEASE. > >> > >> I'm experiencing stability issues related to Netgraph. None of above routers can > >> survive more than 20-30 days of uptime under typical load. There are different > >> flavors of kernel panics, but all are somehow related to netgraph. Typical > >> backtraces follow > > > > I also have stability issues on RELENG_8. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=153497 > > And for one of my servers (8.2-PRERELEASE/amd64 with 4GB RAM) I just cannot obtain crashdump, > it cannot finish to write it. For example, it happened an hour ago: > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 04 > fault virtual address = 0x200000040 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803cc979 Assuming your kernel is built with debug symbols (which is the default), one thing you can do to aid in debugging is this: gdb /boot/kernel/kernel (gdb) l *0xffffffff803cc979 Where the 0xfff bit is the part of the 'instruction pointer' value above after the colon (:) and then send the output of that in your e-mail to the list. This allows us to the source line at which the fault occurred. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 19:53: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 407C6106564A for ; Fri, 14 Jan 2011 19:53:28 +0000 (UTC) (envelope-from freebsd@penx.com) Received: from Elmer.dco.penx.com (elmer.dco.penx.com [174.46.214.114]) by mx1.freebsd.org (Postfix) with ESMTP id 10DE48FC0A for ; Fri, 14 Jan 2011 19:53:27 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by Elmer.dco.penx.com (8.14.4/8.14.4) with ESMTP id p0EJrELw081864; Fri, 14 Jan 2011 12:53:14 -0700 (MST) (envelope-from freebsd@penx.com) Date: Fri, 14 Jan 2011 12:53:14 -0700 (MST) From: Dennis Glatting X-X-Sender: dennisg@Elmer.dco.penx.com To: Bernhard Schmidt In-Reply-To: <201101141835.35915.bschmidt@freebsd.org> Message-ID: References: <201101141835.35915.bschmidt@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Looking for hints re 802.1X wired (fwd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 19:53:28 -0000 On Fri, 14 Jan 2011, Bernhard Schmidt wrote: > On Friday 14 January 2011 15:40:18 Dennis Glatting wrote: >> I forgot to mention an important data point. I see via WireShark the >> EAPOL from the supplicant to the server and the server requesting >> identity but the supplicant doesn't appear to see the request. > > Which FreeBSD version are you running? > RELENG_8, updated yesterday: > uname -a FreeBSD Bart 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #5: Thu Jan 13 15:41:50 PST 2011 root@Bart:/usr/src/sys/amd64/compile/BART amd64 > cat /usr/FreeBSD-CVS/upfile #*default host=localhost #default host=cvsup17.freebsd.org *default host=cvsup.freebsd.org *default base=/usr/FreeBSD-CVS *default prefix=/usr *default delete *default use-rel-suffix src-all release=cvs tag=RELENG_8 ports-all release=cvs tag=. From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 20:59: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 1FF15106566B for ; Fri, 14 Jan 2011 20:59:47 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 00B458FC14 for ; Fri, 14 Jan 2011 20:59:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 64bit)) with ESMTPSA id <0LF1008U86BL7X70@asmtp029.mac.com> for freebsd-net@freebsd.org; Fri, 14 Jan 2011 12:59:46 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1101140129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-01-14_08:2011-01-14, 2011-01-14, 1970-01-01 signatures=0 From: Chuck Swiger In-reply-to: <20110114204810.Y28741@besplex.bde.org> Date: Fri, 14 Jan 2011 12:59:45 -0800 Message-id: <83F77456-6626-4315-B4FB-272569EE1946@mac.com> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org> <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> <20110114204810.Y28741@besplex.bde.org> To: Bruce Evans X-Mailer: Apple Mail (2.1082) Cc: freebsd-net Subject: [OT] Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 20:59:47 -0000 On Jan 14, 2011, at 2:12 AM, Bruce Evans wrote: >> On a good day, my MUA sends "Content-type: text/plain; format=flowed" and should contain line breaks following the 80-character-per-line Usenet conventions, which modern MUAs might well reassemble based upon the user's window size. If it is being re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well, that lies beyond my control. > > Strangely, my MUA is sending format=flowed, etc., but mails received > from you don't have it. So when I reply to you and Cc me, then there > are enough newlines in the now-doubly-quoted original in the Cc. You're right. After checking, it seems like Mail.app stopped emitting format=flowed around 10.6.3, and $REALJOB requirements mean I'm stuck using it as I need to deal with localized text from many languages frequently. [1] > format=flowed apparently even fixes up the quotes, so there are enough > quotes too. But I don't like this. Letting the MUA change the format > will mangle source code, diffs and some types of quotes. Well, source code, diffs, and such could be attached as MIME enclosures, which will insulate them from quote-based reformatting. Unfortunately, unless one is careful with the content-types used, the FreeBSD mailing list software might decide to strip them.... Regards, -- -Chuck [1]: Mozilla's Thunderbird does fine for the Latin-1 families & UTF-8 encodings, but it doesn't handle UTF-16 text or attachments (ja-JP / ISO-2022-JP or zh-CN & zh-TW in Big5 or GBK) correctly. From owner-freebsd-net@FreeBSD.ORG Fri Jan 14 21:47:34 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 8D77410656A4 for ; Fri, 14 Jan 2011 21:47:34 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFEA8FC0C for ; Fri, 14 Jan 2011 21:47:33 +0000 (UTC) Received: from jack.bspruce.com ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Fri, 14 Jan 2011 16:47:29 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4D30C473.7060900@greatbaysoftware.com> Date: Fri, 14 Jan 2011 16:47:31 -0500 From: Charles Owens MIME-Version: 1.0 To: Jack Vogel References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> In-Reply-To: X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net Subject: Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:47:34 -0000 Thanks for all the feedback on polling, Jack and others. Very helpful. We are working to merge the latest RELENG_8 em/igb driver into our custom build that's based on RELENG_8_1. I've been able to create a patch using the following command: cvs di -N -up -jRELENG_8_1 -jRELENG_8 sys/dev/e1000 sys/dev/ixgb sys/dev/ixgbe sys/conf/files > /tmp/e1000.diff ... by hand trimming sys/conf/files down to only the relevant bits. It compiled and seems to be functioning, but I wouldn't mind a sanity check on my methodology. In particular: * Some of the patches overlapped with sys/dev/ixgb, igbe... so I included them. Should I have? * Is there anything else I should have included? Thanks very much, Charles On 1/13/11 4:49 PM, Jack Vogel wrote: > Polling has seemed to me to be a way around other problems, problems > that these days > no longer exist. I remember back in the FreeBSD 6 days having > interrupt problems which > of course also led to watchdogs. Polling got rid of that. But now > there are dedicated > MULTIPLE interrupts by using MSIX, so that reason for polling is gone. > > Of course there can still be advantages, reducing interrupts and hence > context switches, > which is why the Linux approach does what it does. > > I have not spent time with that issue, its good to know that there > could be problems > lurking with it. But if you can simply go with MSIX I would do that > for now. > > Jack > > > On Thu, Jan 13, 2011 at 1:42 PM, Charles Owens > > wrote: > > So we went back to basics (stock 8.1-RELEASE) and found no > issue! We then added in our kernel mods one by one and > ultimately discovered that device-polling is the culprit (the > kernel config was simply GENERIC + PAE + polling). > > Immediately upon running "ifconfig igb0 polling" the symptoms appear. > > This is very good news overall, in that we can certainly disable > polling for igb. This begs the question, though, as to whether > polling is recommended these days at all for em/igb NICs... or > even in general. From other conversations we've seen there seems > to be some general debate about this. In testing we've done in > the past (circa 7.0) there certainly seemed to be benefit to using > this feature. What are your thoughts about this? > > For our product releases we'd like stay with RELENG_8_1. Would > you recommend the driver in 8.2 as being preferable? > > In case it's of interest: > > igb0@pci0:1:0:0: class=0x020000 card=0x34de8086 chip=0x10a78086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' > class = network > subclass = ethernet > > > > Thanks, > Charles > > > > On 1/13/11 1:27 PM, Jack Vogel wrote: >> The 8.2 latest does have the latest igb, so using that should be >> indicative... >> >> Jack >> >> >> On Thu, Jan 13, 2011 at 7:56 AM, Charles Owens >> > > wrote: >> >> Ok... I got my wires crossed: our first time testing 8.1 on >> this particular platform was with a kernel that had ichwd >> enabled (a new thing for us) and so when igb started >> complaining about "watchdog" we thought it was related. >> >> We've tested again and clearly the real story is that we're >> simply seeing igb issues, symptoms similar to those described. >> >> Does 8.2-RC1 have sufficiently "latest" code, or should I be >> looking to load up something else? (8-stable, maybe?) >> >> Thanks, >> Charles >> >> >> >> On 1/13/11 12:07 AM, Jack Vogel wrote: >>> The problem that Robin saw was due to having MSIX interrupts >>> disabled on the system, I doubt that >>> is going to be the "issue" for others. >>> >>> Get the latest version of the igb code and see if that helps >>> you as a first step. >>> >>> Jack >>> >>> >>> On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens >>> >> > wrote: >>> >>> I'd like to report that we're running into this issue >>> also, in our case on systems that are based on the Intel >>> S5520UR Server Board, running 8.1-RELEASE. If the ichwd >>> driver is loaded we see the same messages, and network >>> communication via the igb nics is non-functional. >>> >>> Have you had any luck? >>> >>> Thanks, >>> Charles >>> >>> Charles Owens >>> Great Bay Software, Inc. >>> >>> >>> >>> >>> On 1/3/11 4:02 PM, Robin Sommer wrote: >>> >>> Hello all, >>> >>> quite a while ago I asked about the problem below. >>> Unfortunately, I >>> haven't found a solution yet and I'm actually still >>> seeing these >>> timeouts after just upgrading to 8.2-RC1. Any >>> further ideas on what >>> could be triggering them, or how I could track down >>> the cause? >>> >>> Thanks, >>> >>> Robin >>> >>> On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: >>> >>> Since upgrading from 8.0 to 8.1-RELEASE, I'm >>> seeing lots of messages >>> like those below on all my SuperMicro >>> SBI-7425C-T3 blades. There's >>> almost no traffic on those interfaces. >>> >>> Any idea? >>> >>> Thanks, >>> >>> Robin >>> >>> Jul 29 13:01:18 blade0 kernel: igb1: Watchdog >>> timeout -- resetting >>> Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) >>> tdh = 256, hw tdt = 266 >>> Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc >>> avail = 1013,Next TX to Clean = 255 >>> Jul 29 13:01:18 blade0 kernel: igb1: link state >>> changed to DOWN >>> Jul 29 13:01:18 blade0 kernel: igb1: link state >>> changed to UP >>> Jul 29 13:01:29 blade0 kernel: igb1: Watchdog >>> timeout -- resetting >>> Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) >>> tdh = 0, hw tdt = 10 >>> Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc >>> avail = 1014,Next TX to Clean = 0 >>> Jul 29 13:01:29 blade0 kernel: igb1: link state >>> changed to DOWN >>> Jul 29 13:01:29 blade0 kernel: igb1: link state >>> changed to UP >>> Jul 29 13:01:46 blade0 kernel: igb1: Watchdog >>> timeout -- resetting >>> Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) >>> tdh = 32, hw tdt = 33 >>> Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc >>> avail = 1022,Next TX to Clean = 31 >>> Jul 29 13:01:46 blade0 kernel: igb1: link state >>> changed to DOWN >>> Jul 29 13:01:46 blade0 kernel: igb1: link state >>> changed to UP >>> Jul 29 13:01:57 blade0 kernel: igb1: Watchdog >>> timeout -- resetting >>> Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) >>> tdh = 0, hw tdt = 10 >>> Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc >>> avail = 1014,Next TX to Clean = 0 >>> Jul 29 13:01:57 blade0 kernel: igb1: link state >>> changed to DOWN >>> Jul 29 13:01:58 blade0 kernel: igb1: link state >>> changed to UP >>> Jul 29 13:02:13 blade0 kernel: igb1: Watchdog >>> timeout -- resetting >>> >>> grep igb /var/run/dmesg.boot >>> >>> igb0:>> version - 1.9.5> port 0x2000-0x201f mem >>> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff >>> irq 16 at device 0.0 on pci4 >>> igb0: [FILTER] >>> igb0: Ethernet address: 00:30:48:9e:22:00 >>> igb1:>> version - 1.9.5> port 0x2020-0x203f mem >>> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,0xfc904000-0xfc907fff >>> irq 17 at device 0.1 on pci4 >>> igb1: [FILTER] >>> igb1: Ethernet address: 00:30:48:9e:22:01 >>> >>> pciconf -lv >>> >>> [...] >>> igb0@pci0:4:0:0: class=0x020000 card=0x10a915d9 >>> chip=0x10a98086 rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82575EB Gigabit Backplane >>> Connection' >>> class = network >>> subclass = ethernet >>> igb1@pci0:4:0:1: class=0x020000 >>> card=0x10a915d9 >>> chip=0x10a98086 rev=0x02 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = '82575EB Gigabit Backplane >>> Connection' >>> class = network >>> subclass = ethernet >>> [...] >>> >>> >>> _______________________________________________ >>> 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 Sat Jan 15 02:30:34 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 04F2C106566C for ; Sat, 15 Jan 2011 02:30:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0768FC08 for ; Sat, 15 Jan 2011 02:30:33 +0000 (UTC) Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0F2UT3P010014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jan 2011 13:30:31 +1100 Date: Sat, 15 Jan 2011 13:30:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Chuck Swiger In-Reply-To: <83F77456-6626-4315-B4FB-272569EE1946@mac.com> Message-ID: <20110115131211.C16117@besplex.bde.org> References: <20100729215649.GB2615@icir.org> <20110103210209.GA13091@icir.org> <4D2E66C4.5090607@greatbaysoftware.com> <4D2F20BB.5080204@greatbaysoftware.com> <4D2F71BE.2080801@greatbaysoftware.com> <0B45B324-A819-4230-BBE3-F8468F2DA88F@mac.com> <20110114154326.E27511@besplex.bde.org> <54D25D8E-ED8C-41E8-BD14-4EB86F4D63C3@mac.com> <20110114204810.Y28741@besplex.bde.org> <83F77456-6626-4315-B4FB-272569EE1946@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: [OT] Re: igb watchdog timeouts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 02:30:34 -0000 On Fri, 14 Jan 2011, Chuck Swiger wrote: > On Jan 14, 2011, at 2:12 AM, Bruce Evans wrote: >>> On a good day, my MUA sends "Content-type: text/plain; format=flowed" and should contain line breaks following the 80-character-per-line Usenet conventions, which modern MUAs might well reassemble based upon the user's window size. If it is being re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well, that lies beyond my control. >> >> Strangely, my MUA is sending format=flowed, etc., but mails received >> from you don't have it. So when I reply to you and Cc me, then there >> are enough newlines in the now-doubly-quoted original in the Cc. > > You're right. After checking, it seems like Mail.app stopped emitting format=flowed around 10.6.3, and $REALJOB requirements mean I'm stuck using it as I need to deal with localized text from many languages frequently. [1] Still doesn't have it :-). >> format=flowed apparently even fixes up the quotes, so there are enough >> quotes too. But I don't like this. Letting the MUA change the format >> will mangle source code, diffs and some types of quotes. > > There's the double-blank-line quote-mangling. I see quotes as ">>" in mutt and pine seems to what is responsible for mangling them to "> > ". > Well, source code, diffs, and such could be attached as MIME enclosures, which will insulate them from quote-based reformatting. Unfortunately, unless one is careful with the content-types used, the FreeBSD mailing list software might decide to strip them.... I don't believe in attachments either. > [1]: Mozilla's Thunderbird does fine for the Latin-1 families & UTF-8 encodings, but it doesn't handle UTF-16 text or attachments (ja-JP / ISO-2022-JP or zh-CN & zh-TW in Big5 or GBK) correctly. Surprisingly little FreeBSD mail have format=flowed. Today I have about 100 mails, mostly from FreeBSD mailing lists, and only 12 of the have it, with 7 from just 2 people. 5 From: 3 FreeBSD committers, 7 From: 4 non-committers (?) User-Agents: Mozilla/5.0 (5), Thunderbird 2.0.0.24 (1) Alpine 2.00 (4), Opera Mail/11.00 (1), header not present (1) Do you happen to know what changes tabs to hard \xa0's, and what prevents this. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Jan 15 08:28: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 88B4D1065670; Sat, 15 Jan 2011 08:28:06 +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 5F46F8FC08; Sat, 15 Jan 2011 08:28:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0F8S6sw020424; Sat, 15 Jan 2011 08:28:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0F8S6T4020418; Sat, 15 Jan 2011 08:28:06 GMT (envelope-from linimon) Date: Sat, 15 Jan 2011 08:28:06 GMT Message-Id: <201101150828.p0F8S6T4020418@freefall.freebsd.org> To: kuba.g4@gmail.com, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154007: [ath] Atheros ar9287 card does not get recognized. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 08:28:06 -0000 Old Synopsis: Atheros ar9287 card does not get recognized. New Synopsis: [ath] Atheros ar9287 card does not get recognized. State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Sat Jan 15 08:27:05 UTC 2011 State-Changed-Why: We're going to need more information to diagnose this problem, e.g., the dmesg, possibly pciconf output. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jan 15 08:27:05 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=154007 From owner-freebsd-net@FreeBSD.ORG Sat Jan 15 08:37:33 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 D10B4106566B; Sat, 15 Jan 2011 08:37:33 +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 A860E8FC08; Sat, 15 Jan 2011 08:37:33 +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 p0F8bXZ5032036; Sat, 15 Jan 2011 08:37:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0F8bXsB032032; Sat, 15 Jan 2011 08:37:33 GMT (envelope-from linimon) Date: Sat, 15 Jan 2011 08:37:33 GMT Message-Id: <201101150837.p0F8bXsB032032@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/154006: [tcp] [patch] tcp "window probe" bug on 64bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 08:37:33 -0000 Old Synopsis: tcp "window probe" bug on 64bit New Synopsis: [tcp] [patch] tcp "window probe" bug on 64bit Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jan 15 08:37:18 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=154006 From owner-freebsd-net@FreeBSD.ORG Sat Jan 15 16:28:52 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD05106566C for ; Sat, 15 Jan 2011 16:28:52 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id CB6D98FC15 for ; Sat, 15 Jan 2011 16:28:51 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.4/8.14.4) with ESMTP id p0FGSiYk009961; Sat, 15 Jan 2011 22:28:44 +0600 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4D31CB37.9090003@rdtc.ru> Date: Sat, 15 Jan 2011 22:28:39 +0600 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D3011DB.9050900@frasunek.com> <4D30458D.30007@sentex.net> <4D309983.70709@rdtc.ru> <201101141437.55421.jhb@freebsd.org> In-Reply-To: <201101141437.55421.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Przemyslaw Frasunek , Mike Tancsa Subject: Re: panic: bufwrite: buffer is not busy??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 16:28:52 -0000 > Assuming your kernel is built with debug symbols (which is the default), one > thing you can do to aid in debugging is this: > > gdb /boot/kernel/kernel > (gdb) l *0xffffffff803cc979 > > Where the 0xfff bit is the part of the 'instruction pointer' value > above after the colon (:) and then send the output of that in your e-mail to > the list. This allows us to the source line at which the fault occurred. I'd glad to, but just found that HDD crash on my buildbox took away obj directory for this NanoBSD... I'll rebuild it again do this next time (it won't take much time, sigh). Btw, I did not know of this way to debug, thanks. From owner-freebsd-net@FreeBSD.ORG Sat Jan 15 21:43: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 58A5E106564A; Sat, 15 Jan 2011 21:43:39 +0000 (UTC) (envelope-from ulsanrub@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 ECF438FC15; Sat, 15 Jan 2011 21:43:38 +0000 (UTC) Received: by vws9 with SMTP id 9so1494628vws.13 for ; Sat, 15 Jan 2011 13:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GPstfW/addjpgWosVlHCl2i7aUcGwE6TZWEbogy+7lU=; b=h++WJ/rEdZMbTCMqNUTIt7y87cYdGL3r5EBGDYK6teCE+6/2Ga8NE1FiP+0NwZnpcV mYrop/0ywHncGnlfmG5jA0EfWyYgrPn/zoWLMlTlNx2Zb/eWjfdjjvV7+4H/n5MeY/aG OHxEXAePHK8uLQvy5HtPTf3I4aU6EhVnG+/wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=R3slCnqNO3gEIdTyWM8KWIy1Fb1g9GHY8/scM8JVuut2qnylBOA7uewPN7vt2DHk2g Jg0gZFoShAFHXy8ajGWR+UGeP2PSp33I3nrZXeS68quqMrEBfpyqedSZCl6wHkjB0ePm X8JgTWtxnZ/SMe18UgRXRo0zAbDvqQBxDAZjw= MIME-Version: 1.0 Received: by 10.220.75.20 with SMTP id w20mr762803vcj.34.1295127817344; Sat, 15 Jan 2011 13:43:37 -0800 (PST) Received: by 10.220.84.83 with HTTP; Sat, 15 Jan 2011 13:43:37 -0800 (PST) In-Reply-To: References: <201101130823.10782.bschmidt@freebsd.org> Date: Sat, 15 Jan 2011 16:43:37 -0500 Message-ID: From: Kyungsoo Lee To: batcilla itself Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, bschmidt@freebsd.org Subject: Re: What is recommended wireless LAN card for FreeBSD TDMA? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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 Jan 2011 21:43:39 -0000 Thank you all! On Thu, Jan 13, 2011 at 8:21 AM, batcilla itself wrote: > Greetings > Both XR2 and CM9 are old card and not supported by TDMA. > I believe there is no option for PCMCIA at all, > for the miniPCI - you can use DCMA-82, Mikrotik R52, anything atheros 5414 > and more recent chipsets. > > In Sam Leffler's presentations mentioned, that DCMA-82 was used. > > //batcilla > > 2011/1/13 Kyungsoo Lee > >> Thank you for your responses. >> >> I'm sorry that I forgot another condition. I need PCMCIA cards for >> laptops. >> Could you recommend any PCMCIA cards with external port supported by >> FreeBSD >> TDMA? >> >> Keiran >> >> On Thu, Jan 13, 2011 at 2:23 AM, Bernhard Schmidt > >wrote: >> >> > On Thursday, January 13, 2011 04:44:03 Kyungsoo Lee wrote: >> > > Hello guys, >> > > >> > > I have used Proxim 8470 LAN cards. But I realized that this card is >> too >> > old >> > > to use TDMA on FreeBSD. I need new wireless LAN cards which are >> supported >> > > by TDMA on FreeBSD and with an external port to connect directional >> > > antenna. Do you recommend any cards? Actually, it is hard to find >> > wireless >> > > LAN cards with the conditions. >> > >> > Afaik TDMA was implemented on and for ath(4) only. >> > You might want to try to obtain either a Ubiquiti SR2 or a Wistron CM9, >> > those >> > should do. >> > >> > -- >> > Bernhard >> > >> _______________________________________________ >> 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" >> > >