| Bug ID | 100726 |
|---|---|
| Summary | [REGRESSION][BISECTED] Severe flickering with an R9 290 |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | hiwatari.seiji@gmail.com |
As of the commit:
d8d1721cfb3162abbda078d67a928792d6552b84 : A series of fixup patches me=
ant
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 w=
as
not that easy. I hope I didn't make any mistake.
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.1= 0.11.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Resolution | FIXED | --- |
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
| What | Removed | Added |
|---|---|---|
| Attachment #135725 mime type | text/x-log | text/plain |
None of those commits look even remotely related, so I'm afrai= d you still incorrectly labelled at least one bad commit as good.
I already waited at least 1 week, before marking a commit as g= ood. I guess I will have to try 2 weeks this time. This is going to take ages. Are you sure, that b7d91c915290ab0bfbab84a0fb9c9eae57816982 is definitely n= ot 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-seque= nce (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 probl= em before linux-4.9.
(In reply to hiwatari.seiji from comment #7) > Are you sure, that b7d91c915290ab0bfbab84a0fb9c9= eae57816982 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, some= times > 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 wa= sn'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 t= he correct commit this time. I first ran 4 Weeks on the 4.9-rc1 without the error ever appear= ing, 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 t= he error to appear per commit, before flagging the kernel as ok. Git then tells me, that 5f7f8f6edbf860abf18149a64be036d4be5e2993 is the fir= st bad commit. I will attach the new bisect log. I don't know if the error might already h= ave 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
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | REOPENED | RESOLVED |
-- 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.