On 16/09/2025 05:13, Max Nikulin wrote:
On 15/09/2025 19:35, Eugen Dedu wrote:
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
So the files with the same name are not identical. I would check the
upstream repository if a version for your graphics card is available there.
Seems this is a known bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112208
("firmware-nvidia-graphics: Missing gsp symlink for nvidia ad107").
I made a symbolic link, as the bug report specifies. Now, there is no
error anymore.
On 15/09/2025 04:29, Max Nikulin wrote:
Have the period of resumes changed? What tasks are executed
accordingly to journalctl?
The period is the same, 1h13.
[...]
(full log at https://dedu.fr/log2.txt)
I do not see anything really suspicious. I would search for details of:
"kernel: spd5118 0-0050: PM: dpm_run_callback(): spd5118_resume
[spd5118] returns -6" since I have not idea concerning its impact.
Skimming through "sudo journalctl -b" and searching for noticed warnings
and errors (they are highlighted) might give some hints.
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?
If it was so, I would consider it as a bug. After all, NetworkManager
disables the interface during suspend. You still may disable autoconnect
in connection properties and may explicitly deactivate the connection
before suspending.
I disconnected from AP before suspending: The issue is still there.
What you have posted so far tells that there is no difference of lid
switch and sleep button as they are handled by Linux. Maybe it is
firmware that prevents wake ups when the lid is closed. (By the way,
what happens if you suspend the machine using the sleep button and close
the lid afterwards?)
Power button pressed at around 14:51:47, around 5 secs later close lid,
around 10 secs later open lid (<14:52:10) and awake the laptop.
The log shows that closing lid does not add any info in the log.
Interesting information, however we made no progress.
Tired to see that there is no success so far :o( I hoped to get a
method to discover the program requesting awake up. What a pity there
is no direct way to find out the *cause* of an awake, the only method is
by modify-and-check trials...
I hope, you have tried *cold* reboot after disabling and removing
packages. If it does not reset wake up timers, I am afraid, you have to
check if Dell platform modules expose some timers. There a chance that
some info unrelated to Linux is available on some sites.
I use the simple awesome window manager, I do not remember having
played with dconf etc.
Then I would try to boot a live image with GNOME or KDE that have power
management features to test if behavior is the same.
Yes, I should try...
I do not use external packages or applications, everything is from
Debian.
I was shooting dark speculating that Windows booted before you have
installed Linux could arrange some timers.
Perhaps, it was 9 months ago, when our network administrator received
the machine.
You see, I have run out of ideas. I do not see which way the following
links may be immediately useful, but perhaps they might provide some
keywords for search queries.
<https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html>
<https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html>
Looked over them, nothing interesting except debugging at the end of the
page, and looking at /sys/kernel/debug/wakeup_sources, but it is too
verbose and only numbers.
