How did this get past validation at Intel?
replyThis is worse than https://en.wikipedia.org/wiki/Pentium_FDIV_bug
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.
replyWell, the FDIV bug is simpler. AFAICT this whole thing is tied up in the relationship between DVFS, silicon aging, and being able to have guarantees about clock reliability. That seems hard to reason about when you give BIOS vendors and users the ability to do over-volting/over-clocking (and of course, it's worse when you are maybe relying on all this in certain situations to try and approach parity with other hardware vendors who are taping out machines on CMOS processes that are more mature than yours).
reply"validation? what validation?"
replyhttps://news.ycombinator.com/item?id=27244941
Edit: you should probably read the article I linked first.
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.
replyIt's the Alder Lake MAX. Originally decent design just pushed too far.
replymodifying source to avoid an assembly isntr isn't a fix... this need a compiler fix most likely, or a microcode fix, if possible.
replyAnyone have knowledge of whether microcode can be patched on consumer grade Intel CPUs?
replyYes? 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.
replyhttps://github.com/intel/intel-linux-processor-microcode-dat...
reply $ echo 1 > /sys/devices/system/cpu/microcode/reload
of course, it's hot-swap material, the microcode is 1st deployed by the bios, then the OS can apply changes as well.
replyJust that it's writable by $ (not #) feels awkward.
At boot time, the following package provides the latest Intel CPU microcode data files on NetBSD.
reply sysutils/intel-microcode-netbsd
cpu 0: ucode 0xf0->0xf6
cpu 1: ucode 0xf0->0xf6Why is this downvoted? (At the time of writing, the text is grey, so it has at least a few downvotes.)
replyThis 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.
replyThe 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.
[flagged]
replyIt’s not elitism, it’s just self defense. Every forum starts out with high–value high–signal low–noise conversations and gradually decays towards low–signal high–noise conversations as new people are brought in. The new people are, by definition, new. They don’t know much if anything yet so they cannot participate meaningfully in advanced topics. Naturally they ask questions in order to fill in the gaps in their knowledge. It is simply unfortunate that the effect is to increase the amount of noise in the forum as each new member asks the same questions over and over again. This leads to the most knowledgeable members of the forum dropping out, as the quality of the discussion drops below the point where it is worth their time.
replySee also “Eternal September”.