From: Jesper Krogh <jesper@krogh.cc>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Jeff Garzik <jgarzik@redhat.com>,
aowi@novozymes.com
Subject: Re: Regression in bonding between 2.6.26.8 and 2.6.27.6 - bisected
Date: Sat, 28 Feb 2009 18:21:55 +0100 [thread overview]
Message-ID: <49A972B3.8020309@krogh.cc> (raw)
In-Reply-To: <30478.1235766943@death.nxdomain.ibm.com>
Jay Vosburgh wrote:
> Jesper Krogh <jesper@krogh.cc> wrote:
>
>> Jay Vosburgh wrote:
>>> Jesper Krogh <jesper@krogh.cc> wrote:
>>> [...]
>>>> The offending commit seems to be:
>>>>
>>>> A test with a fresh 2.6.29-rc6 revealed that the problem has been fixed
>>>> subsequently.. but still exists in 2.6.27-newest. (havent tested
>>>> 2.6.28-newest yet).
>>>>
>>>> Any ideas of what the "fixing" commit is .. or should that also be
>>>> bisected?
>>> I went back and looked at your earlier mail. Since you're using
>>> 802.3ad mode, my first guess would be this commit:
>>>
>>> commit fd989c83325cb34795bc4d4aa6b13c06f90eac99
>>> Author: Jay Vosburgh <fubar@us.ibm.com>
>>> Date: Tue Nov 4 17:51:16 2008 -0800
>>>
>>> bonding: alternate agg selection policies for 802.3ad
>> That didn't do it.. I applied it to 2.6.27.19 but it didnt make that work.
>> dmesg | grep bond (2.6.27.19 + above patch).
>
> That was the only real functional change to 802.3ad, there are a
> lot of other commits, but they're all style or cleanup sorts of things.
>
>> [ 13.643301] bonding: MII link monitoring set to 100 ms
>> [ 13.730455] bonding: bond0: enslaving eth0 as a backup interface with
>> an up link.
>> [ 13.781934] bonding: bond0: enslaving eth1 as a backup interface with
>> an up link.
>> [ 13.904665] bonding: bond0: enslaving eth2 as a backup interface with a
>> down link.
>> [ 16.945264] bonding: bond0: link status definitely up for interface eth2.
>> [ 75.040290] bond0: no IPv6 routers present
>>
>> dmesg | grep bond (2.6.29-rc6)
>>
>> $ ssh quad02 dmesg | grep bond
>> [ 27.437877] bonding: MII link monitoring set to 100 ms
>> [ 27.445246] ADDRCONF(NETDEV_UP): bond0: link is not ready
>> [ 27.493260] bonding: bond0: enslaving eth0 as a backup interface with a
>> down link.
>> [ 27.521397] bonding: bond0: enslaving eth1 as a backup interface with a
>> down link.
>> [ 27.542332] bonding: bond0: Warning: No 802.3ad response from the link
>> partner for any adapters in the bond
>> [ 27.611509] bonding: bond0: enslaving eth2 as a backup interface with a
>> down link.
>> [ 27.617017] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
>> [ 27.642330] bonding: bond0: Warning: No 802.3ad response from the link
>> partner for any adapters in the bond
>> [ 30.042501] bonding: bond0: link status definitely up for interface eth1.
>> [ 30.142505] bonding: bond0: link status definitely up for interface eth0.
>> [ 30.742547] bonding: bond0: link status definitely up for interface eth2.
>> [ 37.875044] bond0: no IPv6 routers present
>>
>> I just tested 2.6.28.7.. it still broken. So the fix probably has to be
>> somewhere in the post 2.6.28 sets.
>
> It looks like the above two tests are on different machines, or
> were at least done with different network cards. Is that the case?
There is 12 Sun Fire X2200 in the rack, they are fully identical (some
with a small difference in memory configuration as the only difference.
So yes, different machines, but same hardware (bought in the same
shipment, etc. etc).
> I'm just wondering if what you're seeing is somehow tied to the
> network devices' respective autonegotiation speeds, or some difference
> in the device drivers. The first dmesg looks to have one slow (3 sec)
> and two fast ones; the second dmesg looks to have all slow devices.
>
> Have you tried the kernels the other way around (the first
> kernel on the second machine, and vice versa)?
Yes, I've randomly picked a machine in the set to do the test, they all
falls out as "predicted".
> I'll compile 2.6.28.7 here and see if it works for me.
Jesper
--
Jesper
next prev parent reply other threads:[~2009-02-28 17:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-16 9:41 Regression in bonding between 2.6.26.8 and 2.6.27.6 Jesper Krogh
2008-11-17 23:45 ` Jay Vosburgh
2008-11-18 20:24 ` Jesper Krogh
2008-11-18 20:28 ` Jesper Krogh
2008-11-18 20:53 ` Jay Vosburgh
2008-11-19 7:53 ` Jesper Krogh
2008-12-08 20:42 ` Brandeburg, Jesse
2008-11-19 10:01 ` Jesper Krogh
2009-02-27 9:25 ` Regression in bonding between 2.6.26.8 and 2.6.27.6 - bisected Jesper Krogh
2009-02-27 16:28 ` Jay Vosburgh
2009-02-27 20:07 ` Jesper Krogh
2009-02-27 20:35 ` Jay Vosburgh
2009-02-28 17:21 ` Jesper Krogh [this message]
2009-03-01 6:21 ` Jesper Krogh
2009-03-01 13:19 ` Regression in bonding between 2.6.26.8 and 2.6.27.6 - bisected - twice Jesper Krogh
2009-03-05 18:51 ` Jay Vosburgh
2009-03-09 20:53 ` Jesper Krogh
2009-03-13 23:12 ` David Miller
2009-03-13 23:27 ` Jay Vosburgh
2009-03-16 20:34 ` Jesper Krogh
2009-03-16 20:35 ` David Miller
2009-03-17 20:18 ` Jesper Krogh
2009-03-19 1:39 ` David Miller
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=49A972B3.8020309@krogh.cc \
--to=jesper@krogh.cc \
--cc=aowi@novozymes.com \
--cc=fubar@us.ibm.com \
--cc=jgarzik@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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 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).