Bug 495318 - Bonding driver updelay parameter actual behavior doesn't match documented behavior
Bonding driver updelay parameter actual behavior doesn't match documented beh...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Jiri Pirko
Red Hat Kernel QE team
:
Depends On:
Blocks: 498012
  Show dependency treegraph
 
Reported: 2009-04-11 15:10 EDT by Sean E. Millichamp
Modified: 2015-05-04 21:16 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 498012 (view as bug list)
Environment:
Last Closed: 2009-09-02 04:59:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Removes the updelay for the first slave to become active (531 bytes, patch)
2009-04-11 15:10 EDT, Sean E. Millichamp
no flags Details | Diff
Correct version of the patch (531 bytes, patch)
2009-04-23 10:49 EDT, Sean E. Millichamp
no flags Details | Diff

  None (edit)
Description Sean E. Millichamp 2009-04-11 15:10:31 EDT
Created attachment 339193 [details]
Removes the updelay for the first slave to become active

Description of problem:

The Linux kernel documentation in the kernel-doc package at Documentation/networking/bonding.txt states:

"Note that when a bonding interface has no active links, the
driver will immediately reuse the first link that goes up, even if the
updelay parameter has been specified (the updelay is ignored in this
case).  If there are slave interfaces waiting for the updelay timeout
to expire, the interface that first went into that state will be
immediately reused."

Version-Release number of selected component (if applicable):

kernel-2.6.18-128.1.6.el5

How reproducible:

Always

Steps to Reproduce:
1. Configure an active-passive bond interface with updelay set to something appropriately large (30000 or 60000)
2. From a state where the bond device and both links are up, remove both links.
3. Reconnect one,
4. Wait for the updelay to time out before the bond device returns to an operational state.
  
Expected results:

When no slaves have active links I would expect the bond device to immediately become operational after the first link-up on any slave.

Additional info:

I have tested this patch and it seems to do the right thing.  I have only tested this in an active-passive bonding configuration.

I have also sent a patch to the bonding maintainer (fubar@us.ibm.com) listed in MAINTAINERS rebased against 2.6.29.1 earlier today (but have not heard back from him yet).
Comment 1 Sean E. Millichamp 2009-04-23 10:49:49 EDT
Created attachment 340946 [details]
Correct version of the patch

NOTE: The original patch was accidentally a reverse diff.  This should be a correct, forward, patch.  Thanks to my coworker who was reviewing the bug and patch and asked me why I was removing the or clause... oops.
Comment 2 Jiri Pirko 2009-04-27 07:54:22 EDT
patch applied to net-next-2.6:

http://patchwork.ozlabs.org/patch/26411/
Comment 6 Don Zickus 2009-05-06 13:17:44 EDT
in kernel-2.6.18-144.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 9 errata-xmlrpc 2009-09-02 04:59:19 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html

Note You need to log in before you can comment on or make changes to this bug.