Bug 1094983

Summary:	[regression] kernel 3.14.2-200.fc20.x86_64 doesn't hibernate
Product:	[Fedora] Fedora	Reporter:	Hin-Tak Leung <htl10>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, snark2004-first
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-07 06:56:17 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:

Description Hin-Tak Leung 2014-05-06 20:35:23 UTC

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

Comment 1 snark2004-first 2014-05-10 02:18:56 UTC

Confirm.
Dell XPS x86_64 only (so far) fails to resume on 3.14.2-200.fc20.x86_64 after update yesterday.

Comment 2 snark2004-first 2014-05-10 03:20:51 UTC

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.

Comment 3 snark2004-first 2014-05-12 02:37:17 UTC

Same applies to 3.14.3-200.fc20.x86_64

Comment 4 Hin-Tak Leung 2014-05-25 03:56:44 UTC

Still a problem with 3.14.4-200.fc20.x86_64

Comment 5 snark2004-first 2014-05-27 05:17:08 UTC

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.

Comment 6 Hin-Tak Leung 2014-06-11 09:31:01 UTC

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.

Comment 7 Hin-Tak Leung 2014-06-30 18:53:15 UTC

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 .

Comment 8 Hin-Tak Leung 2014-07-10 01:22:39 UTC

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.

Comment 9 Hin-Tak Leung 2014-07-22 15:24:17 UTC

Still a problem with 3.15.6-200.fc20.x86_64

Comment 10 Hin-Tak Leung 2014-08-03 03:08:34 UTC

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 .

Comment 11 Hin-Tak Leung 2014-08-06 04:23:56 UTC

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).

Comment 12 Josh Boyer 2014-08-07 06:56:17 UTC

Thanks for letting us know.  We track one issue per bug so since the hibernation is fixed we'll close this out.