Annoyance with msk(4) going up and down when initializing interface

[Pyun YongHyeon]

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