#25 Looping debugs
I wouldn't bother, but nobody else seems to know.
Any I dea what is busted here? Bonding seems to work,
but my messages file fills up with repeated debug
statements that only occur when I activate bonding.
I assume that these debugs are either coming from
bonding or sk98lin. Other than the debug while bonding,
everything works.
Fedora Core 4 (2.6.11-1.1369_FC4-smp-i686)
Marvell/Syskonnect Yukon NIC (sk98lin) 8.28 fr Marvell
and an Intel card (e1000)
hostname gateway.
Oct 18 14:19:46 gateway kernel: Debug: sleeping
function called from invalid context at
arch/i386/lib/usercopy.c:628
Oct 18 14:19:46 gateway kernel: in_atomic():1,
irqs_disabled():0
Oct 18 14:19:46 gateway kernel: [<c01d6d94>]
copy_from_user+0x18/0x84
Oct 18 14:19:46 gateway kernel: [<f8b79afb>]
SkGeIoctl+0x2e/0x2e0 [sk98lin]
Oct 18 14:19:46 gateway kernel: [<c011b20f>]
recalc_task_prio+0xc1/0x150
Oct 18 14:19:46 gateway kernel: [<f8b79acd>]
SkGeIoctl+0x0/0x2e0 [sk98lin]
Oct 18 14:19:46 gateway kernel: [<f88a9748>]
bond_update_speed_duplex+0xc7/0xdb [bonding]
Oct 18 14:19:46 gateway kernel: [<c011b679>]
try_to_wake_up+0x6e/0x2b1
Oct 18 14:19:46 gateway kernel: [<c011b32a>]
activate_task+0x8c/0x9b
Oct 18 14:19:46 gateway kernel: [<f88ab1d5>]
bond_mii_monitor+0x153/0x4be [bonding]
Oct 18 14:19:46 gateway kernel: [<c011b679>]
try_to_wake_up+0x6e/0x2b1
Oct 18 14:19:46 gateway kernel: [<f88ab082>]
bond_mii_monitor+0x0/0x4be [bonding]
Oct 18 14:19:46 gateway kernel: [<c012a28d>]
run_timer_softirq+0xe5/0x1b9
Oct 18 14:19:46 gateway kernel: [<c0131b31>]
__rcu_process_callbacks+0x4b/0xaa
Oct 18 14:19:46 gateway kernel: [<c0126602>]
__do_softirq+0x72/0xdc
Oct 18 14:19:46 gateway kernel: [<c0106753>]
do_softirq+0x4b/0x4f
Oct 18 14:19:46 gateway kernel:
=======================
Oct 18 14:19:46 gateway kernel: [<c0104ae8>]
apic_timer_interrupt+0x1c/0x24
Oct 18 14:19:47 gateway kernel: [<c010225d>]
mwait_idle+0x25/0x43
Oct 18 14:19:47 gateway kernel: [<c01020c4>]
cpu_idle+0x4e/0x63
Oct 18 14:19:47 gateway kernel: [<c03cb8bf>]
start_kernel+0x172/0x1c9
Oct 18 14:19:48 gateway kernel: [<c03cb31e>]
unknown_bootoption+0x0/0x1cd
Oct 18 14:19:48 gateway kernel: Debug: sleeping
function called from invalid context at
arch/i386/lib/usercopy.c:628
Oct 18 14:19:48 gateway kernel: in_atomic():1,
irqs_disabled():0
Oct 18 14:19:48 gateway kernel: [<c01d6d94>]
copy_from_user+0x18/0x84
Oct 18 14:19:48 gateway kernel: [<f8b79afb>]
SkGeIoctl+0x2e/0x2e0 [sk98lin]
Oct 18 14:19:48 gateway kernel: [<f8b79acd>]
SkGeIoctl+0x0/0x2e0 [sk98lin]
Oct 18 14:19:48 gateway kernel: [<f88a9748>]
bond_update_speed_duplex+0xc7/0xdb [bonding]
Oct 18 14:19:48 gateway kernel: [<c011b32a>]
activate_task+0x8c/0x9b
Oct 18 14:19:48 gateway kernel: [<f88ab1d5>]
bond_mii_monitor+0x153/0x4be [bonding]
Oct 18 14:19:48 gateway kernel: [<c0129aeb>]
__mod_timer+0x12a/0x14a
Oct 18 14:19:48 gateway kernel: [<f88ab082>]
bond_mii_monitor+0x0/0x4be [bonding]
Oct 18 14:19:48 gateway kernel: [<c012a28d>]
run_timer_softirq+0xe5/0x1b9
Oct 18 14:19:48 gateway kernel: [<c0131b31>]
__rcu_process_callbacks+0x4b/0xaa
Oct 18 14:19:48 gateway kernel: [<c0126602>]
__do_softirq+0x72/0xdc
Oct 18 14:19:48 gateway kernel: [<c0106753>]
do_softirq+0x4b/0x4f
Oct 18 14:19:48 gateway kernel:
=======================
Oct 18 14:19:48 gateway kernel: [<c0104ae8>]
apic_timer_interrupt+0x1c/0x24
Oct 18 14:19:48 gateway kernel: [<c010225d>]
mwait_idle+0x25/0x43
Oct 18 14:19:48 gateway kernel: [<c01020c4>]
cpu_idle+0x4e/0x63
Oct 18 14:19:48 gateway kernel: [<c03cb8bf>]
start_kernel+0x172/0x1c9
Oct 18 14:19:48 gateway kernel: [<c03cb31e>]
unknown_bootoption+0x0/0x1cd
William T. Musil
LabVantage Solutions
wmusil@labvantage.com
Logged In: YES
user_id=579170
Turn off CONFIG_DEBUG_SPINLOCK_SLEEP in your kernel
configuration. There's a known problem in bonding (that's
been there pretty much since the very beginning) with
potential sleeps with locks held. In the past, the warnings
were bogus, as no device drivers actually slept in the
protected section (ioctl, set MAC), but some recent USB
ethernet adapters can sleep in the affected areas. Other
instances of the warning are due to operations that used to
be safe, but no longer are.
This isn't a simple problem to fix (it requires, among other
things, an entirely new locking model for the bonding
driver); I've been working on a solution for this for a very
long time. A preliminary patch set was posted to
bonding-devel in early September, I expect to get back to
working on it in a couple of weeks.