7 ms·

I wonder what would happen if a flaw were found that would render an entire line of expensive CPUs useless.

metalliqaz 7y ago
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. [1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug
- NortySpock 7y ago
  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.
  - wahern 7y ago
    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. https://groups.google.com/d/msg/comp.os.linux.development/4o75FKT7Ng4/_OeHY8a-yWkJ https://groups.google.com/d/msg/comp.os.linux.development/4o... 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.
    - flatiron 7y ago
      not OP but i always assume Linux had a workaround. But you are right, it just prints you got the bug and that's that https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unscoped_q=X86_BUG_FDIV https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...
- __jal 7y ago
  "Render useless" makes me think of something more like the F00F bug - hard lockup until a reboot. https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug OS vendors worked around it in software.
- alex_free 7y ago
  >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.
  - 2J0 7y ago
    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... Edit:typo fixed for pentium
  - sarah180 7y ago
    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.
    - snovv_crash 7y ago
      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.
  - hermitdev 7y ago
    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.
brenden2 7y ago
Intel has already had so many flaws and vulnerabilities that I think nothing will change. People would prefer to ignore the problem and do nothing because they don't want their businesses to implode.
- metalliqaz 7y ago
  I wish the updates for Spectre/Meltdown were optional on my Windows machine. They posed no real risk to my single-user gaming machine and the fixes had an unacceptable performance burden IMHO.
  - swift532 7y ago
    Are you sure they are not optional? I remember disabling various security updates at the time, but unfortunately I wasn't testing whether performance in games was affected positively after removing them. I can only say that it felt as it had been faster, but I hadn't measured FPS.
    - metalliqaz 7y ago
      My understanding is that newer Windows version contain microcode updates for the processors, and once they are applied, they are in there for good.
      - mgiampapa 7y ago
        Microcode doesn't flash the CPU, it's loaded at boot time, you can remove it and disable the software mitigation.
  - agloeregrets 7y ago
    Same on my Chromebook Pixel LS too. They were optional but now they added all kinds of additional mitigations and are also adding linux throttling and in the last 6 months or so I probably have gained ~60% compile time.
atq2119 7y ago
People patch, or seriously consider patching, their compilers -- unfortunately. See for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1596565 https://bugzilla.mozilla.org/show_bug.cgi?id=1596565 Maybe it doesn't quite fit your criteria completely, since there is also a microcode workaround. Still...
2J0 7y ago
Seriously this isn't humor, we're running a "abandoned " processor for authentication and a operating system decidedly unattractive unless you want to win capture the flag at deacon. We abandoned the secure operating system version very reluctantly so it was formerly B book.
- saagarjha 7y ago
  I’m having difficulty understanding this comment, would you mind explaining it a bit more?
kijiki 7y ago
The driver for recalls is demand from the largest customers. In Intel's case, mostly big cloud operators. They have a strong vested interest in pretending that sharing compute resources across customers is a safe thing to do, so they're unlikely to rock the boat.

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. [1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug https://en.wikipedia.org/wiki/Pentium_FDIV_bug

NortySpock 7y ago
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.
- wahern 7y ago
  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. https://groups.google.com/d/msg/comp.os.linux.development/4o75FKT7Ng4/_OeHY8a-yWkJ https://groups.google.com/d/msg/comp.os.linux.development/4o... 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.
  - flatiron 7y ago
    not OP but i always assume Linux had a workaround. But you are right, it just prints you got the bug and that's that https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unscoped_q=X86_BUG_FDIV https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...
__jal 7y ago
"Render useless" makes me think of something more like the F00F bug - hard lockup until a reboot. https://en.wikipedia.org/wiki/Pentium_F00F_bug https://en.wikipedia.org/wiki/Pentium_F00F_bug OS vendors worked around it in software.
alex_free 7y ago
>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.
- 2J0 7y ago
  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... Edit:typo fixed for pentium
- sarah180 7y ago
  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.
  - snovv_crash 7y ago
    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.
- hermitdev 7y ago
  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.

brenden2 7y ago

Intel has already had so many flaws and vulnerabilities that I think nothing will change. People would prefer to ignore the problem and do nothing because they don't want their businesses to implode.

metalliqaz 7y ago
I wish the updates for Spectre/Meltdown were optional on my Windows machine. They posed no real risk to my single-user gaming machine and the fixes had an unacceptable performance burden IMHO.
- swift532 7y ago
  Are you sure they are not optional? I remember disabling various security updates at the time, but unfortunately I wasn't testing whether performance in games was affected positively after removing them. I can only say that it felt as it had been faster, but I hadn't measured FPS.
  - metalliqaz 7y ago
    My understanding is that newer Windows version contain microcode updates for the processors, and once they are applied, they are in there for good.
    - mgiampapa 7y ago
      Microcode doesn't flash the CPU, it's loaded at boot time, you can remove it and disable the software mitigation.
- agloeregrets 7y ago
  Same on my Chromebook Pixel LS too. They were optional but now they added all kinds of additional mitigations and are also adding linux throttling and in the last 6 months or so I probably have gained ~60% compile time.

atq2119 7y ago

People patch, or seriously consider patching, their compilers -- unfortunately. See for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1596565 https://bugzilla.mozilla.org/show_bug.cgi?id=1596565 Maybe it doesn't quite fit your criteria completely, since there is also a microcode workaround. Still...

2J0 7y ago

Seriously this isn't humor, we're running a "abandoned " processor for authentication and a operating system decidedly unattractive unless you want to win capture the flag at deacon. We abandoned the secure operating system version very reluctantly so it was formerly B book.

saagarjha 7y ago
I’m having difficulty understanding this comment, would you mind explaining it a bit more?

kijiki 7y ago

The driver for recalls is demand from the largest customers. In Intel's case, mostly big cloud operators. They have a strong vested interest in pretending that sharing compute resources across customers is a safe thing to do, so they're unlikely to rock the boat.