you can also use the GNOME Logs app to peruse a lot of these logs, if you prefer.

You can install a memory stress test and run it from the boot menu (memtest86).

Could also be a CPU overheating problem and this can be caused by a defect CPU fan. On older systems, that could cause a specific signal when compiling the kernel.

Other potential cause could be file system corruption. Good idea to back up your stuff.

Is your swap big enough? Some installers default to only 1gig. That isn’t big enough normally.

If it fills the ram and the swap, it will cause what you are seeing. Typically the suggestion is a little more than however much ram you have. Personally I set it at either 16 or 32gigs or more. Depending on the machine and what I intend on doing with it and how much drive space I have available.

You can keep a system monitor open (or top, htop etc) and keep an eye on it when you’re doing something ram hungry, like having a bunch of browser tabs open or whatever. If it freezes and you look over and see the ram usage pegged to the top, that will suggest that that is your problem.

Hold the power button till the display goes dark. Then start up the computer.

You’ve mentioned in the thread you’ve on Debian 12 - have you installed mesa from backports?

The version of mesa on 12 is is 22.3.6 which is before the release of the 7900GRE and only very early RDNA3 support.

bookworm-backports has 25.0.7

If you read through https://backports.debian.org/Instructions/ you can enable the backports repo then just reinstall mesa (or dist-upgrade)

Do you have a Ryzen CPU by any chance? I had an issue like this for ages and it turns out it was a faulty Ryzen power state that was disabled by default on Windows, but not on Linux. If this happens to be your issue, there are ways you can disable the power state in software: https://wiki.archlinux.org/title/Ryzen#Soft_lock_freezing

I have some bad experiences with btrfs and timeshift schedules. I have laptops seen freeze for minutes when creating a btrfs snapshot. I have not specifically looked if you are using this combination but it is something to check.

There are many good answers here already, just wanted to add to it.

It sounds very much like what you’re seeing could be either a driver fault or a memory-related issue. Both can manifest as hard system freezes where nothing responds, not even Ctrl+Alt+Fx or SysRq. You mentioned this briefly before, and that still fits the pattern.

If it’s a driver issue, it’s often GPU or storage related. A kernel module crashing without proper recovery can hang the whole system—especially graphics drivers like NVIDIA or AMD, or low-level I/O drivers handling your SSD or SATA controller. Checking dmesg -T and journalctl -b -1 after reboot for GPU resets, I/O errors, or kernel oops messages might reveal clues.

If it’s memory pressure or the OOM killer, that can also lock a machine solid, depending on what’s being killed. When the kernel runs out of allocatable memory, it starts terminating processes to free RAM. If the wrong process goes first—say, something core to the display stack or a driver thread—you’ll see a full freeze. You can verify this by searching the logs for “Out of memory” or “Killed process” messages.

A failing DIMM or a bad memory map region could also behave like this, even if Windows seems fine. Linux tends to exercise RAM differently, especially with heavy caching and different scheduling. Running a memtest86+ overnight is worth doing just to eliminate that angle.

If your live USB sits idle for hours without freezing, that strongly hints it’s a driver or kernel module loaded in your main install, not a hardware fault. If it does freeze even from live media, you’re probably looking at a low-level memory or hardware instability.

The key next steps:

Check system logs after reboot for OOM or GPU-related kernel messages.

Run memtest86+ for several passes.

Try a newer (or older) kernel to rule out regression.

If it’s indeed a driver or OOM event, both would explain the “total lockup” behavior and why Windows remains unaffected. Linux’s memory management and driver model are simply less forgiving when something goes sideways.

Maybe easier to another suggestion, you’re probably using a systemd based distros -

journalctl -b -1 will show you the logs from the previous boot, so you could check that after resetting to see if anything was logged

For some other ideas to narrow down where the issue is…

If you’re stuck in the frozen state, you can Ctrl+alt+delete 7+ times quickly to tell systemd to try to restart the system. If this works, it means init was still able to process messages

If that doesn’t work, you could enable Magic Sysrq Key (if disabled in your distro), and then use the key sequence REISUB to try to see if the kernel is still responding and can reset the system

the /var/log/ folder would be the best place to start.

1. When a random freeze occurs note the time. Try to be as accurate and close to the time it happened as you can, including day, hour, and minute.
         A. If possible, do this for multiple instances of this happening

2. Check various log files starting with syslog and look at the times noted above. Look for any relevant errors being thrown by the system at these times.

https://wiki.archlinux.org/title/Intel_graphics#Baytrail_complete_freeze

Go to 6.15, there is your solution. I had the same very problem and with this it got solved.

If it’s freezing regularly, you could try booting a live usb of any Linux distro and see if it does the same thing. That will tell you relatively quickly if it’s a hardware problem or a software problem.

Sounds to me like your swap is to small. I had similar behaviour on two systems. One with 8gb of ram and one with 16 gb.

this is important, and will help you find solutions much more specific than just “system freeze”

• Right after a crash, once you reboot, run journalctl -b -1 and scroll to the bottom. Look for any big red text, all of that will be very helpful to diagnose this issue

Otherwise,

• Does it freeze permanently, requiring a reboot, or for a few seconds?
  • If it’s just for a few seconds, and you’re on an AMD system, it would sound like an fTPM stutter. A BIOS update would likely fix that, it was a widespread issue.
• Are you using an AMD or NVIDIA GPU?
• Do you play any games or use any software that uses OpenGL? (Blender and minecraft are some I’ve had problems in before)

Command line is your friend. It might not seem like it at first, but it is very helpful.

Use the journalctl command in a terminal.

Command Purpose Example
journalctl -u [SERVICE] View logs for a specific systemd unit/service. journalctl -u nginx.service
journalctl -b Show logs from the current boot. journalctl -b
journalctl -b -[N] Show logs from a previous boot (ee.g., -1 for the last boot). journalctl -b -1
journalctl --list-boots List all recorded boot sessions. journalctl --list-boots
journalctl -p [PRIORITY] Filter by priority level or a range. Levels are 0 (emerg) to 7 (debug). journalctl -p err…warning (shows errors, critical, alerts, and warnings)
journalctl --since=“[TIME]” --until=“[TIME]” Filter by time range. Supports absolute (YYYY-MM-DD HH:MM:SS) and relative times (1 hour ago, yesterday). journalctl --since “20 min ago”
journalctl -n [LINES] Show only the last N entries. journalctl -n 20
journalctl -k Show only kernel messages (equivalent to dmesg output). journalctl -k```

I spent a couple of days trying to figure out why I couldn't install any variant of Arch Linux or Fedora Linux on my laptop.  That command helped me narrow things down.