netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: Weiping Pan <wpan@redhat.com>, <netdev@vger.kernel.org>,
	<andy@greyhouse.net>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bonding:update speed/duplex for NETDEV_CHANGE
Date: Mon, 31 Oct 2011 20:48:28 +0000	[thread overview]
Message-ID: <1320094108.2735.15.camel@bwh-desktop> (raw)
In-Reply-To: <14973.1320093129@death>

On Mon, 2011-10-31 at 13:32 -0700, Jay Vosburgh wrote:
[...]
> 	This particular case arises only during enslavement.  The call
> to bond_update_speed_duplex call has failed, but the device is marked by
> bonding to be up.  Bonding complains that the device isn't down, but it
> cannot get speed and duplex, and therefore is assuming them to be
> 100/Full.
> 
> 	The catch is that this happens only for the ARP monitor, because
> it initially presumes a slave to be up regardless of actual carrier
> state (for historical reasons related to very old 10 or 10/100 drivers,
> prior to the introduction of netif_carrier_*).

Right, I gathered that.  Is there any reason to use the ARP monitor when
all slaves support link state notification?  Maybe the bonding
documentation should recommend miimon in section 7, not just in section
2.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

  reply	other threads:[~2011-10-31 20:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-31  2:53 When can a net device get its setting correctly ? WeipingPan
2011-10-31 14:19 ` [PATCH] bonding:update speed/duplex for NETDEV_CHANGE Weiping Pan
2011-10-31 18:15   ` Ben Hutchings
2011-10-31 20:32     ` Jay Vosburgh
2011-10-31 20:48       ` Ben Hutchings [this message]
2011-10-31 21:23         ` Jay Vosburgh
2011-10-31 22:41           ` Ben Hutchings
2011-11-01  3:20       ` Weiping Pan
2011-11-01 21:53         ` 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=1320094108.2735.15.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=andy@greyhouse.net \
    --cc=fubar@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wpan@redhat.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).