Re: cpufreq + PREEMPT_RT_FULL give bad context sleeping BUG

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 26 Mar 2013, Sebastian Andrzej Siewior wrote:

> * Gregoire Gentil | 2013-03-23 10:17:51 [-0700]:
> 
> >Hello,
> Hi,
> 
> >On OMAP + 3.4 + rt patches with CONFIG_PREEMPT_RT_FULL
> >CONFIG_CPU_FREQ_GOV_ONDEMAND, I get a lot of those cpufreq-related
> >bugs:
> >
> >http://pastebin.com/csy9y3xk
> >
> >BUG: sleeping function called from invalid context at kernel/rtmutex.c:646
> >(__might_sleep+0x124/0x144) from (rt_spin_lock+0x30/0x64)
> >(rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
> >(clk_get_rate+0x30/0x54) from (twd_update_frequency+0x20/0x58)
> 
> Here it tries to grab a mutex
> 
> >(twd_update_frequency+0x20/0x58) from (smp_call_function_single+0xd0/0x1c4)
> >(smp_call_function_single+0xd0/0x1c4) from
> 
> Here it calls a smp functions which runs with interupts off.
> 
> >(twd_cpufreq_transition+0x34/0x40)
> 
> that means it should trigger on mainline as well.

No. It won't. Mainline uses a spinlock which gets converted to a
sleeping spinlock on rt.

  (rt_spin_lock+0x30/0x64) from (clk_get_rate+0x30/0x54)
 
> >Any idea what I should do to fix this problem?

One possibility would be to convert the clk->spinlock to a raw
spinlock, but you have to audit the code which implications this has
latency wise. In theory the code under the spinlock should not do
anything time consuming, so it should be fine. If it does something
time consuming, we better fix that anyway.

Thanks,

	tglx