Bug 813822 - suspend doesn't work - it only turns off NetworkManager and runs screensaver
Summary: suspend doesn't work - it only turns off NetworkManager and runs screensaver
Status: CLOSED DUPLICATE of bug 812588
Alias: None
Product: Fedora
Classification: Fedora
Component: pm-utils
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: F17Blocker, F17FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2012-04-18 13:46 UTC by Petr Schindler
Modified: 2012-04-19 10:14 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-04-19 10:14:20 UTC


Attachments (Terms of Use)
/var/log/messages (838.55 KB, application/octet-stream)
2012-04-18 13:46 UTC, Petr Schindler
no flags Details
/var/log/pm-suspend.log (5.48 KB, text/x-log)
2012-04-18 13:47 UTC, Petr Schindler
no flags Details

Description Petr Schindler 2012-04-18 13:46:17 UTC
Created attachment 578359 [details]
/var/log/messages

Description of problem:
When I try to suspend my laptop (from user menu -> suspend) it only turns off the NetworkManager, runs screensaver and then ... nothing. It doesn't suspend. When I log back to the desktop the Network manager is still sleeping.

My guess: It executes pre-suspend scripts but then it doesn't suspend. So it can't be woken and no post-suspend scripts are executed.

When I install from Fedora 17 Beta DVD it works. It stops working after updates (I have updates-testing enabled).

This is from /var/log/messages (the whole log is appended):
dbus[663]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.4" (uid=0 pid=647 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.40" (uid=1000 pid=1222 comm="gnome-session ")

Version-Release number of selected component (if applicable):
Fedora 17 Beta with updates (with updates-testing enabled)
pm-utilsi-1.4.1-18.fc17.x86_64
gnome-session-3.5.0-2.fc17.x86_64
systemd-44-4.fc17.x86_64

How reproducible:
first suspend after boot

Steps to Reproduce:
1. Boot up the system
2. Try to suspend
  
Actual results:
It turns off the NetworkManager, runs screensaver and doesn't suspend. When I log back into system the network isn't working

Expected results:
laptop should be suspended and after waking up network should work properly

Additional info:
I propose this bug as blocker. It doesn't break any criterion, but suspend is default session managing action and so it should work properly (or at least basic functionality should work). Also we have Beta test case which is now broken: https://fedoraproject.org/wiki/QA:Testcase_desktop_login

Comment 1 Petr Schindler 2012-04-18 13:47:20 UTC
Created attachment 578360 [details]
/var/log/pm-suspend.log

Comment 2 Nils Philippsen 2012-04-18 16:07:25 UTC
Same here, Thinkpad T520 and these package versions:

pm-utils-1.4.1-18.fc17.x86_64
gnome-session-3.4.0-2.fc17.x86_64
systemd-44-4.fc17.x86_64
systemd-44-4.fc17.i686
kernel-3.3.1-5.fc17.x86_64
kernel-3.3.2-1.fc17.x86_64

Comment 3 Nils Philippsen 2012-04-18 20:24:42 UTC
Some more data:

- I've seen this with all the above kernels and kernel-3.3.1-3.fc16.x86_64 (the left over from F-16 prior to the upgrade). It's unlikely that this is (just) a kernel issue as the same kernel suspended just fine before F-17.

- I've attempted suspending with "sh -x pm-suspend" and tailing /var/log/pm-suspend.log -- it seems that the sync just before "echo mem > /sys/power/state" hangs.

- Subsequent executions of the sync command hangs in the sync() call.

- "echo mem > /sys/power/state" hangs, a second attempt gives "device or resource busy"

- I've seen this in both Gnome Shell and XFCE

I'll set severity to high as this is crash-like behavior and not recoverable.

Comment 4 Nils Philippsen 2012-04-18 20:27:13 UTC
I knew I forgot something: one or two times when testing this and then shutting down the system, it suspended the machine during shutdown, then when resuming finished shutting down and switched off. As if whatever caused stuff to be wedged was killed off, then pm-action could continue on its merry way and issue the suspend command.

Comment 5 Nils Philippsen 2012-04-19 10:14:20 UTC
This is actually a deadlocked fusermount process and is fixed in selinux-policy-targeted-3.10.0-116.fc17, closing as duplicate.

*** This bug has been marked as a duplicate of bug 812588 ***


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