Details of the errata from a comment in the diff: "Write both dist bytes as a single 2-byte store. This avoids the `movb %ch, [mem]` instruction pattern (store from high-byte register alias) that LLVM otherwise emits when dist arrives as a wide register. That pattern triggers the Intel Raptor Lake CPU errata, causing silent 2-byte stores that corrupt the adjacent `len` byte."
Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
31–40 of 62 posts
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#32Earlier quoted context omitted.
Intel knowingly sold defective cpus and denied the defect until reports hit critical mass. I don’t think they care.
"knowingly" is meaningless, as otherwise they wouldn't even bother releasing errata lists; it's more likely that they underestimated the severity or their planned obsolescence calculations happened to be more statistically favourable than reality. https://news.ycombinator.com/item?id=41041855
I don't think they've clarified which exact models of which serial number ranges are affected with oxidation to this day. It should've been a recall.
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#33This is why CPU designers should aim for simplicity. This is why RISC-V vector extension, which requires complicated logic, can become a source of implementation errors.
[1] https://edc.intel.com/content/www/us/en/design/products/plat...
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#34Earlier quoted context omitted.
Anyone have knowledge of whether microcode can be patched on consumer grade Intel CPUs?
https://github.com/intel/intel-linux-processor-microcode-dat... $ echo 1 > /sys/devices/system/cpu/microcode/reload Hot-swappable, even. TIL!
Just that it's writable by $ (not #) feels awkward.
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#35Earlier quoted context omitted.
Intel knowingly sold defective cpus and denied the defect until reports hit critical mass. I don’t think they care.
"knowingly" is meaningless, as otherwise they wouldn't even bother releasing errata lists; it's more likely that they underestimated the severity or their planned obsolescence calculations happened to be more statistically favourable than reality. https://news.ycombinator.com/item?id=41041855
You’re intentionally muddying the waters with meaningless philosophy. Even the law makes the difference between “knowingly” (with knowledge, intention, premeditation) and “mistake”. They didn’t knowingly break the CPU but they knowingly launched it despite their own internal findings, and knowingly blamed others when this came out.
But here you are claiming that the company must deserve the benefit of the doubt on their intent.
No, “knowingly” is most definitely not “meaningless”. And anyone who’s not naive or bad intentioned should make that difference and take note. Every time a company gets away with it because an army of philosophers washes away any guilt or plays it down with meaningless distinctions it becomes one more reason to do it again. Knowingly.
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#36I looked at the Raptor Lake errata [1] and it looks pretty scary. What if someones builds an exploit on these errors? This is why CPU designers should aim for simplicity. This is why RISC-V vector extension, which requires complicated logic, can become a source of implementation errors. [1] https://edc.intel.com/content/www/us/en/design/products/plat...
Fortunately, most of the erroneous behaviors are triggered only by very unlikely combinations of circumstances, some of which may even be impossible to happen in user programs, but only in operating system kernels.
Nevertheless, from time to time there are also serious errata, like the one discussed here, which can be triggered even by ordinary user programs. Sometimes, like here, such errata can be avoided by compilers patched to not generate the buggy instructions for the affected CPU models, assuming that it is known with certainty on which model of computer the compiled program will be executed (or using code dispatch at run time, based on the CPU model).
Simplicity in the CPU hardware may reduce the probability of hardware bugs, but it increases the probability of software bugs, because the missing hardware features must be implemented at a much greater cost in software, like in the case with the missing integer overflow detection of RISC-V, which causes most RISC-V programs to omit overflow checks, increasing the chances of undetected bugs.
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#37Linked in the Bugzilla thread is a really nice in depth investigation of the same issue with high register aliases in a similar algorithm (Huffman coding) but in an entirely different product: https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in... . It's concerning that Intel don't seem to have been responsive to anyone with respect to this issue and it doesn't appear to have an official errata yet, although…
It's very interesting because my 13900K has worked like a dream from day one and still to this day. Never had any of the voltage issues, never had any abnormal crashes in Firefox or any other software. I was undervolting it for a long while, so I wonder if somehow that saved me from the voltage issues before they were fixed?
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#38Linked in the Bugzilla thread is a really nice in depth investigation of the same issue with high register aliases in a similar algorithm (Huffman coding) but in an entirely different product: https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in... . It's concerning that Intel don't seem to have been responsive to anyone with respect to this issue and it doesn't appear to have an official errata yet, although…
It's very interesting because my 13900K has worked like a dream from day one and still to this day. Never had any of the voltage issues, never had any abnormal crashes in Firefox or any other software. I was undervolting it for a long while, so I wonder if somehow that saved me from the voltage issues before they were fixed?
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#39Also worth reading this thread on the subject: https://mas.to/@gabrielesvelto/116630047156991279 Regarding the Raptor Lake bug I received a couple of messages from confused users that had read articles on Tomshardware and Neowin. They asked about erratas and microcode updates which puzzled me, because that was part of my early investigation into the bug and we know that the failure is not caused by a known errata and…
Because it's a known problem. It's called Vmin Shift Instability issues. The affected CPUs are broken. One needs to RMA the CPUs. Intel also extended CPU warranty for 2 more years. Because there still are many broken CPUs out in the wild. Firefox works around the crash so the broken CPUs won't flood the channel with crash reports.
Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
#40Also worth reading this thread on the subject: https://mas.to/@gabrielesvelto/116630047156991279 Regarding the Raptor Lake bug I received a couple of messages from confused users that had read articles on Tomshardware and Neowin. They asked about erratas and microcode updates which puzzled me, because that was part of my early investigation into the bug and we know that the failure is not caused by a known errata and…
For example:
Does he mean all existing 13th/14th gen CPUs (prior to Intel's discovery of the vmin issue) are broken in the sense that they are susceptible to damage and can only be replaced.
OR
Does he mean that the microcode updates, applied by Intel to existing CPUs that are susceptible to damage, will only slow degradation and the CPUs will eventually fail and can only be replaced.
OR
Is he saying the 13th/14th gen CPUs which have already sustained damage, cannot be fixed by microcode updates.