Sometimes often sleep doesn't works, how to investigate?

English Applications
1

on my laptop=asus vivobook pro N552VW-FY204T; CPU=i7-6700HQ @ 2.6GHz; GPU=intel HD Graphics; RAM=16GB; boot=dual (windows 10 and leap 15.4) with GRUB2 for EFI; Secure Boot Support=yes; Update NVRAM Entry=yes
running LEAP 15.4 with KDE standard,

often system sleep command (both running it from the application menu and from the login screen) doesn’t works,
when I click on sleep it seems to sleep but after a couple of seconds the login screen (the one that appear when I really sleep not the one that appear after the boot) appears again and if I redo sleep from the login screen it behave in the same way again.

the same but less often happen in my laptop TUXEDO InfinityBook Pro 15 v4, CPU=Intel Core i7-8565U, RAM=32Gb, GPU=Intel UHD Graphics 620 (Whiskey Lake); boot=tri boot (leap 15.4, leap 15.4, windows 10) with GRUB2 for EFI; Secure Boot Support=yes; Update NVRAM Entry=yes
running LEAP 15.4 KDE Argon (installed not LIVE) SDB:Argon and Krypton - openSUSE Wiki
with these KDE repositries
SDB:KDE repositories - openSUSE Wiki

I started a similar thread here

but may be it is better to start a new one

in that thread dcurtisfra asked two things:

Given that, “Argon” is a “live” image, it may be difficult to inspect the systemd Journal

it is not a Live image, my KDE Argon is installed normally

and

is there anything in the Journal indicating why the execution of “system sleep” is failing?

where can I look the systemd journal of the previous dates?

the last system sleep failing happened a couple of times the 2023jan03 at about 19:50-20:01,
I tried to look into systemd messages in yast>systemd Journal but it starts after I rebooted the system the 2023jan04
so I look in the yast>display the system log (/var/log/messages) here is the part from 2023jan03 at about 19:50-20:01
https://paste.opensuse.org/pastes/9ebee4a75297
How can I investigate why system sleep doesn’t works?

P.S. is it ok to post long text using susepaste or now with this new site is there a better way?

2

Assuming you have persistent journals enabled(*) then:

journalctl --list-boots

will give you a list of previous boots, to display one of those use:

journalctl -b -n

where -n is the number derived from list boots.

(*) If persistent journal is not enabled then for future use create the sub-directory /var/log/journal

3

It looks like some device wakes up the system

2023-01-03T19:55:32.569128+01:00 localhost kernel: [172077.216437][T14265] Disabling non-boot CPUs ...
2023-01-03T19:55:32.569132+01:00 localhost kernel: [172077.216438][T14265] Wakeup pending. Abort CPU freeze
2023-01-03T19:55:32.569136+01:00 localhost kernel: [172077.216438][T14265] Non-boot CPUs are not disabled
2023-01-03T19:55:32.569140+01:00 localhost kernel: [172077.216439][T14265] ACPI: EC: EC started
2023-01-03T19:55:32.569145+01:00 localhost kernel: [172077.216457][T14265] ACPI: PM: Waking up from system sleep state S3

There are some guidelines how to check and control wakeup sources here

https://wiki.archlinux.org/title/Power_management/Wakeup_triggers

Sometimes playing with acpi_osi kernel parameter (like pretending you are a Windows) may help by hinting the firmware to do things differently.

4

in my TUXEDO laptop (the one that fails system sleep less often)
happens a failure a couple of times the 2023jan05 at abouto 20:36
in this laptop I created the /var/log/journal directory so I can access at systemd journals,
I tried firstly by yast>systemd journal but it cannot be copyed, only searched and filtered,
why this strange “feature”?
so I followed tannington instructions,

journalctl -b -1 > file.txt

and I discovered tha there was less informations than in the yast>systemd journal,
so I suspected that the tannington instructions should be run as root,

pla@pla4-TW:~> su -
Password: 
pla4-TW:~ # journalctl -b -1 > systemfile.txt

and I get this:
https://paste.opensuse.org/pastes/d1e5f642eab7

firstly I found that the file is not in time sequence, it starts with:
Jan 05 19:14:42 pla4-TW kernel: m…
then comes:
Jan 05 18:14:46 pla4-TW systemd-…
and then continue in time sequence, is it a normal behaviour?

in the file I searched for sleep and found something, the most close to the problem seems this:

....
Jan 05 20:36:30 pla4-TW systemd-sleep[11443]: Failed to put system to sleep. System resumed again: Device or resource busy
Jan 05 20:36:30 pla4-TW kernel: PM: suspend exit
Jan 05 20:36:30 pla4-TW systemd-sleep[11484]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend
Jan 05 20:36:30 pla4-TW systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
Jan 05 20:36:30 pla4-TW systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
Jan 05 20:36:30 pla4-TW systemd[1]: Failed to start System Suspend.
Jan 05 20:36:30 pla4-TW systemd[1]: Dependency failed for Suspend.
Jan 05 20:36:30 pla4-TW systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
Jan 05 20:36:30 pla4-TW systemd[1]: Stopped target Sleep.
Jan 05 20:36:30 pla4-TW systemd-logind[857]: Operation 'sleep' finished.
Jan 05 20:36:30 pla4-TW systemd[1]: Stopping TUXEDO Control Center Service (sleep/resume)...
Jan 05 20:36:30 pla4-TW ModemManager[976]: <info>  [sleep-monitor] system is resuming
....

and before this seems a working sleep procedure

....
Jan 05 19:12:52 pla4-TW systemd-sleep[8491]: INFO: Skip running /usr/lib/systemd/system-sleep/grub2.sleep for suspend
Jan 05 19:12:52 pla4-TW systemd-sleep[8489]: Entering sleep state 'suspend'...
Jan 05 19:12:52 pla4-TW kernel: PM: suspend entry (deep)
Jan 05 19:12:52 pla4-TW kernel: Filesystems sync: 0.032 seconds
Jan 05 20:10:25 pla4-TW kernel: Freezing user space processes ... (elapsed 0.003 seconds) done.
Jan 05 20:10:25 pla4-TW kernel: OOM killer disabled.
Jan 05 20:10:25 pla4-TW kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Jan 05 20:10:25 pla4-TW kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Jan 05 20:10:25 pla4-TW kernel: tuxedo_keyboard: Set keyboard enabled to: 0
Jan 05 20:10:25 pla4-TW kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
Jan 05 20:10:25 pla4-TW kernel: sd 2:0:0:0: [sda] Stopping disk
Jan 05 20:10:25 pla4-TW kernel: psmouse serio2: Failed to disable mouse on isa0060/serio2
Jan 05 20:10:25 pla4-TW kernel: ACPI: EC: interrupt blocked
Jan 05 20:10:25 pla4-TW kernel: ACPI: PM: Preparing to enter system sleep state S3
Jan 05 20:10:25 pla4-TW kernel: ACPI: EC: event blocked
Jan 05 20:10:25 pla4-TW kernel: ACPI: EC: EC stopped
Jan 05 20:10:25 pla4-TW kernel: ACPI: PM: Saving platform NVS memory
....

is here some other useful infos?

I’m working on my ASUS to follow also arvidjaar suggestions here
https://wiki.archlinux.org/title/Power_management/Wakeup_triggers
I will post on this
manythanks

5

Extract from the journal at the time sequence change:

Jan 05 19:14:45 pla4-TW systemd-journald[218]: Journal stopped
Jan 05 18:14:46 pla4-TW systemd-journald[218]: Received SIGTERM from PID 1 (systemd).
Jan 05 18:14:46 pla4-TW systemd[1]: RTC configured in localtime, applying delta of 60 minutes to system time.
Jan 05 18:14:46 pla4-TW systemd[1]: systemd 249.12+suse.151.gbcf040075f running in system mode (+PAM +AUDIT +SELINUX +APPARMOR -IMA -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=hybrid)

Note the line:

Jan 05 18:14:46 pla4-TW systemd[1]: RTC configured in localtime, applying delta of 60 minutes to system time.

6

Yes, sorry I omitted to say that. Alternatively you could add your normal user to the “systemd-journal” group.

7

manythanks, added :grinning: :grinning:

8

as in the instruction here
https://bbs.archlinux.org/viewtopic.php?pid=1575617#p1575617
in my ASUS laptop (the one that fails system sleep more often)
I made this file /etc/systemd/system/disable-USB-wakeup-byPLA2023.service

[Unit]
Description=Disable USB wakeup triggers in /proc/acpi/wakeup

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo XHC > /proc/acpi/wakeup"
ExecStop=/bin/sh -c "echo XHC > /proc/acpi/wakeup"
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

I did not included EHC1 and EHC2 becouse in my /proc/acpi/wakeup there was only XHC and no EHC
then I run this commands:

sudo systemctl enable disable-USB-wakeup-byPLA2023.service
sudo systemctl start disable-USB-wakeup-byPLA2023.service

no error occurred
I rebooted
I don’t know if it is important but in my /proc/acpi/wakeup result this:
XHC S3 *disabled pci:0000:00:14.0

the first two times I tried to sleep worked (at second try), I sleeped from the desktop icon and the system resumed then I tried from the login screen and it worked

but the 2023jan07 at 11:21 I tried to sleep the system and it resumed after few seconds, I tried to sleep again from the login screen and it resumed again, I tried again to sleep and the system hangs with black screen and mouse arrow cannot be moved and keyboard doesn’t works

this is the systemd journal
https://paste.opensuse.org/pastes/58dc33086e42

can be possible to find some useful informations here??

9

How much swap to you have and how much memory?? You need as much swap as memory + any swap used in normal operation. Note that sleep does compress the memory image but compression is rather rule of thumb since it depends on the entropy of the data.

10

Hi, here is for both laptops:
on my TUXEDO laptop (the one that fails system sleep less often) it seems 32GB RAM and 16GB swap

pla@pla4-TW:~> grep MemTotal /proc/meminfo
MemTotal:       32570720 kB
pla@pla4-TW:~> 

pla@pla4-TW:~> sudo swapon -s
[sudo] password for root: 
Filename                                Type            Size            Used            Priority
/dev/sda4                               partition       16383996        0               -2
pla@pla4-TW:~>

on my ASUS laptop (the one that fails system sleep more often) it seems 16GB RAM and 32GB swap

procuste@localhost:~> grep MemTotal /proc/meminfo
MemTotal:       16271432 kB
procuste@localhost:~> 

procuste@localhost:~> sudo swapon -s
[sudo] password di root: 
Filename                                Type            Size            Used            Priority
/dev/sdb5                               partition       32767996        0               -2
procuste@localhost:~>

it seems that the one with 16RAM and 32swap fails more often than the one with 32RAM and 16swap
do you suggest to increse the swap of the TUXEDO?

11

How is it relevant to suspend-to-RAM?

12

I would like to follow these instructions
at this point:
3.2 Instantaneous wakeups from suspend
but I cannor understand what to do, where to insert this
XHCI_SPURIOUS_WAKEUP
black list and where to download it and if it is a permanent solution or temporary.
could somebody help me?

13

It says Haswell and you have Coffee Lake as far as I can tell (at least on one system). Of course, it may still share the same issue.

You insert it in the kernel sources and recompile the kernel. As far as I can tell, it is currently used for the one single chipset only.

It is not even known if it is a solution at all. You may try opening bug report, may be some kernel developer will compile this for you to test.

14

@pier_andreit

On my machines that utilise Gigabyte motherboards there are bios options to disable/ignore wake from S3 sleep on a by peripheral basis: USB, PME, Mouse, KB, etc… I wonder if the bios on your systems also support such a feature?

Additionally, has suspend/resume worked previously and this is a regression bug you’re chasing, or has it never worked.

15

the ASUS (the one that happens more often) is a 2016 laptop, it was my son’s laptop and he never used system sleep, I suspected that the failure started after an update but thinking better it was only that after the update I started to use it more often and I noted more the sleep failure, it happened also before the update.
the TUXEDO (the one that happens less often) is my laptop and I use every day and it happens less often than ASUS so I remember that there was some failure in sleep but I started to note when also ASUS started to fail the sleep

16

Provided you have the time to follow up / test, it would probably be worthwhile opening a bug report at: https://bugzilla.opensuse.org

Searching through existing reports for “suspend / resume” finds several instances of problems on various hardware, for example:
Bug 1181974 – Lenovo X1 Extreme Gen.3: suspend/hibernate to ram doesn't work properly
Bug 1206843 – Lenovo T14s Gen3 AMD resume from sleep broken
Bug 1205410 – Thinkpad T16 touchpad does not work correctly after resume
although they mostly seem to be failure to resume correctly; nonetheless the reports do seem to be acted upon, even if not always resolved.