Random system freeze without any log, even kdump does not trigger

floriv · 2026-01-24 21:18:44

seth wrote:

The most likely cause is actually the early on linked https://wiki.archlinux.org/title/Ryzen#Troubleshooting - if you can disable PBO or tune the curve optimizer that's always worth a shot to see whether it stabilizes the system.

I switched back to the stable kernel today and didn't have a freeze. Yesterday I had one (LTS), and two days ago I must have had 15 (probably more, stable kernel).

I have now enabled PBO and set the curve optimizer offset to +4. I will report back.

seth wrote:

Have you *ever* witnessed such crash w/o AS running at all?

I only had the freezes when I had a Jetbrain IDE open. (Jetbrains is also the basis for AS)

Last edited by floriv (2026-01-24 21:25:21)

rocka · 2026-01-24 21:48:05

seth wrote:

Have you *ever* witnessed such crash w/o AS running at all?

Yes, for example it has freezed with mpv playing fullscreen. But it's relatively easy to reproduce with AS open so I'm using it to test the stability after I've changed some settings.

kalium222 · 2026-01-27 01:54:48

No more freezes since setting usbcore.autosuspend=-1 until now. See power management. But still testing.

floriv · 2026-01-27 16:29:54

kalium222 wrote:

No more freezes since setting usbcore.autosuspend=-1 until now. See power management. But still testing.

Unfortunately, it doesn't work for me. I had several crashes today. Netconsole does not give any meaningful output either.

What could be the reason why kdump kernel is not loading?

seth · 2026-01-27 20:49:41

For kdump to trigger you need a legit kernel crash - if your GPU driver tanks or so, that will not cause this - but you'd expect the sysrq to work under those conditions?

wtx · 2026-01-28 08:59:33

floriv wrote:

Unfortunately, it doesn't work for me. I had several crashes today. Netconsole does not give any meaningful output either.
What could be the reason why kdump kernel is not loading?

I'd try to run console over hardware serial port (assuming you have got it). AFAIK netconsole requires kernel network stack (among others softirq) to send data via ethernet. In case of serious issues there may be not possibility to send anything via network cards. Maintenance of serial port is much simpler, faster and doesn't need so many things as sending frames via ethernet. That is why I suggest to use physical RS232 serial port.

I'd suggest also if you have got some programming skills to configure kGDB over serial console. With this you could try to take a look at log buffer which in some cases has been filled with content but not printed on screen yet.

You may also switch from X11/Wayland to virtual terminal because in case of any calltraces you've got some chance to see them on the screen. Calltrace can be then analysed for any pointers what caused the hard lockup.

Kdump unfortunately doesn't let you catch the hardest issues as some of them can not be handled by software or just developers didn't handle them properly (very rare corner cases, etc).

juho05 · 2026-01-30 17:51:09

I connected my laptop to my PC with a serial cable. I used these cmdline parameters:

console=ttyS0,115200n8 console=tty0 earlyprintk=serial,ttyS0,115200

When I connect my laptop and boot my PC I see boot logs on my laptop and am presented with a login prompt. I tried logging in and running dmesg with:

sudo dmesg --nopager --raw --buffer-size 8 -W

When the freeze occurs I see that a new message is logged. Unfortunately, only the beginning of the timestamp manages to reach my laptop and I can't see the rest of the log message.
I tried playing with the buffer size and using --notime instead of --raw but the result is always the same.

Is there any way to more directly send the kernel messages over serial (without logging in and running dmesg etc.) to hopefully catch more of the message?
So far this is the most promising way to read the logs during the freeze. Up until now there were no logs, now there is the beginning of a log message.

seth · 2026-01-30 20:16:28

If the kernel is sufficiently compromised the network stack won't work.
Are you positive that rebooting w/ sysrq + REISUB doesn't work despite kdump no being triggered?
Do you get MCE errors after the reboot (indicating hardware problems)?

wtx · 2026-01-31 00:06:52

juho05 wrote:

I connected my laptop to my PC with a serial cable. I used these cmdline parameters:
console=ttyS0,115200n8 console=tty0 earlyprintk=serial,ttyS0,115200

Try to add to line above to cmdline:

loglevel=8  always_kmsg_dump=1

juho05 wrote:

When I connect my laptop and boot my PC I see boot logs on my laptop and am presented with a login prompt. I tried logging in and running dmesg with:
sudo dmesg --nopager --raw --buffer-size 8 -W

AFAIR with the options like "loglevel=8..." I suggested above the kernel should just print on serial console all the messages without necessity of running "dmesg" manually.

juho05 wrote:

When the freeze occurs I see that a new message is logged. Unfortunately, only the beginning of the timestamp manages to reach my laptop and I can't see the rest of the log message.
I tried playing with the buffer size and using --notime instead of --raw but the result is always the same.
Is there any way to more directly send the kernel messages over serial (without logging in and running dmesg etc.) to hopefully catch more of the message?
So far this is the most promising way to read the logs during the freeze. Up until now there were no logs, now there is the beginning of a log message.

The other option is as I wrote in my previous reply - using kGDB over serial console. I mean - in case when the system crashes you can try to run GDB client on the second machine and try do dump raw memory:

x/s __log_buf

or:

x/s log_buf

TBH the last time I used the kGDB over serial console was a few years ago and now I'm not 100% if the symbol to read kernel logs was: "__log_buf" or "log_buf".

I recommend using kGDB as in some conditions kernel may already have some log messages written in "dmesg" buffer but doesn't have any chance to print them on the screen or serial console. So kGDB gives you possibility to take a look at logs which have been stored in memory but haven't been printed yet.

Last edited by wtx (2026-01-31 01:26:10)

lcbcfoo · 2026-01-31 06:39:13

I am facing the same issue, I also think it is related to IntelliJ IDEs, in my case android studio.

Fresh Arch install, RTX5080 + AMD 9800X3D. If android studio is running the system crashes in less than 2 hours normally. SSH is not available, router confirms IP is not connected, it is a complete crash.

I was suspecting DRAM clock or GPU driver issues. I lowered a bit DRAM clock and did a test leaving 24h with GPU at 100% capacity running pytorch. No crash. Suspend + resume several times, no crash. Open android studio, crashes in a few minutes or 1h or so. Happens both in Linux 6.12 LTS and 6.18.

I also did not find anything useful in the logs... Just sharing what I tried so far.

juho05 · 2026-01-31 11:13:42

wtx wrote:

Try to add to line above to cmdline:
loglevel=8  always_kmsg_dump=1

With this I don't need to login and run dmesg anymore. When a crash occurs I unfortunately still don't get the complete log message. I tried a couple of times and all I get is the first letter:

[  252.824821] x

I don't have a lot of free time currently so I won't be able to try kGDB for a while.

Last edited by juho05 (2026-01-31 11:16:01)

rocka · 2026-01-31 13:35:21

I tried serial console with kernel cmdline

console=ttyS0,115200 console=tty0

and had the same result as juho05. When it crashes, there's only one letter printed to the console:

[ 1428.884250] x

After rebooting and checking the timestamp, I'me sure that "x" was printed right when the system crashes. Can it be xhci_hcd ?

Anyway I will try kGDB to see whether it can recover the full message.

wtx · 2026-01-31 16:03:58

rocka wrote:

I tried serial console with kernel cmdline
console=ttyS0,115200 console=tty0
and had the same result as juho05. When it crashes, there's only one letter printed to the console:
[ 1428.884250] x
After rebooting and checking the timestamp, I'me sure that "x" was printed right when the system crashes. Can it be xhci_hcd ?
Anyway I will try kGDB to see whether it can recover the full message.

Yes, it can be xhci_hcd but also can be some other string like x86.

Try to add ",keep" to "earlyprintk" so it can be like:

earlyprintk=serial,ttyS0,115200,keep

I haven't tested it but it may slow down the kernel.

Last edited by wtx (2026-01-31 16:06:55)

MarPop · Today 17:23:56

I posted this earlier in another thread for mistake. Not having time to look at pertinent threads, Iĺl post it again for people to share if they believe so. The problem lies in power states handling of the gpu. Could be AMD didn't disclose enough information - to linux ecosystem - on how to handle power saving dynamics (they say it's stable on windows). A nightmare that was resolved yesterday. I have a gb-BRR7H-4800 with Ryzen 7 4800u, and it used to block, crash, and all the rest described in your comments. Yesterday I disabled PSS Support BIOS option, and now everything runs smoothly and fast, though I cannot disable boost and/or use cpupower to regulate frequencies or policies (disabling PSS, ACPI is not exposed to the kernel). Now I have sway session and KDE session opened, and have tried all the sites where it used to crash.
Sorry, but I just registered here for the sake of letting you know how it has been solved here - to fix yours, at least temporarily, and to let know those in charge.

Arch Linux

#26 2026-01-24 21:18:44

Re: Random system freeze without any log, even kdump does not trigger

#27 2026-01-24 21:48:05

Re: Random system freeze without any log, even kdump does not trigger

#28 2026-01-27 01:54:48

Re: Random system freeze without any log, even kdump does not trigger

#29 2026-01-27 16:29:54

Re: Random system freeze without any log, even kdump does not trigger

#30 2026-01-27 20:49:41

Re: Random system freeze without any log, even kdump does not trigger

#31 2026-01-28 08:59:33

Re: Random system freeze without any log, even kdump does not trigger

#32 2026-01-30 17:51:09

Re: Random system freeze without any log, even kdump does not trigger

#33 2026-01-30 20:16:28

Re: Random system freeze without any log, even kdump does not trigger

#34 2026-01-31 00:06:52

Re: Random system freeze without any log, even kdump does not trigger

#35 2026-01-31 06:39:13

Re: Random system freeze without any log, even kdump does not trigger

#36 2026-01-31 11:13:42

Re: Random system freeze without any log, even kdump does not trigger

#37 2026-01-31 13:35:21

Re: Random system freeze without any log, even kdump does not trigger

#38 2026-01-31 16:03:58

Re: Random system freeze without any log, even kdump does not trigger

#39 Today 17:23:56

Re: Random system freeze without any log, even kdump does not trigger

Board footer