Bug 910547

Summary: resume doesn't work, but only if PC suspended more than 1 hour
Product: [Fedora] Fedora Reporter: nicofo <nicofo>
Component: pm-utilsAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: jskarvad, pknirsch, rhughes
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-05 18:09:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log/pm-suspend.log
none
/var/log/messages none

Description nicofo 2013-02-12 19:56:40 UTC 
Created attachment 696600 [details]
/var/log/pm-suspend.log

Description of problem:
1) if I suspend Fedora, I can resume it without any problem after a few minutes
2) BUT if I resume it after a long time (say 1 or 2 hours at least) -> resume doesn't work

See log attached: /var/log/pm-suspend.log and /var/log/messages
 suspend at 18:16:20CET
 attempt to resume at 20:06:16CET

Version-Release number of selected component (if applicable):
pm-utils-1.4.1-22.fc18.i686

How reproducible:
always, if resume after a long time

Steps to Reproduce:
1. suspend (suspend OK)
2. wait 2 hours (maybe 30 min is enough ?)
3. resume
  
Actual results:
resume doesn't work: a few messages appear on screen then black screen (no input on screen)

Expected results:
resume should always work

Additional info:
I had no problem with Fedora 16
Comment 1 nicofo 2013-02-12 20:14:59 UTC 
Created attachment 696613 [details]
/var/log/messages

(see several ERRORS in logs)
Comment 2 Jaroslav Škarvada 2013-03-18 11:20:19 UTC 
Could you try with kernel-3.8? It has various ACPI fixes.
Comment 3 nicofo 2013-04-05 18:09:50 UTC 
Yes, I have tried with kernel 3.8.* => for a few weeks, I have not been able to reproduce this bug. Consequently I mark this bug 'closed'.