Dual or non-dual channel is not displayed in the last version 6.20

[ibobak]

In the previous versions (e.g. 5.21b, which is not downloadable from your website) I could clearly see that the ram is in single channel model (64 bit), dual channel (128 bit), etc.

In the newest version 6.20 I don't see this information any more.

Could you please provide a link where I can download iso image with the 5.21? Or could you enable this info in the 6.20 version?

[debrouxl]

A bit of history first: in pcmemtest, auxiliary features such as SPD reading and IMC reading were removed to produce a cleaner, more maintainable code base. pcmemtest was reintegrated into memtest86+, sparkling the development of memtest86+ 6.00 and subsequent versions.
In memtest86+ 6.00+, SPD reading was reimplemented for SMBus controllers previously supported by memtest86+, and first implemented for a number of other SMBus controllers. Likewise, after 6.20, IMC reading was implemented for a number of recent desktop processors, and ECC error detection implementation has started.

If support for your IMC controllers has been reimplemented, nightly builds downloaded from the memtest86+ site should enable you to get frequency and timing information; however, the width is not displayed, though it is gathered from the IMC.

Which are the processor models contained in the computers where you saw the channel information in legacy memtest86+ ?

[ibobak]

Let me show first my screen with version 6.20, and then goes the screen which I've found in the internet (with version 5.01):

[ibobak]

I cannot answer this question "Which are the processor models contained in the computers where you saw the channel information in legacy memtest86+" because this is not my screenshot.

I can only tell what processor and motherboard I have (as to the first screenshot): AMD Ryzen 7 3700X, motherboard is TUF B450-PRO GAMING.

[ibobak]

So, my problem is to find out which mode I am running: dual channel or single channel. Since I have Linux, I cannot run CPU-Z. I thought that with the help of memtest I will be able to figure this out (as people suggested on some forums). But I faced with the problem that version 6.20 doesn't display this information, unfortunately.

[debrouxl]

Gathering information from desktop Zen processors' IMC has been implemented, but per my previous message, 1) that was after 6.20, as part of the current development cycle, and 2) even then, currently, the memory access width is obtained ( https://github.com/memtest86plus/memtest86plus/blob/main/system/imc/amd_zen.c#L36 ) but is not displayed ( https://github.com/memtest86plus/memtest86plus/blob/main/app/display.c#L279 -> https://github.com/memtest86plus/memtest86plus/blob/main/app/display.h#L109 ).

Are you willing and able to download a clone of the repository, apply a small patch to the source code, build a memtest86+ binary, and install it (e.g. by installing your Linux distribution's memtest86+ 6.xx package - not a 5.xx package - then replacing the memtest86+x64.efi or memtest86+x64.bin file it provides) ?

[ibobak]

I will gladly do this.

Actually, I tried to build the master branch right now, and the commands

cd build64
make

worked just fine and I got this set of files after building:

app
boot
debug_memtest.sh
esp.img
floppy.img
iso
ldscripts
lib
Makefile
memtest.bin
memtest.efi
memtest.mbr
memtest_shared
memtest_shared.bin
system
tests

But the command

make iso

produces an error:

~/github/memtest86plus/build64$ make iso
gcc -m64 -x assembler-with-cpp -c -I../boot -Iapp -o boot/mbr.o ../boot/mbr.S
ld -T ldscripts/memtest_mbr.lds boot/mbr.o -b binary memtest_shared.bin -o memtest.mbr
dd if=/dev/zero of=floppy.img bs=1474560 count=1
1+0 records in
1+0 records out
1474560 bytes (1,5 MB, 1,4 MiB) copied, 0,00210725 s, 700 MB/s
dd if=memtest.bin of=floppy.img bs=1474560 conv=notrunc
0+1 records in
0+1 records out
148472 bytes (148 kB, 145 KiB) copied, 0,000198776 s, 747 MB/s
cp memtest.efi iso/EFI/BOOT/bootx64.efi
/sbin/mkdosfs -n MEMTEST-ESP -F12 -C esp.img 4096
mkfs.fat 4.2 (2021-01-31)
mcopy -s -i esp.img iso/EFI ::
make: mcopy: No such file or directory
make: *** [Makefile:191: esp.img] Error 127

I just wanted to let you know, by the way.

Based on your comment, it looks like I don't need the iso, I need just the efi or bin file, and they are produced by "make" command.

Let me know what fixes should I make in the code, please.

[x86fr]

You need dosfstools, mtools and xorrisofs package to build the iso

[ibobak]

It works. Now make iso creates memtest.iso file, which is good.

Could you please clarify which patch should I apply before I re-build it again?

[debrouxl]

Something along the lines of:

diff --git a/app/display.c b/app/display.c
index ebba21b..231c54f 100644
--- a/app/display.c
+++ b/app/display.c
@@ -267,9 +267,9 @@ void post_display_init(void)
         // Try to get RAM information from IMC
         display_spec_mode("IMC: ");
         if (imc.type[3] == '5') {
-            display_spec_ddr5(imc.freq, imc.type, imc.tCL, imc.tCL_dec, imc.tRCD, imc.tRP, imc.tRAS);
+            display_spec_ddr5(imc.freq, imc.type, imc.tCL, imc.tCL_dec, imc.tRCD, imc.tRP, imc.tRAS, imc.width);
         } else {
-            display_spec_ddr(imc.freq, imc.type, imc.tCL, imc.tCL_dec, imc.tRCD, imc.tRP, imc.tRAS);
+            display_spec_ddr(imc.freq, imc.type, imc.tCL, imc.tCL_dec, imc.tRCD, imc.tRP, imc.tRAS, imc.width);
         }
         display_mode = DISPLAY_MODE_IMC;
     } else if (ram.freq > 0 && ram.tCL > 0) {
@@ -278,7 +278,7 @@ void post_display_init(void)
         if (ram.freq <= 166) {
             display_spec_sdr(ram.freq, ram.type, ram.tCL, ram.tRCD, ram.tRP, ram.tRAS);
         } else {
-            display_spec_ddr(ram.freq, ram.type, ram.tCL, ram.tCL_dec, ram.tRCD, ram.tRP, ram.tRAS);
+            display_spec_ddr(ram.freq, ram.type, ram.tCL, ram.tCL_dec, ram.tRCD, ram.tRP, ram.tRAS, 0);
         }
         display_mode = DISPLAY_MODE_SPD;
     } else {
diff --git a/app/display.h b/app/display.h
index c10428b..96121ef 100644
--- a/app/display.h
+++ b/app/display.h
@@ -102,13 +102,13 @@ typedef enum {
 #define display_spec_mode(mode) \
     prints(8,0, mode);
 
-#define display_spec_ddr5(freq, type, cl, cl_dec, rcd, rp, ras) \
-    printf(8,5, "%s-%u / CAS %u%s-%u-%u-%u", \
-                type, freq, cl, cl_dec?".5":"", rcd, rp, ras);
+#define display_spec_ddr5(freq, type, cl, cl_dec, rcd, rp, ras, width) \
+    printf(8,5, "%s-%u / CAS %u%s-%u-%u-%u %u", \
+                type, freq, cl, cl_dec?".5":"", rcd, rp, ras, width);
 
-#define display_spec_ddr(freq, type, cl, cl_dec, rcd, rp, ras) \
-    printf(8,5, "%uMHz (%s-%u) CAS %u%s-%u-%u-%u", \
-                freq / 2, type, freq, cl, cl_dec?".5":"", rcd, rp, ras);
+#define display_spec_ddr(freq, type, cl, cl_dec, rcd, rp, ras, width) \
+    printf(8,5, "%uMHz %s-%u CAS %u%s-%u-%u-%u %u", \
+                freq / 2, type, freq, cl, cl_dec?".5":"", rcd, rp, ras, width);
 
 #define display_spec_sdr(freq, type, cl, rcd, rp, ras) \
     printf(8,5, "%uMHz (%s PC%u) CAS %u-%u-%u-%u", \

It builds, but is untested on real hardware, and tonight, I don't think I'll have access to a suitable computer (which I can reboot, that is). It's not aimed at being committed as is.

[debrouxl]

Sam, Martin:

• AFAIK, SDR SDRAM has 64-bit width and RDRAM has 16-bit width, so we could hard-code the width for these classes of RAM, right ? Only DDR to DDR4 would have a width which can't be determined by simply looking at SPD data.
• also, the string in display_spec_ddr() needs to be shortened, probably the "%uMHz " part like in display_spec_ddr5() (and then also in display_spec_sdr() for consistency), or maybe the "CAS " part from all three strings ?

[ibobak]

I am at home now with a different PC (configuration is as below).

I made this patch, rebuilt everything (first "make" then "make iso"), wrote the iso file on a USB flash, booted from it, and this is what I see:

My home PC configuration:

As you may notice, no indication of how many channels I have in memtest.

But here at my home PC I also have Windows, and in CPU-Z I've got an indication that it is a quad channel:

Actually, it is a quad channel configuration: all 8 slots are taken by 32GB of RAM.

Tomorrow I will try to run memtest 7.0 with this patch on my work PC with Ryzen (where I don't have Windows, unfortunately). But I believe nothing will change, although I can be wrong. I will let you know tomorrow.

[debrouxl]

• lack of SPD data display on Xeon parts is SMBus not detected on SNB-E (and related -E/-EP IMCs) #65 . Recent memtest86+ versions have broad support for SMBus controller models from Intel, much wider than earlier versions of memtest86+, but Xeon processors since over 10 years ago require extra code for SMBus controller access to work properly. Sam will certainly eventually get back to refining the unstable prototype code he mentioned in that issue; however, chances are that it will be insufficient, because many server models require yet more custom code for dealing with (sometimes undocumented) multiplexers in order to read SPD data from more than 8 memory devices...
• at the time of this writing, the list of IMC controllers supported by memtest86+ has changed little since 7aeac72 : desktop parts from Intel since over 10 years ago, and AMD Zen series. Your Broadwell-EP Xeon is a server part; support for its IMC controller is likely to be implemented at some point.

Progress may seem slow, but well, like many open source projects, barring recent changes that I'm unaware of, nobody's getting paid to work on memtest86+, let alone anywhere close to full time :)
Maintainers are unlikely to be able to spend time implementing and testing IMC and EDAC support for parts earlier than Nehalem/Westmere or Bulldozer/Piledriver/Excavator. Basically, parts earlier than "x86-64-v2", which are becoming increasingly unsupported by recent Linux distributions, or more stringent, ESXi versions (Broadwell-EP+ or Zen, by now) or Windows versions.

[x86fr]

Please keep in mind that this code is not ready for v7.0 (it has not been tested at all on any platform). I didn't displayed the computed value because it needs more tests before we can consider it reliable.

[ibobak]

Your patch worked fine for the Ryzen machine:

Thank you very much, my problem is solved.

However, I wanted to ask as to this line:
https://github.com/memtest86plus/memtest86plus/blob/main/system/imc/amd_zen.c#L36

What about triple and quad channels? I see just 64 and 128 bits. Shouldn't there be some logic for finding more channels than 2?

[debrouxl]

Yes, when support for server processors' IMCs is added, there shall eventually be logic for dealing with more than 2 channels. The processor generations whose IMCs are currently supported by memtest86+ are limited to 2 channels; likewise for the unimplemented mobile processors.