Summary
Hibernate (suspend-to-disk) writes and reads back the image correctly, but the final low-level restore step crashes with a kernel BUG: Bad page state while freeing a page at the boundary of a driver-registered “nosave” memory region. The system falls back to a cold boot instead of resuming. Reproduces identically on two different kernel builds, isolating the cause to the NVIDIA nvidia-open driver/GSP firmware rather than the kernel.
System
- Distro: CachyOS
- Motherboard: Gigabyte Z390 AORUS ULTRA, BIOS F9
- GPU: NVIDIA GeForce RTX 2070 SUPER (TU104, Turing)
- Driver: nvidia-open 610.43.03 (GSP firmware: gsp_tu10x.bin), kernel module tainted (O)
- Kernels tested: 7.1.3-2-cachyos (custom) and 6.18.38-2-cachyos-lts — both fail identically
- RAM: 15GB; dedicated swap partition: 20GB (larger than RAM, as required)
- resume=UUID=… correctly set on kernel cmdline, matches swap partition UUID
- Secure Boot: disabled. No disk encryption involved.
Configuration confirmed correct before filing
- mkinitcpio resume hook present and initramfs rebuilt after config change
- NVreg_PreserveVideoMemoryAllocations=1 set via modprobe.d and confirmed active (/proc/driver/nvidia/params)
- nvidia-suspend.service, nvidia-hibernate.service, nvidia-resume.service, nvidia-suspend-then-hibernate.service all enabled
- logind’s own CanHibernate check reports “yes”
Steps to reproduce
- systemctl hibernate
- Machine powers off, then powers back on (BIOS POST, not a live resume)
- Kernel finds and reads the hibernation image successfully (100%, correct byte count, correct checksum-equivalent signature match)
- Immediately after “Image successfully loaded,” resume fails
Kernel log at failure (both kernels, same PFN each time)
PM: Image loading progress: 100%
PM: Image loading done
PM: hibernation: Read 5270924 kbytes in 2.57 seconds (2050.94 MB/s)
PM: Image successfully loaded
PM: hibernation: Failed to load image, recovering.
BUG: Bad page state in process systemd-hiberna pfn:398d9
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x398d9
flags: 0xfffffc0002000(reserved|node=0|zone=1|lastcpupid=0x1fffff)
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
Modules linked in: hid_logitech_dj nvidia_drm(O) nvidia_uvm(O) nvidia_modeset(O) nvme nvme_core … nvidia(O) mxm_wmi drm_ttm_helper ttm video wmi aead
Call Trace:
bad_page+0xfa/0x110
__free_frozen_pages…+0x1b7/0x6bd
swsusp_free+0x402/0x490
load_image_and_restore+0xb3/0xf0
software_resume+0x10d/0x2e0
resume_store+0x18c/0x260
…
PM: hibernation: resume failed (-5)
Analysis
Every boot (including the write-side boot), the kernel registers an identical “nosave” memory region:
PM: hibernation: Registered nosave memory: [mem 0x39883000-0x398d9fff]
The crashing PFN (0x398d9) is the exact last page of this region. The region sits inside ordinary System RAM per the BIOS e820 map (not an MMIO/PCI BAR), consistent with memory reserved by the NVIDIA GSP firmware co-processor rather than by ACPI/firmware itself. swsusp_free() appears to attempt to free this page as if it were part of the hibernation-image’s own allocation, triggering the “Bad page state” defensive check.
Since this reproduces identically across two independent kernel builds (differing by ~5 major versions apart) with the only common factor being the nvidia-open 610.43.03 module and its GSP firmware reservation, the kernel PM/hibernate core itself is probably not the origin of the bug — but it’s also arguably a kernel-side robustness gap, since a driver mismanaging a nosave region shouldn’t be able to trigger a BUG() splat rather than a graceful error.
Not yet tested: the closed-source (non–open) driver, because for this driver branch (610.x) no closed-source kernel module is offered anymore — the last branch with one is 580.173.02, which would require a full driver downgrade to test. Noting this for anyone trying to narrow it down further.