Created attachment 130926 [details]
Short video showing the issue

It's unlikely that this is caused by the bisected commit. You'll need to test longer before declaring a commit as good.

This seems to have been fixed somewhere between 4.10.8 and 4.10.11.

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.

Created attachment 135725 [details]
New Bisect log

None of those commits look even remotely related, so I'm afraid you still incorrectly labelled at least one bad commit as good.

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.

(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.

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.

Created attachment 138086 [details]
Bisect Log 3

I can confirm this is still a problem (tested 4.15.10).

Maybe related to:
https://gitlab.gnome.org/GNOME/mutter/issues/22

-- 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.