Bug 813822 - suspend doesn't work - it only turns off NetworkManager and runs screensaver
suspend doesn't work - it only turns off NetworkManager and runs screensaver
Status: CLOSED DUPLICATE of bug 812588
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F17Blocker/F17FinalBlocker
  Show dependency treegraph
 
Reported: 2012-04-18 09:46 EDT by Petr Schindler
Modified: 2012-04-19 06:14 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-19 06:14:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Petr Schindler 2012-04-18 09:46:17 EDT
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 09:47:20 EDT
Created attachment 578360 [details]
/var/log/pm-suspend.log
Comment 2 Nils Philippsen 2012-04-18 12:07:25 EDT
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 16:24:42 EDT
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 16:27:13 EDT
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 06:14:20 EDT
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.