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.
Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer
--- Begin Message ---On Thu, Mar 31, 2005 at 10:20:25AM +0300, Ruslan Ermilov wrote: > On Thu, Mar 31, 2005 at 10:01:52AM +0300, Ruslan Ermilov wrote: > > Hi Mike, > > > > On Wed, Mar 30, 2005 at 08:03:21PM -0500, Mike Tancsa wrote: > > [...] > > > If you could somehow fix the problem with em bouncing its interface > > > when you add or remove an alias from it (RELENG_5), I would gladly > > > send you two nics! ;-) > > > > > > eg ifconfig em0 192.168.13.9 netmask 255.255.255.252 alias > > > > > > will down and up the interface. If the switch port it is in has STP, > > > the port will go into blocking for 30 seconds, which is really > > > troublesome :( > > > > > Is this also a problem in HEAD, or only in RELENG_5? > > > OK, I can easily reproduce the problem here, hold on. > I'm not fully sure this is a right fix, but it works for me. Here's what happens: on SIOCSIFADDR, em_ioctl() is called, then ether_ioctl() which calls em_init() which calls em_hardware_init() (for some odd reason I don't understand). em_hardware_init() is correctly called on attach, so I don't understand why it's also needed in em_init(). Anyway, the hack is as easy as this: %%% Index: if_em.c =================================================================== RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v retrieving revision 1.62 diff -u -p -r1.62 if_em.c --- if_em.c 5 Mar 2005 18:30:10 -0000 1.62 +++ if_em.c 31 Mar 2005 07:41:47 -0000 @@ -832,12 +832,14 @@ em_init_locked(struct adapter * adapter) bcopy(adapter->interface_data.ac_enaddr, adapter->hw.mac_addr, ETHER_ADDR_LEN); +#if 0 /* Initialize the hardware */ if (em_hardware_init(adapter)) { printf("em%d: Unable to initialize the hardware\n", adapter->unit); return; } +#endif if (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) em_enable_vlans(adapter); %%% Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer
pgpsRxXyUafG6.pgp
Description: PGP signature
--- End Message ---
pgpFvy5lSGyI8.pgp
Description: PGP signature
