(SOLVED) resume from suspend not working with 980 Ti, drivers 352 - 370, kernels 3.16 - 4.4

True. However I was thinking in terms of a condensed point-by-point list which could be conveniently accessed off-line if need be. I habitually type up such how-tos for my own sake as a future time saver and for the possible benefit of others. But then I am only in a position to determine how to best prioritize my time.

Hopefully a future OS / kernel / linux-firmware update will permanently resolve the resume from suspend issue which currently bedevils DDR4-era Intel hardware.

No solution posted here helped my PC :(

Now installed CUDA 8.0

It has passed many suspend / resume cycles without problems.

There has been a few occasional resume crashes, but with different symptoms than the one described in this thread, and their frequency is more weekly, which is a lot better.

Not a single resume crash here since mid november.

But still without CUDA ;-)

Please test with 378.09 BETA driver. I think issue is fixed for legacy boot [OS installed non-uefi mode]. After resume Xid 62 and Xid 56 is different issue on UEFI OS.

One trouble-shooting approach which wasn’t tried in this thread was to manually change the Z170M-PLUS’ default PCIe x16 Gen 3 link speed down to Gen 2:

“Expansion Slots: 1 x PCI Express x16 slot, running at x16 (The PCI Express x16 slot conforms to PCI Express 2.0 standard)”

GIGABYTE - Motherboard - Socket 775 - GA-EP45-UD3LR (rev. 1.0)
http://www.gigabyte.us/products/product-page.aspx?pid=2951&kw=GA-EP45-UD3LR1.0#sp

Excerpts from the Z170M-PLUS’ manual in English.

Page 66 of 89: “PCI-E Native Power Management [Disabled]” <-- This is worth looking at too for GNU/Linux users.

Page 67 of 89: “PCIEx16_1 Link Speed [Auto]
Allows you to configure the PCIEx16 speed for slot 1. Configuration options: [Auto]
[Gen1] [Gen2] [Gen3]”

E10768__Z170M-PLUS_UM_WEB.pdf
http://dlcdnet.asus.com/pub/ASUS/mb/LGA1151/Z170M-PLUS/E10768__Z170M-PLUS_UM_WEB.pdf?_ga=1.258564300.73628687.1481636288

Z170M-PLUS | Motherboards | ASUS USA
https://www.asus.com/us/Motherboards/Z170M-PLUS/HelpDesk_Manual/

And since reducing PCIe x16 Gen 3 to Gen 2 is about the same as reducing PCIe x16 Gen 3 down to PCIe x8 Gen 3…

“…With a single Titan X (edit: Pascal), there was little benefit (less than 2%) in most cases to running the card at x16 instead of x8. In fact, with a 1080p display, using PCI-E 3.0 x8 was actually about 9% faster than x16! This result is odd and not what we expected, but we ran the benchmark multiple times and got the same result over and over…”

September 8, 2016
Titan X Performance: PCI-E 3.0 x8 vs x16 - Puget Custom Computers
https://www.pugetsystems.com/labs/articles/Titan-X-Performance-PCI-E-3-0-x8-vs-x16-851/

Related to the CUDA aspect of this thread (check out the comments too):

August 29, 2016
Install Ubuntu 16.04 or 14.04 and CUDA 8 and 7.5 for NVIDIA Pascal GPU - Puget Custom Computers
https://www.pugetsystems.com/labs/hpc/Install-Ubuntu-16-04-or-14-04-and-CUDA-8-and-7-5-for-NVIDIA-Pascal-GPU-825/

So I’ve joined just to say a big “Thank you!” to everyone who has contributed here, especially Naanoo whose answer and links saved my system from the trash heap and my faith in Linux which was wavering severely.
I upgraded my video card from a GTX 960 Strix (2Gb) to a GTX 1060 Strix (6Gb) (on a Gigabyte GA-990FXA-UD3 mobo, AMD FX 8350 @ 4.2Ghz, 16Gig DDR3 @ 2133mHz, Samsung Evo 960 ssd and 3Gig Barracuda HD).
What was working perfectly (Mint 17.3 Kde) turned to ***t, not only would it not sleep, but it no longer recognised the USB ports.
The usbs were related to an IOMMU setting in the bios and blacklisting that fixed the problem.
Blacklisting the nouveau driver in Grub, and adding a “disable-nouveau.conf” file to etc/modprobe.d/ fixed the sleep issue for me.
I discovered in the modprobe.d folder that the nvidia installer had attempted to blacklist nouveau by creating its own blacklist.conf file. This blacklisting attempt failed obviously. Perhaps because no entry was added to Grub?
Its obvious that the whole sleep issue is related to the nouveau driver not being effectively removed from the scene when the nVidia driver is installed.
By the way Im using nVidia 378 and a 3 series kernel installed by default when i reinstalled Mint 17.3 Kde.
Cheers guys, thanks for the guidance… there must be heaps of people out there suffering with this.

This is the first GTX 1060 GNU/Linux-related resume-from-suspend success story I’ve seen since joining this forum last October in a bid to determine if a GTX 1070 FE was a practical upgrade over what I’m using now.

It’s too bad that so much jiggery-pokery is still required to get a GTX 1060 to resume-from-suspend as well as a it-just-works STRIX-GTX960-DC2OC-4GD5 does.

Absolutely. A newbie would be destroyed by this sort of crap, give up and never touch Linux again. I’ve been running Linux as my OS of choice for 15 years now, and i can tell you this issue almost pushed me back to the dark side.
It shouldnt happen. Saved by the Forums!

@Careless: Do you boot your system in EFI mode? My understanding is that there is still an unresolved issue with the Nvidia drivers that causes lockups and corruption after waking from suspend if your system is booted in EFI mode. I continue to have issues with suspend on my laptop, which boots in EFI (rather than “legacy BIOS”) mode with a GTX 1060.

No, not using EFI mode… this machine dual boots with Windows 7 and is most definitely in “legacy bios” mode. Sorry that doesnt help.

This bug has been happening for over two years now.

Resume is broken with nvidea drivers. And that is not good enough.

Why has it not been fixed yet.

Just upgraded from a GT 730 to a GT 1030 and now my system does not resume from standby. Well, it does strictly speaking, I can control it remotely via SSH, but the screen is stuck on what looks like the system startup screen in VGA console mode except that the bottom 95% of the screen is completely truncated and black. Nothing short of a reboot seems to help it to recover.

I had absolutely no suspend / resume problems with the GT 730 card.

@MadMartian, did you ever come up with a workaround?
This is close to what I am seeing. My GT 730 always resumed from hibernate correctly. 1050Ti doesn’t always resume correctly if Xorg is running when I hibernated. I got some tips from Systemd and Linux contributors but nothing helped. SSH to kill Xorg is possible to normally rebooting is faster.
The board manufacturer said my PSU is well above the required minimum for my system (including the nvidia card) so it’s not an electrical issue.

Anyone who is using an AMD FX Series (Vishera) CPU may wish to check out the ‘FX-8370, amd64-microcode_3.20160316.3_amd64’ links in my signature.

I’ve found no work-around other than keeping the machine powered-on 24/7. Nouveau is blacklisted in /etc/modprobe.d/ and the only other thing I can think of is GRUB_CMDLINE_LINUX_DEFAULT=“splash quiet vga=0” might be problematic but I doubt it.

Alright, thank you for checking.

What exactly did you do? Is there other people who got this working like this?

Just wanted to post this as a solution for everyone to enjoy: https://devtalk.nvidia.com/default/topic/1070352/linux/solution-for-nvidia-sleep-wake-issue/post/5422587/#5422587

1 Like