Reply to topic

Tip: Nvidia binary driver and corrupt screen after resume

User avatar pinguin74
Registered Member
Posts
48
Karma
0
OS
Hello,

this is not a question, but a useful hint for people who may have experienced the same trouble.

I use the binary Nvidia drivers and when I resumed my machine from suspend to RAM my screen was corrupt. I always needed to kill the X server with ctrl+alt+backspace to get a working log in screen again.

This happened even with the latest drivers 340.x.

I now learned you have to tell the nvidia kernel module to register to the ACPI subsystem.

This is done with an option when you load the module: modprobe nvidia NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1

To automatically use this option, create a file named /etc/modprobe.d/50-nvidia.conf with the following content:

options nvidia NVreg_RegisterForACPIEvents=1 NVreg_EnableMSI=1

Restart your machine and now you can safely suspend and resume without screen corruption. In my case in 9 out of 10 suspend operations this fixes the screen corruption issue. Very rarely it still happens, but much less often than without this options.

EDIT 13-Jun-2014:
1. Ubuntu may not be affected, AFAIK they patch the Nvidia packages they offer for their distro
2. I found out, enabling message signalling interrupt with NVreg_EnableMSI=1 is safe.
3. I can only recommend to also use message signalling interrupt with the sound processor. My sound experience is much smoother, my bluetooth headset connects much faster to Pulseaudio. I use modprobe snd-hda-intel enable_msi=1 to enable it for my hardware.

Check with cat /proc/interrupts if MSI is enabled for your device:
46: 313 320 PCI-MSI-edge snd_hda_intel
47: 0 0 PCI-MSI-edge snd_hda_intel
49: 15392 79096 PCI-MSI-edge nvidia


EDIT: This issue still persists. Maybe the tips from above may help for some time. But in some cases screen corruption returns. Hopefully it gets fixed some time soon.

Last edited by pinguin74 on Fri Jul 25, 2014 8:03 pm, edited 1 time in total.
vootey
Registered Member
Posts
44
Karma
0
OS
I suffered from the same problem. Your suggestion seems to work. Thanks!
May I ask where/how you've learned this?

As a sidenote, an easier workaround would've been to de- and activate kwin compositing (e.g. with alt-shift-f12) instead of killing X.
vootey
Registered Member
Posts
44
Karma
0
OS
Okay, I have to withdraw my previous statement: after some more sleeps/wakeups I see that the situation hasn't improved much after all, i.e. still a lot of corrupted screens.
User avatar pinguin74
Registered Member
Posts
48
Karma
0
OS
vootey wrote:Okay, I have to withdraw my previous statement: after some more sleeps/wakeups I see that the situation hasn't improved much after all, i.e. still a lot of corrupted screens.


I have to agree. This issue is not solved yet.

I still have screen corruption with driver 340.24 and Linux kernel 3.15.3.

I think we have to wait for some more kernel and driver updates. The whole thing is a combined kernel / Nvidia driver issue.

Hopefully they get it fixed not too far away.....
User avatar scummos
KDE Developer
Posts
775
Karma
5
OS
I have this problem as well with an NVS3100M, just to note that it's not an isolated issue.


User avatar gldickens3
Registered Member
Posts
20
Karma
0
OS
There is a thread about this issue on the OpenSUSE forums at:

https://forums.opensuse.org/showthread. ... end-to-RAM

I am running OpenSUSE 13.1 with KDE 4.13.3 and I have also been experiencing this failure to resume after suspend problem. I am currently running the most recent stable kernel-desktop version 3.15.6-2.1.gedc5ddf and the most recent nVidia driver version 340.24 and experience this failure about 10% of the time. Also, I experienced much more frequent failures up to 50% of the time with the stock OpenSUSE 13.1 kernels and nvidia drivers which are earlier versions of each. So, the problem appears to be less frequent with the most recent kernel and nvidia driver combo than with the earlier versions although the bug is obviously still not fixed. I agree with pinguin74 that this is probably a kernel/nVidia driver issue and I hope that it gets fixed soon.

FYI,

Gordon
bloch
Registered Member
Posts
8
Karma
0
I found a more "reliable" way to reproduce this problem:

1. Change to another vt, e.g. by Ctrl+F2
2. Start another X-Server there, e.g. by "xinit `which startxfce4` -- :1 vt2"
3. Change back to be X-Server where Kwin runs, e.g. with Ctrl+F1: Corrupt Screen.

Maybe this is useful to troubleshoot....
bloch
Registered Member
Posts
8
Karma
0
Ah, and by the way:
Restarting Kwin is enough.
Just assign "kwin --replace" to a nice keyboard shortcut.
bloch
Registered Member
Posts
8
Karma
0
And another note:
It doesn't seem to happen with an older kernel, with 3.14.15-1-lts (on arch) everything is fine.
User avatar scummos
KDE Developer
Posts
775
Karma
5
OS
Yes, the issue appeared quite recently.
I also get corrupted fonts sometimes in some applications.


User avatar gldickens3
Registered Member
Posts
20
Karma
0
OS
bloch wrote:Ah, and by the way:
Restarting Kwin is enough.
Just assign "kwin --replace" to a nice keyboard shortcut.


I can confirm that "kwin --replace" will successfully fix the corrupted screen that occurs after resume from sleep-suspend.
FALaholic
Registered Member
Posts
1
Karma
0
I came here looking for a solution to this problem hoping to find a workaround. I was very hopeful when I found the "kwin --replace" code, however I get a fatal error when I attempt it.

Admittedly I am a newbie to Linux, but not systems/programming. Any other news or suggestions?

This is a dual boot system with Linux Mint 17 KDE and Windows 7.

I did notice that while attempting to troubleshoot this if I entered the edit mode at the boot loader>let system boot>entered sleep>it would resume fine without corruption.
luebking
Registered Member
Posts
1965
Karma
12
what "fatal error"?

you need to ensure you're running it
- as the correct useer
- under correct environment (DISPLAY and DBUS_SESSION_BUS_ADDRESS, at least)
User avatar pinguin74
Registered Member
Posts
48
Karma
0
OS
Idea for workaround:

I think currently the best way for an workaround is to call kwin --replace from a script that executes after resume.
But I think kwin --replace should be run as the user who is logged in to KDE currently.
User avatar gldickens3
Registered Member
Posts
20
Karma
0
OS
pinguin74 wrote:Idea for workaround:

I think currently the best way for an workaround is to call kwin --replace from a script that executes after resume.
But I think kwin --replace should be run as the user who is logged in to KDE currently.


That will work fine unless you lock your screen upon suspend. In that case, then you need to unlock your screen with your password before you issue the kwin --replace command. Here is what I do when resume fails with a locked screen:

1) Press ESC - This starts the login dialog, although you can't see it since the screen is garbled.
2) Enter your password - You can't see what you are doing but you can successfully login anyway.
3) Press the keyboard shortcut that you have setup to issue "kwin --replace".

To setup the keyboard shortcut, proceed as follows:

1) Go to settings > Shortcuts and Gestures > Custom Shortcuts > Edit > New > Global Shortcut > Command/URL
2) Name the shortcut "Restart Kwin".
3) Set the Trigger to an available keyboard shortcut. I use Meta+F2 but it can be anything that's available.
4) Set the Action Command/URL to: "kwin --replace".

With this setup, whenever resume from suspend fails then you have an easy way to get your display back working again. Also, if you do not lock your screen upon suspend then you only need to press the keyboard shortcut that you have setup to issue "kwin --replace" since you don't need to enter a password.

Gordon

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], einar, Exabot [Bot], Google [Bot], Majestic-12 [Bot], TheraHedwig, Wenzel, Yahoo [Bot]