Jump to content
AIDA64 Discussion Forum

Recommended Posts

Hello,

My system:

Motherboard: Gigabyte GA-MA770T-UD3P (revision 1.1)

CPU: Phenom II X4 925, RB-C2 stepping

Memory: Kingston KVR1333D3E9SK4/16G (kit of four unbuffered ECC DDR3-1333 modules, 16 GB total, dual rank modules, each module has eighteen 256M x 8-bit FBGA)

I manually underclocked the memory to 1066 MHz in BIOS. I left the timings as SPD auto-detected values for the 1066 MHz profile.

Other values I set in the BIOS:

DCTs Mode: Ganged

DRAM ECC enable: Enabled

DRAM MCE enable: Enabled

Chip-Kill mode enable: Enabled

DRAM ECC Redirection: Enabled

DRAM background scrubber: 163.8us

L2 cache background scrubb: 1.31ms

DCache background scrubber: 5.24ms

...

...

Bank Interleaving: Enabled

Channel Interleave: Enabled

Side-note: BIOS has no option for L3 cache background scrubbing.

AIDA64 Extrene Edition 2.70.2200 prints:

[ Memory Controller ]

Memory Controller Properties:

Error Detection Method: 64-bit ECC

Error Correction: None

Supported Memory Interleave: 1-Way

Current Memory Interleave: 1-Way

Supported Memory Speeds: 70ns, 60ns

Supported Memory Types: SPM, EDO

Supported Memory Voltages: 3.3V

Maximum Memory Module Size: 1024 MB

Memory Slots: 4

...and somewhere under [ North Bridge: AMD K10 IMC ], it prints...

Error Correction:

ECC: Supported, Enabled

ChipKill ECC: Supported, Enabled

RAID: Not Supported

DRAM Scrub Rate: 163.8 us

L1 Data Cache Scrub Rate: 5.24 ms

L2 Cache Scrub Rate: 1.31 ms

L3 Cache Scrub Rate: Disabled

Because the North Bridge report section says "ECC Supported: Enabled" but the Memory Controller report section prints "Error Correction: None", I am confused. Are my modules running in ECC mode?

Another side-note...I underclocked to 1066 MHz because: with stock 1333 MHz (A) it will take several minutes just to POST in "Ganged Mode" if "Channel Interleave" is enabled and "Bank Interleaving" is disabled, and ( B ) my board won't POST in "Ganged Mode" if both "Bank Interleaving" and "Channel Interleave" is enabled. It POSTs fine at stock 1333 MHz in "Unganged Mode" with both "Bank Interleaving" and "Channel Interleave" enabled, but in that Unganged case, AIDA64 will print "ChipKill ECC: Supported, Disabled", regardless of whether I enable Chip-Kill in the BIOS.

Thanks,

Consumer

Share this post


Link to post
Share on other sites

Please check Q#10 at:

http://www.aida64.com/support/knowledge-base

In other words, you should only trust the Chipset page where AIDA64 states:

ECC: Supported, Enabled

ChipKill ECC: Supported, Enabled

As for ganged vs. unganged configuration, I guess ChipKill ECC can only be used in ganged mode. There's no huge performance difference between ganged and unganged modes, so in case you prefer data integrity/safety over negligible performance advantage, then make sure to use the ganged mode where ChipKill ECC is enabled.

Regards,

Fiery

Share this post


Link to post
Share on other sites

Hello,

Thanks for the fast reply.

Please check Q#10 at:

http://www.aida64.co.../knowledge-base

In other words, you should only trust the Chipset page where AIDA64 states:

ECC: Supported, Enabled

ChipKill ECC: Supported, Enabled

Does this mean my system is using normal single-bit ECC in both detection and correction modes, or could it mean that my ECC is working in detection-only (not correction) mode? If my ECC is working in detection-only mode, then the AIDA64's DMI Memory Controller report of

Error Detection Method: 64-bit ECC

Error Correction: None

won't be wrong; am I right? Is there a possibility that, in my case, both the DMI report and the Chipset report are correct?

------------------------------------------------

I have a follow-up question on the ChipKill reporting:

So, the Chipset page of AIDA64 reports "ChipKill ECC: Supported, Enabled". But according to the BIOS and Kernel Developer’s Guide (BKDG) For AMD Family 10h Processors (I refer to this as BKDG, for short), Section 2.12.2 "DRAM Considerations for ECC", pages 173-175, in systems with Revision C processors, the failure of a DRAM device with DRAM width wider than 4 bits will result in error(s) that cannot be corrected. In these cases, ganged mode can detect 100% of the occurrences of these failures, whereas unganged mode can detect 99.99999963% of them.

There are two tables (both labeled Table 77) in this section of the BKDG, one for Revision C and one for Revision D processors. I think the table for Revision C processors is the one that applies to mine. (I explain why I think my processor is treated by Table 77 as Revision C in the postscript at the end of this post).

My RAM modules have 8-bit FBGAs, so I think the "Revision C", "> x4" case in the table applies to me (assuming "> x4" in the BKDG means FBGA width wider than 4-bits). If this is true, then I can have, at best, 100% detection of DRAM failure occurrences, but no correction capability.

From my first post, I said AIDA64 shows ChipKill as enabled when I run in ganged mode and ChipKill as disabled when I run in unganged mode. If I am interpreting the BKDG correctly, then that means the Revision C, unganged mode, DRAM width > x4, 99.99999963% DRAM failure detection case causes AIDA64 to print ChipKill as disabled; and the Revision C, ganged mode, DRAM width >4 bits, 100% DRAM failure detection case causes AIDA64 to print ChipKill as enabled.

Does this mean any of these "hypothetical" cases:

1.) It is not a requirement for ChipKill to be of the correction type for AIDA64 to print ChipKill as enabled; it is only a requirement for ChipKill to be of the 100% detection type for AIDA64 to print ChipKill as enabled?

or

2.) The correction type of ChipKill isn't actually enabled?

or

3.) Having ganged mode enabled on ECC modules substantiates enabled ChipKill for another CPU vendor, not for AMD; but AIDA64 interprets this as enabled ChipKill in terms of that other CPU vendor?

or

4.) The symbol size is x8, so ChipKill has 100% correction of DRAM failure? (But page 173 of BKDG states: "For Revision C and earlier revisions, only the x4 code is available." I don't know if the "code" it refers to is the same as the one in Table 77's entries for "Recommended Symbol Size". I don't know if it is possible to do anything, like toggle bank interleaving or channel interleaving, to make the symbol size x8.)

or

5.) My motherboard has a version of ChipKill that does not conform to the AMD chipkill standard, yet can do 100% correction of DRAM failure?

or

6.) Some other reason?

I'd also like to add that even if I disable ChipKill in the BIOS, the Chipset report of AIDA64 still prints "ChipKill ECC: Supported, Enabled" as long as I am running ganged mode. Why is this? Is it because of any of the above reasons?

In any case, what is the required conditions for the Chipset report of AIDA64 to print "ChipKill ECC: Supported, Enabled"?

In any case, does AIDA64 use hardcoded values to print the ECC and Chip-Kill statuses of the reports based on values set in the BIOS? Is it possible that the values in the BIOS (such as Chip-Kill enable and ECC enable) do not actually make ECC or Chip-Kill work (e.g. if the motherboard manufacturer "copied" a leftover BIOS menu from one of their past server boards and "pasted" it in my board and does not actually include ECC functionality in my board)? In other words, can AIDA64 determine if ECC and Chip-Kill are actually working?

P.S.: Why I think my processor is treated by Table 77 of page 174 of BKDG as Revision C:

The AIDA64 CPUID page prints:

CPUID Properties:

...

CPUID Revision: 00100F42h

Extended CPUID Revision: 00100F42h

AMD Brand ID: 1996h (Phenom II X4 925)

Platform ID: D7h (Socket AM3)

...

----------------------------------------------------------------------

The AIDA64 Overclock page prints:

CPU Stepping: RB-C2

...

CPUID Revision 00100F42h

...

----------------------------------------------------------------------

The AIDA64 CPU page prints:

CPU Stepping RB-C2

----------------------------------------------------------------------

From cross-referencing Tables 2 through 11 of pages 11 through 13 of Revision Guide for

AMD Family 10h Processors (I refer to this as Revision Guide, for short) to Table 1 of page 29 of BKDG, it appears that the BKDG uses the penultimate hexadecimal digit before the letter "h" of the CPUID Revision number as the determining factor for the Revision letter(s). My CPUID Revision is 00100F42h, so my penultimate hexadecimal digit before the "h" is 4. In Table 1 of page 29 of BKDG, 4h corresponds to Revision C and/or Revision RB-C. My processor more specifically belongs to RB-C2 according to Table 8 of page 13 of Revision Guide, and this is confirmed by the AIDA64 reports. However, I don't know if Table 77 of page 174 of BKDG consolidates Revision RB-C under Revision C. Regardless, Revision D is not Revision RB-C, so I presume Revision D of Table 77 of page 175 of BKDG does not apply to me.

Thanks,

Consumer

Edited by Consumer

Share this post


Link to post
Share on other sites

Quite frankly, we are not in a position to be able to put all pieces of the puzzle together about the dark secrets of AMD memory controllers :) What I can tell you for sure is that:

1) DMI info is never 100% reliable, so it shouldn't be considered at all as a verification of memory controller working modes

2) You processor is definitely Revision C

3) Since you are familiar with AMD BKDG's, here's how AIDA64 detects ECC and ChipKill ECC modes:

IsECCSupported:=reg_F3xE8 Shr 3 And 1<>0;

IsChipKillECCSupported:=reg_F3xE8 Shr 4 And 1<>0;

IsECCEnabled:=(regF2x[1,0]90 Shr 19 And 1<>0) And (reg_F3x44 Shr 22 And 1<>0);

IsChipKillECCEnabled:=IsECCEnabled And (reg_F3x44 Shr 23 And 1<>0);

Based on that, and the PCI registers output at the end of AIDA64 reports, I hope you can put the pieces together ;)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Similar Content

    • By Arctucas
      Just down loaded 6.00.5146 BETA and noticed these temperature sensors.
      What are they for?
       
    • By Rabbithole
      So after the recent update my sensor panel no longer shows a sensor reading for my water pump or radiator temp. Is that a Windows update problem or Aida64 ? The radiator temp now reads N/C and the pump sits at zero. But I know the pump is working cause my cpu is at 36 C and it's clocked at 5000mhz. Has anyone else experienced this problem?
    • By fads
      Hello,
      Can you please help me. I just bought this new motherboard Gigabyte Z270X GAMING 9 but aida64 is reading some sensors incorrectly. I have attached the dumps below and a screenshot of aida64 sensor readings. Thank you, really appreciated.
      isasensordump.txt
      smbusdump_full.txt
    • By Dr4g0n
      Hello, 
      i own this mainboard: gigabyte x399 designare ex
      and i'm missing also 2 Onboard Temp-Sensor, in HWMonitor it is shown but Aida64 (Beta 4577) dosnt show it.
      By the way i own also a ADAPTEC HBA 1100-24I SINGLE Raidcontroller and the Temp also not showen....  
      My Temp Sensor Logs (ISA & SMBus) are attatched. 
      isasensordump.txt
      smbusdump_full.txt
    • By pimp1310
      hello,
       
      my native language is german, i hope my english is understandable.
       
      The Problem is, when i use my "aorus Graphic Engine" to control my 1080TI's leds, doesnt works anymore when i have aida64 in autostart.
       
      when i delete aida654 in my autostart the "Aorus graphics engine" works well.
      I tried to make a delayed start of aida64 but this didnt work.
       
       i need both programs, aida for my sensorpanel on the second screen, and aorus graphics engine to control my graphics card.
       
       
      any ideas ?
       
       
      THX
       
×
×
  • Create New...