Henrique de Moraes Holschuh wrote:
> Please run sh -x /etc/init.d/cpufreqd stop >/tmp/out.txt 2>&1, hit
> CTRL+C when it hangs, and look at the log (/tmp/out.txt) to see WHERE
> it hung...
io:/home/sbellon# tail -17 /tmp/out.txt
+ echo -n 'Stopping CPU Frequency daemon: cpufreqd'
Stopping CPU Frequency daemon: cpufreqd+ pidofproc /usr/sbin/cpufreqd
+ local pidfile line i pids= status specified pid
++ POSIXLY_CORRECT=1
++ getopt p: /usr/sbin/cpufreqd
+ set -- -- /usr/sbin/cpufreqd
+ pidfile=
+ specified=
+ for i in '$*'
+ case $i in
+ shift
+ break
+ '[' -z '' ']'
++ basename /usr/sbin/cpufreqd
+ pidfile=/var/run/cpufreqd.pid
+ '[' -f /var/run/cpufreqd.pid ']'
+ read pid
It looks like the line
if ( pidofproc $DAEMON 2>&1 > /dev/null ) ; then
in /etc/init.d/cpufreqd is at fault. Commenting out that line (and the
associated "fi") makes the script work as intended. The function
pidofproc comes from lsb-base and indeed, there have been changes in
that area recently:
* Fix killproc() to work if signal isn't specified; also fix the
pidfile check in both killproc() and pidofproc(). (Closes: #370075)
This fix however seems to brake cpufreqd's init script.
> That said, if you use the "conservative" governor, there is no need
> to use cpufreqd at all. It does an wonderful job of it own, all in
> kernel space, and it has enough knobs (in /sys) that you can use to
> tune it to your needs.
Yes, but does the kernel configuration allow for such detailed profiles
like "performance when on AC, performance when on battery and still
over 50 %, then ondemand and when below 20 % of battery powersave"?
This is the nice thing about cpufreqd. You can even define exceptions
to general rules when certail programs are executed etc.
--
Stefan Bellon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
