Bug 497563 - suspend should be a synchronous operation
suspend should be a synchronous operation
Product: Fedora
Classification: Fedora
Component: DeviceKit-power (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-24 14:22 EDT by Matthew Garrett
Modified: 2013-01-10 02:47 EST (History)
6 users (show)

See Also:
Fixed In Version: 008-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-15 22:24:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 581016 None None None Never

  None (edit)
Description Matthew Garrett 2009-04-24 14:22:54 EDT
g-p-m assumes that suspend is synchronous, but devicekit-power makes a g_spawn_command_line_async() call. The long term ideal might be to send a resume signal when the system has resumed (determined by pm-suspend exiting) and refactoring g-p-m to deal with that, but in the short term just making it synchronous should do. The dpk-client code probably needs to ignore the error returned if it's a timeout.
Comment 1 Richard Hughes 2009-04-25 06:09:05 EDT
commit dccd5fc898bcb3d66038902cfddeb9ea935f5a18
Author: Richard Hughes <richard@hughsie.com>
Date:   Sat Apr 25 11:07:30 2009 +0100

    Ignore method timeouts when we suspend and hibernate

:100644 100644 045c6d7... 859a8be... M  devkit-power-gobject/dkp-client.c

commit 6b197ebd5e0f914071a03f5e3da21e9045df12bc
Author: Richard Hughes <richard@hughsie.com>
Date:   Sat Apr 25 11:06:52 2009 +0100

    Make the suspend and hibernate scripts execute synchronously. Fixes rh#497563

:100644 100644 fdcd21e... bcc6504... M  src/dkp-daemon.c
Comment 2 Richard Hughes 2009-04-25 06:58:51 EDT
Could you please test the packages here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1320198

Comment 3 Matthew Garrett 2009-04-26 10:56:18 EDT
This works, but I'm now seeing double suspends when I hit the sleep key. I'm guessing that this is due to g-p-m not processing the hal event until after resume now (as it's blocked in performing the suspend), and so too much time has passed between them for it to be handled by the de-duplication. Is there any reason for us to listen to hal at all for sleep or hibernation button presses?
Comment 4 Matthew Garrett 2009-04-26 11:36:21 EDT
Confirmed that building gnome-power-manager without --enable-legacy-keys fixes this for me, so from the DeviceKit-power point of view this is fixed in the koji build.
Comment 5 Richard Hughes 2009-04-26 15:05:33 EDT
(In reply to comment #4)
> Confirmed that building gnome-power-manager without --enable-legacy-keys

Then we get no lid events. :-(

Comment 6 Matthew Garrett 2009-04-26 15:22:42 EDT
Ok. So perhaps we should just ignore button (rather than switch) events from hal. I'll open a g-p-m bug for this.
Comment 7 Richard Hughes 2009-04-27 03:40:04 EDT
Is it insane to add a property lid-is-closed to DeviceKit-power? I can't think of a better place for the lid status information, and don't really want to add low level /dev/input type stuff to g-p-m.

If I'm adding lid-is-closed, would SW_TABLET_MODE, SW_HEADPHONE_INSERT and SW_RADIO also needed to be handled?

I can't help thinking this is feature bloat, and should probably be exposed in Xorg or something. Ideas welcome.
Comment 8 Matthew Garrett 2009-04-28 10:23:41 EDT
Switches can't be exposed in Xorg until XInput 2 - there's simply nothing in the protocol to let us deal with them. I think this is simply going to be a case of needing Hal until the rest of the stack catches up. Unless we add a DeviceKit-input.
Comment 9 Richard Hughes 2009-05-08 04:00:47 EDT
Upstream can now use the lid-is-closed property in DeviceKit-power -- we just have to fix this for F11. I'm thinking of including your hacky patch to g-p-m, and tagging the sync DeviceKit-power. Does that sound like a plan?
Comment 10 Fedora Update System 2009-06-01 07:32:56 EDT
DeviceKit-power-008-1.fc11 has been submitted as an update for Fedora 11.
Comment 11 Fedora Update System 2009-06-02 10:19:10 EDT
DeviceKit-power-008-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update DeviceKit-power'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5728
Comment 12 Bug Zapper 2009-06-09 10:31:25 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 13 Jan Drábek 2009-06-15 06:34:05 EDT
Installing this update actually breaks suspend - after waking up laptop go asleep again... (and twice more)...

Btw. this bug seems to be related with 497655
Comment 14 Fedora Update System 2009-06-15 22:24:25 EDT
DeviceKit-power-008-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Jan Drábek 2009-06-16 04:39:57 EDT
As I said yesterday - this update BREAK suspend! Now it is suspending three times!
Comment 16 Richard Hughes 2009-06-16 04:47:58 EDT
(In reply to comment #15)
> As I said yesterday - this update BREAK suspend! Now it is suspending three
> times!  

Different bug, different component. Have you tried updating gnome-power-manager?
Comment 17 Jan Drábek 2009-06-16 07:31:35 EDT
I don't suppose so.

Firstly, I completed today's update and try it again - the problem persist.

Then, I tried downgrade only DeviceKit-power (to version 0.1.20090401git.fc11) and the problem just disappeared.

So, please consider that, thanks.

Btw. My laptop is Thinkpad R61.

Note You need to log in before you can comment on or make changes to this bug.