Bug 90340

Summary:	RADEON "PITCAIRN" displayport output breaks when monitor turned off and on
Product:	DRI	Reporter:	Steve McIntyre <steve>
Component:	DRM/Radeon	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	bugs.xorg, niels_ole, steve
Version:	XOrg git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Steve McIntyre 2015-05-06 13:26:11 UTC

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.

Comment 1 Niels Ole Salscheider 2015-05-06 19:44:13 UTC

I have seen similar behaviour on a Barts card with an NEC MultiSync PA271W...

Comment 2 smoki 2015-05-07 10:59:03 UTC

 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)

Comment 3 Alex Deucher 2015-05-07 14:31:05 UTC

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.

Comment 4 Niels Ole Salscheider 2015-05-08 07:05:50 UTC

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.

Comment 5 Niels Ole Salscheider 2015-05-08 07:11:01 UTC

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

Comment 6 Christian König 2015-05-08 08:29:42 UTC

(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?

Comment 7 Martin Peres 2019-11-19 09:04:54 UTC

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