Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Jul 2006 11:14:44 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Atanas <atanas@asd.aplus.net>
Cc:        Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-stable@freebsd.org, Michael Vince <mv@thebeastie.org>, User Freebsd <freebsd@hub.org>
Subject:   Re: em device hangs on ifconfig alias ...
Message-ID:  <20060706021444.GA76865@cdnetworks.co.kr>
In-Reply-To: <44AC6793.2070608@asd.aplus.net>
References:  <20060628225239.GA93265@dan.emsphone.com> <44A3394C.4090209@asd.aplus.net> <44A3817F.4030105@thebeastie.org> <20060629092154.GE742@turion.vk2pj.dyndns.org> <20060629083130.X1229@ganymede.hub.org> <44A4A02A.9060802@thebeastie.org> <20060630012615.Q1103@ganymede.hub.org> <44A57B71.6020201@asd.aplus.net> <20060701035416.GC54876@cdnetworks.co.kr> <44AC6793.2070608@asd.aplus.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="em.arp.REL_6.patch"

--- if_em.c.orig	Fri 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);
--- if_em.h.orig	Thu Jul  6 11:06:17 2006
+++ if_em.h	Thu Jul  6 11:06:41 2006
@@ -331,6 +331,7 @@
 	struct callout	timer;
 	struct callout	tx_fifo_timer;
 	int             io_rid;
+	int		if_flags;
 	u_int8_t        unit;
 	struct mtx	mtx;
 	int		em_insert_vlan_header;

--1yeeQ81UyVL57Vl7--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060706021444.GA76865>