0

I have been using this laptop for quite a while and got everything working nicely. It seems that after the update to 24.04 suspend does not work reliably. Not 100% sure, because it is now used by my wife.

I can get it to work some times, and have reported at least two times that I fixed it. Only to find out that later it does not work... Interestingly, when it starts resuming from suspend, it also seems to boot up after choosing power off (so not restart!). Nothing but the power cable is connected to the laptop while trying to suspend.

I have tried the following: Enabling S3 by going into some obscure BIOS mode...

And applied ACPI patching see: https://wiki.archlinux.org/title/Lenovo_IdeaPad_5_14are05#Suspend_issues_(S3_sleep_fix)

Disabled all the items in cat /proc/acpi/wakeup. Disabled bluetooth and even wifi. Nothing helps.

Installed a very new kernel 6.10.6, no help.

Went back to an older kernel 6.1.0-1036-oem, no help.

Sometimes it seems to work for my old user, but not for my wife's user. And then it also does not work for my user.

Any help in trying to debug this is greatly appreciated!

EDIT: The logs just seem to indicate a proper sleep, and then awake up. I also noticed it works fine the first time going to sleep, but afterwards it fails. I have tried running 24.04.1 and 22.04.5 from a usb stick and got the same result for both versions...

Other answers reviewed:

Laptop wakes up by itself a few seconds after suspend or lidclose

PC Wakes Up Immediately After Suspend

Laptop wakes up seconds after suspend

WLigtenberg
  • 573

1 Answers1

0

Diagnostic procedure:

First step is to put a pin in the timestream with

date '+%y-%m-%d %H:%M:%S' >pin.tmp

Then, do your problematic action. When your system is usable again,

sudo journalctl  --since="$(cat pin.tmp)"

This will show you all the log messages since you set pin.tmp. Some messages relate to your problem.

The messages produced by journalctl start with a timestamp, the host that issued the log entry, the process name, the PID in [] of the issuer and a colon (:). Everything after the colon is a message from the programmer, intended to help the user understand the program's behavior. Read man logger for more details.

Use sudo journalctl --list-boots to get boot #s for -b, below.

Plug the boot number in place of "#"*, and use

sudo journalctl  -b#

to see the system boot and discover its hardware, and

sudo journalctl  -b # -e

to see the system's final messages.

Of course, read man journalctl.

waltinator
  • 37,856