[solved] Flickering/glitching after suspend end x11 kde plasma nvidia

heyimnyl · 2024-02-21 23:12:25

Hello,

So since I switched to Linux I sometimes have this issue of all open windows flickering, glitching all over the place, screen partially black, cant really move windows because I don't see them after resume from suspend to ram.
I basically have to go through a reboot to fix it and not get a seizure.

I honestly do not know what to look for or where to start because sometimes I close a Window like dolphin and it's gone. Now the flickering even happened in lockscreen after wake up from suspend to ram. So I almost couldn't log in but I just typed my password and got the journal from the wake up until yea .. 2 minutes until I figured - ok no Idea whats going on or how to fix I'm just gonna reboot.
This only happens sometimes. sometimes the resume from suspend is fine.
I run dual monitors and nvidia gpu if thats of importance

If anyone would be so kind to tell me what is going on, because I'm lost and don't want this to become a bigger issue than it already is.

This is my journal from that moment: https://pastebin.com/raw/3Ebcf3Yw
at the end of the log I turned off 1 screen where my mouse and kb are connected too in hopes of fixing it somehow but yea. nothing.

thank you!

Last edited by heyimnyl (2024-04-01 05:52:39)

V1del · 2024-02-22 00:14:29

nvidia GPUs have known problems with this, set up the vram session restore hooks: https://wiki.archlinux.org/title/NVIDIA … er_suspend read this carefully, there are some important decisions you have to make so this has a chance of working properly.

Also if you happen to use the fbdev parameter, you probably don't want to use that yet, it's known to be buggy.

heyimnyl · 2024-02-22 03:10:31

Ok. I don't want to make any mistakes so excuse potentially stupid questions but so far I'm a month in to this and don't wanna mess up to a point where i can not recover from.

As far as I understand I have set certain things up during install which leaves me with:

This is my /boot/loader/entries/arch.conf

title Arch
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=8283a806-21dd-46b0-84bb-a3d810190ad6 rw nvidia-drm.modeset=1
options snd_usb_audio.implicit_fb=1

This is part of my /etc/mkinitcpio.conf

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

and I also have a pacman hook already.

[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
Target=nvidia

[Action]
Depends=mkinitcpio
When=PostTransaction
Exec=/usr/bin/mkinitcpio -P

So.. I would need to place:

NVreg_PreserveVideoMemoryAllocations=1
NVreg_TemporaryFilePath=/var/nvidiatmp

in the boot loader entry arch.conf
like this?

options NVreg_PreserveVideoMemoryAllocations=1
options NVreg_TemporaryFilePath=/var/nvidiatmp

and enable / install

nvidia-suspend.service

correct?

not going for nvidia-hibernate.service because I don't hibernate.
not going for nvidia-resume.service because it's optional for x11 and I don't want to cause more problems by enabling something that's already provided.

The factual accuracy of this article or section is disputed. IOW, early KMS should not be used if hibernation is desired.

^this should be a non issue because hibernation is not desired nor used.

Questions:
1. Is the directory /var/nvidiatmp ok and is it ok if I already created it? (yes the root partition has 500g free so it should be fine for the gpu vram. yes it's a lot I didnt know better )
2. Am I missing something here? there is no way that the steps I followed a month ago set me up for the this so well.
3. Is there a way to check my arch.conf in boot/loader/entries for .. being valid? being ok / error free? before actually rebooting and finding out the hard way?

Thank you!
I know it's a lot but .. Idk where else to go

Last edited by heyimnyl (2024-02-22 03:43:17)

seth · 2024-02-22 10:11:07

So.. I would need to place:
NVreg_PreserveVideoMemoryAllocations=1
NVreg_TemporaryFilePath=/var/nvidiatmp
in the boot loader entry arch.conf
like this?

No.
https://wiki.archlinux.org/title/Kernel … le_options

Questions

1. Yes and yes
2. probably not outside the above
3. "cat /proc/cmdline"

V1del · 2024-02-22 10:14:05

That sounds about right. I'm pretty sure you need to create the directory beforehand indeed. If your parameters are incorrect on the arch.conf they will just be ignored, you shouldn't be able to inherently break things here -- and adding these parameters, the worst that can happen that nvidia doesn't load, which would still leave you with a terminal to fix things.

F5.. and whoops I didn't notice the option name fuckup, follow seths advice here.

Last edited by V1del (2024-02-22 10:15:29)

heyimnyl · 2024-02-22 19:36:11

Thank you both!

I was able to boot normally and so far everything seems to be fine, no graphical glitches when waking up from suspend for now.

Does the filename in /modprobe.d/ matter?

Because I used nvidiamodprobe.conf for the vram glitch but I also tried - after Seth told me where to put this stuff and the place is not /boot/loader/entries/arch.conf - to put

options pcie_port_pm=off
options pcie_pme=nomsi

this in a file named: /modprobe.d/pciepme.conf

and I was greeted with the good old instant wake up from suspend

I had these entries before in my /loader/entries/arch.conf but I wanted to do it right. somehow this now doesnt work.

for my audio device I use this

options snd-usb-audio implicit_fb=1

and in the nvidia file there is also a parameter (module?) right after options.

the pciepme one doesnt have that - do I need to put a module there or change something to make it work from modprobe? :shrug:

otherwise everything should be fine, gonna see how it goes with the wake up vram glitches

Last edited by heyimnyl (2024-02-22 19:36:31)

seth · 2024-02-22 19:44:42

Does the filename in /modprobe.d/ matter?

No, aside from telling you what's likely in the file.

I had these entries before in my /loader/entries/arch.conf

Which is where they belong, those are kernel parameters, not module options.
The syntax overlap by systemd-boot if perhaps more confusing than clever…

heyimnyl · 2024-02-22 20:17:56

Which is where they belong, those are kernel parameters, not module options.
The syntax overlap by systemd-boot if perhaps more confusing than clever…

that does it for. marking this thread as solved tyty
e: ok I cant edit the subject. someone else pls

Last edited by heyimnyl (2024-02-22 20:18:41)

seth · 2024-02-22 20:20:17

https://bbs.archlinux.org/edit.php?id=2152290 - you might have to shorten the title a bit.

heyimnyl · 2024-02-23 06:25:27

I might have been too optimistic about this and thought ' ok didn't happen probably fixed '.. but it's still there.

So I took the journal from the wake up when it happened: https://pastebin.com/raw/AtFWcbLS

To fix this I had to close all previous open windows. everything that was somehow graphically present on desktop, be it background or not.
I noticed this when switching to second desktop that there was no glitching, only on the first where old apps still were open.
This is how my desktop looked when logging back in and .. uh, yea it was just flickering and not present at all, upside down idk: https://imgur.com/qJoIrtT - yes, this is how it was displayed to me too.

Not sure if enabling nvidia-resume.service will fix it but I did enable it for now and will see how it goes.
clueless

seth · 2024-02-23 09:28:29

Please post your complete system journal for the boot after the resume from S3

sudo journalctl -b | curl -F 'file=@-' 0x0.st

heyimnyl · 2024-02-23 12:34:18

http://0x0.st/H5V6.txt

that's quite long. I thought only the recent bit after wake up would be enough. Oh well

seth · 2024-02-23 13:28:31

pfff… 9000 lines

The nvidia DPM services run fine (no complaints about missing kernel parameters) - the only indicator for problems is

Feb 23 06:58:16 nyArch plasmashell[24112]: Crash Annotation GraphicsCriticalError: |[0][GFX1-]: GFX: RenderThread detected a device reset in PostUpdate (t=10342.4) [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
Feb 23 13:30:25 nyArch plasmashell[59805]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
Feb 23 13:30:25 nyArch plasmashell[59805]: [GFX1-]: Failed to make render context current during destroying.
Feb 23 13:30:25 nyArch plasmashell[59805]: [GFX1-]: Failed to make render context current during destroying.

And then there's

Feb 23 13:30:25 nyArch kwin_x11[1170]: Xlib:  extension "NV-GLX" missing on display ":0".

which is only at this time, not before (the journal has several S3 cycles)
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General after waking up from the S3

heyimnyl · 2024-02-23 14:12:57

aah, timestamps are in seconds from boot. yes. sure.
I think I have the spot in here, problem was approx 5hours 20min after boot in seconds 19200 seconds .. should be in here.
https://pastebin.com/raw/NbWGuyN5
this is from the .log file, not the .log.old file let me know if entries from that are needed.

e: in hindsight this made very little sense to me so here is the full Xorg.0.log file:
https://pastebin.com/raw/jBJRQNFX

which is only at this time, not before (the journal has several S3 cycles

yes. the glitching happened at 7:20ish log time. right before my post here.

Last edited by heyimnyl (2024-02-23 14:25:58)

seth · 2024-02-23 16:40:02

[    15.375] (II) Initializing extension NV-GLX

is there and kwin_x11 message is at 13:30

The system was sleeping from 06:42:50 to 06:58:15 and 07:40:17 to 13:30:24, you were posting https://bbs.archlinux.org/viewtopic.php … 7#p2152567 at 6:25 UTC, the journal runs on UTC and right before that you've been playing some steam game?

heyimnyl · 2024-02-23 17:14:35

[    15.375] (II) Initializing extension NV-GLX
is there and kwin_x11 message is at 13:30

there was no issue at 13:30 - at least nothing visual to me. system resumed fine.

The system was sleeping from 06:42:50 to 06:58:15 and 07:40:17 to 13:30:24, you were posting https://bbs.archlinux.org/viewtopic.php … 7#p2152567 at 6:25 UTC, the journal runs on UTC and right before that you've been playing some steam game?

the journal runs on utc+1 for me but yes broadly utc zone
the suspend right before the resume that had the glitches - I dont remember having a steam game open. Not 100% positive, I'd love to check but I cant find a way in steam. before the 6:42 one, yes multiple just tested if they run or not and troubleshooting with limiting cores because 32 is too much for some.

Last edited by heyimnyl (2024-02-23 19:49:24)

Arch Linux

#1 2024-02-21 23:12:25

[solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#2 2024-02-22 00:14:29

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#3 2024-02-22 03:10:31

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#4 2024-02-22 10:11:07

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#5 2024-02-22 10:14:05

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#6 2024-02-22 19:36:11

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#7 2024-02-22 19:44:42

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#8 2024-02-22 20:17:56

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#9 2024-02-22 20:20:17

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#10 2024-02-23 06:25:27

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#11 2024-02-23 09:28:29

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#12 2024-02-23 12:34:18

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#13 2024-02-23 13:28:31

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#14 2024-02-23 14:12:57

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#15 2024-02-23 16:40:02

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

#16 2024-02-23 17:14:35

Re: [solved] Flickering/glitching after suspend end x11 kde plasma nvidia

Board footer