memtester - userspace utility to test for faulty memory subsystem

memtest <mem<B|K|M|G>> [runs] [-l | --log]

memtest is a userspace program to test for a faulty memory subsystem or faulty memory modules in Linux, or any Unix-like environment.

memtest takes the first supplied argument as the amount of memory to test. The value 'all means to test all available memory. A specific amount of memory can be supplied as a number, followed by a letter to indicate units: B or b - bytes K or k - kilobytes M or m - megabytes G or g - gigabytes

memtest used to assume megabytes if no letter was supplied. It now exits instead.

If memtest cannot allocate the amount of memory specified, it will keep trying with smaller amounts until it succeeds.

If the option -l (or --log) is given, memtest will log to the file memtest.log in addition to stderr. Any previous log will be overwritten. If memtest fails to open its logfile it will abort.

memtest will attempt to lock its pages into memory to increase the chances of testing a greater percentage of physical memory. This typically requires the program to be run as root. If it cannot lock its pages into memory due to a lack of permissions, it will issue a warning and continue with unlocked pages. If it fails to lock pages because there are insufficient pages of memory available to be locked, it will reduce its allocation and try again.

Note that if memtest runs with unlocked pages, it may start swapping. Since memtest spends virtually all of its time accessing memory, this will slow down its operation by several orders of magnitude. The best way to run memtest is to use the largest value of memory to test which will allow it to lock its pages into memory.

Simple -- just download, extract the tarball, and run make. I've only tested it with the GNU toolchain, but it may build with others as well.

0 if it runs to completion, or receives one of SIGINT, SIGTERM, or SIGQUIT.

-1 if it encounters an error and cannot run.

memtest will exit if it cannot allocate any memory, or if it attempts to log to a file and cannot open its logfile.

memtest 16m 2 Test 16MB of memory, run all tests twice, and log only to stderr. memtest 2G --log Test 2GB of memory, run until interrupted, and log to stderr and memtest.log. memtest 1g 4 --log Test 1GB of memory, run all tests four times, and log to stderr and memtest.log.

memtest.log -- log file in current directory.

If the machine you are testing on is an x86 clone, and you can afford to take the machine down for an extended period, the program memtest86 may be another option to consider. It is available at http://reality.sgi.com/cbrady_denver/memtest86/.

memtest by design is hard on the memory subsystem of a machine. This can make the machine quite sluggish; it would be a very poor idea to attempt to run memtest on a heavily loaded or shared machine except for testing purposes, with small allocations of memory.

Testing memory can be slow. Sample testing times for one complete run of tests follow. If you have other examples, please send them to me. Pentium 90MHz testing 24MB: ~30 minutes Sun UltraSparc 360MHz testing 1750MB: ~13 hours

The program prints a small amount of information about how it was invoked before running tests:

Successfully allocated 4194304 bytes. Aligning memory...settling on 4190208 bytes at 0x400b7000... Proceeding to lock pages...success. Starting tests...

memtest typically tests a slightly smaller amount of memory than is specified on the commandline. This is because it aligns its memory allocation to a page boundary before attempting to lock its pages into memory. This is a requirement on some Unix systems. With very small allocations of memory (typically only used during debugging of memtest), it may fail to align to a page boundary with a message similar to this:

Aligning memory...allocation too small to align to pagesize of 4096 bytes. Failed to get sufficient memory. Exiting...

If not run as root, the memlock will fail as follows:

Proceeding to lock pages...mlock failed: only root can lock pages. Continuing with unlocked pages. Results are less reliable.

Then, as the program runs through tests, it prints the current `run (cycle of tests) and test number and name. It also prints status information on the progress of the tests. This will look like the following:

Run 1: Test 1: Random value: Setting...Testing...Passed. Test 2: XOR comparison: Setting...Testing...Passed.

If one of the tests finds an error in memory, a message like the following will be printed:

FAILURE: 0x5aa0f5c5 != 0x5aa0f585 at offset 0x0067f837. Skipping to next test...

If the Stuck Address test finds a failure, it outputs a slightly different message, to remind the user that other tests are unreliable if an addressing problem exists:

FAILURE: possible bad address line at offset 0x004563f3.

At the end of each `run it will print a summary of that run as follows:

Run 1 completed in 114 seconds (2 tests showed errors).

When the program completes (is interrupted by a signal, or finishes its last run, when a limit is specified on the commandline), it will print an overall summary:

2 runs completed. 2 errors detected. Total runtime: 235 seconds. Exiting...

May or may not require GNU make, gcc or equivalent, etc. Please let me know if memtest fails to build in your environment.

The output examples in this manpage have fallen out of sync with the software in minor ways.

Bugs should be reported to <memtest@discworld.dyndns.org>.

If your problem is that memtest won't compile, please include some information about your system (basic hardware type, operating system type and version) and a log of the output of make clean; make all.

If memtest builds and runs, but you feel it does not run properly, please include the output log from memtest generated by the --log option.

memtest, running in user space, cannot test all of physical memory. The unswappable pages occupied by the kernel will not be tested. memtest will also be limited to whatever per-process/per-user limitations you have imposed in your system.

This software was written by Charles Cazabon <memtest@discworld.dyndns.org>, based on the version 1 sourcecode by Simon Kirby <sim@stormix.com>.

See the file CHANGELOG for details.