Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Nach langer Zeit gibt es wieder ein aktuelleres IMEI Firmware Update für B660/760-Z690/Z790.
Versionsnummer ist jetzt 16.1.40.2765 und löst damit die bisherige 16.1.38.2676 ab:
..eine Log gibt es leider (noch) nicht dazu.
_
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Schön. Feilt Intel noch an der Haltbarkeit der CPUs oder was hat sich geändert?
Für das Z690 Tomahawk D4 und Pro-A Z690 D4 gibt es das Update noch nicht. Muss aber auch nicht der erste sein, der das testet.
Ich habe nach diesen MC Update auch mal gestern gegoogelt, weil dass ist mir auch unbekannt und meines Wissens nach ist das letzte offizielle MC 0x132 (was aber gar nicht von MSI zu meinen Board verteilt wurde).
Im Intel Forum habe ich auch nichts gefunden und laut User THE|1|BOSS von Reddit, soll es sich hier wohl um ein inoffizielles MC handeln, dass auch noch einmal ein "Vmin Shift Instabilty"-Update beinhaltet.
Aber genaueres kann da wohl nur der MSI HQ zu schreiben. Sicherheitsfixes werden normalerweise über IMEI FW. (primär, da vorgeschaltet) oder halt MS WU (sekundär) ausgerollt.
ps: Laut Errata Details aus den Intel Spezifikationsupdates (PDF) müsste das in der Revision History No#027 -> Revisionsdate: "January 2026" betreffen.
Da ist RPL075 (Bestimmte VMCS-Felder können während der STM-zu-VMX-Übergänge fehlerhaft sein) und RPL076 (Leistungsüberwachungsereignisse CORE_POWER.LICENSE_[0-7] können falsche Werte melden) bereinigt worden. Ich weiß nur nicht, ob das nun MC 0x132 oder ein anderes MC Update betrifft. MC 0x12F kann es schon aufgrund des früheren Releasedatums nicht sein.
Nachtrag: Ich habe mal die KI befragt und da wurde mir folgendes (wie auch sonst im Internetz) zu generiert:
0x133 ist ein inoffizielles Update für bestimmte mobile Intel-Prozessoren der 13./14. Generation der Raptor Lake HX-Serie. Es erschien nach den offiziellen Updates 0x132 und 0x12B. Hauptsächlich wird dieser MC in Enthusiastenforen (wie TechPowerUp) diskutiert, um die Stabilität von Raptor Lake HX-Laptop-CPUs weiter zu verbessern. Diese weisen dieselbe CPU-ID (B0671h) und dieselben Stabilitätsprobleme (Vmin-Verschiebung) wie ihre Desktop-Pendanten auf.
Wichtige Aspekte des Mikrocodes 0x133 und der Raptor Lake-Stabilität:
Status: Es handelt sich um einen inoffiziellen Patch. Das bedeutet, er wird nicht direkt von Intel veröffentlicht und ist üblicherweise auch nicht in offiziellen OEM-BIOS-Updates enthalten. Vielmehr basiert er auf Community-Projekten zur Behebung bestehender Probleme, insbesondere bei mobilen HX-Prozessoren.
Kontext: Dieser Patch taucht in Diskussionen über die anhaltenden Stabilitätsprobleme im Zusammenhang mit der „Vmin-Verschiebung“ (auch bekannt als „Raptor-Lake-Degradationsproblem“) auf, bei denen Chips mit hohen Spannungsanforderungen konfrontiert sind.
Zweck:Während 0x12B und 0x12F offizielle Patches waren, die die Ursache der hohen Spannungsanforderungen beheben sollten, wird 0x133 von Nutzern getestet, die eine bessere Stabilität oder Kontrolle über die Spannungen erreichen möchten, oft in Verbindung mit speziellen Tools wie ThrottleStop.
Risiken: Die Verwendung inoffizieller Mikrocode-Updates birgt Risiken. Es wird stets empfohlen, das neueste BIOS/den neuesten Mikrocode direkt vom Hersteller Ihres Laptops oder Mainboards (ASUS, MSI, HP usw.) zu verwenden. Empfohlene Vorgehensweise: Stellen Sie sicher, dass Ihr System über das offizielle BIOS-Update mit den Sicherheitsupdates 0x12B oder 0x12F verfügt, da es sich hierbei um die von Intel zertifizierten Fehlerbehebungen zur Verhinderung weiterer Leistungseinbußen der CPU handelt.
Da es sich hierbei ja um einen inoffiziellen, scheinbar nicht von Intel zertifizierten MC Patch handelt, wäre es schon interessant zu wissen, warum MSI den nun in deren Biosupdates mit ausrollt.
Vieleicht kann da ja mal @MSIToWi nähere Informationen dazu beim HQ anfragen, warum dort nicht zertifizierte MC frei gegeben werden und welche Bereinigungen (RPL0xx) diese beinhalten sollen?
pps: Derzeit scheint auch nur das Z690 ACE aus der MEG Serie (weder Godlike noch Unify) und auch keines aus der MPG, MAG oder PRO Serie dieses Update erhalten zu haben. Versehen oder Absicht?
Ich habe nach diesen MC Update auch mal gestern gegoogelt, weil dass ist mir auch unbekannt und meines Wissens nach ist das letzte offizielle MC 0x132 (was aber gar nicht von MSI zu meinen Board verteilt wurde).
Im Intel Forum habe ich auch nichts gefunden und laut User THE|1|BOSS von Reddit, soll es sich hier wohl um ein inoffizielles MC handeln, dass auch noch einmal ein "Vmin Shift Instabilty"-Update beinhaltet.
Aber genaueres kann da wohl nur der MSI HQ zu schreiben. Sicherheitsfixes werden normalerweise über IMEI FW. (primär, da vorgeschaltet) oder halt MS WU (sekundär) ausgerollt.
ps: Laut Errata Details aus den Intel Spezifikationsupdates (PDF) müsste das in der Revision History No#027 -> Revisionsdate: "January 2026" betreffen.
Da ist RPL075 (Bestimmte VMCS-Felder können während der STM-zu-VMX-Übergänge fehlerhaft sein) und RPL076 (Leistungsüberwachungsereignisse CORE_POWER.LICENSE_[0-7] können falsche Werte melden) bereinigt worden. Ich weiß nur nicht, ob das nun MC 0x132 oder ein anderes MC Update betrifft. MC 0x12F kann es schon aufgrund des früheren Releasedatums nicht sein.
Nachtrag: Ich habe mal die KI befragt und da wurde mir folgendes (wie auch sonst im Internetz) zu generiert:
0x133 ist ein inoffizielles Update für bestimmte mobile Intel-Prozessoren der 13./14. Generation der Raptor Lake HX-Serie. Es erschien nach den offiziellen Updates 0x132 und 0x12B. Hauptsächlich wird dieser MC in Enthusiastenforen (wie TechPowerUp) diskutiert, um die Stabilität von Raptor Lake HX-Laptop-CPUs weiter zu verbessern. Diese weisen dieselbe CPU-ID (B0671h) und dieselben Stabilitätsprobleme (Vmin-Verschiebung) wie ihre Desktop-Pendanten auf.
Wichtige Aspekte des Mikrocodes 0x133 und der Raptor Lake-Stabilität:
Status: Es handelt sich um einen inoffiziellen Patch. Das bedeutet, er wird nicht direkt von Intel veröffentlicht und ist üblicherweise auch nicht in offiziellen OEM-BIOS-Updates enthalten. Vielmehr basiert er auf Community-Projekten zur Behebung bestehender Probleme, insbesondere bei mobilen HX-Prozessoren.
Kontext: Dieser Patch taucht in Diskussionen über die anhaltenden Stabilitätsprobleme im Zusammenhang mit der „Vmin-Verschiebung“ (auch bekannt als „Raptor-Lake-Degradationsproblem“) auf, bei denen Chips mit hohen Spannungsanforderungen konfrontiert sind.
Zweck:Während 0x12B und 0x12F offizielle Patches waren, die die Ursache der hohen Spannungsanforderungen beheben sollten, wird 0x133 von Nutzern getestet, die eine bessere Stabilität oder Kontrolle über die Spannungen erreichen möchten, oft in Verbindung mit speziellen Tools wie ThrottleStop.
Risiken: Die Verwendung inoffizieller Mikrocode-Updates birgt Risiken. Es wird stets empfohlen, das neueste BIOS/den neuesten Mikrocode direkt vom Hersteller Ihres Laptops oder Mainboards (ASUS, MSI, HP usw.) zu verwenden. Empfohlene Vorgehensweise: Stellen Sie sicher, dass Ihr System über das offizielle BIOS-Update mit den Sicherheitsupdates 0x12B oder 0x12F verfügt, da es sich hierbei um die von Intel zertifizierten Fehlerbehebungen zur Verhinderung weiterer Leistungseinbußen der CPU handelt.
Da es sich hierbei ja um einen inoffiziellen, scheinbar nicht von Intel zertifizierten MC Patch handelt, wäre es schon interessant zu wissen, warum MSI den nun in deren Biosupdates mit ausrollt.
Vieleicht kann da ja mal @MSIToWi nähere Informationen dazu beim HQ anfragen, warum dort nicht zertifizierte MC frei gegeben werden und welche Bereinigungen (RPL0xx) diese beinhalten sollen?
pps: Derzeit scheint auch nur das Z690 ACE aus der MEG Serie (weder Godlike noch Unify) und auch keines aus der MPG, MAG oder PRO Serie dieses Update erhalten zu haben. Versehen oder Absicht?
Ich habe da mal wegen dem Microcode 0x133 nachgefragt.
I have talked to BIOS team, and this 0x133 is simply a routine official security update from Intel.
All 600 & 700 MBs will eventually get this new CPU microcode, and other MB makers might implement it, too.
There is no note about what has been fixed/patched/changed with 0x133 microcode
Danke @MSIToWi aber werden CVE/CVSS nicht normalerweise via IMEI geupdatet?
Ich habe mich jetzt noch einmal im Intel Microcode Channel umgeschaut. Seitens Intel gibt es da wirklich null Infos zu diesen MC. Ich werde aber gerne noch einmal mit Dave (Intel Tech-Support) dazu Kontakt aufnehmen, gefunden habe ich selbst nur folgende Infos zu den letzten dokumentierten -wichtigen- Microcode Updates und habe das mal wie folgt zusammen gefasst:
MC 0x12B (Release 10/24):
behebt Spannungsspitzen im Leerlauf und verhindert, dass der Prozessor im Leerlauf oder bei geringer Last erhöhte Spannungen anfordert. Es enthält kumulative Korrekturen von MC 0x125 (eTVB-Algorithmuskorrekturen) und MC 0x129 (Spannungsanforderungen werden auf 1,55 V begrenzt).
MC 0x12F (Release 05/25):
behebt Stabilitätsprobleme, die auftreten können, wenn die CPU über mehrere Tage oder im Dauerbetrieb läuft (Always-on-Systeme). Diese Probleme können dazu führen, dass die minimale Spannung (Vmin) zu niedrig wird und die CPU abstürzt. Außerdem werden Zuverlässigkeitsprobleme im Zusammenhang mit dem Spannungsmanagement für wenig ausgelastete, schwach parallelisierte Anwendungen behoben, die in seltenen Fällen, die durch MC 0x12B verursacht wurden, weiterhin zu geringfügigen Instabilitäten führten.
MC 0x132 (Release 12/25~01/26):
behebt im allgemeinen das Einfrieren des Systems im laufenden Betrieb oder Systemabstürze, die auftreten können, wenn sich die CPU unter bestimmten Bedingungen im Turbo-Boost-Modus befindet und fehlerhafte Befehle empfangen werden. MC 0x132 enthält alle zuvor genannten Korrekturen. Es wird empfohlen, direkt auf dieses neueste Mikrocode-Update umzusteigen.
MC 0x133 bis MC 0x136 (Lenovo):
keine Informationen bezgl. Releasedates seitens Intel!
..wobei gerade dieses MC 0x132 meines Wissens nach ja nie von MSI in den Biosupdates als MC-Update released wurde. Nach MC 0x12F war da irgendwie Ende.
ps: Es dürfte aber zumindest nicht schaden, sich dennoch MC 0x133 aufzuspielen, denn der Logik zufolge - und da ja MC 0x132 von MSI nie ausgerollt wurde - könnte dieses ja auch Bugfixes aus Rev.-No. 022-027 (06/25-01/26) RPL068~076 enthalten. Und das sind schon einige, hier im Spoiler mal aufgelistet:
06/25 RPL068 xHCI-Controller hängt sich bei Datenpaketen der Länge Null auf:
Problem:
Der xHCI-Controller kann Datenpakete der Länge Null möglicherweise nicht verarbeiten, wenn folgende Geräte gleichzeitig an drei separaten Root-Ports angeschlossen sind:
• USB 3.2 Gen 2x1 (oder 2x2) Hub mit mindestens zwei USB 3.2 Bulk-Geräten.
• USB 3.2 Gen 2x1 (oder 2x2) Hub mit mindestens zwei USB 3.2 Bulk-Geräten.
• USB-Isochron-Gerät, das Datenpakete der Länge Null sendet.
Auswirkung:
Aufgrund dieses Fehlers kann sich der xHCI-Controller aufhängen. Intel hat dieses Verhalten bisher nur bei aktiviertem USB-Audio-Offload und USB 2.0-Audiogeräten beobachtet, die Datenpakete der Länge Null senden.
Lösung: Keine bekannt
----
09/25 RPL069 Interner Timeout-Fehler bei der Maschinenprüfung während Package C8 oder Package C10:
Problem:
Ein LLC-Flush (Last-Level-Cache) des Prozessors während des Eintritts in Package C8 oder C10 kann zu einem unvollständigen automatischen dynamischen LLC-Größen-Flush führen.
Auswirkung:
Aufgrund dieses Fehlers kann der Prozessor mit einem internen Timeout-Fehler bei der Maschinenprüfung (MSCOD=0080h, MCACOD=0400h) hängen bleiben.
Abhilfe: Möglicherweise enthält das BIOS eine Problemumgehung für diesen Fehler.
Problem:
Wenn Software die Befehle „Repeat Scan String Byte“ (REP SCASB) oder „Repeat Compare String Byte“ (REP CMPSB) auf einem Kern ausführt, kann ein anderer Kern oder Thread den Speicher, auf den zugegriffen wird, verändern.
Auswirkung:
Aufgrund dieses Fehlers können die SCASB- oder CMPSB-Befehle falsche Ergebnisse liefern.
Abhilfe: Möglicherweise enthält das BIOS eine Lösung für diesen Fehler.
----
11/25 RPL071 Aussetzer USB 3.2 Bulk-Übertragungen nach Geräteinitiierung der Flusssteuerung:
Problem:
Wenn ein USB 3.2-Gerät die Flusssteuerung initiiert und an das USB-Typ-C*-Subsystem angeschlossen ist, kann der xHCI-Controller USB 3.2 Bulk-Übertragungen vorübergehend anhalten, bis der nächste Mikroframe nach Beendigung der Flusssteuerung durch das Gerät ausgeführt wird.
Auswirkung:
Aufgrund dieses Fehlers können USB 3.2 Bulk-Übertragungen vorübergehend angehalten werden.
Abhilfe: Möglicherweise enthält das BIOS eine Problemumgehung für diesen Fehler.
Problem:
Wenn der CR3-Filtermechanismus von Intel® Processor Trace (Intel® PT) über das CR3Filter-Bit im IA32_RTIT_CTL MSR (MSR 570h, Bit 7) aktiviert ist, werden die Bits des CR3-Steuerregisters [63:52] nicht mit dem Wert im IA32_RTIT_CR3_MATCH MSR (MSR572h) verglichen.
Auswirkung:
Aufgrund dieses Fehlers kann Software, die auf das IA32_RTIT_CTL MSR (Bit 7) angewiesen ist, fehlerhaft funktionieren.
Abhilfe: Keine bekannt. Software kann diesen Fehler beheben, indem sie den Wert des CR3-Registers in das IA32_RTIT_CR3_MATCH MSR kopiert.
Status: Nicht behoben.
----
11/25 RPL073 Falscher Wert für „Letzter Sprung von“ im BTS-Sprungdatensatz bei einem Taskwechsel:
Problem:
Wenn die Sprungverfolgung mithilfe des Sprungverfolgungsspeichers (BTS) während eines Taskwechsels aktiviert ist, meldet der Prozessor im Sprungdatensatzfeld „Letzter Sprung von“ die lineare Adresse des Sprungziels anstelle der linearen Adresse der Anweisung, von der der Sprung ausgeführt wurde.
Auswirkung:
Aufgrund dieses Fehlers können Debugging-Tools, die auf BTS basieren, den Kontrollfluss falsch interpretieren.
Abhilfe: Keine bekannt. Software sollte die Verwendung von BTS zur Bestimmung der Genauigkeit der Sprungvorhersage vermeiden.
----
12/25 RPL074 Leistungsüberwachungsereignis MEMORY_ACTIVITY.STALLS_L2_MISS hat möglicherweise zu niedrigere Zählung:
Problem:
Das Leistungsüberwachungsereignis MEMORY_ACTIVITY.STALLS_L2_MISS (Ereignis 47h, UMASK 05h) kann bei Streaming-Teillasten zu niedrige Werte liefern.
Auswirkung:
Aufgrund dieses Fehlers können die Leistungsüberwachungszähler die Werte für dieses Ereignis unterschätzen, und die Top-Down-Mikroarchitekturanalyse (TMA) L2_Bound kann bei Streaming-Teillasten überschätzt werden.
Abhilfe: Keine bekannt.
----
01/26 RPL075 Fehlerhafte VMCS-Felder bei STM-zu-VMX-Übergängen:
Problem:
Wenn die Intel® Prozessor-Trace-Funktion (Intel® PT) durch Setzen des VM-Entry-Kontrollfelds „Load IA32_RTIT_CTL“ (Bit 18) aktiviert ist und während eines STM-zu-VMX-Übergangs (SMM-Transfermonitor, Root oder Nicht-Root) ein Ereignis ausgelöst wird, können die folgenden VMCS-Felder fehlerhaft sein:
• VM-Entry-Interrupt-Informationsfeld (4016h)
• VM-Entry-Ausnahmefehlercode (4018h)
• VM-Entry-Befehlslänge (401Ah)
Auswirkung:
Aufgrund dieses Fehlers kann der Prozessor in den HLT-Zustand wechseln oder einen falschen Wert im VMCS-IDT-Vektorisierungsinformationsfeld (4408h) melden.
Abhilfe: Eine Lösung für diesen Fehler besteht darin, dass die Software (VMM) die VMCS-Felder beim nächsten VM-Exit vor der Ausführung von vmresume überprüft.
Problem:
Die Leistungsüberwachungsereignisse CORE_POWER.LICENSE_[0-7] (Ereignis 28h) melden möglicherweise falsche Werte.
Auswirkung:
Software, die auf diesen Ereignissen basiert, funktioniert möglicherweise nicht wie erwartet.
Abhilfe: Keine bekannt.
pps: Welche RPL-Bugs, laut Intel Specification Update, bisher komplett gefixt wurden ist RPL070 und RPL071. Beide Fixes dürften aber alleine schon vom Bugfix Datum nicht in MC 0x12F bereinigt worden sein.
Der kritische RPL063 (Vmin Shift) steht noch auf Status "No Fix" bzw. "N/A" je nach Prozessor (Refresh S/S, E/E, P/H/H, HX, U/U).
