From: Tvrtko Ursulin <tvrtko@ursulin.net>
To: David Howells <dhowells@redhat.com>
Cc: linux-cachefs@redhat.com, linux-kernel@vger.kernel.org
Subject: fscache scheduling while atomic bugs under 3.4.10-rt18
Date: Sat, 08 Sep 2012 19:22:54 +0100 [thread overview]
Message-ID: <504B8CFE.5010005@ursulin.net> (raw)
Hi,
I get a lot of those and was wondering if it is a generic fscache issues
or in some way related to the RT patchset. Perhaps that the two do not
play well together?
Traces typically look like this:
BUG: scheduling while atomic: kworker/u:2/4151/0x00000002
Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib fuse
ip6table_filter ip6_tables ebtable_nat ebtables cachefiles
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack ipt_REJECT iptable_mangle xt_tcpudp iptable_filter
ip_tables x_tables bridge stp llc kvm_amd kvm autofs4 dm_crypt joydev
usbhid hid snd_ice1712 nfsd snd_ice17xx_ak4xxx bnep snd_ak4xxx_adda
snd_cs8427 snd_ac97_codec nfs bluetooth snd_pcm lockd fscache
auth_rpcgss snd_page_alloc nfs_acl ac97_bus binfmt_misc sunrpc snd_i2c
snd_mpu401_uart snd_seq_midi microcode snd_rawmidi snd_seq_midi_event
snd_seq snd_timer snd_seq_device snd psmouse soundcore ext4
firewire_ohci mbcache r8169 firewire_core jbd2 mii crc_itu_t pata_atiixp
fglrx(PO) i2c_piix4 it87 hwmon_vid raid10 raid456 async_pq async_xor xor
async_memcpy async_raid6_recov raid6_pq async_tx raid1 linear xfs raid0
ahci libahci
Pid: 4151, comm: kworker/u:2 Tainted: P O 3.4.10-rt18 #1
Call Trace:
[<ffffffff813d8b0f>] __schedule_bug+0x43/0x45
[<ffffffff813ddcda>] __schedule+0x64a/0x680
[<ffffffff813de149>] schedule+0x29/0x80
[<ffffffff813deda7>] rt_spin_lock_slowlock+0x14b/0x1e4
[<ffffffff813df271>] rt_spin_lock+0x21/0x30
[<ffffffff81045520>] __queue_work+0x180/0x330
[<ffffffff8105644a>] ? ttwu_do_activate.constprop.76+0x4a/0x60
[<ffffffff8104571d>] queue_work_on+0x1d/0x30
[<ffffffff8104577e>] queue_work+0x2e/0x50
[<ffffffff81055c9b>] ? migrate_enable+0xcb/0x1b0
[<ffffffffa047aca5>] fscache_enqueue_object+0x65/0xd0 [fscache]
[<ffffffffa047b2d2>] fscache_object_work_func+0x342/0xa20 [fscache]
[<ffffffff81055c9b>] ? migrate_enable+0xcb/0x1b0
[<ffffffffa047af90>] ? fscache_drop_object+0x170/0x170 [fscache]
[<ffffffff81045a87>] process_one_work+0x117/0x3a0
[<ffffffff81045d34>] process_scheduled_works+0x24/0x40
[<ffffffff81046781>] worker_thread+0x271/0x340
[<ffffffff81046510>] ? manage_workers.isra.30+0x230/0x230
[<ffffffff8104bbde>] kthread+0x8e/0xa0
[<ffffffff810546f9>] ? finish_task_switch+0x49/0xf0
[<ffffffff813e1034>] kernel_thread_helper+0x4/0x10
[<ffffffff8104bb50>] ? __init_kthread_worker+0x50/0x50
[<ffffffff813e1030>] ? gs_change+0xb/0xb
Thanks,
Tvrtko
reply other threads:[~2012-09-08 18:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=504B8CFE.5010005@ursulin.net \
--to=tvrtko@ursulin.net \
--cc=dhowells@redhat.com \
--cc=linux-cachefs@redhat.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome