From owner-freebsd-current@FreeBSD.ORG Thu Aug 23 04:50:54 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36D031065672; Thu, 23 Aug 2012 04:50:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDA128FC12; Thu, 23 Aug 2012 04:50:53 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so625255pbb.13 for ; Wed, 22 Aug 2012 21:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=HFmPiWx3CGuNB5oIlJcGJYYdXAbhEYKyVxjiHcn54hU=; b=ICQ1Tl03T77Z4yD1678r773Cr9sfpP+7l52bcO5zm31KsA8YjvVwuHgs9C5842fvsf KiSSzfhC5KTyATNzGXPr+knmbnmtuFFaHy1Uium6ByeYD3PxoHuabg5WPoy86Va11H82 BRSWLqo7B+fBf5msFj/+6wchpoZ72lJHeZQWCWWuFYZiS3pR6K7/IMWLBe1mMejvvsv1 s4rrcZdJR9QYEaFtaSXVNKuM+trTivOn/WRfQcZ0qT64Myqfd1Px+WbzW+TgjZETZKDZ GO3xPSpDi2zLVVdDaQxnMZVfjsRZOVoyH89Dm6jgoOTFjJ9nlAj1Gpse7ME2Soi+d0Vy zofQ== Received: by 10.68.223.164 with SMTP id qv4mr1593017pbc.20.1345697453518; Wed, 22 Aug 2012 21:50:53 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id xd9sm4997321pbc.35.2012.08.22.21.50.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 21:50:51 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 23 Aug 2012 13:50:43 -0700 From: YongHyeon PYUN Date: Thu, 23 Aug 2012 13:50:43 -0700 To: Peter Jeremy Message-ID: <20120823205043.GC3270@michelle.cdnetworks.com> References: <20120821095527.GA33206@hell.ukr.net> <20120822171253.GB3300@michelle.cdnetworks.com> <20120822172822.GA52909@hell.ukr.net> <201208221535.01598.jhb@freebsd.org> <20120823013534.GA31015@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120823013534.GA31015@server.rulingia.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: dhclient cause up/down cycle after 239356 ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 04:50:54 -0000 On Thu, Aug 23, 2012 at 11:35:34AM +1000, Peter Jeremy wrote: > On 2012-Aug-22 15:35:01 -0400, John Baldwin wrote: > >Hmm. Perhaps we could use a debouncer to ignore "short" link flaps? Kind of > >gross (and OpenBSD doesn't do this). For now this change basically ignores > >link up events if they occur with 5 seconds of the link down event. The 5 is > >hardcoded which is kind of yuck. > > I'm also a bit concerned about this for similar reasons to adrian@. > We need to distinguish between short link outages caused by (eg) a > switch admin reconfiguring the switch (which needs the lease to be > re-checked) and those caused by broken NICs which report link status > changes when they are touched. Maybe an alternative is to just ignore > link flaps when they occur within a few seconds of a script_go(). > (And/or make the ignore timeout configurable). > > Apart from fxp(4), does anyone know how many NICs are similarly > broken? FreeBSD used to blindly call driver's if_init() in ether_ioctl() whenever an IP address is assigned to interface. This results in calling foo_init in a driver such that controller/link reset happens after IP address assignment. I tried to fix many ethernet drivers in tree to ignore redundant foo_init() call by checking whether this foo_init() call is the very first time initialization of interface. Both NetBSD/OpenBSD seems to not call if_init() if the driver is already running. Because some controllers(e.g. fxp(4)) may require full controller reset to make multicast work, I couldn't follow their approach. I still don't know what other drivers except fxp(4) require full controller reset. There are too many old ethernet drivers I don't have access. Another reason why fxp(4) requires redundant controller reset is flow control support of the driver. Due to hardware limitation, MAC configuration for negotiated link's flow control parameters also requires controller reset. > > Does anyone know why this issue doesn't bite OpenBSD? Does it have I guess OpenBSD's fxp(4) has to reset controller to update multicast filter but it does not support flow control for fxp(4) yet so OpenBSD may see less number of link flips than that of FreeBSD. > a work-around to avoid resetting the link, not report link status > changes or just no-one has noticed the issue? > > BTW to jhb: Can you check your mailer's list configuration. You > appear to be adding and leaving > in the Cc list. > > -- > Peter Jeremy