News Intel-Prozessoren: Hyper-Threading-Bug bei Skylake(-X) und Kaby Lake

Fragger911 schrieb:
Und wieviel Prozent der verkauften Rechner werden je ein BIOS-Update sehen?

Das stimmt. Allerdings dürfte so ein Fehler halt den allermeisten, normalen Anwendern/Consumern nicht allzu sehr weh tun. Ist zwar ärgerlich, wenn der PC in einem Spiel abschmieren würde, oder schlimmstenfalls ein paar Stunden Arbeit z.B. an einem privaten Video flöten geht, das man gerade bearbeitet. Aber das ist alles zu verschmerzen.

Kritisch ist er in professionellen/kommerziellen/wissenschaftlichen Anwendungen, wo besonders verfälschte Rechenergebnisse, die unbemerkt durchrutschen, richtig weh tun können. Und da wird dann sicher von den BIOS-Patches Gebrauch gemacht, um die Workstations/Server wieder zuverlässig zu machen.
 
Aldaric87 schrieb:
Diese Diskussion findet seit März statt, auch bei AMD direkt und dort sind sich fast alle sicher das es ein Software-Problem von Linux Distributionen ist. Einige haben auch dementsprechend schon Workarounds gepostet....so dramatisch scheint es ja nicht zu sein. :rolleyes:
Das Ryzen-Problem mit segfaults beim Kompilieren lässt sich auch im Windows-Subsystem für Linux reproduzieren. Es liegt also schonmal nicht am Linux-Kernel.

Die Workarounds senken lediglich die Wahrscheinlichkeit, dass das Problem auftritt, und haben unerwünschte Nebenwirkungen (SMT aus -> Leistung sinkt; Kernel-ASLR aus -> Sicherheit sinkt).
 
RayKrebs schrieb:
Das ist schon ärgerlich. Was ist mit den Herstellern, die für ihre Mainboards KEIN BIOS Update mehr bringen! Schon mal daran gedacht!

Auch Betriebssysteme bekommen diese Firmware Updates und spielen sie beim Booten ein.
Ergänzung ()

Fragger911 schrieb:
Und wieviel Prozent der verkauften Rechner werden je ein BIOS-Update sehen?

Sie brauchen schlicht keins, siehe oben. Sofern der PC noch bootet trotz Fehler, reicht es.
 
GrovyGanxta schrieb:
Ist mein i5 6600k auch betroffen?
Gibt es eine komplette liste betroffener cpu's? Würde gern cpus vergleichen von bekannten..

naja nur wenn dein 6600k Hyper Threading hat, gelle!? 0.o

betroffen sind alle Pentium g(nur kabys, skylake pentium g haben kein HT), xeons, i3, i7 bzw i9 modelle der sky & kaby lake generation

quasie alles von skylake an mit HT
 
Zuletzt bearbeitet:
chithanh schrieb:
Das Ryzen-Problem mit segfaults beim Kompilieren lässt sich auch im Windows-Subsystem für Linux reproduzieren. Es liegt also schonmal nicht am Linux-Kernel.

Die Workarounds senken lediglich die Wahrscheinlichkeit, dass das Problem auftritt, und haben unerwünschte Nebenwirkungen (SMT aus -> Leistung sinkt; Kernel-ASLR aus -> Sicherheit sinkt).

Soweit ich mitbekommen habe lässt sich der Bug halt nicht verlässlich reproduzieren , bei dem einen tritt er dort auf , bei dem anderen da und bei einem dritten gar nicht , mal hilft dies , mal hilft das , das ist alles andere als eine " verlässliche Reproduktion "

Bei Windows tritt ein solcher Bug nicht auf , hab zumindest nichts derartiges gehört .
Ich halte das ganze für eine Kombination aus Bios + DDR4 Ram + Software ( Compiler ) und verwendeter Takt und spannungswerte .

Wär s ein CPU Bug ließe er sich , unabhängig von der übrigen Hardware , immer nachweisen - selbst wenn er unregelmäßig auftreten würde
 
Intel und AMD haben jetzt jeweils einen Bug, von dem wir Ottonormalverbraucher zu 99,99999% nie was merken werden, also Ruhe bewahren . ;)
 
Einen? Hunderte, eher tausende. Das haben die CPUs schon immer. Schon seit Pentium FDIV Bug und bevor. Die Erratas für CPUs sind fast schon Regalmeter.

AMD hat mindestens zwei: das Abstürzen oben und ein VME Bug.
 
MK one schrieb:
Soweit ich mitbekommen habe lässt sich der Bug halt nicht verlässlich reproduzieren , bei dem einen tritt er dort auf , bei dem anderen da und bei einem dritten gar nicht , mal hilft dies , mal hilft das , das ist alles andere als eine " verlässliche Reproduktion "
Von verlässlicher Reproduktion habe ich auch nicht geschrieben.

MK one schrieb:
Bei Windows tritt ein solcher Bug nicht auf , hab zumindest nichts derartiges gehört .
Ich halte das ganze für eine Kombination aus Bios + DDR4 Ram + Software ( Compiler ) und verwendeter Takt und spannungswerte .

Wär s ein CPU Bug ließe er sich , unabhängig von der übrigen Hardware , immer nachweisen - selbst wenn er unregelmäßig auftreten würde
Nicht unbedingt. Wie ich schrieb, das Problem tritt auch unter Windows auf, nämlich im WSL.

Im Gentoo-Forum gibt es einen entsprechenden Bericht: https://forums.gentoo.org/viewtopic-p-8080052.html#8080052

Die Tatsache, dass das Problem nur mit bestimmten Befehlssequenzen bei eingeschaltetem SMT auftritt, spricht klar gegen RAM- oder Softwareprobleme. Compiler sind nämlich singlethread-Anwendungen, und das RAM schert sich auch nicht um SMT.
 
GrovyGanxta schrieb:
Ist mein i5 6600k auch betroffen?

kannst du lesen?

HYPERTHREADING-BUG

was hat ein i5 nicht....?

:D
 
Golem schreibt auch viel wenn der Tag lang ist:

Überschrift: UEFI-Updates für Windows und Mac einzige Lösung
Text: Für Skylake-Chips mit den Signaturen 0x406e3 und 0x506e3 wird der Fehler demnach in der Microcode-Version 0xb9/0xba oder neuer behoben ... Zwar erstellt Apple entsprechende EFI-Updates und stellt diese zum Download bereit, für die Macbook Pro ist dies aber noch nicht geschehen.

Sprich: die Überschrift ist für diesen Fall falsch, MS spielt Microcode-Updates ein. Genauso Apple (und natürlich auch Linux. Das weit nervigere ist: die Updates sind nicht permanent und nach einem Reboot wieder weg. Das ist der Vorteil eines BIOS Updates, dort sind die Updates dann quasi permanent und OS unabhängig.
 
Wenn der Fehler bisher quasi noch niemand bemerkt hat bzw erlebt hat ist es doch kein großes Problem - höchstens für eine gewisse irrationale Gruppierung, ein kleiner Fehler wo man überhaupt wissen muss wie man ihn reproduziert, wird mal wieder mehr darum geredet als die Sache Wert ist.
PS: Andere Seiten schreiben es deutlicher wo erwähnt wird, dass dieser Fehler nur in extrem seltenen Anwendungsfällen überhaupt auftreten kann.
 
Zuletzt bearbeitet:
Die Frage ist, wenn es zum Datenverlust kommt, wer schiebt das bitte auf die CPU? Also mein erster Gedanke wäre die CPU erstmal nicht. Daher weiß man gar nicht, wie oft der Fehler schon vorgekommen sein könnte.
 
gaelic schrieb:
Golem schreibt auch viel wenn der Tag lang ist:

Überschrift: UEFI-Updates für Windows und Mac einzige Lösung
Text: Für Skylake-Chips mit den Signaturen 0x406e3 und 0x506e3 wird der Fehler demnach in der Microcode-Version 0xb9/0xba oder neuer behoben ... Zwar erstellt Apple entsprechende EFI-Updates und stellt diese zum Download bereit, für die Macbook Pro ist dies aber noch nicht geschehen.

Sprich: die Überschrift ist für diesen Fall falsch, MS spielt Microcode-Updates ein. Genauso Apple (und natürlich auch Linux. Das weit nervigere ist: die Updates sind nicht permanent und nach einem Reboot wieder weg. Das ist der Vorteil eines BIOS Updates, dort sind die Updates dann quasi permanent und OS unabhängig.

Klar spielt Appel, Microsoft die Update ein. Wenn Intel das könnte, würde das ja bedeuten, das der CPU Kontakt nach Haus aufnimmt.
Ich habe das so verstanden. Intel hat das Problem gefunden und stellt Microcode-Updates zur Verfügung. Was die Hersteller dann machen, ist nicht mehr die Sache von Intel.
 
Mega-Bryte schrieb:
Jetzt weinen am Ende wieder genau die, die mit offenen Armen in den Laden gerannt sind und um Zuteilung eines "neuen besseren Systems" warben. Wann erkennen solche Menschen endlich, dass es nicht immer von Vorteil ist, neues Zeug zu kaufen?
Echt mal ... diese Idioten!
Was sind das nur für dumme Menschen, die sich ihr neues System mit aktueller Hardware zusammenstellen, statt 2 Jahre alte zu nehmen. Das geschieht diesen "IT-Süchtigen" ganz recht! :mad:

Sonst ist bei dir aber alles ok, ja?
 
Meine Güte, dafür gibt es Updates.

Jede CPU hat Fehler und die schweren werden eben mittels Biosupdate bereinigt.
 
chithanh schrieb:
Von verlässlicher Reproduktion habe ich auch nicht geschrieben.

Nicht unbedingt. Wie ich schrieb, das Problem tritt auch unter Windows auf, nämlich im WSL.

Im Gentoo-Forum gibt es einen entsprechenden Bericht: https://forums.gentoo.org/viewtopic-p-8080052.html#8080052

Die Tatsache, dass das Problem nur mit bestimmten Befehlssequenzen bei eingeschaltetem SMT auftritt, spricht klar gegen RAM- oder Softwareprobleme. Compiler sind nämlich singlethread-Anwendungen, und das RAM schert sich auch nicht um SMT.

was wiederum nicht Windows sondern Linux emuliert , simuliert oder wie auch immer es das macht , heißt ja nicht umsonst Windows Subsystem für Linux

Du sagst der Bug ließe sich reproduzieren , auch auf einem anderen Rechner ? oder wenn das nicht der Fall ist zumindest mit der gleichen CPU ?

so wie ich das mitgekriegt habe , ist das nicht der Fall ... sonst wäre es ja klar , oder
 
Dann betrifft das doch auch den G4560?
Wie bekomme ich den raus ob das`bei mir schon gefixt ist?
 
Zurück
Oben