when returning from suspend my laptop tries to hibernate

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description does not yet have enough information.

Please include the following additional information, if you have not already done so (pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.
4. Please follow https://wiki.ubuntu.com/DebuggingKernelSuspend

For your reference, the full description of procedures for kernel-related bug reports is available at [WWW] http://wiki.ubuntu.com/KernelTeamBugPolicies. Thanks in advance!

justin@houston:~$ uname -a
Linux houston 2.6.22-13-generic #1 SMP Thu Oct 4 17:18:44 GMT 2007 i686
GNU/Linux

--
Sincerely

Justin Sunseri

I can confirm this is happening with me too.

Requested information:

uname -a
Linux stephen-laptop 2.6.22-12-generic #1 SMP Sun Sep 23 18:11:30 GMT 2007 i686 GNU/Linux

Further testing I've found out this happens if both suspend while on AC and hibernate while on battery are set for the same time period. When the laptop suspends while on AC and I later wake it up after unplugging the AC power, the laptop will go in to hibernation. If I play with the touchpad while the laptop is resuming, then hibernation does not occur.

Maybe in gnome-power-manager rather than the kernel?

Milan : this is still incomplete until the reporter has provided all the information asked. As suspend also fails sometimes, it's likely to be a kernel problem (at least for the original reporter).

Stephen : i think you should open a new bug report, because we can't be sure your problem is caused by the same thing. Thank you.

jerome what else do i need to provide?

--
Sincerely

Justin Sunseri

When going through the suspend resume debugging steps listed in step 4 i get
this output when trying to suspend the computer. Please keep in mind that
putting the computer into suspend works fine when using either my suspend
hot key or through the quit dialog box. IMHO it appears as though both
suspend and hibernate are being called virtually at the same time but the
suspend takes place first and as soon as the laptop returns from suspend it
continues where it left off and goes into hibernation.

Here is the output of when i try to run

sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force

as mentioned in the suspend/resume debugging documents.

--
Sincerely

Justin Sunseri

justin@houston:~$ sudo sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force
[sudo] password for justin:
bash: /sys/power/pm_trace: Permission denied
open: Permission denied
open: Permission denied
ifdown: failed to open statefile /var/run/network/ifstate: Permission denied
SIOCSIFFLAGS: Permission denied
ifdown: failed to open statefile /var/run/network/ifstate: Permission denied
SIOCSIFFLAGS: Permission denied
ifdown: failed to open statefile /var/run/network/ifstate: Permission denied
SIOCSIFFLAGS: Permission denied
Couldnt get a file descriptor referring to the console
Couldnt get a file descriptor referring to the console
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/suspend.d/80-video-vesa-state.sh: line 7: [: !=: unary operator expected
open: Permission denied
 * Shutting down ALSA... open: Permission denied
 * warning: 'alsactl store' failed with error message 'alsactl: save_state:1280: Cannot open /var/lib/alsa/asound.state for writing: Permission denied'... open: Permission denied
                                                                         [fail]
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/sleep.sh: line 39: /sys/power/state: Permission denied
Wrong chipset detected. 915resolution only works with Intel 800/900 series graphic chipsets.
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/resume.d/17-video-restore.sh: line 6: [: !=: unary operator expected
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/resume.d/35-modules-load.sh: line 7: /sys/class/firmware/timeout: Permission denied
/etc/acpi/resume.d/35-modules-load.sh: line 17: /sys/class/firmware/timeout: Permission denied
Wrong chipset detected. 915resolution only works with Intel 800/900 series graphic chipsets.
Sorry, only the superuser can change the Hardware Clock.
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
ifup: failed to open statefile /var/run/network/ifstate: Permission denied
ifup: failed to open statefile /var/run/network/ifstate: Permission denied
ifup: failed to open statefile /var/run/networ...

Please use these two commands (sudo alone only gives you admin rights for the first command):
$ sudo -s
$ sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force
(note you will need to reset your clock after reboot)
Thank you for this

Jérôme Guelfucci: Sorry, I thought the idea that g-p-m was triggering at the same time suspend and hibernate was a good hint. There may be two independent issues here too.

i still get the same error message

--
Sincerely

Justin Sunseri

I can't believe it! Could you post the whole commands and output (using an attached log would be the best way)? If 'sudo -s' got the right password and you are admin (sudoer), everything should go right...

--
Sincerely

Justin Sunseri

justin@houston:~$ sudo -s sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force
[sudo] password for justin:
/bin/sync: /bin/sync: cannot execute binary file
bash: /sys/power/pm_trace: Permission denied
open: Permission denied
open: Permission denied
ifdown: failed to open statefile /var/run/network/ifstate: Permission denied
SIOCSIFFLAGS: Permission denied
ifdown: failed to open statefile /var/run/network/ifstate: Permission denied
SIOCSIFFLAGS: Permission denied
ifdown: failed to open statefile /var/run/network/ifstate: Permission denied
SIOCSIFFLAGS: Permission denied
Couldnt get a file descriptor referring to the console
Couldnt get a file descriptor referring to the console
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/suspend.d/80-video-vesa-state.sh: line 7: [: !=: unary operator expected
open: Permission denied
 * Shutting down ALSA... open: Permission denied
 * warning: 'alsactl store' failed with error message 'alsactl: save_state:1280: Cannot open /var/lib/alsa/asound.state for writing: Permission denied'... open: Permission denied
                                                                         [fail]
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/sleep.sh: line 39: /sys/power/state: Permission denied
Wrong chipset detected. 915resolution only works with Intel 800/900 series graphic chipsets.
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/resume.d/17-video-restore.sh: line 6: [: !=: unary operator expected
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
/etc/acpi/resume.d/35-modules-load.sh: line 7: /sys/class/firmware/timeout: Permission denied
/etc/acpi/resume.d/35-modules-load.sh: line 17: /sys/class/firmware/timeout: Permission denied
Wrong chipset detected. 915resolution only works with Intel 800/900 series graphic chipsets.
Sorry, only the superuser can change the Hardware Clock.
open /dev/mem: Permission denied
Failed to initialise LRMI (Linux Real-Mode Interface).
ifup: failed to open statefile /var/run/network/ifstate: Permission denied
ifup: failed to open statefile /var/run/network/ifstate: Permission denied
ifup: failed to open statefile /var/run/network/ifstate: Permission denied
chvt: Wrong number of args
open: Permission denied
 * Setting up ALSA... open: Permission denied
                                                                         [ OK ]
FATAL: Error removing button (/lib/modules/2.6.22-13-generic/kernel/drivers/acpi/button.ko): Operation not permitted
FATAL: Error removing fan (/lib/modules/2.6.22-13-generic/kernel/drivers/acpi/fan.ko): Operation not permitted
FATAL: Error removing thermal (/lib/modules/2.6.22-13-generic/kernel/drivers/acpi/thermal.ko): Operation not permitted
FATAL: ...

Justin Sunseri : the files for 2) and 3) are missing, you have to attach them through the web interface.

Do you have admin rights on your session ?

OK ;-)
I meant "these two commands", i.e. type in 'sudo -s' then <RETURN>, and then your password, <RETURN> again and then the rest of the commands and <RETURN>. So good luck, hope we'll find something.

Sorry I thought when i sent an email with the attachments then it would attach those to the bug report.

root@houston:~# sync; echo 1 > /sys/power/pm_trace; /etc/acpi/sleep.sh force
ifdown: interface eth0 not configured
ifdown: interface eth1 not configured
 * Shutting down ALSA... [ OK ]
Starting 915resolution: 915resolution.
Function not supported
Function not supported
Starting 915resolution: 915resolution.
The Hardware Clock does not contain a valid time, so we cannot set the System Time from it.
Unable to set system clock.
Ignoring unknown interface eth1=eth1.
Ignoring unknown interface eth0=eth0.
 * Setting up ALSA... [ OK ]
FATAL: Module acpi_sbs not found.
FATAL: Module acpi_sbs not found.

here is the output from that command Milan suggested. The computer did not try to hibernate after returning from suspend. those in the dmesg output i just posted the output there did capture a time when i did hibernate after suspend

Thank you very much, we should have all we need now.

Jérôme Guelfucci: Considering the timeout is necessary for this bug to happen, I would privilege the gnome-power-manager option. What about adding an affected package?

There is no timeout needed for me though. I usually hit the suspend hot key or go through the menu

Justin : thank you, i'm marking the kernel one as triaged and assigning to the kernel team.

Milan : just added it. thanks.

I have a Dell Latitude D610 laptop which also will hibernate immediately after waking from suspend with Gutsy. I have gnome-power-manager set to sleep after 1 hour idle while on A/C power (20 minutes on battery). What happens is that my computer will suspend perfectly fine, but when I press the power button, the computer resumes, then immediately hibernates (to disk this time). When I press the power button, it boots up and resumes fine.

I will note that previous versions of GNOME used to have a "Sleep type" option on the General tab to select suspend or hibernate, but that has gone missing even in Feisty.

I have gnome-power-manager set to hibernate when the laptop lid is closed, but this hibernate immediately after waking from sleep happens without the lid being closed after suspending during idle.

Don't you have any other way to wake your laptop than pressing the power button? Maybe that's it that triggers hibernate (just an idea). Could you check in the GNOME Power Manager preferences, 'General' tab what action is selected when pressing 'power'? If 'hibernate', try choosing 'suspend'.

I've just experienced the same bug, although I hadn't set 'Hibernate' as action to perform when the timeout is reached. So actually I did the test I asked you to do. ;-) We just need a developer to look here.

In kern.log.0, there's this 3 secs after resume has been successfully performed:
kernel: [ 9672.156000] PM: suspend-to-disk mode set to 'shutdown'

I have gnome-power-manager to shutdown the system when I press the power
button. As far as I can tell, there is no setting that should cause the
system to automatically hibernate, because you can't specify to do anything
other than suspend (sleep) in gnome-power-manager.

What I would like to know is why the option to choose suspend or hibernate
when idle disappeared, but that is irrespective of this bug. :-)

It didn't disappear at all, in every combo box you can choose nothing, suspend, hibernate, turn off the screen (approximate translation). If you haven't those, this may mean that you have a problem either in g-p-m or in your acpi support (which I can't find in your dmesg, but I'm not an expert). We need a g-p-m specialist/developer here.

Michael: Could you check everything that is listed here: (if you don't mind) http://live.gnome.org/GnomePowerManager/FAQ#head-5d4d7bb306ca154c956e3ef69dae036942f6cf40

Justin: Is this the same for you (i.e. you can't choose anything other than 'sleep' in the power management preferences)?

Much thanks you two

# gconftool-2 -R /apps/gnome-power-manater | grep can
 can_hibernate = true
 can_suspend = true

Both suspend and hibernate work when I manually use them from the GNOME
"Quit" button. The system also properly hibernates when I close the
laptop lid.

I'm not sure if this screenshot is up to date:

http://www.gnome.org/projects/gnome-power-manager/gpp.html

If you look at the "Global Options" window, that "Sleep type when
inactive" option is missing on my system. I will note that it is also
missing on my desktop system (IBM ThinkCentre M50). It is also missing
in Feisty.

So, on this system, there is no way for the user to configure the system
to choose between hibernate and suspend when inactive. What happens is
that it first suspends, then hibernates immediately when I resume from
suspend.

Well, you can't set what g-p-m will do when the timeout is reached, it will always suspend, but you can choose what to do when 1) the lid is closed 2) power or standby buttons are pressed.
So there's no issue on this side on your computer. I think I can't help more, please just wait for somebody to investigate this further.

You may provide the output of 'sudo dmidecode', and your /var/log/kern.log.0 file, this might explain what happens before the computer hibernates.

This sounds like a duplicate of Bug #136871 .

Same happens to me on a fresh Gutsy install on a Dell Inspiron 9400 / E1705.
Also when back from hibernation no password is required!!

The next time I tried to reproduce the error suspend failed and when back it tries to suspend/hibernate but also failed.
Below I attach the result of "sudo lspci -vvnn" and my kern.log and acpid.log after I tried this.

uname -a:
Linux Vanquish 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

After I restarted I managed to reproduce the bug.
On AC power and automatic sleep enabled it suspends correctly, but when it returns from suspend my laptop hibernates, it also hibernates OK, but when back it is not asking for the login password.

Below is the kern.log and acpid log, hope it helps.

>
> I know I had my computer set to suspend the laptop when it was inactive
> for one hour when plugged in to the AC adapter. Once i removed this setting
> I have not had the problem since.

I am having the same problem except that since my laptop cannot hibernate with feisty or gutsy Ubuntu, (It worked in edgy Ubuntu). And hibernation causes swap file corruption I have to reformat my swap partition and 'sudo swapon /dev/sda3' and so I have disabled hibernation in gnome-power-manager using gconf-editor.
which prevents the problem reoccurring. so the problem with hibernate being called after suspend is a problem with gnome-power-manager, since changing its settings stops the problem.
However I cannot hibernate and so I attach the relevant log files etc.
Only one attachment at a time? oh well.

I also have this problem, running the latest Gutsy on my desktop machine.

This bug really needs to be moved to gnome-power-manager. After disabling
can_hibernate in the gnome-power-manager section with the gconf editor i no
longer have the problem.

Closing the kernel bug task.

Bumping gnome-power-manager task to high.

I have the same configuration as Michael Elkins (Dell Latitude D610), and I am experiencing the same problem. I reported it as Bug #152735, before I realized (a) it only happens when gnome-power-manager suspends the machine, not when I do it by hand; and (b) the system is hibernating, not shutting down. (I use an encrypted swap partition, so hibernation does not actually work... Which is why I thought the machine was shutting down.)

i'm waiting for upstream to release 2.20.1, since its filed and fixed upstream i expect the fix to be in there, please be patient :)

My short experience of ubuntu is almost satisfying, mainly because I'm learning a lot about my OS.
But looking the huge number of post, and the variety of their subject, I'm quite affraid for my hardware (power management, hard disk..).

To summarize : the power management doesn't work well with gutsy + kernel 2.6.22,
I give you some detail in the following, comparing how it works with feisty and gutsy

My laptop is a Lenovo 3000 C200 8922AZG

I have first intalled Feisty with kernel 2.6.20-15 and then 2.6.20-16 without problems :
- wifi proprietary driver works with ndiswrapper
- sound chipset driver has to be install manualy with realtek add-on.
- special buttons and power management (sleep/hibernation/resume) works well

I try migration from Feisty to Gutsy but I encountered some problems :
- first a freeze of the installation with alternate CD, so I use network install
And with kernel 2.6.22 :
- conflict between nidiswrapper installation and the new management of proprietary driver.
- the main problem is the power management
One or two times, after entering in sleep mode, the system doesn't resume but goes into hybernation... After wake up (with power button), the "half moon" diode continue to light even after entering gnome session...
BUT with the 2.6.20 kernel : the power management works normally.

NOW, with a clean installation of Gutsy, using desktop CD :
- the sound (integrated Intel HDA realtek) works directly and seems to works normally (headphone mic...).
BUT : the chipset caracteristics are not the same under Feisty (ALC862) and Gutsy (ALC861VD) !!

- the wifi proprietary driver works with bcm43xx-cutter
BUT : the hard switch desactivate the connection but doesn't stop lightening

- with both AC or battery supply : after entering in sleep or hibernation mode it's impossible to resume normally. I'm obliged to shutdown using the power button.
This point is the most important : it was working well with kernel 2.6.20 (Gutsy or Feisty) so I think that the 2.6.22 kernel is in cause...;

There is one bug in the syslog which present with kernel 2.6.22 and was not with kernel 2.6.20 :
[ 0.000000] ACPI: BIOS bug: multiple APIC/MADT found, using 0

and other lines looks strange (I do understand nothing!!):
[ 0.000000] ACPI: If "acpi_apic_instance=2" works better, notify <email address hidden>
[ 15.534057] ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
[ 18.289957] Failure registering capabilities with primary security module.
[ 18.311924] ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126]
[ 18.319217] ACPI Exception (thermal-0400): AE_NOT_FOUND, Invalid active threshold [0] [20070126]

I also notice that powernowd doesn't works (I'm cheking, but I suppose it's the same cause)

I don't no what to do to make hardware working properly (compile or change(?) kernel ??..)

I apologize for my poor english (I'm a Fu... Froggy!!, funny?)

Could you to solve this hardware problems, and Ubuntu Gutsy (kernel 2.6.22) would be perfect !!

thanks,

I am not sure that my problem is the same problem that is discussed here, but my desktop certainly tries to hibernate after returning from a suspend by gnome-power-manager. I have attached the output of "gnome-power-manager --no-daemon --verbose" (going through two cycles of suspend&hibernate). There are several failed assertions reported; I believe this could be useful information to pinpoint the cause of this problem.

~> uname -a
Linux atrejoe 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux

Related Bug #61201

Related bug #116826
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/116826

@Johan Cockx

I don't see where GPM is emitting the hibernate signal. It looks to me like it is registering an error, but I don't see it trying to hibernate. Am I missing something in the log there.

Could others post the similar log? I've looked through the GPM code and it isn't obvious how it could be hibernating after a suspend. I'm suspect to believe it is at a lower level in the stack. (i.e. the kernel, which is also include on this bug)

Dear Ted,

If there is any other useful information that I could provide to you,
please tell me. I appreciate your effort to try to solve this bug. I
am not familiar with the Ubuntu source code, so it is hard for me to
know what information could be useful for you.

Best regards,
Johan Cockx

On Thu, Mar 13, 2008 at 1:08 AM, Ted Gould <email address hidden> wrote:
> @Johan Cockx
>
> I don't see where GPM is emitting the hibernate signal. It looks to me
> like it is registering an error, but I don't see it trying to hibernate.
> Am I missing something in the log there.
>
> Could others post the similar log? I've looked through the GPM code and
> it isn't obvious how it could be hibernating after a suspend. I'm
> suspect to believe it is at a lower level in the stack. (i.e. the
> kernel, which is also include on this bug)
>
>
> ** Changed in: gnome-power-manager (Ubuntu)
> Status: New => Invalid
>
>
>
> --
> when returning from suspend my laptop tries to hibernate
> https://bugs.launchpad.net/bugs/149665
> You received this bug notification because you are a direct subscriber
> of the bug.
>

It's been my experience that if you disable hibernation as an option in
g-p-m then this problem goes away. This leads me to believe that the issue
is not in the kernel it self. Maybe I'm just crazy though.

--
Sincerely

Justin Sunseri

I can confirm the experience of Justin: disabling hibernation in g-p-m leads to no problems with coming back from standby.
Also saw that other people found out the same thing.

On Thu, 2008-03-13 at 19:43 +0000, Justin Sunseri wrote:
> It's been my experience that if you disable hibernation as an option in
> g-p-m then this problem goes away. This leads me to believe that the issue
> is not in the kernel it self. Maybe I'm just crazy though.

How are you disabling hibernation as an option? Setting gconf
key /apps/gnome-power-manager/general/can_hibernate to false? Could you
generate a GPM log for both of the scenarios (one with it on and one
with it off). I think that would be very helpful in figuring out what
is going on different between the two situations.

 Thanks,
  Ted

Ted,

I think that your question should be answered by Justin or Peter. I
have never tried to disable hibernation.

Justin, Peter, can you help Ted?

Regards,
Johan Cockx

On Fri, Mar 14, 2008 at 6:45 AM, Ted Gould <email address hidden> wrote:
> On Thu, 2008-03-13 at 19:43 +0000, Justin Sunseri wrote:
> > It's been my experience that if you disable hibernation as an option in
> > g-p-m then this problem goes away. This leads me to believe that the issue
> > is not in the kernel it self. Maybe I'm just crazy though.
>
> How are you disabling hibernation as an option? Setting gconf
> key /apps/gnome-power-manager/general/can_hibernate to false? Could you
> generate a GPM log for both of the scenarios (one with it on and one
> with it off). I think that would be very helpful in figuring out what
> is going on different between the two situations.
>
> Thanks,
> Ted
>
>
>
> --
> when returning from suspend my laptop tries to hibernate
> https://bugs.launchpad.net/bugs/149665
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Sorry for the delay. Planning to look at this bug tomorrow for a GPM log for both of the scenarios.

Ok, I just reread this thread and need to state that I personally have no problems with the swap file. When auto-suspending on Gutsy, my PC hibernates after coming out of that suspendstate, and after restarting, it will correctly come out of hibernation.

Today I have tried out the suspend functionality in Hardy 64bit and I did not have any problems. However, in Gutsy I do still have. It looks like GPM has updated/corrected some bugs upstream and those are available for Hardy now.

==GPM verbose==
On Linux ***.lan 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux, Gutsy.
Suspend AND Hibernate always fails, according to GPM verbose, but in reality it works. Somehow Gutsy's GPM doesn' t record correctly that Suspend did not fail, and therefore moves into hibernation mode, and even that fails when you come out of it according to the log. If you disable hibernation in gconf /apps/gnome-power-manager/general/can_hibernate , and disable the error messages you can use GPM without effective problems, GPM just gives a bunch of errors when returning out of suspend, but the user won' t see them.

Relevant sections out of the GPM logs on Gutsy 64bit, NVIDIA 169.12 64bit from Nvidia's site (Gutsy's version did always restart X when coming out of hibernation, so I couldn't get the logs). (Note, the errrors are false, since the suspend did work correctly)

gpm_control_suspend] gpm-control.c:451 (12:38:04): emitting sleep-failure
[..]
[gpm_notify_create] gpm-notify.c:124 (12:38:04): libnotify: Power Manager : Your computer failed to suspend.
[..]
[idle_do_sleep] gpm-manager.c:736 (12:38:04): cannot suspend, so trying hibernate
[..]
[gpm_control_hibernate] gpm-control.c:528 (12:41:48): emitting sleep-failure
[..]
[gpm_notify_create] gpm-notify.c:124 (12:41:48): libnotify: Power Manager : Your computer failed to hibernate.
[..]
[idle_do_sleep] gpm-manager.c:739 (12:41:48): cannot suspend or hibernate!

It also didn't matter if I returned from suspend in 5 seconds or > 1 min.

FYI: I removed all the gconf options for gnome-power-manager and did a sudo apt-get install --reinstall gnome-power-manager. All settings are default, only edited the timeouts so it would auto-suspend in 1+1 minutes.

Cannot follow instructions for DebuggingKernelSuspend, since the standard Ubuntu Kernel 64bit somehow doesn't give me a /sys/power/pm_trace file-thingy. So that' s all folks. :)

$ ls /sys/power/
disk image_size resume state

Hello Ted,

I have the impression that Peturrr is sending his information to the wrong
person, so I am forwarding it to you. See below. If you already have this
information, please tell me and I will not forward future mails from
Peturrr.

Regards,
Johan Cockx

Forwarded conversation
----------
From: *Peturrr* <email address hidden>
Date: Wed, Mar 26, 2008 at 9:19 PM
To: <email address hidden>

Sorry for the delay. Planning to look at this bug tomorrow for a GPM log
for both of the scenarios.

--
----------
From: *Peturrr* <email address hidden>
Date: Thu, Mar 27, 2008 at 2:15 PM
To: <email address hidden>

** Attachment added: "gpm.log.suspend.working.hardy-64bit"
  http://launchpadlibrarian.net/12920478/gpm.log.suspend.working.hardy-64bit
----------
From: *Peturrr* <email address hidden>
Date: Thu, Mar 27, 2008 at 2:18 PM
To: <email address hidden>

FYI: I removed all the gconf options for gnome-power-manager and did a
sudo apt-get install --reinstall gnome-power-manager. All settings are
default, only edited the timeouts so it would auto-suspend in 1+1
minutes.
----------
From: *Peturrr* <email address hidden>
Date: Thu, Mar 27, 2008 at 2:14 PM
To: <email address hidden>

** Attachment added: "dmesg.suspend.hibernate.failing.gutsy-64bit"

http://launchpadlibrarian.net/12920476/dmesg.suspend.hibernate.failing.gutsy-64bit
----------
From: *Peturrr* <email address hidden>
Date: Thu, Mar 27, 2008 at 2:14 PM
To: <email address hidden>

** Attachment added: "gpm.log.suspend.hibernate-disabled.failing.gutsy-64bit
"

http://launchpadlibrarian.net/12920471/gpm.log.suspend.hibernate-disabled.failing.gutsy-64bit
----------
From: *Peturrr* <email address hidden>
Date: Thu, Mar 27, 2008 at 2:13 PM
To: <email address hidden>

Ok, I just reread this thread and need to state that I personally have
no problems with the swap file. When auto-suspending on Gutsy, my PC
hibernates after coming out of that suspendstate, and after restarting,
it will correctly come out of hibernation.

Today I have tried out the suspend functionality in Hardy 64bit and I
did not have any problems. However, in Gutsy I do still have. It looks
like GPM has updated/corrected some bugs upstream and those are
available for Hardy now.

==GPM verbose==
On Linux ***.lan 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008
x86_64 GNU/Linux, Gutsy.
Suspend AND Hibernate always fails, according to GPM verbose, but in reality
it works. Somehow Gutsy's GPM doesn' t record correctly that Suspend did not
fail, and therefore moves into hibernation mode, and even that fails when
you come out of it according to the log. If you disable hibernation in gconf
/apps/gnome-power-manager/general/can_hibernate , and disable the error
messages you can use GPM without effective problems, GPM just gives a bunch
of errors when returning out of suspend, but the user won' t see them.

Relevant sections out of the GPM logs on Gutsy 64bit, NVIDIA 169.12
64bit from Nvidia's site (Gutsy's version did always restart X when
coming out of hibernation, so I couldn't get the logs). (Note, the
errrors are false, since the suspend did work correctly)

gpm_control_suspend] gpm-control.c:451 (12:38:04): emitting
sleep-fail...

In Hardy (fresh install, only keeping per-user config files) I'm no longer experiencing this. Is it still a problem for someone here?

This problem seems fixed for me too (Hardy fresh install)

My laptop runs under Gutsy :

1. With the kernel 2.6.22-14-generic :
- resume from suspend failled : depending on package and option resume failled or computer goes to hibernation.
- hibernation worked some times, but not really stable

2. With the kernel 2.6.24-16-generic (not a fresh install of Hardy, only kernel installation over Gutsy) :
- suspend/resume works fine if I don't wait too much before to wake up.
BUT after a long sleep time (I have to test futher how much, maybe only a few minutes?...), the system doesn't resume correctly : instead of resuming it goes into hibernation...
when I it wake up (using power button), everything resume as for hibernation (ok, but without wifi), except that there is no window asking me the password (the gnome session open directly...) and there is also a message window like "sleep failled".
- hibernation/resume work fine, except the wifi connexion, which doesn't come back on resume.

So nothing really new : as mentioned it in a previous post, it's certainly a bug in gnome-power-manager : changing kernel fixes the suspend/resume problem, but not this resume->hibernation problem.

Can I do anything to fix it ?
Is it possible :
- to simply modify some settings ?
- to update only gnome-power-manager ?

let me know if I can do anything to further report.

chourave: It looks like this is fixed in Hardy for at least two of us. Backporting the fix to Gutsy may not be really easy, since gnome-power-manager is likely to depend on many libraries from GNOME 2.22. You can ask upstream to find out whether they applied a patch or not, but the linked bug does not mention any.

But this may still have been fixed by pm-utils (which are not in Gutsy) or something else...

Any news on this bug? Does anybody experience it in Hardy or Intrepid? Please report so we can close it.

Both suspend and hibernate are now working properly for me in Hardy.

I can confirm that it STILL exists in Hardy:

Dell XPS m1330 running 8.04 w/latest
kernel version 2.6.24-19 because so far *all later versions of the kernel break suspend/hibernate completely*

Here's when it happens:
Suspend on demand resumes normally
Suspend after preset time, via g-p-m causes hibernate on resume

For a long time this bug didn't exist, but it seems to have (re)appeared(?) sometime in the last month or two

ethanay: maybe the fix came from a newer kernel than the one you're using. You should report a bug for your suspend/hibernate problems, it is specific to your hardware. Could you also check with an older kernel, since you say it has reappeared? Finding the version/patch that brought it back would be really useful.

I am doubtful that it is kernel-related -- I've been running 2.6.24-19 much longer than when I remember this bug appearing on my system!

But anyway, I will, test an older version and see if the problem goes away (or is masked by other problems...heh). Is there a particular version you want me to test?

Maybe I will try to report a bug (or several bugs) for the problems I am experiencing with the new kernels, but I am just an end user and feel like I am in over my head as it is, and the problems seem complicated that it's hard to recognize and understand them all.

(Yet again I'm annoyed by the forward duping that has taken place on this bug. Milan: Please dup bugs against the OLDER version wherever possible)
This bug almost certainly ISN'T kernel related. If you look related bugs at the top of this report you can see an upstream GNOME bug has been linked to ( http://bugzilla.gnome.org/show_bug.cgi?id=486138 ).

Sistofe: sorry for the dup, but as ethanay was the only person still reporting problems with this bug and this one was already quite long, I thought it would be easier to continue the discussion here. Not really a big deal, IMHO.
And I've seen the remote watch in g-p-m; actually I commented twice there. The point is, everybody but ethanay agreed that the bug was fixed. As nothing has normally been introduced in g-p-m in Hardy, it was not stupid to think the kernel fixed something.

ethanay: If you're sure you did not upgrade your kernel in the period the bug reappeared, it's not a kernel bug. Can you have a look in Synaptic (System->Administration), in the File->History menu you have a list of package upgrades. If you find that gnome-power-manager was upgraded around the time the bug came back, then please report the versions. Please do the same for the d-bus package.
If there's no such upgrade, I'm not sure what we can do. No idea of another change you made? Are you sure the bug had disappeared?

No upgrades shown for gnome-power-manager

However, two upgrades for dbus right around the time the bug seemed to appear:
1. 10/15/2008
dbus (1.1.20-1ubuntu2) to 1.1.20-1ubuntu3.1
dbus-x11 (1.1.20-1ubuntu2) to 1.1.20-1ubuntu3.1
libdbus-1-3 (1.1.20-1ubuntu2) to 1.1.20-1ubuntu3.1

2. 11/12/2008
dbus (1.1.20-1ubuntu3.1) to 1.1.20-1ubuntu3.2
dbus-x11 (1.1.20-1ubuntu3.1) to 1.1.20-1ubuntu3.2
libdbus-1-3 (1.1.20-1ubuntu3.1) to 1.1.20-1ubuntu3.2

Before that, the last upgrade was back in May 2008.

hope this helps!

Is anybody else experiencing this bug here? I can't believe I has reappeared only for ethanay...

good news! I have upgraded to kernel 2.6.24-23 and the other problems I have been experiencing appear to be resolved. So I will now test for this bug and report back on behavior:

1. let g-p-m put computer to sleep (suspend) automatically after 45 minutes
2. leave the computer asleep overnight (about minimum 10hrs)
3. resume the computer

either it will hibernate or it won't :) i'll report back and let you know!

ethanay: Any news? Anyway, upstream said they wouldn't care about version 2.22 because it's too old, so that's not really good for you... ;-)

yes, it appears resolved on my computer!

thanks for the reminder, forgot about this :)

Unfortunately, I can confirm this bug is *still present* on my Dell XPS m1330 running Hardy 8.04.2 w/latest

2.6.24-24-generic #1 SMP Wed Apr 15 15:54:25 UTC 2009 i686 GNU/Linux

Last night, I left my computer idle, and it automatically went into suspend. I left it that way all night and into the next day (over 12 hours) and upon waking the computer, it went immediately into hibernate.

I don't know if my previous test was insufficient or if there was a regression...

Ethan

Maybe the 12h delay is in cause. Do you do this often? If you want, you can try once again to see if that's the cause of the bug.

But the problem here is that Ubuntu ships with a version of gnome-power-manager that is no longer developed upstream, so they won't consider our bugs. If it only occurs once in a long while, I'd suggest we wait for the next release...