A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » Motherboards » Gigabyte Motherboards
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Update: Memtest86 errors



 
 
Thread Tools Display Modes
  #1  
Old August 3rd 03, 12:43 AM
Bob Davis
external usenet poster
 
Posts: n/a
Default Update: Memtest86 errors


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 he 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.




  #2  
Old August 3rd 03, 03:27 AM
Tim
external usenet poster
 
Posts: n/a
Default

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 he 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.






  #3  
Old August 3rd 03, 06:27 AM
Bob Davis
external usenet poster
 
Posts: n/a
Default


"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.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
C1 and C2 errors James Perrett Cdr 10 April 14th 04 08:08 AM
Can't install any OS (hardware fault?) Paul Richard Homebuilt PC's 4 September 27th 03 12:55 PM
How concerned should I be about these Nero CD-Speed C2 errors? Robert Hancock Cdr 5 August 19th 03 12:34 AM
Memtest86 errors Bob Davis Homebuilt PC's 11 August 6th 03 05:11 AM
Memtest86 errors Boudewijn Gigabyte Motherboards 3 August 3rd 03 06:11 AM


All times are GMT +1. The time now is 12:41 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.