Graphical corruption in Gnome Shell when resuming from sleep on Nvidia 495.44

UrbenLegend · December 6, 2021, 8:59pm

After upgrading to Nvidia 495.44 on my Arch Linux install, I am experiencing weird graphical glitches in Gnome Shell whenever I resume from sleep. It doesn’t appear every single resume, but it appears quite frequently enough to be bothersome. I can attach a screenshot the next time I encounter this issue.

I do have NVreg_PreserveVideoMemoryAllocations=1 turned on since I need it for Blender to work properly after resuming from sleep. If I turn it off, the corruption issue seems to not occur, at least as far as my personal testing goes, but then of course Blender totally breaks until I restart the program.

Currently, my workaround is to just hit Alt-F2 and type r into the run box to restart Gnome Shell, but having to do this every time is quite annoying.

Is this bug known and can we get it fixed?

Here are the nvidia logs:
nvidia-bug-report.log.gz (924.8 KB)

EDIT: Attached screenshots

generix · December 6, 2021, 11:13pm

Please try setting NVreg_TemporaryFilePath to e.g. /var/tmp

UrbenLegend · December 7, 2021, 2:47am

What does this do? Is it supposed to fix the issue or is this just for logs?

generix · December 7, 2021, 9:38am

It sets the directory where parts of the video memory are dumped to. Default is /tmp which is often tmpfs.

UrbenLegend · December 8, 2021, 3:29am

I did some testing with the following modprobe options:

options nvidia_drm modeset=1
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp
blacklist nouveau

However, I just ran into the same issue so I don’t think changing the temp folder location is working.

user191239281 · December 22, 2021, 1:56am

I’ve seen something similar with Wayland (which is probably not unexpected), resuming under Xorg might be improved with upgpkg: xorg-server 21.1.2-2: fix FS#73075 · archlinux/svntogit-packages@56fe610 · GitHub

UrbenLegend · December 22, 2021, 2:11am

I’ve already tried it with this fix. Graphical issues still exist after resume, but at least it properly resumes now instead of giving me a black screen like 21.1.2-1 did.

user191239281 · December 22, 2021, 2:16am

Thinking a bit more, this seems to trigger a memory… I can’t remember exactly where I saw this, but I think I saw a similar issue and it was related to an extension or system or shell theme (e.g. try Adwaita if you aren’t already using it).

victorsbayas · December 27, 2021, 7:55pm

I’m also experiencing graphics corruption (random squares) in applications after resuming from sleep. I use Gnome Xorg session (Wayland is broken for Optimus laptops) on Arch Linux.

victorsbayas · December 27, 2021, 7:59pm

Due to forum limitations I can only upload an image per post

UrbenLegend · December 28, 2021, 12:41am

@user191239281 I am already using Adwaita. As for shell extensions, I am using:

Sound Input & Output Device Chooser
Tiling Assistant
Tray Icons: Reloaded

Any of these ring a bell?

@victorsbayas I am getting the exact same graphical issues you are in addition to the graphical glitches in Gnome Shell.

padamstx · February 12, 2022, 3:17pm

I started experiencing this same problem several weeks ago with the 495.46 nvidia driver.
Yesterday, I installed some updates which included a new kernel (5.16.7-100) and a new version of the nvidia driver (510.47), and I’m still seeing the same corrupted graphics problem after a resume.

Anyone have any info on when a fix might be available? Is this a known problem that has been reported “properly”?

Thanks!

alwaysanon · February 26, 2022, 2:57am

As per what generix suggested, I was having this issue on Fedora 35 with Gnome and XWin (rather than Wayland - because of the nvidia driver) and creating an /etc/modprobe.d/nvidia.conf and putting this line in it seems to have resolved it for me:
options nvidia NVreg_TemporaryFilePath=/var/tmp

username.murphy · March 9, 2022, 5:14am

Does having the correct (ACPI) kernel parameters set for your specific hardware platform help?
Example Only:
" acpi_osi=! acpi_osi=‘Windows 2020’ acpi_enforce_resources=lax acpi_sleep=s3_mode mem_sleep_default=deep numa=off iommu.forcedac=1 iommu=memaper "

NVreg_PreserveVideoMemoryAllocations=1

https://www.kernel.org/doc/html/v5.16/admin-guide/kernel-parameters.html

github.com

torvalds/linux/blob/master/Documentation/admin-guide/pm/sleep-states.rst

.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>

===================
System Sleep States
===================

:Copyright: |copy| 2017 Intel Corporation

:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>


Sleep states are global low-power states of the entire system in which user
space code cannot be executed and the overall system activity is significantly
reduced.


Sleep States That Can Be Supported
==================================

This file has been truncated. show original

github.com

torvalds/linux/blob/master/Documentation/power/video.rst

===========================
Video issues with S3 resume
===========================

2003-2006, Pavel Machek

During S3 resume, hardware needs to be reinitialized. For most
devices, this is easy, and kernel driver knows how to do
it. Unfortunately there's one exception: video card. Those are usually
initialized by BIOS, and kernel does not have enough information to
boot video card. (Kernel usually does not even contain video card
driver -- vesafb and vgacon are widely used).

This is not problem for swsusp, because during swsusp resume, BIOS is
run normally so video card is normally initialized. It should not be
problem for S1 standby, because hardware should retain its state over
that.

We either have to run video BIOS during early resume, or interpret it
using vbetool later, or maybe nothing is necessary on particular

This file has been truncated. show original

https://us.download.nvidia.com/XFree86/Linux-x86_64/495.46/README/powermanagement.html