News Intel deaktiviert TSX in „Haswell“-CPUs wegen Bug per Microcode

PS-ShootY schrieb:
Erinnert mich irgendwie an den Pentium-FDIV-Bug...
Der FDIV Bug war aber behebbar durch die Korrektur eines einfachen Tabellenwertes.

Diese Bugs bei TSX und Co. entstehen meist durch Timing Probleme wenn Interupts diese Operationen unterbrechen. Es gibt noch viele weitere Bugs in dieser Richtung, Intel veröffentlicht diese aber in seiner Developer Zone.

Bedenklicher finde ich die Fähigkeit solche Features mittlerweile per MicroCode deaktivieren zu können. Das heißt dass einige Teile der CPU programmierbar sind. Das wiederum gibt mir Bedenken bei den mittlerweile integrierten Funktionen bzgl. Verschlüsselung etc., bzw. Zufallsgeneratoren. Prost Mahlzeit!
 
Gibts eigentlich Geld dafür wenn man so einen Fehler entdeckt? Oder sagt Intel dann Danke und das wars. Ich mein in so einem Fall würde ich persönlich mein Wissen eher an den verkaufen der am meisten dafür zahlt.
 
Wie in der News schon geschrieben sind Ottonormalverbraucher davon überhaupt nicht betroffen. Ist speziell im Serverbereich und Datenbankenbetrieb interessant.
 
Zuletzt bearbeitet:
Krautmaster schrieb:
Entweder AMD hat das besser im Griff, oder aber, was ich mehr denke... es kommt einfach nicht so an die Öffentlichkeit wie jetzt bei Intel.

Was hat die News mit AMD zu tun ? Nichts oder. Ich wollte übrigens schon schreiben, mich erinnert die News an den TLB Bug der auch bei K10 bereinigt wurde. Hatte bei meinem Phenom 8600 trotzdem nur vllt 1-2 Blue Screens.
Aber da wurde weit aus mehr Wind gemacht ^^ Okay, für die Server CPUs war es ein scheiß :D
 
Zuletzt bearbeitet:
@DaZpoon

Das ist ja mittlerweile bekannt, das Intel teile der CPU von außerhalb programmieren kann. Man hatte ja bei Intel damals auch überlegt ob man mit einem Update über das Windows den Microcode 306C3/9 direkt in die CPU einspielen soll, damit man das MCE auf alle Core`s beim Xeon verhindert. Natürlich muß der User auch ein solches Update dann erstmal installieren, aber wie viele gibt es, die einfach jedes Update von Windows installieren und gar nicht nach schauen was genau hinter so einem Update steckt.

Das hat man allerdings dann bei Intel verworfen, da man sich ja mit den MB Herstellern dahin geeinigt hat, das Non OC Feature nicht mehr aktiv zu bewerben und anzubieten. Und alle neueren Boards werden ja nur noch mit dem Sperrcode ausgeliefert, auch wenn es trotzdem noch einige MB Hersteller gibt, die ein meist vertecktes Beta-Bios mit dem entsperr Microcode 306C3/7 anbieten, die das Non OC erlauben auch wenn es sich nicht um ein Z-Board handelt und man damit natürlich auch den MCE beim Xeon aktivieren kann.

Interessant war an dem ganzen eigentlich, das so etwas nicht nur durch ein Bios Update möglich ist, sondern halt auch über ein simples Windows Update mit dem man dann direkt auf die CPU zugreifen kann. Da will man sich gar nicht wirklich vorstellen, was sonst noch alles möglich ist, ich sage nur "NSA" lässt grüßen. ;)

mfg Zotac2012
 
CPU Microcode kann man nicht nur übers BIOS aufspielen sondern auch übers Betriebsystem seit X Jahren.
Da kann also auch MS notfalls die CPU kastrieren auf Wunsch von Intel!
 
sollte die unterstützung von TSX nicht einfach im bios/UEFI hinterlegt sein?

bei AMD wird soetwas jedenfalls im AGESA abgespeichert, da wird nichts in der CPU/APU selbst gespeichert.
Ergänzung ()

tobi14 schrieb:
sondern auch übers Betriebsystem seit X Jahren.
aber das wird dann bei jedem start neu geladen, da wird vom windows nichts dauerhaft gespeichert.
 
Was macht Intel da überhaupt? Ein Hardware Bug nach dem Anderen...
Die bewegen sich auf Niveau von Softwareentwicklern :o
 
Sorry da habe ich mich undeutlich ausgedrückt. Ich meinte natürlich dass ich es als bedrohlich sehe dass man solche Features auch außerhalb des BIOS im MicroCode ändern kann.

Aber das geht ja nicht nur in der CPU sondern auch im PCH. Im Prinzip ist damit jeder PC irgendwo anfällig für unaufspürbare Manipulationen.

Die bewegen sich auf Niveau von Softwareentwicklern
Sind sie es im Prinzip auch da ich mir die Entwicklung solcher Features mittlerweile ähnlich der FPGA Programmierung vorstelle. Hat natürlich irgendwo auch seine Vorteile falls eben mal ein Bug drin ist.
 
Das Feature klingt laut dem Golemartikel jedenfalls interessant. Für mich als Hobby- und Berufsprogrammierer wäre das schon von Nutzen, da praktisch jedes Programm insbesondere im Privatbereich mit mehreren Threads arbeitet. Allerdings sind die wenigsten davon performancekritisch, weshalb simple Locks reichen.
 
Warum sich über einen Fehler aufregen, der 99% der hier anwesenden User nicht betrifft...
Selbst das sperren der Funktion führt zu keinerlei "Verlust" beim normalen Nutzer!

Einzig professionelle Anwendungen bzw. Firmen haben evtl. Grund zur Sorge sofern ein unverbreitetes TSX überhaupt verwendet wird...
 
pipip schrieb:
Was hat die News mit AMD zu tun ? Nichts oder. Ich wollte übrigens schon schreiben, mich erinnert die News an den TLB Bug der auch bei K10 bereinigt wurde. Hatte bei meinem Phenom 8600 trotzdem nur vllt 1-2 Blue Screens.
Aber da wurde weit aus mehr Wind gemacht ^^ Okay, für die Server CPUs war es ein scheiß :D

Naja, ist auch Äpfel mit Birnen imo. Am TLB kommst du ja nicht vorbei (auch Intel nicht), TSX ist ein Zusatzfeature bzw. eine neue optionale Funktion die spezielle Anwendungen beschleunigen kann, welches bei der Hälfte der Desktop-Lösungen von vornherein nicht aktiviert war, weils keine Software gibt und dort deshalb bisher wenig relevant ist. Im Server-Bereich suxx der Fehler schon deutlich mehr, aber aufgrund der geringen Relevanz wird Haswell-EP weiter ausgeliefert und in knapp 4 Wochen gelaunched.
 
@Smagjus
Aber wenn du mit PThreads arbeitest bei einem "0815" Programm, wo brauchst du da einen Rollback?
 
Man sollte aus einer Mücke keinen Elefanten machen. Das gilt vor allem hier.
Dieses "Feature" scheint ziemlich exotisch zu sein. Man muss Intel nicht mögen, aber sollte dennoch die Problematik realistisch angehen.
AMD kann sich sowas prinzipiell nicht leisten, da sie dann gleich den Laden dicht machen können. :(
 
StefanBP schrieb:
Ein Fehler der erst 1,5 Jahre nach CPU Release (bei hunderten Millionen verkaufter Haswell Chips) auffällt, kann so schlimm nicht sein. Ich habe jedenfalls bis heute nichts von TSX gehört...
Das könnte vielleicht auch daran liegen, dass HLE und RTM bisher noch selten genutzt wird.
 
Moin, also ich hab mir die Errata mal angesehen und finde HSW134 bedenklicher:

An Intel® Hyper-Threading Technology-enabled Processor May Exhibit Unpredictable Behavior During Power or Thermal Management
Operations

When both logical processors in a core are idled due to power or thermal management operations such as thermal events or C-state entry, under certain circumstances, instruction fetches initiated before entering the idle state may not complete correctly,
resulting in unpredictable system behavior.
:eek:
 
@ZFS

Das Problem dürfte älter sein als du denkst. Wenn eine CPU in tiefere Schlafzustände geht nimmt sie einfach "undefinierte" Zustände an, kein Wunder, dass das Probleme macht, wenn die Pipeline noch mit irgendwas gefüllt ist. Das Problem dürfte in der Form seit Anfang an bestanden haben als die CPUs das Schlafen lernten :)
 
Betrifft das also nur die C states? Habe einen i7-4770k auf einem z87m oc formula und beim anschalten aus dem Kaltstart gibt es immer mal wieder Bootloops noch bevor das Display was anzeigt. Hatte bisher das Mobo in Verdacht?.

Schade jedoch finde ich, dass ganz offensichtlich der Support für eine noch Garantieberechtigte CPU eingestellt wird. Verschlechterungen per MicroCode werden zumindest Newsbeachtend eher durchgereicht als Fixes.
 
Zurück
Oben