Skip to main content ↑ ↓
Topic: System Freeze With Nothing Opened (Read 1046 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

System Freeze With Nothing Opened

My system is completely unstable. I left laptop running with nothing opened for 30 min. The fan went haywire.  I loged in again, pressed ctrl+alt+T to open Konsole in order to type "htop" and couldn't type anyghing. Decided to close Konsole prssing "x" multiple times and the computer got frozen: Konsole got it greyed-out with "Terminate aplication blah blah" but never succeded to close it. Meta for KDE's menu worked. I switched to another system console with ctrl+alt+Fx (some are blocked by default??) and killed -9 Konsole, but couldn't get back to GUI.  Everything got messed up, something spewd about mounted /home, so I did REISUO.

Second time in a week I got f..ed. System is not stable anymore. 2-3 years OK. And now this? Any ideas? Cannot accept it anymore. I even turned off mitigations, but as you read above it doesn't matter.

In between the first (or two first) freezes I got KDE update, so I doubt its KDE.

$ uname -r
6.4.12-artix1-1

Re: System Freeze With Nothing Opened

Reply #2 –
I narrowed it down. Its a very serious problem here:

It looks like this.
f2fs_gc 8:1  <======== THIS EATS 100% CPU LOCING THE SYSTEM COMPLETELY.


It happens when I leave computer on overnight doing nothing.

only my home folder is f2fs. Was never happening.

Re: System Freeze With Nothing Opened

Reply #3 –
This 6-series kernel is a blast...
 

Re: System Freeze With Nothing Opened

Reply #4 –
I narrowed it down. Kernel needs a report from the file system before it engages in fsck.  The only file systems that talks to the kernel/"kernel is aware of" is ext4. If you hard reset, it will engage fsck for ext4. Alternatively you can configure the system/grub to force fsck for ext4 every n-th boot or have it time based (e.g. every two weeks).

When you have other file systems, lets say f2fs, lets say on /home (doesn't matter that you have "/" as ext4, having "/home" as f2fs is enough), then the kernel/f2fs do not talk to each other. F2fs would have to report to kernel to trigger the repair. If it doesn't kernel knows nothing and the repair will not be done.

Same goes for xfs.

Moreover each of these filesystems have different tools to repair the filesystem and different switches that can be confusing. For example f2fs has 3 switches for repair. Its not the main "-a", its not the second one, but the third one: "-f" (this should be programmed to use). Xfs has its own repair. So here we have:

- fsck.f2fs
- xfs_repair

The main fsck above would had to be linked to each depending on the file system. Kernel would also had to be aware if any errors are appearing (is it possible without first scanning, so kernel knows it should trigger the repair, even on another block device?).

And here comes the "best" part. Even if you have healty root partiton, but your '/home' has a very tiny error somwhere, in the case of f2fs it can take the whole system down (hence the 100% CPU usage and total freezes. You even don't have to do anything. Idle is enough).

Same goes for KDE and KDE Software (KDE Gears) are incompatible with other file systems. Like for example XFS. Some errors on xfs will freeze the software and freezes of the system will occur. It would be hard for system to unfreeze, i.e. you to kill the program. Its also worth mentioning that it may even be and external device that has xfs. It will "take you down". KDE is not resilent in this regard. It should show "cannot read" or similar insead of going 100% CPU on one single KDE (KDE Gears) program talking the whole system down with it. Esp. when its an external drive. Errors on external drive should not take down your system (reading files from external drive on xfs). Happens with KDE Gears but if you're using other software it does not trigger the bug. So KDE is very fragile and incompatible with other file systems. I repeat: Errors on external drive should not take down your system.

Temporary Workaround:

1. F2fs. Boot Artix Live. Install f2fs-tools and do this (more than once may be requred, boot again and do again in 2 days if it reappears):
$ fsck.f2fs -f /dev/sdX

2. Do "sdX" first. It should work. (Alternatively you can do the whole drive, but it may not work; be patient then ("searching for the secondary block ..."):
$ xfs_repair -v /dev/sdX

Conclusion:
Your whole system can be taken down with disks/block devices even if its not your "/" directly.

Future Solution:
Setting system/programming kernel so it repairs these file systems. Talk to each other. Do it periodically.
Reprogram KDE/KDE Gears so its not taken down while accessing file or reading files from a slightly corrupted disk (one tiny little place [on external disk] and you're "going down").


Re: System Freeze With Nothing Opened

Reply #5 –
Looks like an individual faulty hardware issue actually. I've never came across this on different machines and different distros (Artix, Void, Fedora, Debian).

Re: System Freeze With Nothing Opened

Reply #6 –
something cleared after months. Probably switching to NON-Default ZSWAP of lz4 and z3flod helped too. Maybe new kernels too and fixings for gcc malloc as well as scanning the drives.