If a socket-AM2+ mainboard has four RAM slots and supports 16 GiB RAM = 4× 4 GiB DDR2 PC-800 it may not work properly in automatic mode. This is a known issue. Manual decrease of memory speed to PC-667 should solve this problem.

memtest86+ contains a bug: SMP mode doesn't work properly with AMD processors. Up to version 5.01, memtest86+ freezes. Current version 5.31b runs in SMP mode but shows memory errors where any memory errors don't exist. These fictive memory errors are shown at nearly same range independent of installed memory size. Running memtest86+ in single core mode avoids this problem but takes a lot of time. Testing 16 GiB DDR2 @ PC-667 with three passes is an overnight job.
Running a current version of proprietory memtest86 may be an alternative but this requires UEFI boot support for USB or optical drive.

From a present-day perspective, a socket-AM2+ system is historic. If you use this system in this way do everything to get it work properly. If you use it for daily work thing about new hardware. Most modern Linux distris work on older x86_64 hardware but you will experience the slowness.

Thanks business_kid!

Yor reply allowed me to solve this issue and I'm now replying from the normal environment of my PC.

After realizing I might having a problem with root filesystem and nothing is wrong with the RAM
I booted from the live DVD, run "fsck" on all 3

/dev/VolGroup/lv_root
/dev/VolGroup/lv_home
/dev/VolGroup/lv_swap

and indeed, some errors were found and corrected on the

/dev/VolGroup/lv_root

After that I removed the DVD and the PC rebooted just fine.
I'm currently running with 4 2GB DIMMs (yesterday, in hope to rule out the possibility of damaged by PSU DIMMs
I bought 2Gb DIMMs and of corse, same error persisted), I'll now power down, return the originsl 4GB DIMMs
and I'm cautiously optimistic that the PC will boot OK with them too (I'm too old to say I'm 100% sure the PC
will boot OK). :-)

Thanks to all the replies,
kaza.

Now back to the original 4 * 4GB DIMMs and all seems to be well.

I'll need to run a compare against the backup to see if "fsck" while
fixing erors changed anything.

Tnakgs again to all the replies,
kaza.

Glad you're sorted.

For my sins, I've been poring over the Slackware init scripts. They call fsck for a basic check, and watch the error number on exit. Depending on the error number, they either repair it or bale out.

Something like that must have happened to you. You can get an autocheck going on that in all likelihood.