Old computer memory test "Funnies"

I picked up an old HPxv4400 Windows XP Pentium D 3.4GHz workstation which
occasionally crashes. I put in my universal boot disk and ran Memtest86+.
Interestingly, the test program shows 612K of ECC memory, whether the PC has
either or both of the 512K simms installed. The memory test program shows 612K
of 18479 MB/s memory, which seems very fast and the wrong amount, and runs at
about 2-3 passes/second, which seems incredibly fast in my experience.

Memtest 4.0 reboots the PC
Memtest v3.5b - results similar to memtest86+

The PC does boot and run WinXP

Can anyone help me understand what is going on here?
Is mentest86+ just testing the cache?
Is this PC likely to be able to be made usable?

Pentium D 945 3.4 GHZ
2x512K ECC pc2-5300 Ram
Nvidia 7300LE

Bob F wrote:
I picked up an old HPxv4400 Windows XP Pentium D 3.4GHz workstation which
occasionally crashes. I put in my universal boot disk and ran Memtest86+.
Interestingly, the test program shows 612K of ECC memory, whether the PC has
either or both of the 512K simms installed. The memory test program shows 612K
of 18479 MB/s memory, which seems very fast and the wrong amount, and runs at
about 2-3 passes/second, which seems incredibly fast in my experience.

Memtest 4.0 reboots the PC
Memtest v3.5b - results similar to memtest86+

The PC does boot and run WinXP

Can anyone help me understand what is going on here?
Is mentest86+ just testing the cache?
Is this PC likely to be able to be made usable?

Pentium D 945 3.4 GHZ
2x512K ECC pc2-5300 Ram
Nvidia 7300LE

Get a copy of CPUZ, and look at the memory tab.

*******

It sounds like one DIMM is being "sub-detected".
With your 2x512MB configuration, a total of 1GB of
memory should be detected. You get to use
1024MB minus 1MB reserved by the BIOS. Or about
1023MB or so.

The BIOS on computers is cleverly designed. On
the one hand, it will probe via SMBUS, the SPD
EEPROM. SPD is a tiny chip, not shaped like the
memory chips. It is smaller than a memory chip.
There is a table stored in there, with
capacity and timing information. The parameters
are standardized by JEDEC, a standards body.

But the BIOS "doesn't trust anyone". The BIOS
will set the memory controller on the Northbridge,
according the details in the SPD. Then it does
the old-fashioned "peek n' poke" memory sizing
test. The idea is, you write a value into an
imaginary location. If there is actual memory
present at that address, the value can be read
out later and verified. Every location, they try to
write a different value - that prevents a floating
computer bus, from accidentally having the "right"
answer, at the instant the read (peek) to verify the
result is carried out. By doing a binary search,
you can rather rapidly detect the "true" value
of the DIMM capacity.

One user here, bought a DIMM, which had the wrong SPD
chip soldered to it. (We figured this out later, using
CPUZ.) The SPD chip was basically telling
a lie about the memory capacity. Yet, the computer
still ran. It did not crash. Because of "peek n' poke",
the BIOS figured this out, all by itself. The BIOS
knew the actual DIMM, was half the size declared
in the SPD.

The evidence comes, when the user checks the claimed
amount of physical memory, and it isn't right. That's when
you begin to suspect, the BIOS has saved you from a
"surprise".

Try the non-install version of CPUZ, and verify the
memory details.

http://www.cpuid.com/softwares/cpu-z.html

1.67.1 zip, english
(no installation, includes 32 and 64-bit binaries)

When you click the "Memory" tab, it shows
the total memory detected by the computer.
The BIOS helped work out all the "safe bits"
of memory, so the computer will not crash.

The "SPD" tab, on the other hand, displays
the declaration soldered to the DIMM.

If there is a difference, between the value
seen in the Memory section, versus the sum
total of the SPD declarations (all slots
totaled together), it could be
one of those "surprise" situations.
For some reason, the DIMM is sub-detected.

*******

Shut down the computer. Turn off the power.
Unplug the computer. Wait around 60 seconds
for +5VSB to drain. On an Asus motherboard,
wait for the green LED to go out, on the motherboard.
It connects directly to +5VSB.

It's important for +5VSB to drain, as you want
all the sockets on the motherboard, to not
have any power floating on them. A DIMM could
get damaged, if you don't wait.

With all power drained, and with an anti-static
strap attached between your wrist and the computer
chassis, you can pull the DIMMs and reseat them.
Due to the usage of 10 micron gold plating, with
pin-holes in the finish, sometimes the electrical
contacts don't "make" as well as they should. There
is quite a strong incentive to "cheat" on the
gold finish on the pins of a DIMM. A simple
re-insertion may fix your problem - for now.

I do not recommend pencil erasers or abrasives
for cleaning DIMMs. That only makes potential
future contact problems, worse. If there is dirt
on the DIMM, you can use isopropyl alcohol. Some
of those simple alcohols, are used for washing
at the factory, and are safe on plastics. Acetone
and gasoline, are not safe.

Other than that, the insertion of the DIMM, has sufficient
wiping action for the purpose of making a
fresh contact.

Gold on gold, wipes or slides. Tin on tin, "bites".
The two metalizations should not be mixed. It's less than
desirable to use a tin socket, with a gold contact.
Tin works best with tin, gold works well with gold.
Gold on gold is a low friction fit, so the contact
friction would be lower than say, tin on tin. With
tin on tin, the oxides scrape over one another, until
fresh metal touches. Gold has no oxide to scrape off.

HTH,
Paul

Paul wrote:
Bob F wrote:
I picked up an old HPxv4400 Windows XP Pentium D 3.4GHz workstation
which occasionally crashes. I put in my universal boot disk and ran
Memtest86+. Interestingly, the test program shows 612K of ECC
memory, whether the PC has either or both of the 512K simms
installed. The memory test program shows 612K of 18479 MB/s memory,
which seems very fast and the wrong amount, and runs at about 2-3
passes/second, which seems incredibly fast in my experience. Memtest 4.0
reboots the PC
Memtest v3.5b - results similar to memtest86+

The PC does boot and run WinXP

Can anyone help me understand what is going on here?
Is mentest86+ just testing the cache?
Is this PC likely to be able to be made usable?

Pentium D 945 3.4 GHZ
2x512K ECC pc2-5300 Ram
Nvidia 7300LE

Get a copy of CPUZ, and look at the memory tab.

*******

It sounds like one DIMM is being "sub-detected".
With your 2x512MB configuration, a total of 1GB of
memory should be detected. You get to use
1024MB minus 1MB reserved by the BIOS. Or about
1023MB or so.

The BIOS on computers is cleverly designed. On
the one hand, it will probe via SMBUS, the SPD
EEPROM. SPD is a tiny chip, not shaped like the
memory chips. It is smaller than a memory chip.
There is a table stored in there, with
capacity and timing information. The parameters
are standardized by JEDEC, a standards body.

But the BIOS "doesn't trust anyone". The BIOS
will set the memory controller on the Northbridge,
according the details in the SPD. Then it does
the old-fashioned "peek n' poke" memory sizing
test. The idea is, you write a value into an
imaginary location. If there is actual memory
present at that address, the value can be read
out later and verified. Every location, they try to
write a different value - that prevents a floating
computer bus, from accidentally having the "right"
answer, at the instant the read (peek) to verify the
result is carried out. By doing a binary search,
you can rather rapidly detect the "true" value
of the DIMM capacity.

One user here, bought a DIMM, which had the wrong SPD
chip soldered to it. (We figured this out later, using
CPUZ.) The SPD chip was basically telling
a lie about the memory capacity. Yet, the computer
still ran. It did not crash. Because of "peek n' poke",
the BIOS figured this out, all by itself. The BIOS
knew the actual DIMM, was half the size declared
in the SPD.

The evidence comes, when the user checks the claimed
amount of physical memory, and it isn't right. That's when
you begin to suspect, the BIOS has saved you from a
"surprise".

Try the non-install version of CPUZ, and verify the
memory details.

http://www.cpuid.com/softwares/cpu-z.html

1.67.1 zip, english
(no installation, includes 32 and 64-bit binaries)

When you click the "Memory" tab, it shows
the total memory detected by the computer.
The BIOS helped work out all the "safe bits"
of memory, so the computer will not crash.

The "SPD" tab, on the other hand, displays
the declaration soldered to the DIMM.

If there is a difference, between the value
seen in the Memory section, versus the sum
total of the SPD declarations (all slots
totaled together), it could be
one of those "surprise" situations.
For some reason, the DIMM is sub-detected.

*******

Shut down the computer. Turn off the power.
Unplug the computer. Wait around 60 seconds
for +5VSB to drain. On an Asus motherboard,
wait for the green LED to go out, on the motherboard.
It connects directly to +5VSB.

It's important for +5VSB to drain, as you want
all the sockets on the motherboard, to not
have any power floating on them. A DIMM could
get damaged, if you don't wait.

With all power drained, and with an anti-static
strap attached between your wrist and the computer
chassis, you can pull the DIMMs and reseat them.
Due to the usage of 10 micron gold plating, with
pin-holes in the finish, sometimes the electrical
contacts don't "make" as well as they should. There
is quite a strong incentive to "cheat" on the
gold finish on the pins of a DIMM. A simple
re-insertion may fix your problem - for now.

I do not recommend pencil erasers or abrasives
for cleaning DIMMs. That only makes potential
future contact problems, worse. If there is dirt
on the DIMM, you can use isopropyl alcohol. Some
of those simple alcohols, are used for washing
at the factory, and are safe on plastics. Acetone
and gasoline, are not safe.

Other than that, the insertion of the DIMM, has sufficient
wiping action for the purpose of making a
fresh contact.

Gold on gold, wipes or slides. Tin on tin, "bites".
The two metalizations should not be mixed. It's less than
desirable to use a tin socket, with a gold contact.
Tin works best with tin, gold works well with gold.
Gold on gold is a low friction fit, so the contact
friction would be lower than say, tin on tin. With
tin on tin, the oxides scrape over one another, until
fresh metal touches. Gold has no oxide to scrape off.

HTH,
Paul

The cpuid SPD data shows both simms as 512MB Samsung ECC memories. The BIOS
detects it as 1MB if both are in. WinXP System box shows 1 GB of ram

Memtest86+ shows this test operating at slightly faster (18479 MB/s) than the
L2 cache (17990 MB/s) I've never seen Memtest86+ run anywhere near this fast.
Normally, It takes a significant chunk of an hour for a pass, on systems with
2-4 times as much memory. This does 2-3 passes/second. No errors detected, but
if it were running in cache, I'd expect that.

Memtest86+ should be able to handle ECC memory, shouldn't it?

I just went back to the PC, it sat 1/2 hour without use. No response to mouse or
keyboard. It's just sitting there on the desktop screen, but crashed, I guess.

I've never dealt with ECC memory before. Can I just swap in some non-ECC memory
for a test?

Bob F corrected:

The cpuid SPD data shows both simms as 512MB Samsung ECC memories.
The BIOS detects it as 1GB if both are in. WinXP System box shows 1
GB of ram

Bob F wrote:
Paul wrote:
Bob F wrote:
I picked up an old HPxv4400 Windows XP Pentium D 3.4GHz workstation
which occasionally crashes. I put in my universal boot disk and ran
Memtest86+. Interestingly, the test program shows 612K of ECC
memory, whether the PC has either or both of the 512K simms
installed. The memory test program shows 612K of 18479 MB/s memory,
which seems very fast and the wrong amount, and runs at about 2-3
passes/second, which seems incredibly fast in my experience. Memtest 4.0
reboots the PC
Memtest v3.5b - results similar to memtest86+

The PC does boot and run WinXP

Can anyone help me understand what is going on here?
Is mentest86+ just testing the cache?
Is this PC likely to be able to be made usable?

Pentium D 945 3.4 GHZ
2x512K ECC pc2-5300 Ram
Nvidia 7300LE
Get a copy of CPUZ, and look at the memory tab.

*******

It sounds like one DIMM is being "sub-detected".
With your 2x512MB configuration, a total of 1GB of
memory should be detected. You get to use
1024MB minus 1MB reserved by the BIOS. Or about
1023MB or so.

The BIOS on computers is cleverly designed. On
the one hand, it will probe via SMBUS, the SPD
EEPROM. SPD is a tiny chip, not shaped like the
memory chips. It is smaller than a memory chip.
There is a table stored in there, with
capacity and timing information. The parameters
are standardized by JEDEC, a standards body.

But the BIOS "doesn't trust anyone". The BIOS
will set the memory controller on the Northbridge,
according the details in the SPD. Then it does
the old-fashioned "peek n' poke" memory sizing
test. The idea is, you write a value into an
imaginary location. If there is actual memory
present at that address, the value can be read
out later and verified. Every location, they try to
write a different value - that prevents a floating
computer bus, from accidentally having the "right"
answer, at the instant the read (peek) to verify the
result is carried out. By doing a binary search,
you can rather rapidly detect the "true" value
of the DIMM capacity.

One user here, bought a DIMM, which had the wrong SPD
chip soldered to it. (We figured this out later, using
CPUZ.) The SPD chip was basically telling
a lie about the memory capacity. Yet, the computer
still ran. It did not crash. Because of "peek n' poke",
the BIOS figured this out, all by itself. The BIOS
knew the actual DIMM, was half the size declared
in the SPD.

The evidence comes, when the user checks the claimed
amount of physical memory, and it isn't right. That's when
you begin to suspect, the BIOS has saved you from a
"surprise".

Try the non-install version of CPUZ, and verify the
memory details.

http://www.cpuid.com/softwares/cpu-z.html

1.67.1 zip, english
(no installation, includes 32 and 64-bit binaries)

When you click the "Memory" tab, it shows
the total memory detected by the computer.
The BIOS helped work out all the "safe bits"
of memory, so the computer will not crash.

The "SPD" tab, on the other hand, displays
the declaration soldered to the DIMM.

If there is a difference, between the value
seen in the Memory section, versus the sum
total of the SPD declarations (all slots
totaled together), it could be
one of those "surprise" situations.
For some reason, the DIMM is sub-detected.

*******

Shut down the computer. Turn off the power.
Unplug the computer. Wait around 60 seconds
for +5VSB to drain. On an Asus motherboard,
wait for the green LED to go out, on the motherboard.
It connects directly to +5VSB.

It's important for +5VSB to drain, as you want
all the sockets on the motherboard, to not
have any power floating on them. A DIMM could
get damaged, if you don't wait.

With all power drained, and with an anti-static
strap attached between your wrist and the computer
chassis, you can pull the DIMMs and reseat them.
Due to the usage of 10 micron gold plating, with
pin-holes in the finish, sometimes the electrical
contacts don't "make" as well as they should. There
is quite a strong incentive to "cheat" on the
gold finish on the pins of a DIMM. A simple
re-insertion may fix your problem - for now.

I do not recommend pencil erasers or abrasives
for cleaning DIMMs. That only makes potential
future contact problems, worse. If there is dirt
on the DIMM, you can use isopropyl alcohol. Some
of those simple alcohols, are used for washing
at the factory, and are safe on plastics. Acetone
and gasoline, are not safe.

Other than that, the insertion of the DIMM, has sufficient
wiping action for the purpose of making a
fresh contact.

Gold on gold, wipes or slides. Tin on tin, "bites".
The two metalizations should not be mixed. It's less than
desirable to use a tin socket, with a gold contact.
Tin works best with tin, gold works well with gold.
Gold on gold is a low friction fit, so the contact
friction would be lower than say, tin on tin. With
tin on tin, the oxides scrape over one another, until
fresh metal touches. Gold has no oxide to scrape off.

HTH,
Paul

The cpuid SPD data shows both simms as 512MB Samsung ECC memories. The BIOS
detects it as 1MB if both are in. WinXP System box shows 1 GB of ram

Memtest86+ shows this test operating at slightly faster (18479 MB/s) than the
L2 cache (17990 MB/s) I've never seen Memtest86+ run anywhere near this fast.
Normally, It takes a significant chunk of an hour for a pass, on systems with
2-4 times as much memory. This does 2-3 passes/second. No errors detected, but
if it were running in cache, I'd expect that.

Memtest86+ should be able to handle ECC memory, shouldn't it?

I just went back to the PC, it sat 1/2 hour without use. No response to mouse or
keyboard. It's just sitting there on the desktop screen, but crashed, I guess.

I've never dealt with ECC memory before. Can I just swap in some non-ECC memory
for a test?

That *is* pretty weird.

If I had to guess...

1) Memtest86+ breaks the test down into pieces.

2) Memtest86+ has the ability to "lift" the code out of the way
and test underneath. That means your 1GB test, is broken down
into a 1MB test and a 1022MB test, just to show the degree of
asymmetry. The area the BIOS uses is reserved, and cannot be
tested. So that's at least three chunks - BIOS reserved (1MB),
the place the memtest86+ code is stored (until moved out of the way),
and the rest of the memory. The "code lifting" thing, is so
memtest86+ can claim to get very close to testing all the memory.
If it wasn't for the BIOS reservation thing, it would have
tested all of it. If you crap all over the BIOS area, the
computer could crash (when system management mode interrupt runs, say).

( http://en.wikipedia.org/wiki/System_Management_Mode )

3) It almost sounds like it's only doing a part of the test
for some reason. Like, it is avoiding testing the upper section
of the RAM. It sounds like somehow, it has managed to reduce
the size of the test area, until the test area fits entirely
into cache. That wouldn't happen, if memtest86+ was really
testing the entire memory. Some failure is causing the
test to be truncated.

The source for the memtest86+ code is available. Before it
evaluates the various "speeds", it does sequential reads of what
it hopes, are larger than cache sized bursts. That's to invalidate
the cache, when testing the speed. Cache has grown over the years,
but I expect the latest version of memtest86+ takes that into account.

So for some reason, lots of things seem "truncated" here.

Maybe a failure is occurring, while memtest86+ is testing a *cache* ?

I don't actually know if it does that or not.

It's either that, or the BIOS reservation table is screwed up
somehow. And the BIOS is telling memtest86+, there is very
little free RAM it can test.

*******

The reason I've looked at the "cache warmup code", the part
that flushes the cache intentionally, is I added three lines
of code to memtest86+ once and recompiled it. The reason
for doing that, is I needed a way to measure memory bandwidth,
in the single and dual channel areas of an NForce2 chips. To
show part of the memory space runs slower than the other part.
I had the program use it's memory speed measurement, run it
eight times, and print the result on the screen. As a result
of modifying the code, I needed to read a little bit of
source, to figure out what three lines to change. That's the
only reason for knowing what's in there. I don't read source
on that many programs :-) It's not a fixation or something :-)

*******

You cannot mix ECC and non-ECC memory. The computer will beep
if you do that. One type of memory should be inserted at a time.
The user manual may state what types it takes.

My current computer accepts ECC. I used to run 2GB of non-ECC,
then I bought 8GB of ECC RAM to try out. I don't mix those, and
can only use one type at a time. It turns out, my stupid chipset
actually has a bug in the ECC hardware, and the BIOS has turned
it off! There is absolutely no ECC interface in the BIOS at all,
because the motherboard engineers knew about that bug. And the
manual doesn't reflect that knowledge. And I didn't know about
that, until I'd bought the damn memory :-(

So the ECC RAM just sits there, and the ninth chip in each
rank, is duly ignored.

On a well designed computer, there should be SPD-based detection
of the ECC. And the ECC circuit can be turned off if needed. In
my case, it's turned off all the time.

Paul

Bob F wrote:
Memtest86+ shows this test operating at slightly faster (18479 MB/s)
than the L2 cache (17990 MB/s) I've never seen Memtest86+ run
anywhere near this fast. Normally, It takes a significant chunk of an
hour for a pass, on systems with 2-4 times as much memory. This does
2-3 passes/second. No errors detected, but if it were running in
cache, I'd expect that.

Interestingly, I get exactly the same results in Memtest86+ whether the PC has 1
or 2 -512MB ECC, 1 or 2 1GB non-ECC memories ibstalled, showing 612K of memory
in all cases, even though the BIOS and windows see the changes.

This seems more like a Memtest86+ problem. Or, some computer problem makes it
see a memory error, and thus, end-of-ram, at 612K

Running the "Windows Memory Diagnostic" on the "ultimate Boot CD" shows 1GB with
both 512's installed and no errors.

Resetting the BIOS to default changed nothing.

Bob F wrote:
Bob F wrote:
Memtest86+ shows this test operating at slightly faster (18479 MB/s)
than the L2 cache (17990 MB/s) I've never seen Memtest86+ run
anywhere near this fast. Normally, It takes a significant chunk of an
hour for a pass, on systems with 2-4 times as much memory. This does
2-3 passes/second. No errors detected, but if it were running in
cache, I'd expect that.

Interestingly, I get exactly the same results in Memtest86+ whether the PC has 1
or 2 -512MB ECC, 1 or 2 1GB non-ECC memories ibstalled, showing 612K of memory
in all cases, even though the BIOS and windows see the changes.

This seems more like a Memtest86+ problem. Or, some computer problem makes it
see a memory error, and thus, end-of-ram, at 612K

Running the "Windows Memory Diagnostic" on the "ultimate Boot CD" shows 1GB with
both 512's installed and no errors.

Resetting the BIOS to default changed nothing.




The memory reservation thing (BIOS table) is supported
by an E820 call. This code (apparently), prints that table
out for viewing.

http://code.google.com/p/e820/source...e/trunk/e820.c

And this page has an example of an output.

http://forum.osdev.org/viewtopic.php...=12230&start=0

E820:
hSz Base Address - Memory Length - Memory Type
14 : 0000000000000000 - 000000000009FC00h - Available to OS ---
14 : 000000000009FC00 - 0000000000000400h - Reserved Memory
14 : 00000000000E0000 - 0000000000020000h - Reserved Memory
14 : 0000000000100000 - 00000000002F0000h - Available to OS ---
14 : 00000000003F0000 - 000000000000F000h - ACPI Reclaim Memory
14 : 00000000003FF000 - 0000000000001000h - ACPI NVS Memory
14 : 00000000FFFC0000 - 0000000000040000h - Reserved Memory

The first segment is fairly small = 654336 bytes or 639K

So the trick would be, finding a copy of the executable. If it
really is 16 bit code, it'll run on a 16 bit or 32 bit Windows
OS.

You would hope, an OS boot loader would also be interested
in that table. And somehow, the OS is ignoring whatever
is upsetting memtest86+.

Paul

Paul wrote:
Bob F wrote:
So retry your test, without the -v argument.

The memtest86+ source code, has a module
for memory sizing, and it actually has fallback
code, if e820 probe fails. It could be, your
machine is resorting to even older standards
for some reason. And your test results are then
something from the "640K days".

Paul

E820 Dump Tool - Version 0.1.0 - Copyright(C) Mike Hou 2011
----------------------------------------------------------------
Base Address Length Type
-----------------------+------------------------------+---------
0: 0x00000000-00000000 (0x00000000-00099000 ~ 612 KB) 1 (Memory)
1: 0x00000000-00099000 (0x00000000-00007000 ~ 28 KB) 2 (Reserved)
2: 0x00000000-000E8000 (0x00000000-00018000 ~ 96 KB) 2 (Reserved)
3: 0x00000000-00100000 (0x00000000-3FED8300 ~ 1022 MB) 1 (Memory)
4: 0x00000000-3FFD8300 (0x00000000-00027D00 ~ 159 KB) 2 (Reserved)
5: 0x00000000-F0000000 (0x00000000-04000000 ~ 64 MB) 2 (Reserved)
6: 0x00000000-FEC00000 (0x00000000-00140000 ~ 1 MB) 2 (Reserved)
7: 0x00000000-FED45000 (0x00000000-012BB000 ~ 18 MB) 2 (Reserved)
----------------------------------------------------------------
(type 'e820 -v' for more details)


Well, that does show something at the 612KB boundary.

Could this have something to do with "security" hardware in this HP xw4400
"workstation"?

Bob F wrote:
Paul wrote:
Bob F wrote:
So retry your test, without the -v argument.

The memtest86+ source code, has a module
for memory sizing, and it actually has fallback
code, if e820 probe fails. It could be, your
machine is resorting to even older standards
for some reason. And your test results are then
something from the "640K days".

Paul

E820 Dump Tool - Version 0.1.0 - Copyright(C) Mike Hou 2011
----------------------------------------------------------------
Base Address Length Type
-----------------------+------------------------------+---------
0: 0x00000000-00000000 (0x00000000-00099000 ~ 612 KB) 1 (Memory)
1: 0x00000000-00099000 (0x00000000-00007000 ~ 28 KB) 2 (Reserved)
2: 0x00000000-000E8000 (0x00000000-00018000 ~ 96 KB) 2 (Reserved)
3: 0x00000000-00100000 (0x00000000-3FED8300 ~ 1022 MB) 1 (Memory)
4: 0x00000000-3FFD8300 (0x00000000-00027D00 ~ 159 KB) 2 (Reserved)
5: 0x00000000-F0000000 (0x00000000-04000000 ~ 64 MB) 2 (Reserved)
6: 0x00000000-FEC00000 (0x00000000-00140000 ~ 1 MB) 2 (Reserved)
7: 0x00000000-FED45000 (0x00000000-012BB000 ~ 18 MB) 2 (Reserved)
----------------------------------------------------------------
(type 'e820 -v' for more details)


Well, that does show something at the 612KB boundary.

Could this have something to do with "security" hardware in this HP xw4400
"workstation"?



I don't see why it would.

Memtest86+ should see both of those chunks, and test both of them.

The 612 KB one and the 1022 MB one.

That's what is supposed to happen. And since the E820 table
is kinda "free-form", the memtest86+ code really has to parse
the table, to get the information properly. It's not like the
code can just afford to randomly grab the first line and third
line or something. It has to find all the "OS" entries,
and bolt them together into a table of areas to be tested.

Paul

Paul wrote:
I just downloaded MemTest86 V4.3.6, and it seems to be testing this PC
properly.I'll let it run awhile and see if it indicates any problems.

"Paul" wrote in message
...
I do not recommend pencil erasers or abrasives
for cleaning DIMMs. That only makes potential
future contact problems, worse. If there is dirt
on the DIMM, you can use isopropyl alcohol. Some
of those simple alcohols, are used for washing
at the factory, and are safe on plastics. Acetone
and gasoline, are not safe.


Servisol (ages ago one could get INIBISOL de-greasant, ...that was good),
for removing tarnish on alloy/metal contacts, is brilliant !
Marvellous for cleaning boards that have years of dust and/or cigarettes tar
deposits :-)
i.e. whip the board out, hold it over a drain and blast away with Servisol -
just watch all that s**t run off !
...of course it has to be left to thoroghly "dry" ...Servisol mostly
evaporates, leaving a small trace of non-conductive lubricant,
....and one has to be careful that small amounts trapped with capilliary type
action still present under surface mounted IC's ... are "dried out."
.....here is where my 38 year old+ Electrolux vacuum cleaner (where one can
connect the hose on the exhaust end), comes in handy.
.... ...(and here is where rapid airflow electrostatic damage is to be
avoided !)

regards, Richard