11900k + Asus z590-A Crashing

[app]

@unclewebb appreciate your opinion but still haven't updated the bios just because I am getting now 0 bsods. Need this build for my work and if the simple solution (c-state) works I am not going to change anything for now. Will notify You all if anything occurs, but after a full day of mixed work/gaming it works fine. 

[Clausewitz]

1 hour ago, ShrimpBrime said:

When overclocking, it's a pretty standard thing to do..... why save power when you want to put the hammer down.

 

It's like getting larger jets in the carburetor, but lowering the fuel pressure at the regulator. 

I mean, I understand where you're coming from but I don't agree.

The reasons are as follows:
 

1. The CPU should not BSOD with C-states enabled when using Adaptive Boost Technology
2. ABT (Adaptive Boost Technology) is an Intel sanctioned feature that does not void the warranty despite pushing the CPU frequency higher opportunistically. 
3. This is also happening to CPUs not using ABT (again an intel advertised "feature" of the 11900k).
4. Lastly, aside of slightly higher base clocks the ABT feature is really the only thing separating the 11900k and 11700k apart. It should work as advertised with the C-states.

[Clausewitz]

39 minutes ago, app said:

@unclewebb appreciate your opinion but still haven't updated the bios just because I am getting now 0 bsods. Need this build for my work and if the simple solution (c-state) works I am not going to change anything for now. Will notify You all if anything occurs, but after a full day of mixed work/gaming it works fine. 

Good decision and it's the right one. 

It's never a good idea to update your BIOS unless you are having issues. 

ASROCK and other manufacturers also state this.

This is from the Z590 Taichi BIOS update section: 
https://www.asrock.com/mb/Intel/Z590 Taichi/#BIOS

We DOT NOT recommend users to update the BIOS if their system is already running normally.

 

Contrary to what you may read on forums most engineers will not argue in favor of needless BIOS updates.

So, it is my opinion - as is the opinion of many manufacturers - to NOT update your BIOS unless your system is not working.

The BIOS updates do not correct the need to disable the C-states at this time until the new ucode is available.

[Guest]

57 minutes ago, Clausewitz said:

I mean, I understand where you're coming from but I don't agree.

The reasons are as follows:
 

1. The CPU should not BSOD with C-states enabled when using Adaptive Boost Technology
2. ABT (Adaptive Boost Technology) is an Intel sanctioned feature that does not void the warranty despite pushing the CPU frequency higher opportunistically. 
3. This is also happening to CPUs not using ABT (again an intel advertised "feature" of the 11900k).
4. Lastly, aside of slightly higher base clocks the ABT feature is really the only thing separating the 11900k and 11700k apart. It should work as advertised with the C-states.

Right I gotcha.... but, correct me if I'm mistaken here...

 

Dude's issue (from the way I had read it) wasn't until after he installed another kit of memory?? 4 dimms crashes and hangs?

[Clausewitz]

25 minutes ago, ShrimpBrime said:

Right I gotcha.... but, correct me if I'm mistaken here...

 

Dude's issue (from the way I had read it) wasn't until after he installed another kit of memory?? 4 dimms crashes and hangs?

According to the thread he's been running the two G.skill kits for a couple of months (a part of original assembly) and having issues.

In his latest post disabling C-states is correcting it.

[Guest]

1 minute ago, Clausewitz said:

According to the thread he's been running the two G.skill kits for a couple of months (a part of original assembly) and having issues.

In his latest post disabling C-states is correcting it.

He has posted gskill will rma but wants him to test the kits separately. 

 

Could be cstates. I have no doubts. Could be a picky imc. Could be both too. 

 

Check his last reply, see whatcha think!

[Clausewitz]

2 minutes ago, ShrimpBrime said:

He has posted gskill will rma but wants him to test the kits separately. 

 

Could be cstates. I have no doubts. Could be a picky imc. Could be both too. 

 

Check his last reply, see whatcha think!

Note that he writes the following:  So I also wound up putting my other memory kit back in last night just to work one thing at a time - if things are stable with the C-State disabled, then my memory probably isn't contributing to the problem. 

[Guest]

24 minutes ago, Clausewitz said:

Note that he writes the following:  So I also wound up putting my other memory kit back in last night just to work one thing at a time - if things are stable with the C-State disabled, then my memory probably isn't contributing to the problem. 

That's not with both kits installed.... which was where the issue was? 

 

Quoted:

"Regarding the memory, yes, you're totally right - I didn't buy the sticks at same time. One pair bought at Microcenter, another bought at Amazon.com a month or so later."

 

He's doing diag on two things at the same time then.

 

It's either ABT and disabled c states with both sticks, but he has removed a set.

 

Thus we are not doing a diag on one thing at a time.

 

We need both kits in now and test c-state theories. 

 

Imo.

[unclewebb]

Disabling the C states also disables full turbo boost. This prevents the 11900K from accessing the 53 and 52 multiplier. 

 

I know a lot of people have achieved stability by disabling the C states. Is the real problem that the C states are broken or is the real problem that some 11900K CPUs have cores that cannot run the 53 multiplier reliably at default voltage? Instead of disabling the C states, has anyone tried to solve this problem by blocking access to the 53 and 52 multiplier?

 

I know enthusiasts always recommend disabling the C states when overclocking. I have never had a problem enabling any C states while overclocking any Intel CPU since Core i was introduced in 2008.

 

 

  

7 hours ago, Clausewitz said:

not sure why you want to argue

Not trying to argue. Just trying to get to the root of the problem. Hopefully someone does some proper testing by disabling the 53 and 52 multiplier while leaving the C states enabled. 

 

3 hours ago, Clausewitz said:

We DOT NOT recommend users to update the BIOS if their system is already running normally.

I think you are ignoring the part at the end, "if their system is already running normally". If a CPU cannot run reliably with the C states enabled then it is not running normally. If a motherboard manufacturer has identified a problem and taken the time to release a BIOS update, it would be best to install that update. If it does not solve the problem, then you can look further.   

[Clausewitz]

2 hours ago, unclewebb said:

Disabling the C states also disables full turbo boost. This prevents the 11900K from accessing the 53 and 52 multiplier. 

 

I know a lot of people have achieved stability by disabling the C states. Is the real problem that the C states are broken or is the real problem that some 11900K CPUs have cores that cannot run the 53 multiplier reliably at default voltage? Instead of disabling the C states, has anyone tried to solve this problem by blocking access to the 53 and 52 multiplier?

 

I know enthusiasts always recommend disabling the C states when overclocking. I have never had a problem enabling any C states while overclocking any Intel CPU since Core i was introduced in 2008.

 

 

  

Not trying to argue. Just trying to get to the root of the problem. Hopefully someone does some proper testing by disabling the 53 and 52 multiplier while leaving the C states enabled. 

 

I think you are ignoring the part at the end, "if their system is already running normally". If a CPU cannot run reliably with the C states enabled then it is not running normally. If a motherboard manufacturer has identified a problem and taken the time to release a BIOS update, it would be best to install that update. If it does not solve the problem, then you can look further.   

The crashing ensues on even the latest BIOS 1007 for the board he has. In fact, updating may give him more grief related to the 0c issues that were on newer ucodes and not observed on the original ucode. 

You're also making assumptions about things that aren't correct. There are Engineering Samples from Dec of last year pertaining to the 11900k. There are 11900k qualification samples that date back to January of this year. 

You've said it "didn't exist". The CPU had to be tested internally on various motherboards long before retail. The motherboards also have a ucode/microcode testing phase and you'll be surprised to know that BIOS he has, that you think existed before the 11900k, isn't even the oldest one. it's just the oldest currently available.

Yes we have tried the 5.2 setting and it only works for some time. The issue is within the ucode pertaining to frequency shifting. The voltage is not being delivered appropriately as the CPU abruptly changes frequencies. In addition, it is observed that the motherboard is not giving the CPU enough voltage during high boost speeds. 

These issues have happened in the past on other platforms such as the release of Skylake - disabling C-states remedied it until the later ucodes were available.

The CPU is qualified to hit 5.3 and will do so with INTEL FAIL SAFE VID. 

The motherboard manufacturers are operating with their own VID conditions which are not appropriate for the Cypress Cove architecture at this point. 

INTEL FAIL SAFE VID will ignore the motherboards VID and give the processor what it wants. However, in practice, there is a balance between the INTEL VID and what the CPU actually needs to be stable. In essence, the motherboard isn't able to deliver that balance and the voltage is either too low or not able to switch fast enough. This will be fixed in future updates. 

In the Interim INTEL FAIL SAFE is pumping too much vcore for most users comfort levels.


Setting the max turbo to 5.2 seemed to fix the issue for some users. 

 

But despite that it still ended up in failure:

 

 

The CPU can handle the 5.3 frequency it just isn't getting the appropriate power delivery. There is also an error in the ucode causing C-states and C7 residency to cause crashes.  Setting 5.2 won't resolve the C-state issue and frequency changing issue.


Adaptive Boost Technology was NOT in the original launch of the 11th gen. It was a couple of days AFTER release that the press received notification of the Adaptive Boost Technology. It is a floating turbo like AMD PBO.

But here's what is happening. INTEL has specified that ABT is ONLY allowed to opportunistically raise the all core frequency to a maximum of 5.1 (which happens when you disable C-states - it remains at 5.1). It was never intended to raise the All core frequency to 5.3 Motherboard manufacturers use MCE and other "out of spec" power limit features for better benchmarks and user performance.

Think of ABT like sanctioned MCE (ASUS). Now you have MCE enabled and ABT enabled simultaneously. Two systems are now trying to push the CPU higher with the MCE allowing Intel limits to be ignored. The sensitive voltages and necessary frequency switching is ignored, other cores not rated to 5.3 begin hitting 5.3, the CPU is unstable and crashes.

The standard VID of the CPU is not being observed by the motherboard and is instead giving the CPU what it "thinks" it needs based on a V/F curve which is not fully matured yet and is wholly insufficient. This is why Intel asks for users to disable Multicore Enhancement while using ABT. Despite this, the ucode has a fault in the C-state functionality and is not appropriately working. This causes crashes WITHOUT ABT enabled AND with it enabled.

With the C-states disabled you're not losing out on any multicore speed provided by ABT (max 5.1). You're only losing out on the short 5.3 bursts in single threaded work loads.



A couple of days after Intel officially announced its 11^th Generation Core Rocket Lake, the press received an email about a new feature coming to the platform that wasn’t in our original briefing. The goal of this feature is to provide more performance to users that have good processors, and Intel is calling it Adaptive Boost Technology.
https://www.anandtech.com/show/16564/intels-new-adaptive-boost-technology-floating-turbo-comes-to-rocket-lake

 

[unclewebb]

12 hours ago, Clausewitz said:

The CPU had to be tested internally on various motherboards long before retail.

That is correct but Asus testing 10 or 100 ES or QS CPUs is not the same level of testing compared to thousands and thousands of end users running retail CPUs. It is not unusual for problems that were never noticed during development to start showing up when more people are testing and using new CPUs during real world user testing. Once Asus starts getting feedback from users, that is when new BIOS versions are released to try to fix the issues. 

 

When troubleshooting issues like this, updating to the latest BIOS is a good place to start. The Z590-E 1007 BIOS may not fix all of the instability issues but you have to start somewhere when troubleshooting. 

 

12 hours ago, Clausewitz said:

Setting the max turbo to 5.2 seemed to fix the issue for some users. 

Disabling the C states disables the 53 and 52 multiplier. That does not prove that the C states are bad. They might be bad but it sounds like the CPU cores are not getting enough voltage when some of them are trying to use the 53 and 52 multipliers.  

 

For a fair comparison you would need to limit the CPU to the 51 multiplier which is the same maximum multiplier the CPU uses when the C states are disabled. Any testing of this when using the 52 multiplier does not prove anything.   

 

13 hours ago, Clausewitz said:

There is also an error in the ucode causing C-states and C7 residency to cause crashes.

Has this been tested with the 51 multiplier or only with the 52 and 53 multipliers? Are the stability issues solved when C7 is disabled?

 

13 hours ago, Clausewitz said:

cores not rated to 5.3 begin hitting 5.3

That seems to be the main problem. The BIOS for my 10th Gen CPU shows two favored cores but when running single threaded tests, the CPU never does anything to use these cores. Tasks are assigned randomly to any core. 

 

Do the 11th Gen CPUs handle this correctly? When you run a single threaded test on an 11900K, is it being scheduled on one of the preferred cores? 

[Clausewitz]

1 hour ago, unclewebb said:

That is correct but Asus testing 10 or 100 ES or QS CPUs is not the same level of testing compared to thousands and thousands of end users running retail CPUs. It is not unusual for problems that were never noticed during development to start showing up when more people are testing and using new CPUs during real world user testing. Once Asus starts getting feedback from users, that is when new BIOS versions are released to try to fix the issues. 

 

When troubleshooting issues like this, updating to the latest BIOS is a good place to start. The Z590-E 1007 BIOS may not fix all of the instability issues but you have to start somewhere when troubleshooting. 

 

Disabling the C states disables the 53 and 52 multiplier. That does not prove that the C states are bad. They might be bad but it sounds like the CPU cores are not getting enough voltage when some of them are trying to use the 53 and 52 multipliers.  

 

For a fair comparison you would need to limit the CPU to the 51 multiplier which is the same maximum multiplier the CPU uses when the C states are disabled. Any testing of this when using the 52 multiplier does not prove anything.   

 

Has this been tested with the 51 multiplier or only with the 52 and 53 multipliers? Are the stability issues solved when C7 is disabled?

 

That seems to be the main problem. The BIOS for my 10th Gen CPU shows two favored cores but when running single threaded tests, the CPU never does anything to use these cores. Tasks are assigned randomly to any core. 

 

Do the 11th Gen CPUs handle this correctly? When you run a single threaded test on an 11900K, is it being scheduled on one of the preferred cores? 

When the CPU has the C-states enabled and is boosting at 5.1 all core the system can still crash and does crash. 

We experienced this in testing during the 6700k launch (skylake). 

https://community.intel.com/t5/Processors/Solution-asked-for-failure-C3-C6-7-states-6700K-CPU/m-p/335197/highlight/true#M9946

The C-states are most likely the issue. 

[unclewebb]

@Clausewitz Have you tested yet to see if tasks are being scheduled on the preferred cores?

 

4 hours ago, Clausewitz said:

We experienced this in testing during the 6700k launch

If you look through the Intel datasheets for various CPUs over the years, C state issues are common. 

 

If it makes you feel any better, my Z490-E and 10850K ran like crap at first. Lots of BSOD and freezes. It took a couple of months of trial and error testing and some BIOS updates to get everything sorted out. Now it is rock solid stable, even with the C states enabled. Anyone that builds a new computer, expecting it to be plug and play, might be disappointed. 

 

Hopefully a microcode update will get the 11th Gen CPUs running just as well as my 10th Gen CPU runs. 

[Clausewitz]

2 hours ago, unclewebb said:

@Clausewitz Have you tested yet to see if tasks are being scheduled on the preferred cores?

 

If you look through the Intel datasheets for various CPUs over the years, C state issues are common. 

 

If it makes you feel any better, my Z490-E and 10850K ran like crap at first. Lots of BSOD and freezes. It took a couple of months of trial and error testing and some BIOS updates to get everything sorted out. Now it is rock solid stable, even with the C states enabled. Anyone that builds a new computer, expecting it to be plug and play, might be disappointed. 

 

Hopefully a microcode update will get the 11th Gen CPUs running just as well as my 10th Gen CPU runs. 

Yeah and speaking of the 10th gen and all Skylake based architecture CPUs - they had a major flaw in them for years. It was revealed in games like APEX Legends and JAVA Minecraft. If you load instances of Java minecraft you'll see parity errors on the 10th gen on HWINFO. 

APEX legends was causing even deeper issues as it exposed the skylake-s flaws.

This is from the stickied thread on ASUS ROG forums: https://rog.asus.com/forum/showthread.php?123415-Maximus-13-and-Rocket-Lake-The-Rules-have-Changed

To get more of a clue about this error, we have to dig deeper. While many people were just pumping more vcore into their systems to try to bypass the Parity Error and the random crashes, I actually tried *lowering* the voltage even more, just to see what would happen in Apex. Sure enough, this was enough to occasionally BSOD the game, but more importantly, I was able to generate a new error alongside the parity errors:

"Translation Lookaside Buffer Error" (TLB).
"What is a TLB? In a very basic definition, a Translation lookaside-buffer (TLB) is a cache that memory management hardware uses to improve virtual address translation speed. All current desktop, laptop, and server processors include one or more TLBs in the memory management hardware, and it is nearly always present in any hardware that utilizes paged or segmented virtual memory.

By default, a TLB miss whether caused by hardware and/or software complications is not fatal (if the virtual address is not stored in the TLB, it's simply computed and found manually from other source data), but we're crashing on a TLB failure, this implies that the CPU determined there was corruption or a hardware error in date, therefore notified Windows that an unrecoverable hardware error has occurred."

What this shows is that Apex Legends is causing the CPU's to function in a very unstable way, and since some users with completely stock systems were getting Parity Errors and crashing in Apex, this was a MAJOR problem.

Respawn tried to look into this, and thanks to the programmer Oriostorm's efforts, he determined that these errors were a *flaw* in the Skylake processors. Specifically, he noticed that, due to some combination of code on the King's Canyon map, under certain rare (considering just how many instructions are processed every second!) conditions, the processor will attempt to read or write to memory it has "no permission to access". This causes an exception error (read, write or execute) and the game to naturally crash. The parity error was simply this error being caught and corrected in time. The fact that reducing vcore even more would lead to a TLB error showed that there was a very low level issue with multithreading and the ringbus happening here.

[lilypad96]

You all are forgetting it’s not just the 11 gen Intel processors. Some of us have the z590 motherboard with the 10th gen processors (10850k) and still running into the same issue…. BSOD with random codes and it began when I tried to update the drivers…. New builds are having the same issue when updating the drivers….
 

I am wondering if it’s a z590 chip problem or if a batch of the Intel chips came out defective…

 

or if somehow going back to the OG drivers would fix it (I had mine from February 2021 installed prior). The problem is it won’t even let me uninstall them. 
 

for the record I have the Intel i9 10850k batch number: X031F032. Made in Vietnam. 
 

I do not know how to distinguish the batch number on the mobo

[Rezur3kt]

I also have Z590 with 11900k. I spent roughly 30 hours without sleeping trying to fix my computer. I found a fix that doesnt involve disabling the cstate. Let me know if any of you are still having the problem. This fix was quite simple and may not work considering you all sound much more knowledgable 

[sh10151]

4 hours ago, Rezur3kt said:

I also have Z590 with 11900k. I spent roughly 30 hours without sleeping trying to fix my computer. I found a fix that doesnt involve disabling the cstate. Let me know if any of you are still having the problem. This fix was quite simple and may not work considering you all sound much more knowledgable 

I’m still having the issue and disabled C-States to combat it. You can see my post history. Would you mind sharing here or on my thread about your findings?

[Clausewitz]

4 hours ago, iransofaraway said:

I’m still having the issue and disabled C-States to combat it. You can see my post history. Would you mind sharing here or on my thread about your findings?

Just to be clear: Are you having the issue with disabled C-states or are you not having the issue when the C-states are disabled?

[Clausewitz]

9 hours ago, Rezur3kt said:

I also have Z590 with 11900k. I spent roughly 30 hours without sleeping trying to fix my computer. I found a fix that doesnt involve disabling the cstate. Let me know if any of you are still having the problem. This fix was quite simple and may not work considering you all sound much more knowledgable 

What was the fix?

[sh10151]

2 minutes ago, Clausewitz said:

Just to be clear: Are you having the issue with disabled C-states or are you not having the issue when the C-states are disabled?

I have not experienced the issue whenever I've disabled C-States. It seems to universally fix the problem for me.

[Clausewitz]

3 minutes ago, iransofaraway said:

I have not experienced the issue whenever I've disabled C-States. It seems to universally fix the problem for me.

Does your ASROCK BIOS allow you to turn off multicore enhancement? You could try using intel factory power limits with ABT and C-states enabled. MCE on is out of intel spec.

[sh10151]

10 minutes ago, Clausewitz said:

Does your ASROCK BIOS allow you to turn off multicore enhancement? You could try using intel factory power limits with ABT and C-states enabled. MCE on is out of intel spec.

I don't believe my motherboard has MCE, or if it does, it's named something else unintuitive. The Intel Adaptive Boost stuff is kind of like an Intel-sanctioned MCE, as far as I can tell. I was running with BIOS defaults, except ABT enabled - and experienced a freeze last night. Went back to disabling all C-States, turned off ABT.

[Clausewitz]

1 minute ago, iransofaraway said:

I don't believe my motherboard has MCE, or if it does, it's named something else unintuitive. The Intel Adaptive Boost stuff is kind of like an Intel-sanctioned MCE, as far as I can tell. I was running with BIOS defaults, except ABT enabled - and experienced a freeze last night. Went back to disabling all C-States, turned off ABT.

ASROCK has an MCE equivalent. Yes ABT is like MCE. However, intel has specified they only validate ABT up to the PL2 limit. Meaning, their power limits being enforced. When you have the MCE enabled (ASROCK does have this usually enabled by default), it pushes the cores higher than ABT would normally allow and is out of spec with intel validation. 

[sh10151]

Just now, Clausewitz said:

ASROCK has an MCE equivalent. Yes ABT is like MCE. However, intel has specified they only validate ABT up to the PL2 limit. Meaning, their power limits being enforced. When you have the MCE enabled (ASROCK does have this usually enabled by default), it pushes the cores higher than ABT would normally allow and is out of spec with intel validation. 

Do you know what ASRock calls it? I can post screenshots of my BIOS if that helps, but I didn't see anything alluding to that sort of enhancement. 

[Clausewitz]

2 minutes ago, iransofaraway said:

Do you know what ASRock calls it? I can post screenshots of my BIOS if that helps, but I didn't see anything alluding to that sort of enhancement. 

Look for this: OC Tweaker -> CPU Configuration -> Multi Core Enhancement