DP1.2 connected monitor cannot be turned on again with DPMS
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?
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?

#31
Posted 10/25/2016 02:15 PM   
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.
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.

#32
Posted 10/26/2016 06:39 AM   
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
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

#33
Posted 11/22/2016 07:50 PM   
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.
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.

#34
Posted 11/23/2016 04:47 PM   
This issue was solve on my laptop after the new driver 375.26 update. Any one who got this issue can try it.
This issue was solve on my laptop after the new driver 375.26 update.
Any one who got this issue can try it.

#35
Posted 12/19/2016 05:10 AM   
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.
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.

#36
Posted 12/19/2016 05:05 PM   
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.
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.

#37
Posted 12/28/2016 07:39 AM   
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 "[b]meta_window_get_work_area_for_monitor: assertion 'which_monitor >= 0' failed[/b]". journalctl shows: [code] 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 [/code] 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.
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.

#38
Posted 01/20/2017 09:30 AM   
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]http://nvidia.custhelp.com/app/answers/detail/a_id/2967[/url]
Contextually relevant:

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

Related:

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

Updated 04/27/2011
Active vs Passive DP-> DVI adaptors | NVIDIA
http://nvidia.custhelp.com/app/answers/detail/a_id/2967

Stability forms the keystone of true performance. Accept no substitute.

Never buy, update or ask anything until after you have done a search. Discovery is curiosity's reward.

Some use a PC to play games. Others use one to learn what games are being played.

Help others to help you. Post complete system specs. in your forum signature.

linuxmint-17.3-mate-64bit, 4.4.0-97-lowlatency | SABERTOOTH 990FX R2.0 (UEFI 2901, 2016/08/05), CSM-->UEFI and *Legacy OpROM (*allows for the custom partitioning of SSDs & HDDs that will also work intact with up-to-date Vishera-capable PC-BIOS-based motherboards), no 'Secure' Boot or HPET | IOMMU Disabled (when Enabled it causes random PCIe WiFi failure after resume from S3) | FX-8370 | CLP0587 with 1 x Venturi HP-14 PWM | KVR16E11K4/32 | STRIX-GTX960-DC2OC-4GD5 (nVidia 387.12). Resume from S3 works correctly in all regards. Hibernate does not. | GL2450HM, DVIDDMM10, ARMUNONB | 220-G2-0850-XR | GH22LP20 (LightScribe), IDE100RND36, PEX2IDE | PEXMSATA3422 (Firmware: 2.3.0.1065) with 2 x SMS200S3/120G in RAID 0 and 2 x ST3000DM001 in RAID 0 | 1 x ST6000DM001 (SB950), 1 x ST6000DM001 (ASM1062) | S252BU33R (Firmware Version: 101.01.01.09) with 2 x ST2000LM003, JU-P40511-S1 (uPD720201), JU-H40711-S1 (VIA VL811 ) | CM 690 II Advanced, HP-12 PWMs, HP-14 PWMs, FAN7X10TX3 | ST0026Z | PEX300WN2X2 | Y-BF37 (Sleep key), SM50F76959

#39
Posted 01/22/2017 12:18 AM   
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.
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.

#40
Posted 01/24/2017 03:07 PM   
[quote="deuscovrigus"]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. [/quote] +1, same here, used the DP cable that came with the Dell 2715Q. I also found a workaround for the gnome-shell crash reported earlier: I just run: [b]xset dpms force off[/b] (makes my screen black for a bit) in a terminal and after than I can lock the Window Manager and power off the screen without crashing gnome-shell. Obviously you will *need* to physically power off the monitor but at least things will keep working when you come back :)
deuscovrigus said: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.


+1, same here, used the DP cable that came with the Dell 2715Q.

I also found a workaround for the gnome-shell crash reported earlier:

I just run:

xset dpms force off

(makes my screen black for a bit) in a terminal and after than I can lock the Window Manager and power off the screen without crashing gnome-shell.

Obviously you will *need* to physically power off the monitor but at least things will keep working when you come back :)

#41
Posted 01/24/2017 04:58 PM   
Hi folks, have the same problem here. My Setup: Debain testing (stretch, latest patches applied) with Gnome 3.22 NVIDIA GeForce GTX 960 (VBIOS Version 84.06.26.00.05) NVIDIA Driver version 375.26 Eizo EV3237 4k Monitor GDM does not crash, but when monitor goes into sleep, it doesn't wake up. When I press the menu-button on the Eizo monitor, it wakes up and shows my Desktop and I can continue to work. Any help highly appreciated! KR, -Andreas.
Hi folks,

have the same problem here.
My Setup:
Debain testing (stretch, latest patches applied) with Gnome 3.22
NVIDIA GeForce GTX 960 (VBIOS Version 84.06.26.00.05)
NVIDIA Driver version 375.26
Eizo EV3237 4k Monitor

GDM does not crash, but when monitor goes into sleep, it doesn't wake up.
When I press the menu-button on the Eizo monitor, it wakes up and shows my Desktop and I can continue to work.

Any help highly appreciated!
KR,
-Andreas.

#42
Posted 02/03/2017 12:58 PM   
I tried 375.39 with the same gnome shell crash, this time with one of the monitors shutting down. Attaching bug report here.
I tried 375.39 with the same gnome shell crash, this time with one of the monitors shutting down. Attaching bug report here.

#43
Posted 02/15/2017 03:37 PM   
I'm seeing this issue as well on Ubuntu 14.04, kernel 4.4.0-70 and 375.39 using an old Quadro K600 card connected with vga and dp to HP L2311c monitors. The dp monitor does not wake up after sleep and I have to switch tty to wake it up. Attaching bugreport.
I'm seeing this issue as well on Ubuntu 14.04, kernel 4.4.0-70 and 375.39 using an old Quadro K600 card connected with vga and dp to HP L2311c monitors. The dp monitor does not wake up after sleep and I have to switch tty to wake it up.

Attaching bugreport.

#44
Posted 03/29/2017 02:24 PM   
Test 381.09 driver can help to resolve this issue for anybody. https://devtalk.nvidia.com/default/topic/1002788 .
Test 381.09 driver can help to resolve this issue for anybody. https://devtalk.nvidia.com/default/topic/1002788 .

Thanks,
Sandip.

#45
Posted 04/07/2017 05:36 AM   
Scroll To Top

Add Reply