Hallo zusammen,

ich habe ein Problem. Mein Server ist, für mich urplötzlich, instabil geworden. Er stürzt aktuell mindestens einmal täglich ab. Erst dachte ich, dass da Global C-States irgendwie rein spielen, aber es passierte heute Nacht zum Beispiel während eine Festplatte im PreClear war, und vorgestern während des Parity Check auf Grund des Absturzes am Tag davor.
Ich habe keine neuen Docker oder Plugins. Mit ist vor zwei Wochen ein Absturz aufgefallen. Da zeitgleich (mitten in der Nacht) die Fritzbox neustartete, bin ich von einem kurzen Stromausfall ausgegangen. Parity Check war fehlerfrei. Letzte Woche Freitag ist er aus mir unbekanntem Grund abgestürzt. Das habe ich genutzt, um den Server umzuziehen in ein anderes Gehäuse (das Jonsbo N4 ist zwar schick, aber thermisch eine Katastrophe!) inkl. Mainboardtausch. Da das Asus ROG Strix X570-E nur USB 3.x Anschlüsse hat, womit Unraid nicht vom Stick starten wollte, habe ich den Stick per Front USB angeschlossen und dann in Unraid auf eine interne SSD als Bootmedium gesetzt.

Leider ist der Server seit Sonntag jeden Tag abgestürzt. Im Log finde ich keine Einträge, die irgendwas andeuten. Da es schon vorm Mainboardtausch zwei Abstürze gab, würde ich das neue Mainboard zumindest als Hardware defekt ausschließen. Ich habe MEMTEST86+ durchlaufen lassen, da gab es keinen Fehler. Die Grafikkarte kann ich mit KI quälen, da passiert auch nichts. Es könnte, wenn Hardware, dann nur die CPU sein. Da überlege ich gerade, wie ich die am besten dauerhaft unter Last setze, um das zu prüfen.

Im Bios sind ResizeBar und SVM aktiv, der Speicher läuft ohne XMP Profile im Standardtakt. Global C States sind disabled... Was kann es noch sein? Das Bios ist mit Absicht auf einer etwas älteren Version, da dies als das stabilste in der COmmunity gilt. Dies wäre sonst mein nächster Punkt auf das neueste upzugraden.
Habt ihr noch Ideen? Könnte ich noch eine Einstellung im Bios übersehen haben? Ich habe hier meine Diagnostics angehangen. Braucht ihr weitere Infos?

Edit: Ich habe Gemini meine Diagnostics analysieren lassen. Da gibt es die Empfehlung, dass ich von macvaln auf ipvlan umstellen soll. Aber ich nutze macvlan dank der Friotzbox Problematik von unraid 6 entsprechend schon ein paar Jahre. Das sehe ich nicht als Problem an, sonst hätte ich ja in den letzten Jahren mehr Probleme haben müssen...

tower-diagnostics-20260917-0737.zip

Edited Thursday at 10:08 AM1 day by BastiKA84

Nimm Prime95 für den CPU Belastungstest. Gibt es auch für Linux.

Der zeigt dir auch an, wenn ein Kern defekt ist. Die längste Laufzeit um festzustellen, ob die CPU defekt war, ist 5 Stunden bei einem Kunden PC bei uns gewesen. Das hatte da tatsächlich so lange gedauert bis der Fehler auftrat. Aber wenn er auftritt, weißt du auch, dass die CPU definitiv DEFEKT ist.

Am meisten sind bei uns die 13. und 14. Generation Intel CPUs gestorben. Die hatten halt das Problem, dass die zu viel Spannung bekamen. Aber auch Ryzen CPUs sterben hin und wieder mal. Das hält sich im großen und Ganzen die Waage.

Edited Thursday at 04:16 PM1 day by TheGCat

Danke für die Antwort (irgendwie kann ich kein "Like" da lassen... 🤷‍♂️). Du meinst dann wahrscheinlich mit einem Linux Live USB Stick, richtig? Ich wüsste nicht, wie ich Prime95 unter unraid installiert bekomme 🙂 Ich habe heute morgen erstmal auf das neueste BIOS geupdatet. Ich hoffe, ich habe alle BIOS Einstellungen gefunden. Ist schon brutal, was dieses Board alles an Optionen bietet...
Jetzt beobachte ich den Server. Wenn der übers WOchenende wieder abstürzt oder einfriert, dann lasse ich Prime95 für ein paar Stunden laufen. Einen aktuellen ubuntu USB Stick habe ich sogar noch liegen 😃

Edit: Ach ja, ist ein Ryzen 9 5900X. Also eigentlich eine zuverlässige CPU.

Edited 19 hours ago19 hr by BastiKA84

Ja, zum Beispiel. Irgendein Live-Linux-System auf den Stick machen, davon booten und dann den Test mit Prime machen. Man muss ja auch nicht alles in der Unraid Umgebung testen Außerdem ist ja noch gar nicht geklärt, ob es wirklich ein CPU Problem ist. Wenn du Pech hast liegt es an Unraid oder irgendeiner Konfiguration.

PS: Vielleicht dürfen GrumpyCats keine Likes bekommen

Edited 19 hours ago19 hr by TheGCat

23 hours ago, BastiKA84 said:

Edit: Ich habe Gemini meine Diagnostics analysieren lassen. Da gibt es die Empfehlung, dass ich von macvaln auf ipvlan umstellen soll. Aber ich nutze macvlan dank der Friotzbox Problematik von unraid 6 entsprechend schon ein paar Jahre. Das sehe ich nicht als Problem an, sonst hätte ich ja in den letzten Jahren mehr Probleme haben müssen...

exakt, verträgt sich auch nicht (ipvlan und Fritz) und die crashes haben sich auch im log angekündigt.

Harte Crash's (reboots) ohne logs sind (leider) fast immer Hardware und es bleibt meist nur "trial & error" ... von A-Z.

wenn das System "einfriert" kann es auch öfters Software sein, sieht man meist jedoch in den logs wenn die dann persistent aktiviert sind.

Viel Erfolg.

Der Server ist vorhin wieder abgestürzt und neugestartet. Die letzten Zeilen vom Log waren:
Sep 18 15:56:06 Tower emhttpd: read SMART /dev/sdg Sep 18 15:56:17 Tower emhttpd: read SMART /dev/sdd Sep 18 16:28:00 Tower emhttpd: spinning down /dev/sdg Sep 18 16:28:00 Tower emhttpd: spinning down /dev/sdd Sep 18 16:58:21 Tower emhttpd: read SMART /dev/sdg Sep 18 16:58:21 Tower emhttpd: read SMART /dev/sdd Sep 18 17:30:25 Tower emhttpd: spinning down /dev/sdg Sep 18 17:30:25 Tower emhttpd: spinning down /dev/sdd Sep 18 17:57:49 Tower emhttpd: read SMART /dev/sdg Sep 18 17:57:59 Tower emhttpd: read SMART /dev/sdd Sep 18 18:30:20 Tower emhttpd: spinning down /dev/sdg Sep 18 18:30:20 Tower emhttpd: spinning down /dev/sdd

Und das nächste Log fängt einfach mit der Startroutine an:
Sep 18 18:38:20 Tower kernel: Linux version 6.18.38-Unraid (root@Develop) (gcc (GCC) 15.3.0, GNU ld version 2.46.1-slack151) #1 SMP PREEMPT_DYNAMIC Mon Jul 6 15:22:03 PDT 2026 Sep 18 18:38:20 Tower kernel: Command line: BOOT_IMAGE=/boot@/bzimage unraidguimode acpi_enforce_resources=lax usbcore.autosuspend=-1 pcie_aspm=off pcie_port_pm=off unraiduuid=1533913480426968572 Sep 18 18:38:20 Tower kernel: BIOS-provided physical RAM map: Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009d1efff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000009d1f000-0x0000000009ffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000000a000000-0x000000000a1fffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000000a200000-0x000000000a20dfff] ACPI NVS Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000000a20e000-0x00000000c30e2fff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000c30e3000-0x00000000c30e3fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000c30e4000-0x00000000c9cf4fff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000c9cf5000-0x00000000ca0a8fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ca0a9000-0x00000000ca212fff] ACPI data Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ca213000-0x00000000ca9b3fff] ACPI NVS Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ca9b4000-0x00000000cb9fefff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000cb9ff000-0x00000000ccffffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000cd000000-0x00000000cfffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fd200000-0x00000000fd2fffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fd400000-0x00000000fd5fffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fea00000-0x00000000fea0ffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000feb80000-0x00000000fec01fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fedc2000-0x00000000fedcffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000fedd4000-0x00000000fedd5fff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x0000000100000000-0x000000102f2fffff] usable Sep 18 18:38:20 Tower kernel: BIOS-e820: [mem 0x000000102f300000-0x000000102fffffff] reserved Sep 18 18:38:20 Tower kernel: NX (Execute Disable) protection: active Sep 18 18:38:20 Tower kernel: APIC: Static calls initialized Sep 18 18:38:20 Tower kernel: efi: EFI v2.7 by American Megatrends Sep 18 18:38:20 Tower kernel: efi: ACPI=0xca212000 ACPI 2.0=0xca212014 TPMFinalLog=0xca967000 SMBIOS=0xcb7b6000 SMBIOS 3.0=0xcb7b5000 MEMATTR=0xc5c7b018 ESRT=0xc7b2e798 INITRD=0xc12a9b18 RNG=0xca1eec18 TPMEventLog=0xca0e9018 Sep 18 18:38:20 Tower kernel: random: crng init done Sep 18 18:38:20 Tower kernel: efi: Remove mem79: MMIO range=[0xf0000000-0xf7ffffff] (128MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xf0000000-0xf7ffffff] reserved Sep 18 18:38:20 Tower kernel: efi: Remove mem80: MMIO range=[0xfd200000-0xfd2fffff] (1MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xfd200000-0xfd2fffff] reserved Sep 18 18:38:20 Tower kernel: efi: Remove mem81: MMIO range=[0xfd400000-0xfd5fffff] (2MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xfd400000-0xfd5fffff] reserved Sep 18 18:38:20 Tower kernel: efi: Not removing mem82: MMIO range=[0xfea00000-0xfea0ffff] (64KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Remove mem83: MMIO range=[0xfeb80000-0xfec01fff] (0MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xfeb80000-0xfec01fff] reserved Sep 18 18:38:20 Tower kernel: efi: Not removing mem84: MMIO range=[0xfec10000-0xfec10fff] (4KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem85: MMIO range=[0xfed00000-0xfed00fff] (4KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem86: MMIO range=[0xfed40000-0xfed44fff] (20KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem87: MMIO range=[0xfed80000-0xfed8ffff] (64KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem88: MMIO range=[0xfedc2000-0xfedcffff] (56KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Not removing mem89: MMIO range=[0xfedd4000-0xfedd5fff] (8KB) from e820 map Sep 18 18:38:20 Tower kernel: efi: Remove mem90: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map Sep 18 18:38:20 Tower kernel: e820: remove [mem 0xff000000-0xffffffff] reserved Sep 18 18:38:20 Tower kernel: SMBIOS 3.3.0 present. Sep 18 18:38:20 Tower kernel: DMI: System manufacturer System Product Name/ROG STRIX X570-E GAMING, BIOS 5055 09/10/2026 Sep 18 18:38:20 Tower kernel: DMI: Memory slots populated: 4/4

Ich kann mir nicht vorstellen, dass da ein Problem mit der CPU vorliegt. Die hatte ja nichts zu tun, und lungerte im idle rum. Ich vermute weiterhin irgendeine Energiesparoption

Edited 8 hours ago8 hr by BastiKA84