Guys,
I’m so happy to update that the bug appear to have been fixed on latest kernel version. In my case, I’m uisng 4.17.2-1-ARCH.
It seems that prior to this, there was a bug regarding PCI power management, which causes NVIDIA PCI to not be able to switch power state (wake-up) after resuming from a suspend.
I named the file xrandr-fix.
To use it you can follow these steps:
This is a fix for a very specific instance of this bug: My display does resume correctly on Gnome and other desktops, the issue I am having seems to be specific to the i3wm and resuming while the physical display is turned OFF. So it may or may not solve your problem - but with the many variations of this bug and other similar bugs, it is worth a shot - which is the reason i posted it.
Below is a slightly better version of the script I had posted previously:
#!/path/to/node
const exec = require('child_process').exec;
const parse = require('xrandr-parse');
var xrandr = function(){
this.disconnected = false;
this.interval = setInterval(function() {
exec('xrandr', function(err, stdout){
var output = parse(stdout);
// console.log("xrandr output: \n" + output);
this.connected = output["HDMI-0"].connected;
console.log("Is Disconnected: " + this.disconnected);
if((!this.connected) && this.disconnected){
console.log("Running screen fix");
exec('xrandr --output HDMI-0 --mode 3840x2160', function(err,stdout){console.log(stdout);});
} else if (!this.connected){
this.disconnected = true;
} else {
this.disconnected = false;
}
console.log("Connected: " + this.connected);
}.bind(this));
}.bind(this), 1000);
}
var xrandr_watch = new xrandr();
I have the latest kernel from Arch (linux 4.17.2-1), and can confirm that it does resume properly if the display is ON, it does not if the display is OFF (which is why I created the above script).
All,
I tried to use the 4.17rc7 kernel on my Ubuntu 16 workstation, but I am still experiencing this issue.
I am unable to execute the file and run it in the background. Please tell the correct extension and how to execute.
It does not
If you are unable to execute the file and run it in the background, then you need to either:
chmod +x xrandr-fix
2.Make sure to replace line one with the correct path to your node binary. You can where it is by running
which node
If there is no result returned by the command above, you will need to follow the instructions from your linux distribution on how to install node.
The return from the command above should look something like this:
/usr/bin/node
Although it will differ based on how node is installed.
There is no specifc extension that the filename needs to be. The first line tells the OS what interpreter to use to execute the script.
Can anyone other than ‘BlackSoil’ confirm that the bug is fixed in kernel version 4.17.2-1-ARCH ?
it’s not working for me
I’d like to clarify what actually “worked” for me.
First of all, I don’t actually use the NVIDIA driver in a conventional way – having it to be the primary graphics drivers of my Arch system – instead, I used it with “nvidia-xrun” script:
https://wiki.archlinux.org/index.php/nvidia-xrun
So what is nvidia-xrun? It’s a script to run a separate X server that is using NVIDIA discrete graphics drivers. So the idea is to have 2 X servers running. The first being the primary which renders main window manager, main applications, etc, running on Intel HD. The second being activated only when I need to run some applications that require the power of NVIDIA card.
So what actually “worked” for me? Before kernel 4.17.2-1-ARCH, after a fresh reboot, I can run “nvidia-xrun” fine. I can close it, and re-open it fine as well. However, if I suspend the device, after a resume, I couldn’t run it anymore. It stated that NVIDIA PCIE device can’t change from a certain power state to another, hence unuseable. After kernel 4.17.2-1-ARCH, even after a suspend, “nvidia-xrun” runs fine.
I highly encourage you guys to try the “nvidia-xrun” approach. I don’t like using NVIDIA proprietary software as the main graphics drivers due to several reasons:
Feel free to email/contact me If I can provide further information.
EDIT:
Also, I think it’s worth to mention that in addition to the kernel update, I also updated NVIDIA drivers version to 396.24. For those of you who are Arch users, what I did was a complete system upgrade through sudo pacman -Syu
I had a similar problem as you guys are experiencing. I do not have a GT940mx so I do not know if my work around for my graphics card GTX1060 would work for you. But try to update your nvidia driver and see if it helps.
I am running a Ubuntu 16.04.
I tried upgrading the kernel which didn’t help. In the process ended up with 4.15.13-041513-generic. I honestly do not know if it is a combination of the kernel update or not. But I will mention the step as it seams to help others. I am new to the Linux world and I am using Ubuntu as like the debian flavor. I found uuku to be an easy tool jump from kernel to kernel. To find out which kernel type the following in terminal.
~$ uname -r
4.15.13-041513-generic
If you like to change your kernel google how to install the uuku tool.
I also installed laptop-mode-tools and used lmt-config-gui to test if that would help. lmt-config-gui must be run as root. I tried tweaking with it but I do not think it helps much as long as you are running an old nvida driver or the nouveau driver. Basically ended up just using the hibernate and sleep button to test if the driver update fixed my problem. But like with the kernel I mention it as it was part of my way to finding the solution.
To update my driver I used the guide found here:
I had a little tricky time finding which nvidia unix driver matched mine but what worked for me on this page:
Was to choose the platform for me which is Linux x64 click on the 3xx.xx longest (like playing it safe) and under supported products search for my nvdia card.
Since I like to play it safe I chose the 390. As the blog in how to install latest nvidia drivers in linux says, start by deleting your old drivers:
~$ sudo apt-get purge nvidia*
Setup your graphical drivers PPA and update.
~$ sudo add-apt-repository ppa:graphics-drivers
~$ sudo apt-get update
Install the driver you chose and activate it:
~$ sudo apt-get install nvidia-390
Mine was the 390 but yours may be different.
Reboot your computer. And remember to check if it was activated.
~$ lsmod | grep nvidia
If it doesn’t show any info then maybe something went wrong. Check if nouveau is showing.
I must also mentioned the Software and Update center under thirdparty became my friend after running the graphical drivers PPA.
Hope this helps.
Desktop users please don’t report this issue on this thread. Please update your issue in the desktop thread or start a new thread if needed. We are focusing on ASUS notebooks since most of ASUS notebooks are affected. We are still investigating this issue from SBIOS, ACPI and nvidia driver side to find the root cause. [ Hope you all are using latest SBIOS for your notebooks ].
Just to make it clear I have a notebook. Its the Dell Alienware R15 with GTX 1060 graphic card. But as sanıp points out it’s not an Asus. I have no idea if it will help them. Good luck guys.
It may not be clear but my first post is a step by step explanation of how I fixed my problem with screen going black after/not resuming after sleep/hibernation. I posted it in hopes that it would help others with the same issue.
I am having this issue on kubuntu 18.04 with nvidia-driver-396 on an ASUS zenbook ux310uq.
Using nouveau until this gets fixed.
One stupid question. Can I switch the nvidia card on and off and run it by passing the DRI_PRIME command using driver-396 (like Nouveau)?
Same problem on Asus-X510UQ GT 940MX.
asanali@asanali-X510UQ:~$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA UNIX x86_64 Kernel Module 390.77 Tue Jul 10 18:28:52 PDT 2018
GCC version: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
asanali@asanali-X510UQ:~$ lsb_release -a
No LSB modules are available.
Distributor ID: elementary
Description: elementary OS 0.4.1 Loki
Release: 0.4.1
Codename: loki
asanali@asanali-X510UQ:~$ uname -r
4.13.0-32-generic
I use Elementary OS but on Ubuntu 18.04 i have same isssue. And Elementary based on Ubuntu 16.04 LTS.Can someone help please?
Hi Users,
We are still investigating this issue. Initial investigation shows some SBIOS related issue.
I think you all are using PRIME with nvidia and modeset driver. Can you please attached nvidia bug report on both cases where you see an issue with nvidia driver and in other cases where you have not seen this issue with the nouveau driver. Make sure you all have latest sbios. It would be good to test with latest kernel and distros too. Make sure to report the issue to your notebook vendor and distro provider because there are many things depend for the root cause of this issue like sbios/driver/acpi etc.
Some users said nouveau driver working fine for suspend/resume.
Is nouveau configured in prime config/mode for the cases mentioned in below? :
Sleep-Resume works with no problems with nouveau. It works fine withnvidia-prime setting (in Ubuntu/Mint) choosing Intel graphics (power saving mode).
https://devtalk.nvidia.com/default/topic/1017185/linux/problem-with-resume-from-suspend-ubuntu-16-04-gt-940mx-/post/5207065/#5207065
To rule out a generalacpi bug, using nouveau would be useful. If suspend/resume works while using nouveau and the nvidia gpu can actually be used after resume, a driver bug is likely.
I am having this issue onkubuntu 18.04 with nvidia-driver-396 on an ASUS zenbook ux310uq.
Using nouveau until this gets fixed.
https://devtalk.nvidia.com/default/topic/1017185/linux/problem-with-resume-from-suspend-ubuntu-16-04-gt-940mx-/post/5271609/#5271609
So I do not seem to be facing that issue. Also nouveau can suspend/resume just fine. The issue only happens when using the official nvidia driver.
https://devtalk.nvidia.com/default/topic/1028058/linux/940mx-black-screen-and-100-xorg-cpu-usage-on-system-resume/post/5229806/#5229806
Notebook : Asus R558U (930MX)
Prime on : It works fine with nvidia-prime setting (in Ubuntu/Mint) choosing Intel graphics (power saving mode).
H all,
I am facing the same problem. I had thought my issue was this related to this forum - https://devtalk.nvidia.com/default/topic/962231/linux/resume-from-suspend-freezes-system-gtx-970-arch-linux-kernel-4-4-4-7-nvidia-370-/1. I had made posts there, and then sandipt had said solution is on the way, but 381 came, and I still have the same problem.
Now I’m sure I am facing the same problem as this particular thread talks about as -
From this much it is clear that this is an nvidia issue and not something else entirely.
Hi Sandipt,
Please look into this matter asap, and reply whatever diagnostics you need. I had given syslogs before in the other thread. I’m including it below as well. Also included is the nvidia-bug-report. (Also included is a video taken in June when I was trying with Kubuntu, I had posted this video in the other thread as per your suggestion).
I’m hoping to resolve this issue which is affecting me since I bought this laptop 6 months back. I am not expecting replies 2-3 days spaced which keep asking to try out minor things. That is not how support works. I am also an engineer and I’ve worked support too. Take this seriously, it is clear that so far the nvidia support for Linux is pathetic. To say the least.
Hoping to get something done.
Jones
Link - https://drive.google.com/open?id=0B3aF7WUKvMO4TE5fVlFobXg3RzA
@generix
I am currently running 18.04, I am willing to try and run the nouveau drivers, but it seems like I only have an option to uninstall the nvidia driver (which should default to nouveau) and use the Intel one (instead), or use the nvidia one with an option of using the prime-select command to switch to the Intel driver. Do you know how to actually make nouveau driver work?
a quick summery of what I have tried.
I also tried your list of steps and I cannot seem to kill the display manager in a way that I drop down to just a bash console, I am not sure if that is because things have changed, or if there is a problem with the instructions, but stopping display-manager does not seem to kill GNOME.
Attachments
I am having this issue on kubuntu 18.04 with nvidia-driver-396 on an ASUS zenbook ux310uq.
Using nouveau until this gets fixed.
One stupid question. Can I switch the nvidia card on and off and run it by passing the DRI_PRIME command using driver-396 (like Nouveau)?
Hi,
On GeForce 940MX found embedded in Asus X705UQ, the system appears to hang during resume after S3 suspend. Testing with driver version 387.34.
At this point the screen is black, but the computer is responsive over ssh.
There are no error messages shown in dmesg. Xorg is using 100% CPU. Backtrace at this point is:
#0 0x00007ff9d6029262 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#1 0x00007ff9d602ddf9 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#2 0x00007ff9d602d389 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#3 0x00007ff9d5fc2b21 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#4 0x00007ff9d5ffe230 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#5 0x00007ff9d5fcdba1 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#6 0x00007ff9d6536fd1 in ?? () from /usr/lib64/xorg/modules/drivers/nvidia_drv.so
#7 0x000000000265a070 in ?? ()
#8 0x0000000001e899f0 in ?? ()
#9 0x000000000272cdd0 in ?? ()
#10 0x000000000047f80e in CMapEnterVT ()
#11 0x000000000048a98c in xf86XVEnterVT ()
#12 0x0000000000477dd0 in xf86VTEnter ()
#13 0x000000000049cb98 in systemd_logind_vtenter ()
#14 0x000000000049ceb5 in message_filter ()
#15 0x00007ff9de1201ad in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#16 0x00007ff9de1205c8 in _dbus_connection_read_write_dispatch () from /lib64/libdbus-1.so.3
#17 0x0000000000496981 in socket_handler ()
#18 0x000000000059df41 in ospoll_wait ()
#19 0x0000000000596f9b in WaitForSomething ()
#20 0x0000000000435603 in Dispatch ()
#21 0x00000000004398a0 in dix_main ()
nvidia-bug-report output: nvidia-bug-report Asus X705UQ when "hung" during S3 resume · GitHub
(this was captured over ssh while the system was in this hung state)
Interestingly if I VT switch away from X before S3 suspend, I can suspend from there, and it will also resume fine to that state. However upon then changing VT back to X, the hang state occurs and I can’t recover.
Please let me know how I can help further.
Hi all, Any update on above-requested information? Many users said no issue with Nouveau driver with the prime setup.
Just a note – With open source nouveau driver (configured in Prime mode), even if system resumes fine, the applications will not run fine. Can you please test and confirm from your side?
Everything works ok with me wrt Nouveau. I use it on a per application basis, and have not noted any increase in the crash frequency and I can launch applications after resume.
I tried kernel 4.17 and the nvidia driver 396. No change
Notebook : ASUS zenbook ux310uq
Sorry but what makes this a laptop specific thread? The problem is also present with desktops. I reported earlier that kernel 4.17 fixed the problem for me (but introduced different issues), this is however no longer the case. I am now on 4.17.11 and nvidia 396.45 and the behaviour is as reported here many times before. As an IT professional it boggles my mind that this issue is taking so long to get resolved. After a resume the system is not frozen, it just does not display the desktop. But you can access it via e.g. ssh so it should be simple to examine relevant processes like the X server with a process trace tool, attach a debugger or whatever to find out about it’s state and why it is not displaying.
Hi mabawsa, Can I get nvidia bug report of your system in both the cases - issue and no-issue after system resume?
tjknigge, as an IT professional you should know that the same symptom does not necessarily has to have the same cause. This thread is about an acpi/driver level problem hitting a specific kind of laptop hardware.
According to your description,
[url]https://devtalk.nvidia.com/default/topic/1017185/linux/problem-with-resume-from-suspend-ubuntu-16-04-gt-940mx-/post/5266292/#5266292[/url]
your problem is ultimately absolutely not connected to this issue discussed here in any way apart from leading to the same symptom.
There are numerous causes for suspend/resume failures.