Hayda Ministral schrieb:
Weil einen Fehler finden und ihn beheben zwei Paar Schuhe sind die nicht immer an einem Abend zum Einsatz kommen.
und das gleich bei über 100 Bugs ? Träum weiter , ich hatte dir ja schon Presse Artikel zu diversen Intel Bugs verlinkt aber Lesen und begreifen sind halt zwei paar Schuhe ...
warum hat wohl Intel die TSX Funktion deaktiviert bei Haswell , wäre es vorher aufgefallen , hätten sie sie gar nicht erst aktiviert ...
https://www.anandtech.com/show/8376...rratum-found-in-haswell-haswelleep-broadwelly
News coming from Intel’s briefings in Portland last week boil down to an erratum found with the TSX instructions.
Tech Report and
David Kanter of Real World Technologies are stating that a
software developer outside of Intel discovered the erratum through testing, and subsequently
Intel has confirmed its existence.
Intel has had numerous issues similar to this in the past, such as the
FDIV bug, the
f00f bug and more recently, the
P67 B2 SATA issues. In each case, the bug was resolved by a new silicon stepping, with certain issues (like FDIV) requiring a recall, similar to recent issues in the car industry.
This time there are no recalls, the feature just gets disabled via a microcode update.
Hier wurde sogar ein Feature komplett deaktiviert , was wesentlich schlimmer ist als der Workaround zu einem Zufallszahl Generator Befehl , den man hat Fixen können ....
Wenn du AMD an den Pranger stellen willst , musst du das ebenfalls bei Intel tun ... , denn Intel hatte bei Haswell sogar groß Werbung mit diesem Feature gemacht ... , und hat es dann deaktiviert ...
One of the main features
Intel was promoting at the launch of Haswell was TSX –
Transactional Synchronization eXtensions.
Du zeigst offen eine Doppelmoral , meinst Intel würde alles besser machen als AMD , Pustekuchen , Fehler werden immer wieder in CPUs auftreten , das hat etwas mit den Milliarden Transistoren zu tun , die verbaut werden , da reicht schon einer aus der falsch oder nicht schaltet und schon ..... Blue Screen , Absturz oder halt nur -1 statt einer Zufallszahl
Wenn du sagst , AMD hätte die Befehle überprüfen müssen , sage ich , Intel hätte bei TSX die Funktion überprüfen müssen , bevor sie groß Werbung damit machen ...
und hier noch ein Artikel für Dich , in deutsch , damit du es auch verstehst .. , zwar etwas älter ( 2016/2017 ) jedoch hat sich bei Intel da im Grunde nichts geändert
https://www.golem.de/news/cpu-bugs-errata-sind-menschlich-updates-besser-1706-128640.html
Anfang des Jahres 2016
schreibt der Elektroingenieur Dan Luu in seinem Blog:
"Wir haben einige wirklich schlimme Intel-CPU-Bugs im Jahr 2015 gesehen, und wir sollten in der Zukunft noch mehr erwarten." Luu weiß, wovon er spricht, so hat er bereits mit der Power- und ARM-Architektur gearbeitet und war am Design von
Googles Deep-Learning-Beschleuniger TPU beteiligt.
In seinem Blog sammelt Luu seitdem bekannte CPU-Bugs, zuletzt jenen,
den das Debian-Team Albtraum genannt hat. Die Bezeichnung ist keinesfalls übertrieben, sondern im Grunde genommen exemplarisch für die Fehlerkategorie und gleich aus mehreren Gründen vollkommen gerechtfertigt.
Welcher Bug gilt für welche CPU?
Die Art und Weise, wie
Intel über entsprechende Fehler informiert - die schlicht Errata heißen -
entspricht nicht viel mehr als einem schlechten Scherz. So hat das Entwickler-Team der Programmiersprache Ocaml
den konkreten Bug zwar vergleichsweise schnell auf ein Auftreten auf
Skylake-CPUs mit aktiviertem Hyperthreading beschränken können, eine Verifikation von Intel gab es dafür irritierenderweise aber offenbar nicht.
Haarsträubend ist darüber hinaus, dass der Fehler laut Intel zwar auf aktuellen
Kaby-Lake-CPUs auftritt, der Dokumentationen zufolge aber nicht auf den Kaby-Lake-X. Beide Prozessor-Serien weisen jedoch die exakt gleiche Signatur aus CPU-Familie, Model-Nummer und Stepping auf. Das verwirrt sogar das Skript zum Erkennen der betroffenen CPUs von Debian,
worauf der zuständige Maintainer Henrique Holschuh hinweist
