You are not logged in.
Pages: 1
Hello!
I recently upgraded my PC.
Specs:
- Arch Linux Hardened 6.17.13
- AMD Radeon RX 6800 XT
- AMD Ryzen 5950X
- 32GB RAM CL14
- 9100 Pro NVMe
Problem:
Now I’m experiencing severe lags and stutters under GPU load. CPU load standalone also seems to perform poorly.
gpu:
- When running OCCT (GPU) or Hashcat, XFCE becomes sluggish and laggy.
- With Mesa drivers, after a few seconds it sometimes crashes back to LightDM.
- With AMDGPU-PRO, it doesn’t log out, but the system is still practically unusable.
for cpu:
Running CPU tests in OCCT shows similar issues. It’s slightly more usable than GPU stress, but typing is delayed — each key appears with about a one-second lag.
Comparison:
- On Windows 11, the same hardware had no issues. Cinebench and FurMark could run simultaneously while I was still able to browse the system smoothly.
- My previous Arch build (Ryzen 2600 + 5700 XT) handled Hashcat, three VMs, and a browser at the same time without any stutters.
What I’ve tried:
- AMDGPU-PRO and Mesa drivers
- Running Hashcat inside a TTY and switching back to XFCE — the same issues persist
sudo journalctl -b | curl -F 'file=@-' 0x0.st
https://0x0.st/PNF0.txt
dmesg | grep -i amdgpu / lspci -k | grep -A 3 -i vga / glxinfo | grep -i "renderer\|version"
https://pastebin.com/cDQDpBEy
Offline
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
The make sure to see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Then because of
cryptdevice=UUID=51981ed9https://wiki.archlinux.org/title/Dm-cry … etup_usage
cryptsetup benchmarkJan 29 15:00:42 notpetya pipewire[5186]: mod.rt: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
Jan 29 15:00:42 notpetya pipewire[5186]: mod.rt: RTKit does not give us MaxRealtimePriority, using 1
Jan 29 15:00:42 notpetya pipewire[5186]: mod.rt: RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
Jan 29 15:00:42 notpetya pipewire[5186]: mod.rt: RTKit does not give us MinNiceLevel, using 0might be an issue, https://archlinux.org/packages/extra/x86_64/rtkit/
Offline
Thank you for your response!!
I’m a bit of a Linux rookie (first year), so sorry if I miss anything.
I’ve already removed Windows, but I did a few reboots before posting the new logs.
I’ve posted XFCE logs — there are no crashes at the moment. I can tried installing regular Mesa to see if it triggers a crash, but no luck.
I have LUKS on most of my disks, and I suspect I might have configured it incorrectly. ( main disk via password, rest via keys, and there is a bunch of them) I thought it wouldn’t affect system performance, but I’ll try to figure out how to fix it.
It’s important to mention that after a hardware upgrade, I just rsynced the whole system to the new SSD to avoid reinstalling.
As for RTKit, it seems I don’t have it installed.
Someone on another forum noticed that I have the kernel parameters `pti=on page_alloc.shuffle=1`, which I definitely didn’t set. Could this be an issue after the hardware upgrade? Maybe the different CPU is affecting it?
And also tried to run w/o xfce compositor - same issue persists.
- XFCE + AMDGPU-PRO + cryptsetup benchmark (no crash): https://pastebin.com/PE5inwVU
reboot ->
- Hashcat + OCCT + Mesa + xf86-video-amdgpu (no crash this time): https://pastebin.com/c4F2hgBE
UPDATE: tried pti=off page_alloc.shuffle=0 in GRUB, it didn’t affect system performance.
I also uploaded a video that shows how badly it performs - https://youtu.be/ERtZpWxaE3I
Last edited by runzilla (2026-01-29 20:34:44)
Offline
each key appears with about a one-second lag
[ 126.117] (WW) AMDGPU(0): flip queue failed: Invalid argument
[ 126.117] (WW) AMDGPU(0): Page flip failed: Invalid argumentFigure whether this is input or output related, when putting the system under stress, does video playback or glxgears suffer even remotely to this extent?
If not, replace the fancy gaming stuff w/ a $5 mouse and keyboard from office supply (that is attached w/ a wire) - does that change things?
Edit: oh, and please try the main or LTS kernel and iff you get severe hits on the output rather than the input, remove all xf86-video-* packages.
Last edited by seth (2026-01-29 20:35:51)
Offline
Yeah, video playback and glxgears suffers as well
last link on youtube captured that.
Ill try LTS right now
Last edited by runzilla (2026-01-29 20:37:03)
Offline
6.12.67-1-lts with deleted xf86-video packages didn’t make any difference, unfortunately.
here is log with different pair of peripherals and lts kernel
pastebin.com/yYuhM42J
Last edited by runzilla (2026-01-29 21:04:22)
Offline
When rsync'ing stuff, did you exclude the external mounts, notably the tmpfs in /tmp and /run and pseudofs (sysfs, devfs, procfs, …)?
Offline
To be frankly i don't remember well, but i probably excluded /tmp and /run
because i have all my other disks mounted in /run and /tmp i just ignored
Offline
mount | curl -F 'file=@-' 0x0.stOffline
I also have previous system on old disk, i ran diff if that helps
*i just mounted it to make a diff command, usually it's not even LUKS opened
UPDATE:
decided to install rtkit + ON/OFF compositor - same issue, deleted that
tried to mess with compositor settings (https://forum.xfce.org/viewtopic.php?id=13233), still no luck
those lags are pretty brutal and remind me situations when you're out of the ram and run solely on swap
GPU powelimits does not make any change as well - https://forum.endeavouros.com/t/howto-m … dgpu/73082
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash \
amdgpu.noretry=0 amdgpu.lockup_timeout=0 amdgpu.gpu_recovery=1 \
amdgpu.runpm=0 amdgpu.mcbp=0 amdgpu.dcdebugmask=0x600 \
amdgpu.ppfeaturemask=0xf7fff"
tried:
stress-ng --cpu 0 --cpu-method all --verify --timeout 10m
stress-ng --vm 4 --vm-method all --vm-bytes 28G --timeout 15m --verify
works like a charm. cpu is 100% but no lags whatsoever
but OCCT ( cpu+ram, cpu, linpack, memory ) makes it sluggish. and if i add 3d adaptive + vram = slideshow
Last edited by runzilla (2026-01-30 01:25:10)
Offline
those lags are pretty brutal and remind me situations when you're out of the ram and run solely on swap
Yes.
The effect you see are not down to any minor performance tweaks and will be some form of IO driven or gross misbehavior of the graphics driver.
For clarification, you're nowhere near running OOM?
Do you get the same when disabling one output?
Do you get the same w/ some wayland session (weston will do) or not-xfce (eg. just an openbox session and an xterm)?
Do you get this w/ a fresh user account?
Offline
1) nope, hashcat stress test take only 3-5 gb. while occt can pretty much take over 26-27. arch is usually around 4 +-. i have 32 in total
2) yeah, i tried to set 1 monitor and it was the same
3) Weston - performs same as x11. xterm from terminal same issues. while TTY seems to be nice until i return to the xfce session, but when i create second tty and surf around there - totally nice experience
4) nope, i'm still on my old account. i guess there might be some temp files linked to the account?
Update:
account didn't made any difference
but i noted that if i run hashcat with " hashcat -a 3" it lags only for couple secs and then smooth. and when i run it like " hashcat -a 3 -w 4 its deadly laggy
My initial thought that is might be too aggressive but OCCT lags as well which is a bit strange. Tried furmark to complete benchmark list and it's half decent. it's usable but i see some performance issues ( it looks like low monitor frequency on 1080p and really bad lags on 4k )
Update x2: installed new xfce arch on spare disk - and everything works like a charm, probably will have to reinstall OS to fix that issue
Last edited by runzilla (2026-01-30 18:16:48)
Offline
You could briefly compare the list of installed packages - stress being fine but hashcat not heavily suggests this is somehow down to the https://wiki.archlinux.org/title/Genera … its#OpenCL installation.
Maybe you're also enforcing a bogus icd via an environment variable?
Offline
Oh no, I just realized that on the new system I installed "POCL," which is a CPU-only package. That's why it was running smoothly.
I swapped to "mesa linux-firmware-amdgpu opencl-mesa", and now on the new system it lags as well ?.
I'm completely confused at this point (the GPU isn't thermally throttling, for sure). new system installed via the "archinstall" script I'll try to investigate. I'm already starting to think this might just be an issue with the 6800 XT architecture.
here is my main system OPENCL logs
pastebin.com/usgyhYDK
tried separated those package
opencl-mesa
rocm-opencl-runtimeno
opencl-legacy-amdgpu-pro - opencl isn't working at all
Unfortunately seems like dead end to me. I’m sorry for taking up so much of your time.
I'll consider to swap my card on something else (maybe return to 5700xt again) or try some ROCm, opencl implementations from cachyOS repos.
Thanks a lot for your support and help!
Last edited by runzilla (2026-01-30 21:35:15)
Offline
Do you happen to have any data that would detail the opencl behavior on the previous system?
(Maybe you did hashcat on software there as well?)
Do you still have the 5700 XT ?
(You didn't cross into RDNA so the different behavior seems weird)
Do you "export RUSTICL_ENABLE=radeonsi"?
Offline
Already sold 5700 xt, now have only 1050 ti in another PC. * everything over 6 series is pricey and i really don't wanna switch back to the windows, so idk list starts from 7*ser (https://rocm.docs.amd.com/projects/inst … ments.html)
"export RUSTICL_ENABLE=radeonsi" - yes
->
clinfo --list
Device: gfx1030
->
ocl-icd-choose amdocl64.icd:mesa.icd + hashcat command = lags
ocl-icd-choose amdocl64.icd:rustci.icd + hashcat command = lags
previous system - before hardware upgrade? to be fair - never messed with it because it just worked
about software - definitely not, i sold it because of the overheating issue in hashcat. and never had POCL on main system ( installed it on new "test" system because saw reddit post of some guy that suggested a solution, and then thought that this is kinda odd thingy - and figured out about software CPU stuff)
Last edited by runzilla (2026-01-30 22:52:08)
Offline
i sold it because of the overheating issue in hashcat
:colbertemoji: - and it was specifically the GPU that was overheating and not the CPU?
(The Ryzen 2600 doesn't have an APU so you cannot have run the GUI on a different VGA device…)
Cinebench and FurMark could run simultaneously while I was still able to browse the system smoothly.
That's not necessary any OpenCL, right?
https://wiki.archlinux.org/title/Benchmarking#Furmark
Edit: I mean what's obviously happening is that the hashcat nightmare mode utilizes 100% of your GPU, not leaving anything to the actual GPU stuff (what'd make sense if it's a dedicated GPGPU device)
Last edited by seth (2026-01-30 23:22:47)
Offline
Yeah, GPU that was overheating. My bad for poorly made sentence
i changed thermal pads on 5700xt and still was terrible ( second handed after mining, so i decided to use it for half a year and swapped it to the 6800xt )
Cinebench and FurMark - that was on windows though. ( was playing with OC and testing new parts )
FurMark on linux works decent only in 1080p right now. 4k - stutters and sluggish GUI
Last edited by runzilla (2026-01-30 23:23:22)
Offline
"not leaving anything to the actual GPU stuff"
Any ways to leave a bit of performance to GUI? maybe different amd profiles?
those one's make no impact:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash \
amdgpu.noretry=0 amdgpu.lockup_timeout=0 amdgpu.gpu_recovery=1 \
amdgpu.runpm=0 amdgpu.mcbp=0 amdgpu.dcdebugmask=0x600 \
amdgpu.ppfeaturemask=0xf7fff"
I guess IRL performance tasks won't be that serious. hashcat and OCCT is really way too power hungry. I'm usually using my pc for virtualization and rarely occasion is gaming, so i might be fine.
UPDATE: Btw i just spotted that hashcat GPU PPT is only 100w, but FURMARK is 265. So i guess card is under performing with those ROCm drivers
pastebin.com/QsUGAAHt - sensors logs
Last edited by runzilla (2026-01-30 23:54:37)
Offline
Idk whether it's possible to quota opencl (other than not telling stuff like hashcat to max out the resources w/ the nightmare mode)
The OpenCL ./. FurMark difference is probably not surprising since opencl will only use some of the GPU features - it however also suggests that the bottleneck is likely the interface (maybe VRAM?) and not the GPU itself.
Offline
Got it, thanks You a lot!
Offline
Pages: 1