shouldn't queue a second suspend if the machine is already suspending

Bug #922968 reported by Chris J Arges
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Won't Fix
Medium
James M. Leddy
Precise
Won't Fix
Medium
James M. Leddy
gnome-power
New
Undecided
Unassigned
gnome-settings-daemon (Ubuntu)
Confirmed
Undecided
Unassigned
Precise
Won't Fix
Undecided
Allison Karlitskaya
linux (Ubuntu)
Invalid
Medium
Joseph Salisbury
Precise
Invalid
Medium
Unassigned

Bug Description

Reproduce:
This only triggers when you suspend with (Fn-F4) then quickly close the laptop lid. The power settings are setup such that the laptop lid close will suspend the laptop as well. So we're getting two suspend events in a row.

Workaround:
Either close the lid to suspend and not use Fn-F4. Or suspend using Fn-F4 then wait a few seconds before closing the lid.

Version:
Ubuntu 3.2.0-11.19-generic 3.2.1

After suspending the computer using Fn-F4, and for an extended period of time, I then wake the computer up by opening the lid and pressing the 'Fn' key. The computer starts to resume, and I am prompted for my password. Then the computer suspends again, and I have to wake it up again to resume the computer. This is with the computer charged sufficiently, but not plugged into an AC source.

In addition I've also confirmed that using pm-suspend and resuming by pressing 'Fn' will still cause the machine to suspend again after resume.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-11-generic 3.2.0-11.19
ProcVersionSignature: Ubuntu 3.2.0-11.19-generic 3.2.1
Uname: Linux 3.2.0-11-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: arges 2127 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xf2620000 irq 46'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:14f1506e,17aa21ce,00100002 HDA:80862805,80860101,00100000'
   Controls : 26
   Simple ctrls : 8
Card29.Amixer.info:
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw unknown'
   Mixer name : 'ThinkPad EC (unknown)'
   Components : ''
   Controls : 1
   Simple ctrls : 1
Card29.Amixer.values:
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Date: Fri Jan 27 23:00:48 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)
MachineType: LENOVO 4177CTO
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-11-generic root=UUID=0f84abde-0eb0-405f-a8c6-b09dd4c4dae9 ro quiet splash i915.i915_enable_rc6=1 vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-11-generic N/A
 linux-backports-modules-3.2.0-11-generic N/A
 linux-firmware 1.68
SourcePackage: linux
StagingDrivers: mei
UpgradeStatus: Upgraded to precise on 2011-12-21 (37 days ago)
dmi.bios.date: 07/29/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 83ET63WW (1.33 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4177CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr83ET63WW(1.33):bd07/29/2011:svnLENOVO:pn4177CTO:pvrThinkPadT420:rvnLENOVO:rn4177CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4177CTO
dmi.product.version: ThinkPad T420
dmi.sys.vendor: LENOVO

Revision history for this message
Chris J Arges (arges) wrote :
Revision history for this message
Chris J Arges (arges) wrote :
Revision history for this message
Chris J Arges (arges) wrote :
description: updated
Revision history for this message
Brad Figg (brad-figg) wrote : Test with newer development kernel (3.2.0-12.20)

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: New → Confirmed
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-12.20
Revision history for this message
Chris J Arges (arges) wrote : Re: computer suspends again after resume

Confirming with latest version.

Revision history for this message
Chris J Arges (arges) wrote :

Confirmed this still affects 3.2.0-12.20.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: kernel-confirmed-3.2.0-12.20
removed: kernel-request-3.2.0-12.20
Revision history for this message
Brad Figg (brad-figg) wrote : Test with newer development kernel (3.2.0-12.20)

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
tags: added: kernel-request-3.2.0-12.20
Chris J Arges (arges)
tags: added: bot-stop-nagging
removed: kernel-confirmed-3.2.0-12.20 kernel-request-3.2.0-12.20
Revision history for this message
Chris J Arges (arges) wrote : Re: computer suspends again after resume

I can confirm this bug still exists when using pm-suspend from the command line to suspend the machine.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → Medium
assignee: nobody → Chris J Arges (christopherarges)
description: updated
tags: added: kernel-da-key
Chris J Arges (arges)
description: updated
Chris J Arges (arges)
description: updated
Revision history for this message
Brent Fox (brent-s-fox) wrote :

I'm seeing this behavior as well on a ThinkPad T400. I am running 12.04 LTS.

bfox@bfox-laptop:/lib/modules/3.2.0-35-generic$ uname -a
Linux bfox-laptop 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux

I can reproduce the problem pretty much at will. The double-suspend problem is quite annoying. Please let me know what I can do to help diagnose the problem further.

Revision history for this message
Kent Baxley (kentb) wrote :

Also reproduces on a Latitude E5430 running 12.04.1. Same sequence of events:

1) Press Fn+F1 hotkey.
2) Close the lid immedately after pressing hotkeys.

Laptop suspends...

3) Open the lid the system appears to resume but then jumps right back into S3.

I can also verify the workarounds in that using just the lid or using the hotkeys and then waiting a few seconds before closing the lid prevents the system from going into a double-suspend state.

Kent Baxley (kentb)
Changed in oem-priority:
importance: Undecided → Medium
Changed in oem-priority:
assignee: nobody → James M. Leddy (jm-leddy)
Changed in oem-priority:
status: New → Confirmed
tags: added: rls-r-incoming
Changed in linux (Ubuntu):
assignee: Chris J Arges (arges) → Brian Murray (brian-murray)
Changed in linux (Ubuntu):
assignee: Brian Murray (brian-murray) → Joseph Salisbury (jsalisbury)
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I can easily reproduce this problem with 12.04 on a thinkpad X200s

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Can folks affected by this bug confirm whether or not this happens in Raring?

Changed in linux (Ubuntu Precise):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I think this has something to do with the way the way hotkeys are delivered as keyboard keys and lid close is treated as a signal in gnome-settings-daemon. You can reproduce this issue by selecting "Suspend" from the menu, and then closing the lid, but you can not reproduce by selecting "Suspend" and then hitting the hotkey. Similarly hitting the suspend hotkey or the suspend+hibernate hotkey quickly does not cause problem.

Also if you take a look at the solution to bug 261084 you can see that in the past this was solved by eating keyboard keys but that was never applied to the lid close signal.

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

This is not a bug but a feature. The user is asking to suspend the machine twice, so it is doing as it is told.

acpid just gets a bunch of events and handles them in a serialized fashion. Hence if a user presses the sleep button and then closes the lid, acpid will have 2 sets of suspend requests.

We may have the following:

sleep button --> event
lid --> event

acpid gets the 1st event and suspends the machine. It may be that the 2nd event is also being activated but the kernel freezes this before it kicks off a 2nd suspend. Once the machine resumes, we can be sure that the 2nd suspend event kicks in and hence we see the double suspend.

Changed in linux (Ubuntu Precise):
status: Confirmed → Invalid
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Bernardo Reino (reinob) wrote :

While I somewhat agree with @jsalisbury above, I'd like to note that I *cannot* reproduce this issue with Kubuntu 12.04 (kernel 3.5.0-25, KDE 4.10).

I wonder if people affected by this issue are using Unity or Gnome or what.

Revision history for this message
Kent Baxley (kentb) wrote :

I will check with 12.04.2 on the same E5430 that I reproduced this on earlier.

Revision history for this message
Kent Baxley (kentb) wrote :

This no longer reproduces on my Latitude E5430 running 12.04.2 using the 3.5.0-based lts-quantal kernels.

Changed in gnome-power:
assignee: nobody → Brian Murray (brian-murray)
assignee: Brian Murray (brian-murray) → nobody
Changed in gnome-power-manager (Ubuntu):
assignee: nobody → Brian Murray (brian-murray)
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I can still reproduce this on 3.5 kernels.

Changed in gnome-power-manager (Ubuntu):
assignee: Brian Murray (brian-murray) → Canonical Desktop Team (canonical-desktop-team)
Changed in gnome-power-manager (Ubuntu Precise):
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Revision history for this message
Brent Fox (brent-s-fox) wrote :

@jsalisbury: You are correct in that the system is simply doing what it is told, but it's still a bug in the user experience.

The question is what the user is intending to do. Is the user intentionally telling the system to suspend twice? There's no use case in which that's useful.

Then we have to consider the user experience. When the user opens the lid, they are telling the system to wake up because they intend to use it. They aren't expecting the system to put itself back to sleep, so this violates the principle of least surprise.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

affects: gnome-power-manager (Ubuntu) → gnome-settings-daemon (Ubuntu)
Changed in gnome-settings-daemon (Ubuntu Precise):
status: New → Confirmed
Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
summary: - computer suspends again after resume
+ shouldn't queue a second suspend if the machine is already suspending
Revision history for this message
Sebastien Bacher (seb128) wrote :

Could somebody upstream the GNOME bug against gnome-settings-daemon: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-settings-daemon ?

Unassigning the desktop team, we don't have currently anyone with spare cycles to look at that, and it seems really a minor issue: it's not easy to trigger the second suspend before the first one kicks in, and there is no breakage, just an annoyance that you need to resume a second time

If that's a real issue for oems please ping me to discuss it

Changed in gnome-settings-daemon (Ubuntu):
assignee: Canonical Desktop Team (canonical-desktop-team) → nobody
Revision history for this message
Sebastien Bacher (seb128) wrote :

Ryan agreed to talk to upstream/have a look to the issue, reassigning to him

Changed in gnome-settings-daemon (Ubuntu Precise):
assignee: Canonical Desktop Team (canonical-desktop-team) → Ryan Lortie (desrt)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Revision history for this message
Allison Karlitskaya (desrt) wrote :

We fixed this issue in saucy by moving responsibility for handling suspend into systemd-shim and adding a check there to ignore suspend requests that come in during a very small window after waking up. From personal reports, this has solved the issue for everyone who has tried it.

I'm not totally happy with the solution -- I would prefer if we had one based on the timestamps of the source of the suspend (ie: clicking a menu item with the mouse, lid-close events, etc) and were able to compare that with the time of the suspend itself. This requires some changes to logind, though. This has been discussed with upstream and we're waiting.

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Hi Ryan,

Can the same fix be applied to the equivalent packages in precise? If so, I will be requesting that we SRU these changes once upstream agrees to them.

Revision history for this message
Allison Karlitskaya (desrt) wrote :

hi James,

Unfortunately we handle suspend in a much more ad-hoc way on precise. There is no logind or systemd-shim through which all suspend requests are handled. These changes are therefore not really possible to backport.

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Okay, thank you for that information.

Revision history for this message
Ara Pulido (ara) wrote :

Not critical enough to get in the OEM priority queue

Changed in oem-priority:
status: Confirmed → Invalid
status: Invalid → Won't Fix
Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in gnome-settings-daemon (Ubuntu Precise):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.