©ASUSTEK COMPUTER INC. ALL RIGHTS RESERVED.

Shamino · ‎05-21-2020

Catweasel · ‎07-26-2020

I was affected by the immediate restart as well and turned off Windows fast start-up (which I didn't want anyway)

Now I observe on my ProArt Z490-CREATOR 10G with BIOS ver. 607 the following:

Whenever I do a power-on (Windows fast start-up disabled, Fast Boot in BIOS disabled) to Win 10 Pro 2004 (clean install and all drivers updated to latest available versions), one CPU core is maxed out by ACPI.sys. It will stay like this for hours. Now comes the interesting part: When I do a restart (not shutdown/power-on), this issue disappears. I can reproduce this every time, so it became a habit to restart the PC before logging into Windows after powering it up.

Do you see this as well? Any ideas?

martine-dee · ‎07-27-2020

Catweasel wrote:
Whenever I do a power-on (Windows fast start-up disabled, Fast Boot in BIOS disabled) to Win 10 Pro 2004 (clean install and all drivers updated to latest available versions), one CPU core is maxed out by ACPI.sys. It will stay like this for hours. Now comes the interesting part: When I do a restart (not shutdown/power-on), this issue disappears. I can reproduce this every time, so it became a habit to restart the PC before logging into Windows after powering it up.

This seems like something that can be solved on the system level. Whenever part of the system is behaving like that, I would first suspect the system itself.

Google for this prob, and try things. I found this one that I would try:
https://social.technet.microsoft.com/Forums/windows/en-US/4e454897-8bbf-4378-93af-965c3f4b60f2/z420-...

My query to google was: acpi.sys using a single core 100%

Keep exploring, keep innovating, keep creating

Catweasel · ‎07-27-2020

martine-dee wrote:
This seems like something that can be solved on the system level. Whenever part of the system is behaving like that, I would first suspect the system itself.

Google for this prob, and try things. I found this one that I would try:
https://social.technet.microsoft.com/Forums/windows/en-US/4e454897-8bbf-4378-93af-965c3f4b60f2/z420-...

My query to google was: acpi.sys using a single core 100%

Thanks for the reply. Yes, before posting here I spent hours searching and trying out what I found, including disabling power management and disconnecting everything except system drive, RAM, CPU and GPU, unfortunately with no success. What puzzles me is the different behaviour upon restart. From a system i.e. OS level, it shouldn't make any difference at all.

EDIT: Just found out it's enough to enter the BIOS with F2 at power-on and then exit again without changing anything. This seems to have the same effect as a restart: no high CPU on ACPI.sys. Experimented with longer POST delays, but that doesn't change a thing.

I can even boot Ubuntu from a USB drive and get the same issue:
- if it is booted from a cold system, I have one core busy with kworker /0:2-kacpi_notify
- if I restart into Ubunto via reboot, then CPU levels are back to normal

Looking at the interrupts there, I find /sys/firmware/acpi/interrupts/gpe6F to be the one causing high CPU. If I disable it within Linux, CPU returns to normal.

GemueseMonster · ‎07-29-2020

just to reiterate, not sure if this issue is known yet or not, this is the RTL/IO-L training inconsistency issue I'm seeing.

from boot to boot, with identical bios settings, sometimes RTL/IO-L of one channel drops to some sort of fallback at ~74/~14, while the other trains properly at ~62/~3 in this case. all screenshots are with identical bios settings, apart from the last with one channels IO latency offset changed from 25 to 23, to clarify that it's not a capability issue of the memory modules.

to get around that, I have to keep rebooting and checking the values in BIOS until they are proper (both channels at ~62/3, then enable MRC fast boot to "conserve" the trained values and boot into windows. needless to say this is kind of an ugly solution.

so is this expected, or a glitch in bios that Asus can fix, or a glitch in IMC microcode that Intel needs to fix?
would love to get some feedback, thank you.

bscool · ‎07-29-2020

GemueseMonster wrote:
just to reiterate, not sure if this issue is known yet or not, this is the RTL/IO-L training inconsistency issue I'm seeing.

from boot to boot, with identical bios settings, sometimes RTL/IO-L of one channel drops to some sort of fallback at ~74/~14, while the other trains properly at ~62/~3 in this case. all screenshots are with identical bios settings, apart from the last with one channels IO latency offset changed from 25 to 23, to clarify that it's not a capability issue of the memory modules.

to get around that, I have to keep rebooting and checking the values in BIOS until they are proper (both channels at ~62/3, then enable MRC fast boot to "conserve" the trained values and boot into windows. needless to say this is kind of an ugly solution.

so is this expected, or a glitch in bios that Asus can fix, or a glitch in IMC microcode that Intel needs to fix?
would love to get some feedback, thank you.

As far as I know that is normal if your pushing the memory or it is on the edge of stability. That is why many set all the timing manual so they stay set. Every Asus board I have(z390 Apex/Hero, z490 Apex) does the same when pushing the memory so I set everything manually.

To test what I am saying put the memory down to say 3600-4133(depending on board and RAM) and it will train correctly every time. I saw in another post of yours you mentioned training above 4500, that is starting to pushing things even on the Apex and will probably require manual settings if you want to ensure the timings stick after every boot.

Just because the Apex has QVL to 4800-5000 many will still be limited to much less because of RAM or the CPU IMC. On overclock.net you will see most run the Apex from 4400-4700 and these guys that have bought multiple kit of memory and some multiple CPU to bin for the best ones. https://www.overclock.net/forum/5-intel-cpus/1569364-official-intel-ddr4-24-7-memory-stability-threa...

As far as i can tell and from what I have seen from others posting RAM OCs I don't think the z490 RAM OC improved much over z390 and in some ways went backwards. I have a z390 Hero also and from what I can see it will give as good or better performance(lower latency) and clock higher(on RAM OC) than most of the new Z490 4 dimm boards. It looks like many struggle to get 4 dimm 4133 17-17-17 stable.

GemueseMonster · ‎07-29-2020

bscool wrote:
As far as I know that is normal if your pushing the memory or it is on the edge of stability. That is why many set all the timing manual so they stay set. Every Asus board I have(z390 Apex/Hero, z490 Apex) does the same when pushing the memory so I set everything manually.

To test what I am saying put the memory down to say 3600-4133(depending on board and RAM) and it will train correctly every time. I saw in another post of yours you mentioned training above 4500, that is starting to pushing things even on the Apex and will probably require manual settings if you want to ensure the timings stick after every boot.

Just because the Apex has QVL to 4800-5000 many will still be limited to much less because of RAM or the CPU IMC. On overclock.net you will see most run the Apex from 4400-4700 and these guys that have bought multiple kit of memory and some multiple CPU to bin for the best ones. https://www.overclock.net/forum/5-intel-cpus/1569364-official-intel-ddr4-24-7-memory-stability-threa...

As far as i can tell and from what I have seen from others posting RAM OCs I don't think the z490 RAM OC improved much over z390 and in some ways went backwards. I have a z390 Hero also and from what I can see it will give as good or better performance(lower latency) and clock higher(on RAM OC) than most of the new Z490 4 dimm boards. It looks like many struggle to get 4 dimm 4133 17-17-17 stable.

thank you for your input.

unfortunately when I set the values manually, and even back off by one to be safe, like 62-4 and 63-4, training does not work at all (post code 55)
so using io latency offset is the only way to get IO-L's with good performance trained at those sorts of clocks atm

also I have noticed that 4266 is some sort of cut off. below 4266 the io latency offset is applied positively, meaning lower offset = lower RTLs/IO-Ls. over 4266 the io latency offset is applied negatively, meaning lower offset = higher RTLs/IO-Ls and higher offset = lower RTLs/IO-Ls.

if I had to guess, this is some kind of historically grown duct tape approach in the IMCs microcode for supporting > 4266 that worked fine with < 8 cores, but now with increased ring length of 10 cores becomes dodgy.

an IOL difference of 1 seems to equal about 0.1ns of latency. so both channels running at default IOL 14, as opposed to properly trained 3 e.g., is a memory latency penalty of 14-3 * 2 * 0.1ns = 1.8 ns ~ 5 %.

probably not a big deal for most users, but significant enough to be addressed imho.

bscool · ‎07-29-2020

GemueseMonster wrote:
thank you for your input.

unfortunately when I set the values manually, and even back off by one to be safe, like 62-4 and 63-4, training does not work at all (post code 55)
so using io latency offset is the only way to get IO-L's with good performance trained at those sorts of clocks atm

also I have noticed that 4266 is some sort of cut off. below 4266 the io latency offset is applied positively, meaning lower offset = lower RTLs/IO-Ls. over 4266 the io latency offset is applied negatively, meaning lower offset = higher RTLs/IO-Ls and higher offset = lower RTLs/IO-Ls.

if I had to guess, this is some kind of historically grown duct tape approach in the IMCs microcode for supporting > 4266 that worked fine with < 8 cores, but now with increased ring length of 10 cores becomes dodgy.

an IOL difference of 1 seems to equal about 0.1ns of latency. so both channels running at default IOL 14, as opposed to properly trained 3 e.g., is a memory latency penalty of 14-3 * 2 * 0.1ns = 1.8 ns ~ 5 %.

probably not a big deal for most users, but significant enough to be addressed imho.

What kind of latency are you getting? I am getting and see other in 34-35ns range using Aida64 to test.

GemueseMonster · ‎07-30-2020

bscool wrote:
What kind of latency are you getting? I am getting and see other in 34-35ns range using Aida64 to test.

granted there is some run-to-run variance with aida64 memory benchmark, but this proves my point. both channels trained vs. one channel dropped to fallback IO-L 14, ~ 0.1ns latency penalty per dropped IO-L

and to clarify, exact same bios settings, just a reboot between these

bscool · ‎07-30-2020

GemueseMonster wrote:
granted there is some run-to-run variance with aida64 memory benchmark, but this proves my point. both channels trained vs. one channel dropped to fallback IO-L 14, ~ 0.1ns latency penalty per dropped IO-L

and to clarify, exact same bios settings, just a reboot between these

It seems like your memory is not stable. I can set my IO-L and all the other settings manually and they boot and work. The only time they wont is when it is on the edge of stability then they might work one boot and not another.

Have you ran any stress test or just bench marks when it does train correct?

I haven't seen anyone else posting about IO-L not working on the Z490 Apex or have you and can you post links I would like to read more about it?

Also why do you set IO offset to 25 instead of 21? I find it harder to boot 25 and if set to 21 and then set the other timings down it gives the same performance when I compared the two methods. Or is there something else it effects?

Here you can see he has IO and every thing manually and it works.

https://youtu.be/jey8x1JB6yo?t=4913

GemueseMonster · ‎07-30-2020

bscool wrote:
It seems like your memory is not stable. I can set my IO-L and all the other settings manually and they boot and work. The only time they wont is when it is on the edge of stability then they might work one boot and not another.

Have you ran any stress test or just bench marks when it does train correct?

I haven't seen anyone else posting about IO-L not working on the Z490 Apex or have you and can you post links I would like to read more about it?

Also why do you set IO offset to 25 instead of 21? I find it harder to boot 25 and if set to 21 and then set the other timings down it gives the same performance when I compared the two methods. Or is there something else it effects?

Here you can see he has IO and every thing manually and it works.

https://youtu.be/jey8x1JB6yo?t=4913

it's not instability. I can lower clock by 300 MHz and behavior is still the same. I have also tried different memory kits and different cpus, so my board is defective?

Why offset 25? Because it results in IOLs/RTLs 4 lower than 21... What "other timings" do you mean that give you the same performance?

He's entering 7 in the video. So are IOLs lower than 7 not supported on the apex? I dont get it.

Asus Z490 stuff