#15 scheduling while atomic
During the system configuration, I modprobing bonding module then e1000 twice (done with a script) then dmesg show me:
[ 17.378040] BUG: scheduling while atomic: bond0/890/0x00000002
[ 17.378111] Pid: 890, comm: bond0 Not tainted 2.6.24.4 #11
[ 17.378180] [<c11adcf3>] schedule+0x583/0x680
[ 17.378303] [<c11ae488>] __mutex_lock_slowpath+0x58/0xa0
[ 17.378413] [<c11ae2da>] mutex_lock+0xa/0x10
[ 17.378519] [<f898627e>] bond_activebackup_arp_mon+0x7e/0x5c0 [bonding]
[ 17.378639] [<c11ad94b>] schedule+0x1db/0x680
[ 17.378746] [<f8986200>] bond_activebackup_arp_mon+0x0/0x5c0 [bonding]
[ 17.378862] [<c102c06b>] run_workqueue+0x7b/0x110
[ 17.378971] [<c102c9c0>] worker_thread+0x0/0xb0
[ 17.379084] [<c102ca39>] worker_thread+0x79/0xb0
[ 17.379190] [<c102fad0>] autoremove_wake_function+0x0/0x50
[ 17.379306] [<c102c9c0>] worker_thread+0x0/0xb0
[ 17.379411] [<c102f802>] kthread+0x42/0x70
[ 17.379517] [<c102f7c0>] kthread+0x0/0x70
[ 17.379622] [<c100372b>] kernel_thread_helper+0x7/0x1c
[ 17.379730] =======================
(the whole revelant kernels log are in th attached file)
What my script does:
modprobe bond mode=1
ifconfig bond0 192.168.0.100 netmask 255.255.255.0
echo 0 > /sys/class/net/bond0/bonding/miimon
echo +192.168.0.149 > /sys/class/net/bond0/bonding/arp_ip_target
echo +192.168.0.5 > /sys/class/net/bond0/bonding/arp_ip_target
echo 1000 > /sys/class/net/bond0/bonding/arp_interval
modprobe eth0
sleep 1
echo +eth0 > /sys/class/net/bond0/bonding/slaves
modprobe eth1
sleep 1
echo +eth1 > /sys/class/net/bond0/bonding/slaves
The kernel version is 2.6.24.4 (from kernel.org)
System busybox-1.9.1
libc version:
GNU C Library stable release version 2.7, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20070925 (Red Hat 4.1.2-32).
Compiled on a Linux >>2.6.20-1.3001.fc6xen<< system on 2007-10-18.
Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
RT using linux kernel aio
cat /proc/net/bonding/bond0 gives:
Ethernet Channel Bonding Driver: v3.2.3 (December 6, 2007)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 1000
ARP IP target/s (n.n.n.n form): 192.168.0.5, 192.168.0.149
Slave Interface: eth0
MII Status: up
Link Failure Count: 2
Permanent HW addr: 00:80:82:72:02:10
Slave Interface: eth1
MII Status: up
Link Failure Count: 1
Permanent HW addr: 00:80:82:72:02:11
Any more informations can be provided on demand.
dmesg output
Logged In: NO
The ethernet device used is a "Intel Corporation 82573L Gigabit Ethernet Controller". When using kernel 2.6.25.1, module "e1000" can't be used with this device, and using "e1000e" solve the problem.
Logged In: YES
user_id=579170
Originator: NO
This is fixed in the current mainline, and the latest stable kernel (2.6.25.3):
commit 21c9d8d73dd1a152c49b4e3176193a099849d4c9
Author: Jay Vosburgh <fubar@us.ibm.com>
Date: Tue Jan 29 18:07:47 2008 -0800
bonding: do not acquire rtnl in ARP monitor
The ARP monitor functions currently acquire RTNL when performing
failover operations, but do so incorrectly (out of order). This causes
various warnings from might_sleep.
The ARP monitor isn't supported for any of the bonding modes
that actually require RTNL, so it is safe to not hold RTNL when
failing over in the ARP monitor.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>