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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C90EDF3.8010401@hp.com>
Date:	Wed, 15 Sep 2010 12:01:55 -0400
From:	Brian Haley <brian.haley@...com>
To:	Arnaud Ebalard <arno@...isbad.org>
CC:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: E1000E/82567LM-3: link reported up too soon

Hi Arnaud,

On 09/15/2010 11:34 AM, Arnaud Ebalard wrote:
> Hi Brian,
> 
> Brian Haley <brian.haley@...com> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html