Bug 1380957

Summary:	resume from hibernate randomly fails (silent reboot)
Product:	[Fedora] Fedora	Reporter:	johnnyfredo124
Component:	kernel	Assignee:	dracut-maint-list
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	24	CC:	danielsun3164, dracut-maint-list, fedora, gansalmon, harald, ichavero, itamar, jonathan, kernel-maint, madhu.chinakonda, maksim.orlov, mchehab, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-02 15:51:35 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 johnnyfredo124 2016-10-01 22:57:22 UTC

Description of problem:
Hibernating and resuming usually works. But sometimes, when resuming, after I enter the main password for my luks-encrypted disk, the computer silently reboots (so I get back to grub, re-enter the password for the luks-encrypted disk, and get into a fresh boot of F24; hibernated image is lost). This happens randomly (typically I get one bad resume if I try hibernating and resuming five times in a row).

Version-Release number of selected component (if applicable):
dracut 20.fc24 (but I am not sure this is a problem with dracut)

How reproducible:
On my computer (a Dell E6320), quite reproducible: I hibernate and resume a few times, until this happens.

Steps to Reproduce:
1. Hibernate
2. Resume
3. If resume works, go back to step 1.

Actual results:
Silent reboot

Expected results:
Resume from suspended state

Additional info:
This happens when I hibernate with "systemctl hibernate" or with "echo disk >/sys/power/state". Also I have tried passing the systemd.log_level=debug option when resuming, but it seems that the failed resume does not produce any output at all in the syslog. I will be happy to provide more info but am not
sure what, since I could not obtain any debug info.

Comment 1 johnnyfredo124 2016-10-04 16:41:40 UTC

I would like to add that hibernation on this computer worked 100% reliably with F24 using kernel versions up to 4.6.7 (included). This bug report is about a problem which occurs only with later kernels. If it can be useful to obtain more info, I can easily temporarily downgrade the kernel version for testing purposes.

Comment 2 johnnyfredo124 2016-10-07 08:50:56 UTC

On second thought, reassigning component to kernel since the problem appeared when kernel was updated from 4.6.7-300 to 4.7.2-201.

Comment 3 fedora 2016-10-13 12:16:59 UTC

I'm seeing similar behavior after kernel updates. I've been tracking it as part of bug 1206936 where it was misplaced. This is my experience with the recent kernel versions:

kernel 4.7.2-201 works flawless resuming from hibernation
kernel 4.7.3-200 resume worked seldom
kernel 4.7.4-200 never resumes successfully, always rebooting after discarding the resume file and booting up normally
kernel 4.7.5-200 worked for some time, the never worked again
kernel 4.7.6-200 never resumes

I keep running 4.7.2-201 as that still runs flawlessly on my fully supported Braswell laptop.

Comment 4 fedora 2016-10-17 19:57:49 UTC

kernel 4.7.7-200 shows similar symptoms to 4.7.5-200 (i.e. I was able to use it for a couple resumes until it failed for inexplicable reasons). Accordingly still sticking with 4.7.2-201.

Comment 5 Maksim Orlov 2016-10-27 15:42:30 UTC

It looks like that vanilla kernel 4.8.4 works fine with Debian 8.

Can confirm that vanilla kernel 4.7.2 works flawless.

Debian kernel images 4.7.5 / 4.7.8 show same symptoms as kernel 4.7.5-200.

Comment 6 fedora 2016-11-01 23:21:09 UTC

Thanks for the comparison. Now that it's in Fedora as well I can confirm 4.8.4-200 appears to work fine here too.