This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: BUG: [preempt-rt] scheduling while atomic: stapio
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Kiran <kiran at linux dot vnet dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com, sripathi at in dot ibm dot com, Darren Hart <dvhltc at us dot ibm dot com>
- Date: Wed, 20 May 2009 09:16:54 -0700
- Subject: Re: BUG: [preempt-rt] scheduling while atomic: stapio
- References: <1242812648.13247.12.camel@kiran-laptop>
On Wed, 2009-05-20 at 15:14 +0530, Kiran wrote:
> Hi,
>
> I am getting the following bug report in dmesg when I run pfaults.stp
> script in the systemtap.examples/memory. I am using systemtap-0.9.7 and
> kernel version is 2.6.29-rt4.
The first thing that comes to mind is that spinlocks are different in
(at least some) real-time kernels. They can give up and sleep after a
while. If you want spinlocks that are guaranteed not to sleep, you have
to use the raw_* versions of the spinlock functions. That's about the
extent of my (mis)information on the subject. I'm cc-ing an RT guy
(Darren) in case he can help.
Jim Keniston
>
> BUG: scheduling while atomic: stapio/0x00000001/26142, CPU#3
> Modules linked in: stap_246f93f30a500769142af9987624737a_5072 ipv6
> autofs4 i2c_dev i2c_core hidp rfcomm l2cap bluetooth sunrpc dm_mirror
> dm_region_hash dm_log dm_multipath scsi_dh dm_mod video output sbs
> sbshc battery ac parport_pc lp parport sg bnx2 serio_raw button shpchp
> k8temp hwmon pcspkr mptsas mptscsih scsi_transport_sas mptbase sd_mod
> scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded:
> stap_8455b451d15976a5e16919831aef7e51_3974]
> Pid: 26142, comm: stapio Not tainted 2.6.29.1-rt4 #1
> Call Trace:
> [<ffffffff81040341>] __schedule_bug+0x6f/0x8a
> [<ffffffff8136f748>] __schedule+0x9f/0x94a
> [<ffffffff81370433>] schedule+0x1d/0x46
> [<ffffffff81370597>] schedule_timeout+0x37/0x1a9
> [<ffffffff810415a9>] ? check_preempt_wakeup+0x138/0x16e
> [<ffffffff8136f3f2>] wait_for_common+0xcb/0x159
> [<ffffffff81043694>] ? default_wake_function+0x0/0x38
> [<ffffffff8136f5b9>] wait_for_completion+0x2b/0x41
> [<ffffffff8109cbc9>] __synchronize_sched+0x57/0x72
> [<ffffffff8105f335>] ? wakeme_after_rcu+0x0/0x36
> [<ffffffff81067016>] ? srcu_readers_active_idx+0x5e/0x89
> [<ffffffff810670b0>] synchronize_srcu+0x6f/0x96
> [<ffffffff8106787d>] srcu_notifier_chain_unregister+0x60/0x82
> [<ffffffff812a2dea>] cpufreq_unregister_notifier+0x35/0x5c
> [<ffffffffa02e0a1f>] _stp_kill_time+0xb6/0xbd [stap_246f93f30a500769142af9987624737a_5072]
> [<ffffffffa02e1749>] probe_1391+0x3c/0xa8 [stap_246f93f30a500769142af9987624737a_5072]
> [<ffffffffa02e2621>] enter_end_probe+0x14a/0x1e3 [stap_246f93f30a500769142af9987624737a_5072]
> [<ffffffffa02e2ed1>] _stp_cleanup_and_exit+0x2df/0x2f8 [stap_246f93f30a500769142af9987624737a_5072]
> [<ffffffffa02e51df>] _stp_ctl_write_cmd+0x460/0x7f8 [stap_246f93f30a500769142af9987624737a_5072]
> [<ffffffff81044e0b>] ? __wake_up+0x4d/0x6e
> [<ffffffff81229bca>] ? tty_ldisc_deref+0x74/0x8f
> [<ffffffff81169d20>] ? security_file_permission+0x24/0x3a
> [<ffffffff810f00f7>] vfs_write+0xc1/0x180
> [<ffffffff810f07c3>] sys_write+0x56/0x93
> [<ffffffff8100beeb>] system_call_fastpath+0x16/0x1b
>
> Could someone please provide pointers on the cause of this bug?
>
>
>