Description of problem: CPU always runs on full power, regardless of load. Selecting a power management scheme from KPowersave does not affect anything. Version-Release number of selected component (if applicable): kernel.i686 2.6.25.6-55.fc9 How reproducible: Always, on this specific hardware. Steps to Reproduce: 1. Install Fedora 9 from the KDE live media. 2. Click the KPowersave icon in the tray. Actual results: CPU is at 100% power. Expected results: Should see the CPU on a low power state instead of the full power state. Additional info: Output of lspci, lsmod and a few other commands added as attachments.
Created attachment 309658 [details] Output of /sbin/lspci
Created attachment 309659 [details] Output of /sbin/lsmod
Created attachment 309660 [details] Output of cat /proc/cpuinfo
Created attachment 309661 [details] Output of cat /proc/acpi/processor/CPU0/info
Created attachment 309663 [details] Output of modprobe acpi_cpufreq
I'm assuming by 'throttling' you mean 'run at different speeds'. Your CPU doesn't actually support this feature. In earlier releases, you were using 'p4-clockmod', which faked the appearance of running at different speeds, by inserting 'pauses' between running instructions. This doesn't actually save any power (which is why it got removed). Matthew has been working on making ACPI 'do the right thing' in the absence of working throttling states. Faking P-states is completely the wrong thing to do however, so kpowersave/cpuspeed/cpufreq-applet will never work on your hardware. Looking at your acpi/processor/info output though, it looks like your cpu/bios doesn't expose T-states either.
Thank you for the fast response. It seems I was then just misinformed about the actual functionality.
I have noticed that after loading p4-clockmod.ko on an Intel Celeron 2 GHz desktop system running kernel 2.6.18-92.1.10.el5, minimum and maximum frequencies are both set to 20000000. Thus, there is no scaling at all whereas the clock is adjusted dynamically for kernel 2.6.22.14-72.fc6 which has been added for testing purposes. Is this change an intended one follwing the reasoning of comment #6?
(In reply to comment #8) more /proc/acpi/processor/CPU1/info processor id: 0 acpi id: 1 bus mastering control: no power management: no throttling control: yes limit interface: yes more /proc/acpi/processor/CPU1/throttling state count: 8 active state: T0 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87%
(In reply to comment #9) After installing F10 plus updates including kernel-2.6.27.5-123.fc10.i686, the p4-clockmod module is present and can be loaded. However, the cpuspeed daemon cannot be started, and /sys/devices/system/cpu/cpu0/cpufreq/ is empty. However, dmesg actually reports: "p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available" upon loading of module p4-clockmod.
this is expected behaviour. The user-interface is meant to be disabled. The ACPI code will call into the p4-clockmod code directly when throttling is necessary.