BSOD 0x09c auf 50 SuperMicro-Maschinen


8

Für ein Projekt haben wir 50 Server, die alle (im Allgemeinen) mit derselben Hardware ausgestattet sind. Das Problem, das wir hier haben, ist sehr ernst und tritt auf allen Maschinen auf. Trotz großer Anstrengungen und der Kontaktaufnahme mit Herstellern und Softwareentwicklern zeigen alle aufeinander und weigern sich sogar, mir einen Hinweis darauf zu geben, was los ist.

Lassen Sie mich zunächst das Setup beschreiben. Dies ist 'Servergrade'-Hardware. Nach meiner ersten Erfahrung ist Servergrade die größte Enttäuschung in meinem Leben.

  • SuperMicro X10SDV-8C + -LN2F
  • Intel Xeon D-1540 (eingebettet in das Motherboard)
  • Kundenspezifisches 1U-Gehäuse oder SuperMicro-Originalgehäuse
  • 480-Watt-Server-Netzteil oder 200-Watt-SuperMicro-Original-Netzteil
  • Samsung Evo 850 500 GB SSD
  • 32 GB DDR4-2133 ECC oder NON-ECC (jedoch nicht auf demselben Server gemischt)
  • Asus GT730 4 GB DDR3 GPU
  • Die GPU wird mit einer PCIe-Riser-Karte (kein Farbband) montiert, die namenlos aus China oder dem SuperMicro-Original stammt

Laufen auf dem System - Windows Server 2012 R2 Enterprise - VMWare Workstation 12 - VMs führen GPU-intensive Aufgaben aus - Dieses System ist auf Lager, es gibt überhaupt kein Über- / Übertakten

Symptome - Zufälliges BSOD 0x09c (auch bekannt als Machine_Check_Exception): Manchmal läuft das System eine Woche ohne Probleme, manchmal bei Abstürzen nach nur 10 Minuten, meistens jedoch einige Stunden.

Bereits ausprobiert / geprüft:

  • BIOS auf die neueste Version aktualisiert (ich würde jetzt denken, dass dies die Zeit für die Stabilität des Systems verbessert hat, aber das könnte zufällig gewesen sein).
  • Windows auf die neueste Version aktualisiert.
  • VMWare wurde auf die neueste Version aktualisiert.
  • Tauschte alle Komponenten aus und probierte jede andere Option aus, versuchte sogar ein Desktop-ATX-Netzteil und eine M.2-SSD.
  • Installierte alle Systeme von Grund auf mit Ubuntu. Ich bin nicht mit Linux vertraut und habe noch nie ein Linux-BSOD gesehen, und ich habe es immer noch nicht gesehen, da Serversysteme kopflos sind und ich dies im DC versucht habe. ERGEBNIS: Das System würde hängen bleiben und nach dem Neustart meldete Linux einen XORG-Absturz (GPU-bezogen).
  • Die GPU-Einstellung im BIOS wurde auf "Über 4G" geändert. Der Rest des BIOS ist werkseitig.

Auch informativ:

  • Systeme befinden sich in einem Rechenzentrum. Temperatur, Luft, Leistung und Netzwerk sind optimal.
  • Die Temperaturen liegen deutlich unter dem Werksmaximum
  • Wir haben genau das gleiche Software- Setup auf Desktop-Computern (mit Desktop-Hardware). Dieses System kann einwandfrei funktionieren, wenn 1 von 100 PCs jeden Monat abstürzt.
  • Ich habe VMWare kontaktiert, sagen wir, dies ist ein Hardwareproblem
  • Ich habe SuperMicro kontaktiert, sie sagen nichts wirklich außer einigen Dingen und haben es bereits versucht und auch, dass dies immer noch ein Softwareproblem sein könnte.

Wir sind hier verzweifelt. Die Anwendung, die wir zum Glück ausführen, ist irgendwie überflüssig. Wenn ein Server und die darauf befindlichen VMs ausfallen, ist dies kein Problem. Andere Server übernehmen die Last innerhalb von 5 Minuten. Bei dieser Geschwindigkeit muss ich jedoch den ganzen Tag online sein, um die Server neu zu starten.

Ich habe ein großes Hardware-Wissen, aber das geht darüber hinaus. Ich habe den ganzen Tag über einen Monat lang danach gesucht und alle möglichen Dinge ausprobiert. Die Tatsache, dass diese Motherboards in großem Umfang bei Hosting-Anbietern verwendet werden, lässt mich vermuten, dass das Board selbst in Ordnung ist. Dies ist definitiv kein spezifisches Hardwareproblem für RMA, da alle 50 Karten die gleichen Symptome aufweisen. Das einzige, was bei uns anders ist, ist die GPU. Dies in Kombination mit dem Linux-Experiment lässt mich vermuten, dass dies definitiv etwas auf der PCIe-Spur ist. Die GPU selbst ist auf Desktop-Mobos stabil. Trotz der großen Speicherkapazität ist dies eine kleine GPU, die nicht viel Strom verbraucht. Ich würde die chinesischen Riser-Karten vermuten, aber andererseits verwenden wir auch SuperMicro-zertifizierte Riser und sie zeigen überhaupt keine Verbesserung.

Ich bin sehr verzweifelt, hier eine Lösung zu finden. Dies beginnt mit der Ermittlung der genauen Ursache. Wir sind bereit, einem Experten ein nettes Kopfgeld zu zahlen, der einige Dumps analysieren und uns mehr Details geben kann (oder noch besser eine Lösung).

Mit freundlichen Grüßen,

Simon


Ich bin ein bisschen mit diesem Board vertraut, habe selbst eines ... Es gibt hier zu viele bewegliche Teile und zu wenig Erklärungen dafür, was sie sind. Was nützt VMware Workstation? Welche Anwendung wird in ihnen ausgeführt? Wie wird die GPU an die VM (s) übergeben?
Michael Hampton

Die VMs führen eine Windows-Firma aus, für die eine gewisse GPU-Last erforderlich ist. Ich kann nicht viel weiter darauf eingehen. Dies ist VMWare Workstation, die GPU ist virtualisiert. Dies sollte auch eigentlich keine Rolle spielen, es funktioniert auf Desktop-Hardware ohne Probleme genauso.
user349749

Es ist wichtig, weil Sie es nicht auf Desktop-Hardware ausführen!
Michael Hampton

2
Ich würde eine Inkompatibilität zwischen Ihren Motherboards und Ihren GPUs vermuten. Mit etwas Glück könnte es etwas sein, das im BIOS korrigiert werden kann, aber ich würde nicht viel darauf wetten. Da dies mit einem Standard-Linux-Kernel reproduzierbar ist, würde ich versuchen, mehr Informationen über die Kernel-Panik zu erhalten, die wahrscheinlich auftritt.
Law29

Was in der VM ausgeführt wird, spielt keine Rolle. Es könnte Porno rendern oder vielleicht ist es ein Logaritmus, ein Heilmittel für Hilfsmittel zu finden. Alles was zählt ist eine Standard GPU Last. @ Law29; Genau so fühle ich mich. Linux hat mir keine Kernel-Panik beschert, denke ich. Der Server stürzte nicht ab, nur die GUI.
user349749

Antworten:


2

Nun, das ist super spät. Ich kann mir vorstellen, dass das Problem zu diesem Zeitpunkt behoben ist. In beiden Fällen bedeutet 0x9C normalerweise einen MCE-Hardwarefehler. Auf unseren GPU-Systemen wurde Linux als Host-Betriebssystem ausgeführt, das diese Fehler etwas ausführlicher als Windows meldet.

Wie auch immer, diese tauchten vor einiger Zeit zufällig auf ähnlicher Hardware von HP auf. Dies führte zu einer unzureichenden Stromversorgung der GPU. Insbesondere die 75 W, die vom PCIe-Port selbst geliefert werden sollen.

Wir haben dies mit einem Multimeter auf einem PCIe-Breakout-Board bestätigt. Die Spannung sank, als sowohl die GPU- als auch die 10-Gbe-Netzwerkkarte gleichzeitig hart getroffen wurden. Während das Motherboard 75 W an den x16-Steckplatz liefern konnte, hatte der Stromversorgungsbereich ein wenig Probleme, als die anderen Karten alle Strom verbrauchten.

Der Riser kann hier verdächtig sein und bei hohen Strombelastungen die Spannung abfallen.


0

Danke für deine Antwort. Es ist jetzt 3 Jahre später. Supermicro hat sich geweigert, uns in jeder Hinsicht zu helfen. Wir haben mehrere Maschinen verschickt (genau wie von uns gebaut). Ihnen zufolge haben sie sie wochenlang gestresst und sind nie abgestürzt.

Beim Riser tritt der gleiche Fehler bei der GPU direkt im Steckplatz auf.

Supermicro gibt VMWare weiterhin die Schuld, etwas, an das ich glauben wollte, bis ich die neue Version desselben Boards in die Hände bekam. Ohne Kommentare von Supermicro wurde das Board mit dem Xeon D-1540 kurz nach wenigen Monaten mit einem Xeon D-1541 aktualisiert. Das neue Board ist im Grunde das gleiche wie für die neuere CPU (auch das gleiche, nur etwas höhere Takt). Das aktualisierte Board verfügt außerdem über einen zusätzlichen Lüfter-Header.

Diese Boards stürzen nicht mehr ab. Mit genau der gleichen Last laufen sie monatelang ohne Probleme. Ich habe hier sogar Maschinen geklont, auf denen genau die Hardware und Software der abstürzenden Maschinen ausgeführt wird.

Diese Art bestätigt meinen Verdacht. Supermicro weiß, dass es ein Problem mit den Boards gibt, möchte mir aber nicht sagen, warum, weil fast 100 dieser Boards wegen der Abstürze unbrauchbar wurden. Ihr war nie und RMA oder Fix nicht einmal BIOS-Update dafür, also muss es etwas auf dem Board gewesen sein.

Unnötig zu erwähnen, dass ich zum ersten und letzten Mal bei Supermicro war. Dies könnte natürlich jeder Marke passieren, aber die Unterstützung war unter Null.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.