You are not logged in.
I've recently installed arch linux (with a kde plasma desktop enviroment) and noticed that after suspending my system to RAM that my window decorations break and their color changes to grey on my applications. If I then click on any of the buttons in the titlebar then the titlebar's font gets messed up and the application crashes shortly after. I also noticed that I get a notification from KWin window manager after waking from suspension that says 'Desktop effects were restarted due to a graphics reset'. I've spent some time searching Google and the Arch wiki for a solution but can't seem to find anything on how to fix this and was hoping someone here could help me.
Thanks!
Offline
qdbus org.kde.KWin /KWin supportInformation
In case of nvidia:
https://download.nvidia.com/XFree86/Lin … ement.html
Online
Here's the output: https://pastebin.com/TcvA8Qw1
I checked the article you posted since I have an nvidia GPU but noticed that I don't have a
/usr/share/doc/NVIDIA_GLX-1.0
directory. Do I have to install something to create the files it talks about? I've already installed drivers for my GPU that seem to work.
Offline
The relevant service files are already properly prepared by the package, you just need to systemctl enable the list mentioned later.
Offline
Ok, I used systemctl to enable the nvidia-suspend.service, nvidia-hibernate.service, and nvidia-resume.service like the article said but noticed the problem persisted. I restarted the system to see if that would have any effect but that seemed to have no effect.
Offline
Can you reproduce this on "official" window decorations, i.e. breeze ? Might be an issue with the aurorae engine.
Offline
Tried switching to both breeze and oxygen and then logging out but I still get the notification that desktop effects were restarted after waking from suspension. The buttons to minimize/exit/etc the program also start flickering when not using aurorae.
Last edited by StrangeAlmond (2020-04-02 18:44:47)
Offline
Does it happen
a) when only using one monitor?
b) with the xrender compositing backend?
Online
a) Yes
b) Yes, but no notification
Last edited by StrangeAlmond (2020-04-02 20:36:26)
Offline
(b) means that the deco still acts up, but the compositor isn't terminated? (In doubt check the supportInformation)
Online
Yes
Offline
And you're back on the aurorae engine?
This sounds a lot like you're loosing the VRAM, did you pass NVreg_PreserveVideoMemoryAllocations=1 to the nvidia kernel module?
Online
Yes. I have not, should I do that?
Offline
This section is specific to the /proc/driver/nvidia/suspend interface. The NVIDIA Linux kernel driver requires no configuration if the default power management mechanism is used.
In order to take advantage of the /proc interface, a system management tool like systemd needs to be configured to access it at appropriate times in the power management sequence. Specifically, the interface needs to be used to suspend or hibernate the NVIDIA kernel drivers just before writing to the Linux kernel's /sys/power/state interface to request entry into the desired sleep state. The interface also needs to be used to resume the NVIDIA kernel drivers immediately after the return from a sleep state, as well as immediately after any unsuccessful attempts to suspend or hibernate.
To save potentially large copies of video memory, the NVIDIA driver uses unnamed temporary files. By default, these files are created in /tmp, but this location can be changed with the TemporaryFilePath kernel module parameter, e.g. TemporaryFilePath=/run. The destination file system needs to support unnamed temporary files, and it needs to be large enough to accommodate all video memory copies for the duration of power management cycles.
When determining a suitable size for the video memory backing store, it is recommended to start with the overall amount of video memory supported by the GPUs installed in the system. For example: nvidia-smi -q -d MEMORY |grep 'FB Memory Usage' -A1. Each Total line returned by this command reflects one GPU's video memory capacity, in MiB. The sum of these numbers, plus 5% of margin, is a conservative starting point for the size of video memory save area.
Please note that file systems such as /tmp and /run are often of the type tmpfs, and potentially relatively small. Most commonly, the size of the type of the file system used is controlled by systemd. For more information, see https://www.freedesktop.org/wiki/Softwa … ileSystems. To achieve the best performance, file system types other than tmpfs are recommended at this time.
Additionally, to unlock the full functionality of the interface, the NVIDIA Linux kernel module needs to be loaded with the NVreg_PreserveVideoMemoryAllocations=1 module parameter. This changes the default video memory save/restore strategy to save and restore all video memory allocations.
Last edited by seth (2020-04-02 21:37:08)
Online
I've created a /etc/modprobe.d/nvidia-suspend.conf file with the contents
options nvidia NVreg_PreserveVideoMemoryAllocations=1
but the problem persists after a restart.
Offline
If the nvidia module is in your initramfs, this won't suffice.
https://wiki.archlinux.org/index.php/Ke … le_options
Online
I added my nvidia-suspend.conf file to the FILES variable in the /etc/mkinitcpio.conf file ( FILES=(/etc/modprobe.d/nvidia-suspend.conf) ) and restarted the system. However, the window decorations still break after waking from suspension.
Offline
You'll still have to rebuild the initramfs.
You caould also just try passing it to the kernel directly…
Online
Tried adding the kernel parameter (nvidia.NVreg_PreserveVideoMemoryAllocations=1) to grub both at boot and via the config file but neither seemed to fix the issue.
Offline
Tried reinstalling Arch and following the steps again, but the compositor still breaks after waking from suspension. Perhaps I'm passing the module parameter incorrectly? I've also tried switching the kernel to linux-lts, but that doesn't fix it either.
Here's the dmesg output when suspending and waking from suspension if that helps: https://pastebin.com/SwP89PZ9
Last edited by StrangeAlmond (2020-04-05 20:02:37)
Offline
Tried reinstalling Arch
That's not going to work. Ever. For nothing.
Perhaps I'm passing the module parameter incorrectly?
cat /proc/cmdline
Did you check "nvidia-smi -q -d MEMORY |grep 'FB Memory Usage' -A1" and compare it to your tmpfs capacity?
Online
cat /proc/cmdline
returns
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=0a34e1c6-ab13-4c0c-b12e-ccec1173f818 rw loglevel=3 quiet nvidia.NVreg_PreserveVideoMemoryAllocations=1
so it looks like I'm loading the module parameter correctly.
nvidia-smi -q -d MEMORY |grep 'FB Memory Usage' -A1
returns 1997 MiB, so I checked the size of my /tmp with "df -h /tmp" and it says I have 7.8 GB of storage available, with only 1% used. The same holds true for /run.
Last edited by StrangeAlmond (2020-04-05 22:21:24)
Offline
I noticed that whenever the graphics reset that this message also appears in /var/log/Xorg.0.log
[ 61.435] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
[ 61.435] (II) NVIDIA(0): may not be running or the "AcpidSocketPath" X
[ 61.435] (II) NVIDIA(0): configuration option may not be set correctly. When the
[ 61.435] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
[ 61.435] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For
[ 61.435] (II) NVIDIA(0): details, please see the "ConnectToAcpid" and
[ 61.435] (II) NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X
[ 61.435] (II) NVIDIA(0): Config Options in the README.
Could this be what's causing the issue?
Last edited by StrangeAlmond (2020-04-30 02:29:08)
Offline
No, that's "normal" and logged everytime you init the nvidia driver (should™ be there even before the first suspend)
Online
Was this problem solved?
I am facing the same problem.
Offline