Recommended solution for kernel suspend problem

I’ve just bought a new laptop (Dell Vostro 5515 with Ryzen7 CPU) and thought I would try Manjaro on it. It’s my first time with Manjaro. I’m running the current stable version with kernel 5.15.28, and am using systemd-swap with no physical swap partition, so have no hibernate.

So, I’ve run into the kernel problem with suspend (see eg. the thread on
Battery drain during suspend mode: on lid closure the laptop suspends, but then restarts. If left suspended overnight on battery the battery is flat in the morning; if left suspended on power overnight, in the morning the laptop is uncomfortably hot.

What I’m trying to find out is the best fix, and I’ve found no clear answer in any of the forums I’ve looked at. Which of the following is likely to be the best approach?

  1. Stop using suspend for now, as a new kernel version will be along any day now; just wait
  2. The next manjaro kernel version will be months at least, so repartition the drive to add swap and use hibernate instead of suspend (though I’m not absolutely certain that hibernate is not also affected)
  3. Move off stable and use a testing kernel (I’m not at all sure which version: As i understand it the problem will be fixed in kernel 5.18, and there may be a 5.17 version with the fix coming first, but that the bug for some bizarre reason has been back-ported to both 5.15 and 5.16.)

Any advice?

PS I tried to link to other threads, but the forum software says no links allowed. Really?

With that kind of hardware you don’t need suspend or hibernation.

Just power off when not needed.

The no links is spamming prevention - when your trustlevel changes - you can post links.

Another option is to codefence the link like



I often end up with a lot of things open at the end of a working day, and prefer not to have to restart everything and remember how it was set up to get back to where I was in order to carry on the next day, so I really don’t like having to switch off every night. I could solve some of that by scripting things, but I’m too lazy and prefer the laptop to just work for me. I do think the need for suspend or hibernation is independent of the kind of hardware.

Thanks for the hint about the links!


As you may know now I am no expert on hibernation and power management.

I understand - we all have different ways of doing things.

The best source of instructions and howto do power management is this section on Arch Wiki


I checked one of my laptops - a Thinkpad - it uses

  1. resume hook in /etc/mkinitcpio
  2. swap partition - referenced in /etc/default/grub as resume=UUID=the-uuid-for-partition

So when your laptop drain the battery - in power management app - check what action is defined for lid close.

System does not power off when hibernating

When you hibernate your system, the system should power off (after saving the state on the disk). Sometimes, you might see the power LED is still glowing. If that happens, it might be instructive to set the HibernateMode to shutdown in sleep.conf.d(5):


[Sleep] HibernateMode=shutdown

With the above configuration, if everything else is set up correctly, on invocation of a systemctl hibernate the machine will shutdown saving state to disk as it does so.
Power management/Suspend and hibernate - ArchWiki

Another thing I can think of is that a lot of hardware is built for Windows and some hardware related like hibernate and suspend only works if you set __ ACPI_OS_NAME__ - check the Troubleshooting section in above link or jump to this section DSDT - ArchWiki.

1 Like

@linux-aarhus : thank you for taking the time to write all this, but my problem is not findng out how to set up sleep/suspend/hibernate, it really is a problem with a kernel bug. See for example this (lets hope the link works this time):

Running journalctl I can see that the laptop enters suspend then comes back out of it on its own, often followed by what looks like an attempted core dump. I don’t have the knowledge or interest to work on kernel-level stuff, so I’m not trying to diagnose this any further.

In the meantime, I seem to have found a workaround: manually suspending before closing the lid instead of using lid closure itself to suspend seems to fix the problem for now.