Resume (from memory) goes back to sleep automatically

[Noel J. Bergman]

Upon resuming from suspend-to-RAM, the system will start to wake, and will immediately go back to sleep. If I cycle it one or two times more, it will stay awake. I have reproduced this exact behavior with Jaunty on the new kernel as well as on Fedora 10 (https://bugzilla.redhat.com/show_bug.cgi?id=475585), so it is not specific to Ubuntu.

It has been observed that this happens when suspending via hotkey but not when suspending command (details in comments, below).

As a conjecture, it is behaving as if due to some race condition it has not yet cleared that it has a suspend event, so it immediately re-processes the suspend upon waking.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-2-generic 2.6.28-2.3
ProcCmdLine: root=UUID=ac4ccc70-26e3-44dd-a6cf-715d1226eeb4 ro quiet
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-2.3-generic
SourcePackage: linux

[Noel J. Bergman (noeljb)]

I added the reference to an upstream defect in gnome-power-manager because Matt Garrett, whom I respect, seems to believe that it is gnome-power-manager related, and reading all of the open defects against gnome-power-manager in upstream, I found one that described the behavior. Keep in mind that I do not have this problem with either Hardy or Intrepid, just Fedora 10 and Jaunty.

[Noel J. Bergman (noeljb)]

This bug in upstream is also similar, except that my scenario has nothing to do with hibernate: http://bugzilla.gnome.org/show_bug.cgi?id=486138

[Noel J. Bergman (noeljb)]

http://bugzilla.gnome.org/show_bug.cgi?id=559238

[Noel J. Bergman (noeljb)]

As a test, I killed gnome-power-manager, and started it up again in a window with --no-daemon so that I could see the results. I then did a suspend, woke it up, woke it up again. Saw the output, and decide to suspend again. Did so, and then had to wake it up three times, with the third one being the charm.

Here is the result:

============================================================

root@jaunty:~# gnome-power-manager --no-daemon# gnome-power-manager --no-daemon

** (gnome-power-manager:11454): WARNING **: DBUS error: Could not get owner of name 'org.gnome.ScreenSaver': no such name
** (gnome-power-manager:11454): DEBUG: proxy is NULL, maybe the daemon responsible for org.gnome.ScreenSaver is not running?

------------- MANUALLY SUSPENDED HERE -----------------

** (gnome-power-manager:11454): WARNING **: DBUS timed out, but recovering

** (gnome-power-manager:11454): WARNING **: Suspend failed without error message

** (gnome-power-manager:11454): WARNING **: Suspend failed without error message

------------- MANUALLY SUSPENDED AGAIN HERE -----------------

** (gnome-power-manager:11454): WARNING **: Suspend failed without error message

** (gnome-power-manager:11454): WARNING **: Suspend failed without error message

** (gnome-power-manager:11454): WARNING **: Suspend failed without error message

============================================================

Notice the output: "Suspend failed without error message". Suspend worked each time, but it is interesting that there is one copy of that message for each sleep that happens. The first one is the one I initiate, and the subsequent ones are the automatic cycling.

[Noel J. Bergman (noeljb)]

Following up on Greg Orlowski's comment in https://bugzilla.redhat.com/show_bug.cgi?id=475585#c6, I checked something that leads me to really wonder about the keyboard handling.

If I suspend with the Fn-F4 hotkey, I go through the aforementioned redundant cycling before the system stays awake. But If I do:

 # pm-suspend

instead, the system behaves as desired. Likewise, if I suspend from the Gnome Fast User Switch Applet 2.24.0, everything works properly. So it appears to be only when suspending via the hotkey that this problem occurs.

[Noel J. Bergman (noeljb)]

Based on what we've seen regarding the differential behavior between hotkey and command initiated suspend, I cannot claim that Intrepid actually would behave any differently, given that Bug 267682 and Bug 217504 prevent hot key suspend in Intrepid.

[Geir Ove Myhr (gomyhr)]

I have marked bug 307977 and bug 307986 as duplicates of this bug, and added the packages that those bugs were reported against. It seems to be a Lenovo Thinkpad specific problem, since Noel has a T61p (from the attached HalComputerInfo.txt), Marc has a X200s and Jeffrey has a X61 Tablet. I can also confirm on a X61 Tablet using a Jaunty alpha-2 LiveCD.

Btw, I also have a problem with suspend from the menu (bug 311362), maybe you can comment there if you are experiencing/not experiencing the same (maybe it's LiveCD specific).

[Geir Ove Myhr (gomyhr)]

The wiki page https://wiki.ubuntu.com/DebuggingACPI has some
information about what is needed for ACPI related bugs. I attach mine
for the Thinkpad X61 Tablet. Since I'm running from a LiveCD I cannot
reboot and then attach kern.log.0, so I'm rather attaching kern.log
from the current session.

[Noel J. Bergman (noeljb)]

> It seems to be a Lenovo Thinkpad specific problem

No -- in the bug report at RedHat, Greg Orlowski reported that "[his] laptop is a Dell D600."

[Geir Ove Myhr (gomyhr)]

Ok, I should have checked the Redhat bug report as well.

I can also confirm this bug on a Compaq nx7400 using a Jaunty alpha-2 LiveCD. In contrast to my Thinkpad, it stays awake after the second resume (the thinkpad only stays awake after the third resume).

[Milan Bouchet-Valat (nalimilan)]

Have a look at bug 149665, which is a long story and may have reappeared recently.

[sanktnelson (launchpad-maibaums)]

is this any closer to resolution? I can reproduce it too, and it's very annoying. (Thinkpad x61t, intrepid)

[Andy Whitcroft (apw)]

@sanktnelson -- can you confirm that you avoid this issue if you use the user-switcher to suspend.

[Andy Whitcroft (apw)]

I can confirm this bug on my Thinkpad T30 laptop, suspending from the user-switcher menu is fine, only suspends via the FN-suspend button are affected.

Testing with the gnome-power-manager running --no-daemon I get the following logs:

# user-switcher suspend

** (gnome-power-manager:30826): WARNING **: Suspend failed without error message

# FN-suspend

** (gnome-power-manager:30826): WARNING **: Suspend failed without error message

** (gnome-power-manager:30826): WARNING **: DBUS timed out, but recovering

** (gnome-power-manager:30826): WARNING **: Suspend failed without error message

# FN-suspend #2

** (gnome-power-manager:30826): WARNING **: DBUS timed out, but recovering

** (gnome-power-manager:30826): WARNING **: Suspend failed without error message

** (gnome-power-manager:30826): WARNING **: Suspend failed without error message

[Andy Whitcroft (apw)]

Attached is a full verbose log from gnome-power-manager.

[Andy Whitcroft (apw)]

If I am understanding my log on the previous comment correctly then we receive two HAL events and an Xevent for the single key-press. Specifically we receive a HAL event, then an Xevent, and then a second HAL event:

TI:13:33:22 TH:0x9b13640 FI:gpm-button.c FN:hal_device_condition_cb,430
 - condition=ButtonPressed, details=sleep
TI:13:33:22 TH:0x9b13640 FI:gpm-button.c FN:emit_button_pressed,374
 - emitting button-pressed : sleep
TI:13:33:22 TH:0x9b13640 FI:gpm-manager.c FN:button_pressed_cb,1020
 - Button press event type=sleep

TI:13:33:47 TH:0x9b13640 FI:gpm-button.c FN:gpm_button_filter_x_events,122
 - Key 150 mapped to HAL key suspend
TI:13:33:47 TH:0x9b13640 FI:gpm-manager.c FN:button_pressed_cb,1020
 - Button press event type=suspend

TI:13:34:08 TH:0x9b13640 FI:gpm-button.c FN:hal_device_condition_cb,430
 - condition=ButtonPressed, details=sleep
TI:13:34:08 TH:0x9b13640 FI:gpm-button.c FN:emit_button_pressed,374
 - emitting button-pressed : sleep
TI:13:34:08 TH:0x9b13640 FI:gpm-manager.c FN:button_pressed_cb,1020
 - Button press event type=sleep

Need to understand where all of these are coming from.

[Andy Whitcroft (apw)]

Attached is my lshal --monitor output from a single suspend press, but with three suspend/resume cycles.

[Andy Whitcroft (apw)]

This log contains these two lines, before all of the suspend/resume cycles:

15:12:41.659: computer_logicaldev_input_3 condition ButtonPressed = sleep
15:12:41.690: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = sleep

Need to figure out if these are two different keys or not.

[Andy Whitcroft (apw)]

I believe they are two keys. So we are specifically getting two events from Hal and one via X. This does not look like a kernel issue to my eye.

[Andy Whitcroft (apw)]

I am suspicious that the XF86Sleep event may have started to be recognised as part of updating the XKeySymDB as part of fixing the XF86Battery key support in bug #281134.

[Martin Pool (mbp)]

As of yesterday's Jaunty, this problem has got worse: I now see the behaviour if I just close the laptop lid, whereas previously it only happened from Fn-F4.

[Milan Bouchet-Valat (nalimilan)]

Andy: Have you read this recent post by Richard Hughes [1]?
"all the multimedia buttons come up through both X and HAL. g-p-m has to filter the second button, and mostly this works well": maybe 'mostly' is the problem here. :-)

1: http://blogs.gnome.org/hughsie/2009/01/28/gnome-power-manager-and-buttons/

[Alan Pope 🍺🐧🐱 🦄 (popey)]

Richard talks about GPM 2.27, Ubuntu Jaunty is on 2.24..0

[Milan Bouchet-Valat (nalimilan)]

"in 2-27 - gnome-power-manager will stop listening to HAL for button events": to me this can mean that in previous releases, HAL events can interfere. Anyway it's just a hint, I just implied that maybe Richard knows more about the current bug.

[Chris Bainbridge (chris-bainbridge)]

This also occurs in KDE with kpowersave on Thinkpad T42p in both Intrepid and Jaunty. It does not occur when selecting Suspend in Shutdown menu, only when using fn-f4 hotkey.

I thought it might be something to do with ACPI event processing discussed in bug 267682 ie. the suspend event gets delivered and processed more than once by different handlers, but I haven't confirmed this.

[Marc Jauvin (marc-r4l)]

* I'm using Intrepid Ibex on a Thinkpad T61, and I found that if you run gconf-editor and "uncheck" the following option:

   apps->gnome-power-manager->lock->suspend

The problem will happen when suspend is triggered from fn-f4 (not from the user switcher applet).

But it never happens if this option is checked (lock screen when suspending).

[Matija Polajnar (matija-polajnar)]

I also see this issue with Intrepid on Thinkpad R52. I'm not sure when it appeared (with update to Intrepid or later). For me, changing the "lock on suspend" option has no effect; computer "resuspends" regardless of that setting.

[Steve Langasek (vorlon)]

> 15:12:41.659: computer_logicaldev_input_3 condition ButtonPressed = sleep
> 15:12:41.690: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = sleep

I think this is an acpi-support bug (i.e., this bug is caused by acpi-support being here at all) - acpi-support is set up to synthesize a 'sleep' key event when pressing Fn+F4, but the kernel already handles synthesizing this event, so we end up with *two* hal sleep events showing up on two different input devices.

Whether the hal events are what g-p-m or kpowersave should be listening for is a separate question - but we definitely shouldn't be emitting two sleep events for one key press.

Conveniently, it happens that I've already committed a fix for this to the acpi-support bzr branch, and will upload soon. In the meantime, users can verify that this fixes the problem by running 'sudo /etc/init.d/acpid stop' and then suspending with Fn+F4.

[Matija Polajnar (matija-polajnar)]

"Idea verification" seems to work for me, so I eagerly wait for yout patch to come through! Thank you!

[Milan Bouchet-Valat (nalimilan)]

Great work, Steve! These days you seem to be tackling a major power management bug every week - good to know they won't keep rotting like many others did before.

[Marc Jauvin (marc-r4l)]

Stoping acpid before suspend fixes this for me as well on Intrepid (Thinkpad T61).

Thanks!

[Geir Ove Myhr (gomyhr)]

Stopping acpid before suspend reduces the number of suspend-resume
cycles from 3 to 2 on my Thinkpad X61 Tablet. I guess those for whom
the problem is solved only had 2 cycles to begin with (i.e. the
computer would stay awake after the second wake-up call) (?)

I attach logs from `gnome-power-manager --no-daemon --verbose` with
and without acpid running. To make the logs easer to read, I did the
relevant actions just after each whole minute. In other words, for
acpid stopped:
21:24:0x: Pressed Fn+F4 to suspend
21:25:0x: Pressed power button to resume (falls back to sleep)
21:26:0x: Pressed power button to resume (stays awake)

For acpid started:
21:28:0x: Pressed Fn+F4 to suspend
21:29:0x: Pressed power button to resume (falls back to sleep)
21:30:0x: Pressed power button to resume (falls back to sleep)
21:31:0x: Pressed power button to resume (stays awake)

[Geir Ove Myhr (gomyhr)]

I should add that I'm running an updated Jaunty.
acpi-support: 0.116
acpid: 1.0.6-9ubuntu4
hal: 0.5.12~rc1+git20090120-0ubuntu1
gnome-power-manager: 2.24.0-0ubuntu14

[Jeffrey Baker (jwbaker)]

I'm with Geir Ove Myhr. The committed fix takes me from 3 to 2 cycles (bravo, Steve!) but that's still one too many.

[Matija Polajnar (matija-polajnar)]

Geir is right: Intrepid falls back to sleep only once, so that's why with stopped acpid the problem is fixed for me.

[Chris Bainbridge (chris-bainbridge)]

I also get two resume cycles rather than three when acpid is stopped.

With acpid running I got:
$ xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0
keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0
keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0
keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0

With it stopped I get:
keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0
keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0

# input-events 8
/dev/input/event8
   bustype : BUS_HOST
   vendor : 0x1014
   product : 0x5054
   version : 16641
   name : "ThinkPad Extra Buttons"
   phys : "thinkpad_acpi/input0"
   bits ev : EV_SYN EV_KEY EV_MSC

waiting for events
13:31:12.184303: EV_KEY KEY_SLEEP pressed
13:31:12.184320: EV_SYN code=0 value=0
13:31:12.184325: EV_KEY KEY_SLEEP released
13:31:12.184328: EV_SYN code=0 value=0
timeout, quitting

I wonder if it is possible that these two events (press and release) both get mapped onto XF86Sleep keycode events, generating two suspend calls?

[Launchpad Janitor (janitor)]

This bug was fixed in the package acpi-support - 0.117

---------------
acpi-support (0.117) jaunty; urgency=low

  * Drop acpi_fakekey translations for keys that are correctly handled
    in the kernel input layer:
    - events/ibm-sleepbtn (LP: #306310)
    - events/ibm-lockbtn, thinkpad-lockorbattery.sh
    - events/ibm-hibernatebtn
    - events/lenovo-lockbtn
    - events/ibm-videobtn
    - events/thinkpad-mute, always-mute.sh
    - events/thinkpad-volume-down
    - events/thinkpad-volume-up (LP: #51537)
    - events/thinkpad-thinklight, thinkpad-thinklight.sh
    - events/tosh-brightness-up
    - events/tosh-brightness-down, toshbright.sh
    - events/tosh-mute
    - events/tosh-sleep
    - events/sony-hibernate
    - events/sony-brightness-up, events/sony-brightness-down, sonybright.sh
    - events/thinkpad-brightness-down, events/thinkpad-brightness-up,
      thinkpad-brightness-up.sh, thinkpad-brightness-down.sh
  * Also drop events/thinkpad-zoom, thinkpad-zoom.sh because this key
    isn't working correctly with or without this script and should be
    fixed up in hal.
  * debian/control: document Vcs-Bzr for the package.

 -- Steve Langasek <email address hidden> Mon, 02 Feb 2009 14:28:38 +0100

[Steve Langasek (vorlon)]

On Mon, Feb 02, 2009 at 01:33:32PM -0000, Chris Bainbridge wrote:
> With it stopped I get:
> keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0
> keycode 150 = (keysym 0x1008ff2f, XF86Sleep), state = 0x0

This is the expected behavior; one of these is the KeyPress event, the other
is the KeyRelease event.

> I wonder if it is possible that these two events (press and release)
> both get mapped onto XF86Sleep keycode events, generating two suspend
> calls?

AIUI, the remaining issue is that gnome-power-manager is responding both to
the X keypress and the hal event. (I.e., look at the output of 'lshal -m'.)
It's not clear to me why this affects some systems and not other.

For me, lshal -m shows:

17:05:11.878: computer_logicaldev_input_4 condition ButtonPressed = sleep

and no other events when hitting Fn+F4.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Geir Ove Myhr (gomyhr)]

I just updated the acpi-support package to 0.117, and the computer now
only goes back to sleep once (same as when acpid was stopped before).

I also only get one event from `lshal -m`:
11:46:09.220: computer_logicaldev_input_3 condition ButtonPressed = sleep

I'm attaching the full output of `lshal -m` when it goes to sleep,
wakes up for a moment and wakes up permanently, in case this is
useful.

Would it be right to reopen this bug for gnome-power-manager?

Geir Ove

[Steve Langasek (vorlon)]

Based on discussion with apw, reopening this task since it appears that gnome-power-manager is responding to both an X key event and a hal event when it shouldn't do so.

[Martin Pool (mbp)]

As of today's Jaunty updates, I'm getting one additional suspend
cycle, and after coming back from suspend I experienced this behaviour
which I'm assuming is related:

After pressing Fn a second time to wake up, I got the gnome screen
lock dialog. I tried to type into it but I didn't see anything when I
pressed keys. Ctrl-Alt-F1 to switch to a text console didn't work.
However, the mouse did still respond, and I could click Cancel to
remove the dialog. When I clicked the mouse, it came back, and I still
couldn't type.

I then pressed Switch user, and got a login screen which _did_ respond
to keyboard input. I typed in my username and password, and it
returned me to my original desktop. However, the keyboard is still
not working in any application.

By sshing in I can see there is a traceback (not an oops?) in the
kernel log, see attached.

[Martin Pool (mbp)]

After I logged out of my gnome session, the keyboard worked ok at the login screen and in the next session.

I suspended the machine again and I did get the double-resume, but I did not have trouble with my keyboard on this attempt.

[Martin Pool (mbp)]

I split that out to bug 325191.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-power-manager - 2.24.2-2ubuntu1

---------------
gnome-power-manager (2.24.2-2ubuntu1) jaunty; urgency=low

  [ Ted Gould ]
  * Merge from Debian experimental.
  * Remove 20_fix_precentage_closures.patch as already applied upstream.
  * Merge in the mactel changes. See mactel changelog entries below.
  * Remove 02_cast_align.patch as it only hides the problem and doesn't fix
  * Remove 13_bugreport_bin_sh.patch as it conflicts with the Debian added
    07-bugreport-shebang.patch patch.
  * Remove 26_check_for_active_session.patch as it should no longer be
    required with the upstream changes.
  * debian/rules: don't disable policy-kit

  [ Steve Langasek ]
  * debian/control: point Vcs-Bzr at current branch.
  * Drop debian/patches/70_relibtoolize.patch in favor of
    76_autoreconf.patch
  * debian/patches/14_inhibit_tool.patch,
    debian/patches/17_icon_cache.patch: split out the changes to
    Makefile.in, so we can handle these as a batch in 76_autoreconf.patch
  * Refresh 76_autoreconf.patch for the above changes
  * 95_dont_listen_for_suspend_X_key.patch: handle 'suspend' via hal only,
    the same as we already do for 'hibernate', eliminating a double-suspend
    on ThinkPads. LP: #306310.

gnome-power-manager (2.24.2-2) experimental; urgency=low

  * Switch to quilt to manage patches; build-depend on quilt.
  * 02_cast_align.patch: new patch. Use memcpy instead of casting
    pointers with incompatible alignments. Closes: #510011.
  * 70_relibtoolize.patch: re-run the autotools on top of the source to
    avoid the rpath issue.
  * Pass -O1 -z defs --as-needed to the linker.

gnome-power-manager (2.24.2-1) experimental; urgency=low

  * New upstream release
  * debian/patches/02-ups-invalid-free.patch
    - Removed, fixed upstream
  * debian/patches/03-system-policy.patch
    - Updated
  * debian/patches/04-graph-labels.patch
    - Removed, fixed upstream
  * debian/patches/05_translation_crash.patch
    - Removed, fixed upstream
  * debian/patches/06-bugreport-debian.patch
    - Updated
  * debian/patches/08-desktop-bugreport-path.patch
    - Updated

gnome-power-manager (2.24.0-1mactel4) unstable; urgency=low

  * Fix light sensor scaling

gnome-power-manager (2.24.0-1mactel3) unstable; urgency=low

  * Nonlinear stepping for smooth dimming
  * Patch trimming for upstream

gnome-power-manager (2.24.0-1mactel2) unstable; urgency=low

  * Mixed signed/unsigned problem in gpm-brightness-xrandr fixed.
    LP: #289520

gnome-power-manager (2.24.0-1mactel1) unstable; urgency=low

  * The gpm-brightness-xrandr smooth brightness function does not take
    the number of brightness levels into account. On recent Macbooks,
    this leads to some 20000 brightness-set calls on startup, an
    activity that takes about one and a half minute. During this time,
    gpm is not responsive. This patch introduces scaled stepping,
    which fixes the problem. LP: #289520

 -- Steve Langasek <email address hidden> Sat, 07 Feb 2009 09:17:32 -0500

[Andy Whitcroft (apw)]

@Steve -- confirmed that with both of these fixes (hal and gnome-power-manager) my thinkpad T30 which was triple suspending now suspends exactly once from the button.

[Martin Pitt (pitti)]

Steve, I'm just porting our patches to 2.25.91. Is that gnome-power-manager patch still relevant with the recent ACPI? Why was the upstream task marked invalid? Without the acpi-support goo, the change should be relevant to upstream as well?

Anyway, new g-p-m now uses DeviceKit-power, so it wouldn't listen to hal events at all any more. Thus I drop the patch for now, and we'll see how it goes. Andy, if you notice that this issue returns in Karmic (or if you enable the ubuntu-desktop PPA with the new g-p-m), please speak up here.

Thanks! Martin

[Milan Bouchet-Valat (nalimilan)]

Martin: upstream marked the bug as obsolete because it should be fixed in current 2.26 g-p-m (as you said, HAL events are not listened to now). Since we ship 2.24, they don't bother about our bugs...

[Matija Polajnar (matija-polajnar)]

Seems to be fixed for me in Jaunty.

[Joakim Lundborg (joakim-lundborg)]

I don't have this problem since Jaunty (Lenovo ThinkPad X300)

[Elie Charest (archiesteel)]

I seem to be having this problem with Karmic... :-(

[Steve Langasek (vorlon)]

Elie, please show the output of acpi_listen running across a suspend/resume test when you get the dual suspend. Also, you may want to open a new bug report, since this bug has been fixed for some time and no one has reported any recurrences of it.

What kind of laptop is this on?

[Elie Charest (archiesteel)]

I'm running current Karmic on a Dell Mini 10v.

The problem is intermittent - in fact, I've been trying to reproduce it for an hour. Now that I *need* for it to happen, of course, it's not... :-/

I can tell, however, that the system runs fine after waking up a second time. I remember it happening at lunch, i.e. when I open my laptop after more than 12 hours of it being off. I'll keep acpi_listen running and see if it happens tomorrow, then post the output here - or actually open a new bug with apport...I assume the package handling suspend/resume is still called gnome-power-manager?

(BTW didn't know about acpi_listen, cool little utility! It would have been handy to debug the more serious suspend/resume problems I had with my previous laptop...)

[sanktnelson (launchpad-maibaums)]

this regression in Karmic has hit me also. Unfortunately I have not been able to reliably reproduce it, so it seems slightly different from the previous issue.

[Martin Pitt (pitti)]

Please also see bug 425411 for a related karmic bug.

[Martin Pitt (pitti)]

Please see bug 425411 for a related karmic bug.

[Elie Charest (archiesteel)]

acpi_listen doesn't show anything but the original lid event:

$ acpi_listen
button/lid LID0 00000080 00000006

I'm going to try the fix for bug 425411.

[Jeffrey Baker (jwbaker)]

Yep, recently started seeing this again on ThinkPad X61 Tablet after not seeing it for months.

[Jerry Quinn (jlquinn)]

I see this behavior on my Asus 1000HA with Karmic installed and 2.6.31-15. I get it perhaps one in three wakeups from sleep. It gets as far as showing me an X screen then goes back to sleep. The second wakeup then works as expected.

[Przemek K. (azrael)]

Possibly related bug in Karmic: bug 492649