Date: Sun, 16 Aug 2009 17:32:26 -0700 From: Freddie Cash <fjwcash@gmail.com> To: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: rc(8) regression. What's the story? Message-ID: <b269bc570908161732j1b5eb3f8hd236549c006de3ca@mail.gmail.com> In-Reply-To: <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com> References: <F61821DF-7187-4C00-A691-0E4D88E83D4F@mac.com> <E04E14BF-8749-47CF-9D47-B5D5AD6A0B6E@lassitu.de> <90E06EA7-4D27-411C-962F-BBCB6D6A13C6@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 16, 2009 at 3:41 PM, Marcel Moolenaar <xcllnt@mac.com> wrote: > On Aug 16, 2009, at 3:29 PM, Stefan Bethke wrote: > >> At this point, /etc/rc.d/netif is finished. >> > > I presume dhclient has been started at this time. > >> bge1: link state changed to DOWN >>> Mounting NFS file systems:mount_nfs: nfs: hostname nor servname provided, >>> or not known >>> . >>> bge0: link state changed to UP >>> >> >> Only now is the interface capable of forwarding packets. >> > > Which means that dhclient is only now able to obtain a > network address. > I've seen this on FreeBSD 6.1-6.3, and 7.0-7.2. It depends on the NIC. fxp(4) and xl(4) appear to be ready as soon as the interface is brought up by /etc/rc.d/netif. em(4) seems to need 3-10 seconds to negotiate a link with the other end of the ethernet cable (regardless of whether it is another NIC or a switch port). For a 10/100 link, it only takes 2-3 seconds to get the link, so things continue as normal. For a 1000 link, it takes up to 10 seconds. I've worked around this on our firewalls by adding a 10-second sleep to /etc/rc.d/netif, to allow the physical link to come up. Haven't had any issues with bge(4) or bce(4) either, although are only used in testing, not in production. -- Freddie Cash fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b269bc570908161732j1b5eb3f8hd236549c006de3ca>