Very Computer

I suspect I may have a problem of memory fault, as many others,
since I get segfault messages when compiling with gcc.

I have seen mentioned in this list a program named Checkit for
that purpose. Is it shareware? If so where can I find it?
Otherwise, is there any shareware program suitable for this?

Thank you.
Ricardo.

: I suspect I may have a problem of memory fault, as many others,
: since I get segfault messages when compiling with gcc.

: I have seen mentioned in this list a program named Checkit for
: that purpose. Is it shareware? If so where can I find it?
: Otherwise, is there any shareware program suitable for this?

: Thank you.
: Ricardo.

Begin3
Title:          memtest
Version:        1.0
Entered-date:   16NOV95
Description:    To provide a way of detecting memory problems which might
                impact the operation of Linux.
Keywords:       memory linux diag error cache


Primary-site:   sunsite.unc.edu  /pub/Linux/system/Misc/memtest.tar.gz
                tsx-11.mit.edu /pub/Linux/sources/sbin/memtest.tar.gz
                Approx 25K
Platforms:      linux / Unix
Copying-policy: GPL

: : I suspect I may have a problem of memory fault, as many others,
: : since I get segfault messages when compiling with gcc.

: : I have seen mentioned in this list a program named Checkit for
: : that purpose. Is it shareware? If so where can I find it?
: : Otherwise, is there any shareware program suitable for this?

: : Thank you.
: : Ricardo.

: Begin3
: Title:          memtest
: Version:        1.0
: Entered-date:   16NOV95
: Description:    To provide a way of detecting memory problems which might
:                 impact the operation of Linux.
: Keywords:       memory linux diag error cache


: Primary-site:   sunsite.unc.edu  /pub/Linux/system/Misc/memtest.tar.gz
:                 tsx-11.mit.edu /pub/Linux/sources/sbin/memtest.tar.gz
:                 Approx 25K
: Platforms:      linux / Unix
: Copying-policy: GPL

I'm sorry, but memtest seems not to be at either location.  I've
just now checked (Sunday, 19 November, 1995 at 7:40 PM, EST).  Is
there a problem with this program or has its location been changed?

[...]

Quote:>How can you allocate memory at a given PHYSICAL ABSOLUTE
>NON-program-memory-address-space location?

[...]

/dev/mem.
But! Note that the kernel itself occupies some 1MB of memory, and if you
write bit patterns there you're likely to crash your machine.
Memory testing is a job for a standalone program, i.e. running
without an OS kernel. Moreover, the code should be position independent
so that it can reposition itself and test the memory occupied by it
previously.
 Note that you can use DOS to load a standalone program, because DOS
doesn't control anything your code does (e.g. changing descriptor tables
or such things)
 Perhaps someone could turn that memtest.c into a standalone program
(to be loaded by lilo or by DOS)?

Greetings,
-Gerhard

be better to write a memory test program without the kernel being
around.  Although i have to concede that his point is correct, it
would be nice to be able to write diagnostics and so on to a file
in a regular linux file system instead of to a DOS file.

But there is STILL a need for some way to allocate memory by
physical block AFTER you have found the bad memory cells:  you
would like to allocate the bad cells (somehow) so that neither the
kernel nor user programs use them.  This is sort of like how
you may keep a list of bad blocks of a disk drive.

There is a system call phys() which can allocate up to 4 blocks
of memory at physical addresses---is it implemented in any kernel,
and does anyone have experience using it?

(Gerhard also suggests using /dev/mem to test, presumably
by reading and writing the raw device, and in a location away
from the kernel.  This sounds, to my untrained
ear, like a good idea also --- are there pointers around to user-level
software doing this?  I guess such a program must be executed right
after boot, before buffers and so on are allocated?)

Y> better to write a memory test program without the kernel being around.
Y> Although i have to concede that his point is correct, it would be nice to
Y> be able to write diagnostics and so on to a file in a regular linux file
Y> system instead of to a DOS file.

I think it should be a kernel module:  Swap everything out and get rid
of the buffers, then check everything not in the kernel.  Copy the kernel.
Jump to the new copy.  If the main kernel in not position independant,
disable interrupts.  Test the low memory.  Restore the kernel.  Jump
back into low memory and restart interrupts.  Grab the data that was
collected and save it.  Start the schedular and let stuff page back in.
Let the data be read from /proc.

Y> But there is STILL a need for some way to allocate memory by physical block
Y> AFTER you have found the bad memory cells: you would like to allocate the
Y> bad cells (somehow) so that neither the kernel nor user programs use them.
Y> This is sort of like how you may keep a list of bad blocks of a disk drive.

Y> There is a system call phys() which can allocate up to 4 blocks of memory
Y> at physical addresses---is it implemented in any kernel, and does anyone
Y> have experience using it?

Quote:>>> How can you allocate memory at a given PHYSICAL ABSOLUTE
>>> NON-program-memory-address-space location?
>> /dev/mem.  But! Note that the kernel itself occupies some 1MB of memory,

No.  You can get to the physical memory, but you can not allocate.
If you write to /dev/mem you must avoid the kernel, _and_ _also_ the
buffers, all programs, libraries, etc.
--

Albert Cahalan

The problem is that many (most?) of the memory problems on Linux
don't manifest under such programs - they require a specific perverse
series of accesses.  A checkit like program isn't going to pick them
up if it doesn't duplicate that series of accesses.

Printing/logging the address of all illegal instruction interrupts
would help to pick this up, although usually you end up with
segmentation faults instead, where the bad memory address doesn't
correspond directly to where the fault occurred.
--
Everyone dies, but not everyone lives.  

Quote:>It would be useful to allocate memory at an absolute address for TWO
>reasons:
>(1)  If an error is detected, then you'd know EXACTLY which SIMM to
>take back to your dealer (if the SIMMs were still under warranty).

Not always so simple. Memory interleaving and such complicates things.

Quote:>(2)  IF you can allocate at a PHYSICAL address, then there's
>a simple cure to bad memory:  you just alloocate ALL of the
>bad memory, and put your process in the background until you next

[...]

Quote:>How can this be done?

Easy. Go into arch/i386/mm/init.c and mark the bad areas as reserved,
akin to what happens to your 640k ->1MB region. The routine you want
is mem_init(). If faulty_mem_addr is known to be bad, then add:

        mem_map[MAP_NR(faulty_mem_addr & PAGE_MASK)].reserved = 1;
        reserved++;

Paul.

: [...]
: >How can you allocate memory at a given PHYSICAL ABSOLUTE
: >NON-program-memory-address-space location?
: [...]

: /dev/mem.
: But! Note that the kernel itself occupies some 1MB of memory, and if you
: write bit patterns there you're likely to crash your machine.
: Memory testing is a job for a standalone program, i.e. running
: without an OS kernel. Moreover, the code should be position independent
: so that it can reposition itself and test the memory occupied by it
: previously.
:  Note that you can use DOS to load a standalone program, because DOS
: doesn't control anything your code does (e.g. changing descriptor tables
: or such things)
:  Perhaps someone could turn that memtest.c into a standalone program
: (to be loaded by lilo or by DOS)?

My personal opinion is that it is unlikely that there are socalled
"CELL errors". Those are the ones that are specifically related to a
single memory cell. These are usually found by the BIOS memory test.

The harder ones are the ones that are caused by specific address
changes. For instance when the address changes from 10101010 to
10101010 the chips might have extra trouble with that, and require a
few ns extra time. If you have your chipset configured for a critical
number of waitstates, this just might mean that the memory delivers
the requested data "too late".

These are rarely detected by simple memory tests, as they tend to
access memory sequentially.

something that is really good :-) . Untill then you might use the

    http://einstein.et.tudelft.nl/~wolff/sig11/memtest.tgz.uue

                                                Roger.

--
 *** War doesn't determine who's right ****** War determines who's left. ***

 *** <a href="http://einstein.et.tudelft.nl/~wolff/">my own homepage</a> ***