cpufreqd-user Mailing List for cpufreq daemon
Brought to you by:
mattia-san
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
2005 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2006 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(4) |
Oct
(12) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(7) |
Dec
(4) |
2009 |
Jan
|
Feb
(2) |
Mar
(7) |
Apr
(8) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
From: Yclept N. <orb...@gm...> - 2012-10-13 04:29:07
|
I've patched the double_check feature to be slightly more verbose as per the attached file. Resultant output: $ cpufreqd -D -V6 ... update_rule_scores : Rule "AC Off" score: 101% update_rule_scores : Rule "Suspend2Ram" score: 51% acpi_ac_update : ac_adapter is on-line acpi_battery_update : Re-scanning available batteries acpi_battery_exit : exited. find_class_device : found /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC find_class_device : found /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 get_class_device_attribute: couldn't open /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/energy_full (No such file or directory) get_class_device_attribute: found charge_full - path /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/charge_full get_class_device_attribute: found charge_now - path /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/charge_now get_class_device_attribute: found current_now - path /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/current_now get_class_device_attribute: found present - path /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/present get_class_device_attribute: found status - path /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/status acpi_battery_init : found 1 Battery acpi_battery_update : BAT0 - present acpi_battery_update : battery life for BAT0 is 92% acpi_battery_update : average battery life 92% acpi_temperature_update : temperature for thermal_zone0 is 43.5C acpi_temperature_update : temperature average is 43.5C update_rule_scores : Rule "AC On" score: 101% update_rule_scores : Rule "AC Off" score: 0% update_rule_scores : Rule "Suspend2Ram" score: 0% cpufreqd_set_profile : Profile "Performance High" set for CPU0 ==================== analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1000 MHz - 1.83 GHz available frequency steps: 1.83 GHz, 1.33 GHz, 1000 MHz available cpufreq governors: ondemand, performance current policy: frequency should be within 1.83 GHz and 1.83 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.83 GHz (asserted by call to hardware). boost state support: Supported: no Active: no ==================== check->max: 1833000 check->min: 1833000 check->governor: 159583944 ==================== new_profile->policy.max: 1833000 new_profile->policy.min: 1833000 new_profile->policy.governor: 159619296 cpufreqd_set_profile : Policy correctly set 1833000-1833000-performance cpufreqd_set_profile : Profile "Performance High" set for CPU1 ==================== analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1000 MHz - 1.83 GHz available frequency steps: 1.83 GHz, 1.33 GHz, 1000 MHz available cpufreq governors: ondemand, performance current policy: frequency should be within 1.83 GHz and 1.83 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1.83 GHz (asserted by call to hardware). boost state support: Supported: no Active: no ==================== check->max: 1833000 check->min: 1833000 check->governor: 159583944 ==================== new_profile->policy.max: 1833000 new_profile->policy.min: 1833000 new_profile->policy.governor: 159619296 cpufreqd_set_profile : Policy correctly set 1833000-1833000-performance ... update_rule_scores : Rule "AC On" score: 101% However a second or two afterwards: $ cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 10.0 us. hardware limits: 1000 MHz - 1.83 GHz available frequency steps: 1.83 GHz, 1.33 GHz, 1000 MHz available cpufreq governors: ondemand, performance current policy: frequency should be within 1000 MHz and 1.83 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz. boost state support: Supported: no Active: no This behavior ties back to my original email. Clearly there is some external impulse that forces a frequency stepping of 1GHz-1.83GHz with the "ondemand" governor upon detecting a new AC adapter, and this interferes in the operation of cpufreqd. I've tried tracking this down and my best guess is the default programming of the CPUFREQ kernel subsystem driver. Any ideas here? P.S. Maybe waiting the maximum transition latency (10.0 us) could help? |
From: Yclept N. <orb...@gm...> - 2012-10-13 03:45:06
|
P.S. Since I lack familiarity, you should most-likely ensure that the previous patch doesn't modify/break the logic of the cpufreqd acpi battery plugin. |
From: Yclept N. <orb...@gm...> - 2012-10-13 03:29:54
|
Here is another patch that prevents a double free and a NULL-dereference condition in cpufreqd_acpi_battery.c. It needs to be applied after the previous cpufreqd_acpi_battery.c.patch. Summary for double-free: After freeing the (struct battery_info) attributes the close_battery() function failed to set them to NULL. In a certain condition this would cause a double-free: 0] static array variable "info" initialized to NULL. 1] Function acpi_battery_update() called. This (partially) fills the variable "info" (acpi_battery_init) 2] Function acpi_battery_update() called again. This frees the array variable "info" (acpi_battery_exit) but does not set member elements to NULL. 3] Function acpi_battery_init() called. 4] Function open_battery() called but returns -1 (error) before all the attributes have been set 5] Error triggers the function close_battery(). This function attempts to free all non-NULL attributes to the variable "info". When it encounters the first attribute that was unable to be set in the previous step, a double free is triggered. Summary for NULL-dereference: 0] The function acpi_battery_init() frees all battery attributes (close_battery) when the previous function (open_battery) fails. Thus not all batteries indexed by the variable "bat_dir_num" have valid attributes. 1] The NULL-dereference occurs when the function acpi_batter_update(), while looping through all batteries indexed by the variable "bat_dir_num", attempts to access the attribute "info[i].present" without first checking if the battery is open (info[i].open). In the meantime I've encountered an error with the double_check feature incorrectly claiming success while in fact the frequencies and governors are utterly unchanged, as seen by "cpupower frequency-info". This is rather serious as it occurs quite often. |
From: Yclept N. <orb...@gm...> - 2012-10-11 22:27:58
|
P.S. My distribution[1] (Arch Linux) also uses an additional patch (probably from Gentoo) which I believe is required for newer kernels. I haven't reviewed it, but since it works I am including it here in case you are interested. [1] http://aur.archlinux.org/packages.php?ID=43484 |
From: Yclept N. <orb...@gm...> - 2012-10-11 22:21:56
|
Wow this has been a really long time and I'm sorry I haven't got back to you any sooner. I hadn't tested the patch till now, so four the past four! years this bug has been niggling around the back of my subconscious. Anway I just wanted to thank you for the work, and let you know that the patch fixes half of the problem. Just so you don't have to reread the old emails, here is a quick recap of the situation: The frequency steps of my laptop range from 1GHz to 1.83GHz. When I disconnect my AC adapter the BIOS enforces a lower frequency limit of 1GHz for a 'settling' period of around 15 seconds. That can be read in: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit For that small time period, regardless of the governor, the cpu frequency is restricted to the range of 1Ghz-1Ghz. After these 15-or-so seconds have elapsed, the BIOS limit is lifted, and the cpu frequency upper limit is restored to its previous setting, as read in: /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq The value of "scaling_max_freq", once the bios limit is lifted, is changed without any outside input. No cpufreqd or acpid daemon running, and without manually setting the frequency. Most likely the CPUFREQ subsystem driver sets "scaling_max_freq" to the value of "cpuinfo_max_freq" once the bios limit is lifted. This looks like: 1GHz-1.83GHz-performance -> (disconnect AC Adapter) 1GHz-1GHz-performance -> (approx. 15 seconds later) 1GHz-1.83GHz-performance Of course, the above is only a generalization. Every now and then for reasons I have no idea, the BIOS limit is ignored: scaling_min_freq < bios_limit < scaling_max_freq (when this happens cpufreqd works fine) And sometimes even the scaling_max_freq range is ignored, though I've only noticed this when the BIOS enforces a lower limit scaling_min_frequency < (bios_limit==scaling_max_freq) < cpuinfo_cur_freq (when this happens cpufreqd develops aforementioned problem) The point of all this is that the patch only works when double_check=1 in cpufreqd.conf. When the cpufreqd_set_profile function is unable to set the profile, it does not return an error unless double_check=1. Therefore the current rule won't be cleared(NULL) if double_check=0. Normally this would be OK, because once the BIOS limit is lifted the requested frequency range is set anyway. However for some strange reason cpufreqd seems to inhibit this behavior, and this is why the patch is only half-complete: when double_check=0 and cpufreqd is running (and only when), the BIOS limit is never lifted. Anyway with double_check=1 cpufreqd now works fine for me, so if this is some obscure kernel bug that's impossible to fix, dont sweat it ;) I've also attached three patchs; the first makes cpufreqd compatible with cpupower, while the second fixes a whitespace problem in the patch you originally sent me and the third addresses a buffer overflow with the "-f" option. The last patch requires a bit more explanation. The function realpath() [main.c:read_args():316] will store a null-terminated string in the variable "configuration->config_file" per limits in "/usr/include/linux/limits.h": #define NAME_MAX 255 #define PATH_MAX 4096 In config_parser.h:55, "config_file" is an array of MAX_PATH_LEN bytes. MAX_PATH_LEN is defined as 512 bytes in cpufreqd.h. Thus, if the MAX_PATH_LEN < (length of configuration file path) < PATH_MAX and the individual path components are less than NAME_MAX length, a buffer overflow will be triggered. At the very least this clobbers the variable configuration->pidfile and any subsequent variables, and at the worst presents a security problem. Furthermore, when compiling cpufreqd with a GCC optimization level greater than -O0, a buffer overflow is immediately triggered for the option "-f" irrespective of the argument to that option. This is because realpath() will copy PATH_MAX bytes into the output buffer regardless of the length of the input path. Since PATH_MAX is less than MAX_PATH_LEN, this immediately causes a buffer overflow. The simplest solution would be to change in cpufreqd.h #define MAX_PATH_LEN PATH_MAX However as per the BUGS section of "man realpath(3)" this approach is not guaranteed to be suitable. So the solution I've chosen is to pass a NULL pointer and let realpath() allocate an output buffer of the appropriate size. This depends on the POSIX.1-2008 specification. Thanks a lot, Yclept Nemo |
From: Mattia D. <mal...@li...> - 2012-02-09 22:05:29
|
On Wed, Feb 08, 2012 at 10:10:52PM -0500, Carlos Andres Perilla Rozo wrote: > > Hi there, > I've used cpufreqd by 2 years and recently I've bought a laptop with a > quad-core chip, so I tried to control only one CPU by changing the > cpufreqd.conf. I want to do that because many programs load only one yes, you can by assigning profiles to specific cpus in your rule configuration. From the manpage (man cpufreqd.conf): [Rule] ... profile A character string that must match a [Profile] section name property. A Rule can also associate profiles to single cpus providing a list of the format CPU%d:%s separated by semicolons (";"), e.g.: profile=CPU0:profile0;CPU1:profile1. The keyword "ALL" can be used to indicate that all cpus must have the profile applied. The "ALL" keyword has a lower priority so you can mix up CPU%d and ALL meaning that if no specific profile is supplied, the "ALL" one will be used. [REQUIRED] then the CPU plugin can be used to monitor individual cores rather than all at the same time. > core at a time so why to change all CPU speeds. Can I change > individually and automatically the CPU speed one at a time? managing separate profiles on separate cores may snd up being quite tricky so if your requirements are not too complex you may want to try to use the ondemand governor on all cpus and that should already take care of only scaling up the loaded core. Thanks! -- mattia :wq! |
From: Carlos A. P. R. <kon...@ho...> - 2012-02-09 03:10:58
|
Hi there, I've used cpufreqd by 2 years and recently I've bought a laptop with a quad-core chip, so I tried to control only one CPU by changing the cpufreqd.conf. I want to do that because many programs load only one core at a time so why to change all CPU speeds. Can I change individually and automatically the CPU speed one at a time? Thanks a lot Carlos |
From: Ioannis G. <ga...@gm...> - 2011-10-11 23:02:24
|
Hi! I am using cpufreqd-2.4.2 under gentoo with kernel 3.1-rc8 / glibc 2.13-r2 If I just type 'cpufreqd -D' it works but gives some warnings -- BAT0/energy_full (No such file or directory) If I specify the -f option (with any file as argument, existent or not), I get this: *** buffer overflow detected ***: cpufreqd terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x7f440758aec7] /lib64/libc.so.6(+0xead20)[0x7f4407588d20] /lib64/libc.so.6(+0xeb39b)[0x7f440758939b] cpufreqd(main+0x7be)[0x403cde] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f44074bcebd] cpufreqd[0x402ec9] ======= Memory map: ======== 00400000-0040b000 r-xp 00000000 08:01 230291 /usr/sbin/cpufreqd 0060a000-0060b000 r--p 0000a000 08:01 230291 /usr/sbin/cpufreqd 0060b000-0060c000 rw-p 0000b000 08:01 230291 /usr/sbin/cpufreqd 015ea000-0160b000 rw-p 00000000 00:00 0 [heap] 7f4407288000-7f440729d000 r-xp 00000000 08:01 1451983 /lib64/libgcc_s.so.1 7f440729d000-7f440749c000 ---p 00015000 08:01 1451983 /lib64/libgcc_s.so.1 7f440749c000-7f440749d000 r--p 00014000 08:01 1451983 /lib64/libgcc_s.so.1 7f440749d000-7f440749e000 rw-p 00015000 08:01 1451983 /lib64/libgcc_s.so.1 7f440749e000-7f4407620000 r-xp 00000000 08:01 245411 /lib64/libc-2.13.so 7f4407620000-7f440781f000 ---p 00182000 08:01 245411 /lib64/libc-2.13.so 7f440781f000-7f4407823000 r--p 00181000 08:01 245411 /lib64/libc-2.13.so 7f4407823000-7f4407824000 rw-p 00185000 08:01 245411 /lib64/libc-2.13.so 7f4407824000-7f4407829000 rw-p 00000000 00:00 0 7f4407829000-7f440782e000 r-xp 00000000 08:01 229920 /usr/lib64/libcpufreq.so.0.0.0 7f440782e000-7f4407a2d000 ---p 00005000 08:01 229920 /usr/lib64/libcpufreq.so.0.0.0 7f4407a2d000-7f4407a2e000 r--p 00004000 08:01 229920 /usr/lib64/libcpufreq.so.0.0.0 7f4407a2e000-7f4407a2f000 rw-p 00005000 08:01 229920 /usr/lib64/libcpufreq.so.0.0.0 7f4407a2f000-7f4407a31000 r-xp 00000000 08:01 243262 /lib64/libdl-2.13.so 7f4407a31000-7f4407c31000 ---p 00002000 08:01 243262 /lib64/libdl-2.13.so 7f4407c31000-7f4407c32000 r--p 00002000 08:01 243262 /lib64/libdl-2.13.so 7f4407c32000-7f4407c33000 rw-p 00003000 08:01 243262 /lib64/libdl-2.13.so 7f4407c33000-7f4407c52000 r-xp 00000000 08:01 245261 /lib64/ld-2.13.so 7f4407e24000-7f4407e27000 rw-p 00000000 00:00 0 7f4407e51000-7f4407e52000 rw-p 00000000 00:00 0 7f4407e52000-7f4407e53000 r--p 0001f000 08:01 245261 /lib64/ld-2.13.so 7f4407e53000-7f4407e54000 rw-p 00020000 08:01 245261 /lib64/ld-2.13.so 7f4407e54000-7f4407e55000 rw-p 00000000 00:00 0 7fff3cfa0000-7fff3cfc1000 rw-p 00000000 00:00 0 [stack] 7fff3cfff000-7fff3d000000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted |
From: Mattia D. <mal...@li...> - 2009-04-23 12:55:53
|
On Wed, Apr 22, 2009 at 11:06:12AM -0700, Scott Stubbs wrote: > Well if you haven't found this already, use the ebuild here to get the > latest stable version. > http://bugs.gentoo.org/show_bug.cgi?id=233481 Argh... it looks like I forgot to include the cpu_all patch... :P 2.3.5 is due soon then thanks -- mattia :wq! |
From: Scott S. <sco...@gm...> - 2009-04-22 18:06:23
|
Well if you haven't found this already, use the ebuild here to get the latest stable version. http://bugs.gentoo.org/show_bug.cgi?id=233481 After a while if you still notice the error, increase the verbosity (change the init.d file) and then send in that info. Scott > Date: Tue, 21 Apr 2009 12:00:58 -0700 > From: cyrus <cyr...@gm...> > Subject: [Cpufreqd-user] cpufreqd-2.1.1 on Gentoo > To: cpu...@li... > Message-ID: <1240340458.3967.2@desktop> > Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed > > > I am running CPU Freq Daemon on Gentoo. The latest stable ebuild is > version 2.1.1. I am also running kernel 2.6.27.12. > > Here is my configuration file: http://pastebin.com/m380b2c > > Here is the error I get: http://pastebin.com/m6807b7fa > > Notice the issue stating that it can't switch to profile low_ondemand. > > My scaling_governors_available are: ondemand performance. > > Any help would be appreciated as once it switched to high_ondemand, it > never goes back as the scaling_min/max, etc get set to the > high_ondemand profile. > > Thanks |
From: Mattia D. <mal...@li...> - 2009-04-22 11:00:28
|
On Tue, Apr 21, 2009 at 08:45:48PM -0700, Matthew Ceroni wrote: > Couple of more questions, regarding configuration setup: > > Here are a couple of rules that I have: > > [Rule] > name=default > acpi_temperature=0-100 > cpu_interval=0-100 > profile=low_ondemand > [/Rule] > > [Rule] > name=media_center > programs=xbmc.bin > cpu_intervale=0-100 > profile=low_performance > [/Rule] > > Basically, a default rule for when nothing is running (just go to > low_ondemand profile). Whenever I start up XMBC I want it to switch to > the low_performance mode. This works, if I boot the computer it starts > in the low_ondemand profile. Once I start XBMC though, it doesn't > switch. As you can see from the output below, both rules get a score of > 101%. Shouldn't the media_center rule get a high score since it matches > more things, cpu_interval and programs? well... his should probably a different thread but anyway: - the default rule also matches acpi_temperature very likely inclrease the score. Maybe you don't have any thermal zone so this actually doesn't affect the rule score -- or your cpu is running at >100C? ;) - you have a typo in your media_center rule cpu_intervale=0-100 ^^^ At the very beginning of the log you should find some warnings about discarded directives that cpufreqd doesn't understand or your computer doesn't support. cheers -- mattia :wq! |
From: Matthew C. <mat...@gm...> - 2009-04-22 04:02:37
|
Couple of more questions, regarding configuration setup: Here are a couple of rules that I have: [Rule] name=default acpi_temperature=0-100 cpu_interval=0-100 profile=low_ondemand [/Rule] [Rule] name=media_center programs=xbmc.bin cpu_intervale=0-100 profile=low_performance [/Rule] Basically, a default rule for when nothing is running (just go to low_ondemand profile). Whenever I start up XMBC I want it to switch to the low_performance mode. This works, if I boot the computer it starts in the low_ondemand profile. Once I start XBMC though, it doesn't switch. As you can see from the output below, both rules get a score of 101%. Shouldn't the media_center rule get a high score since it matches more things, cpu_interval and programs? cpu_evaluate : CPU1 21% - min=0 max=100 scale=3.00 rule_score : Rule "default": cpu_interval matches. update_rule_scores : Rule "default" score: 101% update_rule_scores : Considering Rule "media_center" programs_evaluate : tree ptr 0x9b6a6a0 find_program : tree ptr 0x9b6a6a0 rule_score : Rule "media_center": programs matches. update_rule_scores : Rule "media_center" score: 101% update_rule_scores : Considering Rule "movie_mode" programs_evaluate : tree ptr 0x9b6aa28 find_program : tree ptr 0x9b6aa28 find_program : tree ptr 0x9b6cb80 find_program : tree ptr 0x9b6cbd8 cpu_evaluate : CPU1 user=5957 nice=0 sys=3198 calculate_cpu_usage : CPU delta_activity=43 delta_time=199 weighted_activity=9155. On 04/21/09 19:56:25, Ben Tyger wrote: > Mattia Dongili wrote: > > Hello, > > > > On Tue, Apr 21, 2009 at 12:00:58PM -0700, cyrus wrote: > > > >> I am running CPU Freq Daemon on Gentoo. The latest stable ebuild is > >> version 2.1.1. I am also running kernel 2.6.27.12. > >> > > > > but but! the latest stable cpufreqd release is 2.3.4, I mean there > have > > been a bunch of fixes in the meantime and it would be nice if you > could > > give it a go to avoid trying to fix a problem if it was already > solved. > > > > > The issue has nothing to do with cpufreqd. Cpufreqd doesn't actually > change the governors/freq. Cpufreqd is just the monitor and scheduler > for the cpufreq-set app. The cpufreq-set and cpufreq-info are apart of > the cpufrequtils ebuild. > > >> Here is my configuration file: http://pastebin.com/m380b2c > >> > >> Here is the error I get: http://pastebin.com/m6807b7fa > >> > >> Notice the issue stating that it can't switch to profile > low_ondemand. > >> > > > > increasing the verbosity usually helps in getting a better error > > description. > > > > cheers > > > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Cpufreqd-user mailing list > Cpu...@li... > https://lists.sourceforge.net/lists/listinfo/cpufreqd-user > > |
From: Mattia D. <mal...@li...> - 2009-04-22 03:56:09
|
On Tue, Apr 21, 2009 at 10:56:25PM -0400, Ben Tyger wrote: > Mattia Dongili wrote: > > Hello, > > > > On Tue, Apr 21, 2009 at 12:00:58PM -0700, cyrus wrote: > > > >> I am running CPU Freq Daemon on Gentoo. The latest stable ebuild is > >> version 2.1.1. I am also running kernel 2.6.27.12. > >> > > > > but but! the latest stable cpufreqd release is 2.3.4, I mean there have > > been a bunch of fixes in the meantime and it would be nice if you could > > give it a go to avoid trying to fix a problem if it was already solved. > > > > > The issue has nothing to do with cpufreqd. Cpufreqd doesn't actually > change the governors/freq. Cpufreqd is just the monitor and scheduler > for the cpufreq-set app. The cpufreq-set and cpufreq-info are apart of > the cpufrequtils ebuild. err... you're making some confusion here. cpufreqd _does_ change governors/freq, it monitors the system status and applies whatever policy/rule you set in the configuration file. The cpufrequtils package provides different utilities to change/view the governor/frequency settings from the command line. They don't co-operate, so if you have cpufreqd running and use cpufreq-set to change the frequency, cpufreqd will likely be confused or even override your changes if there was a rule change based on the configuration file. Hope this clarifies things a little bit. -- mattia :wq! |
From: Ben T. <ben...@ty...> - 2009-04-22 03:17:39
|
Mattia Dongili wrote: > Hello, > > On Tue, Apr 21, 2009 at 12:00:58PM -0700, cyrus wrote: > >> I am running CPU Freq Daemon on Gentoo. The latest stable ebuild is >> version 2.1.1. I am also running kernel 2.6.27.12. >> > > but but! the latest stable cpufreqd release is 2.3.4, I mean there have > been a bunch of fixes in the meantime and it would be nice if you could > give it a go to avoid trying to fix a problem if it was already solved. > > The issue has nothing to do with cpufreqd. Cpufreqd doesn't actually change the governors/freq. Cpufreqd is just the monitor and scheduler for the cpufreq-set app. The cpufreq-set and cpufreq-info are apart of the cpufrequtils ebuild. >> Here is my configuration file: http://pastebin.com/m380b2c >> >> Here is the error I get: http://pastebin.com/m6807b7fa >> >> Notice the issue stating that it can't switch to profile low_ondemand. >> > > increasing the verbosity usually helps in getting a better error > description. > > cheers > |
From: Mattia D. <mal...@li...> - 2009-04-21 23:25:33
|
Hello, On Tue, Apr 21, 2009 at 12:00:58PM -0700, cyrus wrote: > > I am running CPU Freq Daemon on Gentoo. The latest stable ebuild is > version 2.1.1. I am also running kernel 2.6.27.12. but but! the latest stable cpufreqd release is 2.3.4, I mean there have been a bunch of fixes in the meantime and it would be nice if you could give it a go to avoid trying to fix a problem if it was already solved. > Here is my configuration file: http://pastebin.com/m380b2c > > Here is the error I get: http://pastebin.com/m6807b7fa > > Notice the issue stating that it can't switch to profile low_ondemand. increasing the verbosity usually helps in getting a better error description. cheers -- mattia :wq! |
From: cyrus <cyr...@gm...> - 2009-04-21 19:17:29
|
I am running CPU Freq Daemon on Gentoo. The latest stable ebuild is version 2.1.1. I am also running kernel 2.6.27.12. Here is my configuration file: http://pastebin.com/m380b2c Here is the error I get: http://pastebin.com/m6807b7fa Notice the issue stating that it can't switch to profile low_ondemand. My scaling_governors_available are: ondemand performance. Any help would be appreciated as once it switched to high_ondemand, it never goes back as the scaling_min/max, etc get set to the high_ondemand profile. Thanks |
From: Mattia D. <mal...@li...> - 2009-03-11 12:23:34
|
On Mon, Mar 02, 2009 at 01:05:14AM +0100, Erik den Toom wrote: > That would be really great. I know the fancontrol script already has > this support, it allows the sensors to be set as (for example) > hwmon0/temp1 and hwmon1/temp1 according to the paths in > /sys/class/hwmon. In this case i need hwmon1/temp1. I implemented the label support for cpufreqd in the sensors plugin now, what I would like to add is support for addressing the sensor feature via <chip>:<feature> so that ambiguous names can be resolved uniquely. In your case you would have: it8716-isa-0290:temp1 or your label instead of 'temp1', but for now only the label is supported. I will probably add the chip name later on when I finally decide to move to libsensors4. > The reason for using cpufreqd 2.2.1 instead of 2.3: I emerged it with > gentoo. 2.3 isn't in the portage tree yet... don't ask me why. well actually I know ;) the released 2.3 is a bit buggy and you need a couple of patches to actually make it usable. Anyway, the current source is here: http://git.kamineko.org/cgi-bin/gitweb.cgi?p=cpufreqd.git;a=summary can you give it a try? You should be able to clone the repository with git clone git://git.kamineko.org/cpufreqd.git let me know if it doesn't work. thanks -- mattia :wq! |
From: Erik d. T. <os...@gm...> - 2009-03-02 00:05:17
|
That would be really great. I know the fancontrol script already has this support, it allows the sensors to be set as (for example) hwmon0/temp1 and hwmon1/temp1 according to the paths in /sys/class/hwmon. In this case i need hwmon1/temp1. The reason for using cpufreqd 2.2.1 instead of 2.3: I emerged it with gentoo. 2.3 isn't in the portage tree yet... don't ask me why. Thanks for the info! Greets, Erik den Toom 2009/3/2 Mattia Dongili <mal...@li...>: > On Sun, Mar 01, 2009 at 07:52:32PM +0100, Erik den Toom wrote: >> It is indeed possible to relabel the sensors. They do show up when i >> do a "sensors -u": >> >> ------------------------------------------ >> k8temp-pci-00c3 >> Adapter: PCI adapter >> Core0 Temp: 31.00 (temp1) >> Core1 Temp: 34.00 (temp3) >> >> it8716-isa-0290 >> Adapter: ISA adapter >> VCore: 0.99 (in0) > ... >> The one i want to use is the CPU Temp (motherboard sensor), known as >> temp1. As you can see temp1 is also the sensor name for a sensor used >> by k8temp. >> With the attached cpufreqd.conf i get the following errors in /var/log/messages: > ... >> Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : >> sensors_plugin is unable to parse this value "CPU Temp (motherboard >> sensor):0-50". Discarded >> Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! >> skipping config option "sensor" > ... >> The sensors are clearly not recognized by their labels. > > Ok, shouldn't be too difficult to add support for this in cpufreqd. And > I found one of my desktops has an it87 ISA sensor so I can reprouce and > test your issue. > ... and eventually implement support for libsensors4 :) > > I was wondering though, why cpufreqd 2.2.1 and not some 2.3 version? > > cheers > -- > mattia > :wq! > |
From: Mattia D. <mal...@li...> - 2009-03-01 23:35:25
|
On Sun, Mar 01, 2009 at 07:52:32PM +0100, Erik den Toom wrote: > It is indeed possible to relabel the sensors. They do show up when i > do a "sensors -u": > > ------------------------------------------ > k8temp-pci-00c3 > Adapter: PCI adapter > Core0 Temp: 31.00 (temp1) > Core1 Temp: 34.00 (temp3) > > it8716-isa-0290 > Adapter: ISA adapter > VCore: 0.99 (in0) ... > The one i want to use is the CPU Temp (motherboard sensor), known as > temp1. As you can see temp1 is also the sensor name for a sensor used > by k8temp. > With the attached cpufreqd.conf i get the following errors in /var/log/messages: ... > Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : > sensors_plugin is unable to parse this value "CPU Temp (motherboard > sensor):0-50". Discarded > Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! > skipping config option "sensor" ... > The sensors are clearly not recognized by their labels. Ok, shouldn't be too difficult to add support for this in cpufreqd. And I found one of my desktops has an it87 ISA sensor so I can reprouce and test your issue. ... and eventually implement support for libsensors4 :) I was wondering though, why cpufreqd 2.2.1 and not some 2.3 version? cheers -- mattia :wq! |
From: Erik d. T. <os...@gm...> - 2009-03-01 18:52:37
|
It is indeed possible to relabel the sensors. They do show up when i do a "sensors -u": ------------------------------------------ k8temp-pci-00c3 Adapter: PCI adapter Core0 Temp: 31.00 (temp1) Core1 Temp: 34.00 (temp3) it8716-isa-0290 Adapter: ISA adapter VCore: 0.99 (in0) in0_min: 0.80 (in0_min) in0_max: 1.25 (in0_max) +3.3V: 3.23 (in1) in1_min: 0.00 (in1_min) in1_max: 4.08 (in1_max) in2: 0.00 (in2) in2_min: 0.00 (in2_min) in2_max: 4.08 (in2_max) +5V: 4.68 (in3) in3_min: 0.00 (in3_min) in3_max: 6.85 (in3_max) +12V: 11.46 (in4) in4_min: 0.00 (in4_min) in4_max: 16.32 (in4_max) -12V: -16.97 (in5) in5_min: -16.97 (in5_min) in5_max: 4.01 (in5_max) -5V: -8.78 (in6) in6_min: -8.78 (in6_min) in6_max: 4.05 (in6_max) 5VSB: 4.60 (in7) in7_min: 0.00 (in7_min) in7_max: 6.85 (in7_max) VBat: 2.94 (in8) CPU Fan: 3260.00 (fan1) fan1_min: 500.00 (fan1_min) Case Fan: 2732.00 (fan2) fan2_min: 1000.00 (fan2_min) CPU Temp (motherboard sensor): 34.00 (temp1) temp1_low: -1.00 (temp1_low) temp1_over: 127.00 (temp1_over) sensor1: 3.00 (sensor1) Case Temp (motherboard sensor): 34.00 (temp2) temp2_low: -1.00 (temp2_low) temp2_over: 127.00 (temp2_over) sensor2: 4.00 (sensor2) VID: 1.08 (vid) alarms: 25616.00 (alarms) ----------------------------------------------- The one i want to use is the CPU Temp (motherboard sensor), known as temp1. As you can see temp1 is also the sensor name for a sensor used by k8temp. With the attached cpufreqd.conf i get the following errors in /var/log/messages: -------------------------------------------------------------------------------------------------------------------------------------------- Mar 1 19:41:00 atlantis cpufreqd: pmu_init : /proc/pmu/info: No such file or directory Mar 1 19:41:00 atlantis cpufreqd: apm_init : /proc/apm: No such file or directory Mar 1 19:41:00 atlantis cpufreqd: parse_config_general : Remote control enabled. Mar 1 19:41:00 atlantis cpufreqd: parse_config_general : Remote controls will be r/w for group wheel (10). Mar 1 19:41:00 atlantis cpufreqd: nforce2_post_conf : Unconfigured, exiting. Mar 1 19:41:00 atlantis cpufreqd: plugins_post_conf : Unable to configure plugin nforce2_atxp1, removing Mar 1 19:41:00 atlantis cpufreqd: acpi_battery_init : error, acpi_battery module not compiled or inserted (/proc/acpi/battery/: No such file or direc tory)? Mar 1 19:41:00 atlantis cpufreqd: acpi_battery_init : exiting. Mar 1 19:41:00 atlantis acpid: client connected from 5830[0:0] Mar 1 19:41:00 atlantis acpid: 1 client rule loaded Mar 1 19:41:00 atlantis cpufreqd: sensor_parse : feature "CPU Temp (motherboard sensor)" does not exist, try 'sensors -u' to see a full list of available feature names. Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : sensors_plugin is unable to parse this value "CPU Temp (motherboard sensor):0-50". Discarded Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! skipping config option "sensor" Mar 1 19:41:00 atlantis cpufreqd: sensor_parse : feature "CPU Temp (motherboard sensor)" does not exist, try 'sensors -u' to see a full list of available feature names. Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : sensors_plugin is unable to parse this value "CPU Temp (motherboard sensor):50-100". Discarded Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! skipping config option "sensor" Mar 1 19:41:00 atlantis cpufreqd: sensor_parse : feature "CPU Temp (motherboard sensor)" does not exist, try 'sensors -u' to see a full list of available feature names. Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : sensors_plugin is unable to parse this value "CPU Temp (motherboard sensor):50-100". Discarded Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! skipping config option "sensor" Mar 1 19:41:00 atlantis cpufreqd: sensor_parse : feature "CPU Temp (motherboard sensor)" does not exist, try 'sensors -u' to see a full list of available feature names. Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : sensors_plugin is unable to parse this value "CPU Temp (motherboard sensor):0-50". Discarded Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! skipping config option "sensor" Mar 1 19:41:00 atlantis cpufreqd: sensor_parse : feature "CPU Temp (motherboard sensor)" does not exist, try 'sensors -u' to see a full list of available feature names. Mar 1 19:41:00 atlantis cpufreqd: plugin_handle_keyword : sensors_plugin is unable to parse this value "CPU Temp (motherboard sensor):50-65". Discarded Mar 1 19:41:00 atlantis cpufreqd: parse_config_rule : WARNING! skipping config option "sensor" -------------------------------------------------------------------------------------------------------------------------------------------- The sensors are clearly not recognized by their labels. -------------------------------------------------------------------------------------------------------------------------------------------- # this is a comment # see CPUFREQD.CONF(5) manpage for a complete reference ## # General/plugins config ## [General] pidfile=/var/run/cpufreqd.pid poll_interval=2 verbosity=4 enable_remote=1 remote_group=wheel [/General] [sensors_plugin] sensors_conf=/etc/sensors.conf [/sensors_plugin] ## # Profiles ## [Profile] name=On Demand High minfreq=40% maxfreq=100% policy=ondemand [/Profile] [Profile] name=On Demand Low minfreq=20% maxfreq=80% policy=ondemand [/Profile] [Profile] name=Performance High minfreq=100% maxfreq=100% policy=performance [/Profile] [Profile] name=Performance Low minfreq=80% maxfreq=80% policy=performance [/Profile] [Profile] name=Powersave High minfreq=70% maxfreq=70% policy=powersave [/Profile] [Profile] name=Powersave Low minfreq=30% maxfreq=30% policy=powersave [/Profile] ## # Rules ## # Normal situations [Rule] name=Standard acpi_temperature=0-55 cpu_interval=ANY:0-70 profile=On Demand High [/Rule] # High load situations [Rule] name=High Load sensor=CPU Temp (motherboard sensor):0-50 cpu_interval=ANY:70-100 profile=Performance High [/Rule] # CPU Too hot! [Rule] name=Hot CPU Idle sensor=CPU Temp (motherboard sensor):50-100 cpu_interval=ANY:0-50 profile=Powersave Low [/Rule] [Rule] name=Hot CPU High Load sensor=CPU Temp (motherboard sensor):50-100 cpu_interval=ANY:50-100 profile=On Demand Low [/Rule] # use performance mode if I'm watching a movie but don't heat too much. [Rule] name=Movie Watcher programs=xine,mplayer,gmplayer sensor=CPU Temp (motherboard sensor):0-50 profile=Performance High [/Rule] [Rule] name=Movie Watcher Hot programs=xine,mplayer,gmplayer sensor=CPU Temp (motherboard sensor):50-65 profile=Performance Low [/Rule] -------------------------------------------------------------------------------------------------------------------------------------------- Greets, Erik den Toom 2009/3/1 Mattia Dongili <mal...@li...>: > On Sat, Feb 28, 2009 at 11:45:31PM +0100, Erik den Toom wrote: >> Hi everybody, >> >> I've almost got cpufreqd 2.2.1 to work now, using gentoo 2.6.28 r2. >> However, since there is an unresolved bug in my bios, my >> /proc/acpi/thermal_zone/THRM/temperature value remains fixed at 40 >> degrees C. Therefore i want to use the sensors defined at "sensors >> -u". >> There is where my problem is: since i've got two hardware monitoring >> chips (one from k8temp and one from IT8716*) i've got two variables >> named temp1. I need the one from IT8716, but how do i specify that in >> cpufreqd.conf? > > It's been a while since I last played with sensors here but you should > be able to relabel your sensors in your /etc/sensors.conf > > cheers > -- > mattia > :wq! > |
From: Mattia D. <mal...@li...> - 2009-03-01 04:30:24
|
On Sat, Feb 28, 2009 at 11:45:31PM +0100, Erik den Toom wrote: > Hi everybody, > > I've almost got cpufreqd 2.2.1 to work now, using gentoo 2.6.28 r2. > However, since there is an unresolved bug in my bios, my > /proc/acpi/thermal_zone/THRM/temperature value remains fixed at 40 > degrees C. Therefore i want to use the sensors defined at "sensors > -u". > There is where my problem is: since i've got two hardware monitoring > chips (one from k8temp and one from IT8716*) i've got two variables > named temp1. I need the one from IT8716, but how do i specify that in > cpufreqd.conf? It's been a while since I last played with sensors here but you should be able to relabel your sensors in your /etc/sensors.conf cheers -- mattia :wq! |
From: Erik d. T. <os...@gm...> - 2009-02-28 22:45:36
|
Hi everybody, I've almost got cpufreqd 2.2.1 to work now, using gentoo 2.6.28 r2. However, since there is an unresolved bug in my bios, my /proc/acpi/thermal_zone/THRM/temperature value remains fixed at 40 degrees C. Therefore i want to use the sensors defined at "sensors -u". There is where my problem is: since i've got two hardware monitoring chips (one from k8temp and one from IT8716*) i've got two variables named temp1. I need the one from IT8716, but how do i specify that in cpufreqd.conf? Thanks a lot in advance! Erik den Toom |
From: Fabio V. <fab...@gm...> - 2008-12-27 03:15:07
|
Hi everybody, I have a hot CPU problem described at http://bbs.archlinux.org/viewtopic.php?pid=469993 When I extensively use the CPU it gets so hot that the laptop shuts down automatically and I'm unable to boot for 10-15 until it cools a bit and start working again. So I decided to try setting up cpufreqd to configure it so that I can scale down cpu frequency once it get too hot. Well.. even if I think I should have everything in place and that my laptop should support cpufreq scaling just fine, I'm only able to get a discouraging "No cpufreqd socket found" message when running cpufreqd-get (with or without -l). My laptop is a Toshiba Tecra A7 equipped with a intel centrino duo 2.0 Ghz running Archlinux. Following other system informations. How can I setup cpufreqd on my laptop? Thanks, Fabio Varesano [root@gamma ~]# uname -a Linux gamma 2.6.27-ARCH #1 SMP PREEMPT Sun Dec 21 09:31:10 UTC 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [root@gamma ~]# lsmod | grep cpufreq cpufreq_stats 6916 0 cpufreq_ondemand 8588 0 acpi_cpufreq 9228 1 freq_table 5632 3 cpufreq_stats,cpufreq_ondemand,acpi_cpufreq processor 34732 4 thermal,acpi_cpufreq [root@gamma ~]# cpufreq-info cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to cp...@vg..., please. analyzing CPU 0: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 0 1 hardware limits: 1000 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz available cpufreq governors: ondemand, performance current policy: frequency should be within 1000 MHz and 2.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 2.00 GHz (asserted by call to hardware). analyzing CPU 1: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 0 1 hardware limits: 1000 MHz - 2.00 GHz available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz available cpufreq governors: ondemand, performance current policy: frequency should be within 1000 MHz and 2.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 2.00 GHz (asserted by call to hardware). |
From: engage <en...@n0...> - 2008-12-12 01:05:08
|
From: engage <en...@n0...> - 2008-12-12 00:08:37
|