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.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
