Laptop doesn't suspend when power is unplugged while lid is closed

[David Emett]

In "Xfce Power Manager", I have:
On AC, when laptop lid is closed: Lock screen
On Battery, when laptop lid is closed: Suspend

This works fine, except when I unplug the power while the lid is closed. In that case, the laptop doesn't suspend and just remains locked.

WORKAROUND: Unplug power before closing lid.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-25-generic 3.2.0-25.40
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
Uname: Linux 3.2.0-25-generic i686
NonfreeKernelModules: wl
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
ApportVersion: 2.0.1-0ubuntu8
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269VB Analog [ALC269VB Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dave 2165 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf5cf8000 irq 45'
   Mixer name : 'Realtek ALC269VB'
   Components : 'HDA:10ec0269,1043841c,00100100'
   Controls : 16
   Simple ctrls : 9
CurrentDmesg: [ 21.979982] init: plymouth-stop pre-start process (1393) terminated with status 1
Date: Mon Jun 18 23:48:15 2012
HibernationDevice: RESUME=UUID=4b5eff08-55db-4f33-8766-255d45a81d44
InstallationMedia: Lubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111011)
MachineType: ASUSTeK Computer INC. 1215N
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm-256color
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/usr/bin/zsh
ProcFB:
 0 inteldrmfb
 1 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-25-generic root=UUID=6a76faae-dcd2-430a-aa4d-511a43d338d5 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-25-generic N/A
 linux-backports-modules-3.2.0-25-generic N/A
 linux-firmware 1.79
SourcePackage: linux
UpgradeStatus: Upgraded to precise on 2012-05-06 (43 days ago)
dmi.bios.date: 05/05/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0902
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 1215N
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0902:bd05/05/2011:svnASUSTeKComputerINC.:pn1215N:pvrx.x:rvnASUSTeKComputerINC.:rn1215N:rvrx.xx:cvnASUSTeKComputerINC.:ct10:cvrx.x:
dmi.product.name: 1215N
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[penalvch (penalvch)]

David Emett, thank you for reporting this and helping make Ubuntu better. Could you please provide the information following https://wiki.ubuntu.com/DebuggingKernelSuspend ? As well, if you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.

[David Emett (akxws32zf-dave)]

As I said in the comments of bug #886629, which AFAICT is identical to this one:

I don't see how https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume is relevant in this case -- the bug appears to be that suspend never gets triggered at all, not that it fails.

Problem persists with the 17th June kernel from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/

It's not clear to me that this is a kernel bug, should I still add the 'kernel-bug-exists-upstream' tag?

[David Emett (akxws32zf-dave)]

Why did you re-add the 'needs-upstream-testing' tag? Is there more testing I should do?

[penalvch (penalvch)]

David Emett, thank you for testing the mainline, and I added the appropriate kernel tag. Could you please provide the information following https://wiki.ubuntu.com/DebuggingKernelSuspend ?

[David Emett (akxws32zf-dave)]

I don't see how https://wiki.ubuntu.com/DebuggingKernelSuspend is relevant in this case -- the bug appears to be that suspend never gets triggered at all, not that it fails. So if I unplug the power and then close the lid, it will suspend fine. The problem is that if I close the lid first and then unplug the power, the suspend just isn't triggered.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Töma Gavrichenkov (ximaera)]

Also affects me with 12.04@Lenovo Thinkpad X200 and X220. Is there enough information provided to fix this, or I can help?

[penalvch (penalvch)]

Artyom Gavrichenkov, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Bug Control and Ubuntu Bug Squad article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_Reporting_Etiquette

When opening up the new report, please feel free to subscribe me to it. Thank you for your understanding.

Helpful Bug Reporting Links:
https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported
https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug
https://help.ubuntu.com/community/ReportingBugs#Adding_Additional_Attachments_to_an_Existing_Launchpad_Bug

[Ian Hutchinson (hutch)]

This bug is now identified as a shortcoming in gnome-settings-daemon.
A work around is available.

[Ian Hutchinson (hutch)]

This is an annoying shortcoming in the current gnome-settings (used to be gnome-power-manager). It does not check whether it should suspend when entering on-battery state. Here's a work-around:

Put the following into an (executable) file /etc/pm/power.d/zzsleepiflidclosed

#!/bin/sh
# If the lid is closed, then sleep when we are switched to battery mode.
case "$1" in
    true) # Going into battery mode.
      sleep 1
      grep -q closed /proc/acpi/button/lid/*/state && dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend
      ;;
    false) # Going into line power mode
      ;;
    *)
        exit
        ;;
 esac
exit 0

I don't know why the sleep 1 pause is necessary, but without it, my lenovo won't resume stably. 2 seconds may be needed.

[Sebastien Bacher (seb128)]

reassigning, xfce doesn't use gnome-settings-daemon+

[Ian (ifreecarve)]

I'm running xfce4-power-manager under Ubuntu 12.04 / awesomewm on a Dell Latitude E6510

xfce4-power-manager will successfully suspend from the context menu -> suspend, and it will successfully suspend if I switch to battery power then close the lid.

If I close the lid first and THEN unplug the power cable, it locks the screen but fails to suspend.

Not sure if this is related to bug 9704.

Nothing extremely helpful in the console, but here's the output anyway:

$ xfce4-power-manager --no-daemon

(xfce4-power-manager:15496): GLib-WARNING **: (/build/buildd/glib2.0-2.32.3/./glib/gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)

(xfce4-power-manager:15496): xfce4-power-manager-WARNING **: Unable to connect to session managet : Failed to connect to the session manager: SESSION_MANAGER environment variable not defined

(xfce4-power-manager:15496): xfce4-power-manager-WARNING **: could not map keysym 1008ffa8 to keycode

12736

12736
15558
12736
15558

[Simon Steinbeiß (ochosi)]

Actually there are different settings for what should happen when you close the laptop lid depending on whether it is connected to a power-source or on battery.

This sounds like you have different settings for the two scenarios. Could you please check your settings?

[Ian (ifreecarve)]

The settings *are* different: lock screen when the lid is closed on AC, and suspend when the lid is closed on battery. But keeping the laptop awake just because the cord was still plugged in at the instant that the lid was closed seems like a very stupid thing for the power manager to do. Is there a good reason for this behavior? And does it offset the silliness of having to open and close the lid (after unplugging) to get the laptop to go to sleep?

Is there some other way that any sequence of events resulting in a simultaneous-closed-lid-and-unplugged-power-supply state will suspend the laptop? That was the case under Ubuntu 10.10, IIRC.

[Simon Steinbeiß (ochosi)]

(In reply to ian from comment #2)
> The settings *are* different: lock screen when the lid is closed on AC, and
> suspend when the lid is closed on battery. But keeping the laptop awake
> just because the cord was still plugged in at the instant that the lid was
> closed seems like a very stupid thing for the power manager to do. Is there
> a good reason for this behavior? And does it offset the silliness of having
> to open and close the lid (after unplugging) to get the laptop to go to
> sleep?

First of all, keep the tone friendly. We took over the power manager after it was unmaintained for 2 years. A lot of the infrastructure around it has changed and we're trying to keep/make it working.

In one of the last few releases, Ubuntu introduced logind to handle these sort of things and xfpm carries patches for that.
Anyway, it's very odd that the behavior seems mixed up. You could check the xfconf variables for the settings, if you've upgraded from previous versions you could also try to reset the channel via xfce4-settings-editor and then configure xfpm anew and see whether that fixes the issue.
It might also help if you attach the settings xml file of xfce4-power-manager (from ~/.config/xfce4/xfconf/..)

> Is there some other way that any sequence of events resulting in a
> simultaneous-closed-lid-and-unplugged-power-supply state will suspend the
> laptop? That was the case under Ubuntu 10.10, IIRC.

Ubuntu 10.10 was released about 4 years ago, the architecture around suspend has changed a lot since then (e.g. UPower doesn't support it anymore).

[Ian (ifreecarve)]

Created attachment 5608
settings XML

From xfce4-power-manager 1.0.11
Ubuntu 12.04

[Ian (ifreecarve)]

Apologies for the tone, but your initial reply suggested that you did not consider this to be a bug.

I tried resetting the channel with xfce4-settings-editor as you suggested, but the problem persists. I've attached the settings XML file.

Are you able to reproduce this issue?

[Simon Steinbeiß (ochosi)]

Holy cow, that is a really old version of the power manager. Just as a disclaimer, we're not doing maintenance releases for previous versions.

I've looked into the source of 1.0.11 and locking the screen upon closing the lid is the default action, so the fact that you don't have an entry for that in your settings.xml file is ok. The on-battery setting also looks ok, cause suspend has the value 1.

I've browsed through the git history of xfpm since 1.0.11 but couldn't see any relevant commits for your bug. However I vaguely remember having problems myself on 12.04.

The current LTS release, 14.04, has a newer version of xfpm and also uses other software for suspend (the aforementioned logind). You could try whether that helps.

[Ian (ifreecarve)]

Looks like an upgrade is in my future. It sounds like this bug is resolved/wontfix (for this version) in any case.

[Simon Steinbeiß (ochosi)]

(In reply to ian from comment #7)
> Looks like an upgrade is in my future. It sounds like this bug is
> resolved/wontfix (for this version) in any case.

Yeah, I'm sorry I don't have better news.

[Ian (ifreecarve)]

No apology needed, because your news *is* better: there has been a lot of development work -- several versions worth -- and I just haven't taken advantage of it yet :)

[Eyal Soha (eyal0)]

This bug still affects xfce and it easily fixed with just 3 lines of code. I have reported it here at put a fix in, too. I've also tested it. Could we get this patched in?

https://bugzilla.xfce.org/show_bug.cgi