Are there any AMD + Pascal (or Maxwell) users experiencing resume-from-suspend issues?

Graphics / Linux Linux
1

So far every resume-from-suspend help thread I’ve seen on this site involves (a typically DDR4-era) Intel motherboard + a Pascal (or the occasional Maxwell) GPU.

As this thread’s title alludes, if you’re an AMD + Pascal (or Maxell) user who is experiencing any resume-from-suspend issues, please post the relevant details of your rig along with any trouble-shooting steps.

I’ll start. The brief resume-from-suspend issue I experienced after upgrading from a Asus GTX750-DCSL-2GD5 to an Asus STRIX-GTX960-DC2OC-4GD5 was caused by the use of a PCI-based StarTech PCI300WN2X2 (and as further experimentation revealed, any PCI card under a load) in conjunction with motherboard’s then available latest UEFI ver. 2501.

The remedy was to stop using any PCI cards (and switch to a PCIe-based StarTech PEX300WN2X2 which delivers better WiFi performance anyway) followed by updating the motherboard’s UEFI to version 2901 as soon as it was released earlier this year.

Edit:

The cables variously employed with both cards were an approx. 4 meter-long Phillips HDMI unit (unknown model #) and a 10ft StarTech bi-directional DVD-D SL to HDMI cable model # HDMIDVIMM10.

2

Honestly, I don’t consider that swapping or removing other PCI cards is the cause for the non working status of suspend and hibernation of Pascal GPUs in current Linux boxes. Yes, maybe you can make it work by removing some card, but, the problem isn’t caused by that card, which is just a side effect of a bug in either the NVIDIA driver, or the Linux kernel, or both.

My great disappointment here is that nobody from either NVIDIA or the Linux kernel team has properly documented nor tried to fix these issues in a proper way. When somebody “fixes” suspend/hibernation on a Pascal GPU, it’s just a matter of magic from unknown side effects by swapping cards, trying some Linux kernel, or after installing unknown updates, but nobody actually knows the cause for the problem. This disappointment can be seen in this very forum, by users acknowledging that the problem just seemed to disappear mysteriously.

I don’t have an AMD processor, but a 6700K. However, I’m almost sure that our problem with Pascal GPUs is the same: Either the NVIDIA driver or the Linux kernel (or both) have suspend/hibernation broken. Maybe you can “fix” it from side effects by switching other cards, but, from what I see Pascal suspend/hibernation is really broken in all current Linux boxes, and nobody is actually tracking it.

3

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]

4

[i]"Originally Posted by Pokuz View Post
Hi Guys,

i`ve been stuck with the same issue.

I have an Asus Motherboard, an Asus 970GTX and the new Asus PG279Q.

When starting the PC or even switching it on or off between use i got the “Displayport has no connection” issue.

But after some extense testing i found a Solution for my specific Setup and also a Workaround that should help other Setups
aswell (at least i hope so).

Solution:

In the menu of my PG279Q there is an option called deep sleep, which is checked in on default.
If you disable it, my Monitor has no connection error at all.

…
This seems to have helped my situation. I had the same types of problems, essentially just unable to wake the monitor from sleep, getting no-signals all the time. Nothing else cleared it up aside from switching to HDMI which worked without issue. I tried the disabling of deep-sleep on my monitor and, for the past week, the issue has cleared completely. Thanks Pokuz. Posting here to help any future searchers.

I have the Strix GTX980TI running on a Dell S2716DG monitor. (Maybe some shared components with the PG279Q)"[/i]

Post #126
GTX 970/980 BIOS update for DisplayPort issues - Page 13
[url]GTX 970/980 BIOS update for DisplayPort issues - Page 13

5

I avoid ‘Secure Boot’ and its (IME) needless complexities which I suspect may be a contributing factor in resume-from-suspend failues.

How I partition a Linux Mint HDD (of greater than 2TB in capacity, in gparted choose ‘gpt’ as the partition map to be applied to the drive prior to partitioning it) in a manner which saves time later on.

Via gparted create four partitions on a GPT drive (CSM / Compatibility Support Module enabled in the UEFI, no alleged *‘Secure Boot’):

  1. bios_grub = 1MB (the 1MB bios_grub partition is there to prevent older, pre-GPT-era disk repair utilities from attempting to ‘repair’ a GPT-era partition)

  2. / = (1024MB x 40 = 40960MB or 40GB, ext4)

  3. swap = 1GB more than the m/b’s max. RAM capacity (1024MB x 33 = 33792MB or 33GB, the required swap partition size in the case of the Sabertooth 990FX R2.0) to ensure a functioning resume from suspend and hibernate.

  4. /home (ext4) = the rest of the drive.

External Media

The above straight forward approach has not only supported resume from suspend on every AMD and the one Intel machine (an i5 750 / H57 Express, Gateway DX4831-07c) I’ve used it with, it also allows me to clean install an OS (after formatting the / partition and deleting the .name invisible preferences files and folders from the /home partition to keep them from mucking up a new OS) without having to delete /home (during an OS install mount /home as ext4 but don’t format it) and then be forced to restore personal files from a backup disk for hours on end.

Further I always install an OS’ GRUB on the same disk (or SSD) which that particular OS resides upon and then use the UEFI / BIOS’ boot menu to boot between various HDDs or SSDs (I have an OS on every drive in my machine to ensure that I can always boot the PC if an OS install or the drive it’s installed on fails). That way if one or more drives is or are removed from the machine the remaining drives will continue to be bootable and function normally.

What’s more, drives prepared in the above manner can be transplanted into a different machine (which also supports GPT drive capacities) and still boot and work correctly. This works best when going from AMD to AMD or from Intel to Intel but AMD to Intel or vice versa nearly always works as well thanks to the Linux kernel having an abundance of firmware and drivers for various constituent chipsets of both hardware platforms. (Caveats re nVidia vs AMD graphics drivers apply.)

*Secure Boot hacked
[url]Secure Boot hacked at DuckDuckGo

10 Aug 2016
*Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea • The Register
[url]http://www.theregister.co.uk/2016/08/10/microsoft_secure_boot_ms16_100/[/url]

–

How I partition a Linux Mint SSD boot drive (of less than 2TB in capacity, in gparted choose ‘msdos’ as the partition map to be applied to the drive prior to partitioning it) in a manner which prevents premature wear.

  1. / = (1024MB x 40 = 40960MB or 40GB, ext4)

  2. /home (ext4) = the rest of the drive.

It is unnecessary to have a swap partition on an SSD boot drive as Linux Mint will automatically use the swap partition(s) on any connected HDD(s) partitioned in the manner described above.