Sounds familiar:
Since I updated from 4.0 to 4.1 in August last year, I’ve had random gui freezes with no possibility to recover, I just have to hard reset the machine every time (I’ve had 4 such freezes trying to write this on a stock new Qubes install, but that’s another story…)
I was checking some github issues and stumbled upon this: Qubes Update tool freezes machine · Issue #6156 · QubesOS/qubes-issues · GitHub
Pretty much the same as my reported freezing issues.
Also, update on this “freezing issues”: I seem to get 1 total system freeze per week now. Definitely better than what I was getting with i3wm + “screen tearing fix” I had previously with QubesOS. Back then, the freezing frequency per week was higher, in my anecdotal evidence.
I’ve watched these freezes for 6 months and it seems to me to be associated with whonix-ws-16. At least, the most consistent freezes occur when I start anon-whonix and use for a few minutes. I very rarely get freezes without anon-whonix being opened, but it does happen. I can’t figure rhyme or reason why it happens.
Sharing an anecdotal experience of mine: the frequency of the freezes I reported in this thread seems to have decreased. I haven’t got a total system freeze on me for some weeks now, even though during the time I had my machine working day and night, doing backups, working idle, etc.
So that’s encouraging. Thanks to the QubesOS dev team!
The only freeze and hard reboot I am experiencing now happened when doing qubes-dom0-update. Otherwise my Qubes 4.1.1 is stable. Using 6.1.12-1 kernel a xen 4.14.5 (after reboot).
Qubes OS if very unstable in my case. Unfortunately, I’ve had enough, I can’t recommend Qubes.
First, desiring to get rid of the reboots, I changed my RAM, CPU, motherboard, and power supply. Now I understand that the problem is in the OS. It’s crashing without any signals in the log, mainly on virtual machine start/stop.
So I still can’t boot into the system at the first time! Usually I am trying to boot five or more times to start all my appVMs. Then I am trying to keep my computer uptime 24/7, that is usually a week without the accident reboot. Starting an appVM turned into a reboot lottery.
I’m sorry you have had these problems. Thanks for trying so hard.
It would be helpful if you could share details of the hardware you have
used.
There is a hard regression in 4.1 that results in these problems for
some users. In some cases this seems to be linked to Qubes
starting/shutting down, and perhaps memory usage. In some cases there is
no log evidence.
It may be that these problems are resolved in 4.2, so it may be worth
your while checking in now and again and trying that release.
I hope to see you again.
Have you tried/tested kernel-latest? - if no, would you be willing to test it?
sudo qubes-dom0-update --disablerepo=* --enablerepo=qubes-dom0-current-testing kernel-latest
(in Dom0)
If you have issues booting, could you try temporally adding:
qubes.skip_autostart
to the kernel line at boot (hit e to edit the GRUB config, use the arrow keys to locate where it says quiet and replace it with qubes.skip_autostart)?
Maybe relevant for some coreboot users: Bug #121: T520: Hangs in OS - coreboot - Issue Tracker
I would like to report that my intel i7-3520M CPU (on Thinkpad X230) has been rock-solid stable since a month. I am on Qubes 4.1 with the latest updates installed. I have been using my setup for video encoding day and night and never had a freeze so far.
Ditto. On a Librem 14. Used to be that I had to have power-adapted plugged in for updates, but rock solid now.
5 posts were split to a new topic: ThinkPad (AMD) becomes unresponsive to input
A post was merged into an existing topic: ThinkPad (AMD) becomes unresponsive to input
7 posts were split to a new topic: Kernel-latest-6.3.2-1 not stable
The Qubes OS stability has increased significantly since last dom0 update. No single crash and reboot since then.
I’m even nervous about that 
user@dom0 ~ % cat /var/log/dnf.log
...
2023-07-14T13:54:33+0100 DEBUG --> Starting dependency resolution
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel.x86_64 1000:6.1.35-1.qubes.fc32 will be installed
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-devel.x86_64 1000:6.1.35-1.qubes.fc32 will be installed
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-latest.x86_64 1000:6.3.9-1.qubes.fc32 will be installed
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-latest-modules.x86_64 1000:6.3.9-1.qubes.fc32 will be installed
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-modules.x86_64 1000:6.1.35-1.qubes.fc32 will be installed
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-qubes-vm.x86_64 1000:6.1.35-1.qubes.fc32 will be installed
2023-07-14T13:54:33+0100 DEBUG ---> Package python3-qubesadmin.noarch 4.1.27-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package python3-qubesadmin.noarch 4.1.31-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-admin-client.noarch 4.1.27-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-admin-client.noarch 4.1.31-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-dom0.noarch 4.1.30-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-dom0.noarch 4.1.32-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-qrexec.x86_64 4.1.21-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-qrexec.x86_64 4.1.22-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-qrexec-dom0.x86_64 4.1.21-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-qrexec-dom0.x86_64 4.1.22-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-qrexec-libs.x86_64 4.1.21-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-core-qrexec-libs.x86_64 4.1.22-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-gpg-split-dom0.x86_64 2.0.67-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-gpg-split-dom0.x86_64 2.0.68-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-manager.noarch 4.1.28-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-manager.noarch 4.1.30-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-mgmt-salt-dom0-update.noarch 4.1.10-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-mgmt-salt-dom0-update.noarch 4.1.11-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-pdf-converter-dom0.x86_64 2.1.16-1.fc32 will be upgraded
2023-07-14T13:54:33+0100 DEBUG ---> Package qubes-pdf-converter-dom0.x86_64 2.1.18-1.fc32 will be an upgrade
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel.x86_64 1000:5.15.89-1.fc32.qubes will be erased
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-devel.x86_64 1000:5.15.89-1.fc32.qubes will be erased
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-latest.x86_64 1000:6.2.6-1.qubes.fc32 will be erased
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-latest-modules.x86_64 1000:6.2.6-1.qubes.fc32 will be erased
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-modules.x86_64 1000:5.15.89-1.fc32.qubes will be erased
2023-07-14T13:54:33+0100 DEBUG ---> Package kernel-qubes-vm.x86_64 1000:5.15.89-1.fc32.qubes will be erased
2023-07-14T13:54:33+0100 DEBUG --> Finished dependency resolution
2023-07-14T13:54:33+0100 DDEBUG timer: depsolve: 16 ms
2023-07-14T13:54:33+0100 INFO Dependencies resolved.
2023-07-14T13:54:33+0100 INFO ==============================================================================================================
Package Arch Version Repository Size
==============================================================================================================
Installing:
kernel x86_64 1000:6.1.35-1.qubes.fc32 qubes-dom0-cached 11 M
kernel-devel x86_64 1000:6.1.35-1.qubes.fc32 qubes-dom0-cached 14 M
kernel-latest x86_64 1000:6.3.9-1.qubes.fc32 qubes-dom0-cached 12 M
kernel-latest-modules x86_64 1000:6.3.9-1.qubes.fc32 qubes-dom0-cached 72 M
kernel-modules x86_64 1000:6.1.35-1.qubes.fc32 qubes-dom0-cached 65 M
kernel-qubes-vm x86_64 1000:6.1.35-1.qubes.fc32 qubes-dom0-cached 16 M
Upgrading:
python3-qubesadmin noarch 4.1.31-1.fc32 qubes-dom0-cached 446 k
qubes-core-admin-client noarch 4.1.31-1.fc32 qubes-dom0-cached 67 k
qubes-core-dom0 noarch 4.1.32-1.fc32 qubes-dom0-cached 703 k
qubes-core-qrexec x86_64 4.1.22-1.fc32 qubes-dom0-cached 170 k
qubes-core-qrexec-dom0 x86_64 4.1.22-1.fc32 qubes-dom0-cached 37 k
qubes-core-qrexec-libs x86_64 4.1.22-1.fc32 qubes-dom0-cached 25 k
qubes-gpg-split-dom0 x86_64 2.0.68-1.fc32 qubes-dom0-cached 23 k
qubes-manager noarch 4.1.30-1.fc32 qubes-dom0-cached 1.8 M
qubes-mgmt-salt-dom0-update noarch 4.1.11-1.fc32 qubes-dom0-cached 32 k
qubes-pdf-converter-dom0 x86_64 2.1.18-1.fc32 qubes-dom0-cached 27 k
Removing:
kernel x86_64 1000:5.15.89-1.fc32.qubes @qubes-dom0-cached 35 M
kernel-devel x86_64 1000:5.15.89-1.fc32.qubes @qubes-dom0-cached 60 M
kernel-latest x86_64 1000:6.2.6-1.qubes.fc32 @qubes-dom0-cached 39 M
kernel-latest-modules x86_64 1000:6.2.6-1.qubes.fc32 @qubes-dom0-cached 411 M
kernel-modules x86_64 1000:5.15.89-1.fc32.qubes @qubes-dom0-cached 309 M
kernel-qubes-vm x86_64 1000:5.15.89-1.fc32.qubes @qubes-dom0-cached 515 M
Transaction Summary
==============================================================================================================
Install 6 Packages
Upgrade 10 Packages
Remove 6 Packages
2023-07-14T13:54:33+0100 INFO Total size: 193 M
...
user@dom0 ~ % uname -a
Linux dom0 6.3.9-1.qubes.fc32.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 23 19:49:58 CEST 2023 x86_64 x86_64 x86_64 GNU/Linux
Since the week of July 29th, 2022 Update, QubesOS freeze, crash and reboots.
And I created this topic on the forum.
Today, August 18, 2023 and many updates later the same still occurs. I have never been able to find what caused the crash since July 2022. Before that period I never had QubesOS crash.
It happens when I move or drag a windows over the screen. Sometimes it happens. Sometimes it does not. Can it be related to a refresh rate, or a lag or something?
My solution is to avoid moving or dragging screens, but in the case a window opens partially outside the screen and you need to drag it to see it. And then it often crashes. But I have no choice.
As an update during July 2022 caused the issue, I was hoping for it to be resolved by now. But a year later and it still happens.
Does it crash if you right click on the window, choose “Move” and then press arrows on the keyboard?
(It never crashes on my Librem 15.)
Are you on i3 by any chance? Your post was a long way back in this thread and a number of useful “fixes” have been posted for this since then.
It happens when I move or drag a windows over the screen. Sometimes it happens. Sometimes it does not. Can it be related to a refresh rate, or a lag or something?
I seemed to have eliminated this by changing:
Window Manager → Focus → Focus model → Delay before window receives focus:
move it all the way left, then tap the right keyboard arrow 25-50 times to make it 25-50 ms.
I use focus follows arrow, but I’ve noticed it gets buggy when mouse focus hops back and forth very quickly between two windows (which occurs during resize).
My main problem right now is gntdev.c:406 errors are filling journalctl.
I was haunted by kernel freezes when using salt for about an half year. A few mount ago the issue disappeared, probably because of an kernel update.
I use i3wm on a Lenovo T430 with Heads.