the closest I can think of was the famous floating point error that caused Intel to recall lots of parts[1]. Even that didn't render the CPUs useless for most users, only some scientific and business use cases really had problems.
>Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the issue to Intel.
Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.
I spent an entire summer as an intern, constantly on the phone with IBM support trying to get DB2 Connect to work in a Windows cluster only to be told "this is not a supported configuration" despite it being clearly supported in the documentation. Gave up. Years later, ran into my former boss randomly (at a liquor store of all places) and he mentioned they were finally able to get it to work.
Another confounding one was where I was trying to bulk copy some data to Sybase using Python. Started getting some really strange DB errors. Couldn't figure it out for a while. Turns out, it was a bug in the DB module and it was using uninitialized memory in certain conditions. Was a 1-line fix, but took about 6 weeks to find.
Yet another one was when I was working on porting my C++ services from 32 to 64-bit. Sockets were timing out immediately sometimes. Couldn't reproduce in the debugger. Was a bug in a 3rd party framework. It was improperly using the rtdsc instruction in some inline ASM. Worked fine on 32-bit, but the register layout was different on 64-bit. So, it was effectively reading a garbage upper 32-bits for the high-res timer. Only found that one because I noticed in my logs that my timers were reporting that some operations had taken >200 years. I forget how long it took to track that one down, but it was months of off and on hunting.
I've also hit internal compiler errors. The one I remember was that an anonymous namespace at global scope would cause an ICE. I was about to file a bug report once I'd a minimal reproduction, but it'd already been reported and fixed.
I had a similar experience when doing my first serious work in a compiled language. I found and reported a compiler bug in double-precision division (in a commercial C compiler). It took me years to stop blaming the compiler for my bugs.
I had the same, an embedded system with GCC 3.something. Managed to get a toolchain together with 4.something and suddenly our uptime and random corruption issues disappeared.
My memory is hazy but I'm sure I recall the problem during summer 94, but I stand corrected. Was there any normal way for the information to reach us? That was the year intel took down Vlsd Pentkovskis profile page.. I loved to tease everyone that Pentium was named tribute to him...
And as I recall Linux had a kernel patch that would bypass the affected hardware and run all floating point operations in software (splitting floats into two integers, etc), so you could bypass the flaw at the cost of performance.
I remember Linux having floating-point emulation for 486 processors without a floating point unit. But at least according to this early message from Torvalds, Linux didn't implement this for FDIV:
> It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead.
> Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones.
Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently.
I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.
[1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug