Random freezes, how to troubleshoot

I saw this on xorg logs:
[ 16096.413] (EE) event4 - Corsair Corsair Gaming K55 RGB Keyboard: client bug: event processing lagging behind by 35ms, your system is too slow
Searching for that message I found [SOLVED] Laggy, sticky mouse input / Kernel & Hardware / Arch Linux Forums

Sounds like USB autosuspend kicking in on the dongle, try disabling that

I am going to try that, I believe I have to edit grub and add usbcore.autosuspend=-1 to disable it for all devices.

Nope, that was not it either. autosuspend was disabled, keyboard and mouse connected directly to the PC (no USB switch involved), no network card, nothing.
And the system just crashed again.
It was just there in the desktop, firefox was the only app running as usually, but was minimized.
I was having breakfast, I came back and the time on the desktop was stuck exactly at 10:45:41 when it should say more like 11:05. Pointer was working, tried to go to tty1/2/3/4, no response, REISUB nothing , and then the mouse stopped working too so I had to hard reset.

Now, the interesting bit, I think, the journal:

dic 26 10:44:57 thebronx systemd[1]: Starting Cleanup of Temporary Directories...
dic 26 10:44:57 thebronx systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
dic 26 10:44:57 thebronx systemd[1]: Finished Cleanup of Temporary Directories.
dic 26 10:44:57 thebronx audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
dic 26 10:44:57 thebronx audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
dic 26 10:44:57 thebronx kernel: audit: type=1130 audit(1640511897.253:156): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
dic 26 10:44:57 thebronx kernel: audit: type=1131 audit(1640511897.253:157): pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
dic 26 10:45:48 thebronx rtkit-daemon[1437]: The canary thread is apparently starving. Taking action.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Demoting known real-time threads.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 3684 of process 2003.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 3678 of process 1921.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 3221 of process 3101.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 2636 of process 1909.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 1781 of process 1586.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 1514 of process 1396.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 1500 of process 1396.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Successfully demoted thread 1396 of process 1396.
dic 26 10:45:48 thebronx rtkit-daemon[1437]: Demoted 8 threads.
...
the canary thread thing repeats for a few docen times after this

It is not the first time I see the Cleanup of Temporary Directories logs just before a crash. I will have to investigate what this thing does exactly and probably disable it. Whatever it does doesn’t sound that super critical, maybe it’s fine if I disable it for a couple days.

I have disabled systemd-tmpfiles-clean with:

systemctl stop systemd-tmpfiles-clean.timer
systemctl mask systemd-tmpfiles-clean.timer

I tried systemctl disable instead of systemctl mask but after restarting the timer was enabled again. With mask it seems to have been completely disabled.
To undo the change systemctl unmask systemd-tmpfiles-clean.timer should work.

To see all the timers that are enabled:
systemctl list-timers

I suggest you update system BIOS to v5.8 - ASRock > AB350 Pro4
(comments for v6.0 and above advise they are not recommended for a Summit Ridge CPU)

1 Like

Yeah, I could try that. But updating the BIOS is always a bit scary, and I would have to go to 5.40 first, then 5.80.

Most of the updates are to support newer CPUs though, which don’t really matter. There is one cryptic “Enhance USB compatibility.” and everything else is the AMD AGESA updates.
I wish they had proper change logs honestly, both ASRock and AMD AGESA.

Will try once I run out of ideas.
I tried creating /etc/X11/xorg.conf.d/20-amdgpu.conf:

Section "Device"
     Identifier "AMD"
     Driver "amdgpu"
     Option "TearFree" "false"
EndSection

That only made the grub screen bigger hehe.
Also tried changing my monitor displayport version to 1.2 instead of 1.4.
Then I went down to 120hz instead of 144hz (at 144hz I was experiencing flashes when playing youtube videos for example).
None of that really worked when it comes to the freezing problem.
Now testing a polling frequency of 125hz on my mouse, as it was set to 1000hz.

I guess I am pretty close to that point where I run out of ideas uh? :laughing:

It’s just that I don’t like updating the BIOS unless it is clear there is a problem there. If it was Windows freezing or crashing too it would be different but that’s not the case so I will leave that for later.

Thank you for taking the time to look at the logs and the ASRock website @nikgnomic, appreciate it.

I don’t want to jinx it but it’s been now a week since I updated the BIOS to 5.40 and then to 5.80 immediately after.
Not a single crash (should I say “yet”?).
It was crashing way more frequently before, 7 days is a record.

So, @nikgnomic sir, thank you! As I said thank you for taking the time to read this crashing monologue, for spotting the bios version and checking the ASRock page for updates, and not just say “update to latest” but “update to this version as it is the latest for your specific CPU”.
Even if it crashes again, so far it has been way way way more stable so thank you.

Can I buy you a coffee or something? or donate to a project in return?

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.