I recently swapped most of my hardware, going from intel to amd. I run Manjaro, usually with the acs patch. But after using the system for about a minute or two, it would hard crash. This is consistent. After regenerating mkinitcpios turning on and off different settings in my bios (IOMMU and virtualization). The crashing is persistent, reviewing logs and dmesg reveals nothing scary, but if they are needed I can try to get them and post them here.
My motherboard is an Asus X570-e gaming wifi 2 with a Ryzen 7 2700x. A 2080 Super and RX260x.
I am very sure the issue isn’t hardware based, I booted windows and played doom eternal on Ultra Nightmare settings, I had zero issues. I am at a loss. What could be happening? Do I need to reinstall?
I booted into a live usb and everything was fine. So I have no clue what the issue was. I imagine something might show up in dmesg but probably just before it crashes, which would be almost impossible to catch real time. Are dmesg or kernel logs stored somewhere that I could check?
I think it’s also useful to mention that now KDE doesn’t start, it simply starts into the manjaro web terminal. When attempting to start sddm manually, nothing happens. I’m thinking this could be some sort of issue spawned from the crashing? As in from crashing so often maybe some things are corrupting? Or just straight up breaking?
After booting into manjaro and letting it crash, the log seems innocuous. Everything including the kernel is just going about it’s processes and then just stops. And the stopping point is not the same between crashes. I will try to get the latest logs and post them here.
Hmm - Don’t really see anything in the log, aside from TOR crapping out. Not sure if that would cause anything though.
There may be some other logs you can check in /var/log/
I didn’t see this before (or maybe it was the edit?). Did you end up changing out your GPU config as well? If you’re running X (and not wayland), there may be some gpu specific configuration when starting up your DE? Those logs should be in /var/log/
I do a gpu passthrough setup. So my main gpu doesn’t really do much within X. But I did add another gpu and remove one. Going from intel integrated as my main gpu to an amd gpu. Could this be the issue? However we can only speculate now, I needed my main setup working and moved over to Arch. However, I can say that my log directory didn’t show anything scary. I scowered it and didn’t find anything alarming still.
Caveat - I haven’t run X in a few years and I’ve never messed with KDE… so what’s below is most likely all lies:
My guess is that there’s some KDE specific configuration files somewhere that use your GPU setup. When switching around GPUs, the output names can change and I think xorg.conf files can have mappings to particular screens or cards?? Maybe something happened along those lines - especially since it seems like your system is “stable”, besides from the DE…
It’s happening again! On my new Arch install it’s happening! This is actually crazy! I don’t know what happened, it crashed once and now it will just crash and restart then crash again! I will attempt to get logs and a restep of what was happening.
I just uninstalled Libvirt, Virt-Manager, and Qemu, removed vfio modules from mkinitcpio.conf. Everything appears to be stable the crashing has stopped.
I’m going to slowly start reinstalling everything and post here my results.
Edit: Got Vfio working no issues.
Almost immediately crashed after starting libvirtd and virtlogd. !!!
I have fixed it, I am no longer crashing. But what is interesting is that this wasn’t an issue when I had an intel cpu. Is this a bug? I believe when I had an intel cpu on Manjaro I had /dev as a storage pool. So what changed when I switched to amd? Should I report this to the libvirt devs?
To summarize, the issue I ran into is AMD specific, as far as I know. After adding the /dev directory as storage device pool. Libvirtd crashes the entire system (don’t know why libvirtd itself doesn’t just crash instead everything just stops). Libvirtd then starts at boot and repeats. This is possibly an issue specifically related to libvirtd. But it is obviously a major issue considering the lack of logs to show an issue was present.