As initially reporte in Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783705 I'm running Debian Jessie (3.16.x kernel) on a machine with a Pitcairn-based video adapter and an NEC Multisync EA274WMi 27" monitor, connected via DisplayPort. I've also tried upgrading to the 4.0 kernel and I see exactly the same symptoms. If I turn the monitor off and then on again (as I was doing overnight), I get no display at all. I've wiggled the mouse, hit numlock on the keybard (the numlock led illuminates fine), etc., but no display. I've seen this kind of thing happen in the past on some machines, so I switch to VT1 and back to see if that helps. Still no display at all, either on console or under X. I log in remotely and I can see that the Xorg.0.log file has been updated with mode lines for the monitor, suggesting things have just woken up fine. But still no display. Here's the really weird thing: at this point, the monitor has basically locked up. It won't respond to the power/input/menu butttons at all, and is still showing the blue LED that says "I have signal" rather than switching to the amber "no signal" warning. Therefore, I can only assume there's a problem here with some weird invalid DP signal being produced. I've carried on playing with this. If I log in from another machine and run xrandr, I can see the display details of the monitor just fine. If I use xrandr to turn the display off and then on again: xrandr --output DisplayPort-0 --off xrandr --output DisplayPort-0 2560x1440 then things start working again.
I have seen similar behaviour on a Barts card with an NEC MultiSync PA271W...
Might be some kind of setup issue as Xorg.0.log shows: [ 14.853] (EE) RADEON(0): eglInitialize() failed [ 14.853] (EE) RADEON(0): glamor detected, failed to initialize EGL. and [ 14.437] (II) NVIDIA GLX Module 340.65 Tue Dec 2 09:10:06 PST 2014 ... [ 15.071] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found)
Does forcing a dpms cycle also work? E.g., sleep 5; xset dpms force off Does turning the monitor off work with other drivers or OSes? DP requires link training to bring the link up between the monitor and the GPU. I suspect when you physically turn off/on the monitor, it does not generate a hotplug signal so the driver had no way of knowing that the link needs to be re-established.
I observed the following behaviour with my setup: - the monitor never comes back on again under memtest86+ or in the BIOS - it always comes back on again when on the console (with the raden driver loaded at least) - it sometimes (?) comes back on under X - if it does not come back on, something like switching to the console, power cycle, switching to X, switching to the console brings it back on the console, but it will turn off as soon as you switch to X. Switching to the console again turns it on, etc.
BTW: Make sure that you use the original cable, otherwise you might have problems with standby anyway: http://www.necdisplay.com/documents/Miscellaneous/DisplayPort_Notice.pdf
(In reply to Niels Ole Salscheider from comment #4) > - the monitor never comes back on again under memtest86+ or in the BIOS That sounds a bit like a problem with the hardware. Can everybody else test this in the BIOS as well?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/613.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.