Re: FreeBSD boots too fast on Dell PE850
On Aug 19 at 11:50, Paul Koch wrote: 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. I have a feeling this is related to windows; I recently watched a windows server boot with ethereal and it did an arp x.x.x.x is-at a:b:c:d:e:f (or 2 or 3) first thing (it had a static IP)...so of course a nic vendor would never realize there's a problem since they only test with windows*sigh*. Not sure how DHCP would play into that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Fri, Aug 18, 2006 at 02:00:06PM +0200, Martin Horcicka wrote: This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): I've deleted the cisco verbage for brevity, but that doesn't mean loops won't be detected. It means that it will behave like any STP port in forwarding state -- forward packets until it detects a loop. The problem is that if you were to link the networks together using portfast ports then it could take 5-20 seconds for the switch to get a clue. (I've never seen it take longer if enough traffic to create a problem was transiting the port) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Dan Nelson [EMAIL PROTECTED]:
In the last episode (Aug 17), Alan Amesbury said:
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.
Have you enabled portfast on the Cisco?
http://www.cisco.com/warp/public/473/12.html#c2k
We have similar problems on various hardware and we also believe it's
caused by the Spanning Tree Protocol procedure done during the switch
port initialization. I don't like the idea of using portfast as it
makes the switch less robust so I tried to delay the boot using an rc
script as well:
/etc/rc.d/slow_interface_startup:
---
#!/bin/sh
# PROVIDE: slow_interface_startup
# REQUIRE: netif
# BEFORE: NETWORKING
slow_interface_startup_enable=${slow_interface_startup_enable:-NO}
slow_interface_startup_duration=${slow_interface_startup_duration:-50}
. /etc/rc.subr
name=slow_interface_startup
rcvar=`set_rcvar`
start_cmd=slow_interface_startup_start
stop_cmd=:
slow_interface_startup_start() {
echo -n Waiting for interfaces to get ready \
($slow_interface_startup_duration seconds)
sleep $slow_interface_startup_duration
echo
}
load_rc_config $name
run_rc_command $1
---
Then you can add to rc.conf:
slow_interface_startup_enable=YES
And optionally also (in seconds):
slow_interface_startup_duration=123
It's a little hack but it works as expected. Anyway, in some cases it
does not help. The NIC is probably reset at some later point. I have
not investigated it further yet.
Another thing to check is whether you have alias IPs. I believe the
bge driver has to reset the card every time you add or remove an IP.
I know the ti driver (whose chipset the broadcom chips are based on)
had that problem.
Yes, but I believe that all such operations are done by the netif script.
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Thu, Aug 17, 2006 at 09:16:43PM -0500, Dan Nelson wrote: In the last episode (Aug 17), Alan Amesbury said: 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. Have you enabled portfast on the Cisco? http://www.cisco.com/warp/public/473/12.html#c2k Another thing to check is whether you have alias IPs. I believe the bge driver has to reset the card every time you add or remove an IP. I know the ti driver (whose chipset the broadcom chips are based on) had that problem. If there is a way to program multicasting filters correctly without resettting the hardware there is no need to reset hardware and it could be easily implemented in ether_ioctl(). -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote:
2006/8/18, Dan Nelson [EMAIL PROTECTED]:
In the last episode (Aug 17), Alan Amesbury said:
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.
Have you enabled portfast on the Cisco?
http://www.cisco.com/warp/public/473/12.html#c2k
We have similar problems on various hardware and we also believe it's
caused by the Spanning Tree Protocol procedure done during the switch
port initialization. I don't like the idea of using portfast as it
makes the switch less robust so I tried to delay the boot using an rc
script as well:
/etc/rc.d/slow_interface_startup:
---
#!/bin/sh
# PROVIDE: slow_interface_startup
# REQUIRE: netif
# BEFORE: NETWORKING
slow_interface_startup_enable=${slow_interface_startup_enable:-NO}
slow_interface_startup_duration=${slow_interface_startup_duration:-50}
. /etc/rc.subr
name=slow_interface_startup
rcvar=`set_rcvar`
start_cmd=slow_interface_startup_start
stop_cmd=:
slow_interface_startup_start() {
echo -n Waiting for interfaces to get ready \
($slow_interface_startup_duration seconds)
sleep $slow_interface_startup_duration
echo
}
load_rc_config $name
run_rc_command $1
---
Then you can add to rc.conf:
slow_interface_startup_enable=YES
And optionally also (in seconds):
slow_interface_startup_duration=123
It's a little hack but it works as expected. Anyway, in some cases it
does not help. The NIC is probably reset at some later point. I have
not investigated it further yet.
Another thing to check is whether you have alias IPs. I believe the
bge driver has to reset the card every time you add or remove an IP.
I know the ti driver (whose chipset the broadcom chips are based on)
had that problem.
Yes, but I believe that all such operations are done by the netif script.
I think it's job of device driver. If the driver find its link
negotiation is in progress it should not send frames.
Unfortunately not all drivers handle this correctly.
--
Regards,
Pyun YongHyeon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Fri, Aug 18, 2006 at 06:22:56PM +0900, Pyun YongHyeon wrote: On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote: 2006/8/18, Dan Nelson [EMAIL PROTECTED]: In the last episode (Aug 17), Alan Amesbury said: 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. [...] It's a little hack but it works as expected. Anyway, in some cases it does not help. The NIC is probably reset at some later point. I have not investigated it further yet. Another thing to check is whether you have alias IPs. I believe the bge driver has to reset the card every time you add or remove an IP. I know the ti driver (whose chipset the broadcom chips are based on) had that problem. Yes, but I believe that all such operations are done by the netif script. I think it's job of device driver. If the driver find its link negotiation is in progress it should not send frames. Unfortunately not all drivers handle this correctly. But the bge's start() routine does this, and did it in 6.1-RELEASE, so it doesn't look like a problem in this particular case. : if (!sc-bge_link || IFQ_DRV_IS_EMPTY(ifp-if_snd)) : return; Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpxP9mBvWi35.pgp Description: PGP signature
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Pyun YongHyeon [EMAIL PROTECTED]: On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote: 2006/8/18, Dan Nelson [EMAIL PROTECTED]: In the last episode (Aug 17), Alan Amesbury said: 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. Have you enabled portfast on the Cisco? http://www.cisco.com/warp/public/473/12.html#c2k We have similar problems on various hardware and we also believe it's caused by the Spanning Tree Protocol procedure done during the switch port initialization. I don't like the idea of using portfast as it makes the switch less robust so I tried to delay the boot using an rc script as well: ... I think it's job of device driver. If the driver find its link negotiation is in progress it should not send frames. Unfortunately not all drivers handle this correctly. Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
Hi, all! On Fri, Aug 18, 2006 at 01:23:15PM +0200, Martin Horcicka wrote: Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. This is indeed the case. The switch port goes up. Then the port goes into either the forwarding or the blocking state. The transition period usually takes between 30 and 50 seconds, which may be to long for some devices. spanning-tree portfast puts the port into the forwarding state immediately but still participates in STP, so eventually a loop will be detected and the port put back into blocking state again. The layer 2 interface is, of course, up during all this mumble - otherwise the switch could not send receive STP frames. This is what confuses hosts waiting for DHCP or similar. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Patrick M. Hausen [EMAIL PROTECTED]: On Fri, Aug 18, 2006 at 01:23:15PM +0200, Martin Horcicka wrote: Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. This is indeed the case. The switch port goes up. Then the port goes into either the forwarding or the blocking state. The transition period usually takes between 30 and 50 seconds, which may be to long for some devices. spanning-tree portfast puts the port into the forwarding state immediately but still participates in STP, so eventually a loop will be detected and the port put back into blocking state again. This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): --- Understanding How PortFast Works Spanning-tree PortFast causes a port to enter the spanning-tree forwarding state immediately, bypassing the listening and learning states. You can use PortFast on switch ports connected to a single workstation or server to allow those devices to connect to the network immediately, rather than waiting for the port to transition from the listening and learning states to the forwarding state. Caution: PortFast should be used only when connecting a single end station to a switch port. If you enable PortFast on a port connected to another networking device, such as a switch, you can create network loops. When the switch powers up, or when a device is connected to a port, the port normally enters the spanning-tree listening state. When the forward delay timer expires, the port enters the learning state. When the forward delay timer expires a second time, the port is transitioned to the forwarding or blocking state. When you enable PortFast on a port, the port is immediately and permanently transitioned to the spanning-tree forwarding state. --- But then I don't see any difference between using portfast and disabling Spanning Tree Protocol frames for that port at all. :-/ Martin The layer 2 interface is, of course, up during all this mumble - otherwise the switch could not send receive STP frames. This is what confuses hosts waiting for DHCP or similar. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
2006/8/18, Patrick M. Hausen [EMAIL PROTECTED]: On Fri, Aug 18, 2006 at 01:23:15PM +0200, Martin Horcicka wrote: Unfortunately, I don't know how it works exactly. In our case when the autodetection is disabled and there is e.g. 100/full configured manually on both, switch and the FreeBSD box, ifconfig shows the interface status wery early as active. I suspect the switch (Cisco) to activate the port (from the point of view of the FreeBSD box) but not to forward any normal frames until the Spanning Tree Protocol procedure is finished for that port. But it's just a guess. I don't know the negotiation protocol in Ethernet at all and I would really welcome a commentary from someone who does. This is indeed the case. The switch port goes up. Then the port goes into either the forwarding or the blocking state. The transition period usually takes between 30 and 50 seconds, which may be to long for some devices. spanning-tree portfast puts the port into the forwarding state immediately but still participates in STP, so eventually a loop will be detected and the port put back into blocking state again. This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): --- Understanding How PortFast Works Spanning-tree PortFast causes a port to enter the spanning-tree forwarding state immediately, bypassing the listening and learning states. You can use PortFast on switch ports connected to a single workstation or server to allow those devices to connect to the network immediately, rather than waiting for the port to transition from the listening and learning states to the forwarding state. Caution: PortFast should be used only when connecting a single end station to a switch port. If you enable PortFast on a port connected to another networking device, such as a switch, you can create network loops. When the switch powers up, or when a device is connected to a port, the port normally enters the spanning-tree listening state. When the forward delay timer expires, the port enters the learning state. When the forward delay timer expires a second time, the port is transitioned to the forwarding or blocking state. When you enable PortFast on a port, the port is immediately and permanently transitioned to the spanning-tree forwarding state. --- But then I don't see any difference between using portfast and disabling Spanning Tree Protocol frames for that port at all. :-/ because there isn't? if you are connecting a host to a switch, you can safely drop Spanning tree. from experience, even with SP enabled, the loop is detected, but not always the correct port is disabled :-(. danny Martin The layer 2 interface is, of course, up during all this mumble - otherwise the switch could not send receive STP frames. This is what confuses hosts waiting for DHCP or similar. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
Hi! This is a little off-topic (and I'm no Cisco specialist) but I'm afraid that the loop detection won't happen with portfast. Cisco.com says (the first page that Google gave me): [ Cisco documentation ] As always: it depends. In this case, what you imply by loop detection. If the loop is built using more Cisco equipment participating in STP, then the loop will be detected and eventually broken by putting one of the links in blocked state. IOS or CatOS bugs notwithstanding. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
On Aug 17, 2006, at 9:49 PM, Alan Amesbury wrote: 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 I'm not sure how much to believe the dell docs... on a PE800, they claim the system has a BCM5721 chip, which is how it was coded into the bge driver when I first got this machine and helped get patches built for it. However, the pciconf database claims it is a BCM5750A1. Which one is correct? I suspect the latter. I have PR's open on resolving this inconsistency, but they are obviously low priority. I have no problems with the delay in the 'active' status, but I hard- code IP configuration since it is a server.
Re: FreeBSD boots too fast on Dell PE850
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD boots too fast on Dell PE850
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 --- 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() ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD boots too fast on Dell PE850
In the last episode (Aug 17), Alan Amesbury said: 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. Have you enabled portfast on the Cisco? http://www.cisco.com/warp/public/473/12.html#c2k Another thing to check is whether you have alias IPs. I believe the bge driver has to reset the card every time you add or remove an IP. I know the ti driver (whose chipset the broadcom chips are based on) had that problem. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
