Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

phabricator.services.mozilla.com

Post reply on HN
Print view View original

11–20 of 62 posts

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#11

Post by userbinator »

whadawha wrote: post #7
Polizeiposaune wrote: post #2

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."

How did this get past validation at Intel? This is worse than https://en.wikipedia.org/wiki/Pentium_FDIV_bug

"validation? what validation?"

https://news.ycombinator.com/item?id=27244941

Edit: you should probably read the article I linked first.

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#12

Post by whadawha »

dmitrygr wrote: post #5
Polizeiposaune wrote: post #2

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."

modifying source to avoid an assembly isntr isn't a fix... this need a compiler fix most likely, or a microcode fix, if possible.

Anyone have knowledge of whether microcode can be patched on consumer grade Intel CPUs?

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#13

Post by bri3d »

whadawha wrote: post #12
dmitrygr wrote: post #5

Earlier quoted context omitted.

modifying source to avoid an assembly isntr isn't a fix... this need a compiler fix most likely, or a microcode fix, if possible.

Anyone have knowledge of whether microcode can be patched on consumer grade Intel CPUs?

Yes? It is regularly; both the firmware or the OS can deliver updates depending on configuration. The Raptor Lake CPUs in question have gone through an enormous number of microcode revisions already due to quite famous voltage scaling issues; it's unclear if this errata is fallout from or related to a similar root cause or just another issue with the processor.

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#14

Post by hsbauauvhabzb »

userbinator wrote: post #8

WTF, Intel? This is reminding me of a very similar bug from 9 years ago: https://news.ycombinator.com/item?id=14630183 Clearly Intel needs to do far more extensive regression-testing, with things like demoscene productions --- especially the extremely size-optimised ones that can exercise the edge-cases much better than the usual "compiler slop".

Intel knowingly sold defective cpus and denied the defect until reports hit critical mass. I don’t think they care.

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#15

Post by [deleted] »

bri3d wrote: post #6

Linked 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…

[deleted]

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#16

Post by userbinator »

hsbauauvhabzb wrote: post #14
userbinator wrote: post #8

WTF, Intel? This is reminding me of a very similar bug from 9 years ago: https://news.ycombinator.com/item?id=14630183 Clearly Intel needs to do far more extensive regression-testing, with things like demoscene productions --- especially the extremely size-optimised ones that can exercise the edge-cases much better than the usual "compiler slop".

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

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#17

Post by robin_reala »

Also 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 microcode updates cannot fix broken CPUs. So why did they ask? As it turns out it was slop. Both articles are 100% slop full of confusing and inaccurate claims.

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#18

Post by altairprime »

whadawha wrote: post #12
dmitrygr wrote: post #5

Earlier quoted context omitted.

modifying source to avoid an assembly isntr isn't a fix... this need a compiler fix most likely, or a microcode fix, if possible.

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!

Re: Bug 1950764: Work Around Crash on Intel Raptor Lake CPU

#20

Post by hsbauauvhabzb »

userbinator wrote: post #16
hsbauauvhabzb wrote: post #14

Earlier 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

The link you provided doesn’t match your comment, one of the comments in that thread points out that Intel blamed motherboards during the early stages.
Post reply on HN