[REGRESSION][BISECTED] Severe flickering with an R9 290
Submitted by Markus Ebner @seijikun
Assigned to Default DRI bug account
Link to original bug (#100726)
Description
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.
Activity
@seijikunuploaded an attachment:Attachment 130926, "Short video showing the issue":
flicker.mkv
@seijikunsaid: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 functionupdate_wall_time':<br> (.text+0x52c37): undefined reference to____ilog2_NaN'
make: *** [Makefile:961: vmlinux] Error 1
So I had to skip all remaining commits.@seijikunuploaded an attachment:Attachment 135725, "New Bisect log":
bisect2.log@seijikunsaid: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.
- It appears noticably more often, when rebooting to Linux after gaming in a dual-booted Windows.
@daenzersaid:(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.@seijikunsaid: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.@seijikunuploaded an attachment:Attachment 138086, "Bisect Log 3":
bisect3.log@janvlugsaid:Maybe related to:
https://gitlab.gnome.org/GNOME/mutter/issues/22This issue hasn't had any activity since 2019-11-19. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.
