https://bugzilla.kernel.org/show_bug.cgi?id=77201 --- Comment #48 from Srivatsa S. Bhat <srivatsa@xxxxxxx> --- Hmm, this just became even more hard :-( Viresh, sure, I'll check the diff tomorrow to see if there is any obvious breakage. Meanwhile, can the bug reporter please test these commits that I mentioned earlier? (6f1e4efd882 is my first suspect commit after 3.13.8) 6f1e4efd882 (cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabled) 1c0ca90207 (cpufreq: don't call cpufreq_update_policy() on CPU addition) 4e97b631f24 (cpufreq: Initialize governor for a new policy under policy->rwsem) I know that the issue might not be in cpufreq (especially after your test results from Viresh's branch). But I still I have some tiny hope that we might have missed something in cpufreq... Besides, bisecting within the cpufreq commits is a lot faster than bisecting everything between 3.13.8 and 3.14, in case the bug is really in cpufreq. By the way, testing the above commits means that you need to test 1 commit before the commits mentioned above and see if it works, and then go to the mentioned commit and see if it fails. Regards, Srivatsa S. Bhat -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
