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-next>] [day] [month] [year] [list]
Message-ID: <871wkruu6p.fsf@kruemel.my-eitzenberger.de>
Date:	Thu, 15 Feb 2007 19:55:42 +0100
From:	Holger Eitzenberger <holger@...eitzenberger.de>
To:	shemminger@...ux-foundation.org
Cc:	sk-drivers@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: sky2 bonding problem, 802.3ad

Hi Steven,

I have problems using sky2 v1.10 with with bonding driver (802.3ad),
on 'Marvell 88E8053 PCI-E Gigabit Ethernet Controller'.  I have attached
the full lspci output.

My test was to setup a bond of two physical links (both links same
hardware) and ping 192.168.11.10, which is the address of the switch
itself.

I have tested v1.10 with kernel 2.6.19 and 2.6.16.36 (own backport),
which despite the bonding problem runs fine.  Both, kernel 2.6.19 and
2.6.16.36 show the same behaviour.  The 802.3ad aware switch is a Dell
PowerConnect 5324.  VLAN is not configured on all switch ports.  Another
test on a host running kernel 2.6.18.2 with two e1000's bonded runs
fine.  Using sk98lin (v8.41 & v10.0.4) worked also.

The host containing the Yukon-II has a total of 8 NICs, 4 PIC and 4
PCI-E, see attached lspci output.  The failed bond was created from two
PCI-E interfaces.

Find attached a short script which I use to set up the bond on both hosts,
also attached is a procfile (/proc/net/bonding/bond0) from
the "e1000 host" with a working bond as well as the procfile from the host
with the Yukon-II cards.

When looking at the working bond I see that both slave interfaces are
IFF_UP, the load is shared over both links.  When looking at the failing
sky2 bond I see that the bond is not IFF_UP, whereas both slave
interfaces are IFF_UP.  The 802.3ad "partner MAC address" is left all zero's, 
also both interfaces have different Aggregator IDs (1 & 2).  One of the
two failing interfaces always has IFF_NOARP set, caused by code
calling bond_main.c:bond_set_slave_inactive_flags().

I used both use_carrier=1 (default) as well as miimon=50 without luck.

Going through the bonding code, and comparing sky2 source to the e100
code, which I am quite familiar with, I see that sky2 does not use the
generic MII interface, which might point in the right direction.

I am currently going through the bonding code and try to understand the
master <-> slave <-> sky2 interaction, basically this is either through
calling the sky2 net_device ops and through the ethtool ops.

If you need further info or further testing from my side: i will gladly
do that.

Besides that, thanks for a great driver!

   /holger


Download attachment "bonding-prob.tgz" of type "application/x-gtar" (5174 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ