Intel says their 13th/14th Gen instabilities are from 'elevated operating voltages stemming from a microcode algorithm'

[leadeater]

1 minute ago, Bitter said:

My Dell laptop tries to apply the same BIOS update with Windows Updates whenever I boot into Windows. Actually kind of annoying and potentially unsafe, if I didn't understand that powering off during a BIOS update could brick the system and just pressed and held power button because I'm an impatient Karen...well..you know. Lots of impatient Karen's out there.

I think your Dell and my HP have dual BIOS or staged BIOS. I don't like it either, makes booting slow as hell when it decides to do it but I've not really seen any laptops get broken from failed BIOS updates in this way. My HP desktop does not update BIOS through Windows Update so it could be a laptop only decision by HP since laptops have batteries 

[Kisai]

1 hour ago, leadeater said:

Again just updating the BIOS is not the solution or the issue and is not what is being asked to be shown in a video.

 

That was addressing the point around Windows Update. Windows Update can deliver microcode updates but Intel has said it cannot be done for this fix. Some things can be applied through microcode patch by the  OS but this is not one of those.

 

BIOS updates done via Windows Updates is  of the level of uncommonness that we may as well exclude it from the discussion, I think my HP Laptop does but this is the exception not the standard. You aren't going to have your Asus Strix Z790 updated through Windows Update for example.

No, OEM's definitely send BIOS updates to Microsoft, but only laptops ever seem to have forced BIOS updates. Dell requires the battery to be 20% and ASUS requires a fully charged battery IIRC, which was the issue I had with the Zepheryus because I couldn't update the BIOS when the battery was dead, but I couldn't reinstall the OS without updating the BIOS.

 

Desktops also get BIOS updates, but I've only seen it for OEMS's like Dell and ASUS systems. I have never seen a third party MB updated this way.

This only downloads a zip file. How you update the BIOS on ASUS boards is by far more frustrating than say ASRock (which will get it from the internet, like Apple,) or even Gigabyte. If the file name isn't named correctly it will just say it's not a BIOS update. How hard is it to just include a tool to automatically put it in spare or a second flash space, and then reboot. These BIOS's are measured in MB's, not GB's, that adds maybe 5$ USD to do.

 

Anyway, I don't recommend updating the BIOS on desktop systems unless you have a UPS, or have a fairly reliable power source. Like don't go updating the BIOS during a rain/wind storm.

 

 

[leadeater]

22 minutes ago, Kisai said:

No, OEM's definitely send BIOS updates to Microsoft, but only laptops ever seem to have forced BIOS updates.

Yes I am aware hence saying Dell and HP do it, I know Asus did for their laptops and pre-builds but didn't expect them to also be sending the Strix motherboards etc as well. But as you mentioned it doesn't actually do it for that either so point really does stand, if you have to step in and do it then Windows Update is not updating your BIOS.

 

HP desktops don't update BIOS through Windows Update though, I know that 100%. You have to either do it manually or use the HP Support Assistant Utility software. Device firmware and drivers are updated through Windows Updates though, just not the BIOS itself.

 

Also remember this effects desktop processors not mobile/laptop, so what can or is done for laptops literally doesn't matter here.

[05032-Mendicant-Bias]

13 hours ago, starsmine said:

I don't understand the being let down part.

All the tech reviewer were dunking on Intel in multiple videos, and justly so, but without the extra step of proactively adding more useful remedial steps. Foolishly, I was expecting a more proactive approach like when GN went really into a deep dive to replicate the nvidia power connector melting issue to find the root cause or when GN did the deep dive on the exploding power supply, or like when GN did the deep dive looking at the ground plane issue that caused fire in fan hub.

 

E.g. I searched really hard what 0x123 meant, and found nothing, until intel released the 0x129 revision.

  

13 hours ago, starsmine said:

You did not lose 35% multicore performance, you lost your all core overclock.

yup. For me, I leave everything default and only apply XMP because I don't want hassles and instability, that's why for me is a performance loss. One good thing that will come out of this, is more explicit MOBO options for the baked in overclocks.

 

Luckly some reviewers enforce default specs in their benchmarks to remove the motherboard baked in overclocks, so the fix has minimal to no effect on default performance.

[porina]

6 hours ago, leadeater said:

Windows Update can deliver microcode updates but Intel has said it cannot be done for this fix.

Got a reference to that? I've not followed any further statements from Intel since the release of the "fix". In that original statement they said that microcode would not be offered through Windows Update, but I don't recall any reason given for that. Reading between the lines, it sounded like they are still investigating and might be offering further updates for whatever reason. Maybe one of those will eventually be distributed through WU.

[leadeater]

27 minutes ago, porina said:

Got a reference to that? I've not followed any further statements from Intel since the release of the "fix". In that original statement they said that microcode would not be offered through Windows Update, but I don't recall any reason given for that. Reading between the lines, it sounded like they are still investigating and might be offering further updates for whatever reason. Maybe one of those will eventually be distributed through WU.

Eh cannot and will not, doesn't change much currently but realistically this isn't an appropriate fix for OS microcode and on Intel side when talking about warranty you can't have systems that can degrade the product before OS or using one without the microcode update. If you will later only warranty CPUs that are running microcode later than [X] you can't very well get in to issues where the customer was but only after OS boot but the CPU is getting degraded by voltages above 1.55V before the OS booted.

 

Which is because OS microcode patches only apply during the booting of the OS which means that the CPU/motherboard can apply greater than 1.55V degrading the CPU before then i.e. during POST or just in BIOS screen, PXE Boot, an OS that doesn't have the fix etc.

 

I also suspect Microsoft won't validate pre-release drivers and firmware through Windows Updates and is a strict policy on that, going by how kernel mode signed drivers work for example. I don't realistically see Microsoft distributing something that not even Intel states is full release version and readiness.

 

Maybe when a final fix is released it'll get put through Windows Updates however like I mentioned it complicates warranty situation so I actually don't think it will. Newly purchased products will just come with it, old ones will live with the warranty extension and if old product later must be running the latest microcode at the time of the claim then that'll just be how it is (provable or not, I would just say yes I am for example). 

[porina]

10 minutes ago, leadeater said:

Eh cannot and will not, doesn't change much but realistically this isn't an appropriate fix for OS microcode and on Intel side when talking about warranty you can't have systems that can degrade the product before OS or using one without the microcode update.

I think you're reading far more into this than given. I accept that OS delivery of microcode wont cover all situations, but I see it as risk mitigation. If you can help most people, most of the time, you would want to do this eventually. My reading is the current "fix" is not final so they are not pushing a wider distribution than via BIOS at this point. I don't agree with your warranty theory (at least for end users of retail product) but this is getting far too deep into "what if" situations.

[leadeater]

24 minutes ago, porina said:

but I see it as risk mitigation.

I see it that way too, anything helps. But that's not necessarily what Intel wants though. I was also talking about retail customers btw, it's the most applicable here since Intel does not warranty OEM/ODM processors to end consumers. Their warranty guide specifically states that is covered by the OEM/ODM and you must contact them for all warranty claims.

 

So the only people contacting Intel for processor warranty claims are retail boxed customers and ODM/OEM customers (which don't have the 3 years retail warranty).

 

If for example you brought an HP desktop from Best Buy and they have warranty conditions that would enable them to deny your claim they will since the cost of the claim is on them the majority of the time, they can't back claim to Intel (after 1 year). So if they put out an advisory or require that you keep your system up to date with drivers and firmware and you don't read that because who does then you can be denied if they require you to supply that information during your warranty claim.

 

Intel equally has an incentive to not actually replace failed product if they don't have to. This is not applying public image in to the equation but in general you won't just get products replaced, questions are asked and they are asked to ensure it's a product fault and not a user fault.

[DutchFakeTuber]

ASUS removed the BETA flag on the BIOS update of my board (ROG STRIX Z690-A GAMING WIFI D4), and I will flash it this evening. I have not checked, but it is very likely this board is not the only one where the BETA-flag is removed.

 

I know the microcode is a standalone thing and is not dependent on the BIOS status but installing a non-BETA BIOS gives me less stress than the BETA version. I'll overclock my i5 13600K again, never had issues apart from enthusiastic overclocks 

 

Reading from the update, I'll keep the eTVB setting enabled.

Edited August 20 by DutchFakeTuber
Added text from Intel website

[Kisai]

7 hours ago, leadeater said:

Yes I am aware hence saying Dell and HP do it, I know Asus did for their laptops and pre-builds but didn't expect them to also be sending the Strix motherboards etc as well. But as you mentioned it doesn't actually do it for that either so point really does stand, if you have to step in and do it then Windows Update is not updating your BIOS.

The conditions for the OS doing the firmware update are pretty narrow, and I suspect there is a standard way to do this that all MB's must do for it to work, especially considering the ASUS boards do not come with a windows flash utility.

 

7 hours ago, leadeater said:

HP desktops don't update BIOS through Windows Update though, I know that 100%. You have to either do it manually or use the HP Support Assistant Utility software. Device firmware and drivers are updated through Windows Updates though, just not the BIOS itself.

I've never seen a HP system initiate a flash though windows, but I've seen plenty of Dell systems do it, particularly during the  spectre issue that came out during the pre 9th-gen intel parts. However I also noticed that Dell's own tools are definitely NOT used when the firmware update is pushed. So there is clearly some "standard" that OEM's are supporting otherwise they'd only be able to invoke microcode from the OS.

 

7 hours ago, leadeater said:

Also remember this effects desktop processors not mobile/laptop, so what can or is done for laptops literally doesn't matter here.

It would not surprise me if they do release firmware updates for HX parts, as HX parts are basically just the Desktop parts as a non-socketed chip. My guess, at least according to information out there is that the i9 parts, and -K SKU's were most affected since they are unlocked and whatever caused these problems is triggered by eTVB/XMP/OEM-"defaults" that aren't actually being enforced to spec.

 

 

Like on the ASUS boards, you have "Auto" which presumably tries to find the ideal settings, ignoring XMP, but seems to always power up in non-XMP mode. XMP I is an "optimized by OEM" and XMP II is a "load full XMP profile", with both XMP I and XMP II turning off a bunch of Auto settings. Yet there are further things you can tweak for the RAM and that's where the stability loss starts happening, mostly involving the GPU which makes me suspect more than just the RAM timings are in play. 

 

There there is ASPM (which is a PCIe power management feature) which destabilizes the 14th gen CPU in some strange ways, where as my 11th gen, ASPM works fine. I feel the connection here is again, the RAM timings from the OC features, but could not pin down what exactly and it's not really a feature that needs to be enabled on a desktop anyway. This I only discovered BTW from the event logs complaining about devices disappearing shortly before it BSOD's.

 

Again, if you just update the BIOS, reset to defaults and then turn XMP I/II on and then leave it, seems to be fine. It's the OC micromanagement that seems to be sitting on the edge of the knife.

 

[leadeater]

15 minutes ago, Kisai said:

The conditions for the OS doing the firmware update are pretty narrow, and I suspect there is a standard way to do this that all MB's must do for it to work, especially considering the ASUS boards do not come with a windows flash utility.

True, Microsoft probably has guidance on how to do it if you want to actually deliver it and have it installed. Personally I just think it's a bad idea for desktops and it's only mostly safe on laptops due to batteries.

 

15 minutes ago, Kisai said:

It would not surprise me if they do release firmware updates for HX parts, as HX parts are basically just the Desktop parts as a non-socketed chip.

I tend to think the reason they haven't needed to is the engineering support and also processor product restrictions Intel has for mobile parts is a lot more strict and standardized so it may well already be the case that all the mobile products have 1.55V limits in place already.

 

15 minutes ago, Kisai said:

I've never seen a HP system initiate a flash though windows

It's called HP Support Assistant like I said. You can read the BIOS update documentation for HP desktops and it's that or manual download of the exe application package that will update it or use USB and bios binary file etc.

 

Pretty sure Support Assistant just downloads the latest BIOS update exe and runs it though, so it's just a layer over top. I uninstall Support Assistant personally, just more bloated crap tbh.

[Glazarus]

The more I read, the more confused I get. I have no idea what to change after the bios update is done. Should I turn XMP on or off? I or II? 
 

So far I’ve got the notion that after the update, the only thing to touch is to turn XMP on, but then some write about XMP as if it’s bad because it overrules some settings supposed to guard the CPU from crashing. 
 

So I’m very confused as to what to do with the update. I don’t understand why all tech channels just say to update the bios, when there seems to be much more going into this than just that. As I mentioned before, it’s easy for people who are tech professionals to do this like riding a bike, but the rest of us are just staring at numbers not knowing what to actually do. 
 

The update process is pretty straight forward, but all the settings and discussions back and forth about what should be done after the update makes it hard to go through with the update confidently. 
 

Can someone just say exactly what should be done after the update? Without the extra deep dive. And if it’s still unknown what to accurately do, say that so we noobs can hold on a while longer before final answers. That would be really helpful.

[porina]

2 hours ago, leadeater said:

Intel equally has an incentive to not actually replace failed product if they don't have to. This is not applying public image in to the equation but in general you won't just get products replaced, questions are asked and they are asked to ensure it's a product fault and not a user fault.

Yes and no. A "no questions asked" policy would obviously be too relaxed. If the CPU is suspected of being at fault, there will be some steps to get there rather than assuming that ANY crash is the fault of the CPU. Maybe bad drivers. Unstable ram. Or just a random one off thing. The friction of making a claim might put off some valid claims. I've got some faulty ram that I'm not going to RMA through lifetime warranty because the value of that ram is now less than the effort it would take to go through with it. It also seems that scammers have attempted to send in remarked CPUs to try to get real ones so that's also something they have to check for.

 

Worst case:

Intel: Hey Asus, who's that company you use for RMAs? We're expecting a bunch soon so could use more capacity.

 

1 hour ago, Kisai said:

The conditions for the OS doing the firmware update are pretty narrow, and I suspect there is a standard way to do this that all MB's must do for it to work, especially considering the ASUS boards do not come with a windows flash utility

My Lenovo laptop started getting BIOS updates getting pushed through Windows, perhaps a year or so ago. I didn't want this to happen so I looked into it. Apparently on Asus mobos there is some BIOS setting you can disable to prevent these OS pushed updates from being allowed. I can't remember exactly what it was called. Unfortunately my Lenovo did not have such a setting. My only option was to disable "driver" updates in Windows which is what the BIOS updates come under, at the risk if I connect a new device I might have to do more to get it to work.

[ImorallySourcedElectrons]

On 8/15/2024 at 6:13 AM, leadeater said:

Personally I think it's more crazy we can have 150A+ thundering in to CPUs, that's a hell of a lot current.

Wait until you realise there are on-die momentary currents in the kA (and sometimes even MA) range. Folks wonder how electromigration can happen, that's how.

[starsmine]

1 hour ago, Glazarus said:

The more I read, the more confused I get. I have no idea what to change after the bios update is done. Should I turn XMP on or off? I or II? 
 

So far I’ve got the notion that after the update, the only thing to touch is to turn XMP on, but then some write about XMP as if it’s bad because it overrules some settings supposed to guard the CPU from crashing. 
 

So I’m very confused as to what to do with the update. I don’t understand why all tech channels just say to update the bios, when there seems to be much more going into this than just that. As I mentioned before, it’s easy for people who are tech professionals to do this like riding a bike, but the rest of us are just staring at numbers not knowing what to actually do. 
 

The update process is pretty straight forward, but all the settings and discussions back and forth about what should be done after the update makes it hard to go through with the update confidently. 
 

Can someone just say exactly what should be done after the update? Without the extra deep dive. And if it’s still unknown what to accurately do, say that so we noobs can hold on a while longer before final answers. That would be really helpful.

intel default with xmp on. xmp II is just used if you cant get I to run stable. 

XMP LUT on die is small, it doesnt have subtiming optimizations. thats what 1 is for, if the motherboard recognizes the die/profile, it can do better subtimings. 

the problems come in from old motherboard defaults that do not agree with intel defaults, which hopefully should get ironed out.

[leadeater]

30 minutes ago, ImorallySourcedElectrons said:

Wait until you realise there are on-die momentary currents in the kA (and sometimes even MA) range. Folks wonder how electromigration can happen, that's how.

I'm aware but I can't see or measure it so "it doesn't exist" 

 

These are all low actual power though, on the other hand I have 24x 120Ah high output power UPS batteries with a max 5 second discharge rated at 950A output wired at 76V (6S) in 4 strings ready to throw absolute minimum 288800W in to my  body if I do something dumb 

[Glazarus]

35 minutes ago, starsmine said:

intel default with xmp on. xmp II is just used if you cant get I to run stable. 

XMP LUT on die is small, it doesnt have subtiming optimizations. thats what 1 is for, if the motherboard recognizes the die/profile, it can do better subtimings. 

the problems come in from old motherboard defaults that do not agree with intel defaults, which hopefully should get ironed out.

So the consensus on the matter is intel default + XMP 1?

 

That also circumvents the issue with the motherboard defaults? I don’t have to fix that in the future if I just go with the above intel default and XMP 1?

[Mumintroll]

5 hours ago, DutchFakeTuber said:

ASUS removed the BETA flag on the BIOS update of my board (ROG STRIX Z690-A GAMING WIFI D4), and I will flash it this evening. I have not checked, but it is very likely this board is not the only one where the BETA-flag is removed.

 

I know the microcode is a standalone thing and is not dependent on the BIOS status but installing a non-BETA BIOS gives me less stress than the BETA version. I'll overclock my i5 13600K again, never had issues apart from enthusiastic overclocks 

 

Reading from the update, I'll keep the eTVB setting enabled.

 

I have an Asus Prime B760-Plus D4, and I noticed something funny.

 

I did use the beta bios 1662, which was said to include Intel microcode 0x129. It was released 9th august.

Hovewer after updating the weird thing was that the microcode revision was 34, the same I already had from bios 1661 that came with 0x125 microcode?!

 

At 15th august version 1663 was released, with the same patch notes as 1662. When I updated to this bios the microcode revision got bumped up to 35.

Looking at the files both from 1662 beta and 1663 there were created with only 1 day between them, but the 1663 was in Q&A for a week to be released as "stable".

 

So did Asus something wrong with the 1662 beta? Like forgot the new Intel microcode in it?

 

I have a mediocre i5 13400. It's one of those that use the C0 based on Alder lake. It's probably one unaffected and also not on Intel's list of cpus that recently got their warranty extended. Even if Intel's official message is still 65w and above.

[Dabombinable]

19 hours ago, Kisai said:

Laptops and desktops from OEM's (yes including ASUS and DELL) will push BIOS updates under the optional updates in Windows.

 

It will appear here, and you will always have to select it. Don't blindly install drivers from optional updates as they're usually out of date, like in this case, the Display driver is extremely old. On my mom's ASUS desktop, the BIOS update was here, for her 7th gen system, and on my ASUS 9th gen laptop it also was an optional update, but the firmware update was FORCED in order to update/reinstall windows to a newer version.

 

Just be aware that the latest BIOS will usually not be here, just whatever version the OEM submitted to Microsoft. Beta BIOS's will not appear here, and neither will BIOS updates for stand-alone motherboards.

 

Though those updates should be done with bitlocker disabled. My mum was luckily able to find the key on her old MS account after I explained what was going on.

[Kisai]

On 8/12/2024 at 11:45 PM, Kisai said:

Works fine for me, but I did get a BSOD late Sunday. This was after 9 hours of the GPU and CPU video encoders being like 80% pinned, so it's possible this was the iGPU encoder crashing. Bluescreenview doesn't point to a driver.

 

So, something seems to have happened in the last 24 hours where all chromium-based browsers tabs now crash, frequently. I have initially chalked this up to the GPU drivers, which I rolled back, but I was still getting things randomly closing, and this only started when I turned core isolation off (cause I needed to use Virtualbox 6 for something.)

 

So I've been running Corecycler for the last 5 hours:

Quote

02:09:23 - Iteration 1
════════════════════════════════════════════════════════════════════════════════
02:09:23 - Set to Core 0 (CPU 1)
           Running for 6 minutes...
           Progress 1/20 | Iteration 1/10000 | Runtime 00h 00m 16s
           Test completed in 00h 06m 00s
02:15:24 - Set to Core 10 (CPU 18)
           Running for 6 minutes...
           Progress 2/20 | Iteration 1/10000 | Runtime 00h 06m 17s
           Test completed in 00h 06m 00s
02:21:25 - Set to Core 1 (CPU 2)
           Running for 6 minutes...
           Progress 3/20 | Iteration 1/10000 | Runtime 00h 12m 18s
ERROR: 02:23:05
ERROR: There has been an error while running Prime95!
ERROR: At Core 1 (CPU 2)
ERROR MESSAGE: FATAL ERROR: Rounding was 0.4989185333, expected less than 0.4
ERROR: The error happened at FFT size 10240K
02:23:05 - Trying to restart Prime95
02:23:07 - Set to Core 11 (CPU 19)
           Running for 6 minutes...
           Progress 4/20 | Iteration 1/10000 | Runtime 00h 14m 00s
           Test completed in 00h 06m 00s
02:29:07 - Set to Core 2 (CPU 4)
           Running for 6 minutes...
           Progress 5/20 | Iteration 1/10000 | Runtime 00h 20m 00s
           Test completed in 00h 06m 00s
02:35:08 - Set to Core 12 (CPU 20)
           Running for 6 minutes...
           Progress 6/20 | Iteration 1/10000 | Runtime 00h 26m 01s
           Test completed in 00h 06m 00s
02:41:09 - Set to Core 3 (CPU 6)
           Running for 6 minutes...
           Progress 7/20 | Iteration 1/10000 | Runtime 00h 32m 02s
           Test completed in 00h 06m 00s
02:47:09 - Set to Core 13 (CPU 21)
           Running for 6 minutes...
           Progress 8/20 | Iteration 1/10000 | Runtime 00h 38m 02s
           Test completed in 00h 06m 00s
02:53:10 - Set to Core 4 (CPU 8)
           Running for 6 minutes...
           Progress 9/20 | Iteration 1/10000 | Runtime 00h 44m 03s
           Test completed in 00h 06m 02s
02:59:13 - Set to Core 14 (CPU 22)
           Running for 6 minutes...
           Progress 10/20 | Iteration 1/10000 | Runtime 00h 50m 06s
           Test completed in 00h 06m 02s
03:05:15 - Set to Core 5 (CPU 10)
           Running for 6 minutes...
           Progress 11/20 | Iteration 1/10000 | Runtime 00h 56m 08s
           Test completed in 00h 06m 00s
03:11:16 - Set to Core 15 (CPU 23)
           Running for 6 minutes...
           Progress 12/20 | Iteration 1/10000 | Runtime 01h 02m 09s
           Test completed in 00h 06m 02s
03:17:18 - Set to Core 6 (CPU 12)
           Running for 6 minutes...
           Progress 13/20 | Iteration 1/10000 | Runtime 01h 08m 12s
           Test completed in 00h 06m 00s
03:23:19 - Set to Core 16 (CPU 24)
           Running for 6 minutes...
           Progress 14/20 | Iteration 1/10000 | Runtime 01h 14m 12s
           Test completed in 00h 06m 00s
03:29:20 - Set to Core 7 (CPU 14)
           Running for 6 minutes...
           Progress 15/20 | Iteration 1/10000 | Runtime 01h 20m 13s
           Test completed in 00h 06m 00s
03:35:20 - Set to Core 17 (CPU 25)
           Running for 6 minutes...
           Progress 16/20 | Iteration 1/10000 | Runtime 01h 26m 14s
           Test completed in 00h 06m 00s
03:41:21 - Set to Core 8 (CPU 16)
           Running for 6 minutes...
           Progress 17/20 | Iteration 1/10000 | Runtime 01h 32m 14s
           Test completed in 00h 06m 02s
03:47:24 - Set to Core 18 (CPU 26)
           Running for 6 minutes...
           Progress 18/20 | Iteration 1/10000 | Runtime 01h 38m 17s
           Test completed in 00h 06m 00s
03:53:25 - Set to Core 9 (CPU 17)
           Running for 6 minutes...
           Progress 19/20 | Iteration 1/10000 | Runtime 01h 44m 18s
           Test completed in 00h 06m 02s
03:59:27 - Set to Core 19 (CPU 27)
           Running for 6 minutes...
           Progress 20/20 | Iteration 1/10000 | Runtime 01h 50m 20s
           Test completed in 00h 06m 00s

The following cores have thrown an error: 1

After that point it skips core 1 and no other errors surface. But also it's been pretty stable while running this which leads me to believe that the 0x129 microcode "fix" doesn't actually fix the problem. So I'm probably going to go into the BIOS and disable P core 1 and try this again and see if it surfaces on another core.

 

 

[05032-Mendicant-Bias]

1 hour ago, Kisai said:

So, something seems to have happened in the last 24 hours where all chromium-based browsers tabs now crash, frequently. I have initially chalked this up to the GPU drivers, which I rolled back, but I was still getting things randomly closing, and this only started when I turned core isolation off (cause I needed to use Virtualbox 6 for something.)

 

So I've been running Corecycler for the last 5 hours:

After that point it skips core 1 and no other errors surface. But also it's been pretty stable while running this which leads me to believe that the 0x129 microcode "fix" doesn't actually fix the problem. So I'm probably going to go into the BIOS and disable P core 1 and try this again and see if it surfaces on another core.

 

 

It makes sense that if the traces already suffered electro migration, there is no going back from that.

 

Have you tried the intel tool? I wonder if it detects the problem.

[Kisai]

3 hours ago, 05032-Mendicant-Bias said:

It makes sense that if the traces already suffered electro migration, there is no going back from that.

 

Have you tried the intel tool? I wonder if it detects the problem.

 

I did the default and the intel burn in and it PASS'd. so I'm like "huh, that's interest" CPU basically sat at 88C the entire time.

[Kisai]

Currently on third attempt with CoreCycler.

 

On the second attempt, Core 16

Quote

ERROR: 11:42:42
ERROR: There has been an error while running Prime95!
ERROR: At Core 16 (CPU 24)
ERROR MESSAGE: FATAL ERROR: Rounding was 0.5, expected less than 0.4

So that is not the same core as before, and Core 16 would be one of the E cores, so this doesn't even make sense.

 

I've turned XMP off and am running it again to see if this points to anything. Cause if it does, well, I'll wait for the "final" version of the bios and then probably RMA this CPU. Cause it worked fine and now it seems to be having issues where it didn't before.

[porina]

23 minutes ago, Kisai said:

I've turned XMP off and am running it again to see if this points to anything.

From your earlier post the error showed at 10240k FFT, which would normally point to a IMC/ram problem if it doesn't also happen at much smaller FFTs.

[AnonymousGuy]

On 8/20/2024 at 9:07 AM, Glazarus said:

So the consensus on the matter is intel default + XMP 1?

 

That also circumvents the issue with the motherboard defaults? I don’t have to fix that in the future if I just go with the above intel default and XMP 1?

Late, but you want xmp ii.    That runs the sticks at what they're rated for.  xmp i applies tighter timings based on asus's guess that it's still OK.  "xmp ii tweaked" appears if you run a memory kit that asus has validated and it's the xmp ii profile with tighter timings that asus found was ok with their sample.

 

0x129 bios seems to just add a menu at the top to select whether you want "Intel Default" turbo power settings or not.   The real fix is whatever was going on allowing the voltage to go out of spec....not the power limits.