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.