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\u2019t 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).<\/p>\n\n\n\n
First phase is to run the ubiqitous memtest86+.<\/strong> 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 \u2013 see the note below). If it succeeds then you need to go on to the second phase of configuring the memory properly.<\/p>\n\n\n\n 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\u2019t 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\u2019t and believe me, you don\u2019t want to get stuck in the latter.<\/p>\n\n\n\n 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\u2019s 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.<\/p>\n\n\n\n Second test is to just see if the memory is working properly with multi core.<\/strong> This phase can also be used to \u201coverclock\u201d 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 If you want to learn more about memtest and dual core checkout this<\/a> and this<\/a> in the memtest86+ discussion board. It seems that memtest86 (as opposed to memtest86+) does<\/strong> have multi core support. Cool. The problem is that on Linux systems usually memtest86+ is the only one installed\u2026<\/p>\n\n\n\n If you want to know how to compile a Linux kernel learn more at this<\/a> URL.<\/p>\n\n\n\nmake -j N<\/code> 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.<\/p>\n\n\n\n