Description of problem: A test that repeatedly loads bonding driver, enslaves a be2net interface and unloads the bonding driver will result in a system freeze. How reproducible: One out of 10 attempts to load and unload bonding driver with a be2net interface as slave. Steps to Reproduce: Run the following commands in a loop : rmmod bonding modprobe bonding miimon=100 echo 4 > /sys/class/net/bond0/bonding/mode ifconfig bond0 <IP-ADDR>netmask 255.0.0.0 ifenslave bond0 eth2 eth3 ping -q -c 10 -w 10 <IP-ADDR-OF-PEER> Actual results: System will lock up in couple of minutes. Expected results: The test must continue without any problem.
Subbu, do you have any additional information for this problem? Backtraces, patches, etc? I would like to help with this, but I will not have the ability to use my card for a day or two so I cannot test this.
The problem is understood and fixed. Fix has been tested and pushed upstream. I will shortly be attaching the patch. Subbu
(In reply to comment #3) > The problem is understood and fixed. Fix has been tested and pushed upstream. > I will shortly be attaching the patch. > > Subbu OK, great! I didn't see anything on netdev (at least based on this subject), so I was just trying to figure out what needed to be done. Thanks.
Created attachment 349974 [details] patch to fix deadlock seen when rmmoding bonding driver Current driver uses the MCC mailbox to post all f/w cmds. mbox posting is protected via a spin_lock(cmd_lock). This can result in a lockup for multicast_set and promiscous_config cmds that may be called in the BH context. spin_lock_bh() must not be used to prevent disabling of BHs while polling on the mbox. This patch modifies the driver to post these cmds on the MCC queue (rather than poll on the mbox) and the completions rcvd asynchronously. Async link status notifications are also rcvd as a part of MCC infrastructure. These changes were submitted to netdev on 6/18 as a four patch series. Subbu
Subbu - *please* make sure I'm included in the CC-list if you create any new bugzillas, thanks.
Sorry about that Andrius. Will do that in future. I have been using the the "depends on" field to indicate the patch order. Is that the appropriate way to indicate the patch order. Thanks. Subbu
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in kernel-2.6.18-157.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.
Verified on 2.6.18-157. Subbu
~~ Attention Partners - RHEL 5.4 Snapshot 5 Released! ~~ RHEL 5.4 Snapshot 5 is the FINAL snapshot to be release before RC. It has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular issue. Please test and report back your results here, at your earliest convenience. If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. If it is urgent, escalate the issue to your partner manager as soon as possible. There is /very/ little time left to get additional code into 5.4 before GA. Partners, after you have verified, do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.
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