Cool. inxi appears fixed for me as well. As long as we're working on inxi, there are two additional issues that are probably not bugs, but you may want to look at them:

1. Does the "HT" next to my CPU indicate hyperthreading? If so, the 2500K does not support hyperthreading. Perhaps "faking" 8 threads in /proc/cpuinfo is to blame.
2. The CPU is actually running at 4.7GHz, not 3.3GHz. This probably has to do with the way overclocking works on Sandy Bridge and newer CPUs. You basically set the clock speed of the "turbo" mode and set the CPU to always run at the turbo level. 3.3GHz is the base speed, but it never runs at that clock and frequency scaling is disabled anyway. CPU-Z on Windows reports 4.7GHz. It may not be worth supporting this, but the forthcoming Ivy Bridge appears to work the same way.

Back to top

damentz, let me know what you need to debug the kernel power issue. I agree it may be a regression in the core code, but it might be worth a look at the changes between -4 and -5. Cheers.
Back to top

HT is triggered when core count = 1/2 processor count, or

2 * core count = processor count

it's automatic. It basically shows you that you have x virtual cores, but y actual ones.

Not much we can do there except change the names or something, the idea is the same.

The cpu speeds are taken from /proc/cpuinfo so if that's lying, or inaccurate, there's nothing we can do about that.

Unless you can show a totally reliable way to get the real speeds, we'll have to stick with this. IE, something to look for that shows that some other overclocking factor is in play, and what that is, not easy.
Back to top

That's exactly how I was expecting you to reply. Perfectly reasonable. Thank you.
Back to top

I did another sanity check by booting with 3.2.0-4 again. The same increased power usage problem remains. Perhaps that rules out your configuration changes as the culprit. I tested this before, but maybe something wasn't exactly equal. I am using the same nvidia driver that I was before the problem started so I doubt that's it. There have been some minor updates to KDE backports, but it would be strange if KDE was the problem. I'm open to suggestions. Anyway, liquorix may be off the hook :) I hope I didn't waste your time.

One thing to note... I have definitely been seeing some instability with my system lately (2 crashes per day). I thought this was also introduced with kernels newer than 3.2.0-4, but I am retesting again to be sure.
Back to top

I tested a few more things including 100% load on Windows to see if I could rule out a few things.

1. Booting to a command prompt and not starting kdm doesn't fix the problem. Therefore, KDE or any other apps I run in X must not be at fault.
2. Prime95 in Windows uses more power still.

My latest best guess is that my Folding@home client got a more complicated work unit(s) about the time that liquorix 3.2.0-5 was released. When I first tested by booting back into -4, perhaps it got an easier WU again. It's possible that different WUs use more or less power, but I've never seen it that drastic. Anyway, it doesn't seem like your problem. Sorry about that.

However, I'll keep testing the instability issue to see if that's new. Even if it is, it's probably something in the latest KDE 4.8 updates that's messing with the nvidia driver because it never happens unless I'm actively using KDE.

Thanks for checking anyway.
Back to top

Your guess re kde 4.8 + current nvidia driver is a good one.

www.nvnews.net/vbulletin/forumdisplay.php?f=14

check those forums for issues, and consider maybe filing a bug report on the crashes there after searching to see if others have seen this problem with kde 4.8 and latest nvidia, that's a good guess.

You seem to be thinking clearly re possible causes of cpu spikes, such coincidences, like new kernel but also new folding WU are by no means unheard of.

Best test is to turn off the folding actions and see what happens with a controlled baseline operating system, otherwise there are too many variables.

If you want to spike the cpu, try this:

open a terminal, open 8 tabs in it, then in each, run this command:

ctrl+c to kill the process per tab.

That's what I use when I want to do cpu scaling etc testing, that says;

create endless zeros, then send each to /dev/null as you create it.

Each thread, or process, which usually means, each cpu core/ht core will then spin as fast as it can on that problem.

This is a very controlled cpu spike, you can test if you need to do it 8 times, or if 4 is enough, just do: inxi -C to see the cpu per core use.

Once you get all cores spiked to close to 100% use, then you can check the wattages, kill one core process, check wattage again, and so on. this will give you a very fine tuned sense of wattage per core, and what the overall cpu does as a baseline with very little variability, ie, that will always run as fast as it possibly can per core.
Back to top