Unreliable resume from hibernation with Asus C302 (Cave)

[PremiumUsername]

When testing with:

echo test_resume > /sys/power/disk
echo disk > /sys/power/state

...there are no problems. But in real use, resume often -- but not always -- fails with:

1.434020] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff] [ 1.434033] PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff] [ 1.434048] PM: hibernation: Marking nosave pages: [mem 0x79bda000-0x79bf7fff] [ 1.434057] PM: hibernation: Marking nosave pages: [mem 0x79c24000-0x79c24fff] [ 1.434062] PM: hibernation: Marking nosave pages: [mem 0x7a6e4000-0x7a6e8fff] [ 1.434067] PM: hibernation: Marking nosave pages: [mem 0x7a6ea000-0x7a6ecfff] [ 1.434072] PM: hibernation: Marking nosave pages: [mem 0x7a6f0000-0x7a6f2fff] [ 1.434077] PM: hibernation: Marking nosave pages: [mem 0x7a91a000-0x7aa69fff] [ 1.434112] PM: hibernation: Marking nosave pages: [mem 0x7aa6b000-0xffffffff] [ 1.441197] PM: hibernation: Basic memory bitmaps created [ 1.622070] PM: Using 3 thread(s) for decompression [ 1.622101] PM: Loading and decompressing image data (304461 pages)... [ 1.622108] Hibernate inconsistent memory map detected! [ 1.622141] PM: hibernation: Image mismatch: architecture specific data [ 1.622181] PM: hibernation: Read 1217844 kbytes in 0.01 seconds (121784.40 MB/s) [ 1.623376] PM: Error -1 resuming [ 1.623384] PM: hibernation: Failed to load image, recovering.

Using Manjaro with K 5.14, but have tried different setups, all with the same problem. Grub, systemd-boot or efi-stub makes no difference.

[MrChromebox]

hibernation (S4/suspend to disk) isn't really supported by coreboot. Not sure this is something I can do much about

[PremiumUsername]

I see. Resuming works most of the time if it's done within a couple of minutes, but more seldom after longer periods (+10 hours), so it's almost working. If I could only figure out what has gone wrong when it fails maybe I could work around it.

Could you tell me what: Image mismatch: architecture specific data means? Is it that the E820 memory map has changed?

Is the duration of the hibernation period and the success rate just in my head? Does coreboot do anything differently if the computer been off for a short time compared to if it's been off for a longer time?

[MrChromebox]

I have no idea what that means offhand, I'd have to google it same as you

[PremiumUsername]

I think I got it working but it's more of a work-around than a real solution. Using the kernel arguments: acpi_osi=Linux acpi_sleep=s4_nohwsig seems to be doing the trick.

I did make an observation that maybe could help solve this in a more permanent manner. Even before using these parameters, resume did work sometimes and these were also the times when systemd-boot could sense the s4 state and boot the alternative config that had been booted earlier (i.e. not just booting the default). But when things went astray, it just started using the default boot option. Just making sure it started the same boot option that was chosen when it was hibernated wasn't enough -- you still need the additional kernel arguments -- but it tells me that whatever data-area systemd-boot uses to see that the computer is in an s4 state was changed by something previous in the boot order. I think that's where the problem lies, for whatever it is worth.

[alexgill]

Hi, have a look at my comment and hope it helps. https://github.com/merge/skulls/issues/216