Bug 100726

Summary: [REGRESSION][BISECTED] Severe flickering with an R9 290
Product: DRI Reporter: hiwatari.seiji
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: fdsfgs, jan.public
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Short video showing the issue
none
New Bisect log
none
Bisect Log 3 none

Description hiwatari.seiji 2017-04-19 18:55:45 UTC
As of the commit:
    d8d1721cfb3162abbda078d67a928792d6552b84 : A series of fixup patches meant to fix the usage of DMA on stack, plus one warning fixup

My R9 290 produces heavy flickering artifacts in 1 of 3 or 4 cases when starting Linux.
I am using the amdgpu kernel module, and have not tested this with radeon.
When the bug occurs, the system is completely unusable.

Since the occurence of this bug is not really deterministic, bisecting it was not that easy. I hope I didn't make any mistake.
Comment 1 hiwatari.seiji 2017-04-19 18:56:42 UTC
Created attachment 130926 [details]
Short video showing the issue
Comment 2 Michel Dänzer 2017-04-20 01:42:05 UTC
It's unlikely that this is caused by the bisected commit. You'll need to test longer before declaring a commit as good.
Comment 3 hiwatari.seiji 2017-04-24 16:08:16 UTC
This seems to have been fixed somewhere between 4.10.8 and 4.10.11.
Comment 4 hiwatari.seiji 2017-11-26 10:56:54 UTC
I was wrong, unfortunately. This error is still present.
A friend of mine is having the same problem with a Fury X card.

So I did another bisect, waiting longer before declaring a commit as good.
But at some point, the build always crashed with:

kernel/built-in.o: In function `update_wall_time':
(.text+0x52c37): undefined reference to `____ilog2_NaN'
make: *** [Makefile:961: vmlinux] Error 1

So I had to skip all remaining commits.
Comment 5 hiwatari.seiji 2017-11-26 10:57:51 UTC
Created attachment 135725 [details]
New Bisect log
Comment 6 Michel Dänzer 2017-11-27 10:34:51 UTC
None of those commits look even remotely related, so I'm afraid you still incorrectly labelled at least one bad commit as good.
Comment 7 hiwatari.seiji 2017-11-27 12:01:59 UTC
I already waited at least 1 week, before marking a commit as good. I guess I will have to try 2 weeks this time. This is going to take ages.

Are you sure, that b7d91c915290ab0bfbab84a0fb9c9eae57816982 is definitely not the cause?

Maybe some helpful information regarding the bug:

- It appears noticably more often, when rebooting to Linux after gaming in a dual-booted Windows.
- When booting, the virtual console disappears, the screen displays black, the login-manager appears. When the flickering does not appear, the black-sequence (mode-setting?) takes noticably longer, than when the flickering appears.
- We both have two displays. One connected through HDMI, one through DisplayPort.
- I have two 2K screens, the Fury X-User has one 4K and one FullHD screen.
- We both have the login-manager SDDM
- For me, when booting the machine (BIOS) - the screen resolution of GRUB is quite random. Sometimes, it's using the native screen resolution, sometimes it is using a very reduced resolution. Sometimes, it's only displaying on one of the two screens, sometimes it's displaying on both. But that wasn't a problem before linux-4.9.
Comment 8 Michel Dänzer 2017-11-28 16:13:19 UTC
(In reply to hiwatari.seiji from comment #7)
> Are you sure, that b7d91c915290ab0bfbab84a0fb9c9eae57816982 is definitely
> not the cause?

At least 99% sure. Pure merge commits are almost never a correct bisection result.


> - For me, when booting the machine (BIOS) - the screen resolution of GRUB is
> quite random. Sometimes, it's using the native screen resolution, sometimes
> it is using a very reduced resolution. Sometimes, it's only displaying on
> one of the two screens, sometimes it's displaying on both. But that wasn't a
> problem before linux-4.9.

This is before the Linux kernel is even loaded, so it can hardly be directly related to it.
Comment 9 hiwatari.seiji 2018-03-14 01:28:28 UTC
My last try of bisecting the error. I'm pretty sure I've got the correct commit this time. I first ran 4 Weeks on the 4.9-rc1 without the error ever appearing, upgraded to one or two release candidates higher, rebooted and instantly had the error. I then did the bisecting in this window, waiting 3-4 Weeks for the error to appear per commit, before flagging the kernel as ok.

Git then tells me, that 5f7f8f6edbf860abf18149a64be036d4be5e2993 is the first bad commit.
I will attach the new bisect log. I don't know if the error might already have been fixed, since I've been months on this ancient version. But I will try that in the following weeks.
Comment 10 hiwatari.seiji 2018-03-14 01:29:05 UTC
Created attachment 138086 [details]
Bisect Log 3
Comment 11 hiwatari.seiji 2018-03-20 19:14:54 UTC
I can confirm this is still a problem (tested 4.15.10).
Comment 12 Jan Vlug 2018-03-24 11:15:43 UTC
Maybe related to:
https://gitlab.gnome.org/GNOME/mutter/issues/22
Comment 13 Martin Peres 2019-11-19 08:15:28 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/154.

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.