Re: em device hangs on ifconfig alias ...
Any status on this patch being merged in?
On Mon, 10 Jul 2006, Atanas wrote:
Pyun YongHyeon said the following on 7/7/06 8:32 PM:
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
Yes -- basically, there are two problems:
(1) A little problem, in which an arp announcement is sent before the
link has
settled after reset.
(2) A big problem, in which the interface is gratuitously recent
requiring
long settling times.
I'd really like to see a fix to the second of these problems (not
resetting when an IP is added or removed, resulting in link
renegotiation); the first one I'm less concerned about, although it
would make some amount of sense to do an arp announcement when the link
goes up.
Ah, I see. Thanks for the insight.
How about the attached patch?
This patch seems to fix both of the issues, or at least this is what I see
now:
- the card no longer gets reset when adding an alias;
- the arp packet gets delivered;
- adding 250 aliases takes less than a second;
I haven't fully tested whether all 250 IP aliases were accessible (I used
non-routable IP addresses), but I suppose so. Also I couldn't stress the
patched driver enough to see whether it performs as expected.
But in overall it looks good. I guess some more testing might be needed in
order to merge the patch into the source tree.
Regards,
Atanas
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 8 Jul 2006 03:30:36 -
@@ -67,6 +67,7 @@
#include netinet/in_systm.h
#include netinet/in.h
+#include netinet/if_ether.h
#include netinet/ip.h
#include netinet/tcp.h
#include netinet/udp.h
@@ -692,6 +693,9 @@
EM_LOCK_ASSERT(sc);
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
if (!sc-link_active)
return;
@@ -745,6 +749,7 @@
{
struct em_softc *sc = ifp-if_softc;
struct ifreq *ifr = (struct ifreq *)data;
+ struct ifaddr *ifa = (struct ifaddr *)data;
int error = 0;
if (sc-in_detach)
@@ -752,9 +757,22 @@
switch (command) {
case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
+ if (ifa-ifa_addr-sa_family == AF_INET) {
+ /*
+* XXX
+* Since resetting hardware takes a very long time
+* we only initialize the hardware only when it is
+* absolutely required.
+*/
+ ifp-if_flags |= IFF_UP;
+ if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ EM_LOCK(sc);
+ em_init_locked(sc);
+ EM_UNLOCK(sc);
+ }
+ arp_ifinit(ifp, ifa);
+ } else
+ error = ether_ioctl(ifp, command, data);
break;
case SIOCSIFMTU:
{
@@ -802,17 +820,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +898,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x),
(int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.44
diff
Re: em device hangs on ifconfig alias ...
On Mon, Jul 31, 2006 at 08:21:19PM -0300, User Freebsd wrote: Any status on this patch being merged in? Because there are so many em(4) users there I'd like to have test last for one or two more weeks. -- 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: em device hangs on ifconfig alias ...
On Mon, Jul 10, 2006 at 01:47:23PM -0700, Atanas wrote: Pyun YongHyeon said the following on 7/7/06 8:32 PM: On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote: Yes -- basically, there are two problems: (1) A little problem, in which an arp announcement is sent before the link has settled after reset. (2) A big problem, in which the interface is gratuitously recent requiring long settling times. I'd really like to see a fix to the second of these problems (not resetting when an IP is added or removed, resulting in link renegotiation); the first one I'm less concerned about, although it would make some amount of sense to do an arp announcement when the link goes up. Ah, I see. Thanks for the insight. How about the attached patch? This patch seems to fix both of the issues, or at least this is what I see now: - the card no longer gets reset when adding an alias; - the arp packet gets delivered; - adding 250 aliases takes less than a second; I haven't fully tested whether all 250 IP aliases were accessible (I used non-routable IP addresses), but I suppose so. Also I couldn't stress the patched driver enough to see whether it performs as expected. But in overall it looks good. I guess some more testing might be needed in order to merge the patch into the source tree. I haven't received any reports execept this one. If there is no objection I'll commit these changes within two days. -- 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: em device hangs on ifconfig alias ...
On Mon, Jul 10, 2006 at 02:56:27PM -0700, Brooks Davis wrote: On Mon, Jul 10, 2006 at 05:55:23PM -0300, User Freebsd wrote: On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote: Of course, any reasonable administrator would configure interface FastEthernet0/1 spanning-tree portfast It tells the switch that this port will never be anything but a leaf in the tree so STP does not need to re run before allowing packets to flow. If you do this and then create a loop with it, bad things happen, but cisco recommends it in general. Note that STP still runs, it just doesn't start out blocking the port. Any bad things will only happen until the switch figures out that there is a loop, which usually happens fairly quickly. Worst case scenario: you may have a packet storm for a second or two. All the switches I've tried it on detect the loop very quickly (after only a few packets), so I usually just enable portfast across the board. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Mornin'! On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote: Not sure what STP is Spanning Tree Protocol. Having the link go up and down would cause the switch port to block traffic for a period of time. Of course, any reasonable administrator would configure interface FastEthernet0/1 spanning-tree portfast for all ports connected to hosts. (shown syntax is Cisco's). Regards, Patrick -- 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: em device hangs on ifconfig alias ...
At 03:09 AM 10/07/2006, Patrick M. Hausen wrote: Of course, any reasonable administrator would configure interface FastEthernet0/1 spanning-tree portfast for all ports connected to hosts. (shown syntax is Cisco's). Yes, its great if you have access to the cisco... Not always possible in a colo. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Pyun YongHyeon said the following on 7/7/06 8:32 PM:
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
Yes -- basically, there are two problems:
(1) A little problem, in which an arp announcement is sent before the link
has
settled after reset.
(2) A big problem, in which the interface is gratuitously recent requiring
long settling times.
I'd really like to see a fix to the second of these problems (not resetting
when an IP is added or removed, resulting in link renegotiation); the first
one I'm less concerned about, although it would make some amount of sense
to do an arp announcement when the link goes up.
Ah, I see. Thanks for the insight.
How about the attached patch?
This patch seems to fix both of the issues, or at least this is what I
see now:
- the card no longer gets reset when adding an alias;
- the arp packet gets delivered;
- adding 250 aliases takes less than a second;
I haven't fully tested whether all 250 IP aliases were accessible (I
used non-routable IP addresses), but I suppose so. Also I couldn't
stress the patched driver enough to see whether it performs as expected.
But in overall it looks good. I guess some more testing might be needed
in order to merge the patch into the source tree.
Regards,
Atanas
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 8 Jul 2006 03:30:36 -
@@ -67,6 +67,7 @@
#include netinet/in_systm.h
#include netinet/in.h
+#include netinet/if_ether.h
#include netinet/ip.h
#include netinet/tcp.h
#include netinet/udp.h
@@ -692,6 +693,9 @@
EM_LOCK_ASSERT(sc);
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
if (!sc-link_active)
return;
@@ -745,6 +749,7 @@
{
struct em_softc *sc = ifp-if_softc;
struct ifreq *ifr = (struct ifreq *)data;
+ struct ifaddr *ifa = (struct ifaddr *)data;
int error = 0;
if (sc-in_detach)
@@ -752,9 +757,22 @@
switch (command) {
case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
+ if (ifa-ifa_addr-sa_family == AF_INET) {
+ /*
+* XXX
+* Since resetting hardware takes a very long time
+* we only initialize the hardware only when it is
+* absolutely required.
+*/
+ ifp-if_flags |= IFF_UP;
+ if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ EM_LOCK(sc);
+ em_init_locked(sc);
+ EM_UNLOCK(sc);
+ }
+ arp_ifinit(ifp, ifa);
+ } else
+ error = ether_ioctl(ifp, command, data);
break;
case SIOCSIFMTU:
{
@@ -802,17 +820,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +898,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x), (int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.44
diff -u -r1.44 if_em.h
--- if_em.h 15 Feb 2006 08:39:50
Re: em device hangs on ifconfig alias ...
On Mon, 10 Jul 2006, Patrick M. Hausen wrote: Mornin'! On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote: Not sure what STP is Spanning Tree Protocol. Having the link go up and down would cause the switch port to block traffic for a period of time. Of course, any reasonable administrator would configure interface FastEthernet0/1 spanning-tree portfast 'k, I know nothing about Cisco but do have access to change my configs (knowing nothing tends to keep me from doing too much playing) ... what does the above do, exactly? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Mon, Jul 10, 2006 at 05:55:23PM -0300, User Freebsd wrote: On Mon, 10 Jul 2006, Patrick M. Hausen wrote: Mornin'! On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote: Not sure what STP is Spanning Tree Protocol. Having the link go up and down would cause the switch port to block traffic for a period of time. Of course, any reasonable administrator would configure interface FastEthernet0/1 spanning-tree portfast 'k, I know nothing about Cisco but do have access to change my configs (knowing nothing tends to keep me from doing too much playing) ... what does the above do, exactly? It tells the switch that this port will never be anything but a leaf in the tree so STP does not need to re run before allowing packets to flow. If you do this and then create a loop with it, bad things happen, but cisco recommends it in general. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpYgOwJoPkFT.pgp Description: PGP signature
Re: em device hangs on ifconfig alias ...
At 04:55 PM 10/07/2006, User Freebsd wrote: 'k, I know nothing about Cisco but do have access to change my configs (knowing nothing tends to keep me from doing too much playing) ... what does the above do, exactly? Spanning tree is there to prevent switch loops as well as allow for redundant paths with switches among other things. If you are just putting a non bridge device in the port it should be safe to put the switch port in portfast mode so when there is a link transition, the port does not block traffic for 20 seconds on that vlan. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Sat, Jul 08, 2006 at 08:20:01PM +0300, Ruslan Ermilov wrote: On Sat, Jul 08, 2006 at 12:32:55PM +0900, Pyun YongHyeon wrote: On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote: On Fri, 7 Jul 2006, User Freebsd wrote: I think that I have patched, built and loaded the em(4) kernel module correctly. After applying the patch there were no rejects, before building the module I intentionally appended (patched) to its version string in if_em.c, and could see that in dmesg every time I loaded the module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) Is it possible that we're going at this issue backwards? It isn't the lack of ARP packet going out that is causing the problems with moving IPs, but that delay that we're seeing when aliasing a new IP on the stack? The ARP packet *is* being attempted, but is timing out before the re-init is completing? Yes -- basically, there are two problems: (1) A little problem, in which an arp announcement is sent before the link has settled after reset. (2) A big problem, in which the interface is gratuitously recent requiring long settling times. I'd really like to see a fix to the second of these problems (not resetting when an IP is added or removed, resulting in link renegotiation); the first one I'm less concerned about, although it would make some amount of sense to do an arp announcement when the link goes up. Ah, I see. Thanks for the insight. How about the attached patch? I've been working on this problem for Mike Tancsa about a year ago, and my fix was naive. I ended up not committing it because I found that it broke something else, but I don't remember what exactly now. Ahh, I seem to remember now -- setting a different MAC address was not programmed into a hardware with my patch applied. I guess, in some cases(FIFO overrun/underrun, link duplex changes, hardware malfunction or watchdog error etc) the hardware needs a global reset which in turn needs em_hardware_init(). If we can invoke em_hardware_init() under absolutely required condition it would work as expected. This will also eliminates long time delay needed to add alias addresses. See my other post in the list.( It has a layering violation, handled protocol specific operation in a driver, but I failed to find a better way to fix the issue without rewriting bunch of hardware specific parts of 8254x.) -- 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: em device hangs on ifconfig alias ...
At 01:20 PM 08/07/2006, Ruslan Ermilov wrote: Ah, I see. Thanks for the insight. How about the attached patch? I've been working on this problem for Mike Tancsa about a year ago, and my fix was naive. I ended up not committing it because I found that it broke something else, but I don't remember what exactly now. Ahh, I seem to remember now -- setting a different MAC address was not programmed into a hardware with my patch applied. For my uses, this was a non issue. Having STP block for 20 seconds because I add or remove an alias made it kind of a non issue. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Mon, 10 Jul 2006, Mike Tancsa wrote: At 01:20 PM 08/07/2006, Ruslan Ermilov wrote: Ah, I see. Thanks for the insight. How about the attached patch? I've been working on this problem for Mike Tancsa about a year ago, and my fix was naive. I ended up not committing it because I found that it broke something else, but I don't remember what exactly now. Ahh, I seem to remember now -- setting a different MAC address was not programmed into a hardware with my patch applied. For my uses, this was a non issue. Having STP block for 20 seconds because I add or remove an alias made it kind of a non issue. Not sure what STP is, but I've not noticed any blocking on removing an alias, only on adding one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
At 12:06 AM 10/07/2006, User Freebsd wrote: Not sure what STP is Spanning Tree Protocol. Having the link go up and down would cause the switch port to block traffic for a period of time. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Robert Watson wrote: On Fri, 7 Jul 2006, User Freebsd wrote: I think that I have patched, built and loaded the em(4) kernel module correctly. After applying the patch there were no rejects, before building the module I intentionally appended (patched) to its version string in if_em.c, and could see that in dmesg every time I loaded the module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) Is it possible that we're going at this issue backwards? It isn't the lack of ARP packet going out that is causing the problems with moving IPs, but that delay that we're seeing when aliasing a new IP on the stack? The ARP packet *is* being attempted, but is timing out before the re-init is completing? Yes -- basically, there are two problems: (1) A little problem, in which an arp announcement is sent before the link has settled after reset. (2) A big problem, in which the interface is gratuitously recent requiring long settling times. I thought I remember a developer working on the em driver saying just before 6.1 was released that this reset was needed and couldn't be avoided to ensure performance of the device to work at its best, I can't remember his explanation, but this topic has come up before, of course anything is possible to fix. Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Sat, 8 Jul 2006, Michael Vince wrote: I thought I remember a developer working on the em driver saying just before 6.1 was released that this reset was needed and couldn't be avoided to ensure performance of the device to work at its best, I can't remember his explanation, but this topic has come up before, of course anything is possible to fix. The thing is, and I may be mis-understanding the explanations so far, the 'reset' is to renegotiate the connection ... if that is the case, and both the switch and the interface are already locked at a speed (in my case, both are hard coded to 100baseTX full duplex, then what is there to re-negotiate? And, why does it appear that *only* the em driver/interface requires this? I run bge and fxp interfaces on this same network, against the same switch, all locked at the same speed, and only the em driver exhibits this problem ... in fact, its only the *newer* em driver that does, as I have one server on the network, using an em interface, that is running an older FreeBSD 4.x kernel, that performs the same as the bge/fxp (ie. perfectly) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Sat, Jul 08, 2006 at 12:32:55PM +0900, Pyun YongHyeon wrote:
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
On Fri, 7 Jul 2006, User Freebsd wrote:
I think that I have patched, built and loaded the em(4) kernel module
correctly. After applying the patch there were no rejects, before
building the module I intentionally appended (patched) to its version
string in if_em.c, and could see that in dmesg every time I loaded the
module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18
(patched)
Is it possible that we're going at this issue backwards? It isn't the
lack of ARP packet going out that is causing the problems with moving
IPs,
but that delay that we're seeing when aliasing a new IP on the stack?
The
ARP packet *is* being attempted, but is timing out before the re-init is
completing?
Yes -- basically, there are two problems:
(1) A little problem, in which an arp announcement is sent before the link
has
settled after reset.
(2) A big problem, in which the interface is gratuitously recent requiring
long settling times.
I'd really like to see a fix to the second of these problems (not
resetting
when an IP is added or removed, resulting in link renegotiation); the
first
one I'm less concerned about, although it would make some amount of sense
to do an arp announcement when the link goes up.
Ah, I see. Thanks for the insight.
How about the attached patch?
I've been working on this problem for Mike Tancsa about a year ago,
and my fix was naive. I ended up not committing it because I found
that it broke something else, but I don't remember what exactly now.
Ahh, I seem to remember now -- setting a different MAC address was
not programmed into a hardware with my patch applied.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
---BeginMessage---
On Thu, Mar 31, 2005 at 10:20:25AM +0300, Ruslan Ermilov wrote:
On Thu, Mar 31, 2005 at 10:01:52AM +0300, Ruslan Ermilov wrote:
Hi Mike,
On Wed, Mar 30, 2005 at 08:03:21PM -0500, Mike Tancsa wrote:
[...]
If you could somehow fix the problem with em bouncing its interface
when you add or remove an alias from it (RELENG_5), I would gladly
send you two nics! ;-)
eg ifconfig em0 192.168.13.9 netmask 255.255.255.252 alias
will down and up the interface. If the switch port it is in has STP,
the port will go into blocking for 30 seconds, which is really
troublesome :(
Is this also a problem in HEAD, or only in RELENG_5?
OK, I can easily reproduce the problem here, hold on.
I'm not fully sure this is a right fix, but it works for me.
Here's what happens: on SIOCSIFADDR, em_ioctl() is called,
then ether_ioctl() which calls em_init() which calls
em_hardware_init() (for some odd reason I don't understand).
em_hardware_init() is correctly called on attach, so I
don't understand why it's also needed in em_init().
Anyway, the hack is as easy as this:
%%%
Index: if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.62
diff -u -p -r1.62 if_em.c
--- if_em.c 5 Mar 2005 18:30:10 - 1.62
+++ if_em.c 31 Mar 2005 07:41:47 -
@@ -832,12 +832,14 @@ em_init_locked(struct adapter * adapter)
bcopy(adapter-interface_data.ac_enaddr, adapter-hw.mac_addr,
ETHER_ADDR_LEN);
+#if 0
/* Initialize the hardware */
if (em_hardware_init(adapter)) {
printf(em%d: Unable to initialize the hardware\n,
adapter-unit);
return;
}
+#endif
if (ifp-if_capenable IFCAP_VLAN_HWTAGGING)
em_enable_vlans(adapter);
%%%
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpsRxXyUafG6.pgp
Description: PGP signature
---End Message---
pgpFvy5lSGyI8.pgp
Description: PGP signature
Re: em device hangs on ifconfig alias ...
On Fri, 7 Jul 2006, Pyun YongHyeon wrote: I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: That's odd. I've tested it on CURRENT and I could see the ARP packet. Are you sure you patched correctly? If so I have to build a RELENG_6 machine and give it try. Is it possible you're seeing an interaction between the reset generated as part of IP address changing, and the time it takes to negotiate link? It's possible that the arp packets are being eaten during the link negotiation, so for systems negotiating quickly (or not at all) then the arp packet is seen on other hosts, and otherwise not... Robert N M Watson Computer Laboratory University of Cambridge EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# ifconfig em1 inet -alias 10.10.64.40 nothing It's normal. The fxp driver appears to send something on startup and nothing on shutdown: FXP# ifconfig fxp0 inet alias 10.10.64.40 18:41:54.584059 arp who-has 10.10.64.40 tell 10.10.64.40 FXP# ifconfig fxp0 inet -alias 10.10.64.40 nothing When I manually arping the em alias after startup (i.e. simulate what fxp does), everything works as expected: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# arping -c1 -S10.10.64.40 10.10.64.40 18:46:07.808701 arp who-has 10.10.64.40 tell 10.10.64.40 Because arping requested it em(4) generated it. EM# ifconfig em1 inet -alias 10.10.64.40 nothing It appears that this is what the em driver is supposed to do, or at least fxp does it in this way. No, it's an em(4) driver bug. fxp(4)'s behavior is correct. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. OK, let's put that aside for now. Regards, Atanas -- 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] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Robert Watson said the following on 7/7/06 7:17 AM: I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: That's odd. I've tested it on CURRENT and I could see the ARP packet. Are you sure you patched correctly? If so I have to build a RELENG_6 machine and give it try. Is it possible you're seeing an interaction between the reset generated as part of IP address changing, and the time it takes to negotiate link? It's possible that the arp packets are being eaten during the link negotiation, so for systems negotiating quickly (or not at all) then the arp packet is seen on other hosts, and otherwise not... Looks like this is exactly what happens. I was able to see it by running two tcpdump instances - one on the EM machine running in background and another running elsewhere on the same subnet. So on the EM machine the arp packet actually gets generated by em(4) and caught by the tcpdump running there: EM# tcpdump -n arp and ether src 00:04:23:b5:1b:ff EM# EM# ifconfig em1 inet alias 10.10.64.40 EM# 11:28:37.178946 arp who-has 10.10.64.40 tell 10.10.64.40 EM# But it doesn't reach the other tcpdump instance running on another host. It seems that the arp packet gets killed before leaving the EM machine, due to the card initialization or something else. I tried sending it manually with arping, just to make sure both tcpdumps operate properly and yes, the packet got delivered to both. I think that I have patched, built and loaded the em(4) kernel module correctly. After applying the patch there were no rejects, before building the module I intentionally appended (patched) to its version string in if_em.c, and could see that in dmesg every time I loaded the module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, 7 Jul 2006, Atanas wrote: Robert Watson said the following on 7/7/06 7:17 AM: I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: That's odd. I've tested it on CURRENT and I could see the ARP packet. Are you sure you patched correctly? If so I have to build a RELENG_6 machine and give it try. Is it possible you're seeing an interaction between the reset generated as part of IP address changing, and the time it takes to negotiate link? It's possible that the arp packets are being eaten during the link negotiation, so for systems negotiating quickly (or not at all) then the arp packet is seen on other hosts, and otherwise not... Looks like this is exactly what happens. I was able to see it by running two tcpdump instances - one on the EM machine running in background and another running elsewhere on the same subnet. So on the EM machine the arp packet actually gets generated by em(4) and caught by the tcpdump running there: EM# tcpdump -n arp and ether src 00:04:23:b5:1b:ff EM# EM# ifconfig em1 inet alias 10.10.64.40 EM# 11:28:37.178946 arp who-has 10.10.64.40 tell 10.10.64.40 EM# But it doesn't reach the other tcpdump instance running on another host. It seems that the arp packet gets killed before leaving the EM machine, due to the card initialization or something else. I tried sending it manually with arping, just to make sure both tcpdumps operate properly and yes, the packet got delivered to both. I think that I have patched, built and loaded the em(4) kernel module correctly. After applying the patch there were no rejects, before building the module I intentionally appended (patched) to its version string in if_em.c, and could see that in dmesg every time I loaded the module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) Is it possible that we're going at this issue backwards? It isn't the lack of ARP packet going out that is causing the problems with moving IPs, but that delay that we're seeing when aliasing a new IP on the stack? The ARP packet *is* being attempted, but is timing out before the re-init is completing? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, 7 Jul 2006, User Freebsd wrote: I think that I have patched, built and loaded the em(4) kernel module correctly. After applying the patch there were no rejects, before building the module I intentionally appended (patched) to its version string in if_em.c, and could see that in dmesg every time I loaded the module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) Is it possible that we're going at this issue backwards? It isn't the lack of ARP packet going out that is causing the problems with moving IPs, but that delay that we're seeing when aliasing a new IP on the stack? The ARP packet *is* being attempted, but is timing out before the re-init is completing? Yes -- basically, there are two problems: (1) A little problem, in which an arp announcement is sent before the link has settled after reset. (2) A big problem, in which the interface is gratuitously recent requiring long settling times. I'd really like to see a fix to the second of these problems (not resetting when an IP is added or removed, resulting in link renegotiation); the first one I'm less concerned about, although it would make some amount of sense to do an arp announcement when the link goes up. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
On Fri, 7 Jul 2006, User Freebsd wrote:
I think that I have patched, built and loaded the em(4) kernel module
correctly. After applying the patch there were no rejects, before
building the module I intentionally appended (patched) to its version
string in if_em.c, and could see that in dmesg every time I loaded the
module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18
(patched)
Is it possible that we're going at this issue backwards? It isn't the
lack of ARP packet going out that is causing the problems with moving IPs,
but that delay that we're seeing when aliasing a new IP on the stack? The
ARP packet *is* being attempted, but is timing out before the re-init is
completing?
Yes -- basically, there are two problems:
(1) A little problem, in which an arp announcement is sent before the link
has
settled after reset.
(2) A big problem, in which the interface is gratuitously recent requiring
long settling times.
I'd really like to see a fix to the second of these problems (not resetting
when an IP is added or removed, resulting in link renegotiation); the first
one I'm less concerned about, although it would make some amount of sense
to do an arp announcement when the link goes up.
Ah, I see. Thanks for the insight.
How about the attached patch?
--
Regards,
Pyun YongHyeon
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 8 Jul 2006 03:30:36 -
@@ -67,6 +67,7 @@
#include netinet/in_systm.h
#include netinet/in.h
+#include netinet/if_ether.h
#include netinet/ip.h
#include netinet/tcp.h
#include netinet/udp.h
@@ -692,6 +693,9 @@
EM_LOCK_ASSERT(sc);
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
if (!sc-link_active)
return;
@@ -745,6 +749,7 @@
{
struct em_softc *sc = ifp-if_softc;
struct ifreq *ifr = (struct ifreq *)data;
+ struct ifaddr *ifa = (struct ifaddr *)data;
int error = 0;
if (sc-in_detach)
@@ -752,9 +757,22 @@
switch (command) {
case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
+ if (ifa-ifa_addr-sa_family == AF_INET) {
+ /*
+* XXX
+* Since resetting hardware takes a very long time
+* we only initialize the hardware only when it is
+* absolutely required.
+*/
+ ifp-if_flags |= IFF_UP;
+ if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ EM_LOCK(sc);
+ em_init_locked(sc);
+ EM_UNLOCK(sc);
+ }
+ arp_ifinit(ifp, ifa);
+ } else
+ error = ether_ioctl(ifp, command, data);
break;
case SIOCSIFMTU:
{
@@ -802,17 +820,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +898,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x), (int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
===
RCS file:
Re: em device hangs on ifconfig alias ...
Pyun YongHyeon said the following on 7/5/06 7:14 PM:
Here is patch generated against RELENG_6.
OK, I just tested that, but it doesn't seem to make any difference.
Here's what I did:
I commented out the em device from my kernel (a 6-STABLE one from
yesterday) and compiled three if_em kernel modules:
- one taken from 6.1 release
- the unpatched 6-STABLE one
- the latter with the above patch applied
So I was able to load and test each of these modules independently and
without actually restarting the machine. I changed also the driver
version string in if_em.c, just to ensure that I'm really loading the
right em module by checking dmesg:
em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched)
port 0xdc80-0xdcbf mem 0xfcfe-0xfcff irq 55 at device 4.1 on pci3
em1: Ethernet address: 00:04:23:b5:1b:ff
em1: link state changed to UP
I used 2 machines - one running 6.1-RELEASE and using fxp (I'll call it
FXP), and the test one running 6-STABLE with em (I'll call it EM),
and tried exchanging/moving an IP alias between them.
FXP# ifconfig
fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=bRXCSUM,TXCSUM,VLAN_MTU
inet 10.10.64.30 netmask 0xff00 broadcast 10.10.64.255
ether 00:e0:81:31:f4:1e
media: Ethernet autoselect (100baseTX full-duplex)
status: active
EM# ifconfig
em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=bRXCSUM,TXCSUM,VLAN_MTU
inet 10.10.64.63 netmask 0xff00 broadcast 10.10.64.255
ether 00:04:23:b5:1b:ff
media: Ethernet autoselect (100baseTX full-duplex)
status: active
First I brought up an IP alias on the FXP machine:
FXP# ifconfig fxp0 inet alias 10.10.64.40 netmask 255.255.255.255
and checked whether it's accessible from anywhere - yes. Then I moved
that to EM:
FXP# ifconfig fxp0 inet -alias 10.10.64.40
EM# ifconfig em1 inet alias 10.10.64.40 netmask 255.255.255.255
and checked again - no. It was accessible only from its own subnet
(10.10.64.x), but not from anywhere else.
Moving that back to FXP works, but moving it back to EM doesn't. The
only way I found to make it accessible was to arping something from the
aliased IP address:
EM# arping -S10.10.64.40 -c1 somehost
So it seems that when an IP alias has been recently used on some other
machine (on FXP in my case), the em driver is unable to initialize that
IP alias properly.
It might be that the fxp driver is not sending something when releasing
an alias, who knows. But fact is that fxp always initializes its aliases
properly - I use it extensively and it always worked.
I tried setting another IP alias that never has been used on these
machines. I brought that up first on EM and it worked. The moved it to
FXP and it also worked! But moving it back to EM made it inaccessible.
It looks like there's something fishy with the alias initialization.
Another related problem is that the card gets re-initialized (reset?) on
each alias you add (takes between 0.3 and 1 seconds, depending how fast
the hardware is), which for mass aliased systems could be a serious
hurdle after a crash or reboot.
Regards,
Atanas
--- if_em.c.origFri May 19 09:19:57 2006
+++ if_em.c Thu Jul 6 11:10:56 2006
@@ -657,8 +657,9 @@
mtx_assert(adapter-mtx, MA_OWNED);
-if (!adapter-link_active)
-return;
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
@@ -719,11 +720,6 @@
if (adapter-in_detach) return(error);
switch (command) {
- case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
- break;
case SIOCSIFMTU:
{
int max_frame_size;
@@ -760,16 +756,17 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(adapter);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ adapter-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(adapter);
+ em_set_promisc(adapter);
+ }
+ } else
em_init_locked(adapter);
- }
-
- em_disable_promisc(adapter);
- em_set_promisc(adapter);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if
Re: em device hangs on ifconfig alias ...
On Thu, Jul 06, 2006 at 01:29:11PM -0700, Atanas wrote: Pyun YongHyeon said the following on 7/5/06 7:14 PM: Here is patch generated against RELENG_6. OK, I just tested that, but it doesn't seem to make any difference. Here's what I did: I commented out the em device from my kernel (a 6-STABLE one from yesterday) and compiled three if_em kernel modules: - one taken from 6.1 release - the unpatched 6-STABLE one - the latter with the above patch applied So I was able to load and test each of these modules independently and without actually restarting the machine. I changed also the driver version string in if_em.c, just to ensure that I'm really loading the right em module by checking dmesg: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 (patched) port 0xdc80-0xdcbf mem 0xfcfe-0xfcff irq 55 at device 4.1 on pci3 em1: Ethernet address: 00:04:23:b5:1b:ff em1: link state changed to UP I used 2 machines - one running 6.1-RELEASE and using fxp (I'll call it FXP), and the test one running 6-STABLE with em (I'll call it EM), and tried exchanging/moving an IP alias between them. FXP# ifconfig fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 10.10.64.30 netmask 0xff00 broadcast 10.10.64.255 ether 00:e0:81:31:f4:1e media: Ethernet autoselect (100baseTX full-duplex) status: active EM# ifconfig em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 10.10.64.63 netmask 0xff00 broadcast 10.10.64.255 ether 00:04:23:b5:1b:ff media: Ethernet autoselect (100baseTX full-duplex) status: active First I brought up an IP alias on the FXP machine: FXP# ifconfig fxp0 inet alias 10.10.64.40 netmask 255.255.255.255 and checked whether it's accessible from anywhere - yes. Then I moved that to EM: FXP# ifconfig fxp0 inet -alias 10.10.64.40 EM# ifconfig em1 inet alias 10.10.64.40 netmask 255.255.255.255 and checked again - no. It was accessible only from its own subnet (10.10.64.x), but not from anywhere else. Moving that back to FXP works, but moving it back to EM doesn't. The only way I found to make it accessible was to arping something from the aliased IP address: EM# arping -S10.10.64.40 -c1 somehost So it seems that when an IP alias has been recently used on some other machine (on FXP in my case), the em driver is unable to initialize that IP alias properly. It might be that the fxp driver is not sending something when releasing an alias, who knows. But fact is that fxp always initializes its aliases properly - I use it extensively and it always worked. I tried setting another IP alias that never has been used on these machines. I brought that up first on EM and it worked. The moved it to FXP and it also worked! But moving it back to EM made it inaccessible. Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? It looks like there's something fishy with the alias initialization. Another related problem is that the card gets re-initialized (reset?) on each alias you add (takes between 0.3 and 1 seconds, depending how fast the hardware is), which for mass aliased systems could be a serious hurdle after a crash or reboot. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. -- 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: em device hangs on ifconfig alias ...
Pyun YongHyeon said the following on 7/6/06 6:03 PM: Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# ifconfig em1 inet -alias 10.10.64.40 nothing The fxp driver appears to send something on startup and nothing on shutdown: FXP# ifconfig fxp0 inet alias 10.10.64.40 18:41:54.584059 arp who-has 10.10.64.40 tell 10.10.64.40 FXP# ifconfig fxp0 inet -alias 10.10.64.40 nothing When I manually arping the em alias after startup (i.e. simulate what fxp does), everything works as expected: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# arping -c1 -S10.10.64.40 10.10.64.40 18:46:07.808701 arp who-has 10.10.64.40 tell 10.10.64.40 EM# ifconfig em1 inet -alias 10.10.64.40 nothing It appears that this is what the em driver is supposed to do, or at least fxp does it in this way. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. OK, let's put that aside for now. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Thu, Jul 06, 2006 at 07:11:57PM -0700, Atanas wrote: Pyun YongHyeon said the following on 7/6/06 6:03 PM: Hmm, that's strange. I've double checked that stock em(4) didn't generate ARP packets when its addresses were changed. So I made em(4) generate ARP. Could you see a gratuitous ARP with tcpdump when you change its address? I just left a tcpdump -n arp host 10.10.64.40 on a third machine sniffing around and tested all em module versions I had (the stock 6.1, 6-STABLE and 6-STABLE with your patch), but got silence on all three: That's odd. I've tested it on CURRENT and I could see the ARP packet. Are you sure you patched correctly? If so I have to build a RELENG_6 machine and give it try. EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# ifconfig em1 inet -alias 10.10.64.40 nothing It's normal. The fxp driver appears to send something on startup and nothing on shutdown: FXP# ifconfig fxp0 inet alias 10.10.64.40 18:41:54.584059 arp who-has 10.10.64.40 tell 10.10.64.40 FXP# ifconfig fxp0 inet -alias 10.10.64.40 nothing When I manually arping the em alias after startup (i.e. simulate what fxp does), everything works as expected: EM# ifconfig em1 inet alias 10.10.64.40 nothing EM# arping -c1 -S10.10.64.40 10.10.64.40 18:46:07.808701 arp who-has 10.10.64.40 tell 10.10.64.40 Because arping requested it em(4) generated it. EM# ifconfig em1 inet -alias 10.10.64.40 nothing It appears that this is what the em driver is supposed to do, or at least fxp does it in this way. No, it's an em(4) driver bug. fxp(4)'s behavior is correct. This is other issue. em(4) performs two time-consuming operations in its initialization routine. One is DMA tag/map creation and the other is checksumming EEPROM contents in init routine. I have an experimental patch for it but let's fix one at a time. OK, let's put that aside for now. Regards, Atanas -- 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: em device hangs on ifconfig alias ...
Pyun YongHyeon said the following on 6/30/06 8:54 PM:
On Fri, Jun 30, 2006 at 12:28:49PM -0700, Atanas wrote:
User Freebsd said the following on 6/29/06 9:29 PM:
The other funny thing about the current em driver is that if you move an
IP to it from a different server, the appropriate ARP packets aren't
sent out to redirect the IP traffic .. recently, someone pointed me to
arping, which has solved my problem *external* to the driver ...
That's the second reason why I (still) avoid em in mass-aliased systems.
I have a single pool of IP addresses shared by many servers with
multiple aliases each. When someone leaves and frees an IP, it gets
reused and brought up on a different server. In case it was previously
handled by em, the traffic doesn't get redirected to the new server.
Similar thing happens even with machines with single static IPs. For
instance when retiring an old production system, I usually request a new
box to be brought up on a different IP, make a fresh install on
everything and test, swap IP addresses and reboot. In case of em, after
a soft reboot both systems are inaccessible.
A workaround is to power both of the systems down and then power them
up. This however cannot be done remotely and in case there were IP
aliases, they still don't get any traffic.
I haven't fully tested it but what about attached patch?
It may fix your ARP issue. The patch also fixes other issues
related with ioctls.
Now em(4) will send a ARP packet when its IP address is changed even
if there is no active link. Since em(4) is not mii-aware driver I
can't sure this behaviour is correct.
The patch is against if_em.c,v 1.116 2006/06/06, which is 7-CURRENT. I
tried merging the relevant em driver files into a 6-STABLE
installation by simply copying sys/dev/em/* and sys/modules/em/Makefile,
but it seems that the new revision depends on other -CURRENT things and
the module build fails:
# pwd
/usr/src/sys/modules/em
# make clean; make
...
/usr/src/sys/modules/em/../../dev/em/if_em.c: In function
`em_setup_interface':
/usr/src/sys/modules/em/../../dev/em/if_em.c:2143: error:
`IFCAP_VLAN_HWCSUM' undeclared (first use in this function)
...
I don't have a 7-CURRENT based box around. It seems too bleeding edge
for me anyway. I was hoping to play with different if_em kernel modules
on a semi-production (spare) box and eventually test the proposed em
patch, but apparently it's not so easy.
Please let me know if I'm missing something obvious.
Thanks,
Atanas
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 1 Jul 2006 03:51:41 -
@@ -692,7 +692,8 @@
EM_LOCK_ASSERT(sc);
- if (!sc-link_active)
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
return;
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
@@ -751,11 +752,6 @@
return (error);
switch (command) {
- case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
- break;
case SIOCSIFMTU:
{
int max_frame_size;
@@ -802,17 +798,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +876,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x), (int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
Re: em device hangs on ifconfig alias ...
On Wed, Jul 05, 2006 at 06:29:55PM -0700, Atanas wrote:
Pyun YongHyeon said the following on 6/30/06 8:54 PM:
On Fri, Jun 30, 2006 at 12:28:49PM -0700, Atanas wrote:
User Freebsd said the following on 6/29/06 9:29 PM:
The other funny thing about the current em driver is that if you move
an IP to it from a different server, the appropriate ARP packets
aren't sent out to redirect the IP traffic .. recently, someone
pointed me to arping, which has solved my problem *external* to the
driver ...
That's the second reason why I (still) avoid em in mass-aliased systems.
I have a single pool of IP addresses shared by many servers with
multiple aliases each. When someone leaves and frees an IP, it gets
reused and brought up on a different server. In case it was previously
handled by em, the traffic doesn't get redirected to the new server.
Similar thing happens even with machines with single static IPs. For
instance when retiring an old production system, I usually request a
new box to be brought up on a different IP, make a fresh install on
everything and test, swap IP addresses and reboot. In case of em, after
a soft reboot both systems are inaccessible.
A workaround is to power both of the systems down and then power them
up. This however cannot be done remotely and in case there were IP
aliases, they still don't get any traffic.
I haven't fully tested it but what about attached patch?
It may fix your ARP issue. The patch also fixes other issues
related with ioctls.
Now em(4) will send a ARP packet when its IP address is changed even
if there is no active link. Since em(4) is not mii-aware driver I
can't sure this behaviour is correct.
The patch is against if_em.c,v 1.116 2006/06/06, which is 7-CURRENT. I
tried merging the relevant em driver files into a 6-STABLE
installation by simply copying sys/dev/em/* and sys/modules/em/Makefile,
but it seems that the new revision depends on other -CURRENT things and
the module build fails:
# pwd
/usr/src/sys/modules/em
# make clean; make
...
/usr/src/sys/modules/em/../../dev/em/if_em.c: In function
`em_setup_interface':
/usr/src/sys/modules/em/../../dev/em/if_em.c:2143: error:
`IFCAP_VLAN_HWCSUM' undeclared (first use in this function)
...
I don't have a 7-CURRENT based box around. It seems too bleeding edge
for me anyway. I was hoping to play with different if_em kernel modules
on a semi-production (spare) box and eventually test the proposed em
patch, but apparently it's not so easy.
Please let me know if I'm missing something obvious.
My bad. Here is patch generated against RELENG_6.
--
Regards,
Pyun YongHyeon
--- if_em.c.origFri May 19 09:19:57 2006
+++ if_em.c Thu Jul 6 11:10:56 2006
@@ -657,8 +657,9 @@
mtx_assert(adapter-mtx, MA_OWNED);
-if (!adapter-link_active)
-return;
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
+ return;
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
@@ -719,11 +720,6 @@
if (adapter-in_detach) return(error);
switch (command) {
- case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
- break;
case SIOCSIFMTU:
{
int max_frame_size;
@@ -760,16 +756,17 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(adapter);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ adapter-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(adapter);
+ em_set_promisc(adapter);
+ }
+ } else
em_init_locked(adapter);
- }
-
- em_disable_promisc(adapter);
- em_set_promisc(adapter);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(adapter);
- }
}
EM_UNLOCK(adapter);
break;
@@ -835,8 +832,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x), (int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return(error);
Re: em device hangs on ifconfig alias ...
Michael Vince said the following on 6/29/06 8:53 PM: The thing that have to ask is if Atanas has 100's why can't he just boot Freebsd have have them all prebound to the interface at startup, why would you need to add and remove them constantly by the hundreds during normal server uptime? I wasn't talking about the normal server uptime. Sooner or later, regardless of how perfect the hardware is and how great the OS performs, you will have to reboot. At least once or twice a year to update the kernel and/or world. Even in such rare occasions several minutes of additional downtime per reboot (in my case) are not justifiable. I know that in a perfect world this downtime could be scheduled. But I prefer to keep the option to quickly reboot my systems when necessary. 2 vs 10-15 minutes downtime per reboot really makes a difference. How you bind the aliases doesn't really matter - you always end up waiting the em driver to reset the card on each alias. And don't get me wrong, I do use em for years on many machines having one static IP or a few additional static aliases and it works great. It just doesn't fit well in mass-alias configurations. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
User Freebsd said the following on 6/29/06 9:29 PM: The other funny thing about the current em driver is that if you move an IP to it from a different server, the appropriate ARP packets aren't sent out to redirect the IP traffic .. recently, someone pointed me to arping, which has solved my problem *external* to the driver ... That's the second reason why I (still) avoid em in mass-aliased systems. I have a single pool of IP addresses shared by many servers with multiple aliases each. When someone leaves and frees an IP, it gets reused and brought up on a different server. In case it was previously handled by em, the traffic doesn't get redirected to the new server. Similar thing happens even with machines with single static IPs. For instance when retiring an old production system, I usually request a new box to be brought up on a different IP, make a fresh install on everything and test, swap IP addresses and reboot. In case of em, after a soft reboot both systems are inaccessible. A workaround is to power both of the systems down and then power them up. This however cannot be done remotely and in case there were IP aliases, they still don't get any traffic. I have a third machine that uses an em driver, but its an older 4.x kernel, and it operates perfectly ... no timeouts/hangs and sends out the appropriate ARP packet ... all three servers are connected to the same Cisco switch, with all ports configured identically, so it isn't a switch issue, as someone else intimated ... This seems strange, could depend on the chip version, who knows. I still have many 4.x based machines, and both em issues (the card reset on each alias and the arp packets not been sent when going down) were present when I was doing my tests. I check for these once in a while (a year or so), usually with the latest major release branch. We had a compatibility issue about a year ago with a (rather exotic?) fiber NIC - 82545GM, where FreeBSD-4.x did better. The em driver coming with 5.x didn't support that (or wasn't working as expected, I don't remember the specifics), while the one coming with 4.x did, so we ended up installing 4.11 then. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, 30 Jun 2006, Atanas wrote: A workaround is to power both of the systems down and then power them up. This however cannot be done remotely and in case there were IP aliases, they still don't get any traffic. see 'arping' ... great little tool, solved all my problems as far as moving around IPs ... I still have many 4.x based machines, and both em issues (the card reset on each alias and the arp packets not been sent when going down) were present when I was doing my tests. Right, what version of 4.x? The one that I have working is from ~Feb 2005 .. if I were to upgrade that to the latest 4-STABLE, it would break like the rest ... the older 4.x had a different em driver in the kernel then the newer one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Francisco Reyes writes: | Atanas writes: | I have some newer machines with 2 Broadcom chips on-board. I plan to | give them a try at some point in the future, but I'm not sure how stable | the bge driver | | For us they have been a problem. Primarily because it causes all kinds of | freezing/crashes when having an IPMI board. I believe it has performed ok in | machines where we don't have an IPMI card. Can you try: http://www.ambrisko.com/doug/bge_ipmi_3.patch and see if that helps. I need one minor tweak to it before I can commit it. Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Doug Ambrisko writes: Can you try: http://www.ambrisko.com/doug/bge_ipmi_3.patch and see if that helps. I need one minor tweak to it before I can commit it. We have a brand new machine getting readied.. Passed along the patch URL to the tech building the machine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
User Freebsd said the following on 6/30/06 1:48 PM: see 'arping' ... great little tool, solved all my problems as far as moving around IPs ... Thanks for the tip, I will try it next time. I still have many 4.x based machines, and both em issues (the card reset on each alias and the arp packets not been sent when going down) were present when I was doing my tests. Right, what version of 4.x? The one that I have working is from ~Feb 2005 .. if I were to upgrade that to the latest 4-STABLE, it would break like the rest ... the older 4.x had a different em driver in the kernel then the newer one ... The problem was initially discovered back in 2003 (must have been with 4.8 or 4.9) and after switching back to fxp I haven't tested the 4.x branch any more. I remember testing 5.x around the 5.3 release (2004) and 6.x shortly after 6.0 (2005), and both em driver versions shipped with these releases were having the same issues. I haven't tested it this year yet, but even in case it's fixed, it's not likely that all improvements will get back-ported to the older branches (over 90% of my servers run something older than 6.x). But as long as fxp works, this is a non-issue for me. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, Jun 30, 2006 at 12:28:49PM -0700, Atanas wrote:
User Freebsd said the following on 6/29/06 9:29 PM:
The other funny thing about the current em driver is that if you move an
IP to it from a different server, the appropriate ARP packets aren't
sent out to redirect the IP traffic .. recently, someone pointed me to
arping, which has solved my problem *external* to the driver ...
That's the second reason why I (still) avoid em in mass-aliased systems.
I have a single pool of IP addresses shared by many servers with
multiple aliases each. When someone leaves and frees an IP, it gets
reused and brought up on a different server. In case it was previously
handled by em, the traffic doesn't get redirected to the new server.
Similar thing happens even with machines with single static IPs. For
instance when retiring an old production system, I usually request a new
box to be brought up on a different IP, make a fresh install on
everything and test, swap IP addresses and reboot. In case of em, after
a soft reboot both systems are inaccessible.
A workaround is to power both of the systems down and then power them
up. This however cannot be done remotely and in case there were IP
aliases, they still don't get any traffic.
I haven't fully tested it but what about attached patch?
It may fix your ARP issue. The patch also fixes other issues
related with ioctls.
Now em(4) will send a ARP packet when its IP address is changed even
if there is no active link. Since em(4) is not mii-aware driver I
can't sure this behaviour is correct.
--
Regards,
Pyun YongHyeon
Index: if_em.c
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.116
diff -u -r1.116 if_em.c
--- if_em.c 6 Jun 2006 08:03:49 - 1.116
+++ if_em.c 1 Jul 2006 03:51:41 -
@@ -692,7 +692,8 @@
EM_LOCK_ASSERT(sc);
- if (!sc-link_active)
+ if ((ifp-if_drv_flags (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) !=
+ IFF_DRV_RUNNING)
return;
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
@@ -751,11 +752,6 @@
return (error);
switch (command) {
- case SIOCSIFADDR:
- case SIOCGIFADDR:
- IOCTL_DEBUGOUT(ioctl rcv'd: SIOCxIFADDR (Get/Set Interface
Addr));
- ether_ioctl(ifp, command, data);
- break;
case SIOCSIFMTU:
{
int max_frame_size;
@@ -802,17 +798,19 @@
IOCTL_DEBUGOUT(ioctl rcv'd: SIOCSIFFLAGS (Set Interface
Flags));
EM_LOCK(sc);
if (ifp-if_flags IFF_UP) {
- if (!(ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING)) {
+ if ((ifp-if_flags ^ sc-if_flags)
+ IFF_PROMISC) {
+ em_disable_promisc(sc);
+ em_set_promisc(sc);
+ }
+ } else
em_init_locked(sc);
- }
-
- em_disable_promisc(sc);
- em_set_promisc(sc);
} else {
- if (ifp-if_drv_flags IFF_DRV_RUNNING) {
+ if (ifp-if_drv_flags IFF_DRV_RUNNING)
em_stop(sc);
- }
}
+ sc-if_flags = ifp-if_flags;
EM_UNLOCK(sc);
break;
case SIOCADDMULTI:
@@ -878,8 +876,8 @@
break;
}
default:
- IOCTL_DEBUGOUT1(ioctl received: UNKNOWN (0x%x), (int)command);
- error = EINVAL;
+ error = ether_ioctl(ifp, command, data);
+ break;
}
return (error);
Index: if_em.h
===
RCS file: /pool/ncvs/src/sys/dev/em/if_em.h,v
retrieving revision 1.44
diff -u -r1.44 if_em.h
--- if_em.h 15 Feb 2006 08:39:50 - 1.44
+++ if_em.h 1 Jul 2006 03:51:41 -
@@ -259,6 +259,7 @@
struct callout timer;
struct callout tx_fifo_timer;
int io_rid;
+ int if_flags;
struct mtx mtx;
int em_insert_vlan_header;
struct task link_task;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, Jun 30, 2006 at 05:48:23PM -0300, User Freebsd wrote: On Fri, 30 Jun 2006, Atanas wrote: A workaround is to power both of the systems down and then power them up. This however cannot be done remotely and in case there were IP aliases, they still don't get any traffic. see 'arping' ... great little tool, solved all my problems as far as moving around IPs ... The 'arping' should be teached to run correctly on Big endian systems. -- 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: em device hangs on ifconfig alias ...
Atanas wrote: Dan Nelson said the following on 6/28/06 3:52 PM: In the last episode (Jun 28), User Freebsd said: has anyone figured out why the em device 'hangs' for about 30-45 seconds whenever you ifconfig alias a new IP on to the device? The em driver resets the card when you add an IP to it, and unless you've configured your switch not to autodetect fancy features on that port, it may very well take 45 seconds for it to come up. For me the em reset actually takes about a second or so per single IP alias. But more aliases you got, longer the timeout becomes. In case you have hundreds (like I do), a single reboot might cost you something like 10-15 minutes of downtime, just for the aliases to come up. Does anybody know a better NIC driver alternative when dealing with lots of IP aliases? Regards, Atanas ___ For me its IP alias additions take 1 or maybe 2secs, but it is noticeable, but really isn't an issue for me. As far as I have noticed the em driver in 6.1 after being rebuilt is at its peak of driver quality, so much in fact that since 6.1 its recommended not to even bother with polling with em if you need maximum network performance as it won't go any faster, the em driver for 6.1 got very large performance improvement compared to older em driver versions before 6.1-release, which I suspect got over hacked over time. I am pretty sure I used to only be able to get 200,300mbits/sec max but now I can get up to 850mbits on some and on the lowest side 500mbits/sec on others which I suspect is due to cable quality etc. I am just thankful for it working as it is. Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Thu, 2006-Jun-29 17:30:07 +1000, Michael Vince wrote: For me its IP alias additions take 1 or maybe 2secs, but it is noticeable, but really isn't an issue for me. But it obviously is for Atanas, who has 100's of aliases. As far as I have noticed the em driver in 6.1 after being rebuilt is at its peak of driver quality, ... now I can get up to 850mbits on some and on the lowest side 500mbits/sec on others which I suspect is due to cable quality etc. In other words, the shortcomings of the em device/driver aren't an issue for you. Other people have different requirements and the em(4) is currently unsuitable for them. -- Peter Jeremy pgpCzMs0W9tP4.pgp Description: PGP signature
Re: em device hangs on ifconfig alias ...
On Thu, 29 Jun 2006, Peter Jeremy wrote: On Thu, 2006-Jun-29 17:30:07 +1000, Michael Vince wrote: For me its IP alias additions take 1 or maybe 2secs, but it is noticeable, but really isn't an issue for me. But it obviously is for Atanas, who has 100's of aliases. In my case, it isn't 100's, but the problem is noticeable ... I have my start up scripts, right now, do the ifconfig, sleep for 45 seconds, and then start up the jail ... and even then, apache doesn't *always* start up, since sometimes that isn't long enough for the network to come back up for DNS to be reachable :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
Atanas writes: I have some newer machines with 2 Broadcom chips on-board. I plan to give them a try at some point in the future, but I'm not sure how stable the bge driver For us they have been a problem. Primarily because it causes all kinds of freezing/crashes when having an IPMI board. I believe it has performed ok in machines where we don't have an IPMI card. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
User Freebsd wrote: On Thu, 29 Jun 2006, Peter Jeremy wrote: On Thu, 2006-Jun-29 17:30:07 +1000, Michael Vince wrote: For me its IP alias additions take 1 or maybe 2secs, but it is noticeable, but really isn't an issue for me. But it obviously is for Atanas, who has 100's of aliases. In my case, it isn't 100's, but the problem is noticeable ... I have my start up scripts, right now, do the ifconfig, sleep for 45 seconds, and then start up the jail ... and even then, apache doesn't *always* start up, since sometimes that isn't long enough for the network to come back up for DNS to be reachable :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) The thing that have to ask is if Atanas has 100's why can't he just boot Freebsd have have them all prebound to the interface at startup, why would you need to add and remove them constantly by the hundreds during normal server uptime? I do restart my jails now and then, but because the IPs are already bound to the interface I don't have any pause issues. Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Fri, 30 Jun 2006, Michael Vince wrote: The thing that have to ask is if Atanas has 100's why can't he just boot Freebsd have have them all prebound to the interface at startup, why would you need to add and remove them constantly by the hundreds during normal server uptime? I do restart my jails now and then, but because the IPs are already bound to the interface I don't have any pause issues. In my case, I move jails around between machines for load balancing reasons ... so, a physical server may be up for, hell, in one case, 211 days, but a vServer may only have been on it a few days ... The other funny thing about the current em driver is that if you move an IP to it from a different server, the appropriate ARP packets aren't sent out to redirect the IP traffic .. recently, someone pointed me to arping, which has solved my problem *external* to the driver ... I have a third machine that uses an em driver, but its an older 4.x kernel, and it operates perfectly ... no timeouts/hangs and sends out the appropriate ARP packet ... all three servers are connected to the same Cisco switch, with all ports configured identically, so it isn't a switch issue, as someone else intimated ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
em device hangs on ifconfig alias ...
has anyone figured out why the em device 'hangs' for about 30-45 seconds whenever you ifconfig alias a new IP on to the device? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
In the last episode (Jun 28), User Freebsd said: has anyone figured out why the em device 'hangs' for about 30-45 seconds whenever you ifconfig alias a new IP on to the device? The em driver resets the card when you add an IP to it, and unless you've configured your switch not to autodetect fancy features on that port, it may very well take 45 seconds for it to come up. See: http://www.cisco.com/warp/public/473/12.html Using PortFast and Other Commands to Fix Workstation Startup Connectivity Delays -- 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]
Re: em device hangs on ifconfig alias ...
Dan Nelson said the following on 6/28/06 3:52 PM: In the last episode (Jun 28), User Freebsd said: has anyone figured out why the em device 'hangs' for about 30-45 seconds whenever you ifconfig alias a new IP on to the device? The em driver resets the card when you add an IP to it, and unless you've configured your switch not to autodetect fancy features on that port, it may very well take 45 seconds for it to come up. For me the em reset actually takes about a second or so per single IP alias. But more aliases you got, longer the timeout becomes. In case you have hundreds (like I do), a single reboot might cost you something like 10-15 minutes of downtime, just for the aliases to come up. That's the primary reason I stay away from the on-board 1Gbps em NICs that almost every Intel server board nowadays comes with. I simply disable them and use a good old (and cheap) Intel PRO/100 fxp compatible PCI NIC instead. It's fast enough and doesn't reset the card when you add an alias. The only downside is that it gives you 100Mbps at most. Does anybody know a better NIC driver alternative when dealing with lots of IP aliases? I have some newer machines with 2 Broadcom chips on-board. I plan to give them a try at some point in the future, but I'm not sure how stable the bge driver is when compared to fxp and em. Regards, Atanas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em device hangs on ifconfig alias ...
On Wed, 28 Jun 2006, Atanas wrote: I have some newer machines with 2 Broadcom chips on-board. I plan to give them a try at some point in the future, but I'm not sure how stable the bge driver is when compared to fxp and em. I'm using the bge driver on our new HP servers, and haven't noticed any problems with them to date ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
