Arch Linux

screen froze, and I was forced to reboot the PC by pressing the power button for 3s

seems like some data was saved, while other files were discarded

I would not worry too much about a somehow "forgetful" file system immediately after a hard power cycle. This is exactly what happens if data could not be flushed to disk. Thanks to journaling, your FS does not get corrupted, but data lingering in caches is still lost and discarded on fsck, to retain a consistent fs. I would recommend to repeat the installations you did before the crash, and maybe shove a manual sync behind it, to make sure you don't encounter totally weird "bugs" with man later, when you don't remember this as a cause anymore. Your bash history is saved to file on clean shell exit only, and is generally a bit non-intuitive, especially with multiple interactive shells in parallel, so I would personally disregard the old .bash_history file as "not a fault, only confusing" and let that rest, too.

Starting a long SMART self-test and a keen eye on the drive's error logs (smartctl -l error <drive>), or better yet, all available SMART info (-x), to see if anything seems fishy with your drive is a good idea, anyway. Keep in mind that your mainboard / drive controller or its connection may just as well be (intermittently) faulty. In ye olden times, a defective disk cable or socket was messing up my system once or twice. You will see particular faults in your syslog, though - this is not invisible. You don't only get a kernel panic without some sprinkling of I/O errors as well. If your drive is SMART-OK, but you clearly get disk I/O errors, time to inspect and clean the SSD socket and contacts and re-seat once more. If you never saw any disk I/O errors, and your disk's logs are clean, I'd consider the SSD as not an issue.

If you encouter random kernel panics, random as in "in different and unrelated call stacks that do not make sense in any other way", I agree that RAM is a likely culprit, or an electrical fault somewhere on the mainboard. It's rare, but it happens. If you can, replace (only) the mainboard, or better yet, take a working PC with compatible parts, and replace the working MBO with your suspected broken one to see if the previously working machine now faults. "Carrying the fault with you" is easier/quicker than proving an intermittent fault gone.

Unless you get different kernel panics, my money's still on your c-states handling. I'd prefer the lowest level you can find to inhibit your CPUs from going to sleep, i. e. BIOS > kernel boot args > sysctl > cpupower, to keep the stack thin. If that is finnicky somehow, you could alternatively boot with a single CPU and leave the rest disabled (bootarg nosmp). The point is just to find out where to focus your attention, not to keep this as a long-term workaround.

To keep N CPUs running, I usually just background N infinite loops in bash:

$ cpus=4; for i in $(seq 1 $cpus); do { while true; do true; done; } & done 
[1] 7185
[2] 7186
[3] 7187
[4] 7188

In your case you might change that to:

cpus=4; for i in $(seq 0 $((cpus - 1))); do { taskset -c $i bash -c 'while true; do sleep 1; done'; } & done

To just kick each CPU every second, it does not have to be stressed. The taskset will bind each loop to one CPU, to prevent the system from cleverly distributing the tiny load. This could also become a terrible, terrible workaround to keep running if all else fails. :)