| Summary: | Display port bandwidth regression | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Christian L. <barneyman> | ||||||||||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | medium | ||||||||||||||||
| Version: | unspecified | ||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Christian L.
2016-04-29 11:40:16 UTC
Please attach your xorg log and dmesg output. Can you bisect? Created attachment 123350 [details]
dmesg kernel 4.5.2
Created attachment 123351 [details]
Xorg.0.log kernel 4.5.2
Created attachment 123352 [details]
xrandr output kernel 4.5.2
Attachments added... What do you mean with bisect? "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". Ok, understood. Didn't know that feature. I'll give it a try in the next days. 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 Created attachment 123611 [details] [review] add debugging output Can you attach the dmesg output with the attached debugging patch applied? Created attachment 123618 [details]
dmesg with debugging patch
attached dmesg output of mainline kernel 4.5.0 with your debugging patch applied
Created attachment 123629 [details] [review] possible fix This patch should fix it. Your fix works like a charm. Thanks alot! Applied the fix to 4.5.0 mainline and the problem is gone. May be causing https://bugzilla.redhat.com/show_bug.cgi?id=1402293 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 The (native) display resolution exhibiting the problem on the Radeon HD6320 (AMD G-series T56N) is 1366x768. 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*+ (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. 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.