On 12/30/2015 02:55 PM, Tantilov, Emil S wrote:
>> -Original Message-
>> From: zhuyj [mailto:zyjzyj2...@gmail.com]
>> Sent: Tuesday, December 29, 2015 6:49 PM
>> To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>> Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bru
From: Zhu Yanjun
In X540 NIC, there is a time span between reporting "link on" and
getting the speed and duplex. To a bonding driver in 802.3ad mode,
this time span will make it not work well if the time span is big
enough. The big time span will make bonding driver change the state of
the slave
Hi, all
According to Rustad, Mark D, maybe it is related with copper phy. To make fiber
phy more
robust, synchronize both the link_up and link_speed of a slave interface in
ixgbe driver.
Best Regards!
Zhu Yanjun
--
__
From: Zhu Yanjun
According to the suggestion from Rustad, Mark D, this behavior perhaps
is more related to the copper phy. But to make fiber phy more robust,
to all the interfaces as a slave interface, the link_speed and link_up
is synchronized.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethern
From: Zhu Yanjun
When the X540 NIC acts as a slave of some virtual NICs, it is very
important to synchronize link_up and link_speed, such as a bonding
driver in 802.3ad mode. When X540 NIC acts as an independent interface,
it is not necessary to synchronize link_up and link_speed. That is,
the ti
>-Original Message-
>From: zhuyj [mailto:zyjzyj2...@gmail.com]
>Sent: Wednesday, December 30, 2015 12:20 AM
>To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>John; Williams, Mitch A; intel-wired-..
Can't get ixgbevf 3.0.3 or 3.1.1:
http://sourceforge.net/projects/e1000/files/ixgbevf%20stable/3.0.3/ixgbevf-3.0.3.tar.gz/download
http://sourceforge.net/projects/e1000/files/ixgbevf%20stable/3.1.1/ixgbevf-3.1.1.tar.gz/download
The web interface doesn't actually display an error, just redirects m
I'm having the same issue with anything I attempt to download from Source
Forge. We don't directly control the hosting site, it might be worthwhile to
report this to Source Forge itself.
Thanks,
-Don Skidmore
> -Original Message-
> From: Steven Noonan [mailto:ste...@uplinklabs.net]
>
I cut a ticket:
https://sourceforge.net/p/forge/site-support/11820/
On Wed, Dec 30, 2015 at 4:21 PM, Skidmore, Donald C
wrote:
> I'm having the same issue with anything I attempt to download from Source
> Forge. We don't directly control the hosting site, it might be worthwhile to
> report th
zyjzyj2...@gmail.com wrote:
> From: Zhu Yanjun
>
> According to the suggestion from Rustad, Mark D, this behavior perhaps
> is more related to the copper phy. But to make fiber phy more robust,
> to all the interfaces as a slave interface, the link_speed and link_up
> is synchronized.
>
> Signe
From: Zhu Yanjun
According to the suggestions from Rustad, Mark D, to all the slave
interfaces, the link_speed and link_up should be synchronized since
the time span between link_up and link_speed will make some virtual
NICs not work well, such as a bonding driver in 802.3ad mode.
Signed-off-by
Hi, all
Thanks for the suggestions from Rustad, Mark D.
According to his suggestions, the logs and source code are simplified.
Zhu Yanjun
--
___
E1000-devel mailing list
E1000
On Thu, 2015-12-31 at 13:04 +0800, zyjzyj2...@gmail.com wrote:
> Thanks for the suggestions from Rustad, Mark D.
> According to his suggestions, the logs and source code are
> simplified.
I find it funny that this email (no patch) is got the correct subject,
yet the updated patch you sent does not
On 12/31/2015 01:17 PM, Jeff Kirsher wrote:
> On Thu, 2015-12-31 at 13:04 +0800, zyjzyj2...@gmail.com wrote:
>> Thanks for the suggestions from Rustad, Mark D.
>> According to his suggestions, the logs and source code are
>> simplified.
> I find it funny that this email (no patch) is got the correc
On Thu, 2015-12-31 at 13:04 +0800, zyjzyj2...@gmail.com wrote:
> From: Zhu Yanjun
>
> According to the suggestions from Rustad, Mark D, to all the slave
> interfaces, the link_speed and link_up should be synchronized since
> the time span between link_up and link_speed will make some virtual
> N
From: Zhu Yanjun
According to the suggestions from Rustad, Mark D, to all the slave
interfaces, the link_speed and link_up should be synchronized since
the time span between link_up and link_speed will make some virtual
NICs not work well, such as a bonding driver in 802.3ad mode.
Signed-off-by
Hi, all
Thanks for the reply from Jeff.
V2: Based on feedback from Jeff Kirsher, it is not appropriate to continue
in the function ixgbe_watchdog_link_is_up without link_speed since this will
make some virtual NICs not work well.
V3: Based on feedback from Emil Tantilov, the time span b
17 matches
Mail list logo
