Re: Annoyance with recent parallelism in rc.d

Mike Makonnen [mmakonnen_at_gmail.com] wrote:
> Alexey Shuvaev wrote:
> > Rev. 1.4 of rc.d/defaultroute.
> > Ok, what should I do to have network daemons happy on startup?
> > I am on a LAN so always have plugged-in cable.
> > I do see on the console:
> > msk0: link state changed to DOWN
> > msk0: link state changed to UP
> >                    got link
> > msk0: link state changed to DOWN
> > Starting Network: lo0 msk0.
> > msk0: link state changed to UP
> > msk0: link state changed to DOWN
> > 
> > AFAIK some NIC (or PHY-s?) require some sort of reset to handle some
> > events.
> > Should I live with synchronous_dhclient="YES" or something else?
> 
> This seems to be an issue with the driver for the network card. No 
> special handling needs to take place in rc.d. So, yes, 
> synchronous_dhclient=yes should be the appropriate work-around.

Maybe synchronous_dhclient=yes should be the default, as there are a
lot of cases of it not working async?  I had horribly annoying
problems with NFS failing (via amd using NIS based maps) at boot on
different machines 90% of the time.  Some use bge, and others use nfe.

At least in my case, there was no "reset".  Eg:

/dev/da0s2g: clean, 1992874 free (138 frags, 249092 blocks, 0.0% fragmentation)
bge0: link state changed to DOWN
Starting Network: lo0 bge0.
bge1: link state changed to DOWN
Setting date via ntp.
13 Feb 13:41:48 ntpdate[638]: no servers can be used, exiting
Setting NIS domain: sw.myri.com.
Starting rpcbind.
/etc/rc: WARNING: failed to start amd
Recovering vi editor sessions:.

Setting synchronous_dhclient=yes seems to have fixed it for me.

Drew