Der Kontext muss zuerst stehen, weil er tragend ist. Die Raptor-Lake-Instabilität von Intel – eine Klasse von Abstürzen, Hängern und langfristiger Chip-Degradation, die einen Großteil der mobilen und Desktop-Silizium der 13. und 14. Intel-Core-Generation betrifft – ist kein von Minisforum verursachtes Problem. Intel hat es verursacht, Intel hat es bestätigt, und Intel hat die Garantiezeit der betroffenen SKUs verlängert, nachdem die Ursache als Kombination aus dem eTVB-Algorithmus (enhanced Thermal Velocity Boost) und einem VMin-Shift-Degradationsmechanismus in den betroffenen Kernen identifiziert worden war. Käufer, deren Raptor-Lake-Chips sich in den vergangenen zwei Jahren erratisch verhielten, haben zuerst und vor allem eine berechtigte Beschwerde gegen den Silizium-Hersteller. Das ist der faire Rahmen.

Warum es dennoch lohnt, über Minisforum zu schreiben: Von allen Wegen, auf denen ein Hardware-Hersteller auf einen bekannten Upstream-Bug des von ihm verkauften Siliziums reagieren kann, hat Minisforum einen der leiseren gewählt – und seine Kunden leben mit den Folgen dieser Entscheidung bis heute.

Wie der MS-01 betroffen war

Der MS-01 wurde mit Intels Core i9-13900H und Core i5-13500H als Top-CPU-Konfigurationen auf den Markt gebracht. Beide sind Raptor-Lake-Chips der 13. Generation. Beide fallen in den Bereich der Intel-SKUs, für die das Intel-Community-Forum nutzerseitige Instabilitätsmuster dokumentiert hat, die mit dem späteren eTVB/VMin-Shift-Eingeständnis des Unternehmens vereinbar sind, und die die VideoCardz-Berichterstattung von 2024 als branchenweite Untersuchung beschrieb.

Im Fall des MS-01 zeigt sich das Muster in zwei Ausprägungen. Der Workstation-Test des MS-01 mit i9-13900H bei NotebookCheck dokumentierte unvorhersehbare Abstürze während mehrschleifiger Cinebench-Läufe – genau jener Dauerlast-Test, der das Spannungs- und Boost-Fehlverhalten von Raptor Lake sichtbar macht. Der XCP-ng-Forumsthread zur MS-01-Instabilität unter Hypervisor-Last erfasst die andere Ausprägung: Maschinen, die unter Desktop-Last unauffällig laufen und sich dann aufhängen oder neu starten, sobald eine Virtualisierungslast viele Kerne über längere Zeit beschäftigt.

Nichts davon ist Beleg für MS-01-spezifische Hardwarefehler. Es ist Beleg dafür, dass Raptor Lake an die Grenzen von Raptor Lake stößt, in einem Gehäuse, das keine thermischen oder leistungsseitigen Besonderheiten aufweist, die das Silizium anders verhalten ließen als anderswo.

Was Minisforum tat und was es nicht aufschrieb

Minisforum hat für den MS-01 in diesem Zeitraum BIOS-Updates veröffentlicht. Einige dieser Updates enthalten Mikrocode-Revisionen, die in der Downstream-Akte dem Mikrocode entsprechen, den Intel zur Behebung des Raptor-Lake-Verhaltens bereitgestellt hat. Das ist die gute Hälfte der Geschichte. MS-01-Besitzer, die ihr BIOS aktuell hielten, haben im Großen und Ganzen von den Milderungen profitiert, die schließlich upstream ausgeliefert wurden.

Die weniger gute Hälfte: Die BIOS-Release-Notes von Minisforum sprachen an dem Punkt, an dem der Großteil dieser Updates ausgerollt wurde, nichts davon aus. Ein Kunde, der die Notes las, sah Versionsnummern, in Allgemeinformeln gefasste Änderungslisten (“improved stability”, “updated microcode”) und keine ausdrückliche Aussage, dass das Update den von Intel eingeräumten CPU-Bug adressiere. Ein Kunde, der der branchenweiten Raptor-Lake-Geschichte nicht folgte, hatte keine Möglichkeit zu erkennen, ob die Instabilität seines Geräts durch das vor ihm liegende Update behoben werden würde. Die Entscheidung, ein BIOS zu flashen – ein nicht-trivialer Vorgang an einem 1,9-Liter-Mini-PC, der im Fehlerfall unbrauchbar werden kann –, wurde getroffen, ohne über die für die Abwägung nötigen Informationen zu verfügen.

Die Informationen, die der Kunde gebraucht hätte

Eine gute BIOS-Release-Note in genau diesem Szenario hätte drei Dinge in Klartext gesagt:

  1. Den adressierten Bug. “Dieses Update enthält Intel-Mikrocode-Revision XXX, die die in Intel-Advisory YYY beschriebene eTVB/VMin-Shift-Instabilität von Raptor Lake adressiert.”
  2. Die betroffenen Geräte. “MS-01-Konfigurationen mit i9-13900H und i5-13500H sind betroffen. Konfigurationen mit i9-12900H sind nicht betroffen.”
  3. Was der Nutzer erwarten soll. “Wer vor dem Update unerwartete Hänger unter Dauerlast erlebt hat, dem wird dieses Update empfohlen. Nach dem Update kann die Leistung unter Dauerlast aufgrund angepasster Boost-Charakteristik um bis zu N Prozent von früheren BIOS-Versionen abweichen.”

Nichts davon stand dort. Es war in jedem Fall Aufgabe des Kunden, Tom’s Hardware, Ars Technica und den Intel-Community-Thread zu lesen, das Gelesene in eine eigene BIOS-Update-Entscheidung zu übersetzen und zu hoffen, dass die Übersetzung stimmte. Manche Käufer übersetzten korrekt. Andere hörten ganz auf, Firmware zu aktualisieren, weil das Vertrauen, das ein BIOS-Flash ohne klare Release-Notes erfordert, höher war, als sie zu leisten bereit waren.

Der strukturelle Vorwurf

Es ist aufrichtig unfair, einen Mini-PC-Hersteller für Intels Silizium-Bug verantwortlich zu machen. Wofür ihn verantwortlich zu machen fair ist, sind Takt und Offenheit seiner Kommunikation mit den Kunden, die das Silizium über ihn bezahlt haben. Das Muster von Minisforum in der MS-01-Raptor-Lake-Geschichte war, den Fix auszuliefern, ohne das Problem zu benennen – ein Kommunikationsstil, der für ein Kundensegment funktioniert, das täglich Enthusiastenforen liest, und an jedem anderen Kundensegment scheitert. Zwei Jahre nach dem Start dieser Chips gibt es MS-01-Besitzer, die bis heute nicht wissen, ob ihr BIOS die Raptor-Lake-Milderungen enthält, weil die Dokumentation, die sie zur Verifikation bräuchten, nie geschrieben wurde. Diese Stille ist kein Silizium-Bug. Sie war die Entscheidung des Herstellers, der ihnen das Silizium verkauft hat.