I feel like it possible bug in i915 driver at least it sounds so from symptoms , try add to boot parameters

i915.enable_psr=0 i915.enable_rc6=0

About log try enable debugfs

mount -t debugfs debugfs /sys/kernel/debug

When it freeze, after you’ve rebooted it, try running sudo journalctl -p 5 -b -1; you might see something in those logs.

Maybe also open a task manager before you do anything graphics intensive, just to see if there’s a process that rapidly increases its memory usage; while it might not be the cause, I’ve experienced similar freezes when I use all my memory (on a machine with 32GB of RAM).

A quick google search shows that many people have issues with the Intel Integrated Graphics on this particular PC (including on Windows) and this seems to be the solution: https://forum.asrock.com/forum_posts.asp?TID=17021&title=solution-for-intel-graphics-freezing-system

The main solution is Windows based but someone does offer a Linux route to the same solution, although a linked file that sounds like setting it up may be easier is missing. Essentially it looks like the chipset needs tweaking to throttle the GPU slightly to prevent the flaw triggering.

Are you sure you are not hitting swap too hard? Windows by default makes a bonkers massive page file, while most distributions try to limit wasting so much for swap.

If so, try installing SwapSpace

Frezze like not even the mouse is responsive? If is a yes, it’s a known bug for some chipboard and can be resolved easy. As soon as I get home I will look at it

SSH in from another machine, and sudo dmesg -w. If the graphics die, it can’t display new logs on the screen. If the rest of the system is fine, an open SSH session should give you more info (and allow you to troubleshoot further).

You can also check if the kernel is still functional by using a keyboard with a caps-lock LED. If the LED starts flashing after the “freeze”, it’s actually a kernel panic. You’ll have to figure out a way to obtain the kernel panic information (like using tty1).

After the “freeze”, try pressing the caps-lock key. If the LED turns on when pressing caps-lock, the Linux kernel is still functional. If the caps-lock key/LED does not work, the entire computer is frozen, and you are most likely looking at a hardware fault.

From there, you basically need to make educated guesses of what to attempt in order to narrow down the issue and obtain more information. For example, try something like glxgears or vkgears to see if it happens with only one of those, or both (or neither).

Linux is kind of dogshit at memory management unfortunately, due to a thing called overcommit it can essentially commit more memory than there actually exists on the system, cue potential for hard locks, stutters and freezing, there are some mitigations

Now the common recommendation is brute forcing the issue by making a swap partition or file, this is generally a bad idea on a modern system, due to the speed of ssds and even some fast spinning hard drives its possible for the kernel to get confused and think there’s enough memory spare where it becomes less snappy about clearing memory, often ironically making the problem worse, generally only use a swap partition if you need something else like hibernation

What should instead be done these days is setting up zram which essentially does compression of your memory in ram so that it stays clear for as long as possible, zswap does something similar but will also fallback to a swap partition soon after, the two are very similar so just setup zram on installs that dont have or need a swap partition, and setup zswap on ones that need or already have a swap partition(as they’re annoying to remove in an existing install)

But we’re not done yet because while this will buy you a lot of time there is still another massive issue at play, the linux kernel’s oom killer doesn’t generally care how full your memory is unless it starts biting into the kernel’s needs, this means it can take ages before it does anything even if everything is so overloaded where your display server has been hard frozen for 20 minutes, and since it has no real priority outside of the kernel it may force shut off vital processes first rather than secondary ones

To fix this you want a userspace oom killer that keeps in mind the entire OS and prioritises what needs to go first, many exist but if you want something that just works then EarlyOOM is great

With these mitigations in place your OS should become much less prone to freezing and stutters, if you really want a nuclear option there’s also cgroups

deleted by creator

Were you running dmesg on another screen or over ssh or something? I’d look in journalctl -b-1 after a reboot.

Is it completely frozen or does it respond to pings etc?

Were you running dmesg on another screen or over ssh or something? I’d look in journalctl -b-1 after a reboot.

Is it completely frozen or does it respond to pings etc?

Could still be a hardware issue that’s only triggered by certain code paths.

Update everything, BIOS, firmware, microcode, drivers. If it still freezes, the next step will be swapping out hardware components.

What video adapter is in there?

Have you tried dmesg over SSH? Sometimes you can get an extra message or two if the display freezes before the entire kernel does.

deleted by creator