Bug 91202 - Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors
Summary: Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple ...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-03 01:22 UTC by Brian Paterni
Modified: 2019-11-09 07:37 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg for e965b8ce4215ac2b22b23ffc8a8dfbae964b9496 (122.60 KB, text/plain)
2015-07-03 01:22 UTC, Brian Paterni
no flags Details
xorg log (54.89 KB, text/plain)
2015-07-03 01:23 UTC, Brian Paterni
no flags Details
xrandr --verbose output with DVI-I-0 in the nonworking 1920x1080 mode (13.17 KB, text/plain)
2015-07-25 18:47 UTC, Brian Paterni
no flags Details
xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode (13.18 KB, text/plain)
2015-07-25 18:49 UTC, Brian Paterni
no flags Details
xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode (16.06 KB, text/plain)
2016-04-22 10:09 UTC, Marco Wentsch
no flags Details
Xorg.log (233.30 KB, text/plain)
2016-04-22 10:18 UTC, Marco Wentsch
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Paterni 2015-07-03 01:22:44 UTC
Created attachment 116902 [details]
dmesg for e965b8ce4215ac2b22b23ffc8a8dfbae964b9496

I have a radeon r9 285 (tonga) and I'm trying to run dual DVI displays via the new AMDGPU driver. The problem I'm having though is that the display connected to the DVI-I output goes blank during drm initialization on boot, and thereafter never 'recovers'. If I plug either DVI-D or DVI-I in individually, however, and disconnect the other on a fresh boot, either outputs work just fine. Additionally, dual displays do work if I use any combination of DVI-D, HDMI, or DisplayPort; which leads me to believe that the problem has something to do with how amdgpu is handling output to DVI-I or a hardware problem. Hopefully it is not the latter.

Please let me know if there is anything I can do to help debug this problem!

I'm using Debian unstable, with the latest linux kernel compiled from git mainline (e965b8ce4215ac2b22b23ffc8a8dfbae964b9496)

dmesg and Xorg log should be attached.
Comment 1 Brian Paterni 2015-07-03 01:23:27 UTC
Created attachment 116903 [details]
xorg log
Comment 2 Brian Paterni 2015-07-04 17:51:45 UTC
Up to now I haven't attempted this, but I just tried changing display modes with xrandr, and this does result in a working display on DVI-I. That is, if the mode is anything other than the preferred 1920x1080. If I try to switch back to 1920x1080, the display goes blank and returns to standby mode.

Would anyone happen to know why preferred mode would have problems while other modes seem to display just fine?
Comment 3 Brian Paterni 2015-07-25 18:47:55 UTC
Created attachment 117375 [details]
xrandr --verbose output with DVI-I-0 in the nonworking 1920x1080 mode
Comment 4 Brian Paterni 2015-07-25 18:49:28 UTC
Created attachment 117376 [details]
xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode
Comment 5 Brian Paterni 2015-07-25 18:50:05 UTC
Just a little update on this bug.

Still experiencing this problem with the latest upstream kernel code (up to 33b40178cb3bd75294d1a758b3f509a0d38682ab)

It was mentioned on irc that the output of xrandr --verbose may be useful. So I've also attached two additional files with DVI-I-0 in either a working/nonworking state.
Comment 6 Mathias Tillman 2015-08-18 15:44:23 UTC
I know this may not be a very useful comment, but I can confirm that this bug also happens on 4.2-rc7, and that changing the display resolution via xrandr makes it come back.
I set up a script that's run when X11 is started that changes the resolution (and then back again) as a temporary workaround.
Comment 7 Guido Winkelmann 2015-11-07 18:01:56 UTC
Can confirm the problem with an R9 285 chip (graphics card is called ASUS STRIX-R9285-DC2OC-2GD5).

The monitor receives no input (switching to power saving mode) when run at its preferred resolution of 2560x1440. It will work with any other resolution, but switching it back 2560x1440 will disable it again.

This is with Kernel 4.3 and the amdgpu driver from today's git master.
Comment 8 Vedran Miletić 2016-01-05 21:26:33 UTC
I am using XFX R9 380X: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Amethyst XT [Radeon R9 M295X Mac Edition / R9 380X] [1002:6938] (rev f1)

This bug affects me as well. Interesting part is this: when I plug in just DVI-I on boot, monitor works fine, and plugging DVI-D makes the monitor connected to DVI-D blank. However, if I change monitor setup using e.g. GNOME Displays, the DVI-I will turn blank and DVI-D will work. Disconnecting DVI-D afterwards does not help, DVI-I remains blank.

I have three HDMI monitors, two of them are connected via DVI->HDMI adapters, and I can do further testing if it could be helpful.
Comment 9 Vedran Miletić 2016-01-06 11:26:58 UTC
EoD did testing on Sapphire R9 380X Nitro, details at https://gist.github.com/EoD/2baa78b81e233218a59c and copied below:

Booted with DVI-D-0 + HDMI-A-0
Both displays work

Booted with DVI-I-1 + HDMI-A-0
Both displays work

Booted with DVI-D-0 + DVI-I-1
DVI-D-0 shows output, DVI-I-1 stays blank  (via xrandr)

Booted with DVI-I-1 + plugging in DVI-D-0 after boot
DVI-I-1 shows output, DVI-D-0 stays blank  (via xrandr)

Booted with DVI-I-1 + plugging in DVI-D-0 after boot + removing DVI-I-1: 
DVI-D-0 stays blank  (via xrandr)

Booted with DVI-I-1 + plugging in HDMI-A-0 after boot + removing DVI-I-1 + plugging in DVI-D-0:
HDMI-A-0 shows output, DVI-D-0 stays blank (via xrandr)
When switching to a virtual termina, HDMI-A-0 goes blank, DVI-D-0 shows output
Comment 10 Vedran Miletić 2016-01-07 10:49:48 UTC
Further information: this bug does not occur on R9 380, tested with

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (rev f1) (prog-if 00 [VGA controller])

Dual DVI using DVI-I and DVI-D works fine.
Comment 11 EoD 2016-01-07 12:12:29 UTC
(In reply to Vedran Miletić from comment #9)
> EoD did testing on Sapphire R9 380X Nitro, details at
> https://gist.github.com/EoD/2baa78b81e233218a59c and copied below:

This has been tested on drm-next-4.5 geafbbd9 and drm-next-4.5-wip gbc48ef9, although only the trivial cases.
Comment 12 Marco Wentsch 2016-04-22 10:09:18 UTC
Created attachment 123142 [details]
xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode
Comment 13 Marco Wentsch 2016-04-22 10:18:10 UTC
Created attachment 123143 [details]
Xorg.log
Comment 14 Marco Wentsch 2016-04-22 10:19:46 UTC
hi, i have the same issue on Ubuntu 16.04 LTS final. 
I tried to upgrade the kernel to 4.6 rc4 by self compile but nothing have changed, it doesn't work.

My graphiccard:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Amethyst XT [Radeon R9 M295X Mac Edition / R9 380X] (rev f1)

XFX R9 380X DD Black Edition OC


On HDMI-A-0 it works on native solution
on DVI-I-1 its does not work on native solutions but on 1680x1050, i have choose at the moment 1600x900 because it looks better

befor i upgrade i have ubuntu 15.10 (fgrlx and amdgpu) with the orginal kernel and self compiled 4.3 with kvm patches and with both driver it works.
Comment 15 Guido Winkelmann 2016-05-09 17:36:40 UTC
Problem is still present in Linux 4.5.3
Comment 16 Brian Paterni 2016-05-23 21:45:55 UTC
just to confirm something mentioned on IRC back in February:

    10:55 #radeon: < vedranm> by the way, any chance that you looked into the 3 display issue on Linux_
    10:55 #radeon: < vedranm> sorry, DVI-I issue that is
    10:56 #radeon: < agd5f> vedranm, no. should be fixed by the new dal code 


I checked out branch 'drm-next-4.7-wip-dal' from git://people.freedesktop.org/~agd5f/linux today and can say that I no longer experience a 'dead' display on DVI-I running the new DAL code!

Interestingly, with DAL, both DVI interfaces on my r9 285 are now detected as DVI-D by xrandr...
Comment 17 Thomas R. 2016-06-03 14:42:46 UTC
Thanks for letting us know. Sadly, I have a feeling we'll wait quite some time for DAL in mainline.

I realize that Alex kinda has to act as if merging DAL was right around the corner (wrt this bug, fex), but.. Well...

http://thread.gmane.org/gmane.comp.video.dri.devel/149763/focus=149834

Admittedly this makes buying a R9 285 specifically to be able to use this driver look a bit stupid. :/
Comment 18 Guido Winkelmann 2016-08-28 15:22:27 UTC
Looks like the DAL line has been pretty much abandoned at this point.

So what now? Are us AMD now just stuck with either outdated kernels or broken multi-monitor support?
Comment 19 Alex Deucher 2016-08-28 18:14:28 UTC
DAL is still being actively developed.  The latest branch is here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7
Comment 20 jokeyrhyme 2016-08-28 20:56:10 UTC
For a while there it looked like we might get the DAL work in Linux 4.9, but now I'm wondering if this is more of a 4.10 or 4.11 thing.
- https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Linux-4.9-First

It's actually a pretty exciting time for AMD GPUs on Linux, as it is right in the middle of a massive overhaul. I purchased a Tonga specifically so I could bear witness to this open-by-default turnaround for the AMD team.

And yeah, it's totally frustrating the multi-monitor is broken right now, but at least we get re-clocking. Imagine how frustrating it must be for open-source nVidia fans right now, with nVidia itself having long stymied the community work in that area.

With my current setup, I have both monitors connected to my Intel GPU, and the primary monitor also connected to the AMD one, with Intel being initialised by EFI / BIOS first. In Linux, I switch the primary monitor to Intel, and for Windows I switch it back to AMD. Not perfect of course, but this flow sort of works for me.
Comment 21 Guido Winkelmann 2016-08-28 21:52:37 UTC
(In reply to Alex Deucher from comment #19)
> DAL is still being actively developed.  The latest branch is here:
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7

I just tried booting with that kernel (commit f67b5d7409ed6f4c5b353932bcafffea995094be). It doesn't solve this issue for me. (Branch drm-next-4.7-wip-dal did.)
Comment 22 Guido Winkelmann 2016-09-17 18:44:32 UTC
Please ignore that last comment - turns out I just hadn't switched DAL on in the config...
Comment 23 Thomas R. 2016-09-26 11:08:01 UTC
Guido, does that mean that now it works for you, or simply that you can't say one way or the other because you didn't test with DAL actually running?

I'm asking because I finally got around to compile amd-staging-4.7 (which only works with a certain set of kernel options, BTW), and with DAL enabled and both the last commit and f67b5d74 you mentioned, I still see this bug. So now I'm confused - am I doing something wrong, or was the fix a victim of the numerous DAL cleanups along the way, or maybe the freesync changes? I got "[drm] DAL is enabled" in my kernel log at any rate, and freesync.c dumps stack traces in warn_slowpath_null, which I guess is just a development help and nothing serious.

If I'd find a branch with both a working and non-working revision in it I'd be willing to bisect, but going back in staging-4.7 removes DAL completely, and staging-4.6 doesn't even compile for me, which was when I gave up yesterday.

It's a shame because apart from this, 4.7 works really, really well. So if there is anything I can do to properly triangulate this problem, I'd be very eager to help.
Comment 24 Guido Winkelmann 2016-09-27 17:31:58 UTC
(In reply to Thomas R. from comment #23)
> Guido, does that mean that now it works for you, or simply that you can't
> say one way or the other because you didn't test with DAL actually running?

No, it works for me like this, as of commit d330e1e9c232895dbd0c183a647d41d54ecc0884.
Comment 25 Guido Winkelmann 2016-11-14 23:03:40 UTC
I tried upgrading to the newest commit in amd-staging-4.7 today (680da8633ae17cdea8fddd1ede87253325c8ca25), and now it is broken now, but in a different way, see: https://bugs.freedesktop.org/show_bug.cgi?id=98730
Comment 26 Thomas R. 2017-02-20 03:28:49 UTC
ASUS STRIX-R9285-DC2OC-2GD5:

Still not working in Mainline 4.9.11. 
Not working in any DAL-4.7 version, either (tried all commits Guido mentioned, but it seems he switched cards in between, now having reported a bug for a Sapphire Nitro Radeon R9 380X.
Comment 27 Thomas R. 2017-02-21 11:25:12 UTC
With amd-staging-4.9, commit a364784ea02674736abd9d345fd74bf6787f95a1 ("drm/amdgpu: expose GPU sensor related information"), it works now, but only if DC is enabled (I guess it's DAL reborn?)

Either I didn't configure DAL correctly before (even though it showed up in dmesg), or there was an actual change that made it work for my card between xmas and now.

Today I lit a candle and deleted fglrx.
Comment 28 Lars Wendler 2019-11-09 07:37:55 UTC
Still not fixed with kernel-5.4-rc6


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.