resume from suspend freezes system (GTX 970, Arch Linux, Kernel 4.4/4.7, NVIDIA 370)

Graphics / Linux Linux
81

Frustrating.

I had the same problem, and I spent many hours investigating and fixing this issue.

It was completely trivial for me to reproduce. I had this problem with Ubuntu 14.04, and upgrading to Ubuntu 16.04 still persisted the issue.

My setup:
Nvidia GTX 950
Dual monitor: DVI and DisplayPort
Console: tried both with vga and without vga.
No nouveau drivers anywhere.
Nvidia-367
x86_64 Linux

I force the ‘ConnectedMonitor’ Option in X, because I don’t want my desktop resizing when I switch my KVM. The suspend-resume problems are not impacted by this. I had suspend-resume issues even before the ConnectedMonitor Option.

I tried all tricks suggested on the internet: forcing ‘chvt 1; sleep 3’ before suspend, to avoid Kerneloops at suspend.

I got to the point where suspend worked reliably every time. But then resume failed reliably. I’m seeing the same issues as many, many other people here: displays turn on but never show anything. The X-windows process takes 100% CPU, computer is completely unresponsive and you need to ssh into it.

Entirely disappointing. With Nvidia’s driver source (which I don’t have) and the Linux kernel source (which I do have), someone could debug this rather easily. The profusion of these bugreports suggests that there is an easy repro if someone would take the effort.

I appreciate that Sandip (and others?) at Nvidia are investigating this, but this is a productivity killer. For better or worse, many of us trust Nvidia on our work setup, and this is erodes that trust.

The problem also appears to be a recent introduction into the Nvidia drivers. I have owned the GTX950 for a while, and I only started noticing suspend-resume issues recently.

I do have an outcome here that might work for some people (depending on how new your display card is). I’ve reverted to NVIDIA-Linux-x86_64-352.79, and this fixes all suspend-resume problems for me. I got lucky: I have a relatively old graphics card. Not everyone is as lucky as me.

A market that pays top dollar for the latest hardware expects reasonable support.

I agree with djbuldog’s sentiment. I will be cautious before buying another Nvidia card. Life is too short to deal with nonsense like this. I have my own bugs to find and fix.

82

And I spoke too soon. Resuming from suspend is still broken after reverting to 352.

So strange, given that suspend has worked with this card in the past. I wonder if some firmware has been updated on the card, since the problem persists even with older versions of the drivers.

As a sorry consequence, X startup now takes many seconds after you see the Nvidia logo. If you revert to generic (VESA?) mode, then X startup is as quick as before.

Extremely dissatisfying. I either have to keep the machine on and burn a lot of power, or turn off the machine every night.

Nvidia folks, please let us know how we can help you debug this issue while we still have these cards in our desktop.

83

As it turns out, pm-hibernate works beautifully, even though suspend doesn’t.

Strange and weird.

Anyway, I’ve lost interest in debugging this any further. The AMD Radeon RX 480 looks pretty neat, and it has reasonable graphics support in Linux. I’m heading there.

84

Same problem, crashes on resume about 70% of the time. My configuration:

OS: Ubuntu 16.04
Kernel: 4.4.0-53-generic
NVIDIA driver: 375.26
NVIDIA card: GeForce GTX 970M
Monitors: Clevo SDC Panel (by DP)

Some bug reports:
http://www.patrickfasano.com/upload/nvidia-bug-report_2016-12-14.log.gz
http://www.patrickfasano.com/upload/nvidia-bug-report_2016-12-15.log.gz

85

Joining the party.
Swapped a gtx750 ti for a gtx 1060 and resume seems to be broken for me too.
I’m sepaking about resuming from disk.
First resume is usually good.
Subsequent are likely to fail if i stress the card before sleep (eg: play a game).
What happens is that the kernel log is filled with the following:

[ 1932.114647] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000474 00010073 00000007 00000000
[ 1932.114816] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 0000045c 00010058 00000007 00000000
[ 1932.232573] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 0000045c 00010058 00000007 00000000
[ 1932.301236] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000001 000000a4 00010053 00000007 00000000
[ 1932.301442] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000001 000000a4 00010053 00000007 00000000
[ 1962.903683] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000474 00010073 00000007 00000000
[ 1962.903838] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 0000045c 0001005a 00000007 00000000

…really flooded

Then the system begins to be unresponsive (even the mouse is jerky).
But if i script to restart the Xorg server at resume time, it will work.

86

Hello,
On a Gigabyte gtx970 and ArchLinux, I had no issue before drivers 375.20 (and I own this card for 1 year), but since, resuming from suspend always fails.
It works if I jump on a tty where no Xorg is running, but when I return on xorg, I get a complete video freeze, and this error from the kernel:

kernel: BUG: unable to handle kernel paging request at ffff8815ea5c0790
kernel: IP: [<ffffffffa0183140>] _nv007872rm+0x620/0x780 [nvidia]
kernel: PGD 30e3067 PUD 0 
kernel: Oops: 0000 [#1] PREEMPT SMP
kernel: Modules linked in: af_packet xt_pkttype msr nct6775 hwmon_vid sunrpc nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 intel_rapl i
kernel:  r8169 i2c_algo_bit i2c_smbus lpc_ich snd_timer mii snd soundcore xt_LOG shpchp thermal fan rtc_cmos fjes battery wmi video tpm_infineon button tpm_tis tpm_tis_core tpm xt_
kernel: CPU: 0 PID: 672 Comm: irq/30-nvidia Tainted: P           O    4.8.13-1-lqx #1
kernel: Hardware name: ASUS All Series/Z87-A, BIOS 2005 06/03/2014
kernel: task: ffff88022414e600 task.stack: ffff880214e80000
kernel: RIP: 0010:[<ffffffffa0183140>]  [<ffffffffa0183140>] _nv007872rm+0x620/0x780 [nvidia]
kernel: RSP: 0000:ffff880214e83c78  EFLAGS: 00010246
kernel: RAX: 00000004fffffffb RBX: ffff880212c84008 RCX: ffff880214f4de50
kernel: RDX: 00000000ffffffff RSI: 0000000000000001 RDI: ffff880212c84008
kernel: RBP: ffff880214f4ddf0 R08: 0000000000000000 R09: ffff880214f4de48
kernel: R10: 0000000000000004 R11: 0000000000000000 R12: 00000000ffffffff
kernel: R13: ffff880214f86010 R14: ffff8815ea5c078c R15: 0000000000000000
kernel: FS:  0000000000000000(0000) GS:ffff88022ec00000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: ffff8815ea5c0790 CR3: 0000000002e06000 CR4: 00000000001406f0
kernel: Stack:
kernel:  0000000000000000 ffff880212c84008 0000000000000006 ffff880214c0c008
kernel:  0000000000001201 ffffffffa01ccd1e ffff880214f4ded8 ffff880212c84008
kernel:  ffff880214c0c008 0000000000000000 00000000ffffffff ffffffffa01ce842
kernel: Call Trace:
kernel:  [<ffffffffa01ccd1e>] ? _nv007285rm+0x1ee/0x11b0 [nvidia]
kernel:  [<ffffffffa01ce842>] ? _nv007289rm+0x3a2/0x410 [nvidia]
kernel:  [<ffffffffa0203b0f>] ? _nv007741rm+0x22f/0x2c0 [nvidia]
kernel:  [<ffffffffa03a7dfe>] ? _nv003149rm+0x19e/0x280 [nvidia]
kernel:  [<ffffffffa039fbd9>] ? _nv015587rm+0x69/0x90 [nvidia]
kernel:  [<ffffffffa05c941f>] ? _nv000809rm+0xdf/0x120 [nvidia]
kernel:  [<ffffffffa05ce8c3>] ? rm_isr_bh+0x23/0x70 [nvidia]
kernel:  [<ffffffffa0020c36>] ? nvidia_isr_kthread_bh+0x36/0x60 [nvidia]
kernel:  [<ffffffff810d3a38>] ? irq_thread_fn+0x18/0x100
kernel:  [<ffffffff810d2bbf>] ? irq_thread+0x12f/0x310
kernel:  [<ffffffff810d3a20>] ? free_irq+0x90/0x90
kernel:  [<ffffffff810d29c0>] ? irq_forced_thread_fn+0x60/0x60
kernel:  [<ffffffff810036d2>] ? syscall_slow_exit_work+0x122/0x160
kernel:  [<ffffffff810d2a90>] ? irq_thread_dtor+0xd0/0xd0
kernel:  [<ffffffff810a6f1a>] ? kthread+0x10a/0x120
kernel:  [<ffffffff818c519f>] ? ret_from_fork+0x1f/0x40
kernel:  [<ffffffff810a6e10>] ? kthread_worker_fn+0x160/0x160
kernel: Code: 5c 00 0f 85 09 fc ff ff 48 8b 55 48 44 89 e0 45 31 c0 48 8d 04 80 48 8d 4d 60 8b 75 2c 48 89 df 4c 8d b4 82 a0 07 00 00 44 89 e2 <45> 8b 6e 04 ff 93 a0 0d 00 00 48 8b
kernel: RIP  [<ffffffffa0183140>] _nv007872rm+0x620/0x780 [nvidia]
kernel:  RSP <ffff880214e83c78>
kernel: CR2: ffff8815ea5c0790
kernel: ---[ end trace f693ef9320ca2390 ]---
kernel: nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000046
kernel: PGD 0 
kernel: Oops: 0000 [#2] PREEMPT SMP
kernel: Modules linked in: af_packet xt_pkttype msr nct6775 hwmon_vid sunrpc nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 intel_rapl i
kernel:  r8169 i2c_algo_bit i2c_smbus lpc_ich snd_timer mii snd soundcore xt_LOG shpchp thermal fan rtc_cmos fjes battery wmi video tpm_infineon button tpm_tis tpm_tis_core tpm xt_
kernel: CPU: 0 PID: 672 Comm: irq/30-nvidia Tainted: P      D    O    4.8.13-1-lqx #1
kernel: Hardware name: ASUS All Series/Z87-A, BIOS 2005 06/03/2014
kernel: task: ffff88022414e600 task.stack: ffff880214e80000
kernel: RIP: 0010:[<ffffffff810b81e6>]  [<ffffffff810b81e6>] __wake_up_locked+0x16/0x70
kernel: RSP: 0000:ffff880214e83e80  EFLAGS: 00010002
kernel: RAX: 0000000000000282 RBX: ffff880214e83f18 RCX: 000000010010000c
kernel: RDX: 0000000000000046 RSI: 0000000000000003 RDI: ffff880214e83f18
kernel: RBP: ffff880214e83f10 R08: 0000000000000001 R09: ffffffff811328b8
kernel: R10: ffffea000861bb00 R11: 0000000000000000 R12: ffff880214e83f20
kernel: R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000046
kernel: FS:  0000000000000000(0000) GS:ffff88022ec00000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000046 CR3: 0000000002e06000 CR4: 00000000001406f0
kernel: Stack:
kernel:  ffff880214e83f18 ffff880214e83f10 0000000000000282 0000000000000001
kernel:  ffff8815ea5c0790 ffffffff810b8bfc ffff88022414ec28 ffff88022414e600
kernel:  ffff880214e83b01 ffffffff8107d863 ffff88022414e600 0000000000000000
kernel: Call Trace:
kernel:  [<ffffffff810b8bfc>] ? complete+0x2c/0x40
kernel:  [<ffffffff8107d863>] ? mm_release+0xa3/0x120
kernel:  [<ffffffff81084857>] ? do_exit+0x137/0xb40
kernel:  [<ffffffff818c7377>] ? rewind_stack_do_exit+0x17/0x20
kernel:  [<ffffffff810a6e10>] ? kthread_worker_fn+0x160/0x160
kernel: Code: ca 5b 5d 41 5c 41 5d 41 5e c3 90 66 2e 0f 1f 84 00 00 00 00 00 41 56 41 89 d6 41 55 41 89 f5 41 54 4c 8d 67 08 55 53 48 8b 57 08 <48> 8b 32 49 39 d4 74 3a 48 8d 42 e8
kernel: RIP  [<ffffffff810b81e6>] __wake_up_locked+0x16/0x70
kernel:  RSP <ffff880214e83e80>
kernel: CR2: 0000000000000046
kernel: ---[ end trace f693ef9320ca2391 ]---
kernel: Fixing recursive fault but reboot is needed!
kernel: BUG: scheduling while atomic: irq/30-nvidia/672/0x00000003
kernel: Modules linked in: af_packet xt_pkttype msr nct6775 hwmon_vid sunrpc nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 intel_rapl i
kernel:  r8169 i2c_algo_bit i2c_smbus lpc_ich snd_timer mii snd soundcore xt_LOG shpchp thermal fan rtc_cmos fjes battery wmi video tpm_infineon button tpm_tis tpm_tis_core tpm xt_
kernel: Preemption disabled at:[<          (null)>]           (null)
kernel: 
kernel: CPU: 0 PID: 672 Comm: irq/30-nvidia Tainted: P      D    O    4.8.13-1-lqx #1
kernel: Hardware name: ASUS All Series/Z87-A, BIOS 2005 06/03/2014
kernel:  0000000000000000 ffffffff814e2802 ffff88022ec17b80 0000000000000000
kernel:  ffffffff810aeb53 ffffffff818bf7ef 0000000000000001 ffff88022414e600
kernel:  ffffffff81e0d500 ffffffff82051722 000000000000002c ffff880214e83f18
kernel: Call Trace:
kernel:  [<ffffffff814e2802>] ? dump_stack+0x5c/0x7a
kernel:  [<ffffffff810aeb53>] ? __schedule_bug+0x53/0xa0
kernel:  [<ffffffff818bf7ef>] ? __schedule+0xc3f/0xf70
kernel:  [<ffffffff818bfb93>] ? schedule+0x73/0x220
kernel:  [<ffffffff8108502f>] ? do_exit+0x90f/0xb40
kernel:  [<ffffffff818c7377>] ? rewind_stack_do_exit+0x17/0x20
kernel:  [<ffffffff810a6e10>] ? kthread_worker_fn+0x160/0x160
rtkit-daemon[778]: The canary thread is apparently starving. Taking action.
rtkit-daemon[778]: Demoting known real-time threads.
rtkit-daemon[778]: Successfully demoted thread 777 of process 777 (/usr/bin/pulseaudio).
rtkit-daemon[778]: Demoted 1 threads.

However, hibernation works.

Edit: In case you ask: yes I’m running on a custom kernel (liquorix), but the same error happens on Vanilla.

87

The relationship between resume-from-suspend failures (and other monitor-related anomalies) and bad Display Port cables & adapters:

[i]"Summary

When using certain incorrectly manufactured 3 rd party Mini DisplayPort to DisplayPort cables to connect a display to a host computer, problems such as the following may arise:

  1. Host computer is unable to power on.
  2. Host computer is unable to correctly enter sleep modes.
  3. Host computer is unable to correctly resume from sleep modes.
  4. Display is unable to be turned on or display video correctly.
  5. Incorrect display resolution or corrupted video is shown.

Technical description of cause

Certain Mini DisplayPort to DisplayPort cables available in the market do not adhere to the DisplayPort design wiring specification. This incorrect design causes power-related issues with the display and/or host computer.

The DisplayPort specification states that a display (known as a “sink” device) must output power on its DisplayPort input connector. The specification also states that a graphics adapter (known as a “source” device) must also output power on its DisplayPort output connector. The idea for providing power on both the “source” and “sink” devices is that certain other devices connected between the two can receive power. Such devices may be, for example, a repeater or a converter of some sort.

When a cable is used to connect a display directly to a graphics adapter, the DisplayPort specification states that the cable must not connect the power line, and the power outputs of the two devices should not be connected together via the cable.

The cables that were manufactured incorrectly connect the power line through the cable and allow the power outputs of the display and graphics adapter to be connected together - a condition that is forbidden in the DisplayPort specification.

Because the two power sources are connected together when using one of these cables, situations can arise in which one device is actually supplying power to the other. For example, if the host computer is powered off but the display is on (or even in standby mode), the display will inadvertently supply power to the host computer, which may cause problems such as not being able to power on, enter sleep modes or resume correctly. Similarly, if the host computer is powered on but the display is off, the computer will be supplying power to the display, which may cause problems with the display powering on."[/i]

Notice regarding incompatibility of certain 3rd party DisplayPort video cables
[url]http://www.necdisplay.com/documents/Miscellaneous/DisplayPort_Notice.pdf[/url]

Special thanks to dudepare for finding the above document:

(Page 38, Posts #556 and #557)
Black Screen on Windows Login (344.16 and .11) on DisplayPort with GTX980 SC (Fix info posted 11/25/ - GeForce Forums
[url]https://forums.geforce.com/default/topic/777412/geforce-drivers/black-screen-on-windows-login-344-16-and-11-on-displayport-with-gtx980-sc-fix-info-posted-11-25-/38/[/url]

Related:

How to Choose a DisplayPort Cable, and Not Get a Bad One! - DisplayPort
[url]http://www.displayport.org/cables/how-to-choose-a-displayport-cable-and-not-get-a-bad-one/[/url]

88

@JGB123321: FYI, I have a triple screen, 2xDVI + 1xHDMI. No display port.

89

i have an ASUS laptop with a built in DFP, no display port or third party components. my laptop is able to correctly power on, correctly suspend, and correctly resume. it is entirely the video system which breaks on resume. i can still ping and ssh into the laptop from another system. it’s the GPU emitting the error messages about it’s own state that shows it’s the nvidia card and driver at fault.

nvidia is dragging their heels on this and paying little attention to a long standing problem.

90

A number of YouTube videos cite an out-of-date Intel Management Engine driver as being a contributing factor in sleep related issues. Here’s one of them:

“Many windows users have been facing the “dead sleep” issue. this problem is actually happening because of the hibernation feature in windows and also because of the intel management engine interface driver, i have been using winddows 10 form the beggining but i never faces this issue but recently i updated my laptop’s drivers and i faced this issue. In this tutorial i will show how to fix this Windows PC Does not Wake Up From Sleep issue. Don’t forget to like and sub ;)”

2:02
Jan 24, 2016
Windows PC Does not Wake Up From Sleep Fixed 2016 - YouTube

91

Wow just bought a GTX 1060 and here I am

Fully updated various distros, with Nvidia binary drivers 375.26…

Very easy to reproduce on two machines of mine.

Here’s a good way to reproduce every time

  1. Run any game , counter strike go. Or launch chrome… open a bunch of tabs maybe.

  2. Suspend system

  3. Wake.

  4. Jerky mouse almost right away everything freezes, you can break out of this by switching to tty1 and back.

Confirmed this with one gtx1060 that upgraded in one core i5 system from a 660 that worked perfect.

Also built a new computer with a different GTX 1060 . Same Problem.

So it’s very easy to reproduce and yeah please fix this !!

Edit: here is another person that is having a similar problem, I am also wondering how to show logs for this as well. https://devtalk.nvidia.com/default/topic/984532/linux/best-way-for-running-nvidia-bug-report-sh-when-reporting-suspend-hibernate-bugs-/

92

Checking in with the same issue. I just migrated from a 960 to a 1060, and get the issue with the 1060 whereas the 960 was fine.

I’ve tried the blacklisting and allow flipping suggestions, to no avail. Can confirm #4 above, switching to tty1 and back to fix.

I was running the 367 drivers from Ubuntu 16.04, but added the ppa to get the latest 375.

I’ve seen suggestions around the web to update your bios. I’ve got an 1150 motherboard that hasn’t had a bios update since 2014, so no luck there.

93

Does not fix it for me. Resuming works, but when I switch on tty7 (where xorg is running), I immediately get the kernel panic I pasted before.

94

I take this to mean that there hasn’t been a new BIOS update available for your motherboard since 2014?

Is your M/B’s Intel Management Engine functioning correctly?

“What is the Intel® Management Engine Verification Utility for?
Built into many Intel® Chipset-based platforms is a small, low-power computer subsystem called the Intel® Management Engine (Intel® ME). This performs various tasks while the system is in sleep, during the boot process, and when your system is running. It is important that this subsystem is functioning correctly to get the most performance and capability from your PC. This utility checks that the Intel® ME subsystem is running and communicating properly up to the operating system. This can give the system builder and user a good sense that in case of any system boot or performance issue, the Intel® ME is not the trouble spot…”

05-Dec-2016
Frequently Asked Questions for the Intel® Management Engine Verification Utility
http://www.intel.com/content/www/us/en/support/technologies/000005974.html

Version: 1.0.3604.30920 (Latest) Date: 5/12/2010
Download Intel® Management Engine Verification Utility
https://downloadcenter.intel.com/download/19009/Intel-Management-Engine-Verification-Utility

95

Yes, that’s what I meant to say.

I’ll check that out too. Would be a needle in a haystack like the bios update. Given that Windows and Ubuntu both worked with the 960, and Windows works fine with the 1060, makes me think that outside variables may not be in play.

96

I agree that it’s a long shot. But the process of elimination being what it is…

The vast majority of persistent issues re Pascal GeForce cards (the GTX 1060 seems to be the most problematic followed by the GTX 1080’s flickering and then the hit or miss GTX 1070, depending upon the brand and cooler design) that I’ve seen on this site and on its Windows-centric forums.geforce.com flip-side involve (usually DDR4-era) Intel motherboards.

Thus vetting the functionality of Intel’s Management Engine (along with to varying degrees VPro and Intel’s Anti-Theft technology etc) should be included in any comprehensive approach to trouble-shooting performance issues which defy conventional remedies.

–

FTR my interest in seeing a resolution to these assorted Pascal issues is that I’d like to get an Asus GTX1070-8G FE or a ROG STRIX-GTX1070-8G-GAMING but not at the sacrifice of the issue-free performance my rig currently delivers.

It would be interesting to learn how well the Pascal-based Quadro line is doing for I’m beginning to suspect that nVidia’s designers went ‘a bridge too far’ in appeasing shareholders’ expectations with a Pascal GeForce line-up that could surpass the gems of the GeForce Maxwell series, the GTX 960, the GTX TITAN X and the GTX 980 Ti.

Edit:

Here’s an example of a GTX 1060 resume-from-suspend issue under Windows 10 Pro 64 Bit, AU 1607 on an ASUS M5A78L, a PC-BIOS-based AM3+ motherboard:

08/07/2016
GTX 1060 Windows sleep S3 problem - GeForce Forums
https://forums.geforce.com/default/topic/955352/geforce-1000-series/gtx-1060-windows-sleep-s3-problem/

97

It’s not your bios updates or motherboard or anything else it’s just the Nvidia drivers… I can upgrade from a 660 with no issues to a gtx1060 and have this bug every time in Linux on multiple machines. Just sayin…

98

That’s what I figured. I hope that they roll in a fix to a driver update at some point. I’ve already sold my 960, so I’m going to see the 1060 through.

99

Kepler:

“On September 13, 2012, GTX 660 and GTX 650 was officially announced.”
[url]https://en.wikipedia.org/wiki/GeForce_600_series[/url]

Maxwell:

“GeForce GTX 960, January 22, 2015”
[url]https://en.wikipedia.org/wiki/GeForce_900_series[/url]

Pascal:

“GeForce GTX 1060 6GB, July 19, 2016
GeForce GTX 1060 3GB, August 18, 2016”
[url]https://en.wikipedia.org/wiki/GeForce_10_series[/url]

Three generations of nVidia graphics cards spanning nearly four years and yet you guys see no value in ensuring your motherboard’s UEFI / BIOS is up-to-date and that Intel’s ME is functioning correctly?

BTW. When I upgraded to a STRIX-GTX960-DC2OC-4GD5 I kept the GTX750-DCSL-2GD5 it replaced. Why? The '750 is my backup / a card I can use for trouble-shooting other systems.

100

@JGB123321: My UEFI is up to date, no problem with Intel’s ME.

The issue depends on the nvidia driver I use. When I bought my gtx970 more than 1 year ago, I had issues when resuming from suspend. a few weeks later, new driver, everything was ok, until the 375.20 drivers on which I have a kernel panic after resume.

So yeah, maybe on Windows it has to deal with the intel’s ME drivers. But on Linux, kernel panics prove that it has to deal with an nvidia module, and in my case I can easily fix this issue by just downgrading my drivers.