I'm getting severe graphics glitches in the desktop environment (XFCE, Fedora 30, on Lenovo Ideapad 330-15ARR with Ryzen 3), including text, text cursor, images, buttons and other GUI elements including screen brightness pop-ups.
The annoyance level is severe, and usability is also affected. As can be seen in the attachment, the output of "uname -a" is partly garbled. In this case I know roughly what the output should have been, but I would be wary of doing extensive debugging if I can't trust what I see on the screen.
Some of the errors last for about a second before self-correcting. Others persist until some activity like clicking on a button with the mouse 'prompts' the affected area of the display to be refreshed.
How to reproduce:
Normal interaction with D.E. using mouse and keyboard.
Select kernel version 5.1.20x or older when restarting.
Created attachment 285243 [details]
output of uname -a with garbled graphics
Can you bisect? Does booting with amdgpu.ppfeaturemask=0xffff3fff or 0xfffdbfff or 0xfffd3fff on the kernel command line in grub help?
Booting with amdgpu.ppfeaturemask=0xffff3fff and the other options gives
"error: ../../grub-core/kern/fs.c:167:invalid file name `amdgpu.ppfeaturemask=0xffff3fff
Press any key to continue..."
to the end of the kernel command line in grub. Replace 0xffff3fff with 0xfffdbfff to try the other option. Repeat with 0xfffd3fff if necessary.
Ok, this is what I've tried: holding shift to force the boot menu to show up, then pressing e to edit the options for kernel version 5.2.17, then appending
amdgpu.ppfeaturemask=0xffff3fff, and finally pressing Ctrl-x.
If I add a space and put the text at the end of the last line with text already on it, the error appears for a few seconds, then the Lenovo splash screen appears indefinitely and nothing else happens until I cycle the power.
On the other hand, if I put the text on a new line, there's no error message and Fedora boots normally, but the graphics issues persist.
I tried a total of 6 different boot edits with amdgpu.ppfeaturemask=0xffff3fff,
amdgpu.ppfeaturemask=0xfffdbfff, and amdgpu.ppfeaturemask=0xfffd3fff, with the same result each time.
(In reply to lechp from comment #5)
> If I add a space and put the text at the end of the last line with text
> already on it [...]
You need to append to the line that starts with "linux", not the last line. E.g. if you have something like this:
linux /vmlinuz-3.17.4-301.fc21.x86_64 root=/dev/mapper/fedora-root ro
You need to change it to this:
linux /vmlinuz-3.17.4-301.fc21.x86_64 root=/dev/mapper/fedora-root ro amdgpu.ppfeaturemask=0xffff3fff
Ok, because of the automatic line wrapping, I'll make the example shorter:
linux /vmlinuz-3.17.4-301.fc21.x86_64 ro
linux /vmlinuz-3.17.4-301.fc21.x86_64 ro amdgpu.ppfeaturemask=0xffff3fff
I added the amdgpu.ppfeaturemask=0xfffxxxxx text directly after the 'ro' as shown, and the fix doesn't seem to have any effect, at least not for 5.2.17-200.
Kernel 5.2.18 has the same problem. What's going on?
I've already increased the default number of old kernels that are kept by grub, from 3 to 5, but at this rate, I'm going to have to either increase it again, or stop updating. The last 'usable' kernel (version 5.1.20-200) has other problems too, including unexplained freezing once or twice a day, and wifi that 'sometimes' stops working after resuming from sleep.
These are all regressions from years ago.
Just a quick report that I'm experiencing the same issue(s) as email@example.com. I'm using a Lenovo T510 running Fedora 30. On my last usable kernel now and will be increasing by own kernel default number from 3 to 5 now.
Hope there is a fix soon . . .
Can you bisect?
Is anyone actually working on this problem?
I just upgraded from Fedora 30 to 31, hoping that the upgrade might include other miscellaneous changes that fix the problem, but the problem is EXACTLY THE SAME.
Nothing has changed. I'm starting to lose my mind with this chronic lack of progress.
Support for the Lenovo Ideapad 330 has been been severely broken for at least the last 6-7 kernel versions!
Can you bisect the people supposedly working on the kernel???
I'm not able to reproduce this on my raven systems. Could be a mesa issue. Does setting the R600_DEBUG=nodcc environment variable help?
This bug looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=111122 - so indeed using R600_DEBUG=nodcc might be a workaround.
I opened a Merge Request for Mesa to address this issue: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2836
Testing it and reporting the results (here or in the MR comments) would be appreciated.
Could somebody please provide a clear set of instructions on what can actually be done with this link? It just seems to contain a heap of forum comments, but no nothing "useful" in the conventional sense where a user can download and install a damned fix.
This bug has been fixed in Mesa, but is not part of a release yet.
So the 3 possible fixes are:
- compile Mesa from git
- or find a package for your distribution that contains Mesa git
- or define this environment variable system-wide "AMD_DEBUG=nodcc" until Mesa 20 is released and your distribution is updated.