public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: arno@natisbad•org (Arnaud Ebalard)
To: Brian Haley <brian.haley@hp•com>
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 17:34:30 +0200	[thread overview]
Message-ID: <87pqwff2bd.fsf@small.ssi.corp> (raw)
In-Reply-To: <4C90E11B.7020807@hp.com> (Brian Haley's message of "Wed, 15 Sep 2010 11:07:07 -0400")

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?
 
> 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.

Cheers,

a+

  reply	other threads:[~2010-09-15 15:33 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 [this message]
2010-09-15 16:01     ` Brian Haley
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=87pqwff2bd.fsf@small.ssi.corp \
    --to=arno@natisbad$(echo .)org \
    --cc=brian.haley@hp$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=e1000-devel@lists$(echo .)sourceforge.net \
    --cc=jeffrey.t.kirsher@intel$(echo .)com \
    --cc=jesse.brandeburg@intel$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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