Bug#364119: closed by Olivier Vitrat ovit.deb...@gmail.com (Closing Debian bug 364119)
Hmmm. I fail to see how KLaptopDaemon has anything to do with a bug report
against KWin? The problem (if it still exists) is in a combination of kwin
and laptop-mode-tools, which as nothing to do with KLaptopDaemon.
Cheers,
Bart
On Thu, Mar 4, 2010 at 04:51, Debian Bug Tracking System
ow...@bugs.debian.org wrote:
This is an automatic notification regarding your Bug report
which was filed against the kwin package:
#364119: kwin writes to disk synchronously
It has been closed by Olivier Vitrat ovit.deb...@gmail.com.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Olivier Vitrat
ovit.deb...@gmail.com by
replying to this email.
--
364119: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364119
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
-- Forwarded message --
From: Olivier Vitrat ovit.deb...@gmail.com
To: 364119-d...@bugs.debian.org, 364119-qu...@bugs.debian.org
Date: Wed, 3 Mar 2010 22:48:38 -0500
Subject: Closing Debian bug 364119
Hello,
This is no longer maintained.
See the comment at https://bugs.kde.org/146789
--- Comment #2 From Dario Andres 2010-02-26 14:09:00 (-)
[reply] ---
I have personally contacted the KLaptopDaemon author/assigned and he
confirmed
that the tool is deprecated in KDE SC 4 (replaced by PowerDevil) and that
there
are no current efforts to support/maintain the KDE SC 3 version.
Because of this, I will close the reports as UNMAINTAINED.
Regards
I'm also closing the Debian bug report
thanks
Olivier
-- Forwarded message --
From: Bart Samwel b...@samwel.tk
To: sub...@bugs.debian.org
Date: Fri, 21 Apr 2006 18:09:19 +0200
Subject: kwin writes to disk synchronously
Package: kwin
Severity: normal
Hi there,
I got a report from a laptop-mode-tools user saying that kwin kept his disk
spun up. I checked his logs, and indeed it seems to be the case that his
kwin process explicitly syncs pretty regularly. I straced my own kwin to
confirm this behaviour, and I see the following:
open(/home/bsamwel/.kde/share/config/kwinrulesrc6EREMa.new,
O_RDWR|O_CREAT|O_EXCL, 0600) = 11
umask(0)= 022
umask(022) = 0
fchmod(11, 0600)= 0
getgid32() = 1000
getuid32() = 1000
fchown32(11, 1000, 1000)= 0
fcntl64(11, F_SETFD, FD_CLOEXEC)= 0
stat64(/home/bsamwel/.kde/share/config/kwinrulesrc,
{st_mode=S_IFREG|0600, st_size=824, ...}) = 0
getuid32() = 1000
getgid32() = 1000
fchmod(11, 0100600) = 0
fchmod(11, 0600)= 0
fcntl64(11, F_GETFL)= 0x2 (flags O_RDWR)
fstat64(11, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6705000
_llseek(11, 0, [0], SEEK_CUR) = 0
write(11, [1]\ndescription=(Default) Disabl..., 824) = 824
fdatasync(11) = 0
close(11) = 0
munmap(0xb6705000, 4096)= 0
rename(/home/bsamwel/.kde/share/config/kwinrulesrc6EREMa.new,
/home/bsamwel/.kde/share/config/kwinrulesrc) = 0
and then:
open(/home/bsamwel/.kde/share/config/kdeglobalsZbum9a.new,
O_RDWR|O_CREAT|O_EXCL, 0600) = 11
umask(0)= 022
umask(022) = 0
fchmod(11, 0600)= 0
getgid32() = 1000
getuid32() = 1000
fchown32(11, 1000, 1000)= 0
fcntl64(11, F_SETFD, FD_CLOEXEC)= 0
stat64(/home/bsamwel/.kde/share/config/kdeglobals, {st_mode=S_IFREG|0600,
st_size=5804, ...}) = 0
getuid32() = 1000
getgid32() = 1000
fchmod(11, 0100600) = 0
fchmod(11, 0600)= 0
fcntl64(11, F_GETFL)= 0x2 (flags O_RDWR)
fstat64(11, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6705000
_llseek(11, 0, [0], SEEK_CUR) = 0
write(11, [$Version]\nupdate_info=kded.upd:..., 4096) = 4096
write(11, ndow to Desktop 2=none\nWindow to..., 1708) = 1708
fdatasync(11) = 0
close(11) = 0
munmap(0xb6705000, 4096)= 0
rename(/home/bsamwel/.kde/share/config/kdeglobalsZbum9a.new,
/home/bsamwel/.kde/share/config/kdeglobals) = 0
So, here's my question: is that call to fdatasync() really necessary? And
can it be disabled somehow? It makes laptop mode pretty much unusable on
KDE. :-(
Cheers,
Bart Samwel
Bug#562883: acpi-support: why is nvclock 'recommended'?
The policy manual states (7.2): The Recommends field should list packages that would be found together with this one in all but unusual installations. It's hardly unusual to have a system without nVidia hardware. It doesn't say in all but unusual hardware configurations. :-) Anyhow, the intention is that the package makes things work out of the box for all users, novices included. If a user has nVidia hardware and this isn't installed, then some functionality will simply be absent, and even an advanced user will have absolutely no idea why. Therefore, it is preferable that we consider install-everything-it-might-possibly-need as a usual installation, i.e., this stuff is installed by default, and the advanced user can choose to remove it while tweaking the system. Cheers, Bart
Bug#524986: acpi-support: /etc/acpi/sleep.sh should not call prepare.sh unconditionally
Bjørn Mork wrote: Package: acpi-support Version: 0.114-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 One of the changes between 0.109-11 and 0.114-1 is that sleep.sh calls prepare.sh, which does for SCRIPT in /etc/acpi/suspend.d/*.sh; do if [ -x $SCRIPT ] ; then . $SCRIPT fi done This should not happen unless we're using the legacy suspend support. Other methods have their own list of suspend quirks, which are more likely to be up-to-date than the scripts in /etc/acpi/suspend.d/*.sh The same goes for the hdparm DMA fiddling: acpi-support should leave this up to the actual suspend method unless legacy suspend is used. On my Lenovo Thinkpad X301, running the default scripts in /etc/acpi/suspend.d/*.sh results in - - non-functional wireless network (module iwlagn unloaded) - - non-functional display (needs VT switch) + possibly other minor errors Calling /usr/share/acpi-support/suspendorhibernate suspend directly still works as expected (using pm-utils as suspend method). Hmmm, that's probably caused by the merge of upstream 0.114 from Ubuntu -- Ubuntu does not support suspend methods, this has been added to Debian only. (The ubuntu package did at some point mention suspend methods in the config files though, probably an over-enthousiastic merge from Debian. Don't know if that's still there.) Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524986: [Pkg-acpi-devel] Bug#524986: acpi-support: /etc/acpi/sleep.sh should not call prepare.sh unconditionally
Michael Meskes wrote: On Tue, Apr 21, 2009 at 01:04:37PM +0200, Bart Samwel wrote: Debian only. (The ubuntu package did at some point mention suspend methods in the config files though, probably an over-enthousiastic merge from Debian. Don't know if that's still there.) This merge really went awol. The old Debian code is still there but was put *after* the new Ubuntu code. No idea what happened. Will fix with the next upload. Great! This is probably caused by the fact that the Debian and Ubuntu packages have diverged too much for reliable automatic merging -- manual verification is required every time. :-( Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522683: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Hi Steve, On Mon, April 6, 2009 05:44, Steve Langasek wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. I have to say here in defense of Ubuntu that I don't see any record of these patches being submitted to the Ubuntu package via Launchpad, which, since Ubuntu does not have individual package maintainers, is the only reliable way to ensure that proposed changes are seen and considered by the people working on the package at any given time. Yeah, I think it's probably mostly me being disappointed earlier, and not so much the Ubuntu side. The feeling that I have had is that because there are no individual package maintainers, it's hard to find somebody on the other side who feels responsible for the package, and who is willing to discuss merging of sets of patches etc., so that you can discuss the chances of acceptance _before_ you do the work. It's so much easier if you can talk to a person, launchpad sometimes feels like throwing stuff into a black hole. /rant Things suddenly got much easier when I got into direct contact with you. But I shouldn't be blaming Ubuntu, my expectations just didn't match the way Ubuntu works. I don't have time to work on the Debian package myself (either as maintainer or for sifting through the delta between Debian and Ubuntu), but I definitely am happy to accept fixes upstream in reasonable-sized chunks. Anyway, as Bart points out, there's another issue: 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. Since the last time I had a chance to speak with Bart about this, there's been quite a bit of progress on phasing out the package for Ubuntu; in jaunty, we've dropped a number of quirk scripts related to suspend/resume, as well as close to 30 of the ACPI event-handling scripts from /etc/acpi - basically: all those scripts that were being used to synthesize key events (which doesn't work with recent kernels anyway) and which we could verify were being handled by hal. And yes, Martin Pitt works very closely with hal upstream to ensure fixes are incorporated. Thanks for the update! Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522683: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Meskes wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: I'm putting the acpi-support package up for adoption. The RFA bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683 Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes, the acpi team will welcome new members who like to help too. :-) Thanks for helping out! It sounds like a very good plan to move acpi-support to the acpi team. I will do what's necessary to transfer maintainership to you, I'll keep you informed of the progress. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522683: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Package: wnpp I want to stop maintaining the acpi-support package and am looking for an adopter. This package is relatively high-profile, since it is installed by default on all laptops, and part of it is installed on all ACPI machines. There are some specific challenges with the package that make it interesting to maintain, for some value of interesting. The package provides the following: 1. Power button support for all systems, in the form of package acpi-support-base. 2. Button support for laptops. Special laptop button translations are included for various laptop brands and types. This also includes default scripts for button functionality for some laptops, including wireless buttons etc. 3. Suspend/resume support. Acpi-support used to be one of the primary suspend packages, before pm-utils came along. Right now, it still contains the suspend logic, but in the default configuration it delegates any suspend requests to pm-utils. Still, the legacy suspend support should keep working for now. This package receives a pretty steady stream of bug reports due to new hardware with new button quirks, and it requires active maintenance. There are several challenges involved in maintaining this package: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. 2. Even though we have an upstream, we build the package as a Debian-native package, since we have extensively changed the package. We moved files around etc., and specifying an upstream source tarball results in an incorrect package being built. :-/ 3. Changes from the upstream are extensive: - We build two packages: acpi-support-base and acpi-support. The upstream builds only one, for laptops only. - We have support for suspend methods, i.e., we can delegate suspend to pm-utils but we can also handle it ourselves, depending on configuration. - A very large variety of small changes have been made as well, in response to bug reports. None of these changes have been sent upstream. :-/ 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. 5. The kernel is adding more and more native support for these buttons, so that acpi-support does not need to translate them anymore. In the end, the package may need phasing out in Debian as well, or it may need to become the upstream instead of Ubuntu, in which case it requires extra maintenance. Whatever happens, it will be a challenge to keep all hardware working properly. Whoever adopts this package will help to keep extremely large numbers of laptop users happy! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520669: [acpi-support-base] CheckPolicy doesn't detect Power Devil in KDE4
Michal Sojka wrote: Package: acpi-support-base Version: 0.109-11 Severity: normal When KDE4.2 is running, pressing power button switches the computer off regardless of settings in Power Management module under System settings. This is probably because KDE4 is not detected in CheckPolicy in /usr/share/acpi- support/policy-funcs. You're probably right about that. I could check it out myself, but do you perhaps have a suggestion on how I could detect this? Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519426: laptop-mode-tools: ethernet speed not restored
Hi Ritesh, Ritesh Raj Sarraf wrote: I'd have preferred giving you a patch, but my ethernet driver itself has some problems. r...@champaran:/usr/share/laptop-mode-tools/modules$ sudo ethtool -s eth0 speed 1000 duplex full Cannot set new settings: Invalid argument not setting speed not setting duplex Anyway, LM should still be restoring the normal speed when on AC. Currently, it is not doing that. Thanks for reporting. I've set this back to severity normal since it's in a feature that's disabled by default and that's also not used very often (why not plug in the AC adapter if you have an ethernet cable handy?). I've just checked the code and it is indeed incorrect, it doesn't restore ethernet speed at all. I'll have it fixed in the next release. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518570: Should acpi-support rename /etc/modprobe/thinkpad_acpi.modprobe?
Hi Salvatore, Salvatore Bonaccorso wrote: With the last upload of module-init-tools, booting up get's warnings for files in /etc/modprobe.d/ not ending with .conf (which will be required in future uploads). See: http://blog.bofh.it/debian/id_236 Should the file provided in acpi-support /etc/modprobe/thinkpad_acpi.modprobe thus be renamed? Yes, that should definitely happen. Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518570: Should acpi-support rename /etc/modprobe/thinkpad_acpi.modprobe?
Hi Raphael, Raphael Hertzog wrote: Should the file provided in acpi-support /etc/modprobe/thinkpad_acpi.modprobe thus be renamed? Or maybe it could simply be removed and replaced by a dynamic configuration if needed: parm: hotkey:Simulates thinkpad-acpi procfs command at module load, see documentation It looks like we can control the driver through /proc/ibm. Hmmm. If that works, that would be preferable. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516865: laptop-mode-tools: allow to easily preserve customizations in the configuration
Hi Yaroslav, Thanks for reporting. The laptop-mode-tools package is designed to be resilient w.r.t. old configuration files (in fact, configuration files from the very first version should still work), so the only reason why you would want this is if you really really want to get upgrades to the main config, which is supposed to change only in comments. So I'm inclined to treat this as a low-priority item for now. I don't mind adding it at some point though, it'll probably show up in one of the next releases! Cheers, Bart Yaroslav Halchenko wrote: Package: laptop-mode-tools Version: 1.47-1 Severity: wishlist Tags: patch As it is now, any customization of the parameters described in /etc/laptop-mode/laptop-mode.conf is either lost if a maintainers version is installed or the whole file with customized parameters need to be preserved between upgrades with manual patching of a new .conf.dpkg-dist file later on. As laptop_mode does it -- it loads conf.d/* files first and then laptop-mode.conf later on, so there is no way to override defaults in .conf so they are preserved through the upgrades. I would suggest a simple, yet imho effective way: add a line [ -r /etc/laptop-mode/laptop-mode.local ] . /etc/laptop-mode/laptop-mode.local either at the end of /etc/laptop-mode/laptop-mode.conf or in laptop_mode after sourcing /etc/laptop-mode/laptop-mode.conf file. That would allow to define custom changes in /etc/laptop-mode/laptop-mode.local without impact on any distributed .conf file (so they would be safely preserved through upgrades). even better approach would be for any .conf (ie under conf.d as well) to check if there is a corresponding .local file and source it after corresponding .conf (needs to be done in laptop_mode) This way it would be easy to add customizations to any file. P.S. Sorry for such a 'verbal' patch -- but I am not sure which way you would like to follow (if any) -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (600, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii psmisc22.6-1 Utilities that use the proc filesy ii util-linux2.13.1.1-1 Miscellaneous system utilities Versions of packages laptop-mode-tools recommends: ii acpid 1.0.6-13 Utilities for using ACPI power man ii apmd3.2.2-10 Utilities for Advanced Power Manag ii ethtool 6+20080227-1 display or change ethernet card se ii hal 0.5.11-3 Hardware Abstraction Layer ii hdparm 8.9-1tune hard disk parameters for high ii sdparm 1.02-1 Output and modify SCSI device para laptop-mode-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516662: EeePC: Plugging the power launches email tool
Francois Gouget wrote: I forgot to mention this in my previous email. For reference, here are the events that acpi_listen reports when I plug the power in: ac_adapter AC0 0080 0001 battery BAT0 0080 0001 hotkey ATKD 0050 0011 processor P001 0081 processor P002 0081 And also, someone else had the same issue (albeit with Ubuntu) and reported about it in his blog. It's in French but what's to be learnt is that the EeePC 901 has the same issue. http://www.ddmdllt.org/weblog/posts/2008/09/19/kubuntu-asus-eeepc-901-acpi-kmail-ac-cable/ Sounds like the EeePC has some very weird hotkeys -- last time I checked an AC adapter wasn't a key. :-) It does sound like we need to filter this out. We already needed to do some other weird stuff for EeePCs, so it isn't going to be a big deal to fix this up as well. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495036: laptop-mode-tools Not Hooked into pm-utils
Hi Leo, Leo L. Schwab wrote: On Thu, Feb 19, 2009 at 10:46:52AM +0100, Bart Samwel wrote: I'm just wondering about how I'm going to prevent *double* calls to laptop-mode-tools here -- or perhaps it just doesn't matter if I add locking so that simultaneous calls don't bite eachother. I've already noticed this fight going on, which is one of the reasons I uninstalled acpid entirely. Without looking at it in detail, I think the packages acpid and/or acpi-support may need to be marked as conflicting with pm-utils, since they both process the same class of events, and both are written expecting to be the exclusive processor thereof. Trouble with acpi-support (which I maintain for Debian as well -- which makes it even more of a shame that I didn't know what was going on) is that it has two functions: (a) converting hotkey ACPI events into virtual key presses (b) suspend (legacy) I heard that the Ubuntu guys are moving the hotkey support into pm-utils, but until that happens, lots of laptops need acpi-support (and therefore also acpid etc.) to make their hotkeys work. But here's the really good part: the suspend code now delegates its work to pm-utils by default! And that means that acpi-support and pm-utils cannot conflict! I've been contemplating for a while to split the legacy acpi-support suspend part and the hotkeys part into a separate package. Your suggestion makes it clear to me that this is not an optional thing, I really need to do this ASAP. In the case of laptop_mode, it seems to avoid doing redundant work by keeping track of its current state, so I would expect it could be invoked any number of times without clobbering things. It does. But I don know what happens if the script gets called multiple times at the same time -- I'll probably have to do something with lock files to fix this. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495036: laptop-mode-tools Not Hooked into pm-utils
Leo L. Schwab wrote: On Wed, Feb 18, 2009 at 12:19:24PM +0100, Bart Samwel wrote: Hmmm, are you saying that you aren't running acpid? Correct. Since /proc/acpi/event has been deprecated since at least 2.6.24, 'acpid' just plain won't work. Ergo, acpi-support won't work, and neither will anything that plugs into that framework. ACPI events are now broadcast over the regular kernel input event system, which get picked up by HAL and friends. Because laptop-mode-tools is supposed to be triggered by acpid scripts. And, back when /proc/acpi/event still existed, those scripts ran for me just great. No longer. Hence, my new script. Fair enough. :-) Thanks for explaining, I wasn't aware that this stuff was going away so soon. I'm just wondering about how I'm going to prevent *double* calls to laptop-mode-tools here -- or perhaps it just doesn't matter if I add locking so that simultaneous calls don't bite eachother. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515796: acpi-support: videobtn.sh: optionally run a graphical UI to RandR
Hi, intrig...@boum.org wrote: Bart Samwel wrote (17 Feb 2009 19:33:49 GMT) : It's a nice suggestion, but this one I can't accept. The problem is that acpi-support isn't supposed to do this kind of thing. It simply translates the hardware key press into a virtual button, and the user's desktop environment (which can basically be *anything* in Debian) is supposed to handle the key and respond. So the proper way to do this, is to convince somebody in the desktop environments game to add a handler for this hotkey, just like there are handlers for video brightness buttons, sound and even for things like suspending. Oh. Since acpi-support already handled locking screen with xscreensaver, KDE and al, I thought this was the right place to implement such a behaviour. Anyway, I guess you're the one who knows better. It's not so strange that you assumed that. The acpi-support package has two major components which are going to be split into separate packages eventually: 1. Hotkey translation 2. Suspend The xscreensaver etc. stuff is part of (2), which does a lot of work. Your script is part of (1), which should really be as simple as possible. Of course you can change it to do what you want, all the scripts are config files. But the design of the package is simply that it translates hardware specific hotkeys into generic ones -- nothing more, nothing less. :-) Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495036: laptop-mode-tools Not Hooked into pm-utils
Leo L. Schwab wrote: On Tue, Feb 17, 2009 at 08:46:21AM +0100, Bart Samwel wrote: Thanks for reporting. In fact, laptop-mode-tools *does* hook into pm-utils, this was added in version 1.47-1. But it doesn't do this in /etc/pm/power.d, but in the system folder for hooks (I think it's /usr/lib/pm-utils/sleep.d). ^^^ Yes, in fact, I had noticed this some weeks ago. However, the solution there is incomplete. Scripts in sleep.d are invoked when the system transitions into/out of suspend-to-RAM or suspend-to-disk and, in fact, the scripts there work perfectly for me. However, power state changes -- plugging and unplugging the AC adapter -- are not handled through sleep.d (since the system isn't sleeping), but rather through power.d. This was the support I added. Hmmm, are you saying that you aren't running acpid? Because laptop-mode-tools is supposed to be triggered by acpid scripts. I expect that there is a dependency on acpid, even... Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#448673: acpi-support: excessively load cycles some hard drives
Renato S. Yamane wrote: One more info: If you have laptop-mode-tools installed, disabling hdd power management (hdparm -B 255 /dev/sda) don't fix the problem. Load_Cycle_Count still increase. Only removing laptop-mode-tools don't fix the problem. Is necessary *remove* laptop-mode-tools *and* do: #hdparm -B 255 /dev/sda Note that that should be 254. 255 gives undefined behaviour for lots of hardware. Here's a question to everybody here: does the load cycle count increase quickly *while you're on AC*? (Why I'm asking: the current solution was designed so that the load cycle count increases while on battery, but stops increasing while on AC. The theory is that nobody works on battery 24 hrs/day, and that HD power management actually has benefits while working on battery. We've calculated that with this solution, even with very mobile usage patterns your drive should live for years. If the load cycle count increases while you're on AC, then the solution is broken. If the load cycle count increases only on battery, then it works as designed.) Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#448673: acpi-support: excessively load cycles some hard drives
Renato S. Yamane wrote: Bart Samwel wrote: Note that that should be 254. 255 gives undefined behaviour for lots of hardware. 254 don't fix the problem (Load_Cycle_Count still increasing). Even if you do it and do nothing else, so that nothing runs laptop mode tools and/or acpi-support? And check below: # hdparm -B 254 /dev/sda /dev/sda: setting Advanced Power Management level to 0xfe (254) # hdparm -B 255 /dev/sda /dev/sda: setting Advanced Power Management level to disabled So, I really think that correct is 255. What you think? Nope, 254 is correct for this. 255 means do what you want, 254 means do as little power management as possible. For many drives disable power management does the same as 128 (the default). Here's a question to everybody here: does the load cycle count increase quickly *while you're on AC*? - When I run in AC, Load_Cycle_Count never increase. - When I run in battery, Load_Cycle_Count increase at least 1 time per minute. No more than 2 times per minute. Ah, it works exactly as designed then! The theory is that nobody works on battery 24 hrs/day, and that HD power management actually has benefits while working on battery. We've calculated that with this solution, even with very mobile usage patterns your drive should live for years. If the load cycle count increases while you're on AC, then the solution is broken. Yes, when I'm running in AC, Load_Cycle_Count don't increase in my laptop. Messias, and in your laptop? And... Messias can hear this sound when Load_Cycle_Count increase: http://bugzilla.kernel.org/attachment.cgi?id=8777action=view This can be a different bug? I don't have sound so I can't see if this is the same. On my laptop it gives a pretty loud click. This is expected, this is just the sound of the head parking. If the load cycle count increases only on battery, then it works as designed.) You think that is a good idea change hdparm -B from 254 to 255 in my case (/etc/acpi/battery.d/90-hdparm.sh)? Because when I run as 254, I get: setting Advanced Power Management level to 0xfe (254) And when I run as 255, I get: setting Advanced Power Management level to disabled No, I'd keep it at 254 if it works for you. And I wouldn't worry if the load cycle count increases while you're on battery: you're not on battery all day. Here's the math again, which shows why this is safe: 8 hours on battery per day * 60 minutes per hour * 1 load cycle per minute = 480 cycles per day. Drives are rated for 60 load cycles - 60 / 480 = 1250 days = 3.42 years. And that's if you use your laptop on battery for 8 hours EVERY DAY for 3.42 years. Nobody does that: a typical Li-Ion battery can take 300 load cycles before it's exhausted and needs to be replaced. So, assuming you have a battery which can handle 8 hours (!) you'd need to be in your 5th replacement battery before your hard drive fails. Do you know ANYONE who uses a laptop into its second replacement battery? I don't either. So this is perfectly safe. :-) Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510213: acpi-support: Hibernate doesn't work on Lenovo 3000 N200
David Jarvie wrote: It turns out that executing the following command before suspending or hibernating makes things work correctly: modprobe -r ehci_hcd Note that without this command, neither suspend nor hibernate work, and they don't work under a KDE 4 desktop any more either. Hmmm. In that case this is a kernel bug! I'll reassign it. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515784: acpi-support-base: getXuser() broken with login names longer than 8 chars
Hi there, intrig...@boum.org wrote: getXuser uses 'w' to list the logged on users. 'w' truncates the login names to 8 chars, which in turns breaks the various /etc/acpi/*.sh scripts that use getXuser/getXconsole to get a username they feed into 'su'. This issue is fixed by using pinky instead of 'w', as proposed by Luca Niccoli on bug #502141. Sounds like a useful suggestion, I'll look into it! Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515794: acpi-support: ibm-videobtn: should run videobtn.sh as any other video button
Hi, intrig...@boum.org wrote: unlike other video button event handlers, that run /etc/acpi/videobtn.sh, ibm-videobtn is currently a placeholder running /bin/true. The attached patch makes the latter work as others. I'm not sure why this was a placeholder in the first place. Perhaps the videobtn handlers were originally placeholders for all hardware. Anyway, I think this looks fine so I'll include it. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515796: acpi-support: videobtn.sh: optionally run a graphical UI to RandR
Hi there, intrig...@boum.org wrote: videobtn.sh currently runs acpi_fakekey to generate a $KEY_VIDEOOUT X event. I'd like it to run a RandR GUI (e.g. grandr), which would, I believe, enhance the desktop user's experience in most cases. The attached patch achieves so, by adding a USE_RANDR_UI to /etc/default/acpi-support. For backward compatibility's sake, this option is disabled by default. Unless the preferred UI software is explicitly set in /etc/default/acpi-support, a sensible one is guessed at runtime. It's a nice suggestion, but this one I can't accept. The problem is that acpi-support isn't supposed to do this kind of thing. It simply translates the hardware key press into a virtual button, and the user's desktop environment (which can basically be *anything* in Debian) is supposed to handle the key and respond. So the proper way to do this, is to convince somebody in the desktop environments game to add a handler for this hotkey, just like there are handlers for video brightness buttons, sound and even for things like suspending. Unfortunately I'm not quite sure where you should go for this. :-) I'll see if I can find out, but I won't make any promises. In the mean time I'll tag it wontfix for acpi-support. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495036: laptop-mode-tools Not Hooked into pm-utils
Hi Leo, Leo L. Schwab wrote: I have a similar issue on a Thinkpad Z61t. When I plug/unplug the AC adapter, laptop_mode is not invoked to change the power settings. Since /proc/acpi/event (and therefore 'acpid') is deprecated, everything's moving to pm-utils. Attached is a quick bash script I wrote that plugs in to the pm-utils framework and runs laptop_mode when the power state changes. It should be placed in /etc/pm/power.d . You may wish to add it or its moral equivalent to the laptop-mode-tools distribution. Thanks for reporting. In fact, laptop-mode-tools *does* hook into pm-utils, this was added in version 1.47-1. But it doesn't do this in /etc/pm/power.d, but in the system folder for hooks (I think it's /usr/lib/pm-utils/sleep.d). So, your problem will probably be caused by the fact that this hook is not working. Could you check that this hook script is actually there, and if so, update it to log something so that you can see that it's actually being run? Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515081: laptop-mode-tools: auto-hibernating triggers twice in a row
Hi Clemens, Clemens Buchacher wrote: With AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=4 and AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1 auto-hibernation always triggers twice in a row. I.e. after power-down, I plug in the AC and restart the laptop. It resumes successfully but suspends again immediately. This does not happen the third time. Setting AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=-1 fixed the issue. Note that I use HIBERNATE_COMMAND=/etc/acpi/sleep.sh, which eventually does STR on this machine. Thanks for reporting. I have some ideas about what's going on here, but I'll have to check it out in detail. It's possible that the kernel still thinks it's on battery just after booting up, or something like that. Unfortunately I'm not in a position where I can check things out right now, so I'll have to get back to you later. I'm going to set this back to normal priority. The reason is that this is a feature that is not enabled by default, it doesn't cause data loss (in fact, it still saves your data by hibernating in time -- I'd be more worried if it didn't), and there's a workaround. This doesn't mean I don't think it's worth checking out -- it's just in comparison with other bugs. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513078: usb-autosuspend fails
Hi Hannes, Hannes von Haugwitz wrote: Package: laptop-mode-tools Version: 1.46-1 Severity: normal Tags: patch Hi, usb-autosuspend fails with the following error message: /usr/share/laptop-mode-tools/modules/usb-autosuspend: line 20: echo: write error: Invalid argument The attached patch solves the issue. Ahhh. A typical case of thinking of testing but then forgetting to do so in the end... :-/ Thanks for contributing, I'll fix it up ASAP. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511653: laptop-mode-tools: When the wireless interface is down, wireless-iwl-power fails
Hi Costas, cost...@students.cs.unipi.gr wrote: Quoting Bart Samwel b...@samwel.tk: Thanks for reporting and contributing. Apparently we cannot tell the driver to use a certain power level when the hardware is disabled... This is a shame, because the power level will be incorrect when the device is re-enabled -- laptop mode tools doesn't re-apply settings when interfaces are enabled or disabled. I wonder, does this problem happen only when the hardware kill switch is used? Or does this already go wrong if you just do an ifdown on your device (as indicated by /sys/class/net/$DEVICE/operstate)? I wonder if there are other things that can't be used if the device's radio is killed. Might be worth a submitting a bug report to the iwl guys... Cheers, Bart Hello again Bart, When I submitted the bug, the wireless was killed by the hardware rf switch on boot. If it is killed by the switch, cat /sys/class/net/wlan0/device/enable gives 0 cat /sys/class/net/wlan0/operstate gives down Now, if i turn the rf switch to on and keep the interface down: cat /sys/class/net/wlan0/device/enable gives 0 cat /sys/class/net/wlan0/operstate gives down During ifconfig ups/ifconfig downs /sys/../operstate remains down, /sys/../enable changes according to up/down. As it seems, for operstate to work i have to be connected to an ap. ifconfig wlan0 up just doesn't change it. In my /etc/network/interfaces i have no section for wlan0. The /sys/class/net/wlan0/device/enable maybe better for laptop-mode, because many people don't have an rf switch or are not connected to ap at boot. I've reported this problem upstream because I really don't think this should be my problem to solve: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1893 If they don't respond positively I'll have to reconsider, but for now I'll wait to see what they say! Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512482: acpi-support: brightness control on laptops doesn't work
Seems like a kernel problem then, you get an increase + decrease button when you press the increase button! I'll have to reassign this to the kernel. I don't have time now, I'll do it in the weekend. Cheers, Bart Рушан wrote: So, there is acpi_listen when i press increase button appears two strings video LCD 0086 video LCD 0087 and when i press decrease button appears only one string video LCD 0087 and syslog: when i press buttons appears such messages: Jan 22 16:25:02 note acpid: client connected from 3412[0:0] Jan 22 16:25:06 note kernel: [ 167.379101] ACPI: EC: non-query interrupt received, switching to interrupt mode Jan 22 16:25:06 note acpid: client 3320[1000:1000] has disconnected Jan 22 16:25:11 note kernel: [ 172.451016] ACPI: EC: non-query interrupt received, switching to interrupt mode Jan 22 16:25:12 note kernel: [ 173.586807] ACPI: EC: non-query interrupt received, switching to interrupt mode Jan 22 16:25:32 note acpid: client connected from 3456[0:0] Jan 22 16:25:35 note kernel: [ 196.299111] ACPI: EC: non-query interrupt received, switching to interrupt mode Jan 22 16:25:35 note acpid: client 3412[0:0] has disconnected Jan 22 16:25:36 note kernel: [ 197.243852] ACPI: EC: non-query interrupt received, switching to interrupt mode Jan 22 16:26:47 note kernel: [ 268.133702] ACPI: EC: non-query interrupt received, switching to interrupt mode Jan 22 16:26:47 note acpid: client 3456[0:0] has disconnected Bart Samwel wrote: H. AFAIK there's no special support for Fujitsu Siemens brightness in acpi-support, but I'm not sure. Could you run acpi_listen while you press the brightness keys and show me the output? I would also like to see the syslog output when you press the keys, to see what acpid is doing. Can you send me this info? Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512482: acpi-support: brightness control on laptops doesn't work
Hi there, Рушан wrote: Brightness control on my Debian Lenny laptop doesn't work. When i press button for descresing brightness it works, but when i try to increase brightness it become brightly and in next second return to previous bright level. My lap is fujitsu siemens esprimo mobile u9200. In the end are dmesg, lspci and packages related to acpi-suppoprt. Also i want to say, that on my friends laptop (he's got another model, sorry i don't remember exactly the model) also brightness control trouble. He can control it, but in linux only 10 steps of control, instead 10 in windows. His lspci and dmesg also attached. H. AFAIK there's no special support for Fujitsu Siemens brightness in acpi-support, but I'm not sure. Could you run acpi_listen while you press the brightness keys and show me the output? I would also like to see the syslog output when you press the keys, to see what acpid is doing. Can you send me this info? Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511653: laptop-mode-tools: When the wireless interface is down, wireless-iwl-power fails
Hi Constantinos, Constantinos Drogos wrote: Hello. In my system, wireless-iwl-power module fails at startup of laptop-mode-tools, if the wireless interface are not up. The error seems to be that the scriptcannot write power level to /sys/class/net/$DEVICE/device/power_level if $DEVICE is down. The error showed is: /usr/share/laptop-mode-tools/modules/wireless-iwl-power: line 48: echo: write error: Resource temporarily unavailable The driver used is the iwl3945. The error seems to be corrected if everytime it searches for an interface, it checks if it is up via /sys/class/net/$DEVICE/device/enable (1 for up, 0 for down) This change seems to work at least in my computer: Thanks for reporting and contributing. Apparently we cannot tell the driver to use a certain power level when the hardware is disabled... This is a shame, because the power level will be incorrect when the device is re-enabled -- laptop mode tools doesn't re-apply settings when interfaces are enabled or disabled. I wonder, does this problem happen only when the hardware kill switch is used? Or does this already go wrong if you just do an ifdown on your device (as indicated by /sys/class/net/$DEVICE/operstate)? I wonder if there are other things that can't be used if the device's radio is killed. Might be worth a submitting a bug report to the iwl guys... Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510294: laptop-mode-tools: LM_VERBOSE is inverted in respect to VERBOSE_OUTPUT
Darn, thanks for reporting! But I wonder, why does the VERBOSE_OUTPUT switch work then? I'll have to look into this... Cheers, Bart Jean-Sebastien Trottier wrote: Package: laptop-mode-tools Version: 1.45-1 Severity: normal Tags: patch LM_VERBOSE is initialized to [1 = 0] when VERBOSE_OUTPUT is 1 and to [1 = 1] when VERBOSE_OUTPUT is 0. This is obviously backwards. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii util-linux2.13.1.1-1 Miscellaneous system utilities Versions of packages laptop-mode-tools recommends: ii acpid 1.0.8-1Utilities for using ACPI power man ii apmd 3.2.2-12 Utilities for Advanced Power Manag ii hal 0.5.11-6 Hardware Abstraction Layer ii hdparm8.9-2 tune hard disk parameters for high ii sdparm1.02-1 Output and modify SCSI device para laptop-mode-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509597: acpi-support: bug in 90-hdparm.sh?
Hi Christian, Cristian Ionescu-Idbohrn wrote: Isn't this more sensical? --- 90-hdparm.sh~ 2008-08-19 21:59:10.0 +0200 +++ 90-hdparm.sh2008-12-23 17:18:23.0 +0100 @@ -12,7 +12,7 @@ DO_HDPARM=y if [ -e /usr/sbin/laptop_mode ] ; then LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf echo $CONTROL_HD_POWERMGMT) - if [ $LMT_CONTROL_HD_POWERMGMT != 0 ] ; then + if [ $LMT_CONTROL_HD_POWERMGMT != 1 ] ; then # Laptop mode controls hdparm -B settings, we don't. DO_HDPARM=n fi Well, no. The logic is like this: if LMT_CONTROL_HD_POWERMGMT is nonzero, then *we* shouldn't do it because laptop mode tools already does this. So we set our flag to N if the LMT flag is set to nonzero! Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509588: acpi-support: do we really need 4 identical copies of the 90-hdparm.sh script?
Hi Christian, Cristian Ionescu-Idbohrn wrote: Or one copy (/etc/acpi/hdparm.sh) and 4 symlinks should be enough? ./ac.d/90-hdparm.sh - ../hdparm.sh ./battery.d/90-hdparm.sh - ../hdparm.sh ./resume.d/90-hdparm.sh - ../hdparm.sh ./start.d/90-hdparm.sh - ../hdparm.sh Yes. :-) I'll try and fix this up at some point. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509597: acpi-support: bug in 90-hdparm.sh?
Cristian Ionescu-Idbohrn wrote: On Wed, 24 Dec 2008, Bart Samwel wrote: Hi Christian, Cristian Ionescu-Idbohrn wrote: Isn't this more sensical? --- 90-hdparm.sh~ 2008-08-19 21:59:10.0 +0200 +++ 90-hdparm.sh2008-12-23 17:18:23.0 +0100 @@ -12,7 +12,7 @@ DO_HDPARM=y if [ -e /usr/sbin/laptop_mode ] ; then LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf echo $CONTROL_HD_POWERMGMT) - if [ $LMT_CONTROL_HD_POWERMGMT != 0 ] ; then + if [ $LMT_CONTROL_HD_POWERMGMT != 1 ] ; then # Laptop mode controls hdparm -B settings, we don't. DO_HDPARM=n fi Well, no. The logic is like this: if LMT_CONTROL_HD_POWERMGMT is nonzero, then *we* shouldn't do it because laptop mode tools already does this. So we set our flag to N if the LMT flag is set to nonzero! I see... Hmm... That's some sort of catch 22 situation then. If CONTROL_HD_POWERMGMT=0, acpi-support will do hd power management. If CONTROL_HD_POWERMGMT=1, laptop-mode will do hd power management. I have both the acpi-support and laptop-mode-tools packages installed, and I don't want any of these to do hd power management. I don't see how I can achieve that by just modifying the flag value in /etc/laptop-mode/laptop-mode.conf. The reason for wanting to stop 'hdparm -B 254' from executing is that it _some times_ it locks up my laptop at boot, when on AC. The only way to get around is to power cycle and reboot. I don't like that. I didn't figure out yet what to blame. Hmmm, so this is actually a wishlist item to be able to disable this behaviour. We can do that -- I can add a config option if you want. For now, it's simple: delete the code from 90-hdparm.sh, and set CONTROL_HD_POWERMGMT=0 as well. The 90-hdparm.sh is a config file, so it won't get overwritten on upgrade. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506839: laptop-mode-tools: [PATCH] Add USB Autosuspend mode
Hi Michael, Michael Leuchtenburg wrote: This patch looks great, but isn't quite sufficient. This will set the autosuspend timeout for all existing USB devices to 0 when activated, but will not modify the timeout for new USB devices. This can be set by writing to /sys/module/usbcore/parameters/autosuspend. Both this and the existing behavior of the script are required to make sure that all USB devices connected to the system when on battery have autosuspend=0. I'm not sure how to set the default power level for new devices - it would probably require some HAL hooks. Attached is a modified version of the script with this change. Cool, thanks for contributing! I'll include this modified version in the next upstream release. Cheers, Bart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507927: Fix suspend-resume in Thinkpad R50e (intel 855gm card)
Hi Raphael, I'm very much behind on everything, so if you could handle the upload I would be very grateful! Cheers, Bart Raphael Hertzog wrote: Hi Bart, do you have time to handle this bug report quickly or do you need someone else to do the upload? It seems that this change has been integrated in Ubuntu's acpi-support 0.111 and it looks fairly safe. Cheers, On Fri, 05 Dec 2008, Diego Escalante Urrelo wrote: Package: acpi-support Version: 0.109-9 Severity: serious Thinkpad R50e won't resume correctly (corrupted X) unless its acpi-support file contains this: # R50e 1834 - see LP: #40621, #211285 1834*) ACPI_SLEEP=true; SAVE_VIDEO_PCI_STATE=true; SAVE_VBE_STATE=true; POST_VIDEO=true; ;; 1842*|2670*) ACPI_SLEEP=true; SAVE_VIDEO_PCI_STATE=true; SAVE_VBE_STATE=false; POST_VIDEO=false; ;; instead of this: # R50e 1834*|1842*|2670*) ACPI_SLEEP=true; SAVE_VIDEO_PCI_STATE=true; SAVE_VBE_STATE=false; POST_VIDEO=false; ;; I confirmed this two days ago after a test Lenny install on my own R50e. Please apply this change so R50e users of Lenny have working out-of-the-box suspend/resume. greetings PD: I hope you don't mind that I set serious, but I considered that despite not being a negative thing it's an enhancement worth doing. Feel free to disagree obviously. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504395: [Lenovo T61] Wireless switch don't work
Hi Renato, Renato S. Yamane wrote: Can someone give any kind of help here in #504395? I'm sorry about the slow response. A combination of the flu, building activities and a baby have kept me overly busy in the past month and a half. I will definitely try to pay some attention to this problem somewhere in the next week! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507640: laptop-mode-tools: Problems enabling laptop-mode
Hi Jakob, Jakob Schuerz wrote: Bootmessage: Enabling laptop mode.../usr/share/laptop-mode-tools/modules/lcd-brightness: line 25: echo: write error: Invalid argument I found the line if ( $BRIGHTNESS_COMMAND $BRIGHTNESS_OUTPUT ) ; then in the Script. It is a shell-skript, i think it should be: if [ $BRIGHTNESS_COMMAND -gt $BRIGHTNESS_OUTPUT ] ; then But i don't know how to make a patch. Ehm... no. It's not as in greater than, it's as in redirect the output of the $BRIGHTNESS_COMMAND to the file $BRIGHTNESS_OUTPUT. So that's fine. What is in your configuration file for the lcd-brightness module (/etc/laptop-mode/conf.d/lcd-brightness.conf)? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507640: It ist only a bad errorhandling
Jakob Schuerz wrote: Ok, sorry for this bug-report. I've just seen, there is a Problem with my hardware: $ cat /proc/acpi/video/VID/LCD/brightness not supported It is a NVIDIA LVM 135M on a Dell Latitude-Laptop. So, how i change the Bug-Level from Important to wish-list? I want have a better error-handling. OK, it's set to wishlist now. I will fix it in a future release. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506839: laptop-mode-tools: [PATCH] Add USB Autosuspend mode
Hi Ritesh, Ritesh Raj Sarraf wrote: USB Autosuspend mode is good for the hub and devices. These days USB is the way to go and most laptops come with 4 USB ports. When running on battery, they are useless and drawing a lot of power. Powertop, when run on a default Debian kernel/laptop-mode-tools, reports that USB autosuspend mode be enabled. I looked into powertop's usb.c implementation and am submitting a similar thing for laptop-mode-tools usb-autosuspend module. This should help save some more power. Very interesting! I was already considering doing a similar thing myself, but didn't have the time. This will most certainly be included in the next (upstream) release, thank you very much for contributing! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506549: suspendorhibernate: dbus-pm method is inherently broken
Raphael Hertzog wrote: On Sun, 23 Nov 2008, Bart Samwel wrote: 1. This program is running as root, right? I would be very careful with sourcing arbitrary shell commands from a users home directory then. I agree that that would be risky. However, on my system the .dbus directory is owned by root and not accessible to anyone else. So that should be no problem. (The session dbus system is apparently set up by Yes it is a problem. Here it's not owned by root and furthermore the user has write rights to ~/ so he can mv .dbus .dbus-temp. Please be more careful about security when you think of code running as root. ACK -- this needs more thought. You should rather parse those files and not source them directly. That was in fact what I had in mind for the actual implementation -- yesterday's stuff was just a quick proof of concept to check if it would work at all. Or maybe you can call dbus-send with the user rights (su user -c ) provided that you include an export DISPLAY=… command before the dbus-send command ? Sounds like a definite possibility. The export DISPLAY=... stuff won't work however, because dbus doesn't derive it's session bus from that AFAICT. I really need to set the three env variables listed in one of the .dbus/session-bus/* files. Perhaps I can run an entire script as the user, which then tries to determine the session bus parameters (safely sourcing these files) and then tries to send commands to the session bus. Yes, I think that would work. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506549: suspendorhibernate: dbus-pm method is inherently broken
Hi Fredrik, Fredrik Tolf wrote: The dbus-pm suspend method in the suspendorhibernate script (which is enabled by default) is inherently broken and, I think, should be removed altogether. It uses the dbus-send program with the --session option, but since it does not run in the desktop user's session, it will never actually find the right session, and furthermore, will sometimes even create a new session. Every time I suspend my laptop, it will create a new DBus session as root and start gnome-power-manager inside it, running as root, so that I need to kill it every time it wakes up again. For some reason, this appears not to be a problem when running Gnome, however. I can only assume that two g-p-m's can manage to lock out each other or something. That is indeed true, two g-p-m's can coexist peacefully. I only tested this stuff with g-p-m which is why I didn't find this problem. Thanks for pointing this out! Anyway, I don't think the suspend method is inherently broken, although it is broken as it is now. :-) We do things inside X sessions as well (such as locking all screens when suspending), so I expect it should be possible to get dbus-send to run inside a particular session. For instance, by finding the user corresponding to the console X session and by sourcing ~username/.dbus/session-dbus/*. Could you try the following change to suspendorhibernate: dbus-pm) if [ -x /usr/bin/dbus-send ] ; then +getXconsole +. $userhome/.dbus/session-bus/* # Call the power management daemon (which, if it is # running, we probably don't know about, since we send That *might* just do the trick. Or it might not, of course. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506549: suspendorhibernate: dbus-pm method is inherently broken
Hi Fredrik, Fredrik Tolf wrote: On Sat, 2008-11-22 at 20:31 +0100, Bart Samwel wrote: Anyway, I don't think the suspend method is inherently broken, although it is broken as it is now. :-) We do things inside X sessions as well (such as locking all screens when suspending), so I expect it should be possible to get dbus-send to run inside a particular session. For instance, by finding the user corresponding to the console X session and by sourcing ~username/.dbus/session-dbus/*. I see. That's interesting -- I did not know of that directory or its significance. However: dbus-pm) if [ -x /usr/bin/dbus-send ] ; then +getXconsole +. $userhome/.dbus/session-bus/* I don't think that it going to work. I've got several files in there (probably stuff left over from some unclean shutdowns) overwriting each other, so it seems very unlikely that the last file will have the correct values. What would be the correct procedure here? Trying all of the files until one is found to work? Hmmm. That would probably be a problem. I'll have to look into that. Also, the directory can contain multiple files if you are logged in multiple times. The files do seem to mention a display in the comments, I'll have to do some research to see if I can filter out the files for the correct display, then try each and every one of them until I find one that is still live. Not pretty, but it's my only option. :-/ Also -- I believe that you only meant that code to be used for testing, but I can see at least two large problems with it: 1. This program is running as root, right? I would be very careful with sourcing arbitrary shell commands from a users home directory then. I agree that that would be risky. However, on my system the .dbus directory is owned by root and not accessible to anyone else. So that should be no problem. (The session dbus system is apparently set up by root, and the information is passed on through environment variables; dbus-send uses environment variables to determine where --session is supposed to go.) 2. On a system using home directories on Kerberized NFS, the script should be able to handle root not having access to that directory at all. That's actually something acpi-support can't handle at all -- all of the X accessing functionality also requires access to the user's home directory. I agree that a check for that would have to be added -- this was just concept code, for testing purposes. Real code would have to deal with all sorts of things. [Rant mode on] As an aside, I would love to be able to have a generic mechanism to hook into all started sessions and inject some functionality (like registering the appropriate session info with acpi-support), but I haven't found it yet (I have to support users who use startx as well as gdm, kdm, xdm etc. users -- it's very hard to access all of these sessions from the outside but it's even harder to hook into all of them automatically). If only I would be able to easily get all available info about sessions (other than parsing the output of w, finger or some other tool), that would already be an enormous help, but now I find myself once again without some crucial bit of information (dbus session info) which is only known in fscking *environment variables* inside the session, and not available from the outside in such a way that I can correlate it with the session itself. Aaargh!! [Rant mode off] Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504955: acpi-support: suspendorhibernate method 'dbus-pm' exits without doing anything
Hi Adam, Adam M. Costello wrote: Package: acpi-support Version: 0.109-6 Ahhh, but this is not the latest version! In fact, this problem has been fixed a while ago, in version 0.109-7: http://bugs.debian.org/496911 So I've merged this bug report with (closed) bug #496911. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504012: Add support for Eee PC volume buttons
Hi Per, Per Olofsson wrote: On an Eee PC 901, the volume buttons don't do anything by default with acpi-support installed. Apparently they are not bound to anything in /etc/acpi/events. The following files can be added to fix it: eeepc-volume-mute: -- event=hotkey ATKD 0013 action=/etc/acpi/mutebtn.sh -- eeepc-volume-down: -- event=hotkey ATKD 0014 action=/etc/acpi/voldownbtn.sh -- eeepc-volume-up: -- event=hotkey ATKD 0015 action=/etc/acpi/volupbtn.sh -- Note that these are similar to the asus-volume-* files, which I looked at. The only difference is the key number and the fact that my system only says ATKD and not HOTK when I press the buttons. Perhaps the codes can be added as alternatives in the asus-volume-* files instead using the (...|...) syntax. This should be handled by asus-eee-volume-down and -up... Oh wait, that only detects model 701. Could you change /etc/acpi/if-asus-eee.sh so that the line: if [ $model = 701 ] ; then reads if [ $model = 701 -o $model = 901 ] ; then and try again? If that works, I'll commit that change. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448673: acpi-support: excessively load cycles some hard drive
Boyd Stephen Smith Jr. wrote: fixed 448673 0.103-5 tags 448673 + fixed thanks Bart didn't upload his fixed version discussed in message 71, but it does look like he checked them into the debian VCS for the package and that Raphael included them when he pushed out 0.103-5. Bart or Michael, please close if this bug is actually squashed. Was that bug still open then? I'm surprised -- it's supposed to be closed, this fix has been in for a long time. Anyway, it seems that you closed it then, so no action is required on my side anymore! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502246: Duplicate
Merwok wrote: My quick search before posting was obviously too quick: this bug is a duplicate of #495364. Sorry. I don’t send a message with “merge” because I’m unfamiliar with the system. Oh, I was too quick to reply -- thanks anyway for the report, I'll do the merge. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502246: laptop-mode-tools: inconsistency in conf file hal-polling
Merwok wrote: Hello. I was poking around in /etc/laptop-mode/conf.d on Lenny and tweaking thinks when I noticed this contradiction in hal-polling.conf, lines 29-30: # Enable HAL polling on AC AC_DISABLE_HAL_POLLING=1 I don’t know whether to follow the comment or the variable name for the last setting; I guess the name is right, since the default value is true, but can’t be sure. The comment should be corrected then. Thanks for the report, will fix! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500983: still reproducable for me
Hi Dave, The gnome-power-manager actually does some stuff and then forwards the request to HAL, which then forwards it to pm-utils. Acpi-support (in your configuration) actually forwards to gnome-power manager (that's what the dbus-pm suspend method does), so that's why acpi-support doesn't work. So it goes like this: acpi-support - gnome-power-manager - hal - pm-utils HAL doesn't add anything AFAIK, and if pm-suspend works, then the problem must be in the stuff that gnome-power-manager adds. I'll reassign the bug to gnome-power-manager then. Cheers, Bart Dave O wrote: It does seem to, yes. Looks like the problem happens for me when suspending through gnome-power-manager. I didn't see anything in gconf about suspend method for that program, so I'm not sure what to do next. On Thu, 9 Oct 2008, Bart Samwel wrote: Hi Dave, I see that you are using pm-utils for suspend (the dbus-pm and dbus-hal methods eventually go to pm-utils as well). Does your laptop suspend and resume correctly when you issue the command pm-suspend (as root)? Cheers, Bart Dave O wrote: I have the same issue, since the upgrade to this version, using an x61. It occurs more frequently than described in the original report for me, in fact nearly every time. Here's the non-comment lines from the config file: SUSPEND_METHODS=dbus-pm dbus-hal pm-utils ACPI_SLEEP=true ACPI_HIBERNATE=true ACPI_SLEEP_MODE=mem MODULES= MODULES_WHITELIST= SAVE_VBE_STATE=true VBESTATE=/var/lib/acpi-support/vbestate POST_VIDEO=true USE_DPMS=true HIBERNATE_MODE=shutdown LOCK_SCREEN=true STOP_SERVICES= RESTART_IRDA=false SKIP_INTERFACES=dummy qemu Please let me know if I can provide more detail for you. Thanks! Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500983: still reproducable for me
Hi Dave, I see that you are using pm-utils for suspend (the dbus-pm and dbus-hal methods eventually go to pm-utils as well). Does your laptop suspend and resume correctly when you issue the command pm-suspend (as root)? Cheers, Bart Dave O wrote: I have the same issue, since the upgrade to this version, using an x61. It occurs more frequently than described in the original report for me, in fact nearly every time. Here's the non-comment lines from the config file: SUSPEND_METHODS=dbus-pm dbus-hal pm-utils ACPI_SLEEP=true ACPI_HIBERNATE=true ACPI_SLEEP_MODE=mem MODULES= MODULES_WHITELIST= SAVE_VBE_STATE=true VBESTATE=/var/lib/acpi-support/vbestate POST_VIDEO=true USE_DPMS=true HIBERNATE_MODE=shutdown LOCK_SCREEN=true STOP_SERVICES= RESTART_IRDA=false SKIP_INTERFACES=dummy qemu Please let me know if I can provide more detail for you. Thanks! Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481766: pm-utils: Please fix this before lenny becomes stable!
Hi Michael, Michael Biebl wrote: Michael Biebl wrote: The problem is, that the bug is about adding support for laptop-tools, but I am missing proper justification, why this is necessary, what the underlying problem is and why laptop-mode-tools is the correct solution. Bart, can you elaborate a bit on this. The linked launchpad bug is a bit hard to digest. Sorry about the delay, I've just returned from some scheduled downtime (aka a holiday). I understand that you can't read the launchpad thing, but it's not all that important really. Let me try to explain the situation. The basic problem is the following combination of things: 1. Laptop mode tools tweaks hardware settings. Most of these are lost over suspend. So, on resume, it must re-tweak them. The settings that are lost over suspend include the ones that are required for the basic functionality of laptop mode, i.e., spinning down the hard drive. So it is *very* important that laptop mode tools is restarted on resume, or else it is entirely broken on resume. This is especially important since suspending is used most frequently on laptops which are running on battery power, exactly the target audience of laptop mode tools. 2. Until recently, the package acpi-support handled suspend itself. It has a directory of on-resume scripts in /etc/acpi/resume.d. This directory contains a script that restarts laptop mode tools. 3. The package acpi-support has since been changed to delegate suspend to pm-utils instead (by default -- the old functionality is still present). 4. The pm-utils suspend functionality does not contain a script that restarts laptop mode tools on resume. So technically: a) This is not a regression in pm-utils when viewed in isolation. The pm-utils package has never supported this. b) This is not a regression in laptop-mode-tools. Laptop mode tools has never cared about suspend. c) This IS a regression in acpi-support, because it used to do this in sarge, and now it doesn't in lenny. So it's all a bit strange -- an important regression in the functionality of acpi-support, which can only be fixed by changing pm-utils. BTW, in an earlier mail you suggested that this should actually be fixed in laptop-mode-tools. While I understand the reasoning behind this policy, and while I support this design concept in general, there are simply too many suspend methods in Linux to support, each of which have their own set of scripts which have to be tweaked. The ones I know of are hibernate, pm-utils, pmud, pbbuttonsd, and acpi-support. I'm afraid this situation needs to be resolved before such scripts can be put in the resume-action-requiring packages. :-/ On a side note, I've just received another bug report (#501804) for laptop-mode-tools mentioning exactly this -- indicated priority by the submitter as important. I've CC'ed the submitter, as he may want do some advocacy as well. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500983: acpi-support: resume from suspend to RAM unreliable on ThinkPad X61s
Hi Anton, Anton Ekblad wrote: Laptop does not wake up from suspend to RAM reliably anymore but freezes completely about one time in three. Worked fine before the last update to acpi-support. Thanks for reporting. I will ask you some questions to debug this problem. First of all, could you send me the contents of /etc/default/acpi-support? That will help me determine which suspend method is being used, and it determines the next questions that I will need to ask. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500751: acpi-support ships file and deletes it in postinst
Hi Paul, Paul Wise schreef: acpi-support ships /etc/modprobe.d/thinkpad_acpi.modprobe and deletes it in postinst when upgrading from versions before 0.109-1 or just installing from scratch. I detected this because I occasionally run the cruft program. Ohhh, this may actually be a problem for lenny, because the version of acpi-support in the previous release was before 0.109-1. I'll have to check once I get back to my own computer... Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489465: changes from 0.109-5 to -6 disabled sleep button
Hi Krunoslav, Krunoslav Sever wrote: On Sun, Sep 07, 2008 at 10:26:13AM +0200 wrote Bart Samwel [EMAIL PROTECTED]: Hi Krunoslav, Krunoslav Sever wrote: On Thu, Sep 04, 2008 at 08:36:03PM +0200 wrote Bart Samwel [EMAIL PROTECTED]: Hi Krunoslav, Krunoslav Sever wrote: Today I upgraded to -6 which disabled the sleep button on my (old) HP Omnibook 6000, at least on console. Haven't tested if it still works from X, though (xfce Desktop). With -5 the sleep button functioned perfectly from console and from the xfce Desktop. After downgrading to -5 again, everything works fine again, so it must be the changes between these two versions. Before downgrading I tried to revert the change in /etc/acpi/events/sleepbtn manually and and stop/start /etc/init.d/acpi-support, but that didn't have any effect, so I guess there have been some more changes (or I forget to restart something else?). The changelog led me to this bug number which I guess is the culprit, so I hope this is the right place to post this issue. Maybe you can provide a workaround, otherwise I will be staying with -5 for now. This is a fairly basic lenny installation, just base and some selected additional packages, nothing custom. If you should need more details, I can provide them later (at work right now). Sorry about the delay, I've been a bit busy. Could you try replacing the contents of /usr/share/acpi-support/suspendorhibernate by the contents of the attached file and tell me the results? This change will be included to fix another suspend problem in 0.109-6, and if this fixes it for you, then you are experiencing the same problem and I don't have to change anything else. For more info, see bugs #496911 an d #497570: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496911 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497570 If this doesn't fix things for you, we need to do do some debugging on your setup. But we'll wait with that until we know that it's necessary! Cheers, Bart No sweat about the delay, since I have a working setup for now, there is no real urgency. Anyway, replaced the file, sleep button didn't work (console). Replacing back, enabled it again. Let me know what you need for debugging the setup. I did no manual changes, so it is the setup established by apt, though I suppose there are local settings involved. OK, then let's debug this. I would like to see the output of: bash -x /usr/share/acpi-support/suspendorhibernate suspend Okay, following occurred: with version -5 I obtained out-5 in the attachment and notebook suspended. Then I replaced the file you provided earlier and rerun. I obtained out-7 in the attachment (a few lines differ, may be of help) and the notebook suspended again (but the button does not work): button assignment? I haven't retested but I think I tried something like this command to obtain a manual suspend command with version -6 and it did not suspend. May be I will retry later. For now I am quite optimistic the current results will help you. Yes, this helps. It must be a button handler problem. Could you show me the output of: bash -x /etc/acpi/sleepbtn.sh and also tell me if the laptop suspends when you do this? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489465: changes from 0.109-5 to -6 disabled sleep button: SOLVED!
Hi Krunoslav, Krunoslav Sever wrote: [...] I haven't retested but I think I tried something like this command to obtain a manual suspend command with version -6 and it did not suspend. May be I will retry later. For now I am quite optimistic the current results will help you. Yes, this helps. It must be a button handler problem. Could you show me the output of: bash -x /etc/acpi/sleepbtn.sh and also tell me if the laptop suspends when you do this? Gak. Okay, I found the problem myself after this output, i.e. your patched file works! I just forgot to make it executable (the output showed me that I had no permission to run your file). Now button works with patch from console and X again. That means version 7 will likely fix this for me: have you an ETA for upload already? Thank you for the help and I hope you don't mind me having been a little stupid there. I actually did watch for reading rights when replacing but totally ignored execution somehow. Well, at least the solution didn't require serious work :) Version 7 is actually already uploaded -- it's in unstable (or actually, version 8 is), I still need to get a release exception from the release managers so that it still goes into Lenny, I'll do that tonight. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin, I've uploaded a fix for this final problem, using a fix similar to what you suggested but using exit instead of nextfile. The reason is that nextfile is gawk-only, while exit is supported by both gawk and mawk, and it does the same thing in this situation. Let's just hope that it works now! Cheers, Bart Bart Samwel wrote: Hi Kevin, Well, at least this *looks* a bit reassuring. And we always grabbed the first one in the past, so this will probably be fine in practice. Thanks for all of the extra info! Cheers, Bart Kevin Mitchell wrote: It looks like openbox (or whatever is logging the terminals) knows not to cause this sort of trouble. I added a sudo aterm shortcut and when I fire it up, I get USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 09:030.00s 13.38s 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 09:035:55m 0.02s 0.02s mutt kevmitch pts/0:0 09:035:55m 0.13s 0.13s bash kevmitch pts/2:0 09:033:47m 0.41s 0.04s /usr/bin/aterm -geometry 106x32-640-412 - kevmitch pts/3:0 09:051:32m 0.22s 0.22s bash root pts/5:0.0 09:071:33m 0.20s 0.20s bash root pts/6:0.0 09:090.00s 0.18s 0.00s w So it appends the extra .0 when it might cause confusion. In any case, it might have been all right even if this wasn't the case, since the real login TTY seems to always be the first in the list. Thus, truncating to just the first result would have prevented any root :0 from spoiling the pudding. That probably wouldn't be very reassuring though, because who knows if that ordering is set in stone. Kevin On Mon, Sep 8, 2008 at 1:20 AM, Bart Samwel [EMAIL PROTECTED] wrote: Hi Kevin, Kevin Mitchell wrote: $ w 01:00:47 up 1 day, 23:51, 9 users, load average: 0.00, 0.04, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 Sun030.00s 8:36m 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 00:572.00s 0.22s 0.02s aterm kevmitch pts/2:0 00:555:01m 0.17s 0.17s bash kevmitch pts/4:0 13:273:07 0.77s 0.77s bash kevmitch pts/5:0 23:49 14:05m 3.51s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/6:0 18:486:12 0.26s 0.26s bash kevmitch pts/7:0 18:493:08 2.09s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/8:0 00:563:48m 0.19s 0.19s bash kevmitch pts/9:0.0 01:000.00s 0.19s 0.00s w All the pts's are the xterminals I have open. The ones without .0 are aterm's started via key bindings in Openbox. The lone :0.0 is one that I started by typing aterm on the command line of an already open xterminal. Don't ask me why that makes a difference :) Thanks for the info. I hadn't seen this type before -- all cases I've seen up till now showed one entry for :0 and all terminal entries for :0.0. What I'm wondering is if you can get it to show a different user name while still showing :0, for instance rootpts/4:0 13:273:07 0.77s 0.77s bash if you edit the Openbox config and edit the hotkey to start something like sudo aterm command line or something similar. Because then I'm getting *really* unhappy about how this looks... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin,
Kevin Mitchell wrote:
Looking a littler closer, there are more problems than just this typo.
*) This loop is attempting to match $displaynum rather than :$displaynum
*) Variables inside the | while read construct are only local to within the
loop (probably because it's executed in some sort of subshell or something),
so $user never actually gets set. I tried to export it, but that
didn't work eiither. Instead, the patch attached (again to be
applied to power-funcs file itself) reverts back to something
closer to the old method, but using w instead of finger as
this was noted to be more reliable.
Thanks for the scrutiny -- apparently I failed to test this batch of
changes, blindly trusting the fact that I copied most of it from
laptop-mode-tools. Stupid me. Anyway, the reason to go to the read
construct was also the fact that filtering for :0 would also match a
significant percentage of all logged in times (the fourth column in the
output of w, and also present in the finger output). And it also
matches entries which contain :0.0, which are present for terminal
emulators. We really need to check only the second and third columns for
display numbers, and we need to do exact matches only. So I think I'll
go for this awk-based solution:
user=`w -hs | awk '{ if ($3 == :'$displaynum' || $2 ==
:'$displaynum' ) print $1; }'`
Does that work for you?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: setting package to acpi-support acpi-support-base, tagging 497999
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-8) unstable; urgency=low # # * Fix broken getXuser (Closes: #497999) package acpi-support acpi-support-base tags 497999 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Hi Phil, Phil Endecott wrote: I am trying to get the lid event to suspend on my Eee 901 and have encountered the following problems: 1. getXuser() in /usr/share/acpi-support/power-funcs uses finger, but the package does not depend on finger (and I didn't have it installed). Thanks for reporting, added! 2. getXuser() is called from CheckPolicy() in /usr/share/acpi-support/policy-funcs and $displaynum is not set. Do you expect that $displaynum is set by the caller of CheckPolicy(), i.e. in this case eeepc-acpi-scripts' /etc/acpi/actions/lid.sh? Or should it be set to 0 in CheckPolicy()? (Most users won't notice this second problem as the grep in getXuser will look for ':' when displaynum is not set and match either the idle time or the login time. In fact, even with a valid display number, the pattern ':0' will frequently match the idle or login time in the second finger|grep|awk. You need to take care to match only in the Tty column of the finger output.) The way I see it, there are two issues here: First of all, the format provided by finger is (:$displaynum) or (:$displaynum.screennum). We filter by :$displaynumspace, which doesn't even find (:$displaynum). We then filter by just :$displaynum, which frequently gives unwanted matches, as you mention. I've replaced it by a filter for (:$displaynum) and then for (:$displaynum as a fallback. Secondly, the call from CheckPolicy() is completely incorrect. Like you say, the getXuser function is intended to be called when the display number has already been determined. CheckPolicy() should have called getXconsole, which gets the foreground X display and then calls getXuser for that display! I'll put fixes in for these issues. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: setting package to acpi-support acpi-support-base, tagging 497220
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-7) unstable; urgency=low # # * Added finger to Depends of acpi-support-base (Closes: #497220) # package acpi-support acpi-support-base tags 497220 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Hi Phil,
Phil Endecott wrote:
I've just spotted detect_x_display() in
/usr/share/eeepc-acpi-scripts/functions.sh from package
eeepc-acpi-scripts which does a similar thing by parsing the output of
who, rather than finger. who has the advantage of being provided
by coreutils, which is a Priority: required package, while finger is
Priority: standard. There is also w from procps.
the format provided by finger is (:$displaynum) or
(:$displaynum.screennum).
Err, no; mine doesn't have the ():
$ finger
Login NameTty Idle Login Time Office Office
Phone
phil Phil Endecott *tty114:51 Sep 2 16:40
phil Phil Endecott pts/0 Sep 4 12:09 (egypt.chezphil.org)
phil Phil Endecott *:0 Sep 4 12:29
root root *tty213:02 Sep 3 21:40
Obviously yours does and I'm sure I've seem that notation somewhere or
other; I don't know if the () mean something or whether it's a finger
version thing, or what.
Mine actually only lists the display in the Office column:
$ finger
Login Name Tty Idle Login Time Office Office Phone
bsamwel bsamweltty7 Sep 4 11:36 (:0)
bsamwel bsamwelpts/2 Sep 4 11:37 (:0.0)
root root *tty11 Sep 4 14:17
root root *tty21 Sep 4 14:18
root root pts/1 25 Sep 4 11:37 (:0.0)
So that's a bit strange. I like the w approach, I've already got a bit
of code in laptop-mode-tools that uses w -hs. I've now got:
getXuser() {
w -hs | while read -r THIS_USER THIS_TTY THIS_DISPLAY DUMMY_REMAINDER;
do
if [ $THIS_DISPLAY = $displaynum ] ; then
user=$THIS_USER
break
fi
done
if [ x$user = x ]; then
startx=`pgrep -n startx`
if [ x$startx != x ]; then
user=`ps -o user --no-headers $startx`
fi
fi
if [ x$user != x ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=
fi
export XUSER=$user
}
This does the trick for me. Does it work for you? If so, I'll use that.
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497801: acpi-support: scripts in /etc/acpi test files from acpi-support-base instead of acpi-support
Package: acpi-support Version: 0.109-6 Severity: important The acpi-support scripts in /etc/acpi test for the existence of files in /usr/share/acpi-support to check if they should run. However, a lot of them check for power-funcs or policy-funcs, which are now in acpi-support-base. That means that the scripts will continue to run even though acpi-support is no longer installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497801: setting package to acpi-support acpi-support-base, tagging 497801, tagging 497125
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-7) unstable; urgency=low # # * Added missing 'policy-funcs' include to hibernatebtn.sh (Closes: ##497125) # * scripts in /etc/acpi no longer test files from acpi-support-base #to see if they should run (Closes: #497801) # package acpi-support acpi-support-base tags 497801 + pending tags 497125 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497377: not clear how to have scripts run on suspend
Hi Frederik, Let me see if I can answer your questions. Frederik Eaton wrote: I am sorry to be trouble, there is probably an easy solution but I couldn't find it after some time, so I am submitting this as a documentation bug, hopefully the situation can be improved for future users even if my question is addressed. I just want to turn of my network interfaces on suspend (maybe this happens automatically with some desktop environment or using /etc/network/interfaces but I don't use those), so I looked around and found /etc/acpi/suspend.d/ and put a script in there. It doesn't seem to run on suspend, which I do with acpitool -s A... acpitool is a low-level tool which runs *nothing* on suspend. It is not really intended for end user usage, because it doesn't integrate with the system at all. So that explains it. If you want to use the suspend method as specified in /etc/default/acpi-support, you need to run /etc/acpi/sleep.sh. The trouble here is that suspend on Linux is an absolute mess. There is confusion between layers: acpitool is a low-level hardware tool while acpi-support and pm-utils both deliver a high-level suspend system integrated with the system. There is no central place to put scripts (acpi-support and pm-utils both have their own systems for this, and there are even more suspend systems!). The only way to fix this is for the various authors to get together and make arrangements. I haven't had much success cooperating with the pm-utils folks in the past, and the acpi-support upstream is not too cooperative either. All in all, I've given up. I've deprecated the acpi-support suspend system in favor of the pm-utils one so that there's at least *some* semblance of a single suspend system (especially since gnome-power-manager forces the use of pm-utils and we like to keep behaviour consistent with that). Anyway, I might be able to add some docs, but it's going to remain a mess whatever I do... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Phil Endecott wrote:
Bart Samwel wrote:
getXuser() {
w -hs | while read -r THIS_USER THIS_TTY THIS_DISPLAY
DUMMY_REMAINDER; do
if [ $THIS_DISPLAY = $displaynum ] ; then
user=$THIS_USER
break
fi
done
if [ x$user = x ]; then
startx=`pgrep -n startx`
if [ x$startx != x ]; then
user=`ps -o user --no-headers $startx`
fi
fi
if [ x$user != x ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=
fi
export XUSER=$user
}
No this doesn't work for me. You're looking for :0 in the FROM column,
right? I have it in the TTY column:
$ w -hs
phil tty1 -17:19 -bash
root tty2 -15:31 -bash
phil pts/0egypt.chezphil.o 0.00s sshd: phil [priv]
phil pts/2egypt.chezphil.o 1:54 nano
libskyline/src/compute_skyline.cc
phil :0 -?xdm? -:0
Very peculiar. I'm not really sure what to suggest; I think that
understanding what w, who, finger etc. are really trying to tell us WRT
X sessions would be a good start. I doubt there's anything useful in
the man pages
Darn. I see that you use xdm, that might explain the difference. No clue
WHY this makes things different, but apparently it does. It's
interesting to note that your FROM column was dipslayed in the Office
column by finger, and I was getting my display from there as well.
Anyway, I can simply check both columns:
getXuser() {
w -hs | while read -r THIS_USER THIS_TTY THIS_FROM DUMMY_REMAINDER; do
if [ $THIS_TTY = $displaynum -o $THIS_FROM =
$displaynum ] ; then
user=$THIS_USER
break
fi
done
if [ x$user = x ]; then
startx=`pgrep -n startx`
if [ x$startx != x ]; then
user=`ps -o user --no-headers $startx`
fi
fi
if [ x$user != x ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=
fi
export XUSER=$user
}
Does this version work for you?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Phil Endecott wrote: Julien Cristau wrote: On Thu, Sep 4, 2008 at 15:04:14 +0100, Phil Endecott wrote: No this doesn't work for me. You're looking for :0 in the FROM column, right? I have it in the TTY column: $ w -hs phil tty1 -17:19 -bash root tty2 -15:31 -bash phil pts/0egypt.chezphil.o 0.00s sshd: phil [priv] phil pts/2egypt.chezphil.o 1:54 nano libskyline/src/compute_skyline.cc phil :0 -?xdm? -:0 Very peculiar. I'm not really sure what to suggest; I think that understanding what w, who, finger etc. are really trying to tell us WRT X sessions would be a good start. I doubt there's anything useful in the man pages Your wtmp entry comes from xdm, Bart's probably comes from a terminal emulator. I have this: USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT julien :0 -02:54 ?xdm? 14:13m 0.04s -:0 julien pts/0:0.0 02:54 25:03m 0.58s 0.58s bash (first xdm, then xterm) I'd say looking at the tty is the right thing to do. Ah yes; I did wonder about that. For some reason I'm not seeing lines in w, who or finger output for terminal emulators running inside my X session, though I have seen them in the past. If you did have them they could in principle be for different users than the user who owns the X session itself. The TTY=:0 line is the right one to use. But presumably Bart is not seeing a line like that, right? Nope. I use gdm, and I get: $ w -hs root tty1 - 2:19 -bash root tty2 - 2:19 -bash bsamwel tty7 :00.00s x-session-manager root pts/1:0.0 2:09m gnome-terminal bsamwel pts/2:0.0 0.00s w -hs The first two lines are from virtual terminals, the third one is for tty7 which is what my X is running on, and the final two ones are for terminals. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: requested output
Hi Christian, Christian Gogolin wrote: the output of $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend when run as root is: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. So I think I have a similar but slightly different problem. I don't know if that matters, but I am using xmonad as window manager, just like Nikolay A. Panov who reported #496911. My xorg version is 1:7.3+15. I guess the general problem is that I filter out the wrong kind of the error messages. I was hoping to be able to distinguish between local and remote errors other than I don't know how to suspend, and I was doing that by trying to filter for DBus related errors. Here's what I know: - All errors return an error code. - DBus connection errors do not start with Error org.freedesktop. - DBus interface mismatch errors do start with Error org.freedesktop, and return defined errors. - When I forcibly uninstall pm-utils I get: Error org.freedesktop.DBus.GLib.UnmappedError.GpmControlError.Code0: General failure: No suspend method found - When I replace /usr/sbin/pm-suspend by a script that does exit 1, I get *no error message*, just like when it does exit 0, and I get a return code of 0. In effect, I think I should just take the return code of dbus-send instead of trying to filter error messages. If the message was received by pm-utils on the other end, even if it failed, I should look no further, and consider it a succeeded suspend attempt. I'll put this in. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496911: additional information
Hi Michael, Bart Samwel wrote: Michael Marsh wrote: On Sun, Aug 31, 2008 at 2:02 PM, Bart Samwel [EMAIL PROTECTED] wrote: Hi Michael, It seems to follow the right path, but the command is somehow detected as being successful without actually being successful. Could you manually run that last command: /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend and send me the output? That will tell us more about what's going wrong here. # /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend Failed to open connection to session message bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. If it matters, I boot into runlevel 2 and run startx from the console. A, that's an error I didn't anticipate. Thanks for the info, I'll try and still get a fix into lenny! I've got a potential fix. Could you try to replace /usr/share/acpi-support/suspendorhibernate with the attached file and see if it works then? If it does, I'll put that in! Cheers, Bart #!/bin/sh # # How we handle suspend/hibernate is a bit complicated: # # If gnome-power-manager or klaptopdaemon are running, we send a fake key # and that's it. The daemons may have policies that turn off suspend in # response to suspend keys etc., so we don't want to do anything ourselves. # # If not, we follow the SUSPEND_METHODS setting. # # # This script takes parameter suspend or hibernate. # . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs . /usr/share/acpi-support/device-funcs . /usr/share/acpi-support/policy-funcs . /usr/share/acpi-support/key-constants DeviceConfig; # The difference between suspend and hibernate if [ $1 = suspend ] ; then KEY=$KEY_SLEEP HIBERNATE_CMD=/usr/sbin/hibernate-ram PM_UTILS_CMD=/usr/sbin/pm-suspend DBUS_METHOD=Suspend DBUS_PARAMS=int32:0 elif [ $1 = hibernate ] ; then KEY=$KEY_SUSPEND HIBERNATE_CMD=/usr/sbin/hibernate-disk PM_UTILS_CMD=/usr/sbin/pm-hibernate DBUS_METHOD=Hibernate DBUS_PARAMS= else echo 'Usage: '$0' (suspend|hibernate)' fi # # Backward compatibility # # Backward compatibility for setting USE_HIBERNATE_PACKAGE if [ $SUSPEND_METHODS = ] [ $USE_HIBERNATE_PACKAGE = true ] [ -x $HIBERNATE_CMD ] ; then SUSPEND_METHODS=hibernate fi # Backward compatibility for setups before SUSPEND_METHODS existed. if [ $SUSPEND_METHODS = ] ; then # Legacy configuration -- use the built-in legacy suspend support. We # can NEVER change this explicitly, because it will break people's # working suspend setups, especially ones that depend on custom scripts # in /etc/acpi/suspend.d and /etc/acpi/resume.d. SUSPEND_METHODS=acpi-support fi # # Try the SUSPEND_METHODS in order. # for METHOD in $SUSPEND_METHODS; do case $METHOD in none) exit ;; dbus-pm) if [ -x /usr/bin/dbus-send ] ; then # Call the power management daemon (which, if it is # running, we probably don't know about, since we send # keys if we detect one running that we know of). if /usr/bin/dbus-send --session \ --dest=org.freedesktop.PowerManagement \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.$DBUS_METHOD ; then # The other side exists, we have access to it, # and it received the message. It may have # failed (I tested this: if pm-suspend returns # exit code 1, then the return code of dbus-send # is still 0 and you get no errors), but that # doesn't matter: the first method in the list # that we can access is the one that has to do # it. exit fi # We got a DBUS error, which means that the other side # does not exist or we don't have access to it. We # continue by trying the next option. fi ;; dbus-hal) if [ -x /usr/bin/dbus-send
Bug#497570: requested output
Hi again Christian, Could you confirm that if you replace /usr/share/acpi-support/suspendorhibernate by the attached file, that it works? Cheers, Bart Bart Samwel wrote: Hi Christian, Christian Gogolin wrote: the output of $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend when run as root is: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. So I think I have a similar but slightly different problem. I don't know if that matters, but I am using xmonad as window manager, just like Nikolay A. Panov who reported #496911. My xorg version is 1:7.3+15. I guess the general problem is that I filter out the wrong kind of the error messages. I was hoping to be able to distinguish between local and remote errors other than I don't know how to suspend, and I was doing that by trying to filter for DBus related errors. Here's what I know: - All errors return an error code. - DBus connection errors do not start with Error org.freedesktop. - DBus interface mismatch errors do start with Error org.freedesktop, and return defined errors. - When I forcibly uninstall pm-utils I get: Error org.freedesktop.DBus.GLib.UnmappedError.GpmControlError.Code0: General failure: No suspend method found - When I replace /usr/sbin/pm-suspend by a script that does exit 1, I get *no error message*, just like when it does exit 0, and I get a return code of 0. In effect, I think I should just take the return code of dbus-send instead of trying to filter error messages. If the message was received by pm-utils on the other end, even if it failed, I should look no further, and consider it a succeeded suspend attempt. I'll put this in. Cheers, Bart #!/bin/sh # # How we handle suspend/hibernate is a bit complicated: # # If gnome-power-manager or klaptopdaemon are running, we send a fake key # and that's it. The daemons may have policies that turn off suspend in # response to suspend keys etc., so we don't want to do anything ourselves. # # If not, we follow the SUSPEND_METHODS setting. # # # This script takes parameter suspend or hibernate. # . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs . /usr/share/acpi-support/device-funcs . /usr/share/acpi-support/policy-funcs . /usr/share/acpi-support/key-constants DeviceConfig; # The difference between suspend and hibernate if [ $1 = suspend ] ; then KEY=$KEY_SLEEP HIBERNATE_CMD=/usr/sbin/hibernate-ram PM_UTILS_CMD=/usr/sbin/pm-suspend DBUS_METHOD=Suspend DBUS_PARAMS=int32:0 elif [ $1 = hibernate ] ; then KEY=$KEY_SUSPEND HIBERNATE_CMD=/usr/sbin/hibernate-disk PM_UTILS_CMD=/usr/sbin/pm-hibernate DBUS_METHOD=Hibernate DBUS_PARAMS= else echo 'Usage: '$0' (suspend|hibernate)' fi # # Backward compatibility # # Backward compatibility for setting USE_HIBERNATE_PACKAGE if [ $SUSPEND_METHODS = ] [ $USE_HIBERNATE_PACKAGE = true ] [ -x $HIBERNATE_CMD ] ; then SUSPEND_METHODS=hibernate fi # Backward compatibility for setups before SUSPEND_METHODS existed. if [ $SUSPEND_METHODS = ] ; then # Legacy configuration -- use the built-in legacy suspend support. We # can NEVER change this explicitly, because it will break people's # working suspend setups, especially ones that depend on custom scripts # in /etc/acpi/suspend.d and /etc/acpi/resume.d. SUSPEND_METHODS=acpi-support fi # # Try the SUSPEND_METHODS in order. # for METHOD in $SUSPEND_METHODS; do case $METHOD in none) exit ;; dbus-pm) if [ -x /usr/bin/dbus-send ] ; then # Call the power management daemon (which, if it is # running, we probably don't know about, since we send # keys if we detect one running that we know of). if /usr/bin/dbus-send --session \ --dest=org.freedesktop.PowerManagement \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.$DBUS_METHOD ; then # The other side exists, we have access to it, # and it received the message. It may have # failed (I tested this: if pm-suspend returns
Bug#496911: setting package to acpi-support acpi-support-base, tagging 496911
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-7) unstable; urgency=low # # * Always consider a dbus-send call for a suspend method failed if #dbus-send returns an error code (Closes: #496911) # package acpi-support acpi-support-base tags 496911 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489465: changes from 0.109-5 to -6 disabled sleep button
Hi Krunoslav, Krunoslav Sever wrote: Today I upgraded to -6 which disabled the sleep button on my (old) HP Omnibook 6000, at least on console. Haven't tested if it still works from X, though (xfce Desktop). With -5 the sleep button functioned perfectly from console and from the xfce Desktop. After downgrading to -5 again, everything works fine again, so it must be the changes between these two versions. Before downgrading I tried to revert the change in /etc/acpi/events/sleepbtn manually and and stop/start /etc/init.d/acpi-support, but that didn't have any effect, so I guess there have been some more changes (or I forget to restart something else?). The changelog led me to this bug number which I guess is the culprit, so I hope this is the right place to post this issue. Maybe you can provide a workaround, otherwise I will be staying with -5 for now. This is a fairly basic lenny installation, just base and some selected additional packages, nothing custom. If you should need more details, I can provide them later (at work right now). Sorry about the delay, I've been a bit busy. Could you try replacing the contents of /usr/share/acpi-support/suspendorhibernate by the contents of the attached file and tell me the results? This change will be included to fix another suspend problem in 0.109-6, and if this fixes it for you, then you are experiencing the same problem and I don't have to change anything else. For more info, see bugs #496911 an d #497570: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496911 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497570 If this doesn't fix things for you, we need to do do some debugging on your setup. But we'll wait with that until we know that it's necessary! Cheers, Bart #!/bin/sh # # How we handle suspend/hibernate is a bit complicated: # # If gnome-power-manager or klaptopdaemon are running, we send a fake key # and that's it. The daemons may have policies that turn off suspend in # response to suspend keys etc., so we don't want to do anything ourselves. # # If not, we follow the SUSPEND_METHODS setting. # # # This script takes parameter suspend or hibernate. # . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs . /usr/share/acpi-support/device-funcs . /usr/share/acpi-support/policy-funcs . /usr/share/acpi-support/key-constants DeviceConfig; # The difference between suspend and hibernate if [ $1 = suspend ] ; then KEY=$KEY_SLEEP HIBERNATE_CMD=/usr/sbin/hibernate-ram PM_UTILS_CMD=/usr/sbin/pm-suspend DBUS_METHOD=Suspend DBUS_PARAMS=int32:0 elif [ $1 = hibernate ] ; then KEY=$KEY_SUSPEND HIBERNATE_CMD=/usr/sbin/hibernate-disk PM_UTILS_CMD=/usr/sbin/pm-hibernate DBUS_METHOD=Hibernate DBUS_PARAMS= else echo 'Usage: '$0' (suspend|hibernate)' fi # # Backward compatibility # # Backward compatibility for setting USE_HIBERNATE_PACKAGE if [ $SUSPEND_METHODS = ] [ $USE_HIBERNATE_PACKAGE = true ] [ -x $HIBERNATE_CMD ] ; then SUSPEND_METHODS=hibernate fi # Backward compatibility for setups before SUSPEND_METHODS existed. if [ $SUSPEND_METHODS = ] ; then # Legacy configuration -- use the built-in legacy suspend support. We # can NEVER change this explicitly, because it will break people's # working suspend setups, especially ones that depend on custom scripts # in /etc/acpi/suspend.d and /etc/acpi/resume.d. SUSPEND_METHODS=acpi-support fi # # Try the SUSPEND_METHODS in order. # for METHOD in $SUSPEND_METHODS; do case $METHOD in none) exit ;; dbus-pm) if [ -x /usr/bin/dbus-send ] ; then # Call the power management daemon (which, if it is # running, we probably don't know about, since we send # keys if we detect one running that we know of). if /usr/bin/dbus-send --session \ --dest=org.freedesktop.PowerManagement \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.$DBUS_METHOD ; then # The other side exists, we have access to it, # and it received the message. It may have # failed (I tested this: if pm-suspend returns # exit code 1, then the return code of dbus-send # is still 0 and you get no errors), but that # doesn't matter: the first method in the list # that we can access is the one that has to do
Bug#497570: attached file resolves the problem
Great! It's been uploaded as part of 0.109-7, so that should hit unstable soon. Cheers, Bart Christian Gogolin wrote: Hi, with the attached file suspension works with acpi-support 0.109-6 and acpi-support-base 0.109-6. Regards, Christian Bart Samwel wrote: Hi again Christian, Could you confirm that if you replace /usr/share/acpi-support/suspendorhibernate by the attached file, that it works? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: acpi-support: suspend fails after upgraed from 0.109-5 to 0.109-6
Hi Christian, Christian Gogolin wrote: Package: acpi-support Version: 0.109-6 Severity: important After upgrading acpi-support and acpi-support-base from 0.109-5 to 0.109-6 my Samsung x20 notebook no more enters suspend mode when calling /etc/acpi/sleep.sh. Before the update everything worked fine. Downgrading to 0.109-5 resolved the problem. Below you find a trace of what happens when /etc/acpi/sleep.sh is called. If you tell me what information you need to resolve this problem I'd be happy to help you. I think this is the same problem as one that has already been reported, but I need to be sure. Could you run it using bash -x sleep.sh And show us the output? Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: acpi-support: suspend fails after upgraed from 0.109-5 to 0.109-6
Hi Christian,
Christian Gogolin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The requested output is:
$ bash -x /etc/acpi/sleep.sh
+ test -f /usr/share/acpi-support/policy-funcs
+ . /usr/share/acpi-support/policy-funcs
++ . /usr/share/acpi-support/power-funcs
+++ umask 022
+++
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
+++ POWERSTATE=/var/lib/acpi-support/powerstate
+++ HDPARM='/sbin/hdparm -q'
+++ LIDSTATE=/var/lib/acpi-support/lidstate
++ CheckPolicy
++ getXuser
+++ finger
+++ grep -m1 ': '
+++ awk '{print $1}'
++ user=
++ '[' x = x ']'
+++ finger
+++ grep -m1 :
+++ awk '{print $1}'
++ user=cgogolin
++ '[' xcgogolin = x ']'
++ '[' xcgogolin '!=' x ']'
+++ getent passwd cgogolin
+++ cut -d: -f6
++ userhome=/home/cgogolin
++ export XAUTHORITY=/home/cgogolin/.Xauthority
++ XAUTHORITY=/home/cgogolin/.Xauthority
++ export XUSER=cgogolin
++ XUSER=cgogolin
++ pidof gnome-power-manager kpowersave
++ test cgogolin '!=' ''
++ pidof dcopserver
++ echo 1
+ '[' 1 '!=' 0 ']'
+ /usr/share/acpi-support/suspendorhibernate suspend
Thanks! This output matches my expectations. Now could you send in the
output of:
bash -x /usr/share/acpi-support/suspendorhibernate suspend
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: requested output
Hi Christian, Christian Gogolin wrote: $ bash -x /usr/share/acpi-support/suspendorhibernate suspend [...] + for METHOD in '$SUSPEND_METHODS' + case $METHOD in + '[' -x /usr/bin/dbus-send ']' + /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend + grep -q ' org.freedesktop.DBus.Error.' + exit It's starting to look more and more like the other problem. Could you now try running this command (on a single line): /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend and send us the output? If it's this one: ---snip--- Failed to open connection to session message bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. ---snip--- then it's the same problem as #496911. If not, then we have a similar but slightly different problem. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497345: laptop-mode-tools should recommend psmisc
And thanks for reporting again! Cheers, Bart Daniel Moerner wrote: Package: laptop-mode-tools Version: 1.45-1 Severity: normal If I had noticed I would have filed this along with bug #497343. The configuration-file controller requires killall to function. killall is in psmisc, which is not priority required, and thus is not installed by default. Since laptop-mode-tools actually spits out an error message without killall, I think it might be better for laptop-mode-tools to depend on psmisc, instead of just recommend it. Thanks. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii util-linux2.13.1.1-1 Miscellaneous system utilities Versions of packages laptop-mode-tools recommends: ii acpid 1.0.6-10 Utilities for using ACPI power man ii hal 0.5.11-3 Hardware Abstraction Layer ii hdparm8.9-1 tune hard disk parameters for high pn sdparmnone (no description available) laptop-mode-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497343: laptop-mode-tools should recommend ethtool
Thanks for reporting, will fix! Daniel Moerner wrote: Package: laptop-mode-tools Version: 1.45-1 Severity: normal /etc/laptop-mode/conf.d/ethernet.conf uses ethtool to manipulate the wol and speed settings of ethernet devices. Other parts of laptop-mode-tools that use commands not in the package, like hdparm, have the package listed as a Recommend of laptop-mode-tools. I think the same should apply to ethtool. Thanks. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii util-linux2.13.1.1-1 Miscellaneous system utilities Versions of packages laptop-mode-tools recommends: ii acpid 1.0.6-10 Utilities for using ACPI power man ii hal 0.5.11-3 Hardware Abstraction Layer ii hdparm8.9-1 tune hard disk parameters for high pn sdparmnone (no description available) laptop-mode-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Marc Haber wrote: On Tue, Jul 29, 2008 at 08:35:10PM +0200, Bart Samwel wrote: Marc Haber wrote: On Tue, Jul 29, 2008 at 04:45:23PM +0200, Bart Samwel wrote: Marc Haber wrote: Why is laptop-mode-tools trying to remount the file systems in the first place? Let me try to explain. Ext3 file systems (and some other journalling file systems) write to disc periodically, to flush its journal transactions. When laptop mode is enabled, laptop mode tools must tweak the mount options for ext3 to make the flush intervals larger, so that the disc doesn't spin up every 30 seconds. At resume time, some of the settings are forgotten by the hardware and/or the kernel, so laptop mode tools has to forcibly reapply all settings, including the mount options. Can this behavior of laptop-mode-tools be disabled by configuration? Well, you can set CONTROL_MOUNT_OPTIONS to 0 in laptop-mode.conf. But that does mean that laptop mode won't work anymore. If you're going to do that, you might as well uninstall it... So this option will completely disable all features of laptop-mode, not only the remount upon power loss? Wee... not quite. It will not disable all features of laptop-mode-tools, but it will disable the remount on power loss, yes. And that will make the spin-down-the-hard-drive option (a.k.a. laptop mode) fail to work, because changing the mount options is required if the hard drives need to spin down. You can still use the other modules. Anyway, you could try and report this for the upstream kernel at: http://bugzilla.kernel.org/ They should be able to debug and fix this! I could do it myself BTW, but since I can't reproduce the problem it's better if you report it and help them find out what's going on. Keep me posted -- I want to know what happens with this, because it definitely isn't nice. :-/ Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496911: additional information
Michael Marsh wrote: I'm seeing this same bug, I believe. I've tried running # /etc/acpi/sleepbtn.sh # /etc/acpi/sleep.sh # /usr/share/acpi-support/suspendorhibernate suspend and all three have no effect. By adding a call to the syslogger to suspendorhibernate, I was able to confirm that Fn-F4 on my Thinkpad T23 *is* ultimately calling this (and sleep.sh, as well). I also added +x to the shell invocation, which gives me: + . /etc/default/acpi-support ++ SUSPEND_METHODS='dbus-pm dbus-hal pm-utils' ++ ACPI_SLEEP=true ++ ACPI_HIBERNATE=true ++ ACPI_SLEEP_MODE=mem ++ MODULES= ++ MODULES_WHITELIST= ++ SAVE_VBE_STATE=true ++ VBESTATE=/var/lib/acpi-support/vbestate ++ POST_VIDEO=true ++ USE_DPMS=true ++ HIBERNATE_MODE=shutdown ++ LOCK_SCREEN=true ++ STOP_SERVICES= ++ RESTART_IRDA=false ++ SKIP_INTERFACES='dummy qemu' + . /usr/share/acpi-support/power-funcs ++ umask 022 ++ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 ++ POWERSTATE=/var/lib/acpi-support/powerstate ++ HDPARM='/sbin/hdparm -q' ++ LIDSTATE=/var/lib/acpi-support/lidstate + . /usr/share/acpi-support/device-funcs + . /usr/share/acpi-support/policy-funcs ++ . /usr/share/acpi-support/power-funcs +++ umask 022 +++ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/bin/X11 +++ POWERSTATE=/var/lib/acpi-support/powerstate +++ HDPARM='/sbin/hdparm -q' +++ LIDSTATE=/var/lib/acpi-support/lidstate + . /usr/share/acpi-support/key-constants ++ KEY_RESERVED=0 ++ KEY_ESC=1 ++ KEY_1=2 ++ KEY_2=3 ++ KEY_3=4 ++ KEY_4=5 ++ KEY_5=6 ++ KEY_6=7 ++ KEY_7=8 ++ KEY_8=9 ++ KEY_9=10 ++ KEY_0=11 ++ KEY_MINUS=12 ++ KEY_EQUAL=13 ++ KEY_BACKSPACE=14 ++ KEY_TAB=15 ++ KEY_Q=16 ++ KEY_W=17 ++ KEY_E=18 ++ KEY_R=19 ++ KEY_T=20 ++ KEY_Y=21 ++ KEY_U=22 ++ KEY_I=23 ++ KEY_O=24 ++ KEY_P=25 ++ KEY_LEFTBRACE=26 ++ KEY_RIGHTBRACE=27 ++ KEY_ENTER=28 ++ KEY_LEFTCTRL=29 ++ KEY_A=30 ++ KEY_S=31 ++ KEY_D=32 ++ KEY_F=33 ++ KEY_G=34 ++ KEY_H=35 ++ KEY_J=36 ++ KEY_K=37 ++ KEY_L=38 ++ KEY_SEMICOLON=39 ++ KEY_APOSTROPHE=40 ++ KEY_GRAVE=41 ++ KEY_LEFTSHIFT=42 ++ KEY_BACKSLASH=43 ++ KEY_Z=44 ++ KEY_X=45 ++ KEY_C=46 ++ KEY_V=47 ++ KEY_B=48 ++ KEY_N=49 ++ KEY_M=50 ++ KEY_COMMA=51 ++ KEY_DOT=52 ++ KEY_SLASH=53 ++ KEY_RIGHTSHIFT=54 ++ KEY_KPASTERISK=55 ++ KEY_LEFTALT=56 ++ KEY_SPACE=57 ++ KEY_CAPSLOCK=58 ++ KEY_F1=59 ++ KEY_F2=60 ++ KEY_F3=61 ++ KEY_F4=62 ++ KEY_F5=63 ++ KEY_F6=64 ++ KEY_F7=65 ++ KEY_F8=66 ++ KEY_F9=67 ++ KEY_F10=68 ++ KEY_NUMLOCK=69 ++ KEY_SCROLLLOCK=70 ++ KEY_KP7=71 ++ KEY_KP8=72 ++ KEY_KP9=73 ++ KEY_KPMINUS=74 ++ KEY_KP4=75 ++ KEY_KP5=76 ++ KEY_KP6=77 ++ KEY_KPPLUS=78 ++ KEY_KP1=79 ++ KEY_KP2=80 ++ KEY_KP3=81 ++ KEY_KP0=82 ++ KEY_KPDOT=83 ++ KEY_103RD=84 ++ KEY_ZENKAKUHANKAKU=85 ++ KEY_102ND=86 ++ KEY_F11=87 ++ KEY_F12=88 ++ KEY_RO=89 ++ KEY_KATAKANA=90 ++ KEY_HIRAGANA=91 ++ KEY_HENKAN=92 ++ KEY_KATAKANAHIRAGANA=93 ++ KEY_MUHENKAN=94 ++ KEY_KPJPCOMMA=95 ++ KEY_KPENTER=96 ++ KEY_RIGHTCTRL=97 ++ KEY_KPSLASH=98 ++ KEY_SYSRQ=99 ++ KEY_RIGHTALT=100 ++ KEY_LINEFEED=101 ++ KEY_HOME=102 ++ KEY_UP=103 ++ KEY_PAGEUP=104 ++ KEY_LEFT=105 ++ KEY_RIGHT=106 ++ KEY_END=107 ++ KEY_DOWN=108 ++ KEY_PAGEDOWN=109 ++ KEY_INSERT=110 ++ KEY_DELETE=111 ++ KEY_MACRO=112 ++ KEY_MUTE=113 ++ KEY_VOLUMEDOWN=114 ++ KEY_VOLUMEUP=115 ++ KEY_POWER=116 ++ KEY_KPEQUAL=117 ++ KEY_KPPLUSMINUS=118 ++ KEY_PAUSE=119 ++ KEY_KPCOMMA=121 ++ KEY_HANGUEL=122 ++ KEY_HANJA=123 ++ KEY_YEN=124 ++ KEY_LEFTMETA=125 ++ KEY_RIGHTMETA=126 ++ KEY_COMPOSE=127 ++ KEY_STOP=128 ++ KEY_AGAIN=129 ++ KEY_PROPS=130 ++ KEY_UNDO=131 ++ KEY_FRONT=132 ++ KEY_COPY=133 ++ KEY_OPEN=134 ++ KEY_PASTE=135 ++ KEY_FIND=136 ++ KEY_CUT=137 ++ KEY_HELP=138 ++ KEY_MENU=139 ++ KEY_CALC=140 ++ KEY_SETUP=141 ++ KEY_SLEEP=142 ++ KEY_WAKEUP=143 ++ KEY_FILE=144 ++ KEY_SENDFILE=145 ++ KEY_DELETEFILE=146 ++ KEY_XFER=147 ++ KEY_PROG1=148 ++ KEY_PROG2=149 ++ KEY_WWW=150 ++ KEY_MSDOS=151 ++ KEY_COFFEE=152 ++ KEY_DIRECTION=153 ++ KEY_CYCLEWINDOWS=154 ++ KEY_MAIL=155 ++ KEY_BOOKMARKS=156 ++ KEY_COMPUTER=157 ++ KEY_BACK=158 ++ KEY_FORWARD=159 ++ KEY_CLOSECD=160 ++ KEY_EJECTCD=161 ++ KEY_EJECTCLOSECD=162 ++ KEY_NEXTSONG=163 ++ KEY_PLAYPAUSE=164 ++ KEY_PREVIOUSSONG=165 ++ KEY_STOPCD=166 ++ KEY_RECORD=167 ++ KEY_REWIND=168 ++ KEY_PHONE=169 ++ KEY_ISO=170 ++ KEY_CONFIG=171 ++ KEY_HOMEPAGE=172 ++ KEY_REFRESH=173 ++ KEY_EXIT=174 ++ KEY_MOVE=175 ++ KEY_EDIT=176 ++ KEY_SCROLLUP=177 ++ KEY_SCROLLDOWN=178 ++ KEY_KPLEFTPAREN=179 ++ KEY_KPRIGHTPAREN=180 ++ KEY_F13=183 ++ KEY_F14=184 ++ KEY_F15=185 ++ KEY_F16=186 ++ KEY_F17=187 ++ KEY_F18=188 ++ KEY_F19=189 ++ KEY_F20=190 ++ KEY_F21=191 ++ KEY_F22=192 ++ KEY_F23=193 ++ KEY_F24=194 ++ KEY_PLAYCD=200 ++ KEY_PAUSECD=201 ++ KEY_PROG3=202 ++ KEY_PROG4=203 ++ KEY_SUSPEND=205 ++ KEY_CLOSE=206 ++ KEY_PLAY=207 ++ KEY_FASTFORWARD=208 ++
Bug#496911: additional information
Michael Marsh wrote: On Sun, Aug 31, 2008 at 2:02 PM, Bart Samwel [EMAIL PROTECTED] wrote: Hi Michael, It seems to follow the right path, but the command is somehow detected as being successful without actually being successful. Could you manually run that last command: /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend and send me the output? That will tell us more about what's going wrong here. # /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend Failed to open connection to session message bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. If it matters, I boot into runlevel 2 and run startx from the console. A, that's an error I didn't anticipate. Thanks for the info, I'll try and still get a fix into lenny! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Hi Christian, Christian Perrier wrote: Quoting Raphael Hertzog ([EMAIL PROTECTED]): severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? Well, I'm indeed really sorry for putting such pressure but this is the only way to handle these things after the very very annoying decision taken by the Kernel Team when disabling /proc/acpi so close to the release. I'm still pondering raising an RC issue on linux-2.6 for /proc/acpi to be back. I know that bugs have been reassigned to various packages when they were reported but I think I would then go up to CTTE as an attempt to revert to /proc/acpi support to be reintroduced in the kernel. I only regret not doing that much earlier when I noticed that 2/3 of my power management utilities had been broken without prior notice. While working on a fix for this problem I noticed that acpi-support uses on_ac_power to find power state changes, and that has an unopened bug in this exact same area as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473629 Should we be tagging this one as serious as well? Since on_ac_power will simply not work on ACPI systems with the kernels that will ship with lenny, powermgmt-base will be badly broken. The acpi-support code is very interesting in other ways as well: it uses the broken on_ac_power to determine power state *changes* (to prevent calling scripts when nothing has changed), but then proceeds to use its own broken logic to determine the actual power state (to determine which scripts to call)... I'll have a fix ready tonight. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: setting package to acpi-support acpi-support-base, tagging 491396
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-6) unstable; urgency=high # # * /etc/acpi/battery.d is ignored on newer kernels (Closes: #491396) package acpi-support acpi-support-base tags 491396 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488937: setting package to acpi-support acpi-support-base, tagging 488937
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-6) unstable; urgency=high # # * Incorrect D-BUS HAL call in dbus-hal suspend method (Closes: ##488937) # package acpi-support acpi-support-base tags 488937 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Bart Samwel wrote: Hi Christian, Christian Perrier wrote: Quoting Raphael Hertzog ([EMAIL PROTECTED]): severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? Well, I'm indeed really sorry for putting such pressure but this is the only way to handle these things after the very very annoying decision taken by the Kernel Team when disabling /proc/acpi so close to the release. I'm still pondering raising an RC issue on linux-2.6 for /proc/acpi to be back. I know that bugs have been reassigned to various packages when they were reported but I think I would then go up to CTTE as an attempt to revert to /proc/acpi support to be reintroduced in the kernel. I only regret not doing that much earlier when I noticed that 2/3 of my power management utilities had been broken without prior notice. While working on a fix for this problem I noticed that acpi-support uses on_ac_power to find power state changes, and that has an unopened bug in this exact same area as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473629 Should we be tagging this one as serious as well? Since on_ac_power will simply not work on ACPI systems with the kernels that will ship with lenny, powermgmt-base will be badly broken. The acpi-support code is very interesting in other ways as well: it uses the broken on_ac_power to determine power state *changes* (to prevent calling scripts when nothing has changed), but then proceeds to use its own broken logic to determine the actual power state (to determine which scripts to call)... I'll have a fix ready tonight. OK, a fix has been uploaded. I guess this should hang around in unstable for a couple of days before I send it as a proposed update to the release team, right? (My experience with this process is limited, so hints are appreciated. ;-) ) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Hi Raphael, Raphael Hertzog wrote: severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? The bug is in acpid, right? I don't think I can do much else other than bug the acpid maintainer. Unless I want to go and NMU of course. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Raphael Hertzog wrote: On Mon, 18 Aug 2008, Bart Samwel wrote: Agreed. Bart, can you handle that? The bug is in acpid, right? Why? /etc/acpi/power.sh is part of acpi-support and needs to be updated to use /sys/class/power_supply/ instead of /proc/acpi/ac_adapter/ which has been removed in recent kernels (2.6.26 in Debian sid, intended for lenny)... I don't see what concerns acpid here. Oh, aaargh, I've done some bad reading here. Will get this fixed. BTW, if I fix anything for this, do I need to make a special update containing *only* a fix for this bug, or can I piggyback some other nasty bug fixes onto the update? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Hi Christian, Christian Perrier wrote: Quoting Raphael Hertzog ([EMAIL PROTECTED]): severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? Well, I'm indeed really sorry for putting such pressure but this is the only way to handle these things after the very very annoying decision taken by the Kernel Team when disabling /proc/acpi so close to the release. Yeah, that is a very annoying decision. IMO Work without /proc/acpi is something that should go in as a general release goal like the bash transition -- don't change the default in the first release, but file bugs against anything that breaks if you do. Then change the default in the next release. I'm still pondering raising an RC issue on linux-2.6 for /proc/acpi to be back. I know that bugs have been reassigned to various packages when they were reported but I think I would then go up to CTTE as an attempt to revert to /proc/acpi support to be reintroduced in the kernel. There may be much more breakage waiting to be found, and there's no time to fix it all. These kind of changes need months of testing! I only regret not doing that much earlier when I noticed that 2/3 of my power management utilities had been broken without prior notice. Of course, when it comes at acpi-support itself, I think that supporting /sysfs would be good anyway. Definitely, and it was already planned for a future update -- I just wasn't aware that this default had changed already. :-/ Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495364: laptop-mode-tools: AC_DISABLE_HAL_POLLING has wrong default value
Daniel Moerner wrote: In /etc/laptop-mode/conf.d/hal-polling.conf, the comments state that the default is to Disable HAL polling on battery and Enable HAL polling on AC. The default value for HAL polling on AC is: AC_DISABLE_HAL_POLLING=1 Either this or the comment should be changed to reflect that it HAL polling is by default disabled on AC power. Thanks Quite right, that should be fixed. I vote for changing the comment -- if people have to enable this module manually, they know where to change it back if they want it. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495208: laptop-mode-tools: Auto-hibernation not working on ThinkPad X40
Soenke wrote: Hi Bart, thanks for the quick reply. H. These events are actually hardware dependent, and if the new battery does not send them, there's not much you can do about it except perhaps polling. I was afraid that this might be the case. I checked again with acpid in debug mode, there is a battery event every 60 - 70 minutes. :( I will consider adding a polling feature to laptop mode tools; it would be something like a cron job that runs every minute or so. It's a pretty heavyweight solution though. :-/ If you install a cron job that runs /usr/sbin/laptop_mode auto every minute, I expect it works again? The cron job works fine, so a polling feature would be nice. For now, I just put a new entry into the system crontab, but I will try to find a somewhat more elegant (and perhaps configurable via the laptop-mode config files) solution for the problem over the weekend. At the moment I am not sure how to get a polling behaviour without using cron, but I might have time to look into that as well. If you are interested, I can send you my solution when it is finished. That might take a few days, though. Hi Soenke, I think this might be related to bug #491396 which I just noticed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491396 Could you perhaps try an older kernel to confirm whether you are experiencing this problem? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495208: laptop-mode-tools: Auto-hibernation not working on ThinkPad X40
Hi Soenke, Soenke wrote: it seems that the auto-hibernation feature of laptop-mode-tools (configurable via /etc/laptop-mode/conf.d/auto-hibernate.conf) does not work with my laptop (ThinkPad X40) any more. It worked a while ago, but as I have not used this option for some time, I am not sure when it stopped working. I tried several settings for AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT (as high as 20) and also enabling AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL. Regardless of these settings, the system does not exectute the command set in HIBERNATE_COMMAND but just turns off (no regular shutdown, just switched off) as the battery runs down. If I remember correctly, laptop-mode is called via acpid when a battery event is caught, checks the battery state and acts accordingly. So I tried running acpid in debug mode (for about 20 minutes, on battery), but I only got battery events when (un)plugging the AC-adapter. During normal system operation, I did not see any battery events at all. When I unplug the AC-adapter while the battery is below AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT, I get a battery event and HIBERNATE_COMMAND is executed. When just running on battery, it does not seem to work. Is there a way of triggering the battery events without plugging in the AC-adapter? I recently got a new battery for this system, maybe the problem is related to that? I cannot test the old battery as it does not work anymore. If more information is required, I will gladly supply it. H. These events are actually hardware dependent, and if the new battery does not send them, there's not much you can do about it except perhaps polling. I will consider adding a polling feature to laptop mode tools; it would be something like a cron job that runs every minute or so. It's a pretty heavyweight solution though. :-/ If you install a cron job that runs /usr/sbin/laptop_mode auto every minute, I expect it works again? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Hi Marc, Marc Haber wrote: when I wake up my notebook from Hibernation, it sometimes happens that laptop-mode tries to remount /usr and the mount wedges itself in kernel space: Eats 90 % CPU and is unkillable: acpid,4115 -c /etc/acpi/events `-lm_battery.sh,19925 /etc/acpi/actions/lm_battery.sh battery C137 0080 0001 `-laptop_mode,19926 /usr/sbin/laptop_mode auto `-laptop-mode,19982 /usr/share/laptop-mode-tools/modules/laptop-mode `-laptop-mode,19986 /usr/share/laptop-mode-tools/modules/laptop-mode `-laptop-mode,20007 /usr/share/laptop-mode-tools/modules/laptop-mode `-mount,20008 /dev/mapper/usr /mnt/usr -t ext3 -o remount,rw,commit=600 I do not have the slightest clue what happens here, so I am reporting this bug against the package which has the most scripts in the process tree in the hope that somebody with more clue can reassign. fwiw, it's reboot time in these cases :-( Thanks for reporting. I've recently had a report where remounts would hang for 20 minutes at 90% CPU before completing. Firstly, could you try letting it hang for very long (perhaps even several hours) to see if it eventually finishes? (If it is, it's the same bug as the other one. If it isn't, then it's also a kernel bug, but perhaps a different one.) Also, could you check when exactly it hangs? Is it only when you resume in a different power state (plugged vs. unplugged) than when you hibernated? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Hi Marc, Marc Haber wrote: On Tue, Jul 29, 2008 at 09:09:08AM +0200, Bart Samwel wrote: Thanks for reporting. I've recently had a report where remounts would hang for 20 minutes at 90% CPU before completing. Firstly, could you try letting it hang for very long (perhaps even several hours) to see if it eventually finishes? Tried it for like three hours this morning, didn't happen. Even a few minutes is not acceptable Also, could you check when exactly it hangs? Is it only when you resume in a different power state (plugged vs. unplugged) than when you hibernated? I had it happen without hibernation this morning when unplugging the power. So it does not look hibernation related. Then it's a kernel bug, there's nothing I can do about this. :-/ I'll reassign it (tonight). Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Marc Haber wrote: On Tue, Jul 29, 2008 at 04:33:56PM +0200, Bart Samwel wrote: Marc Haber wrote: On Tue, Jul 29, 2008 at 09:09:08AM +0200, Bart Samwel wrote: Thanks for reporting. I've recently had a report where remounts would hang for 20 minutes at 90% CPU before completing. Firstly, could you try letting it hang for very long (perhaps even several hours) to see if it eventually finishes? Tried it for like three hours this morning, didn't happen. Even a few minutes is not acceptable Also, could you check when exactly it hangs? Is it only when you resume in a different power state (plugged vs. unplugged) than when you hibernated? I had it happen without hibernation this morning when unplugging the power. So it does not look hibernation related. Then it's a kernel bug, there's nothing I can do about this. :-/ I'll reassign it (tonight). The kernel team is just going to close this since I do not use a Debian kernel. Ahhh, that's an important fact. If you are not running a Debian kernel, then you should report this to the kernel upstream. It is definitely not a bug in laptop-mode-tools -- it's not doing anything unexpected, and the kernel should be able to handle this just fine. Why is laptop-mode-tools trying to remount the file systems in the first place? Let me try to explain. Ext3 file systems (and some other journalling file systems) write to disc periodically, to flush its journal transactions. When laptop mode is enabled, laptop mode tools must tweak the mount options for ext3 to make the flush intervals larger, so that the disc doesn't spin up every 30 seconds. At resume time, some of the settings are forgotten by the hardware and/or the kernel, so laptop mode tools has to forcibly reapply all settings, including the mount options. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Hi Marc, Marc Haber wrote: On Tue, Jul 29, 2008 at 04:45:23PM +0200, Bart Samwel wrote: Marc Haber wrote: Why is laptop-mode-tools trying to remount the file systems in the first place? Let me try to explain. Ext3 file systems (and some other journalling file systems) write to disc periodically, to flush its journal transactions. When laptop mode is enabled, laptop mode tools must tweak the mount options for ext3 to make the flush intervals larger, so that the disc doesn't spin up every 30 seconds. At resume time, some of the settings are forgotten by the hardware and/or the kernel, so laptop mode tools has to forcibly reapply all settings, including the mount options. Can this behavior of laptop-mode-tools be disabled by configuration? Well, you can set CONTROL_MOUNT_OPTIONS to 0 in laptop-mode.conf. But that does mean that laptop mode won't work anymore. If you're going to do that, you might as well uninstall it... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: acpi-support: /etc/acpi/battery.d is ignored on newer kernels
Hi Jeff, Jeff King wrote: Package: acpi-support Version: 0.109-5 Severity: normal Tags: patch Newer kernels have disabled the /proc interface to power management, leaving only the /sys. However, the /etc/acpi/power.sh script makes a decision about running the scripts in battery.d by looking for ac adapters in /proc (this also affects the running of scripts in ac.d). The patch below fixes it for me (but this is the first time I have ever done anything with the /sys power interface, so I don't know how correct the method for finding ac adapters is). Looks good to me! I'll try to keep support for the old stuff as well, but I'll use the stuff in your patch for the new. Thanks for contributing! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490587: laptop-mode-tools: implement sched_mc_power_savings for SMP boxes
Hi Ritesh, Ritesh Raj Sarraf wrote: As per http://www.lesswatts.org/tips/cpu.php#smpsched, we can save some power. It will be good to have this handled by laptop-mode-tools. Thanks for the patch, consider it accepted (for upstream as well). If only all reporters were so helpful. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490167: laptop-mode-tools: Complains about missing /sys/class/power_supply/
Hi Frederik, Frederik Himpe wrote: When starting or stopping the laptop-mode service on my Apple Powerbook G4 it complains about /sys/class/power_supply which does not exist on my system. I'm using linux-image-2.6.25-2-powerpc 2.6.25-6/ powerbook:~# /etc/init.d/laptop-mode stop * Disabling laptop mode... cat: /sys/class/power_supply/*/type: No such file or directory Polling is already disabled on the given drive. [ ok ] powerbook:~# /etc/init.d/laptop-mode start * Enabling laptop mode... cat: /sys/class/power_supply/*/type: No such file or directory Polling is already disabled on the given drive. Thanks for reporting, I'll investigate. Apple testing is not my forte, not having an Apple available. :-/ I'll try and have a fix in the next update. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481766: Patch
Hi again pm-utils maintainers, Here's the file as something you can save to disk, if that makes it easier to incorporate. It should be incorporated as /usr/lib/pm-utils/sleep.d/99laptop-mode I'll be setting the priority of this one back to normal for a couple of reasons: 1. acpi-support suspend also does this. The latest versions of acpi-support defer their suspend support to pm-utils, hoping that that would be better supported than the upstream acpi-support suspend code. I'm also the maintainer of acpi-support. If this doesn't go in, I'll hack around it in acpi-support before the release. This is something which I *don't* want to do, quite simply because it *stinks*. 2. Lots of people use laptop-mode-tools to set their hard drive's APM levels, to fix this problem: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 The use of laptop mode tools is one of the common workarounds for this problem. However, if it doesn't get a chance to reprogram the hard drive on resume, these people are screwed: their supposed workaround will not work, and their hard drive will wear out without them knowing it. 3. Priority inheritance: this bug is reported as a normal bug for laptop-mode-tools that cannot be fixed within laptop-mode-tools itself. To fix it for laptop-mode-tools, this needs fixing in pm-utils. That means the actual priority should be higher than the priority purely from an intra-package standpoint. IOW, pleasepleaseplease fix this. You can also convince me that it shouldn't be fixed this way. But PLEASE don't leave this hanging in wishlist limbo. Cheers, Bart #!/bin/sh # # 99laptop-mode: Reload laptop mode case $1 in hibernate|suspend) ;; thaw|resume) if [ -e /etc/init.d/laptop-mode ] ; then invoke-rc.d laptop-mode restart fi ;; *) exit $NA ;; esac
Bug#473055: Fix Provided
Hi Sheridan, Sheridan Hutchinson wrote: Since I originally posted this bug report other users have emailed me with the same problem seeking help in resolving it, and I have created working solution for my system. I specify the problem as LTM settings not correctly being restored after a resume from hibernate or suspend, if the user is using the pmutils package. The solution was to create a file called 66LTM (attached) in /etc/pm/sleep.d/ and apply chmod +x to it. This file explicitly requires pmutils to restart LTM on resume from S3 or S4, and now LTM and pmtuils work together perfectly on my system. Janne Casserstedt worked with me on this problem and although I think he may be using Ubuntu, he has the same issue and hope that he can confirm that this fixes the problem on his machine too. Please accept my findings for consideration for incorporation into LTM. This should go into pm-utils, unfortunately. If you look at pm-utils bug #481766: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481766 you will see that I submitted a patch similar to yours about two monts ago, and the only thing they did is set it to wishlist and ignore it... Lazy maintainers, shame on them. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490246: sched_mc_power_savings
Juliusz Chroboczek wrote: Package: laptop-mode-tools Version: 1.43-1 Severity: wishlist Shouldn't laptop mode also control /sys/devices/system/cpu/sched_mc_power_savings ? Please see http://lwn.net/Articles/287524/ Thanks for bringing this to my attention, I'll add a module for it! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
