To be honest, I looked through all the screens of the BIOS and I can't
see anything that may affect this. As the ONLY defaults option available
is optimal, I gave it a go ;)
Unfortunately it might not be that obvious which BIOS knob(s) need
to be turned. . . .
As an example in some ASUS BIOS they have a "AITweak section" which
has an option called "ASUS/3rdParty UI Priority" which needs to be
set to "3rdParty" for acpi-cpufreq to load and cpuspeed governors to
work accordingly.
As you can see in that example it's far from being "Captain Obvious"
which knob the end user should/needs to turn so users are forced to
walk the lengthy process of turning a BIOS knob reboot, check,
reboot turn the next BIOS knob etc.. until they hit the *magic* BIOS
knob that turns that on.
As I have previously mentioned before, the most common cause these
days for cpufreq scaling not working is that the BIOS has some
secret knob that needs to be turned on to do so.
I took a look at your report and noticed that you mentioned that
"Scaling only happens with DRIVER=p4-clockmod &
GOVERNOR=userspace and the cpuspeed daemon running." Now once more
try to get the wide spread ignorance out of your head that
p4-clockmod has anything to do with frequency scaling. If
maintainers sees p4-clockmod on a report against component I'm
pretty sure that he will direct that report straight to /dev/null
since their patience in educating reporters if exist in the first
place is very thin.
The reason the scaling is happening there is because you set the
governor to userspace so set the DRIVER= and GOVERNOR=userspace and
you should get the same result as I have previously mentioned and
make note of that on your bug report.
Now under normal circumstances Matthew Garret or some other kernel
maintainer would have asked you to add to your report, the output
from acpidump but given that this has been incorrectly triaged and
marked as a duplicated of bug 50837 which was filed against F11 our
kernel maintainers probably wont take a look at it.
I would have expected the kernel team to have opted themselves out
of triage process or at least be extremly selective on the
individuals triaging the kernel since it requires a bit more skill
set than running around changing bug status-is and copy/paste
predefined responses to the report but since it's not the case, I'm
forced to direct you directly upstream to the kernel bugzilla (
https://bugzilla.kernel.org/ ) which is something usually dont
recommend since our bugzilla should be sufficient for our reporters
and it requires reporters to be educated in the art of kernel
patching and compiling since upstream oftern request reporters to
recompile with patch and provide feedback back.
If I noticed more incorrectly triaged reports against the kernel I
will recommend that we take up the policy of directing our reporters
directly upstream instead of using our own bugzilla ( it kinda beats
the triage purpose if maintainers are forced to oversee the triage
process themselves ) anyway creating bugzilla account on
bugzilla.kernel.org is a breeze and should take you a less then a
minute to setup simply click "Open a new Kernel Bug Tracker account"
type in your email address and confirm and provide your real name
and password and you are good to go.
Login into your newly created account and click New, click "Power
Management" in "Component" select cpufreq in "Kernel Version:" put
the kernel versions you tested this on, in "Tree" select Fedora, in
summary put something like cpufreq does not work on <insert cpu
type>/<insert platform>, In Description you should simply
put. Summary says it all and make note if you have tried turning
some bios knobs and it did not make a difference.
Then restore "/etc/sysconfig/cpuspeed" to it's original form,
install the pmtools package which contains acpidump and boot with
"cpufreq.debug=7".
Run. . .
dmidecode > /tmp/dmidecode.txt and attach it to the report
dmesg > /tmp/dmesg.txt and attach it to the report
acpidump > /tmp/acpidump.txt and attach it to the report
And the output of "for x in
/sys/devices/system/cpu/cpu0/cpufreq/*;do echo $x;cat $x;done
&& for x in
/sys/devices/system/cpu/cpu0/cpufreq/ondemand/*;do echo $x;cat
$x;done" in a file that's attached to the bug report.