Your message dated Sun, 14 Nov 2010 15:01:10 +0100
with message-id <[email protected]>
and subject line Closing
has caused the Debian Bug report #491394,
regarding acpid causes CPUfreq to be limited to 800MHz - 800Mhz
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
491394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491394
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: acpid
Version: 1.0.6-10
Severity: grave
Justification: renders package unusable
Even with hal turned off and gnome-power and all that crap not being
installed, I have up until recently had laptop-mode-tools as the sole
controller of my laptop's power management. laptop_mode is of course
controlled through /etc/acpi/actions/lm_*. Lately, something has been
limiting my CPU to 800Mhz only, when I go to battery:
AC:
> cpufreq-info | grep 'should be within'
current policy: frequency should be within 800 MHz and 2.20 GHz.
battery:
> cpufreq-info | grep 'should be within'
current policy: frequency should be within 800 MHz and 800 MHz.
The CPU governor remains on ondemand.
If I disable the calls to lm_* within the acpi directory, or if I tell
laptop_mode to not touch anything CPU related (despite it being
configged not to limit the CPU in such fashion), and even if I
uninstall it, something is still telling the CPU to limit to 800MHz.
So it's not laptop_mode. I don't have other cpufreq related tools
installed (except cpufrequtils, which doesn't run anything that might
change the governor behaviour on the fly). If I remove the acpi
directory, then the goveror is still changed. If I stop the acpid
daemon, then the govenor *isn't* changed.
As I can't see anything else being run by acpid, it must therefore be
acpi itself at fault, do you agree? Is there anything new that acpid
is doing behind our back to change the CPU goveronr?
Below, I show the order of events - first I generate an strace output
on acpi, tail the strace output once things have settled down, unplug
the laptop and terminate the logging once acpi has started polling for
the next acpi event:
0-0-12:49:26, Fri Jul 18 r...@dirac:/etc/acpi (bash)
51307,131> strace -o /tmp/acpi.txt -f /etc/init.d/acpid restart
....
0-0-13:03:26, Fri Jul 18 r...@dirac:/home/tconnors (bash)
> cpufreq-info | grep 'should be within'
current policy: frequency should be within 800 MHz and 2.20 GHz.
current policy: frequency should be within 800 MHz and 2.20 GHz.
0-0-13:03:38, Fri Jul 18 r...@dirac:/home/tconnors (bash)
51301,42> tail -f /tmp/acpi.txt > /tmp/acpi-to-batt
###################################
#unplug laptop here, and wait a bit
###################################
^C
130-0-13:03:50, Fri Jul 18 r...@dirac:/home/tconnors (bash)
51302,43> cpufreq-info | grep 'should be within'
current policy: frequency should be within 800 MHz and 800 MHz.
current policy: frequency should be within 800 MHz and 800 MHz.
The 330K of strace output has been placed on my webserver:
http://rather.puzzling.org/~tconnors/tmp/acpi-to-batt
I can't see anything incriminating in there, but since disabling acpi
is sufficient to stop this happening, it must be in there somewhere...
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25 (SMP w/2 CPU cores)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages acpid depends on:
ii libc6 2.7-12 GNU C Library: Shared libraries
ii lsb-base 3.2-15 Linux Standard Base 3.2 init scrip
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
acpid recommends no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
this bug has been waiting for more information for quite some time now.
Assuming that this means you don't see the problem anymore either I take the
freedom to close it. Should my assumption be wrong feel free to reopen by
providing additional information.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--- End Message ---
