Hi!
A long post, but hopefully I get atleast some insight :)

As the topic states. Since the 3.11-1.dmz.1-liquorix-amd64 update, my cpu (i7-3770K) seems to stay at turbo mode, i.e. 3.8GHz.

i7z program says that all cores stay at 3898MHz (max turbo for this cpu). Core0 stays at C0 state 100%, whole the time, but the rest seem to swap between C1, C3 and C6 depending on load.
It stays this way even in recovery mode, when there's almost no cpu utilization. Top and ps seem to indicate no out-of-control processes.


/sys/devices/system/cpu/cpu[0-7]/cpufreq/*


Inxi:


I'm quite sure there was no packets that could affect this, the last time I did an apt-get upgrade.
And liquorix 3.10 did have a working governor, because I did some load testing and monitored cpuinfo with: watch grep MHz /proc/cpuinfo
Back to top

I had this issue start in 3.10, different cpu:



debian sid, updated to present.

No idea if the stuff is related, sadly, the excessive rate of linux kernel releases almost guarantees, no, it does guarantee, that things that were working will break, and things that were broken, might get fixed, might not, and new features will be added, and those may break old features. This is why in sane software development, you do not release 4 primary versions a year, give or take, it's too many, too little time to stabilize and fix bugs as they happen.
Back to top

Hmm, this must be a bug in intel_pstate. I was using intel_pstate in 3.10 and my temperatures were the same as the temperatures when using acpi-cpufreq with ondemand.

Anyway, check this post under the arch linux forums. It appears that when implemented correctly, intel_pstate should be significantly better than acpi-cpufreq. There's no denying though that something is wrong with intel_pstate - I'm just watching Breaking Bad and it has one core stuck in C0:





Source: bbs.archlinux.org/viewtopic.php?pid=1294415#p1294415

In the meantime, we can add intel_pstate=disable to our boot parameters and see what happens. I'll test it myself too and if the temperatures drops, set intel_pstate to disable by default.

If you don't mind, can you test with intel_pstate and see if acpi-cpufreq with ondemand is indeed lowering your temperatures?
Back to top

Sorry for the late reply, but I've been very busy lately.
I'll test as soon as I get some free time.
Back to top

I just thought I'd add my two cent.

I'm getting the same behavior with liquorix 3.11-1. My i7 2630QM stays in the high range of 2500 - 2800 MHz and only occasionally drops below 1500 MHz. Version 3.11-2 is much worse. It doesn't ever drop below 2700 MHz and the temp. skyrockets from ~32 C to the mid 70's in under half a minute from a cold boot up.

I think my nVidia 325.08 edgers driver may be staying at higher frequencies for longer periods. Although, that could easily be me.

I'm running a self compiled 3.11 clean except for using oldconfig and the frequency scaling for the cpu is fine. Ranges between 760 - 1400 MHz and only hits the 2000+ mark rarely and as needed.
Back to top

I just rebooted into liquorix 3.11-2 with intel_pstate=disable set as boot parameter. Frequency scaling is much better but not great. It now normally stays at 800 MHz but never lower. Only occasionally peaks and simply goes straight to 2001 MHz but no higher. Nor is there any middle ground. It's either 800 or 2001 MHz and that's it.
Back to top

Same behavior with 3.11-3. My i7 stays in turbo mode.
Back to top

warfacegod, this is intended behavior. Liquorix will only burn more power than a typical stock kernel that uses the default scaling configuration. This is to improve performance and reduce latency. There's no magic configuration that lets me save power and reduce latency at the same time, so the power has to give.

As far as intel_pstate goes, yes there's some kind of bug where the CPU prefers turbo and high frequencies over low frequencies when the system is relatively idle, I really don't know what's going on with that. It could be with Sandy Bridge and Ivy Bridge processors, the frequency of the CPU doesn't matter as much as the C state that a core is in, so intel_pstate intelligently keeps your CPU as a higher frequency.

This is why I asked gvoima what his temperatures were with intel_pstate in liquorix versus a kernel that appears to be working "correctly". All that matters is that the CPU governor is reducing power usage, which results in reduced heat. For example, when my laptop is idle, my CPU cores are at about 40*C. Right now I'm typing up this response while watching a 720p video on YouTube. The temperatures on my cores are 45*C right now and intel_pstate is putting my CPU cores in turbo:



And here's i7z:


And lastly, the last kernel upload changes nohz behavior from 'FULL' to 'IDLE'. I have a suspicion that intel_pstate has not been fully tested with nohz_full and it relies on the kernel to have a steady tick while the CPU is doing work.
Back to top

Ok, first and foremost sorry for the very late answer. I've been so busy that I completely forgot this thread :)

And secondly, the only problem here is that the one core is stuck at c0 state at 100%
With the kernel parameter provided the only difference is, that the one core (core 0) temperature drops about 3-5 degrees celsius.

This is not a problem atm. because I use a watercooling, a mATX case and it's winter, but in the summer when the overall temperature is much higher, the one core can raise the whole cpu temperature quite a lot.

Let's hope there's a fix when we get to kernel 3.12, there should be some (major?) fixes relating to the governors.
And btw. I'm still using the same kernel when I posted this thread.

[edit] oh, and if there's anything I could test, please feel free to ask. I should have some spare time now.
Back to top

Looks like 3.11.8 may have fixed the issue. Here is the new output from i7z - no 100% C0 on Core 0:



EDIT: Just read that you never upgraded your kernel. My early kernels for 3.11 have full dynticks enabled. This is wrong and increases heat output by never letting Core 0 get out of C0. Upgrade to the latest in the repository and that should fix your heat problems.
Back to top