Date: Sat, 19 Aug 2006 11:50:21 +1000 From: Paul Koch <paul.koch@statseeker.com> To: freebsd-stable@freebsd.org, Alan Amesbury <amesbury@umn.edu> Subject: Re: FreeBSD boots too fast on Dell PE850 Message-ID: <200608191150.22128.paul.koch@statseeker.com> In-Reply-To: <44E5F4F2.7030807@umn.edu> References: <20060818120041.024AA16A66B@hub.freebsd.org> <44E5F4F2.7030807@umn.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 19 August 2006 03:12, Alan Amesbury wrote: > Thanks for the feedback and discussion! Alas, in terms of network > configuration, I'm just a tenant; I have no direct control over the > networking gear, nor direct visibility into how the switch is > configured. > > A couple people wrote to me directly and suggested I 'send-pr' this, > so I'll do so (hopefully later today). > > Thanks again! > > > -- > Alan Amesbury > University of Minnesota This is a really old problem, actually two. The first being the spanning tree problem where it can take a "long" time for it to settle and your port go into forwarding state. Adding a random sleep doesn't help because - how long do you sleep for ? How we got around this problem at various sites was, by modifying rc scripts, to check if a default gateway was configured (typical), and ping it until a response was received, or a large timeout occurred (eg. 5 minutes). That way, all other network services like nptdate, and sendmail would have a better chance of working. If your machine doesn't use a static IP, but instead dhcp, then you will need to have a long timeout/retry on the dhcp requests. The second problem we found was, various NICs would report that they were "active" after doing auto negotiation, but no rx packets were being passed into to the OS. Not sure if it was a hardware or driver issue, but we discovered that by forcing a packet out the NIC via the bpf interface, it would immediately start doing stuff. It was if the auto negotiation had not really completed fully until a packet was transmitted. This only occurred on certain types of NICs, the newer ones. This was a problem for us because we build something called a "remote network appliance" (RNA) which is basically FreeBSD on a floppy and runs a statistical lan analyser. The RNA might have many NICs in it, one with an IP, the others just connected to network segments in promiscuous mode. Our apps couldn't monitor any traffic because no packets had be sent out the interfaces. So, early in the boot process we force out a couple of "Loopback" packets and everything works just fine. Not sure if the second issue would be a problem for normal installations though. Paul.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608191150.22128.paul.koch>