Bug 495318

Summary: Bonding driver updelay parameter actual behavior doesn't match documented behavior
Product: Red Hat Enterprise Linux 5 Reporter: Sean E. Millichamp <sean>
Component: kernelAssignee: Jiri Pirko <jpirko>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: low Docs Contact:
Priority: low    
Version: 5.3CC: dzickus, rkhan, rousseau, syeghiay
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 498012 (view as bug list) Environment:
Last Closed: 2009-09-02 08:59:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 498012    
Attachments:
Description Flags
Removes the updelay for the first slave to become active
none
Correct version of the patch none

Description Sean E. Millichamp 2009-04-11 19:10:31 UTC
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.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 14:49:49 UTC
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 11:54:22 UTC
patch applied to net-next-2.6:

http://patchwork.ozlabs.org/patch/26411/

Comment 6 Don Zickus 2009-05-06 17:17:44 UTC
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 08:59:19 UTC
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