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.binSo 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.