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 -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
