Supermicro H12 Serie - Finger weg!

[java4ever]

Hallo zusammen,

Ich möchte hier eine kurze Warnung bzgl. der Supermicro H12 Serie (Spezifisch: H12SSL-i / H12SSL-NT und H12DSi-N6 und H12DSi-NT6) aussprechen. Ich würde diese Boards NICHT empfehlen.

Grund Nr. 1:
Boards der Revisionen Rev 1.0, Rev 1.01 und Rev 1.02 nutzen sogenannte "Bare-Die" VRMs. Hier handelt es sich um Spannungsregulatoren, die direkt aus dem Wafer geschnitten sind und OHNE JEGLICHEN Schutz (die haben KEIN Gehäuse) verwendet werden. Die Nutzung dieser Teile ist wohl eine Folge der Halbleiterkrise damals in Corona.

Problem: Diese Spannungsregulatoren sind EXTREM anfällig. Teilweise reicht schon der leichte Flex des Boards beim Installieren einer PCIe Karte, um diese Spannungsregulatoren zu beschädigen. Teilweise sind diese Spannungsregulatoren auch auf der Rückseite des Boards verbaut, sodass diese beim Installieren des Boards einfach beschädigt werden können.

Die Spannungsregulatoren werden sowohl für den BMC, als auch in der Nähe des Sockels benutzt.

Typische Symptome:

• Board zeigt absolut keine Lebenszeichen
• BMC Heartbeat LED leuchtet nur extrem schwach
• Board bootet, aber hängt ewig bei "Waiting for BMC"

In Rev 1.10 scheint das alles behoben zu sein. Es gibt zahllose Berichte von Leuten mit demselben, extrem spezifischen Problem (allein im ServeTheHome Forum 17 Leute + mich selbst)

Leider geht Supermicro mit diesem Problem extrem unsouverän um. Der Support leugnet alles (Problem wäre nicht bekannt, etc) und bei der RMA Abwicklung gibt es außerhalb der einjährigen Garantiezeit kaum Kulanz.

Ein paar Zitate von Supermicro:

Ultimately forum posts don’t mean much to our PMs.

We have sold many thousands of these motherboards, a hand full forum posts of boards having issues with similar observations doesn’t mean there is a revision issue specifically.

I had a conversation with the PM just now, he went through the RMA reports of the H12SSL board, there is no significant change in failure rate or failure causes before and after the revision 1.10 update. He also looked at returns from large customers, and there are no large scale returns for the board from any particular supplier.

We are aware of changes where components were placed in different places to prevent those components from easily getting damaged when fitting a motherboard into a chassis or when placing add-on hardware. I can’t see what exactly waws done with the revision update, this would require a signed NDA to obtain details about and this will only be provided to companies, not individual end users.

Das klassische "Wir tun einfach so als gäbe es kein Problem"... Für Serverhardware dieser Preisklasse ein No-Go.


Grund Nr. 2:
Die Boards haben extrem komische BIOS bugs.
Aktuelles Szenario: Neuer Workstation Build von mir mit H12SSL-NT, EPYC 7773X CPU, 8x64GB RAM, etc.
BIOS 2.9 / 2.8:
2x onboard M.2 + CX623106AC + RTX3050 -> Boot

2x onboard M.2 + CX623106AC + AOC-SLG4-4E4T -> Boot

2x onboard M.2 + CX623106AC + SSDs via onboard SlimSAS -> Boot

2x onboard M.2 + CX623106AC + AOC-SLG4-4E4T + SSDs via onboard SlimSAS -> Boot

2x onboard M.2 + CX623106AC + RTX3050 + AOC-SLG4-4E4T + SSDs via onboard SlimSAS -> KEIN Boot

2x onboard M.2 + RTX3050 + AOC-SLG4-4E4T + SSDs via onboard SlimSAS -> Boot
BIOS 2.7:
2x onboard M.2 + CX623106AC + RTX3050 + AOC-SLG4-4E4T + SSDs via onboard SlimSAS -> Bootet problemfrei
Wie man es schafft mit einem BIOS Update normale PCIe Karten nicht mehr funktionieren zu lassen erschließt sich mir nicht. Das ist jetzt auch keine allzu außergewöhnliche Konfiguration.

Auch hier ist leider der Umgang mit dem Problem durch den Supermicro Support sehr unsouverän und mit "Mangelhaft" zu bewerten:

OK so as previously mentioned this hardware configuration is not officially tested/validated so we can’t guarantee that it will work properly.

If your current hardware configuration is indeed working under bios 2.7 , we cannot guarantee that it will keep working with a new bios version,

I will check this with our MBD PM for any comment on this matter but I will recommend you to keep using the bios2.7.

Please note that Supermicro only test/valid GPU’s at the system level ,not at the MBD level and your MBD H12SSL-NT is not assembled on any Supermicro GPU systems so we can’t recommend any specific GPU.

Also die klassische Ausrede "Das ist nicht validated, ist uns egal". Für Serverhardware dieser Preisklasse ebenfalls ein No-Go.



Alles in allem kann ich von diese Boards nur dringend abraten.

 

[Fusseltuch]

Wir haben zwei Server mit H12SSW-NTR (im Einsatz, die sind aber als kompletter Server gekommen und nicht als einzelnes Board. Bisher unauffällig, aber wie gesagt, kompletter Supermicro-Server mit Gehäuse usw, die Boards haben das Gehäuse nach Ersteinbau also nie verlassen. Ich habe alles mögliche an Steckkarten nachgerüstet, bisher keine besonderen Vorkommnisse.

Der Support ist in der Tat durchwachsen, das kann ich in jedem Fall bestätigen. Aber: die Aussagen, dass zumindest Produktverantwortliche befragt werden, ist auch nicht selbstverständlich. Scheinbar hat der Supporter ja was gemacht, auch wenn die Antworten am Ende doch nur Bla Bla sind. Manches davon, insbesondere "dann bleiben Sie halt auf Version 2.7 wenn's funktioniert", geht aber absolut nicht.

Der Tyan-Support ist aber kein bisschen besser. Die scheinen ihr BIOS zwar insgesamt etwas besser im Griff zu haben, kooperativ sind die aber auch nicht. Hatte nach reBAR-Support für's S8030 gefragt. Kam auch nur lapidar die Antwort, dass das nicht umgesetzt wird. Das S8030 wurde aber auch in GPU-Servern eingesetzt...

 

[sch4kal]

Naja was soll ich dazu sagen. Für uns Nerds als Hobbyserver Bastler sicherlich kacke, aber Supermicro gibt ja auch QVLs raus, wenns damit nicht klappt könnte ich einen Full-Blown Shitstorm voll und ganz verstehen. Ansonsten hab ich leider/zum Glück keine Erfahrung mit den SM H12 MoBos gemacht.

Die Probleme hatte ich aber auch bei meinem MZ32-AR0 von Gigabyte. Da gabs auf deren FTP Server damals wesentlich neuere und viel mehr BIOS Versionen zum Runterladen als auf deren offizieller Seite. Ich hatte da leider nur etwa 3 Monate Zugriff drauf, bis sie die Credentials geändert/deaktiviert haben. Selbst wenn ich jetzt über unsere Firma bei meinem Sales-Rep für Gigabyte anfrage, bei dem ich das Board für mich selbst bestellt hatte, kommt keine Reaktion mehr seitens Gigabyte. Ursprüngliches Problem siehe https://www.hardwareluxx.de/community/threads/gigabyte-mz32-ar0-rev-1-0-auf-3-0-flashen.1327949/
Da scheint es also sogar verschiedene Rev 1.0 Boards zu geben, manche können auf Rev 3.0 geflashed werden, Manche nicht. Mittlerweile hat Gigabyte das Problem behoben, sie nennen die neuen rev 3.0 Boards einfach MZ32-AR1

Da gibts also Seitens SM wenigstens mehr Kommunikation als bei Gigabyte, die melden sich einfach gar nicht mehr auf Anfragen.

 

[java4ever]

Wir haben zwei Server mit H12SSW-NTR (im Einsatz, die sind aber als kompletter Server gekommen und nicht als einzelnes Board. Bisher unauffällig, aber wie gesagt, kompletter Supermicro-Server mit Gehäuse usw, die Boards haben das Gehäuse nach Ersteinbau also nie verlassen. Ich habe alles mögliche an Steckkarten nachgerüstet, bisher keine besonderen Vorkommnisse.

Ja beim H12SSW-NTR läuft das ja alles über Riser, und der BMC ist ein gutes Stück von dem Slot entfernt.

Der Support ist in der Tat durchwachsen, das kann ich in jedem Fall bestätigen. Aber: die Aussagen, dass zumindest Produktverantwortliche befragt werden, ist auch nicht selbstverständlich.

Das kommt immer. Ich glaube das Problem sind tatsächlich die PMs. Die haben mir auch schon ein paar andere komische Aussagen um die Ohren gehauen
(bspw. auf die Frage warum man Link Speed von PCIe Slots auf Supermicro boards nicht manuell forcen kann "Das braucht ja keiner" - DOCH zum Troubleshooting)

Für uns Nerds als Hobbyserver Bastler sicherlich kacke, aber Supermicro gibt ja auch QVLs raus

Weißt du wie viele PCIe Karten auf der QVL vom H12SSL-NT stehen?
EINE. EINE EINZIGE.

Da gibts also Seitens SM wenigstens mehr Kommunikation als bei Gigabyte, die melden sich einfach gar nicht mehr auf Anfragen.

Ob man jetzt inhaltsloses blabla zurückkriegt oder keine Antwort, kommt unterm Strich aufs selbe raus

 

[besterino]

Ich hab bisher mit dem Support von SM eigentlich sehr gute Erfahrungen gemacht. Meine Anfragen wurden schnell und kompetent beantwortet, da ging es allerdings auch nicht um irgendwelche Defekte.

SM war auch vor den H12 bisweilen schon zickig, insb. bei der Kombination gewisser Hardware, teilweise auch abhängig von was steckt in welchem Slot usw. Häufig halt missliches trial & error bis hin zu harter Inkompatibilität.

Frage ist aber auch, was gibt's für Alternativen? AsrockRack mag ich grundsätzlich, ist aber in meinen Augen definitiv deutlich mehr "Bastelbude" als SM. Gigabyte hingegen würde ich zum Beispiel nicht mal mit der Kneifzange anfassen, wenn ich in irgendeiner Form Erwartungen an Zuverlässigkeit, Support oder sonstige Professionalität hätte. Die taugen halt für absolute Schnapper wie das MC12-LE0 - wenn's funzt, hurra, wenn nicht --> Pech gehabt & Tonne.

Klar, ich kann nun auch nicht mit Erfahrung mit dutzenden Mainboards wuchern, sondern habe davon vielleicht bisher 5 oder 6 selbst in Verwendung gehabt. Umgekehrt käme mir z.B. nie wieder ein Intel-Server-Mainboard ins Haus.

 

[p4n0]

AsrockRack mag ich grundsätzlich, ist aber in meinen Augen definitiv deutlich mehr "Bastelbude" als SM.

+1

Bei meinem B650 AsrockRack finde ich zeug wie: ‚For testing purposes only, DO NOT CHANGE‘ Einstellungen im Bios. Nicht grad vertrauenserweckend

 

[AliManali]

Hatte schon ein ASRock SP3 verbauen dürfen. Sehr geiles Brett. Da gab es nichts zu beanstanden. War allerdings auch das einzige Epyc Board, was ich bislang in der Hand hatte. 7x 16x PCI-E 4.0, und hat auch sonst ganz viel Ausstattung zu bieten.

Als Bastelware würd ich das nicht bezeichnen:

ASRock Rack > ROMED8-2T

www.asrockrack.com

Bei SM vermisse ich halt auch immer das Debug Display. Und auch von den Gehäusen war ich enttäuscht. Entweder nicht lieferbar, oder halt so werkzeugloser OEM Kram. Dachte SM sei schrauberfreundlicher.

Wenn ich jetzt wählen dürfte zwischen SM, ASUS oder ASRock Rack, würde ich zu ASRock tendieren. Bin da aber keine Referenz.

 

[besterino]

Hab von AsrockRack die „Kultbretter“ (zumindest in meinen Augen ) X399D8A-2T und TRX40D8A-2n2t - will nicht meckern, laufen gut. Aber BIOS-Pflege zum Beispiel ist eher so „meh“ (last time I checked).

„Bastelbude“ kommt für mich halt daher, weil AsrockRack auch ab und an so komische Sachen bringt, die außerhalb der offiziell supporteten Bandbreite liegen, z.B. die „Server“-Bretter für AM4 (auch AM5?) mit „ECC-Support“. Sowas würde SM schon vom Grundsatz her halt nicht machen, weil sie es gar nicht vernünftig Supporten könnten. Soll nicht heißen, dass das nicht auch funzt, aber das Testen liegt halt da beim Kunden und der ist im Zweifel eben auf sich allein gestellt.

 

[MrWahoo]

Sowas würde SM schon vom Grundsatz her halt nicht machen

Erzähl das mal dem H13SAE-MF

 

[besterino]

Na immerhin (auch) für Epycs… wobei ich mit den 4000ern null Erfahrung habe.

 

[Luckysh0t]

„Bastelbude“ kommt für mich halt daher, weil AsrockRack auch ab und an so komische Sachen bringt,

Warum sollte ASrockRack auch anders agieren als Asrock. Wie der Vater so der Sohn - oder so ähnlich, wenn ich da an die Sockel 754/939 dual Boards, oder ein 939 Board mit AM2 Riser denke

 

[Icenice]

Boards der Revisionen Rev 1.0, Rev 1.01 und Rev 1.02 nutzen sogenannte "Bare-Die" VRMs. Hier handelt es sich um Spannungsregulatoren, die direkt aus dem Wafer geschnitten sind und OHNE JEGLICHEN Schutz (die haben KEIN Gehäuse) verwendet werden. Die Nutzung dieser Teile ist wohl eine Folge der Halbleiterkrise damals in Corona.

Gibts da ein Bild von solchen VRMs (am besten direkt auf einem SM-Board)? Würde mich mal interessieren, da ich von sowas noch nichts gehört habe.
Kann mir gerade sowas schwer vorstellen, den der Chip wird ja auf einem Träger gebondet und dann kommt das Gehäuse drum rum.

 

[java4ever]

Kann mir gerade sowas schwer vorstellen, den der Chip wird ja auf einem Träger gebondet und dann kommt das Gehäuse drum rum.

nö

Wenn man aus dem richtigen Winkel draufschaut / leuchtet sieht man die richtig schön hervorblitzen / reflektieren. Da ist kein Gehäuse drum.

bspw hier einer der am Sockel, links neben "U60"

oder hier die am BMC (Bild aus dem STH geklaut, bin zu faul)

Wenn ich mich recht entsinne sind das TPS62088 (https://www.ti.com/product/de-de/TPS62088#order-quality).
Da sieht man dann unten "DSBGA (YFP)"

DSBGA = Die Size Ball Grid Array
Die Size Ball Grid Array (DSBGA), also known as Wafer Chip Scale Package (WCSP), refers to packaging an IC in wafer form, in contrast to packaging an IC after it has been singulated from the wafer. It uses a copper redistribution layer to connect the silicon interconnect to an array of solder balls. The package size is equal to the silicon die size, enabling WCSP to have the smallest form factor compared to other package types. WCSP is a great package solution for space-constrained applications such as mobile or wearables.

Find all TI packages | Texas Instruments

Find the Die Size Ball Grid Array (DSBGA) package drawing and specs such as pin count, pitch and dimension.

www.ti.com

 

[Icenice]

nö

Doch Bei "normalen" Bauteilen. Das die hier anders sein müssen, war mir schon klar.

DSBGA = Die Size Ball Grid Array

Jetzt weiß ich, was du meinst. Solche Bauformen habe ich tatsächlich schon gesehen; konnte es jetzt nur nicht der Bezeichnung zuordnen.

Diese Spannungsregulatoren sind EXTREM anfällig. Teilweise reicht schon der leichte Flex des Boards

Da bin ich anderer Meinung. Ich kann mir absolut nicht vorstellen, dass man ein Board so verbiegen kann, dass diese Teile beschädigt werden. Niemals; dafür sind die viel zu klein.
Vorher geht eher was anderes kaputt. Auch ist auf dem eine Bild klar eine extern zugefügte Beschädigung zu erkennen -> Schraube in unmittelbarer Nähe; alles klar
Wenn man mit der Slotblende unsanft gegen Bauteile stößt, passiert sowas schon mal. Mit ist auch klar, dass da ein herkömmliches Bauteil mit Gehäuse weniger empfindlich ist.
Beim Einbau des Boards sollte man halt genauso wenig über die Abstandshalter schrammen. Das alles gilt aber unabhängig von diesen speziellen Bausteinen.
Man kann einem Hersteller keine Vorwurf machen, wenn er Garantileistungen aufgrund sichtbarer Beschädigung an Bauteilen ablehnt.

Die Teile kosten ja fast nichts bei Digikey oder Mouser und lassen sich super einfach tauschen. Ich nehme Aufträge an

Das mit dem Bios ist eine andere Geschichte

 

[java4ever]

Da bin ich anderer Meinung. Ich kann mir absolut nicht vorstellen, dass man ein Board so verbiegen kann, dass diese Teile beschädigt werden. Niemals; dafür sind die viel zu klein.

ich Verkauf dir gerne alle meine Rev 1.01 oder 1.02 boards dann kannst du das selbst rausfinden

 

[Icenice]

Nee, danke 😅 Ich habe keine Verwendung für so ein overkill Board und dazu noch der Preis 😳 Die passende CPU ist ja auch kein Schnäppchen.

Aber mein Angebot mit dem tauschen des entsprechenden Bauteils steht immer noch.
Ich vermute mal, dass Rev 1.10 ein anderes Layout und auch andere Bauform für diese VRMs hat?

 

[myBerg]

In meinem Homelab habe ich das H12SSL-NT in Rev 1.02 und das H12SSL-i in Rev 1.10.

Das der U60 in der Rev 1.10 ein anderes Gehäuse hat als in der Rev 1.02 kann ich bestätigen.

Der Bereich neben der Schraube MH1 ist bei mir bei beiden Boards komplett unbestückt. U4, U5 und U6 gibt es gar nicht. Insgesamt habe ich 6 spiegelnde Chips gefunden. Auf der Unterseite (Das NT-Board ist sowieso gerade ausgebaut) keine.

Die geschilderten Probleme hatte ich zum Glück bisher nicht, ABER ich finde es überaus irritierend, dass Supermicro die Firmware der auf dem Board verbauten Hardware nicht aktiv pflegt. Beispielsweise bekommt man nur auf Nachfrage eine neue Firmware für den in der NT-Variante verbauten Broadcom BCM57416. Normalerweise sind solche Updates in den BIOS-Update-Paketen enthalten. Bei Supermicro muss man explizit nachfragen. Aber man weiß ja nicht, ob was Neues zur Verfügung steht. In der Kombination mit Broadcoms quasi nicht vorhanden Treiber-Engagement für Linux ist das einfach eine Katastrophe. Siehe z.B. hier https://forum.proxmox.com/threads/broadcom-nics-down-after-pve-8-2-kernel-6-8.146185/post-703392

Von der NT-Variante des Boards würde ich daher auch abraten.

 

[java4ever]

In der Kombination mit Broadcoms quasi nicht vorhanden Treiber-Engagement für Linux ist das einfach eine Katastrophe. Siehe z.B. hier https://forum.proxmox.com/threads/broadcom-nics-down-after-pve-8-2-kernel-6-8.146185/post-703392

Ja in diesen Bug bin ich auch reingelaufen nach Wechsel von ASRock ROME2D16-2T auf H12SSL-NT...

Warum bootet mein Linux nicht? Oh, doch. War nur zu ungeduldig. Hä wo sind meine ZFS pools?! OHHHHH FU***** BRÖTCOM

 

[java4ever]

Kleines Update:

Supermicro schaut sich jetzt tatsächlich den GPU-BIOS-Bug an! Hab jetzt schon 6 Beta-BIOS durchprobiert. Wobei ich vermute, dass sie gerade erst den Bug bisecten, ein Fix dürfte noch ein wenig dauern und ein paar mehr BIOS Versionen erfordern

 

[Kullberg]

Ich hab 4 Rechner mit Supermicro H12DSi-N6 und einen mit Supermicro H12DSi-NT6 - die laufen 24/7 problemlos. Die Alternativen sind nicht besonders attraktiv.
Allerdings hab ich keine Karten in den PCIe Slots. Dafür sind die VRMs maximal gefordert - die Rechner laufen teils stundenlang mit Dauervolllast.

 

[java4ever]

Zu früh gefreut bzgl. BIOS… Nach ca 10 getesteten Beta BIOSen:

Hi Robin,
Please be informed that after all those tests our TWN BIOS team found out that your problem is due to your specific hardware configuration and security patch(Stage 4).

In this case it means that to provide you a definitive solution you will have to use an OEM bios specifically made for your case; to do so you will have to contact your supplier that must contact his Supermicro sales representative for this OEM bios request.

Please note that OEM bios will have a charge fees

Da ist Supermicro nicht nur der Clown, sondern der gesamte Zirkus.

 

[myBerg]

In der Kombination mit Broadcoms quasi nicht vorhanden Treiber-Engagement für Linux ist das einfach eine Katastrophe. Siehe z.B. hier https://forum.proxmox.com/threads/broadcom-nics-down-after-pve-8-2-kernel-6-8.146185/post-703392

Von der NT-Variante des Boards würde ich daher auch abraten.

Mittlerweile wurde der Support erweitert. Z.B. steht beim BCM95741X/BCM95750X jetzt Ubuntu auch 24.04 LTS (6er Kernel) mit auf der Supportliste ( https://techdocs.broadcom.com/us/en...installation/supported-operating-systems.html )

Und es gibt auch neuere Linux-Treiber für Karten, die den selben Chipsatz haben wir das Board (z.B. https://www.broadcom.com/products/ethernet-connectivity/network-adapters/p210tp )

Es gibt auch seit ein paar Wochen wieder ein neues BIOS v3.0.