Bug 107889

Summary: colors are wrong on one screen with Radeon RX Vega M GL and Kernel 4.18
Product: DRI Reporter: Mauro Carvalho Chehab <mchehab>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium    
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Picture with the 3 monitors. The colors at the center one are wrong
none
output of xrandr
none
Xorg logs with Kernel 4.18.5
none
Xorg logs with Kernel 4.17.3 + drm-next patches submitted for 4.18-rc1
none
Dmesg with Kernel 4.18.0 vanilla none

Description Mauro Carvalho Chehab 2018-09-10 17:22:27 UTC
Created attachment 141508 [details]
Picture with the 3 monitors. The colors at the center one are wrong

I have a 3 monitors setup on a NUC8i7HNK (with latest BIOS: 0049).

I'm currently using Kernel 4.17 + DRM patches for 4.18-rc1. Everything works OK. However, upgrading the Kernel to 4.18.5 (kernel-4.18.5-200.fc28.x86_64) causes that the center (and default) monitor to mangle colors. The same issue also happens with upstream Kernel 4.18 vanilla.

I'm enclosing a picture of what's happening there.
Comment 1 Mauro Carvalho Chehab 2018-09-10 17:24:02 UTC
Created attachment 141509 [details]
output of xrandr
Comment 2 Mauro Carvalho Chehab 2018-09-10 17:27:08 UTC
Created attachment 141510 [details]
Xorg logs with Kernel 4.18.5
Comment 3 Mauro Carvalho Chehab 2018-09-10 17:28:14 UTC
Created attachment 141511 [details]
Xorg logs with Kernel 4.17.3 + drm-next patches submitted for 4.18-rc1
Comment 4 Alex Deucher 2018-09-10 21:59:38 UTC
Can you bisect?  Also please attach your dmesg output.
Comment 5 Mauro Carvalho Chehab 2018-09-11 11:36:37 UTC
Created attachment 141526 [details]
Dmesg with Kernel 4.18.0 vanilla
Comment 6 Mauro Carvalho Chehab 2018-09-11 11:40:43 UTC
(In reply to Alex Deucher from comment #4)
> Can you bisect?  Also please attach your dmesg output.

Bisect didn't work. There is a regression between 4.17 and 4.18-rc4 on ext4fs that causes it fail to mount a file system:

set 11 08:16:49 coco.lan kernel: EXT4-fs (dm-13): ext4_check_descriptors: Block bitmap for group 0 overlaps block group descriptors
set 11 08:16:49 coco.lan kernel: EXT4-fs (dm-13): group descriptors corrupted!
Comment 7 Mauro Carvalho Chehab 2018-09-11 11:52:54 UTC
(In reply to Mauro Carvalho Chehab from comment #5)
> Created attachment 141526 [details]
> Dmesg with Kernel 4.18.0 vanilla

Forgot to mention, but the bug also happens on 4.18.0 vanilla.
So, the bug is somewhere between drm-next-2018-06-06-1, e. g.

between this changeset:

commit 568cf2e6aa0c762f14d2d0d481a006f93c63ab7a
Merge: 74860cbfdd41 ebe1d22b57b8
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed May 30 11:06:17 2018 +1000

    Merge tag 'drm-amdkfd-next-2018-05-28' of git://people.freedesktop.org/~gabbayo/linux into drm-next
    
    - Build amdkfd's related files inside amdgpu only if amdkfd is built
    - Fix compile warning
    - Print info message in case ASIC is not supported by amdkfd
    
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180528110435.GA17960@odedg-x270

and Kernel 4.18.
Comment 8 Michel Dänzer 2018-09-11 12:33:46 UTC
(In reply to Mauro Carvalho Chehab from comment #6)
> Bisect didn't work. There is a regression between 4.17 and 4.18-rc4 on
> ext4fs that causes it fail to mount a file system:

There are ways to deal with that, e.g.:

* Manually apply the fix for the ext4 regression when necessary
* Run "git bisect skip" for commits which aren't testable
* Manually find another commit which can be tested
Comment 9 Mauro Carvalho Chehab 2018-12-29 13:14:34 UTC
(In reply to Michel Dänzer from comment #8)
> (In reply to Mauro Carvalho Chehab from comment #6)
> > Bisect didn't work. There is a regression between 4.17 and 4.18-rc4 on
> > ext4fs that causes it fail to mount a file system:
> 
> There are ways to deal with that, e.g.:
> 
> * Manually apply the fix for the ext4 regression when necessary
> * Run "git bisect skip" for commits which aren't testable
> * Manually find another commit which can be tested

I tried to bisect, but I was unable to find the patch with broke it. I suspect it could be some sort of race condition, perhaps when retrieving EDID from the 3 monitors. Which buggy Kernels, the collor has a chance to be mangled during X11 start and after DPMS screen on. Sometimes, it goes fine, sometimes, it gets messed.

Anyway, since yesterday I'm using Kernel 4.20, with the latest linux-firmware. It seems that the issue vanished, but I need to keep it running for a while to be certain.
Comment 10 Martin Peres 2019-11-19 08:55:10 UTC
-- 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/521.

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.