C states not used

Well, that makes two. Any more?
Just stumbled upon this thread while checking C-state usage on my different machines, which are all running RELENG-12.2. It seems my Compaq notebook (Core2Duo T6600) shows the same behaviour of neither C2 nor C3 being ever used:
Code:
dev.cpu.1.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc/bma
dev.cpu.1.cx_usage_counters: 2152134 0 0
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 2634us
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.1.temperature: 43,0C
dev.cpu.1.coretemp.throttle_log: 0
dev.cpu.1.coretemp.tjmax: 100,0C
dev.cpu.1.coretemp.resolution: 1
dev.cpu.1.coretemp.delta: 57
dev.cpu.1.%parent: acpi0
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%driver: cpu
dev.cpu.1.%desc: ACPI CPU
dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc/bma
dev.cpu.0.cx_usage_counters: 2105107 0 0
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 1056us
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/57
dev.cpu.0.freq_levels: 2200/35000 1600/23000 1200/15000
dev.cpu.0.freq: 1200
dev.cpu.0.temperature: 43,0C
dev.cpu.0.coretemp.throttle_log: 0
dev.cpu.0.coretemp.tjmax: 100,0C
dev.cpu.0.coretemp.resolution: 1
dev.cpu.0.coretemp.delta: 57
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.%parent:
Another machine with a Core i3 550 CPU doesn't really like to spend much time in C3 although it's probably being idle most of it's life:
Code:
dev.cpu.3.cx_usage: 2.20% 94.62% 3.16% last 3272us
dev.cpu.2.cx_usage: 4.91% 92.32% 2.75% last 911us
dev.cpu.1.cx_usage: 10.80% 87.59% 1.60% last 940us
dev.cpu.0.cx_usage: 6.44% 93.37% 0.18% last 180us
Whereas my desktop machine running a Core i5 6600 paints an entirely different picture:
Code:
dev.cpu.3.cx_usage: 33.36% 43.27% 23.35% last 436us
dev.cpu.2.cx_usage: 32.77% 35.33% 31.89% last 376us
dev.cpu.1.cx_usage: 31.43% 32.92% 35.64% last 586us
dev.cpu.0.cx_usage: 34.09% 36.13% 29.76% last 661us
As I haven't been running anything older than FreeBSD 12 on this particular notebook, I cannot say whether or not it has been working (differently/at all) in 10.x. Still, the fact that it doesn't seem to be using C2/3 at all doesn't look right.
 
I noticed that some time ago my laptops did stop using C states, and looking it up with sysctrl shows that f.e. C2 is unused in 30 seconds idle time. Yes, powerd is running, est is loaded, Cmax is set in tuneables to C3. It happens on a core2duo as well as core1solo. I can supply more info when I am back on my machines.

Did I miss some migration action on 11.1?
Necromancer FrostKiwi reporting in for 3 year old Necroposting:
Same deal for me stuck at C1, FBSD 13, Thinkpad x200, Core2Duo. I had the same issue on DragonFlyBSD, but IIRC there it was solved by switching Hardware timer, to i8254 as per doc. This does not apply to FBSD and it's realtime kernel anymore if I understand it correctly.
Here my sysctl dev.cpu
Code:
dev.cpu.1.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc
dev.cpu.1.cx_usage_counters: 14390 0 0
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 1393us
dev.cpu.1.cx_lowest: C8
dev.cpu.1.cx_supported: C1/1/1 C2/2/1 C3/3/55
dev.cpu.1.freq_levels: 2667/35000 2666/35000 2133/25000 1600/15000 800/12000
dev.cpu.1.freq: 1600
dev.cpu.1.%parent: acpi0
dev.cpu.1.%pnpinfo: _HID=none _UID=0 _CID=none
dev.cpu.1.%location: handle=\_PR_.CP01
dev.cpu.1.%driver: cpu
dev.cpu.1.%desc: ACPI CPU
dev.cpu.0.cx_method: C1/mwait/hwc C2/mwait/hwc C3/mwait/hwc
dev.cpu.0.cx_usage_counters: 14522 0 0
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 4018us
dev.cpu.0.cx_lowest: C8
dev.cpu.0.cx_supported: C1/1/1 C2/2/1 C3/3/55
dev.cpu.0.freq_levels: 2667/35000 2666/35000 2133/25000 1600/15000 800/12000
dev.cpu.0.freq: 1600
dev.cpu.0.%parent: acpi0
dev.cpu.0.%pnpinfo: _HID=none _UID=0 _CID=none
dev.cpu.0.%location: handle=\_PR_.CP00
dev.cpu.0.%driver: cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.%parent:
For good measure also "dmesg | grep cpu"
Code:
cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
[drm ERROR :intel_cpu_fifo_underrun_irq_handler] CPU pipe A FIFO underrun
Something curious here and in every other user's post:
mwait comanded C-states are detected, but ACPI commanded c states are not. There should be two sets of C-states listed, but only one is present. Normally it looked like this when it worked IIRC:
dev.cpu.0.cx_method: C1/acpi C1/mwait C2/acpi C2/mwait C3/acpi C3/mwait

Either way, if memory does not betray, these CPUs can get you to C4 (even though the OS only sees C3). And the powersavings going from C1 to C2 were huge. I'm hitting myself for not properly writing the data down, but on DragonFlyBSD I split a Notebook cable and measured a drop from ~30W to 16W going from C1 to C4. (On a Core2Quad Thinkpad with fullbright Monitor).
1Nw6rbA.jpg
ZBqTfMc.png

Thus I would love to get those c-states going. If there is anything I could do (creating dumps with a debug Kernel or what have you), I'm here.
 
Hell yeah it's fixed :D
The problem was indeed the same as with DragonFlyBSD.

kern.timecounter.hardware is by default TSC-low, even when the KENV kern.timecounter.hardware was set to something different. So first of all, the KENV is not being honored. (Though this can luckily be set after boot as well)

Next, as long as TSC-low is enabled, the kernel just refuses to go into lower C-states. Simply setting kern.timecounter.hardware to something different, even after boot fixes everything.
kern.timecounter.hardware=HPET works for my Thinkpad x200 with an Intel Core2Duo P8800
 
Now C3 is used about 22% when totally idle. This seems to be the way.
 
Now C3 is used about 22% when totally idle.
Confusingly, the percentages are cumulative. As long as the percentage rises, it is being used 100% of the time. If you have had a CPU load for an hour and the CPU enters complete idle, it will still show 90-99% usage of C1 for the next 10 minutes, even when only C3 is being used.
 
Back
Top