Bug 142683 - bonding with mii monitoring does not work with realtek card
Summary: bonding with mii monitoring does not work with realtek card
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-12 17:36 UTC by Bert Barbe
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-18 13:28:50 UTC
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 22:57 UTC, John W. Linville
no flags Details | Diff
8139too-update-rhel3.patch (34.98 KB, patch)
2004-12-13 22:59 UTC, John W. Linville
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:294 normal SHIPPED_LIVE Moderate: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 5 2005-05-18 04:00:00 UTC

Description Bert Barbe 2004-12-12 17:36:12 UTC
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 20:24:51 UTC
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 20:34:05 UTC
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 21:07:39 UTC
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 21:58:34 UTC
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 22:57:47 UTC
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 22:59:25 UTC
Created attachment 108475 [details]

False start...this one includes a necessary header file...

Comment 7 John W. Linville 2004-12-13 23:01:20 UTC
I promise I'll correct the 8139too_compat.h comments before it is
added to RHEL3... :-)

Comment 8 Bert Barbe 2004-12-13 23:15:26 UTC
Sure i'll give it a try

Comment 9 Bert Barbe 2004-12-14 14:54:25 UTC
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 15:01:52 UTC
Probably best to log each one separately...

Thanks for the feedback!

Comment 12 Bert Barbe 2005-01-05 16:01:36 UTC
In which kernel will this fix be visible ? Thanks.

Comment 13 John W. Linville 2005-01-05 17:34:26 UTC
My guess is that it will be in U5...

Comment 14 Ernie Petrides 2005-01-11 23:45:09 UTC
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 13:28:50 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 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.