PDA

View Full Version : Update: Memtest86 errors


Bob Davis
August 3rd 03, 12:43 AM
Update to original message:

I managed to shoehorn the stick in bank0/slot1 past the HSF and installed
the new memory alone in B0/S1 and B1/S3 (remember, I have six slots). The
tests showed no errors for the new memory, so the error on Test 5 occurs
only when all four sticks are installed. I am now satisfied that the
physical memory is solid, but here's an interesting blurb from the Memtest86
site:

"In the vast majority of cases errors reported by the test are valid. There
are some systems that cause Memtest86 to be confused about the size of
memory and it will try to test non-existent memory. This will cause a large
number of consecutive addresses to be reported as bad and generally there
will be many bits in error. If you have a relatively small number of failing
addresses and only one or two bits in error you can be certain that the
errors are valid."

This sounds exactly what's happening here: When it hits 98% on Test 5 it
spits out from two to 20 errors very quickly, all with multiple bits in
error, usually 10k-20k but more rarely 100. I've never seen any bit count
in between. Also, when it hits 98% it zips to 100% much faster than the
previous progression for Test 5.

The big question now is, does this behavior in Memtest86 translate into a
potential problem in real-world computing? I emailed the author of
Memtest86, so maybe I'll get some response.


"Bob Davis" > wrote in message
...
> System: Gigabyte 8KNXP, P4 2.8C, 2gb RAM (Kingston DDR400
KVR400X64C3A/512)
> , not overclocked.
>
> When running Memtest86 v3 I get random errors at the very end of test #5.
> The "good" is always one of the following: ff7fffff, ffefffff, fff7ffff,
or
> fffeffff--and the "bad" is always ffffffff.
>
> A second GB of RAM was installed two days ago, and the errors started at
> that time. Previous tests with 1gb did not manifest errors. The address
> location of the errors is random throughout the 2gb, so it apparently
isn't
> in the new modules. Error count can be as low as two and as high as 20,
and
> they always occur just as Test #5 is completing and transitioning to Test
> #6. I reversed the two new modules without effect, but since I use a
Zalman
> HSF the Bank 0, Slot 1 module appears not to be removable without moving
or
> removing the HSF, I haven't tried the new memeory alone.
>
> Anyone have an idea what's going on here? The computer runs fine and I've
> had no trouble yet in real-world experience.
>
>

Tim
August 3rd 03, 03:27 AM
What happens now if you put the remainder of the memory into the second pair
of slots?
If you get a similar set of errors with the original memory moved, then the
h/w must be mapping some of the memory out and providing for some add in
cards to sit in these addresses.

- Tim


"Bob Davis" > wrote in message
...
>
> Update to original message:
>
> I managed to shoehorn the stick in bank0/slot1 past the HSF and installed
> the new memory alone in B0/S1 and B1/S3 (remember, I have six slots). The
> tests showed no errors for the new memory, so the error on Test 5 occurs
> only when all four sticks are installed. I am now satisfied that the
> physical memory is solid, but here's an interesting blurb from the
Memtest86
> site:
>
> "In the vast majority of cases errors reported by the test are valid.
There
> are some systems that cause Memtest86 to be confused about the size of
> memory and it will try to test non-existent memory. This will cause a
large
> number of consecutive addresses to be reported as bad and generally there
> will be many bits in error. If you have a relatively small number of
failing
> addresses and only one or two bits in error you can be certain that the
> errors are valid."
>
> This sounds exactly what's happening here: When it hits 98% on Test 5 it
> spits out from two to 20 errors very quickly, all with multiple bits in
> error, usually 10k-20k but more rarely 100. I've never seen any bit count
> in between. Also, when it hits 98% it zips to 100% much faster than the
> previous progression for Test 5.
>
> The big question now is, does this behavior in Memtest86 translate into a
> potential problem in real-world computing? I emailed the author of
> Memtest86, so maybe I'll get some response.
>
>
> "Bob Davis" > wrote in message
> ...
> > System: Gigabyte 8KNXP, P4 2.8C, 2gb RAM (Kingston DDR400
> KVR400X64C3A/512)
> > , not overclocked.
> >
> > When running Memtest86 v3 I get random errors at the very end of test
#5.
> > The "good" is always one of the following: ff7fffff, ffefffff, fff7ffff,
> or
> > fffeffff--and the "bad" is always ffffffff.
> >
> > A second GB of RAM was installed two days ago, and the errors started at
> > that time. Previous tests with 1gb did not manifest errors. The
address
> > location of the errors is random throughout the 2gb, so it apparently
> isn't
> > in the new modules. Error count can be as low as two and as high as 20,
> and
> > they always occur just as Test #5 is completing and transitioning to
Test
> > #6. I reversed the two new modules without effect, but since I use a
> Zalman
> > HSF the Bank 0, Slot 1 module appears not to be removable without moving
> or
> > removing the HSF, I haven't tried the new memeory alone.
> >
> > Anyone have an idea what's going on here? The computer runs fine and
I've
> > had no trouble yet in real-world experience.
> >
> >
>
>

Bob Davis
August 3rd 03, 06:27 AM
"Tim" > wrote in message ...

> What happens now if you put the remainder of the memory into the second
pair
> of slots?


I've tried the following arrangements:

Old pair in Slots 1 and 4 (1gb): No errors
New pair in Slots 1 and 4 (1gb): No errors
Old pair in Slots 2 and 5 (1gb): No errors
(Didn't try new pair in Slots 2 and 5)

Only when all four modules (2gb) are installed will Memtest86 generate any
errors, either with the old sticks in Slots 1 and 4 or Slots 2 and 5. The
arrangement is irrelevant to the results, as are the memory timings I
mentioned in another post (2.5-7-3-3, 3-8-3-3 (SPD), and 3-10-4-4). I have
left the timings at the more aggressive setting for testing the individual
pairs, and plan on leaving them there.


> If you get a similar set of errors with the original memory moved, then
the
> h/w must be mapping some of the memory out and providing for some add in
> cards to sit in these addresses.


The errors have the same characteristics (i.e., random addresses) regardless
of the order the RAM is installed, and no errors when the pairs are used
separately (1gb), also regardless of which slots are used (1 & 4 or 2 & 5).
The commonality is that most errors are in the f....... range and show many
bit errors (usually 10000-20000).

I reiterate that in real-world computing I have seen no evidence of any
memory problems since the new modules were installed.