The fact that some program tells you that there is no performance loss doesn't mean anything, really. The only way to determine whether or not there is a performance loss is to run real benchmarks before and after the updates. All of the Spectre/Meltdown-related updates aren't going to make your PC faster, that's for sure.

Oh, and there's no need to use any third-party programs (which may or may not be accurate) for testing - there is an official PowerShell module for this:
https://support.microsoft.com/en-us/help...nerabilities-in

@thecrowler
If you did the manual update, then UBU placed the single mcode .bin file you selected into the first offset slot. This is what I had to do also, as my BIOS insisted on reading the mcode in slot #1 after this mcode update. Previously, my BIOS read the correct slot for my CPU. So the auto update (option "1" in UBU) placed the Ivy Bridge mcode in slot #1 which causes endless boot loops for my Sandy Bridge system. Even though the other mcodes are now gone, there's no real loss because we can only use one mcode at a time anyway. It looks like your system is checking out on InSpectre, so I'd say you did the update "correctly".

@Nemo1985
The way I'm reading that output, is that UBU is correcting the _FIT_ address offsets, which is the fix introduced in 1.69.16. Note that my 6-series motherboard doesn't implement _FIT_ , so I can't speak from direct experience. From your motherboard spec, you have a dual BIOS - so in the worst case scenario, you should be able to recover from that. Just familiarize yourself with the procedure before you flash your BIOS; for example, on my Gigabyte BIOS it was a combination of pressing the power and reset buttons for 10 sec., after which the backup BIOS kicked in. I used it to recover when using the standard option "1" in UBU to update my mcodes resulted in endless boot loops after flashing. I brought back the backup BIOS, updated the newer BIOS image mcode in "m" (User Select) UBU mode, then successfully flashed that to my BIOS.

@hancor
I'm reading your mcode list as two duplicates - usually multiple entries will either differ in the CPUID (so a single board can support multiple CPU types) or their revision #. It's odd, but in your case it appears you have the correct mcode (0x24 per Intel recommendations) for you processor, so that's all that matters.

@Bugger Vance
There is the powershell script, but when I tried it, it required changing permissions that I'd rather not touch. InSpectre is good and doesn't require permission changes, plus it allows the OS fixes to be enabled/disabled as the need arises, such as when the meltdown fix makes older computers so slow as to be barely usable. The developer, Steve Gibson (GRC.com), knows his stuff.

It's definitely a problem if some motherboards with support for multiple CPU types (Sandy/Ivy) will work with the modded BIOS only after you remove the microcode for one of the CPU types entirely. Especially when there's no clear reason for this to happen, according to the developer of UBU:

Zitat von SoniX im Beitrag #3763

---

Strangely, on 6-7 series there is no _FIT_ to read the microcodes for a specific offset.

---

@ygbsm
Thank you, yes my mb has dual bios I never used it but I know that there is a switch on my mb, Ill have to open the case.
This is the situation before and after the update, let's see if someone else can say if I can safely flash or not...

@Bugger Vance
Finding out there is no _FIT_ on my board was a surprise to me - I'm not sure what mechanism my BIOS used to previously select the correct mcode offset out of a long list. I agree that UBU wiping out all mcode save one or two is a bug, but I'm not sure fixing it will be worthwhile. We have to consider that these older platforms are at the end of the support cycle, and very few of them will be upgraded to a different processor than their current one. The vast majority of people will simple buy a completely new platform several generations newer when upgrading. We have also discovered a workaround with the manual update, and it works well enough since we can only use one microcode at a time anyway. It's also doubtful that this generation of processors will receive any further mcode updates. All that considered, we have to be considerate of SoniX's time and whether it is best spent fixing what can be considered an edge case. Perhaps it's a super simple fix - that's for SoniX to say. I've offered up multiple versions of my BIOS image to him if he should decide to pursue it. The remedy may realistically end up being to update the guide to recommend manual updating for these older boards.

@Nemo1985
I did a little reading, it appears that flashing the backup BIOS on your board requires setting jumpers as opposed to pressing buttons. I agree that it's reasonable for you to wait to see what information others have before taking action, especially since it looks like your new mcode have new sizes and new offsets. Even the first slot has a new offset. That would be enough to give me pause too.

#ygbsm Most likely the CPUID is the same for the board but one is for the the gaggle of 2 core cpus; while the other is for the 4 core cpus which includes a bunch of E3 version Xeons.

Performance as per Passmark ~ 96th percentile which isn't too bad for an "ancient" Asus Z87-Deluxe with i7-4770K



Cheers

Zitat von ygbsm im Beitrag #3800

---

I agree that UBU wiping out all mcode save one or two is a bug, but I'm not sure fixing it will be worthwhile.

---

Zitat von ygbsm im Beitrag #3800

---

We have to consider that these older platforms are at the end of the support cycle, and very few of them will be upgraded to a different processor than their current one. The vast majority of people will simple buy a completely new platform several generations newer when upgrading.

---

Zitat von ygbsm im Beitrag #3800

---

We have also discovered a workaround with the manual update, and it works well enough since we can only use one microcode at a time anyway.

---

Just registering to say modded MMTool 5.02.0024 worked perfectly with 1.70.a15-DEV on my P8Z77-V Pro.

Started with..
SHA1: FBA82BD83C603700E6763ED8A9C5633980822C21
and ended up with
SHA1: 8E54AC68DE355E1031527B89C0560AE1C9C8C508

@hancor
Thanks for the "twin" CPUID explanation. That's a really good Passmark score - my i5-2500k / Z68 system is only around 3700. My 2D score is very low for some reason; the only reason I've found so far is that MS introduced a patch to Windows 8 that tanked Direct2d performance and said update made its way into Windows 10. That said, this system still serves me well and I have no immediate plans to upgrade.

Zitat von Bugger Vance im Beitrag #3802

---

I wasn't talking about that. Although I'd also like to know why does UBU wipe all of the microcodes except for the ones it's updating - let's add this to my previous question.
I was talking about a chance of getting a bootloop after updating both microcodes in the BIOS with support for Sandy/Ivy. Isn't that what you were talking about in your own post? That would mean that UBU can brick a motherboard through something that is supposed to be normal operation.

---

Zitat von Bugger Vance im Beitrag #3802

---

Isn't the whole purpose of UBU is to extend the lifetime of older platforms by letting users to apply updates that weren't provided officially?

---

Zitat von Bugger Vance im Beitrag #3802

---

This is a pretty bad workaround, because it requires you to reflash the BIOS every time when you want to swap a CPU with the one from a different generation. This is not normal.

---

@ygbsm
In your BIOS, between microcode needs to be done to offset 0x800, to make it work properly.

Thx @SoniX for your info.

I checked the original cpu microcode file of my bios and noticed that between microcodes there must be a padding of 400 bytes 'FF'.

How can I create a valid microcode file with matching padding?
Thx

@mictlan
Each offset can be different, I will think
What is your motherboard and BIOS?

@SoniX
Sorry to bother you, do you think I can safely flash the bios with updated microcodes?
[Discussion] UBU Tool related Questions, Reports and Suggestions (254)

Thank you.