Date: Thu, 17 Aug 2006 20:49:07 -0500 From: Alan Amesbury <amesbury@umn.edu> To: freebsd-stable@freebsd.org Subject: FreeBSD boots too fast on Dell PE850 Message-ID: <44E51C93.5090000@umn.edu>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------070103010608090204030604 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OK, booting *too* quickly is a somewhat unusual problem..... I have FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some reason, in the PowerEdge 850 Dell chose to replace the perfectly adequate em(4) adapters found on the PE750 with bge(4) hardware. FreeBSD identifies these adapters as BCM5750A1, but Dell says they're actually Broadcom 5721J adapters instead. See http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf for details. The switch to which the host is connected is a Cisco Catalyst 3750. How this relates to FreeBSD, however..... During the boot process and before /etc/rc.d/netif runs, the networking hardware is *cold*, i.e., no link lights or anything. During boot, when FreeBSD brings the interface up, there is a period where the interface appears to do autonegotiation with the switch to which it's connected, regardless of whether the 'ifconfig_bge0=...' line in rc.conf includes "media" and "mediaopt" options. The console also displays various bge0: link state changed to DOWN bge0: link state changed to UP messages, while the link lights flash on and off in various patterns. Eventually the link stabilizes... but by this point FreeBSD has completed booting and is in multiuser. The result is that any services that rely on network being present during boot (NTP, for example, as well as numerous stuff installed from ports) fail in various ways. As hinted at above, locking the NIC and the associated switch ports to a fixed speed and duplex (thus avoiding the whole autonegotiation mess) does NOT help; FreeBSD still notes link state changes as described above and things break in unpleasant ways. My fix for this has been to apply this patch to /etc/rc.d/netif (also attached in pristine form): ---------- Patch for netif ---------- --- netif.orig Thu Jun 29 17:21:10 2006 +++ netif Thu Aug 17 20:30:10 2006 @@ -71,6 +71,12 @@ # Resync ipfilter /etc/rc.d/ipfilter resync fi + + if [ ! -z "$sleep_postnetif" ]; then + echo -n "Sleeping for $sleep_postnetif seconds . . . " + sleep $sleep_postnetif + echo "Done." + fi } network_stop() -------- End patch for netif -------- Setting $sleep_postnetif to a value of about 7 then causes the boot process to delay long enough that the network connection's stabilized enough to be usable. I chose that RC variable name as I suspected it would have a low incidence of collision in rc.conf in the future, i.e., I'm hoping this patch is safe to include in -STABLE in the event this sort of problem is widespread (and nobody comes up with a more elegant fix). Anyway, since I suspect that I might not be the only one running FreeBSD with Dell and/or Broadcom hardware, I figured it might be worth mentioning this and providing what has been (for me, anyway) a workable patch thus far. I hesitated to open a bug report on this because--well, it doesn't seem like the OS is really at fault here. :-\ Recommendations for improvement are welcome, as well as any suggestions for a less kludgy fix. I *really* dislike the idea of slowing down the boot process. :-( -- Alan Amesbury University of Minnesota --------------070103010608090204030604 Content-Type: text/plain; name="netif_patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netif_patch" --- netif.orig Thu Jun 29 17:21:10 2006 +++ netif Thu Aug 17 20:30:10 2006 @@ -71,6 +71,12 @@ # Resync ipfilter /etc/rc.d/ipfilter resync fi + + if [ ! -z "$sleep_postnetif" ]; then + echo -n "Sleeping for $sleep_postnetif seconds . . . " + sleep $sleep_postnetif + echo "Done." + fi } network_stop() --------------070103010608090204030604--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44E51C93.5090000>