MemTest86 Technical Information
What's New in MemTest86 for the UEFI platform (Version 5 and later)?MemTest86 supports booting from both the newer UEFI platform and the traditional BIOS. When booting from UEFI, MemTest86 has access to additional services not available in BIOS including:
See the feature comparison page for a summary of the differences between the various editions of MemTest86. If UEFI is not supported on the system, the older v4 BIOS version is booted. MemTest86 can boot from a CD, USB flash drive or, with Linux systems, by the boot loader (for example, LILO or Grub). Any Windows, Linux or Mac system may be used to create the CD or USB flash drive. Once a MemTest86 boot disk has been created, it may be used on any x86 (PC/Mac) computer. MemTest86 (Site Edition) can also boot via network (PXE) boot for scalable provisioning of MemTest86 to multiple client machines in the LAN network. In this configuration, no disks are required; only a PXE Server and PXE boot enabled clients are required to support network boot. Back to topCreating a MemTest86 boot disk in WindowsTo create a MemTest86 bootable USB, CD or floppy in Windows, it is recommended that you download one of the Windows MemTest86 images. Note: There is no difference in the resulting MemTest86 boot disk created using either the Windows or Linux/Mac images; the difference is merely that the images are packaged in a way that it is more suited for the respective operating system (eg. zip vs tarball). Create a bootable CD-ROM:
Create a bootable USB Flash drive:
Create a bootable floppy (v4 only):
Creating a MemTest86 boot disk in Linux/MacTo create a MemTest86 bootable USB, CD or floppy in Linux/Mac, it is recommended that you download one of the Linux/Mac pre-compiled MemTest86 images. Note: There is no difference in the resulting MemTest86 boot disk created using either the Windows or Linux/Mac images; the difference is merely that the images are packaged in a way that it is more suited for the respective operating system (eg. zip vs tarball). Create a bootable CD-ROM:
Create a bootable USB Flash drive:
Create a bootable floppy (v4 only):
UsageBooting MemTest86 MemTest86 supports booting from both UEFI and BIOS systems. Most newer systems are able to run the UEFI version of MemTest86, but all systems should be able to boot the traditional BIOS version. To start MemTest86 insert the CD-ROM or USB flash drive into the appropriate drive and restart your computer. Note: If running on a UEFI system, the UEFI BIOS must be configured to boot from the device that MemTest86 is installed on. Most systems have an optional boot menu that is enabled be pressing a key at startup (often ESC, F9, F11 or F12) similar to the following:
If available use the boot menu to select the correct drive. You may see both the UEFI and BIOS as separate options. Please consult your motherboard documentation for details. On a Mac, you need to hold down the 'c' key while the computer is booting to boot from CD. To boot from USB, you need to hold down the ALT / Option key on the Mac keyboard while powering on the machine. Booting v5 or later in UEFI All MemTest86 images supports dual-booting of v4 (BIOS) and v5 or later (UEFI), depending on whether your system is configured to boot in UEFI or BIOS mode. If your system is booting v4, it is most likely that either:
If (1) is true, you system will not be able to boot MemTest86 v5 or later. You will need to upgrade to a new system that supports UEFI in order to run MemTest86 v5 or later. If (2) is true, you will need to go to the BIOS setup and change the necessary settings in order to boot from UEFI. The actual setting varies depending on the vendor but it is typically "Legacy Boot", "CSM" or "Compatibility Support Module", like the following screenshot for an ASUS system
Using a Serial Console For systems without video support, MemTest86 can run in serial console mode from both UEFI and BIOS systems. For MemTest86 v4, select option 5 from the menu to enable output to serial console. You will not need to do anything for MemTest86 v5 or later as it will automatically use the serial console, provided that the UEFI BIOS has been configured to redirect the console to the serial port. No GUI support is available when using the serial console so all test configurations must be done using the configuration file. Back to topPXE Network Booting (Site Edition only) MemTest86 (Site Edition only) supports network booting via PXE. In order to configure PXE booting of MemTest86, a DHCP/PXE server must be present on the network which distributes the MemTest86 boot image to PXE boot-enabled client machines. Network booting of MemTest86 has been tested successfully with the Linux-based CentOS 7 (DHCP + TFTP server) and Windows-based Serva PXE Server but other PXE servers should work as well. For step-by-step instructions, see 'Configuring a PXE Server on CentOS 7' or 'Configuring Serva for MemTest86 PXE Boot' in the MemTest86 User Guide. For others, consult the documentation for your DHCP/PXE server for configuration instructions. PXE Client Configuration Once the PXE server is configured, extract the files from the MemTest86 package to the appropriate directory for your PXE server configuration. In the PXE server settings, specify the boot image file to "BOOTX64.efi" for x86-64 client machines and "BOOTIA32.efi" for x86 client machines. On the client machine, the UEFI BIOS must support booting from the network. In the BIOS setup, ensure that the "UEFI Network Stack" and "IPv4 PXE Support' features are enabled, similar to the screenshot below.
The configuration file (mt86.cfg) is supported in PXE boot and can be used to configure and customize MemTest86. Likewise, report files are supported and can be uploaded to the PXE/TFTP server. Currently, logging is not supported when booting via network. Note: Chainloading MemTest86 via iPXE There is a known issue with using the iPXE open source network boot firmware to chainload the MemTest86 UEFI image. Because iPXE does not support TFTP uploads, report files cannot be saved to the TFTP server. However, the mt86.cfg configuration file can still be downloaded from the TFTP server. Back to topConfiguring MemTest86 When MemTest86 boots, a splashscreen is displayed with a 10 second countdown timer which when expires, automatically starts the memory tests with default settings. Pressing a key or moving the mouse shall stop the timer. To configure the memory tests, select 'Config' and the main menu is displayed. The main menu allows the user to customize the memory test settings such as the specific tests to execute, address range to test and which CPU(s) are used in testing.
The Main Menu is structured as follows:
(Pro and Site Edition only) Memory test parameters can also be set via a configuration file (mt86.cfg) that is loaded on startup, without the need to manually configure the memory tests every time MemTest86 is run. This is useful especially in testing environments where memory tests need to be executed in an automated fashion without user intervention. The mt86.cfg config file need to be placed into the EFI\BOOT folder on the USB drive. The following is an example of a MemTest86 configuration file:
TSTLIST=0,1,3,5,8
NUMPASS=3
ADDRLIMLO=0x10000000
ADDRLIMHI=0x20000000
CPUSEL=PARALLEL
CPUNUM=1
CPULIST=2,3
DISABLEMP=1
ENABLEHT=1
ECCPOLL=0
ECCINJECT=0
MEMCACHE=0
PASS1FULL=0
ADDR2CHBITS=12,9,7
ADDR2SLBITS=3,4
ADDR2CSBITS=8
LANG=ja-JP
REPORTNUMERRS=10
REPORTNUMWARN=10
AUTOMODE=1
SKIPSPLASH=1
EXITMODE=1
MINSPDS=0
SPDMANUF=Kingston
SPDPARTNO=9905402
BGCOLOR=BLUE
HAMMERPAT=0x10101010
HAMMERMODE=SINGLE
HAMMERSTEP=0x10000
CONSOLEMODE=1
BITFADESECS=300
MAXERRCOUNT=10000
TFTPSERVERIP=192.168.1.1
Test Results At the end of the test, a summary of the test results is displayed, as shown in the following screenshot:
Lowest Error Address:
The lowest address that where an error has been reported.
Highest Error Address:
The highest address that where an error has been reported.
Bits in Error Mask:
A mask of all bits that have been in error (hexadecimal).
Bits in Error:
Total bit in error for all error instances and the min, max and average
bit in error of each individual occurrence.
Max Contiguous Errors:
The maximum of contiguous addresses with errors.
ECC Correctable Errors:
The number of errors that have been corrected by ECC hardware.
Test Errors:
On the right hand side of the screen the number of errors for each test
are displayed.
The user may also save the results as an HTML test report to a file. The test report appearance is fully customizable in the pro and site license version. Here is an example of an HTML test report Back to topTroubleshooting Memory Errors Please see the Troubleshooting Memory Errors page on what to do when MemTest86 detects an errory with memory. Back to topExecution Time The time required for a complete pass of MemTest86 will vary greatly depending on CPU speed, memory speed and memory size. The pass counter increments after all of the selected tests have been run. Generally a single pass is sufficient to catch all but the most obscure errors. However, for complete confidence when intermittent errors are suspected testing for a longer period is advised. Back to topDetailed DescriptionsMemory 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 memory architecture or how errors can best be detected. This works fine for hard memory failures but does little to find intermittent errors. 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 attempts to test for this condition. Therefore, an ideal strategy for testing memory would be the following:
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. Back to topMemTest86 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:
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:
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. Back to topIndividual 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 cache setting. The execution order for these tests were arranged so that errors will be detected as rapidly as possible. 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. Test 1 [Address test, own address, Sequential] 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. This test is done sequentially with each available CPU. Test 2 [Address test, own address, Parallel] Same as test 1 but the testing is done in parallel using all CPUs and using overlapping addresses. Test 3 [Moving inversions, ones&zeros, Parallel] This test uses the moving inversions algorithm with patterns of all 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 is done in parallel using all CPUs. Test 4 [Moving inversions, 8 bit pattern] This is the same as test 3 but uses a 8 bit wide pattern of "walking" ones and zeros. This test will better detect subtle errors in "wide" memory chips. Test 5 [Moving inversions, random pattern] Test 5 uses the same algorithm as test 4 but the data pattern is a random number and it's complement. This test is particularly effective in finding difficult to detect data sensitive errors. The random number sequence is different with each pass so multiple passes increase effectiveness. Test 6 [Block move, 64 moves] 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 less than 8mb away from the reported address. Errors from this test are not used to calculate BadRAM patterns. Test 7 [Moving inversions, 32 bit pattern] 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 quite effective at detecting data sensitive errors but the execution time is long. Test 8 [Random number sequence] This test writes a series of random numbers into memory. By resetting the seed for the random number the same sequence of number can be created for a reference. The initial pattern is checked and then complemented and checked again on the next pass. However, unlike the moving inversions test writing and checking can only be done in the forward direction. Test 9 [Modulo 20, Random pattern] Using the Modulo-X algorithm should uncover errors that are not detected by moving inversions due to cache and buffering interference with the algorithm. Test 10 [Bit fade test, 2 patterns] The bit fade test initializes all of memory with a pattern and then sleeps for a few minutes. Then memory is examined to see if any memory bits have changed. All ones and all zero patterns are used. Test 11 [Random number sequence, 64-bit] This test is the same as Test 8, but native 64-bit instructions are used. Test 12 [Random number sequence, 128-bit] This test is the same as Test 8, but native SIMD (128-bit) instructions are used. Test 13 [Hammer Test] The row hammer test exposes a fundamental defect with RAM modules 2010 or later. This defect can lead to disturbance errors when repeatedly accessing addresses in the same memory bank but different rows in a short period of time. The repeated opening/closing of rows causes charge leakage in adjacent rows, potentially causing bits to flip. This test 'hammers' rows by alternatively reading two addresses in a repeated fashion, then verifying the contents of other addresses for disturbance errors. For more details on DRAM disturbance errors, see Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors by Yoongu Kim et al. Starting from MemTest86 v6.2, potentially two passes of row hammer testing are performed. On the first pass, address pairs are hammered at the highest possible rate. If errors are detected on the first pass, errors are not immediately reported and a second pass is started. In this pass, address pairs are hammered at a lower rate deemed as the worst case scenario by memory vendors (200K accesses per 64ms). If errors are also detected in this pass, the errors are reported to the user as normal. However, if only the first pass produces an error, a warning message is instead displayed to the user.Back to top Recover disk space on a flash driveWe have had a few users wondering how to get back the space on a USB drive once they have finished using MemTest86. The problem stems from the fact that the Windows Disk Management function doesn't allow for wiping or re-partitioning of USB flash drives. You can find the steps needed to reformat a USB flash drive to full capacity here. Back to topHelp improve MemTest86
We are always looking for ways to improve MemTest86 for our users. Please send any general suggestions to
Translating MemTest86 to your language Since MemTest86 v6, we have added support for allowing the user to select the language to use in MemTest86. Currently, the following languages are supported:
If your language is not available for selection, or would like to generously provide translations for the benefit of other users, you may download the following string file that contains all the strings in the program. MemTest86 localization string file Please follow the instructions in the file on how to provide translations for the text. Any translated text we receive may be included in the next version of MemTest86, with appropriate credit given. Acknowledgments Translation work performed by Freelancer members: GauthierC (French), daufenbach (German), Kentaro Ide (Japanese), tomhu (Chinese). Spanish translations provided by Gabriel Barrandeguy of GabakTech. Portuguese translations provided by Siael Carvalho. Czech translations provided by Michal Waclawik of ASUS Czech Service (ACZS). Italian translations provided by Stefano Ronchi. Catalan translations provided by Elvis Gallegos Trias. Russian translations provided by Victor Lutz. Back to top |
 |
