Date: Sat, 08 Jul 2006 17:28:50 +1000 From: Michael Vince <mv@thebeastie.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Pyun YongHyeon <pyunyh@gmail.com>, Peter Jeremy <peterjeremy@optushome.com.au>, Atanas <atanas@asd.aplus.net>, freebsd-stable@FreeBSD.org, User Freebsd <freebsd@hub.org> Subject: Re: em device hangs on ifconfig alias ... Message-ID: <44AF5EB2.2040701@thebeastie.org> In-Reply-To: <20060707223609.N60542@fledge.watson.org> References: <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> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 thought I remember a developer working on the em driver saying just before 6.1 was released that this reset was needed and couldn't be avoided to ensure performance of the device to work at its best, I can't remember his explanation, but this topic has come up before, of course anything is possible to fix. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44AF5EB2.2040701>