Bug 117071

Summary:	Kernel doesn't resume from hibernation - Lenovo Y50-70
Product:	Power Management	Reporter:	Paulo Castro (pauloedgarcastro)
Component:	Hibernation/Suspend	Assignee:	Rafael J. Wysocki (rjw)
Status:	CLOSED UNREPRODUCIBLE
Severity:	high	CC:	almametcal, lenb, rui.zhang
Priority:	P1
Hardware:	Intel
OS:	Linux
See Also:	https://bugzilla.kernel.org/show_bug.cgi?id=112761
Kernel Version:	4.4.7	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	acpi dump file lspci

Description Paulo Castro 2016-04-24 15:13:29 UTC

Created attachment 213861 [details]
acpi dump file

Kernel doesn't resume from hibernation hanging at the same point as in here https://bugzilla.kernel.org/attachment.cgi?id=204121&action=edit
If given the boot param nomodeset it will resume fine.

Booting with nomodeset will produce a continuous output of messages into syslog

Apr 24 15:47:21 localhost kernel: DMAR: DRHD: handling fault status reg 3
Apr 24 15:47:21 localhost kernel: DMAR: DMAR:[DMA Read] Request device [00:02.0] fault addr 46f373a000

Currently using Fedora (4.4.7-300.fc23.x86_64) 23 (Twenty Three), custom kernel config  seems to suffer from the same problem.

Comment 1 Paulo Castro 2016-04-24 15:13:59 UTC

Created attachment 213871 [details]
lspci

Comment 2 Paulo Castro 2016-04-24 15:15:16 UTC

Hardware:

System Information
        Manufacturer: LENOVO
        Product Name: 20378
        Version: Lenovo Y50-70
        Wake-up Type: Power Switch
        SKU Number: LENOVO_MT_20378_BU_idea_FM_Lenovo Y50-70
        Family: IDEAPAD

Comment 3 Zhang Rui 2016-04-26 03:02:00 UTC

can you please verify if this is a regression just like bug #112761?
say check if 3.18 kernel works for you but 3.19 kernel does not.

Comment 4 Paulo Castro 2016-04-28 12:13:48 UTC

3.18 works and so as 3.19 my custom versions at least. 
Even 4.6.0-rc5 works. 
All these work at least for the first hibernation cycle. I've been having trouble resuming at the second attempt.
I fixed a broken kdmrc and that somehow magically made it work again I think...
Closing ticket.

Comment 5 Len Brown 2016-05-02 23:43:53 UTC

please re-open if this turns out to be a upstream kernel bug.

Comment 6 Richard Davis 2017-08-12 07:22:03 UTC


My immediate impression from your listing of DMAR errors was that this was a typical Marvell controller issue, from an Intel based system with a Marvell SATA controller, and the usual advice is to add iommu=pt to the append line in the syslinux.conf file (often fixes it).  And that may be the right advice after all, because of similar symptoms.  But you don't have any Marvell chipsets.

 

You also don't show a PCI device at exactly 04:00.0, but you do have an old Promise card at 04:01.0, which is so close it's probably *on* the same card.  A little strange but I suspect the Promise card had an issue.  Try the advice above.  This didn't happen in your first syslog, and may not have happened here for quite awhile, so may be a sporadic issue.

 

This diagnostics was odd, in that there was not a full syslog, and folders.txt shows that there wasn't one in /var/log either.  The included 'syslog.txt' file is just a chopped tail of the whole, not from a syslog rotation either (no starting rsyslog line).  Did you possibly delete the original syslog from /var/log?

JurassicJunkie was broadcasting himself playing the pants-shitting horror game Outlast 2 on http://playhorrorgames.com as his young daughter waddled into the room