DP1.2 connected monitor cannot be turned on again with DPMS

sandipt, the nouveau driver does not get loaded so I had little hope that adding it to the blacklist would make a difference. I did add it to the blacklist and it made no difference.

We have no luck to reproduce this issue. Is this repro with 370.28 ?

I am using 370.28 and still have the issue.

EugeneDuvenage, Can you please share nvidia bug report ?

Hi Sandip, I have generated the bug report but there is no means for me to attach it in the “Add Reply” box. Do I need to upload it to an external site and link to it, or can I email it to you??

nvidia-bug-report.log.gz (195 KB)

I think you can attach it to your existing post.

Thanks I have attached the bug report, its a rather unintuitive attachment process, I hope it will help you investigate the issue. Additionally, I have upgraded my kernel hoping for better hardware support as well as ensuring my bios and firmware versions are the latest of for my hardware configuration,a ll without any improvement.

Currently on 16.04 with gnome 3.18 on 367.48. This issue has been pestering me since the 340 series
I have two 4k Samsung dsiplay port monitors U28D590 on a Quadro K5200. Gnome screensaver shuts them off but a click or a keystroke attempts to turn them back on. Effects vary from 33% both turn back on but they are swaped, 33% only one turns on, or 33% both won’t turn back on.
I had this issue on ubuntu 14.04 as well. I recall the 352 series had a fix for this, and only RARELY this behavior occured ( maybe once a month) but that got broken again.

I am aware that Windows had this exact problem with these type of monitors in the same NVIDIA driver/ display port connection but the forums say it got fixed with the new driver.
Maybe this is relevant?:

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-/

So as of now, I prevent the screensaver to turn them off and they just stay on, burning needlessly until nvidia ( or samsung? ) will push a fix

i have that monitor. no issues for me in 370.28 with bios machine (don’t have uefi). of course, with DP

Hi all, Can you please test with 375.10 driver ?

On my Ubuntu 16.04 I only see the 370.28 driver available in the package manager. As for the Linux 64 downloads only 367.57 is ready. Is the 375.10 a beta driver?

I have updated to 375.10 and the issue has NOT been resolved by the upgrade.
As soon as the external monitors goes into power saving mode they do not wake when the primary monitor does. I still have to resort to Ctrl+Alt+F1 then Ctrl+Alt+F7.

Running 375.20, I continue to run into this issue.
I am able to recover by switching to a VT then back, and most of the time I am immediately back at my desktop.

And for what it’s worth, I downgraded back to 367.57 but suffered the same issue.

Bug report: https://es.gy/d/nvidia-bug-report1122.log.gz
nvidia-bug-report.log.gz (260 KB)

Well I tried the new drivers, still no luck with my samsung and K5200 driving the display. I’ll try to upload the bug report , running the script right after the event occured. Scarily enough, if leave the monitors sleeping for like 30m, they won’t wake up at all, the system hangs as I can’t even SSH into it. if I wake up the monitors like 1 min after they go to sleep, one of them or if i’m lucky both might wake up and I can resume work.
nvidia-bug-report.log.gz (551 KB)

This issue was solve on my laptop after the new driver 375.26 update.
Any one who got this issue can try it.

Tried them, I was very excited to have this finally fixed, booted the screensaver, monitors went black as expected, woke them up from the screensaver, they lit up! That moment, a flicker of hope also lit up in my soul, but was rapidly extinguished as the gnome shell crashed and restarted, bringing me back to the login screen. At least now, they both lit up, however, the shell completely crashed.
nvidia-bug-report.log.gz (556 KB)

Confirmed the same behavior as deuscovrigus.
On nvidia driver 375.26-1 (from negativo repo, on Fedora 24).
Used to be able to not resume power after shutting off the monitor (Dell 2715Q)
Now it is enough to just click the power button of the monitor, wait a few sec, power on the monitor again, screen comes on but gnome-shell has crashed and back to the login screen.

The gnome-shell crash issue still persists. I dug a bit into it and collected the following info:

My system is Fedora 24 (latest packages), gnome3, with the nvidia-driver-375.26-4 connected to a Dell 2715Q 27" 4k screen via DP.

Up until driver ver 375.26 monitor display wouldn’t resume after power off/power on cycle unless I would use the xrandr command (which I assigned to a hot key).

After 375.25, power off → power on → greeter → gnome-shell crashes.

It appears that the gnome-shell crash happens precisely when the monitor is powered off. Immediately after pushing power off, libmutter segfaults with the critical message “meta_window_get_work_area_for_monitor: assertion ‘which_monitor >= 0’ failed”.

journalctl shows:

Jan 20 11:10:41 MS-7885 blueman-mechanism[17657]: Exiting
Jan 20 11:11:21 MS-7885 kernel: usb 6-4: USB disconnect, device number 3
Jan 20 11:11:21 MS-7885 kernel: usb 5-1.4: USB disconnect, device number 4
Jan 20 11:12:17 MS-7885 kernel: snd_hda_codec_hdmi hdaudioC2D0: HDMI: invalid ELD data byte 9
Jan 20 11:12:17 MS-7885 org.gnome.Shell.desktop[17153]: Window manager warning: Configuring CRTC 442 with mode 450 (3840 x 2160 @ 59.996624) at position 0, 0 and transform 0 failed
Jan 20 11:12:17 MS-7885 org.gnome.Shell.desktop[17153]: (gnome-shell:17153): mutter-CRITICAL **: meta_window_get_work_area_for_monitor: assertion 'which_monitor >= 0' failed
Jan 20 11:12:17 MS-7885 kernel: gnome-shell[17153]: segfault at ffffffff3bfe6ac0 ip 00007fd0ecb905f5 sp 00007ffc05ad12d0 error 5 in libmutter.so.0.0.0[7fd0ecb01000+106000]
Jan 20 11:12:17 MS-7885 audit[17153]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=6 pid=17153 comm="gnome-shell" exe="/usr/bin/gnome-shell" sig=11

At this point I am unsure if this warrants a bug report for freedesktop or if there’s something handled wrongly by the NVIDIA driver.

Contextually relevant:

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]

Related:

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

Updated 04/27/2011
Active vs Passive DP-> DVI adaptors | NVIDIA
[url]Error | NVIDIA

All the monitors in this thread are on the supported list of the link you just slammed as “contextually relevant” including the U28D590. I think it’s obvious that we used the DP cable that came with the monitor. This is clearly either an xorg /nvidia bug as I have the same monitor on my Windows machine and it works fine.