From: Emmanuel Deloget <emmanuel.deloget@efixo.com>
To: linux-rt-users@vger.kernel.org
Subject: How do I get rid of these "BUG: sleeping function called from ... kernel/rtmutex.c:707"?
Date: Fri, 20 May 2011 16:30:21 +0200 [thread overview]
Message-ID: <4DD67AFD.2080709@efixo.com> (raw)
Hello,
I hope this message will find its way to the linux-rt mailing list. I
subscribed but for reasons that are unknown to me I cannot receive
anything from this list (I contacted the owner to sort out the problem).
As I side note, for this very reason, I'll appreciate if you CC me
whenever you answer to this mail, otherwise I might miss it. Thanks in
advance.
I am using 2.6.33.7-rt30 (platform in arm/mach-ixp4xx ; distro is
OpenWRT with 2.6.33.7 re-imported (it has been removed from OpenWRT)).
When I up a network interface with ifconfig, I systematically get the
following error message in dmesg :
[ 64.205417] BUG: sleeping function called from invalid context at
kernel/rtmutex.c:707
[ 64.205453] pcnt: 0 0 in_atomic(): 0, irqs_disabled(): 128, pid:
1047, name: ifconfig
[ 64.205472] Backtrace:
[ 64.205521] [<c002b6c0>] (dump_backtrace+0x0/0x110) from [<c02dbe20>]
(dump_stack+0x18/0x1c)
[ 64.205545] r7:c780daa0 r6:c780daa0 r5:00000020 r4:00000000
[ 64.205591] [<c02dbe08>] (dump_stack+0x0/0x1c) from [<c0032f7c>]
(__might_sleep+0xf8/0x118)
[ 64.205629] [<c0032e84>] (__might_sleep+0x0/0x118) from [<c02de468>]
(rt_spin_lock+0x34/0x64)
[ 64.205650] r4:c03a18d8
[ 64.205689] [<c02de434>] (rt_spin_lock+0x0/0x64) from [<c0095908>]
(kmem_cache_alloc+0x40/0x15c)
[ 64.205711] r4:c5bd1df0
[ 64.205744] [<c00958c8>] (kmem_cache_alloc+0x0/0x15c) from
[<c01c749c>] (__alloc_skb+0x30/0x104)
[ 64.205778] [<c01c746c>] (__alloc_skb+0x0/0x104) from [<c01c813c>]
(dev_alloc_skb+0x20/0x44)
[ 64.205800] r8:a0000013 r7:c42f4340 r6:c42f4000 r5:c5ae1540 r4:c5bd1df0
[ 64.205866] [<c01c811c>] (dev_alloc_skb+0x0/0x44) from [<bf0d9a88>]
(do_dev_stop+0x11c/0x2e4 [ixp400_eth])
[ 64.205909] [<bf0d9a60>] (do_dev_stop+0xf4/0x2e4 [ixp400_eth]) from
[<bf0d9ba8>] (do_dev_stop+0x23c/0x2e4 [ixp400_eth])
[ 64.205952] [<bf0d9b30>] (do_dev_stop+0x1c4/0x2e4 [ixp400_eth]) from
[<bf0da230>] (do_dev_open+0x24/0xa4 [ixp400_eth])
[ 64.205977] r6:00001043 r5:bf0db448 r4:c42f4000
[ 64.206020] [<bf0da20c>] (do_dev_open+0x0/0xa4 [ixp400_eth]) from
[<c01d0e0c>] (dev_open+0xcc/0x134)
[ 64.206042] r5:bf0db1d0 r4:c42f4000
[ 64.206086] [<c01d0d40>] (dev_open+0x0/0x134) from [<c01d0204>]
(dev_change_flags+0xb0/0x190)
[ 64.206107] r5:00000041 r4:c42f4000
[ 64.206154] [<c01d0154>] (dev_change_flags+0x0/0x190) from
[<c0256444>] (devinet_ioctl+0x2f0/0x6b0)
[ 64.206177] r7:c5bd1e80 r6:c59e0600 r5:c788c4e0 r4:00000000
[ 64.206226] [<c0256154>] (devinet_ioctl+0x0/0x6b0) from [<c02579a8>]
(inet_ioctl+0xd0/0x10c)
[ 64.206270] [<c02578d8>] (inet_ioctl+0x0/0x10c) from [<c01be7c8>]
(sock_ioctl+0x1fc/0x25c)
[ 64.206291] r4:c4ab3ec0
[ 64.206318] [<c01be5cc>] (sock_ioctl+0x0/0x25c) from [<c00a57bc>]
(vfs_ioctl+0x34/0xb4)
[ 64.206338] r6:be8cdd60 r5:00008914 r4:c4ab3ec0
[ 64.206375] [<c00a5788>] (vfs_ioctl+0x0/0xb4) from [<c00a5e98>]
(do_vfs_ioctl+0x548/0x5b4)
[ 64.206396] r6:00000003 r5:c4ab3ec0 r4:c6014afc
[ 64.206433] [<c00a5950>] (do_vfs_ioctl+0x0/0x5b4) from [<c00a5f44>]
(sys_ioctl+0x40/0x60)
[ 64.206477] [<c00a5f04>] (sys_ioctl+0x0/0x60) from [<c0027f20>]
(ret_fast_syscall+0x0/0x28)
[ 64.206499] r7:00000036 r6:000001c3 r5:00000004 r4:000508e7
It seems that this message does not prevent ifconfig to work correctly.
The code at kernel/rtmutex.c:707 says:
/* 701 */ static inline void
/* 702 */ rt_spin_lock_fastlock(struct rt_mutex *lock,
/* 703 */ void (*slowfn)(struct rt_mutex *lock))
/* 704 */ {
/* 705 */ /* Temporary HACK! */
/* 706 */ if (likely(!current->in_printk))
/* 707 */ might_sleep();
/* 708 */ else if (in_atomic() || irqs_disabled())
/* 709 */ /* don't grab locks for printk in atomic */
/* 710 */ return;
/* 711 */
/* 712 */ if (likely(rt_mutex_cmpxchg(lock, NULL, current)))
/* 713 */ rt_mutex_deadlock_account_lock(lock, current);
/* 714 */ else
/* 715 */ slowfn(lock);
/* 716 */ }
I did my homework, and found that a similar message have been seen here
and there ([1], [2]). But the solution provided in [1] (avoid the
dynamic allocation, reserve an automatic (as in C 'auto' keyword)
buffer) is not helping much in my case : I'm not going to ask to
dev_alloc_skb() to not perform static allocations, while [2] do not
provide any kind of solution.
Now, I want to get rid of these messages in the correct way. I can
implement a bizzare hack to remove this issue, but I have no guarantee
that this hack will be sensible. What I'm searching for is a correct (in
the linux kernel way) to do this.
Can anybody help?
Thanks in advance,
-- Emmanuel Deloget
[1] http://www.spinics.net/lists/linux-rt-users/msg06048.html
[2] http://comments.gmane.org/gmane.linux.kernel.firewire.devel/14648
next reply other threads:[~2011-05-20 14:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 14:30 Emmanuel Deloget [this message]
2011-05-24 13:05 ` How do I get rid of these "BUG: sleeping function called from ... kernel/rtmutex.c:707"? Emmanuel Deloget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DD67AFD.2080709@efixo.com \
--to=emmanuel.deloget@efixo.com \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.