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

[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.

 

[Holt]

Richtig! Dies hat ja nicht geklappt mit den vorherigen Bios/MC 0x12C

Aus der Antwort erkenne ich nur einmal mehr, dass du nichts von dem verstanden hast, was ich geschrieben habe und es daher total sinnlose Zeitverschwendung wäre, hier weiter zu machen. Die CPU wird ja nun über Garantie getauscht und danach ist hoffentlich alles gut und wenn nicht, ist es mir auch egal.

 

[Erklärbär]

Update: Intel hält das Fehlerbild für "schlüssig" und die Rückgabe findet über Amazon statt. Ähnlich wie schon RMA bei MSI, WD, Fanxiang und Fikwot Produkten, über Amazon gekauft.
Bei Amazon gibt es eh immer Geld zurück (Ersatz senden die aus internen Gründen nie) und vieleicht nutze ich auch die Gelegenheit um komplett auf LGA 1851 umzusteigen.



ps: Über 2ten Bioschip unt älteres Bios war auch nur für knapp 2 Tage alles gut, danach kamen dann wieder die Bugs mit den E-Cores.
Intel hatte darüber am 20.06. auch ein ausgiebiges Fehlerprotokoll erhalten und -siehe Screen- kann diese Bugs auch nachvollziehen (im Gegensatz zu bestimmten Usern diesen Forums).
Da von qualifizierter Seite des Herstellers nun quasi der defekt der CPU eingeräumt wird, alles gut, nun bin ich beruhigt.

 

[denni]

Also wenn die CPU zurück geht und du die Kohle zurück bekommst, dann würde ich wechseln. Eine bessere Möglichkeit wird es nicht mehr geben

 

[Erklärbär]

Da hast du recht aber bin da etwas zwiegespalten, weil wieder 600~700€ in ein neues ACE Board investieren (Z890) und das alte mit hohen Verlust verkaufen..
..sollte man sich überlegen ob das Sinn macht, wenn man mit der Kiste eh das gleiche macht wie vorher.

Zumindest hätte dann aber dieses MC Geplänkel mit der Vmin Problematik ein Ende. Außer es kommt irgendwann heraus, dass Intel mit den neuen Prozis wieder wo was versemmelt hat.

 

[denni]

Naja, ich denke schon das Intel bei den Ultra CPUs nicht mehr die selben Fehler eingebaut hat. Ansonsten hat man ständig diesen Fehler im Hinterkopf.

 

[Holt]

wieder 600~700€ in ein neues ACE Board investieren (Z890)

Wozu braucht man so ein teures Board? Gute Z890 Boards gibt es ab so 200€ und die massiven Spawas der teuren Boards braucht man nur, wenn man die CPU massiv Allcore Übertakten will, wo die Effizienz dann komplett in den Keller geht. Was fehlt denn bei z.B. einem MSI Pro Z890-P WIFI? Dies hat auch 4 M.2 Slots, dazu zwei PCIe 4.0 x4 Slots wo man mit billigen Adaptern noch zwei weitere M.2 NVMe SSDs betreiben kann, 5Gb/s und TB4. Wenn man den Rechner wirklich nutzen und nicht Übertaktungsrekord jagen will, reicht so ein Board dicke.

 

[LeVauTi]

vieleicht nutze ich auch die Gelegenheit um komplett auf LGA 1851 umzusteigen.

so nutzt man die macht des konsumenten. bescheidene konzepte und umsetzung belohnen mit noch mehr geld nachwerfen.

 

[Schrotti]

Ein ASRock Z890 PRO RS z.b. ab 179,90

ASRock Z890 Pro RS ab € 179,90 (2025) | Preisvergleich Geizhals Deutschland

✔ Preisvergleich für ASRock Z890 Pro RS ✔ Produktinfo ⇒ Formfaktor: ATX • Sockel: Intel 1851 (LGA1851) • Chipsatz: Intel Z890 • CPU-Kompatibilität: Core Ultra 20… ✔ Mainboards ✔ Testberichte ✔ Günstig kaufen

geizhals.de

Oder ein MSI PRO Z890-P Wifi für 181,90

MSI PRO Z890-P WIFI ab € 181,90 (2025) | Preisvergleich Geizhals Deutschland

✔ Preisvergleich für MSI PRO Z890-P WIFI ✔ Produktinfo ⇒ Formfaktor: ATX • Sockel: Intel 1851 (LGA1851) • Chipsatz: Intel Z890 • CPU-Kompatibilität: Core Ultra 20… ✔ Mainboards ✔ Testberichte ✔ Günstig kaufen

geizhals.de

Muss nicht immer ein 500 Euro Board sein. Mein ASUS Strix Z890-A Gaming WiFi hat knapp 400 gekostet.

ASUS ROG Strix Z890-A Gaming WIFI ab € 393,87 (2025) | Preisvergleich Geizhals Deutschland

✔ Preisvergleich für ASUS ROG Strix Z890-A Gaming WIFI ✔ Bewertungen ✔ Produktinfo ⇒ Formfaktor: ATX • Sockel: Intel 1851 (LGA1851) • Chipsatz: Intel Z890 • CPU-Kompatibilität: Core Ultra 20… ✔ Mainboards ✔ Testberichte ✔ Günstig kaufen

geizhals.de

 

[Beavis99]

oder knapp über 200€, gibt es z.B. das Steel Legend

ASRock Z890 Steel Legend WiFi ab € 219,95 (2025) | Preisvergleich Geizhals Deutschland

✔ Preisvergleich für ASRock Z890 Steel Legend WiFi ✔ Produktinfo ⇒ Formfaktor: ATX • Sockel: Intel 1851 (LGA1851) • Chipsatz: Intel Z890 • CPU-Kompatibilität: Core Ultra 20… ✔ Mainboards ✔ Testberichte ✔ Günstig kaufen

geizhals.de

Ich hab davon das Z790 und bin sehr zufrieden.

 

[zog88]

Hab von diesen das Z790 und bin sehr zufrieden damit.

MSI MAG Z890 Tomahawk WIFI ab € 234,90 (2025) | Preisvergleich Geizhals Österreich

✔ Preisvergleich für MSI MAG Z890 Tomahawk WIFI ✔ Bewertungen ✔ Produktinfo ⇒ Formfaktor: ATX • Sockel: Intel 1851 (LGA1851) • Chipsatz: Intel Z890 • CPU-Kompatibilität: Core Ultra 20… ✔ Mainboards ✔ Testberichte ✔ Günstig kaufen

geizhals.at

 

[Holt]

Eben, es gibt genau gute Z890 Boards um die 200€, wer meint wirklich ein Board für 500€ und mehr zu brauchen, sollte mal genau hinterfragen warum er dies meint und was er denn genau machen will. Für den Alltag braucht man das nicht, da reicht eines der günstigen Z890 Boards und dazu ein Ultra 7 265K und man hat für um die 500€ ein geile CPU und ein gut ausgestattetes Z890 Board mit mindestens 4 M.2 Slot (PCIe 4.0 x4 oder besser) und TB4. Da ist dann auch der Wertverlust des Mainboards beim Verkauf nachher längst nicht so hoch wie bei teuren Boards.

 

[Erklärbär]

Hab von diesen das Z790 und bin sehr zufrieden damit.

MSI MAG Z890 Tomahawk WIFI ab € 234,90 (2025) | Preisvergleich Geizhals Österreich

✔ Preisvergleich für MSI MAG Z890 Tomahawk WIFI ✔ Bewertungen ✔ Produktinfo ⇒ Formfaktor: ATX • Sockel: Intel 1851 (LGA1851) • Chipsatz: Intel Z890 • CPU-Kompatibilität: Core Ultra 20… ✔ Mainboards ✔ Testberichte ✔ Günstig kaufen

geizhals.at

Ist auch ein schönes Board, da kann ich dann ggf. zwei Gen4 SSD via Graugear Adapter @ PCIe sockeln. Ergibt in Summe dann auch sechs. Weil die brauche ich und nutze die auch im 2ten Rechner.
Da du das ja selbst nutzt: Wird da bei gesockelt/belegt M.2_1 bis M.2_4 plus PCI_E2/E3 mit SSD belegt irgend etwas geshared? Sollte im UEFI ersichtlich sein.
Ob da irgend etwas Gen5 supported wird ist für mich belanglos. Sowohl Graka_seitig als auch vom Storage her ist bei Gen4 ende.

ps: Sorry überlesen, du hast ja das Vorgänger Z790 Board davon.

 

[Holt]

Da du das ja selbst nutzt: Wird da bei gesockelt/belegt M.2_1 bis M.2_4 plus PCI_E2/E3 mit SSD belegt irgend etwas geshared

Um das zu erfahren, reicht doch ein Blick ins Handbuch, aber wieso sollte da was geshared sein? Die Z890 CPUs bieten 24 nutzbare PCIe Lanes, 16 PCIe 5.0 für die Graka, 4 PCIe 5.0 für einen M.2 Slot und 4 PCIe 4.0 für einen zweiten M.2 Slot. Der Z890 bietet noch mal bis zu 24 PCIe Lanes, wobei die meisten Boards 4 davon gegen SATA Ports tauschen und mit den verbleibenden 20 dann PCIe oder M.2 Slots mit PCIe 4.0 x4 realisieren. Die Frage ist dann wie sich das zwischen M.2 und PCIe Slots aufteilt und beim MSI MAG Z890 Tomahawk sind es halt zwei M.2 Slots und 2 PCIe Slots, beim Ace sind es drei M.2 Slots und ein PCIe Slot. Die restlichen 4 Lanes sind für Onboard Komponenten wie den NIC (da hat das Ace 10GbE, statt 5GbE beim Tomahawk) und beim Ace kann man die 16 PCIe 5.0 Lanes auf zwei Slots aufteilen, was die Boards der 200€ Klasse nicht bieten. Für weitere Detail einfach die Handbücher der Mainboards lesen, dies sollte man immer machen, bevor man sich eines kauft, da dort solche Dinge wie eben was geshared ist, drin stehen. Generell wird aber bei den Z890 Boards kaum was geshared, schon gar nicht bei den billigen, die Plattform bietet ja genug PCIe Lanes.

 

[Normal_User]

So Leute jetzt voll auf Risiko die Bios Version 3001 (0x12F) übers UEFI-Bios EZ-flash upgedated. Ergebnis: der SP Wert ist von 81 auf 82 hoch gehüpft. CPU Benchmark-Punkte gleich wie beim1303er Bios (Hab keine FPS/Einbußen hinnehmen müssen) CPU/Mainboard Temperaturen auch da keine Veränderung (alles gleich wie mit Bios 1303)
Alles Rock-Stabil mit Bios 3001 vom 2025/05/19 ..kein BSOD seit ich des Kisterl hab (Sept.2023) Rog Strix Z790-E Gaming WiFi (Version 1) I7-13700KF / DDR5-6000
Softwaremäßig alles funktioniert, Steam Spiele auch da alles stabil...
BIOS: latest bios for strix z790-e gaming wifi

Keine Whea-Fehler! auch S4/S5 arbeitet einwandfrei, NULL Probleme mit dem neuen Bios
BIOS 3001 zeigt exact das gleiche Verhalten 1zu1 wie beim Vorgänger-Bios 1303 vom Sep/2023 (hab div. Testergebnisse in der Schublade
ausgedruckt vorliegen, kann so gut vergleichen von Vor/Nachher)

 

[denni]

Gut das bei dem Risiko alles glatt gelaufen ist

 

[zog88]

No Risk No Fun.
Für mein MSI Z790 Tomahawk ist das BIOS leider noch immer ein Beta, da will ich tatsächlich den vollen Release abwarten.

 

[ET4000]

hab div. Testergebnisse in der Schublade
ausgedruckt vorliegen

🚑