System freezing/hanging regardless of OS

Kusoneko · 2025-09-21 15:38:54

Hello,

I've moved recently, and ever since I've been having issues where the system hangs, essentially.

First, the system specs:
- CPU: AMD Ryzen 9 5950X
- GPU: AMD RX 6900XT
- MB: MSI MAG X570 Tomahawk Wifi (MS-7C84, bios version 1.J0)
- RAM: Corsair DDR4 128GB (4x32GB) 3600MHz w/ XMP, 2133 w/out
- drives: samsung 980 pro 2tb nvme (x2) (the first one is the boot drive), samsung 970 EVO 4tb sata (x2), WD black 8tb sata hdd
PSU: Seasonic 1000W 80+ platinum

The current OS is W11 pro, however I've been wanting to switch back to linux for a while and this hanging issue seemed to be a good time to get rid of it... Except it turns out the NT kernel isn't alone in hanging, hence why this thread isn't in Installation but in Hardware.

So. The symptoms:

Under Windows:
- boot hangs at the spinning wheel half the time
- hangs when idling
- doesn't hang when doing something, no matter if it's intensive for a particular piece of HW or not
- hangs when locked
- doesn't hang when locked with a slideshow on the lockscreen (??)

So I've made with Rufus 4 usb sticks, 3 latest arch and one gentoo so I can see if it's distro specific. The symptoms for linux happen on all 4 sticks (arch202509, arch202508, arch202507, gentoo20250914).

Under linux, the symptoms are:
- hanging during the installer's initial bootup, before the copy to ram stage
- hanging during the copy to ram stage
- hanging after a successful boot, a few seconds or minutes in (i tried rushing the archinstall script, it hangs before i finish the disk partitioning stage)
- nothing interesting shows up posthang if I do dmesg -w before it hangs

what I've done:
- ran memtest86+ (passed without errors)
- ran crystaldisk benchmarks on all drives (fine)
- looked at all drives health status (all good, above 85%, most above 90%)
- ran a CPU stress test (no hanging, finished successfully)
- updated the MB bios from 1.F0 to 1.J0 doing jumps version by version (hanging persists)
- opening up the PC and cleaning up, unplugging components and replugging them to ensure they didn't get partially unplugged or something (still hanging)
- removing the GPU entirely and putting it back (still hangs, this is currently the component I theorize to be the issue) (this sorta fixed an error that kept popping up but did not fixed the real problem obviously)
- booting the arch usb stick with nomodeset (still hangs)

things I've noticed:
- the PSU/MB still provides power to USB devices and still lights up internal RGB components, runs fans, etc. which leads me to believe the MB and PSU are fine.

The windows event log viewer couldn't be more useless (literally just notes that it booted up without properly shutting down, no error codes or other details, useless)

The linux dmesg seems to be pretty useless, mostly noting that devices are connected and configured and such and when hanging nothing new is added. I've considered trying to ssh into the installer and seeing if there's more but unfortunately, the switch the PC is plugged in has the lights on the port the PC is plugged in turn off entirely, implying no network connection at all.

The only errors I've managed to get are the following:
- during the bootup process of the arch installer:

scsi 5:0:0:1: asked for 1 got 8
scsi 5:0:0:1: failed to get diagnostic page 0x1
scsi 5:0:0:1: failed to bind enclosure -19
amdgpu 0000:2f:00.0: amdgpu: psp reg (0x16063) wait timed out, mask: 00000000, read: 0 exp: 00000000
amdgpu 0000:2f:00.0: amdgpu: psp reg (0x16063) wait timed out, mask: 00000000, read: 0 exp: 00000000
amdgpu 0000:2f:00.0: amdgpu: psp reg (0x16063) wait timed out, mask: 00000000, read: 0 exp: 00000000

(the scsi issue confused me for a bit cause I dont have scsi ports afaik, but the gentoo bootup process mentioned the ports and the devices and it seems they're the USB storage devices? presumably removing all usb storage devices but the archiso stick might remove that error entirely?)

- prior to removing and reinstalling the GPU, I also had the following errors, but haven't been able to reproduce them since:

watchdog: BUG: soft lockup - CPU#2 stuck for Xs! [pv:734]
CPU#2 Utilization every 4s during lockup:
o#1: 100% system,o 0% softirq,o 0% hardirq,o 0% idle
o#2: 100% system,o 0% softirq,o 1% hardirq,o 0% idle
o#3: 100% system,o 0% softirq,o 0% hardirq,o 0% idle
o#4: 100% system,o 0% softirq,o 1% hardirq,o 0% idle
o#5: 100% system,o 0% softirq,o 0% hardirq,o 0% idle
amdgpu 0000:2f:00.0: [drm] *ERROR* flip-done timed out
amdgpu 0000:2f:00.0: [drm] *ERROR* [PLANE:xx:plane-y] commit wait timed out
amdgpu 0000:2f:00.0: [drm] *ERROR* [CRTC:YY:crtc-z] flip-done timed out

(where X is an amount of seconds that increases every 30 seconds, xx is a random 2 digit number, y is a random 1 digit number, YY is a random 2 digit number and z is a random 1 digit number), the amdgpu errors varied in quantity each 30 seconds, but the content was otherwise the same with different numbers.

So, I'd like some help figuring out if my instinct stating the GPU might be dying is correct or if something else might be the issue before pulling the trigger on buying a replacement GPU. Especially considering how much buying a replacement 6900XT would cost, not looking forward to that.

Thank you for any help,
Kusoneko.

Scimmia · 2025-09-21 15:43:33

Have you tried plugging the PC into a different circuit?

Kusoneko · 2025-09-21 16:03:04

Scimmia wrote:

Have you tried plugging the PC into a different circuit?

Just tried, it's still hanging.

EDIT: the amdgpu flip_done timed out errors are back, but this time without the CPU soft lockup accompanying them.

Last edited by Kusoneko (2025-09-21 16:09:29)

Kusoneko · 2025-09-21 16:41:19

Okay, I had an idea to eliminate the possibility that the GPU causes the hanging. I had an old Nvidia GTX 660 lying around, removed the 6900XT, put the 660 in and it *still* hangs, so the 6900XT isn't the issue. Back to square 1 I guess. Now idk what could be the issue.

Tiikerihai · 2025-09-21 18:03:33

Have you considered the possibility that it could be the I/O die that's suffering? Maybe it has become damaged from high voltage. I don't have the same type of system, but when I enabled EXPO on my board with a Zen 5 the voltage it used for the I/O die was high at 1.3V. It might be fine for a while with that, but it's still really high. You could try setting all your UEFI settings to factory settings since you don't mention doing that and for hardware testing you could try a different CPU on the system with other components being the same to see if that has an effect. Of course you'd need to have another CPU to try, but it's an AM4 system so it might not be too hard to find one.

Kusoneko · 2025-09-21 18:48:18

Tiikerihai wrote:

Have you considered the possibility that it could be the I/O die that's suffering? Maybe it has become damaged from high voltage. I don't have the same type of system, but when I enabled EXPO on my board with a Zen 5 the voltage it used for the I/O die was high at 1.3V. It might be fine for a while with that, but it's still really high. You could try setting all your UEFI settings to factory settings since you don't mention doing that and for hardware testing you could try a different CPU on the system with other components being the same to see if that has an effect. Of course you'd need to have another CPU to try, but it's an AM4 system so it might not be too hard to find one.

I did not change BIOS settings outside of boot order, XMP and turning off secure boot when trying to boot up a linux distro installer afair. I don't have another AM4 CPU on hand however to test that option. Gonna look into acquiring a working but cheap one to check that I guess?

seth · 2025-09-21 20:09:21

- ran memtest86+ (passed without errors)

For how long? Cause one pass means pretty much nothing.

- looked at all drives health status (all good, above 85%, most above 90%)

Can you post the complete smartctl data?

watchdog: BUG: soft lockup - CPU#2 stuck for Xs! [pv:734]

Please post your complete system journal for such boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

for the current one.

Ceterum censeo: https://wiki.archlinux.org/title/Ryzen# … k_freezing
Edit: specifically CPU stress tests would actively prevent this one from emerging.

Last edited by seth (2025-09-21 20:09:54)

Kusoneko · 2025-09-21 20:51:56

seth wrote:

- ran memtest86+ (passed without errors)
For how long? Cause one pass means pretty much nothing.

Several hours, it did about 2 and a half passes before I had to stop it since I had to do something besides waiting for it to run through infinite passes.

I've also thought perhaps it wasn't enough and removed all but one stick, tried each individual stick alone but all 4 sticks, by themselves and together somehow do not affect the hanging issue.

seth wrote:

- looked at all drives health status (all good, above 85%, most above 90%)
Can you post the complete smartctl data?

I believe that was using Crystaldiskinfo or something like that on Windows, cause somehow there I can at least do things when booted, whereas in the rare occasions archlinux's install iso on my usb stick gets to the prompt, I have less than 30 seconds (actual amount of seconds varies from none to 10 in the majority of cases in fact) to do anything before freezing, im afraid i may not be able to get smartctl data for that reason.

seth wrote:

watchdog: BUG: soft lockup - CPU#2 stuck for Xs! [pv:734]
Please post your complete system journal for such boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
for the current one.

So like I said above this is all happening in the archiso put on a variety of usb sticks (just in case), and I can't seem to reproduce the CPU soft lockup issue, and I'm afraid since it's a read-only usb stick as far as arch is concerned, journalctl -b would get the current boot info but not any past boots, furthermore that long command string may not be typeable under the current time constraints I got when I get the prompt.

seth wrote:

Ceterum censeo: https://wiki.archlinux.org/title/Ryzen# … k_freezing
Edit: specifically CPU stress tests would actively prevent this one from emerging.

So if I manage to get to the prompt, presuming the ISO contains a CPU stress testing command it could buy me additional time while it's running? That sounds like such a weird bug "this CPU hangs up unless it's being abused properly".

Last edited by Kusoneko (2025-09-21 20:54:45)

seth · 2025-09-21 21:42:25

Try to add "processor.max_cstate=1" to the kernel commandline.

Kusoneko · 2025-09-21 22:04:20

seth wrote:

Try to add "processor.max_cstate=1" to the kernel commandline.

Interesting I seem to be able to go through the install stuff, I'll get back on if it works or not. One thing I can confirm is I've completed the entire archinstall menu except for the additional packages which I'm going through right now, which is farther than previously so that seems to be the entire issue, but we'll see if that fixes it entirely when I'm done and it's all set up.

seth · 2025-09-21 22:09:21

The most common problem is c-state 6 so if this ends up being stable (keep it at 1 for a day or so to be sure) you could try whether you get away w/ "processor.max_cstate=5"

Kusoneko · 2025-09-23 01:04:39

seth wrote:

The most common problem is c-state 6 so if this ends up being stable (keep it at 1 for a day or so to be sure) you could try whether you get away w/ "processor.max_cstate=5"

It's been running (still in the installer but chrooted into the future system as im busy and didnt (and still dont) quite have the time to set everything up for an actual boot and everything is still working with processor.max_cstate=1) for a day at least now, so it's safe to say that fixed it, still gonna wait a while before marking as solved in case it's a fluke (after all most of the day it spent doing fuck all today as i wasn't home, and tomorrow will be the same, wednesday however i should have plenty of time to finish setting up everything and then reboot and all that stuff.)

Kusoneko · 2025-09-24 18:46:54

Okay, so it has been running fine except for one issue, it isn't related to hardware, and has more to do with some sort of misconfiguration of cryptsetup/dev-mapper, mkinitcpio, grub2 and the various fstab/crypttab/etc that the installer script apparently made. I'm not quite sure how to fix it so I'll type the issue here and we'll see:

- on the archiso install I can easily decrypt and mount all filesystems and use arch-chroot to get into them. This is how I've been trying to diagnose and fix this latest issue so far.
- when booting outside of the iso, so directly on the install, it apparently decrypts and mounts the root filesystem and then gives out an error that there isn't a /sbin/init, which obviously since it's a symlink to /usr/bin/init, which doesn't exist cause I had it make /usr a separate partition. The issue is, in the archiso it seemingly has all it needs to decrypt and mount it, but the default system apparently does not? not sure where the misconfiguration is though. The setup as far as I understand it is like this:

(im replacing all of the uuids with mapper names for now cause they're annoyingly long to type)

fstab:

uuid=root / ext4 rw,relatime 0 1
uuid=boot /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
uuid=home /home ext4 rw,relatime 0 2
uuid=steam /mnt/steam ext4 rw,relatime 0 2
uuid=backup /mnt/backup ntfs ro,nosuid,nodev,user_id=0,group_id=0,allow_other,blksize=4096 0 0
uuid=usr /usr ext4 rw,relatime 0 2

out of these only root, home, steam and usr are currently encrypted and the backup drive will eventually switch to encrypted ext4 too when I move stuff off of it and place everything else so it can retake it's role as a backup drive rather than a temporary "hold this stuff i wanted to keep from windows" drive.

crypttab:

home UUID=home /etc/cryptsetup-keys.d/home.key luks,key-slot=1
steam UUID=steam /etc/cryptsetup-keys.d/steam.key luks,key-slot=1
usr UUID=usr /etc/cryptsetup-keys.d/usr.key luks,key-slot=1

mkinitcpio.conf's hooks:

HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems usr fsck)

grub's GRUB_CMDLINE_LINUX{,_DEFAULT}:

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"
GRUB_CMDLINE_LINUX="cryptdevice=UUID=root:root zswap.enabled=0 rootfstype=ext4 processor.max_cstate=1"

In short, I'm trying to figure out what archinstall missed for this usr on a different encrypted partition thing to work?

seth · 2025-09-24 19:46:36

cause I had it make /usr a separate partition

Why? And what made that? The archinstall script offers this???
https://systemd.io/SEPARATE_USR_IS_BROKEN/ (lennart casually ignores that he's responsible for a good chunk of the stuff that was broken before systemd broke it more)

Kusoneko · 2025-09-24 19:56:03

seth wrote:

cause I had it make /usr a separate partition
Why? And what made that? The archinstall script offers this???
https://systemd.io/SEPARATE_USR_IS_BROKEN/ (lennart casually ignores that he's responsible for a good chunk of the stuff that was broken before systemd broke it more)

Well, it doesn't specifically offer it, it just asks you for each partition where you want it mounted, but I guess I can easily switch it to be a separate /var partition then. I was essentially splitting it like so to save space on / but if / and /usr have to be the same partition, then I believe /var is the next one in line that tends to grow big? Presumably that one won't cause issues?

seth · 2025-09-24 20:28:58

https://wiki.archlinux.org/title/Partitioning#/var
Not if you frequently clean up

Btw, "processor.max_cstate=1", have you already tried "processor.max_cstate=5"?

Kusoneko · 2025-09-24 20:55:46

seth wrote:

https://wiki.archlinux.org/title/Partitioning#/var
Not if you frequently clean up
Btw, "processor.max_cstate=1", have you already tried "processor.max_cstate=5"?

I haven't yet, that's on the list of things to try today

Kusoneko · 2025-09-27 01:35:30

seth wrote:

https://wiki.archlinux.org/title/Partitioning#/var
Not if you frequently clean up
Btw, "processor.max_cstate=1", have you already tried "processor.max_cstate=5"?

Okay, so this is unfortunately later than planned due to a file transfer that took all night on that day, and now was the moment I finally got a minute to test. So I've tested max cstates 5, 4, 3 and 2 and they all cause hanging, 1 doesn't. I thought the issue was supposed to be only on 6, so I'm curious as to why this is, but otherwise I can probably live just fine with staying on 1.

seth · 2025-09-27 08:03:34

Does your BIOS allow you to adjust the PBO w/ the curve optimizer and does setting that +20 for all cores stabilize the system (on higher c-states)?
Or can you at least disable PBO?

Arch Linux

#1 2025-09-21 15:38:54

System freezing/hanging regardless of OS

#2 2025-09-21 15:43:33

Re: System freezing/hanging regardless of OS

#3 2025-09-21 16:03:04

Re: System freezing/hanging regardless of OS

#4 2025-09-21 16:41:19

Re: System freezing/hanging regardless of OS

#5 2025-09-21 18:03:33

Re: System freezing/hanging regardless of OS

#6 2025-09-21 18:48:18

Re: System freezing/hanging regardless of OS

#7 2025-09-21 20:09:21

Re: System freezing/hanging regardless of OS

#8 2025-09-21 20:51:56

Re: System freezing/hanging regardless of OS

#9 2025-09-21 21:42:25

Re: System freezing/hanging regardless of OS

#10 2025-09-21 22:04:20

Re: System freezing/hanging regardless of OS

#11 2025-09-21 22:09:21

Re: System freezing/hanging regardless of OS

#12 2025-09-23 01:04:39

Re: System freezing/hanging regardless of OS

#13 2025-09-24 18:46:54

Re: System freezing/hanging regardless of OS

#14 2025-09-24 19:46:36

Re: System freezing/hanging regardless of OS

#15 2025-09-24 19:56:03

Re: System freezing/hanging regardless of OS

#16 2025-09-24 20:28:58

Re: System freezing/hanging regardless of OS

#17 2025-09-24 20:55:46

Re: System freezing/hanging regardless of OS

#18 2025-09-27 01:35:30

Re: System freezing/hanging regardless of OS

#19 2025-09-27 08:03:34

Re: System freezing/hanging regardless of OS

Board footer