Feisty reports suspend failed after resuming from suspend

[Matt Weller]

After upgrading to Feisty I occasionally get a message stating that there was a problem with suspend and Ubuntu was not able to enter suspend mode. However, I get this message after resuming from suspend. So suspend is working but something thinks it's failing. This does not always happen. Seems to be fairly random.

HP nx7000 laptop

[Matt Weller (gapplewagen)]

Oops, here may be some relevant information.

Linux gapplewagen 2.6.20-9-386 #2 Mon Feb 26 02:58:41 UTC 2007 i686 GNU/Linux

See attachments for dmesg and lspci

[Matt Weller (gapplewagen)]

lspci-vvnn.log

[Ben Collins (ben-collins)]

No idea why the desktop would think that, but since it's obviously wrong... :)

[Oliver (lobohacks)]

I can confirm this bug,
same thing here on my dell 640m!

here is what /var/log/messages says:
Apr 1 14:52:25 inspiron gnome-power-manager: (oliver) An unknown error occured code='32' quark='g-exec-error-quark'

One thing i noticed:
I have a dual core cpu and in /var/log/kern.log only cpu1 is send to suspend/resume.
see attachment

thx oliver

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

I can also confirm this (single-core amd64 cpu, running current Feisty). The relevant lines in syslog from my most recent suspend/resume:

Apr 2 21:54:51 localhost gnome-power-manager: (j) Suspending computer because the lid has been closed on ac power
Apr 3 10:40:49 localhost gnome-power-manager: (j) An unknown error occured code='32' quark='g-exec-error-quark'
Apr 3 10:40:59 localhost gnome-power-manager: (j) Resuming computer
Apr 3 10:40:59 localhost gnome-power-manager: (j) suspend failed

[Mariano Draghi (chaghi)]

I can confirm this, on my Dell Inspiron 640m.
As soon as the laptop enters sleep mode (display, disks, fans, everything shutdowns ok, and the power led starts to blink), it wakes up again, and after unlocking the screen, a g-p-m alert informs me that the computer couldn't suspend.

This is some kind of regression, because it worked as expected width Edgy.

Suspend to disk on the other hand works ok.

I opened a new bug about my problem yesterday (see #112659), but after further diggin' on launchpad, now I'm afraid that bug is a duplicate of this one.

[Nicolas M (nicolas-martin-gmail)]

I can confirm also this bug, on an old AMD Athlon 1700. Never encountered before with Edgy.

Here is an extract from /var/log/messages, during an hibernation session.
Note: I get this occasionally weird message from gnome-power-manager, both after hibernate and suspend
Note: the gnome-power-manager unknown error 32 message seems to be the first log into /var/log/messages after exiting hibernation.

May 7 08:25:25 nico gnome-power-manager: (nicolas) Hibernation de l'ordinateur car La méthode DBUS Hibernate(
) a été appelée
May 7 08:25:27 nico kernel: [ 1418.321456] ACPI: PCI interrupt for device 0000:00:0e.0 disabled
May 7 19:36:44 nico gnome-power-manager: (nicolas) An unknown error occured code='32' quark='g-exec-error-qua
rk'
May 7 19:36:44 nico kernel: [ 1420.222199] Disabling non-boot CPUs ...
May 7 19:36:44 nico kernel: [ 1420.222206] Stopping tasks ... done.
May 7 19:36:44 nico kernel: [ 1420.457331] Shrinking memory... ^H-^H\^H|^H/^Hdone (38494 pages freed)
May 7 19:36:44 nico kernel: [ 1421.318856] Freed 153976 kbytes in 0.86 seconds (179.04 MB/s)
...
May 7 19:36:46 nico gnome-power-manager: (nicolas) Reprise de l'ordinateur
...
May 7 19:36:46 nico gnome-power-manager: (nicolas) hibernate failed

[nino (launchpad-nino)]

I also get this bug on an Intel P915GM chipset laptop with a Celeron M processor. For all intents and purposes the suspends seems to work fine - everything shuts down and the power led starts blinking, indicating the computer is sleeping, and when I resume the battery isn't drained more than expected.

From syslog, edited for brevity, full log attached:
Jun 10 01:15:46 molotov gnome-power-manager: (nino) Suspending computer because the DBUS method Suspend() was invoked
-- snipped messages from network interfaces going down, DHCP releases etc --
Jun 10 01:15:59 molotov kernel: [ 2687.540000] ACPI: PCI interrupt for device 0000:02:00.0 disabled
Jun 10 01:15:59 molotov kernel: [ 2687.664000] ACPI: PCI interrupt for device 0000:06:02.0 disabled
Jun 10 08:02:14 molotov gnome-power-manager: (nino) An unknown error occured code='32' quark='g-exec-error-quark'
Jun 10 08:02:14 molotov gnome-power-manager: (nino) Resuming computer
Jun 10 08:02:14 molotov gnome-power-manager: (nino) suspend failed
Jun 10 08:02:14 molotov kernel: [ 2690.256000] PM: Preparing system for mem sleep
Jun 10 08:02:14 molotov kernel: [ 2690.256000] Disabling non-boot CPUs ...
Jun 10 08:02:14 molotov kernel: [ 2690.256000] Stopping tasks ... done.
Jun 10 08:02:14 molotov kernel: [ 2691.028000] Suspending console(s)

Here the computer seems to be entering suspension again, after the fact? lots of suspend messages edited out...

Jun 10 08:02:14 molotov kernel: [ 2692.688000] pci 0000:00:02.1: suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] pci 0000:00:02.0: suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] agpgart-intel 0000:00:00.0: suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] acpi acpi: suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] ACPI: Transitioning device [FAN0] to D0
Jun 10 08:02:14 molotov kernel: [ 2692.688000] ACPI: Transitioning device [FAN0] to D0
Jun 10 08:02:14 molotov kernel: [ 2692.688000] PM: Entering mem sleep
Jun 10 08:02:14 molotov kernel: [ 2692.688000] platform bluetooth: LATE suspend
-- snipped --
Jun 10 08:02:14 molotov kernel: [ 2692.688000] HDA Intel 0000:00:1b.0: LATE suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] pci 0000:00:02.1: LATE suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] pci 0000:00:02.0: LATE suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] agpgart-intel 0000:00:00.0: LATE suspend
Jun 10 08:02:14 molotov kernel: [ 2692.688000] Back to C!
Jun 10 08:02:14 molotov kernel: [27059.688000] agpgart-intel 0000:00:00.0: EARLY resume
Jun 10 08:02:14 molotov kernel: [27059.688000] pci 0000:00:02.0: EARLY resume
Jun 10 08:02:14 molotov kernel: [27059.688000] pci 0000:00:02.1: EARLY resume
Jun 10 08:02:14 molotov kernel: [27059.688000] HDA Intel 0000:00:1b.0: EARLY resume
-- snipped --
Jun 10 08:02:14 molotov kernel: [27059.688000] platform bluetooth: EARLY resume
Jun 10 08:02:14 molotov kernel: [27059.688000] PM: Finishing wakeup.
Jun 10 08:02:14 molotov kernel: [27059.688000] acpi acpi: resuming
Jun 10 08:02:14 molotov kernel: [27059.688000] ACPI: [Power Resource - CTHT] resume failed: -8
Jun 10 08:02:14 molotov kernel: [27059.688000] ACPI: Transitioning device [FAN0] to D3
Jun 10 08:02:14 molotov ker...

[OpenMindDJ (mrothlein)]

Confirmed on Dell Dimension 4500.

The computer returns from suspend with an errors in the log stating,
"Jun 12 07:02:53 Ubuntu gnome-power-manager: An unknown error occured code='32' quark='g-exec-error-quark'
Jun 12 07:02:53 Ubuntu gnome-power-manager: Resuming computer
Jun 12 07:02:53 Ubuntu gnome-power-manager: suspend failed

Oh and "occured" is spelled wrong. :)

[Turbo Fredriksson (turbo-bayour)]

I have (had) the same problem with a up-to-date Feisty, but I managed to find a workaround. I created the file /etc/acpi/local/lid.sh.post with the following content

----- s n i p -----
#!/bin/sh

grep -q closed /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
    # Lidstate = closed
    /sbin/s2ram -f -s -p -a 2
fi
----- s n i p -----

Then I installed the 'uswsusp' package. I had to use all the params to s2ram because my MacBook was not detected/unknown:

----- s n i p -----
Machine is unknown.
This machine can be identified by:
    sys_vendor = "Apple Computer, Inc."
    sys_product = "MacBook2,1"
    sys_version = "1.0"
    bios_version = " MB21.88Z.00A5.B00.0610192027"
----- s n i p -----

This worked like a charm! It took only one or two seconds until the machine was in a suspended state, and wakeup was also quick...

[Turbo Fredriksson (turbo-bayour)]

Oups, sorry. Didn't test it throughly! It suspended even if the power was connected. I only want the suspend when on battery, not on AC. So I modified it like this instead:

----- s n i p -----
#!/bin/sh

grep -q off-line /proc/acpi/ac_adapter/ADP1/state
AC=$?

grep -q closed /proc/acpi/button/lid/*/state
LID=$?

if [ $AC = 0 -a $LID = 0 ]; then
    # Lidstate = closed
    /sbin/s2ram -f -s -p -a 2
fi
----- s n i p -----

I also had to add this snippet to the /etc/acpi/power.sh so that suspend works when the lid is closed (on AC) and the power is disconnected.

[Guido Conaldi (guido-conaldi)]

I have the same issue on my vaio vgn-s1xp running current gusty i686 since the last g-p-m update.

[David Erosa (erosa)]

I can confirm this bug too on a iBook G4 (powerpc). After being successfully suspended and resumed, g-p-m reports that something went wrong and could not suspend.

[Jamie Strandboge (jdstrand)]

I have been seeing this on latest gutsy as well. All I have in the logs are:
Sep 16 08:37:11 lupin gnome-power-manager: (james) Resuming computer
Sep 16 08:37:11 lupin gnome-power-manager: (james) suspend failed

However this is *after* a suspend then resume. Everything after the resume seems fine (except I have to manually restart Network Manager-- but there are other bugs for this)

[Jamie Strandboge (jdstrand)]

I should mention I have an IBM T42.

[jbj (jbj-ubu)]

I have seen the problem in Gutsy, and two things are broken:
/etc/acpi/suspend.d/55-down-interfaces.sh:
When it tries to ifdown interfaces that are brought up not through ifup/ifdown, it turns into a 'suspend failure".

/etc/acpi/resume.d/72-acpi-pain.sh:
It tries to unload/load acpi_sbs. No such module exists. The correct name is "sbs".

I fixed the 72-acpi-pain.sh script on my system, and 55-down-interfaces I hacked on a workaround tied to my setup, and that makes the Gutsy problem go away.

BTW, the ultimate debug step for me was:
dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0

[gcc (chris+ubuntu-qwirx)]

My Thinkpad X31 fails to suspend when closing the lid (sleep light flashes for a while and then the box comes back up) and gnome-power-manager reports this error in the logs.

/etc/acpi/lid.sh is linked to /etc/acpi/sleep.sh and I get the same symptoms if I call either script with the "force" parameter. However, choosing Quit -> Suspend from the Ubuntu menu does successfully put the box to sleep.

[none (ubuntu-bugs-nullinfinity-deactivatedaccount)]

That's a different bug. This is about g-p-m claiming that suspend failed when it actually succeeded.

[Jamie Strandboge (jdstrand)]

I'll mention that I haven't seen this bug for some time, and I suspend every night (latest gutsy).

[axm (70ip53x02)]

I had the error message the first time today, although instead of the unknown error I got

Nov 23 00:58:52 f NetworkManager: <WARN> nm_device_802_11_wireless_get_mode(): error getting card mode on eth1: No such device

..and had wireless deactived. Hibernate was successful as fas as I can tell, just the warning it failed popped up.

Nov 23 07:52:32 freihafen gnome-power-manager: (axm) hibernate failed

[Felipe Figueiredo (philsf)]

I still get this bug in latest hardy. Here are some possibly relevant logs of it, now it's just happened.

Any laptop-specific information needed is probably posted at bug 212660.

[Lauren (lwozniak)]

I have the same problem; gateway E-295C. If someone could tell me what logs to attach (and how to get them), I'd be more than happy to contribute. It'd be really nice to get this fixed soon.

[Geek2theCore (jeremymccaleb)]

I'll add another interesting twist to this. I have a Toshiba M60, and it exhibits all the same "features" (successful suspend resume, unhelpful failure message), the pm-suspend.log is completely clean, with no sign of an error, but mine returns with a squeal through the laptop speakers at full volume, like a feedback loop. If I don't turn down the speakers before I resume in the morning, it's enough to wake the dead. But other than the error message and squeal there is no failure of any device on resume. I can instantly use anything, including sound.

I'm on Hardy 8.04.1

[Geek2theCore (jeremymccaleb)]

OK... i finally found the operative bug report (the duplicate) and that the sound thing is actually the sound: /usr/share/gnome-power-manager/gpm-suspend-failure.wav which is played on an error, so I just turned the error sound off in the Power Manager preferences. It was that or turn the bug into a feature by making the failure sound a QUIET little wave file that says in a HAL 9000 voice "Welcome back. Now close the error message and we'll begin."

If I could only get rid of it instead...

[Felipe Figueiredo (philsf)]

Geek2theCore escreveu:
> OK... i finally found the operative bug report (the duplicate) and that
> the sound thing is actually the sound: /usr/share/gnome-power-manager
> /gpm-suspend-failure.wav which is played on an error, so I just turned
> the error sound off in the Power Manager preferences. It was that or
> turn the bug into a feature by making the failure sound a QUIET little
> wave file that says in a HAL 9000 voice "Welcome back. Now close the
> error message and we'll begin."
>
> If I could only get rid of it instead...
>
You have a different bug, Bug #242713.

[Geek2theCore (jeremymccaleb)]

Thanks, Felipe

On Fri, Mar 20, 2009 at 3:17 PM, Felipe Figueiredo <email address hidden>wrote:

> Geek2theCore escreveu:
> > OK... i finally found the operative bug report (the duplicate) and that
> > the sound thing is actually the sound: /usr/share/gnome-power-manager
> > /gpm-suspend-failure.wav which is played on an error, so I just turned
> > the error sound off in the Power Manager preferences. It was that or
> > turn the bug into a feature by making the failure sound a QUIET little
> > wave file that says in a HAL 9000 voice "Welcome back. Now close the
> > error message and we'll begin."
> >
> > If I could only get rid of it instead...
> >
> You have a different bug, Bug #242713.
>
> --
> Feisty reports suspend failed after resuming from suspend
> https://bugs.launchpad.net/bugs/89983
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “gnome-power-manager” source package in Ubuntu: Confirmed
>
> Bug description:
> After upgrading to Feisty I occasionally get a message stating that there
> was a problem with suspend and Ubuntu was not able to enter suspend mode.
> However, I get this message after resuming from suspend. So suspend is
> working but something thinks it's failing. This does not always happen.
> Seems to be fairly random.
>
> HP nx7000 laptop
>

[Petr Vandrovec (petr-vmware)]

Just in case you can reproduce this on any system which supports hibernate but does not support sleep. Responsible code is this:

static void
idle_do_sleep (GpmManager *manager)
...
        } else if (strcmp (action, ACTION_SUSPEND) == 0) {
                gpm_info_explain_reason (manager->priv->info, GPM_EVENT_SUSPEND,
                                        _("Suspending computer."), _("System idle."));
                ret = gpm_control_suspend (manager->priv->control, &error);
                if (!ret) {
                        egg_warning ("cannot suspend (error: %s), so trying hibernate", error->message);
                        g_error_free (error);
                        error = NULL;
                        ret = gpm_control_hibernate (manager->priv->control, &error);
                        if (!ret) {
                                egg_warning ("cannot suspend or hibernate: %s", error->message);
                                g_error_free (error);
                        }
                }

        } else if (strcmp (action, ACTION_HIBERNATE) == 0) {

It appears to throw away errors from gpm_control_suspend, falling through to gpm_control_hibernate - but unfortunately gpm_control_suspend does not check whether can_suspend is TRUE - it blindly issues suspend, and if it fails, it signals sleep-error - causing error message to pop up after computer is waken up from hibernate.

Also gpm_manager_suspend() checks inhibit on "hibernate", not "suspend", but unfortunately fixing that won't help here :-(

gnome-power-manager 2.24.4 still suffers from this problem. If you are looking for platform where you can investigate this behavior, try VMware's VMs - only S1 & S4 is supported there, so you get hibernate + suspend error on them.

[Thomas Hotz (thotz-deactivatedaccount)]

Can you reproduce this with supported Ubuntu versions? Thank you!

[Nicolas M (nicolas-martin-gmail)]

Le 03/10/2012 16:42, Thomas Hotz a écrit :
> Can you reproduce this with supported Ubuntu versions? Thank you!
>
Not any more, I'm using now 12.04, and I never got this situation at
least since 11.04

I do not remember with older versions !