MemTest86+ V2.00 www.memtest.org S. DEMEULEMEESTER memtest@memtest.org ------------------------------------------------------------------------ - What is memtest86+, what do I use it for? Memtest86+ is a utility designed to test whether your memory is in working order. It repeatedly writes an enormous amount of different patterns to all memory locations and reads them back again and verifies whether the result of the read is the same as what was written to memory. There can be a multitude of reasons for running memtest, but foremost of all is of course to test whether your memory modules might be bad. Whenever you suspect your modules to be bad because of system crashes, lockups or reboots it would be nice to know whether the modules are in working order. Memtest86+ is a utility which tries to answer that question for you. Another common use exists in the overclocking scene. When overclocking a system you are essentially pushing your system to the limits and at some point it will simply give way and break. Unfortunately there isn't a clear cut way of deciding whether a system is still working correctly. Because of the complexity of a computer a system which is pushed to the limits doesn't just break completely when it starts to fail, instead little errors start showing up in many different places in the system growing more frequent and widespread the more the system is pushed. Each one of these little errors can lead to a crash of your system but can also go unnoticed for days or weeks in a running system. The art so to speak of overclocking is thus to push the system as far as it can go without introducing any such errors. As memory is usually one of the first places these such errors start coming up a memory test is very useful. - How do I get it to run? There are several ways to use memtest, which are described below: + Run from floppydisk Memtest86+ is directly executable by any modern x86 compatible machine, by writing the bootable binary to a floppy disk one can boot from the disk to run memtest. Simply download the appropriate package, the Pre-Compiled Bootable Binary (.gz) package for Linux users and the Pre-Compiled package for Floppy (DOS - Win) for Windows users. For Windows, unzip the package into a directory like C:\memtest, insert a blank floppy into your a: disk drive and run the install.bat file. As the install prompts you, to use memtest directly, leave the disk in the drive and reboot your machine. For Linux, unpack the package into your home directory, insert a blank floppy into your floppy drive and execute 'dd if=~/memtest+-1.xx.bin.gz of=/dev/fd0 conv=osync' replacing 1.xx with the correct version number of the memtest86+ you downloaded. To run memtest immediately reboot your machine. Your machine should now boot from the disk, display the word Loading folowed by a series of periods and then show a screen much like the screenshots on the memtest86+ web page. The test is automatically started. If your machine simply boots back into Windows/Linux you will most likely have to configure your BIOS to attempt to boot from floppy disk on startup, refer to your computer's/mainboard's manual how to do this. When you are done testing simply remove the floppy and reset your computer, if ever you want to execure the test again simply reinsert the disk and reboot/start your computer. + Run from CD Memtest86+ is directly executable by any modern x86 compatible machine, by writing the iso to a CD one can boot from the CD to run memtest. Simply download the appropriate package, the Download - Pre-Compiled Bootable ISO (.gz) for Linux users and the Pre-Compiled Bootable ISO (.zip) for Windows users. For Windows, unzip the package into a directory like C:\memtest. You will now see a file called memtest86+-1.xx.iso in this directory. You will need to burn this file to a CD with a CD recording program. Do note however that you should not make a regular data CD on which you for instance write your text documents and holiday photographs. Instead the iso file is a so called image of a CD, it is a direct copy of a CD. Your CD recording program will most likely have a feature called burn image or something to that effect which you should use to burn the CD. For linux, unzip the package into your home directory. and execute 'cdrecord dev= ~/memtest86+-1.xx.iso' where you replace with the scsi address of your CD burner and replace 1.xx with the correct version number of the memtest86+ your downloaded. When the burning completed your drive will most likely have ejected the CD and you should have a bootable memtest86+ CD. To run the test directly reinsert the CD and reboot your machine. Your machine should now boot from the CD, display the word Loading folowed by a series of periods and then show a screen much like the screenshots on the memtest86+ web page. The test is automatically started. If your machine simply boots back into Windows/Linux you will most likely have to configure your BIOS to attempt to boot from CD-ROM drive on startup, refer to your computer's/mainboard's manual how to do this. When you are done testing simply remove the CD and reset your computer, if ever you want to execure the test again simply reinsert the CD and reboot/start your computer. + Run from USB Flash drive FIXME + Run from boot manager FIXME - How long does memtest86+ run? How do I stop it? Memtest86+ runs indefinately unless you stop it. It does however repeat the same tests over and over again. Memtest86+ contains a number of different tests which each take different approaches in trying to expose any errors in your memory. In the top right of your screen you can see the progress of each test in the lower of the two progress bars. The topmost progress bar shows the progress of a pass, each pass consists of all the tests in the memtest suite. Thus all tests are executed in one pass, so does that mean that no errors will show after the first pass if that pass didn't reveal any errors? Well no, there are several reasons why errors might only show up after a number of passes. Firstly as of this writing, the latest version of memtest also includes a test which uses random test patterns, each pass these patterns will of course be different. Secondly some types of errors simply don't show up until the system has been running for a while or are very critical on a certain timing condition, or other such conditions. To conclude, one successful pass of memtest will give you a pretty good idea that your memory is ok, only in rare cases will there be errors showing after the first pass. To be sure though simply have the test run overnight or even for a couple of days depending on the level of importance of the system. - How many errors are acceptable? No errors are acceptable. Even if there is just one error, something is amiss which can cause your system to crash. Of course what the cause of the errors is you will still have to determine. - What do I do when I get errors? Firstly, don't start drawing any conclusions. You only know that memtest86+ is giving your errors, not what the cause is. Unfortunately it is not a straightforward exercise to decisively test the memory in an actual system. This is because a computer is not just built up of some memory, but also includes many other elements such as a memory controller, cache, a cache controller, algorithmic and logic units, etc, all of which contribute to the machine. If there are faults in any of these other parts of the computer you will likely also see errors showing up in memtest. So what to do? First verify that the BIOS settings of your machine are correctly configured. Look up the memory timing settings applicable to the brand and type of memory modules you have and check they match your BIOS settings, correct them if they don't and run memtest again Ok, you have all the settings correctly set and you're still getting errors. Well of course a very likely cause are the memory modules and the logical course of action is to look into them further. If you are well stocked, have a few other machines at your disposal, or just want to spend the cash for some new modules the best way to test if the cause are your memory modules is just to replace them and test again. If you are less fortunate though there is still something you can do. If you have more then one module in your system, test them one by one, if one is consistently giving errors and another is consistently showing no errors it's a pretty good bet that the module giving the errors is simply defective. To exclude the possibility that a defective slot is throwing your results, use the same slot to test each different module. If each module by itself shows no errors, but when you place two or more modules into the machine at the same time you do get errors, you are most likely stuck with a compatibility issue and unfortunately there isn't a whole lot you can do about it. Be sure to check your computer/motherboard manual to see if the setup you are trying is allowed, some boards require special restrictions in the sizes of modules, the order of modules, the placement of double sided and single sides modules and more of such things. If you have only one module in your system, or all modules are giving errors, there are only very few options left. The only thing you can do really is to try the module(s) in another slot. Finally simply try out different orders of the memory modules, although your manual might not mention anything on the matter sometimes there simply exist timing or other issues which can be resolved by changing the order of your modules. And of course test each slot by putting a single module into that slot and running memtest on it. In the end if you still have not been able to localize the problem you will have to find a replacement module to establish whether the problem lies in your modules. See if you can borrow a module from someone else. When you have replaced the memory by new memory and the errors still persist, first check if you can rule out any compatibility issues or timing issues. If you are sure the memory should work in the system the cause of the errors must obviously lie someplace else in the system. The only way to find out where, is by trial and error really. Simply start replacing and/or removing parts of your computer one by one, running memtest each time you changed anything, until the errors are resolved. - I'm getting errors in test #x, what doest that mean? Interpreting memtest results is as scientific an endeavour as testing whether a person is a witch by the methods used in Monty Python's Holy Grail. In short, don't even start, it's not going to get you anywhere. Just interpret any error as you should any other and use the methods descibed in the previous question to determine the cause. - I'm getting errors in test #5 and/or #8 and have read a lot about it. Yes there are just about enough discussions on the topic to fill a book, but it all boils down to the answer given above. The only thing that can be said is that many a times, when memory latencies are incorrectly set in the BIOS you will experience errors in test #5 and #8. (Though #8 does not exist anymore as of version 1.40 and might be reinstated as a different test in a later version.) This does however NOT mean that errors in these tests are always the cause of incorrect settings, your memory might just as well be defective. - I'm getting errors in memtest on one machine, but not when I put the same memory in another, what does that mean? It can mean one of two things: - The machine that is giving the errors is defective. Errors don't just orginate from the memory module itself, but can also be caused by defects in the cpu, chipset, motherboard, PSU and even by timing issues introduced by any other component in the machine. - The machine giving the errors is imposing stricter timing than the other which the memory module simply can't cope with. If the module should work with the machine according to its specifications then it most likely is defective. - Which memory is tested? As much as possible of the system memory is tested. Unfortunately memtest86+ can usually not test all of the memory. The reason for this is that todays processors have become so complex that they require a small amount of memory to keep accounting data of the processor state. If memtest were to write over these areas the state of the processor becomes invalid and it's behaviour unpredictable. Alas it is also impossible to relocate these areas in the memory. This means that a small area of your memory can not be tested by memtest. If this part of the memory is defective you will know soon enough though as the processor, or parts of the processor simply won't work correctly if this part of your memory is defective. Do realise though that in very rare cases memtest will show no errors even though the module is defective, not because memtest can't detect the error, but because memtest can't test the area the error is located in. - When I select BIOS-ALL I get many errors / my machine crashes. This is normal. With todays computers this option should never be selected. See the previous question about the reason for the errors. - I want to use memtest on a multiboot CD, how do I do this? This is of course very dependent on which boot loader you use for your CD. Below is a description of how to set up a multiboot CD including memtest+ with isolinux, if you have experience with any other bootloader(s) please consider writing a small description of using memtest with that bootloader for the FAQ. -isolinux For general instructions on how to make a bootable CD with isolinux see the syslinux website and the manual. What you need to do to get memtest working is as follows. Download the Pre-Compiled Bootable Binary, the .gz if you are working under linux, the .zip if you are working under windows. Unpack the file from the package and rename it to an 8.3 filename with an extension other than .bin, renaming to memtest. (without an extension) is a good choice. Put the file somewhere in your CD directory structure, for example in images/memtest and edit your config file to include the following: label memtest kernel /images/memtest If you want to boot memtest automatically insert or change a line at the top to: default memtest If you want to display a prompt from which you can start memtest add or change the lines at the top to: (Change the timeout to suit your needs) prompt 1 timeout 200 - If memtest86+ shows no errors does that mean my memory is not defective? Of course no answers are definitive, no matter how good memtest86+ will eventually become there is always the possibility that a particular type of error will go unnoticed. As long as you are having no problems with the system it will be pretty safe to say that the modules are good. If you are having problems with the system however you will just have to check by trial and error, ie swapping the modules for new ones and/or testing with modules of a different brand/type. - When I run install.bat it doesn't write anything to floppy. You most likely have unpacked the memtest+-1.xx.floppy.zip file into a folder with a long pathname and/or containing + and - signs. It seems rawrite doesn't like that. Just move the files you unpacked to a directory like c:\memtest and execure it from there. ------------------------------------------------------------------------ =================== = MemTest-86 v3.0 = =================== Table of Contents ================= 1) Introduction 2) Licensing 3) Installation 4) Serial Port Console 5) Online Commands 6) Memory Sizing 7) Error Display 8) Trouble-shooting Memory Errors 9) Execution Time 10) Memory Testing Philosophy 11) Memtest86 Test Algorithms 12) Individual Test Descriptions 13) Problem Reporting - Contact Information 14) Known Problems 15) Planned Features List 16) Change Log 17) Acknowledgments 1) Introduction =============== Memtest86 is thorough, stand alone memory test for Intel i386 architecture systems. BIOS based memory tests are only a quick check and often miss failures that are detected by Memtest86. For updates go to the Memtest86 web page: http://www.memtest86.com To report problems or provide feedback send email to: cbrady@cray.com 2) Licensing ============ Memtest86 is released under the terms of the Gnu Public License (GPL). Other than the provisions of the GPL there are no restrictions for use, private or commercial. See: http://www.gnu.org/licenses/gpl.html for details. 3) Installation =============== Memtest86 is a stand alone program that cannot be executed under windows and must be loaded from a floppy disk. To install Memtest86: - Extract the files from the zip archive - Open the directory where the files were extracted and click on "install.bat". - The install program will prompt you for the floppy drive and also prompt you to insert a blank floppy. - To run Memtest86 leave the floppy in the drive and reboot. NOTE: After the boot floppy has been created you will not be able to read the floppy from windows. This is normal. 4) Serial Console ================= Memtest86 can be used on PC's equipped with a serial port for the console. By default serial port console support is not enabled since it slows down testing. To enable change the SERIAL_CONSOLE_DEFAULT define in config.h from a zero to a one. The serial console baud rate may also be set in config.h with the SERIAL_BAUD_RATE define. The other serial port settings are no parity, 8 data bits, 1 stop bit. All of the features used by memtest86 are accessible via the serial console. However, the screen sometimes is garbled when the online commands are used. 5) Online Commands ================== Memtest86 has a limited number of online commands. Online commands provide control over caching, test selection, address range and error scrolling. A help bar is displayed at the bottom of the screen listing the available on-line commands. Command Description ESC Exits the test and does a warm restart via the BIOS. c Enters test configuration menu Menu options are: 1) Cache mode 2) Test selection 3) Address Range 4) Memory Sizing 5) Error Summary 6) Error Report Mode 7) ECC Mode 8) Restart Test 9) Reprint Screen SP Set scroll lock (Stops scrolling of error messages) Note: Testing is stalled when the scroll lock is set and the scroll region is full. CR Clear scroll lock (Enables error message scrolling) 6) Memory Sizing ================ The BIOS in modern PC's will often reserve several sections of memory for it's use and also to communicate information to the operating system (ie. ACPI tables). It is just as important to test these reserved memory blocks as it is for the remainder of memory. For proper operation all of memory needs to function properly regardless of what the eventual use is. For this reason Memtest86 has been designed to test as much memory as is possible. However, safely and reliably detecting all of the available memory has been problematic. Versions of Memtest86 prior to v2.9 would probe to find where memory is. This works for the vast majority of motherboards but is not 100% reliable. Sometimes the memory size is incorrect and worse probing the wrong places can in some cases cause the test to hang or crash. Starting in version 2.9 alternative methods are available for determining the memory size. By default the test attempts to get the memory size from the BIOS using the "e820" method. With "e820" the BIOS provides a table of memory segments and identifies what they will be used for. By default Memtest86 will test all of the ram marked as available and also the area reserved for the ACPI tables. This is safe since the test does not use the ACPI tables and the "e820" specifications state that this memory may be reused after the tables have been copied. Although this is a safe default some memory will not be tested. Two additional options are available through online configuration options. The first option (BIOS-All) also uses the "e820" method to obtain a memory map. However, when this option is selected all of the reserved memory segments are tested, regardless of what their intended use is. The only exception is memory segments that begin above 3gb. Testing has shown that these segments are typically not safe to test. The BIOS-All option is more thorough but could be unstable with some motherboards. The second option for memory sizing is the traditional "Probe" method. This is a very thorough but not entirely safe method. In the majority of cases the BIOS-All and Probe methods will return the same memory map. For older BIOS's that do not support the "e820" method there are two additional methods (e801 and e88) for getting the memory size from the BIOS. These methods only provide the amount of extended memory that is available, not a memory table. When the e801 and e88 methods are used the BIOS-All option will not be available. The MemMap field on the display shows what memory size method is in use. Also the RsvdMem field shows how much memory is reserved and is not being tested. 7) Error Information ====================== Memtest has two options for reporting errors. The default is to report individual errors. In BadRAM Patterns mode patterns are created for use with the Linux BadRAM feature. This slick feature allows Linux to avoid bad memory pages. Details about the BadRAM feature can be found at: http://home.zonnet.nl/vanrein/badram For individual errors the following information is displayed when a memory error is detected. An error message is only displayed for errors with a different address or failing bit pattern. All displayed values are in hexadecimal. Tst: Test number Failing Address : Failing memory address Good: Expected data pattern Bad: Failing data pattern Err-Bits: Exclusive or of good and bad data (this shows the position of the failing bit(s)) Count: Number of consecutive errors with the same address and failing bits In BadRAM Patterns mode, Lines are printed in a form badram=F1,M1,F2,M2. In each F/M pair, the F represents a fault address, and the corresponding M is a bitmask for that address. These patterns state that faults have occurred in addresses that equal F on all "1" bits in M. Such a pattern may capture more errors that actually exist, but at least all the errors are captured. These patterns have been designed to capture regular patterns of errors caused by the hardware structure in a terse syntax. The BadRAM patterns are `grown' increment-ally rather than `designed' from an overview of all errors. The number of pairs is constrained to five for a number of practical reasons. As a result, handcrafting patterns from the output in address printing mode may, in exceptional cases, yield better results. 8) Trouble-shooting Memory Errors ================================ Please be aware that not all errors reported by Memtest86 are due to bad memory. The test implicitly tests the CPU, L1 and L2 caches as well as the motherboard. It is impossible for the test to determine what causes the failure to occur. Most failures will be due to a problem with memory. When it is not, the only option is to replace parts until the failure is corrected. Once a memory error has been detected, determining the failing SIMM/DIMM module is not a clear cut procedure. With the large number of motherboard vendors and possible combinations of simm slots it would be difficult if not impossible to assemble complete information about how a particular error would map to a failing memory module. However, there are steps that may be taken to determine the failing module. Here are three techniques that you may wish to use: 1) Removing modules This is simplest method for isolating a failing modules, but may only be employed when one or more modules can be removed from the system. By selectively removing modules from the system and then running the test you will be able to find the bad module(s). Be sure to note exactly which modules are in the system when the test passes and when the test fails. 2) Rotating modules When none of the modules can be removed then you may wish to rotate modules to find the failing one. This technique can only be used if there are three or more modules in the system. Change the location of two modules at a time. For example put the module from slot 1 into slot 2 and put the module from slot 2 in slot 1. Run the test and if either the failing bit or address changes then you know that the failing module is one of the ones just moved. By using several combinations of module movement you should be able to determine which module is failing. 3) Replacing modules If you are unable to use either of the previous techniques then you are left to selective replacement of modules to find the failure. 4) Avoiding allocation The printing mode for BadRAM patterns is intended to construct boot time parameters for a Linux kernel that is compiled with BadRAM support. This work-around makes it possible for Linux to reliably run on your average damaged RAM (or clearly panic if it cannot). For more information on BadRAM support for Linux, sail to http://home.zonnet.nl/vanrein/badram Sometimes memory errors show up due to component incompatibility. A memory DIMM/SIMM may work fine in one system and not in another. This is not uncommon and is a source of confusion. The components are not necessarily bad but certain combinations may need to be avoided. I am often asked about the reliability of errors reported by Mestest86. In the vast majority of cases errors reported by the test are valid. 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. All valid memory errors should be corrected. It is possible that a particular error will never show up in normal operation. However, operating with marginal memory is risky and can result in data loss and even disk corruption. You can be sure that Murphy will get you if you know about a memory error and ignore it. Memtest86 can not diagnose many types of PC failures. For example a faulty CPU that causes Windows to crash will most likely just cause Memtest86 to crash in the same way. 9) Execution Time ================== The time required for a complete pass of Memtest86 will vary greatly depending on CPU speed, memory speed and memory size. Here are the execution times from a Cleron-366 with 64MB of SDRAM: Test 0: 0:05 Test 1: 0:18 Test 2: 1:02 Test 3: 1:38 Test 4: 8:05 Test 5: 1:40 Test 6: 4:24 Test 7: 6:04 Total Time for Default tests: 23:16 Test 8: 12:30 Test 9: 49:30 Test 10: 30:34 Test 11: 3:29:40 Total Time for All tests: 5:25:30 10) Memory Testing Philosophy ============================ There are many good approaches for testing memory. However, many tests simply throw some patterns at memory without much thought or knowledge of the memory architecture or how errors can best be detected. This works fine for hard memory failures but does little to find intermittent errors. The BIOS based memory tests are useless for finding intermittent memory errors. Memory chips consist of a large array of tightly packed memory cells, one for each bit of data. The vast majority of the intermittent failures are a result of interaction between these memory cells. Often writing a memory cell can cause one of the adjacent cells to be written with the same data. An effective memory test should attempt to test for this condition. Therefore, an ideal strategy for testing memory would be the following: 1) write a cell with a zero 2) write all of the adjacent cells with a one, one or more times 3) check that the first cell still has a zero It should be obvious that this strategy requires an exact knowledge of how the memory cells are laid out on the chip. In addition there is a never ending number of possible chip layouts for different chip types and manufacturers making this strategy impractical. However, there are testing algorithms that can approximate this ideal strategy. 11) Memtest86 Test Algorithms ============================ Memtest86 uses two algorithms that provide a reasonable approximation of the ideal test strategy above. The first of these strategies is called moving inversions. The moving inversion test works as follows: 1) Fill memory with a pattern 2) Starting at the lowest address 2a check that the pattern has not changed 2b write the patterns complement 2c increment the address repeat 2a - 2c 3) Starting at the highest address 3a check that the pattern has not changed 3b write the patterns complement 3c decrement the address repeat 3a - 3c This this algorithm is a good approximation of an ideal memory test but there are some limitations. Most high density chips today store data 4 to 16 bits wide. With chips that are more than one bit wide it is impossible to selectively read or write just one bit. This means that we cannot guarantee that all adjacent cells have been tested for interaction. In this case the best we can do is to use some patterns to insure that all adjacent cells have at least been written with all possible one and zero combinations. It can also be seen that caching, buffering and out of order execution will interfere with the moving inversions algorithm and make less effective. It is possible to turn off cache but the memory buffering in new high performance chips can not be disabled. To address this limitation a new algorithm I call Modulo-X was created. This algorithm is not affected by cache or buffering. The algorithm works as follows: 1) For starting offsets of 0 - 20 do 1a write every 20th location with a pattern 1b write all other locations with the patterns complement repeat 1b one or more times 1c check every 20th location for the pattern This algorithm accomplishes nearly the same level of adjacency testing as moving inversions but is not affected by caching or buffering. Since separate write passes (1a, 1b) and the read pass (1c) are done for all of memory we can be assured that all of the buffers and cache have been flushed between passes. The selection of 20 as the stride size was somewhat arbitrary. Larger strides may be more effective but would take longer to execute. The choice of 20 seemed to be a reasonable compromise between speed and thoroughness. 12) Individual Test Descriptions =============================== Memtest86 executes a series of numbered test sections to check for errors. These test sections consist of a combination of test algorithm, data pattern and caching. The execution order for these tests were arranged so that errors will be detected as rapidly as possible. Tests 8, 9, 10 and 11 are very long running extended tests and are only executed when extended testing is selected. The extended tests have a low probability of finding errors that were missed by the default tests. A description of each of the test sections follows: Test 0 [Address test, walking ones, no cache] Tests all address bits in all memory banks by using a walking ones address pattern. Errors from this test are not used to calculate BadRAM patterns. Test 1 [Moving Inv, ones&zeros, cached] This test uses the moving inversions algorithm with patterns of only ones and zeros. Cache is enabled even though it interferes to some degree with the test algorithm. With cache enabled this test does not take long and should quickly find all "hard" errors and some more subtle errors. This section is only a quick check. Test 2 [Address test, own address, no cache] Each address is written with its own address and then is checked for consistency. In theory previous tests should have caught any memory addressing problems. This test should catch any addressing errors that somehow were not previously detected. Test 3 [Moving inv, 8 bit pat, cached] This is the same as test zero but uses a 8 bit wide pattern of "walking" ones and zeros. This test will better detect subtle errors in "wide" memory chips. A total of 20 data patterns are used. Test 4 [Moving inv, 32 bit pat, cached] This is a variation of the moving inversions algorithm that shifts the data pattern left one bit for each successive address. The starting bit position is shifted left for each pass. To use all possible data patterns 32 passes are required. This test is very effective at detecting data sensitive errors in "wide" memory chips. Test 5 [Block move, 64 moves, cached] This test stresses memory by using block move (movsl) instructions and is based on Robert Redelmeier's burnBX test. Memory is initialized with shifting patterns that are inverted every 8 bytes. Then 4MB blocks of memory are moved around using the movsl instruction. After the moves are completed the data patterns are checked. Because the data is checked only after the memory moves are completed it is not possible to know where the error occurred. The addresses reported are only for where the bad pattern was found. Since the moves are constrained to a 8MB segment of memory the failing address will always be lest than 8MB away from the reported address. Errors from this test are not used to calculate BadRAM patterns. Test 6 [Modulo 20, ones&zeros, cached] Using the Modulo-X algorithm should uncover errors that are not detected by moving inversions due to cache and buffering interference with the the algorithm. As with test one only ones and zeros are used for data patterns. Test 7 [Moving inv, ones&zeros, no cache] This is the same as test one but without cache. With cache off there will be much less interference with the test algorithm. However, the execution time is much, much longer. This test may find very subtle errors missed by tests one and two. Test 8 [Block move, 512 moves, cached] This is the same as test #5 except that we do a lot more memory moves before checking memory. Errors from this test are not used to calculate BadRAM patterns. Test 9 [Moving inv, 8 bit pat, no cache] This is the first extended test. By using an 8 bit pattern with cache off this test should be effective in detecting all types of errors. However, it takes a very long time to execute and there is a low probability that it will detect errors not found by the previous tests. Test 10 [Modulo 20, 8 bit, cached] This is the first test to use the modulo 20 algorithm with a data pattern other than ones and zeros. This combination of algorithm and data pattern should be quite effective. However, it's very long execution time relegates it to the extended test section. Test 11 [Moving inv, 32 bit pat, no cache] This test should be the most effective in finding errors that are data pattern sensitive. However, without cache it's execution time is excessively long. 13) Problem Reporting - Contact Information =========================================== Due to the growing popularity of Memtest86 I am being inundated by, questions, feedback, problem reports and requests for enhancements. Memtest86 is a side project and often my day job interferes with Memtest86 support. To help me keep up with this project, please use the following guidelines. Problems/Bugs: Before submitting a problem report please check the Known Problems section to see if this problem has already been reported. Be sure to include the version number and also any details that may be relevant. Memtest86 sometimes just dies with no hints as to what went wrong. Without any details it is nearly impossible to fix these failures. Fixing these problems will require debugging assistance on your part. There is no point in reporting these failures unless you have a Linux system and would be willing to assist me in finding the failure. Enhancements: If you would like to request an enhancement please see if is already on the Planned Features List before sending your request. All requests will be considered, but not all can be implemented. If you are be interested in contributing code please contact me so that the integration can be co-ordinated. Feedback: I have received a lot of feedback about the effectiveness of various tests. I am still interested in hearing about failures that only a single test was able to detect. Of course, gratitude, praise and cash are always accepted. Chris Brady, Email: cbrady@cray.com 14) Known Problems ================== Sometimes when booting from a floppy disk the following messages scroll up on the screen: X:8000 AX:0212 BX:8600 CX:0201 DX:0000 This the BIOS reporting floppy disk read errors. Either re-write or toss the floppy disk. Memtest86 has no support for multiple CPUs. Memtest86 should run without problems, but it will only use one CPU. Memtest86 can not diagnose many types of PC failures. For example a faulty CPU that causes Windows to crash will most likely just cause Memtest86 to crash in the same way. There have been numerous reports of errors in only tests 5 and 8 on Athlon systems. Often the memory works in a different system or the vendor insists that it is good. In these cases the memory is not necessarily bad but is not able to operate reliably at Athlon speeds. Sometimes more conservative memory timings on the motherboard will correct these errors. In other cases the only option is to replace the memory with better quality, higher speed memory. Don't buy cheap memory and expect it to work with an Athlon! Memtest86 supports all types of memory. If fact the test has absolutely no knowledge of the memory type nor does it need to. This not a problem or bug but is listed here due to the many questions I get about this issue. Changes in the compiler and loader have caused problems with Memtest86 resulting in both build failures and errors in execution. A binary image (precomp.bin) of the test is included and may be used if problems are encountered. 15) Planned Features List ========================= This is a list of enhancements planned for future releases of Memtest86. There is no timetable for when these will be implemented, if ever. - Option to allow printing of error information on an attached printer. - Option to write error information to a floppy disk. - Supply Memtest in RPM format. - Read and display RAM SPD information. 16) Change Log ============== Enhancements in v3.0 (22/May/2002) Provided by Eric Biederman Testing of more than 2gb of memory is at last fixed (tested with 6Gb) The infrastructure is to poll ecc error reporting chipset regisets, and the support has been done for some chipsets. Uses dynamic relocation information records to make itself PIC instead of requiring 2 copies of memtest86 in the binary. The serial console code does not do redundant writes to the serial port Very little slow down at 9600 baud. You can press ^l or just l to get a screen refresh, when you are connecting and unconnecting a serial cable. Netbooting is working again LinuxBIOS support (To get the memory size) Many bugfixes and code cleanup. Enhancements in v2.9 (29/Feb/2002) The memory sizing code has been completely rewritten. By default Memtest86 gets a memory map from the BIOS that is now used to find available memory. A new online configuration option provides three choices for how memory will be sized, including the old "probe" method. The default mode generally will not test all of memory, but should be more stable. See the "Memory Sizing" section for details. Testing of more than 2gb of memory should now work. A number of bugs were found and corrected that prevented testing above 2gb. Testing with more than 2gb has been limited and there could be problems with a full 4gb of memory. Memory is divided into segments for testing. This allow for frequent progress updates and responsiveness to interactive commands. The memory segment size has been increased from 8 to 32mb. This should improve testing effectivness but progress reports will be less frequent. Minor bug fixes. Enhancements in v2.8 (18/Oct/2001) Eric Biederman reworked the build process making it far simpler and also to produce a network bootable ELF image. Re-wrote the memory and cache speed detection code. Previously the reported numbers were inaccurate for intel CPU's and completely wrong for Athlon/Duron CPU's. By default the serial console is disabled since this was slowing down testing. Added CPU detection for Pentium 4. Enhancements in v2.7 (12/Jul/2001) Expanded workaround for errors caused by BIOS USB keyboard support to include test #5. Re-worked L1 / L2 cache detection code to provide clearer reporting. Fixed an obvious bug in the computation of cache and memory speeds. Changed on-line menu to stay in the menu between option selections. Fixed bugs in the test restart and redraw code. Adjusted code size to fix compilation problems with RedHat 7.1. Misc updates to the documentation. Enhancements in v2.6 (25/May/2001) Added workaround for errors caused by BIOS USB keyboard support. Fixed problems with reporting of 1 GHZ + processor speeds. Fixed Duron cache detection. Added screen buffer so that menus will work correctly from a serial console. The Memtest86 image is now built in ELF format. Enhancements in v2.5 (14/Dec/00) Enhanced CPU and cache detection to correctly identify Duron CPU and K6-III 1MB cache. Added code to report cache-able memory size. Added limited support for parity memory. Support was added to allow use of on-line commands from a serial port. Dropped option for changing refresh rates. This was not useful and did not work on newer motherboards. Improved fatal exception reporting to include a register and stack dump. The pass number is now displayed in the error report. Fixed a bug that crashed the test when selecting one of the extended tests. Enhancements in v2.4 The error report format was reworked for better clarity and now includes a decimal address in megabytes. A new memory move test was added (from Robert Redelmeier's CPU-Burn) The test sequence and iterations were modified. Fixed scrolling problems with the BadRAM patterns. Enhancements in v2.3 A progress meter was added to replace the spinner and dots. Measurement and reporting of memory and cache performance was added. Support for creating BadRAM patterns was added. All of the test routines were rewritten in assembler to improve both test performance and speed. The screen layout was reworked to hopefully be more readable. An error summary option was added to the online commands. Enhancements in v2.2 Added two new address tests Added an on-line command for setting test address range Optimized test code for faster execution (-O3, -funroll-loops and -fomit-frame-pointer) Added and elapsed time counter. Adjusted menu options for better consistency Enhancements in v2.1 Fixed a bug in the CPU detection that caused the test to hang or crash with some 486 and Cryrix CPU's Added CPU detection for Cyrix CPU's Extended and improved CPU detection for Intel and AMD CPU's Added a compile time option (BIOS_MEMSZ) for obtaining the last memory address from the BIOS. This should fix problems with memory sizing on certain motherboards. This option is not enabled by default. It may be enabled be default in a future release. Enhancements in v2.0 Added new Modulo-20 test algorithm. Added a 32 bit shifting pattern to the moving inversions algorithm. Created test sections to specify algorithm, pattern and caching. Improved test progress indicators. Created popup menus for configuration. Added menu for test selection. Added CPU and cache identification. Added a "bail out" feature to quit the current test when it does not fit the test selection parameters. Re-arranged the screen layout and colors. Created local include files for I/O and serial interface definitions rather than using the sometimes incompatible system include files. Broke up the "C" source code into four separate source modules. Enhancements in v1.5 Some additional changes were made to fix obscure memory sizing problems. The 4 bit wide data pattern was increased to 8 bits since 8 bit wide memory chips are becoming more common. A new test algorithm was added to improve detection of data pattern sensitive errors. Enhancements in v1.4 Changes to the memory sizing code to avoid problems with some motherboards where memtest would find more memory than actually exists. Added support for a console serial port. (thanks to Doug Sisk) On-line commands are now available for configuring Memtest86 on the fly (see On-line Commands). Enhancements in v1.3 Scrolling of memory errors is now provided. Previously, only one screen of error information was displayed. Memtest86 can now be booted from any disk via lilo. Testing of up to 4gb of memory has been fixed is now enabled by default. This capability was clearly broken in v1.2a and should work correctly now but has not been fully tested (4gb PC's are a bit rare). The maximum memory size supported by the motherboard is now being calculated correctly. In previous versions there were cases where not all of memory would be tested and the maximum memory size supported was incorrect. For some types of failures the good and bad values were reported to be same with an Xor value of 0. This has been fixed by retaining the data read from memory and not re-reading the bad data in the error reporting routine. APM (advanced power management) is now disabled by Memtest86. This keeps the screen from blanking while the test is running. Problems with enabling & disabling cache on some motherboards have been corrected. 17) Acknowledgments =================== The initial versions of the source files bootsect.S, setup.S, head.S and build.c are from the Linux 1.2.1 kernel and have been heavily modified. Doug Sisk provided code to support a console connected via a serial port. Code to create BadRAM patterns was provided by Rick van Rein. Tests 5 and 8 are based on Robert Redelmeier's burnBX test. Screen buffer code was provided by Jani Averbach. Eric Biederman provided all of the feature content for version 3.0 plus many bugfixes and significant code cleanup.