Hi everyone, I want to preface that I’m a complete noob at manjaro and linux as a whole so I hope I haven’t missed anything obvious. The problem I face is that after a game is open for 5-10 minutes, I start getting black lines randomly displaying all over my screen, not just in the game window (The only game I’m able to test right now is Left 4 Dead 2 playing in borderless windowed mode, but it happens in all window modes).
Here’s the inxi report:
That sounds like artifacts from hardware failure (I hope it’s not). Try monitoring your CPU and GPU temperature and power while stressing them (playing games or encoding videos). The simple way to do that is to run watch -d -n1 sensors in the terminal.
I tried running the game on my windows OS I have dual booted and I don’t get the artifacts so it (might) thankfully mean it’s not a hardware issue. I grabbed a copy of the sensor output during the glitces in-case:
Thanks for the clear and easy instructions, after performing your instructions I managed to play the game with no artifacts in one half hour test session, but I ran into a different problem.
If I open Firefox and load any YouTube video, it would not load, then if I closed Firefox and re-opened it, the whole system would lock up. I noticed that a Firefox process would not end when I closed the browser so I assume the process got locked up.
I used troubleshooting mode in Firefox and noticed it no longer happened so it might be some of the about:config changes I gathered from here with regards to hardware acceleration as my CPU usage gets really high when watching videos. I’ll keep tinkering with stuff and hopefully if everything becomes stable I can mark this solved.
You can always reset Firefox to default from the Help menu, and then reconfigure it manually in its Settings. You’ll also need to reinstall extension and reconfigure them, but at least you start on a refreshed profile with no issue.
That 68 out of 70 degree is pretty high, but it’s ok, I guess. So like what megavolt said, it might just be a power management and or mesa fault. But be sure to check that temperature again with DPM disabled.
Anyway, if you want to venture more, try setting up your monitor frequency to 60 Hz or below if you can and enable vsync globally (also during playing games), as this archlinux wiki said it’s related to amdgpu DPM issue (look at the Screen artifacts and frequency problem section). You can also follow a workaround mentioned on that page.
I guess I forgot to mention that this is a laptop (quite an old one) so I think those temps are ok.
As an update after disabling power management, gaming is fine but other applications which use hardware acceleration proceed to hang my machine. I’ve tried 3 applications, Firefox as previously mentioned, Discord and Parsec. All 3 immediately hang upon displaying video output.
While they all have means to disable hardware acceleration, it does result in an inferior performance (1080p 60fps videos constantly drop frames, Parsec has worse input latency, etc.). Is there any way to rectify this? If it helps, this laptop has an APU, so it’s not got a dedicated graphics card.
Have you tried this with DPM enabled? Also did you check the link to archlinux wiki I mentioned and try the workaround they’ve suggested?
If you have, and if it’s it still doesn’t work, you might want to try to add acpi_osi='Windows 2009' in grub, with and without DPM (just to be safe! do it temporally by accessing grub when booting your laptop. read manjaro or archlinux wiki if you don’t know how to do that). It might not be related to your problem, but it’s for fooling your laptop to make it think that it’s running on Windows 7.
I don’t have the same laptop as yours, so I can’t test it myself. If fooling your laptop also doesn’t work, then you might want to wait until the next mesa and kernel update (or use kernel 5.16 instead, or 5.17 when it released).
So I re-enabled DPM and did the udev rule in that link, it fixed the hardware acceleration crash but brought back the artifacts in game, effectively back to square one.
I’m not 100% sure if I did it right, but what I did was:
Wait, can you try this cat /sys/class/drm/card0/device/pp_dpm_mclk and post the output here before you disable DPM. If you disable DPM, then you need to delete that rules, as it might conflicts to each other (but you’re free to try both of them, tho)
Tried again with DPM off, and it hung on hardware acceleration again, so I can only assume the udev sadly didn’t change anything. Turned it back on, and here’s the output for that command:
It should’ve sit at 933Mhz. Can you try this: sudo echo "1" > /sys/class/drm/card0/device/pp_dpm_mclk and run cat /sys/class/drm/card0/device/pp_dpm_mclk again. You can change the echo number to “0” or “2” to test where the high performance is set. It will revert the change to default value if you reboot, in case you want it to.
Oh, that means you need to switch to root account completely using su. But I don’t recommend that. Well, i guess disabling DPM is your only option for now. Lets hope someone else know another workaround. Good luck.
Ah that’s unfortunate, I do appreciate you trying to help me out though.
As an aside, if no solution does get found, is there a way to toggle DPM on the fly without requiring a reboot? It’d be a little inconvenient but I wouldn’t be opposed to manually turning it off/on when needed if it’s possible to.
I can think of two way to do that. First, if you still have the udev rules that doesn’t work before, you can try trigger it with sudo udevadm trigger and hope it will run as expected. You may have to trigger it every times you reboot your laptop.
I tried sudo udevadm trigger but it didn’t seem to toggle dynamic power management, I guess the grub method is the only way that works?
I also previously tried the that package, but after it took a while to build, it ended up not detecting anything from my system, all windows were blank.
One thing that puzzles me is why disabling dynamic power management would end up bricking hardware acceleration. If that could somehow be resolved then I can live without DPM.
A side thought, and I doubt it would, but would a different video driver affect anything? I’m currently using video-linux, the other options are video-modesetting and video-vesa.
One last try, boot with amdgpu.runpm=0 instead of amdgpu.dpm=0.
Well, this is just my uneducated guess, disabling DPM means turning off a module (or something) to control you GPU clocks/power. Thus your GPU stuck at the bottom speed and your games runs slower. The absence of that module also affect application behavior that expect it to exist, thus makes them crash or slow. Again, this is just my uneducated guess.
Edit:
You’re free to try. The video-modesetting is for intel gpu, i guess. And video-vesa is for prehistorical vesa card, 99% that thing wont work.
I don’t know if it will help in any way, but I ran the command cat /sys/class/drm/card0/device/pp_dpm_sclk to try to gather any more info that I could find, and got this output:
After running it in watch for a while I noticed it would periodically jump to the 7th level for a few seconds before falling back down to the 0th regardless of activity type. The other levels don’t seem to ever be selected, neither idle, light activity or heavy activity. Again I don’t know if this info is useful in anyway but I’m trying to provide whatever I can since there doesn’t seem to be many options left.
If runpm doesn’t work then I have no idea left how to fix it. You can try AMD proprietary driver (amdgpu-pro), they are in AUR (again, not supported by manjaro). Or you can stay with DPM disabled and wait for the next mesa update. Or, drastically, you can try another well-funded distro such as Ubuntu (now I really going to get banned for promoting other distro in here. ).
Maybe that’s the bug. You might want to report that to mesa or kernel team, or anyone responsible with amdgpu driver. That might helps or at least push them to make a patch for the next mesa update.
).