Bug 27314 - displayport link training fails on certain panels (channel equalization fails)
Summary: displayport link training fails on certain panels (channel equalization fails)
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 28267 28554 35179 35479 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-25 10:37 UTC by Travis Glenn Hansen
Modified: 2019-11-19 08:12 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (199.11 KB, text/plain)
2010-03-25 10:37 UTC, Travis Glenn Hansen
no flags Details
Xorg.0.log (34.03 KB, patch)
2010-03-25 10:38 UTC, Travis Glenn Hansen
no flags Details | Splinter Review
drm.debug=15 (211.62 KB, text/plain)
2010-03-28 20:25 UTC, Travis Glenn Hansen
no flags Details
Xorg.0.log with nomodeset (120.21 KB, patch)
2010-03-28 20:51 UTC, Travis Glenn Hansen
no flags Details | Splinter Review
bios (63.50 KB, application/octet-stream)
2010-03-28 20:59 UTC, Travis Glenn Hansen
no flags Details
Xorg.0.log (79.85 KB, patch)
2010-03-28 21:42 UTC, Travis Glenn Hansen
no flags Details | Splinter Review
possible link training fix (1.41 KB, patch)
2010-03-29 11:19 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg (189.64 KB, text/plain)
2010-03-29 14:25 UTC, Travis Glenn Hansen
no flags Details
possible fix (1.81 KB, patch)
2010-03-31 11:49 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg (189.58 KB, text/plain)
2010-03-31 12:46 UTC, Travis Glenn Hansen
no flags Details
avivotool regs all (vanilla radeontool package) (185.13 KB, text/plain)
2010-08-05 18:10 UTC, Travis Glenn Hansen
no flags Details
avivotool regs all (patched radeontool package) (46.14 KB, text/plain)
2010-08-05 18:12 UTC, Travis Glenn Hansen
no flags Details
enable downspread if the sink supports it (1.23 KB, patch)
2011-01-05 18:36 UTC, Alex Deucher
no flags Details | Splinter Review
retry the training with a higher voltage (2.56 KB, patch)
2011-01-05 18:37 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (8.22 KB, patch)
2011-01-12 17:10 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg output with 2011-01-25 patches (221.69 KB, text/plain)
2011-01-26 08:35 UTC, Travis Glenn Hansen
no flags Details
dmesg with DP rewrite patches (138.23 KB, text/plain)
2011-04-30 02:55 UTC, Ortwin Glück
no flags Details
efi iMac12,2 dmesg (78.87 KB, text/x-log)
2011-05-08 15:39 UTC, Jérémy Lal
no flags Details
bios iMac12,2 dmesg (56.43 KB, text/x-log)
2011-05-08 15:40 UTC, Jérémy Lal
no flags Details
xorg log with the ati driver in fedora16 (12.63 KB, application/x-bzip2)
2011-11-08 17:43 UTC, Rafael Ávila de Espíndola
no flags Details
dmesg from kernel-3.1.0-7.fc16 (22.56 KB, application/x-bzip2)
2011-11-13 11:29 UTC, Rafael Ávila de Espíndola
no flags Details
dmesg with linus tree (7f80850d3f9fd8fda23a317044aef3a6bafab06b) (21.98 KB, application/x-bzip2)
2011-11-14 19:54 UTC, Rafael Ávila de Espíndola
no flags Details
dmesg from kernel 3.2 (93.53 KB, application/octet-stream)
2012-01-09 17:11 UTC, Rafael Ávila de Espíndola
no flags Details
dmesg trying kms after efi booting (118.44 KB, patch)
2012-01-19 20:53 UTC, Rafael Ávila de Espíndola
no flags Details | Splinter Review
dmesg with bios booting and kernel 3.3.0 (20.18 KB, application/x-bzip2)
2012-04-06 17:22 UTC, Rafael Ávila de Espíndola
no flags Details

Description Travis Glenn Hansen 2010-03-25 10:37:10 UTC
Created attachment 34441 [details]
dmesg

I have precision m6500 and I can't get any output to my monitor once radeon loads.  Neither the vga out nor the displayport out is working.

I'm using

xorg-server-1.7.6
ati-6.12.192
libdrm-2.4.19
kernel-2.6.33
Comment 1 Travis Glenn Hansen 2010-03-25 10:38:58 UTC
Created attachment 34442 [details] [review]
Xorg.0.log
Comment 2 Travis Glenn Hansen 2010-03-28 20:03:21 UTC
After booting with vga connected it now works.  DP will not work for me however.
Comment 3 Travis Glenn Hansen 2010-03-28 20:25:02 UTC
Created attachment 34525 [details]
drm.debug=15

just booting with no X startup
Comment 4 Travis Glenn Hansen 2010-03-28 20:51:22 UTC
Created attachment 34526 [details] [review]
Xorg.0.log with nomodeset

no kms, just ums
Comment 5 Travis Glenn Hansen 2010-03-28 20:59:49 UTC
Created attachment 34527 [details]
bios
Comment 6 Travis Glenn Hansen 2010-03-28 21:42:16 UTC
Created attachment 34528 [details] [review]
Xorg.0.log

nomodeset
git
patch applied from http://fpaste.org/WgQj/raw/
Comment 7 Alex Deucher 2010-03-29 11:19:53 UTC
Created attachment 34531 [details] [review]
possible link training fix

Does this kms patch help?  Try applying this other patch as well:
http://marc.info/?l=dri-devel&m=126988624220184&w=2
although it shouldn't be necessary.
Comment 8 Travis Glenn Hansen 2010-03-29 14:25:43 UTC
Created attachment 34535 [details]
dmesg

dmesg with attachment 34531 [details] [review] applied.
With the patch applied the monitor no longer goes into 'power save' mode and appears to think something is being sent to it.  However I still get no picture.
Comment 9 Alex Deucher 2010-03-31 11:49:38 UTC
Created attachment 34585 [details] [review]
possible fix

Does this drm patch help?  We should be turning the DP vid stream on after we do link training.
Comment 10 Travis Glenn Hansen 2010-03-31 12:46:44 UTC
Created attachment 34587 [details]
dmesg

dmesg after attachment 34585 [details] [review] applied.  Still no output.
Comment 11 Travis Glenn Hansen 2010-03-31 12:47:35 UTC
No go.  Thanks so much for the continued help!

(In reply to comment #9)
> Created an attachment (id=34585) [details]
> possible fix
> 
> Does this drm patch help?  We should be turning the DP vid stream on after we
> do link training.
> 

Comment 12 Alex Deucher 2010-06-17 09:02:54 UTC
*** Bug 28554 has been marked as a duplicate of this bug. ***
Comment 13 Alex Deucher 2010-06-17 09:23:53 UTC
boot up to a vga console (don't load the radeon drm or X) so that the DP monitor is still enabled.  Then dump the reg state to a file and attach that dump.  You can get avivotool here:
http://cgit.freedesktop.org/~airlied/radeontool/
and then apply this patch:
https://bugs.freedesktop.org/attachment.cgi?id=34810
then dump the regs (as root):
avivotool regs all > dp_bios.dump
Comment 14 Alex Deucher 2010-06-17 09:31:30 UTC
You can also dump the regs as described in the previous comment using fglrx if that's easier.  I just need a dump from a working state.
Comment 15 Alex Deucher 2010-07-19 08:33:37 UTC
*** Bug 28267 has been marked as a duplicate of this bug. ***
Comment 16 Alex Deucher 2010-08-05 17:55:57 UTC
This is a problem in the link training algo.  The timing and ordering may need to be tweaked to make some monitors happy.
Comment 17 Travis Glenn Hansen 2010-08-05 18:10:05 UTC
Created attachment 37606 [details]
avivotool regs all (vanilla radeontool package)

This is the output of my machine while running fglrx.
attachment 34810 [details] [review] *not* applied.  will upload output with that patch momentarily.
Comment 18 Travis Glenn Hansen 2010-08-05 18:12:10 UTC
Created attachment 37607 [details]
avivotool regs all (patched radeontool package)

From my properly running machine with fglrx.
radeontool patched with attachement 34810
Comment 19 Rafael Ávila de Espíndola 2010-11-09 18:58:37 UTC
Building the current X driver on a Fedora 14 system still has this bug.

The hack of reverting c7eeda8c3f3514ba95ebf2893fbe124bf526b3df works on the imac27.

Anything I could do to help with this bug?
Comment 20 Travis Glenn Hansen 2011-01-05 13:59:50 UTC
Is there any hack I can do to get this working?  I'd like to be using the open-source drivers (9 months has been more than enough for me)...
Comment 21 Alex Deucher 2011-01-05 14:59:46 UTC
You'll have to tweak the link training algo (dp_link_train() in atombios_dp.c) until the monitor accepts the link.  Unfortunately, there's not a lot I can do without access to the problematic monitor.
Comment 22 Alex Deucher 2011-01-05 18:36:37 UTC
Created attachment 41696 [details] [review]
enable downspread if the sink supports it

First see if this patch helps, if not, try the second patch both with and without this one.
Comment 23 Alex Deucher 2011-01-05 18:37:26 UTC
Created attachment 41697 [details] [review]
retry the training with a higher voltage

Try this patch both with and without the previous downspread patch.
Comment 24 Travis Glenn Hansen 2011-01-06 21:45:30 UTC
I've tried the attached patches and no go.  I started digging through code and even read part of the dp spec but didn't get very far :(  I'll allow ssh access to the machine or possibly figure out a way to get one of these monitors into a dev's hands if that's what it takes...
Comment 25 Ortwin Glück 2011-01-07 08:28:47 UTC
The patches don't help the iMac11,2 (21.5" version) either. Still no picture.
http://www.odi.ch/prog/imac/index.php
Comment 26 Alex Deucher 2011-01-12 17:10:50 UTC
Created attachment 41944 [details] [review]
possible fix

Maybe the monitor doesn't like the clock...  Does this patch help?
Comment 27 Ortwin Glück 2011-01-13 11:19:41 UTC
Tried on the iMac11,2 and seeing no difference. Find the dmesg debug output (with that patch) and a lot more info on the site mentioned in comment 25. I am not even sure if the drivers configures the right pll/encoder/transmitter etc.
Comment 28 Travis Glenn Hansen 2011-01-19 11:24:20 UTC
Been out on vacation.  Is it still necessary to test the latest patch?
Comment 29 Alex Deucher 2011-01-19 12:07:25 UTC
(In reply to comment #28)
> Been out on vacation.  Is it still necessary to test the latest patch?

Worth a shot.
Comment 30 Alex Deucher 2011-01-25 17:14:01 UTC
Can you try the patches available here:
http://people.freedesktop.org/~agd5f/dp_fixes/
Comment 31 Travis Glenn Hansen 2011-01-26 08:35:56 UTC
Created attachment 42529 [details]
dmesg output with 2011-01-25 patches

Thanks for continuing to look at this!  Still no go with those patches for me.  See attached dmesg.
Comment 32 Ortwin Glück 2011-01-29 06:38:39 UTC
Tried patches from comment 30 on the iMac11,2 and still seeing no difference.
Comment 33 Alex Deucher 2011-03-15 00:11:48 UTC
*** Bug 35179 has been marked as a duplicate of this bug. ***
Comment 34 Alex Deucher 2011-03-20 22:17:23 UTC
*** Bug 35479 has been marked as a duplicate of this bug. ***
Comment 35 Ortwin Glück 2011-03-23 06:34:13 UTC
Just out of curiosity, why is link training implemented on driver level and not on drm level? I see that nouvau and radeon each have their own implementation. The algorithm does not depend on the card, right? Only the way voltage, patterns etc are set does. Maybe by merging them the problem can be found.
Comment 36 Alex Deucher 2011-03-23 09:46:22 UTC
(In reply to comment #35)
> Just out of curiosity, why is link training implemented on driver level and not
> on drm level? I see that nouvau and radeon each have their own implementation.
> The algorithm does not depend on the card, right? Only the way voltage,
> patterns etc are set does. Maybe by merging them the problem can be found.

The link training algo is the same across all chips in theory (it's defined in a VESA spec).  However, there are often a lot of asic specific things that need to be handled.  It would probably be doable if you could figure out the right set of callbacks and driver adjustable fields to make all the drivers happy.
Comment 37 Alex Deucher 2011-04-25 11:20:35 UTC
Does the following patch set (against 2.6.39) help?
http://people.freedesktop.org/~agd5f/dp_rewrite/
Comment 38 Ortwin Glück 2011-04-30 02:55:06 UTC
Created attachment 46185 [details]
dmesg with DP rewrite patches

Still doesn't work unfortunately. dmesg attached.
Comment 39 Jérémy Lal 2011-05-08 15:39:33 UTC
Created attachment 46455 [details]
efi iMac12,2 dmesg

Same problem with latest iMac12,2 (27") when booting with efi.
(I had to patch kernel 2.6.38 because of https://bugzilla.kernel.org/show_bug.cgi?id=23202)

The first attachment is booting with efi, the second booting with bios.
I removed the timestamps from mesg to ease the diff.

EFI : black screen when drm is activated (not before)
BIOS : drm and Xorg work, DRI2 activated.
Comment 40 Jérémy Lal 2011-05-08 15:40:51 UTC
Created attachment 46456 [details]
bios iMac12,2 dmesg

and the one booting with bios.
Comment 41 Jérémy Lal 2011-05-08 15:58:38 UTC
and i forgot to mention my current kernel is 2.6.38 with all ~agd5f/dp_rewrite/ patches applied. Results are much the same with and without those.
Comment 42 Jérémy Lal 2011-05-10 18:28:22 UTC
I think the problem comes from the difference between BIOS run (working):
drm:radeon_dp_get_link_status], link status 11 11 80 00 00 00
[drm:radeon_dp_link_train], clock recovery at voltage 0 pre-emphasis 0
[drm:radeon_dp_get_link_status], link status 77 77 81 00 00 00
[drm:radeon_dp_link_train], channel eq at voltage 0 pre-emphasis 0

and EFI run (black screen):
[drm:radeon_dp_get_link_status], link status 00 00 00 00 11 11
[drm:dp_get_adjust_train], requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB
[drm:dp_get_adjust_train], requested signal parameters: lane 1 voltage 0.6V pre_emph 0dB
[drm:dp_get_adjust_train], requested signal parameters: lane 2 voltage 0.6V pre_emph 0dB
[drm:dp_get_adjust_train], requested signal parameters: lane 3 voltage 0.6V pre_emph 0dB
[drm:dp_get_adjust_train], using signal parameters: voltage 0.6V pre_emph 0dB
[drm:radeon_dp_get_link_status], link status 00 00 00 00 22 22

Though I'm a bit weak on atombios_dp.c, i'm ready to promptly test any patch.
Last test was with kernel 2.6.39-rc6.
Comment 43 Jérémy Lal 2011-05-16 13:47:02 UTC
It seems the bios that's found when booting in UEFI mode is wrong.
Following that patch and procedure :
https://bugs.freedesktop.org/show_bug.cgi?id=26891
solves the issue.
When the mode is set, the screen displays weird stuff for a moment.
I'll investigate drm messages to see what happens.
Comment 44 Ortwin Glück 2011-05-17 02:45:27 UTC
But I also noticed the line "radeon 0000:01:00.0: Invalid ROM contents" in my dmesg. Although I am not using EFI boot (plain old grub without EFI support), this indicates that the kernel doesn't see a valid video BIOS, right?
So I doubt this bug as anything to do with DP link training actually, and bug 26891 is really the cause.
Comment 45 Travis Glenn Hansen 2011-05-17 08:11:35 UTC
I just wanted to note that EFI is out of the picture in my setup.  Both laptop and monitor in my case are Dell.
Comment 46 Alex Deucher 2011-05-20 09:47:58 UTC
Please try the new patches I sent out last night.  you can find them here:
http://people.freedesktop.org/~agd5f/dp_rewrite/
You may have to apply Jesse's bpc patches first (in the bpc firectory) depending on what kernel you are using.
Comment 47 Alex Deucher 2011-05-20 09:49:43 UTC
Please don't drag in Mac EFI issues, this bug is about DP link training problems.  For Mac's stick to the legacy bios rather than trying to run in EFI mode.
Comment 48 Alex Deucher 2011-05-20 09:55:24 UTC
Travis, please try this latest patch set.  I was finally able to reproduce a problem similar to yours on a new board I got.  The problem was actually with the way the spread spectrum interaction with the PPLL was set up.  That should be fixed in this patch set.
Comment 49 Travis Glenn Hansen 2011-05-20 10:07:39 UTC
Alex I will try as soon as I get back to the office (early next week).  What version should these be applied against or do you have a git repo I should use?
Comment 50 Alex Deucher 2011-05-20 10:20:03 UTC
Dave's drm-next or drm-fixes trees should work:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
if you use drm-fixes, you'll need to apply Jesse's bpc patches (in the bpc directly in by server) first.
Comment 51 Travis Glenn Hansen 2011-05-20 10:34:10 UTC
I'll just simply use drm-next then when I test.
Comment 52 Alex Deucher 2011-05-20 10:44:25 UTC
Looks like Dave pushed a new drm-radeon-testing, so you can use that and then you'll only need to apply patches 0019 and 0020.

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing
Comment 53 Ortwin Glück 2011-08-06 01:29:30 UTC
I am happy to report that with kernel 3.0.1 all works well on the iMac 27".
Comment 54 Merlijn Wajer 2011-08-27 06:10:09 UTC
I can confirm DisplayPort seems to work for me as well now with Linux 3.1-rc3. It didn't work on previous kernels (I'm not sure if I tested 3.0, but certainly not before 3.0) when using my Dell U2133H monitor.
Comment 55 Alex Deucher 2011-10-05 06:16:30 UTC
Does kernel 3.1 help?  Also, please try this patch:
http://lists.freedesktop.org/archives/dri-devel/2011-October/014993.html
Comment 56 Travis Glenn Hansen 2011-10-31 19:59:41 UTC
Alex

Thanks for continuing to look at this :)  I have converted my amd machine to a server so I'm not using it (or rebooting it for that matter) with an external monitor.  However I ran through some updates today and decided to hook it up to provide feedback.  I updated to 3.1.0 (gentoo variant) and it continues to fail for me :(  After looking at the patch it appears to either be in vanilla 3.1.0 or already included in the gentoo patchset.  To summarize, I've tried 3.1.0 with the patch from the link and it doesn't work with my setup.
Comment 57 Rafael Ávila de Espíndola 2011-11-08 17:43:24 UTC
Created attachment 53309 [details]
xorg log with the ati driver in fedora16

I have just installed fedora 16 on an "imac11,1", and I still have the same problem. I have attached the xorg log, let me know if there is anything else I could do to help.

I checked that the patch pointed by Comment 55 is include in the linux 3.1 shipping with fedora.

I am going to try the current linus tree and let you know if that helps.
Comment 58 Rafael Ávila de Espíndola 2011-11-08 18:10:31 UTC
I also decided to try reverting c7eeda8c3f3514ba95ebf2893fbe124bf526b3df and it works.
Comment 59 Alex Deucher 2011-11-09 06:44:37 UTC
(In reply to comment #57)
> Created attachment 53309 [details]
> xorg log with the ati driver in fedora16
> 
> I have just installed fedora 16 on an "imac11,1", and I still have the same
> problem. I have attached the xorg log, let me know if there is anything else I
> could do to help.
> 
> I checked that the patch pointed by Comment 55 is include in the linux 3.1
> shipping with fedora.
> 
> I am going to try the current linus tree and let you know if that helps.

Why are you using UMS?  All of the relevant fixes have been in KMS.
Comment 60 Rafael Ávila de Espíndola 2011-11-13 11:26:58 UTC
> Why are you using UMS?  All of the relevant fixes have been in KMS.

KMS also failed with the fedora kernel. I will upload the dmesg in a sec.
Comment 61 Rafael Ávila de Espíndola 2011-11-13 11:29:13 UTC
Created attachment 53481 [details]
dmesg from kernel-3.1.0-7.fc16
Comment 62 Rafael Ávila de Espíndola 2011-11-14 19:54:15 UTC
Created attachment 53564 [details]
dmesg with linus tree (7f80850d3f9fd8fda23a317044aef3a6bafab06b)

Got the same problem with linus tree and KMS. dmesg attached, let me know if there is anything I should try.
Comment 63 Rafael Ávila de Espíndola 2012-01-09 17:11:34 UTC
Created attachment 55359 [details]
dmesg from kernel 3.2

I just tried KMS with kernel 3.2 and I still get a black screen :-(
Comment 64 Jérémy Lal 2012-01-15 04:16:02 UTC
FYI, linux 3.2-rc7 on iMac12,2 (27" 2011 model) has radeon kms running without any glitch, and even with pretty good performance ! I'm EFI-booting with default debian/experimental kernel, so it's not customized nor patched.
Comment 65 Rafael Ávila de Espíndola 2012-01-18 21:27:43 UTC
(In reply to comment #64)
> FYI, linux 3.2-rc7 on iMac12,2 (27" 2011 model) has radeon kms running without
> any glitch, and even with pretty good performance ! I'm EFI-booting with
> default debian/experimental kernel, so it's not customized nor patched.

Interesting. I have a iMac11,1. I will try EFI booting it.
Comment 66 Rafael Ávila de Espíndola 2012-01-19 20:53:01 UTC
Created attachment 55818 [details] [review]
dmesg trying kms after efi booting

EFI booting doesn't look very different from a bios boot.

There is initially a fb thanks to efifb, but the screen goes black just after

[    4.071160] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
Comment 67 Rafael Ávila de Espíndola 2012-04-06 17:22:46 UTC
Created attachment 59612 [details]
dmesg with bios booting and kernel 3.3.0

Results are similar to 3.2 :-(
This is an imac 11,1. Let me know if there any additional debugging I could do.
Comment 68 Rafael Ávila de Espíndola 2012-06-04 21:05:29 UTC
I don't know exactly what changed, but I just installed fedora 17 and after updating the kernel kms is working! :-)
Comment 69 Guilherme Amadio 2013-08-19 18:25:49 UTC
Hi,

Has anyone been able to get KMS working on a 27" iMac?

I have an iMac 11,1 and I cannot get X to work. Documentation
is scarce, so I don't know how to discover what is the problem.
When I start X, it doesn't show any errors, but I get a blank
screen. Same for when I insert the radeon module with kms on.
I suspect that the EDID is not being handled correctly. Does
any of you know how I can create an external EDID for a 2560x1440
monitor? My video card is an ATI Radeon HD 4850, by the way.

I'd appreciate any help. I'm using linux 3.10, and can post dmesg,
Xorg.0.log, etc. I'd also happily live with a non kms setup, but
recent X seems to require kms...

Thank you,
Comment 70 Alex Deucher 2013-08-19 19:57:58 UTC
(In reply to comment #69)
> I have an iMac 11,1 and I cannot get X to work. Documentation
> is scarce, so I don't know how to discover what is the problem.
> When I start X, it doesn't show any errors, but I get a blank
> screen. Same for when I insert the radeon module with kms on.
> I suspect that the EDID is not being handled correctly. Does
> any of you know how I can create an external EDID for a 2560x1440
> monitor? My video card is an ATI Radeon HD 4850, by the way.

If xrandr --verbose shows the appropriate modes for your display, there is no problem with the EDID.  You might try a 3.11 kernel.
Comment 71 Rafael Ávila de Espíndola 2013-08-19 21:23:02 UTC
(In reply to comment #69)
> Hi,
> 
> Has anyone been able to get KMS working on a 27" iMac?
> 
> I have an iMac 11,1 and I cannot get X to work. Documentation
> is scarce, so I don't know how to discover what is the problem.
> When I start X, it doesn't show any errors, but I get a blank
> screen. Same for when I insert the radeon module with kms on.
> I suspect that the EDID is not being handled correctly. Does
> any of you know how I can create an external EDID for a 2560x1440
> monitor? My video card is an ATI Radeon HD 4850, by the way.
> 
> I'd appreciate any help. I'm using linux 3.10, and can post dmesg,
> Xorg.0.log, etc. I'd also happily live with a non kms setup, but
> recent X seems to require kms...
> 
> Thank you,

I works for me on the same hardware if I bios boot it. With an EFI boot I get a black screen like yours.
Comment 72 Benjamin Bellec 2015-12-27 11:02:47 UTC
I bought a new screen and it looks like I have the same issue.

Hardware is:
GPU: Radeon HD5850 (1GB)
Screen: Dell U2414H
Connection: DisplayPort (GPU) / MiniDisplayPort (Screen)

Software is:
Fedora 23 (64-bit)
Kernel 4.2.8

At Fedora loading my screens got no more signal and enter in sleep mode. If I unplug and replug the DisplayPort cable the screen connection is recovered.

The log shows these 2 messages:
[drm:radeon_dp_link_train [radeon]] *ERROR* channel eq failed: 5 tries
[drm:radeon_dp_link_train [radeon]] *ERROR* channel eq failed
Comment 73 nickles1995 2016-05-02 21:38:45 UTC
I believe I have this issue. The screen turns off after grub.

Hardware:
27 inch imac, late 2009
radeon hd 4850
core i7

I'm trying to put the latest fedora 23 on it. I'm not overwhelmingly sure about the details beyond that. I'm relatively new to linux, so if anyone wants me to try anything it would take a bit of hand holding.
Comment 74 Martin Peres 2019-11-19 08:12:03 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/111.


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.