Test procedures for new memory installations

When you buy a new computer or get one and you are not sure of the quality of memory that it has, or when you buy, upgrade or add new memory you should test it before going on to simply use it. The reason is quite intricate. In most probability the memory with will either work or won’t and if the machine works it will be a good indication that the memory works fine. But in a few of the cases your machine may exhibit very strange behavior indeed. Various programs crashing, machine freezes, kernel crashes and the like. In that case, which may happen some time after the upgrade you may fail to connect the symptoms with hardware memory issues and attribute them to other factors like OS upgrades, driver installations or other peripheral failures. This may lead you, as it has led me, on wild goose chases after non issues which will certainly drive you insane or into writing blog posts at 4 AM. So what do I suggest? A simple and short 2 step procedure to be executed when using new memory in order to be sure that your memory is functional and well configured. This can also save you money since from my experience the probability of buying faulty memory is very high (at least 15% from my statistics).

First phase is to run the ubiqitous memtest86+. This is available via the boot menu of most current linux distros. This test runs for some time and long years of using it have led me to a solid statistic according to which if memtest does not find a problem with your memory in the first 30 seconds it will not find any problems in the next 30 hours. But, then again, this is just a statistic, feel free to run this for as long as you wish. If memtest fails return the chips to the manufacturer and get new ones (if you feel that it is the chips fauls – see the note below). If it succeeds then you need to go on to the second phase of configuring the memory properly.

Once the memory is installed open your bios configuration and see how is it configured. How are its parameters (speed and 4 more numbers) set. Is it on automatic or is it on manual? Do you have heterogenous memory banks? If so what is the speed of each and what is the overall speed of the entire memory subsystem? Why should you know all of this info, you rightly ask. Well, in a perfect world you would just buy memory, plug it in and the BIOS would configure and use it properly. Alas, this is not the world we live in. In reality you usualy buy the motherboard at date X and buy the upgrade or new memory at date Y. Y is a couple of years following X. This means that the memory you are buying is too fast for your motherboard. Shouldn’t your BIOS be able to handle this? Well, yes and no. In lots of cases it does manage to handle it but in some it doesn’t and believe me, you don’t want to get stuck in the latter.

In my case I installed a DDR2 800 MHz memory on a standard Intel board which did not complain and the BIOS ran that memory at the auto-selected optimal speed of 800 MHz. There was no problem with the memory and so memtest ran smoothly. It’s just that when the 2 cores were accessing it together with high speed then put more pressure on it than memtest did and memory faults started happening.

Second test is to just see if the memory is working properly with multi core. This phase can also be used to “overclock” your RAM and to make sure that you will not be experiencing any weird side effects from this overclocking. In this phase we will test the memory in practice using the N cores. I found that the best way to achieve this is to just compile the Linux kernel on the machine using make -j N where N is the number of your cores. Whenever I had memory problems this compilation would crash in some spectacular way and in random places and so served as a clear indication of RAM issues.

If you want to learn more about memtest and dual core checkout this and this in the memtest86+ discussion board. It seems that memtest86 (as opposed to memtest86+) does have multi core support. Cool. The problem is that on Linux systems usually memtest86+ is the only one installed…

If you want to know how to compile a Linux kernel learn more at this URL.

memtester: There is a package called memtester in Linux which will test memory from user space. In Ubuntu this package is simply called memtester. It is developed here. I have tried it out and it is a fine piece of code but does not do multi-threaded testing with CPU affinity. You have to do that on your own at the command line by running two instances of memtester and assigning them to different CPUs via taskset. Another problem with memtester is that you need to let it know how much ram to test which is very hard to do since you want to test as much as possible. This means that you need to calculate the size to test which is roughly total_ram_size-(size_of_os+size_of_all_currently_running_programs) which is a hard to calculate and if you miscalculate the program may fail since it locks the memory that it gets using mlock, which you need to have permission to perform. It may also throw other programs that you are running at the time into swap (since they are not locked into memory).

The kernel compilation mentioned above is better in my opinion due to the following reasons: it uses all of your CPUs and it also uses every last bit of RAM you have since the kernel is big and during the compilation stage will use up all of your Linux cache which means all of your spare memory.

Note: as mentioned in the memtester documentation, if you do find any problems with your memory it may not be the fault of your memory chips at all. It may be the fault of your motherboard not supplying enough power for the chips or the CPU, it may be an overheating CPU, a mis-configured BIOS or other reasons.

Please leave comments if you think that I am wrong in any of the above and I promise to improve the post if you convince me that I could do better…

Leave a Reply

Your email address will not be published.