Red Hat Bugzilla – Bug 425902
kernel panic when removing bonding module
Last modified: 2009-02-10 06:45:47 EST
Description of problem: The kernel panics when removing the bonding driver by doing: `rmmod bonding' Version-Release number of selected component (if applicable): 2.6.18-8.el5 How reproducible: Occurs once in 3 attempts to unload/unconfigure bonding Steps to Reproduce: 1.Configure channel bonding using two interfaces. 2.ifdown <slave_interface1> 3.ifdown <slave_interface2> 4.ifdown <bond_interface) 5.rmmond bonding Actual results: Kernel Panic Expected results: bonding module should unload gracefully. bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details. NMI Watchdog detected LOCKUP on CPU 0 CPU 0 Modules linked in: bonding xt_state ip_conntrack nfnetlink iptable_filter ip_tables ip6table_filter ip6_tables hidp nfs lockd fscache nfs_acl sunrpc rfcomm l2cap bluetooth ipt_REJECT xt_tcpudp x_tables ipv6 dm_mirror dm_mod parport_pc lp parport sg shpchp i2c_nforce2 i2c_core pcspkr e1000 tg3 serio_raw ide_cd k8_edac cdrom edac_mc aacraid mptscsih mptbase cciss ata_piix sata_nv libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 8017, comm: iwconfig Not tainted 2.6.18-8.el5 #1 RIP: 0010:[<ffffffff80062724>] [<ffffffff80062724>] .text.lock.spinlock+0x1a/0x30 RSP: 0018:ffff81006ceb9d10 EFLAGS: 00000086 RAX: 0000000000000000 RBX: 0000000000008b01 RCX: 000000000000000c RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff88307f44 RBP: ffffffff88307f40 R08: 00007fff15697ab5 R09: 0000000000000003 R10: 00007fff15698ed1 R11: 0000000000000246 R12: 00000000ffffffed R13: ffff810071bfa000 R14: ffff81006ceb9e48 R15: 0000000000000000 FS: 00002aaaaaac7d50(0000) GS:ffffffff8038a000(0000) knlGS:00000000f7fe16c0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000037670c5fd0 CR3: 000000006cd67000 CR4: 00000000000006e0 Process adinfo ffff81006ceb8000, task ffff81006ce30820) Stack: ffffffff800620b4 0000000000000001 0000000000000001 8000000070ce8067 ffff81000000fc10 ffff81006ceb9e48 0000000000008b01 ffff81006ceb9e48 ffffffff882ef86f ffff810002bfc798 ffffffff80013040 ffff81006ceb9ed9 Call Trace: [<ffffffff800620b4>] __down_write_nested+0x12/0x92 [<ffffffff882ef86f>] :bonding:bond_do_ioctl+0x206/0x3a3 [<ffffffff80013040>] filemap_nopage+0x188/0x322 [<ffffffff80211d49>] wireless_process_ioctl+0x30f/0x349 [<ffffffff800lt+0x4e1/0xdf2 [<ffffffff802088d0>] dev_ioctl+0x422/0x465 [<ffffffff80021b6e>] __up_read+0x19/0x7f [<ffffffff801ffd09>] sock_ioctl+0x1d4/0x1e5 [<ffffffff8003fc3f>] do_ioctl+0x21/0x6b [<ffffffff8002fa45>] vfs_ioctl+0x248/0x261 [<ffffffff8004a24b>] sys_ioctl+0x59/0x78 [<ffffffff8005b2c1>] tracesys+0xd1/0xdc Code: 83 3f 00 7e f9 e9 f8 fe ff ff f3 90 83 3b 00 7e f9 e9 ff fe Kernel panic - not syncing: nmi watchdog BUG: warning at kernel/panic.c:137/panic() (Not tainted) Call Trace: <8b476>] panic+0x1e3/0x1f4 [<ffffffff80069261>] _show_stack+0xdb/0xea [<ffffffff80069354>] show_registers+0xe4/0x100 [<ffffffff8006300b>] die_nmi+0x66/0xa3 [<ffffffff8006368d>] nmi_watchdog_tick+0x105/0x1a6 [<ffffffff80063374>] default_do_nmi+0x86/0x214 [<ffffffff80063771>] do_nmi+0x43/0x61 [<ffffffff80062c2f>] nmi+0x7f/0x88 [<ffffffff80062724>] .text.lock.spinlock+0x1a/0x30 <<EOE>> [<ffffffff800620b4>] __down_write_nested+0x12/0x92 [<ffffffff882ef86f>] :bonding:bond_do_ioctl+0x206/0x3a3filemap_nopage+0x188/0x322 [<ffffffff80211d49>] wireless_process_ioctl+0x30f/0x349 [<ffffffff80008ac9>] __handle_mm_fault+0x4e1/0xdf2 [<ffffffff802088d0>] dev_ioctl+0x422/0x465 [<ffffffff80021b6e>] __up_read+0x19/0x7f [<ffffffff801ffd09>] sock_ioctl+0x1d4/0x1e5 [<ffffffff8003fc3f>] do_ioctl+0x21/0x6b [<ffffffff8002fa45>] vfs_ioctl+0x248/0x261 [<ffffffff8004a24b>] sys_ioctl+0x59/0x78 [<ffffffff8005b2c1>] tracesys+0xd1/0xdc Additional info:
Have you been able to reproduce this with any of the later kernels? I haven't seen any reports of this on any recent version (5.2 or 5.3-beta) of RHEL5.
I'm not able to reproduce this issue. RHEL 5.2 and RHEL 5.3 are not affected by this bug. The kernel version 2.6.18-8 is pretty old. I'm going to close this issue, if you are able to reproduce it on current RHEL-5 release (5.3) please re-open this bug again.