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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"