You are not logged in.
I ran mkinitcpio -P before rebooting
cat /proc/cmdlinewill tell you whether the parameters were applied - did you get a panic report for the latest occurrence as well? Or the system journal for the boot?
froze at 90min uptime yet again
Is there any pattern (time or usage-wise) to this? Is there a temperature limit?
W/ the page fault were're oc still in the realm of unstable RAM.
Offline
I ran mkinitcpio -P before rebooting
cat /proc/cmdlinewill tell you whether the parameters were applied - did you get a panic report for the latest occurrence as well? Or the system journal for the boot?
froze at 90min uptime yet again
Is there any pattern (time or usage-wise) to this? Is there a temperature limit?
W/ the page fault were're oc still in the realm of unstable RAM.
Yes, here is the output of cat /proc/cmdline :
initrd=\amd-ucode.img initrd=\initramfs-linux-zen.img root=UUID=f5fdea1a-3851-4c32-a944-c84705967219 rw rtw89_pci.disable_aspm_l1=Y rtw89_pci.disable_aspm_l1ss=Y rtw89_core.disable_ps_mod=Y pcie_aspm=offOddly enough, even when idling a game this time (to facilitate GPU usage) I did not receive a kernel panic. The system journal still does not show the moments of the crash (freezes so even SysReq is unusable).
The only concrete pattern I notice is that it occurs around 90min uptime (with at most that i have seen at about 92min). Temperatures are cool and I get the same numbers as I have gotten since I had this computer.
An additional note is that I idled overnight on a windows install and no freezing or BSODs occured.
Since I have tried the live ISO of Cachyos and it froze the same way, could it be an obscure issue with arch/based distros?
Last edited by qxbash (2026-06-03 23:34:04)
Offline
could it be an obscure issue with arch/based distros?
It's more likely an issue w/ more recent kernels => https://aur.archlinux.org/packages?O=0&K=linux-lts
An additional note is that I idled overnight on a windows install and no freezing or BSODs occured.
Have I pointed you towards the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
?
occurs around 90min uptime (with at most that i have seen at about 92min). Temperatures are cool
Leaking RAM/GART/GTT?
Can you keep the system running longer when frequently (every 30m or so) isolating the multi-user.target (implies killing your GUI session and all GUI clients!) and in doubt reclaim memory, https://unix.stackexchange.com/question … ree-memory (using heads and tails should do
)
Offline
An additional note is that I idled overnight on a windows install and no freezing or BSODs occured.
That is intersting. As far as I am aware, AM5 is very temperamental about 4 sticks of ram so I try to avoid it.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
I ran another 9+ hour memtest overnight and received over 19,000 fails on a memory address. This occurred heavily around the 90 minute mark(s).
Although I should've done it sooner, I am in the process of RMAing all 4 of my ram modules.
I will update as soon as I can test the new DIMMs
Here are the memtest results:
Last edited by qxbash (2026-06-06 01:00:33)
Offline
DIMM is 66°C at this point?
Can you do something to physically keep the system cooler (open it and blow a room fan at it)?
Offline
It would be interesting if you reboot before 90 minutes time limit hit for crash - would you gain next 90 minutes or not?
Disable all power saving options in bios.
Offline
Hello everyone. After a pretty long wait, I ended up receiving 4 new DIMMs from TeamGroup.
It seemed to fix the issue of freezing, there was indeed bad blocks on the old ram.
Thank you all again for helping me with troubleshooting.
Offline
FWIW, after switching to btrfs and zfs (only for raidz), I find that it is a good overall system health indicator. If something is wrong, errors are reported by the integrity checks in short order, which would have been silent on ext4 till it crashes.
Offline
although using zfs myself as for OS i still recommend ext4 or xfs - and setup your system in a way the os becomes disposable/replacable and your data on the zfs pool independent of the os
os on the same pool is not something i would setup (or os on any raid for that matter)
Offline
Actually, this is exactly my approach. Fully documented and hence disposable OS install (and thus can be on ext4, easy to recover from issues as well), with data on separate drives on FSs better suited to data integrity. Even this puts all the hardware components through the extra checks.
Offline