2026-11-12 08:53 UTC
Replies (6)
-
@akunohana@piefed.blahaj.zone 2026-11-12 09:23
I’ve had similar issues when I ran out of system memory. It also didn’t leave any traces in the journaling program, but I think it did say something about it in dmesg. Not sure though. But since you’re probably using the VRAM and not the RAM, maybe this isn’t it at all? Just spitballing.
-
@Buffalox@lemmy.world 2026-11-12 09:29
Sounds like a long tedious elimination process is ahead. But since the only errors you get regard KDE, I’d try installing another desktop environment. Afterwards you can generally choose which desktop to log into at the login screen. And when it’s resolved whether or not KDE is the problem, you can easily switch back if you want. So it’s very easy to try. But each elimination will take 5 days!! If the computer behaves the same each time it crashes, it is definitely NOT random. If it was random it would be different things each time, and then it could be RAM or even CPU problems. But this sounds like a software problem.
-
@aSaabD00d@lemmy.today 2026-11-12 09:36
I had a similar issue on bazzite and I think it had to do with the Out Of Memory service. This link might help if that’s it.
-
@CameronDev@programming.dev 2026-11-12 09:44
How much RAM/swap?
-
@BananaTrifleViolin@lemmy.world 2026-11-12 10:11
Well drkronqi is a crash handler, and KDE connect has its fingers in multiple pies? You say theyre not relevant but who do you know when the crash is, if you only notice it when you try to use the PC and its unresponsive? I wouldn’t dismiss the timing of these crashes if you can’t say exactly when it stopped functioning. I’d start by increasing the logging levels to make them more detailed. You change the kernel and system logs to make them more detailed - how will differ slightly on your distro but essentially you want debug level system logs and lowest severity kernel logs. You can also setup some extra logging such as outputting system memory and vram usage to a dedicated file every second or so. This will.give you more information to hunt for the culprit. As others have said, my first thought from your useage and description is a memory issue. That could be RAM or vram - especially with the AI useage. I’d start by logging both to their own files; out of memory can crash without much trace if the logs aren’t tracking the right things. Also whatever process you are using - your AI tool for example - get that logging too.
-
@custard_swollower@lemmy.world 2026-11-12 10:26
I did have an old laptop with bad SSD that would have similar problem - cannot ssh, but can ping, and desktop quickly gets unresponsive. On root device issues kernel remounts root drive to read-only, and that breaks everything, but the machine still works - yet you get no logs because /var/log is also read-only. I did some googling and it seems SSH requires writable /tmp, so you might setup some in-memory one, if you haven’t already - you could check if your machine uses tmpfs (in-memory tmp) to reject this hypothesis.