Random UI freezes on KDE

Kernel: 6.1.1-AMD arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-amd
root=UUID=1dbaae96-1d61-4f73-9f69-5aab42d5b8c7 rw [email protected]
root=/dev/mapper/luks-d7e177b0-1c29-4eea-9eb3-b96c262d51c4 quiet splash
rd.udev.log_priority=3 vt.global_cursor_default=0 loglevel=3 ibt=off
Desktop: KDE Plasma v: 5.26.4 tk: Qt v: 5.15.7 info: latte-dock
wm: kwin_x11 vt: 1 dm: SDDM Distro: Garuda Linux base: Arch Linux
Type: Desktop Mobo: MSI model: B350M MORTAR ARCTIC (MS-7A37) v: 2.0
serial: <superuser required> UEFI: American Megatrends v: A.40
date: 04/28/2017
Info: model: AMD Ryzen 7 1700X bits: 64 type: MT MCP arch: Zen level: v3
note: check built: 2017-19 process: GF 14nm family: 0x17 (23) model-id: 1
stepping: 1 microcode: 0x800111C
Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
L1: 768 KiB desc: d-8x32 KiB; i-8x64 KiB L2: 4 MiB desc: 8x512 KiB
L3: 16 MiB desc: 2x8 MiB
Speed (MHz): avg: 2267 high: 3800 min/max: 2200/3800 boost: enabled
scaling: driver: acpi-cpufreq governor: performance cores: 1: 1926 2: 3800
3: 1881 4: 2142 5: 1885 6: 1974 7: 1884 8: 3800 9: 1878 10: 1877 11: 1884
12: 1891 13: 1891 14: 1884 15: 1886 16: 3800 bogomips: 121635
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: mmio_stale_data status: Not affected
Type: retbleed mitigation: untrained return thunk; SMT vulnerable
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
Type: spectre_v2 mitigation: Retpolines, STIBP: disabled, RSB filling,
PBRSB-eIBRS: Not affected
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M]
vendor: Micro-Star MSI driver: amdgpu v: kernel arch: RDNA-2 code: Navi-2x
process: TSMC n7 (7nm) built: 2020-22 pcie: gen: 4 speed: 16 GT/s
lanes: 16 ports: active: HDMI-A-1 empty: DP-1,DP-2,DP-3 bus-ID: 22:00.0
chip-ID: 1002:73df class-ID: 0300
Device-2: Logitech Webcam C270 type: USB driver: snd-usb-audio,uvcvideo
bus-ID: 3-2:2 chip-ID: 046d:0825 class-ID: 0102
Display: x11 server: X.Org v: 21.1.6 with: Xwayland v: 22.1.7
compositor: kwin_x11 driver: X: loaded: amdgpu unloaded: modesetting,radeon
alternate: fbdev,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: HDMI-A-1 mapped: HDMI-A-0 model: Philips 222EL serial: <filter>
built: 2011 res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2
size: 476x268mm (18.74x10.55") diag: 546mm (21.5") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
API: OpenGL v: 4.6 Mesa 22.3.1 renderer: AMD Radeon RX 6700 XT (navi22
LLVM 14.0.6 DRM 3.49 6.1.1-AMD) direct render: Yes
Device-1: AMD Navi 21/23 HDMI/DP Audio driver: snd_hda_intel v: kernel pcie:
bus-ID: 1-3:2 gen: 4 chip-ID: 1397:0301 speed: 16 GT/s class-ID: 0300
lanes: 16 bus-ID: 22:00.1 chip-ID: 1002:ab28 class-ID: 0403
Device-2: AMD Family 17h HD Audio vendor: Micro-Star MSI
driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
bus-ID: 24:00.3 chip-ID: 1022:1457 class-ID: 0403
Device-3: BEHRINGER GmbH C-1U type: USB
driver: hid-generic,snd-usb-audio,usbhid
Device-4: Logitech Webcam C270 type: USB driver: snd-usb-audio,uvcvideo
bus-ID: 3-2:2 chip-ID: 046d:0825 class-ID: 0102
Sound API: ALSA v: k6.1.1-AMD running: yes
Sound Server-1: PulseAudio v: 16.1 running: no
Sound Server-2: PipeWire v: 0.3.63 running: yes
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: Micro-Star MSI driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s
lanes: 1 port: f000 bus-ID: 1e:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp30s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Local Storage: total: 5.57 TiB used: 646.69 GiB (11.3%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 980 1TB
size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
lanes: 4 type: SSD serial: <filter> rev: 1B4QFXO7 temp: 39.9 C scheme: GPT
ID-2: /dev/sda maj-min: 8:0 vendor: A-Data model: SU700 size: 111.79 GiB
block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD
serial: <filter> rev: 203b scheme: GPT
ID-3: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST4000VN008-2DR166
size: 3.64 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
type: HDD rpm: 5980 serial: <filter> rev: SC60 scheme: GPT
ID-4: /dev/sdc maj-min: 8:32 vendor: Toshiba model: DT01ACA100
size: 931.51 GiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
type: HDD rpm: 7200 serial: <filter> rev: A750 scheme: GPT
ID-1: / raw-size: 931.21 GiB size: 931.21 GiB (100.00%)
used: 78.52 GiB (8.4%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
mapped: luks-d7e177b0-1c29-4eea-9eb3-b96c262d51c4
ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
used: 26.2 MiB (8.8%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
ID-3: /home raw-size: 931.21 GiB size: 931.21 GiB (100.00%)
used: 78.52 GiB (8.4%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
mapped: luks-d7e177b0-1c29-4eea-9eb3-b96c262d51c4
ID-4: /var/log raw-size: 931.21 GiB size: 931.21 GiB (100.00%)
used: 78.52 GiB (8.4%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
mapped: luks-d7e177b0-1c29-4eea-9eb3-b96c262d51c4
ID-5: /var/tmp raw-size: 931.21 GiB size: 931.21 GiB (100.00%)
used: 78.52 GiB (8.4%) fs: btrfs dev: /dev/dm-0 maj-min: 254:0
mapped: luks-d7e177b0-1c29-4eea-9eb3-b96c262d51c4
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 15.59 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
System Temperatures: cpu: 35.4 C mobo: N/A gpu: amdgpu temp: 45.0 C
mem: 42.0 C
Fan Speeds (RPM): N/A gpu: amdgpu fan: 0
Processes: 417 Uptime: 4m wakeups: 0 Memory: 15.59 GiB
used: 3.86 GiB (24.7%) Init: systemd v: 252 default: graphical
tool: systemctl Compilers: gcc: 12.2.0 clang: 14.0.6 Packages: pm: pacman
pkgs: 2197 libs: 581 tools: octopi,pamac,paru Shell: fish v: 3.5.1
default: Zsh v: 5.9 running-in: konsole inxi: 3.3.24
Garuda (2.6.12-1):
System install date:     2022-12-30
Last full system update: 2022-12-30
Is partially upgraded:   No
Relevant software:       NetworkManager
Windows dual boot:       Probably (Run as root to verify)
Snapshots:               Snapper
Failed units:

Hi, I recently switched from Manjaro to Garuda because of a few problems, one of these being random UI freezes. I was thinking it is manjaro but apparently it happens on a fresh install of Garuda too. Using the normal, zen and amd kernels had the same problem. Live booting on xfce and gnome seems to work fine without the freezes. I searched on the internet and there seems to be no fixes. Does anyone have an idea of how to do this?

An initial consideration would be a hardware issue of some kind, as that would be a resource in common between the two operating systems.

This could be a clue as well--not the desktop environment part, rather the fact that your system is fine in the live environment. My suspicion is drawn to your hard drive, as this is not used or even mounted in the live environment.

A quick Whoogle search of your hard drive turns up quite a few hits for folks experiencing a similar issue.

Ultimately, a disk issue is something that should be resolved by Samsung through a firmware update to the disk, but until that happens the last link above has a few ideas to try that seemed to resolve the issue for the person who opened the thread.

From what I've read nvme SSD's can have issues when lower power mode is enabled.

This is my main desktop so I don't care about going into lower power mode.

Under Advanced Power Options
Set to High Performance.

Change Plan Settings
Put computer to sleep Never

Turn Off DIsplay 30 Mins.

Advanced Power settings
Turn off Hard Disk after 60 Minutes

Sleep After Never
Hibernate After Never

USB Settings
USB selective Suspend Setting

PCI Express
Link State Power Management

I think the Link State Power Management might be the most important since we are on PCI Express BUS 4.0 X 4

I hope that helps, welcome to the community @ChillSheep. :slightly_smiling_face:


Thanks! The SSD wasn't used for more than a few months and SMART indicates that it's ok, that is why I thought KDE was the problem since I didn't use my pc for ~2months and only after updating everything it started to have problems, the thing is that after updating I directly switched from an nvidia card to this amd one.
Samsung magician doesn't recognize my ssd on Linux so I'll boot into the 256gb ssd I have where I have windows installed and try from there.
Also I can't seem to find those type of power settings in the "System Settings" app from kde. I only found the basic screen ones.
I'll boot into windows, update the firmware if possible and come back with an update if it works fine now. Thanks a lot for the help!

Edit, installed samsung magician, had to run with --no-sandbox because of a bug with electron and windows apparently. Will update with more info

Edit 2, the issue still isn't fixed

1 Like

Have you looked for a BIOS update? Your current one is dated 2017.


I did not read the notes closely, but now that I do I think they are referring to setting that must be available inside Windows. :face_with_diagonal_mouth:

I would comb through the BIOS settings at least, to make sure any available disk-related power saving options are disabled. This person in the same thread had another BIOS-related piece of advice:

Go to BIOS

Under Boot select CSM to use both UEFI & Legacy. leave the rest options as UEFI only.

Honestly, on its face it seems like strange advice to me, and I don't see how this setting would be helpful for the indicated issue. On the other hand, it doesn't seem like it could hurt; you could give it a shot, and just change it back if no improvement is observed.

1 Like

this broke grub, I'll come back with news after I try to fix grub from live boot of garuda, it will take some time because my ventoy usb was used to update the bios

I have a 980 PRO as well.
I also suffered random UI freezes a few weeks after I got my new CPU in 2019. It started to get worse in Summer 2022 and after MANY tests I had to conclude for HW stability issues. I bought a new CPU and ALL of my issues got IMMEDIATELY fixed. But I had to pay and buy new HW in order to test that!

It is sometimes a tedious process but I highly recommend you find ways to test various things in order to eliminate the possibilities one by one. Random freezes with 2 different distros can often point to HW. Could be a simple setting or a real HW failure. :frowning:


:bulb: Oh! That reminded me to check the CPU in the inxi. Its a first gen AMD Ryzen CPU, which have some nasty C-state issues. If this "UI freeze" can't be rebooted from using REISUB, I am thinking this is the issue with the Ryzen 1700X and the c-states. There MIGHT be a way to fix this if the motherboard @ChillSheep has options for c-states.
If not, I highly suggest looking into a more recent Ryzen processor as even running the LTS kernel can only help so much (and a few months back even LTS didn't help my Ryzen 1700 anymore and I had to upgrade the CPU in order to fix the issue).


I understand, I had the system like this for some time though

I'll try this fix, since it all happened after a system upgrade after ~2 months, so the kernel was upgraded as well, the live boots had an older kernel
Also is there any tutorial for downgrading the kernel? In Manjaro kde typing kernel opened a helper that let you manage them, but it doesn't seem to show in my install of Garuda

Edit: Used LTS, still same problem

Also can you explain more about C-states? What should I look for in the bios?

Sorry for the spam of replies
New problem, now I had the whole "session" crash.
The screen went black, after some seconds the lock screen appeared, after entering my password, everything was like a fresh boot. I use luks and wasn't asked for my pw so the pc didn't restart.

Soo.... most things pot to a HW issue? If yes, is it definitely the CPU? It all started to happen after I switched my GPU too from a 1060 to a rx 6700xt. The 6700xt I got isn't new, but it has warranty and I don't think it is the problem since the guy I got it from tested it

Oh god there is absolutely no guarantee to that. :frowning: IF, if HW is the culprit, it could be pretty much anything... bad mem sticks, incompatible mem sticks with other HW, failing MB, failing CPU, failing GPU, failing HD, could even be failing power supply (I had one of these!). This is why the HW troubleshooting requires a lot of creativity to test various scenarios and isolate the component. On top of that, you sometimes don't even see any errors in journalctl. Not always easy to track!

Are you able to switch it back? That's a good HW test! Actually, that would be awesome if you could swap back, it would be easier to focus on something (software driver or GPU itself).

That doesn't mean anything, unfortunately. There are so many variables at stake, like what HW that guy was using and even if it's the exact same as yours, what if his was top shape but yours has one failing component...

It's hell when HW is involved. If you can swap for other HW that's a great way to isolate. If you can try more distros as well, like Ubuntu, Kubuntu, Fedora, etc... If you experience the same issue in all of them, you start to see a pattern.

But if in any way you can try another GPU, this would provide great data to troubleshoot deeper.


Aah I'll try to switch back, also the PSU is 650W and it's the minimum recommended so it sucks it can be anything, i hope i'll have the time (i wont be home for a few m again)

1 Like

Apparently with my old gpu it seems to work fine? Still had it stutter one time but not on that level... Can it be the PSU? It is rated for 650w and the minimum recommended wattage for the gpu is 650 too... Can it be a problem that the gpu is "daisy chained"? The same cables were used for both the 8 pins there (6+2 and another 6+2).

Your old GPU is using PCIe 3.0 and your new 6700 can use 4.0.

Can you test rollbacking to 3.0 in your BIOS, for all PCIe slots? (including 980 Pro)

I had issues when I got my 980, I enabled 4.0 although my NVIDIA was 3.0, for my MB it's not possible to segregate slot generations (even after web reading I had no indication of this back then!), so I ended up with issues until I disabled 4.0 and rolled back to 3.0. Then I swapped to a 4.0 PCIe AMD, enabled again 4.0 and all good.

Normally roll backing to 3.0 is easy and should not suffer any data loss by doing so.
This is well worth testing, with your new AMD of course.


Thanks! I have a MSI B350M Mortar which doesn't have support for PCIe 4.0.
Tomorrow morning I'll test with different DE as well to see if it's a KDE specific issue too.

1 Like

Excellent test!
Although you seemed to say that swapping back to your old GPU fixed the issue?
If yes the DE has nothing to do in that.

1 Like

It seems there is something with my setup with an AMD card (or at least navi 2) and KDE. I tried installing Manjaro GNOME and it seems to work perfectly fine with the AMD gpu in, with MESA drivers installed. This is very weird but it might be a bug in KDE? Or a bug in KDE with my specific setup?

1 Like

The good news is you are on the right track! It seems to be something around the GPU.

Maybe some better skilled persons can hop in and point out what to check/test from here. My suggestions would only be far fetched in this scenario. :frowning:

In the meantime if you google for your card running KDE you will certainly find something if there is a bug there.

BTW your understanding of the issue and acceptance to try various things in order to isolate the issue is very well appreciated! In Linux this is a great mind to have. Don't give up.