Date: Mon, 10 Jul 2006 11:01:59 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Ruslan Ermilov <ru@freebsd.org> Cc: freebsd-stable@freebsd.org, Peter Jeremy <peterjeremy@optushome.com.au>, Atanas <atanas@asd.aplus.net>, User Freebsd <freebsd@hub.org>, Robert Watson <rwatson@freebsd.org>, Michael Vince <mv@thebeastie.org> Subject: Re: em device hangs on ifconfig alias ... Message-ID: <20060710020158.GA1128@cdnetworks.co.kr> In-Reply-To: <20060708172001.GB77281@ip.net.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <Intel(R) PRO/1000 Network Connection Version - 3.2.18 > > > >>(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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060710020158.GA1128>