Bug 95206 - Display port bandwidth regression
Summary: Display port bandwidth regression
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (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: 2016-04-29 11:40 UTC by Christian L.
Modified: 2017-01-09 03:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg kernel 4.5.2 (70.89 KB, text/plain)
2016-04-29 14:59 UTC, Christian L.
no flags Details
Xorg.0.log kernel 4.5.2 (88.10 KB, text/plain)
2016-04-29 15:00 UTC, Christian L.
no flags Details
xrandr output kernel 4.5.2 (1.16 KB, text/plain)
2016-04-29 15:01 UTC, Christian L.
no flags Details
add debugging output (1.99 KB, patch)
2016-05-10 20:36 UTC, Alex Deucher
no flags Details | Splinter Review
dmesg with debugging patch (123.12 KB, text/plain)
2016-05-11 08:27 UTC, Christian L.
no flags Details
possible fix (1.44 KB, patch)
2016-05-11 20:22 UTC, Alex Deucher
no flags Details | Splinter Review

Description Christian L. 2016-04-29 11:40:16 UTC
Hi,

I have a mobile laptop (Dell Precision M4600) with an external monitor (Dell U2414H) connected via display port.

Starting with mainline kernel 4.5.x I'm unable to connect the monitor with mode (1920x1080p), instead the highest available option is 1920x1080i (interlaced) which produces heavy flickering on the monitor and makes it unable to use at all. Forcing the monitor into 1920x1080p (using xrandr --newmode, --addmode and --mode) causes a total signal loss, however forcing the monitor into 1920x1080p@30hz makes the monitor available again. If I connect the monitor using DVI/HDMI 1080p@60hz works without any problems. 

So I think the problem might be that the maximum bandwidth of the display port is reduced compared to the previous version.

Using kernel 4.4.8 the monitor is connected with 1080p using DP as expected again. So it's definitely a regression introduced in kernel 4.5.

As a side note: the Ubuntu 16.04 kernel (4.4.0-21.37) also has this display port problem, but as far as I know the ubuntu devs have backported large portions of the 4.5 radeon patches.

If you need any further information (dmesg, xrandr output), don't hesitate to ask...

Kind regards,
Christian
Comment 1 Alex Deucher 2016-04-29 14:19:19 UTC
Please attach your xorg log and dmesg output.  Can you bisect?
Comment 2 Christian L. 2016-04-29 14:59:18 UTC
Created attachment 123350 [details]
dmesg kernel 4.5.2
Comment 3 Christian L. 2016-04-29 15:00:56 UTC
Created attachment 123351 [details]
Xorg.0.log kernel 4.5.2
Comment 4 Christian L. 2016-04-29 15:01:25 UTC
Created attachment 123352 [details]
xrandr output kernel 4.5.2
Comment 5 Christian L. 2016-04-29 15:03:08 UTC
Attachments added...

What do you mean with bisect?
Comment 6 Felix Schwarz 2016-04-29 16:46:18 UTC
"bisecting" is a way to find out which commit caused a specific regression. This involves compiling the linux kernel from git and testing the compiled versions. If you can find out which commit is the culprit chances are pretty good that the problem can be fixed quickly.

To learn more about bisecting I suggest seaching for "git bisect".
Comment 7 Christian L. 2016-04-29 19:51:44 UTC
Ok, understood. Didn't know that feature. I'll give it a try in the next days.
Comment 8 Christian L. 2016-05-10 09:27:57 UTC
Hi,

I've bisected the problem down to the following commit to the mainline kernel (see below). Can I help with some further information?

092c96a8ab9d1bd60ada2ed385cc364ce084180e is the first bad commit
commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Dec 17 10:23:34 2015 -0500

    drm/radeon: fix dp link rate selection (v2)
    
    Need to properly handle the max link rate in the dpcd.
    This prevents some cases where 5.4 Ghz is selected when
    it shouldn't be.
    
    v2: simplify logic, add array bounds check
    
    Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

:040000 040000 c27fa6e02534c3ef9f53c3c954fa936b1e414cb3 0be8f64ebe28383efa39ebce68247b148f4a78f2 M	drivers
Comment 9 Alex Deucher 2016-05-10 20:36:47 UTC
Created attachment 123611 [details] [review]
add debugging output

Can you attach the dmesg output with the attached debugging patch applied?
Comment 10 Christian L. 2016-05-11 08:27:06 UTC
Created attachment 123618 [details]
dmesg with debugging patch

attached dmesg output of mainline kernel 4.5.0 with your debugging patch applied
Comment 11 Alex Deucher 2016-05-11 20:22:56 UTC
Created attachment 123629 [details] [review]
possible fix

This patch should fix it.
Comment 12 Christian L. 2016-05-12 11:01:17 UTC
Your fix works like a charm. Thanks alot!

Applied the fix to 4.5.0 mainline and the problem is gone.
Comment 13 mrj 2016-12-08 23:18:17 UTC
May be causing https://bugzilla.redhat.com/show_bug.cgi?id=1402293
Comment 15 mrj 2016-12-10 16:48:44 UTC
Sorry Alex, I wasn't clear.

It's the fixed version that (I've now verified) is causing the Radeon HD6320 problem as described here

https://bugzilla.redhat.com/show_bug.cgi?id=1402293
Comment 16 mrj 2016-12-10 17:01:57 UTC
The (native) display resolution exhibiting the problem on the Radeon HD6320 (AMD G-series T56N) is 1366x768.
Comment 17 mrj 2017-01-03 00:53:34 UTC
The good and bad kernels give identical xrandr outputs:

Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
XWAYLAND0 connected 1360x768+0+0 520mm x 320mm
   1360x768      59.98*+
Comment 18 Alex Deucher 2017-01-03 15:57:09 UTC
(In reply to mrj from comment #15)
> Sorry Alex, I wasn't clear.
> 
> It's the fixed version that (I've now verified) is causing the Radeon HD6320
> problem as described here
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1402293

Please open a new bug as this one has been addressed.
Comment 19 mrj 2017-01-09 03:40:00 UTC
Alex, I've created Bug 99326.


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.