Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.arch
Subject: Re: VAX Memory Test
Summary: must be done standalone
Message-ID: <12849@mimsy.UUCP>
Date: 5 Aug 88 08:19:55 GMT
References: <3300032@m.cs.uiuc.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 42

In article <3300032@m.cs.uiuc.edu> carey@m.cs.uiuc.edu writes:
>I would like to get (adapt, or write) a memory test routine for
>a VAX-750 or a VAX-780.
>
>I want it to run under UNIX, ....

Memory tests usually cannot run underneath a virtual memory O/S, since
they have no way to force the machine to allocate particular memory
regions.  To have any hope of testing all of memory (except that
part in which the test program is loaded, unless it moves itself),
the program will have to run standalone.

>This should be pretty simple, but I don't really know how to go about it.

A trivial test, like the ones in DEC's microdiagnostics, is not too
hard.  A complete test is infeasible: there are 2^(total number of bits)
patterns to test.  You can test for common faults such as address and
data line shorts, stuck bits, etc.; but no matter what you test, there
will always be *some* failure mode you will miss.

(For instance, early MicroVAX IIs would sometimes crash if idle.  This
happened only when running Unix, never under VMS.  It turned out that
the refresh on some of the DRAMs was weak, and after not being accessed
for 30 seconds or so, they would begin to forget.  VMS's idle loop did
enough work that the external RAS- or CAS-only refresh hit all the rows
or columns and thus took care of it.  The 4BSD idle loop is just a few
instructions, and did not.)

>If I have to write it myself, I would appreciate any hints or advice.

The easiest test for a Vax with ECC is to let the machine run
normally.  Single-bit errors will be corrected automatically, with a
note from the O/S (as reported by the hardware) when this happens.  The
`address' and `syndrome' bits identify exactly which chip is failing,
although the only way to go from address+syndrome to chip is via the
manufacturer's tables (or trace the board! ... not for me, thanks),
which are sometimes hard to find.

(Of course, if the ECC logic is broken . . . .)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris