[PATCH 0/1] x86/power: only verify usable RAM regions during hibernation E820 check

[PATCH 0/1] x86/power: only verify usable RAM regions during hibernation E820 check

[Marco Scardovi]

This patch addresses a hibernation resume regression on some UEFI platforms (such
as the HP OmniBook X Flip) where resume from hibernation fails with the error:
"Hibernate inconsistent memory map detected!"

The issue is triggered because the UEFI firmware or bootloader (like GRUB) makes
non-deterministic allocations or shifts ACPI/reserved memory regions across boots.
This changes the CRC32 checksum computed over the entire E820 table, even if the
usable system RAM layout remains completely identical and safe to restore.

We fix this by restricting the E820 map CRC32 calculation to only include entries
of type E820_TYPE_RAM. This maintains the check for system RAM safety while
preventing false-positive mismatches due to dynamic shifts in reserved and ACPI ranges.

Marco Scardovi (1):
  x86/power: only verify usable RAM regions during hibernation E820
    check

 arch/x86/power/hibernate.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

-- 
2.54.0

[PATCH 1/1] x86/power: only verify usable RAM regions during hibernation E820 check

[Marco Scardovi]

On some UEFI platforms (such as the HP OmniBook X Flip), resuming from
hibernation fails with 'Hibernate inconsistent memory map detected!'
even though the usable system RAM configuration is identical.

This happens because the UEFI firmware or bootloader (like GRUB) makes
non-deterministic allocations or shifts reserved/ACPI memory regions
dynamically across boots, which changes the CRC32 checksum computed
over the entire E820 table (which includes non-RAM types like reserved,
ACPI, NVS, and unusable memory).

Fix this by modifying compute_e820_crc32() to only calculate the
checksum over memory map entries of type E820_TYPE_RAM. Usable system
RAM layout is still verified to ensure data safety, but dynamic shifts
in ACPI and other reserved ranges are ignored.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221569
Fixes: f5d1499ae209 ("PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820 integrity check")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 arch/x86/power/hibernate.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
index a2294c1649f6..752a490bc3d2 100644
--- a/arch/x86/power/hibernate.c
+++ b/arch/x86/power/hibernate.c
@@ -70,12 +70,19 @@ struct restore_data_record {
  *
  * Return: the resulting checksum
  */
-static inline u32 compute_e820_crc32(struct e820_table *table)
+static u32 compute_e820_crc32(struct e820_table *table)
 {
-	int size = offsetof(struct e820_table, entries) +
-		sizeof(struct e820_entry) * table->nr_entries;
+	u32 crc = ~0;
+	int i;
+
+	for (i = 0; i < table->nr_entries; i++) {
+		if (table->entries[i].type == E820_TYPE_RAM) {
+			crc = crc32_le(crc, (unsigned char const *)&table->entries[i],
+				       sizeof(struct e820_entry));
+		}
+	}
 
-	return ~crc32_le(~0, (unsigned char const *)table, size);
+	return ~crc;
 }
 
 #ifdef CONFIG_X86_64
-- 
2.54.0

Re: [PATCH 1/1] x86/power: only verify usable RAM regions during hibernation E820 check

[Milan Oravec]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

Hallo, thank you very much! This patch resolves this issue on my HP 
OmniBook X Flip - hibernation is working again.

Best regards,

Milan Oravec

CIKT UKF Nitra
Mobil/Signal: +421907670270
email: moravec@ukf.sk

--------------------------------------------------------------------

Tuto spravu nepreveril ziadny antivirus - nebolo treba...

On 6/20/26 10:15, Marco Scardovi wrote:
> On some UEFI platforms (such as the HP OmniBook X Flip), resuming from
> hibernation fails with 'Hibernate inconsistent memory map detected!'
> even though the usable system RAM configuration is identical.
>
> This happens because the UEFI firmware or bootloader (like GRUB) makes
> non-deterministic allocations or shifts reserved/ACPI memory regions
> dynamically across boots, which changes the CRC32 checksum computed
> over the entire E820 table (which includes non-RAM types like reserved,
> ACPI, NVS, and unusable memory).
>
> Fix this by modifying compute_e820_crc32() to only calculate the
> checksum over memory map entries of type E820_TYPE_RAM. Usable system
> RAM layout is still verified to ensure data safety, but dynamic shifts
> in ACPI and other reserved ranges are ignored.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221569
> Fixes: f5d1499ae209 ("PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820 integrity check")
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Marco Scardovi <scardracs@disroot.org>
> ---
>   arch/x86/power/hibernate.c | 15 +++++++++++----
>   1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> index a2294c1649f6..752a490bc3d2 100644
> --- a/arch/x86/power/hibernate.c
> +++ b/arch/x86/power/hibernate.c
> @@ -70,12 +70,19 @@ struct restore_data_record {
>    *
>    * Return: the resulting checksum
>    */
> -static inline u32 compute_e820_crc32(struct e820_table *table)
> +static u32 compute_e820_crc32(struct e820_table *table)
>   {
> -	int size = offsetof(struct e820_table, entries) +
> -		sizeof(struct e820_entry) * table->nr_entries;
> +	u32 crc = ~0;
> +	int i;
> +
> +	for (i = 0; i < table->nr_entries; i++) {
> +		if (table->entries[i].type == E820_TYPE_RAM) {
> +			crc = crc32_le(crc, (unsigned char const *)&table->entries[i],
> +				       sizeof(struct e820_entry));
> +		}
> +	}
>   
> -	return ~crc32_le(~0, (unsigned char const *)table, size);
> +	return ~crc;
>   }
>   
>   #ifdef CONFIG_X86_64

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4983 bytes --]

Re: [PATCH 1/1] x86/power: only verify usable RAM regions during hibernation E820 check

[Rafael J. Wysocki]

On Sat, Jun 20, 2026 at 10:16 AM Marco Scardovi <scardracs@disroot.org> wrote:
>
> On some UEFI platforms (such as the HP OmniBook X Flip), resuming from
> hibernation fails with 'Hibernate inconsistent memory map detected!'
> even though the usable system RAM configuration is identical.

That may not be sufficient for the image kernel to work after resuming though.

> This happens because the UEFI firmware or bootloader (like GRUB) makes
> non-deterministic allocations or shifts reserved/ACPI memory regions
> dynamically across boots,

The boot loader has nothing to do with this, the memory map comes from
the UEFI firmware.

> which changes the CRC32 checksum computed
> over the entire E820 table (which includes non-RAM types like reserved,
> ACPI, NVS, and unusable memory).
>
> Fix this by modifying compute_e820_crc32() to only calculate the
> checksum over memory map entries of type E820_TYPE_RAM. Usable system
> RAM layout is still verified to ensure data safety, but dynamic shifts
> in ACPI and other reserved ranges are ignored.

Which is risky because the image kernel may access stuff located in
those non-RAM memory regions (for instance, ACPI tables, AML operation
regions, UEFI runtime variables, etc.).

Hibernation in Linux simply cannot cope with a changing memory map in
general, sorry about that.

> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221569
> Fixes: f5d1499ae209 ("PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820 integrity check")
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Marco Scardovi <scardracs@disroot.org>
> ---
>  arch/x86/power/hibernate.c | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
> index a2294c1649f6..752a490bc3d2 100644
> --- a/arch/x86/power/hibernate.c
> +++ b/arch/x86/power/hibernate.c
> @@ -70,12 +70,19 @@ struct restore_data_record {
>   *
>   * Return: the resulting checksum
>   */
> -static inline u32 compute_e820_crc32(struct e820_table *table)
> +static u32 compute_e820_crc32(struct e820_table *table)
>  {
> -       int size = offsetof(struct e820_table, entries) +
> -               sizeof(struct e820_entry) * table->nr_entries;
> +       u32 crc = ~0;
> +       int i;
> +
> +       for (i = 0; i < table->nr_entries; i++) {
> +               if (table->entries[i].type == E820_TYPE_RAM) {
> +                       crc = crc32_le(crc, (unsigned char const *)&table->entries[i],
> +                                      sizeof(struct e820_entry));
> +               }
> +       }
>
> -       return ~crc32_le(~0, (unsigned char const *)table, size);
> +       return ~crc;
>  }
>
>  #ifdef CONFIG_X86_64
> --
> 2.54.0
>
>

Re: [PATCH 1/1] x86/power: only verify usable RAM regions during hibernation E820 check

[Milan Oravec]

[-- Attachment #1: Type: text/plain, Size: 3293 bytes --]

Hello Rafael. OK, what is proper solution for the Hibernate inconsistent 
memory map detected! problem?

Thank you,

best regards,

Milan Oravec

CIKT UKF Nitra
Mobil/Signal: +421907670270
email: moravec@ukf.sk

--------------------------------------------------------------------

Tuto spravu nepreveril ziadny antivirus - nebolo treba...

On 6/23/26 14:59, Rafael J. Wysocki wrote:
> On Sat, Jun 20, 2026 at 10:16 AM Marco Scardovi <scardracs@disroot.org> wrote:
>> On some UEFI platforms (such as the HP OmniBook X Flip), resuming from
>> hibernation fails with 'Hibernate inconsistent memory map detected!'
>> even though the usable system RAM configuration is identical.
> That may not be sufficient for the image kernel to work after resuming though.
>
>> This happens because the UEFI firmware or bootloader (like GRUB) makes
>> non-deterministic allocations or shifts reserved/ACPI memory regions
>> dynamically across boots,
> The boot loader has nothing to do with this, the memory map comes from
> the UEFI firmware.
>
>> which changes the CRC32 checksum computed
>> over the entire E820 table (which includes non-RAM types like reserved,
>> ACPI, NVS, and unusable memory).
>>
>> Fix this by modifying compute_e820_crc32() to only calculate the
>> checksum over memory map entries of type E820_TYPE_RAM. Usable system
>> RAM layout is still verified to ensure data safety, but dynamic shifts
>> in ACPI and other reserved ranges are ignored.
> Which is risky because the image kernel may access stuff located in
> those non-RAM memory regions (for instance, ACPI tables, AML operation
> regions, UEFI runtime variables, etc.).
>
> Hibernation in Linux simply cannot cope with a changing memory map in
> general, sorry about that.
>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221569
>> Fixes: f5d1499ae209 ("PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820 integrity check")
>> Assisted-by: Antigravity:gemini-3.5-flash
>> Signed-off-by: Marco Scardovi <scardracs@disroot.org>
>> ---
>>   arch/x86/power/hibernate.c | 15 +++++++++++----
>>   1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
>> index a2294c1649f6..752a490bc3d2 100644
>> --- a/arch/x86/power/hibernate.c
>> +++ b/arch/x86/power/hibernate.c
>> @@ -70,12 +70,19 @@ struct restore_data_record {
>>    *
>>    * Return: the resulting checksum
>>    */
>> -static inline u32 compute_e820_crc32(struct e820_table *table)
>> +static u32 compute_e820_crc32(struct e820_table *table)
>>   {
>> -       int size = offsetof(struct e820_table, entries) +
>> -               sizeof(struct e820_entry) * table->nr_entries;
>> +       u32 crc = ~0;
>> +       int i;
>> +
>> +       for (i = 0; i < table->nr_entries; i++) {
>> +               if (table->entries[i].type == E820_TYPE_RAM) {
>> +                       crc = crc32_le(crc, (unsigned char const *)&table->entries[i],
>> +                                      sizeof(struct e820_entry));
>> +               }
>> +       }
>>
>> -       return ~crc32_le(~0, (unsigned char const *)table, size);
>> +       return ~crc;
>>   }
>>
>>   #ifdef CONFIG_X86_64
>> --
>> 2.54.0
>>
>>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4983 bytes --]

[PATCH v2 0/4] PM: hibernate: Add relaxed_memmap option for x86 E820 integrity check

[Marco Scardovi]

Hi Rafael, Milan,

> ...
>
> Hibernation in Linux simply cannot cope with a changing memory map in
> general, sorry about that.

You are totally agree. While mine is still a solution for these like @Milan
with a buggy firmware, it's not a solution to make it unconditional for every
device so I came with a solution to introduce the boot flag
hybernate=relaxed_memmap. This is still a bit hacky and I don't like it at
all at the end of the day but works better than nothing, at least until HP
releases a proper firmware with it fixed.

This v2 of the patch address hibernation E820 map integrity check failures
on UEFI platforms where firmware dynamically shifts reserved or ACPI memory
ranges across boots (such as the HP OmniBook X Flip).

In v1, I attempted to restrict the integrity check to only E820_TYPE_RAM
ranges by default. As pointed out by Rafael, this is risky because the
resumed kernel could attempt to access shifted ACPI tables or UEFI runtime
services at stale addresses, leading to post-resume crashes or corruption.

To address this feedback while still allowing hibernation to function on
affected platforms, v2 introduces the 'hibernate=relaxed_memmap' command-line
parameter.

- Patch 1: Declare the 'hibernate_relaxed_memmap' flag in the PM core header.
- Patch 2: Define the flag and add parsing logic to kernel/power/hibernate.c.
- Patch 3: Implement the relaxed E820 memory map check on x86, which compares
           a secondary RAM-only checksum if the main checksum mismatches,
           warning the user but proceeding with resume.
- Patch 4: Document the option in Documentation/admin-guide/kernel-parameters.txt.

1. By default, the E820 checksum verification remains strict to ensure
   safety for all systems.
2. If 'hibernate=relaxed_memmap' is specified, the kernel will perform
   a secondary check on only the usable RAM regions (E820_TYPE_RAM) if the
   main E820 checksum mismatches.
   - If the RAM regions differ, the resume is aborted (to prevent direct map
     mismatches and kernel paging faults during page restoration).
   - If the RAM regions match, the resume is allowed to proceed and a warning
     is logged about the non-RAM changes.

To support this, a secondary 'e820_ram_checksum' field is added to the
x86-specific 'restore_data_record', and 'RESTORE_MAGIC' is incremented to
signal the header layout change.

Marco Scardovi (4):
  PM: hibernate: Declare hibernate_relaxed_memmap
  PM: hibernate: Define and parse hibernate=relaxed_memmap parameter
  x86/power: Implement relaxed E820 memory map integrity check
  Documentation: Document hibernate=relaxed_memmap parameter option

 .../admin-guide/kernel-parameters.txt         |  5 +++
 arch/x86/power/hibernate.c                    | 40 +++++++++++++++++--
 include/linux/suspend.h                       |  1 +
 kernel/power/hibernate.c                      |  3 ++
 4 files changed, 45 insertions(+), 4 deletions(-)

-- 
2.54.0

[PATCH v2 1/4] PM: hibernate: Declare hibernate_relaxed_memmap

[Marco Scardovi]

Declare the 'hibernate_relaxed_memmap' global variable in
include/linux/suspend.h, which will be used to relax the E820 memory map
integrity check.

Assisted-by: Antigravity:gemini-3.5-flash

Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 include/linux/suspend.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index b02876f1ae38..92eb3eb23422 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -393,6 +393,7 @@ extern void hibernation_set_ops(const struct platform_hibernation_ops *ops);
 extern int hibernate(void);
 extern bool system_entering_hibernation(void);
 extern bool hibernation_available(void);
+extern bool hibernate_relaxed_memmap;
 asmlinkage int swsusp_save(void);
 extern struct pbe *restore_pblist;
 int pfn_is_nosave(unsigned long pfn);
-- 
2.54.0

[PATCH v2 2/4] PM: hibernate: Define and parse hibernate=relaxed_memmap parameter

[Marco Scardovi]

Define the 'hibernate_relaxed_memmap' global variable and parse the
'relaxed_memmap' option under the 'hibernate=' kernel boot parameter.
This enables users to relax E820 memory map integrity checks during resume.

Assisted-by: Antigravity:gemini-3.5-flash

Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 kernel/power/hibernate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index d2479c69d71a..62ce708f37bd 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -41,6 +41,7 @@
 static int nocompress;
 static int noresume;
 static int nohibernate;
+bool hibernate_relaxed_memmap;
 static int resume_wait;
 static unsigned int resume_delay;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
@@ -1430,6 +1431,8 @@ static int __init hibernate_setup(char *str)
 	} else if (!strncmp(str, "no", 2)) {
 		noresume = 1;
 		nohibernate = 1;
+	} else if (!strncmp(str, "relaxed_memmap", 14)) {
+		hibernate_relaxed_memmap = true;
 	} else if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)
 		   && !strncmp(str, "protect_image", 13)) {
 		enable_restore_image_protection();
-- 
2.54.0

[PATCH v2 3/4] x86/power: Implement relaxed E820 memory map integrity check

[Marco Scardovi]

On some UEFI platforms (such as the HP OmniBook X Flip), resuming from
hibernation fails with 'Hibernate inconsistent memory map detected!' because
the UEFI firmware makes non-deterministic allocations or shifts reserved/ACPI
memory regions dynamically across boots. This changes the CRC32 checksum
computed over the entire E820 table, even though the usable RAM layout
remains completely identical and safe to restore.

However, bypassing the E820 integrity check entirely is risky, as the
restored kernel might access shifted ACPI tables, AML operation regions,
or UEFI runtime services at stale physical addresses, leading to post-resume
crashes or corruption.

Implement a relaxed verification path if 'hibernate=relaxed_memmap' is set.
If the full E820 table checksum mismatches, perform a secondary check
comparing only the usable RAM regions. If the RAM regions differ, the resume
is aborted to prevent direct map mismatches and paging faults. If the RAM
regions match, the resume is allowed to proceed with a warning.

To support this, add a secondary 'e820_ram_checksum' field to the
x86 'restore_data_record', and increment 'RESTORE_MAGIC' to signal the
header layout change.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 arch/x86/power/hibernate.c | 40 ++++++++++++++++++++++++++++++++++----
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/x86/power/hibernate.c b/arch/x86/power/hibernate.c
index a2294c1649f6..88452769d1aa 100644
--- a/arch/x86/power/hibernate.c
+++ b/arch/x86/power/hibernate.c
@@ -61,6 +61,7 @@ struct restore_data_record {
 	unsigned long cr3;
 	unsigned long magic;
 	unsigned long e820_checksum;
+	unsigned long e820_ram_checksum;
 };
 
 /**
@@ -78,10 +79,32 @@ static inline u32 compute_e820_crc32(struct e820_table *table)
 	return ~crc32_le(~0, (unsigned char const *)table, size);
 }
 
+/**
+ * compute_e820_ram_crc32 - calculate crc32 of usable RAM regions in e820 table
+ *
+ * @table: the e820 table to be calculated
+ *
+ * Return: the resulting checksum
+ */
+static u32 compute_e820_ram_crc32(struct e820_table *table)
+{
+	u32 crc = ~0;
+	int i;
+
+	for (i = 0; i < table->nr_entries; i++) {
+		if (table->entries[i].type == E820_TYPE_RAM) {
+			crc = crc32_le(crc, (unsigned char const *)&table->entries[i],
+				       sizeof(struct e820_entry));
+		}
+	}
+
+	return ~crc;
+}
+
 #ifdef CONFIG_X86_64
-#define RESTORE_MAGIC	0x23456789ABCDEF02UL
+#define RESTORE_MAGIC	0x23456789ABCDEF03UL
 #else
-#define RESTORE_MAGIC	0x12345679UL
+#define RESTORE_MAGIC	0x1234567AUL
 #endif
 
 /**
@@ -122,6 +145,7 @@ int arch_hibernation_header_save(void *addr, unsigned int max_size)
 	rdr->cr3 = restore_cr3 & ~CR3_PCID_MASK;
 
 	rdr->e820_checksum = compute_e820_crc32(e820_table_firmware);
+	rdr->e820_ram_checksum = compute_e820_ram_crc32(e820_table_firmware);
 	return 0;
 }
 
@@ -144,8 +168,16 @@ int arch_hibernation_header_restore(void *addr)
 	restore_cr3 = rdr->cr3;
 
 	if (rdr->e820_checksum != compute_e820_crc32(e820_table_firmware)) {
-		pr_crit("Hibernate inconsistent memory map detected!\n");
-		return -ENODEV;
+		if (hibernate_relaxed_memmap) {
+			if (rdr->e820_ram_checksum != compute_e820_ram_crc32(e820_table_firmware)) {
+				pr_crit("Hibernate inconsistent RAM map detected!\n");
+				return -ENODEV;
+			}
+			pr_warn("Hibernate inconsistent non-RAM memory map ignored due to relaxed_memmap!\n");
+		} else {
+			pr_crit("Hibernate inconsistent memory map detected!\n");
+			return -ENODEV;
+		}
 	}
 
 	return 0;
-- 
2.54.0

[PATCH v2 4/4] Documentation: Document hibernate=relaxed_memmap parameter option

[Marco Scardovi]

Document the new 'relaxed_memmap' option under the 'hibernate=' kernel
boot parameters.

Assisted-by: Antigravity:gemini-3.5-flash

Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 Documentation/admin-guide/kernel-parameters.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22..107935c585e4 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1967,6 +1967,11 @@ Kernel parameters
 		protect_image	Turn on image protection during restoration
 				(that will set all pages holding image data
 				during restoration read-only).
+		relaxed_memmap	[x86] Relax E820 memory map integrity check.
+				Instead of aborting resume on any mismatch,
+				only verify that the usable RAM layout remains
+				identical, and warning-only for shifts/changes
+				in reserved or ACPI ranges.
 
 	hibernate.compressor= 	[HIBERNATION] Compression algorithm to be
 				used with hibernation.
-- 
2.54.0

Re: [PATCH v2 0/4] PM: hibernate: Add relaxed_memmap option for x86 E820 integrity check

[Milan Oravec]

[-- Attachment #1: Type: text/plain, Size: 4214 bytes --]

Hello, I wanted to try this new set of patches, but I was unable to 
apply them. Tested with 7.1.2 and master too.

migo@migo-HP:~/build/linux-test/linux$ patch -p1 < ../hibernate2.patch
patching file include/linux/suspend.h
patching file kernel/power/hibernate.c
Hunk #2 FAILED at 1431.
1 out of 2 hunks FAILED -- saving rejects to file 
kernel/power/hibernate.c.rej
patching file arch/x86/power/hibernate.c
Hunk #1 FAILED at 61.
Hunk #2 succeeded at 78 with fuzz 1.
Hunk #3 FAILED at 144.
Hunk #4 FAILED at 166.
3 out of 4 hunks FAILED -- saving rejects to file 
arch/x86/power/hibernate.c.rej
patching file Documentation/admin-guide/kernel-parameters.txt
Hunk #1 FAILED at 1967.
1 out of 1 hunk FAILED -- saving rejects to file 
Documentation/admin-guide/kernel-parameters.txt.rej

Thank you,

Milan

s pozdravom

Milan Oravec

CIKT UKF Nitra
Mobil/Signal: +421907670270
email: moravec@ukf.sk

--------------------------------------------------------------------

Tuto spravu nepreveril ziadny antivirus - nebolo treba...

On 6/23/26 18:47, Marco Scardovi wrote:
> Hi Rafael, Milan,
>
>> ...
>>
>> Hibernation in Linux simply cannot cope with a changing memory map in
>> general, sorry about that.
> You are totally agree. While mine is still a solution for these like @Milan
> with a buggy firmware, it's not a solution to make it unconditional for every
> device so I came with a solution to introduce the boot flag
> hybernate=relaxed_memmap. This is still a bit hacky and I don't like it at
> all at the end of the day but works better than nothing, at least until HP
> releases a proper firmware with it fixed.
>
> This v2 of the patch address hibernation E820 map integrity check failures
> on UEFI platforms where firmware dynamically shifts reserved or ACPI memory
> ranges across boots (such as the HP OmniBook X Flip).
>
> In v1, I attempted to restrict the integrity check to only E820_TYPE_RAM
> ranges by default. As pointed out by Rafael, this is risky because the
> resumed kernel could attempt to access shifted ACPI tables or UEFI runtime
> services at stale addresses, leading to post-resume crashes or corruption.
>
> To address this feedback while still allowing hibernation to function on
> affected platforms, v2 introduces the 'hibernate=relaxed_memmap' command-line
> parameter.
>
> - Patch 1: Declare the 'hibernate_relaxed_memmap' flag in the PM core header.
> - Patch 2: Define the flag and add parsing logic to kernel/power/hibernate.c.
> - Patch 3: Implement the relaxed E820 memory map check on x86, which compares
>             a secondary RAM-only checksum if the main checksum mismatches,
>             warning the user but proceeding with resume.
> - Patch 4: Document the option in Documentation/admin-guide/kernel-parameters.txt.
>
> 1. By default, the E820 checksum verification remains strict to ensure
>     safety for all systems.
> 2. If 'hibernate=relaxed_memmap' is specified, the kernel will perform
>     a secondary check on only the usable RAM regions (E820_TYPE_RAM) if the
>     main E820 checksum mismatches.
>     - If the RAM regions differ, the resume is aborted (to prevent direct map
>       mismatches and kernel paging faults during page restoration).
>     - If the RAM regions match, the resume is allowed to proceed and a warning
>       is logged about the non-RAM changes.
>
> To support this, a secondary 'e820_ram_checksum' field is added to the
> x86-specific 'restore_data_record', and 'RESTORE_MAGIC' is incremented to
> signal the header layout change.
>
> Marco Scardovi (4):
>    PM: hibernate: Declare hibernate_relaxed_memmap
>    PM: hibernate: Define and parse hibernate=relaxed_memmap parameter
>    x86/power: Implement relaxed E820 memory map integrity check
>    Documentation: Document hibernate=relaxed_memmap parameter option
>
>   .../admin-guide/kernel-parameters.txt         |  5 +++
>   arch/x86/power/hibernate.c                    | 40 +++++++++++++++++--
>   include/linux/suspend.h                       |  1 +
>   kernel/power/hibernate.c                      |  3 ++
>   4 files changed, 45 insertions(+), 4 deletions(-)
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4983 bytes --]

Re: [PATCH v2 0/4] PM: hibernate: Add relaxed_memmap option for x86 E820 integrity check

[Marco Scardovi]

In data lunedì 29 giugno 2026 15:04:04 Ora legale dell’Europa centrale, Milan Oravec ha scritto:
> Hello, I wanted to try this new set of patches, but I was unable to 
> apply them. Tested with 7.1.2 and master too.
> 
> migo@migo-HP:~/build/linux-test/linux$ patch -p1 < ../hibernate2.patch
> patching file include/linux/suspend.h
> patching file kernel/power/hibernate.c
> Hunk #2 FAILED at 1431.
> 1 out of 2 hunks FAILED -- saving rejects to file 
> kernel/power/hibernate.c.rej
> patching file arch/x86/power/hibernate.c
> Hunk #1 FAILED at 61.
> Hunk #2 succeeded at 78 with fuzz 1.
> Hunk #3 FAILED at 144.
> Hunk #4 FAILED at 166.
> 3 out of 4 hunks FAILED -- saving rejects to file 
> arch/x86/power/hibernate.c.rej
> patching file Documentation/admin-guide/kernel-parameters.txt
> Hunk #1 FAILED at 1967.
> 1 out of 1 hunk FAILED -- saving rejects to file 
> Documentation/admin-guide/kernel-parameters.txt.rej
> 
> Thank you,
> 
> Milan
> 
Hi Milan,
that's probably because all the patches I write are against linux-next and
not a specific linux version. In that case linux-next contain [1] which
is not on stable version, making the patch non working for you.

To be honest I'm not gonna release a new patch specifically for kernel 7.1:
it's a waste of effort to target a specific version as the patch will be merged
(if rafael will agree with it) in a future version. Said that, I'm not even
sure it will be merged for the points stated by Rafael, which I understand
and agree.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/kernel/power/hibernate.c?h=next-20260629&id=783c8109844503bd1c35dab41b6d5fd074a9f131

With best regards,
Marco

Re: [PATCH v2 0/4] PM: hibernate: Add relaxed_memmap option for x86 E820 integrity check

[Milan Oravec]

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

Hello Marco, thank you for your effort and help. Unfortunately no 
solution for my system. :(

Best regards,

Milan

s pozdravom

Milan Oravec

CIKT UKF Nitra
Mobil/Signal: +421907670270
email: moravec@ukf.sk

--------------------------------------------------------------------

Tuto spravu nepreveril ziadny antivirus - nebolo treba...

On 6/29/26 21:53, Marco Scardovi wrote:
> In data lunedì 29 giugno 2026 15:04:04 Ora legale dell’Europa centrale, Milan Oravec ha scritto:
>> Hello, I wanted to try this new set of patches, but I was unable to
>> apply them. Tested with 7.1.2 and master too.
>>
>> migo@migo-HP:~/build/linux-test/linux$ patch -p1 < ../hibernate2.patch
>> patching file include/linux/suspend.h
>> patching file kernel/power/hibernate.c
>> Hunk #2 FAILED at 1431.
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> kernel/power/hibernate.c.rej
>> patching file arch/x86/power/hibernate.c
>> Hunk #1 FAILED at 61.
>> Hunk #2 succeeded at 78 with fuzz 1.
>> Hunk #3 FAILED at 144.
>> Hunk #4 FAILED at 166.
>> 3 out of 4 hunks FAILED -- saving rejects to file
>> arch/x86/power/hibernate.c.rej
>> patching file Documentation/admin-guide/kernel-parameters.txt
>> Hunk #1 FAILED at 1967.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> Documentation/admin-guide/kernel-parameters.txt.rej
>>
>> Thank you,
>>
>> Milan
>>
> Hi Milan,
> that's probably because all the patches I write are against linux-next and
> not a specific linux version. In that case linux-next contain [1] which
> is not on stable version, making the patch non working for you.
>
> To be honest I'm not gonna release a new patch specifically for kernel 7.1:
> it's a waste of effort to target a specific version as the patch will be merged
> (if rafael will agree with it) in a future version. Said that, I'm not even
> sure it will be merged for the points stated by Rafael, which I understand
> and agree.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/kernel/power/hibernate.c?h=next-20260629&id=783c8109844503bd1c35dab41b6d5fd074a9f131
>
> With best regards,
> Marco
>
>

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4983 bytes --]