This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 142683 - bonding with mii monitoring does not work with realtek card
bonding with mii monitoring does not work with realtek card
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-12-12 12:36 EST by Bert Barbe
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-18 09:28:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
8139too-update-rhel3.patch (34.69 KB, patch)
2004-12-13 17:57 EST, John W. Linville
no flags Details | Diff
8139too-update-rhel3.patch (34.98 KB, patch)
2004-12-13 17:59 EST, John W. Linville
no flags Details | Diff

  None (edit)
Description Bert Barbe 2004-12-12 12:36:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041007 Debian/1.7.3-5

Description of problem:
Loading the bonding module with options "mode=1 miimon=100".
Adding eth0 and eth1 to the bonding device (both realtek cards,
driver module 8139too). When pulling out the cable from the
active card, mii monitoring should detect that the link status is down
on the active card and switch to the backup card.
In the 2.4.21-20.0.1.EL this doesn't work. 
Compared with standard kernels 2.4.22 and 2.4.23. In
2.4.22 it didnt work either, but in 2.4.23 it did work.
The bonding module source is identical in  2.4.21-20.0.1.EL
and 2.4.23, so it appears to be a 813too driver problem.
When copying the 8139too source
from the 2.4.23 kernel to the 2.4.21-20.0.1 kernel source
(with some minor changes to re-integrate it),
the miimon feature does indeed work.

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

How reproducible:

Steps to Reproduce:
1. load bonding modules as bond0 with options "mode=1 miimon=100"
   configure the ip for bond0 and add routes if neccessary

2. add eth0 and eth1 to bond0 : ifenslave bond0 eth0 ; ifenslave bond0

3. ping another machine on the network to verify bond0 is working
4. pull out the cable from the active card (eth0)

Actual Results:  In 2.4.21-20.0.1.EL the bonding device doesnt switch
the the
backup card (eth1). No machines can be reached on the network.

Expected Results:  eth1 (the backup card) should have become the
active card for
the bonding device after detecting the link down on eth0.

Additional info:

I'm using the realtek cards on my test machine, but the error
has also been reported with other systems (with different
network cards) that would like to use this feature in production. 
I'm compiling a list, please advice if I should add
them to this bug or add a seperate bug for each different driver.
Comment 1 Ernie Petrides 2004-12-13 15:24:51 EST
Hi, Bert.  It sounds to me like this problem has *already* been fixed
in U4, which is scheduled for release one week from today.  Is this
correct?  If so, what is the purpose of this bug report?  Thanks.
Comment 2 Bert Barbe 2004-12-13 15:34:05 EST
Hi  Ernie,

Why does it sound to you like the problem has already
been fixed in U4 ? Please be specific. Is it a 2.4.23 or 
higher kernel ? Is this a duplicate bug - if so I didn't
find the preceding bug. I tested with the latest available
kernel from rhn. If the upcoming U4 will fix it, so much the better :) 
Comment 3 Bert Barbe 2004-12-13 16:07:39 EST
BTW, as you mentioned an upcoming U4, i had a look and found
the 2.4.21-25.EL kernel , tested it and the problem persists there.
I cant find any more recent RHEL3 kernel to test. Hence the bug report.
Comment 4 Ernie Petrides 2004-12-13 16:58:34 EST
Hi, Bert.  My mistake (confusing 2.4.23 and 2.4.21-23.EL).  Thanks for
reporting the bug.  It is appropriately assigned to John Linville.
Comment 5 John W. Linville 2004-12-13 17:57:47 EST
Created attachment 108474 [details]

Interested in testing my patch against the latest RHEL3 kernel you can find?
Comment 6 John W. Linville 2004-12-13 17:59:25 EST
Created attachment 108475 [details]

False start...this one includes a necessary header file...
Comment 7 John W. Linville 2004-12-13 18:01:20 EST
I promise I'll correct the 8139too_compat.h comments before it is
added to RHEL3... :-)
Comment 8 Bert Barbe 2004-12-13 18:15:26 EST
Sure i'll give it a try
Comment 9 Bert Barbe 2004-12-14 09:54:25 EST
Yeah that patch also works fine. 
There might be some other drivers for other cards that need
to be updated .. but I still have to verify the results with those.
If I verify the problem with other cards, should I log them here,
or open a new bug ? Thanks.
Comment 10 John W. Linville 2004-12-14 10:01:52 EST
Probably best to log each one separately...

Thanks for the feedback!
Comment 12 Bert Barbe 2005-01-05 11:01:36 EST
In which kernel will this fix be visible ? Thanks.
Comment 13 John W. Linville 2005-01-05 12:34:26 EST
My guess is that it will be in U5...
Comment 14 Ernie Petrides 2005-01-11 18:45:09 EST
A fix for this problem has just been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.7.EL).
Comment 15 Tim Powers 2005-05-18 09:28:50 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 the 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.

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