Hi,
I need to write a memory diagnosis ?program which will test each and
every location of SDRAM
to know whether its working properly or a bad location
What would be the best approach ??
If I want to test each location sequentially then How can I do it ? If
Base address is required then how to find it in my system??
regards
Santosh
On Sat, 2010-08-28 at 16:57 +0530, santosh wrote:
> Hi,
>
> I need to write a memory diagnosis program which will test each and
> every location of SDRAM
> to know whether its working properly or a bad location
>
> What would be the best approach ??
If you can, it's best to just use code other people have already
written :)
If you can reboot the computer to test the memory, Memtest86+ is a
well-known and very reliable tool which does just what you ask. You can
obtain it from http://www.memtest.org/
There's some work done on an in-kernel memory tester, but testing memory
while Linux is running is somewhat limited as there are sections of
memory that you can't overwrite during testing. Take a look at
CONFIG_MEMTEST and arch/x86/mm/memtest.c (which is currently only
capable of testing memory in early boot).
--
Calvin Walton <[email protected]>
On Tue, 2010-08-31 at 18:07 +0530, santosh wrote:
> hi Calvin,
>
> > There's some work done on an in-kernel memory tester, but testing memory
> > while Linux is running is somewhat limited as there are sections of
> > memory that you can't overwrite during testing. Take a look at
> > CONFIG_MEMTEST and arch/x86/mm/memtest.c (which is currently only
> > capable of testing memory in early boot).
> >
>
> I was just looking at "linux-source-2.6.27.48" but could not find
> "memtest.c" at the location you mentioned above:
>
> [root@localhost linux-2.6.27.48]# cd arch/x86/mm/
This code was moved fairly recently, although I don't remember exactly
when. In the kernel version you have, it should be present in
arch/x86/mm/init_64.c
(and is only available on the 64-bit x86 architecture).
Please check a newer kernel if you can, there's been some improvements
since.
--
Calvin Walton <[email protected]>