Guten Morgen alle miteinander.
Seit gestern habe ich das Problem, dass Fedora ca. 30 Sekunden nach dem Hochfahren einen Kernel Panic auslöst – mit immer unterschiedlichen Fehlermeldungen:
- (heute neu) Attempted to kill init! Exitcode=0x0000008b
- Attempted to kill init! Exitcode=0x00000009
- Attempted to kill the idle task!
- Fatal exception in interrupt
Ich habe bereits mein Glück mit ChatGPT und Google versucht, finde aber nichts Sinnvolles.
Hardware
- AMD Ryzen 7 5700X
- 4×8 GB G.Skill DDR4-3200 (gemischt aus zwei kompatiblen Kits)
- ASUS ROG Strix RX 5700 XT Gaming OC
- Kingston 2 TB NVMe SSD (Systemlaufwerk)
- 3 weitere SATA-SSDs
- 1 HDD
- ASUS B550-F Gaming Mainboard
- Fedora 44 KDE und Triple Boot mit Ubuntu 26.04 und Win 11 Pro
- BIOS Version: 3636
Keine manuellen CPU-Übertaktungen aktiv
RAM läuft mit DOCP 3200 MHz bei 1,2 V
Weitere OC-Einstellungen wurden meines Wissens nach nicht verändert
Symptome
- Kernel Panic tritt meist innerhalb von ca. 30 Sekunden nach dem Booten auf.
- Teilweise friert das System vorher komplett ein.
- Manchmal lässt sich die Maus noch wenige Sekunden bewegen, bevor alles stehen bleibt.
- Die Panics treten sowohl mit grafischer Oberfläche als auch im Textmodus auf.
- Die Fehlermeldungen sind nicht immer identisch.
- Nach einem erfolgreichen Boot läuft das System teilweise stundenlang problemlos.
Was ich bereits geprüft habe
- Memtest86+ komplett durchlaufen lassen
- Btrfs-Scrub durchgeführt
- btrfs device stats / zeigt ausschließlich 0-Werte
- SMART-Werte der NVMe überprüft
- Im Journal taucht regelmäßig Folgendes auf:
amdgpu 0000:0c:00.0: Fence fallback timer expired on ring sdma0
Außerdem erscheint beim Booten:
- amdgpu: Overdrive is enabled
Kernel-Parameter wurden getestet:
- nomodeset
- amdgpu.runpm=0
- amdgpu.gpu_recovery=1
Ohne Verbesserung.
Mit der GPU komplett deaktiviert
- modprobe.blacklist=amdgpu
schien das Problem zunächst behoben.
Später traten die Kernel Panics jedoch auch ohne geladenen AMDGPU-Treiber wieder auf.
Dann hab ich die PCIe-Linkgeschwindigkeit im BIOS von Auto auf Gen3 gestellt.
Dadurch lief das System zunächst wieder stabil, nach weiteren Neustarts traten die Panics jedoch erneut auf.
Schonmal Danke im Voraus für die Bemühungen!
Hallo!
Kannst Du einen älteren Kernel starten? Tritt das Problem da auch auf?
kannst Du mal mit journalctl -b -1 -e die Fehlermeldungen des letzten Boots aufrufen und die Call Trace-Meldungen rauskopieren?
Memtest lief für ein paar Stunden (8+) ?
Durch ein Wunder läuft es gerade ohne Kernel Panic.
ich hab alle verfügbaren Kernels getestet inklusive dem rescue Kernel, aber die verhalten sich alle gleich.
memtest lief ca 2 Stunden ohne Fehler.
im journalctl hab ich nichts mit call trace gesehen, deswegen hab ich hier einfach die gesamte ausgabe:
https://pastebin.com/vZZ8nM8B
Ich würde den memtest von einem USB Stick mal über Nacht laufen lassen, oft braucht es mehrere Durchläufe um defekten RAM zu detektieren.
würden dann nicht auch die anderen Systeme (Ubuntu, Windows) Probleme machen? die funktionieren beide problemlos (bis darauf das manchmsl der explorer einfriert und dann das gesamte windows crashen lässt, aber ich glaube das sind nor ale windows probleme)
Ja, wahrscheinlich schon.
oder eben doch ein Hardware-Problem.
Sicher, dass die Platte in Ordnung ist?
bei der platte ist alles fein, Windows hat noch nie so richtig gebockt bei mir, weswegen ich jetzt hier bin 
Noch so ein Ding, was mir einfällt: Ist dein BIOS auf dem aktuellsten Stand?
könnte auch sein das das Mainboard langsam ins Gras beißt, da bin ich gerade mit dem Asus support am telefonieren
ja, vorgestern erst aktualisiert
guck mal bei 09:12:42 und 09:12:47, da steht:
fedora abrt-notification[1836]: System encountered a non-fatal error in srso_alias_return_thunk()
- SRSO steht für Speculative Return Stack Overflow (auch bekannt als die Sicherheitslücke „Inception“, die primär AMD-Prozessoren der Zen-1- und Zen-2-Generation betrifft)
- Das Betriebssystem nutzt spezielle Kernel-Funktionen (diesen Thunk), um diese Sicherheitslücke per Software zu patchen.
- Wenn hier ein Fehler gemeldet wird (ein sogenannter Kernel-„Oops“), könnte das heißen, dass der Kernel bei der Ausführung dieser Mitigations auf ein unerwartetes Verhalten gestoßen ist. Im Log wird es zwar als „non-fatal“ eingestuft, aber solche CPU-Sicherheits-Mitigations-Fehler sind bekannt dafür, bei etwas anderer Systemlast oder unglücklichem Timing in einem Kernel Panic zu enden.
Gibt noch Spuren vorheriger Abstürze:
EXT4-fs (dm-0): recovery complete (Das Dateisystem musste repariert werden).abrt-dump-journal-oops[1316]: Found oopses: 5 (Der automatische Fehlerbericht-Dienst ABRT hat direkt beim Start 5 alte Kernel-Fehler in den Logs gefunden).File [...] user-1000.journal corrupted or uncleanly shut down (Das System-Log selbst wurde abrupt abgewürgt).
Hast Du denn neuesten kernel installiert (sudo dnf update --refresh)?
Was sagt: abrt-cli list?
bestimmt nicht, dann würden Ubuntu und Windows nicht stabil laufen.
ASUS Support, … oje, würde mich wundern, wenn da was Gutes bei rauskommt. ASUS unterstützt offiziell bestimmt kein GNU Linux, geschweige denn Fedora.
ich würde den Fehler in jedem Fall den Fedora Kernel-maintainern melden: Making sure you're not a bot!
Du könntest auch mal versuchen die Software-Mitigations für die Sicherheitslücke auszuschalten und gucken, ob es das Problem mit Kernelabstürzen löst:
spec_rstack_overflow=off
und zwar so:
sudo grubby --update-kernel=ALL --args="spec_rstack_overflow=off"
sudo reboot
nach dem neustart schaust du Dir mal cat /proc/cmdline an, in der Ausgabe sollte am Ende irgendwo spec_rstack_overflow=off stehen.
Falls Du das dann wieder rückgängig machen möchtest: sudo grubby --update-kernel=ALL --remove-args="spec_rstack_overflow=off"
ich hab den neuesten 7.0.11-200.fc44.x86_64 kernel installiert.
ich kann leider gerade die ausgabe nicht einschicken, weil das system mal wieder komplett eingefriert ist, vielleicht klappts wieder nach ein paar neustarts
probier mal als erstes das mit sudo grubby --update-kernel=ALL --args="spec_rstack_overflow=off"
bist jetzt bekomme ich nur Fatal exception in interrupt Panics aber ich weiß auch nicht ob es das wirklich übernommen hat, weil ich im. Neustart ladebildschirm festhingen geblieben bin. gibt es vielleicht einen command den ich in grub mit einfügen kann?
Also es hat die einstellung mit übernommen, aber wirklich zu ändern scheint das nichts
kernel auswählen, dann e drücken und dann die kernel kommandozeile editieren.
ist aber nicht nötig, wenn cat /proc/cmdline die änderung zeigt.
Aber wenn es das übernommen hat und den Fehler nicht behebt, dann hinfällig.
Ich kenne mich mit diesen AMD Mitigations leider nicht gut aus. Probier mal einen alten Kernel, z.b. ein F42 Livesystem von USB und guck ob das stabil läuft…
Ansonsten muss hier mal jemand helfen, der noch einen andere Idee oder Lösung hat.
hier die ausgabe von abrt-cli:
https://pastebin.com/LkZH0N8J
falls ich noch befehle ausführen kann / soll wäre wahrscheinlich jetzt die beste Gelegenheit wenn ich einmal keinen crash habe
abrt-cli list -d 37a1ef6
oder
abrt info 37a1ef6
oder
journalctl -k --since "2026-06-08 11:00:00" --until "2026-06-08 11:05:00"
