Intels 475-Millionen-Dollar-Fehler: Das Siliziumproblem hinter dem Pentium-FDIV-Bug

 (righto.com)
3 Punkte von GN⁺ 2024-12-30 | 1 Kommentare | Auf WhatsApp teilen
  • Das 1993 erschienene Pentium setzte für schnellere Gleitkomma-Divisionen als beim Intel 486 auf das SRT-Verfahren, doch nachdem 1994 der Fehler im FDIV-Befehl öffentlich wurde, erklärte sich Intel zum Austausch aller fehlerhaften Chips bereit — zu Kosten von 475 Millionen US-Dollar
  • Der Defekt lag in der Lookup-Tabelle für die Division, die als PLA implementiert war. Intel erklärte, durch einen Skriptfehler seien 5 Einträge entfallen, doch eine Die-Analyse deutet auf 16 fehlende Einträge hin, von denen 5 tatsächlich Fehler verursachten
  • Die radix-4-SRT-Division erzeugt pro Schritt 2 Quotientenbits und ist dadurch schnell, hat aber eine komplexe Struktur, bei der partieller Rest und Divisor auf eine P-D-Tabelle mit 2048 Einträgen abgebildet und dann in ein PLA mit 112 Zeilen komprimiert werden
  • Die Hauptursache war, dass der Lookup-Index wegen des Carry-Save-Adders um eine Zelle unter dem tatsächlichen partiellen Rest liegen konnte. Intel wandte an der oberen Grenze des +2-Bereichs eine falsche mathematische Korrektur an und ließ dadurch einige Zellen auf 0 stehen
  • Beim korrigierten Pentium wurden nicht nur die 5 fehlenden Einträge ergänzt, sondern alle ungenutzten Tabellenbereiche mit 2 gefüllt, wodurch die Grenzen einfacher wurden. Außerdem sank die Zahl der verwendeten PLA-Zeilen von 120 auf 74, sodass das korrigierte PLA etwa ein Drittel kleiner war als das fehlerhafte

Wie der FDIV-Bug öffentlich wurde und was er kostete

  • Intel brachte 1993 den Hochleistungsprozessor Pentium auf den Markt und integrierte einen schnelleren Algorithmus für Gleitkomma-Division als im früheren Intel 486
  • Im Mai 1994 entdeckten interne Tests bei Intel, dass die Gleitkomma-Division des Pentium in sehr seltenen Fällen ungenau war
    • Intel ging davon aus, dass nur etwa 1 von 9 Milliarden Werten Probleme verursachen würde, und stufte das als geringfügig ein
    • Dennoch wurde die Pentium-Schaltung stillschweigend korrigiert
  • Im Oktober 1994 entdeckte Professor Thomas Nicely bei der Untersuchung der Kehrwerte von Primzahlzwillingen falsche Rechenergebnisse
    • Die Berechnung von 1/824633702441 war auf drei verschiedenen Pentium-Computern falsch, während ältere Rechner das richtige Ergebnis lieferten
    • Nachdem er vom Intel-Support keine ausreichende Hilfe erhielt, verschickte Nicely E-Mails an Computermagazine und Privatpersonen
    • Diese E-Mail landete im Compuserve-Forum, und Electronic Engineering Times veröffentlichte am 7. November den Artikel Intel fixes a Pentium FPU glitch
  • Intel wollte anfangs nur Kunden einen Austausch anbieten, die einen Ingenieur von der Notwendigkeit hoher Genauigkeit überzeugen konnten, worauf Nutzer in Online-Gruppen wie comp.sys.intel ihren Unmut äußerten
  • Nach einem CNN-Bericht am 22. November wuchs das öffentliche Interesse stark, und am 12. Dezember verschärfte IBM die Lage mit der Ankündigung, den Versand von Pentium-Computern auszusetzen
  • Intel gab am 19. Dezember bekannt, allen Kunden die fehlerhaften Chips zu ersetzen
    • Die Rückrufkosten beliefen sich auf 475 Millionen US-Dollar
    • Nach heutigem Wert entspricht das mehr als 1 Milliarde US-Dollar

Die vom Pentium genutzte SRT-Division

  • Die gewöhnliche binäre schriftliche Division ist langsam, weil sie für jedes Bit des Quotienten einen Takt benötigt
    • Intel 486 und frühere Prozessoren nutzten diesen Ansatz
  • Das Pentium verwendete den SRT-Algorithmus in radix-4, also mit 2-Bit-Schritten
    • Pro Schritt werden 2 Quotientenbits erzeugt, wodurch das Verfahren doppelt so schnell ist wie normale binäre Division
    • Jede Quotientenziffer ist eine von -2, -1, 0, 1, 2
  • SRT erlaubt negative Quotientenziffern, sodass eine in einem Schritt etwas zu große Wahl im nächsten Schritt durch eine negative Ziffer korrigiert werden kann
  • Weil die Quotientenziffer nicht exakt eindeutig bestimmt sein muss, lässt sie sich schnell über eine Lookup-Tabelle auswählen
    • Dabei werden nur einige Bits von partiellem Rest und Divisor verwendet, um die Tabellengröße praktikabel zu halten
  • Das Verfahren ist schnell, benötigt aber zusätzlich eine Lookup-Tabelle, Schaltungen zum Addieren oder Subtrahieren des 1- oder 2-fachen des Divisors sowie eine Schaltung zur Umwandlung in die Standardform des Quotienten

Die Struktur: 2048 Tabellenwerte in ein PLA mit 112 Zeilen komprimiert

  • Die SRT-Lookup-Tabelle des Pentium nimmt den partiellen Rest p und den Divisor d als Eingabe und gibt die passende Quotientenziffer aus
  • Die Tabelle besteht aus 2048 Einträgen
    • Der Divisor wird auf einen Bereich zwischen 1 und 2 skaliert und bildet die X-Achse
    • Der partielle Rest bildet mit Werten zwischen -8 und 8 die Y-Achse
    • Vom Divisor 1.dddd werden die 4 Bits hinter der stets vorhandenen führenden 1 verwendet
    • Der partielle Rest wird auf einen 7-Bit-Signed-Wert pppp.ppp gekürzt
    • Ein 11-Bit-Index adressiert somit 2^11 = 2048 Einträge
  • Die Tabelle enthält 5 Bereiche für die Quotientenziffern +2, +1, 0, -1, -2
    • Einige obere und untere Bereiche werden mathematisch im SRT-Verfahren nie genutzt
    • In der ursprünglichen fehlerhaften Tabelle waren ungenutzte Einträge mit 0 gefüllt
    • Die 5 problematischen roten Einträge hätten +2 sein müssen, blieben aber 0
  • Das Pentium implementierte diese Tabelle nicht als ROM, sondern als PLA (Programmable Logic Array)
    • Als vollständiges ROM wären 2048 Zeilen nötig gewesen
    • Wegen der regelmäßigen Struktur und vieler leerer Bereiche genügten im PLA 112 Zeilen
  • Ein PLA besteht aus AND plane und OR plane
    • Die AND plane erzeugt Logikterme aus Kombinationen von Eingabebits und deren invertierten Formen
    • Die OR plane fasst diese Terme zu Ausgabebits zusammen, die anzeigen, ob der Quotient 1 oder 2 ist
  • Aus dem Transistormuster des PLA unter dem Mikroskop lassen sich die Logikgleichungen der einzelnen PLA-Zeilen rekonstruieren
    • Eine PLA-Zeile steht nicht für eine einzelne Tabellenzelle, sondern wirkt wie ein rechteckiger Bereich, der mehrere Zellen zugleich abdeckt
    • Je gezackter eine Tabellengrenze verläuft, desto mehr PLA-Zeilen werden benötigt

Mathematische Grenzen und der fehlerhafte +2-Bereich

  • Der entscheidende Schritt der SRT-Division besteht darin, die Quotientenziffer q anhand des Verhältnisses p/d von partiellem Rest p zu Divisor d auszuwählen
  • Der zulässige Bereich von p/d muss aus mathematischen Gründen innerhalb von [-8/3, 8/3] liegen
    • Nach der Wahl der Quotientenziffer wird q*d subtrahiert und mit 4 multipliziert, um den partiellen Rest des nächsten Schritts zu bilden
    • Damit dieser Prozess wiederholbar bleibt, muss der neue Bereich dieselbe Größe wie der ursprüngliche haben
  • Durch die Redundanz im SRT-Verfahren kann in manchen Bereichen eine von zwei Quotientenziffern gewählt werden
    • Wenn jedoch dort, wo q=2 nötig wäre, 0 gewählt wird, fällt der nächste partielle Rest aus dem zulässigen Bereich und der Algorithmus kann sich nicht erholen
    • Genau das geschieht beim FDIV-Bug
  • Die P-D-Tabelle des Pentium ist eine auf Zellen quantisierte Form dieser mathematischen Grenzen
    • Die diagonalen Grenzen bestimmen, welche Zellen zwingend +2 sein müssen, welche +1 oder +2 sein dürfen, welche zwingend +1 sind usw.
  • Die Die-Analyse zeigt, dass die obere magentafarbene Grenzlinie der fehlerhaften Tabelle eigentlich vollständig oberhalb der schwarzen mathematischen Grenzlinie liegen müsste, diese aber wiederholt schneidet
    • Dadurch blieben einige Zellen, die zwingend +2 sein mussten, auf 0
    • Diese Zellen waren die fehlenden Einträge, die den FDIV-Bug auslösten

Wie der Carry-Save-Adder den Fehler selten, aber entscheidend machte

  • Die Divisionsschaltung des Pentium verwendete einen Carry-Save-Adder, um Additionen und Subtraktionen zu beschleunigen
    • Ein Carry-Save-Adder propagiert Überträge nicht sofort, sondern speichert sie in einem separaten Wort, was bei Divisionen mit vielen Additionen vorteilhaft ist
    • Am Ende ist eine langsamere Addition nötig, um die gespeicherten Überträge zusammenzuführen
  • Für den Index der Lookup-Tabelle wird der partielle Rest benötigt, der im Carry-Save-Adder jedoch in Sum-Bits und Carry-Bits getrennt gespeichert ist
  • Das Pentium nutzte einen Carry-Lookahead-Adder, um die für den Tabellenindex benötigten 7 Bits schnell zu berechnen
    • Diese Schaltung berechnet die Überträge jeder Stelle parallel
    • Für große Wortbreiten ist sie zu komplex, für einen 7-Bit-Wert aber praktikabel
  • Das Problem war, dass der partielle Rest 64 Bit breit ist, für die Berechnung des Tabellenindex aber nur 7 Bits verwendet werden
    • Die übrigen Bits werden vor der Summenbildung abgeschnitten, wodurch der für den Index verwendete partielle Rest geringfügig kleiner als der tatsächliche Wert sein kann
    • Konkret kann der Zugriff eine Zelle unterhalb der korrekten Zelle landen, also mit einem Offset von 1/8
  • Deshalb müssen manche Grenzlinien um 1/8 nach unten verschoben werden, aber nicht alle
    • Die obere +2-Grenze durfte nicht nach unten verschoben werden, Intel erzeugte jedoch eine Tabelle, in der genau das geschah
    • Dieser Carry-Save-Effekt war bereits in damaligen Facharbeiten zur SRT-Division beschrieben

Wo sich Intels Erklärung und die Die-Analyse widersprechen

  • In einem Whitepaper erklärte Intel, ein Problem in einem Skript zur Übertragung der Tabelle in das PLA habe dazu geführt, dass einige Einträge im PLA fehlten
    • Intel nannte die Struktur zwar ein Programmable Lookup Array, tatsächlich handelt es sich aber um ein Programmable Logic Array
  • Die Die-Analyse deutet darauf hin, dass die fehlenden Einträge besser zu einem Fehler in der mathematischen Grenzziehung passen als zu einem simplen Kopierfehler
    • Möglich ist, dass das Programm zur Tabellenerzeugung die Randbedingungen falsch definierte
    • Die Bezeichnung „Skript“ kann technisch korrekt sein, wenn damit ein C-Programm zur Tabellenerzeugung gemeint war, doch das eigentliche Problem war dieser Lesart zufolge eine falsche mathematische Grenze
  • Robert Colwells The Pentium Chronicles liefert eine andere Erklärung
    • Demnach habe das Pentium-Design ursprünglich dieselbe Lookup-Tabelle wie der 486 verwendet und erst kurz vor dem Marktstart aus Druck zur Einsparung von Die-Fläche eine Optimierung vorgenommen, bei der der Fehler entstand
  • An dieser Darstellung gibt es mehrere Widersprüche
    • Das Pentium nutzte von Anfang an einen anderen Divisionsalgorithmus als der 486
    • Das Pentium verwendete radix-4-SRT, der 486 klassische binäre Division
    • Im 486 existiert diese Lookup-Tabelle gar nicht
    • Im fehlerhaften PLA blieben 8 Zeilen ungenutzt; hätte man nur Fläche sparen wollen, hätte man diese zuerst entfernen können

Warum das korrigierte PLA kleiner wurde

  • Zeitgenössische Berichte sagten, Intel habe zur Fehlerbehebung einige Dutzend Transistoren oder zusätzliche gate sequence in das PLA eingefügt
  • Das auf dem Die sichtbare korrigierte PLA zeigt das Gegenteil
    • Die Größe des PLA blieb gleich
    • Etwa ein Drittel der Terme wurde entfernt
    • Von 120 Zeilen werden nur 74 genutzt, die übrigen 46 sind leer
    • Im ursprünglichen fehlerhaften PLA gab es nur 8 leere Zeilen
  • Intels Korrektur bestand nicht nur darin, die 5 fehlenden Einträge mit 2 zu füllen
    • Stattdessen wurden alle zuvor ungenutzten Tabelleneinträge mit 2 gefüllt
    • Dadurch verschwand die Möglichkeit, versehentlich auf einen leeren Eintrag zuzugreifen
  • Das Füllen der ungenutzten Bereiche mit 2 vereinfachte die Tabellengrenzen
    • Gezackte Grenzen erfordern viele PLA-Terme
    • Große rechteckige Bereiche können von einem einzigen PLA-Term abgedeckt werden
    • So wurden zwar mehr Tabellenzellen gefüllt, aber die PLA-Logik insgesamt einfacher
  • Da sich die Logikterme des korrigierten PLA vollständig von denen des ursprünglichen unterscheiden, lässt sich nicht auf ein paar bestimmte Transistoren zeigen und sagen, genau diese hätten den Bug behoben

Reale Auswirkungen und die Debatte darüber

  • Bei zufälligen Divisionen lag die Wahrscheinlichkeit für den Defekt nur bei etwa 1 zu 9 Milliarden
    • Selbst falsche Divisionsergebnisse unterschieden sich meist erst in der 9. oder 10. Dezimalstelle
    • In seltenen Worst-Case-Fällen trat der Fehler bereits bei der 4. signifikanten Stelle auf
  • In seinem Whitepaper schätzte Intel, dass normale Nutzer dem Problem nur etwa einmal in 27.000 Jahren begegnen würden
    • Für die meisten Anwender sei es kein Problem; nur einige Nutzer in Wissenschaft, Ingenieurwesen und Financial Engineering könnten einen korrigierten Prozessor oder Software-Workarounds benötigen
  • IBM kam in einer eigenen Analyse zu dem Schluss, Kunden könnten das Problem alle paar Tage erleben, und stoppte deshalb den Verkauf von Pentium-Systemen
    • IBM verfügte damals mit PowerPC auch über einen konkurrierenden Prozessor
  • Einer Analyse zufolge scheint Professor Nicely der einzige Mensch gewesen zu sein, der den Bug im realen Einsatz tatsächlich entdeckte
    • IBMs Analyse wird so bewertet, dass sie Zahlen auswählte, die besonders leicht Fehler auslösten
    • Die meisten Nutzer würden dem Bug wohl nie begegnen, und selbst dann wäre ein kleiner Präzisionsverlust bei Gleitkommazahlen oft unerheblich
  • Trotzdem war der FDIV-Bug deterministisch reproduzierbar
    • Wenn bestimmte dividend und divisor den Fehler auslösten, war das Ergebnis zu 100 % falsch
    • Weil Kunden das auf ihren eigenen Rechnern leicht nachstellen konnten, war es für Intel schwer zu behaupten, man werde dem Problem „nie begegnen“

Spätere Prozessor-Bugs und patchbarer Mikrocode

  • Der FDIV-Bug ist einer der bekanntesten Prozessorfehler, aber bei Intel gab es weitere wichtige Bugs
  • Bei manchen frühen 386-Prozessoren gab es ein Problem bei 32-Bit-Multiplikationen
    • Unter bestimmten Temperatur-, Spannungs- und Frequenzbedingungen erzeugten sie unvorhersehbar falsche Ergebnisse
    • Ursache war ein Layout-Problem mit zu geringer elektrischer Reserve
    • Intel verkaufte die fehlerhaften Chips nur noch für den 16-Bit-Markt und kennzeichnete sie mit „16 BIT S/W ONLY“
  • Ein weiteres Pentium-Problem war der 1997 entdeckte F00F bug
    • Eine bestimmte Befehlssequenz beginnend mit F0 0F ließ den Prozessor bis zum Neustart hängen
    • Behoben wurde das Problem durch ein Betriebssystem-Update
  • Beim Pentium war der Mikrocode fest in ROM eingebrannt, daher ließ sich der FDIV-Bug nicht per Mikrocode-Update beheben
  • Intel ergänzte 1995 im Pentium Pro patchbaren Mikrocode
    • Ursprünglich war das für Chip-Debugging und Tests gedacht
    • Nach dem FDIV-Bug wurde klar, dass es auch für Bugfixes wertvoll ist
    • Der Pentium Pro kombinierte ROM-Mikrocode mit SRAM für bis zu 60 Mikroinstruktionen, in den das BIOS beim Booten Patches laden konnte
  • Mikrocode-Patches in modernen Intel-Prozessoren werden für verschiedenste Probleme eingesetzt, von der Spectre-Schwachstelle bis zu Spannungsproblemen

Ein Fehler, den immer komplexere Schaltungen möglich machten

  • Nach dem Mooreschen Gesetz stieg die Zahl der Transistoren in Prozessoren, und damit wurden auch Schaltungen und Algorithmen immer komplexer
  • Die Entwicklung der Divisionsunterstützung zeigt das gut
    • Der Intel 8080 nutzte 1974 6000 Transistoren und unterstützte weder Hardware-Division noch Gleitkomma-Arithmetik
    • Der Intel 8086 nutzte 1978 29.000 Transistoren und implementierte Ganzzahldivision per Mikrocode, benötigte für Gleitkomma aber den 8087-Koprozessor
    • Der Intel 486 integrierte 1989 bei 1,2 Millionen Transistoren die Gleitkomma-Unterstützung direkt auf dem Chip
    • Das Pentium setzte 1993 mit 3,1 Millionen Transistoren auf einen schnelleren, aber komplexeren SRT-Divisionsalgorithmus
  • Allein das Divisions-PLA des Pentium umfasst etwa 4900 Transistor-Standorte
    • Das ist mehr als der gesamte MOS Technology 6502-Prozessor
    • Eine einzelne Komponente der Pentium-Divisionsschaltung nutzte also mehr Transistoren als ein kompletter Prozessor aus dem Jahr 1975
  • Die langfristigen Auswirkungen des FDIV-Bugs sind umstritten
    • Konkurrenten wie AMD profitierten mit Werbeanzeigen, die sich über das Pentium-Problem lustig machten
    • Robert Colwell meint, der FDIV-Bug habe den Bekanntheitsgrad des Namens Pentium stark erhöht und gezeigt, dass Intel hinter seiner Marke steht, sodass der Nettoeffekt sogar positiv gewesen sein könnte
  • Intel überstand den FDIV-Bug, doch der damalige Defekt zeigte, wie die Kombination aus komplexer Mathematik, Schaltungskomprimierung und Grenzen der Verifikation selbst extrem seltene Fehler in große Vertrauensprobleme verwandeln kann

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-30
Hacker-News-Kommentare

  • Ich bin der Autor. Wenn es Fragen zum Pentium gibt, kann ich sie beantworten :-)
    Der Mastodon-Thread zu diesem Bug war vor ein paar Wochen auf HN, daher kommt er manchen vielleicht bekannt vor; inzwischen habe ich aber den ausführlichen Blogbeitrag fertiggestellt. Auch im früheren HN-Beitrag gibt es ziemlich viele Kommentare: https://news.ycombinator.com/item?id=42391079

    • Diese 475 Millionen US-Dollar waren aus Intels Sicht vielleicht die beste Marketingausgabe überhaupt. Durch den Bug und den Rückruf wurde Intel auch Menschen außerhalb der Tech-Branche bekannt. In einer Zeit, in der man nach dem 486 einen 586 oder 686 erwartete und plötzlich der Name Pentium auftauchte, hat dieser Vorfall meiner Ansicht nach Bekanntheit und Wohlwollen aufgebaut, was sich später bis zum Pentium MMX fortsetzte.
    • Wie immer sind Artikel und Analyse hervorragend. Rückblickend ist es ziemlich seltsam, dass ein im Grunde kleiner CPU-Fehler weltweit Schlagzeilen machte.
      Auch bei Intel gab es schlimmere Fehler, und bei anderen Firmen ebenfalls, aber die sind völlig in Vergessenheit geraten. Ich bin neugierig auf die Überarbeitung des Wertestacks der Floating-Point-Unit des Pentium – die genaue Bezeichnung kenne ich nicht. Das ist lange her, aber war das nicht eine frühe Form von Register Renaming, bei der man fxchg vorsichtig von Hand verwalten musste?
    • Mich interessiert die Stelle: „Der Bug steckt vermutlich in der umfangreichen Microcode des Pentium. Microcode ist zu komplex, um ihn zu analysieren; erwartet also keinen ausführlichen Blogbeitrag zu diesem Thema.“
      Wie schwierig wäre es, den Microcode als Bitstream zu „dumpen“? Ginge das programmatisch anhand hochauflösender Die-Fotos? Natürlich wäre das vermutlich noch der leichtere Teil verglichen mit dem Reverse Engineering dessen, was der Bitstream bedeutet.
      Auch die Stelle „ich habe die PLA sorgfältig unter dem Mikroskop untersucht“ interessiert mich. Macht man so etwas zu Hause, welche Ausrüstung steht im Labor, und wie lernt man solche Techniken?
    • Ich wollte fragen, ob die Avogadro-Konstante in der Erklärung zu Floating-Point-Zahlen absichtlich gewählt war, bis mir auffiel, dass die andere Zahl die Planck-Konstante ist.
    • Ich habe zum ersten Mal verstanden, dass Floating-Point-Division so implementiert werden kann. Es ist irgendwie witzig, dass mir nicht klar war, dass man zur tatsächlichen Implementierung von Floating-Point-Division mehrere Schritte der Integer-Division braucht.
      Im Nachhinein fragt man sich, warum die ungenutzten Bereiche der Lookup-Tabelle nicht von Anfang an mit 2 und -2 gefüllt wurden.

  • Der Bug selbst ist interessant, aber Intels Reaktion ist für sich genommen ebenfalls spannend. Offenbar wurden nicht allen, die es wollten, fehlerfreie Prozessoren als Ersatz angeboten, was zu enorm schlechter Presse führte.
    Zum Vergleich muss ich sehr an den Start des Amazon Colorsoft denken. Einige Geräte, darunter auch meines, hatten ein Grafikproblem mit einem gelben Streifen. Amazon prüfte ein oder zwei Tage lang die Fakten, räumte es dann ein und tauschte anschließend stillschweigend alles aus. Kein Rückruf; wenn man nachfragt, schicken sie ein neues Gerät. Mein Austauschgerät kommt am Freitag, hoffentlich ist es behoben. Wenn ein Launch holpert, ist ein sehr solides Rückgabe-/Supportsystem eindeutig ein viel größerer Vorteil, als man es anhand von Analysen erwarten würde.
    Ähnlich wurde vor ein paar Jahren über das Rauschproblem der Apple AirPods Pro zuletzt nicht mehr besonders groß berichtet. Meine AirPods mussten zweimal ersetzt werden, aber auch Apple hat sie stillschweigend ausgetauscht. Es fühlte sich so an, als ob Supportkompetenz nach außen kaum sichtbar ist, aber ziemlich wirkungsvoll greift.
    Colorsoft: https://www.tomsguide.com/tablets/e-readers/amazon-kindle-co...
    AirPods Pro: https://support.apple.com/airpods-pro-service-program-sound-...

    • Kindle und AirPods passen als Vergleich nicht besonders gut zum Pentium, weil sie für die jeweiligen Unternehmen relativ kleine Produkte sind.
      Bei Apple wäre iPhone 4 Antennagate der bessere Vergleich. Die gleichwertige Lösung wäre dort gewesen, das umsatzentscheidende Flaggschiffprodukt kostenlos auszutauschen, aber das hat Apple nicht getan.
      Intel dagegen bot am Ende jedem, der darum bat, einen kostenlosen Austausch an und nahm einen großen finanziellen Schaden in Kauf.
    • Ich hatte ein weißes MacBook der ersten Generation; wegen des magnetischen Verschlusses riss und verfärbte sich das Topcase. Während der Lebensdauer des Computers wurde es mir drei- oder viermal kostenlos ersetzt, sogar noch nach Ablauf der dreijährigen AppleCare.
      Diese Art, für ein Produkt einzustehen, fand ich bei Apple wirklich respektabel.
    • Ich hatte den Eindruck, dass Intels Reaktion eine Zeit lang darin bestand, stark in Korrektheit zu investieren. Dann kamen sie offenbar zu dem Schluss, dass AMD trotz höherer Fehlerraten nicht abgestraft wurde, und in jüngerer Zeit scheinen sie in andere Dinge investiert zu haben, um bei Kennzahlen mit AMD zu konkurrieren, bei denen es nicht darum geht, wie bugarm eine CPU ist.
    • Im Großen und Ganzen war das kein Problem einzelner Privatkunden. Unternehmen kauften ziemlich teure Pentium-Rechner über Distributoren, und je nach Supportvertrag tauschte der Anbieter sie aus.
      Ich kenne diese „Schatten-Garantie“-Situation bei Consumer-Apple-Produkten und verstehe, was gemeint ist, aber das war sehr anders als die IT-Krise, mit der Intel konfrontiert war. Damals hatte „IBM hat das gesagt“ in der IT enormes Gewicht.
    • Das ist im Grunde die Standardmethode von Amazon. Man kann fast aus jedem Grund ohne große Umstände etwas zurückgeben.

  • Im Intel-Whitepaper hieß es, ein normaler Nutzer würde dem Problem einmal in 27.000 Jahren begegnen, und im Vergleich zu anderen Fehlerursachen wie DRAM-Bit-Flips sei es vernachlässigbar. IBM dagegen kam in einer eigenen Analyse zu dem Schluss, dass Kunden alle paar Tage darauf stoßen könnten.
    Die beiden Zahlen liegen vermutlich nicht so weit auseinander, wie es scheint. Intel scheint von einem einzelnen Nutzer ausgegangen zu sein, während IBM möglicherweise aus der Perspektive von Supportanfragen dachte.
    Im Job hatte ich ein ähnliches Problem. Wenn man 100 Millionen Requests pro Tag verarbeitet, tritt ein Eins-zu-einer-Milliarde-Problem ein paar Mal im Monat auf. Wenn es die Art von Problem ist, die Kunden oder, schlimmer noch, Manager bemerken, ignorieren die Leute den Nenner und vermuten, alle seien inkompetent. Viermal im Monat kann sich in der menschlichen Wahrnehmungsverzerrung wie „ständig“ anfühlen. Wenn es zweimal zu einem statistischen Cluster von drei Fällen pro Woche kommt, explodiert irgendjemand.

    • Nein. Auch IBMs Schätzung bezog sich auf einen einzelnen Nutzer. IBM rechnete damit, dass ein typischer Spreadsheet-Nutzer während einer Neuberechnung 5.000 Divisionen pro Sekunde ausführt und pro Tag 15 Minuten lang neu berechnet.
      Außerdem nahm IBM an, dass die von Menschen verwendeten Zahlen mit 90-fach höherer Wahrscheinlichkeit einen Fehler auslösen als Intels Zahlen bei Gleichverteilung. Daraus ergab sich, dass ein Nutzer alle 24 Tage einen Fehler erleben würde.

  • Es gibt die Passage: „Die einzige Person, die diesen Bug im realen Einsatz bemerkt zu haben scheint, war Professor Nicely.“
    Das erinnert mich an eine Studie von vor langer Zeit, in der Schülern Taschenrechner für den Mathematikunterricht ausgeteilt wurden. Die Rechner waren so manipuliert, dass sie falsche Ergebnisse lieferten, und die Forscher wollten wissen, wie stark der Rechner danebenliegen musste, damit die Schüler die Auffälligkeit bemerkten.
    Die Antwort war: um den Faktor 2.
    Einen Fehler zu bemerken und von einem Fehler betroffen zu sein, sind zwei völlig verschiedene Dinge. Wie viele Menschen prüfen, ob die Ausgabe eines Computers stimmt? Sehr, sehr, sehr wenige, würde ich sagen. Ich selbst habe es auch nicht getan, außer in einem Fall, als ich bei Boeing für eine technische Berechnung die Gleichung rückwärts durchgerechnet habe, um zu prüfen, ob die Ausgabe zur Eingabe passte.

    • Ich habe an der Uni Nachhilfe in Physik gegeben. Wenn Studierende mir ihre gelösten Aufgaben zeigten und um Feedback baten, sagte ich ihnen manchmal, dass sie irgendwo sicher einen Fehler gemacht hätten, wenn sie für die Höhe einer Achterbahn 23.000 Meilen berechnet hatten.
      Am Ende hängt es stark vom Kontext ab und davon, wie gut die rechnende Person den Inhalt versteht.
    • „Einen Fehler zu bemerken und von einem Fehler betroffen zu sein, sind zwei völlig verschiedene Dinge“ stimmt nur bis zu einem gewissen Grad. Nehmen wir Consumer-Nutzung: Wenn beim Spielen eine falsche Ausgabe entsteht, man aber letztlich nichts davon bemerkt, war man dann wirklich betroffen?
      Wie viel der FDIV-Nutzung auf dem Pentium diente wohl numerisch relevanten Ausgaben und nicht Multimedia?

  • Ich erinnere mich an diesen Bug. Weil wir nicht kontrollieren konnten, auf welcher CPU ein Kunde lief, mussten wir in unsere Library Code zur Erkennung fehlerhafter FPUs einbauen und einen Workaround ausführen. Diesen Code stellte Intel bereit.
    Mit anderen Worten: Intels Problem wurde zu meinem Problem, ugh.

  • Mir fällt ein Witz ein, der damals kursierte. Er brachte mehrere Stimmungen der 90er gut auf den Punkt:
    I AM PENTIUM OF BORG.
    DIVISION IS FUTILE.
    YOU WILL BE APPROXIMATED.

    • Das war vermutlich in meinem Signaturgenerator.

  • Wieder ein hervorragender Artikel von Ken. Mir ist das besonders in Erinnerung geblieben, weil in meinem ersten PC, den ich von meinem eigenen Geld gekauft habe, eine betroffene CPU steckte. Davor hatte ich mich nicht besonders für PCs interessiert, weil sie keine „richtige“ Software ausführen konnten.
    Aber Windows NT änderte das, und dafür danke ich Cutler. Dank günstiger Mainboards aus Taiwan wurde es auch realistisch, sich selbst eine Maschine zusammenzubauen, und viele tun das bis heute. Ken weist darauf hin, dass Nutzer leicht prüfen konnten, ob ihre CPU betroffen war. Ich erinnere mich, dass es ungefähr so einfach war, in Excel eine Divisionsformel mit einer magischen Zahl einzugeben. Hätte Microsoft eine Excel-Version veröffentlicht, die den Bug umgeht, hätten wohl weniger Nutzer einen Austausch verlangt.

    • Konnten diese PCs kein 386BSD ausführen?

  • Eine interessante und wirklich hartnäckige Analyse. Beeindruckend, wie viel Mühe darin steckt, das Silizium zu analysieren und die Ergebnisse zu teilen. Besonders gut fand ich, dass Intels PR die tatsächliche Ursache wie ein kleines Versäumnis klingen ließ, der Artikel aber die eigentliche Root Cause herausarbeitet.
    Tatsächlich war das Problem viel weniger verzeihlich und stärker vorwerfbar: Man hatte den Algorithmus zur Tabellenerzeugung vermasselt.

  • Der Satz „Smith postete diese E-Mail in einem Compuserve-Forum, der 1990er-Version von Social Media“ löst bei mir ein seltsames Gefühl aus.

    • Ich nenne es lieber die 1900er statt der 1990er.
    • Mein erster Gedanke war, dass diese Daten wahrscheinlich größtenteils verschwunden sind, ohne je gemined worden zu sein. Glückliche Kerle!
    • Er verschickte das mit einem Personal Computer, dem Vorläufer des Smartphones.

  • Die korrigierte Tabelle wurde viel einfacher, indem sie außerhalb des Bereichs einfach 2 zurückgab, statt zusätzliche Schaltungsteile einzubauen, die dort 0 zurückgeben. Da frage ich mich, warum man das nicht von Anfang an so gemacht hat.

    • Es wirkt wie eine Optimierung, die übersehen wird, wenn mehrere Leute die Arbeit aufteilen und niemand das gesamte Problem vollständig im Blick hat.
      Die Person, die die Tabelle erzeugte, wusste nicht, dass das Füllen der Out-of-Range-Werte mit 2 zu einer einfacheren PLA führen würde, und die Person, die die Tabelle in die PLA presste, wusste vielleicht nicht, dass 0 ein Don't-care-Wert war, und nahm an, er müsse erhalten bleiben.
      Oder sie hörten einfach mit der Optimierung auf, sobald die PLA klein genug erschien. Wenn die Platzierungsplanung bereits abgeschlossen war, hätte eine noch kleinere PLA den gesamten Chip ohnehin nicht kleiner gemacht, und die Engineering-Zeit war anderswo besser eingesetzt.
    • Da fällt mir der Spruch ein: „Mach es erst funktionsfähig, bevor du es schnell machst.“ Im Kern war das ein Softwareproblem, das mit Softwaremethoden gelöst wurde.
      Wie bei der meisten Software gab es eine Optimierung, die liegen blieb, weil niemand rechtzeitig daran dachte. Und CPUs aus dieser Zeit konnte man nicht patchen.
    • Für undefinierte Tabelleneinträge 0 zurückzugeben, ist die naheliegendste Wahl. Diese Einträge auf 2 zu setzen, erfordert konzeptionell einen kleinen Sprung. Auch wenn das den FDIV-Fehler verhindert und die PLA vereinfacht hätte, kann man Intel dafür schwer die Schuld geben.
    • Trotzdem muss das für die Ingenieure eine wirklich befriedigende Korrektur gewesen sein.
    • Mehr Engineering-Zeit führte eben zu einer effizienteren Lösung.