Date: Wed, 05 Jul 2006 18:29:55 -0700 From: Atanas <atanas@asd.aplus.net> To: pyunyh@gmail.com 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: <44AC6793.2070608@asd.aplus.net> In-Reply-To: <20060701035416.GC54876@cdnetworks.co.kr> References: <20060628185426.M43909@ganymede.hub.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -0000 1.116
> +++ if_em.c 1 Jul 2006 03:51:41 -0000
> @@ -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 -0000 1.44
> +++ if_em.h 1 Jul 2006 03:51:41 -0000
> @@ -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 "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AC6793.2070608>