From owner-freebsd-net@FreeBSD.ORG Mon Jan 5 10:13:31 2009 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 5782B1065687 for ; Mon, 5 Jan 2009 10:13:31 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 165D68FC19 for ; Mon, 5 Jan 2009 10:13:30 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so6348350rvb.2 for ; Mon, 05 Jan 2009 02:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MZwlTRPAxWlBwwwESdLw03YUABiNhL/m7unvBEoiL8w=; b=OKckEC3/E9UQ2L2ro9YEcc510FvtdvWPmIcA0PwXHJUncKv6q2cIR5GwXQKTT9eaVY nU8h41fp5GwtuzrWGvB1AFePZ3r+6XEuOvGEMYUGecEm8uBT2vDzJdAn/Q0cd0ar9XtU 068Jmk/6Yx3kC35RkO1o3jubcM0m7PGcKZePg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=M3lByq82bfEhe6up53/jIm17Ugjr7VsclrHSOojVfavj/8Ji8OQu8kzdT4fgVxgQ09 Gx7xRQ+LJ641CR+Zlo4ZUZ5ppACv6PrOjr5PBtOf752UhAL11Lgo5L0+lw+Zr0gX/Lw1 eRKzISHOKyfaqnO2s9JIviyPZV521g9e6ZrPo= Received: by 10.140.188.19 with SMTP id l19mr10316547rvf.51.1231149103433; Mon, 05 Jan 2009 01:51:43 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id g22sm32714964rvb.1.2009.01.05.01.51.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Jan 2009 01:51:42 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id n059pa4o003542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 18:51:36 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id n059pZZd003541; Mon, 5 Jan 2009 18:51:35 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 5 Jan 2009 18:51:35 +0900 From: Pyun YongHyeon To: Garrett Cooper Message-ID: <20090105095135.GH1842@cdnetworks.co.kr> References: <20081224021016.GF95088@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: Annoyance with msk(4) going up and down when initializing interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 10:13:37 -0000 On Fri, Jan 02, 2009 at 03:31:33PM -0800, Garrett Cooper wrote: > Hi Pyun, > I've noticed an issue for a while now with my chipset (I think that > this is post an MFC between 7.0 and 7.1, but I could be wrong). > Basically, each CPU (with the ULE scheduler) grabs the task to check > for media status, goes out and attempts to get an IP, and if the > timing of the status modifications is just right, one of the CPU's > will mark the link up and others will mark it down, and it will stay > down. No, the link state change event is protected by driver lock. > Same thing occurs when trying to get a DHCP request -- there will > typically be multiple requests and ACK's for any given requests. > This occurs with my onboard NICs on my P5K-e motherboards on 7.1- > rc[12], and also 8-CURRENT. If you're referring to multiple link UP/DOWN messages when dhclient(8) trying to get an IP address via DHCP it's normal for drivers that rely on mii(4) state change event. Technically it's not normal but it's the way how it was implemented on most drivers. Ideally drivers should not need to reset controllers when it's not absolutely required to reset hardwares but most drivers blindly reset hardware which in turn results in link renegotiation. You can see similiar behavour when alias addresseses are added to the interface. Because controllers that have complex firmware/embedded OS will take time to complete the reset operation, the reset operation would be pain to these controllers. Long time ago I added a hack to em(4) to mitigate the issue but I don't think it's way to go. NetBSD seems to have right fix in ioctl handler. However the approach will require careful checking of multicasting code of all drivers. I don't have all hardwares to test this and I don't know hardware internals of all drivers. -- Regards, Pyun YongHyeon