On Sat, Mar 23, 2013 at 08:46:00PM +0530, Viresh Kumar wrote:
On 23 March 2013 20:04, Viresh Kumar viresh.kumar@linaro.org wrote:
I think otherwise, Its the cpu online path but this didn't happened for first boot (probably).
I tried on my 4 cpu laptop and my bad, couldn't reproduce the issue reported by both Borislav and Duncan :(
Hibernation logs (Borislav's bug): https://pastebin.linaro.org/2019/
cpufreq-info after hibernation (same happens with suspend) (Duncan's bug): https://pastebin.linaro.org/2020/
Those pastebin things want a login. Use a free one.
The main difference between our systems is number of cpu groups that share clock line. On setup of both Duncan and Borislav, they had total of 8 cpus and four groups 0-1, 2-3, 4-5, 6-7. And thus have four policy structures. And i have only one group 0-1-2-3 and thus only one policy struct.
So this should give you a clue - you need to repro it on a similar machine and your laptop is obviously not similar.
@Borislav: BTW, can you try reproducing your issue again? If that is reproducible?
I've seen it only once so far and I've suspended the machine a bunch of times already. So I don't think it is that easy to reproduce.
I don't see (logically) how sub_preempt_count() can be called from cpufreq_governor_dbs()? As it is mostly called from kernel/sched/ part only.
As Rafael said, there's a notifier running which can, AFAICT, disable preemption on another CPU in parallel, for example.
If you still get it, try disabling cpufreq completely and see if it is gone or not.
Unfortunately this is my desktop machine and I don't want to test stuff on it because I need it to work. And I've already downgraded to 3.8.3 because of the other cpufreq breakage which kept a subset of the cores at max freq because acpi-cpufreq wasn't loading on them.