This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: BUG: [preempt-rt] scheduling while atomic: stapio
On 05/27/2009 02:01 PM, Paul E. McKenney wrote:
> On Wed, May 27, 2009 at 09:43:22AM -0700, Darren Hart wrote:
>> Josh Stone wrote:
>>> On 05/20/2009 02:44 AM, Kiran wrote:
>>>> BUG: scheduling while atomic: stapio/0x00000001/26142, CPU#3
>>>> [...]
>>>> [<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]
>>> enter_end_probe will call preempt_disable, and apparently the call path
>>> from cpufreq_unregister_notifier can sleep. Is this true only of the RT
>>> kernel?
>>
>> The call into the __synchronize_sched() from synchronize_rcu() appears to
>> be able to sleep regardless of -rt. It's possible -rt is more likely to
>> make them sleep.
>
> One would expect __synchronize_sched() to sleep, except on non-rt
> uniprocessor systems. So a uniprocessor system might well see this
> only when running -rt.
Thanks for the confirmation guys. I went ahead and rearranged our code
that calls cpufreq_unregister_notifier to run in a context that is
permitted to sleep, so it shouldn't be a problem anymore.
Josh