x86: memtest: WARN if bad RAM found

From: Ben Hutchings <[email protected]>
Date: Mon, 5 Dec 2011 04:00:58 +0000

Since this is not a particularly thorough test, if we find any bad bits of RAM then there is a fair chance that there are other bad bits we fail to detect.

---
Hi,

The patch below comes from this discussion

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=50;bug=613321

and has been in use in Debian kernels since last December. The rationale does not seem particularly distro-specific, and all in all it looks to me like a good change.

Nothing urgent here. I imagine this patch as targetted to v3.5.

Thoughts?
Jonathan

 arch/x86/mm/memtest.c |    2 ++
 1 file changed, 2 insertions(+)

index c80b9fb95734..38caeb44a218 100644
@@ -30,6 +30,8 @@ static u64 patterns[] __initdata = {
 
 static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
 {
+	WARN_ONCE(1, "Bad RAM detected. Use memtest86+ to perform a thorough test\n"
+		  "and the memmap= parameter to reserve the bad areas.");
 	printk(KERN_INFO "  %016llx bad mem addr %010llx - %010llx reserved\n",
 	       (unsigned long long) pattern,
 	       (unsigned long long) start_bad,

1.7.10.rc3

From: Ben Hutchings <[email protected]>
Date: Mon, 5 Dec 2011 04:00:58 +0000

Since this is not a particularly thorough test, if we find any bad bits of RAM then there is a fair chance that there are other bad bits we fail to detect.

Warn so the TAINT_WARNING flag shows up in panic traces and other bug reports from users that enabled memtest and found bad RAM during bootup, to help people debugging to see that problems are potentially due to unreliable RAM. The warning text gives advice that can be used to make the warning go away using a more thorough test:

Bad RAM detected. Use memtest86+ to perform a thorough test and the memmap= parameter to reserve the bad areas.

In this way, this patch should make the lives of people helping to analyze bug reports from builds with CONFIG_MEMTEST enabled easier.

---
Hi again,

The patch below last visited this list on 2 April, about a week and a half ago. No reply.

The patch has been in Debian since last December. I like it. The patch is targetted at v3.5, so I would like to see it in linux-next so it can get more exposure. Comments?

Thanks,
Jonathan

 arch/x86/mm/memtest.c |    2 ++
 1 file changed, 2 insertions(+)

index c80b9fb95734..38caeb44a218 100644
@@ -30,6 +30,8 @@ static u64 patterns[] __initdata = {
 
 static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
 {
+	WARN_ONCE(1, "Bad RAM detected. Use memtest86+ to perform a thorough test\n"
+		  "and the memmap= parameter to reserve the bad areas.");
 	printk(KERN_INFO "  %016llx bad mem addr %010llx - %010llx reserved\n",
 	       (unsigned long long) pattern,
 	       (unsigned long long) start_bad,

1.7.10

From: Ben Hutchings <[email protected]>
Date: Mon, 5 Dec 2011 04:00:58 +0000

The novice who enables CONFIG_MEMTEST may not realize that it is not a particularly thorough test. If we find any bad bits of RAM then there is a fair chance that there are other bad bits we fail to detect; add a WARNING for this situation so people helping debug ensuing problems can understand what happened.

The warning text gives advice to allow the sysadmin to run a more thorough test and suppress the warning.

Bad RAM detected. Use memtest86+ to perform a thorough test and the memmap= parameter to reserve the bad areas.

---

Are Ben and I the only ones who care either way about this change?

 arch/x86/mm/memtest.c |    2 ++
 1 file changed, 2 insertions(+)

index c80b9fb95734..38caeb44a218 100644
@@ -30,6 +30,8 @@ static u64 patterns[] __initdata = {
 
 static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
 {
+	WARN_ONCE(1, "Bad RAM detected. Use memtest86+ to perform a thorough test\n"
+		  "and the memmap= parameter to reserve the bad areas.");
 	printk(KERN_INFO "  %016llx bad mem addr %010llx - %010llx reserved\n",
 	       (unsigned long long) pattern,
 	       (unsigned long long) start_bad,

1.7.10

How about "more thorough test"? Or do you have a better recommendation for users?

Thanks for looking it over.
Jonathan

The reason for adding early_memtest is for debug purpose. Sometimes BIOS mess up setting, on some booting memory is ok, but other booting the memory is not initialized properly.

in that case: preboot memtest tools is not going to help.

also preboot memtest tools and early_memtest is not stressed enough. --- only one process is running.
Need to run memtester multiple instances to test your memory and systems.

Yinghai

From: Ben Hutchings <[email protected]>

The novice who enables CONFIG_MEMTEST may not realize that this is not a particularly thorough test. If we find any bad bits of RAM then there is a fair chance that there are other bad bits we fail to detect; add a WARNING for this situation so people helping debug ensuing problems can understand what happened.

The warning text gives advice to allow the sysadmin to address the warning by fixing the underlying problem or running a more thorough test and using the memmap= parameter to reserve bad areas.

---

[... and another hint about how memtest86 may be more suitable
than memtest86+ in some situations]

Makes perfect sense. How about this?

This punts to Documentation/memory.txt for advice, in the hope of nudging people to improve that document where it is lacking (hint, hint).

Thanks,
Jonathan

 arch/x86/mm/memtest.c |    1 +
 1 file changed, 1 insertion(+)

index c80b9fb95734..d26067d5ddec 100644
@@ -30,6 +30,7 @@ static u64 patterns[] __initdata = {
 
 static void __init reserve_bad_mem(u64 pattern, u64 start_bad, u64 end_bad)
 {
+	WARN_ONCE(1, "Bad RAM detected. See Documentation/memory.txt for hints.");
 	printk(KERN_INFO "  %016llx bad mem addr %010llx - %010llx reserved\n",
 	       (unsigned long long) pattern,
 	       (unsigned long long) start_bad,

1.7.10