[SOLVED] Nvidia driver update causing suspend + screen tearing problem

GeneralPoxter · 2020-09-25 02:34:37

I have a GeForce RTX 2070 SUPER, running Arch with GNOME on my computer.

I do recall having screen-tearing before the recent nvidia driver updates (specifically from 450.66-21 to 450.66-22), but activating Full Composition Pipeline was able to fix it. However, upon updating, the screen tearing came back. Upgrading to nvidia-455 did not fix any of the screen-tearing.
Throughout this entire process Full Composition Pipeline was active, and was able to reduce some screen-tearing, but not all of it all the time.

With no kernel modesetting and no additional options to my xorg.conf besides Full Composition Pipeline, there is no screen-tearing, but there are suspend problems. I see a blank screen immediately after awakening that hangs for a second or two before the screen loads. Such a suspend problem did not occur before the above nvidia driver updates. After the screen loads, some applications (e.g. anki and vscode) have black artifacts and other graphical issues. For example, in anki, the entire screen is black while in vscode, I see some black rectangles off to the side and the text for the terminal prompt disappears. Changing workspaces gets rid of the blank anki screen while hovering over the artifacts and reopening the in-application terminal fixes vscode issues. Nevertheless, this is an extremely annoying issue that also affects some GNOME themes I tried to apply. I suspect this same issue affects other applications.

I spent up to an hour and half researching the problem on the web and trying different solutions, but to no avail.

Modesetting (e.g. nvidia-drm.modeset=1) without TripleBuffering and IndirectGLXProtocol options in xorg.conf results in no suspend problems, but significant screen-tearing

Turning TripleBuffering on and/or turning IndirectGLXProtocol off results in the above suspend problems but no screen-tearing (with and without kernel modesetting).

As you can see, I am either left with having screen-tearing but no suspend problems or no screen-tearing and suspend problems.
Downgrading just the nvidia packages to a version before the driver update that broke my setup breaks lightdm.
Downgrading to a mirror on September 17 (before the driver update) is doable, but not ideal as I would rather have software updates with graphical inconveniences than a computer stuck in time.

I am not entirely sure this is an issue with the nvidia driver specifically, but given the above events, I believe it is quite plausible.

Please tell me if you are experiencing the same issues. I would like to know what solutions you have tried as well.

Last edited by GeneralPoxter (2020-10-19 12:43:25)

loqs · 2020-09-25 03:32:04

If you downgrade to September 17 using the ALA. Change from the nvidia package to the nvidia-dkms and check if the issue is present.
Then upgrade the kernel to 5.8.10.arch1-1 which is the kernel update matching 450.66-21 to 450.66-22, is the issue present after reboot?

GeneralPoxter · 2020-09-25 04:41:30

According to the wiki, nvidia-dkms is for custom kernels, but I use mainline linux kernel - so before I go about doing that, I want to know whether that might break my system or not.
Also, if it is safe to try that, couldn't I just try replacing my nvidia package with nvidia-dkms without downgrading to September 17?

kokoko3k · 2020-09-25 08:41:07

It is safe to use dkms packages with non custom kernels too.

GeneralPoxter · 2020-09-25 13:21:58

I did loqs's suggestion, but apparently on the September 17 mirror, the same problems persist under the same conditions.
However, the only noticeable difference is that before the September 18 updates, wakening my computer from suspend does not take as long and there is no hanging black screen.
Trying to replace the nvidia package with nvidia dkms results in: ==> Unable to install module nvidia/450.66 for kernel *: Missing kernel headers.
Rebooting, I find that this breaks lightdm.

loqs · 2020-09-25 13:28:01

You need linux-headers so DKMS can build a module for the kernel. So the issue started before September 17th?
Edit:
The 450 series was in the repositories starting July 9th so you have to go back to July 8th for the 440 series.

Last edited by loqs (2020-09-25 13:37:54)

GeneralPoxter · 2020-09-25 15:34:46

I'm really confused now. I undid the mirror downgrade, but now all of the above properties I observed don't apply anymore.
The common trend is it seems that on initial boot, screen tearing + no suspend problems.
But all subsequent reboots have no screen tearing + suspend problems.
It doesn't matter if I kernel modeset or set options in the xorg.conf anymore.

GeneralPoxter · 2020-09-25 16:14:39

This is even weirder. Sometimes initial boot after a power down does not have screen tearing, but sometimes it does. I have no idea why. I didn't change any settings and did this five times in a row. 2 out of the five times had screen-tearing for no particular reason.
Logging out and logging back in seems to fix the problem, but now I'm really confused.

Last edited by GeneralPoxter (2020-09-25 16:15:35)

GeneralPoxter · 2020-09-25 16:21:20

And yes, having no screen tearing always seems to coincide with suspend problems.

One time, but not all the time, I got the following errors when closing out of anki after graphical problems:
[2797:2822:0925/121607.231876:ERROR:gles2_cmd_decoder.cc(8617)] [.DisplayCompositor]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glFramebufferTexture2D: <- error from previous GL command

This suggests that the issue might have something to do with compositors, so I'm going to try switching to a DE/WM without compositors and see what happens.
Unfortunately, this does not resolve the problem of inconsistent screen-tearing results after powering on.

GeneralPoxter · 2020-09-25 16:32:33

Update: I'm not sure what the heck this did, but adding the "TripleBuffering" and "AllowIndirectGLXProtocol" options to not just "Screen" (as the wiki recommends) but also the Nvidia "Device" section in the xorg.conf seems to result in a consistently tear-free experience.
I've powered off and powered on five times in a row, and none had any screen-tearing.
I'm not exactly sure why this works, but theories are welcome.

GeneralPoxter · 2020-09-25 23:33:20

Update: the above fix doesn't actually work.
Also it doesn't seem to be a GNOME compositor issue. Switching to xmonad did not solve any of my graphical problems.
Now there is no pattern to the graphical issues.
Sometimes when I boot, there's screen-tearing (and some applications like Zoom run at extremely high cpu usage), but no suspend problems. This can be solved temporarily by logging out and logging back in through lightdm, but it can be undone by the next boot.
Sometimes when I boot, there's no screen-tearing, but qt5 applications like Anki as well as other applications like VSCode have graphical problems after a suspend.
I've tried almost every fix conceivable on linux and nvidia forums and wikis throughout, but none seem to be able to fix my issues.
Given that the driver update seemed to only lead to minor slow down when resuming from suspend, I'm not sure whether this thread can be moved to a more suitable topic.

V1del · 2020-09-26 10:00:09

Please stop bumping your thread every time a new thought occurs to you, there's an edit button if no one has answered in between to amend previous posts.

The "screen tearing" case just sounds like one of the usual race condition issues during startup, follow https://wiki.archlinux.org/index.php/NV … de_setting to enable the modules to be loaded early.

Suspension works in this case because your nvidia card is not actually rendering xorg correctly and you use a software renderer.

The suspension issues when the nvidia card is the actual driving force are somewhat known, there's a new way that wakeup from suspension can be configured for that should alleviate issues like these: https://wiki.archlinux.org/index.php/NV … er_suspend

In any case, instead of assumptions based only on the observation of symptoms, check/post your xorg log and a journal excerpt from after boot with tearing, no tearing, suspension issues, no suspension issues.

Last edited by V1del (2020-09-26 10:00:54)

GeneralPoxter · 2020-09-26 15:54:27

I already have "options nvidia-drm modeset=1" in a config in /etc/modprobe.d/

I have tried the preserve memory allocation, but that caused my computer to not wake properly from suspend.
I put the options in an /etc/modprobe.d/ conf file and enabled all 3 services, but I was not sure what to make the tmp file path. That might have been the problem last time, so I was wondering what an example NVreg_TemporaryFilePath would look like?

Also, sorry about the comment chain. I won't do it again : (

Last edited by GeneralPoxter (2020-09-26 15:57:33)

kokoko3k · 2020-09-26 17:14:38

Do you have an integrated IGP?
Try to put your Nvidia to sleep and use it for heavy gpu tasks only; use the integrated chip for everything else.
https://wiki.archlinux.org/index.php/PR … er_offload

GeneralPoxter · 2020-09-26 17:34:29

How do I tell if I have an IGP?
I know that my processor is an Intel Core i7-9700 and that my graphics card is a GeForce RTX 2070.

kokoko3k · 2020-09-26 18:09:08

Yea, your cpu does provide an integrated gpu.

GeneralPoxter · 2020-09-26 18:23:20

I am a bit confused after reading the wiki pages you linked me. Do I just install nvidia-prime and reboot?

Also I'm not sure what I did wrong with kernel modesetting. I tried having "nvidia-drm.modeset=1" included in the Linux commandline in my /etc/default/grub, and then having a conf file in my /etc/modprobe.d/ do the same thing, but I seem to experience race condition issues for both.
I'm going to post the journal logs soon, but should I filter for any specific terms since I don't want include an overwhelmingly long log.

Last edited by GeneralPoxter (2020-09-26 22:29:20)

kokoko3k · 2020-09-26 23:00:51

I'm sorry, but if you are completely unaware of what i'm talking about, then probably it is not a good idea to follow my advice.
After all, what i was suggesting was just a workaround.

GeneralPoxter · 2020-09-26 23:53:56

I understand what prime does, but I was just worried I might mess it up since the wiki doesn't seem to be all that clear on what to do.
I'm having traumatic flashbacks to my Ubuntu days in which I was trying to troubleshoot something to do with nvidia's prime-select.

Thanks for your help though, I'm just confused overall since I've read through nvidia troubleshooting on the Arch wiki and also on various forums, but they all don't seem to work for me.

I just need some help implementing V1del's suggestion since it seems to address both my inconsistent screen-tearing and my suspend problems. I've tried on my own using just the wiki, but I think I might have missed something (see above). I'm also not entirely sure what I should be looking for in the journal logs.

Last edited by GeneralPoxter (2020-09-27 00:00:15)

V1del · 2020-09-27 13:45:02

If you're not sure, you need to post them, many of us generally know what to look for but it's hard to explain what to look for so it's easier if the relevant contents are provided.

FWIW to properly enable early loading, just adding the modeset param to modprobe is insufficient, you need to do the whole setup with adding the modules to the initramfs.

GeneralPoxter · 2020-09-27 14:53:27

Yes I did read that sometimes udev does not ensure that it will work.
I added the modules in a conf file in /etc/modules-load.d/, but I have yet to find out whether it works. When you say the modules should be added to the initramfs, does that mean adding it to MODULES in the /etc/mkinitcpio.conf?
I also tried dumping the log of a non-screen-tearing boot into a txt file, but it turns out to be at least 2000 lines long. Is that okay, or should I try filtering it out a bit more? (I noted that there are far fewer (only around a few hundred) lines when I run journalctl -b as the user, but I'm not sure whether that might leave out some important information)

Last edited by GeneralPoxter (2020-09-27 14:58:39)

V1del · 2020-09-27 15:13:19

That does mean adding them to the MODULES section in initramfs (read the link beyond the modeset parameter). modules-load.d is for drivers/kernel modules that aren't natively loaded by udev, which is irrelevant for the issue as present, they are loaded, just logically too late to be ready for the xorg start, as linux has (at least not in the default config) no concept of explicitly waiting for the graphics driver before trying to load the graphical target/xorg (this is - by the way - not specific to nvidia this can and does happen with every setup).

Posting the journal here in [ code ] [ /code ] tags without the spaces is fine if you still have doubts use a pastebin service. Yes just the user journal usually leaves out important information and we are interested in kernel/system space so you should post one from sudo/root

GeneralPoxter · 2020-09-27 15:35:14

Since the solution does require modifying the mkinitcpio.conf, I should also link the conf file in my /etc/modprobe.d/ that does loads the modules with options in the FILES section?
Here are the pastebins of the boot journal logs (one with suspend and one without) of non-screen-tearing boots:
https://pastebin.com/dXR6ysad
https://pastebin.com/UMyas73e
I have yet to boot into a case where there is screen-tearing.

Last edited by GeneralPoxter (2020-09-27 15:35:36)

V1del · 2020-09-27 17:54:09

You could do that, but unless you deviate from the default hooks, the modconf hook should be loaded by default and it will ensure that the file is present even without you explicitly adding that.

GeneralPoxter · 2020-09-27 18:44:04

Yes, modconf is in my Hooks, so I just made the Modules line MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm) and updated the initramfs.
I'll update this comment if screen-tearing persists. So far everything seems to be working fine on reboot - save for the suspend problems.

Edit: Adding the nvidia modules to my mkinitcpio seems to have fixed the inconsistent reboot problem. Now I am wondering what I should set the NVreg_TemporaryFilePath for Preserve Memory Allocation fix since the wiki isn't all too clear on this.

Update: I tried the preserve video memory allocation trick again by setting the temporary file path to /tmp/nvidia. This did not work, and the log file can be found here: https://pastebin.com/Jdng9jyR (the nvidia suspend error starts at line 2048). When I start sleep, the screen just goes blank and I can't seem to wake my computer up again. I don't know what went wrong and could use some help! Thanks!

Last edited by GeneralPoxter (2020-10-01 16:49:09)

Arch Linux

#1 2020-09-25 02:34:37

[SOLVED] Nvidia driver update causing suspend + screen tearing problem

#2 2020-09-25 03:32:04

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#3 2020-09-25 04:41:30

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#4 2020-09-25 08:41:07

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#5 2020-09-25 13:21:58

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#6 2020-09-25 13:28:01

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#7 2020-09-25 15:34:46

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#8 2020-09-25 16:14:39

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#9 2020-09-25 16:21:20

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#10 2020-09-25 16:32:33

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#11 2020-09-25 23:33:20

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#12 2020-09-26 10:00:09

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#13 2020-09-26 15:54:27

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#14 2020-09-26 17:14:38

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#15 2020-09-26 17:34:29

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#16 2020-09-26 18:09:08

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#17 2020-09-26 18:23:20

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#18 2020-09-26 23:00:51

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#19 2020-09-26 23:53:56

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#20 2020-09-27 13:45:02

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#21 2020-09-27 14:53:27

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#22 2020-09-27 15:13:19

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#23 2020-09-27 15:35:14

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#24 2020-09-27 17:54:09

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

#25 2020-09-27 18:44:04

Re: [SOLVED] Nvidia driver update causing suspend + screen tearing problem

Board footer