Please attach your xorg log and dmesg output from when the problem occurs.

dmesg says

[554729.894304] [drm:radeon_dp_link_train_ce] *ERROR* displayport link status failed
[554729.894307] [drm:radeon_dp_link_train_ce] *ERROR* channel eq failed
[554729.897695] [drm:radeon_dp_link_train_cr] *ERROR* displayport link status failed
[554729.897697] [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed
[555004.704953] [drm:btc_dpm_set_power_state] *ERROR* rv770_restrict_performance_levels_before_switch failed

Xorg log dumps EDID information multiple times.

[555001.004] (II) RADEON(0): EDID vendor "SAM", prod id 2184
[555001.004] (II) RADEON(0): Using hsync ranges from config file
[555001.004] (II) RADEON(0): Using vrefresh ranges from config file
[555001.004] (II) RADEON(0): Printing DDC gathered Modelines:
[555001.004] (II) RADEON(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync -vsync (88.8 kHz eP)
[555001.004] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[555001.004] (II) RADEON(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 601 603 625 +hsync +vsync (35.2 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 483 486 525 -hsync -vsync (35.0 kHz e)
[555001.004] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[555001.005] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[555001.005] (II) RADEON(0): Modeline "1024x768"x0.0   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[555001.005] (II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz e)
[555001.005] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[555001.005] (II) RADEON(0): Modeline "800x600"x0.0   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
[555001.005] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x800"x0.0   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488 1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[555001.005] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)


[This entire block is repeated more than 100 times]

Please attach the whole dmesg output/Xorg log, as requested. Otherwise it is really difficult to get the whole picture.

Currently, there is no information provided by you indicating kernel version, XOrg server version, radeon xorg driver version, distribution. All this would be available when you provided the full logs.

Created attachment 114791 [details]
dmesg with bootup and failure

Created attachment 114792 [details]
Xorg.0.log after failure

I have the same issue.
In fact, I've been having this issue for years, probably since I own the hardware.

The issue happens when I turn off my screen and turn it back on, and does so reproducibly.
It only affects DisplayPort.

My card is a Cayman, and I'm building the X stack from git.

I've attached the relevant dmesg and the Xorg.0.log directly after the issue appeared.

Created attachment 116162 [details]
xorg log via journalctl -b0 | grep gdm

I see a similar failure with two Samsung Syncmaster SA850 monitors on an ATI Firepro 2260 quad displayport framebuffer and 4.x kernels on Fedora-22.   Fedora-21 and 3.x kernels worked fine.

typo.  That should be ATI Firepro 2460.

This sounds similar to https://bugs.freedesktop.org/show_bug.cgi?id=90340.

Maybe you could try if the problem also occurs in your BIOS screen? I have found similar reports by windows users and it might really be some hw / cable issue.

Apart from that it seems that most (all?) setups that cause problems have a screen with a 2560x1600 resolution...

I can't tell if comment #8 was addressed to me or not.   My bios screen is fine as is the display during early stages of booting.   The display was also fine under the previous version of fedora.  I don't believe it is a hardware problem.

(In reply to Wolfgang Rupprecht from comment #9)
> I can't tell if comment #8 was addressed to me or not.   My bios screen is
> fine as is the display during early stages of booting.   The display was
> also fine under the previous version of fedora.  I don't believe it is a
> hardware problem.

It was addressed to anyone in this report who has this problem...

[I hit enter too fast]

I mean, does your screen come back on when you enter the bios and then turn it off and on again? It does not for me (with two different mainboards) and it would be interesting to know if this is a common problem or not.

Sitting in the initial bios screen and turning off the monitor with either the front soft power switch or the back/top real power switch does indeed cause it to go and stay into power-save mode with a slow blinking of the front blue led.  My motherboard has the same problem you observe.  (Asus F2A85-M Pro, bios 6601 (the latest))

One thing that I should mention is that under X the monitor will sometimes wake up with a "not optimal mode, 2560 x 1440" small moving box displayed on the screen.  This happens some of the time when I turn the monitor off/on or switch displays vea alt-ctl-f3  and then back again.  It may be because the two 2560x1440 monitors prefer a slightly different refresh rate.  Xrandr seems to think the monitors want 59.xx hz instead of 60.

(In reply to Wolfgang Rupprecht from comment #12)
> Xrandr seems to think the monitors want 59.xx hz instead of 60.

Just FYI: 59.xx is probably a modeline with reduced blanking (CVT-RB standard) while 60 is probably usual CVT modeline. You'd better use 59.xx and not 60 because CVT-RB was designed specially for LCDs and requires less bandwidth than CVT.

I should warn that some displays does not seem to follow the displayport standard properly. I would recommend trying a different one, and if its related to some models, discuss what to do. I dont have an answer for that.

I am working on a embedded displayport source here and find a Dell U2913 2560x1080 monitor (It has a STDP9320-BB "Athena" displayport sink, with unknown firmware) does not report a correct SINK_STATUS (DPCD register 0x00205, bit 0) wich the specification says it should do. Also its seem to lock the LINK_STATUS_UPDATED bit to 1 (in DPCD register 0x00204) But even if this is wrong, it still shows an image. Googling my symptom made me find this thread.

Wether to skip this test is a good idea is up for discussion. For an home/office environment, its probably ok, but for an industrial environment it may not be ok.

#93021 is possibly related or a duplicate.

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