em device hangs on ifconfig alias ...

[Pyun YongHyeon]

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