gldickens3 wrote:

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:

Hm, I created a script in /usr/lib/pm-utils/sleep.d to call kwin --replace. Why does kwin --replace not work, when the screen is locked?

How can I check if kwin --replace is executed from within my power management script?

I added kwin --replace && echo kwin restarted >> /var/log/messages but I have to admit, I did not see the message in var/log/messages. Because the screen was locked?

pinguin74 wrote:Hm, I created a script in /usr/lib/pm-utils/sleep.d to call kwin --replace. Why does kwin --replace not work, when the screen is locked?

How can I check if kwin --replace is executed from within my power management script?

I added kwin --replace && echo kwin restarted >> /var/log/messages but I have to admit, I did not see the message in var/log/messages. Because the screen was locked?

I assume that you have pm-utils installed? I haven't had much experience or success with pm-utils so I can't help you here.

gldickens3 wrote:

pinguin74 wrote:Hm, I created a script in /usr/lib/pm-utils/sleep.d to call kwin --replace. Why does kwin --replace not work, when the screen is locked?

How can I check if kwin --replace is executed from within my power management script?

I added kwin --replace && echo kwin restarted >> /var/log/messages but I have to admit, I did not see the message in var/log/messages. Because the screen was locked?

I assume that you have pm-utils installed? I haven't had much experience or success with pm-utils so I can't help you here.

Yes, I have pm-utils installed.

What power management system do you use?

What power management system is supposed to be "state of the art" for recent kernels?

pinguin74 wrote:

gldickens3 wrote:Hm, I created a script in /usr/lib/pm-utils/sleep.d to call kwin --replace. Why does kwin --replace not work, when the screen is locked?

This cannot work. That script is called as root (but kwin runs as the logged in user), has no idea on what display your user's KDE session is running and won't find the user's DBUS session bus either.

I don't have any idea how to restart kwin after suspend, I have to admit.
Maybe send it some signal with "killall" (but not SIGTERM or SIGKILL) that would crash it and make it restart automatically.

Code: Select all

killall -SIGSEGV kwin

would work f.e., but you would get a KDE crash dialog as well.
If you don't mind that, it might be a viable work-around until the issue is fixed.
Not nice, but well...

pinguin74 wrote:What power management system is supposed to be "state of the art" for recent kernels?

The kernel has its own power management system.
And nowadays on Linux systems systemd handles the suspend/resume. Currently it calls pm-utils though, if they are installed, if not it directly uses the kernel's interface AFAIK.
systemd has a similar feature for calling suspend/resume hooks, they need to be placed in /usr/lib/systemd/system-sleep/, see also "man systemd-suspend.service".
This is only used if pm-utils is not installed, otherwise pm-utils (/etc/pm/sleep.d and /usr/lib/pm-utils/sleep.d) are used as mentioned.

Note that this only applies to openSUSE 13.1 though. I think on Factory systemd does not use pm-utils at all any more.

Another note regarding pm-utils: A script is only run if it is owned by root (I think) and has to have execute permissions for root. Check the permissions, maybe your script is not run because they are wrong.

I have found a kernel/nVidia driver combo that works *MUCH* better than anything else that I have tried. Its not perfect since it doesn't work 100% of the time. However, so far its worked just over 95% of the time which is far better than the other combos. At the very least, this is the best combo of kernel/nVidia driver that I have tested and, by the way, I have tested a bunch of combos by now. The combo that I am now using is kernel version 3.12 with nVidia driver 337. I have been using this combo for 6 days with 74 resumes and only 3 failures so far. Lets see how this combo holds up over time but I am optimistic that this may be a liveable solution. Also, the rare times that it does fail to resume, then I simply hit <ESC>, enter my password and hit my function key that I programmed as "kwin --replace" and I am back in business.

I was tipped off to try this kernel/nVidia driver combo by EmperorLinux where I originally purchased my Dell Precision M6300. They sell Linux laptops pre-loaded with your distro choice and they do whatever possible to ensure that all of the hardware (video drivers, card readers, wifi, etc.) works right out of the box. So, last week, I called EmperorLinux and asked what combo of kernel/nVidia driver that they were currently installing. They recommended the 3.12 kernel and the 337 nVidia driver and *BAM*, everything immediately started working most everytime... I wish that I had thought about calling them sooner!

FYI,

Gordon

I now found a way that may be a very elegant cure to this issue.

I´m on openSUSE, I hope the following configuration file is available on other distros as well.

Look at /usr/lib/pm-utils/defaults there you can set the power management backend and how the video card is treated at resuming.

I put there these values:

HIBERNATE_RESUME_POST_VIDEO="yes"
SLEEP_MODULE="kernel"

The first value causes to "restart" the video card after resuming. Afterwards you do not need to restart kwin any longer!
The second, SLEEP_MODULE may not be necessary for the video card issue, but I needed it to change to kernel to get proper suspending.

After I changed these values the video card woke up properly now each time after suspend.

But, keep in mind the file /usr/lib/pm-utils/defaults may get overwritten after power management updates, so you may restore your settings there,

To me this seems the most elegant and reliable solution to this issue.

I wonder why they don´t use the values as default, because this is the most reliable way to wake up a video card.

pinguin74 wrote:Look at /usr/lib/pm-utils/defaults there you can set the power management backend and how the video card is treated at resuming.

I put there these values:

HIBERNATE_RESUME_POST_VIDEO="yes"

I have a similar setting in my BIOS...

But, keep in mind the file /usr/lib/pm-utils/defaults may get overwritten after power management updates, so you may restore your settings there,

Right. It will get overwritten, although it's probably unlikely that there still will be an update to pm-utils.
https://en.opensuse.org/SDB:Pm-utils#Configuration says this:

The main configuration file is /usr/lib/pm-utils/defaults. You should not edit this file, since after a package update it might be overwritten with the default settings. Put your config file into /etc/pm/config.d/ instead.

So better create a file in /etc/pm/config.d/ with your settings.

Bear in mind though that this probably will _not_ work on openSUSE 13.2 any more, as pm-utils is not used any more in Factory already AFAIK.

wolfi323 wrote:Bear in mind though that this probably will _not_ work on openSUSE 13.2 any more, as pm-utils is not used any more in Factory already AFAIK.

Oh, what will they use instead? Will there still be a way to set the power management "backend" to use?

systemd supports scripts in /usr/lib/systemd/system-sleep
https://wiki.archlinux.org/index.php/Po ... vice_files

I have not been able to get resume from suspend to work consistently using either the pm-utils scripts at /usr/lib/pm-utils/ or with systemd scripts at /usr/lib/systemd/system-sleep. For example, the following script in /usr/lib/systemd/system-sleep/nVidia.sh does not altogether fix the problem:

Code: Select all

#!/bin/sh
case $1 in
  pre)
        rmmod nvidia
    ;;
  post)
        modprobe nvidia
    ;;
esac

That is, resume from suspend will fail on my laptop 5% to 10% of the time with this script or any of the pm-utils or systemd scripts that I have tried.

Nevertheless, I have found two separate scripts that do appear to fix the problem. Simply assign either of the following scripts to a function key for ease of use with: Configure Desktop > Shortcuts and Gestures > Custom Shortcuts. Then, you will be able to suspend and resume without any problems using the function key that you select.

This script toggles composing off prior to suspend and then back on after resume from suspend with "qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing":

Code: Select all

#!/bin/sh
qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing
/usr/lib64/kde4/libexec/kscreenlocker_greet --immediateLock &
sleep 2
/usr/bin/systemctl suspend
qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing

So, resume from suspend works properly by toggling compositing off prior to suspend and the script then toggles compositing back on after suspend is complete.

This script uses "kwin --replace":

Code: Select all

#!/bin/sh
/usr/lib64/kde4/libexec/kscreenlocker_greet --immediateLock &
sleep 2
/usr/bin/systemctl suspend
kwin --replace

Here, this script simply reloads kwin after resuming from suspend.

I believe that KDE is playing a significant role in this problem and specifically KDE's desktop effects. That is, if I disable compositing/desktop effects prior to suspend then it always resumes properly (so far for the last 3 weeks).

I don't know if this is primarily a kernel bug, an nVidia bug, a KDE bug or a combination thereof. However, most all of the folks that I have seen reporting this problem are running KDE. So, if most all users who are reporting this problem are running KDE and toggling compositing/desktop effects prior to suspend prevents the bug from occurring and "kwin --replace" also fixes it, then I would say that KDE is playing a significant role here.

FYI,

Gordon

I believe that I have finally figured out what is causing this resume from suspend problem. It turns out that the bug is caused by KDE's Magic Lamp effect. See my post on the OpenSUSE forums at:

https://forums.opensuse.org/showthread. ... ost2665598

The KDE bug report is here:

https://bugs.kde.org/show_bug.cgi?id=323686

FYI,

Gordon

I am 100% convinced that the KDE Magic Lamp effect was the culprit causing the resume from suspend problems. I have been running without the Magic Lamp now for 5 days without a single failure resuming from suspend. I am going to continue for a few more days after which I plan to turn the Magic Lamp back on and test the systemd script from bug 323686 that toggles compositing off/on upon suspend and which provides a seamless way to run the Magic Lamp effect and not have any resume from suspend failures with that bug present when using the stock KDE suspend.

Gordon

gldickens3 wrote:I am 100% convinced that the KDE Magic Lamp effect was the culprit causing the resume from suspend problems...

This problem has nothing to do with the Magic Lamp effect or even KDE itself. Most probably, it's related to some recent changes in the kernel and nVidia's not keeping abreast of them. The way it occurs varies from card to card. It has afflicted v340.xx and, as far as I know, it's still present in v343.36.

Tsu Jan wrote:This problem has nothing to do with the Magic Lamp effect or even KDE itself. Most probably, it's related to some recent changes in the kernel and nVidia's not keeping abreast of them. The way it occurs varies from card to card. It has afflicted v340.xx and, as far as I know, it's still present in v343.36.

I concur with your assessment of the problem that this has nothing to do with KDE, I have this problem even when trying to resume from suspend to RAM from console with no KDE running. It appears to be a post 3.11 kernel/Nvidia issue as I had suspend to RAM working on opensuse 13.1 and kernel 3.11.

See here:

https://forums.opensuse.org/showthread. ... re-on-13-2