[Bug 832179] New: Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Bug ID: 832179
        QA Contact: [e-mail]
          Severity: medium
           Version: devel
          Priority: unspecified
                CC: [e-mail], [e-mail]
          Assignee: [e-mail]
           Summary: Power management guide is wrong for frequency scaling
                    in Fedora 17
        Regression: ---
      Story Points: ---
    Classification: Fedora
                OS: Linux
          Reporter: [e-mail]
              Type: Bug
     Documentation: ---
          Hardware: All
        Mount Type: ---
            Status: NEW
         Component: power-management-guide
           Product: Fedora Documentation

Description of problem:
Power management guide is wrong 
https://docs.fedoraproject.org/en-US/Fedora/17/html/Power_Management_Guide/c...

Version-Release number of selected component (if applicable):
Fedora 17

the location of the cpufreq directory is misspecified
it is
/lib/modules/3.4.0-1.fc17.x86_64/kernel/drivers/cpufreq

There are no modules
acpi-cpufreq or p4-clockmod available
is acpi-cpufreq directly compiled in.

the cpuspeed package is mentioned for the userspace governor but no package
exists in fedora 17.

I have been completely unable to figure out the following use case.

My laptop overheats and powers off if the cpu load is high for too long.

There should be a cpu governor or userspace daemon that reduces frequency when
the temperature gets too high.

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Jack Reed  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |needinfo?(jskarvad@redhat.c
                   |                            |om)

--- Comment #1 from Jack Reed  ---
Thanks for reporting these issues, Jim. I'll address them individually, and
have asked Jaroslav Skarvada for his advice on a couple of them.

(In reply to comment #0)
> the location of the cpufreq directory is misspecified
> it is
> /lib/modules/3.4.0-1.fc17.x86_64/kernel/drivers/cpufreq

No problem, I've fixed this up.
> There are no modules
> acpi-cpufreq or p4-clockmod available
> is acpi-cpufreq directly compiled in.

Jaroslav, how are these drivers acquired? I don't have them listed in my
/lib/modules/KERNEL/kernel/drivers/cpufreq directory either. (They are
mentioned in the Important admonition in [1].)
> the cpuspeed package is mentioned for the userspace governor but no package
> exists in fedora 17.

Jaroslav, the F16 Alpha release notes [2] say that cpuspeed has been rendered
obsolete. The Power Management Guide mentions that the userspace governor is
"normally used in conjunction with the cpuspeed daemon". Is whatever has
replaced cpuspeed still used in conjunction with the userspace governor? Or can
I just remove this point entirely?
> I have been completely unable to figure out the following use case.
>
> My laptop overheats and powers off if the cpu load is high for too long.
>
> There should be a cpu governor or userspace daemon that reduces frequency
> when the temperature gets too high.

Jim, it would be best to submit a new bug against the cpupowerutils component
as a request for enhancement.

[1]
http://docs.fedoraproject.org/en-US/Fedora/17/html/Power_Management_Guide/cp...
[2]
https://fedoraproject.org/wiki/Fedora_16_Alpha_release_notes#What.27s_New_in...

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Jaroslav Škarvada  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
              Flags|needinfo?(jskarvad@redhat.c |
                   |om)                         |

--- Comment #2 from Jaroslav Škarvada  ---
(In reply to comment #1)
> (In reply to comment #0)
> > the location of the cpufreq directory is misspecified
> > it is
> > /lib/modules/3.4.0-1.fc17.x86_64/kernel/drivers/cpufreq
>
> No problem, I've fixed this up.

All are built-in and get selected automatically, so the text is obsoleted. So
the "3.1 Procedure" should go away. The command:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
is useful and could be moved to 3.2.2 introduction, or maybe to 3.2 procedure.
Or just reuse/modify the text from the RHEL guide.

Also all governors are built-in, so preamble for 3.2 procedure is not right.
> > There are no modules
> > acpi-cpufreq or p4-clockmod available
> > is acpi-cpufreq directly compiled in.
>
> Jaroslav, how are these drivers acquired? I don't have them listed in my
> /lib/modules/KERNEL/kernel/drivers/cpufreq directory either. (They are
> mentioned in the Important admonition in [1].)

Everything is built-in in the kernel. The "important admon" should go away, the
right module should be autoselected by kernel.
> > the cpuspeed package is mentioned for the userspace governor but no package
> > exists in fedora 17.
>
> Jaroslav, the F16 Alpha release notes [2] say that cpuspeed has been
> rendered obsolete. The Power Management Guide mentions that the userspace
> governor is "normally used in conjunction with the cpuspeed daemon". Is
> whatever has replaced cpuspeed still used in conjunction with the userspace
> governor? Or can I just remove this point entirely?

Right, it gone. AFAIK there is currently no replacement (I pointed this out in
the past, but such scenarios are very rare and to be honest this is the way how
it shouldn't be done).
> > I have been completely unable to figure out the following use case.
> >
> > My laptop overheats and powers off if the cpu load is high for too long.
> >
> > There should be a cpu governor or userspace daemon that reduces frequency
> > when the temperature gets too high.
>
> Jim, it would be best to submit a new bug against the cpupowerutils
> component as a request for enhancement.

Currently I am not aware of any similar daemon in Fedora but there are still
some possible workarounds:
You can create/download script that will periodically read sensors and alters
cpufreq settings or you can alter your cpufreq settings statically (i.e. limit
the max freq) by writing to:
/sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
this limits the max frequency the ondemand governor uses on all cores, the bias
can be set to 1 - 1000 to reduce the target frequency by one-thousandth of that
value, or you can limit the max frequency used by ondemand governor on specific
cpu (e.g. for cpu0) by writing the frequency to:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Available frequencies can be get by:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

Or you can switch to userspace governor by (e.g. for cpu0):
# echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

and then control the frequency directly by writing the requested frequency to
(e.g. for cpu0):
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

But anyway the overheating indicates some HW or ACPI table problem.
Cleaning/replacing fan/sink/heat pipes or upgrading BIOS is recommended. In
case your laptop supports thermal zones (check the trippoints in
/sys/class/thermal/thermal_zoneX), you should be able to lower the trippoints
by booting with thermal.act=TEMPERATURE kernel command line parameter, where
TEMPERATURE is the target temperature in degrees where the thermal zone cooling
is started. Or if you think the critical shutdown temperature is too low, you
can increase it by booting with thermal.crt=TEMPERATURE (it can be very
dangerous). Also AFAIK when the trip point is reached the message is
broadcasted on the netlink. Theoretically the acpid daemon could be configured
to react to such messages and to lower the cpufreq max frequency. This is async
event, so still better than periodical polling by cpuspeed. I could try to
prepare some example acpid config if you are interested. But all are
workarounds for broken HW.

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Jack Reed  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |MODIFIED
              Flags|                            |needinfo?(jskarvad@redhat.c
                   |                            |om)

--- Comment #3 from Jack Reed  ---
(In reply to comment #2)
> >
>
> All are built-in and get selected automatically, so the text is obsoleted.
> So the "3.1 Procedure" should go away. The command:
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> is useful and could be moved to 3.2.2 introduction, or maybe to 3.2
> procedure. Or just reuse/modify the text from the RHEL guide.
>
> Also all governors are built-in, so preamble for 3.2 procedure is not right.

Thanks Jaroslav, but I'm unsure of what to edit. If I'm removing "If a specific
governor is not listed as available for your CPU" because those governors are
built in, then the whole step is redundant because it says to use modprobe to
enable a governor that is listed as unavailable for your CPU. If all governors
are listed as available, then I assume the modprobe command is unnecessary, in
which case the second step, which enables the governor, is all that's needed.
Should I delete the first step?

Note that because I am updating this section to incorporate the cpupower
command as we discussed, then this second step to enable the governor will use
"cpupower frequency-info --governors"

The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
you've asked to be retained has also been replaced, by "cpupower frequency-info
--policy".

I just want to be sure that this is acceptable and you don't actually want the
existing cat and echo commands to be retained despite the emphasis on cpupower.
> >
>
> Everything is built-in in the kernel. The "important admon" should go away,
> the right module should be autoselected by kernel.

No problem - deleted.
> >
>
> Right, it gone. AFAIK there is currently no replacement (I pointed this out
> in the past, but such scenarios are very rare and to be honest this is the
> way how it shouldn't be done).

Great, OK. I've removed the sentence "This governor is normally used in
conjunction with the cpuspeed daemon" from 3.2.1.

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Jaroslav Škarvada  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|needinfo?(jskarvad@redhat.c |
                   |om)                         |

--- Comment #4 from Jaroslav Škarvada  ---
(In reply to comment #3)
> Thanks Jaroslav, but I'm unsure of what to edit. If I'm removing "If a
> specific governor is not listed as available for your CPU" because those
> governors are built in, then the whole step is redundant because it says to
> use modprobe to enable a governor that is listed as unavailable for your
> CPU. If all governors are listed as available, then I assume the modprobe
> command is unnecessary, in which case the second step, which enables the
> governor, is all that's needed. Should I delete the first step?

Yes, please delete the first step (about modprobe).
> Note that because I am updating this section to incorporate the cpupower
> command as we discussed, then this second step to enable the governor will
> use "cpupower frequency-info --governors"

Great, I hardly follow all the changes :). But your substitution command is not
correct.
"cpupower frequency-info --governors" will show all available governors, but
enable the specific governor by:
"cpupower frequency-set --governor GOVERNOR" or simply by "cpupower
frequency-set -g GOVERNOR". This will change governer on all cores (CPUs). You
can also modify governor on specific core only (if supported by HW) by using
the -c switch.
> The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
> you've asked to be retained has also been replaced, by "cpupower
> frequency-info --policy".

OK, no problem, just be consistent.
> I just want to be sure that this is acceptable and you don't actually want
> the existing cat and echo commands to be retained despite the emphasis on
> cpupower.

The admon box from RHEL guide that very briefly noted that there are also the
sysfs "echo/cat" alternatives is enough.

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

--- Comment #5 from Jack Reed  ---
(In reply to comment #4)
> Yes, please delete the first step (about modprobe).

Sure, done. I've removed Procedure 3.1 as per Comment 2 and the first step from
Procedure 3.2. This has effectively stripped that section down to the two
commands.
> >
>
> Great, I hardly follow all the changes :). But your substitution command is
> not correct.
> "cpupower frequency-info --governors" will show all available governors, but
> enable the specific governor by:
> "cpupower frequency-set --governor GOVERNOR" or simply by "cpupower
> frequency-set -g GOVERNOR". This will change governer on all cores (CPUs).
> You can also modify governor on specific core only (if supported by HW) by
> using the -c switch.

And also this: I've added an example command to explain the -c switch.

And oops - that was a typo with frequency-info. I had distinguished them
properly in the XML but not here in Comment 3.
> > The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
> > you've asked to be retained has also been replaced, by "cpupower
> > frequency-info --policy".
>
> OK, no problem, just be consistent.
> > I just want to be sure that this is acceptable and you don't actually want
> > the existing cat and echo commands to be retained despite the emphasis on
> > cpupower.
>
> The admon box from RHEL guide that very briefly noted that there are also
> the sysfs "echo/cat" alternatives is enough.

Great, OK. All is well then. Thanks Jaroslav.

The commits can be viewed here:

For the removal of the procedures -
http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=...

For the addition of -c -
http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=...

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

--- Comment #6 from Jack Reed  ---
(In reply to comment #4)
> Yes, please delete the first step (about modprobe).

Sure, done. I've removed Procedure 3.1 as per Comment 2 and the first step from
Procedure 3.2. This has effectively stripped that section down to the two
commands and...
> >
>
> Great, I hardly follow all the changes :). But your substitution command is
> not correct.
> "cpupower frequency-info --governors" will show all available governors, but
> enable the specific governor by:
> "cpupower frequency-set --governor GOVERNOR" or simply by "cpupower
> frequency-set -g GOVERNOR". This will change governer on all cores (CPUs).
> You can also modify governor on specific core only (if supported by HW) by
> using the -c switch.

... this: I've also added an example command to explain the -c switch.

And oops - that was a typo with frequency-info. I had distinguished them
properly in the XML but not here in Comment 3.
> > The command "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" that
> > you've asked to be retained has also been replaced, by "cpupower
> > frequency-info --policy".
>
> OK, no problem, just be consistent.
> > I just want to be sure that this is acceptable and you don't actually want
> > the existing cat and echo commands to be retained despite the emphasis on
> > cpupower.
>
> The admon box from RHEL guide that very briefly noted that there are also
> the sysfs "echo/cat" alternatives is enough.

Great, OK. All is well then. Thanks Jaroslav.

The commits can be viewed here:

For the removal of the procedures -
http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=...

For the addition of -c -
http://git.fedorahosted.org/cgit/docs/power-management-guide.git/commit/?id=...

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

[Red Hat Bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Simon Green  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|[e-mail]            |[e-mail]

[Bug 832179] Power management guide is wrong for frequency scaling in Fedora 17

https://bugzilla.redhat.com/show_bug.cgi?id=832179

Bugzilla account termination  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|[e-mail]          |[e-mail]