Hide Forgot
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:
Created attachment 530017 [details] good suspend but resume failed log
Created attachment 530018 [details] good suspend and good resume
Created attachment 530019 [details] system messages log at time of both failed and good suspend/resume runs
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?
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
Created attachment 531285 [details] /var/log/pm-suspend.log for F16 RC4
(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).
> 2. > Please change the corresponding line grouping and spacing so the log is easier > to read. > Cloned as bug 750755.
(In reply to comment #7) > ... > 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. > ... Well, it happened, but on the notebook with F14: Installed Packages pm-utils.i686 1.3.1-4.fc14 @updates While in Gnoem, on 3rd try with '# echo disk > /sys/power/state' it crashed with ABRT reporting: Package: kernel Latest Crash: Wed 02 Nov 2011 02:42:33 PM Command: not_applicable Reason: BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1079 Comment: None Bug Reports: I also got quite a lot of messages in Gnome terminal following that hibernate entry. Next the system just shutdown and I had to restart it as usually (without any hibernation process effects). The /var/log/messages contained the crash messages as in messages.crash-f14 attachment, starting approx with: ... Nov 2 14:42:05 localhost kernel: [26753.941110] Restarting tasks ... Nov 2 14:42:05 localhost kernel: [26753.945535] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1079 ... and followed by my normal reboot messages. Despite the fact that this is F14 and near EOL, perhaps the code is common to F16, so please take a look at it. I tried on another notebook with F16 RC4 but all was OK. JB
Created attachment 531360 [details] /var/log/messages for F14 crash on hibernate
> BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1079 > This is probably consequence of the previous problem and not the problem itself. Is it reproducible with f16 kernel?
This is an up-to-date F16. I tested 3 times all cases as requested in Comment 7. No problems.
Thanks for info, I am closing this as it seems fixed in f16. Feel free to reopen if the problem persist.