Re: Laptop resumes each 1h13 after suspend-to-ram
On 15/09/2025 04:29, Max Nikulin wrote:
On 15/09/2025 00:26, Eugen Dedu wrote:
On 13/09/2025 05:27, Max Nikulin wrote:
I expect, you may make it a bit shorter by installing firmware-
nvidia- graphics.
I have this package installed, but ad107 subdirectory is empty, cf.
https://packages.debian.org/sid/all/firmware-nvidia-graphics/filelist
I missed that available files reside in other directories. Sorry. Are
they really different files or symlinks/hardlinks to the same blob? I
would check the upstream repository if files for your graphics card are
available there.
I do not see files related to ad107:
snoopy:~$ ls -l /usr/lib/firmware/nvidia/ad107
total 0
snoopy:~$ ls -ld /usr/lib/firmware/nvidia/ad107
drwxr-xr-x 2 root root 4096 Aug 16 20:50 /usr/lib/firmware/nvidia/ad107
snoopy:~$
snoopy:~$ dpkg -S gsp-535
firmware-nvidia-graphics:
/usr/lib/firmware/nvidia/ga100/gsp/gsp-535.113.01.bin
firmware-nvidia-graphics:
/usr/lib/firmware/nvidia/tu116/gsp/gsp-535.113.01.bin
firmware-nvidia-graphics:
/usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin
firmware-nvidia-graphics:
/usr/lib/firmware/nvidia/ga102/gsp/gsp-535.113.01.bin
firmware-nvidia-graphics:
/usr/lib/firmware/nvidia/ad102/gsp/gsp-535.113.01.bin
snoopy:~$ ls -l /usr/lib/firmware/nvidia/ga100/gsp/gsp-535.113.01.bin
/usr/lib/firmware/nvidia/tu116/gsp/gsp-535.113.01.bin
/usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin
/usr/lib/firmware/nvidia/ga102/gsp/gsp-535.113.01.bin
/usr/lib/firmware/nvidia/ad102/gsp/gsp-535.113.01.bin
lrwxrwxrwx 1 root 34 Aug 15 14:51
/usr/lib/firmware/nvidia/ad102/gsp/gsp-535.113.01.bin ->
../../ga102/gsp/gsp-535.113.01.bin
lrwxrwxrwx 1 root 34 Aug 15 14:51
/usr/lib/firmware/nvidia/ga100/gsp/gsp-535.113.01.bin ->
../../tu102/gsp/gsp-535.113.01.bin
-rw-r--r-- 1 root 38061600 Aug 15 14:51
/usr/lib/firmware/nvidia/ga102/gsp/gsp-535.113.01.bin
-rw-r--r-- 1 root 23750944 Aug 15 14:51
/usr/lib/firmware/nvidia/tu102/gsp/gsp-535.113.01.bin
lrwxrwxrwx 1 root 34 Aug 15 14:51
/usr/lib/firmware/nvidia/tu116/gsp/gsp-535.113.01.bin ->
../../tu102/gsp/gsp-535.113.01.bin
snoopy:~$
I noticed that even if I stop fwupd service, it restarts automatically
after some time. So, to be sure, I removed all packages fwupd*:
You should stop or disable timer rather than service. Consider
installing fwupd back later.
Sure. I forgot to add that I also removed - until the issue is solved -
anacron, because it was at the top of my list of timers.
Finally, I do not have any suspicious WakeSystem:
root@snoopy:~# grep -r WakeSystem /etc/systemd/
Notice that units provided by packages are in
/usr/lib/systemd/system
Right, sorry. Still, no WakeSystem there:
root@snoopy:~# grep -r WakeSystem /usr/lib/systemd/system
root@snoopy:~#
However, the awaking problem is still there.
Have the period of resumes changed? What tasks are executed accordingly
to journalctl?
The period is the same, 1h13.
journald upon awaking at 11h24 shows some units and NetworkManager,
among others:
Sep 15 11:24:11 snoopy systemd[1]: user@1000.service: Unit now thawed.
Sep 15 11:24:11 snoopy systemd[1]: session-3.scope: Unit now thawed.
Sep 15 11:24:11 snoopy systemd[1]: user-1000.slice: Unit now thawed.
Sep 15 11:24:11 snoopy systemd[1]: user.slice: Unit now thawed.
Sep 15 11:24:11 snoopy systemd-sleep[2921]: Successfully thawed unit
'user.slice'.
Sep 15 11:24:11 snoopy systemd[1]: systemd-suspend.service: Deactivated
successfully.
Sep 15 11:24:11 snoopy systemd[1]: Finished systemd-suspend.service -
System Suspend.
Sep 15 11:24:11 snoopy systemd[1]: Stopped target sleep.target - Sleep.
Sep 15 11:24:11 snoopy systemd[1]: Reached target suspend.target - Suspend.
Sep 15 11:24:11 snoopy systemd-logind[992]: Operation 'suspend' finished.
Sep 15 11:24:11 snoopy NetworkManager[1027]: <info> [1757928251.8773]
manager: sleep: wake requested (sleeping: yes enabled: yes)
Sep 15 11:24:11 snoopy NetworkManager[1027]: <info> [1757928251.8774]
device (enp0s31f6): state change: unavailable -> unmanaged (r>
(full log at https://dedu.fr/log2.txt)
In the past I tried removing NetworkManager and still had the issue.
Could the culprit be dhcp client which awakes the laptop to renew the lease?
As to logind, perhaps the following is more reliable
systemd-analyze cat-config systemd/logind.conf | grep 'Lid\|Suspend'
The output is:
root@snoopy:~# systemd-analyze cat-config systemd/logind.conf | grep
'Lid\|Suspend'
#HandleSuspendKey=suspend
#HandleSuspendKeyLongPress=hibernate
HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#SuspendKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=
root@snoopy:~#
I would check power management configuration of desktop environment as
well.
I use the simple awesome window manager, I do not remember having played
with dconf etc.
I have heard that on Windows a mailer and social network applications
may request wake ups to receive messages. I cannot say if something
similar is available on Linux.
I do not use external packages or applications, everything is from Debian.
Is it common for both cases of keyboard button and lid? On my laptop
I have "PM: suspend entry (deep)", "ACPI: PM: Preparing to enter
system sleep state S3", "ACPI: PM: Waking up from system sleep state
S3". Perhaps different power states are configured for different event.
For me it is s2idle in both cases:
root@snoopy:~# journalctl --since '2025-09-14 19:07' >button
root@snoopy:~# journalctl --since '2025-09-14 19:09' >lid
If there are no apparent difference then I have no other ideas.
I am unsure if various power management tools (tlp and others) might
have something related to scheduled wake ups.
What I would like to get is a method to discover the program requesting
awake up, because I tried numerous methods without detecting it.
Reply to: