Re: BUG: [preempt-rt] scheduling while atomic: stapio

[Josh Stone <jistone@redhat.com>]

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