cpufreqd-devel Mailing List for cpufreq daemon
Brought to you by:
mattia-san
Menu
▾
▴
cpufreqd-devel — Developers list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
(8) |
Jul
(23) |
Aug
(9) |
Sep
|
Oct
(8) |
Nov
|
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
(33) |
Jun
|
Jul
(21) |
Aug
(89) |
Sep
(70) |
Oct
(10) |
Nov
(6) |
Dec
(12) |
| 2006 |
Jan
(5) |
Feb
(4) |
Mar
(9) |
Apr
(11) |
May
(3) |
Jun
(22) |
Jul
(23) |
Aug
(1) |
Sep
(8) |
Oct
|
Nov
(9) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
(13) |
Aug
(11) |
Sep
(1) |
Oct
(1) |
Nov
(11) |
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bernd R. <bb...@ri...> - 2012-04-07 13:32:07
|
Hi, This email is in response to Burt's email from March 2011. The issue that Burt reports is also documented in: https://bugs.launchpad.net/ubuntu/+source/cpufreqd/+bug/733507 There are actually two bugs in cpufreqd_acpi_battery.c: 1. acpi_battery_update() doesn't check whether a battery is open or not. This causes the segmentation fault when it tries to access closed battery attributes. 2. acpi_battery_init() doesn't know about that attribute current_now has been replaced by power_now in recent kernels. Both bugs are fixed with the patch attached to this comment. I've provided the same patch and information to the Ubuntu bug-tracker on launchpad. Cheers, Bernd |
|
From: Burt B. <bet...@gm...> - 2011-03-13 08:56:34
|
Hi, I have upgraded my kernel to 2.6.36 from 2.6.34, and cpufreqd no longer works. I think it is because cpufreqd is looking for current_now sysfs attribute, which is deprecated in favor of power_now, as described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532000 Burt |
|
From: Hugo \Bonstra\ G. <dw2...@gm...> - 2010-05-04 19:40:04
|
Add alternative syntax to config option "sensor" to specify the chip name the feature belongs to. This way, it's possible to monitor two features having the same name (e.g. temperature for each CPU core with the coretemp module). |
|
From: Martin v. G. <Mar...@gm...> - 2009-10-20 12:44:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mattia! Mattia Dongili wrote: >> http://sourceforge.net/tracker/index.php?func=detail&aid=1766838&group_id=58904&atid=489241 >> http://bugs.gentoo.org/187581 > > I'm sure I commented about it somewhere cursing myself for not having > released cpufreqd with your patch applied. I don't recall reading that comment, but I'm happy to hear you took notice in the first place. > The next release will have it, promised. I'm even gladder to hear that. Thanks!!! While you are at it: Andrew Cleveland committed a patch to support lm-sensors 3: http://sourceforge.net/tracker/index.php?func=detail&aid=2826341&group_id=58904&atid=489239 In http://bugs.gentoo.org/233481#c14 the Gentoo user Søren Færløv references that patch, and even adjusted it for cpufreqd 2.3.4. I'm using the patch myself, and so far all seems well. Would make a great addition to the next release, I guess. Greetings, Martin von Gagern -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrdsK0ACgkQRhp6o4m9dFtrTwCgmod41Hp732k9HAIjXtSSOhjA /QMAoIyg88PrmA1Y6EUwbZwZ4N5SPLR+ =o8al -----END PGP SIGNATURE----- |
|
From: Mattia D. <mal...@li...> - 2009-10-20 10:57:20
|
On Tue, Oct 20, 2009 at 12:14:08PM +0200, Martin von Gagern wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! Hi Martin! > I've submitted a patch to the SF patch tracker over two years ago. It > hasn't received even a comment yet. cpufreqd has made a number of > releases since, the patch was against 2.2.1, and still the issue > addressed by the patch remains. > > http://sourceforge.net/tracker/index.php?func=detail&aid=1766838&group_id=58904&atid=489241 > http://bugs.gentoo.org/187581 I'm sure I commented about it somewhere cursing myself for not having released cpufreqd with your patch applied. The next release will have it, promised. Cheers -- mattia :wq! |
|
From: Martin v. G. <Mar...@gm...> - 2009-10-20 10:14:34
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I've submitted a patch to the SF patch tracker over two years ago. It hasn't received even a comment yet. cpufreqd has made a number of releases since, the patch was against 2.2.1, and still the issue addressed by the patch remains. http://sourceforge.net/tracker/index.php?func=detail&aid=1766838&group_id=58904&atid=489241 http://bugs.gentoo.org/187581 The break if a CPU_ALL rule does not match breaks only the inner loop, but does not leave the if, so that an ALL rule will always end up just after the inner loop and thus always return MATCH. There are basically two possible solutions; either replace the break by a goto or have the loop counter checked afterwards. I chose the latter for this patch, as many people avoid goto. My patch also fixes a minor issue where negative numbers are printed in some log messages for CPU_ALL and CPU_ANY. Greetings, Martin von Gagern -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrdjW8ACgkQRhp6o4m9dFucpACghXB/EzoxmO7Gl+LlLFMDp7fT Xg4AnRr/BNGzhHX1c50K0KyRmbons0X+ =/CxO -----END PGP SIGNATURE----- |
|
From: Mattia D. <mal...@li...> - 2008-12-24 12:55:45
|
On Tue, Dec 23, 2008 at 07:57:00PM +0100, Stefan Bühler wrote: > The problem is that check_timeout is reset after the first battery got > updated, so the values for the second battery are never read. > > This results in status->value == NULL, and strncmp segfaults. > > The solution is to update check_timeout after all battery values are updated. excellent, thanks -- mattia :wq! |
|
From: Stefan B. <stb...@we...> - 2008-12-23 18:57:22
|
The problem is that check_timeout is reset after the first battery got
updated, so the values for the second battery are never read.
This results in status->value == NULL, and strncmp segfaults.
The solution is to update check_timeout after all battery values are updated.
kind regards
Stefan
---
diff -r -u -b cpufreqd-2.3.3/src/cpufreqd_acpi_battery.c cpufreqd-2.3.3.new/src/cpufreqd_acpi_battery.c
--- cpufreqd-2.3.3/src/cpufreqd_acpi_battery.c 2008-08-23 05:52:47.000000000 +0200
+++ cpufreqd-2.3.3.new/src/cpufreqd_acpi_battery.c 2008-12-23 19:39:18.850501003 +0100
@@ -325,7 +325,6 @@
/* if check_timeout is expired */
if (check_timeout <= 0) {
- check_timeout = acpi_config.battery_update_interval;
if (read_battery(&info[i]) == 0)
n_read++;
else
@@ -365,6 +364,11 @@
#endif
} /* end info loop */
+ /* check_timeout is global for all batteries, so update it after all batteries got updated */
+ if (check_timeout <= 0) {
+ check_timeout = acpi_config.battery_update_interval;
+ }
+
/* calculates medium battery life between all batteries */
if (total_capacity > 0)
avg_battery_level = 100 * (total_remaining / (double)total_capacity);
|
|
From: tehownt t. <te...@gm...> - 2008-11-08 12:49:26
|
Ok the double_check option seems to work fine, I get around 10 seconds of these:
cpufreqd_set_profile : Profile "Powersave High" set for CPU0
cpufreqd_set_profile : I haven't been able to set the chosen
policy for CPU0.
I set 2401000-800000-ondemand
System says 800000-800000-ondemand
cpufreqd_loop : Cannot set policy, Rule unchanged ("AC Rule").
but in the end it seems to be able to change it:
cpufreqd_set_profile : Profile "Powersave High" set for CPU0
cpufreqd_set_profile : Policy correctly set 2401000-800000-ondemand
cpufreqd_set_profile : Profile "Powersave High" set for CPU1
cpufreqd_set_profile : Policy correctly set 2401000-800000-ondemand
alarm_handler : Caught ALARM signal (Alarm clock).
It's not perferct but for what I need, it's quite OK ;)
So I hope they get that bug fixed in future kernels but in the mean
time I'll use the double_check option, nice from you to have thought
about this feature ;)
Thanks again for taking your time helping me, I hope this log will
provide someone with help at some point in time !
Gracie Mille !
On Sat, Nov 8, 2008 at 7:43 AM, tehownt tehownt <te...@gm...> wrote:
> On Sat, Nov 8, 2008 at 7:41 AM, tehownt tehownt <te...@gm...> wrote:
>> Yes I don't think I have a typo in the config file, and I'm pretty
>> sure you're right that the laptop requires to "settle" before being
>> able to change to ondemand 800/2.4, I've tried to mimic the cpufreqd
>> behaviour I wanted using basic .sh scripts in /etc/acpi/battery.d/ and
>> /etc/acpi/ac.d/ which called cpufreq -d 800000 -u 2400000 -g ondemand
>> and I wasn't able to change the file scaling_max_freq right after I
>> unplugged the laptop around 10 seconds according to what I've noticed.
>> So I did a loop, reading the file and calling cpufreq until it had the
>> right value, it sortof worked but while doing so I used inotify in
>> order to monitor scaling_max_freq file access and noticed wierd things
>> for instance double modification to scaling_max_freq when the AC was
>> unplugged and some process (which I can't identify) reading
>> scaling_max_freq in loop forever when I replugged the AC.
>>
>> So I'll try the double_check option, but the more I'm searching, the
>> more it seems to be a problem with cpufreq and the kernel modules in
>> itself resulting in a file access race conditions of some sort...
>>
>>
>> On Sat, Nov 8, 2008 at 2:25 AM, Mattia Dongili <mal...@li...> wrote:
>>> On Sat, Nov 08, 2008 at 04:07:18PM +0900, Mattia Dongili wrote:
>>>> On Fri, Nov 07, 2008 at 07:05:24AM -0500, tehownt tehownt wrote:
>>> ...
>>>> > close(3) = 0
>>>> > open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq", O_WRONLY) = 3
>>>> > write(3, "800000", 6) = 6
>>>> > close(3) = 0
>>>> > open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_WRONLY) = 3
>>>> > write(3, "ondemand", 8) = 8
>>>> > close(3) = 0
>>>> > write(1, "cpufreqd_set_profile : Profi"..., 65) = 65
>>>> > open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq", O_RDONLY) = 3
>>>> > read(3, "800000\n", 254) = 7
>>>> > close(3) = 0
>>>> > open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq", O_WRONLY) = 3
>>>> > write(3, "2400000", 7) = 7
>>>>
>>>> and this too, which leads to:
>>>> parse_config_profile : [Profile] "Powersave High" MAX is 2400000, MIN is 800000
>>>
>>> hell no!
>>> 2400000 is actually an acceptable value:
>>>
>>> scaling_available_frequencies:
>>> 2401000 2400000 2000000 1600000 1200000 800000
>>>
>>> out of ideas for now. One thing: if you try the entire process by hand,
>>> does it work? i.e: with cpufreqd stopped run
>>> for i in `seq 0 1` ; do cpufreq-set -c $i -g ondemand --min 800000 --max 2400000 ; done ; cpufreq-info
>>> after replugging the laptop.
>>> I remember there were some user reports about laptops that required
>>> settling for a few seconds before the kernel was able to actually
>>> change the freq/voltage.
>>> --
>>> mattia
>>> :wq!
>>>
>>
>
|
|
From: tehownt t. <te...@gm...> - 2008-11-08 12:43:41
|
On Sat, Nov 8, 2008 at 7:41 AM, tehownt tehownt <te...@gm...> wrote:
> Yes I don't think I have a typo in the config file, and I'm pretty
> sure you're right that the laptop requires to "settle" before being
> able to change to ondemand 800/2.4, I've tried to mimic the cpufreqd
> behaviour I wanted using basic .sh scripts in /etc/acpi/battery.d/ and
> /etc/acpi/ac.d/ which called cpufreq -d 800000 -u 2400000 -g ondemand
> and I wasn't able to change the file scaling_max_freq right after I
> unplugged the laptop around 10 seconds according to what I've noticed.
> So I did a loop, reading the file and calling cpufreq until it had the
> right value, it sortof worked but while doing so I used inotify in
> order to monitor scaling_max_freq file access and noticed wierd things
> for instance double modification to scaling_max_freq when the AC was
> unplugged and some process (which I can't identify) reading
> scaling_max_freq in loop forever when I replugged the AC.
>
> So I'll try the double_check option, but the more I'm searching, the
> more it seems to be a problem with cpufreq and the kernel modules in
> itself resulting in a file access race conditions of some sort...
>
>
> On Sat, Nov 8, 2008 at 2:25 AM, Mattia Dongili <mal...@li...> wrote:
>> On Sat, Nov 08, 2008 at 04:07:18PM +0900, Mattia Dongili wrote:
>>> On Fri, Nov 07, 2008 at 07:05:24AM -0500, tehownt tehownt wrote:
>> ...
>>> > close(3) = 0
>>> > open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq", O_WRONLY) = 3
>>> > write(3, "800000", 6) = 6
>>> > close(3) = 0
>>> > open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_WRONLY) = 3
>>> > write(3, "ondemand", 8) = 8
>>> > close(3) = 0
>>> > write(1, "cpufreqd_set_profile : Profi"..., 65) = 65
>>> > open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq", O_RDONLY) = 3
>>> > read(3, "800000\n", 254) = 7
>>> > close(3) = 0
>>> > open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq", O_WRONLY) = 3
>>> > write(3, "2400000", 7) = 7
>>>
>>> and this too, which leads to:
>>> parse_config_profile : [Profile] "Powersave High" MAX is 2400000, MIN is 800000
>>
>> hell no!
>> 2400000 is actually an acceptable value:
>>
>> scaling_available_frequencies:
>> 2401000 2400000 2000000 1600000 1200000 800000
>>
>> out of ideas for now. One thing: if you try the entire process by hand,
>> does it work? i.e: with cpufreqd stopped run
>> for i in `seq 0 1` ; do cpufreq-set -c $i -g ondemand --min 800000 --max 2400000 ; done ; cpufreq-info
>> after replugging the laptop.
>> I remember there were some user reports about laptops that required
>> settling for a few seconds before the kernel was able to actually
>> change the freq/voltage.
>> --
>> mattia
>> :wq!
>>
>
|
|
From: Mattia D. <mal...@li...> - 2008-11-08 07:25:45
|
On Sat, Nov 08, 2008 at 04:07:18PM +0900, Mattia Dongili wrote:
> On Fri, Nov 07, 2008 at 07:05:24AM -0500, tehownt tehownt wrote:
...
> > close(3) = 0
> > open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq", O_WRONLY) = 3
> > write(3, "800000", 6) = 6
> > close(3) = 0
> > open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_WRONLY) = 3
> > write(3, "ondemand", 8) = 8
> > close(3) = 0
> > write(1, "cpufreqd_set_profile : Profi"..., 65) = 65
> > open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq", O_RDONLY) = 3
> > read(3, "800000\n", 254) = 7
> > close(3) = 0
> > open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq", O_WRONLY) = 3
> > write(3, "2400000", 7) = 7
>
> and this too, which leads to:
> parse_config_profile : [Profile] "Powersave High" MAX is 2400000, MIN is 800000
hell no!
2400000 is actually an acceptable value:
scaling_available_frequencies:
2401000 2400000 2000000 1600000 1200000 800000
out of ideas for now. One thing: if you try the entire process by hand,
does it work? i.e: with cpufreqd stopped run
for i in `seq 0 1` ; do cpufreq-set -c $i -g ondemand --min 800000 --max 2400000 ; done ; cpufreq-info
after replugging the laptop.
I remember there were some user reports about laptops that required
settling for a few seconds before the kernel was able to actually
change the freq/voltage.
--
mattia
:wq!
|
|
From: Mattia D. <mal...@li...> - 2008-11-08 07:07:24
|
On Fri, Nov 07, 2008 at 07:05:24AM -0500, tehownt tehownt wrote:
> I've used strace in order to get more details on the execution hoping
> to find something...
...
> write(1, "cpufreqd_loop : New R"..., 75) = 75
> open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq", O_RDONLY) = 3
> read(3, "800000\n", 254) = 7
> close(3) = 0
> open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq", O_WRONLY) = 3
> write(3, "2400000", 7) = 7
this looks wrong
> close(3) = 0
> open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq", O_WRONLY) = 3
> write(3, "800000", 6) = 6
> close(3) = 0
> open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_WRONLY) = 3
> write(3, "ondemand", 8) = 8
> close(3) = 0
> write(1, "cpufreqd_set_profile : Profi"..., 65) = 65
> open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq", O_RDONLY) = 3
> read(3, "800000\n", 254) = 7
> close(3) = 0
> open("/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq", O_WRONLY) = 3
> write(3, "2400000", 7) = 7
and this too, which leads to:
parse_config_profile : [Profile] "Powersave High" MAX is 2400000, MIN is 800000
It looks like you have a typo in your config file. And I have a bug in
cpufreqd when trying to validate the frequencies.
I'll see what I can do, in the meantime you can fix your config file and
you should be ok.
BTW: you may want to switch on the 'double_check' parameter in the
configuration general section for a bit just to make sure all is working
ok. Cpufreqd will re-read the values written to /sys and verify they
correspond to the expected values.
Let me know
--
mattia
:wq!
|
|
From: tehownt t. <te...@gm...> - 2008-11-07 12:05:30
|
I've used strace in order to get more details on the execution hoping
to find something...
On Thu, Nov 6, 2008 at 5:40 PM, tehownt tehownt <te...@gm...> wrote:
> I managed to compile and install version 005, same problem.
>
> I launched the daemon with the AC OFF (values were correctly set) then
> plugged it, and unplugged it (values were then locked at 800000),
> output attached.
>
> Thanks again for your time !
>
>
>
> On Thu, Nov 6, 2008 at 5:28 PM, tehownt tehownt <te...@gm...> wrote:
>> Thanks for the follow-up, sorry for the delayed answer I had limited
>> acces to my mail today.
>>
>> It's funny that the new 2.3.3-3 logging has an error because when I
>> did the -V7 command with the 2.3.3-1 version I didn't have such errors
>> in the log:
>>
>> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
>> cpufreqd_set_profile : Profile "Powersave High" set for CPU0
>> cpufreqd_set_profile : Profile "Powersave High" set for CPU1
>> event_wait : processor CPU0 00000080 0000000 (32)
>> alarm_handler : Caught ALARM signal (Alarm clock).
>>
>> eventhough the frequencies still were stuck at 800-800 ondemand.
>>
>> But I also noticed that, if I restart the daemon while the AC is OFF,
>> it sometimes manages to get it right to 800000-2400000-ondemand
>> (attached the log too)...
>>
>>
>> Regarding cpufrequtils version, I had these installed:
>>
>> cpufrequtils 002-7.2
>> libcpufreq0 002-7.2
>>
>> I found some builds for 004-2 which I installed, but without much sucess...
>>
>> It removed the errors in the log though (full log attached).
>>
>> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
>> cpufreqd_set_profile : Profile "Powersave High" set for CPU0
>> cpufreqd_set_profile : Profile "Powersave High" set for CPU1
>> event_wait : processor CPU0 00000080 0000000 (32)
>> alarm_handler : Caught ALARM signal (Alarm clock).
>> cpufreqd_loop : Current time is: 1226009471::769134
>>
>> But didn't change the frequencies correctly, still stuck at
>> 800000-800000-ondemand...
>>
>> I'll have to search more in order to get the 005 version of
>> cpufrequtils since it's not build for ubuntu yet, and it wasn't
>> compiling straight through when I tried.
>>
>> Thanks !
>>
>> On Thu, Nov 6, 2008 at 8:13 AM, Mattia Dongili <mal...@li...> wrote:
>>> On Thu, Nov 06, 2008 at 07:52:41AM -0500, tehownt tehownt wrote:
>>> ...
>>>> I followed your advice and installed a 2.3.3-3 Ubuntu .deb but without
>>>> luck, at least it removed the /energy_* debug output.
>>>>
>>>> I've attached the log from 2.3.3-3 in which I've plugged/unplugged the
>>>> laptop multiple times, I really am clueless as to why the frequency
>>>> gets locked at 800mhz because everything seems to work fine...
>>>
>>> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
>>> cpufreqd_set_profile : Couldn't set profile "Powersave High" set for cpu0 (2400000-800000-ondemand)
>>> cpufreqd_loop : Cannot set policy, Rule unchanged ("AC Rule").
>>>
>>> this is the culprit. Now,why is this happening... I have no idea.
>>> Actually there was a problem related to libcpufreq a few months ago.
>>> The latest cpufrequtils/libcpufreq is 005, what do you have?
>>>
>>> Best,
>>> --
>>> mattia
>>> :wq!
>>>
>>
>
|
|
From: tehownt t. <te...@gm...> - 2008-11-06 22:40:40
|
I managed to compile and install version 005, same problem.
I launched the daemon with the AC OFF (values were correctly set) then
plugged it, and unplugged it (values were then locked at 800000),
output attached.
Thanks again for your time !
On Thu, Nov 6, 2008 at 5:28 PM, tehownt tehownt <te...@gm...> wrote:
> Thanks for the follow-up, sorry for the delayed answer I had limited
> acces to my mail today.
>
> It's funny that the new 2.3.3-3 logging has an error because when I
> did the -V7 command with the 2.3.3-1 version I didn't have such errors
> in the log:
>
> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
> cpufreqd_set_profile : Profile "Powersave High" set for CPU0
> cpufreqd_set_profile : Profile "Powersave High" set for CPU1
> event_wait : processor CPU0 00000080 0000000 (32)
> alarm_handler : Caught ALARM signal (Alarm clock).
>
> eventhough the frequencies still were stuck at 800-800 ondemand.
>
> But I also noticed that, if I restart the daemon while the AC is OFF,
> it sometimes manages to get it right to 800000-2400000-ondemand
> (attached the log too)...
>
>
> Regarding cpufrequtils version, I had these installed:
>
> cpufrequtils 002-7.2
> libcpufreq0 002-7.2
>
> I found some builds for 004-2 which I installed, but without much sucess...
>
> It removed the errors in the log though (full log attached).
>
> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
> cpufreqd_set_profile : Profile "Powersave High" set for CPU0
> cpufreqd_set_profile : Profile "Powersave High" set for CPU1
> event_wait : processor CPU0 00000080 0000000 (32)
> alarm_handler : Caught ALARM signal (Alarm clock).
> cpufreqd_loop : Current time is: 1226009471::769134
>
> But didn't change the frequencies correctly, still stuck at
> 800000-800000-ondemand...
>
> I'll have to search more in order to get the 005 version of
> cpufrequtils since it's not build for ubuntu yet, and it wasn't
> compiling straight through when I tried.
>
> Thanks !
>
> On Thu, Nov 6, 2008 at 8:13 AM, Mattia Dongili <mal...@li...> wrote:
>> On Thu, Nov 06, 2008 at 07:52:41AM -0500, tehownt tehownt wrote:
>> ...
>>> I followed your advice and installed a 2.3.3-3 Ubuntu .deb but without
>>> luck, at least it removed the /energy_* debug output.
>>>
>>> I've attached the log from 2.3.3-3 in which I've plugged/unplugged the
>>> laptop multiple times, I really am clueless as to why the frequency
>>> gets locked at 800mhz because everything seems to work fine...
>>
>> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
>> cpufreqd_set_profile : Couldn't set profile "Powersave High" set for cpu0 (2400000-800000-ondemand)
>> cpufreqd_loop : Cannot set policy, Rule unchanged ("AC Rule").
>>
>> this is the culprit. Now,why is this happening... I have no idea.
>> Actually there was a problem related to libcpufreq a few months ago.
>> The latest cpufrequtils/libcpufreq is 005, what do you have?
>>
>> Best,
>> --
>> mattia
>> :wq!
>>
>
|
|
From: tehownt t. <te...@gm...> - 2008-11-06 22:28:11
|
Thanks for the follow-up, sorry for the delayed answer I had limited
acces to my mail today.
It's funny that the new 2.3.3-3 logging has an error because when I
did the -V7 command with the 2.3.3-1 version I didn't have such errors
in the log:
cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
cpufreqd_set_profile : Profile "Powersave High" set for CPU0
cpufreqd_set_profile : Profile "Powersave High" set for CPU1
event_wait : processor CPU0 00000080 0000000 (32)
alarm_handler : Caught ALARM signal (Alarm clock).
eventhough the frequencies still were stuck at 800-800 ondemand.
But I also noticed that, if I restart the daemon while the AC is OFF,
it sometimes manages to get it right to 800000-2400000-ondemand
(attached the log too)...
Regarding cpufrequtils version, I had these installed:
cpufrequtils 002-7.2
libcpufreq0 002-7.2
I found some builds for 004-2 which I installed, but without much sucess...
It removed the errors in the log though (full log attached).
cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
cpufreqd_set_profile : Profile "Powersave High" set for CPU0
cpufreqd_set_profile : Profile "Powersave High" set for CPU1
event_wait : processor CPU0 00000080 0000000 (32)
alarm_handler : Caught ALARM signal (Alarm clock).
cpufreqd_loop : Current time is: 1226009471::769134
But didn't change the frequencies correctly, still stuck at
800000-800000-ondemand...
I'll have to search more in order to get the 005 version of
cpufrequtils since it's not build for ubuntu yet, and it wasn't
compiling straight through when I tried.
Thanks !
On Thu, Nov 6, 2008 at 8:13 AM, Mattia Dongili <mal...@li...> wrote:
> On Thu, Nov 06, 2008 at 07:52:41AM -0500, tehownt tehownt wrote:
> ...
>> I followed your advice and installed a 2.3.3-3 Ubuntu .deb but without
>> luck, at least it removed the /energy_* debug output.
>>
>> I've attached the log from 2.3.3-3 in which I've plugged/unplugged the
>> laptop multiple times, I really am clueless as to why the frequency
>> gets locked at 800mhz because everything seems to work fine...
>
> cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
> cpufreqd_set_profile : Couldn't set profile "Powersave High" set for cpu0 (2400000-800000-ondemand)
> cpufreqd_loop : Cannot set policy, Rule unchanged ("AC Rule").
>
> this is the culprit. Now,why is this happening... I have no idea.
> Actually there was a problem related to libcpufreq a few months ago.
> The latest cpufrequtils/libcpufreq is 005, what do you have?
>
> Best,
> --
> mattia
> :wq!
>
|
|
From: Mattia D. <mal...@li...> - 2008-11-06 13:13:20
|
On Thu, Nov 06, 2008 at 07:52:41AM -0500, tehownt tehownt wrote:
...
> I followed your advice and installed a 2.3.3-3 Ubuntu .deb but without
> luck, at least it removed the /energy_* debug output.
>
> I've attached the log from 2.3.3-3 in which I've plugged/unplugged the
> laptop multiple times, I really am clueless as to why the frequency
> gets locked at 800mhz because everything seems to work fine...
cpufreqd_loop : New Rule ("AC Off - Medium Battery"), applying.
cpufreqd_set_profile : Couldn't set profile "Powersave High" set for cpu0 (2400000-800000-ondemand)
cpufreqd_loop : Cannot set policy, Rule unchanged ("AC Rule").
this is the culprit. Now,why is this happening... I have no idea.
Actually there was a problem related to libcpufreq a few months ago.
The latest cpufrequtils/libcpufreq is 005, what do you have?
Best,
--
mattia
:wq!
|
|
From: tehownt t. <te...@gm...> - 2008-11-06 12:59:58
|
First I want to thank you for taking the time to help me and for developing cpufreqd, its ease of configuration and flexibility makes it one of the most useful application for anyone using some frequency scaling (if someone could just develop a GTK frontend to the config file, I'm sure it'll get included by default in most distros). I followed your advice and installed a 2.3.3-3 Ubuntu .deb but without luck, at least it removed the /energy_* debug output. I've attached the log from 2.3.3-3 in which I've plugged/unplugged the laptop multiple times, I really am clueless as to why the frequency gets locked at 800mhz because everything seems to work fine... I hope you can find useful info in the output. Thanks again ! --teht On Thu, Nov 6, 2008 at 6:24 AM, Mattia Dongili <mal...@li...> wrote: > Hello, > > On Wed, Nov 05, 2008 at 11:57:02PM -0500, tehownt tehownt wrote: >> So here's the little story/mess: >> >> I have that XPS M1330 running cpufreq successfully in Ubuntu 8.10 >> kernel 2.6.27-7-generic with ondemand, performance, userspace and >> conservative governors available. >> >> I've also got cpufreq_acpi and speedstep-centrino modules correctly loaded. > > you don't need both, cpufreq_acpi is the one you want generally > >> >> I've been using a simple cpufreq 'ondemand' setup that comes with >> ubuntu stock without any problems, ( i.e. choses between 800mhz and >> 2.4ghz depending on load) but I wanted to make it more "intelligent", >> i.e. switch from a 'performance' running at 2.4ghz when plugged in and >> when running on battery, keep the original 'ondemand' (800000-2400000) >> mode. >> >> I thus installed cpufreqd 2.3.3-1 (from the repos), reading somewhere > > so you're using a debian based distro, there is a 2.3.3-3 in debian at > least that fixes a couple of bugs, one of which is the energy_* thing > you mentioned. > > ... >> i.e. the file /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq >> and scaling_min_freq contain '800000' and cpufreq-info states that >> both cores are in 'ondemand' governor mode that choses between 800mhz >> and 800mhz. > > hmmmm... > can you run cpufreqd with > cpufreqd -D -V7 > and check what it's doing? That is the best way to debug it, there will > be a lot of output (feel free to send it here) it will give me some > clues about what cpurfeqd is doing wrong even though there is no > apparent error. > > Thanks. > PS: I also read the -user ml, just I didn't have time to reply this > morning. > -- > mattia > :wq! > |
|
From: Mattia D. <mal...@li...> - 2008-11-06 11:24:45
|
Hello, On Wed, Nov 05, 2008 at 11:57:02PM -0500, tehownt tehownt wrote: > So here's the little story/mess: > > I have that XPS M1330 running cpufreq successfully in Ubuntu 8.10 > kernel 2.6.27-7-generic with ondemand, performance, userspace and > conservative governors available. > > I've also got cpufreq_acpi and speedstep-centrino modules correctly loaded. you don't need both, cpufreq_acpi is the one you want generally > > I've been using a simple cpufreq 'ondemand' setup that comes with > ubuntu stock without any problems, ( i.e. choses between 800mhz and > 2.4ghz depending on load) but I wanted to make it more "intelligent", > i.e. switch from a 'performance' running at 2.4ghz when plugged in and > when running on battery, keep the original 'ondemand' (800000-2400000) > mode. > > I thus installed cpufreqd 2.3.3-1 (from the repos), reading somewhere so you're using a debian based distro, there is a 2.3.3-3 in debian at least that fixes a couple of bugs, one of which is the energy_* thing you mentioned. ... > i.e. the file /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq > and scaling_min_freq contain '800000' and cpufreq-info states that > both cores are in 'ondemand' governor mode that choses between 800mhz > and 800mhz. hmmmm... can you run cpufreqd with cpufreqd -D -V7 and check what it's doing? That is the best way to debug it, there will be a lot of output (feel free to send it here) it will give me some clues about what cpurfeqd is doing wrong even though there is no apparent error. Thanks. PS: I also read the -user ml, just I didn't have time to reply this morning. -- mattia :wq! |
|
From: tehownt t. <te...@gm...> - 2008-11-06 04:57:08
|
So here's the little story/mess:
I have that XPS M1330 running cpufreq successfully in Ubuntu 8.10
kernel 2.6.27-7-generic with ondemand, performance, userspace and
conservative governors available.
I've also got cpufreq_acpi and speedstep-centrino modules correctly loaded.
I've been using a simple cpufreq 'ondemand' setup that comes with
ubuntu stock without any problems, ( i.e. choses between 800mhz and
2.4ghz depending on load) but I wanted to make it more "intelligent",
i.e. switch from a 'performance' running at 2.4ghz when plugged in and
when running on battery, keep the original 'ondemand' (800000-2400000)
mode.
I thus installed cpufreqd 2.3.3-1 (from the repos), reading somewhere
that it was more efficient than laptop_mode scripts and I thus checked
that every section related to CPU control in laptop_mode config files
was commented out.
I used a very simple cpufreqd configuration (/etc/cpufreqd.conf) as
follows, which is used by the daemon ran at startup (init.d):
[General]
pidfile=/var/run/cpufreqd.pid
poll_interval=2
verbosity=5
[/General]
[Profile]
name=Performance High
minfreq=2401000
maxfreq=2401000
policy=performance
[/Profile]
[Profile]
name=Performance Low
minfreq=1600000
maxfreq=1600000
policy=performance
[/Profile]
[Profile]
name=Powersave High
policy=ondemand
maxfreq=2400000
minfreq=800000
[/Profile]
[Profile]
name=Powersave Low
maxfreq=1600000
minfreq=800000
policy=ondemand
[/Profile]
[Rule]
name=AC Rule
ac=on # (on/off)
profile=Performance High
[/Rule]
[Rule]
name=AC Off - Medium Battery
ac=off # (on/off)
profile=Powersave High
[/Rule]
[Rule]
name=CPU Too Hot
acpi_temperature=65-100
cpu_interval=50-100
profile=Performance Low
[/Rule]
Now for the best part of this:
cpufreqd has absolutely no problem detecting the AC on/off (eventhough
it 'craps' the daemon.log with battery status access errors (searching
energy_full and energy_now instead of charge_full and charge_now, but
this should have been corrected in 2.3.3)) and it even manages to
switch between different profiles, but when switching to the
'ondemand' profiles the CPU frequency is locked at 800mhz.
i.e. the file /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
and scaling_min_freq contain '800000' and cpufreq-info states that
both cores are in 'ondemand' governor mode that choses between 800mhz
and 800mhz.
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0 1
hardware limits: 800 MHz - 2.40 GHz
available frequency steps: 2.40 GHz, 2.40 GHz, 2.00 GHz, 1.60 GHz,
1.20 GHz, 800 MHz
available cpufreq governors: ondemand, conservative, powersave,
userspace, performance
current policy: frequency should be within 800 MHz and 800 MHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
All my cpufreq settings seems to be fine, here's the contents of the
files located in [I]/sys/devices/system/cpu/cpu*/cpufreq/[/I] :
affected_cpus:
0 1
cpuinfo_max_freq:
2401000
cpuinfo_min_freq:
800000
related_cpus:
0 1
scaling_available_frequencies:
2401000 2400000 2000000 1600000 1200000 800000
scaling_available_governors:
ondemand conservative powersave userspace performance
scaling_cur_freq:
800000
scaling_driver:
acpi-cpufreq
scaling_governor:
ondemand
scaling_max_freq:
2401000
scaling_min_freq:
800000
scaling_setspeed:
<unsupported>
I've spent a lot of time trying to understand what the problem is,
I've even tried to add an exec_post parameter in order to modify
scaling_max_freq to 2401000 (or 2400000) at the end of the
cpufreqd.conf profile, and according to the daemon.log it runs fine
(exit 0)
exec_post=echo 2401000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
or
exec_post=cpufreq-set -g ondemand -u 2400000
but it doesn't change squat in the file (I've double-checked
monitoring file modifications with fileschanged) eventhough it works
when I do it manually.
The strange thing is that if I restart the cpufreqd daemon when the
laptop is unplugged, sometimes (yes only sometimes) the
scaling_max_freq file is correctly set to 2400000, then if I replug
the laptop it correctly switches to performance-2400000-2400000, but
as soon as I unplug it it falls back into the ondemand-800000-800000
eventhough the config specifies otherwise.
I haven't been able to set ondemand with max to 2400000 and min to
either 1200000,1600000 or 2400000 for that matter.
Here's a cat /proc/cpuinfo for the record:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz
stepping : 6
cpu MHz : 2401.000
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr sse4_1 lahf_lm ida
bogomips : 4787.99
clflush size : 64
power management:
and an lsmod | grep -i freq
acpi_cpufreq 15500 1
cpufreq_ondemand 14988 0
cpufreq_stats 13188 0
cpufreq_conservative 14600 0
freq_table 12672 3 acpi_cpufreq,cpufreq_ondemand,cpufreq_stats
cpufreq_powersave 9856 0
cpufreq_userspace 11396 0
processor 42156 4 acpi_cpufreq,thermal
I've also tried to switch the /etc/default/cpufreqd config so as to
use centrino-speedstep without success, and raising the verbosity
level in cpufreqd doesn't help since there's no obvious 'error' per se
and all the Profiles are apparently correctly configured (verified
using cpufreqd-get).
Has anyone any idea of what that mess is about ?
Someone on ubuntu forums has suggested that I use powernowd, but I
don't like this option since the powernowd project isn't that much
maintainted anymore and the configuration is somewhat flaky compared
to the extensive options of cpufreqd.
|
|
From: Mattia D. <mat...@us...> - 2008-10-05 02:24:35
|
Update of /cvsroot/cpufreqd/sources2/src In directory ddv4jf1.ch3.sourceforge.com:/tmp/cvs-serv31403/src Modified Files: cpufreqd_acpi.c Log Message: Fix segfault on start when reading a class device with no attributes. Index: cpufreqd_acpi.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -d -r1.8 -r1.9 --- cpufreqd_acpi.c 31 Aug 2008 01:17:25 -0000 1.8 +++ cpufreqd_acpi.c 5 Oct 2008 02:24:12 -0000 1.9 @@ -246,8 +246,8 @@ /* read `clsname` devices */ devs = sysfs_get_class_devices(cls); - if (!cls) { - clog(LOG_INFO, "class '%s' not found (%s)\n", clsname, + if (!devs) { + clog(LOG_INFO, "class device '%s' not found (%s)\n", clsname, strerror(errno)); sysfs_close_class(cls); return -1; |
|
From: Mattia D. <mat...@us...> - 2008-08-31 01:17:30
|
Update of /cvsroot/cpufreqd/sources2/src In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv5102/src Modified Files: cpufreqd_acpi.c cpufreqd_acpi_ac.c cpufreqd_acpi_ac.h cpufreqd_acpi_battery.c cpufreqd_acpi_battery.h cpufreqd_acpi_event.c cpufreqd_acpi_event.h cpufreqd_acpi_temperature.c cpufreqd_acpi_temperature.h cpufreqd_cpu.c cpufreqd_programs.c Log Message: - make the acpi thermal comaptible with kernels >2.6.25 when the type has changed from "ACPI Thermal Zone" to "acpitz" - squash some converison warnings (gcc 4.3 is very loud about it) Index: cpufreqd_acpi_event.h =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_event.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- cpufreqd_acpi_event.h 12 May 2006 18:08:40 -0000 1.1 +++ cpufreqd_acpi_event.h 31 Aug 2008 01:17:25 -0000 1.2 @@ -23,8 +23,8 @@ */ int acpi_event_conf (const char *key, const char *value); -int acpi_event_init (void); -int acpi_event_exit (void); +short int acpi_event_init (void); +short int acpi_event_exit (void); int acpi_event_lock (void); int acpi_event_unlock (void); int is_event_pending(void); Index: cpufreqd_acpi_ac.h =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_ac.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- cpufreqd_acpi_ac.h 12 May 2006 18:08:40 -0000 1.1 +++ cpufreqd_acpi_ac.h 31 Aug 2008 01:17:25 -0000 1.2 @@ -18,8 +18,8 @@ */ -int acpi_ac_init(void); -int acpi_ac_exit(void); +short int acpi_ac_init(void); +short int acpi_ac_exit(void); int acpi_ac_update(void); int acpi_ac_parse(const char *ev, void **obj); int acpi_ac_evaluate(const void *s); Index: cpufreqd_cpu.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_cpu.c,v retrieving revision 1.18 retrieving revision 1.19 diff -u -d -r1.18 -r1.19 --- cpufreqd_cpu.c 4 Jul 2006 16:49:05 -0000 1.18 +++ cpufreqd_cpu.c 31 Aug 2008 01:17:25 -0000 1.19 @@ -98,8 +98,8 @@ char *cpu_cmd = NULL; char wcards[4]; unsigned int cpu_num = 0; - unsigned int min = 0; - unsigned int max = 0; + int min = 0; + int max = 0; float nice_scale = 0.0f; struct cpu_interval *ret = NULL, **temp_cint = NULL; struct cpufreqd_info *cinfo = get_cpufreqd_info(); Index: cpufreqd_acpi_ac.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_ac.c,v retrieving revision 1.18 retrieving revision 1.19 diff -u -d -r1.18 -r1.19 --- cpufreqd_acpi_ac.c 21 Jul 2008 07:56:28 -0000 1.18 +++ cpufreqd_acpi_ac.c 31 Aug 2008 01:17:25 -0000 1.19 @@ -34,7 +34,7 @@ #define UNPLUGGED 0 static struct sysfs_attribute *mains[64]; -static unsigned short ac_state; +static int ac_state; static int ac_dir_num; static int mains_callback(struct sysfs_class_device *cdev) { @@ -56,7 +56,7 @@ * * test if AC dirs are present */ -int acpi_ac_init(void) { +short int acpi_ac_init(void) { find_class_device(POWER_SUPPLY, AC_TYPE, mains_callback); if (ac_dir_num <= 0) { @@ -66,7 +66,7 @@ return 0; } -int acpi_ac_exit(void) { +short int acpi_ac_exit(void) { while (--ac_dir_num >= 0) put_attribute(mains[ac_dir_num]); clog(LOG_INFO, "exited.\n"); Index: cpufreqd_acpi_event.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_event.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -d -r1.8 -r1.9 --- cpufreqd_acpi_event.c 27 Jul 2008 07:46:35 -0000 1.8 +++ cpufreqd_acpi_event.c 31 Aug 2008 01:17:25 -0000 1.9 @@ -202,7 +202,7 @@ /* Launch the thread that will wait for acpi events */ -int acpi_event_init (void) { +short int acpi_event_init (void) { int ret = 0; event_pending = 1; @@ -216,7 +216,7 @@ return 0; } -int acpi_event_exit (void) { +short int acpi_event_exit (void) { int ret = 0; if (event_thread) { Index: cpufreqd_acpi.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi.c,v retrieving revision 1.7 retrieving revision 1.8 diff -u -d -r1.7 -r1.8 --- cpufreqd_acpi.c 27 Jul 2008 07:47:42 -0000 1.7 +++ cpufreqd_acpi.c 31 Aug 2008 01:17:25 -0000 1.8 @@ -27,10 +27,10 @@ #include "cpufreqd_acpi_event.h" #include "cpufreqd_acpi_temperature.h" -static short acpi_ac_failed; -static short acpi_batt_failed; -static short acpi_ev_failed; -static short acpi_temp_failed; +static short int acpi_ac_failed; +static short int acpi_batt_failed; +static short int acpi_ev_failed; +static short int acpi_temp_failed; struct acpi_configuration acpi_config; /* @@ -83,7 +83,7 @@ } static int acpi_exit (void) { - int ret = 0; + short int ret = 0; if (!acpi_ac_failed) { clog(LOG_DEBUG, "Closing AC\n"); ret |= acpi_ac_exit(); Index: cpufreqd_acpi_battery.h =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_battery.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- cpufreqd_acpi_battery.h 12 May 2006 18:08:40 -0000 1.1 +++ cpufreqd_acpi_battery.h 31 Aug 2008 01:17:25 -0000 1.2 @@ -17,8 +17,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -int acpi_battery_init(void); -int acpi_battery_exit(void); +short int acpi_battery_init(void); +short int acpi_battery_exit(void); int acpi_battery_parse(const char *ev, void **obj); int acpi_battery_evaluate(const void *s); int acpi_battery_update(void); Index: cpufreqd_programs.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_programs.c,v retrieving revision 1.19 retrieving revision 1.20 diff -u -d -r1.19 -r1.20 --- cpufreqd_programs.c 31 Jul 2006 19:57:57 -0000 1.19 +++ cpufreqd_programs.c 31 Aug 2008 01:17:25 -0000 1.20 @@ -97,11 +97,11 @@ if (cmp > 0) { insert_tnode(&((*t)->right), c); (*t)->right->parent = *t; - (*t)->right->height = (*t)->height+1; + (*t)->right->height = (short unsigned)((*t)->height + 1); } else if (cmp < 0) { insert_tnode(&((*t)->left), c); (*t)->left->parent = *t; - (*t)->left->height = (*t)->height+1; + (*t)->left->height = (short unsigned)((*t)->height + 1); } else { (*t)->used++; } Index: cpufreqd_acpi_temperature.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_temperature.c,v retrieving revision 1.20 retrieving revision 1.21 diff -u -d -r1.20 -r1.21 --- cpufreqd_acpi_temperature.c 21 Jul 2008 07:56:28 -0000 1.20 +++ cpufreqd_acpi_temperature.c 31 Aug 2008 01:17:25 -0000 1.21 @@ -26,9 +26,11 @@ #include "cpufreqd_acpi.h" #include "cpufreqd_acpi_temperature.h" -#define THERMAL "thermal" -#define THERMAL_TYPE "ACPI thermal zone" -#define THERMAL_TEMP "temp" +#define THERMAL "thermal" +#define THERMAL_TYPE "acpitz" +/* the below is for kernels <= 2.6.25 */ +#define THERMAL_TYPE_ALT "ACPI thermal zone" +#define THERMAL_TEMP "temp" struct thermal_zone { int temperature; @@ -77,9 +79,12 @@ * test if ATZ dirs are present and read their * path for usage when parsing rules */ -int acpi_temperature_init(void) +short int acpi_temperature_init(void) { find_class_device(THERMAL, THERMAL_TYPE, atz_callback); + /* try with the old type name */ + if (atz_dir_num <= 0) + find_class_device(THERMAL, THERMAL_TYPE_ALT, atz_callback); if (atz_dir_num <= 0) { clog(LOG_INFO, "No thermal zones found\n"); return -1; @@ -89,7 +94,7 @@ return 0; } -int acpi_temperature_exit(void) +short int acpi_temperature_exit(void) { while (--atz_dir_num >= 0) { put_attribute(atz_list[atz_dir_num].temp); Index: cpufreqd_acpi_battery.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_battery.c,v retrieving revision 1.24 retrieving revision 1.25 diff -u -d -r1.24 -r1.25 --- cpufreqd_acpi_battery.c 23 Aug 2008 03:58:17 -0000 1.24 +++ cpufreqd_acpi_battery.c 31 Aug 2008 01:17:25 -0000 1.25 @@ -173,7 +173,7 @@ * we can easily rescan for availability later (see acpi_battery_update * when an event is pending) */ -int acpi_battery_init(void) { +short int acpi_battery_init(void) { int i; find_class_device(POWER_SUPPLY, BATTERY_TYPE, &clsdev_callback); @@ -194,7 +194,7 @@ bat_dir_num > 1 ? "ies" : "y"); return 0; } -int acpi_battery_exit(void) { +short int acpi_battery_exit(void) { /* also reset values since this is called on pending * acpi events to rescan batteries */ Index: cpufreqd_acpi_temperature.h =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_temperature.h,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- cpufreqd_acpi_temperature.h 12 May 2006 18:08:40 -0000 1.1 +++ cpufreqd_acpi_temperature.h 31 Aug 2008 01:17:25 -0000 1.2 @@ -16,8 +16,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -int acpi_temperature_init(void); -int acpi_temperature_exit(void) ; +short int acpi_temperature_init(void); +short int acpi_temperature_exit(void) ; int acpi_temperature_parse(const char *ev, void **obj); int acpi_temperature_evaluate(const void *s); int acpi_temperature_update(void); |
|
From: Mattia D. <mat...@us...> - 2008-08-23 04:19:14
|
Update of /cvsroot/cpufreqd/sources2 In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv29770 Modified Files: ChangeLog Log Message: update with recent changes Index: ChangeLog =================================================================== RCS file: /cvsroot/cpufreqd/sources2/ChangeLog,v retrieving revision 1.20 retrieving revision 1.21 diff -u -d -r1.20 -r1.21 --- ChangeLog 9 Aug 2008 06:32:31 -0000 1.20 +++ ChangeLog 23 Aug 2008 04:19:11 -0000 1.21 @@ -1,3 +1,7 @@ +version 2.3.3 +------------- +* support reading the acpi battery status from charge_* attributes + version 2.3.2 ------------- * Fix damn stupid bug that made cpufreq spin forever if there is |
|
From: Mattia D. <mat...@us...> - 2008-08-23 04:17:50
|
Update of /cvsroot/cpufreqd/sources2 In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv29058 Modified Files: configure.in Log Message: prepare for 2.3.3 upload Index: configure.in =================================================================== RCS file: /cvsroot/cpufreqd/sources2/configure.in,v retrieving revision 1.25 retrieving revision 1.26 diff -u -d -r1.25 -r1.26 --- configure.in 9 Aug 2008 06:32:31 -0000 1.25 +++ configure.in 23 Aug 2008 04:17:46 -0000 1.26 @@ -1,5 +1,5 @@ # Process this file with autoconf to produce a configure script. -AC_INIT([cpufreqd],[2.3.2],[mal...@li...], [cpufreqd]) +AC_INIT([cpufreqd],[2.3.3],[mal...@li...], [cpufreqd]) AC_CANONICAL_TARGET([]) AM_INIT_AUTOMAKE(1.8 dist-bzip2 foreign) |
|
From: Mattia D. <mat...@us...> - 2008-08-23 04:17:19
|
Update of /cvsroot/cpufreqd/sources2/manpages In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv29042/manpages Modified Files: cpufreqd-get.1 Log Message: remove ellipses to silence groff Index: cpufreqd-get.1 =================================================================== RCS file: /cvsroot/cpufreqd/sources2/manpages/cpufreqd-get.1,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- cpufreqd-get.1 21 Nov 2006 21:31:00 -0000 1.6 +++ cpufreqd-get.1 23 Aug 2008 04:17:15 -0000 1.7 @@ -44,7 +44,7 @@ Governor: ondemand Min freq: 1000000 Max freq: 1333000 -... + .fi .LP .B "LIST_APPLIED_PROFILES" |
|
From: Mattia D. <mat...@us...> - 2008-08-23 03:58:23
|
Update of /cvsroot/cpufreqd/sources2/src In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv20847/src Modified Files: cpufreqd_acpi_battery.c Log Message: From: Goedson Teixeira Paixao <go...@de...> BTS: http://bugs.debian.org/495655 Package: cpufreqd Version: 2.3.2-2 Severity: important cpufreqd fails to read battery info on my system because it tries to read files named "energy_full" and "energy_now" while the files are named "charge_full" and "charge_now". Index: cpufreqd_acpi_battery.c =================================================================== RCS file: /cvsroot/cpufreqd/sources2/src/cpufreqd_acpi_battery.c,v retrieving revision 1.23 retrieving revision 1.24 diff -u -d -r1.23 -r1.24 --- cpufreqd_acpi_battery.c 9 Aug 2008 06:28:18 -0000 1.23 +++ cpufreqd_acpi_battery.c 23 Aug 2008 03:58:17 -0000 1.24 @@ -31,6 +31,8 @@ #define BATTERY_TYPE "Battery" #define ENERGY_FULL "energy_full" #define ENERGY_NOW "energy_now" +#define CHARGE_FULL "charge_full" +#define CHARGE_NOW "charge_now" #define PRESENT "present" #define STATUS "status" #define CURRENT_NOW "current_now" @@ -123,11 +125,20 @@ binfo->open = 1; binfo->energy_full = get_class_device_attribute(binfo->cdev, ENERGY_FULL); - if (!binfo->energy_full) - return -1; + if (!binfo->energy_full) { + /* try the "charge_full" name */ + binfo->energy_full = get_class_device_attribute(binfo->cdev, + CHARGE_FULL); + if (!binfo->energy_full) + return -1; + } binfo->energy_now = get_class_device_attribute(binfo->cdev, ENERGY_NOW); - if (!binfo->energy_now) - return -1; + if (!binfo->energy_now) { + /* try the "charge_now" name */ + binfo->energy_now = get_class_device_attribute(binfo->cdev, CHARGE_NOW); + if (!binfo->energy_now) + return -1; + } binfo->present = get_class_device_attribute(binfo->cdev, PRESENT); if (!binfo->present) return -1; @@ -306,8 +317,8 @@ continue; } - /* if battery not present skip to the next one */ - if (!info[i].is_present || info[i].capacity <= 0) { + /* if battery not open or not present skip to the next one */ + if (!info[i].open || !info[i].is_present || info[i].capacity <= 0) { continue; } clog(LOG_INFO, "%s - present\n", info[i].cdev->name); |
2 messages has been excluded from this view by a project administrator.
