Bug 425902

Summary:	kernel panic when removing bonding module
Product:	Red Hat Enterprise Linux 5	Reporter:	Sriharsha Setty <sriharsha.setty>
Component:	kernel	Assignee:	Ivan Vecera <ivecera>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Martin Jenner <mjenner>
Severity:	high	Docs Contact:
Priority:	low
Version:	5.0	CC:	agospoda, benlu, peterm
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-02-10 11:45:47 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sriharsha Setty 2007-12-17 06:53:13 UTC

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:

Comment 1 Andy Gospodarek 2008-12-18 14:50:20 UTC

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.

Comment 2 Ivan Vecera 2009-02-10 11:45:47 UTC

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.