Distribution: gentoo Linux Hardware Environment: nforce2, Athlon XP 1700+ Software Environment: Linux Problem Description: cat /proc/acpi/processor/CPU0/power active state: C1 default state: C1 bus master activity: 00000000 states: *C1: promotion[--] demotion[--] latency[000] usage[00000000] C2: <not supported> C3: <not supported> shows the problem: My CPU/mobo combination can do C1 state, but either it is not used or it is not counted. Looking at my idle temps, I rather think C1 isn't probperly used. sensors eeprom-i2c-1-52 Adapter: SMBus nForce2 adapter at 5000 Memory type: DDR SDRAM DIMM Memory size (MB): 512 eeprom-i2c-1-50 Adapter: SMBus nForce2 adapter at 5000 Memory type: DDR SDRAM DIMM Memory size (MB): 512 w83627hf-isa-0290 Adapter: ISA adapter VCore 1: +1.69 V (min = +1.65 V, max = +2.05 V) VCore 2: +2.81 V (min = +1.65 V, max = +2.05 V) +3.3V: +3.29 V (min = +2.82 V, max = +3.80 V) +5V: +5.09 V (min = +0.44 V, max = +0.01 V) +12V: +11.33 V (min = +0.02 V, max = +0.02 V) -12V: -12.25 V (min = -14.88 V, max = -14.80 V) -5V: -5.18 V (min = -7.59 V, max = -7.29 V) V5SB: +5.30 V (min = +0.44 V, max = +0.01 V) VBat: +3.65 V (min = +0.52 V, max = +0.01 V) fan1: 0 RPM (min = -1 RPM, div = 2) fan2: 0 RPM (min = 10546 RPM, div = 2) fan3: 1527 RPM (min = -1 RPM, div = 4) temp1: +39
Created attachment 2783 [details] dmidecode
Created attachment 2784 [details] acpidmp
reproduced on non-nforce2 system.
Perhaps just to mention: It seems on VIA chipset it works. Checked on MVP3 and KT133. (Both having C1 and C2 state.)
I think, this is more of a misinformation from ACPI C-state driver than anything else. C1 state is same as "halt". When a platform only supports C1 state, there is nothing special that ACPI can do to save power. It just lets the normal idle routine to handle it, by calling "halt". If you look at 'cat /proc/acpi/processor/CPU0/info', you should see "no" for power. That means there is nothing more ACPI can do to manage C-states. And we dont use acpi pm_idle in that case. If a platform supports C2 or C3, thats when acpi pm_idle becomes active, by changing across different C states.
Oh OK, sound very reasonable. Nevertheless it would be nice if even in just C1 case, acpi would handle it and count the usage, so -like in my case- it would be easier to hunt after drivers which seem to prevent the C1 usage (-> higher idle temps.) by looking at the amount of C1 calls done.
Created attachment 2855 [details] use acpi_idle even when only C1 is available
Ok. Simple, effectively one line, patch attached here does that. Disclaimer - It doesn't save any power. It doesn't improve performance. Only thing it does is to use acpi_idle, even when just C1 state is available. And gives prettier numbers in /proc/acpi/processor/CPU1/power. Not sure whether incorporating this patch in acpi adds good enough value. Len can make that call.
Thanks for the patch. Even it just gives statistics, I think it may be usefull for some people.
Len, what do you think about the patch? Then we can close the bug.
*** This bug has been marked as a duplicate of 4233 ***