Bug 98751 - radeon: multihead "no signal" on one of the monitors - regression
Summary: radeon: multihead "no signal" on one of the monitors - regression
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
: 98651 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-05-21 20:35 UTC by Mikkel Oscar Lyderik
Modified: 2016-03-23 18:34 UTC (History)
9 users (show)

See Also:
Kernel Version: 4.0.3+
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg (61.03 KB, text/plain)
2015-05-21 20:58 UTC, Mikkel Oscar Lyderik
Details
xorg log (79.30 KB, text/x-log)
2015-05-21 20:59 UTC, Mikkel Oscar Lyderik
Details
xorg.log (35.37 KB, application/x-gzip)
2015-05-21 23:59 UTC, Mike Noe
Details
dmesg.txt (17.32 KB, application/x-gzip)
2015-05-21 23:59 UTC, Mike Noe
Details
possible fix (1.38 KB, patch)
2015-05-26 22:05 UTC, Alex Deucher
Details | Diff
dmesg from linux-4.0.5-gentoo on PALM/Wrestler APU (71.09 KB, text/plain)
2015-06-14 11:39 UTC, Robin Bankhead
Details

Description Mikkel Oscar Lyderik 2015-05-21 20:35:50 UTC
Since this commit: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=d5c3b64 one of my two monitors doesn't get a signal (it just says "no signal").

The monitors are connected to a Radeon HD 6990 card. One is connected through HDMI and one through DVI. I'm using the radeon driver.

Most of the time it is the monitor connected through HDMI which doesn't get a signal, but I was able to switch it around somehow by messing around with screen orientation in X (not quite sure how to replicate or if it's even relevant).

I tried to revert the commit in kernel 4.0.4 (latest I tried) and that solves the problem for me.
Comment 1 Alex Deucher 2015-05-21 20:53:56 UTC
Please attach your xorg log and dmesg output.
Comment 2 Mikkel Oscar Lyderik 2015-05-21 20:58:49 UTC
Created attachment 177561 [details]
dmesg
Comment 3 Mikkel Oscar Lyderik 2015-05-21 20:59:04 UTC
Created attachment 177571 [details]
xorg log
Comment 4 Mike Noe 2015-05-21 23:58:04 UTC
Same problem here on Tumbleweed x86-64

I have a monitor connected to DVI and a HDTV connected to HDMI on a
HD6570 (Turks).  Recent TW dup with the 4.03 kernel breaks dual-mon
support.  Basically, when booting (with the HDTV on) or when connecting
the HDTV (via HDMI), the primary monitor on DVI just goes directly into
sleep mode and won't come back unless I use xrandr directly.  If I get
to Kscreen5, I can disable the HDMI which will then re-enable the DVI
(even though it shows enabled).

4.01 and earlier work great, do not have this problem.  I also tried on the latest two RCs with the same results.
Comment 5 Mike Noe 2015-05-21 23:59:06 UTC
Created attachment 177581 [details]
xorg.log
Comment 6 Mike Noe 2015-05-21 23:59:41 UTC
Created attachment 177591 [details]
dmesg.txt
Comment 7 Robin Bankhead 2015-05-25 10:22:38 UTC
Duplicate of #98651.
Comment 8 Mikkel Oscar Lyderik 2015-05-25 10:29:11 UTC
It's actually a 6950 card I have, same as in #98651.

I called it 6990 because that is what lspci tells me, but that might narrow it down?
Comment 9 Andy Furniss 2015-05-25 11:16:28 UTC
I just hit this one with my R9270X.

Reverting "drm/radeon: adjust pll when audio is not enabled" fixes it.

For me starting with DVI on and enabling HDMI results in loosing DVI. If I off then auto DVI it comes back but HDMI goes off, repeat for HDMI = DVI off again and so on.

I did find a way to get both working = xset dpms force off 
then coming out of dpms both will come on an behave as if nothing was ever wrong (I can flip either on/off without affecting the other).
Comment 10 Alex Deucher 2015-05-26 22:05:20 UTC
Created attachment 178001 [details]
possible fix

Does the attached patch help?
Comment 11 Mikkel Oscar Lyderik 2015-05-26 22:39:39 UTC
It's working for me!
Comment 12 Mike Noe 2015-05-27 00:15:37 UTC
Yes, fixed it here too on Turks, tested with 4.1-RC5
Comment 13 Andy Furniss 2015-05-27 09:46:45 UTC
Also fixes for me.
Comment 14 Thomas 2015-05-27 11:19:03 UTC
@Alex Deucher: For Bug #98651 it helps: There's a image. But HDMI-Audio isn't working (which it did prior to the bug).
Comment 15 Thomas 2015-05-27 11:24:39 UTC
Summary for Bug #98651

Kernel 4.0.2: HDMI image and audio working.
Kernel 4.0.3 and upward: No HDMI.
Kernel 4.0.4 with commit d5c3b64b9618214a5443c57c64511ab5fa599cec reverted: HDMI image works, audio does not.
Kernel 4.0.4 with attachment 178001 [details]: HDMI image works, audio does not.
Comment 16 Alex Deucher 2015-05-27 13:49:37 UTC
(In reply to Thomas from comment #15)
> Summary for Bug #98651
> 
> Kernel 4.0.2: HDMI image and audio working.
> Kernel 4.0.3 and upward: No HDMI.
> Kernel 4.0.4 with commit d5c3b64b9618214a5443c57c64511ab5fa599cec reverted:
> HDMI image works, audio does not.
> Kernel 4.0.4 with attachment 178001 [details]: HDMI image works, audio does
> not.

Can you bisect when audio stopped working and open a new bug?
Comment 17 Thomas 2015-05-27 15:26:09 UTC
@Alex Deucher there you go: https://bugzilla.kernel.org/show_bug.cgi?id=99041
Comment 18 Thomas 2015-05-27 15:26:43 UTC
*** Bug 98651 has been marked as a duplicate of this bug. ***
Comment 19 Robin Bankhead 2015-06-14 11:38:25 UTC
(In reply to Alex Deucher from comment #10)
> Created attachment 178001 [details]
> possible fix
> 
> Does the attached patch help?

Nope, just built 4.0.5-gentoo which has this patch applied, laptop LCD still goes dark when radeondrmfb takes over from simplefb (or around that point, when the display would normally flicker at the changeover).
Comment 20 Robin Bankhead 2015-06-14 11:39:59 UTC
Created attachment 179891 [details]
dmesg from linux-4.0.5-gentoo on PALM/Wrestler APU
Comment 21 Robin Bankhead 2015-06-14 12:23:54 UTC
APU model name:
AMD E2-1800 APU with Radeon(tm) HD Graphics

PCI ID:
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 7340]

Reverting the commit in OP solves it for me.

Note You need to log in before you can comment on or make changes to this bug.