#25 Looping debugs

open
nobody
None
5
2005-10-26
2005-10-26
Anonymous
No

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

Discussion

  • Jay Vosburgh
    Jay Vosburgh
    2005-10-28

    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.