Random System Crashes F40 KDE

Hi,

I’m having random system crashes. Screen freezes, after a few seconds the systems boots again. I looked through the logs, no graceful shutdown.
I also don’t see any errors before the crash.
Maybe you can suggest something I could do to produce data to analyze? I didn’t find any general mention in the AsahiLinux (github) wiki for reporting issues. (I’m also new to fedora.)
The same issue is reported on reddit (it’s the only thing that came up when I was search on how to report crashes): Whole system crashing : AsahiLinux

My system:

Operating System: Fedora Linux Asahi Remix 40
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.8.9-403.asahi.fc40.aarch64+16k (64-bit)
Graphics Platform: Wayland
Processors: 10
Memory: 15,3 GiB of RAM
Graphics Processor: Apple M2 Pro
Product Name: Apple Mac Mini (M2 Pro, 2023)

I just found the asahi-diagnose script, I put the output there:

(replaced user and hostname)

Can reproduce! Often get several freezes like this on my M2 MacBook Pro per day, however nothing shows up in the journal. Weird! I am somewhat sure it is related to KDE.

Well, actually I’m pretty sure that its not KDE related. I use Gnome, and started to see the same behavior since a while ago under F39. It is probably related to a kernel and/or mesa updates. Unfortunately, I didn’t test with older kernels, and I’ve upgraded to F40 already. Same thing happens in F40.

If anybody still uses F39, it’d be great if (s)he boots with older kernels to see if the problem is fixed (not any of recent 2 or 3 kernel updates in recent weeks).

Yes, I also had those crashes in the last days of using F39 (before F40 was released for Asahi) and upgraded to F40 early in the hopes they go away. Totally forgot to mention it.
Before that I never experienced a crash.

Seems like many people are having this issue. I also had this issue in about the last week of Asahi F39 and just as frequently in F40. (In fact, I just experienced one of these a few minutes ago… quite annoying!)

I’m also quite certain that it is not related to OOM issues as discussed on the reddit thread. I had 2 crashes today where I only had 2 Firefox tabs open and 2 files in my editor. I was below half my physical ram capacity for sure.

1 Like

I used to have heaps of OOM freezes (circa late 2022, early 2023), but most of those have gone away now. I can confidently say this is not an OOM freeze beacuse:

  • The system does not lag, stutter or slow down beforehand, it just freezes.
  • OOMs (in my experience) are logged in the journal. Nothing happens in the journal in this instance.
  • It automatically restarts after about 20 seconds, which is not something I’ve ever seen in an OOM crash.

ChatGPT spambot. Reported.

1 Like

Some additional information for maybe reproducibility, all my crashes today occurred while using a java application, this at least also means it is not native wayland.
In contrast I was also using Firefox quite heavily but no crash at all.

Maybe that helps the developers in regards to possibly narrow down what to use for stress-tests to reproduce this reliably. I currently don’t have the time to do that or the infrastructure to debug via m1n1 remotly or similar available.

1 Like

I saw this has also been posted in a different thread by another user (but deleted, probably because said author noticed there was already another thread.) This indicates that this is a widespread problem, and it occurs 2-3 times a day. I don’t use many Java apps (I have the LibreOffice Java integration disabled and the only Java program I have is Minecraft), so I don’t think it’s very likely that this is related to Java (in theory it shouldn’t bring the system down anyway).

Yes, I didn’t mean to say it was a Java specific problem, but that I was able to reproduce crashes the most while using it. As I don’t know the cause at all I’m just looking into how one could reproduce crashes more reliably / faster so that it is easier to analyze. Ppl who have the infra. available to reproduce it while in m1n1 hypervisor will be our best bet.

1 Like

I’m confident it’s not a memory leak. I logged memory usage over almost 24 hours every 10 seconds, and the usage is mostly stable.

Date       Time                 Total       Used         Free       Shared      Buff/Cache   Available
# Random earlier lines
2024-05-17 06:38:42             7506        6962         644        1848        2703         544
2024-05-17 06:38:52             7506        6962         644        1848        2703         543
2024-05-17 06:39:02             7506        6962         643        1848        2704         543

# Last three lines from file

2024-05-17 17:11:37             7506        6838         821        1849        2599         667
2024-05-17 17:11:47             7506        6727         876        1639        2499         778
2024-05-17 17:11:57             7506        6683         919        1580        2442         822

## The crash happened at 17:12:17 ##

I’m pretty sure this isn’t a memory leak, or else all the devs would’ve noticed (most of us have more RAM but any memory leak will exhaust all RAM over time).

We do, however, have known issues with deadlocking on OOM, and there may be a memory bloat problem which would particularly impact 8GB machines.

With just 800MB free it’s not unthinkable that a single action caused you to run out of RAM during the next 10 seconds.

Haven’t upgraded yet to F49, but facing a crash every few hours. Only app running was Firefox, with 5-10 tabs. M2 Air, 8GB. Couldn’t find anything in the logs, but attaching: Hastebin

Over the weekend I didn’t use any of my work related apps like my JetBrains editor (Java application I mentioned) and never had a crash but got into using swap, so over 16gb ram and about 8gb swap used. No crashes all weekend.
When I started work and was below 8GB ram usage the system crashes happened again. (The IDE was using < 1.9GB)
I’m very certain that the conditions that trigger “my” crashes are not “simple” OOM issues.
I would say 90% of my crashes are when using this Java application (JetBrains IDE), but that’s a bad sample to do statistics on, as I have it open ~100% of the time during work-week.

If had the hardware available I would try to gather data via m1n1 HV. Is there any other way I could try to help analysis efforts?

I also was not able to observe some specific action that always triggers a crash while using the JetBrains Editor.

1 Like

I have the same problem, as most others describe here, since a certain kernel or other update in F39 - impossible to say when exactly it started. On a Mac Mini M1 with 8GB. I increased my swap to 8 GB cause indeed my memory usage is often high, but the problem persists. I don’t think I’m using Java applications. Most often the crashes happen when I’m using Firefox with max. 10 tabs open. Somehow the OOM function doesn’t work because when I’m using zoom in a FF tab and browsing in another tab, I see the browser crashing in front of my eyes but instead of being killed it stalls the machine.

Can someone reproduce this? So keep a zoom call open in a FF tab and scroll in another tab, within minutes this stalls my machine.

Hi, I know, this is a Fedora discussion, but I experience the same thing on Ubuntu 23.10, kernel 6.6.0-1004-apple-arm, MacBook Air M2, 24G RAM, no swap. I’m using DisplayLink for external monitor, bluetooth keyboard and mouse.

The system doesn’t crash but becomes really slow. I did very extensive computation this time but sometimes it locks doing just light tasks like web browsing. Sometimes I’m able to switch to text console and do a reboot by Ctrl-Alt-Del.

My syslog during the crash: Ubuntu KDE lockup - Pastebin.com

It happened around 2024-05-22T14:40 time, but there are some slowdowns before this as you can see.
I was able to switch to console and reboot using keyboard on the MacBook (Ctrl-Option-fn-Backspace)

This is very off-topic. There is no crash and you are neither using an “Asahi packaged” distro nor even Fedora.
So to me you are not only writing to the wrong thread but also the wrong forum.

As I mentioned on Reddit: This is completely normal and is what happens when you run out of RAM on most vanilla Linux systems. This thread is about actual crashes. Slowing down to a crawl until the OOM killer triggers is what is supposed to happen (yes, it’s rather bad behavior, but this is a general Linux defaults thing and not an Asahi-specific issue).