Framework 13 (12th Gen Intel) BIOS 3.20: Non-deterministic e820 memory map across boots breaks hibernation resume

[jeg7]

Device Information

System Model or SKU

Please select one of the following

• Framework Laptop 12 (13th Gen Intel® Core™)
• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (AMD Ryzen™ AI 300 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)
• Framework Laptop 16 (AMD Ryzen™ AI 300 Series)
• Framework Desktop (AMD Ryzen™ AI 300 PRO Series)

BIOS VERSION

03.20

DIY Edition information

Storage: WD_BLACK SN850X 4000GB
Size: 16 GB
Manufacturer: Crucial Technology
Part Number: CT16G4SFRA32A.C16FP
Configured Memory Speed: 3200 MT/s
Volatile Size: 16 GB

Standalone Operation (Laptop Only)

Are you running your mainboard as a standalone device? Is standalone mode enabled in the BIOS?

• Yes
• No

Describe the bug

On BIOS 03.20, the firmware-supplied e820 memory map is not deterministic across boots. An 8 KiB ACPI data region located just below 0x38C00000 is placed at a different physical address on nearly every boot, with a corresponding shift in the adjacent System RAM boundaries. Region sizes stay constant; only the base addresses move.

Because the Linux kernel verifies that the e820 map is unchanged before restoring a hibernation image, this makes resume-from-hibernation fail non-deterministically. Observed across six consecutive boots: five distinct memory maps, only one matching pair.

The memory-map non-determinism is reproducible without hibernation — it is visible in dmesg on any two consecutive boots — so hibernation is the symptom, not a prerequisite for reproducing the underlying issue.

Steps To Reproduce

Reproducing the memory map non-determinism (no hibernation needed):

1. Boot the system.
2. Run: dmesg | grep 'BIOS-e820' and save the output.
3. Reboot. Repeat steps 1-2 four or five times, changing nothing between boots.
4. Diff the saved outputs.

Expected: identical output every time. Actual: the ACPI data region below
0x38C00000 and the adjacent System RAM boundaries differ between most boots.

Reproducing the hibernation consequence:

1. Configure hibernation (swap sized at or above installed memory, resume= and
   resume_offset= kernel parameters set). Secure Boot must be off on Ubuntu.
2. sudo systemctl hibernate
3. Power the system back on.
4. Roughly four times out of five, the session is not restored and
   Hibernate inconsistent memory map detected! appears in the kernel log.

Expected behavior

The firmware supplies an identical e820 memory map on every boot with an
unchanged hardware configuration. Region base addresses are stable, allowing the
kernel's hibernation image consistency check to pass.

Operating System:

• OS/Distribution: Ubuntu 24.04.4 LTS (Noble Numbat)
• Version: 24.04.4 LTS
• Linux Kernel Version: 7.0.0-30-generic (x86_64)
• Bootloader: GRUB 2 (Ubuntu default), UEFI boot, Secure Boot disabled

Actual behavior

The ACPI data region below 0x38C00000 is relocated between boots. Consecutive
boots produce different maps with no configuration change in between.

---

Evidence 1 — firmware memory map differs between consecutive boots

Two consecutive boots, same kernel (7.0.0-30-generic), no hardware change.
Only the differing rows are shown; every other e820 entry is byte-for-byte
identical between the two boots.

Boot A (hibernation was performed during this boot):

BIOS-e820: [mem 0x0000000000100000-0x0000000038b6afff]  System RAM
BIOS-e820: [mem 0x0000000038b6b000-0x0000000038b6cfff]  ACPI data
BIOS-e820: [mem 0x0000000038b6d000-0x000000003c2c8fff]  System RAM

Boot B (resume was attempted during this boot):

BIOS-e820: [mem 0x0000000000100000-0x0000000038b6dfff]  System RAM
BIOS-e820: [mem 0x0000000038b6e000-0x0000000038b6ffff]  ACPI data
BIOS-e820: [mem 0x0000000038b70000-0x000000003c2c8fff]  System RAM

The ACPI data region is 0x2000 (8 KiB) in both cases. Its base address moved
by 0x3000 (three 4 KiB pages).

---

Evidence 2 — region placement across six consecutive boots

Kernel-registered nosave regions from six consecutive boots, most recent first.
Two regions vary; the remaining six entries in the list are identical on every
boot and are omitted.

Boot	Region 1 (0x2000 / 8 KiB)	Region 2 (0x4F000 / 316 KiB)
N	0x38b6e000-0x38b6ffff	0x38b84000-0x38bd2fff
N-1	0x38b6b000-0x38b6cfff	0x38b83000-0x38bd1fff
N-2	0x38b71000-0x38b72fff	0x38b84000-0x38bd2fff
N-3	0x38ad9000-0x38adafff	0x38b79000-0x38bc7fff
N-4	0x38adf000-0x38ae0fff	0x38b84000-0x38bd2fff
N-5	0x38adf000-0x38ae0fff	0x38b84000-0x38bd2fff

Five distinct address combinations across six boots. Region sizes are constant
throughout — only the base addresses move. Observed range of movement for
Region 1 spans roughly 0x38ad9000 to 0x38b71000, about 610 KiB.

Full unfiltered nosave list from the most recent boot, for reference:

[mem 0x00000000-0x00000fff]
[mem 0x0009f000-0x000fffff]
[mem 0x38b6e000-0x38b6ffff]     <- varies
[mem 0x38b84000-0x38bd2fff]     <- varies
[mem 0x39a48000-0x39a48fff]
[mem 0x3c2c9000-0x3cbc8fff]
[mem 0x3e9df000-0x43afefff]
[mem 0x43b00000-0xffffffff]

---

Evidence 3 — resulting hibernation resume failure

Hibernation was entered cleanly on Boot A. The image was written successfully
(1,676,728 pages, approximately 6.9 GB).

On Boot B, the kernel located and began decompressing the image, then aborted:

PM: Image signature found, resuming
PM: hibernation: resume from hibernation
PM: hibernation: Basic memory bitmaps created
PM: Using 3 thread(s) for lzo decompression
PM: Loading and decompressing image data (1676728 pages)...
Hibernate inconsistent memory map detected!
PM: hibernation: Image mismatch: architecture specific data

The system then continued booting normally, discarding the session.

This check was added to the kernel deliberately (see the "PM / hibernate: Verify
the consistency of e820 memory map by md5 digest" series). The kernel passes a
digest of the e820 map from the suspending kernel to the resuming kernel and
aborts the restore when they differ, because restoring a page onto a region the
new map treats differently can panic or silently corrupt memory. The kernel is
behaving correctly here; the input it is being given is not stable.

[jeg7]

Update: the bootloader may be a co-factor, not firmware alone

Two environment details I've now added to the report above:

• Bootloader: GRUB 2 (Ubuntu 24.04 default), UEFI, Secure Boot disabled
• Storage: WD_BLACK SN850X 4000GB

Since filing, I found a Framework Community thread describing an identical
failure on the same board (Framework Laptop 13, 12th Gen, i7-1260P), reported
against BIOS 03.19:

https://community.frame.work/t/solved-hibernate-inconsistent-memory-map-on-framework-13-12th-gen-intel/81661

That report describes it as an interaction rather than a pure firmware fault:
the Insyde firmware allocates the ACPI data region dynamically on each boot,
and GRUB's non-deterministic allocations from the EFI memory pool then shift
the resulting e820 map far enough to fail the kernel's resume hash check. The
author reports the same hardware on the same BIOS hibernating and resuming
correctly under Pop!_OS and Fedora, neither of which boots via GRUB, and a
second user confirmed on 2026-08-21 that moving to systemd-boot resolved it
for them.

I have not yet tested systemd-boot on my own machine, so I can't independently
confirm that part — I'll report back once I have. Flagging it now so this
isn't evaluated purely as a firmware issue if the bootloader turns out to be a
necessary co-factor.

Correction to the original report: the "roughly four times out of five"
failure rate was an inference from the memory-map sample (one matching pair
across five consecutive boot transitions), not from repeated hibernate trials.
I have directly observed one hibernate/resume cycle, and it failed.

The underlying observation is unchanged and reproducible without hibernation:
the e820 map this machine presents to the kernel differs across most boots
with no configuration change in between.