GUI randomly freezes

[GammaSQ]

Qubes OS version: 4.0

Affected component(s): GUI

---

Steps to reproduce the behavior:

Random. Happened three times by now and every time within ~30 min after boot. Couldn't find any other correlation, apart from the VMs started at that moment, but they are what I always start after bootup.

Actual behavior:

At some point, the GUI freezes but the cursor can be moved around. Nothing reacts, not windows nor xfce-taskbar buttons. Switching to tty2 (Alt+Ctrl+F2) takes very long. When switching back (Alt+Ctrl+F1), again taking very long, it appears the windows actually reacted to what I did before (they are brought to foreground / moved around), but the cursor doesn't move anymore and any keyboard-input is ignored. (i.e. I can't switch back to tty2).

General notes:

I thought this was a performance-issue, so I checked xentop and top in tty2, but there was nothing out of the ordinary. RAM usage was far below maximum every time, CPU usage was in the single-% range.

Anything else I could check when it happens again?

[GammaSQ]

Just happened again, twice in a row. This time, I tried killing xfce4, restarted with startxfce4. When returning to tty1, I was greeted by a login-screen, mouse was moving, but nothing else happened. (i.e. typing password did not show anything in the password-field)

I noticed that changing to tty2 first displays an error message three times: [1759.711636] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:36:pipe A] flip_done timed out

[marmarek]

Looks like a GPU driver problem, may be related to IOMMU. Try adding iommu=no-igfx to the hypervisor command line (options= in /boot/efi/EFI/qubes/xen.cfg).

[GammaSQ]

I'll try that!

Quick note: Xen claims iommu=no-igfx having an effect points to a bug, though they don't say weather it's a Xen-bug or dom0-driver-bug.

[mibmo]

I'll try that!

Quick note: Xen claims iommu=no-igfx having an effect points to a bug, though they don't say weather it's a Xen-bug or dom0-driver-bug.

Did that fix it for you?

[andrewdavidwong]

Is this still a problem in 4.1?

[GammaSQ]

No, 4.1 doesn't show this problem. Can be closed.

[andrewdavidwong]

Closing as resolved. If anyone believes this issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen it. Thank you.

[St3f1073]

Hello all, I believe I'm encountering a similar issue with my notebook when the second monitor is connected through the HDMI port. Notably, the problem only arises when the second monitor is connected. Randomly, the dom0 GUI gets stuck, rendering the machine unusable. During these occurrences, I cannot select any items on the desktop, and after a few seconds, the mouse freezes. At this point, the only solution is to force a hardware reset.

I've been unable to locate any logs that might report this issue. The only information I've found is that 'journalctl' logs the following lines when the problem arises: gen 03 12:49:10 dom0 kernel: i915 0000:00:02.0: [drm] ERROR [CRTC:131:pipe B] flip_done timed out gen 03 12:49:20 dom0 kernel: i915 0000:00:02.0: [drm] ERROR flip_done timed out gen 03 12:49:20 dom0 kernel: i915 0000:00:02.0: [drm] ERROR [CRTC:131:pipe B] commit wait timed out

I have attached the 'journalctl' and the 'hcl-report' for your reference. hcl-report.log journalctl.log

As you can see from the journal log, the issue arises at 12:49. Just a moment before the GUI got stuck, I had selected a VM update. From the journal, I can see that the update was correctly executed, so the system was working in the background, but the dom0 GUI was completely frozen.

As a newcomer to Qubes, I'm seeking your assistance in understanding the issue and guiding me through the troubleshooting process.

Any help would be greatly appreciated.

Thanks in advance

[andrewdavidwong]

@St3f1073: Please note that this issue tracker (qubes-issues) is not intended to serve as a help desk or tech support center. Instead, we've set up other venues where you can ask for help and support, ask questions, and have discussions. (By contrast, the issue tracker is more of a technical tool intended to support our developers in their work.) Thank you for your understanding.

[St3f1073]

@andrewdavidwong: Many thanks for your information. I'm new to Qubes, and I didn't use the issue tracker correctly; I apologize for that. It was not my intention to waste your time. I have already opened a case on the Qubes forum (https://forum.qubes-os.org/t/dom0-gui-gets-stuck-with-second-monitor-connected/23364). Thanks.