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

21–30 of 62 posts

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

#21

Post by __patchbit__ »

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?

At boot time, the following package provides the latest Intel CPU microcode data files on NetBSD.

  sysutils/intel-microcode-netbsd
dmesg shows

  cpu 0: ucode 0xf0->0xf6
  cpu 1: ucode 0xf0->0xf6

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

#22

Post by mtlmtlmtlmtl »

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?

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

#24

Post by fuhsnn »

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…

> The sad vicious cycle of compilers not exercising the hardware

There could theoretically be instruction selection passes that are biased toward rare instructions, specialized for fuzzing hardware, I'm surprised Intel doesn't already do that.

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

#25

Post by progval »

charcircuit wrote: post #19

Hopefully this bug is getting handled upstream in a microcode update or a compiler fix to avoid emitting such instructions. Just a comment mentioning that you should not emit a particular instruction is not a strong guarantee.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1950764#c23 , it is not getting fixed.

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

#26

Post by m132 »

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…

Read the Oodle article in full, fantastic investigation indeed!

It also looks like there's a slight difference in the unwanted effect both companies have reported, despite the bug being seemingly triggered the same way (mov touching the high byte):

- Oodle reports that a low byte is occasionally stored in the intended location.

- Mozilla's fix suggests that a full 16-bit value is stored instead, corrupting an adjacent variable! This could have much more serious consequences.

Technically, this could still be the same exact bug. I found no mention of the order the output buffer was accessed in by the Huffman decoder debugged in the Oodle report, and, since it was a contiguous buffer, it's easy to mistake an occasional out-of-bounds copy there for a copy from a wrong location. But if both analyses are correct, the behavior of high byte accesses on Raptor Lake is way less predictable than those fixes suggest. Haven't managed to find an official erratum from Intel.

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

#27

Post by websg-x »

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…

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

#28

Post by throwaway2037 »

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?

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.

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

#29

Post by varispeed »

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.

[flagged]

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

#30

Post by whizzter »

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?

I remember Puget systems pointed to this same thing when they analyzed the issues back in the day when it was blowing up.

https://www.pugetsystems.com/blog/2024/08/02/puget-systems-p...

Post reply on HN