#15 scheduling while atomic

open
nobody
None
5
2008-05-06
2008-05-06
Anonymous
No

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.

Discussion

  • dmesg output

     
    Attachments
  • 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.

     
  • Jay Vosburgh
    Jay Vosburgh
    2008-05-14

    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>