Intel Raptor Lake voltage problem

I think you should post your source for where Intel said the microcode changed the temperature readout. And then I think you should post where you're getting your information about how microcode updates work.
Ugh, so I went through about a hundred documents when this story first broke, and I swear I found something about the eTVB bug including a misreport of a thermal junction temperature which permitted the overvoltage. I can't find it now, at least partially because "intel" "eTVB" "temp" search terms in Google come up with about one hojillion hits versus what it came up with two months ago. Bleh. I wish I would've just posted the link. So, for now, I suppose take it with a grain of salt? I'll keep looking.

The firmware / microcode thing is old BIOS workstation admin knowledge. Intel CPU microcode goes hand-in-hand with the Intel Management Engine firmware. If you've got Windows and a modern-ish Intel processor, you'll find the Intel Management Engine drivers are what expose the microcode update path in Windows -- Microsoft's own driver repository provides the IME drivers to make life easier, but you can trace it via the provided INF file. The IME firmware is disconnected from the BIOS in a general sense, however it can all be bundled together in the same flash file to simplify an end-user's life. If you've ever done firmware upgrades OTA via Windows, you've probably dealt with the discrete update modules of the IME and the CPU microcode.

All that to say, in my experience the motherboard firmware can usually be rolled back (modern boards are better at this than older ones) however this doesn't automagically always roll back the IME firmware, which is also linked to the CPU microcode. The overall behavior would be unique to the manufacturer of the BIOS update tool; Intel provides mechanisms to do this work as I mentioned in my prior post. If whoever wrote the BIOS upgrade (downgrade...) utility wanted to, there's no reason they couldn't write the additional logic to roll back multiple firmware images in a single command.
 
I'm pretty confident there's no such temperature readout issue, as you and this thread is the only place I've heard it or can find through google.

In regards to the microcode update, my understanding is that it's something that's applied on each and every startup of the system. There's no nonvolatile store for it on the CPU itself; it's just a bank of SRAM that gets populated. As such I'm squeamish of even using the term "downgrade", as it implies something on the CPU is being changed in a persistent way. Maybe there'd be some potential issue with compatibility between the microcode version, the ME, and the OS; but I don't see any evidence of that in this case where we're talking about jumping between 0x123, 0x125, 0x129, 0x12B all released in the span of a handful of months (the ME firmware version hasn't changed across those BIOS+ucode releases, at least for MSI.)

 
Last edited:
At this point, we know those microcode versions are all interoperable on the same CPU sets anyway, so I wouldn't forsee any specific problems with upgrading and downgrading. We also know the various microcode versions aren't cumulative, so skipping straight to the 0x12B means you'll get all four fixes.

I know every CPU has a Microcode ROM component which can never be updated; I believe newer versions of microcode updates are stored in a sort of EEPROM state however I know there are versions (I was under the impression these are older CPUs) which had a RAM region for storing microcode patches, which were refreshed as you describe. Here's a cool paper that briefly touches on the microcode patching via patch ram embedded into the CPU here: https://misc0110.net/files/cpu_woot23.pdf Most of the paper is actually about reverse engineering Intel microcode and microcode patches for Intel Goldmont (Atom processors built circa 2016.)
 
No, the CPU is not being flashed. It's loading a config file on startup. The motherboard in this case is what's being flashed to store the new config file.
 
I could go in the back and flash a CPU right now. I'd have to turn off the cameras so nobody reports me to HR but I could do it. It would take a while though since these pants have double buttons.
 
I could go in the back and flash a CPU right now. I'd have to turn off the cameras so nobody reports me to HR but I could do it. It would take a while though since these pants have double buttons.

Removing the heatsink and thermal paste could take a while too, right?
 
finally my board MSI MEG Z790 ACE has got the bios with the 12B microcode, hope this is the end of the saga and my cpu (which i started using in october last year) is fine now for years and years
 
finally my board MSI MEG Z790 ACE has got the bios with the 12B microcode, hope this is the end of the saga and my cpu (which i started using in october last year) is fine now for years and years
My board (Z790 UD AC) still hasn't gotten it. They were quick with the other ones.

Intel is saying this is the actual fix so I will update to it once it's available. I want my CPU to last a long time. My brother still uses my old 3770K and it runs most games he plays fine.
 
It's going to take months before we can say with any confidence that the issue has been addressed. For now we're basically just taking on faith that Intel is both honest and competent with their diagnosis and fix, which is dubious given everything that's happened. Statistics from third-parties are what brought this issue to light, so statistics are going to be what's needed to put it to bed. And either way: in terms of power, voltages and clock speeds we're kind of in uncharted territory in terms of what kind of longevity we can reasonably expect to have. I wouldn't have dreamt about running any CPU in the past two decades at >1.4v and >80C, and yet that's what the out-of-box settings are delivering for these chips.

The only thing that really gives me some comfort here is maybe if I do encounter stability issues in the years ahead I might be able to get away with reducing clocks and fiddling with the voltage and not be looking at a completely bricked system. Maybe the system won't be able to boost to 5.x anymore, but if it's able to handle 4.x reliably that'll still be plenty to use for a NAS, web server, media PC, a nephew's hand-me-down rig or whatever old systems get used for.
 
Last edited:
It's going to take months before we can say with any confidence that the issue has been addressed. For now we're basically just taking on faith that Intel is both honest and competent with their diagnosis and fix, which is dubious given everything that's happened. Statistics from third-parties are what brought this issue to light, so statistics are going to be what's needed to put it to bed. And either way: in terms of power, voltages and clock speeds we're kind of in uncharted territory in terms of what kind of longevity we can reasonably expect to have. I wouldn't have dreamt about running any CPU in the past two decades at >1.4v and >80C, and yet that's what the out-of-box settings are delivering for these chips.

The only thing that really gives me some comfort here is maybe if I do encounter stability issues in the years ahead I might be able to get away with reducing clocks and fiddling with the voltage and not be looking at a completely bricked system. Maybe the system won't be able to boost to 5.x anymore, but if it's able to handle 4.x reliably that'll still be plenty to use for a NAS, web server, media PC, a nephew's hand-me-down rig or whatever old systems get used for.
I wouldn't put a funky CPU in a NAS or any kind of server that is of any importance. Media PC is good though.
 
I've updated to the newest BIOS and entered all my settings again. Question. The new microcode applies even if you don't use "Intel Default" settings right? Pretty sure the microcode is entirely decided by the BIOS version but I wanna make sure.
 
Back
Top