I'm rebuilding a three-year-old AMD Athlon 5000 system which has an "ASRock NF7G-FullHD" motherboard with 4 memory slots, labeled "DDR2 800", said to have RAM capacity 8GB total. Besides 550W PS and 500GB disk I bought a "matched pair" of 2 ea. 2GB DIMMs that, unfortunately, have persistent single-bit errors at several locations (see picture).

What would be the effect of running Linux on this system with such memory? I.e., how likely is instability, undetected error, or low performance? Will there be OS crashes, segfaults, miscellaneous application failures, or what? Is there a way to map out or disable bad chunks of RAM?

memtest86 picture

Note, the 4 memory slots are labeled DDRII_1,2,3,4; 1&2 are yellow, 3&4 are orange. The Memtest86 picture above was taken when slots were filled in (new,old,new,old) order. Errors also occur at similar addresses with fill order (old,old,new,new), with same memory access rate (about 2.9GB/s) as in picture. Filled (old, old, -, -) or (old, -, old, -) or (new, -, new, -) no errors occurred in a few hours of testing, but (new, new, -, -) for some reason didn't get into or through BIOS and reset button appeared to have no effect and there was no video signal. With 3 slots filled, e.g. (new1, old, new0, -) one error occurred (located in first GB of RAM) in 1.5 hours of testing; with (old, old, new0, -), no errors in 2 hours of testing. A performance problem with 6GB configurations is memory access rate of only 1.7GB/sec.

Question summary: What would be the effect of running Linux on this system with memory subject to some single-bit errors? Is there a fix other than replacing RAM?

  • 1
    You can usually resolve these errors by raising the RAM voltage, raising the latency, and/or decreasing the FSB frequency. – David Schwartz Nov 19 '11 at 21:43
  • Re latency, do you know of documentation on which of the 4-4-4-12 CAS numbers (as in picture) would need to change? – James Waldby - jwpat7 Nov 19 '11 at 22:03
  • Tech spec of these chips specify a CAS latency of 5 by the way. – Dennis Nov 19 '11 at 23:10
  • You either need to raise the voltage to 2.0V or increase the CAS latency to 5. At least, if the specifications I'm seeing online are correct, that's what they say. (Didn't they come with specs?) – David Schwartz Nov 19 '11 at 23:29
  1. Memory access rate is lower with only 3 chips since dual channel memory should always be installed in pairs.

  2. Single bit errors can cause pretty much everything to happen. How likely it is depends on how bad your memory has gone, but it is not a good idea to take those chances. System instability is what you should hope for. You could also store a system critical file (or any other file that is important to you) in this part of the memory, modify it and overwrite the original file. So a single bit error can mess up your entire OS.

  3. Chances are that only one of the memory sticks is defective (probably new1). PYG's memory comes with a lifetime warranty, so you could try to get a working one. I have heard very bad things about PYG's memory and customer service, but I cannot know for sure.

  • I'll ask for a replacement, but I'm looking at alternatives in case of problems or delays with replacement. – James Waldby - jwpat7 Nov 19 '11 at 21:00
  • You will have to turn in the faulty stick for replacement, so just use 4 GiB for now. – Dennis Nov 19 '11 at 23:09

As stated a single bit memory error can cause almost anything to go wrong, or you may never notice it at all.

I had a bad memory stick before and the bad point in RAM effectively meant that Windows would sometimes work, but it would corrupt itself pretty regularly. You can never predict what will be allocated into any given spot of RAM in a system (due to the way OS'es allocate memory) and while you may get lucky and only have it break some unimportant program or corrupt one graphic there is a good chance that it will do a lot worse and you are risking your data by using a bad stick of RAM.

Linux has support for BadMem which, if I remember correctly, can mean that you can "map out" the bad block of memory. I couldn't work out if it supports the latest kernel to see if it is of any use to you though.

My advice is as follows: in the short term be prepared for data loss and general system instability, in the long term you should figure out which stick is faulty and replace it.


To be able to run programs a computer fetches instructions about what to do from memory. (the programs are loaded in memory). Instructions are just number sequences and is the computers language.

Let's construct a simple language where 1 = copy, 3 = from, 4 = to


So the number sequence 1,50,3,100,4,200 may for the computer mean copy 50 bytes of data from memory locaton 100 to memory location 200. This is the same as you moving 50 socks from one drawer to another.

Now if the memory is malfunctioning and there is a single bit error a number may for example change from 1 to 129. So assuming that any number in the sequence above might be changed you could end up with a lot of interesting errors. If 50 gets changed to 35 or 188 or whatever it is quite easy to understand that the amount of data who is to be copied will be wrong and may possibly overwrite other data (who might be instructions) in memory. if 1 gets changed to 5 the computer might not even understand that it is supposed to copy anything at all. So as demonstrated a single bit error may lead to not only a single fault but possibly other errors caused by the first error as well.

Linux (or any other operatingsystem) is basically the same as the rest of the programs that run on your computer: a sequence of numbers that tells the computer what to do. If this sequence gets corrupted you programs will not make the computer do what it was intended to do and thus you may experience all kinds of problems.

Also remember that music, video or pictures is also just a sequence of numbers so the same principle applies there as well. It is worth adding that depending on your file a corruption may not be noticeable (for example a bad pixel in a picture) but that does not mean that the file is ok. There might even be a typo in the text you read on a webpage if that particular character is stored in a bad memory location.

There exists ram chips that are designed to recover single bit errors and that can detect two bit errors (ECC ram).

Hopefully this explains why any operating system will fail to work if the memory that contains it's data and/or instructions are corrupted. Your safest way of solving this is to replace the broken ram. Meanwhile you might want to map out the bad memory area using the memmap kernel parameter (the following is copied from a answer I got on another question).

            [KNL,ACPI] Mark specific memory as reserved.
            Region of memory to be used, from ss to ss+nn.
            Example: Exclude memory from 0x18690000-0x1869ffff

I had this same problem, but found the available answers confusing and incomplete, so I put together a step-by-step guide, assuming as little background as I could.

  1. Run Memtest86+ in “Badram” output (preferably from a bootable external medium). When Memtest86+ starts, type:
  2. “c” (“configuration”), then
  3. “4” (“Error Report Mode”), then
  4. “3” (“Bad RAM Patterns”), then
  5. “0” (“Continue”).
  6. Copy the output that follows any lines beginning with “badram=”.
  7. Open a terminal (command line).
  8. Change to the directory where the “grub” file is located. For example, “cd /etc/default”.
  9. With “root” privileges, use a text editor to open the “grub” file (If you are not signed in as “root,” use “sudo.” You will be asked for the “root” password.): “sudo nano grub” (This example changes the user to “root” and opens the file “grub” with the “nano” text editor.).
  10. Find the section describing memtest.
  11. Uncomment the last line (Delete the special character at the beginning of the line, such as “#,” “>,” or “!”). This makes it active (For example,“#GRUB_BADRAM=” becomes “GRUB_BADRAM=”.).
  12. Replace the example addresses (following “GRUB_BADRAM=”) with the “badram=” output that you copied from Memtest86+ (for example, “0x98f548a0,0xfffffffc”).
  13. Save (or “write out”) your changes.
  14. In the terminal (command line) update the “grub.cfg” file, by typing “sudo update-grub”.
  15. Reboot.
  • Looks like a nice answer. Minor quibble with “(If you are not signed in as “root,” use “sudo.” You will be asked for the “root” password.)” – sudo asks for user pw. From man sudoers, “Unlike su(1), when sudoers requires authentication, it validates the invoking user's credentials, not the target user's (or root's) credentials” unless told otherwise by sudoer flags – James Waldby - jwpat7 Nov 22 '14 at 19:17

Today's memories (say from at least 10 years to date) should all have error correcting built in. If that is regularly failing something is very wrong and could fail catastrophically at any moment.

See to replace the failing RAM as soon as possible.

  • I discarded the referenced computer years ago. If I still had it, it would be slightly over 10 years old. :) – James Waldby - jwpat7 Aug 17 at 3:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.