Gigabyte X670E Aorus Master mit fehlenden UEFI-Funktionen und ein völlig überforderter Support

1 - Einführung und Problemstellung 2 - Mailverkehr - Viel Text für nichts 3 - Von Gigabyte zu MSI - Und alles läuft

Der heutige Artikel zeigt leider einmal mehr, wie weit die Lücke zwischen Hersteller-Anspruch, Marketing, bezahltem Influenzertum, Support und Wirklichkeit klafft. Mir ist es in solchen Fällen (wenn sich ein langjähriges Mitglied der Community bei mir meldet und entnervt alle Unterlagen und Korrespondenzen anbietet, um vor gewissen Herangehensweisen im Support zu warnen) letztendlich auch egal, um wen oder was es geht, wenn der Kunde so sichtbar im Recht ist. Es hätte in diesem Fall jeden Hersteller gleichermaßen treffen können, aber Schweigen hilft niemandem.

Wichtiges Vorwort – Unbedingt lesen!

Ich will eines vorab klarstellen: es ist heute KEIN Rant gegen ein Produkt im Besonderen oder Gigabyte im Allgemeinen, sondern es zeigt die Hilflosigkeit zweier Parteien, die sich am Ende nicht auf einem gemeinsamen Nenner treffen konnten. Der fragende und hilfsbereite Kunde wird von einem hilflosen deutschen Produkt-Support fast in den Wahnsinn getrieben. Nur muss ich zum besseren Verständnis voranstellen, dass der Kunde des damals fast 600 Euro teuren Produkts mehr Ahnung von der angemahnten Materie hat, als so mancher Mitarbeiter bei Gigabyte zu haben scheint (es aber eigentlich müsste). Ok, das wiederum kann der Support zwar vorab nicht wissen, hätte es aber im Verlauf der Konversion eigentlich merken können.

Ich will auch nicht über die eingebauten Eskalationsstufen des Supports im Allgemeinen diskutieren, die vorab filtern, mit welchem Problem das Headquarter letztendlich noch kontaktiert wird, denn Vieles kann man ja per Checkliste vorab klären. So etwas ist korrekt und üblich. Ein Fehler, wie der heutige, gehört aber definitiv nicht zu diesem Bereich, sondern schnellstens auf den Tisch der UEFI-Entwickler und nicht irgendeines FAE. Und genau da ist der Support gefordert, dies auch gefälligst so zu erkennen und zu handeln. Das eigentliche Problem des heutigen Artikels ist eine Kommunikationskette, die nicht funktioniert hat.

Denn auch wenn das UEFI einen Schnittstellen-Fehler ab Werk aufweist, ist es kein großes Problem, so etwas zu beheben und dem Kunden (und seinem Produkt) zu helfen. Ich habe mich mit meinen Bekannten aus den Entwicklungsabteilungen diverser Mainboard-Hersteller ausgetauscht und es stieß überall auf komplettes Unverständnis, wie sich ein Hersteller durch eine derartige Ignoranz in den ersten Eskalationsstufen selbst vom Informationsfluss abschneidet, den er eigentlich dringend benötigt. Das soll vorab reichen, nur wollte ich auch die Korrespondenz ins rechte Licht rücken.

AMI Aptio und Fehler bei der UEFI-Anpassung

Zum Verständnis und als Begriffserklärung für Außenstehende: AMI Aptio bezieht sich auf eine Familie von UEFI Firmware-BIOS-Lösungen für moderne PC-Mainboards, die von der Firma AMI (American Megatrends Inc.) entwickelt wurden. UEFI steht für “Unified Extensible Firmware Interface” und ist der Nachfolger des traditionellen BIOS (“Basic Input/Output System”), das in älteren PCs verwendet wurde. AMI Aptio nutzt dabei die UEFI-Spezifikationen, die erweiterte Funktionen und Sicherheitsmerkmale gegenüber dem herkömmlichen BIOS bieten. Es erleichtert den Herstellern zudem, ihre Firmware nach ihren spezifischen Anforderungen anzupassen. Und genau da liegt das Problem, mit dem wir es heute zu tun haben.

Die sogenannte Human Interface Infrastructure (HII) bietet Standards für die Kommunikation zwischen Mensch und Maschine, in diesem Falle z.B. mit Erweiterungskarten für den PC bzw. Server. Und genau an dieser Stelle besitzt das Gigabyte X670E Aorus Master einen gravierenden Mangel:

Das Board ist nicht in der Lage, das HII Interface der meisten Nicht-Intel Erweiterungskarten sauber und vollständig im UEFI einzublenden zu lassen, so dass man diese bequem und ohne Probleme direkt im UEFI konfigurieren kann (Sicherheitsfeature!). Es ist dabei komplett unverständlich, warum so eine grundlegende Information nicht nur nicht mit Priorität weitergegeben wurde, sondern man den Kunden ignoriert und am Ende mit einem für ihn nun nutzlosen 600-Euro-Ziegelstein im Regen stehen lässt. Aber es zeugt leider auch von einer gewissen Mentalität, sich Problemen zu verweigern, um den eigenen Aufwand zu minimieren.

Auf dem Bild sehen wir das Testfeld des Kunden (von links nach rechts) und das, was ging bzw. meist nicht:  Broadcom P225P (Firmware aktuell!), daneben die obere Reihe mit der OEM i210, OEM x550 T2L sowie Intel X710 T2L (keine OEM, Original von Intel) und die untere Reihe mit Emulex OCE14102 (10GbE RJ45) (Firmware aktuell), Emulex OCE14xxx (10GbE SFP+), Emulex OCE11xxx (10GbE SFP+) (Firmware aktuell, sehr alt, aber mit UEFI Support und HII) sowie ein LSI Megaraid (ACAGO/ Broadcom 9271 4i mit Superkondensator).

Bei RAID-Controllern ist das wichtig bzw. interessant, um eben im UEFI direkt RAID-Volumes anlegen zu können. Bei Netzwerkkarten, wie in unserem Fall, bezieht sich das auf das Konfigurieren von Features wie nPar/ SR-IOV oder auch der Art und Weise, wie der NIC sich dem OS meldet (Hardwarefeatures/ Gerätetyp) usw. falls er unterstützt wird. Auch Firmwareupdates sind dabei (wie bei beispielsweise bei einer Emulex OCE14102 T2)  direkt im UEFI möglich, ohne dass man sich irgendwelche Bootlaufwerke oder USB Sticks mit der EFI Shell basteln muss.

Teilweise gibt es sogar Features, die nur in einer UEFI Umgebung funktionieren bzw. eingestellt werden können. Es hilft also z.B. nicht, bei einem LSI Megaraid per Legacy Mode in das ROM zu gehen und dort die Unterstützung von großen Adressbereichen zu aktivieren. Das wird (logischerweise) sofort wieder deaktiviert, da dies unter dem Legacy Boot nun mal nicht funktioniert. Hier ist das Fehlen des HII Interface also sogar der Performance abträglich und durchaus auch sicherheitsrelevant!

Es ging doch schon einmal (nicht)

Was dem Kunden zu denken gab: er besitzt noch ein Gigabyte X299 Aorus Master und auf diesem Board trat anfangs der gleiche Fehler auf. Das HII Interface wurde dann eine Zeit später stillschweigend übers BIOS-Update wieder zugefügt, ohne aber explizit in den Change-Logs aufzutauchen. Gigabyte hatte dieses Problem also schon einmal und kennt es auch, nur ist der Support noch nicht einmal in der Lage, so eine Information fürs Unternehmen gewinnbringend einzuordnen. Ein FAE hätte das wissen müssen.