On 01/01/2011 09:43 PM, Steven Haigh wrote:
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 |
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
