Red Hat Bugzilla – Bug 142683
bonding with mii monitoring does not work with realtek card
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
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):
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
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.
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.
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.
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 :)
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.
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.
Created attachment 108474 [details]
Interested in testing my patch against the latest RHEL3 kernel you can find?
Created attachment 108475 [details]
False start...this one includes a necessary header file...
I promise I'll correct the 8139too_compat.h comments before it is
added to RHEL3... :-)
Sure i'll give it a try
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.
Probably best to log each one separately...
Thanks for the feedback!
In which kernel will this fix be visible ? Thanks.
My guess is that it will be in U5...
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).
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.