PREEMPT_RT causing instability and software crashes

[mintyTHPS]

I have used Gentoo (amd64) for some years without any issues or bugs, and no software crashes that weren't due to my own modifications. I use my computer for a lot of music production and often other forms of media production which is why I set PREEMPT_RT=y in my kernel. I immediately noticed a huge difference in behavior on many applications. My web browser would crash seemingly out of nowhere while watching YouTube, sometimes just downloading a game on Steam would cause everything else running to freeze for a whole minute or so, and many of these things would end up just crashing. I recompiled the kernel without PREEMPT_RT again and these issues went away. I have never actually just used the "Low-latency Desktop" option and I'm wondering if that option may be more suitable for my use case. But I have seen many desktop users claim that PREEMPT_RT has only been a benefit for them. I want to know if there is any other consideration I should make before building that into the kernel, or if this is a common occurrence on desktop systems.

Kernel: 6.12.16
File system: XFS

Computer hardware:
i9-12900KF
AMD Radeon RX 6900 XT
Z790 Pro RS WiFi
DDR5 G-skill 32G (2x)

[pietinger]

I would like to encourage you to check the new 6.13 kernel with the new PREEMPT_LAZY option (instead of PREEMPT_RT).


P.S.: See more: https://wiki.gentoo.org/wiki/User:Pieti ... 12_to_6.13

[Spanik]

I wanted to start a new thread because of issues with Virtualbox and 6.12.16 when I found your thread on top of the page. Just like you I have enabled PREEMPT_RT in my kernel for the first time. So I tried to check if this could be that cause. I tried 3 things:

Code: Select all

Linux daw 6.12.16-gentoo #2 SMP PREEMPT_RT Thu Mar  6 14:07:19 CET 2025 x86_64 AMD EPYC 7401P 24-Core Processor AuthenticAMD GNU/Linux

Virtualbox cannnot start the virtual machine and hangs, needs "kill -9" to even stop it.

Code: Select all

Linux daw 6.6.52-gentoo #1 SMP PREEMPT_DYNAMIC Sat Mar  1 13:07:08 CET 2025 x86_64 AMD EPYC 7401P 24-Core Processor AuthenticAMD GNU/Linux

My previous kernel, the same machine starts and works flawless.

So I recompiled my kernel and went back to "low latency desktop" PREEMPT_DYNAMIC=y. But with "make modules_install" I got this at the end:

Code: Select all

DEPMOD  /lib/modules/6.12.16-gentoo
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxsf.ko needs unknown symbol rt_spin_unlock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxsf.ko needs unknown symbol rt_spin_lock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxnetflt.ko needs unknown symbol __local_bh_disable_ip
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxnetflt.ko needs unknown symbol rt_read_lock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxnetflt.ko needs unknown symbol rt_read_unlock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxvideo.ko needs unknown symbol rt_spin_unlock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxvideo.ko needs unknown symbol rt_spin_lock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxvideo.ko needs unknown symbol __mutex_rt_init
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxguest.ko needs unknown symbol rt_spin_unlock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxguest.ko needs unknown symbol rt_spin_lock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxdrv.ko needs unknown symbol rt_spin_unlock
depmod: WARNING: /lib/modules/6.12.16-gentoo/misc/vboxdrv.ko needs unknown symbol rt_spin_lock

I next emerged (as always after a kernel rebuild) @module-rebuild and virtualbox-extpack-oracle. and rebooted.

Code: Select all

Linux daw 6.12.16-gentoo #4 SMP PREEMPT_DYNAMIC Sat Mar  8 14:25:40 CET 2025 x86_64 AMD EPYC 7401P 24-Core Processor AuthenticAMD GNU/Linux

The same VM that failed to start with PREEMPT_RT does start and works again.

[Hu]

I have used "only" the "Low-latency Desktop" mode for my system, and have always been quite happy with it. It seems preemptible enough for my use cases (though I do not do music production as OP does), and has been completely stable.

OP: as a general comment, when reporting a problem you suspect to be kernel related, you should tell us at least the exact kernel version (such as 6.13.5). It's possible that your problem is fixed in a newer version, but we cannot check that for you if we cannot determine what is newer than your affected version.

[mintyTHPS]

Sorry about that, I updated it (6.12.16). I may try the Low-latency desktop and see if that causes similar instability issues. I use the stable branch for most things so I may just have to wait to try the PREEMPT_LAZY option.