https://bugzilla.kernel.org/show_bug.cgi?id=16072 Robert Bradbury <robert.bradbury@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robert.bradbury@xxxxxxxxx --- Comment #1 from Robert Bradbury <robert.bradbury@xxxxxxxxx> 2010-06-25 07:02:05 --- See Kernel Bug #14771 and Gentoo Bug #287463. The "ondemand" scheduler was changed circa Linux 2.6.30 so it no longer works correctly. (Patch to p4-clockmod.c is attached to the Gentoo bug report). Kernel developers seem to believe that everyone is running Intel CPU's with "Enhanced" SpeedStep capabilities with an ACPI BIOS which has power control (_PCT) abilities. If either are unavailable then the acpi-cpufreq driver is unlikely to work. For the "ondemand" scheduler to work correctly it needs to be fixed so detects non-enhanced Intel SpeedStep processors *or* non-_PCT enabled ACPI BIOS conditions and reverts the ondemand scheduler that found prior to Linux 2.6.30 (though changing p4-clockmod.c: policy->cpuinfo.transition_latency to the old value -- or some other modifications). In your case I think the Celeron may have "Enhanced" SpeedStep capabilities, but if the HP ACPI BIOS doesn't have the "_PCT" controls the acpi-cpufreq functions are unlikely to work. You need to build the kernel with both acpi-cpufreq and ondemand as modules and flip back and forth between them with ACPI debugging enabled. If you attempt to modprobe acpi-cpufreq and get "No such device" (ENODEV) it is likely your BIOS is the source of the problem. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- 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
