Suspends again right after resume

I forgot: It is a Thinkpad T41p.

I also just noticed: It only happens when I press the suspend key (Fn+F4). When I suspend e.g. via the Gnome battery applet, the notebook resumes normally.

Ciao

Martin

I have this behaviour on my Asus Z53Sv (similar to F3Sv) since a longer time (gutsy, hardy). It only happens sometimes. I definitely occurs after using the suspend key, I think it also happens after a suspend triggered by kpowersave ...

I'm removing the regression-potential tag since there is no clear indication in this bug report that this used to work for the original reporter of the bug. Additionally, the bug maybe actually be in gnome-power-manager as indicated by the 'gnome-power-manager' as indicated by the log messages. So it would be helpful to know which particular version of gnome-power-manager you experienced this with. You can check via 'apt-cache policy gnome-power-manager'. Also what are you power management preferences set to for pressing the suspend button? Thanks in advance.

Hi!

It is actually a regression, on Hardy the standby key (Fn+F4) worked fine, as well as the suspend key (Fn+F12).
My gpm version: 2.24.0-0ubuntu2, I just tried it and the problem is still there with this version.
My standby key setting ("Beim Drücken der Bereitschaftstaste" == "On pressing the standby key") is set to "Standby".

Ciao

Martin

I've been able to recreate this bug using the following settings:

When the power button is pressed: Ask me
When the suspend button is pressed: Suspend

I then press Fn+F5 (supsend on my laptop) and after suspending press the power button to resume. The system will immediately suspend again.

This also only happens for me when I use Fn+F5 to suspend.

I've been trying to recreate this bug for a bit and went through a period of time where it wasn't happening however it started again. I was able to capture a verbose gnome-power-manager log as requested at the debugging page for gnome-power-manager - https://wiki.ubuntu.com/DebuggingGNOMEPowerManager.

At the end of the log there is a message about a fatal IO error which is due to the fact that I pressed Ctrl + Alt + Backspace on the 2nd resume to break out of the cycle.

Martin - Does this happen for you 100% of the time?

Here are the gconf values for gnome-power-manager from the system.

I hate to pass the buck here, but it seems like this is unlikely to be a GPM bug. The function gpm_button_filter_x_events is set up as a callback from X sending an event. Since it is getting the keypress in that case, I would have to believe that X is continuing to send it. Either that or GDK.

Could you capture the output of xev when pressing the suspend button. This would show whether X is sending the event continually or not.

It is 100% reproducible here: Standby via right-click-menu of the g-p-m icon: Standby once (as it should be), Pressing Fn+F4: Standby twice (Suspends, after closing and opening the display it resumes, beeps and suspends again. After closing and opening again (or pressing the little display lid switch or the power button) it resumes and stays up.

I don't know if I understand Brian correctly, but it sounds like it does loop endlessly on his laptop.

Yes, it does loop endlessly (well at least as long as I was patient for) on my laptop. I believe the key to recreating this bug is the length of time that they keys are pressed. If I just briefly press them it will suspend only one time, however if I hold them for a couple of seconds it will suspend multiple times.

I think I grabbed the xev output Ted is looking for and have attached it.

Here's one where I held the keys for a bit longer.

I was also able to recreate this using an Ubuntu i386 Live CD dated 20080930.4.

Bug 272587 is likely a duplicate of this one.

In general, X is less involved in hotkey management than before. It's not completely out of the picture quite yet, so there's still some chance of X interfering.

However, from what I can tell, when X is involved in handling the sleep key, you should see something like "XF86Standby" listed in the xev output. If X were issuing the key twice, that should show up (at least) twice. I didn't spot it in the xev output though, which leads me to think that the error occurs at a deeper layer.

Fwiw, I've seen acpi-support bug reports about double-hotkey events, in particular brightness keys. So it wouldn't surprise me if this is an acpi-support bug (or at a lower level).

A few experiments that would help narrow things down:

a. In gnome-keyboard-properties, can you map the standby action to some action such as launching the calculator? If X is passing double events, this should launch two copies of the calculator.

b. acpi-support uses scripts in /etc/acpi to handle hotkey events, such as sleepbtn.sh. Experiment with adding lines to have them log to a file, to see if they're getting called. If it happens that the script is getting triggered twice, a quirk could be added to make it ignore the second one.

c. Shut down /etc/init.d/acpid, cat /proc/acpi/event, and hit the key. You should see a single entry there; if two appear, that suggests possibly something at the kernel level. (On my system I see no output, which I think means that X is stealing it.)

Hope this helps, good luck.

Experiment A - the "Suspend" action is not linked to any key press, so the shortcut shows as "Disabled".

Experiment B - /etc/acpi/sleepbtn.sh does seem to be called when my suspend keys are pressed.

Experiment C - It doesn't appear in /proc/acpi/event.

I also tried pressing the suspend keys in a console and nothing happens until I switch back to X at which point in time it suspends. I haven't recreated the bug when pressing suspend in a console though.

I've introducted some code to hopefully fix the repeated keypresses. Please look at gnome-power-manager_2.24.0-0ubuntu4~ppa2 in my PPA:

http://launchpad.net/~ted-gould/+archive

I've suspended and resumed quite a few times with the gnome-power-manager package from your ppa and have not seen this bug again.

I tried the PPA package for some time, but it worked only once. All the other times I suspended the original behaviour remained, suspending once after resuming.

This bug was fixed in the package gnome-power-manager - 2.24.0-0ubuntu6

---------------
gnome-power-manager (2.24.0-0ubuntu6) intrepid; urgency=low

  * Adding 21_idle_key_removal.patch which makes it so that the glib
    mainloop has to hit the idle state before we'll accept another key
    from X. This should remove quickly repeated keys and keys that were
    queued before suspend. (LP: #261084)
  * Adding 22_xfce_desktop_files.patch which adds XFCE to the ShowIn
    properties of the preferences and statistics desktop files.
  * Added 23_numlock_hotkey.patch which is the changes from 0ubuntu4 and put
    it into a patch.
  * Adding 24_interactive_shutdown_dbus.patch which is based on the patch
    in GNOME Bug: #507393. Made to build on 2.24.0 and also put in more
    error checking and a fallback to XSMP when DBus based session management
    is not available. (LP: #252795)

 -- Ted Gould <email address hidden> Wed, 15 Oct 2008 11:10:23 -0500

I've tested gnome-power-manager version 2.24.0-0ubuntu6 and confirm that it still fixes the bug I was experienceing.

Martin - could you update to that version of the package and try recreating the bug report? Thanks in advance.

I just upgraded to 2.24.0-0ubuntu7, and rebooted afterwards. After initiating suspend-to-RAM via the hardware keys (Fn+F4) and resuming, the laptop still suspends again right away, so the problem is not yet fixed for my laptop.

Ciao

Martin

On Thu, 2008-10-16 at 19:07 +0000, Martin Emrich wrote:
> I just upgraded to 2.24.0-0ubuntu7, and rebooted afterwards. After
> initiating suspend-to-RAM via the hardware keys (Fn+F4) and resuming,
> the laptop still suspends again right away, so the problem is not yet
> fixed for my laptop.

Martin,

Can you submit a GPM log similar to Brian did earlier?

https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/261084/comments/6

I think that this is likely to be a different bug.

Ok, here's my debug log, from before the first suspend to after the second resume.

I just got this happening to me on my Jaunty test system.
Should I open a new ticket, or change the status to this one, and add a regression flag?

Hmm, I wonder why this was marked as "Fix Released" after all, as it is clearly not fixed.

I didn't experience this bug on a Asus Z53S / F3S for a while, tough suspend/resume was working like a charme. As resume is broken completely in Intrepid with 2.6.27-7 since my latest upgrades, this doesn't matter that much at the moment ...

I am also experiencing this on Jaunty. It resuspends twice after resuming.

confirm the bug on Thinkpad x200 and x61s, both machines behave the same way on intrepid 8.10 (all latest).
when i press Fn+F4 suspend happens, but on the next resume machine suspends again.

INTERESTING - if Transmission (bittorrent) is running g-p-m shows two messages about "policy preventing suspend"
LOOKS like acpid and g-p-m are both catching the same events.
HOWEVER, I was digging into the problem, and here are my findings:

1. running acpid in debug shows only one ACPI event and only one run of /etc/acpi/sleepbtn.sh
---
acpid: received event "ibm/hotkey HKEY 00000080 00001004"
acpid: rule from 5589[0:0] matched
acpid: notifying client 5589[0:0]
acpid: rule from 5509[111:123] matched
acpid: notifying client 5509[111:123]
acpid: rule from /etc/acpi/events/ibm-sleepbtn matched
acpid: executing action "/etc/acpi/sleepbtn.sh"
BEGIN HANDLER MESSAGES
END HANDLER MESSAGES
---

2. g-p-m in verbose mode shows _twice_ "Button press event type=sleep"
---
TI:22:30:55 TH:0x91ad640 FI:gpm-button.c FN:hal_device_condition_cb,430
 - condition=ButtonPressed, details=sleep
TI:22:30:55 TH:0x91ad640 FI:gpm-button.c FN:emit_button_pressed,374
 - emitting button-pressed : sleep
TI:22:30:55 TH:0x91ad640 FI:gpm-manager.c FN:button_pressed_cb,1020
 - Button press event type=sleep
[snip]
 - Button press event type=sleep
TI:22:31:11 TH:0x91ad640 FI:gpm-backlight.c FN:gpm_backlight_button_pressed_cb,536
 - Button press event type=sleep
TI:22:31:11 TH:0x91ad640 FI:gpm-info.c FN:button_pressed_cb,679
 - Button press event type=sleep
TI:22:31:11 TH:0x91ad640 FI:gpm-button.c FN:gpm_button_filter_x_events,122

3. when acpid triggers sleepbtn.sh it sends 'acpi_fakekey $KEY_SLEEP' . in my system $KEY_SLEEP has code 142
and if i do manually 'sudo acpi_fakekey 142' my system suspends and resumes correctly.

4. if i stop acpid with 'sudo /etc/init.d/acpid stop' and then suspend it also works correctly.

THE QUESTION IS why g-p-m works correctly without acpid ? If that is intended why both are running doubling like this the events?

My fix for now is just to comment out "acpi_fakekey $KEY_SLEEP" in /etc/acpi/sleepbtn.sh:
---
test -f /usr/share/acpi-support/key-constants || exit 0

. /usr/share/acpi-support/key-constants
# acpi_fakekey $KEY_SLEEP
---

I still see this bug in Jaunty. Is there any fix pending?

I'm also getting the same problem on a Medion MD96420.

The problem seems to be gone for me since a few weeks.

Same issue with Intrepid and Beta Jaunty (amd64), seen on both T500 and HP2530p.

It happens when suspending via the hotkey or simply closing the lid. On resume, the laptop suspends right away.

A workaround for the lid is to check the state in /proc, at the beginning of /etc/acpi/sleep.sh (was tested on Intrepid):

   grep -q closed /proc/acpi/button/lid/*/state
   if [[ $? != 0 && $1 = "from_lid" ]]; then
      exit
   fi

I dropped the patch from the recent karmic upload of gnome-power-manager. It is unclear whether this is still an issue in the new world where we just read -evdev events instead of ACPI events from hal, is pretty hackish, and it potentially leads to dropping valid events. I discussed it with Richard Hughes, and he suggested to try without the patch, and that he doesn't like to adopt it.

So I'd appreciate if folks could test version 2.27.2+git20090729 or above in karmic and check if they still get the problem. Thanks!

@Martin I havent seen this in Karmic so far

@Martin: I have just tested it briefly (with gnome-power-manager 2.27.2+git20090729-0ubuntu2 installed) and couldn't reproduce the issue. I'm using Thinkpad T61 if it's relevant.

On Wed, Jul 29, 2009 at 07:20:00PM +0200, Martin Pitt wrote:
> in Ubuntu 8.10 we added a patch to gnome-power-manager [1] to ignore
> power management related hotkey events which came in in quick
> succession; this caused effects like suspending immediately after
> resuming [2].
>
> I dropped the patch from the recent karmic upload of
> gnome-power-manager. It is unclear whether this is still an issue in
> the new world where we just read -evdev events instead of ACPI events
> from hal, is pretty hackish, and it potentially leads to dropping
> valid events. I discussed it with Richard Hughes, and he suggested to
> try without the patch, and that he doesn't like to adopt it.

I've been seeing spurious suspends immediately after resume over the past
week in Karmic.

--
 - mdz

Matt Zimmerman [2009-08-10 8:59 -0000]:
> I've been seeing spurious suspends immediately after resume over the past
> week in Karmic.

Indeed I got that once as well. However, it also happens with that
patch applied, so I believe it's a different cause now.

Can you reproduce the double-suspend with version
2.27.5-0ubuntu1.test1 in
https://launchpad.net/~ubuntu-desktop/+archive/ppa ? If so, then we
really don't need that old patch any more.

Thanks!
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

> Indeed I got that once as well. However, it also happens with that
> patch applied, so I believe it's a different cause now.

I'm seeing spurious suspends too, starting recently; I filed bug #425411.

> Can you reproduce the double-suspend with version
> 2.27.5-0ubuntu1.test1 in
> https://launchpad.net/~ubuntu-desktop/+archive/ppa ?

Yes, I can reproduce this both under the PPA version and under the latest g-p-m in karmic (2.27.91-0ubuntu1).

My T61p sometimes suspends right after a resume too. I'm running 2.6.31-11.38 and g-p-m 2.28.0-0ubuntu1.

I'm too seeing this issue (again) after upgrading from Jaunty to Karmic on a Thinkpad X300. Is it useful at this time to attach debugging logs - with HAL going away - as described here: https://wiki.ubuntu.com/DebuggingGNOMEPowerManager?

The wiki page also explains how to get devicekit-power information. the gnome-power-bugreport script is still valid.

Thanks Martin, I will create debugging logs then (may take a day till I get to it). Apart from that I've noticed that /etc/default/acpi-support has the line SUSPEND_METHODS='dbus-pm dbus-hal pm-utils'. I removed the 'dbus-hal' part. Also, there's the ENABLE_LAPTOP_MODE=false line, but the comment above states the Ubuntu's default is 'true'. I had set this to 'true' previously, but reverted back to 'false'. After I made these two changes I haven't seen any spurious suspends triggered by FN+F4 (sleep key). Hope this is helpful. If there's anything in particular I can help with or test, I'll gladly do so.

I can reproduce that with a mini 10v.
If I suspend (closing the lid) while on ac power, then I unplug ac and try to resume the netbook (opening the lid), it will resume and suddenly come back to suspend. hitting the power button will resume normaly.

forgot to say that also removing 'dbus-hal' from /etc/default/acpi-support will not change anything.
Laptop mode is disabled

FYI, bug 425411 is currently open about this, so you might want to subscribe there.