Subject: Re: E1000E/82567LM-3: link reported up too soon

From: Brian Haley <[email-masked]>
Date: Wed, 15 Sep 2010 12:01:55 -0400

Hi Arnaud,

On 09/15/2010 11:34 AM, Arnaud Ebalard wrote:
> Hi Brian,
> 
> Brian Haley <[email-masked]> writes:
> 
>>> <snip>
>>>
>>> I tested it with 2 different 100M/s switches (Cisco Catalyst 2960 and a
>>> Planex FX08-Mini) so I guess the switch is not the root of the issue. I
>>> came to the conclusion that the link is reported up too soon by the
>>> driver.
>>>
>>> Because the first packets are losts, the result is that address
>>> autoconfiguration is delayed by a few seconds as can be seen on
>>> following capture on the laptop:
>>
>> I've seen similar things on various NICs,
> 
> I remember I add the same kind of issue on a broadcom chip on a dell
> D600 but had no time to investigate at that time. Did you notice the
> problem for different brands? Do you think those are driver-related
> issues or something in common code?

I know I've seen this on an 82571EB (HP NC364T), but I also *thought* I
saw it with bnx2 as well (5708), but I'm not at the moment.  So maybe
this is just hardware or driver-related?  This is what I see:

 [87878.453422] ADDRCONF(NETDEV_UP): eth6: link is not ready
 [87880.298458] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
 [87880.299296] ADDRCONF(NETDEV_CHANGE): eth6: link becomes ready
 [87881.369642] e1000e: eth6 NIC Link is Down
 [87883.418475] e1000e: eth6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Procurve 5400zl switch, standard settings on the port and NIC.

>> posted a patch last week that unfortunately had other bad
>> side-effects.  When I have time I'll work on it again, but I'd also be
>> curious if there's something that can be done at the driver level to
>> help out, since it seemed like part of the problem is that the link-UP
>> came before the device was actually able to transmit packets, so the
>> DAD was lost.
> 
> I am not familiar with e1000e code but as I said previously I'd be happy
> to test patches to help determine precisely where the packet gets lost
> and why.

I'm not either, the patches I've tried are all for IPv6.

-Brian