6 ms·

It's happened to AMD before, and it was pretty bad for their brand. http://www.anandtech.com/show/2477/2 http://www.anandtech.com/show/2477/2

by zelon88 10y ago

raverbashing 10y ago
Intel had serious problems as well, let's not forget: the Pentium fp bug and the F00F bug (though those are more than a decade old at this point)
- msbarnett 10y ago
  Haswell and early Broadwell had a bug in its transactional memory extensions so serious that the microcode "fix" simply permanently disabled the instructions. CPU errata like this aren't uncommon.
  - m45t3r 10y ago
    While those are the most remembered bugs, almost every CPU have some kinda of CPU errata that can lock up the system in really weird and specific ways. For example, my Intel Ivy Bridge CPU running Linux: $ dmesg | grep -i microcode [ 0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26 [ 1.415548] microcode: sig=0x306a9, pf=0x10, revision=0x1c [ 1.415665] microcode: Microcode Update Driver: v2.2. The fact that most users does not hit those bugs is because modern OS already patches those microcode before execution (like the case above). Of course, if AMD can't fixes those bugs without performance regressions (remember the infamous TLB Bug from earlier Phenoms?) it can be pretty bad. However I don't think the majority of users needs to be too cautious about it.
    - yuhong 10y ago
      Some of which are quite serious: http://yuhongbao.blogspot.ca/2015/06/why-your-core-2-processor-appear-to-not.html http://yuhongbao.blogspot.ca/2015/06/why-your-core-2-process...
- deleted 10y ago
  [deleted]
- rincebrain 10y ago
  Don't forget the (other) f00f bug in the Intel Quark![1] [1] - https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug
  - makomk 10y ago
    Yeah, that was kind of unfortunate as it made the Intel Quark incompatible with all normal Linux distros. I don't think it even had any kind of microcode update facility, being effectively a slightly updated 486.
    - rincebrain 10y ago
      Even with a runtime microcode update facility, no BIOS update equivalent would still make it pretty fatal for packaging except as an entirely distinct build target, because otherwise you'd need to do something kinky like always first booting a custom kernel+initrd target built to involve no locks, load the microcode update, then kexec into the real kernel.
neogodless 10y ago
I don't know if this bug affects Phenom II chips, but I've been running a Phenom II for 8 straight years in my primary desktop with nary a hiccup. Rock solid reliable. Guess I haven't been running the "correct conditions" for a crash?
- rincebrain 10y ago
  You could also have a BIOS update with the workaround already baked in, or a chip that has the later silicon without the bug... (I also had a Phenom II for many years without any mysterious crashing problems, even though the chip was the correct revision and there was no BIOS erratum workaround enabled.)
  - informedperson 10y ago
    Windows 7 and later distribute and activate microcode updates through Windows Update.
    - rincebrain 10y ago
      It seems like it's not a microcode update fix, but an MSR killbit flip from the BIOS? [1] [1] - http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf page 66
      - yuhong 10y ago
        Yes, which reduces performance if I remember correctly. It was quite famous. They eventually released a fixed stepping, and Phenom II is not affected.
      - informedperson 10y ago
        True, my mistake. (While it doesn't apply for this specific example, it's still the reason why one generally will see microcode-fixed errata go away rather quickly, independently of BIOS updates)
- 10y ago

It's happened to AMD before, and it was pretty bad for their brand. http://www.anandtech.com/show/2477/2 http://www.anandtech.com/show/2477/2

by zelon88 10y ago

It's happened to AMD before, and it was pretty bad for their brand. http://www.anandtech.com/show/2477/2 http://www.anandtech.com/show/2477/2

raverbashing 10y ago

Intel had serious problems as well, let's not forget: the Pentium fp bug and the F00F bug (though those are more than a decade old at this point)

msbarnett 10y ago
Haswell and early Broadwell had a bug in its transactional memory extensions so serious that the microcode "fix" simply permanently disabled the instructions. CPU errata like this aren't uncommon.
- m45t3r 10y ago
  While those are the most remembered bugs, almost every CPU have some kinda of CPU errata that can lock up the system in really weird and specific ways. For example, my Intel Ivy Bridge CPU running Linux: $ dmesg | grep -i microcode [ 0.000000] microcode: microcode updated early to revision 0x1c, date = 2015-02-26 [ 1.415548] microcode: sig=0x306a9, pf=0x10, revision=0x1c [ 1.415665] microcode: Microcode Update Driver: v2.2. The fact that most users does not hit those bugs is because modern OS already patches those microcode before execution (like the case above). Of course, if AMD can't fixes those bugs without performance regressions (remember the infamous TLB Bug from earlier Phenoms?) it can be pretty bad. However I don't think the majority of users needs to be too cautious about it.
  - yuhong 10y ago
    Some of which are quite serious: http://yuhongbao.blogspot.ca/2015/06/why-your-core-2-processor-appear-to-not.html http://yuhongbao.blogspot.ca/2015/06/why-your-core-2-process...
deleted 10y ago
[deleted]
rincebrain 10y ago
Don't forget the (other) f00f bug in the Intel Quark![1] [1] - https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug
- makomk 10y ago
  Yeah, that was kind of unfortunate as it made the Intel Quark incompatible with all normal Linux distros. I don't think it even had any kind of microcode update facility, being effectively a slightly updated 486.
  - rincebrain 10y ago
    Even with a runtime microcode update facility, no BIOS update equivalent would still make it pretty fatal for packaging except as an entirely distinct build target, because otherwise you'd need to do something kinky like always first booting a custom kernel+initrd target built to involve no locks, load the microcode update, then kexec into the real kernel.

neogodless 10y ago

I don't know if this bug affects Phenom II chips, but I've been running a Phenom II for 8 straight years in my primary desktop with nary a hiccup. Rock solid reliable. Guess I haven't been running the "correct conditions" for a crash?

rincebrain 10y ago
You could also have a BIOS update with the workaround already baked in, or a chip that has the later silicon without the bug... (I also had a Phenom II for many years without any mysterious crashing problems, even though the chip was the correct revision and there was no BIOS erratum workaround enabled.)
- informedperson 10y ago
  Windows 7 and later distribute and activate microcode updates through Windows Update.
  - rincebrain 10y ago
    It seems like it's not a microcode update fix, but an MSR killbit flip from the BIOS? [1] [1] - http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf page 66
    - yuhong 10y ago
      Yes, which reduces performance if I remember correctly. It was quite famous. They eventually released a fixed stepping, and Phenom II is not affected.
    - informedperson 10y ago
      True, my mistake. (While it doesn't apply for this specific example, it's still the reason why one generally will see microcode-fixed errata go away rather quickly, independently of BIOS updates)
10y ago