netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Haley <brian.haley@hp.com>
To: Arnaud Ebalard <arno@natisbad.org>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: E1000E/82567LM-3: link reported up too soon
Date: Wed, 15 Sep 2010 12:01:55 -0400	[thread overview]
Message-ID: <4C90EDF3.8010401@hp.com> (raw)
In-Reply-To: <87pqwff2bd.fsf@small.ssi.corp>

Hi Arnaud,

On 09/15/2010 11:34 AM, Arnaud Ebalard wrote:
> Hi Brian,
> 
> Brian Haley <brian.haley@hp.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

  reply	other threads:[~2010-09-15 16:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 13:48 E1000E/82567LM-3: link reported up too soon Arnaud Ebalard
2010-09-15 15:07 ` Brian Haley
2010-09-15 15:34   ` Arnaud Ebalard
2010-09-15 16:01     ` Brian Haley [this message]
2010-09-18 14:14       ` Arnaud Ebalard
2010-09-20 18:22         ` David Miller
2010-09-20 18:57           ` Arnaud Ebalard
2010-09-20 19:54             ` David Miller
2010-09-20 20:09               ` Arnaud Ebalard
2010-09-20 20:18                 ` David Miller
2010-09-20 20:22                   ` Arnaud Ebalard
2010-09-20 21:28                   ` Arnaud Ebalard
2010-09-20 22:23                     ` David Miller
2010-09-21 11:03                       ` Arnaud Ebalard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C90EDF3.8010401@hp.com \
    --to=brian.haley@hp.com \
    --cc=arno@natisbad.org \
    --cc=davem@davemloft.net \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).