Testing memory cell by cell, and a specific cell ?
in [ASM]
|
Prev: CPU type idea
Next: Variable values are lost
From: Skybuck Flying on 24 Jul 2008 04:19 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.
From: Alexei A. Frounze on 24 Jul 2008 06:13 On Jul 24, 1:19 am, "Skybuck Flying" <BloodySh...(a)hotmail.com> wrote: > 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. 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 ? 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
From: 599863331 599863331 on 24 Jul 2008 06:25 On Thu, 24 Jul 2008 10:19:11 +0200, Skybuck Flying wrote: > 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. You truly are a fuckwit. Such a test is practically useless.
From: Robert Redelmeier on 24 Jul 2008 07:58 In alt.lang.asm Skybuck Flying <BloodyShame(a)hotmail.com> wrote in part: > 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. 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
From: Robert Redelmeier on 24 Jul 2008 08:57
In alt.lang.asm 599863331 599863331 <599863331(a)hotmail.com> wrote in part: > On Thu, 24 Jul 2008 10:19:11 +0200, Skybuck Flying wrote: >> I would like to have a memory test which tests each memory cell by cell. > You truly are a fuckwit. Such a test is practically useless. 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 |