Microcode 0x12F: Intel arbeitet weiter an der Stabilität der Core-Prozessoren

[Nozomu]

Was die Spannung angeht zeigt es hier auch die 1.9 an.

 

[Erklärbär]

Ja, Auslesefehler. Hatte ich schon vermutet aber gut, dass du es auch mal geprüft hast.
Intel soll das bloss nicht als "Vorlage" für irgendwas verwenden.

 

[Nozomu]

Ich glaube bei 1.9V wäre die CPU schon längst durch

 

[Erklärbär]

Würde aber eine berechtigte RMA durchaus wohlwollend beschleunigen.

ps:
Werde aber jetzt erst einmal im ersten Schritt die E-Cores komplett deaktivieren und schauen, wie das System die nächsten Tage only P-Cores läuft.
Bringt das nichts, schalte ich das Board auf Bios Baustein-B und flashe dort ein Bios mit max. MC 0x125/0x129 und teste dann weiter.
Wenn das auch dann nicht bugfree läuft dann darf Intel bzw. Amazon gerne seinen Elektroschrott zurück nehmen, werde das alles dokumentieren und es kommt eine Alderlake CPU auf's Board.


Nachtrag: So, E-Cores komplett abgeschaltet, gleiches Szenario wie in Post #150 via Handbrake gestartet. Nach 03:25 (Zeit laut HWInfo) war Handbrake schon bei 10,39%, vorher wo die Last only nur auf den E-Cores liegen wollte nach 07:11 in Handbrake bei 11,02%. Während Hb läuft kann man nun auch sauber und flüssig weitere Anwendungen öffnen und ausführen, keinerlei Verzögerungen oder sogar Freezes. Irgend etwas stimmt da mit den Kernezuweisungen/E-Cores oder vieleicht sogar Intel ThreadDirector nicht. Nur die CPU jetzt only auf P-Cores laufen zu lassen dürfte alles andere als eine optimale Lösung sein. Ob es noch spontane Systemfreezes Idle/Last geben wird, dass werde ich jetzt ein paar Tage beobachten.

 

[Holt]

Ich kann also nur noch die CPU als Fehlerquelle eingrenzen, zumal bei Tools wie z.b. Handbrake kurioserweise nur noch die E-Cores angesprochen werden.
Egal ob Intel Profil oder MSI Profil, die Last bei Energieplan Höchstleistung und Kodierung 4K (2160p60 4K HEVC Upscaling), sollte primär eher auf den P-Cores liegen.
Die schlafen aber und während Hb läuft reagieren alle anderen Anwendungen vom Datei Explorer über Firefox usw. extrem träge oder frieren komplett ein.

Das hat aber nichts mit der CPU zu tun, sondern mit dem Windows Task Scheduler, denn der bestimmt auf welchem Kern welcher Software Thread läuft. Das Problem der Raptor Lake CPUs sind Instabilitäten wegen einer durch Alterung erhöhten Vmin, dies hat nichts mit dem zu tun was du hier beschreibst.

Irgend etwas stimmt da mit den Kernezuweisungen/E-Cores oder vieleicht sogar Intel ThreadDirector nicht.

So ist es, dies würde sich dann aber mit einer neuen CPU nicht ändern. Wenn nur die e-Kerne genutzt werden, würde ich mal im Taskmanager die Priorität der Prozesse anschauen, denn es ist von Windows so vorgesehen, dass alles Prozesse deren Priorität unterhalb Normal ist, dann nur auf den e-Kernen laufen sollen. Dies wäre als ein normales Verhalten, wenn Handbrake die Priorität entsprechend setzt.

 

[Erklärbär]

Na, dann erkläre mir mal bitte warum Handbrake bis ca. April bei mir noch einwandfrei lief und auch die Threads nicht nur only @ E-Cores zugewiesen wurden.

denn es ist von Windows so vorgesehen, dass alles Prozesse deren Priorität unterhalb Normal ist, dann nur auf den e-Kernen laufen sollen.

..würdest du Handbrake selber nutzen, dann solltest du wissen, dass in Hb die Settings @ default bei Arbeitslastpriorität auf "Normal" gestellt sind, bei mir ist das Setting sogar "über Normal", was bis siehe zuvor auch noch nie Probleme bereitet hatte. Handbrake läuft ja ansich auch, nur dass ebend die Last kurioserweise only auf die E-Cores ausgelagert wird, bereitet Probleme wenn weitere Anwendungen gestartet werden.
Ich werde das aber gerne noch einmal @ allcore anhand des TM prüfen, natürlich @ Intel-Default Settings und Dimm ohne XMP Modus.

Probleme mit den neueren MC Updates hatte ich schon seit 0x12C und Anfang Mai, siehe z.b. hier und hier. Von der Beta v1L mit MC 0x12F lasse ich erst einmal die Finger, dass ist mir alles nicht ganz koscha.

Nach knapp 10 Stunden, wo die CPU nun im only P-Core Modus läuft, kann ich nun nach vier Handbrake Encodings und mehreren Rechner Neustarts berichten -> bisher keinerlei Freezes und plötzliche Neustarts.
Nur das ist halt keine Lösung auf Dauer eine 14-Kerne CPU kastriert auf 6-Kerne laufen zu lassen damit es bugfree läuft. Das werde ich auch den Intel Support so mitteilen wenn die sich ab Montag melden.

 

[Holt]

dann erkläre mir mal bitte warum Handbrake bis ca. April bei mir noch einwandfrei lief und auch die Threads nicht nur only @ E-Cores zugewiesen wurden.

Zwar habe ich keine Ahnung woran es liegt, aber ich bin mir zu 100% sicher, dass es nichts mit einer ggf. vorzeitigen Alterung der CPU zu tun hat, da diese "nur" zu Instabilität des Systems führt, nicht aber zu einer Änderung des Verhaltens des Task Schedulers von Windows. Eine saubere Neuinstallation von Windows mit den entsprechenden Treiber, aber ohne die unsinnigen Tuningtools wie das Intel Extreme Tuning Utility oder was der Boardhersteller da so anbietet, wäre hier mal die erste Maßnahme die ich empfehlen würde. Man sollte die Einstellungen im BIOS machen, gerade auf für das RAM und dann hat auch ein RAM Test mit Memtest86 oder Memtest86+ (immer erstmal mit allem Riegel zusammen) eine Aussagekraft, denn ob die Riegel zusammen fehlerfrei laufen, ist immer auch eine Frage der ganzen Einstellungen, vor allem aber nicht nur der RAM Einstellungen und wenn diese von den Tools unter Windows verändert werden, kann man das RAM mit Memtest86(+) halt nicht so testen wie es dann unter Windows läuft.

Nur wenn es beim Test mit allen Riegeln zusammen Probleme gibt, testet man die Riegel einzeln oder eben alle zusammen mit weniger scharfen Einstellungen, bis alle zusammen wenigstens 3 Pass fehlerfrei schaffen.

..würdest du Handbrake selber nutzen

Aber ich nutze es nicht, sondern habe nur den Hinweis gegeben, wie Windows Task Scheduler sich verhält.

in Hb die Settings @ default

Außer dir kann keiner hier wissen welche Settings verwendet werden, es hätte also auch nichts genutzt, wenn ich Hb selbst nutzen würde.

bisher keinerlei Freezes und plötzliche Neustarts.

Freezes können auch durch übertriebene RAM Frequenzen kommen, denn seit DDR4 wird jede Übertragung von und zum RAM mit einer CRC verstehen und als fehlerhaft erkannte Übertragungen müssen wiederholt werden, bis sie fehlerfrei funktioniert haben. Ich könnte mir vorstellen, dass es zu plötzlichen Neustarts kommen könnte, wenn dies zu lange dauern sollte, bin da aber nicht sicher. Ansonsten könnte plötzliche Neustarts auch ein Problem des Netzteils sein oder gar des Mainboards, wenn der Rechner dabei richtig runterfährt. Das habe ich mal mit einem der Rechner im Büro erlebt, der fing plötzlich an immer mal von selbst angegangen oder runterzufahren, erst hatte ich den Einschalter am Gehäuse in Verdacht und den mal abgezogen, aber es war das Mainboard selbst, welches meinte jemand hätte auf den Einschalter gedrückt. Das war damals ein HP PC mit einer Sandy Bridge CPU.

 

[Erklärbär]

aber ohne die unsinnigen Tuningtools wie das Intel Extreme Tuning Utility oder was der Boardhersteller da so anbietet, wäre hier mal die erste Maßnahme die ich empfehlen würde.

Mit den Intel XTU kann man zwar onfly temporär (sind nach Neustart verloren) Prozessorsettings ändern, bei mir dient das Tool aber eher zum auslesen, nicht für OC.

Man sollte die Einstellungen im BIOS machen, gerade auf für das RAM und dann hat auch ein RAM Test mit Memtest86 oder Memtest86+ (immer erstmal mit allem Riegel zusammen) eine Aussagekraft, denn ob die Riegel zusammen fehlerfrei laufen, ist immer auch eine Frage der ganzen Einstellungen, vor allem aber nicht nur der RAM Einstellungen und wenn diese von den Tools unter Windows verändert werden, kann man das RAM mit Memtest86(+) halt nicht so testen wie es dann unter Windows läuft.

Siehe Post #150 schon mehrfach geschehen und absolut ohne Fehler, sowohl einzeln als auch im Paar und natürlich unter DOS.
Ich wüßte jetzt auch nicht, welche Tools in meiner Konfig. unter Windows den Dimm Takt ändern könnten/sollten. Zumindest laut AIDA und HWInfo läuft der so wie im UEFI -ohne XMP- gesetzt.

Außer dir kann keiner hier wissen welche Settings verwendet werden, es hätte also auch nichts genutzt, wenn ich Hb selbst nutzen würde.

Das war auch nur der Hinweis, wie Hb die Arbeitslastpriorität @ default gesetzt hat und demzufolge, deiner Annahme aus Post #155 nach, ja die Arbeitslast auf alle Kerne bzw. ebend nicht nur strikt auf die E-Cores ausgelagert werden müsste. So wie ich das normalerweise auch bisher kannte aber ebend in letzter Zeit nicht mehr ist.

Ich werde mal ein älteres Bios bis MC 0x129 oder 0x125 auf den zweiten Bioschip flashen und darüber starten. Natürlich wie jetzt, mit Intel-Default Profil und XMP aus (Dimms 5600MHz).

 

[Holt]

und natürlich unter DOS.

DOS? Welches Tool hast du genau genommen?

und demzufolge, deiner Annahme aus Post #155 nach, ja die Arbeitslast auf alle Kerne bzw. ebend nicht nur strikt auf die E-Cores ausgelagert werden müsste.

Das war keine Annahme, sondern ein Hinweis wie Windows das handhabt und die Priorität kann man sich im Task Manager anzeigen lassen und sollte dies auch machen, wenn man sonst keinen Grund findet, warum bestimmte Prozesse nur auf den e-Kernen laufen, die dies nicht tun sollten.

 

[Erklärbär]

DOS? Welches Tool hast du genau genommen?

Das übliche, Memtest86(+) in der Freeware Version. Ob die Benutzeroberfläche nun Dos, Linux oder sonstwie basiert ist das dürfte doch wohl absolut unerheblich sein.
Es findet außerhalb der Windows Oberfläche statt und das zählt (man kann es auch übertreiben mit der Erbsenzählerei). Alle Tests @ 4 Passes, nur Test "Hammer" optional deaktiviert.
Jeweils 5800MHz (XMP aus) und 6400MHz (XMP an), solo und paarweise - in summe also 4 komplette Memtestsessions und die waren alle fehlerfrei (über Tage verteilt, hat auch lang genug gedauert).

Das war keine Annahme, sondern ein Hinweis wie Windows das handhabt und die Priorität kann man sich im Task Manager anzeigen lassen und sollte dies auch machen, wenn man sonst keinen Grund findet, warum bestimmte Prozesse nur auf den e-Kernen laufen, die dies nicht tun sollten.

Warum sollte der TM etwas anderes auslesen als HWInfo und XTU zusammen? Das musst du mir mal erklären.

Das OS jedenfalls scheint keine gravierende Fehler aufzuweisen, gerade noch einmal geprüft (zum xten Mal), letzte derzeit verfügbare Build .5413 für Win11 23H2:


Werde heute nachmittag mal den Gegencheck über den 2ten Biosbaustein anhand älteren Biosupdate via USB-Flash prüfen, da dort wohl noch das firstrelease Bios drauf sein dürfte, welches Raptor noch nicht supportet.
Zumindest dürfte dieser Baustein dann noch nicht von eventuell "Resten" (meine Annahme) neuerer MC/ME Updates in den entscheidenen Areas versifft sein und werde dort erst einmal maximal das v1H Bios mit MC 0x125 vom 05.08.24 mit derzeit aktueller ME Firmware aufspielen. Vieleicht bringt das Langzeit (werde das dann mal beobachten) etwas, schauen wir mal. Zumindest ist das ein Versuch wert.

ps: Heute morgen gegen 02:30 hatte ich übrigens wieder die E-Cores testweise aktiviert und keine 2min. nach hochfahren hat das komplette System, diesesmal beim surfen via FF, plötzlich wieder gefreezt.
Neustart ging -wie gehabt- nur über Reset (Gehäuse), im Ereignisprotokoll (siehe Screen) keine kritischen Warnungen. Irgend etwas stimmt da mit den E-Cores oder der CPU gesamt nicht. Vieleicht ist auch der MC daran Schuld, wer weiß das schon. Was Intel da öffentlich kommuniziert ist auch mehr als dürftig und das wirst du auch nicht mit Sicherheit beantworten können, ob da nicht doch der MC irgendwo quer funken könnte.

 

[Dark_angel]

Sind bei dir WHEA Fehler im HWI zu erkennen? Ganz unten beim HWI.

Kannst ja man HWI zusammen mit Handbrake laufen lassen.

 

[Erklärbär]

Guter Tipp! Müsste ich testen, danke für die Info.

Werde aber erst den Weg über den zweiten Bios Baustein mit älteren MC gehen und dann gerne mal P+E Core via Hb probieren.
Momentan sind nur die P-Cores aktiv, seither keinerlei Probleme. Ist aber alles keine Lösung auf Dauer.

 

[Holt]

man kann es auch übertreiben mit der Erbsenzählerei

Computer sind aber nun mal eben Erbsenzähler, die lassen nicht mal eben 5 gerade sein, sondern arbeiten eben 100% exakt (und wehe wenn nicht). Jemand mit deiner Einstellung wird am Computer immer Probleme haben.

Jeweils 5800MHz (XMP aus) und 6400MHz (XMP an), solo und paarweise - in summe also 4 komplette Memtestsessions und die waren alle fehlerfrei (über Tage verteilt, hat auch lang genug gedauert).

Wieso testet man denn die Riegel einzeln, wenn sie zusammen fehlerfrei laufen? Dies macht keinen Sinn, man testet sie nur einzeln, wenn sie zusammen nicht fehlerfrei laufen um zu sehen, ob es die Einstellungen sind oder ob ein Riegel selbst einen Fehler hat.

Wichtiger wäre, wie lange dies her ist. Mein 13900K lief zuerst mit 64GB (2x32GB @5600), dann habe ich mir noch ein identisches Kit von Kingston gekauft und er lief (natürlich erstmal ausführlich mit Memtest86 getestet) dann 128GB (dann nur noch @4000 bis er anfing Probleme zu machen. Er ging zwei oder dreimal spontan einfach aus und ließ er sich nicht mehr einschalten, was dann am Ende aber am über 10 Jahre alten Netzteil lag. Mit dem neuen Netzteil habe ich den RAM Test wiederholt und diesmal war er nicht mehr ohne RAM Fehler zum laufen zu bekommen, wenn alle 4 RAM Riegel drin waren, jeder Riegel einzeln ging fehlerfrei, jedes Kit lief fehlerfrei und auch jede Kombination aus 3 oder 4 Riegel lief ohne Fehler fehlerfrei durch und ich habe jeweils mindestens 3 Passes gemacht. Habe mir dann noch einen 265K System gekauft weil ich eben so viel RAM brauche und ein Kit läuft jetzt darin und ebenfalls fehlerfrei.

Warum sollte der TM etwas anderes auslesen als HWInfo und XTU zusammen?

Der Task Manager kann unter Details die Priorität der Prozesse anzeigen, was meines Wissens bei HWInfo64 nicht geht, zumindest habe ich es bei der Version die ich verwende, noch nie gesehen. Was XTU kann, weiß ich nicht, ich habe mir das Tool nie installiert und dies auch nicht vor. Aber das hatte ich doch geschrieben:

die Priorität kann man sich im Task Manager anzeigen lassen

Was ist daran so schwer zu verstehen? Aber wenn man sowas als Erbsenzählerei abtut, wird man nie eine vernünftige Fehleranalyse hinbekommen. Nur weil bei Handbrake in der Anleitung steht, dass die Thread bei einer bestimmten Einstellung mit der normalen Priorität laufen sollen, muss das nicht in jedem Fall für jede Version des Programms stimmen, es gibt in jeder Software immer wieder Bug und die sind weit häufiger als Hardwarefehler. Wie schon geschrieben, wenn nur die e-Kerne ausgelastet werden, dann ist dies das normale Verhalten des Windows Task Schedulers für Threads mit einer Priorität unterhalb von Normal und damit sollte es klar sein, dass man zuerst die Priorität prüft, bevor man ein anderes BIOS aufspielt oder eine RMA der CPU anstößt.

 

[Erklärbär]

Wieso testet man denn die Riegel einzeln, wenn sie zusammen fehlerfrei laufen? Dies macht keinen Sinn, man testet sie nur einzeln, wenn sie zusammen nicht fehlerfrei laufen um zu sehen, ob es die Einstellungen sind oder ob ein Riegel selbst einen Fehler hat.

Weil ich die zuerst einzeln mit getauschten Bänken getestet habe?
Macht ja ebendso wenig Sinn, diese zuerst im Kit zu testen wenn dann z.b. Fehler auftreten würden. Dann bist nämlich genauso schlau wie vorher und musst die Dimms sowieso einzeln testen um den fehlerhaften Dimm zweifelsfrei zu lokalisieren - im schlimmsten Fall sogar das komplette Kit.

Der Task Manager kann unter Details die Priorität der Prozesse anzeigen,

..und genau das ist Erbsenzählerei. Denn wenn komplette Threads/Kerne nicht angesprochen werden, dann wird der TM dort nicht als Tausendsassa diese Fehler lokalisieren/eliminieren.

Normal und damit sollte es klar sein, dass man zuerst die Priorität prüft, bevor man ein anderes BIOS aufspielt oder eine RMA der CPU anstößt.

Zeigt mir, dass du nicht den Zusammenhang MC Update und meiner Vermutung, dass da eventuell was mit den Bios was nicht stimmt, nicht verstanden hast.
Mein letzter Kenntnisstand ist, dass Mikrocode immer initial bei jeden Rechnerstart/Bootvorgang aus den jeweiligen Areas in den reversiblen MC (uCode) Speicher der CPU geladen wird.
Die ME Firmware, üblicherweise primär der UEFI Oberfläche vorgeschaltet, in den entsprechenden, boardseitigen Co-Controller.
Wenn du da andere Informationen hast die diesen Vorgang als nicht mehr zutreffend beschreiben, immer her damit.

Ich habe jetzt das Bios via DIP umgeschaltet und mit Bios v1C inkl. MC 0x119 geflasht. ME-FW. in aktueller Version über Windows nachgeflasht und werde jetzt sämtliche Testszenarien noch einmal ausführen.

Nachtrag:
Erstes Testergebnis auf die schnelle jetzt nur anhand Handbrake. Im UEFI wurde nur das Lüfterprofil angepasst und da Bios v1C aus 07/23 noch kein Intel-Default Setting bietet, wurde das "Boxed"-Profil gewählt.
Links: Zuletzt ausgeführtes Hb Testszenario mit Bios v1K (0x12C) auf Bioschip A / Rechts: Aktuelles Hb Testszenario mit Bios v1C (0x119) auf Bioschip B:


..wenn das so bleibt und sich auch im weiteren Verlauf die nächsten Tage/Wochen keine "Hänger" oder Neustarts mehr zeigen, dann bleibe ich bei den MC und aktualisiere halt nur noch die ME-Firmware.
Trotzdem will ich erstmal wissen was der Intel Support dazu meint. Wird sich ja die nächsten Tage zeigen und eine im Grunde dann doch nicht (teil)defekte CPU einsenden möchte ich auch nicht.

 

[Holt]

Macht ja ebendso wenig Sinn, diese zuerst im Kit zu testen wenn dann z.b. Fehler auftreten würden. Dann bist nämlich genauso schlau wie vorher und musst die Dimms sowieso einzeln testen um den fehlerhaften Dimm zweifelsfrei zu lokalisieren - im schlimmsten Fall sogar das komplette Kit.

Aber wenn kein Fehler auftritt, dann hat man einmal getestet und alles ist gut, wenn man gleich mit den ganzen RAM Riegeln und deren finalen Einstellungen getestet hat. Nach einigen Monaten sollte man den Test wiederholen, da Chips eben altern und sich dabei ihre Eigenschaften leicht ändern, so dass die Ergebnisse eines Tests heute, morgen nicht mehr relevant sein können. Außerdem ist meist nicht das ganze Kit defekt, es dürfte wahrscheinlicher sein, dass die Einstellungen zu optimistisch gewählt wurden.

..und genau das ist Erbsenzählerei.

Wies soll es Erbsenzählerei sein, zuerst zu schauen ob der Fehler nicht darin liegt, dass das Programm die Priorität unterhalb von Normal einstellt und der Task Scheduler daher genau das macht was vorgesehen ist?

Denn wenn komplette Threads/Kerne nicht angesprochen werden, dann wird der TM dort nicht als Tausendsassa diese Fehler lokalisieren/eliminieren.

Dann nimm ein anderes Tool welches die Prioritäten anzeigt, aber dies sollte der erste Punkt sein den man in so einem Fall prüft.

Rechts: Aktuelles Hb Testszenario mit Bios v1C (0x119)

Hast du auch mal geschaut ob mit dem MC eine Singlethreadlast wirklich nur auf den P-Kernen läuft? Dier Windows Task Scheduler bekommt ja letztlich von der CPU Hinweise welche Kerne P und welche e Kerne sind. Wenn dies mit dem BIOS nicht klappt, dann würde er zwar MT Lasten die alle Kerne auslasten wollen und eine Priorität unter Normal haben, auf alle Kerne verteilen, aber ebenso Singlethread Lasten die eigentlich nur auf den P-Kernen laufen sollten.

 

[Erklärbär]

Bin gerade rein gekommen, Antwort vom Support:



..wie ich es von Intel (NL) kenne, Garantie ist denen wichtiger als Ursachenanalyse.

ps: Von gestern letzten Post hier bis jetzt keinen einzigen Freeze oder spontanes herunterfahren mit MC 0x119 auf anderen Bioschip. Rechner ist seit morgens an und wurde genutzt (Frau hat gespielt).

---- edit ----

Wies soll es Erbsenzählerei sein, zuerst zu schauen ob der Fehler nicht darin liegt, dass das Programm die Priorität unterhalb von Normal einstellt und der Task Scheduler daher genau das macht was vorgesehen ist?

Weil ich dir ja eigentlich schon in Post #156 erklärt hatte, dass in Hb @ default die Arbeitspriorität auf "Normal" - nicht "unterhalb normal" oder "höher als normal" eingestellt ist.
Dies wird im TM so auch in den Prioritäten übernommen und bei anliegender Last auch von der HbWorker.exe:

Dann nimm ein anderes Tool welches die Prioritäten anzeigt, aber dies sollte der erste Punkt sein den man in so einem Fall prüft.

Könnte ich, den CoreDirector z.b., nur was versprichst du dir davon?

Wenn dies mit dem BIOS nicht klappt

Richtig! Dies hat ja nicht geklappt mit den vorherigen Bios/MC 0x12C auf voreingestellten Bioschip-A, siehe z.b. Screen Post #150 und linker Screen Post #164.
Klappt aber scheinbar nun mit Bios/MC 0x119 auf Bioschip-B, siehe rechter Screen Post #164.

dann würde er zwar MT Lasten die alle Kerne auslasten wollen und eine Priorität unter Normal haben, auf alle Kerne verteilen, aber ebenso Singlethread Lasten die eigentlich nur auf den P-Kernen laufen sollten.

Kann so mit den Sheduler auch nicht ganz stimmen, denn wenn ich z.b. in Hb in den Voreinstellungen den Defaultwert auf "unter Normal" ändere, habe ich im TM trotzdem Last auf allen Kernen:


..was abnimmt ist laut Graphen die Last auf den E-Cores, bei Einstellung/Priorität "niedrig" noch weniger auf den E-Cores. Das aber die Last komplett auf die E-Cores ausgelagert wird, dass trifft so nicht zu.
Zumindest trifft das nicht auf z.b. Hb zu, den Effekt hättest du nur, wenn du die Prioritäten "manuell" umlegst, nicht aber durch den Sheduler.

Mich wundert halt nur, dass nun scheinbar, nachdem ich ein älteres Bios mit älteren MC auf anderen Bioschip geflasht habe, wieder alles wunderbar zu funktionieren scheint.
Bin mir aber nicht ganz sicher, ob das jetzt wirklich nur an den Bios/MC gelegen hat oder ob das nun nur ein temporärer Effekt ist und mit den E-Cores wirklich was nicht stimmt. Daher wird das weiter beobachtet.
Von der Logik her würde das aber Sinn machen, da der jeweilige MC ja zusätzlich zur ME in der Firmware (Area 1-4) liegt und initial in den reversiblen MC der CPU ausgeführt wird.
Kann man auch ganz einfach testen, wenn halt das Board ein umschaltbares Bios mit zwei verschiedenen Bios/MC Versionen besitzt. Die CPU erhält das jeweils gültige MC welches laut Bios geflasht wurde.
Praktisch schaut das dann so aus, dass mit Bioschip-A die CPU bei Rechnerstart MC0x12C initial ausführt, bei umschalten auf Bioschip-B die CPU dann initial MC0x119 ausführt.
Von daher kann Intel bei einer CPU RMA eigentlich gar nicht praktisch nachverfolgen, welches "Profil" oder MC der User vor Ort mit der CPU betrieben hat.
Schlicht unmöglich und daher werden auch vorab Infos bezgl. des verwendeten Profils und Bios, nach Marke & Typ abgefragt.