From: Jay Vosburgh <fubar@us.ibm.com>
To: Jonathan Thibault <jonathan@navigue.com>
Cc: netdev@vger.kernel.org, Francois Romieu <romieu@fr.zoreil.com>
Subject: Re: Bonding/LACP on RTL8169sc/8110sc (R1869)
Date: Tue, 12 Apr 2011 15:47:45 -0700 [thread overview]
Message-ID: <13118.1302648465@death> (raw)
In-Reply-To: <4DA45518.60407@navigue.com>
Jonathan Thibault <jonathan@navigue.com> wrote:
>I have a a pair of Jetway motherboards with an add-on 3Gbit LAN modules
>and have been doing some testing for a linux router project. I found
>that I while I can get LACP working properly using eth0 and eth1, using
>the exact same setup with any of the other three lan fails. Is this a
>known issue?
Fails how, exactly? If eth2/3/4 is part of the bond, then no
aggregation forms at all, or those devices don't join, or what?
>This is on Linux 2.6.32.10. Here is a blurb of dmesg showing the NICs
>detected.
That's a fairly old kernel; one relatively recent fix that comes
to mind is:
commit ab12811c89e88f2e66746790b1fe4469ccb7bdd9
Author: Andy Gospodarek <andy@greyhouse.net>
Date: Fri Sep 10 11:43:20 2010 +0000
bonding: correctly process non-linear skbs
It was recently brought to my attention that 802.3ad mode bonds would no
longer form when using some network hardware after a driver update.
After snooping around I realized that the particular hardware was using
page-based skbs and found that skb->data did not contain a valid LACPDU
as it was not stored there. That explained the inability to form an
802.3ad-based bond. For balance-alb mode bonds this was also an issue
as ARPs would not be properly processed.
>eth0: RTL8168b/8111b at 0xf8adc000, 00:30:18:ac:a6:80, XID 0c200000 IRQ 24
>eth1: RTL8168b/8111b at 0xf8ae0000, 00:30:18:ac:a6:81, XID 0c200000 IRQ 25
>eth2: RTL8169sc/8110sc at 0xf8ae4c00, 00:30:18:ae:34:3a, XID 18000000 IRQ 18
>eth3: RTL8169sc/8110sc at 0xf8ae8800, 00:30:18:ae:34:3b, XID 18000000 IRQ 19
>eth4: RTL8169sc/8110sc at 0xf8aec400, 00:30:18:ae:34:3c, XID 18000000 IRQ 16
The fix might apply if your eth2/3/4 hardware uses page based
skbs as mentioned in this commit.
Also, what is your network topology? Are all the devices
connected to the same switch?
>I can probably manage this project using only eth0 and eth1 in LACP
>configuration but I figured I'd give a heads up.
>
>The interfaces seem able to detect when the link is up or down, bonding
>removes and adds them to the LACP trunk but I can't get traffic through
>them.
If the above commit doesn't resolve the problem, can you post
some sample output of /proc/net/bonding/bondX (with the appropriate
value for "X") when you've got the "bad" devices in the bond, along with
a description of exactly what doesn't work?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2011-04-12 22:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 13:35 Bonding/LACP on RTL8169sc/8110sc (R1869) Jonathan Thibault
2011-04-12 22:47 ` Jay Vosburgh [this message]
2011-04-13 17:49 ` François Romieu
2011-04-13 18:28 ` Ben Hutchings
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=13118.1302648465@death \
--to=fubar@us.ibm.com \
--cc=jonathan@navigue.com \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
/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).