Bug 750755

+++ This bug was initially created as a clone of Bug #748723 +++

Description of problem:
The system does not resume after suspend.
Note: it happens occasionally (every few days) after overnight suspend.
 
Version-Release number of selected component (if applicable):
$ rpm -q pm-utils
pm-utils-1.3.1-4.fc14.i686

How reproducible:
menu: System - Shut Down... - Suspend

Steps to Reproduce:
1. as above
2.
3.
  
Actual results:
System can not resume after suspend.

Expected results:
After suspend, a good resume.

Additional info:

--- Additional comment from jurek.bajor on 2011-10-25 09:21:54 CEST ---

Created attachment 530017 [details]
good suspend but resume failed log

--- Additional comment from jurek.bajor on 2011-10-25 09:23:05 CEST ---

Created attachment 530018 [details]
good suspend and good resume

--- Additional comment from jurek.bajor on 2011-10-25 09:28:13 CEST ---

Created attachment 530019 [details]
system messages log at time of both failed and good suspend/resume runs

--- Additional comment from jskarvad on 2011-10-25 09:41:58 CEST ---

The pm log seems good. In the syslog it seems to hang after the b44, but it doesn't mean anything. Try to debug according to:
http://fedoraproject.org/wiki/KernelCommonProblems#Suspend.2FResume_failure
Also please note the F14 is near EOL, could you upgrade and retest with newer kernel?

--- Additional comment from jurek.bajor on 2011-11-02 09:23:47 CET ---

I changed this BZ Report to F16 (I am testing F16 RC4 Live-CD LXDE).

I added pm-suspend.log-F16 attachment.

1.
I think you should change the order (reverse numbering) of dhclient and
NetworkManager.
It is:
-  on suspend
...
/usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend:success.
...
/usr/lib/pm-utils/sleep.d/56dhclient suspend suspend:success.
...
- on resume
...
/usr/lib/pm-utils/sleep.d/56dhclient resume suspend:success.
...
/usr/lib/pm-utils/sleep.d/55NetworkManager resume suspend:success.
...

The reason for changing order is:
- on suspend you can not bring down NM and interfaces and still have dhclient
  active
- on resume you should let NM bring up interfaces first and then let dhclient
  request IPs, etc
 
2.
Please change the corresponding line grouping and spacing so the log is easier
to read.

It is:
...
/usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend:
Having NetworkManager put all interfaces to sleep...Done.

/usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/56atd suspend suspend:
...

and it would be better:
...
/usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend: success.

Running hook /usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend:
Having NetworkManager put all interfaces to sleep...Done.
/usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend: success.

Running hook /usr/lib/pm-utils/sleep.d/56atd suspend suspend:
...

JB

--- Additional comment from jurek.bajor on 2011-11-02 09:25:34 CET ---

Created attachment 531285 [details]
/var/log/pm-suspend.log for F16 RC4

--- Additional comment from jskarvad on 2011-11-02 11:05:34 CET ---

(In reply to comment #5)
> 1.
> I think you should change the order (reverse numbering) of dhclient and
> NetworkManager.
>
The dhclient hook is provided by dhcp package, not the pm-utils.

I think it should work as is, because the dhclient hook only processes interfaces that are not handled by NetworkManager (see the 56dhclient source), thus the ordering shouldn't matter. Also CCing dhcp maintainer if he has any comments about this.

I think your problem is somewhere else. Please try to bypass the pm-utils, by suspending from command line with command:
# echo mem > /sys/power/state
or hibernating with command:
# echo disk > /sys/power/state
Try it several times from a) graphical target (e.g. something previously called the runlevel 5) and also b) text mode (runlevel 3). If only a) fails it is probably the X org driver, if b) only fails it is probably the kernel.

> 2.
> Please change the corresponding line grouping and spacing so the log is easier
> to read.
> 
Good point, I will clone this and I will fix it in rawhide (and also post upstream).