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