Date: Mon, 5 Jan 2009 18:51:35 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Garrett Cooper <yanefbsd@gmail.com> Cc: net@freebsd.org Subject: Re: Annoyance with msk(4) going up and down when initializing interface Message-ID: <20090105095135.GH1842@cdnetworks.co.kr> In-Reply-To: <B26A2D09-B515-4E85-943D-A9C28B82955B@gmail.com> References: <E1LF7Oc-000Djt-C1@clue.co.za> <20081224021016.GF95088@cdnetworks.co.kr> <B26A2D09-B515-4E85-943D-A9C28B82955B@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090105095135.GH1842>