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): kernel-2.4.21-20.0.1.EL How reproducible: Always 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 eth1 3. ping another machine on the network to verify bond0 is working properly 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.
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.
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 :)
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] 8139too-update-rhel3.patch Interested in testing my patch against the latest RHEL3 kernel you can find? :-)
Created attachment 108475 [details] 8139too-update-rhel3.patch 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. http://rhn.redhat.com/errata/RHSA-2005-294.html