You are not logged in.
The system would freeze randomly, and the log just shut after freeze, no any log or panic about it. Sometimes it will reboot because of freeze.
I've tried to fsck because I thought it might be some filesystem issues caused kernel to switch root into read-only mode. And this doesn't work.
If I'm using latest kernel, the system would reboot every time the system freeze, and with lts kernel, it just freeze for about 5 second and recover, with no log, too.
Because I don't know what the problem is, so there's no log about this, sorry for lack of logs.
Device Info:
Device: ASUS TUF GAMING A15 2022
CPU: AMD Ryzen R7 6800H
GPU: NVIDIA RTX 3060 Mobile
Hard Drive: Samsung PM9A1 512G(pcie 4 nvme)
Is there any suggestions for me to get more info about this or solve this?
Last edited by Misaka19465 (2022-10-22 06:10:04)
Offline
https://wiki.archlinux.org/title/Ryzen#Troubleshooting
When the ystem "freeezs", do not reboot it w/ the power button but use https://wiki.archlinux.org/title/Keyboa … el_(SysRq) to try to sync the filesystem and unmount the drive.
Also pay attention to MCE errors at the head of the next boot.
You should also stress-test your RAM https://wiki.archlinux.org/title/Stress … MemTest86+ (this usually needs multiple cycles to find issues, so let it run at least over night)
with lts kernel, it just freeze for about 5 second and recover, with no log
That is *highly* unlikely, what log did you look at?
Try "sudo journalctl -b" (journalctl w/o privileges will only show you the session log)
Offline
When the ystem "freeezs", do not reboot it w/ the power button but use https://wiki.archlinux.org/title/Keyboa … el_(SysRq) to try to sync the filesystem and unmount the drive.
Actually, it reboots automatically, not beacuse of my actions like pressing the power button.
Also pay attention to MCE errors at the head of the next boot.
I've noticed this already, but there's no MCE errors
You should also stress-test your RAM
Right away
That is *highly* unlikely, what log did you look at?
Try "sudo journalctl -b" (journalctl w/o privileges will only show you the session log)
I DID look at "journalctl -b", but there's only logs before and after the freeze, and nothing for the freeze
Offline
Actually, it reboots automatically
Undercurrent or overtemperature? (Next to RAM issues)
Also see the first link I posted about the AMD curve optimiser.
Offline
Undercurrent or overtemperature?
If it is, it will at least show a log, so it can't be, I thought.
Also, I've tested my RAM, and there is nothing wrong.
Offline
If the system reboots instantly, there's no log left.
Also
this usually needs multiple cycles to find issues, so let it run at least over night
Running one cycle of memtes86+ tells you nothing at all. "Over night" is on the short side, you'd usually talk about days to find errors in such kind of synthetic test.
Offline
After my test, RAM seem to be alright. I bought this laptop for only three months, so it mustn't be, unless this laptop is renewed lol
With infos this gave, freeze seem to be reduced, but with latest kernel, but reboot issue still exist, so there are more than one thing caused this maybe?
Offline
Bad or badly configured RAM is bad or badly configured RAM - the age hardly matters.
Did you increase the CPU voltage?
Please post the complete system journal of a boot directly after such spontanous reboot (sudo journalctl -b | curl -F 'file=@-' 0x0.st)
Offline
Log of reboot on linux-zen kernel
Just like what I've said, the log just shut when the reboot happens.
And I haven't done any overclock or overvoltage.
Offline
If that's the journal of the boot that crashed that's useless - it's the journal of the boot *after* the crash that might have some information.
Though obviously test the non-zen kernel and also
And I haven't done any […] overvoltage.
read the wiki again: the CPU not getting enough voltage is a common cause for this
To solve this problem you need to supply higher voltage to your CPU so that it is stable when running at peak frequencies. The easiest way to achieve this is to use the AMD curve optimiser which is accessible via your motherboard's bios. Access it and put a positive offset of 4 points, which will increase the voltage your CPU is getting at higher loads.
Offline
If that's the journal of the boot that crashed that's useless - it's the journal of the boot *after* the crash that might have some information.
Though obviously test the non-zen kernel
non-zen kernel act the same.
read the wiki again: the CPU not getting enough voltage is a common cause for this
increasing the voltage didn't help.
Offline
No MCE errors, no trace of the spontanous reboot
Unrelated, but you've dhcpcd and NM concurrently enabled and they stumble over each other.
=> Pick one, disable the other.
The log of the crashing boot is only 3 seconds, it's not clear because the journal will stop at whenever it last was synced to disk, but do those crashing boots (always) crash immediately?
Offline
Sorry for long delay, I left home for a week.
I didn't really understand "immediately", but what I got is just as normal boot, stable for some minutes, then crash.
Offline
The system would freeze randomly
just as normal boot, stable for some minutes, then crash
The inital post sounds like this happens randomly, your last post seems(?) to confirm that either a boot is stable or it is not and in that case crashes very early.
Absent any hard data, we'll need to hook onto every behavioral pattern you can get (at least for insta-reboots, kernel crashes could be captured through https://wiki.archlinux.org/title/Kdump )
If you boot the system and leave it alone for "some minutes" to you find it "crashed" when you try to login?
Does it "crash" when you only log into the multi-user.target (and crush some time w/ eg. any of https://archlinux.org/packages/communit … bsd-games/ )
Offline
the 'ramdomly' means that crash is not predictable. As long as I stay the machine on for a while, in the end, it must crash. Also, "some minutes" doesn't mean very early, but to show crash is not predictable.
After adding all the suggestions, freezing issue seem that it has been solved, but crash, reboot issue continued, so the reason of freeze and crash are not the same, I guess.
Does it "crash" when you only log into the multi-user.target (and crush some time w/ eg. any of https://archlinux.org/packages/communit … bsd-games/ )
multi-user would also crash.
If you boot the system and leave it alone for "some minutes" to you find it "crashed" when you try to login?
the crash has no relation with my specific action, so this didn't happen as well. Only keep away from the laptop and doing nothing would help the system not to crash.
Offline
the crash has no relation with my specific action
and
Only keep away from the laptop and doing nothing would help the system not to crash.
are contradictive.
There may be multiple "actions" causing this, but if "doing nothing" prevents the reboot, *something* you do is relevant.
multi-user would also crash.
What did you do in the multi-user target / console login?
Offline
Sorry for my poor English. Actually, I meant any of my actions might cause the crash, not some specific actions.
What did you do in the multi-user target / console login?
I compiled the kernel for two time, the second time crashed. It might be relavant between high CPU or disk usage and the crash?
Last edited by Misaka19465 (2022-09-17 13:36:55)
Offline
It might be relavant between high CPU or disk usage and the crash?
CPU, RAM or disk I/O
Let' assume you've rules out the RAM, try to isolate the CPU:
https://wiki.archlinux.org/title/Stress_testing#stress
You can also fire
echo "scale=5000; 4*a(1)" | bc -l
a couple of times in parallel (to hit many/all cores)
(It btw. calculates Pi, nobody cares about the output and if you increase the "scale" it'll take much longer)
Offline
I tried to do CPU stress test under 5.19, it crashed, but it seems that the test didn't boost the crash to happen.
Also, there is nothing wrong under 5.15 lts kernel.
Offline
I had the same problem, and my machine is the same model as yours, ASUS TUF GAMING A15 2022, This problem only occurs when using the latest kernel.
Offline
I had the same problem, and my machine is the same model as yours, ASUS TUF GAMING A15 2022, This problem only occurs when using the latest kernel.
So maybe some hardware disigning issues?
Offline
So maybe some hardware disigning issues?
I have no idea, I couldn't find any useful information.
Offline
My RX 6600 has lots of freezes with latest kernel. Have you tested LTS-kernel?
Last edited by bitterhalt (2022-10-06 23:10:04)
Offline
I upgraded to the 6.0 kernel today, I tested it for more than an hour this morning, and there was no previous problem, maybe it has been fixed? I'll be testing a little bit more lately, and I'll come back and tell you if there's a follow-up.
Offline
I upgraded to the 6.0 kernel today, I tested it for more than an hour this morning, and there was no previous problem, maybe it has been fixed? I'll be testing a little bit more lately, and I'll come back and tell you if there's a follow-up.
Well, I'm overly optimistic, and the problem remains.
Offline