How does Memtest work?

[ManOfArc]

How is Memtest able to test all of the memory if it loads itself into and runs from memory?

 

[nobspls]

The amount of code memtest takes up is tiny compared to the actual memory being tested. See:
https://en.wikipedia.org/wiki/Memtest86
"MemTest86 is designed to run as a stand-alone, self-contained program from a bootable floppy disk, CD-ROM, USB flash drive, or from a suitable boot manager without an operating system present.[9] This is because the program must directly control the hardware being tested and leave as much of the RAM space as possible for examination. "

I don't have solid proof, but considering the megs of L2 Cache CPUs have nowdays, I suspect memtest86 runtime probably fits in a tiny fraction of that CPU cache.

In any case if memtest blowsup/crash even before it gets going, because memory where it was loaded on to was bad, it would be pretty obvious something is wrong. You won't be able to say for certain it is the memory, but you would definitely suspect it.

 

[USAFRet]

How is Memtest able to test all of the memory if it loads itself into and runs from memory?

Really good programmers.

 

[ManOfArc]

The amount of code memtest takes up is tiny compared to the actual memory being tested. See:
https://en.wikipedia.org/wiki/Memtest86
"MemTest86 is designed to run as a stand-alone, self-contained program from a bootable floppy disk, CD-ROM, USB flash drive, or from a suitable boot manager without an operating system present.[9] This is because the program must directly control the hardware being tested and leave as much of the RAM space as possible for examination. "

I don't have solid proof, but considering the megs of L2 Cache CPUs have nowdays, I suspect memtest86 runtime probably fits in a tiny fraction of that CPU cache.

In any case if memtest blowsup/crash even before it gets going, because memory where it was loaded on to was bad, it would be pretty obvious something is wrong. You won't be able to say for certain it is the memory, but you would definitely suspect it.

The cache! I never thought of that. Thanks. I'm going with that until someone offers a better explanation. 😉 My theory was that it swapped out memory once it proved a same size section OK. But that would have to be done with every pass. I liike your idea better.

 

[jfriend00]

As others have said, MemTest86 is carefully crafted to run in and use very little memory. The memory that it does use is not tested directly by its own algorithms (it's tested indirectly on whether basic reads and writes work in the process of loading and running MemTest86).

When you boot into MemTest86, here's the sequence of events. First the BIOS loads and runs and initializes the hardware. This very operation is using some memory. So, if your memory isn't capable of basic reads and writes, then you will have problems booting, long before MemTest86 runs.

Then, a very small OS is loaded which again uses basic reads and writes in memory. If the memory it's using there fails, you will just fail to boot into MemTest86 and you will know that even basic reads and writes in your memory aren't working.

Then, the program MemTest86 is loaded into memory and run. Running code from memory is probably the lowest stress thing there is to do with memory. If the computer boots through the BIOS which has to use some memory to hold variables while it's running and loading system configuration, etc... then you already know that basic simple reads and writes from memory are working already. If the memory is so broken that you can't even load MemTest86 into it and run it, then the computer probably doesn't boot, long before it gets to running MemTest86 and you can conclude that your memory is not even close to operable.

If you look at the actual tests that MemTest86 is running and if you understand the dozens of memory timings that the memory controller uses to know how to safely read/write to the memory, then it's easier to understand that it's not usually simple slow reads and writes that cause problems with memory (once you've already booted). It's more involved things like reading through a whole bunch of successive rows of memory, spanning DIMMs, then writing to one, then reading back that value as quickly as possible and things like that, then doing writes after a read, then reads after a write all to the same rows, etc... That's where the details of the dozens of memory timings come into play and where things can more likely go wrong with memory.