# The Pentium FDIV bug: a small defect and a $475 million answer > Five missing entries in a lookup table made certain divisions slightly wrong. Intel had found it internally, decided it did not qualify as an erratum, fixed it quietly and said nothing. When a mathematics professor found it independently, the company offered replacements only to customers who could prove they were affected - and turned a rare arithmetic flaw into the most famous recall in computing. Source: https://ronutz.com/en/learn/the-pentium-fdiv-bug Updated: 2026-09-09 --- ## The defect Division in the early Pentium used the Sweeney-Robertson-Tocher algorithm, which works by looking up partial quotients in a table. The table was implemented as a programmable logic array of 2,048 cells, of which 1,066 needed to hold one of five values: minus two, minus one, zero, plus one, plus two. Because of an error in the script that loaded the array, five entries were left out. When the division hardware indexed one of those cells it read zero instead of plus two, and the answer came out wrong - by a relative error of up to about six parts in a hundred thousand. That is the whole engineering fault. A script, five cells, a wrong answer in the fifth significant figure. Later steppings loaded the complete table and the problem disappeared. ## The statistic, and why it was the wrong one Intel's position was that the flaw was negligible, and the company published a study to support it: *Statistical Analysis of Floating Point Flaw in the Pentium Processor*, which estimated that a typical user would encounter an error roughly once in many thousands of years of ordinary computing. On random 64-bit divisions the rate is about one in nine billion. The arithmetic is correct and the conclusion does not follow, for a reason that is worth internalising because it recurs constantly in security and reliability work. **The flaw was deterministic.** For a particular pair of operands it did not fail rarely; it failed *every time*. A once-in-nine-billion figure describes what happens when inputs are drawn at random, and real computations do not draw at random. They run the same formula over the same data repeatedly, in a loop, in a spreadsheet model, in a nightly batch. A user whose work happened to touch an affected operand pair would meet the error on every run and never see a correct result - while the population average said the problem practically did not exist. Averaging over the population is the right statistic for estimating total incidents. It is the wrong statistic for telling an individual whether they are affected, and Intel used it to answer the second question. Any risk argument of the form "the probability is tiny" deserves the follow-up: *tiny across what, and is the failure independent or deterministic for a given input?* ## The timeline, which is the real story **May or June 1994.** Intel's own testing finds it. Accounts differ on who and exactly when, and one detailed reconstruction suggests it was probably found more than once internally and kept quiet each time. The internal assessment, quoted in that account, was that it did not even qualify as an erratum. The company quietly revised the circuitry, disclosed nothing, and did not recall anything. **13 June 1994.** Thomas Nicely, a mathematics professor at Lynchburg College computing sums over primes and twin primes, notices inconsistencies shortly after adding a Pentium to his machines. He spends four months eliminating other explanations - his own code, the motherboard, the chipset - because a professional's first assumption is that the fault is his. **19 October.** He is certain the processor is wrong. Older machines give the right answer; three different Pentium systems give the same wrong one. **24 October.** He reports it to Intel. **1 November.** Intel replies that preliminary checks have found no issue. **30 October, and after.** Nicely emails academic contacts describing the bug and asking them to test their own machines. Verification comes back quickly, and the story spreads across the young internet at a speed the company had not planned for. **Then the position that broke it.** Intel offered replacements only to customers who could **demonstrate that they were affected** - a burden that was close to impossible to discharge, since establishing that your calculations touched one of the missing table entries required knowing which entries were missing, which Intel had not published. The people asked to prove harm were the ones who could not. **20 December 1994.** Intel reversed: replacement on request, no questions asked, with a charge against fourth-quarter earnings. The charge was about **$475 million**. The company's annual report described itself as having been engulfed in a controversy. ## What a practitioner should take from it **The defect was cheap and the handling was expensive.** A different sequence was available at every step: publish the erratum in May, describe the affected operations, ship the fix, offer replacement to anyone doing numerical work. That path costs a bad week and some silicon. The path taken cost most of half a billion dollars and thirty years of being the example. This is the [no-perfect-code](https://ronutz.com/en/learn/there-is-no-perfect-code) argument in hardware: the failure was not in engineering, it was in the interval between knowing and saying. **"We fixed it quietly" is a decision with a shelf life.** Intel corrected the circuitry while saying nothing, which works only for as long as nobody outside finds the original. Somebody always finds it - and when they do, the fact that you already knew becomes the story, replacing the defect entirely. [DigiNotar](https://ronutz.com/en/learn/rsa-and-diginotar-2011) revoked certificates for a month in silence and was found by a member of the public; the shape is identical. **Asking the customer to prove harm inverts the relationship.** In practice it tells them they are the ones being doubted, at the moment they most need to be believed - which is the opposite of what the [Therac-25](https://ronutz.com/en/learn/therac-25-and-defence-in-depth) record teaches about reports you cannot immediately explain. Where a defect is deterministic and the affected inputs are known to the vendor and not to the user, the burden cannot honestly sit with the user. **And the finder was an outsider doing his own work.** Nicely was not auditing Intel. He was counting primes, noticed his numbers were wrong, and spent four months suspecting himself before suspecting the chip. Almost every case in this catalogue has someone like him in it - [Kaminsky](https://ronutz.com/en/learn/the-kaminsky-dns-flaw) with DNS, a Gmail user in Tehran with DigiNotar, a statistics department with [a map](https://ronutz.com/en/learn/the-500-mile-email). The report that arrives from outside, about something that should not be possible, is the most valuable input a vendor receives and the one most likely to be dismissed. ## Sources - [HandWiki: the SRT division algorithm is implemented as a programmable logic array with 2,048 cells, of which 1,066 should have been populated with one of five values (-2, -1, 0, +1, +2); on the buggy chips five cells that should have contained +2 were missing and instead returned 0; Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets and quadruplets, noticed inconsistencies on 13 June 1994 shortly after adding a Pentium, was unable to eliminate other factors such as programming errors and motherboard chipsets until 19 October, and reported the issue to Intel on 24 October](https://handwiki.org/wiki/Software:Pentium_FDIV_bug) - [Wikipedia: Intel had reportedly become aware of the issue independently by June 1994 and had begun fixing it, but chose not to publicly disclose any details or recall affected CPUs; on 30 October 1994 Nicely emailed various academic contacts describing the bug and requesting reports of testing on 486-DX4s, Pentiums and Pentium clones; the bug was quickly verified by others and news spread quickly on the internet; Intel adopted an upon-request replacement policy on 20 December 1994 and took a fourth-quarter charge against earnings](https://en.wikipedia.org/wiki/Pentium_FDIV_bug) - [Ken Shirriff, "Intel's $475 million error": in May 1994 Intel's internal testing revealed that very rarely floating-point division was slightly inaccurate, and since only one in 9 billion values caused the problem Intel's view was that it did not even qualify as an errata; nonetheless Intel quietly revised the circuitry to fix it; Nicely determined that a particular division was wrong on three different Pentium computers while his older computers gave the right answer; accounts of who found it internally differ, and the bug was probably kept quiet inside Intel and discovered more than once](http://www.righto.com/2024/12/this-die-photo-of-pentium-shows.html) - [Grokipedia: the flaw stemmed from five omitted entries in a 1,066-entry lookup table in the FPU's constant ROM implementing the SRT algorithm, producing relative errors up to approximately 6 x 10^-5; it affected approximately 1 in 9 billion random 64-bit divisions **but was deterministic for particular operand pairs**; an Intel representative responded to Nicely on 1 November 1994 stating that preliminary checks had found no issue with the processor](https://grokipedia.com/page/Pentium_FDIV_bug) - [Center Consulting: the table should have held 1,066 entries but because of an error in the script that loaded the array five entries were left out, and when the divide hardware indexed one of those missing cells it fetched zero instead of the correct value; Intel's in-house study "Statistical Analysis of Floating Point Flaw in the Pentium Processor" by Sharangpani and Barton argued the flaw was extremely unlikely to affect ordinary users, estimating an error only once in many thousands of years of normal computing; Intel initially offered replacements only to customers who could demonstrate they were affected, reversed course in December 1994 to replace any affected Pentium on request, and took a charge of roughly 475 million dollars; the lasting lesson was about handling, a narrow well-understood hardware defect becoming one of the most famous failures in computing less because of the silicon than because of how its maker first chose to talk about it](https://www.centerconsulting.com/code-library/stories/pentium-fdiv-bug) - [Tom's Hardware, thirty years on: because only five of the 1,066 populated cells had the wrong value, floating point division was usually correct until at least the fourth digit, which is perhaps why the bug went unnoticed for over a year; Intel acknowledged the problem in its 1994 annual report, saying it had been engulfed in a controversy, and admitted it cost 475 million dollars to recall the defective processors](https://www.tomshardware.com/pc-components/cpus/its-been-30-years-since-intels-infamous-pentium-fdiv-bug-reared-its-ugly-head-a-math-bug-caused-intels-first-cpu-recall)