QubesOS freeze, crash and reboots

[ephile]

@Sven

I am sure there is a more elegant way, but here is my pedestrian approach:

• immediately after rebooting open dom0 terminal and run sudo journalctl
• press the End button on your keyboard

journalctl -r will reverse the order of the log entries so that you only have to scroll down a few lines to find the critical entries

[tanky0u]

@unman

This is a huge backwards step for me - I’m now working on the basis that
my machine may go down at any time.

I share the same feeling with my X220 Qubes setup.

@Sven

For me this happens exclusively during salt-based updates.

This has been my casual observation, as well.

So, what is there to do? Do we, as QubesOS users, have some fix to look forward to with this bothersome situation?

[Sven]

journalctl -r will reverse the order of the log entries so that you
only have to scroll down a few lines to find the critical entries

Thank you!

[Sven]

So, what is there to do? Do we, as QubesOS users, have some fix to look
forward to with this bothersome situation?

I ran a poll a while ago that gave me the impression that this issue is
not seen by the majority of users. From this thread here I get the
impression it mostly concerns users of older hardware.

My T430 is not purchased from Nitrokey but matches the top configuration
you can get from them … it is therefor identical to a certified
laptop. I wonder if the team sees the same issue when testing Qubes OS
on their certified laptop?

[ephile]

@Sven

I ran a poll a while ago that gave me the impression that this issue is
not seen by the majority of users. From this thread here I get the
impression it mostly concerns users of older hardware.

Both my T430s and my 7th Gen Carbon X1 have crashed randomly a few times since installing 4.1,

[whitedust]

same here

Random system freezes after 4.1 clean install

I can’t find a topic close to my issue. I have upgraded from 4.0 to 4.1 by clean install. at random times specially when i am alt + tabbing between windows, the whole system freezes. I cannot do anything except move my mouse cursor. mouse clicks do not look like it works. What is the best way to get logs to see what happened? i tried “journalctl -p 3 -x -b -2” but i don’t know what I’m looking for here

Are you all experiencing the issue when you guys are using ALT + TAB?
I notice its more common while I’m doing this inside a fedora VM

I have cycled through the available kernel version but all of them get the same freeze issue.

[Isolator]

Ok, so just now my Qubes system froze and then rebooted on dom0 update while I was doing some tasks in the other qubes. It never crashed on me on updates before, I don’t like this development, because it already takes ages to update, especially dom0, it literally can take more than an hour, and in qubes update tool you don’t even get any feedback…

anyway, I’m running qubes on AsRock H370M motherboard with Intel i5-8500
right after I switched to 4.1 I had graphical glitches with mouse cursor not rendering properly, especially at the borders of windows
I solved this by creating a file in /etc/X11/xorg.conf.d/20-intel.conf that contains

Section “Device”
Identifier “Intel Graphics”
Driver “Intel”
EndSection

But I still get occasional glitching/not properly rendering windows that I never got in 4.0, but it is enough to just switch windows around to solve this

Anyway, right before it froze I had this visual glitch again with half of the window being black.
And this time I got something in the logs right before – Reboot –

dom0 kernel: BUG: Bad page map: 1332 messages suppressed
dom0 kernel: BUG: Bad page map in process Xorg pte:8000000787137365 pmd:10e039067

– Reboot –

I’m also using kernel 5.15.64-1.fc32
I also don’t use sys-gui

[tanky0u]

@Isolator

it already takes ages to update, especially dom0, it literally can take more than an hour, and in qubes update tool you don’t even get any feedback…

Yes. I experience the same. Especially if I route the updates over the Tor network.

Regarding the logs: interesting. I hope they will provide the devs with some clue for a solution.

[enmus]

I had glitches and artifacts while never before. Even more. Some of my templates stopped working either by not booting or showing blank screen only, and temporary fix was to to reverse gui and gui-emulated values after which they worked again (!?)

[Isolator]

Ok, more logs.
Apparently this Xorg kernel bug is a recurring error
I can see these kinda entries repeating for 8-9 times already

[tanky0u]

the screenshot image is broken? I onlt see a green-ish image with no logs visible.

[Isolator]

yes, apparently it needs png images

[tanky0u]

now visible, thanks.

[0x9060]

@Sven

I ran a poll a while ago that gave me the impression that this issue is
not seen by the majority of users. From this thread here I get the
impression it mostly concerns users of older hardware.

Certified hardware

These all have a maximum of 16GB of RAM. Qubes is already a resource pig. My Thinkpad P51 has 64 GB or RAM and ran Qubes 4.0 perfectly. In fact, my laptop is provided in your list from this thread of those supporting Qubes 4.1.

Am I boxed into taking a step back in computational resources if I want hardware that is assured of running Qubes 4.1 stably?

It feels like a walled garden has quietly been constructed around Qubes OS.

[Sven]

@0x9060 instead of moving your post into it’s own thread let me try and
say this:

1. your post has nothing to do with the topic of this thread
2. your sentiments about RAM are echoed in countless other threads which
   you can easily find and participate in using the forum’s search
3. if you are serious about “walled garden” please start a new thread
   under ‘General Discussion’ and try to make an actual argument

Others: if you feel the need to respond, please do so in a separate
thread and keep this one focused on the topic at hand. Thank you!

[qub411]

For the record I just had another major freeze and reboot using kernel 5.15.64. I was simply moving a window (I use the i3 twm). Logs show the same as reported above: massive Xorg crash/bug:

– Reboot –
Oct 01 09:25:10 dom0 kernel: addr:000072ae93871000 vm_flags:1c0600f9 anon_vma:0000000000000000 mapping:ffff88810186dca8 index:1c54
Oct 01 09:25:10 dom0 kernel: page dumped because: bad pte
Oct 01 09:25:10 dom0 kernel: raw: 0000000000000000 0000540000000007 00000001fffffffe 0000000000000000
Oct 01 09:25:10 dom0 kernel: raw: 0027ffffc0003408 ffff8881156f5180 ffffea0004a4e000 0000000000000000
Oct 01 09:25:10 dom0 kernel: flags: 0x27ffffc0003408(dirty|owner_priv_1|reserved|private|node=0|zone=4|lastcpupid=0x1fffff)
Oct 01 09:25:10 dom0 kernel: page:00000000e5385bb0 refcount:1 mapcount:-1 mapping:0000000000000000 index:0x0 pfn:0x12937f
Oct 01 09:25:10 dom0 kernel: BUG: Bad page map in process Xorg pte:80000003445e0365 pmd:10b9fe067
Oct 01 09:25:10 dom0 kernel:
Oct 01 09:25:10 dom0 kernel: R13: 0000563f5af5f058 R14: 0000000000000069 R15: 0000563f59749e00
Oct 01 09:25:10 dom0 kernel: R10: 000072aeab02e000 R11: 0000000000000206 R12: 0000000000000009
Oct 01 09:25:10 dom0 kernel: RBP: 000072ae93870000 R08: 0000000000000008 R09: 0000000000000000
Oct 01 09:25:10 dom0 kernel: RDX: 00007fff4ea73850 RSI: 00000000003c8000 RDI: 000072ae93870000
Oct 01 09:25:10 dom0 kernel: RSP: 002b:00007fff4ea73838 EFLAGS: 00000206 ORIG_RAX: 000000000000000b
Oct 01 09:25:10 dom0 kernel: Code: 8b 15 21 6b 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb 89 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 0b 00 00 00 0f>
Oct 01 09:25:10 dom0 kernel: RIP: 0033:0x72aeaf35d37b
Oct 01 09:25:10 dom0 kernel: entry_SYSCALL_64_after_hwframe+0x61/0xcb
Oct 01 09:25:10 dom0 kernel: do_syscall_64+0x38/0x90
Oct 01 09:25:10 dom0 kernel: __x64_sys_munmap+0x28/0x40
Oct 01 09:25:10 dom0 kernel: __vm_munmap+0x75/0x120
Oct 01 09:25:10 dom0 kernel: __do_munmap+0x1f5/0x4e0
Oct 01 09:25:10 dom0 kernel: unmap_region+0xbd/0x120
Oct 01 09:25:10 dom0 kernel: unmap_vmas+0x83/0x100
Oct 01 09:25:10 dom0 kernel: unmap_page_range+0x17a/0x210
Oct 01 09:25:10 dom0 kernel: zap_pud_range.isra.0+0xaa/0x1e0
Oct 01 09:25:10 dom0 kernel: zap_pmd_range.isra.0+0x1cc/0x2d0
Oct 01 09:25:10 dom0 kernel: ? __raw_callee_save_xen_pmd_val+0x11/0x22
Oct 01 09:25:10 dom0 kernel: zap_pte_range+0x388/0x7d0
Oct 01 09:25:10 dom0 kernel: print_bad_pte.cold+0x6a/0xc5
Oct 01 09:25:10 dom0 kernel: dump_stack_lvl+0x46/0x5e
Oct 01 09:25:10 dom0 kernel:

…etc

[enmus]

As I said, it’s most probably not related to kernel, but to Qubes and/or Xen and something with gui

I also had these errors when freezing, having issues

[user@dom0 ~]$ sudo journalctl --reverse | grep “GPU hang”
Sep 29 xx:xx:29 dom0 kernel: i915 0000:00:0xx.0: [drm] Xorg[4220] context reset due to GPU hang

But after recent update of dom0 from later that day (stubdom-linux, xen and other major updates) haven’t faced it so far while on kernel 5.19.9-1

[Qubeuser]

I am on librem 14 and its crashing first keyboard always stop responding and then its down hill task bar disappears etc i have power off and on. Used reliably for over a year it just started happening past few days.

[Qubeuser]

This problem is really bad my librem is crashing 10 time a day!!!

[Qubeuser]

My librem is now even freezing on the boot up i get half way entering my disk password and it freezes