Description of problem: Since upgrading to 4.10.9-200.fc25.x86_64 I get in consist hibernate. The computer does not always resume correctly. Version-Release number of selected component (if applicable): 4.10.9-200.fc25.x86_64 How reproducible: hibernate and then resume Steps to Reproduce: 1.Hibernate 2.resume 3. Actual results: The computer boots normally instead of resuming from hibernation Expected results: resuming from hibernation Additional info: journalctl says the following: apr 16 12:29:16 elif kernel: PM: Hibernation image partition 8:5 present apr 16 12:29:16 elif kernel: PM: Looking for hibernation image. apr 16 12:29:16 elif kernel: PM: Image signature found, resuming apr 16 12:29:16 elif kernel: PM: Preparing processes for restore. apr 16 12:29:16 elif kernel: Freezing user space processes ... (elapsed 0.000 seconds) done. apr 16 12:29:16 elif kernel: PM: Loading hibernation image. apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0x00000000-0x00000fff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0x000a0000-0x000fffff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0x20000000-0x201fffff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0x40000000-0x401fffff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0xc70ae000-0xc70aefff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0xc70be000-0xc70befff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0xcaa25000-0xcaa68fff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0xcad53000-0xcaffefff] apr 16 12:29:16 elif kernel: PM: Marking nosave pages: [mem 0xcb000000-0xffffffff] apr 16 12:29:16 elif kernel: PM: Basic memory bitmaps created apr 16 12:29:16 elif kernel: PM: Using 3 thread(s) for decompression. PM: Loading and decompressing image data (340822 pages)... apr 16 12:29:16 elif kernel: Hibernate inconsistent memory map detected! apr 16 12:29:16 elif kernel: PM: Image mismatch: architecture specific data apr 16 12:29:16 elif kernel: PM: Read 1363288 kbytes in 0.01 seconds (136328.80 MB/s) apr 16 12:29:16 elif kernel: PM: Error -1 resuming apr 16 12:29:16 elif kernel: PM: Failed to load hibernation image, recovering. apr 16 12:29:16 elif kernel: PM: Basic memory bitmaps freed apr 16 12:29:16 elif kernel: Restarting tasks ... done. apr 16 12:29:16 elif kernel: PM: Hibernation image not present or could not be loaded.
I'm seeing the same behavior reliably on the current rawhide-nodebug kernel as well if that's a useful datapoint: <snip> [root@surface2] # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.11.0-0.rc8.git2.2.fc27.x86_64 root=/dev/mapper/fedora_surface2-root ro rd.lvm.lv=fedora_surface2/root rd.luks.uuid=luks-831dcbfe-57c1-4020-8040-f44874368f15 rd.lvm.lv=fedora_surface2/swap rhgb quiet LANG=en_US.UTF-8 resume=/dev/mapper/fedora_surface2-swap <snip> Apr 29 12:09:45 surface2 systemd[1]: Found device /dev/mapper/fedora_surface2-root. Apr 29 12:09:45 surface2 systemd[1]: Reached target Initrd Root Device. Apr 29 12:09:45 surface2 systemd[1]: Found device /dev/mapper/fedora_surface2-swap. Apr 29 12:09:45 surface2 systemd[1]: Starting Resume from hibernation using device /dev/mapper/fedora_surface2-swap... Apr 29 12:09:45 surface2 kernel: PM: Starting manual resume from disk Apr 29 12:09:45 surface2 kernel: PM: Hibernation image partition 253:2 present Apr 29 12:09:45 surface2 kernel: PM: Looking for hibernation image. Apr 29 12:09:45 surface2 kernel: PM: Image signature found, resuming Apr 29 12:09:45 surface2 kernel: PM: Preparing processes for restore. Apr 29 12:09:45 surface2 kernel: Freezing user space processes ... (elapsed 0.001 seconds) done. Apr 29 12:09:45 surface2 kernel: PM: Loading hibernation image. Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0x00000000-0x00000fff] Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0x00058000-0x00058fff] Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0x0009e000-0x000fffff] Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0xa5ba7000-0xa5ba7fff] Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0xa5bb7000-0xa5bb7fff] Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0xaa379000-0xabffefff] Apr 29 12:09:45 surface2 kernel: PM: Marking nosave pages: [mem 0xac000000-0xffffffff] Apr 29 12:09:45 surface2 kernel: PM: Basic memory bitmaps created Apr 29 12:09:45 surface2 kernel: PM: Using 3 thread(s) for decompression. PM: Loading and decompressing image data (795066 pages)... Apr 29 12:09:45 surface2 kernel: Hibernate inconsistent memory map detected! Apr 29 12:09:45 surface2 kernel: PM: Image mismatch: architecture specific data Apr 29 12:09:45 surface2 kernel: PM: Read 3180264 kbytes in 0.01 seconds (318026.40 MB/s) Apr 29 12:09:45 surface2 kernel: PM: Error -1 resuming Apr 29 12:09:45 surface2 kernel: PM: Failed to load hibernation image, recovering. Apr 29 12:09:45 surface2 kernel: PM: Basic memory bitmaps freed Apr 29 12:09:45 surface2 systemd-hibernate-resume[675]: Could not resume from '/dev/mapper/fedora_surface2-swap' (253:2). Apr 29 12:09:45 surface2 kernel: Restarting tasks ... done. Apr 29 12:09:45 surface2 kernel: PM: Hibernation image not present or could not be loaded. </snip>
This bug still happens on 4.10.13-200.fc25.x86_64 Hibernation and resume does not work consistently, see the journalctl output: PM: Loading and decompressing image data (356161 pages)... mei 08 20:52:12 elif kernel: Hibernate inconsistent memory map detected! mei 08 20:52:12 elif kernel: PM: Image mismatch: architecture specific data mei 08 20:52:12 elif kernel: PM: Read 1424644 kbytes in 0.01 seconds (142464.40 MB/s) mei 08 20:52:12 elif kernel: PM: Error -1 resuming mei 08 20:52:12 elif kernel: PM: Failed to load hibernation image, recovering. mei 08 20:52:12 elif kernel: PM: Basic memory bitmaps freed mei 08 20:52:12 elif kernel: Restarting tasks ... done. mei 08 20:52:12 elif kernel: PM: Hibernation image not present or could not be loaded.
I've reproduced this with 4.11.2-1 (Arch Linux)
The problem still occurs on 4.11.5-200.fc25.x86_64. Hibernation does not work reliably anymore.
The problem seems to be related to the following commit: commit 62a03defeabd58f74e07ca030d6c21e069d4d88e Author: Chen Yu <yu.c.chen> Date: Thu Oct 20 16:14:52 2016 +0800 PM / hibernate: Verify the consistent of e820 memory map by md5 digest I built my own kernel with this commit reverted and I can now successfully hibernate and resume as I was able to do prior to 4.10. I have noticed that all of the reported occurrences of this problem, including mine, have involved LUKS encrypted filesystems so I wonder if this consistency check does not work properly when encrypted filesystems have to be mounted by the initramfs.
Reverting the patch seems to be dangerous according to commit logs. https://github.com/torvalds/linux/commit/62a03defeabd58f74e07ca030d6c21e069d4d88e Quoting Lee Chen-Yu: > Note: > 1. Without this patch applied, it is possible that BIOS has > provided an inconsistent memory map, but the resume kernel is still > able to restore the image anyway(e.g, E820_RAM region is the superset > of the previous one), although the system might be unstable. So this > patch tries to treat any inconsistent e820 as illegal. So, it will boot but there's a very strong chance that it will panic randomly while running. We need to investigate the root cause. And I highly suspect that it might be either related to ACPI or plug-and-play devices.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I'm also running into such a bug: Apr 23 11:58:21 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-cryptsetup@luks\x2df27aad08\x2d0fc7\x2d402c\x2dbb4a\x2d754e92bd55c5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Apr 23 11:58:21 localhost kernel: kauditd_printk_skb: 16 callbacks suppressed Apr 23 11:58:21 localhost kernel: audit: type=1130 audit(1619171901.827:27): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-cryptsetup@luks\x2df27aad08\x2d0fc7\x2d402c\x2dbb4a\x2d754e92bd55c5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Apr 23 11:58:21 localhost systemd[1]: Finished Cryptography Setup for luks-f27aad08-0fc7-402c-bb4a-754e92bd55c5. ░░ Subject: A start job for unit systemd-cryptsetup@luks\x2df27aad08\x2d0fc7\x2d402c\x2dbb4a\x2d754e92bd55c5.service has finished successfully ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit systemd-cryptsetup@luks\x2df27aad08\x2d0fc7\x2d402c\x2dbb4a\x2d754e92bd55c5.service has finished successfully. ░░ ░░ The job identifier is 27. Apr 23 11:58:22 localhost kernel: PM: Image signature found, resuming Apr 23 11:58:22 localhost kernel: PM: hibernation: resume from hibernation Apr 23 11:58:22 localhost kernel: Freezing user space processes ... (elapsed 0.001 seconds) done. Apr 23 11:58:22 localhost kernel: OOM killer disabled. Apr 23 11:58:22 localhost kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x00058000-0x00058fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x861b9000-0x861b9fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x861c7000-0x861c8fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x861e8000-0x861e8fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x86bf0000-0x86bf1fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x88e5d000-0x8909dfff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x8ce41000-0x8ce41fff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x8ea5d000-0x8ed9ffff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x8ef13000-0x8fbfdfff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Marking nosave pages: [mem 0x8fbff000-0xffffffff] Apr 23 11:58:22 localhost kernel: PM: hibernation: Basic memory bitmaps created Apr 23 11:58:22 localhost kernel: PM: Using 3 thread(s) for decompression Apr 23 11:58:22 localhost kernel: PM: Loading and decompressing image data (1616388 pages)... Apr 23 11:58:22 localhost kernel: Hibernate inconsistent memory map detected! Apr 23 11:58:22 localhost kernel: fbcon: Taking over console Apr 23 11:58:22 localhost kernel: PM: hibernation: Image mismatch: architecture specific data Apr 23 11:58:22 localhost kernel: PM: hibernation: Read 6465552 kbytes in 0.01 seconds (646555.20 MB/s) Apr 23 11:58:22 localhost kernel: Console: switching to colour frame buffer device 128x48 Apr 23 11:58:22 localhost kernel: PM: Error -1 resuming Apr 23 11:58:22 localhost kernel: PM: hibernation: Failed to load image, recovering. Apr 23 11:58:22 localhost kernel: PM: hibernation: Basic memory bitmaps freed Apr 23 11:58:22 localhost kernel: OOM killer enabled. Apr 23 11:58:22 localhost kernel: Restarting tasks ... done. Apr 23 11:58:22 localhost kernel: PM: hibernation: resume failed (-1)
NAME=Fedora VERSION="33 (Workstation Edition)" ID=fedora VERSION_ID=33 VERSION_CODENAME="" PLATFORM_ID="platform:f33" PRETTY_NAME="Fedora 33 (Workstation Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:33" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=33 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=33 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation Linux localhost 5.11.14-200.fc33.x86_64 #1 SMP Wed Apr 14 15:25:53 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Using LUKS. Yesterday hibernation was successful, today it wasn't.
2022-07-31T09:50:58.687799+02:00 host2 kernel: Linux version 5.18.13-200.fc36.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1), GNU ld version 2.37-27.fc36) #1 SMP PREEMPT_DYNAMIC Fri Jul 22 14:03:36 UTC 2022 ... Aug 6 08:25:34 host2 systemd-sleep[1706581]: Entering sleep state 'hibernate'... Aug 6 08:25:34 host2 kernel: PM: hibernation: hibernation entry Aug 6 13:16:50 host2 kernel: Linux version 5.18.13-200.fc36.x86_64 (mockbuild.fedoraproject.org) (gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1), GNU ld version 2.37-27.fc36) #1 SMP PREEMPT_DYNAMIC Fri Jul 22 14:03:36 UTC 2022 ... Aug 6 13:16:58 host2 kernel: PM: hibernation: resume from hibernation Aug 6 13:16:58 host2 kernel: Freezing user space processes ... (elapsed 0.023 seconds) done. Aug 6 13:16:58 host2 kernel: OOM killer disabled. Aug 6 13:16:58 host2 kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. Aug 6 13:16:58 host2 kernel: PM: Using 3 thread(s) for decompression Aug 6 13:16:58 host2 kernel: PM: Loading and decompressing image data (1290055 pages)... Aug 6 13:16:58 host2 kernel: Hibernate inconsistent memory map detected! Aug 6 13:16:58 host2 kernel: PM: hibernation: Image mismatch: architecture specific data Aug 6 13:16:58 host2 kernel: PM: hibernation: Read 5160220 kbytes in 0.01 seconds (516022.00 MB/s) Aug 6 13:16:58 host2 kernel: PM: hibernation: Failed to load image, recovering. Aug 6 13:16:58 host2 kernel: OOM killer enabled. Aug 6 13:16:58 host2 kernel: Restarting tasks ... done. Aug 6 13:16:58 host2 kernel: PM: hibernation: resume failed (-1)
Manufacturer: LENOVO Product Name: 20TD002MCK Version: ThinkPad E15 Gen 2 BIOS Information Vendor: LENOVO Version: R1EET43W(1.43 ) Release Date: 09/02/2021
It is because BIOS provided memory map really differs from boot to boot, expecting whether it did boot with a docking station or not (not verified): BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved XBIOS-e820: [mem 0x0000000000100000- ] usable -BIOS-e820: [mem 0x0000000000100000-0x0000000000ffffff] usable -BIOS-e820: [mem 0x0000000001000000-0x0000000004be6fff] reserved -BIOS-e820: [mem 0x0000000004be7000-0x000000004fda2fff] usable -BIOS-e820: [mem 0x000000004fda3000-0x00000000522fdfff] reserved -BIOS-e820: [mem 0x00000000522fe000-0x000000006da7dfff] usable XBIOS-e820: [mem -0x000000006da7dfff] usable +BIOS-e820: [mem 0x0000000000100000-0x000000006da7dfff] usable BIOS-e820: [mem 0x000000006da7e000-0x0000000072f3bfff] reserved BIOS-e820: [mem 0x0000000072f3c000-0x0000000073b32fff] ACPI NVS BIOS-e820: [mem 0x0000000073b33000-0x0000000073bfefff] ACPI data (X lines added by me) Maybe to provide a list of machine overrides of their e820 memory maps. But the whole flipping area is 1.3GiB, that is too big to lose: (0x00000000522fe000-0x1000000)/1024.0/1024.0/1024.0 = 1.2685470581054688
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.