Hibernation failing due to insufficient memory

infraviolet · 2026-06-01 20:24:59

I've been recently running into an issue on my laptop where hibernation will fail with the error "PM: hibernation: Not enough free memory". This system, in its same configuration, used to consistently hibernate after 24 hours in sleep like it was supposed to, but recently has started throwing these errors. I'm not aware of any significant increase in the memory usage of my system, and I have plenty of free swap space (64 gigabytes, for 32 gigabytes of RAM, 4 of which are dedicated to the integrated GPU).

It's pretty consistent, but I have had occasional success hibernating. I have noticed that it tends to be more likely to succeed if I initiate the hibernation myself (e.g. by running systemctl hibernate), but that can still fail too, even on a fresh boot with very little RAM used. Has anyone else noticed an increase in failures like this? Is there something obvious I'm missing? Does anyone know how I can get it hibernating again?

For completeness' sake, here's the kernel logs from a failed hibernation attempt:

PM: hibernation: hibernation entry
Filesystems sync: 0.039 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.002 seconds)
OOM killer disabled.
PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
PM: hibernation: Marking nosave pages: [mem 0x0009f000-0x000fffff]
PM: hibernation: Marking nosave pages: [mem 0x09b00000-0x09dfffff]
PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f3bfff]
PM: hibernation: Marking nosave pages: [mem 0x49b50000-0x4bd4ffff]
PM: hibernation: Marking nosave pages: [mem 0x4bd69000-0x4bd6cfff]
PM: hibernation: Marking nosave pages: [mem 0x4bd6f000-0x4bd6ffff]
PM: hibernation: Marking nosave pages: [mem 0x52e13000-0x52e61fff]
PM: hibernation: Marking nosave pages: [mem 0x54857000-0x54857fff]
PM: hibernation: Marking nosave pages: [mem 0x57f7f000-0x5affefff]
PM: hibernation: Marking nosave pages: [mem 0x5b000000-0xffffffff]
PM: hibernation: Basic memory bitmaps created
PM: hibernation: Preallocating image memory
PM: hibernation: Allocated 2044280 pages for snapshot
PM: hibernation: Allocated 8177120 kbytes in 42.02 seconds (194.60 MB/s)
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.002 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
queueing ieee80211 work while going to suspend
ACPI: EC: interrupt blocked
ACPI: PM: Preparing to enter system sleep state S4
ACPI: EC: event blocked
ACPI: EC: EC stopped
ACPI: PM: Saving platform NVS memory
Disabling non-boot CPUs ...
smpboot: CPU 15 is now offline
smpboot: CPU 14 is now offline
smpboot: CPU 13 is now offline
smpboot: CPU 12 is now offline
smpboot: CPU 11 is now offline
smpboot: CPU 10 is now offline
smpboot: CPU 9 is now offline
smpboot: CPU 8 is now offline
smpboot: CPU 7 is now offline
smpboot: CPU 6 is now offline
smpboot: CPU 5 is now offline
smpboot: CPU 4 is now offline
smpboot: CPU 3 is now offline
smpboot: CPU 2 is now offline
smpboot: CPU 1 is now offline
Spectre V2 : Update user space SMT mitigation: STIBP off
PM: hibernation: Creating image:
PM: hibernation: Need to copy 4317283 pages
PM: hibernation: Normal pages needed: 4317283 + 1024, available pages: 2971550
PM: hibernation: Not enough free memory
PM: hibernation: Error -12 creating image

Thank you!

seth · 2026-06-01 21:05:48

PM: hibernation: Normal pages needed: 4317283 + 1024, available pages: 2971550

You need ~17.27 GB but only have 11.88 GB free swap - what's the output of "cat /proc/meminfo" before failing to hibernate?
Do you manually specify the resume target?

Interestingly enough though

PM: hibernation: Allocated 2044280 pages for snapshot

So you're adding ~9GB to that - VRAM preservation?

In doubt please post your complete system journal for the boot:

sudo journalctl -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

infraviolet · Yesterday 15:06:30

Sorry, I've actually been having some trouble replicating it lately until today, and then when I went to check my logs I realized I had forgotten to actually enable the service I wrote to dump /proc/meminfo into the journal prior to hibernating. I can say with certainty, however, that I had far more than 11.88 GB of free swap. I'm also not manually specifying the resume target, but resume has not been a problem; when hibernation is successful, I am able to resume as well. Here's what my meminfo looks like right now, at least:

MemTotal:       28528972 kB
MemFree:        19802624 kB
MemAvailable:   21846300 kB
Buffers:              36 kB
Cached:          2932628 kB
SwapCached:      1644788 kB
Active:          3988728 kB
Inactive:        1866916 kB
Active(anon):    2622540 kB
Inactive(anon):   765816 kB
Active(file):    1366188 kB
Inactive(file):  1101100 kB
Unevictable:        2736 kB
Mlocked:            2724 kB
SwapTotal:      67108860 kB
SwapFree:       60635324 kB
Zswap:           1012676 kB
Zswapped:        3133584 kB
Dirty:              2316 kB
Writeback:             0 kB
AnonPages:       2620836 kB
Mapped:          1332704 kB
Shmem:            545600 kB
KReclaimable:     193864 kB
Slab:             632432 kB
SReclaimable:     193864 kB
SUnreclaim:       438568 kB
KernelStack:       31644 kB
PageTables:        90216 kB
SecPageTables:      4460 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    81373344 kB
Committed_AS:   24746284 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      322392 kB
VmallocChunk:          0 kB
Percpu:            18304 kB
HardwareCorrupted:     0 kB
AnonHugePages:     43008 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
Unaccepted:            0 kB
Balloon:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:    11984124 kB
DirectMap2M:    17176576 kB
DirectMap1G:     1048576 kB

After reducing the timeout to 1 hour to try and get this, the system has so far this week:

crashed on hibernation entry once
successfully automatically hibernated twice
successfully manually hibernated twice
failed to hibernate once

The crash happened first, and I haven't rebooted since then, so it's successfully hibernated four times and failed once this boot.

Edit: The kernel logs look interesting as well this time, with the image size seemingly more than doubling from the preallocation size. I'm not sure what exactly is going on here. I'm running the 6.18.33-1-lts kernel if that helps.

Other potentially relevant info might be, the swap space is a logical volume inside a LUKS2 crypt. My kernel command-line is "root=/dev/disk/by-label/SYS_ROOT rootflags=subvol=@arch-root rw quiet splash". I freeze execution on some programs when my screen locks, which prevents them from running their sleep hooks, but that just causes the delay inhibitor to time out, so I would be surprised if that was the issue.

Thanks again!

Last edited by infraviolet (Yesterday 15:17:30)

seth · Yesterday 15:23:37

I suspect zswap could blow in your face.
If this is too infrequent I'd suggest to setup a simple https://wiki.archlinux.org/title/Power_ … stem-sleep that just dumps meminfo into a persistent location to be able to check it after the fact.

Did you check about

seth wrote:

So you're adding ~9GB to that - VRAM preservation?

The VRAM of a dedicated GPU will be copied to RAM when entering any kind of sleep (and then has also to be written into the hibernation image)

I'm also not manually specifying the resume target

What if you do and where does systemd decide to write the hibernation image?

infraviolet · Yesterday 15:32:00

seth wrote:

I suspect zswap could blow in your face.

I could definitely look into disabling it if you think it would help, though I'm still pretty surprised it could cause such a large discrepancy.

seth wrote:

If this is too infrequent I'd suggest to setup a simple https://wiki.archlinux.org/title/Power_ … stem-sleep that just dumps meminfo into a persistent location to be able to check it after the fact.

Yeah, I wrote a systemd service on Monday, I just forgot to enable it. It's been enabled now, so I should get it next time it fails.

seth wrote:

Did you check about
seth wrote:
So you're adding ~9GB to that - VRAM preservation?
The VRAM of a dedicated GPU will be copied to RAM when entering any kind of sleep (and then has also to be written into the hibernation image)

I don't have a dedicated GPU on this system at all, just the iGPU with 4 GB of system RAM allocated to it.

seth wrote:

I'm also not manually specifying the resume target
What if you do and where does systemd decide to write the hibernation image?

I only have the one swap device (at /dev/mapper/system-swap), so that's the only place it should be able to write the hibernation image. I've thought about splitting my swap into a dedicated hibernation device and a separate paging device, but given how little of it I'm actually using at any given time I don't know how useful it would be. I can certainly try manually setting resume= though.

Arch Linux

#1 2026-06-01 20:24:59

Hibernation failing due to insufficient memory

#2 2026-06-01 21:05:48

Re: Hibernation failing due to insufficient memory

#3 Yesterday 15:06:30

Re: Hibernation failing due to insufficient memory

#4 Yesterday 15:23:37

Re: Hibernation failing due to insufficient memory

#5 Yesterday 15:32:00

Re: Hibernation failing due to insufficient memory

Board footer