It started freezing maybe a month or two ago. It happens anytime between a few seconds after the OS loads, to hours or days later. I do not recall downloading anything around when this issue began that could be suspect.
I’ve put off fixing this because I have no idea how to even begin troubleshooting it. Internet searches for “Linux freezes” returns practically countless potential problems.
What are some recommendations? I have my root directory on a 30 GB partition separate from my home directory, which I think makes reinstalling my base image (Debian) easy without losing personal data, so that’s an option. Maybe there’s a system log file that would provide some insight?
I’m Linux dumb so please teach me how to fish!
I’ll add that my Windows install (on a separate drive) doesn’t freeze, and my Linux install is on a new Samsung drive that didn’t report issues, so the problems unlikely hardware related.
dmesg/journalctl, then udev (
udevadm monitor) and lsusb/lspci might be helpful too. Places to look at (only if you fiddled with them):/etc/fstabfor mount options and do you maybe have a weird rule in/etc/udev,/etc/modprobe.dor/etc/sysctl?Which distro are you on?
Was there a kernel update recently by chance? Have you tried falling back to an earlier version? Got any timeshift backups?
Debian 12. When the freezing first started, I lied to myself saying it’ll self-correct with time. I’ve since lost track of which timeshift backup to use. I am a silly fool.
And there was no kernel update afaik.
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.
16gb seems huge.
Is there some sort of rubric you follow that leads you to that figure?
The rule of thumb is that you want at least the same amount of ram that you have (plus a little more just in case) if you have a laptop or similar where you’re going to use hibernate, since that works by moving whatever is in the ram into the swap.
Also, note that swap is basically emergency (and slow) ram. You want enough to handle any emergencies. Although I think it gets used before ram fills up completely. There are a lot of uses of ram where swap works just as well. Like if you got a program and/or browser tabs open in the background that you’re not presently using, it needs somewhere to store that data. And don’t forget about all the programs you may use that handle or process large files. Typically that gets loaded into ram (or direct to swap if fast access isn’t needed), and if ram can’t hold it, something that is used less is moved to swap.
But if there is no room, it keeps trying any way and it all freezes up like what op describes.
So… since people often have 16 gigs of ram in their machines, no, that isn’t a huge amount of swap to have. Even on my desktops I generally have at least 32 gigs swap just because I often do things that fill up a lot of ram. One of them has 64 gigs ram, and it can fill a good chunk of the swap as well if I try to render something heavy in Blender. Add on to that, I may have a vm open as well. That often uses swap along with filling ram. And of course general web use where it is normal to keep several tabs constantly open.
I want to make sure I have more swap than will ever be used. Because if it does get used, then that means it and ram is full and the computer will freeze.
One thing that I did when distro hopping was to have /home be separate like you have, but I would back it up elsewhere and let it be a clean start which I could bring over what I wanted from the backup.
It was easier than hunting down which dotfile the new distro didn’t like.
Others have already given some good advice, but rather than let it sit and wait to error, use the program “stress”
It’ll work specific components hard which can help locate whether it’s a CPU/Heat problem, or Memory, or disk.
And if it still fails on random things, take a long hard look at your PSU and measure voltages if you can. But if everything else checks out, motherboard could be it. Tiny cracks/dry joints, even inside the pcb layers, can lead to occasional problems that come and go with heat or vibration and are impossible to accurately diagnose beyond swapping it out.
This definitely can’t hurt and will probably help narrow it down, but it’s unlikely that OPs problem is hardware-related given that it doesn’t happen on Windows.
I can understand that view, but I’ve personally experienced things where it absolutely can be this and I respectfully disagree with you. I think what OP describes is more likely to be hardware than the OS.
Firstly - different drive for linux. A dying drive can freeze and take down its host, regardless of OS.
Secondly, linux uses memory very differently to windows, especially in relation to caching the filesystem. Linux might be accessing memory that Windows doesn’t get to.
We also don’t know what loads OP puts on his computer when running windows and linux. Maybe he has windows to game with, or may he uses linux for LLM/compute work and runs it full tilt. Each may do very different things and tax different aspects of the hardware.
It’s simply not safe to assume anything when diagnosing intermittent problems with hardware. The only reliable method is methodical testing and isolation.
Very good points.
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.
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.
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)
Maybe easier to another suggestion, you’re probably using a systemd based distros -
journalctl -b -1will show you the logs from the previous boot, so you could check that after resetting to see if anything was loggedFor 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
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.
Less destructive way would be to try to open a terminal session with ctr+alt+f3 (or any f key) If it’s only the gui that’s frozen. Makes it also possible to troubleshoot things from there. I had this issue recently. AMD core boost caused random freezes to kwin.
It froze again tonight. Neither ctrl+alt+del spam nor trying to change terminal session worked unfortunately. Seems to be 100% locked up.
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
Had the same issue and it was my mouse causing the USB ports to stop working I realized that the clock was still working and it would go into hibernate. Just wouldn’t respond to mouse or kb.
- Would be good to know the hardware you’re working, especially if it’s a laptop and the model.
- What kind of freeze is this? Black screen, frozen graphics, mouse frozen…etc. Also whether is time-bssed, and how long it takes to freeze.
- As a test, boot, and play music continuously until it freezes. Does the sound stop as well?
In all practical reality, Linux takes A LOT to topple over like this. It certainly would fair better than Windows with wonky hardware, but if it’s a laptop for example, maybe your fans aren’t working and therefore it’s a heat. Just try and define what kind of freeze it is first.
I’m running a desktop with relatively new hardware. Amd 5900x CPU, AMD 7900 GRE GPU, 32 GB ram, plenty of space and good airflow for stable thermals.
The freeze is definitely at least frozen desktop and mouse/keyboard. I also tried changing terminal sessions after a freeze tonight and this had no effect, so it’s probably the whole system?
Good idea with playing sound, I will try this on my next boot.
You could try to ping your machine from another device and see if it responds. I had issues with older nvidia card on a old system where it would lock up keyboard/mouse and video but the underlying system was still running and I could ssh into the machine and debug the problem that way. Another computer is obviously preferred but in a pinch a cellphone is better than nothing.
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.
It happens anytime between a few seconds after the OS loads, to hours or days later.
That will tell you relatively quickly if it’s a hardware problem or a software problem.
I mean, potentially not that quickly if they have to wait days for it to happen. Good low-investment-of-personal-time-and-effort suggestion though.
Yeah, I would give it a few hours to most of the day to test and then move on with something else. I really recommend journalctl though. Of course it depends on how long it stays on and how fast you can read the logs.
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.
Command line is your friend. It might not seem like it at first, but it is very helpful.
Use the
journalctlcommand 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.
