Your message dated Sun, 19 Oct 2008 13:24:12 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#502634: acpi-support: Last update fixed the issue
has caused the Debian Bug report #502634,
regarding acpi-support: sleep key first hibernates, then suspends
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
502634: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502634
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: acpi-support
Version: 0.109-9
Severity: normal
I have a Sid installation with no changes made to configuration files related
to suspension/hibernation. I'm not running any power management software for
KDE or GNOME.
When I press the sleep key on my laptop keyboard, the computer goes into
hibernation (suspend to disk), with s2disk issuing progress messages on the
console. When the laptop is booted, the state is successfuly recovered, but
then it automatically proceeds to suspend to RAM. When the computer is woken
up by a keypress, the state is finally recovered successfuly.
I'm also able to abort s2disk by pressing the backspace key while snapshotting,
and then the computer proceeds to suspend to RAM. I find this behaviour a
little cumbersome but still OK, assuming that both methods are tried and the
user could prefer suspending to hibernation. What doesn't make sense to me is
that suspension is tried after a *successful* (i.e. not aborted) hibernation.
Is this made on purpose or is there something strange going on with my
(default) setup? 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=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages acpi-support depends on:
ii acpi-support-base 0.109-9 scripts for handling base ACPI eve
ii acpid 1.0.6-14 Utilities for using ACPI power man
ii dmidecode 2.9-1 Dump Desktop Management Interface
ii finger 0.17-12 user information lookup program
ii hdparm 8.9-2 tune hard disk parameters for high
ii laptop-detect 0.13.7 attempt to detect a laptop
ii libc6 2.7-15 GNU C Library: Shared libraries
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii powermgmt-base 1.30+nmu1 Common utils and configs for power
ii vbetool 1.0-3 run real-mode video BIOS code to a
ii x11-xserver-utils 7.3+5 X server utilities
Versions of packages acpi-support recommends:
ii dbus 1.2.1-3 simple interprocess messaging syst
ii hal 0.5.11-5 Hardware Abstraction Layer
ii nvclock 0.8b3-1 Allows you to overclock your nVidi
ii pm-utils 1.1.2.4-1 utilities and scripts for power ma
ii radeontool 1.5-5 utility to control ATI Radeon back
ii toshset 1.73-2 Access much of the Toshiba laptop
Versions of packages acpi-support suggests:
pn laptop-mode-tools <none> (no description available)
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Ivan,
Ivan Vilata i Balaguer wrote:
> Package: acpi-support
> Followup-For: Bug #502634
>
>
> I wonder why, but it looks that the very last kernel, acpi-support or another
> related package update (from the last few days) fixed the issue, i.e. waking
> up
> from hibernation doesn't proceed to suspend to RAM.
>
> This is what happens when suspend to RAM works, rebooting the system gets very
> rare. ;) Sorry for the noise.
Weird -- there's been no updates to acpi-support, pm-utils, uswsusp or
gnome-power-management, so it must be the kernel? I'm closing this bug
report for now then, please reopen it if the behaviour reappears!
Cheers,
Bart
--- End Message ---
