Bug 91202

Created attachment 116903 [details]
xorg log

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?

Created attachment 117375 [details]
xrandr --verbose output with DVI-I-0 in the nonworking 1920x1080 mode

Created attachment 117376 [details]
xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode

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.

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.

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.

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.

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

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.

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

Created attachment 123142 [details]
xrandr --verbose output with DVI-I-0 in a working 1680x1050 mode

Created attachment 123143 [details]
Xorg.log

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.

Problem is still present in Linux 4.5.3

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

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

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?

DAL is still being actively developed.  The latest branch is here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7

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.

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

Please ignore that last comment - turns out I just hadn't switched DAL on in the config...

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.

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

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

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.

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.

Still not fixed with kernel-5.4-rc6

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