Others have reported success.. It could be the newer bios is interacting badly somehow. I grabbed the latest from ASUS and started there, but I haven't yet tried older versions.
Others have reported success.. It could be the newer bios is interacting badly somehow. I grabbed the latest from ASUS and started there, but I haven't yet tried older versions.Ah, bummer, I misunderstood then. If I should mess with it and get something working, I'll definitely report. But, sounds like it may just be a no-go.
I then tried all the V3x2_xxx.efi I could find in this thread (including _cp, _cup, _vup32, _cup27, cp27, cp39, and the 50/vcc versions as well)
Thanks for reacting but I read you have a X99 MSI, a different mobo.Your CPU is more expensive, than mine, yet you have only 3.2 GHz (I have stable 3.0 with 3.5 for up to 10 cores with balanced power plan, 2.7 under very heavy AVX2). Seems to be motherboard restriction, really... Right now using new EFI driver with -50 mV, uCode 039 through VMWare, i believe this is the best combination for my MSI X99A Raider (but no uCode may give you better results, or you can use this version with built-in 039 uCode). Pinned GPU driver restart bug - MSI Afterburner somehow forgot +24 mV setting, so now i'm 100% stable.
update to the update to the update... This is definitely an improvement to the old V3x1...
Yeah, I'll have to figure out where best to put them, but happy to share.Any chance you can link/upload the BIOS and EFI you used for this? I'd love to give this a try, looks amazing!
ok, update to the update (2696v3 + Z10PE-D16-WS)
V3x2_50_39_vcc.efi works!
Removed linux initrd - so relying entirely on the .efi to load the uCode (0x39) which appears to work just fine:
[ 1.677287] microcode: CPU0 sig=0x306f2, pf=0x1, revision=0x39
[ 1.677293] microcode: CPU1 sig=0x306f2, pf=0x1, revision=0x39
Curiously:
- still getting the 50/50 mix of clocks, but now its 3.3 and 3.4 vs 3.2 and 3.3 (w/0x38 and prior .efi).
I see this same pattern (as before) - it looks as if 1/2 the cores (or 1/2 the threads?) are running 100MHz higher
....
cpu MHz : 3299.960
cpu MHz : 3299.960
cpu MHz : 3399.957
cpu MHz : 3399.957
....p.s. temps are lower:
59C peak (w/50 mv vcc and 0x39) vs 63C peak before under stressapp -W
Sorry, I think that statement might confuse more than it helps...How did you remove the linux initrd? Was this necessary?
Can somebody send the 'v3x2_50_39_vcc.efi' modded bios for the asrock x99 taichi please?
I couldn't even open ubu as described on page 9 because of the missing mmtool.
randir, thank you, both EFIs give plus x1 improvement!
Results:
0x39 microcode: x34 (instead of x33) in non-AVX applications and x29 (instead of x28) in AVX applications
By the way, this version causes HWInfo's core multiplier bars to be slow in response. No microcode version doesn't have this issue. Weird, huh?
No microcode: x34 both in non-AVX and AVX applications
No stability issues experienced, however I tested Prime95's Torture test only briefly, for obvious reasons
But why does it say Error at startup?
I got kernel panic / oops for the undervolted efi. I am trying the efi mentioned in the quote.Maybe because of I set uncore to max in it, not sure.
Have you tried Throttlestop? If it also doesn't work - you're stuck with experimenting with different BIOS options, as those msrs are completely undocumented by Intel.
Too much undervolt for your silicon) Here's a version without vcore adjustments - https://ufile.io/oxr6j. BTW, this hack sticks pretty hard, so, once you've run this without "vccin error", you'll get it's effect until a hard reset (but not all other adjustments - they're cleared on soft reset). As a side effect, 2nd load of this after soft reset yields "vccin error" - but this just mean that is still present.
I was going to start a github project for future modifications - can I use your sources as a base? I've asked you in this thread ~2 weeks ago, but since you didn't answer then - I was too lazy to make a complete rewrite before publishing)
Sorry, I think that statement might confuse more than it helps...
Let me clarify that I had previously modified initrd to include a ucode update so that I could control what ucode was ultimately loaded AFTER and completely separate from the .efi driver.
By default initrd will not do this and no it is not required. Without it you will either get:
1. The ucode version loads by the .efi driver IF you use one those that includes a ucode
OR
2. The ucode update performed by the kernel which will bring the ucode to whatever version your distro includes at the moment.
An oddity I've noticed though, is after putting the system to sleep, and then waking back up, I seem to be back to the default turbo limits. Honestly, none of this is a huge deal for me, more for fun that anything... but wondering if anyone else has seen that?
the cpu may hit TJ max, so the frequency will be lower.I got kernel panic / oops for the undervolted efi. I am trying the efi mentioned in the quote.
I just registered to say this: if you are using this efi, try to avoid avx2 applications like mprime. This got my 2683 to 89C in few minutes. I am using Hyper 212x.
I haven't tried. It's pretty unfortunate, that lime is dragging their feet on that given the reality of devices starting to require EFI to function as boot devices (NVMe for example). The request for support there seems to go back to at least 2014 with the response being, "don't need it", but even during late 2016, I'm still finding that response.Might be dumb Qs but since people have to use UEFI boot to load the code,
1) anyone loading Vmware VSphere and then virtual machines (like Windows) successfully?
2) anyone chain-loading something like ReFit or Clover?
Reason for asking is I use unRAID which boots a USB stick MBR only - don't see how I can get this to work with my unRAID setup.