From owner-freebsd-stable@FreeBSD.ORG Mon Jul 10 02:02:17 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 F18C116A4DA for ; Mon, 10 Jul 2006 02:02:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45AC543D45 for ; Mon, 10 Jul 2006 02:02:15 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by nz-out-0102.google.com with SMTP id v1so44595nzb for ; Sun, 09 Jul 2006 19:02:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=XL2fy0arzOFQmk+tuUL21b9WekLdaewRN4Jv0Z6EOYqWFAxP7dTz4gdjNvEx64ppwD8ZuVfiJyu/UTS8EDVFri0eRv6EVatrOO9oiRSqkTAyul3unP9bZKwdsENokK9uIoIQ+AHA91EI/CrhFLuBA30eagJxnUiUBW6VIeGDMrI= Received: by 10.36.138.15 with SMTP id l15mr4128704nzd; Sun, 09 Jul 2006 19:02:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id c12sm1059458nzc.2006.07.09.19.02.10; Sun, 09 Jul 2006 19:02:14 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k6A227nu001728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jul 2006 11:02:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k6A21xLo001727; Mon, 10 Jul 2006 11:01:59 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 10 Jul 2006 11:01:59 +0900 From: Pyun YongHyeon To: Ruslan Ermilov Message-ID: <20060710020158.GA1128@cdnetworks.co.kr> References: <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> <20060708172001.GB77281@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060708172001.GB77281@ip.net.ua> User-Agent: Mutt/1.4.2.1i 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 Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 02:02:17 -0000 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: > > >>(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