https://bugzilla.redhat.com/show_bug.cgi?id=832179
Jaroslav Škarvada jskarvad@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jskarvad@redhat.com Flags|needinfo?(jskarvad@redhat.c | |om) |
--- Comment #2 from Jaroslav Škarvada jskarvad@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.