<div dir="ltr">Of course, using acpi has its drawbacks. Depending on processor capability, sometimes a longer-running task at low frequency uses more power than a fast task at a high frequency. The intel_pstate driver knows about this and accomodates. The issue is that intel_pstate does not use the same governor options as acpi; with intel_pstate, there are only powersave and performance.<br>
<br>So in this case, the "right" solution is for me to go hunt down the configurations for the cpuspeed daemon and modify it to not try to set the scaling_governor to something that is not allowed.<br><br>This post has more information:<br>
<a href="https://bbs.archlinux.org/viewtopic.php?pid=1294415#p1294415">https://bbs.archlinux.org/viewtopic.php?pid=1294415#p1294415</a><br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 12:25 PM, Joshua Kramer <span dir="ltr"><<a href="mailto:joskra42.list@gmail.com" target="_blank">joskra42.list@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>So I found out that starting with 3.4 I think, the kernel defaults to using the intel_pstate driver instead of acpi_pstate. If using the intel_pstate driver causes issues (as it did with me), then add this to the kernel boot parameters:<br>
<br>intel_pstate=disable<br><br></div>After doing this, my copy of the 3.12 kernel now uses the acpi driver, and things work as they should.<br><div><div class="gmail_extra"><br></div></div></div>
</blockquote></div><br></div>