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.
Created attachment 213871 [details] lspci
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
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.
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.
please re-open if this turns out to be a upstream kernel bug.
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