Bug 251902

I test 2.6.22 successfully. Here is the extracted fix:

http://www.mail-archive.com/netdev@vger.kernel.org/msg40353.html

Interesting.  We will include this fix in an upcoming update.  Feel free to test
any of the kernels here:

http://people.redhat.com/agospoda/#rhel5

for a preview of what will be included in our upcoming update.  The patch
mentioned in comment #1 is not included, but many other updates are.

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.

Trunking is a very helpful feature and easy to apply. When you will add a
iscsi-target to the new release, I think it is more than necessary. We use
currently a self-compiled kernel since months with 802.3ad support enabled.

My test kernels have been updated to include a patch for this bugzilla.

http://people.redhat.com/agospoda/#rhel5

Please test them and report back your results.

I just verified the new kernel, 802.3ad (link aggregation) works now. Verified 
with 3com gbit switch.

Great\!  Thanks for the feedback\!

My test kernels have been updated to include a patch for this bugzilla.

http://people.redhat.com/agospoda/#rhel5

Please test them and report back your results.

Hmmh, the last version works, I see no need to test it again. Perhaps anyone 
other will test it?

I'm glad to hear the last set of kernels worked.  I added a few more patches to this set to correct a few sysfs problems as well as problems that occurred when bringing the interface down.  If you can manage putting it on one of your systems to make sure these are no worse than the last ones I would appreciate it.

in 2.6.18-62.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

We just tested kernel-2.6.18-62.el5.i686.rpm. We confirm that it works with 
802.3ad. You can close the case.

*** Bug 241719 has been marked as a duplicate of this bug. ***

*** Bug 435249 has been marked as a duplicate of this bug. ***

Is this fix now accepted for the next kernel release?

Regards,

Dirk Nehring

yes it will be in the next update

With respect to comment #18 , i tested bonding on RHEL 5.2 beta kernel 
version: 2.6.18-85.el5 and bonding driver version: 3.2.4. Call traces are not 
seen in dmesg when bonding is started in balance-alb mode.

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/RHBA-2008-0314.html

Any chance of getting this fix in the xen kernels? Below is the backtrace from  2.6.18-128.el5xen

Feb  5 13:08:21 pearlygates kernel: Pid: 3696, comm: ip Not tainted 2.6.18-128.el5xen #1
Feb  5 13:08:21 pearlygates kernel: RIP: e030:[<ffffffff80261157>]  [<ffffffff80261157>] __write_lock_failed+0xf/0x20
Feb  5 13:08:21 pearlygates kernel: RSP: e02b:ffff8801d30c9d70  EFLAGS: 00000206
Feb  5 13:08:21 pearlygates kernel: RAX: ffff8801d30c9fd8 RBX: ffff8801d6bc8530 RCX: 0000000000000000
Feb  5 13:08:21 pearlygates kernel: RDX: 0000000000000180 RSI: 000000000000004c RDI: ffff8801d6bc8530
Feb  5 13:08:21 pearlygates kernel: RBP: 0000000000000000 R08: ffff8801def49ac0 R09: ffff8801dbed8600
Feb  5 13:08:21 pearlygates kernel: R10: ffff8801dbed9c80 R11: ffffffff881dd594 R12: 0000000000000000
Feb  5 13:08:21 pearlygates kernel: R13: ffff8801d6bc81a8 R14: 0000000000000002 R15: ffff8801d6bc8000
Feb  5 13:08:21 pearlygates kernel: FS:  00002b05ac9057f0(0000) GS:ffffffff805ba300(0000) knlGS:0000000000000000
Feb  5 13:08:21 pearlygates kernel: CS:  e033 DS: 0000 ES: 0000
Feb  5 13:08:21 pearlygates kernel: 
Feb  5 13:08:21 pearlygates kernel: Call Trace:
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff80263b01>] _write_lock_bh+0x1a/0x1c
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8842f972>] :bonding:bond_alb_set_mac_address+0x23a/0x254
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8040fd76>] dev_set_mac_address+0x38/0x58
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff804119de>] dev_ioctl+0x386/0x465
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff80316453>] inode_has_perm+0x56/0x63
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8040897b>] sock_ioctl+0x1d4/0x1e5
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff802437ba>] do_ioctl+0x21/0x6b
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff80231010>] vfs_ioctl+0x248/0x261
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8024ddde>] sys_ioctl+0x59/0x78
Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8025f2f9>] tracesys+0xab/0xb6

(In reply to comment #25)
> Any chance of getting this fix in the xen kernels? Below is the backtrace from 
> 2.6.18-128.el5xen
> 
> Feb  5 13:08:21 pearlygates kernel: Pid: 3696, comm: ip Not tainted
> 2.6.18-128.el5xen #1
> Feb  5 13:08:21 pearlygates kernel: RIP: e030:[<ffffffff80261157>] 
> [<ffffffff80261157>] __write_lock_failed+0xf/0x20
> Feb  5 13:08:21 pearlygates kernel: RSP: e02b:ffff8801d30c9d70  EFLAGS:
> 00000206
> Feb  5 13:08:21 pearlygates kernel: RAX: ffff8801d30c9fd8 RBX: ffff8801d6bc8530
> RCX: 0000000000000000
> Feb  5 13:08:21 pearlygates kernel: RDX: 0000000000000180 RSI: 000000000000004c
> RDI: ffff8801d6bc8530
> Feb  5 13:08:21 pearlygates kernel: RBP: 0000000000000000 R08: ffff8801def49ac0
> R09: ffff8801dbed8600
> Feb  5 13:08:21 pearlygates kernel: R10: ffff8801dbed9c80 R11: ffffffff881dd594
> R12: 0000000000000000
> Feb  5 13:08:21 pearlygates kernel: R13: ffff8801d6bc81a8 R14: 0000000000000002
> R15: ffff8801d6bc8000
> Feb  5 13:08:21 pearlygates kernel: FS:  00002b05ac9057f0(0000)
> GS:ffffffff805ba300(0000) knlGS:0000000000000000
> Feb  5 13:08:21 pearlygates kernel: CS:  e033 DS: 0000 ES: 0000
> Feb  5 13:08:21 pearlygates kernel: 
> Feb  5 13:08:21 pearlygates kernel: Call Trace:
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff80263b01>]
> _write_lock_bh+0x1a/0x1c
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8842f972>]
> :bonding:bond_alb_set_mac_address+0x23a/0x254
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8040fd76>]
> dev_set_mac_address+0x38/0x58
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff804119de>] dev_ioctl+0x386/0x465
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff80316453>]
> inode_has_perm+0x56/0x63
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8040897b>]
> sock_ioctl+0x1d4/0x1e5
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff802437ba>] do_ioctl+0x21/0x6b
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff80231010>] vfs_ioctl+0x248/0x261
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8024ddde>] sys_ioctl+0x59/0x78
> Feb  5 13:08:21 pearlygates kernel:  [<ffffffff8025f2f9>] tracesys+0xab/0xb6


This backtrace appears to be related to a completely different mode of bonding (mode 5 or 6 rather than mode 4) since there is a reference to bond_alb_set_mac_address in the backtrace.

If you are experiencing problems with bonding and RHEL5.3, please go through the normal support channels or open a new bugzilla, provide the needed reproduction information and assign it to agospoda.

I will be happy to take a look at it, but it's quite difficult for me to understand the situation with only this backtrace and no other information about what caused this panic to occur.

Thanks!