Supermicro MBD-X11SCL-IF Mainboard: Sporadische Freezes

[visar]

Hallo Zusammen

Für mein Homelab (19" Rack im Keller) habe ich im Herbst 2022 u.a. 3 Stk. SuperMicro MBD-X11SCL-IF Mainboards gekauft. Alle 3 Boards haben die gleiche CPU/RAM/Lüfter/10GE Karte verbaut. Es ist das aktuellste BIOS installiert (vom 2022).
BIOS-Settings sind default.

Auf einem Board läuft OPNsense und auf den beiden anderen Proxmox (Cluster).

Seit Beginn erlebe ich immer wieder Komplett-Freezes. Bei allen 3 Boards. (Muss das Board jeweils resetten. Immerhin geht das auch über IPMI.)
Bei der Erstinstallation hatte ich es einmal. Da dachte ich mir noch nicht viel dabei. Dann lief es viele Wochen stabil. Plötzlich wieder ein Freeze aus heiterem Himmel.
Da es recht selten passiert, konnte ich noch kein wirkliches Muster erkennen. Es geschah aber mal in der Aufstartphase, mal im IDLE-Mode, mal beim Updaten von Files. Aber meines Wissens nicht wirklich unter Volllast. (Ich habe zu Beginn auch ein Burn-In durchgeführt, den alle 3 Boards ohne Probleme überstanden haben. Also Memory und CPU scheinen eigentlich ok zu sein.)

Heute wollte ich meine beiden Proxmox-Installationen auf Version 8 updaten. Und da habe ich nun an einem Abend schon 2 Freezes (pro Motherboard) gesehen. z.T. erst 15 Min. nach dem Reboot und ohne Last (keine VMs aktiv).

Einziger Anhaltspunkt ist das "Health-Log", welches ich via IPMI anzeigen lassen kann. Dort sehe ich zumindest den Freeze, aber leider ohne weitere Infos. Hier ein Beispiel eines dieser Logs:

CATERR steht glaub für "Catastrophic Error"
Der Quelle, die diesen Fehler gemeldet hat, ist der Prozessor. Aber eben...mehr weiss ich nicht. Ist der Prozessor der Auslöser oder einfach der, der als letztes dem IPMI noch etwas meldet?
Im Internet habe ich leider nichts dazu gefunden.

Bei meiner CPU handelt es sich um ein Intel i3-9300T, da dieser noch ECC unterstützt. Die T-Variante ist nicht sehr verbreitet. Es sollte aber die stromsparendste sein.

Da das Problem leider nicht reproduzierbar ist und manchmal monatelang nicht auftritt, kann ich auch schwer nach dem Ausschlussverfahren einfach Komponenten austauschen. (Abgesehen davon, dass dies auch recht ins Geld geht.)

Ich weiss, die Chancen sind bei diesen Infos sehr klein. Aber hat evtl. jemand Ideen, wie man das besser eingrenzen könnte? Oder wo man unter Debian evtl. Logs findet, die kurz vor dem Freeze geschrieben wurden und möglicherweise eine heisse Spur ergeben.

Bin um jeden Input dankbar!

 

[Trambahner]

Intel "T"-CPUs (oder auch "S") sind im Idle nicht sparsamer als die normalen der gleichen Generation ! Die sind nur von der maximalen Leistung obenrum gedeckelt, da sie für kleine Gehäuse gedacht sind.

 

[underclocker2k4]

Neustes BIOS bzw. IPMI FW drauf? (neuste ist von Juli 2023)
Mal Supermicro angeschrieben? Die haben einen Top Support. Ggf. haben die einen Ansatz.

Mal nach ner gebrauchten BilligCPU zum Testen (auch wenn das mal 1 Jahr dauern kann) geschaut?

 

[visar]

Vom 2023 BIOS wusste ich noch nichts. Danke...muss ich dann mal draufladen. (Auch wenn es eben mit dem Reproduzieren leider sehr schwierig ist...wobei ich es glaub schon etwas "provozieren" kann. Ich muss einfach "etwas" dran rumschrauben. Dabei geht es nicht um Last oder Restart...einfach etwas ändern, was sich vom normalen Betrieb unterscheidet. Dann habe ich meist die Freezes gehabt. Klingt furchtbar schwammig...und ist es leider auch. )

Supermicro habe ich noch nicht angeschrieben, weil ich mir irgendwie nicht soviel davon erwarte (kann ja nicht viele Infos liefern). Aber hätte ich wohl sicher noch probiert.

Ja...da der Log-Eintrag ja vom Prozessor kommt, habe ich immer noch "Hoffnung", dass es damit zusammenhängt. Evtl. ist der i3 T in gewissen Situationen nicht kompatibel mit diesem Board. Und da dieser Prozessor (zumindest Typ) vermutlich selten im Server-Umfeld eingesetzt wird, gibt es vielleicht wenig Fälle.
Ich habe mir aber vor ein paar Monaten relativ günstig einen "normalen" i3 gekauft (neu) und werde dies wohl mal auf dem 2. Proxmox Node testen. Weil auf diesen Server kann ich für die Testphase verzichten, da ich nicht zwingend ein Cluster benötige. (Habe auf dem Proxmox zurzeit eh nur unwichtige Test VMs/Container am Laufen, weil ich wegen den Freezes nichts wirklich Wichtiges installieren möchte.)

Was ich mit diesem 2. Proxmox Node auch noch testen werde, ist das Entfernen der 10GE Karte. (Kann ja mit den Onboard 1 GE testen)
Ich habe irgendwie so das Bauchgefühl, dass es (nebst dem Prozessor) evtl. an dieser Dual 10GE-Karte liegt. Ich erhalte nämlich beim Starten von Debian einige komische Fehlermeldungen, obwohl die Karte einwandfrei funktioniert. (Mit iPerf bekomme ich auch stabil 10GE hin.)

Natürlich habe ich auch hier wieder das Problem mit dem Fehler reproduzieren. Ich werde mit diesem Testsystem evtl. mal die Karte rausnehmen und dann paarmal hintereinander Debian installieren/löschen. Wenn ich dabei ein Freeze bekomme, dann weiss ich zumindest, dass es NICHT an der Karte liegt.
Anschliessend die CPU mal wechseln und auch testen (ohne 10GE Karte). Und dann die Karte wieder rein....wenn ich dann länger keinen Freeze erhalte, heisst das zwar noch nichts, aber ist zumindest besser als ein Freeze.

Ja, könnte ich den Freeze reproduzieren (z.B. ab einer gewissen Last, oder Themik-Problem von Kaltstart aus), dann wäre das wesentlich einfacher. Da könnte man nur schon mit dem Ausschlussverfahren recht weit kommen.

 

[smoothwater]

Kurze Zwischenfrage: Welcher RAM ist verbaut und ist der ECC-Modus überhaupt bei Default-Settings aktiv?

 

[visar]

Kurze Zwischenfrage: Welcher RAM ist verbaut und ist der ECC-Modus überhaupt bei Default-Settings aktiv?

Es ist ein Samsung 32GB DDR4 ECC RAM UDIMM 2666Mhz (DDR4 PC4-2666V-E 2666Mhz 288pin ECC UDIMM MODULE MIT THERMAL SENSOR)
Samsung Part Nr.: M391A4G43MB1-CTD (welche ich irgendwo als kompatibel zu diesem Board gelesen habe.)

Im BIOS gibt es keine Option, ECC zu konfigurieren. Das ist alles, was ich bei "Memory Configuration" sehe:

Ich hatte das Memory mit dem MemTest auf diesem Board durchgetestet.

Das SuperMicro Board unterstützt folgendes:
Up to 64GB Unbuffered ECC UDIMM, DDR4-2666MHz, 2667/2400/2133 MT/s SDRAM 72-bit, 4GB, 8GB, 16GB, 32GB, 1.2V
Corrects single-bit errors

Beitrag automatisch zusammengeführt: 05.10.2023

Habe heute eines dieser 3 Boards mit dem aktuellen BIOS aktualisiert und danach die "Optimized Default Settings" geladen.
Soweit so gut. Die BIOS Version (2.1) wird mir auch korrekt angezeigt.

Nur habe ich jetzt seit diesem BIOS Update ein neues Problem: Ich kann nicht mehr von der internen 1 TB SSD booten!

Habe testhalber Proxmox vom USB-Stick installiert und später auch nochmals Ubuntu Server. Beide Installationen liefen normal durch. D.h. die SSD wurde erkannt und wohl beschrieben.

Aber wenn ich das System boote und manuell die SSD im Boot-Menü auswähle, dann wechselt er nach ca. 1-2 Sekunden (ohne Meldung) auf das nächste Boot-Medium, was in meinem Fall die Dual 10GE Netzwerkkarte ist. Dort findet er via DHCP natürlich kein Boot-Image.

Habe keine Ahnung, warum ich die SSD zwar im Boot-Menü sehe (und auch auswählen kann), er aber dann nicht davon booten kann. (Sowohl der Proxmox- und auch Ubuntu-Installer löschen ja die SSD zuerst und das sollte danach auch bootfähig sein.)

Hier das Boot-Menü:

Und hier der erfolglose Versuch, von der 10GE-Karte zu booten:

Gibt es im AMI BIOS eine Einstellung, die eine (stinknormale) SSD nicht mehr kompatibel macht? (zum Booten zumindest....man kann ja darauf zugreifen)

Einziger kleiner Lichtblick: Obwohl ich jetzt sicher 10x neu gestartet habe, Proxmox mehrmals installiert habe, Ubuntu Server installiert habe und mehrfach im BIOS war, hatte ich kein einziges Mal ein Freeze erlebt.
Muss nichts heissen, aber genau bei solchen Eingriffen kam der Freeze am häufigsten.

Aber schön wäre, wenn ich jetzt wieder auf die SSD booten könnte...

 

[underclocker2k4]

Spiel mal mit den EFI nonEFI Bootmodi rum, in der Regel liegt da das Problem, beim beschriebenen Verhalten.

 

[hardwear]

Die SSD ist aber schon als GPT eingerichtet, ja? Da scheint es ja nur einen Eintrag für MBR-Boot zu geben.

Da war vor einer Weile mal was mit einem Update der Zertifikate für Secure Boot. Ältere Linux-Systeme dürften damit quasi ausgeschlossen sein, wenn das aktiv ist.

 

[smoothwater]

Laut Handbuch: Bios-> Advanced -> Chipset Configuration -> System Agent Configuration -> Memory Configuration -> ECC Support auf enabled setzen

 

[visar]

Spiel mal mit den EFI nonEFI Bootmodi rum, in der Regel liegt da das Problem, beim beschriebenen Verhalten.

Hmm...leider habe ich nicht viel dazu gefunden. Das Vielversprechenste war das hier:

Das stand vorher zwar auf DUAL und ich habe es jetzt mal auf LEGACY gesetzt. Aber leider ohne Erfolg. Er bootet nicht von der M.2 SSD.

Die SSD ist aber schon als GPT eingerichtet, ja? Da scheint es ja nur einen Eintrag für MBR-Boot zu geben.

Ich hab die nicht speziell eingerichtet. Einmal wurde sie vom Proxmox-Installer (8.0.2 / Juni 23) gelöscht und beschrieben (EXT4) und einmal vom Ubuntu Server 23.04. Beides sollten eigentlich aktuelle Linux-Versionen sein. (Bei Proxmox ist es Debian Bookworm mit Kernel 6.2.16)
D.h. diese Installer haben die SSD bootfähig gemacht. Vielleicht kann ich mit einem GParted Live ISO die aktuelle Partition mal anschauen. Aber ich denke nicht, dass diese beiden Installer eine nicht sauber bootfähige Disk erstellt haben.
Da das Problem ja offenbar erst seit dem BIOS Update existiert, muss es irgendwie mit dem BIOS (bzw. UEFI) zu tun haben. Wäre noch der Hammer, wenn ich evtl. mein Freeze-Problem mit diesem BIOS behoben hätte, dafür kann ich mit Debian (Proxmox) nicht mehr booten.

Laut Handbuch: Bios-> Advanced -> Chipset Configuration -> System Agent Configuration -> Memory Configuration -> ECC Support auf enabled setzen

Siehe oben mein Screenshot zu Memory Configuration. Der Pfad passt, aber den letzten Punkt (ECC Support) habe ich nicht.
Da es sich ja um ein Serverboard handelt (mit ECC-Support), ist vielleicht ECC fix enabled.

Beitrag automatisch zusammengeführt: 05.10.2023

So sieht übrigens die SSD mit GParted aus:

Offenbar gpt. Was es mit dem "bios_grub" Flag auf sich hat, weiss ich nicht.

 

[underclocker2k4]

Das stand vorher zwar auf DUAL und ich habe es jetzt mal auf LEGACY gesetzt. Aber leider ohne Erfolg. Er bootet nicht von der M.2 SSD.

Und mal auf UEFI? Und dann nochmal bei den boot devices schauen.

 

[visar]

Und mal auf UEFI? Und dann nochmal bei den boot devices schauen.

Du hast recht. Das ist mir gar nicht aufgefallen: Wenn ich auf UEFI wechsle, wird bei Hard Disk die SSD nicht mehr angezeigt:

Bei LEGACY (und auch DUAL) wird die SSD jedoch angezeigt. (Siehe Screenshot aus meiner letzten Nachricht.)
Dafür bootet er aber dann nicht.

Ich kenn mich mit der Thematik zuwenig aus. Liegt das jetzt nur an einer nicht UEFI kompatiblen Bootpartition?
Wenn ich aber den Boot mode auf LEGACY setzen kann (und dort die SSD auch angezeigt wird), warum bootet er trotzdem nicht davon? Wenn das BIOS das jetzt nicht mehr erlauben würde, ok. Aber ich habe ja scheinbar die Option.
Zudem bootet bis jetzt jeder USB-Stick (oder virtuelles ISO-Image) korrekt. Und diese USB-Sticks sind ja auch alle Linux-basierend (Live ISO). Auch GParted Live habe ich vorhin so gebootet (das virtuelle CD/DVD ISO wird im Screenshot oben sogar noch angezeigt.)
Wenn das BIOS das nicht (mehr) zulassen würde, würde das doch von dort auch nicht booten.

Oder wird bei dieser Sache zwischen USB-Sticks/CD/DVD und fixen Harddisks unterschieden?

 

[visar]

So, bin einen grossen Schritt weiter!

Habe nochmals den Proxmox Installer (ab Live ISO) gestartet und diesmal bei den Harddisk Options ZFS (anstatt EXT4) ausgewählt. In der Hoffnung, dass dies evtl. "moderner" ist.
Und siehe da...nun konnte ich das allererste Mal seit dem BIOS Update von der SSD booten.

Das Bootmenü sieht auch etwas anders aus:

Wo früher nur an erster Stelle KIOXIA-EXCERIA G2 SSD stand, hat es jetzt sogar 2 Einträge. Ein Linux Boot Manager und darunter noch ein UEFI OS (beide lauten aber auf meine SSD).

In GParted sieht die SSD nun auch etwas anders aus (ja, wegen ZFS natürlich...aber diese beiden im Bootmenü sichtbaren Einträge werden hier auch als Partitionen angezeigt)
"Unknown" und fat32

Mir ist aber vorhin noch was anderes aufgefallen. Der Proxmox Installer (Live ISO) hat während der Startphase etwas ähnliches wie "UEFI system detected" ausgegeben.
Ich vermute langsam, dass es aktuell gar nicht wegen dem ZFS funktioniert, sondern nur, weil ich im BIOS nun den UEFI Mode angegeben habe.
Bei meinen ersten Tests war ja noch der DUAL mode drin. Offenbar liest der Proxmox-Installer dies aus und schreibt entsprechend dann eine etwas andere Bootpartition.
Und obwohl ich im BIOS dann mal auf LEGACY und UEFI umgeschaltet habe, habe ich Proxmox nicht neu installiert. D.h. die Bootpartition war immer noch "falsch".

Erst jetzt, wo ich VORHER im BIOS den UEFI mode explizit angegeben habe und DANACH Proxmox installierte (mit ZFS), hat er das richtig ausgelesen.
Nachtrag: Mein Verdacht hat sich glaub bestätigt. Habe jetzt bewusst Proxmox nochmals neu installiert. Diesmal wieder mit EXT4 (was ja früher nicht ging). Der einzige Unterschied, dass nun im BIOS schon vor der Installation UEFI mode aktiviert ist (anstatt DUAL).

Und er bootet nun auch mit EXT4 von der SSD!

Das Bootmenü sieht erneut etwas anders aus. Aber auch jetzt wieder 2 Einträge für meine SSD:

Und zur Vollständigkeit hier auch noch die Anzeige von GParted:

Ich werde später (testhalber) nochmals Ubuntu Server 23.04 erneut installieren, weil das ja zu Beginn auch nicht funktioniert hat. Vielleicht erkennt der Ubuntu Installer dann auch den UEFI mode korrekt und kann dann von der SSD booten.

Aber immerhin bringe ich jetzt so schon mal Proxmox zum Laufen (was ja für dieses System gedacht ist.)

Und immer noch kein Freeze, obwohl ich jetzt sehr aktiv mit dem System gearbeitet habe. Aber eben...ich hab noch nicht wirklich Vertrauen, bin nur optimistischer als auch schon.

Beitrag automatisch zusammengeführt: 05.10.2023

Letzter Nachtrag für heute: Auch Ubuntu Server 23.04 bootet nun von der SSD!

Ich scheine somit kein Problem mit dem neuen BIOS zu haben, sondern ich muss nur dran denken, VOR der Installation auf UEFI mode zu schalten. (Und natürlich ein OS zu installieren, dass dies unterstützt...wobei dann vermutlich wieder der LEGACY mode gehen würde. Nur DUAL ist offenbar nicht so gut...)

 

[visar]

Soll ich mich freuen? Eher nicht, aber dafür kann ich mich in diesem Thread wieder dem eigentlichen Thema widmen: Freeze (nachdem es zuletzt ja praktisch nur um das Boot-Problem ging.)
Das System ist nämlich heute Nacht wieder steckengeblieben (Zeit ist UTC, also war es um 7:22):

Gestern Abend habe ich ja noch erfolgreich Ubuntu Server 23.04 installiert und konnte ja auch davon booten. Ich habe mich testhalber im Terminal angemeldet und habe dann den Linux Befehl top eingegeben. Der listet ja kontinuierlich und live die laufenden Prozesse auf.
Ich dachte noch, ok...ich geh jetzt eh ins Bett, da kann ich ja den top-Befehl einfach weiterlaufen lassen. Da ich nichts wirkliches auf diesem Ubuntu Server konfiguriert habe, laufen eh nur die Standardprozesse. Ist also eher einem idle-Mode zu vergleichen.

Und heute morgen sah ich dann, dass das Bild eingefroren war und ich somit wieder ein Freeze hatte. (Und im Log sah ich dann den Eintrag.)

Man sieht auch im (Freeze) Screenshot, dass dies um 05:22:17 (also 7:22) geschehen war, 8:24 Std. nachdem ich es gestern gebootet habe.
Im Log wurde es um 05:22:40 (also 23 Sek. später) erkannt.
Ich sehe im Screenshot nichts aussergewöhnliches: Kein load, wenig Memory in use.

Das einzige, was mir halt auffällt: Ich habe gestern einige Stunden sehr aktiv mit dem System gearbeitet. BIOS-Anpassungen, Reboots, OS-Installationen, Live-ISO etc. und nie ein Freeze erlebt.
Und später nach über 8 Std. up-time (idle) plötzlich ein Freeze. Das ist so das unlogische am Ganzen.
Memory-Leak kann man glaub ausschliessen. Temperatur-Problem auch, da ich diese Freezes im normalen Betrieb ja auch eher selten habe, mit mehr Last als jetzt dieser top-Befehl.
Wenn es ein Hardware-Konflikt gibt, warum geschah es denn nicht gestern, als ich wirklich aktiv daran arbeitete?

 

[oNyX`]

Seltsam, Passmark Memtest haste aber schonmal drüber gejagt oder?

Ich hab selbst 2 X11 (SCH-LN4F/SCL-F) hier, die laufen mit Xeon E2236 (Anfangs i3-9100f) seit Board Release. 0 Stress gemacht.

 

[underclocker2k4]

Das mit dem UEFI Kram ist schon sehr speziell, eben weil die Bootpartition und das "BIOS" miteinander "sprechen" und jeder von jedem Weiß. Und wenn man daran rumschraubt (auch ungewollt) führt das zum beschriebenen Verhalten. Wird lustig, wenn mal eben versucht von einer anderen Platte zu booten, die eben eine andere Aufteilung hat.

@ Absturz
Kannst du mal schauen, was im BIOS an Stromsparmechanismen einstellbar ist. Evtl. crasht das System weil irgendein Wechsel zwischen den Sleepmodes Stress macht und das im Zusammenspiel mit der T CPU.

 

[Supaman]

Ich hab hier eine Topton China Box mit einem Intel Celeron n5105 im Einsatz, da war anfänglich mit Proxmox ein ähnliches Problem: sporadische Freezes, obwwohl auf der Kiste fast nix lief. Ursache war eine verbuggter Kernal, d.h. man muss entweder auf einen deutlich älteren zurück greifen oder manuell einen einspielen, der über das Standard Reposotory (noch) nicht ausgelifert wurde. Das Problem war nicht allgemein, sondern betraf nur bestimmte CPU Modelle. Inzwischen sind die Proxmox Kernals aktualisiert, so das kein manueller Workaround notwendig sit.


Von daher einfach mal folgende Try & Error Ansätze:

1)
Wenn man mal die Microcode Version als Ursache unterstellt
- instaliere mal ein Ubuntu/Debian 1-2 Versionen vor der aktuellen
- wechsel die CPU gegen ein anders Modell

2) SSD timings
Die m2 haben unterschiedliche Timings, was z.B. dazu führen kann das ein bestimmtes SSD Modell beim booten nicht erkannt wird. Als Korrektur gibt es im Kernal hardcodierte Tabellen, wo dann für bestimmte Modelle Wartezeitten und angepasste Parameter hinterlegt sind. Einfach mal das Massenspoeicher Modell wechseln, und schauen ob sich was verändert.

 

[visar]

Seltsam, Passmark Memtest haste aber schonmal drüber gejagt oder?

Ja, gestern habe ich z.B. nochmals ein MemTest gemacht (passed). Und nach dem Zusammenbau der Komponenten vor einem Jahr habe ich einen mehrstündigen, intensiven Memory Test gemacht.

Kannst du mal schauen, was im BIOS an Stromsparmechanismen einstellbar ist. Evtl. crasht das System weil irgendein Wechsel zwischen den Sleepmodes Stress macht und das im Zusammenspiel mit der T CPU.

Ich war ja schon von Anfang der Meinung, dass es irgendwie mit der T CPU zu tun hat. Aktuell habe ich keine speziellen Stromsparmechanismen (z.B. C-States) im BIOS konfiguriert. Ist alles (bis auf den UEFI Boot Mode) default. Was nicht heisst, dass das unbedingt gut für DIESE CPU ist. Vielleicht MUSS man hier dran schrauben.
Im Moment läuft erneut (nach dem Freeze von heute morgen) wieder der TOP-Befehl. Ich möchte ihn nochmals ca. 8-9 Std. laufen lassen, um zu sehen, ob es evtl. auch zeitlich ein Muster gibt. (eher unwahrscheinlich)
Werde also erst am Abend wieder ins BIOS gehen. Problem ist halt, dass es bezüglich CPU recht viele Settings gibt.

- instaliere mal ein Ubuntu/Debian 1-2 Versionen vor der aktuellen
- wechsel die CPU gegen ein anders Modell

Das kann schon sein, dass ein verbuggter Kernel das Problem auslöst. Aber ich hatte diese Freezes jetzt auf allen meiner drei Systemen (gleiches Board/CPU/Memory). Und darauf läuft OPNSense 22.7.11_1 (FreeBSD) und Proxmox/Debian (vorher 7.3.x, aktuell 8.0.x).
Und jetzt (Test) läuft ja Ubuntu 23.04 (auch schon mit Ubuntu 22.04 getestet). Mit allen diesen Linux-Versionen habe ich auf diesen 3 Boards schon Freezes gehabt.
Und da es ja jetzt auch mit dem neuen BIOS kein Erfolg brachte, werde ich sicher mal auf diesem Test-System die T CPU mit einem "Standard" i3-9300 austauschen. Und das ist aktuell auch meine grösste Hoffnung.
Bezüglich SSD-Timings scheint ja das Problem mit dem Boot nun gelöst zu sein. (Sofern ich im BIOS den UEFI-Mode VOR der OS-Installation setze.) Werde das Thema im Moment nicht weiterverfolgen, solange ich nicht wieder Boot-Probleme bekomme.

 

[underclocker2k4]

Problem ist halt, dass es bezüglich CPU recht viele Settings gibt.

Schau mal, ob es ggf. sowas wie nen "immer auf full power" setting gibt. Das ist zwar nicht besonders stromsparend, aber hilft, ggf. das Problem etwas einzugrenzen.

 

[Supaman]

Bezüglich SSD-Timings scheint ja das Problem mit dem Boot nun gelöst zu sein. (Sofern ich im BIOS den UEFI-Mode VOR der OS-Installation setze.) Werde das Thema im Moment nicht weiterverfolgen, solange ich nicht wieder Boot-Probleme bekomme.

Angesichts des Aufwandes der bisher betrieben worden ist, wäre ein Test mit irgendeinem anderen Massenspeicher schnell gemacht. Probleme mit SSD Timings müssen sich nicht zwingend auf das booten beschränken - auch wenn die wahrscheinlichkeit gering ist. Einfach um auszuschliessen, das es an dieser Komponente liegt.

 

[visar]

Schau mal, ob es ggf. sowas wie nen "immer auf full power" setting gibt. Das ist zwar nicht besonders stromsparend, aber hilft, ggf. das Problem etwas einzugrenzen.

Hier die BIOS Optionen bezüglich CPU Configuration:

Mein TOP-Befehl ist übrigens seit dem letzten Freeze nun 1 Tag 8.5 Std. ohne Probleme durchgelaufen. (Musste ihn jetzt für den BIOS Screenshot abbrechen.)
Vermutlich hatte ich wirklich "Glück", dass ich den letzten Freeze "schon" nach 8 Std. erlebt habe. (Und damit zumindest das BIOS Update ausschliessen kann.)
Das kann leider monatelang so laufen ohne Freeze.

Ich werde wohl in den nächsten Tagen mal die CPU tauschen (i3-9300T durch i3-9300 Standard), da die ja hier nutzlos rumliegt und ich zumindest mal sehen möchte, obs damit besser wird. (Auch wenn ich weiss, dass ich da Geduld haben muss. Werde sicher auch bisschen rumspielen, was aber leider nicht unbedingt den Freeze provoziert.)

Ist eigentlich noch schräg: Wenn ich ein Freeze erhalte, bin ich irgendwie froh darüber, weil ich dann weiss, dass die Massnahme nichts gebracht hat. Wenn kein Freeze kommt, kann es sein, dass das Problem wirklich gelöst wurde oder aber auch einfach NOCH nicht wieder aufgetreten ist.
Hat leider damit dazu tun, dass ein Freeze nur eines bedeutet: Fehler. Und kein Freeze können halt zwei Sachen bedeuten: Kein Fehler oder noch kein Fehler. (Fast schon wie Schröders Katze)

Beitrag automatisch zusammengeführt: 07.10.2023

Einfach um auszuschliessen, das es an dieser Komponente liegt.

Leider habe ich im Moment keine M.2 SSD rumliegen. Zudem hat mindestens eines dieser 3 Boards eine Kingston SSD verbaut (die anderen 2 Kioxia). Und ich hatte die Freezes ja auf allen 3 Systemen. Somit auch mit der Kingston SSD. Macht es irgendwie noch unwahrscheinlicher, dass es daran liegt. Alle 3 Systeme haben aber den gleichen Prozessor und das gleiche Memory.
Wobei ich dir grundsätzlich Recht gebe, dass bei solch unlogischen Problemen man nie etwas ausschliessen darf. Das kann schnell unnötig viel Zeit kosten. (Habe ich schon öfters in der IT erlebt, dass es am Ende die Ursache war, die ich zu Beginn zu 100% ausgeschlossen habe. Wenn man etwas ohne grossen Aufwand probieren kann, auch wenns noch so unlogisch ist, dann sollte man es irgendwie testen.)

 

[smoothwater]

Wäre es ein Ryzen-System würde ich direkt auf "Power Supply Idle Control" tippen und zwischen von "Low Current" auf "Typical" wechseln.
Gibt es da bei Intel ne Entsprechung? Hab schon einige Jahre nix mehr mit Intel zu tun gehabt 😅

 

[visar]

Ich habe heute die bestehende CPU (i3-9100T) durch einen "Standard" i3-9100 CPU @ 3.60GHz Prozessor ausgetauscht und das BIOS auf Defaults zurückgesetzt (nur Boot Mode auf UEFI geändert).

Werde zuerst noch bisschen "rumspielen" (Ubuntu installieren, Proxmox installieren, paar Tests). Danach werde ich wieder die "richtige" Proxmox (Cluster Node 2) Konfiguration installieren und paar VMs/Container erstellen und so tun, als ob das Problem gelöst sei.

Weil wenn ich noch kein Vertrauen in das System habe und warten möchte, bis ich Gewissheit habe, dann müsste ich auf den nächsten Freeze warten oder irgendwie 6 Monate oder gar 12 Monate KEIN Freeze mehr haben. Aber solange möchte ich eigentlich nicht warten bzw. das System nicht "unproduktiv" einsetzen.
Es bleibt mir also nichts anderes übrig, als es wie ein neues Board zu betrachten und produktiv konfigurieren. Klar muss ich im Hinterkopf behalten, dass ich hier vielleicht nicht die ganz kritischen VMs laufen lassen sollte, sondern Dinge, bei denen ein Freeze zwar ärgerlich, aber nicht grad zu Datenverlusten (korrupte Daten) führt.

Mal sehen...habe ich schon mal erwähnt, dass es nichts schlimmeres gibt, als wenn man ein Problem troubleshooten muss, aber nicht wirklich reproduzieren kann.

 

[visar]

Tja...mein Hoffnungsschimmer währte nicht lange.
Gestern Mittag den Standard i3-9100 Prozessor eingebaut, am Abend Proxmox neu installiert und bisschen rumgespielt. Alles (wie meistens) ok. Keine Freezes.
System lief über Nacht (Proxmox, aber noch keine VMs etc. konfiguriert).
Und heute Morgen kein Kontakt mehr und gemäss Log wieder ein Freeze!

Also umsonst 2 i3-9100 Prozessoren gekauft. Langsam gehen mir die Optionen aus. Nächster (Hardware-)Kanditat wäre das Memory. Aber das ist halt auch wieder mit Kosten verbunden. (Sind wenigsten stark im Preis gefallen...)

Habe im IPMI noch etwas gefunden. Vermutlich irrelevant, trotzdem möchte ich es hier posten:

Sagt jemand dieses "a0" etwas?

 

[underclocker2k4]

Ist das denn nur unter proxmox so?
Hast du mal den RAM extrem im Takt reduziert und ggf. auch die Spannung mal hochsetzen.
Ggf. auch mal Anzahl der Sticks reduzieren?

 

[visar]

Vielleicht mal ein Versuch, eine Art "Muster" hier zu beschreiben. Wobei ich es jetzt eher als meine Beobachtungen bezeichnen würde. Für ein wirkliches Muster habe ich zuwenig Freezes gehabt.

Wie man aus dem Log oben entnehmen kann, hatte es auf dem aktuellen System im Januar und im April mal ein Freeze. (Im 2022 gabs auch mal 1-2, da habe ich aber das Log gelöscht.)
Dieser Server ist seit Spätherbst 2022 im laufenden Betrieb.
D.h. im laufenden Betrieb habe ich monatelang keine Freezes. Die beiden Freezes im Januar und April stehen vermutlich auch im Zusammenhang mit einem Update meinerseits.

1. Erkenntnis/Beobachtung: Systemänderungen lösen Freeze aus.
Seit ich nun bei diesem Server (von 3 identischen) aktiv am Troubleshooten bin, habe ich bereits 4 Freezes gehabt. Diese Häufigkeit ist somit sicher ein "Muster": Wird am System was geändert, steigt die Chance zu einem Freeze. Wird das System aber nur "normal" betrieben, läuft es monatelang sehr stabil. Eigentlich, bis wieder etwas verändert wird.

2. Erkenntnis/Beobachtung: Freeze tritt mit einer Verzögerung auf.
Die letzten 3 Freezes hatten ein ähnliches Muster: Ich update das OS (keine BIOS- oder Hardware-Änderungen) und nach einigen Stunden Verzögerung tritt der Freeze auf. Es passiert aber nie während des Updates oder Reboots. Ich kann hintereinander verschiedene Linux (Debian/Ubuntu) installieren, wobei die SSD komplett gelöscht wird. Ich kann nach der Installation damit arbeiten und Konfigurationen vornehmen und auch zwischenzeitliche Reboots durchführen. Alles völlig normal und stabil.
Lasse ich dann diese Installation (in welchem Zustand auch immer) über Nacht einfach laufen (meist ohne spezielle Last, also praktisch idle), dann ist die Chance hoch, dass nach 8-12 Std. der Freeze geschieht.

3. Erkenntnis/Beobachtung: Nach einem Freeze (Restart) bleibt das System stabil.
Wenn ich das System nach einem Freeze neu starte (geht ja nicht anders), läuft es danach im normalen Betrieb sehr stabil (vermutlich monatelang). Erst, wenn ich wieder mal ein Softwareupdate oder grössere Änderungen durchführe, fängt das Spiel bei Punkt 1 wieder an.

Wie gesagt, das ist jetzt einfach meine Beobachtung aus der letzten Zeit. Welche Art von "Softwareupdates" hier eine Rolle spielen, kann ich leider nicht sagen. Ich kann bei Proxmox z.B. VMs/Container erstellen und verändern und es passiert nichts. Wenn ich aber den Proxmox Host selber update (oder wie aktuell mit verschiedenen Linux-Installationen rumspiele), dann steigt das Risiko nach Freezes stark an.

Jetzt stellt sich natürlich die Frage, was löst nach einem Update bwz. einer Neuinstallation verzögert ein Freeze aus? Ist da ein Cache im Spiel? Eine Indexierung? Versucht das BIOS, die richtigen C-States zu finden?
Irgendetwas, was dann (warum auch immer) dann in einen Freeze endet.
Beim erneuten Start (mit der völlig gleichen Konfiguration wie vor dem Freeze) wird dieser Prozess dann offenbar nicht mehr angestossen und ab da läuft es stabil. Bis irgendetwas wieder diesen "Prozess" auslöst.

Auch wenn ich leider nicht viele Daten zum Freeze selber habe, sieht es aber zumindest nicht danach aus, dass das Memory gefüllt wurde oder irgendein Prozess die CPU überlastet. Das System ist meist vor dem Freeze eher im idle Mode.
Gerade in meinen letzten Tests war das System während des Freeze ja nicht wirklich in Betrieb. Es lief zwar, aber kein anderes System oder User griff über das Netzwerk darauf zu. (Teilweise war noch nicht mal das Netzwerk konfiguriert). Der Server ist also wirklich nur mit sich selber beschäftigt, während der Freeze geschieht.

 

[p4n0]

Herzlichen Glueckwunsch zum finden eines 'kack-Problems'
Sitzen in allen Rechnern die baugleichen Netzteile?
Wuerde da mal eins testweise tauschen und beobachten.

 

[visar]

Herzlichen Glueckwunsch zum finden eines 'kack-Problems'
Sitzen in allen Rechnern die baugleichen Netzteile?
Wuerde da mal eins testweise tauschen und beobachten.

Haha...danke für den Glückwunsch. Ist mir glaub auch schon aufgefallen, dass ich hier was ganze Besonderes habe.

Da die Server in einem Rack sind, habe ich ein 1HE Rack-Case gewählt (ist ja ein Mini ATX Board) und dann auch das vom Case Hersteller angebotene Netzteil, damit es vom Platz passt.
D.h. alle 3 Boards (bzw. Server) haben das gleiche Netzteil.
Leider gibt es da nicht so eine grosse Auswahl an passenden Netzteilen. Natürlich kann ich temporär ein normalen Netzteil verwenden und dies ausserhalb des Case montieren und nur die Kabel reinführen.
(Netzteil hätte ich sogar noch eins übrig...zwar überdimensioniert, aber das ist ja egal.)
Rein von der Logik macht das zwar auch nicht so viel Sinn, weil warum läuft es praktisch das ganze Jahr stabil, bis man etwas verändert und dann tritt der Fehler auch nur erst verzögert auf?
Aber hier spielt die Logik eh keine Rolle mehr...sonst wäre der Fehler sicher schon gefunden.

Ausprobieren kann ich noch vieles (und muss es leider auch)...in der Hoffnung, dass man am Ende eher per Zufall die Ursache findet. Problem ist nur, dass dies alles sehr viel Zeit (und z.T. Kosten) verursacht.
Ich denke (ist aber nicht sicher), dass ich das Problem forcieren kann, in dem ich die Dinge mache, die ich in den letzten Tagen gemacht habe. Aber jeweils eine Nacht warten, bis man (evtl.) ein Freeze bekommt, ist leider nicht unbedingt echtes Reproduzieren.

Theoretisch könnte ich auch gefälschtes RAM gekauft haben, die zwar mit ECC gelabelt sind, aber es nicht können. Ich könnte evtl. eine fehlerhafte Motherboard-Charge erwischt haben (alle 3 Boards)...und und und. Je länger es dauert, desto weiter muss die Wahrscheinlichkeiten einbeziehen. Aber am Ende habe ich dann 3 komplett neue Systeme mit neuen Komponenten. Das würde ich eigentlich schon gerne vermeiden. Das Zeugs war schon so genug teuer. (Vorallem im 2022 mit den damals noch höheren Preisen.)

P.S. Nur so als Beispiel die History dieser 3 Server:
Alle 3 wurden im September/Oktober 2022 zusammengebaut und in Betrieb genommen. Ganz zu Beginn (also Oktober 22) hatte ich mit allen 3 Server Freezes nach der OS-Installation bzw. ersten Tests. Ich weiss aber natürlich nicht mehr, ob das damals auch verzögert geschah. Die Freezes (max. 2) waren für mich überraschend, aber ich dachte, das lag an falschen/fehlenden Treibern bzw. meiner Konfiguration, weil ich damals noch am Kennenlernen des Systems war. Da es nach effektiver Inbetriebnahme nicht mehr auftrat, habe ich das wirklich nur als Anfangsprobleme abgetan.
Eines dieser 3 System ist meine OPNsense Firewall. Die ist für mich im Homelab natürlich essentiell, weil ich sonst kein Internet hätte. Dort war der letzte Freeze im Dezember 2022 (hab damals glaub OPNsense upgedated). Seitdem läuft dieses System 24h völlig stabil! (wenig Last, weil keine aktiven Security-Features installiert wurden)
Es ist aber (bis auf die SSD) genau die gleiche Hardware wie die anderen 2 Systeme. Aber eben...an diesem OPNsense Server habe ich seit Dezember 2022 nichts gemacht (ausser an den Rules). Das ist wohl der Hauptgrund. Würde ich dort OPNsense updaten (was schon länger bei mir pendent ist), würde ich vermutlich auch wieder einen Freeze erleben.

Bei meinem 2. Server (Proxmox Node 1) laufen ein paar (unkritische) VMs. Bei diesem Server hatte ich im Februar, April und September Freezes. Sehr wahrscheinlich im Zusammenhang mit einem Proxmox-Host-Update. Und diese Freezes decken sich von der Zeit auch mit dem 3. Server (Proxmox Node 2, mit dem ich jetzt aktuell teste).
Es sind also definitiv keine zufälligen Freezes, auch wenn sie wegen der stundenlangen Verzögerung nicht wirklich vorauszusehen sind.

Beitrag automatisch zusammengeführt: 13.10.2023

Nachtrag:

Ich habe vorhin (bisschen willkürlich) paar Dinge im BIOS geändert, in der Hoffnung, dass dies einen positiven Einfluss hat.

Bei der CPU habe ich das Power Management deaktiviert. Es sollten also keine C-States verwendet werden.

Und bei der Memory Configuration habe ich die Maximum Memory Frequency auf 2400 fixiert (war vorher Auto) und noch den Memory Scrambler deaktivert. Was immer der tut.

Ist wirklich (mehr oder weniger) kompetentes raten. Ausser Zeit (und Nerven) kostet mich das aber wenigstens nichts.

Werde dann wiedermal Ubutun 23.04 Server neu installieren und dann den TOP-Befehl bis morgen laufen lassen.

Die, die mit dem Popcorn hier mitlesen, bekommen morgen vermutlich wieder ein Update.

 

[Supaman]

Lasse ich dann diese Installation (in welchem Zustand auch immer) über Nacht einfach laufen (meist ohne spezielle Last, also praktisch idle), dann ist die Chance hoch, dass nach 8-12 Std. der Freeze geschieht.

Das schreit <eigentlich> nach einem Memory Leak.

Frage dazu: hast Du bei den VMs unter Memory "Balooning Device" aktiv ?

 

[visar]

Das schreit <eigentlich> nach einem Memory Leak.

Frage dazu: hast Du bei den VMs unter Memory "Balooning Device" aktiv ?

Memory Leak ja, wenn es immer so nach einigen Stunden passiert. Es passiert bei mir aber ja nur nach einer grösseren Änderung. Nach dem Freeze (und Reboot) läuft es dann monatelang stabil. Ausser das, was das Memory Leak ausgelöst hat, wurde nach dem Freeze auch gestoppt. (Und der zufällig erstellte Screenshot paar Sekunden vor dem vorletzten Freeze zeigt kein Memory Leak an, sofern man das sieht.)

Ich habe die Freezes auch mit einem Standard Ubuntu 23.04 Server (ohne VMs).
Zudem verwende ich zurzeit bei Proxmox nur Container und keine VMs. Soweit ich weiss, kann man Ballooning nur bei VMs aktivieren. (Meine Guest sind nur Linux-Server)