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>