The kernel can be made to only load modules which it thinks are trustworthy. It can be used as a countermeasure against rootkits or the like. Add enforcemodulesig=1 as kernel boot parameter if you wanne play with it. In your case the module is not blocked but the kernel is merely flagged as tainted. So if you report a kernel issue to the Ubuntu folks they will more likely notice it and will probably tell you to reproduce the bug with a pristine kernel, because they won't bother hunting bugs in code they can't control.

However, the module should work as expected. Does it? Just ignore the message and if it really bothers you to have a tainted kernel search the internet on how to sign modules (or how to disable the check )

phc-intel:
Running module version sanity check.
Good news! Module version for phc-intel.ko
exactly matches what is already found in kernel 3.11.0-15-generic.
DKMS will not replace this module.
You may override by specifying --force.

Just did a quick run with 2x burncpu and 2x stress. 2 minutes lowered vids as above, 3 min stock, 2 min lowered again. Still a lot of noise in it and much more fluctuations in the stock voltage area, but the modified vids seem to have overall lower power consumption. Also, xsensors reports a little lower temperatures. So I think it works. Big THX!

This hops back and forth, "performance" sets 2.4-2.4 GHz, "ondemand" sets 1.6-1.6 GHz. But it takes half a minute to change between them, so that cannot be optimal. And, as power consumption is also a linear function of frequency, this cannot be the most economic setting as well.

Bzzz wrote:This hops back and forth, "performance" sets 2.4-2.4 GHz, "ondemand" sets 1.6-1.6 GHz. But it takes half a minute to change between them, so that cannot be optimal. And, as power consumption is also a linear function of frequency, this cannot be the most economic setting as well.

The performance governor stays at the highest frequency all the time. No transitions no lower frequency, just pure performance.

By default the ondemand governor switches between lowest and highest available frequencies all the time but cpufreq-set --min and --max can nail the frequency to some specific values (which is great to test carefully every frequency and its undervolted stability). If you set --min and --max appropriately, you can enable all of the steppings.

You mentioned tlp control. Did you specify a min or max frequency in there or. if you use it, in laptop-mode-tools?

lio wrote:By default the ondemand governor switches between lowest and highest available frequencies all the time but cpufreq-set --min and --max can nail the frequency to some specific values (which is great to test carefully every frequency and its undervolted stability). If you set --min and --max appropriately, you can enable all of the steppings.

No, it can't. It wont set 800 or even 1600 als max freq. And although set manually, 800 as min freq is not used.

lio wrote:You mentioned tlp control. Did you specify a min or max frequency in there or. if you use it, in laptop-mode-tools?

Without phc, all steps worked fine. So the phc governor has yet to prove that it is not his fault

Did work all the time, I recently had some 30 days "uptime", but put it in sleep mode every night. Atm, it doesn't even shut off the screen and wake up asap, but instead the sleep indicator is blinking for a minute, and then everything is back up. I don't know what the mount.nfs message has to do with it, I have in fact nfs mounts configured, but not active. I do some testing if disabling the boot parameter and therefore not using phc fixes this...

Bzzz wrote:Without phc, all steps worked fine. So the phc governor has yet to prove that it is not his fault

If you don't set any value through the phc-interface at all, you get the stock acpi-cpufreq behaviour. At least it's supposed to be this way. What kind of CPU do you have? Which patch-version do you use: 0.3.2 or 0.4.0?

but not active. I do some testing if disabling the boot parameter and therefore not using phc fixes this...

Is the suspend-fail reproducible over multiple reboots and does it on the other side succeed with the stock acpi-cpufreq? It could all be related – If you undervolt your system to much it crashs in an instant. No crash does not mean the lower voltage is safe to use. If you use phcintel without applying any settings, does it happen too? Next step would be to test a vanilla kernel from kernel.org with phc applied.