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
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
