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.
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…”
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.
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.
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.