MemTest86 User Guide V4.x BIOS
MemTest86 User Guide V4.x BIOS
MemTest86 User Guide V4.x BIOS
Version 4.3
Page 1
Table of Contents
1 Introduction.............................................................................................................................................3 1.1 Memory Reliability.......................................................................................................................3 1.2 Memtest86 Overview....................................................................................................................3 1.3 Compatibility.................................................................................................................................3 2 Setup and Use..........................................................................................................................................4 2.1 Boot-disk Creation using Windows...............................................................................................4 2.2 Boot-disk Creation Using Linux...................................................................................................5 2.3 Building Memtest86 from source..................................................................................................6 2.4 Using Memtest86...........................................................................................................................7 2.5 Runtime Configuration Options....................................................................................................8 2.6 Startup (boot) Options...................................................................................................................9 2.7 Troubleshooting Memtest86 Problems with Boot Trace.............................................................10 3 Repairing Memory Faults......................................................................................................................11 3.1 Anti-Static Handling Procedures.................................................................................................11 3.2 Re-Seating Memory Modules......................................................................................................11 3.3 Replacing Modules......................................................................................................................11 3.4 Error Validity...............................................................................................................................12 4 Over Clocking.......................................................................................................................................13 4.1 Background..................................................................................................................................13 4.2 Operating Margins.......................................................................................................................13 4.3 Using Memtest86 for Over Clocking..........................................................................................13 Appendices...............................................................................................................................................16 Appendix A.Technical Information...................................................................................................16 A.1 Memory Testing Philosophy................................................................................................16 A.2 Memtest86 Test Algorithms.................................................................................................16 A.3 Individual Test Descriptions................................................................................................17 A.4 Error Display Information....................................................................................................19 A.5 Serial Console......................................................................................................................20 Appendix B.Licensing.......................................................................................................................21 Appendix C.Product Support.............................................................................................................22 C.1 Known Problems..................................................................................................................22 C.2 Enhancements......................................................................................................................22 Appendix D.Change Log...................................................................................................................23 Appendix E.Acknowledgments.........................................................................................................27
Page 2
1 Introduction
1.1 Memory Reliability
Properly functioning memory is critical for reliable operation of a PC or laptop. Few computer users fully understand the risks associated with memory errors. Because PCs typically do not have any mechanisms for detecting memory errors, confusing and potentially disastrous consequences can result from these undetected memory problems. Memory errors will often cause erratic behavior with software applications that can mysteriously fail. The most serious risk from memory errors, however, is corruption of data that manages how information is stored on disk. In most cases, this type of corruption will cause one or more files to be lost. There are cases where a memory error can cause the loss of the entire contents of your hard disk. Periodic testing of memory with a rigorous and thorough memory test will greatly reduce the risk of problems and data loss due to memory errors.
1.3 Compatibility
Memtest86 is designed to work with all processors using the Intel/AMD x86 and X86_64 architecture. For 64 bit CPUs, Memtest86 currently executes in 32 bit mode using PAE. For 32 bit CPUs, testing is limited to 64 GB. 64 bit CPUs running MemTest86 executes in long mode which allows for testing of up to 8 TB of memory. CPUs executing in 32 bit mode can test a maximum of 2 GB of memory at a time. This 2 GB window is then advanced, allowing for all of memory to be tested. A native 64 bit implementation is planned. Starting with version 4.0 Memtest86 is multi-threaded and is able to concurrently use multiple CPUs to test memory. It will function properly with any number of CPUs but is currently configured to use a maximum of 32 CPUs for testing. Memtest86 is able to test all types of memory. There is no need for Memtest86 to know what type of memory it is testing. Memtest86 attempts to detect and display information about the hardware it is testing but this information is not used during testing. Since Memtest86 is a standalone program it does not require any operating system support for execution. It can be used with any PC regardless of what operating system, if any, is installed.
Page 3
Page 5
Page 6
Note: The BIOS must be configured to boot from the device that Memtest86 is installed on. Newer computers have an optional boot menu that is enabled be pressing a key at startup (often ESC, F9, F11 or F12). If available use the boot menu to select the correct drive. With older computers the boot sequence must list the drive used to load Memest86 before any other bootable media (i.e. a hard disk where Windows is installed). Most systems will be configured with a suitable boot sequence. If not you can reconfigure the boot sequence using the BIOS settings. Please consult your motherboard documentation for details. When Memtest86 starts it displays details about the system configuration and then begins testing. Memtest86 executes a repeating cycle of tests. Testing will continue to run until the program execution is interrupted (by pressing the ESC key or pressing the reset button). There is no set time for how long the test should be run. The following is an example of the Memtest86 screen.
Memtest86 executes a series of numbered test sections to check for errors. The execution order for these tests has been arranged so that errors will be detected as rapidly as possible. The pass counter increments each time that all of the tests have been run. The first pass is abbreviated to find errors more quickly. Subsequent passes execute longer and will be more thorough. Generally a single pass is sufficient to detect all but the most obscure errors. For complete confidence in cases where intermittent errors are suspected, testing for a longer period is advised. The time required for a complete pass of Memtest86 will vary greatly
Copyright 2013 Passmark Software Page 7
depending on CPU speed, memory speed and memory size. If memory errors are detected they will be displayed on the lower half of the screen. The default error reporting mode will display a detailed summary of all errors. If Memtest86 runs multiple passes without errors you can be certain that your memory is functioning properly. Other problems (hardware or software) may exist but at least you can eliminate memory as a culprit. In addition the CPU must work properly to run Memtest86 so successful execution implicitly assures that your CPU is also functioning properly. 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.
The runtime configuration commands allow the user to adjust the following settings. (1) Test Selection - Individual tests may be selected for execution or the current test may be skipped. When a failure has been identified it is much faster to troubleshoot by running only the failing test. (2) Address Range - With this option memory testing may be restricted to a selected portion of memory. This is also useful to speed up the troubleshooting process by testing only the failing portion of memory. (3) Error Report Mode - The error report mode may be changed to provide different types of error information. The default Error Summary mode provides all of the details required for diagnosing memory problems. However, other error reporting modes are available. "BadRAM patterns may be used with Linux systems to map out bad memory blocks. (4) CPU Selection Mode This option controls how CPUs are selected for testing. The options are All, Round Robin and Sequential. With Round Robin CPUs are selected in round robin fashion for each test. With the Sequential option all available CPUs are
Copyright 2013 Passmark Software Page 8
used for each test. (5) Refresh Screen - Redraws the screen when the display becomes garbled. (6) Restart Test Restarts test with default settings. (7) Miscellaneous Options Enable and disable runtime options. Currently only two options are available, One Pass and Boot trace. The One Pass feature runs the complete test once and then exits, but only if there were no errors. This provides a convenient method for unattended testing. The Boot Trace option is a debugging tool that is primarily designed for troubleshooting startup problems, but may be enabled at anytime. A help bar is displayed at the bottom of the screen with the following options. Keyboard Assignment ESC C SP (Spacebar) Description Exits the test and does a warm restart via the BIOS Enter the configuration menu Set scroll lock (Stops scrolling of error messages) Note: Memory testing is suspended when the scroll lock option is set and the scrolling display region is full. CR (Enter) Clear scroll lock (Enables error message scrolling)
Pass Enables the One Pass option. This feature runs the complete test once and then exits, but only if there were no errors. This provides a convenient method for unattended testing. One Pass may also be enabled via an on-line command. The syntax is onepass and there are no additional options.
Btrace
Enables the boot trace option and is used to diagnose test failures please see section 2.7 for details. The syntax is btrace and there are no additional options.
Maxcpus
Set the maximum number of CPU's to start. This is primarily a troubleshooting option. Setting maxcpus to one skips all code related to finding and starting additional CPUs. The syntax is maxcpus=N where N = 1 to 31.
Test
List Allows for execution on a subset of the normal test sequence. The syntax is tstlist=list where list is a comma separated list of test numbers to run (do not include spaces). Example: tstlist=1,4,5,7
CPU
Mask A mask of CPU numbers that are started and enables. A 32 bit mask is specified with a 1 set for each CPU that will be enabled. CPU 0 cannot be disabled and will be enabled regardless of the mask. The syntax is cpumask=N where N is a 32 bit hexadecimal number with or without a 0x prefix. Example: cpumask=0x55555555 enables all
Copyright 2013 Passmark Software Page 9
Used to setup serial console parameters. The syntax is console=ttySn,baudPL where n = serial port number (0 or 1), baud = baud rate, P = parity setting (N, O or E) and L is the number of bits (7 or 8). Example: console=ttyS0,9600e8 uses port 0 at 9600 baud, even parity and 8 bits. The standard Memtest86 media images provided use Syslinux for booting and allow for boot options to be specified interactively. At the boot: prompt type memtest followed by any of the above options. Multiple options may be specified separated by spaces. For example memtest onepass tstlist=1,6,7,8 will start the test with the One Pass option enabled and execute tests 1,6,7 and 8.
module in order to locate the failing one. Using the guidelines in your motherboard manual to maintain a working configuration selectively remove modules from the system and rerun Memtest86 to find the bad module(s). Be sure to carefully note which modules are in the system when the test passes and fails. In most cases memory failures will be due to a faulty memory module and replacing the module will resolve the problem. However, the motherboard affects memory operation and may also cause memory errors. There are instances where only a particular combination of memory and motherboard will cause errors. This is typically due to the memory not being of sufficient quality and speed to keep up with the motherboard. This memory may function properly when installed in a less demanding motherboard. When errors are only detected by test #5 it is usually due to memory not being fast enough to work properly with the motherboard. More conservative memory timing BIOS settings (if supported) may resolve these problems. Otherwise higher quality memory may be required, or possibly the motherboard may need to be replaced.
Page 12
4 Over Clocking
4.1 Background
Memtest86 is an invaluable tool for over clocking and may be used to increase your systems performance and reliability. Many shy away from over clocking fearing that it will make their PC less reliable. With a proper procedure, fine tuning your system timings is safe and in some cases will even improve reliability. Before embarking on over clocking one must understand the concept of margins or margin for error.
1. Before attempting to over clock you need to know what system parameters your motherboard will allow you to adjust and how they are adjusted. Some motherboards will allow all useful parameters to be adjusted while others do not allow for any adjustment. Consult your motherboard manual for details. Some of the parameters that may be available are:
System clock rate CPU clock multiplier Memory timing Memory clock multiplier CPU voltage Memory voltage
2. You need to know how to reset the CMOS to factory settings. It is common when over clocking to end up with settings that will not run the BIOS. When the parameters are set via CMOS the only way to recover is to reset the CMOS to the factory configuration. For some motherboards this is accomplished by removing a jumper. Other will require removal of the CMOS backup battery. Make sure that you know how to recover before starting. 3. Before adjusting any parameters, run Memtest86 for a full pass to establish a baseline. Record the memory bandwidth and CPU clock frequency for the default configuration. 4. Typically the best place to start is with the system clock rate. Increase the clock rate in fairly small increments (2-4 MHz) and then run at least a partial pass of Memtest86. Running at least 15% of tests 1-5 should be the minimum amount of testing for each iteration. Continue increasing the clock rate until you get a failure. Take your time and take good notes. For each step be sure that you record the memory bandwidth reported by Memtest86. Some BIOS's automatically adjust memory timings according to clock rate. You may find that by increasing the clock rate, memory performance will decrease. Once you find a failure back off on the clock rate until you find the point at which you get errors. Once you find the point at which memory errors occur back the clock off one step and run a full pass of Memtest86 to confirm the operational limit. In some cases the CPU will hang (stop responding) before memory errors are detected. 5. Some motherboards will allow you to adjust memory timing. Memory timings are typically listed as 4 values separated by hyphens. However, some motherboards only offer choices like fast, faster and fastest. There are two strategies for adjusting memory timing. If memory errors are detected before the CPU exhibits problems then slower memory timing may be used to allow a higher system clock rate to be used. The second strategy is to use faster memory timings to get more memory bandwidth without increasing the system clock rate. It is impossible to know which values will effect errors. Some of the memory timings will affect memory bandwidth and others will not. Be sure to record the reported memory bandwidth for each parameter change. 6. If in step 4 the CPU hangs before memory errors appear then the CPU has less margin for error than the memory. If available you may want to try reducing the CPU multiplier and then continue to increase the system clock until either the CPU stops or memory errors occur. This is helpful if memory timings are not adjustable or are ineffective.
Copyright 2013 Passmark Software Page 14
7. CPU and memory voltages are adjustable on some motherboards and increasing them may allow you to run at higher speeds. In particular higher CPU voltages tend to be quite effective for over clocking. However, higher voltages also mean higher temperatures so be sure that you have plenty of case cooling and an effective CPU cooler. Use carefully. 8. Some motherboards allow you to use a system clock multiplier for memory. The default is usually 1:1, or in other words the system and memory clock rates will be the same. This setting is only useful when the memory and CPU operational limits are significantly different and can not be brought into balance using the techniques listed above. Once you have established the operational limits of your system then you need to select settings that allow for a reasonable margin for error. Do not be tempted to use the maximum settings! A margin of 3% to 6% is recommended for reliable operation. The easiest way to add operational margin is to simply reduce the system clock rate by 3% to 6% from the maximum setting that functioned properly. In many cases the operational limits for the CPU and memory will be different. For example you can get more CPU speed by reducing memory settings. Or you can get more memory performance by reducing the CPU multiplier. For these cases you will need to choose a compromise. Both memory bandwidth and CPU clock rate are important so don't be tempted to only optimize for one or the other. Memtest86 provides good assurance of reliable memory operation when over clocking. Even when a dramatic increase in memory bandwidth is achieved. As long as Memtest86 does not report errors and appropriate margins have been applied then you should not hesitate to fully maximize memory timings. However, some caution must be exercised for system clock rate increases. With most motherboards the clock rate for the PCI and AGP busses are based on the system clock. Generally these busses will have no problem running at somewhat higher rates. Memtest86 does not test PCI or AGP and do not provide any assurance that anything other than the CPU and memory are working properly. Sadly there is currently no safe way to determine the operational limits for PCI and AGP and therefor there is no way to assure that there are appropriate margins. Unless your motherboard is able to independently establish the frequency of PCI and AGP busses you should be careful about running with large (more than 15%) increases in the system clock. In addition running your CPU at higher frequencies will generate more heat. Small frequency increases will generally be fine with the installed CPU cooler. Larger increases in the system clock rate may necessitate a larger, more effective CPU cooler.
Page 15
Appendices
Appendix A.Technical Information
Appendix A contains technical information from the Memtest86 README file that was previously released under the Gnu Public License (GPL). This section provides additional background information and technical information that may be useful for advanced users.
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 called 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 steps 2-5 2. write every 20th location with a pattern 3. write all other locations with the patterns complement 4. repeat 1b one or more times 5. 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.
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. 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. A total of 20 data patterns are used. Test 5 [Moving inversions, random pattern] This test uses the same algorithm as test 3 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. A total of 60 patterns are used. The random number sequence is different with each pass so multiple passes increase effectiveness. Test 6 [Block move] 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 an 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 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 generator the same sequence of numbers are 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. A sequence of 6 32 bit random patterns are used. Test 10 [Bit fade test, 2 patterns] The bit fade test initializes all of memory with a pattern and then sleeps for 5 minutes. Then memory is examined to see if any memory bits have changed. All ones and all zero patterns are used.
Copyright 2013 Passmark Software Page 18
When the individual error reporting mode is selected the following information is displayed. An error message is only displayed for errors with a different address or failing bit pattern. All displayed values are in hexadecimal.
Label Tst: Failing Address : Good: Bad: Err-Bits: Count: Test number Failing memory address Expected data pattern Failing data pattern Exclusive or of good and bad data (this shows the position of the failing bit(s)) Number of consecutive errors with the same address and failing bits Page 19 Description
Page 20
Appendix B.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.
Page 21
The software version. A detailed description of the problem and how to reproduce it. A copy of the result files / log files (if available). Details of how we may be able to contact you.
C.2 Enhancements
Please send enhancement requests to: [email protected] All requests will be considered, but not all can be implemented
Page 22
Fixed incorrect progress calculation for test 0 Fixed incorrect memory size due to bug with memory map when the e820 entry size member is 0 Fixed incorrect number of CPU's found due to duplicate entries in the MADT Changed the method used to search for processors to searching the APIC MADT first, then search the MP spec table (as opposed to vice versa). The MP spec table has largely been deprecated. Fixed incorrect progress calculation for test 4 Fixed potential false positives in parallel mode caused by overlapped/unaligned memory chunk allocations per CPU Fixed program freeze when selecting test 0 or 1 when running in non-parallel mode Memory bandwidth is now measured for one CPU (as opposed to a total for all CPUs) Fixed crash when attempting to boot a hyperthread reported by MADT Restored the Start only one CPU boot option Fixed bug with Test 6 (Block Move Test) not testing the end of a memory segment correctly Removed unnecessary boot options in menu Changed default CPU selection mode to round robin. Running all CPUs at once has been shown to cause false positives on a number of systems. Fixed a bug that could cause the program to go into a tight loop that could not be escaped when setting certain memory ranges to test. Fixed a bug displaying the memory location of individual errors. The values after the decimal point in the MB readout were incorrect. Fixed a bug in configuring upper and lower memory limits, previously lower limits equal or grater than 2gb would not work, as well as some other more obsucre configurations. Added a misc option to display the systems memory map. Fixed a bug that would cause the number of passes to not correctly reset after changing the selected tests. Added missing source code to some of the download packages.
Page 23
Fixed a bug in test 8 causing a single error to cascade into multiple errors. Fixed a bug causing the average error bits to be incorrect once the errors had maxed out at 65k Fixeda bug preventing test 10 to be selected as a single test to run. Fixed bug displaying individual test error counts. Fixed bug making overall errors 10x what they should be. Fixed issues with USB keyboards. The USB keyboard functionality is memory mapped into a portion of low memory on some (maybe many) machines, typing on a USB keyboard changes some values in RAM as the key presses are stored in memory as you type. This can cause the keyboard to become unresponsive during testing or input from the keyboard to generate errors in the tests. Fixed crash when configuring memory ranges. Changing the meory range during the first test, or changing the memory range multiple times during later tests could cause the current test number to become negative, triggering a crash. Fixed highest error address not reporting correctly on error. Fixed error counters overflowing and reseting to 0 after too many errors. Fixed max contiguous error reporting. Cleaned up some UI text. The Windows USB package now includes ImageUSB to make creating Memtest86 USB drives easier. Added a new boot trace option that single steps through the testing process and displays messages and data that is valuable in diagnosing problems with test execution. A large number of trace points have been added in key portions of the code (in particular SMP startup routines) to provide visibility of obscure failures. This feature will allow non-technical users to provide troubleshooting data for better test stability. Added a new One Pass feature. This feature runs the complete test once and then exits, but only if there were no errors. This provides a convenient method for unattended testing. One Pass may be enabled via a boot option or via an on-line command. Images for CD, USB key and Floppy disks now use Syslinux for booting and include a variety of standard options and two previous versions of Memtest86. The new boot time options may be specified at the boot prompt. A feature has been added to allow customization of the list of tests to be run. The test list may be specified via a boot option or via an on-line command. A feature has been added to restrict specific CPUs that are to be used for testing. The maximum number of CPUs may be specified or a 32 bit CPU mask may be specified. These are enabled with boot options.
Page 24
A number of problem with use of on-line commands when testing with more than one CPU have been fixed. A selection of boot time parameters are were added. These options enable boot tracing, the One Pass feature, limit the maximum number of CPUs to use, specify a CPU mask to select CPUs to be used and setup serial console parameters. Improved and extended CPU identification routines. Newer CPUID based method is now used to determine cache sizes for Intel CPUs for better accuracy and supportability. Routines for calculating cache and memory speeds have been reworked for better accuracy. An overflow problem has been fixed that resulted in no memory speed being reported for CPUs with large L3 caches. Fixed some errors in the crash reporting routines. Misc minor fixes and code cleanup. Full support for testing with multiple CPUs. All tests except for #11 (Bit Fade) have been multithreaded. A maximum of 16 CPUs will be used for testing. CPU detection has been completely re-written to use the brand ID string rather than the cumbersome, difficult to maintain and often out of date CPUID family information. All new processors will now be correctly identified without requiring code support. All code related to controller identification, PCI and DMI has been removed. This may be a controversial decision and was not made lightly. The following are justifications for the decision: 1. Controller identification has nothing to do with actual testing ofmemory, the core purpose of Memtest86. 2. This code needed to be updated with every new chipset. With the ever growing number of chipsets it is not possible to keep up with the changes. The result is that new chipsets were more often than not reported in-correctly. In the authors opinion incorrect information is worse than no information. 3. Probing for chipset information carries the risk of making the program crash. 4. The amount of code involved with controller identification was quite large, making support more difficult.
Removing this code also had the unfortunate effect of removing reporting of correctable ECC errors. The code to support ECC was hopelessly intertwined the controller identification code. A fresh, streamlined implementation of ECC reporting is planned for a future release. A surprising number of conditions existed that potentially cause problems when testing more than 4 GB of memory. Most if not all of these conditions have been identified and corrected. A number of cases were corrected where not all of memory was being tested.
Page 25
For most tests the last word of each test block was not tested. In addition an error in the paging code was fixed that omitted from testing the last 256 bytes of each block above 2 GB. The information display has been simplified and a number of details that were not relevant to testing were removed. Memory speed reporting has been parallelized for more accurate reporting for multi channel memory controllers. This is a major re-write of the Memtest86 with a large number of minor bugfixes and substantial cleanup and re-organization of the code. Limited support for execution with multiple CPUs. CPUs are selected round-robin or sequential for each test. Support for additional chipsets. (from Memtest86+ v2.11). Additions and corrections for CPU detection including reporting of L3 cache. Reworked information display for better readability and new information. Abbreviated iterations for first pass. Enhancements to memory sizing. Misc fixes and code cleanup A new error summary display with error confidence analysis Display of memory module information (from Memtest86+ v1.70) Relocated testing reworked to overlap main testing for better error detection Support for additional chipsets. (from Memtest86+ v1.70) Additions and corrections for CPU identification Misc bug fixes and code cleanup Added support for additional chipsets. (from Memtest86+ v1.60) Changed Modulo 20 test (#8) to use a more effective random pattern rather than simple ones and zeros. Fixed a bug that prevented testing of low memory. Added an advanced menu option to display SPD info (only for selected chipsets). Updated CPU detection for new CPUs and corrected some bugs. Reworked online command text for better clarity. Added a fix to correct a Badram pattern bug.
Page 26
Appendix E.Acknowledgments
Memtest86 was developed by Chris Brady with the resources and generous assistance of individuals and sources listed below: 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 is 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. Major enhancements to hardware detection and reporting in version 3.2, 3.3 and 3.4 provided by Samuel Demeulemeester (from Memtest86+ v1.11, v1.60 and v1.70).
Page 27