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

41–50 of 62 posts

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

#41

Post by nubinetwork »

mtlmtlmtlmtl wrote: post #22
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…

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?

My 1360p and 13400 seem fine too. I applied the microcode and firmware updates when they came out... but I'm guessing it didn't affect all skus equally for whatever magical reason.

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

#42

Post by camel-cdr »

adrian_b wrote: post #36
codedokode wrote: post #33

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

All Intel, AMD or Arm-based CPUs and any other modern CPUs have dozens of errata, even if some CPU vendors keep them secret, instead of publishing them, as they should. 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 ther…

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

Since I've got a SpacemiT K3 board my self now, I though I test it again:

I compiled microjs with both tinycc and chibicc, which where both compiled for the target platform with and without -ftrapv:

    Slowdown Zen1: tinycc: 1.34%, chibicc: -0.3% (slight speedup somehow?)
    Slowdown X100: tinycc:  0.1%, chibicc:  3.4%
Last time I did full clang: https://news.ycombinator.com/item?id=47328214#47342362 And there was minimal slowdown (sometimes speedup) on x86, Arm and RISC-V. It was pointed out that llvm mostly uses size_t, however chibicc and tinycc use int as their default type, so there should be lots of overflow checking.

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

#43

Post by codedokode »

adrian_b wrote: post #36
codedokode wrote: post #33

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

All Intel, AMD or Arm-based CPUs and any other modern CPUs have dozens of errata, even if some CPU vendors keep them secret, instead of publishing them, as they should. 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 ther…

And Rust omits overflow check under the same excuse, although overflow was a reason that allowed multiple Linux kernel vulnerabilities.

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

#44

Post by websg-x »

samlinnfer wrote: post #40
robin_reala wrote: post #17

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…

Sorry it's still not clear what he means? When a CPU is "broken", is it already failing or is it "broken" in the sense it will fail? 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 susceptib…

Only the desktop 8p+16e cores(13600/700/900,14600/700/900)k are susceptible. The CPUs are safe with the fixed bios/microcode. The notebook version of 8p+16e CPUs are also safe from vmin shift since notebook computer cannot go insane with voltage.

If the CPU is damaged already, the new microcode wont fixed the problem. It broken. You have to RMA the CPU.

The vmin shift instability is fixed. There are no new report of mass failures of 13th/14th gen CPUs after the new bios/microcode release.

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

#45

Post by anonymars »

Numerlor wrote: post #38
mtlmtlmtlmtl wrote: post #22

Earlier quoted context omitted.

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?

Undervolting would definitely help, and is the actual fix. The current Intel fixes were mostly just for the symptoms, as the main issue is high voltage+power when pushing high clocks, but they can't actually fix that as it'd downgrade the advertised clocks the cpus were sold with

Sorry, but that understanding is dangerously incomplete. You're describing the first set of issues they uncovered, but there's also:

"Microcode and BIOS code requesting elevated core voltages which can cause Vmin shift especially during periods of idle and/or light activity" (emphasis mine)

https://community.intel.com/t5/Blogs/Tech-Innovation/Client/...

Recall also that "Vmin shift" means "the minimum voltage the processor needs to run correctly goes up" so if the issue isn't addressed, that level of undervolt may stop working

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

#46

Post by GoblinSlayer »

codedokode wrote: post #43
adrian_b wrote: post #36

Earlier quoted context omitted.

All Intel, AMD or Arm-based CPUs and any other modern CPUs have dozens of errata, even if some CPU vendors keep them secret, instead of publishing them, as they should. 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 ther…

And Rust omits overflow check under the same excuse, although overflow was a reason that allowed multiple Linux kernel vulnerabilities.

Buffer overflows are caught by bound checks that don't need integer overflow checks, cf dotnet.

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

#47

Post by wtallis »

throwaway2037 wrote: post #28
whadawha wrote: post #12

Earlier quoted context omitted.

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

Why is this downvoted? (At the time of writing, the text is grey, so it has at least a few downvotes.) This is a good question. As others have noted below, yes, and sometimes you can see kernel logging on start-up when the microcode is loaded.

It's a dumb question, because it's in reply to a comment that already implies the answer, and it's trivial to find an answer online in less time than it takes to post that question and wait for someone to supply an answer.

The subject of CPU microcode update mechanisms is an interesting and relevant topic, but such a shallow, low-effort question is not a good way to promote interesting discussion on that topic.

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

#48

Post by happycube »

moffkalast wrote: post #31
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."

Common Raptor Lake L, add it to the pile of oxidation and overvoltage faults. This has to be the most faulty generation in Intel's entire recent manufacturing history.

It's the Alder Lake MAX. Originally decent design just pushed too far.

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

#49

Post by cesarb »

userbinator wrote: post #10
Polizeiposaune wrote: post #4

Earlier quoted context omitted.

Use of the "h" register slices (bits 8..15) by compilers is thankfully pretty rare -- otherwise this would have been noticed much sooner! Agner Fog's optimization guide says "Any use of the high 8-bit registers AH, BH, CH, DH should be avoided because it can cause false dependences and less efficient code."

Use of the "h" register slices (bits 8..15) by compilers is thankfully pretty rare That's unfortunate, because it's precisely why things like this will keep happening. Agner Fog's optimization guide says "Any use of the high 8-bit registers AH, BH, CH, DH should be avoided because it can cause false dependences and less efficient code." The sad vicious cycle of compilers not exercising the hardware, and then the hard…

> That's unfortunate, because it's precisely why things like this will keep happening.

I have the opposite opinion. Its use being rare means CPU designers have less need to optimize for that rare case, and hardware optimizations are precisely where these kinds of issues tend to pop up.

And high 8-bit registers are a x86-specific feature, other CPU families don't have it. So that special case being less optimized (or even pessimized) is not much of a loss.

Post reply on HN