anphsw / memtest86 Goto Github PK

Hi,

Could you merge patch from debian?

https://sources.debian.org/patches/memtest86+/5.01-3/

my moterboard is ASUS Z370-A and its memory type is DDR4.
the CPU is i5-8400, the memory controller is "INTEL IMC (Integrated Memory Controllers)" whose vendor is 0xffff and device is 0x0001.
when the memtest86 is executed, "RAM: 0 MHZ" is displayed on the 8th line of the screen.
It's confirmed that the funtion,"static void poll_fsb_nhm(void){xxxxxxxxx}" cannot poll the memory frequency.
do you have any suggestion?

in the test.c , the function ,"void movinvr(int me)", the assembly codes(started from line 386) cannot be replaced by the c codes displayed above(started from line 380) ,why?
when i try to replace the assembly code with c code, the memtest.bin will make the running system reboot.

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977217 it fix some systems

Care to merge upstream ?

test13[Random number sequence, 64-bit]
this test is aiming to read and write 64bit of data at a time from the RAM.
this test13 is same to test9[random number sequence,32-bit]
the code of realizing the test13 is as following:
void movinvr_64_bit(long me)
{
long i, j, done;
ulong seed1, seed2;
ulong *p;
ulong *pe;
ulong *start,*end;
ulong num0,num1,bad;//ulong: 8-bytes length under 64-bit compiler. 4-bytes length under 32-bit compiler.

	/* Initialize memory with initial sequence of random numbers.  */
	if (cpu_id.fid.bits.rdtsc) {
		asm __volatile__ ("rdtsc":"=a" (seed1),"=d" (seed2));
	} else {
		seed1 = 521288629 + v->pass;
		seed2 = 362436069 - v->pass;
	}
 
	/* Display the current seed */
		if (mstr_cpu == me) hprint(LINE_PAT, COL_PAT, seed1);
		
	rand_seed_64_bits(seed1, seed2, me);
	for (j=0; j<segs; j++) {
		calculate_chunk(&start, &end, me, j, 4);
		pe = start;
		p =  start;
		done = 0;
		do {
			do_tick(me);
			BAILR

			/* Check for overflow */
			if (pe + SPINSZ > pe && pe != 0) {
				pe += SPINSZ;
			} else {
				pe = end;
			}
			if (pe >= end) {
				pe = end;
				done++;
			}
			if (p >= pe ) {
				break;
			}
/* Original C code replaced with hand tuned assembly code */

#if 1
*p = (rand_64_bits(me)&0xffffffff);
*(++p) = (rand_64_bits(me)>>32);//高位地址高字节，little-endian
--p;
for (; p < pe; ) {
p+=2;
*p = (rand_64_bits(me)&0xffffffff);
*(++p) = (rand_64_bits(me)>>32);
--p;
}
#else
*p=rand_64_bits(me);
for (; p < pe; ) {
p++;
*p=rand_64_bits(me);
}

#endif

			p = pe + 1;
		} while (!done);
	}

	/* Do moving inversions test. Check for initial pattern and then
	 * write the complement for each memory location.
	 */
	for (i=0; i<2; i++) {
		rand_seed_64_bits(seed1, seed2, me);
		for (j=0; j<segs; j++) {
			calculate_chunk(&start, &end, me, j, 4);
			pe =start;
			p = start;
			done = 0;
			do {
				do_tick(me);
				BAILR

				/* Check for overflow */
				if (pe + SPINSZ > pe && pe != 0) {
					pe += SPINSZ;
				} else {
					pe = end;
				}
				if (pe >= end) {
					pe = end;
					done++;
				}
				if (p >= pe ) {
					break;
				}
/* Original C code replaced with hand tuned assembly code */

#if 1
num1=(rand_64_bits(me)>>32);
num0 =(rand_64_bits(me)&0xffffffff);
if (i) {
num1 = ~num1;
num0 = ~num0;
}
if ((bad=p) != num0 ) {
error((ulong)p, num0, bad);
}
if ((bad=(++p)) != num1 ) {
error((ulong)p, num1, bad);
--p;
}
*p = ~num0;
*(++p) = ~num1;
--p;

				for (; p < pe; ) {
					p+=2;
					num1=(rand_64_bits(me)>>32);
					num0 =(rand_64_bits(me)&0xffffffff);
					if (i) {
							num1 = ~num1;
							num0 = ~num0;
					}
					if ((bad=*p) != num0 ) {
							error((ulong*)p, num0, bad);
					}
					if ((bad=*(++p)) != num1) {
							error((ulong*)p, num1, bad);
							--p;
					}
					*p = ~num0;
					*(++p) = ~num1;
					--p;
				}

#else
num=rand_64_bits(me);
if (i) {
num = ~num;
}
if ((bad=*p) != num ) {
error_64bits(p, num, bad);
}
*p = ~num;

				for (; p < pe; ) {
					p++;
					num=rand_64_bits(me);
					if (i) {
						num = ~num;
					}
					if ((bad=*p) != num ) {
						error_64bits(p, num, bad);
					}
					*p = ~num;
				}

#endif
p = pe + 1;
} while (!done);
}
}

when I run the execute binary file, the screen is filled with error report.
}

Tried writing out the memtest.bin and memtest.img to USB. Got a 0104 loop both times. The 5.0.1 images upstream also do the same thing.

Are these supposed to be USB bootable?

Hi, my closely friend.
At present, I am trying to running your program on ASUS Z390-A(i7-9700k) whose deviceId is 0xa323 of the smbus controller.
the issue is that the abtained spd byte,spd_raw[2],is 0x00, which leads to "ddr4 spd cannot be uncovered" .

Hello, I don't know if you are aware, but a beta version has been released recently. It might be interesting to merge the new version with your fixes.
http://www.memtest.org/download/5.31b/memtest86+-5.31b.tar.gz

Even when pie disabled (and all compiler flags and versions same), memtest86+ cannot run in SMP mode, it just reboot or hangs after selecting SMP option.
In ordinary or failsafe it runs correctly.
There is no error on any other (for example debian/fedora) gcc.

THIS command is extrememly difficult, but i hanve realized it!

hi ! thanks for your work.

my config is r7 2700X + strix x370-f + f4-3600c15d-gtz. it runs at 3333mhz and it hold 25hrs of prime95 v298.b6 large fft (win10 latest update). while testing 5.31b, ambiant temp were pretty low (23°c max), 5.01 were running at higher temp.

bug report : entering a test list run the next test instead. if i enter 7,9 it run test#8 and #10 (that bug was already there in 5.01).
5.31b test 17GB of memory. actually it skip 1GB (from 3 to 4GB) and it add 1GB (from 16 to 17GB).

as you explain : "There are some systems that cause Memtest86+ to be confused about the size of memory and it will try to test non-existent memory. This will cause a large number of consecutive addresses to be reported as bad and generally there
will be many bits in error. If you have a relatively small number of failing addresses and only one or two bits in error you can be certain that the errors are valid. Also intermittent errors are always valid."
when selecting smp (f2) and entering a test list (T#7,T#9), i get that "large number with many bits" of errors during T#7 (200-400E), but T#9 get no error (12 pass),
whereas when running the same loop on memtest86+ v5.01 i get an average of 1error/GB during t#9 (one bit in error - 12 pass) and no error during t#7 !
imho this is a huge improvement for T#9. whereas for t#7, before, my hardware wasn't confusing 5.01.

i have also to mention that smp enabled heat a lot more. i've noticed a higher power consumption (300w, p95 is around 200w) which obviously push my sticks to their temp limit. so i also tried to set all fans (cpu, aux, dram) at full speed before running 5.01 smp enabled. result was -96% of error. i had 2errors/12pass during t#9 which look like intermittent errors ? however i felt like 5.01 wasn't fully applying that full fans speed settings from bios.
another thing that is true for 5.01 and 5.31b, according to the test duration, i've noticed two kind of test of the same test#. on my configuration, T#9 can be fast (2min) or slow (6min). i don't know if it's a ryzen stuff but the fact is if it finds errors, it's exclusively during slow pass. example : i had a run where it first ran 7 fast pass of T#9, then, it started to run slow pass. during the 8th slow pass, it found one error, only one bad bit, the 4th bit was +8 digit. i tried to run it with a large fft, it failed in less than 1 min (unstable set of settings @3400mhz).
one last thing, v5.01 (smp disabled) does not find error during test list #6-7-9-10 (7 pass - 10hrs). i haven't tried it on 5.31b, but i believe it can not be different.

sorry to ask but i really wonder if i'm right to conclude that smp enabled is more like a memory controller and dram stability test, whereas smp disabled is a dram failure test ?
please could you give informations about F3 key ? that mode looks less stressing that F2, but is it reliable ?
memory sticks can be very sensitive to heat. mine doesn't like more than 42°c (thaiphoon - hwinfo). should i believe that unconsistant or small number of errors come from system overall heat ?

Thanks.

A ipxe (coreboot related?) dev also made a whole bunch of changes. Anything useful here?

https://github.com/hadrava/memtest86plus/commits/develop

Serial output text is duplicated per-cpu on some tests, for example, printing "abcd" gives "aaaabbbbccccdddd" on 4-CPU machine, ANSI-codes also damaged.
Problem that outb() is not SMP-safe.

When creating repository for software where at least separate release tarballs exist, it's always better to import all of them as separate commits to keep the history.
See https://github.com/Saruspete/memtest86/ for example.

Hello

I see there's a lot of commits already. That's fantastic, thanks for the continuing development.
But i have some questions.

Is this project it based on the original memtest86+ v5.01? or older 4.20? 4.00?
It looks to be from 5.01 looking at the changelog file, but not accordingly to other documentation files (same as in the original author's source code)

The code came from memtest86+ https://www.memtest.org/#downcode ?
5.01 (27/09/2013)
4.20 (25/01/2011)
4.10 (04/05/2010)
4.00 (22/09/2009)
The original author didn't update much of the documentation after 4.00, including version history on readme, but did update changelog file, which in turns makes everything more confusing.

From memtest86 https://www.memtest86.com/downloads ?
Is the source code of 4.3.7 significantly older and already included in memtest86+?
https://www.memtest86.com/downloads/memtest86-4.3.7-iso.tar.gz

The roadmap and contributions,

• Is there a roadmap and what it is?
• Is there any company or institution or group contributing?
• Is this source being used by upstream linux distributions?
• What can a user contribute with? CPU IDs? and how?
• Plans for porting to 32bit for UEFI while keeping 16bit for BIOS?

Cheers!

https://www.memtest86.com/ecc.htm

https://github.com/google/rowhammer-test

This is still very useful for verifying that ECC memory is working properly after purchase.

In addition, it should be very useful to write logs to the storage media to help locate memory errors after the PC is down for memtest.

On you web sight you suggest balenaEtcher for creating a bootable USB. balenaEtcher does not work properly. I suggest you change your recommendation to something else (perhaps Gnome Multiwriter). balenaEtcher is garbage.

I wan to add a file system into this program so as to record the test result by creating a txt file.

do u have any suggestions?

when the memory size of my compiled binary file,mt86plus, is bigger than 279KB, the program will not run normally ,and the SCREEN is black .
why? how could i fix the issue?

Dear @anphsw , thank you for continuing the memtest development! (yours is the only alive version). Your test always freezes instantly after reaching the following memory range:

"Testing: 4096M - 6144M of 15GB RAM (= 16GB - iGPU_shared)"

that's no matter what I do: even if skip a current test (the next will freeze at the same moment), or enable safe mode, or multithreading. Meanwhile, all the other versions - official 4.37 and official 5.01 - are working fine at the same hardware:

• Lenovo G505S laptop with a coreboot opensource BIOS installed
• AMD A10-5750M (Richland 15h architecture)
• Bolton A76M chipset (similar to Hudson)
• two sticks of 8GB DDR3 SO-DIMM Kingston KHX1600C9S3L/8G running as 1600MHz CL9
• bootable media: built a memtest.bin floppy, expanded it to 1.44MB and inserted to a BIOS

By the way, if I quickly skip 3 tests (before reach this freezing moment), Test number 4 is "Test is missing!".

Freezes: I mean, the whole screen freezes and all the values/time are staying the same, only a + is blinking at top left corner besides a Memtest86 logo.

Is there any way to provide more debug info? If you have any ideas, I'm ready to test any custom floppy versions with more debug info collection included.

a DRAM defect was found by Test 9 [Modulo 20, Random pattern] belonged to memtest86-purchase ,however,the defect cannot be found by memtest86plus. why?

have you try to realize the function about changing timing of "HSW IMC"?
in the extra.c , no function is silimar to "0xFFFF, 0x0007, "HSW IMC" or any other "Integrated Memory Controllers".