Description of problem: I put my laptop to hibernate fairly regularly - for the reason that the screen occasionally fails to refresh etc (reported/commented elsewhere) - and hibernate/suspend/resume seem to reset the graphic device and work around it. Out of the two, hibernate is more reliable as suspend occasionally get stuck also. Anyway, hibernate with 3.14.2-200.fc20.x86_64 always fails. Everything the same, just booting kernel 3.13.10-200.fc20.x86_64 and hibernate works. Version-Release number of selected component (if applicable): kernel-3.14.2-200.fc20.x86_64 How reproducible: Always. Steps to Reproduce: 1. su - root, then systemctl hibernate 2. 3. Actual results: Machine fails to hibernate, and does not switch itself off. Expected results: Machine should hibernate and switches itself off after a while. Additional info: tried kernel-3.15.0-0.rc4.git1.1.fc21.x86_64 from koji, that hibernate alright, but cannot resume properly. On hibernate, kernel 3.15.0 generates two lines of: ODEBUG: assert_init not available (active state 0) object type: timer_list hint: stub_timer+0x0/0x20 seems to be dicussed in this thread: https://lkml.org/lkml/2013/3/9/45 grep'ing through /var/log/messages*, I was able to put the machine to hibernate with these, at least: 3.13.10-200.fc20.x86_64 3.13.9-200.fc20.x86_64 3.13.6-200.fc20.x86_64
Confirm. Dell XPS x86_64 only (so far) fails to resume on 3.14.2-200.fc20.x86_64 after update yesterday.
Looking at journalctl, seems it is hibernating successfully on 3.14.2-200.fc20.x86_64, but on restart it seems to activate the hardware, but sits on blank screen. Unable to interruot it. I had also added "resume=UUID=<uuid-of-swap>" to the boot parms, but didn't help.
Same applies to 3.14.3-200.fc20.x86_64
Still a problem with 3.14.4-200.fc20.x86_64
In my case looks like the radeon changes have broken things. - adding radeon.dpm=0 allows suspend to work. - no amount of fiddling with acpi_sleep parms could convince hibernate to work, so I have given up using it for now.
Still a problem with 3.14.5-200.fc20.x86_64 - I also tried adding radeon.dpm=0 to boot screen, but it does not help. (In reply to snark2004-first from comment #5) ... > - adding radeon.dpm=0 allows suspend to work. ... Just to clarify two things: (1) are you referring to suspend (to ram) or hibernate (to disk)? (2) you seems to refer to problems with waking up (from either)? My problem (regression in 3.14.x, still works well with 3.13.10 which I continue to use) is to do with hibernate (to disk). My laptop simply does not power-off fully on trying to suspend under 3.14.x, so it is *not* about waking up. I am hibernating instead of suspending (to reset the GPU...) because suspending has not been reliable for months if not years. I had a look at git log --grep=dpm drivers/gpu/drm/radeon/ and there are a small number of new changes in 3.14 (5 to 10?) which you might want to try reverting to see if it helps your situation. but yours seems to differ from mine (which is not helped by radeon.dpm=0). HTH.
3.14.8-200.fc20.x86_64 also breaks. also tried booting 3.14.8-200.fc20.x86_64 with radeon.dpm=0 radeon.aspm=0 radeon.runpm=0 . Does not improve. Still won't hibernate. Am staying with 3.13.10-200.fc20.x86_64 .
slight change of behavior with 3.15.x - kernel-3.15.3-200.fc20.x86_64 - can hibernate, but does not resume with "radeon.dpm=0 radeon.aspm=0 radeon.runpm=0", does not hibernate.
Still a problem with 3.15.6-200.fc20.x86_64
pleasantly surprised that 3.15.7-200.fc20.x86_64 seems to hibernate okay. Will write again if/when it fails (hopefully not need to...). It might be worth noting that I have these after a successful hibernate + wake cycle, in 3.15.7-200.fc20.x86_64 : ACPI: Error installing CMOS-RTC region handler radeon 0000:01:05.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment both seems to be new to 3.15.7-200.fc20.x86_64 .
3.16.0-1.fc21.x86_64 also works fine; but both 3.16.0-1.fc21.x86_64 and 3.15.7-200.fc20.x86_64 suffers from the uas /usb 4 external drive crash related problem (there is a work-around).
Thanks for letting us know. We track one issue per bug so since the hibernation is fixed we'll close this out.