You are not logged in.
I switched to Arch from Windows on my 2022 Zephyrus G14 (GA402RJ), because I keep getting BSOD on Windows. I'm already somewhat familiar with Arch, but most of the things I do are based around following guides or other people's posts. I wouldn't say I can come up with a solution to something I haven't seen/
Anyways, I get random crashes on Arch as well, the screen freezes, I can't do anything -- after a while I get logged out but still can't type or anything. At this point I can only suspect bad ram, which is unfortunate since there is a soldered memory channel, and one removable channel. I still get the issue if I remove the single stick of memory.
I would really appreciate it if someone could check the output of `journalctl -b -1`, and let me know if it is indeed a RAM issue, and if so how do I find the bad ram addresses through the journalctl logs? Or should I do a memtest86+? For the latter, I was thinking that it wouldn't find all the addresses that are messed up, and if I simply added them while it happened, eventually I would get to the bottom of it.
Output: https://pastebin.com/gaEdmFmN
I appreciate any help in advance, thanks!
Edit: Currently, I am testing the Intel AX210 as a replacement to the Mediatek network card. My jaw is practically on the ground from how well the system has been working but I'm still a little skeptical. I also updated to the beta bios found here: https://www.asus.com/support/faq/1049059/. I hope that crashes won't occur anymore but I will update within the next few days.
Last edited by jattila (2025-05-09 03:45:01)
Offline
Hi.
You should test for all possible errors, bad RAM could show this behavior, but it could also be anything else. If you don't have ECC memory the logs won't help you.
First thing, install memtest86+, reboot, choose it in the boot menu and let it run for at least a whole night (longer is better). If this doesn't report errors after a long time, your RAM is probably fine.
Have a look at your disk health with something like gsmartcontrol, run the extended self-test. Post attributes here if you don't know how to interpret them.
Test your CPU with prime95 from the mersenne project (stresstest only) it will tell you if your CPU has a problem or straight up crash. Install lm-sensors to watch out for overheating.
Use furmark to test your GPU, watch temps.
Use furmark + prime95 together to test maximum heat/load of your system.
Offline
Thanks for getting back to me,
I an memtest86+ for 8 hours, 0 errors. And here I was thinking it was a RAM problem this entire time. I believe it did 13 passes or something so I hope that was enough.
I changed out the NVME for a different one to see if that was the issue. But I will run the tests that you mentioned just be sure, as it might be the related controller or something, and will update you with any findings.
Offline
The system seems more unstable now after the test. I'm not sure if that did something. Also I did notice that the system is suspiciously stable when booting from the live USB -- how was it able to run the test for 8 hours with no crashes when Arch or Windows crash after 2 minutes.
I ran the gsmartcontrol disk health test, and it passed the test. But the things that were lacking from the live USB was Wi-Fi and the NVME. Someone mentioned that their issue was caused by the mediatek drivers, so I'm going to replace the Wi-Fi card with the AX-210, first off because it's better and possibly better support on Linux.
Anyways, some more tips from here would be appreciated. How would I know if it's an issue with the NVME seating or something like that? Maybe there's some dust in the bay?
Offline
Surprisingly, putting in the intel AX210 has made things much smoother. I also updated my BIOS to a beta version, that was released much more recently than the stable version available from ASUS. I will update if it starts crashing again, but so far good news.
Offline
I started getting crashes, it seems like only on battery power that it happens. Could someone take a look at the following output of journalctl -b -1? I'm guessing it's something to do with the dGPU on batteery power, thanks in advance:
https://lesma.eu/fawavisi (expires in 100 hours, pastebin wasn't responding)
Offline
I'm not that familiar with systemd logs. The NVMe errors look strange, but if SMART said the device is fine it might be a driver issue.
Since you mentioned it only happens on battery, you could try acpi=off or processor.max_cstate=0 boot options: https://wiki.archlinux.org/title/ACPI_m … leshooting
Offline