Fiery

You should check sub-3000 MHz memory frequencies as well. In case your system gets stable at e.g. DDR4-2666 setting, it means it's the RAM that has to be carefully tweaked by raising the memory frequency step by step and also adjusting memory timings if necessary. Command Rate can be adjusted in the BIOS Setup (UEFI Setup) on the page where you can manually set DRAM (memory) timings. As for CPU+FPU, that is still a scenario where both the caches and some portion of system memory is still used. The System Memory subtest allocates almost the entire available physical memory, so it can be considered a more thorough test than when you run the AIDA64 System Stability Test without that subtest enabled, but even without it AIDA64 can catch stability issues.

As long as the Commander Pro unit can monitor the thermal sensors, AIDA64 will be able to show you the readings. We cannot guarantee that a certain device will be compatible with another device. All we can assure you is that the Command Pro device is fully supported by AIDA64 as long as you don't try to use it together with Corsair's own monitoring software (iCUE) which is notorious for causing collisions on the hardware communication side.

Awesome, thank you for your help!

Please right-click on the bottom status bar of AIDA64 main window --> Video Debug --> nVIDIA GPU Registers. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. Thanks, Fiery

Thank you. It must be due to a memory leak on one of the 100+ pages that AIDA64 offers. Problem is: without knowing what exact page causes the issues, it's difficult to dig deeper into it. Please try to narrow it down and try to find the one page that causes the memory leak on your system. My guess is that it will be one of the software-related pages, so I'd start with the Computer group (in the left menu), then Operating System, then Server, Display, Multimedia, Network, DirectX, Software, Security, Config, Database. If none of them causes the memory leak, only then I'd check the hardware-focused groups: Motherboard, Storage and Devices. If you right-click on one of the mentioned page group names, you can make a quick report, so you don't have to hassle with the Report Wizard and can quickly step through all those page groups to find the culprit.

Yes, AMD did contact us to talk about this issue and find a middle ground that would satisfy all users. I'm not sure what that middle ground would eventually be, since only this week we can get a proper Matisse test system to check out the problem in details. We'll do our homework (test runs, research) and will come up with something that hopefully will be useful for you as as well as other owners of this superb CPU by AMD.

On some (but not all) systems AIDA64 reports the CMOS battery voltage as VBAT Battery voltage on the Computer / Sensor page. If it's not there, you need to try to find it in the BIOS Setup. In there it's usually shown on the PC Health Status page or H/W Monitor page. Replacing it requires a full power-down of the PC. Disconnect the power cord as well. You can remove the battery without any tools and virtually any CR2032 battery can be used as a replacement. Make sure to check the old battery though after removing it, that it's really a CR2032 part.

I think I know what you mean, so no need to hassle with making and uploading a video of the anomaly. I'm thinking about a proper way to get around this issue. The problem is that the OSD Panel is top-left anchored, so when the width changes its top-left corner stays in place and the width increases (or shrinks). It's great when you use left alignment, but can produce jerkiness when the OSD content is right-aligned. We can either let you specify a minimum width for the panel, but then you need to tweak around the find the right width to accomodate all possible text widths as the values keep changing; or make the OSD Panel top-right anchored so its width would increase and shrink on the left border of the panel. Since the latter would require less of a hassle and tweaking on your part, IMHO that should be the way to go. Let us think about it and make a few test runs before coming up with a proper fix.

Most likely WD's software kept the drives locked and other software (like AIDA64) couldn't gain proper access to them.

Try to update the motherboard BIOS to the latest version, and check if your PSU is powerful enough. Also check if it gets stable if you lower the memory frequency or if you use slightly more relaxed timings, like changing Command Rate (tCMD / tCR) from 1T to 2T.

What GPU do you have, and what version of AIDA64 are you using?

We reckon there're different methodologies to measure the core temperature of Matisse processors, and both Ryzen Master and AIDA64 are right about the temperatures. They just indicate a different value because Ryzen Master computes an average reading during a short timeframe, while AIDA64 shows the immediate reading at any given time point.

Using the FPU subtest alone is important too, since it's vital to see whether the system can work at peak power draw and highest thermal state regardless of whether it is overclocked or not. GPU subtest is a strange beast, since it uses OpenCL and so it consumes quite a few CPU cycles as well. It can also behave differently with integrated GPUs than with discrete GPUs (video cards). It's definitely worth a try to enable the GPU subtest besides all the others, but it may cause troubles when the OpenCL stack has some installation issues. So we generally wouldn't recommend using it automatically, but only with cautions. If it works fine and produces the right system load (as per your expectations), then use it.

No, it cannot filter down that way, since the sensor module is called everytime there's any sensor reading requested. I'm glad you've solved it using the EC options, that would have been my suggestion too We've seen a few Asus motherboards where polling EC registers can cause high DPC latencies.

Is it because the width of the OSD panel keeps changing? It should change with left alignment too, BTW.

The FPU subtest alone is perfect to drive the power draw and thermal state of the system to the maximum. You should run it for several hours, and then switch to a mixed workload, like CPU+FPU+Cache+RAM+Disks order to verify how the system handles a more mixed scenario.

Here's the fix for the rotation bug: https://www.aida64.com/downloads/latesta64xebeta

The new AIDA64 beta build is available for download at: https://www.aida64.com/downloads/latesta64xebeta

We've implemented a new option called Alignment on the AIDA64 / main menu / File / Preferences / Hardware Monitoring / OSD page. You'll know what to do https://www.aida64.com/downloads/latesta64xebeta

Thank you for the dump. I'm afraid we have no information on noise detection sensors, but we'll try to ask someone at Gigabyte about it. As for the fan labels, we've checked, and they should be labelled properly already. Can you please post a screenshot of the Computer / Sensor page of AIDA64 showing all measured values (incl. temperatures, fan speeds, voltages)

Does it crash if you disable Include debug information in the report in AIDA64 / main menu / File / Preferences / Report?

No need to install it.

Yes, I'm afraid AMD's PMLog API is not 100% stable

I'm not entitled to publish any of the Corsair contact emails I've got. Especially since they're proven to be great folks -- except for this single issue. So I don't want to unleash a s* storm of angry emails flying into their individual mailboxes

Does it work if you make a custom HTML report and exclude the Config / Event Logs page? Maybe that page is very long in your case?