Testing memory cell by cell, and a specific cell ?

  • Thread starter Thread starter Skybuck Flying
  • Start date Start date
S

Skybuck Flying

Hello,

I would like to have a memory test which tests each memory cell by cell.

So it runs from cell 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, etc

It reads and writes each cell at least once.

When it finds a cell corrupted it halts the program and shows which cell is
corrupted.

Then I also need a command line to immediately test this cell again to see
if it's truely damaged, so for example memory cell 5 was maybe damaged:

MemTest 5

Which tool can do this ?

Bye,
Skybuck.
 
Skybuck said:
Hello,

I would like to have a memory test which tests each memory cell by cell.

So it runs from cell 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, etc

It reads and writes each cell at least once.

When it finds a cell corrupted it halts the program and shows which cell is
corrupted.

Then I also need a command line to immediately test this cell again to see
if it's truely damaged, so for example memory cell 5 was maybe damaged:

MemTest 5

Which tool can do this ?

Bye,
Skybuck.
Click to expand...

Memtest86+ from memtest.org is a program for testing memory.
It is available for floppy disc, or the ISO9660 version can be
burned to a CD (for example, using Nero). The source
for the memtest86+ code is also available, and I was able to
alter the source a couple of years ago, to do a custom test
on my other computer (measure memory bandwidth at various
addresses in the address space).

There is a "Pause" function, so you can stop the error screen
from scrolling, and that makes it easier to read the error
output. For example, just recently, a stick of Ballistix PC3200
CAS2 memory failed on my current computer, and I used memtest86+
to determine one chip on the module had gone entirely bad.

Paul
 
Hello,

I would like to have a memory test which tests each memory cell by cell.

So it runs from cell 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, etc

It reads and writes each cell at least once.

When it finds a cell corrupted it halts the program and shows which cell is
corrupted.
Click to expand...

If it's just a write-read-compare sequence for every individual
"cell", it may not detect a problem for a number of reasons. Even when
there's no memory at the address since the data can get buffered in
hardware.
Then I also need a command line to immediately test this cell again to see
if it's truely damaged, so for example memory cell 5 was maybe damaged:

MemTest 5

Which tool can do this ?
Click to expand...

I'm not aware of such a tool, but there're plenty of memory checkers.
The old DOS CheckIt had decent memory checking algorithms. Maybe this
one will suit you: http://www.memtest86.com/

Alex
 
Hello,

I would like to have a memory test which tests each memory cell by cell.

So it runs from cell 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, etc

It reads and writes each cell at least once.

When it finds a cell corrupted it halts the program and shows which cell
is corrupted.

Then I also need a command line to immediately test this cell again to
see if it's truely damaged, so for example memory cell 5 was maybe
damaged:

MemTest 5

Which tool can do this ?

Bye,
Skybuck.
Click to expand...

You truly are a ****wit. Such a test is practically useless.
 
In alt.lang.asm Skybuck Flying said:
I would like to have a memory test which tests each memory cell
by cell. So it runs from cell 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
10, 11, 12, etc It reads and writes each cell at least once.
Click to expand...

Memory testing is an important subject. Different bit
patterns provoke different types of failures.

Personally, I have always used Chris Brady's memtest86 for
exhaustive testing (it tests every cell, then moves itself
and tests its previous location). But it is not as intense
(high bandwidth) as I would like to provoke bus and latch
errors. For this I use my own `burnMMX` [needs updating].


-- Robert author `cpuburn` http://pages.sbcglobal.net/redelm
 
You truly are a ****wit. Such a test is practically useless.
Click to expand...


You must need the ad-hominem because you have no better argument.

Memory testing is _extremely_ important in the [homebuilt]
PC world where ECC is only rarely used. If you look at the
server world, memory failures (presumably indicated by ECC
logs) are surprisingly common, just after hard disks and PSUs.

There are uncountable variations in components: memory
modules, motherboards, power supplies that can impact memory
reliability. Sure the modules are tested by special-purpose
intense machines. But that is no assurance of system performance.
I have seen errors in the 1 per two hour range. These are would
usually get blamed on the OS.

If they are working responsibly, the first tier PC mfrs (Dell,
HPaq, ...) should be exhaustively testing their base model
designs and some sampling of line production. Then they rely
on statistics for quality assurance of their production runs.
Unit testing let alone burn-in costs too much time [money].

In addition to the usual advantages of customizability and
often lower cost, a user-built PC can be more _RELIABLE_ than
name-brand if the builder pays attention to all the hidden
factors like case airflow, grounding, cable routing, etc.
The testing [burn-in] makes the difference -- instead of
statistical reliability, you get actual component testing
with the actual capacitors, traces, etc.

Put it this way: when I buy a name-brand, the first thing
I do is test it.


-- Robert
 
"599863331 599863331" answered to 'the Flying Bucket':
You truly are a ****wit. Such a test is practically useless.
Click to expand...


Yeah, Flying is known to post weird questions and reside in my quiet cage.
But this question sounds reasonable and may be of interest for others too.


Many tools may be around, but the BIOS does this anyway if you
disable the quick-check option in the BIOS setup screen.

It read/write/read 'walking bit' patterns to check every bit is
isolated and not affected by neighbour-bits or became slow.
Often seen test pattern pairs are 0x55/0xAA and 0x66/0x99,
some BIOS use even both and/or other complementary values.

Addon cards memory (PCI) may not be checked by all cards themself,
so here it may be really required to have your own test routines.
Such a 'test-tool' may contain just a few code lines anyway,
but will need an unprotected environment which can access all RAM.
__
wolfgang
 
You truly are a ****wit. Such a test is practically useless.
Click to expand...


You must need the ad-hominem because you have no better argument.

Memory testing is _extremely_ important in the [homebuilt] PC world
where ECC is only rarely used. If you look at the server world, memory
failures (presumably indicated by ECC logs) are surprisingly common,
just after hard disks and PSUs.

There are uncountable variations in components: memory modules,
motherboards, power supplies that can impact memory reliability. Sure
the modules are tested by special-purpose intense machines. But that is
no assurance of system performance. I have seen errors in the 1 per two
hour range. These are would usually get blamed on the OS.

If they are working responsibly, the first tier PC mfrs (Dell, HPaq,
...) should be exhaustively testing their base model designs and some
sampling of line production. Then they rely on statistics for quality
assurance of their production runs. Unit testing let alone burn-in costs
too much time [money].

In addition to the usual advantages of customizability and often lower
cost, a user-built PC can be more _RELIABLE_ than name-brand if the
builder pays attention to all the hidden factors like case airflow,
grounding, cable routing, etc. The testing [burn-in] makes the
difference -- instead of statistical reliability, you get actual
component testing with the actual capacitors, traces, etc.

Put it this way: when I buy a name-brand, the first thing I do is test
it.


-- Robert
Click to expand...

I was talking about per cell testing, not about memory testing. Now go
away and study the internal design and manufacture of RAM chips and get
back to me.

By the way, the person I was responding to is a troll and deserves a more
comprehensive accolade than ****wit.
 
In alt.lang.asm 599863331 599863331 said:
I was talking about per cell testing, not about memory
testing. Now go away and study the internal design and
manufacture of RAM chips and get back to me.
Click to expand...

How can you test memory without looking at cells?
Usually grouped as words.
By the way, the person I was responding to is a troll
Click to expand...

"Skybuck Flying" might well be unpleasant. But I see
no evidence that s/he is a troll (posting controversial
unfelt views for the response numbers, not content)
and deserves a more comprehensive accolade than ****wit.
Click to expand...

Perhaps so. Then why were you so vague? Insults are very poor
arguments and using them with imprecision just rudely proclaims
your frustration without revealing anything about the target.


-- Robert
 
Hello,

I would like to have a memory test which tests each memory cell by cell.

So it runs from cell 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, etc

It reads and writes each cell at least once.

When it finds a cell corrupted it halts the program and shows which cell is
corrupted.

Then I also need a command line to immediately test this cell again to see
if it's truely damaged, so for example memory cell 5 was maybe damaged:

MemTest 5

Which tool can do this ?

Bye,
Skybuck.
Click to expand...

Many years ago I had a minicomputer memory card that would fall over
once a day or every other day with a single parity error. Each 16-bit
word on this card had 17 RAM chips (16 data plus 1 parity chip). The
OS would trap the error by recording the faulty memory address but it
would not report the faulty bit. All I knew was that one of the 17
chips in that column was bad ... once a day.

Subsequent testing in the workshop with a memory diagnostic produced
no errors, even after several days. I then wrote a tiny program that
exercised just that one address in a tight loop. It took a while, but
eventually the card fell over and my program trapped the faulty bit.

These same cards sometimes had failures in the refresh logic. They
would always pass the POST because the RAM would be read almost
immediately after being written, which meant that the data in the
memory cells did not have enough time to decay. So a proper memory
test should wait some time between writes and reads for such faults to
show up.

- Franc Zabkar
 
Back
Top