How to do memory(RAM) test when linux is running..?

[vinaybondade]

Hello,

My question is about linux in embedded systems.

I understand that normally Memory test or RAM test is done in bootloaders, but I would like to bring up the memory test routine when the kernel starts running and not in the boot loader.

More specifically, I will have some services running and interrupts enabled and the memory test should go on in the background without affecting the current executions happening in the system and the memory test will be doing just device test on entire RAM.

I thought of making a user space application which would open /dev/mem device file and then do a mmap on the physical address(0x80000000) where RAM is located. If I mmap as "shared" I would be corrupting the execution RAM as I need to write and check patterns to the RAM, if I mmap as "private" then the pattern will not be written back to the device file and might corrupt the RAM where the kernel is executing and hence will crash the system.

Is there any way that I can ask kernel if a page/frame has a valid virtual address being referenced to..? so that I can only test the RAM frames (4096 bytes) which are not under use and the RAM frames that were under use by the kernel will be tested in the bootloader when the next reboot happens. This way the system would be faster in response when memory test happens as the bootloader will not test the entire RAM and the most of the RAM will be tested in linux in background.

I need to figure out a way where I can check if a RAM frame is in use or not so that I can select the RAM frames to do the memory test.

Thanks,
Vinay

[Rubberman]

There is a package called memtester that will install the program of the same name on your system which can be run while the system is functioning (with caveats). Here is the manpage:

memtester(8)                 Maintenance Commands                 memtester(8)

NAME
       memtester - stress test to find memory subsystem faults.

SYNOPSIS
       memtester [-p PHYSADDR] <MEMORY> [ITERATIONS]

DESCRIPTION
       memtester  is an effective userspace tester for stress-testing the memory subsystem.  It is
       very effective at finding intermittent and non-deterministic faults.  Note that problems in
       other  hardware  areas (overheating CPU, out-of-specification power supply, etc.) can cause
       intermittent memory faults, so it is still up to you to  determine  where  the  fault  lies
       through normal hardware diagnostic procedures; memtester just helps you determine whether a
       problem exists.

       memtester will malloc(3) the amount of memory specified, if possible.  If  this  fails,  it
       will  decrease  the  amount of memory requested until it succeeds.  It will then attempt to
       mlock(3) this memory; if it cannot do so, testing will be slower and much  less  effective.
       Run memtester as root so that it can mlock the memory it tests.

       Note  that the maximum amount of memory that memtester can test will be less than the total
       amount of memory installed in the system; the operating system, libraries, and other system
       limits  take some of the available memory.  memtester is also limited to the amount of mem-
       ory available to a single process; for example, on 32-bit machines with more  than  4GB  of
       memory, memtester is still limited to less than 4GB.

       Note  that it is up to you to know how much memory you can safely allocate for testing.  If
       you attempt to allocate more memory than is available, memtester should  figure  that  out,
       reduce  the  amount  slightly, and try again.  However, this can lead to memtester success-
       fully allocating and mlocking essentially all free memory on the system --  if  other  pro-
       grams  are  running, this can lead to excessive swapping and slowing the system down to the
       point that it is difficult to use.  If the system allows allocation of more memory than  is
       actually available (overcommit), it may lead to a deadlock, where the system halts.  If the
       system has an out-of-memory process killer (like Linux), memtester or another  process  may
       be killed by the OOM killer.

       So choose wisely.

OPTIONS
       -p PHYSADDR
              tells  memtester  to  test  a specific region of memory starting at physical address
              PHYSADDR (given in hex), by mmap(2)ing /dev/mem.  This is mostly of use to  hardware
              developers, for testing memory-mapped I/O devices and similar.  Note that the memory
              region will be overwritten during testing, so it is not safe to specify memory which
              is  allocated  for the system or for other applications; doing so will cause them to
              crash.  If you absolutely must test a particular region of actual  physical  memory,
              arrange  to  have  that  memory allocated by your test software, and hold it in this
              allocated state, then run memtester on it with this option.

       MEMORY the amount of memory to allocate and test, in megabytes by default.  You can include
              a  suffix  of  B,  K,  M, or G to indicate bytes, kilobytes, megabytes, or gigabytes
              respectively.

       ITERATIONS
              (optional) number of loops to iterate through.  Default is infinite.

NOTE
       memtester must be run with root privileges to mlock(3) its pages.  Testing  memory  without
       locking the pages in place is mostly pointless and slow.

EXIT CODE
       memtester’s exit code is 0 when everything works properly.  Otherwise, it is the logical OR
       of the following values:

       x01    error allocating or locking memory, or invocation error

       x02    error during stuck address test

       x04    error during one of the other tests

AUTHOR
       Written by Charles Cazabon.

REPORTING BUGS
       Report bugs to <charlesc-memtester-bugs@pyropus.ca>.

COPYRIGHT
       Copyright © 2009 Charles Cazabon
       This is free software; see the file COPYING for copying conditions.  There is NO  warranty;
       not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

memtester 4                        July 2009                      memtester(8)

[vinaybondade]

Thank you for the reply. I need to test the entire RAM and have to be sure that Ram test happens in every reboot and it succeeds on the whole of RAM. (A std requiremnet for the project)

I have figured out a way to do the test in bootloader itself. The boot loader used is Redboot and the "version" command indicates the RAM addresses that are unused. So I run destructive RAM test for the unused part of RAM(I disable the data cache but the instruction cache is on and then run the RAM test from SDRAM itself). For the part of RAM that is used by Redboot I copy the RAM test code to internal RAM and execute from there, this test will copy the RAM contents, perform destructive test and copy back the original contents and then switch back to external SDRAM.

This way the test takes 4.5 seconds now which was taking 35 seconds before when the whole RAM test was getting executed from internal RAM.

Regards,
Vinay

[Rubberman]

Ah yes, the old relocate-and-execute-in-place. That's the standard behavior of the boot loader. Good solution, and generally there is enough room in the boot loader portion of the MBR to do what you want (cache disabling, etc). Elegant. One question, however; why don't you just set the BIOS to do full memory testing on startup instead, or is this an embedded project where that is not really an option?

[surendradhobale]

HI ,
According to vinay, he done with the S DRAM memory test in the boot loader. I want to test the memory and find out the time required to write and read of the Texas AM-335x series board.
It uses the ubootloader. Can anyone help me to how can write the program for the same in c?
or give the direction...

[Rubberman]

Unfortunately, the standard x86 boot loader is in x86 assembler, and the instructions you need are probably going to be in assembler as well. If the AM-335x series board is an ARM or other than x86 processor, then you will have to write it in the appropriate assembler or machine language. The only redeeming thing here is that the necessary instructions are usually only a couple of hundred bytes of machine code, assuming that the system firmware has the requisite instructions to bootstrap from.

[surendradhobale]

Its fine, but can we write any standlone program. In second state of u bootloader, which runs independantly and test memory and find out the time?

[Rubberman]

It should be possible, but you would have to structure and compile it in a manner that makes it non-dependent upon any outside functions or libraries, etc. I haven't done this with Linux and the Gnu compilers myself, so I can't tell you exactly how to do it without more research than I have the time for right now.