Linux

I had this same thing happen a while back. You know what it was? A bad USB device!

I had a little USB debug probe that went bad (somehow) and it totally screwed up my USB hub's ability to... Stay stable? Haha, that's the best way to put it.

Anyway, the fix was to remove the device and disconnect the USB hub (and its power) for a few seconds. If I ever reconnected the probe, the problem would recur within an hour or two.

Here's how you can check for something similar: Run dmesg and look for regular messages like, "unable to enumerate device". It'll tell you which bus and port it's on but that's not easy to figure out so just keep unplugging things until you get the one matching the device that's regularly throwing errors in dmesg. Keep it disconnected, power everything off (PC, USB hub's, etc) for a few seconds and then try running without that device for a while. It might be the culprit!

This sounds like a hardware issue. If you are lucky, it is a keyboard, mouse, or something. Doesn't sound like memory because you would possibly have memory errors or kernel panics.

This sounds very much like a swapfile issue. Check you have swap enabled and it is big enough for your needs.

If the swapfile is filled, the OS will lock up and advance very slowly. You can monitor swap in top or whatever you prefer.

Good news is this is trivial to fix.

If your system keeps losing time that may point to the need to replace the CMOS battery, but its rare for a mobo to be in use long enough to need that.

it froze, but I could still hear her over our call, and then it slowly advanced the display over the next couple minutes-

This means the system is not entirely frozen. The kernel is probably still running, but something is interfering with the display or some other subsystem(s). If SysRq key commands (reisub) worked on this system before the freeze, there's a good chance they will still work after it happens.

as in the mouse was moving very slowly according to how she was moving her mouse when it froze-

I have seen behavior like this caused by a buggy video driver. You might want to experiment with different Nvidia driver versions.

If that doesn't bear fruit, you might experiment with different kernel versions.

Edit 1: Also consider watching for kernel log messages when the problem happens (sudo dmesg --follow) or noting the time when it happens and then reviewing syslog/journalctl from that time after rebooting.

Edit 2: Also take note of anything that consistently happens shortly before the problem turns up, like the screen going to sleep and waking up. Some devices have trouble with power saving features.

I just want to second (third?) the possibility that it's an OOM. My system freezes in the same way when I run out of memory.

Generally it's because I have too many tabs open in Firefox, so I tweaked the Firefox settings to make it unload tabs when below a certain amount of free memory:

browser.tabs.unloadOnLowMemory	true  
browser.low_commit_space_threshold_mb	8192	
browser.low_commit_space_threshold_percent	25  
browser.tabs.fadeOutUnloadedTabs	true  
browser.tabs.min_inactive_duration_before_unload	86400000  

The above settings in about:config will start to unload tabs when you get below 8Gb or 25% of free memory. The "inactive duration" is set to 1 day so that Firefox doesn't just start unloading tabs unnecessarily.

Since I changed these settings, I always have at least 8Gb memory free for other programs. You could reduce those values if you want to use more of your memory for Firefox.

Fedora

GTX 1660 Super

freezing

Almost certainly a Nvidia issue, and that's such a deep rabbit hole, I don't even know where to start.

...It's not a fun troubleshooting/learning process.

The most expedient thing would be to try Bazzite or Nobara for a while. Both are Fedora based distros (so they're familiar), but they have better support for older Nvidia cards out of the box.

This would be a better long term solution anyway, as whatever's going wrong, you wont have to maintain it yourself through updates.

As others have suggested, it sounds like an Out of Memory situation.

Install earlyoom and tmux then run earlyoom in a tmux session and see if that helps, it will also give you handy logs to help debug.

I've had this issue and for me using earlyoom helped. My computer ram would fill up and the kernel oom killer wouldn't trip in time to be helpful. It could just be your memory filling up and your computer not killing the offending process in time.

My guess would be a hardware failure

Check all of the system components. That machine is quite old and could be having issues.

If it is really an Nvidia issue you could always pull the GPU.

Another troubleshooting thing you could do is setup SSH and monitor dmesg

Last time for me it was a bad CPU. Lived with it until I upgraded my CPU and recycled the old one into a new build. Then that one was having the same issue.

I have this exact same issue because of my GFX card.

I think it overheats but it could just be borked too.

I had this in KDE (I have Nvidia too...), it was when I was sharing or downloading linux ISOs. If you see this problem when downloading or moving files (like KDE itself freezing, changing volume, but it staying the same, changing brightness, but it actually staying the same), I recommend going after another DE while using nvidia, because I could never figure out why it only freezes on KDE (I changed a lot of things over the years, only KDE gave me this problem).

Are you doing anything like network mounts? I've had freezes happen when home was mounted remotely. I've also had freezes before -- though not recently -- when doing extremely intensive I/O operations. I've also seen it with failing hardware, but I don't remember what hardware was failing specifically (if we ever found out -- that was an always-on display system at work, and we might have just replaced it since it was ancient at that point...).

See if you can switch from GUI to console (either on the system or SSH-ing in). Usually the Ctrl-Alt-Fn keys switch between GUI and full screen console modes if you're physically there to try it. If you can get in, you might be able to get some insight into what's going on from logs, top, etc. while it's happening.

Have you tried logging in with a X11 session instead of Wayland?