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

[bugzilla at redhat.com]

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

Jaroslav Škarvada <jskarvad at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jskarvad at redhat.com
              Flags|needinfo?(jskarvad at redhat.c |
                   |om)                         |

--- Comment #2 from Jaroslav Škarvada <jskarvad at redhat.com> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.