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

▲ moffkalast 3 minutes ago | parent | next [-]

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.

▲ whadawha 6 hours ago | parent | prev | next [-]

How did this get past validation at Intel?

This is worse than https://en.wikipedia.org/wiki/Pentium_FDIV_bug

	▲	bri3d 6 hours ago \| parent \| next [-]
		There's another blog post going into more depth about the issue here: https://fgiesen.wordpress.com/2025/05/21/oodle-2-9-14-and-in... where they speculate that it seems to relate to both other clock-related instability on specific Raptor Lake parts and possibly the overarching voltage control problems that the platform had early on; I can't tell entirely from the bug reports whether the behavior reliably reproduces on 100% of Raptor Lakes but the indicators I'm reading point to that it doesn't. It is concerning that Intel didn't get back to Mozilla about it though, since it's certainly a lot more than a one off.
	▲	userbinator 6 hours ago \| parent \| prev [-]
		"validation? what validation?" https://news.ycombinator.com/item?id=27244941 Edit: you should probably read the article I linked first.

▲ dmitrygr 6 hours ago | parent | prev [-]

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

▲ whadawha 6 hours ago | parent [-]

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

▲ __patchbit__ 4 hours ago | parent | next [-]

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

▲ altairprime 5 hours ago | parent | prev | next [-]

https://github.com/intel/intel-linux-processor-microcode-dat...

  $ echo 1 > /sys/devices/system/cpu/microcode/reload

Hot-swappable, even. TIL!

▲ throwaway2037 an hour ago | parent | prev | next [-]

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.

	▲	varispeed an hour ago \| parent [-]
		Classic HN elitism. Oh this peasant doesn't know the basics and dares to ask question that I deem stupid? DOWNVOTE

▲ bri3d 6 hours ago | parent | prev [-]

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.