F14 cpuspeed / ondemand broken?

["Jóhann B. Guðmundsson"]

On 01/01/2011 09:43 PM, Steven Haigh wrote:
> 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.

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/test/attachments/20110103/b1c406ce/attachment.html