hibernate stopped working: dmesg: inconsistent memory map detected!

jorgenwiki · 2025-01-23 15:00:20

I infrequently use my swap partition for hibernating. I use sleep then hibernate. The swap partition is not often used for other purposes and most of the time the laptop re wakes from sleep.

Last week I discovered that after sleeping my laptop didn't hibernate and booted with the error: "inconsistent memory map detected!".
So my memory was written to swap, but couldn't get read!

I tried to solve this:
1. I checked all the settings and nothing has changed.
2. It could be some (kernel)update. But I did not find any bugs about this.
3. I physically checked the nvme swap partition with badblock: no errors.

At step 3 I made the error to use badblock with -w instead of -n so I had to re-partition my swap partition and that fixed the problem (by accident).

My question is still: nothing happened, No HW-fault detected (and the disk is new, modern and not to much used) and I am not aware of any changes.
So what made that I could not correctly read the hibernated memory from swap?

Any Ideas or tips to prevent this for the future?

Thanks.

seth · 2025-01-23 16:32:13

Spitballing:
* https://wiki.archlinux.org/title/Solid_state_drive#TRIM
* https://wiki.archlinux.org/title/Power_ … Management (but unlikely w/ an nvme)
=> more likely https://wiki.archlinux.org/title/Solid_ … leshooting

Is there another parallel OS or did you somehow boot arch "skipping" the hibernation?
Is the swap partition potentially underdimensioned for your RAM?

jorgenwiki · 2025-01-23 17:09:01

No, I don't have a parallel OS

I did not skip hibernation. On the contrary I could see (several times) that when I tried hibernating that when booting again the system tried to resume, then it gave the error "inconsistent memory map detected!" and then something like a resume error exit -1 and continuing with a normal boot.
The only thing that I changed to get it working again was reformating the swap file.
Can the SWAP partition get corrupted without HD failure? Like I said the HD is quit new, not very much used for swapping and I tested it with badblocks -w. And than I had to reformat it with mkswap.

My ram is 32 GB and my swap partition is 40 GB (so ram could fit twice or so if sufficient compressed).

dimich · 2025-01-23 19:09:13

jorgenwiki wrote:

I tested it with badblocks -w

badblock is not much useful for modern hardware with it's transparent remapping. Use nvme command with subcommands error-log, device-self-test, self-test-log.

jorgenwiki · 2025-01-23 20:34:46

Thanks, I tested it, no erros (see below the output of one entry).
So still I think it is not a HW fault.

I did however have a problem that the xcfe4-display couldn't handle switching multiple displays (bug I think) made my user account crash with flickering screens, but I don´t think that should have somehow hurt a swap partition. And I think it didn't work before that. Only my xfce4 settings were messed op on user level.

Should I do something with smartctl? I did one short run (also no errors), but I think it does not run periodically or something like that. Should it?

Check with nvme:

nvme error-log /dev/nvme1n1p2 device-self-test self-test-log

Output (1 of 64 equal reports):

Error Log Entries for device:nvme1n1p2 entries:64
.................
 Entry[ 0]
.................
error_count	: 0
sqid		: 0
cmdid		: 0
status_field	: 0 (Successful Completion: The command completed without error)
phase_tag	: 0
parm_err_loc	: 0
lba		: 0
nsid		: 0
vs		: 0
trtype		: 0 (The transport type is not indicated or the error is not transport related)
csi		: 0
opcode		: 0
cs		: 0
trtype_spec_info: 0
log_page_version: 0

Last edited by jorgenwiki (2025-01-24 14:34:59)

seth · 2025-01-24 10:15:25

Please use [code][/code] tags

If this isn't a one-off, I'd look into the APST situation, esp. because of

I use sleep then hibernate.

ReDress · 2025-01-24 13:42:16

It seems to me like the easiest or probably the most straight forward way would be track down this error in the code.

This would probably give the immediate cause of the issue.

jorgenwiki · 2025-01-24 14:30:46

seth wrote:

If this isn't a one-off, I'd look into the APST situation, esp. because of
I use sleep then hibernate.

The sleep then hibernate worked fine for about a year (hibernating regular, but not to often though).
Should I consider to switch off some APST modes? At least if this is not one of a kind issue?

I tried to check what is in use with APST:

nvme id-ctrl /dev/nvme1n1

I think these are the states that are reported:

s      0 : mp:5.24W operational enlat:0 exlat:0 rrt:0 rrl:0
            rwt:0 rwl:0 idle_power:- active_power:-
            active_power_workload:-
ps      1 : mp:4.49W operational enlat:0 exlat:0 rrt:1 rrl:1
            rwt:1 rwl:1 idle_power:- active_power:-
            active_power_workload:-
ps      2 : mp:2.19W operational enlat:0 exlat:500 rrt:2 rrl:2
            rwt:2 rwl:2 idle_power:- active_power:-
            active_power_workload:-
ps      3 : mp:0.0500W non-operational enlat:210 exlat:1200 rrt:3 rrl:3
            rwt:3 rwl:3 idle_power:- active_power:-
            active_power_workload:-
ps      4 : mp:0.0050W non-operational enlat:1000 exlat:9000 rrt:4 rrl:4
            rwt:4 rwl:4 idle_power:- active_power:-
            active_power_workload:-

Further:

ReDress wrote:

It seems to me like the easiest or probably the most straight forward way would be track down this error in the code.
This would probably give the immediate cause of the issue.

I think this is about the unstable xfce4-display issue. I am able to reproduce the behavior, I would be glad to track something down, if I knew how. I need some work around for it anyway.
However this subject is for this problem a sidetrack I think and it might be in the wrong place.

ReDress · 2025-01-24 14:45:23

jorgenwiki wrote:

ReDress wrote:
It seems to me like the easiest or probably the most straight forward way would be track down this error in the code.
This would probably give the immediate cause of the issue.
I think this is about the unstable xfce4-display issue. I am able to reproduce the behavior, I would be glad to track something down, if I knew how. I need some work around for it anyway.
However this subject is for this problem a sidetrack I think and it might be in the wrong place.

It seems obvious to me that Linux is having trouble recovering from the image that was presumably saved at hibernation.

That is, while being grossly unfamiliar with the topic being a desktop user.

seth · 2025-01-24 15:41:07

Should I consider to switch off some APST modes? At least if this is not one of a kind issue?

Yes, it's a somewhat common problem and the conditions fit your problem (sleep, wake, nvme fails, hibernation image storage fails, hibernation is borked)
It's just a guess, though. You no longer have the journal of the boot that failed to hibernate?

__pedro_andrade · 2025-02-22 19:43:19

Hello

I found a way to "bypass" this trouble. Always i want to hibernate my system i execute this one:

sudo swapoff -a
sudo swapon -a
sudo systemctl hibernate

i believe doing this the memory map will be reseted, and the correct memory map will be remembered by the kernel in the next system inicialization.

i execute this with a .sh file, and now "sudo sh z.sh" is my new turn-off button.

hope that help you or anybody

seth · 2025-02-22 20:03:51

This suggests you're short on swap space and need to clear it to get enough free space for the hibernation image?

__pedro_andrade · 2025-02-22 21:11:19

Probably not. i think the same, but i recriated the swap with 2,5x my RAM (16gb) = 40gb and the behavior remained. Moreover, the system logs tell me that the swap memory barely exceeded 50% usage. Obviously, i reduce the partition to the original 17,5gb that is more than enought for my system

__pedro_andrade · 2025-03-13 19:55:41

Hello guys, im back. Finally i got to resole definitely this problem. In general terms, i go to the BIOS and set ACPI config to 'auto' and coment all lines of the /etc/systemd/sleep.conf

I understood that problem is a incompatibility with ACPI BIOS settings and system power management configurations. So i tried to let de BIOS set the best configuration of ACPI by accepting the system requests, doing the procedure above.

Is more than two weeks that my system can hibernate and wake up perfectly.

Note: x11 has problem to return from hibernation (the graphical environment cannot understand that it should be initialized when the system wakes up. This can be worked around with a script that runs right after waking up and just restarts x11. It works, although it is not a definitive fix), i currently use wayland/kwin, that works

Hope that can help anybody else, hugs

seth · 2025-03-13 20:19:51

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

For KWin/X11 you might want to test whether it's just the compositor (and not X11) - Shift+Alt+F12 will suspend it, you can try that before or after the hibernation.

jorgenwiki · 2025-11-01 16:05:49

Since a few days again this problem is raised again. In the end the solution was running:

mkinitcpio -P linux

What I don't understand is how this could have happened. This morning I updated the kernel and I see that pacman is updating the boot image, but only my manual intervention (previous command) helped eventually. I'm trying to prevent future issues and understand this, but also looking to varies scrips did not give me any answer. Everything seems OK and worked for quit some time until now. Although sometimes resume does not work, but I think that this is my fault of not rebooting after an specific update.

Any suggestion what might be wrong? A bug in an update? A misconfiguration on my side?

seth · 2025-11-01 16:28:38

Please post your pacman log, but I strongly suspect that you will not be able to update the kernel and hibernate without rebooting after the update (because waking up from the hibernation will switch the kernel) and the mkinitcpio run is probably just coincidental?

jorgenwiki · 2025-11-01 17:21:31

@Seth: thanks for your quick response!

1. My pacman.log:

[2025-11-01T10:00:30+0100] [PACMAN] Running 'pacman -Syu'
[2025-11-01T10:00:30+0100] [PACMAN] synchronizing package lists
[2025-11-01T10:00:31+0100] [PACMAN] starting full system upgrade
[2025-11-01T10:00:39+0100] [ALPM] running '60-mkinitcpio-remove.hook'...
[2025-11-01T10:00:39+0100] [ALPM] transaction started
[2025-11-01T10:00:39+0100] [ALPM] upgraded audit (4.0.5-1 -> 4.1.2-1)
[2025-11-01T10:00:39+0100] [ALPM] upgraded libcap (2.76-1 -> 2.77-1)
[2025-11-01T10:00:39+0100] [ALPM] upgraded libelf (0.193-5 -> 0.194-1)
[2025-11-01T10:00:39+0100] [ALPM] upgraded debuginfod (0.193-5 -> 0.194-1)
[2025-11-01T10:00:39+0100] [ALPM] upgraded intel-gmmlib (22.8.1-1 -> 22.8.2-1)
[2025-11-01T10:00:40+0100] [ALPM] upgraded linux (6.17.5.arch1-1 -> 6.17.6.arch1-1)
[2025-11-01T10:00:40+0100] [ALPM] upgraded mesa (1:25.2.5-2 -> 1:25.2.6-1)
[2025-11-01T10:00:40+0100] [ALPM] upgraded postgresql-libs (17.6-2 -> 18.0-1)
[2025-11-01T10:00:40+0100] [ALPM] upgraded qt6-svg (6.10.0-1 -> 6.10.0-2)
[2025-11-01T10:00:40+0100] [ALPM] upgraded vulkan-mesa-device-select (1:25.2.5-2 -> 1:25.2.6-1)
[2025-11-01T10:00:40+0100] [ALPM] upgraded vulkan-intel (1:25.2.5-2 -> 1:25.2.6-1)
[2025-11-01T10:00:40+0100] [ALPM] transaction completed
[2025-11-01T10:00:41+0100] [ALPM] running '30-systemd-daemon-reload-system.hook'...
[2025-11-01T10:00:41+0100] [ALPM] running '30-systemd-restart-marked.hook'...
[2025-11-01T10:00:41+0100] [ALPM] running '30-systemd-tmpfiles.hook'...
[2025-11-01T10:00:41+0100] [ALPM] running '30-systemd-update.hook'...
[2025-11-01T10:00:41+0100] [ALPM] running '60-depmod.hook'...
[2025-11-01T10:00:42+0100] [ALPM] running '90-mkinitcpio-install.hook'...
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET] ==> Using default configuration file: '/etc/mkinitcpio.conf'
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux.img
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET] ==> Starting build: '6.17.6-arch1-1'
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2025-11-01T10:00:43+0100] [ALPM-SCRIPTLET]   -> Running build hook: [microcode]
[2025-11-01T10:00:43+0100] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2025-11-01T10:00:43+0100] [ALPM-SCRIPTLET]   -> Running build hook: [kms]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [consolefont]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET] ==> WARNING: consolefont: no font found in configuration
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET] ==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> Early uncompressed CPIO image generation successful
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET] ==> Initcpio image generation successful
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET] ==> Using default configuration file: '/etc/mkinitcpio.conf'
[2025-11-01T10:00:44+0100] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux-fallback.img -S autodetect
[2025-11-01T10:00:45+0100] [ALPM-SCRIPTLET] ==> Starting build: '6.17.6-arch1-1'
[2025-11-01T10:00:45+0100] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2025-11-01T10:00:45+0100] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2025-11-01T10:00:45+0100] [ALPM-SCRIPTLET]   -> Running build hook: [microcode]
[2025-11-01T10:00:45+0100] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2025-11-01T10:00:45+0100] [ALPM-SCRIPTLET]   -> Running build hook: [kms]
[2025-11-01T10:00:56+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'ast'
[2025-11-01T10:00:56+0100] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2025-11-01T10:00:56+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'xhci_pci_renesas'
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET]   -> Running build hook: [consolefont]
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: consolefont: no font found in configuration
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'aic94xx'
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'bfa'
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qed'
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qla1280'
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'qla2xxx'
[2025-11-01T10:00:58+0100] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: 'wd719x'
[2025-11-01T10:01:01+0100] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2025-11-01T10:01:02+0100] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
[2025-11-01T10:01:02+0100] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2025-11-01T10:01:04+0100] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2025-11-01T10:01:04+0100] [ALPM-SCRIPTLET] ==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux-fallback.img'
[2025-11-01T10:01:05+0100] [ALPM-SCRIPTLET]   -> Early uncompressed CPIO image generation successful
[2025-11-01T10:01:05+0100] [ALPM-SCRIPTLET] ==> Initcpio image generation successful

This update was about 10:00 this morning. I would expect that with these actions something like mkinitcpio -P linux is run by a script. It looks like that. So I expect that hibernation would continue to work after this pacman script, or that if the bootimage was somehow not uptodate would be fixed anyway.

What is wrong, is that hibernation was broken (at all) and was not fixed be this and earlier kernel updates that created a boot image etc..
What restored hibernation was only my manual intervention by executing mkinitcpio -P linux as root. I ran this around 15:00 and now multiple tries hibernating succeeded.
Still I don't understand this. What's the difference? I think the manual command and pacman script should have done the same. So I don't understand I had to do this manually.

I just would like to understand what's happening and correct any errors in my configuration that might be there.

2.

seth wrote:

but I strongly suspect that you will not be able to update the kernel and hibernate without rebooting after the update (because waking up from the hibernation will switch the kernel)

I can confirm this. What I generally do is reboot after an kerrnel update (or grub or systemd or anything other suspected), but I don't reboot after small/other updates. What I was trying to say is that in the passed year sometimes hibernate failed. I don't know why but I thought that I might have forgotten to reboot after a critical update. But I'm not sure about that. I got hibernation failures for sure, but I'm not sure about mistakes from my side ;-)

So there might be more trouble with hibernating, but I can't be sure about that.

Last edited by jorgenwiki (2025-11-01 17:27:26)

seth · 2025-11-01 20:22:31

So I expect that hibernation would continue to work after this pacman script, or that if the bootimage was somehow not uptodate would be fixed anyway.

No. As a matter of fact, pacman triggering mkinitcpio.conf is a pretty strong indicator that the next hibernation attempt will go wrong.

[2025-11-01T10:00:40+0100] [ALPM] upgraded linux (6.17.5.arch1-1 -> 6.17.6.arch1-1)

Hibernation means
* store RAM into a file
* shutdown
* boot
* load RAM out of a file

You're shutting down out of the 6.17.5.arch1-1 kernel but booting the 6.17.6.arch1-1 kernel and then load the memory (including the kernel modules!) of the previous boot - but now have the wrong kernel!
Here's the story of a bear: https://bbs.archlinux.org/viewtopic.php … 4#p1960554

The next mkinitcpio run didn't do anything - what crucially happened is that you rebooted (the failing hibernation wakeup), synchronizing the exit and entrance kernel versions.

jorgenwiki · 2025-11-02 10:44:19

Thanks for your help so far. We have a misunderstanding:

jorgenwiki wrote:

So I expect that hibernation would continue to work after this pacman script, or that if the bootimage was somehow not uptodate would be fixed anyway. So that after a reboot, hibernation would work, but it didn't!

seth wrote:

No. As a matter of fact, pacman triggering mkinitcpio.conf is a pretty strong indicator that the next hibernation attempt will go wrong.

I was incomplete in my explanation, I added the missing text in bold. In short: I understand I have to reboot after a kernel update, but how many times I rebooted did not mater (including an extra update of a new kernel after a few days). The only way I was able to restore was to run manualy:

mkinitcpio -P linux

I would have expected that the kernel/pacman scripts would take care of that (so that after the next reboot hibernation and all other things would work again), but I had to do it manually.

So my question: what's wrong with my configuration, that something like "mkintcpio -P linux" isn't run automatically?.

Last edited by jorgenwiki (2025-11-02 10:45:36)

seth · 2025-11-02 16:55:42

So my question: what's wrong with my configuration, that something like "mkintcpio -P linux" isn't run automatically?.

The premise:

[2025-11-01T10:00:42+0100] [ALPM] running '90-mkinitcpio-install.hook'...

mkinitcpio was run automatically by pacman - otherwise you could not even have rebooted properly.

jorgenwiki · 2025-11-05 06:20:15

seth wrote:

mkinitcpio was run automatically by pacman - otherwise you could not even have rebooted properly.

So we both agree that the automatic pacman script should have solved it. It should, but it didn't: only a manual mkinitcpio -P linux did the job.

So I still wonder what happened and what's the difference. Pacman starts the script:

[2025-11-01T10:00:42+0100] [ALPM] running '90-mkinitcpio-install.hook'...
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET] ==> Using default configuration file: '/etc/mkinitcpio.conf'
[2025-11-01T10:00:42+0100] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux.img

In my journal I see: Starting build: 'none', is that wrong?

journalctl --since "2025-10-31 00:00:00" --until "2025-11-01 23:59:59" | grep -E 'mkinitcpio|hook'
Oct 31 09:23:19 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Oct 31 12:01:54 jblaptop mkinitcpio[16424]: ==> Starting build: 'none'
Oct 31 12:01:54 jblaptop mkinitcpio[16424]:   -> Running build hook: [sd-shutdown]
Oct 31 12:01:54 jblaptop mkinitcpio[16424]: ==> Build complete.
Oct 31 12:01:54 jblaptop systemd[1]: mkinitcpio-generate-shutdown-ramfs.service: Deactivated successfully.
Oct 31 12:02:11 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 08:46:33 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 10:01:53 jblaptop pulseaudio[1045]: Assertion 'pa_atomic_load(&(y)->_ref) > 0' failed at ../pulseaudio/src/modules/bluetooth/bluez5-util.c:2207, function pa_bluetooth_discovery_hook(). Aborting.
Nov 01 10:01:53 jblaptop mkinitcpio[33164]: ==> Starting build: 'none'
Nov 01 10:01:53 jblaptop mkinitcpio[33164]:   -> Running build hook: [sd-shutdown]
Nov 01 10:01:53 jblaptop mkinitcpio[33164]: ==> Build complete.
Nov 01 10:01:53 jblaptop systemd[1]: mkinitcpio-generate-shutdown-ramfs.service: Deactivated successfully.
Nov 01 10:02:10 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 13:09:36 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 13:14:36 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 14:09:46 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 14:10:35 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 14:12:07 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension
Nov 01 14:58:15 jblaptop mkinitcpio[36175]: ==> Starting build: 'none'
Nov 01 14:58:15 jblaptop mkinitcpio[36175]:   -> Running build hook: [sd-shutdown]
Nov 01 14:58:15 jblaptop mkinitcpio[36175]: ==> Build complete.
Nov 01 14:58:15 jblaptop systemd[1]: mkinitcpio-generate-shutdown-ramfs.service: Deactivated successfully.
Nov 01 14:58:39 jblaptop kernel: ACPI: battery: new hook: System76 Battery Extension

Below some configuration files:

Is below the "#" before #default_config="/etc/mkinitcpio.conf" wrong, or anywhere else?
mkinitcpio.d/linux.preset

# mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_uki="/efi/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
#fallback_uki="/efi/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"

mkinitcpio.conf

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES=(usbhid xhci_hcd)
MODULES=()

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=()

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=()

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No RAID, lvm2, or encrypted root is needed.
#    HOOKS=(base)
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS=(base udev autodetect modconf block filesystems fsck)
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS=(base udev modconf block filesystems fsck)
#
##   This setup assembles a mdadm array with an encrypted root file system.
##   Note: See 'mkinitcpio -H mdadm_udev' for more information on RAID devices.
#    HOOKS=(base udev modconf keyboard keymap consolefont block mdadm_udev encrypt filesystems fsck)
#
##   This setup loads an lvm2 volume group.
#    HOOKS=(base udev modconf block lvm2 filesystems fsck)
#
##   This will create a systemd based initramfs which loads an encrypted root filesystem.
#    HOOKS=(base systemd autodetect modconf kms keyboard sd-vconsole sd-encrypt block filesystems fsck)
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr and fsck hooks.
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems resume fsck)

# COMPRESSION
# Use this to compress the initramfs image. By default, zstd compression
# is used for Linux ≥ 5.9 and gzip compression is used for Linux < 5.9.
# Use 'cat' to create an uncompressed image.
#COMPRESSION="zstd"
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
#COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=()

# MODULES_DECOMPRESS
# Decompress loadable kernel modules and their firmware during initramfs
# creation. Switch (yes/no).
# Enable to allow further decreasing image size when using high compression
# (e.g. xz -9e or zstd --long --ultra -22) at the expense of increased RAM usage
# at early boot.
# Note that any compressed files will be placed in the uncompressed early CPIO
# to avoid double compression.
#MODULES_DECOMPRESS="no"

]

seth · 2025-11-05 09:05:49

So we both agree that the automatic pacman script should have solved it.

No, because…

only a manual mkinitcpio -P linux did the job

… I still contest that premise.

Cause the situation where you cannot hibernate after multiple reboots again, then post the journals covering the hibernation and failed resume (-b and -b -1)

mmy8x · 2025-11-05 09:41:26

It kinda looks like there is either a weird bug in the kernel or your FW/BIOS/UEFI declares different memory layout after reboot. WTF.

/**
 *      arch_hibernation_header_restore - read the architecture specific data
 *              from the hibernation image header
 *      @addr: address to read the data from
 */
int arch_hibernation_header_restore(void *addr)
{
        struct restore_data_record *rdr = addr;

        if (rdr->magic != RESTORE_MAGIC) {
                pr_crit("Unrecognized hibernate image header format!\n");
                return -EINVAL;
        }

        restore_jump_address = rdr->jump_address;
        jump_address_phys = rdr->jump_address_phys;
        restore_cr3 = rdr->cr3;

        if (rdr->e820_checksum != compute_e820_crc32(e820_table_firmware)) {
                pr_crit("Hibernate inconsistent memory map detected!\n");
                return -ENODEV;
        }

        return 0;
}

 * - 'e820_table_firmware': the original firmware version passed to us by the
 *   bootloader - not modified by the kernel. It is composed of two parts:
 *   the first 128 E820 memory entries in boot_params.e820_table and the remaining
 *   (if any) entries of the SETUP_E820_EXT nodes. We use this to:
 *
 *       - inform the user about the firmware's notion of memory layout
 *         via /sys/firmware/memmap
 *
 *       - the hibernation code uses it to generate a kernel-independent CRC32
 *         checksum of the physical memory layout of a system.

jorgenwiki · 2025-11-05 18:25:36

Could it be that not the manual command 'mkinictcpio -P linux' differs from what the pacman script does but that due to a configuration error or bug once in a while this command has to be executed twice (so in my case once by pacman and once by me manually) to make hibernate work again? Maybe hibernate is only resorted if the command is issued with the new kernel in memory, or ...
Because since I have issued manual this command I've got already several kernel updates and hibernate is still working without problems since I issued the command myself. I am just looking for where the error is, because I had this before months ago. Every now and again, hibernate gets broken and is fixed if I do this.

mmy8x wrote:

It kinda looks like there is either a weird bug in the kernel or your FW/BIOS/UEFI declares different memory layout after reboot. WTF.

So can this kernel or bios bug explain why I a manual mkinitcpio -P linux fixes the problem and the pacman script did not with several kernel updates in about a week time?

Don't know if it has anything to do with it but I've a coreboot bios. That could have a bug, bit it's difficult to trace an update (have no clue where to search, laptop came with this bios). And maybe it has nothing to do with it at all.

Last edited by jorgenwiki (2025-11-05 18:28:07)

Arch Linux

#1 2025-01-23 15:00:20

hibernate stopped working: dmesg: inconsistent memory map detected!

#2 2025-01-23 16:32:13

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#3 2025-01-23 17:09:01

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#4 2025-01-23 19:09:13

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#5 2025-01-23 20:34:46

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#6 2025-01-24 10:15:25

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#7 2025-01-24 13:42:16

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#8 2025-01-24 14:30:46

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#9 2025-01-24 14:45:23

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#10 2025-01-24 15:41:07

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#11 2025-02-22 19:43:19

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#12 2025-02-22 20:03:51

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#13 2025-02-22 21:11:19

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#14 2025-03-13 19:55:41

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#15 2025-03-13 20:19:51

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#16 2025-11-01 16:05:49

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#17 2025-11-01 16:28:38

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#18 2025-11-01 17:21:31

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#19 2025-11-01 20:22:31

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#20 2025-11-02 10:44:19

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#21 2025-11-02 16:55:42

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#22 2025-11-05 06:20:15

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#23 2025-11-05 09:05:49

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#24 2025-11-05 09:41:26

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

#25 2025-11-05 18:25:36

Re: hibernate stopped working: dmesg: inconsistent memory map detected!

Board footer