Kernel randomly crashes with no useful journalctl logs whatsoever

SaintFTS · 2026-02-22 19:54:51

My MX450+I71165G7 linux laptop randomly crashes the kernel. SysRq does not work, holding down the power button is the only way to shut the system down.

I used both nvidia-580xx-dkms and nvidia-open-590xx, but crashes persisted.

Here are full journalctl -b -1 logs right after crashes occurred: https://gist.github.com/saintfts/ca4e3f … 4ebcb1e8f1

First crash, i believe, occurred when i was just browsing the web using firefox.

Second crash occurred when i was casually testing basic template flutter app.

Last crash occurred when i held down "space" button to press flutter's app button that was selected (highlighed) by Tab. I held it down for 3 seconds, executing lots of onClick methods, and the laptop just froze. SysRq did not work.

Before these crashes i suspended laptop multiple times.

I wasn't able to identify cause of these consistent crashes using journalctl logs by myself . Thanks everyone in advance!

P.S: I memtested ram multiple times, all tests passed. My current setup has 32gb of swap and 8gb of zram

Last edited by SaintFTS (2026-02-22 19:56:53)

seth · 2026-02-22 21:18:45

After the last suspend and before the end

Feb 22 20:27:25 saintfts rtkit-daemon[6856]: Warning: Reached burst limit for user '1000', denying request.

happens *a* *lot*
So likely rtkit-daemon/pipewire/sound related?

Have you ever had this w/o sleeping the system first?

SaintFTS · 2026-02-22 21:40:38

seth wrote:

After the last suspend and before the end
Feb 22 20:27:25 saintfts rtkit-daemon[6856]: Warning: Reached burst limit for user '1000', denying request.
happens *a* *lot*
So likely rtkit-daemon/pipewire/sound related?

Well, i don't think it's really relevant. I forgot to mention that the flutter code looks like this:

    void _playMusic(String musicPath) async {
        await _player.setFilePath(musicPath);
        _player.seek(Duration(days: 0));
        _player.play();
    }

and this method's binded to the EvaluatedButton's onClick event, and i spammed it by holding space button (i have a logic bug in the code that sometimes throw exceptions or cause ui to replace widget with an error, maybe that's why there are so many of such logs in journalctl). Unfortunately, it's highly unlikely that pipewire alone is responsible for the crash

seth wrote:

Have you ever had this w/o sleeping the system first?

Nope, the crashes are so random that they can not show themselves for 7, 8 hours, and then, something strikes the kernel out of nowhere. That's the worst part of this - i have no idea when it occurs nor how to trigger it, and it's driving me crazy.

seth · 2026-02-22 21:46:15

https://wiki.archlinux.org/title/Kdump

SaintFTS · 2026-02-23 08:33:01

seth wrote:

https://wiki.archlinux.org/title/Kdump

Thanks for the response! I wrote a massive reply regarding the settings other people suggested on another forum, but this piece of sh*t froze literally right before I could hit send. But I noticed something strange...

!!!And now for the most important part!!!

In Ghostty, right before the crash, I couldn't copy anything from the terminal using Ctrl+Shift+C, even though that shortcut usually works flawlessly. BUT IT DIDN'T JUST FAIL TO WORK! Pressing Ctrl+Shift+C was inserting some kind of CODE into the current line buffer instead of copying the text—something like ~42u28 or something along those lines. I tried it several times, and it always inserted the same code, like when you press an undefined key sequence in Neovim/Vim.

**And KDUMP DIDN'T TRIGGER EITHER, at all, even though kdump works perfectly fine and without any issues when I manually use the SysRq 'PrtSc + C' combo.**

No, it didn't just run in the background, because I have disk encryption with a password, and I have to enter it every time kdump starts; so theoretically, it wouldn't have been able to write anything to the disk anyway.

But exactly 3 minutes before the crash, the Ctrl+Shift+C shortcut was definitely working fine, but this time there wasn't even a 'Copied to clipboard' pop-up. I had even pasted the output of /proc/driver/nvidia/params into that very message I was writing, and it had displayed correctly.

~ ❯ sudo ls -la /var/crash/
[sudo] password for saintfts:
total 0
drwx------ 1 root root  38 Feb 23 02:39 .
drwxr-xr-x 1 root root 136 Feb 23 02:39 ..
drwx------ 1 root root  56 Feb 23 02:39 2026-02-23-02:39:38  # <<<< This one was created by manually by me by triggering SysRq Kernel Crash combination
# <<< Nothing afterwards

Latest journalctl log:
https://gist.github.com/saintfts/2196ef … 44a8dcdefb

I'd already tried:

i915.enable_psr=0 split_lock_detect=off i915.enable_dc=0 i915.enable_guc=3 i915.enable_fbc=0 
nvme_core.default_ps_max_latency_us=0

Before the crash, laptop was in sleep mode (systemctl suspend'ed) for ~7 hours

Last edited by SaintFTS (2026-02-23 08:39:32)

seth · 2026-02-23 08:55:11

Feb 23 11:01:09 saintfts elephant[8916]: 2026/02/23 11:01:09 INFO providers p=clipboard results=129 time=28.924374ms

Esp. look at the time - that's a CPU eternity.
Disable elephant and see whether the system stabilizes, you might be running into OOM and swap thrashing.

SaintFTS · 2026-02-23 10:43:26

seth wrote:

Feb 23 11:01:09 saintfts elephant[8916]: 2026/02/23 11:01:09 INFO providers p=clipboard results=129 time=28.924374ms
Esp. look at the time - that's a CPU eternity.
Disable elephant and see whether the system stabilizes, you might be running into OOM and swap thrashing.

I really doubt it's elephant, since other logs did not have that issue. It seems like it's not the cause of the crash but the result of something that was already blocking the kernel at some level

seth · 2026-02-23 13:52:55

Maybe, but w/o any hard data slicing away apparent suspects is pretty much all you can reasonably do.
And the clipboard anecdote very much fits this suspect.
¯\_(ツ)_/¯

SaintFTS · 2026-02-28 09:37:14

So, nothing helps, i even increased limits for rkit:

[Service]
Environment=RTKIT_BURST_LIMIT=300
Environment=RTKIT_ACTIONS_PER_BURST_MAX=3000
Environment=RTKIT_ACTIONS_BURST_SEC=60

and:

options nvidia-drm modeset=1 fbdev=1
options nvidia NVreg_EnableGpuFirmware=0
options nvidia NVreg_PreserveVideoMemoryAllocations=1
options nvidia NVreg_TemporaryFilePath=/var/tmp

  cmdline: quiet splash acpi_mask_gpe=0x6E acpi.brightness_switch_enabled=0 intel_idle.max_cstate=1 crashkernel=512M i915.enable_psr=0 i915.enable_dc=0 i915.enable_fbc=0 i915.enable_guc=3 nvidia_drm.modeset=1 oops=panic panic=10 split_lock_detect=off

> cat /proc/driver/nvidia/params
ResmanDebugLevel: 4294967295
RmLogonRC: 1
ModifyDeviceFiles: 1
DeviceFileUID: 0
DeviceFileGID: 0
DeviceFileMode: 438
InitializeSystemMemoryAllocations: 1
UsePageAttributeTable: 4294967295
EnableMSI: 1
EnablePCIeGen3: 0
MemoryPoolSize: 0
KMallocHeapMaxSize: 0
VMallocHeapMaxSize: 0
IgnoreMMIOCheck: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
NvLinkDisable: 0
RmProfilingAdminOnly: 1
PreserveVideoMemoryAllocations: 1
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
RegisterPCIDriver: 1
EnablePCIERelaxedOrderingMode: 0
EnableResizableBar: 0
EnableGpuFirmware: 0
EnableGpuFirmwareLogs: 2
RmNvlinkBandwidthLinkCount: 0
EnableDbgBreakpoint: 0
OpenRmEnableUnsupportedGpus: 1
DmaRemapPeerMmio: 1
ImexChannelCount: 2048
CreateImexChannel0: 0
GrdmaPciTopoCheckOverride: 0
CoherentGPUMemoryMode: ""
RegistryDwords: ""
RegistryDwordsPerDevice: ""
RmMsg: ""
GpuBlacklist: ""
TemporaryFilePath: "/var/tmp"
ExcludedGpus: ""

but no use. Here are 3 new logs: crash_6 happened when i casually browsed web with firefox, others happened when i was developing a flutter app:

https://gist.github.com/saintfts/1b432b … 4b6d0939c3

P.S: all the crashes happened after the laptop was some time in "systemctl suspend". One log has ~17k lines because i did not let the laptop fall into suspend mode, and that's why it didn't crash for that long

Last edited by SaintFTS (2026-02-28 09:45:43)

seth · 2026-02-28 15:11:20

Cut out
* uwsm (strongly discouraged by hyprland upstream)
* elephant (conjecture, since all journals likely end well before the actual crash w/ the hard reboot we're hanging on the clipboard anecdote here and elephant is clearly a rather uncommon and very relevant player)
* fcitx5 (in case this is strictly input related)
and see whether you can trigger the "crash".

wrt nvidia, there's quite some noise from the i915 chip and I

Feb 27 13:42:00 saintfts kernel: nvidia 0000:01:00.0: [drm] Cannot find any crtc or sizes

suspect you're running on that anyway ("glxinfo -B" ?)
Are you using an external display?
About the nature of the crash, does the system still respond to ICMP requests ("ping")?
A

SaintFTS · 2026-02-28 16:04:40

my glxinfo -B:

> glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) Iris(R) Xe Graphics (TGL GT2) (0x9a49)
    Version: 25.3.5
    Accelerated: yes
    Video memory: 15224MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Iris(R) Xe Graphics (TGL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 25.3.5-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.3.5-arch1.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 25.3.5-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

It's capable of running apps on nvidia via prime-run/steam though

No, i only use laptop's screen

About elephant, since the clipboard contents is persistent throughout the reboots and crashes, and the system doesn't crash unless there was a suspend, elephant is not guilty here.

And uwsm is not guilty as well. It'd be obvious if the crash would occur right away/2-4 minutes after the suspend (e.g. negotiation between nvidia-resumed or nvidia-persistenced and uwsm), but i always run nvidia-smi and an app with high gpu use using prime-run after the sleep mode, and the laptop never froze during these tests.

I'll try PINGing the device during the crash if one occurs, thanks!

seth · 2026-02-28 19:36:04

And uwsm is not guilty as well.

seth wrote:

strongly discouraged by hyprland upstream

In reality we do not know what's to blame at all ("is not guilty because I don't want it to be" is pure superstition) and all we can do w/o *any* data to look at is to remove as many variables as we can and see what's left.

uwsm is a bad idea in any event, elephant is completely superfluous and maybe so is fcitx5 (depending on how badly you need it on a daily base)

SaintFTS · 2026-02-28 23:17:05

Well, new crash occured pretty fast.

Important additions:
1) It happened after i had closed the lid and opened it sometime after. It was working just fine for 12 hours, but after woke it up from lid suspension, 40 minutes after it's frozen again. I'm 99% sure that it happens only after i suspend it for long enough

2) Ping did not work. I have IP address reservation for my laptop, so its ip is consistent each boot. 100% packet loss

3) MOST IMPORTAINT DETAIL - laptop's internal keyboard backlight is responding to button presses - it lights up and after some time it disables on its own! But i couldn't disable its responsitiveness with Fn key, which i can do when the laptop is not frozen.

4) A music was playing in the background while the crash occured. It's looped like in old source (valve) games.

5) SysRq REISUB, along with C do not work.

6) tty's cannot be changed

7) 10 munutes after the crash (not rebooted yet) the laptop is mildly warm, but it's usually pretty cold when it's executing some complicated stuff (e.g. playing music and having a simple flutter app opened in the background)

8) I had opened intel_gpu_top and nvidia-smi 10 minutes before the crash - they were working fine

9) i did not use elephant at least 20 minutes before the crash

10) I had just tested some things related to laptop's USBs and HDMI ports: connecting hdmi to external display during the frozen state doesn't work - it doesn't see any signal. USBs are delivering power (tested with multiple devices, including a powerbank), but one of my keyboard, specifically the most advanced i have, doesn't even turn the backlight if i connect it via USB-C/USB-A, but other knockoff keyboard turns on the backlight (prob just uses usb-a power), but doesn't respond for CTRL nor NumLk.

Gonna post journalctl log soon

P.S: https://gist.github.com/saintfts/d7546b … b8af7d7c51

Last edited by SaintFTS (2026-02-28 23:21:26)

seth · 2026-03-01 08:53:45

A music was playing in the background while the crash occured. It's looped like in old source (valve) games.

That's common symptom of a kernel panic.

intel_idle.max_cstate=1 crashkernel=512M i915.enable_psr=0 i915.enable_tc=0 i915.enable_dc=0 i915.enable_fbc=0 i915.enable_guc=3 nvidia_drm.modeset=1 oops=panic panic=10 split_lock_detect=off cryptdevice=PARTUUID=65b281f1-1c72-4f8a-8591-3d6f162d6578:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs

"oops=panic panic=10"
Why?

"i915.enable_tc=0" is a typo for "i915.enable_dc=0"?

"i915.enable_guc=3"
Why are you trying to enable GUC w/ a tigerlake CPU??

"nvidia_drm.modeset=1" is default anyway

Assuming the commandline is the trsult of flailing, drastically simplify that and try

intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1 i915.enable_psr=0 i915.enable_fbc=0 crashkernel=512M cryptdevice=PARTUUID=65b281f1-1c72-4f8a-8591-3d6f162d6578:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs

The by far most important thing is to get a usable indicator of the freeze - kernel backtraces via bluescreen or in the journal or whatever.

Another thing you might try is https://wiki.archlinux.org/title/Intel_ … _Xe_driver - nb. that all other i915 parameters above will then become inert.

One more thing:

Hardware name: Default string be filled by O.E.M Default string be filled by O.E.M/Default string be filled by O.E.M, BIOS NB01.63 11/19/2024

What is that laptop actually? Where does its firmware come from?

Arch Linux

#1 2026-02-22 19:54:51

Kernel randomly crashes with no useful journalctl logs whatsoever

#2 2026-02-22 21:18:45

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#3 2026-02-22 21:40:38

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#4 2026-02-22 21:46:15

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#5 2026-02-23 08:33:01

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#6 2026-02-23 08:55:11

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#7 2026-02-23 10:43:26

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#8 2026-02-23 13:52:55

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#9 2026-02-28 09:37:14

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#10 2026-02-28 15:11:20

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#11 2026-02-28 16:04:40

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#12 2026-02-28 19:36:04

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#13 2026-02-28 23:17:05

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

#14 2026-03-01 08:53:45

Re: Kernel randomly crashes with no useful journalctl logs whatsoever

Board footer