From owner-freebsd-stable@FreeBSD.ORG Sat Jul 8 17:19:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1A7916A4DA; Sat, 8 Jul 2006 17:19:33 +0000 (UTC) (envelope-from ru@ip.net.ua) Received: from cielago.ip.net.ua (cielago.ip.net.ua [82.193.96.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACDBC43D46; Sat, 8 Jul 2006 17:19:32 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by cielago.ip.net.ua (8.13.6/8.13.6) with ESMTP id k68HIjp9041187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Jul 2006 20:18:45 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.6/8.13.6) id k68HK2P3078400; Sat, 8 Jul 2006 20:20:02 +0300 (EEST) (envelope-from ru) Date: Sat, 8 Jul 2006 20:20:01 +0300 From: Ruslan Ermilov To: Pyun YongHyeon Message-ID: <20060708172001.GB77281@ip.net.ua> References: <20060706021444.GA76865@cdnetworks.co.kr> <44AD7297.7080605@asd.aplus.net> <20060707010341.GD82406@cdnetworks.co.kr> <44ADC2ED.4070904@asd.aplus.net> <20060707040838.GE82406@cdnetworks.co.kr> <20060707151640.D51390@fledge.watson.org> <44AEB0CB.5060102@asd.aplus.net> <20060707181750.O1171@ganymede.hub.org> <20060707223609.N60542@fledge.watson.org> <20060708033254.GB87930@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <20060708033254.GB87930@cdnetworks.co.kr> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new Cc: freebsd-stable@freebsd.org, Peter Jeremy , Atanas , User Freebsd , Robert Watson , Michael Vince Subject: Re: em device hangs on ifconfig alias ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2006 17:19:33 -0000 --0vzXIDBeUiKkjNJl Content-Type: multipart/mixed; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >=20 > > On Fri, 7 Jul 2006, User Freebsd wrote: > >=20 > > >>I think that I have patched, built and loaded the em(4) kernel modul= e=20 > > >>correctly. After applying the patch there were no rejects, before=20 > > >>building the module I intentionally appended " (patched)" to its ver= sion=20 > > >>string in if_em.c, and could see that in dmesg every time I loaded t= he=20 > > >>module: em1: > >>(patched)> > > > > > >Is it possible that we're going at this issue backwards? It isn't th= e=20 > > >lack of ARP packet going out that is causing the problems with moving= IPs,=20 > > >but that delay that we're seeing when aliasing a new IP on the stack?= The=20 > > >ARP packet *is* being attempted, but is timing out before the re-init= is=20 > > >completing? > >=20 > > Yes -- basically, there are two problems: > >=20 > > (1) A little problem, in which an arp announcement is sent before the = link=20 > > has > > settled after reset. > >=20 > > (2) A big problem, in which the interface is gratuitously recent requi= ring > > long settling times. > >=20 > > I'd really like to see a fix to the second of these problems (not rese= tting=20 > > when an IP is added or removed, resulting in link renegotiation); the = first=20 > > one I'm less concerned about, although it would make some amount of se= nse=20 > > to do an arp announcement when the link goes up. > >=20 >=20 > Ah, I see. Thanks for the insight. > How about the attached patch? >=20 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, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --cvVnyQ+4j833TQvp Content-Type: message/rfc822 Content-Disposition: inline Date: Thu, 31 Mar 2005 10:59:40 +0300 From: Ruslan Ermilov To: Mike Tancsa Subject: Re: em(4) + bridging Message-ID: <20050331075940.GA75268@ip.net.ua> References: <424AB340.1060207@puffy.nu> <20050330151027.GA28805@ip.net.ua> <20050331070152.GA75009@ip.net.ua> <20050331072025.GB75009@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20050331072025.GB75009@ip.net.ua> User-Agent: Mutt/1.5.9i --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, > >=20 > > 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! ;-) > > >=20 > > > eg ifconfig em0 192.168.13.9 netmask 255.255.255.252 alias > > >=20 > > > 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 :( > > >=20 > > Is this also a problem in HEAD, or only in RELENG_5? > >=20 > OK, I can easily reproduce the problem here, hold on. >=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 -0000 1.62 +++ if_em.c 31 Mar 2005 07:41:47 -0000 @@ -832,12 +832,14 @@ em_init_locked(struct adapter * adapter) bcopy(adapter->interface_data.ac_enaddr, adapter->hw.mac_addr, ETHER_ADDR_LEN); =20 +#if 0 /* Initialize the hardware */ if (em_hardware_init(adapter)) { printf("em%d: Unable to initialize the hardware\n",=20 adapter->unit); return; } +#endif =20 if (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) em_enable_vlans(adapter); %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCS63sqRfpzJluFF4RAnZHAKCBea2pVCJ30D/DMmhd/agISU9y+QCfbwMI tklANWUVCgjgYYAsxGW1+rM= =beCd -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- --cvVnyQ+4j833TQvp-- --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFEr+lBqRfpzJluFF4RAiffAKCIt9H003toOJhYlHOfk4yz8y33GACfV0LE LEmvFXwPDwIGdLCaIXisR8E= =nECB -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl--