From: arno@natisbad.org (Arnaud Ebalard)
To: Brian Haley <brian.haley@hp.com>,
"David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: E1000E/82567LM-3: link reported up too soon
Date: Sat, 18 Sep 2010 16:14:16 +0200 [thread overview]
Message-ID: <87bp7vnnpj.fsf@small.ssi.corp> (raw)
In-Reply-To: <4C90EDF3.8010401@hp.com> (Brian Haley's message of "Wed, 15 Sep 2010 12:01:55 -0400")
Hi Brian and David, [removed Intel people from CC]
Brian Haley <brian.haley@hp.com> writes:
>> 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.
I definitely think the issue is not chipset-specific (keep reading) and
that it is not just a matter of few milliseconds. It also not
IPv6-specific.
I spent some additional time on it in userspace. I implemented a
*workaround* in UMIP to allow configuration of a per-interface
additional delay before sending RS after a link up event. I initially
thought few milliseconds would be sufficient. It is not. Obviously, this
gets better when delay is increased but still.
I progressively increased the value until RS is no more dropped. Below,
UMIP is configured to send RS only *550ms* after the RTM_NEWLINK event
(indicating link is up and running event) is received and the packet is
still dropped locally. Note that the IPv4 DHCP Request below is sent as
soon as link gets up to show the time difference (RS is indeed sent
550ms later):
15:12:32.728429 ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
15:12:33.256201 ethertype IPv6 (0x86dd), length 62: :: > ff02::2: ICMP6, router solicitation, length 8
15:12:35.729668 ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
15:12:35.741238 ethertype IPv4 (0x0800), length 590: 192.168.0.254.67 > 192.168.0.16.68: BOOTP/DHCP, Reply
The switch is a 5 ports Planex gigabit switch connected to the 82567LM-3
on my Dell E4300 (negotiated 1000baseT-FD flow-control, link ok). Still
on a 2.6.35.4 kernel.
Then, I decided to test with a totally different kind of ethernet
interface. An USB2 Ethernet 10/100 dongle. Here is what lsusb reports
about it:
Bus 002 Device 003: ID 0411:003d MelCo., Inc. LUA-U2-KTX Ethernet
Below, UMIP is configured w/o any additional delay before RS emission on
that interface. No DHCP running either:
15:40:22.984311 ethertype IPv6 (0x86dd), length 62: :: > ff02::2: ICMP6, router solicitation, length 8
15:40:26.984845 ethertype IPv6 (0x86dd), length 62: :: > ff02::2: ICMP6, router solicitation, length 8
15:40:26.989264 ethertype IPv6 (0x86dd), length 158: fe80::224:d5ff:fed4:476c > ff02::1: ICMP6, router advertisement
David, any idea on where this may come from and how to track the cause?
Cheers,
a+
next prev parent reply other threads:[~2010-09-18 14:14 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
2010-09-18 14:14 ` Arnaud Ebalard [this message]
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=87bp7vnnpj.fsf@small.ssi.corp \
--to=arno@natisbad.org \
--cc=brian.haley@hp.com \
--cc=davem@davemloft.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.