Fiery

Thank you for your help. I've just sent you a private message about this.

Thank you for the info. Then maybe some other SMBus addresses cause the issue, but it's not easy to debug that remotely. Would it be okay with you if we made a special debug build of AIDA64 that would let us find out exactly at which SMBus address does the Discovery board crash?

I'm not sure how could replacing the PSU make the onboard sensor chip to report incorrect values. Quite frankly, I've never heard of such issue. The sensor chip used on your motherboard is Nuvoton NCT6776F. The base voltage (voltage resolution) of the sensor chip is 0.008V, but AFAIK that has nothing to do with the temperature measurement module of the sensor chip.

Thank you guys for the info. The BitDefender bit is quite interesting. What version of BitDefender are you using? Is it the BitDefender Antivirus, Internet Security or Total Security variant? BTW, since AIDA64 doesn't poll anti-virus software or virus database constantly, the only thing I can think of is that maybe the firewall module of BitDefender somehow collides with either the network traffic measurement layer of AIDA64, or with the external IP address detection part of AIDA64. Do you have any of those items enabled on your SensorPanel, Logitech LCD or OSD Panel?

Your motherboard sensor chip (Nuvoton NCT6776F) seems to have 2 temperature inputs utilized, labelled as Motherboard and CPU by AIDA64 on its Sensor page. Both temperature inputs indicate a very high temperature reading which I assume would be incorrect. That however is not the fault of AIDA64 or any software, but an issue with the sensor chip that is integrated on your motherboard. What you can do is try updating the BIOS, but I don't think it would help. You can also ask ASRock Support about this, maybe they know of a workaround or resolution. If none of those work out, then you can simply just ignore those 2 temperature readings and rely on the processor's own temperature diode readings which seem to be a lot more accurate in your system. Regards, Fiery

Exactly under what circumstances did you get those messages? Did you connect via Remote Control? If yes, then what did you do when you had those error messages come up? Do you use AIDA64 v4.20? (latest version)

Here's the new AIDA64 Extreme beta update: http://www.aida64.com/downloads/aida64extremebuild2833czvd4jfw8yzip Let me know if it works better than the previous one

It is not related to the fact that you're using a trial version of AIDA64. It only means your computer is not 100% stable. You need to tweak your overclock settings, or return back to factory settings to make your system stable again. Regards, Fiery

The next beta with the mentioned fix will be rolled out later this week. We're targeting today or tomorrow right now, but it's not 100% yet

Those options, except for #2, are not really relevant in your case. Your issue comes from the fact that the Discovery motherboard raises issues when an application scans for SMBus devices in the device range of 0x28..0x2F. In the next AIDA64 beta we'll disable the rest of the SMBus-based sensor device scans, and hopefully that will enable you to re-enable the SMBus stability option.

Thank you for the feedback

It's normal, since integrated video on the AIDA64 CPUID Panel refers to a chipset-integrated or CPU-integrated video controller. Your Volari is integrated on the motherboard, and it works independently from the motherboard chipset and the CPU. Regards, Fiery

Make sure to configure a different port for each remote feature of AIDA64. You cannot use the same port on all features.

Different WAN address is not a problem, it should work fine in your scenario as long as the port forwarding is properly configured, and the remote computer has its firewall port open.

We'll disable detecting the rest of the SMBus sensors on the AMD Discovery platform. Maybe that will help you to let you re-enable the SMBus stability option.

Please verify if both the local computer and the remote computer has the same TCP/IP port configured for remote control in AIDA64 Preferences. Also verify that the remote computer has accepting incoming connections enabled via e.g. /ACCEPT or /ACCEPTBG command-line option, or via AIDA64 / main menu / Remote / Accept Incoming Remote Connections. Regards, Fiery

Thank you, the +12V reading will be fixed in the next AIDA64 beta release due next week.

Thank you

Then please try to disable the following options in AIDA64 / main menu / File / Preferences / Stability: Apple SMC sensor support Asus ATKEX sensor support Dell SMI sensor support HID UPS sensor support Koolance TMS-200 sensor support T-Balancer sensor support DIMM thermal sensor support Toshiba TVALZ sensor support Please let me know if it helps.

We have currently no plans about any kind of video benchmarks. Regards, Fiery

Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild2827jfg9rmvxdwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps. Thanks, Fiery

Thank you for the data. Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild2827jfg9rmvxdwzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps.

Thank you, we've added the 2 mentioned lines to the AIDA64 language modules. Regards, Fiery

It all depends on the logical processor ordering of your operating system. On Vista and later Windowses ordering goes as: Core #1 / HTT Unit #1 Core #1 / HTT Unit #2 Core #2 / HTT Unit #1 Core #2 / HTT Unit #2 ... etc. So to select Core #1 and Core #4, you would have to use a binary bit mask of 01000001 which is hex 41. Regards, Fiery

No problem about the time. We definitely want to find this issue and implement a fix or a workaround to get around it. I've just sent you a private message about this.