Ubuntu Desktop and PREEMPT_RT kernel issue

Canonical Ubuntu Ubuntu OS issues
1

Hi,

I am testing Ubuntu Desktop with the RT kernel on a Rubik Pi 3. After interacting with the GUI (e.g. moving the mouse cursor), the system becomes unresponsive - the desktop freezes, network is lost, and drm error messages appear on the debug tty interface (logs below).

Is it a known issue or is there a recommended configuration for running the desktop environment together with the RT kernel?

Environment

Board: Rubik Pi 3
OS: Ubuntu Desktop 24.04.4
Kernel: 6.8.0-1071-qcom-rt
Date tested: March 28, 2026

Kernel cmdline:

/proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-6.8.0-1071-qcom-rt root=UUID=131450ff-95bc-4791-b611-70855201b0cd ro console=ttyMSM0,115200n8 pcie_pme=nomsi earlycon console=ttyMSM0,115200n8 pcie_pme=nomsi earlycon irqaffinity=0-1,5-7 rcu_nocbs=2-4 isolcpus=2-4 nohz_full=2-4 pcie_aspm=off fsck.mode=force fsck.repair=yes

Kernel logs:

[  278.294313] [drm:dpu_encoder_frame_done_timeout:2459] [dpu error]enc31 frame done timeout
[  278.781129] irq 232: nobody cared (try booting with the "irqpoll" option)
[  278.781509] handlers:
[  278.781511] [<00000000eadffe51>] irq_default_primary_handler threaded [<00000000bce6dcae>] msm_irq [msm]
[  278.781668] Disabling IRQ #232
[  289.223808] Error sending AMC RPMH requests (-110)


[  118.085129] [drm:dpu_encoder_frame_done_timeout:2459] [dpu error]enc31 frame done timeout
[  128.945330] irq 232: nobody cared (try booting with the "irqpoll" option)
[  128.945693] handlers:
[  128.945695] [<00000000f73c08a6>] irq_default_primary_handler threaded [<00000000ec8fed8d>] msm_irq [msm]
[  128.945852] Disabling IRQ #232
[  129.957141] [drm:dpu_encoder_frame_done_timeout:2459] [dpu error]enc31 frame done timeout
[  132.741149] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0: hangcheck detected gpu lockup rb 0!
[  132.741322] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     completed fence: 10220
[  132.741468] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     submitted fence: 10221
[  133.764148] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0: hangcheck detected gpu lockup rb 0!
[  133.764316] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     completed fence: 10220
[  133.764464] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     submitted fence: 10221
[  134.789148] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0: hangcheck detected gpu lockup rb 0!
[  134.789317] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     completed fence: 10220
[  134.789464] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     submitted fence: 10221
[  135.749154] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0: hangcheck detected gpu lockup rb 0!
[  135.749328] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     completed fence: 10220
[  135.749475] msm_dpu ae01000.display-controller: [drm:hangcheck_handler [msm]] *ERROR* 6.3.5.0:     submitted fence: 10221
[  140.970456] msm_dpu ae01000.display-controller: [drm:recover_worker [msm]] *ERROR* 6.3.5.0: hangcheck recover!
2

We are currently syncing this issue internally.

3

Could you please share the specific use case or requirements for using the PREEMPT_RT kernel?

4

Thanks for the reply.
The PREEMPT_RT kernel is required because the system is used as an Ethercat master for servomotor control in a robotic application, so deterministic latency is needed. At the same time DE is used to provide robot UI.

Currently we are using an x86-64 Intel-based platform for that, but we are considering moving to ARM, and performance-wise QCS6490 looks very promising and Rubik Pi3 board has all the interfaces we need.