AMDs neuester Prozessor-Revisionsleitfaden für die EPYC 7002 „Rome“-Serverchips enthüllt einen interessanten neuen Fehler (Errata), der dazu führen kann, dass ein Kern auf dem Chip nach 1.044 Tagen Betriebszeit (~2,93 Jahre) hängen bleibt Setzen Sie den Server zurück, damit der Chip ordnungsgemäß läuft. AMD sagt, dass es das Problem nicht beheben wird.
AMDs Beschreibung des Problems, das seine EPYC-Prozessoren der zweiten Generation betrifft (AMDs Genoa-Chips der vierten Generation sind die neuesten), ist prägnant, aber es gibt viel zu entpacken.
Das Problem ist darauf zurückzuführen, dass der Kern den CC6-Ruhezustand nicht verlässt. Laut AMD kann der Zeitpunkt des Fehlers jedoch je nach Spreizspektrum und REFCLK-Frequenz variieren. Letztere ist der Referenztakt, der dem Chip dabei hilft, die Zeit im Auge zu behalten.
Reddit-Benutzer acid_migrain hat eine plausible Theorie über den genauen Zeitpunkt des Kerns bleibt hängen und sagt: „Trotz allem, was sie sagen, manifestiert sich das Problem tatsächlich bei 1042 Tagen und ungefähr 12 Stunden. Der TSC tickt bei 2800 MHz und 2800 * 10**6 * 1042,5 Tage entsprechen fast 0x380000000000000, das zu viele Nullen hat, um kein Zufall zu sein.“
Die Problemumgehung ist einfach: Starten Sie entweder vor 1.044 Tagen Betriebszeit neu, wodurch die CPU zurückgesetzt wird, um Ihren 1.044-Tage-Timer neu zu starten, oder deaktivieren Sie den CC6-Ruhezustand.
Auch wenn dieser 2,93 Jahre alte Core-Absturzfehler interessant ist, stellt sich die Frage, ob er wirklich von Bedeutung ist. Sicher, es ist wichtig, auch wenn in vielen Bereichen Sicherheitsupdates und Wartungsarbeiten durchgeführt werden sollten. viel kürzere Intervalle.
Das realistischste Szenario wären einfach diejenigen, die die Linux-Live-Patching-Funktion oder kexec zum Aktualisieren ohne Neustart verwenden – das könnte sicherlich zu der Art von verlängerter Betriebszeit führen, die den Fehler auslösen würde. Außerdem verzeichnen Server für geschäftskritische Anwendungen häufig eine längere Betriebszeit.
Obwohl dieser Fehler interessant ist, stellt er für die Mehrheit der Benutzer kein Problem dar, und Fehler in den Chips sind definitiv nicht ungewöhnlich. Moderne CPUs sind die komplexesten Geräte, die von der Menschheit gebaut wurden, und sie kommen fast immer mit zahlreichen Fehlern/Bugs auf den Markt, die entweder während oder nach der endgültigen Auslieferungsrevision (Stepping) der Chips entdeckt werden. Hier erfahren Sie etwas mehr darüber.
Chip-Errata sind häufig, aber nicht großartig
Da Milliarden von Transistoren im Einsatz sind, sind Probleme unvermeidlich: Es ist nicht ungewöhnlich, dass ein Chip tausend oder mehr Errata/Bugs aufweist, die in neueren Schritten des Chips oder durch Firmware-Optimierungen vor der Markteinführung behoben werden. Diese Errata können alle Arten von Fehlern umfassen, von Sicherheitslücken bis hin zu fehlerhaften Flags und Cache-Tags, die nicht richtig funktionieren, und die Chiphersteller tun ihr Bestes, um sie vor der Veröffentlichung zu beseitigen.
Allerdings bleiben auch bei Versandchips immer einige Fehler bestehen. Bei Intels 8. Generation sind beispielsweise immer noch mehr als 150 Errata aufgelistet, und diese Chips wurden 2017 auf den Markt gebracht. Wir wissen nicht, wie viele Errata die Rome-Chips hatten, da AMD die Auflistungen für behobene Errata entfernt hat . Allerdings wissen wir, dass noch 39 Fehler vorliegen, was vor dem Hintergrund von Intel eigentlich gar nicht so schlimm erscheint.
Einige Erratas bleiben einfach deshalb unrepariert, weil sie keinen Schaden anrichten, aber abgesehen von kritischen Erratas, die einen Angriffsvektor offen lassen könnten, werden einige funktionsbezogene Erratas einfach nie gepatcht. Der Chiphersteller wägt Faktoren wie die Schwere der Errata, die Leichtigkeit der Behebung des Problems und die Tatsache ab, dass es überhaupt eine ausreichend große Anzahl von Errata gibt, die einen weiteren Schritt rechtfertigen – das ist kein triviales Unterfangen.
Warum hat AMD es nicht früher gefunden? Nun, 2,93 Jahre sind länger als die Validierungs- und Qualifizierungszyklen, und es ist nicht klar, ob sich beschleunigte Alterungstests durchsetzen könnten, bei denen die Ausrüstung häufig über längere Zeiträume bei höheren Temperaturen als üblich getestet wird, um den Alterungsprozess zu simulieren auch der Fehler. Die AMD EPYC Rome-Chips wurden Ende 2018 auf den Markt gebracht, sodass einige Kunden von AMD das Problem möglicherweise bereits auf die harte Tour kennengelernt haben – bei der Bereitstellung.
EPYC Rome wurde aus dem Uptime Club geworfen
Und dann gibt es noch die Leute, die einfach nur dem Uptime-Club beitreten und einen Rekord aufstellen wollen. Dazu müssen Sie den Bordcomputer besiegen Raumsonde Voyager 2. Ja, derjenige, der als Zweiter den interstellaren Raum betrat. Dieser Computer ist seit 16.735 Tagen (über 48 Jahre) in Betrieb, Tendenz steigend.
Für terrestrische Aufzeichnungen scheinen 6.014 Tage (16 Jahre) die richtige Zeit zu sein Datensatz für einen Server, aber ich habe viele Debatten über andere Anwärter auf die Krone gesehen. (Das kleine /r/uptimeporn/Reddit In der Community gibt es viele Beispiele für längere Betriebszeiten.)
In beiden Fällen werden Sie mit keinem der EPYC Rome-Chips einen solchen Rekord brechen können – diese Fehler werden nicht behoben, sodass unter keinen Umständen alle Ihre Kerne den Schwellenwert von 1.044 Tagen deutlich überschreiten werden. AMDs Hinweis besagt, dass das Problem dadurch nicht behoben wird – vielleicht hat das Unternehmen entschieden, dass das Problem zu kostspielig ist, um es auf Silizium zu beheben, oder ein Mikrocode-/Firmware-Fix hat zu viel Leistungsaufwand, oder vielleicht gibt es einfach nicht genug betroffene Kunden, um das Problem zu lösen reparieren lohnt sich.
In beiden Fällen hilft es, den CC6-Ruhezustand des Servers zu deaktivieren Du Schlafen Sie nachts oder führen Sie einfach alle 1.000 Tage einen Neustart durch.