Date: Mon, 5 Jan 2009 21:43:25 +1100 From: Edwin Groothuis <edwin@mavetju.org> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: Garrett Cooper <yanefbsd@gmail.com>, net@freebsd.org Subject: Re: Annoyance with msk(4) going up and down when initializing interface Message-ID: <20090105104325.GA70686@mavetju.org> In-Reply-To: <20090105095135.GH1842@cdnetworks.co.kr> References: <E1LF7Oc-000Djt-C1@clue.co.za> <20081224021016.GF95088@cdnetworks.co.kr> <B26A2D09-B515-4E85-943D-A9C28B82955B@gmail.com> <20090105095135.GH1842@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 05, 2009 at 06:51:35PM +0900, Pyun YongHyeon wrote: > 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. When booting diskless via PXE I sometimes run into this problem too: machine boots via NFS, NIC gets down and up and oh, it doesn't work anymore. Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090105104325.GA70686>