https://bugzilla.kernel.org/show_bug.cgi?id=19702 --- Comment #18 from vyncere <vyncere@xxxxxxxxx> 2010-10-16 08:56:37 --- I just did some tests with >= 2.6.33 Kernels. * Results : 2.6.33 : KERNEL_PANIC (Ouch !!!) 2.6.33.1 : Ondemand scaling KO (freeze my laptop after few minutes... I did not investigate deeply...) In any case, just before freezing, I had enough time to check cpufreq-info and cpuidle state. * cpufreq-info print out the same "hardware limits" and "cpufreq stats" that I reported higher in this thread, when Ondemand governor failed to scale. So the regression may highly appear since 2.6.33. * The current driver used for cpuidle was "acpi_idle". So, if intel_idle driver is not incriminated, we can check the differences between 2.6.32.24 and 2.6.33[.1] Kernel tree, which may cause this regression. * Comparing the two "drivers/cpufreq" directories, there are some changes between : - cpufreq.c (add bios limit reading and release the rwsem around governor) - cpufreq_conservative.c (some stuffs, but I never use this gouvernor) - cpufreq_ondemand.c (very few : add a condition to read the new min policy) - freq_table.c (some function names refactoring) I'm not a kernel hacker and I do not know (not yet) how the cpufreq API works. I hope this information will help you. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list 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
