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

[Paul E. McKenney]

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.

							Thanx, Paul