Memtest in 2.6.30.5

In the 4.3 feedback thread one of the guys laments the absence of memtest.

I took it out as the kernel from 2.6.26 has a simplified memtest builtin:

http://kernelnewbies.org/Linux_2_6_26

If I boot with "puppy memtest loglevel=7", nothing is reported.

Looking at kernel git logs:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=272b9cad6e7a2f61b13cfcd7dde0010e02e9376e

x86: early memtest to find bad ram


do simple memtest after init_memory_mapping

use find_e820_area_size to find all ram range that is not reserved.

and do some simple bits test to find some bad ram.

if find some bad ram, use reserve_early to exclude that range.


...which seems to indicate that bad ram is automatically reserved.

Looking in the kernel source documentation, kernel-parameters.txt:

memtest=	[KNL,X86] Enable memtest

Format: <integer>
default : 0 <disable>
Specifies the number of memtest passes to be
performed. Each pass selects another test
pattern from a given set of patterns. Memtest
fills the memory with this pattern, validates
memory contents and reserves bad memory
regions that are detected.


...oh, just putting "memtest" as the boot parameter actually does nothing!!!?

So, I tried "puppy memtest=2 loglevel=7".

Still nothing. Run 'dmesg' after bootup, nothing in there. Look in /proc and /sys, can't find anything in there.

So, a memtest feature that reserves any bad ram it finds, but doesn't actually report any of its findings ...unless it only reports if bad ram found? ...I think that borders on useless -- well, no, not "useless", but less than satisfactory.

Note, the 2.6.30.5 kernel is configured with:
CONFIG_MEMTEST=y

So, for pup 4.4 we do need to consider putting memtest86+ in.


Posted on 9 Oct 2009, 8:00


Comments:

Posted on 9 Oct 2009, 15:29 by scsijon
badram
lets say your badram is in the bottom 640K (remember the old ?286 limit below swaping ram blocks), this area still needs to be clean today.

If I read this test right, it means that any faulty ram will be "enclosed" and therefore not used by the system.

For laptops with soldered in memory (I have a few in the junk bin) it should mean they may be reuseable again.

will test and add note when my new cd arrives from barry


Posted on 9 Oct 2009, 15:49 by BarryK
bad ram
Yeah, it is good that this is being done at the kernel level, but I want to be told, hey that ram is bad! If it is on pluggable ram then I can replace it.
But not being told anything, then you don't know whether bad ram is found or not. So, to play safe you have to do the "memtest=<number>" at every boot!



Posted on 10 Oct 2009, 7:10 by Dougal
dmesg info
From arch/x86/mm/memtest.c:
in void __init early_memtest:
printk(KERN_INFO "early_memtest: pattern num %d", memtest_pattern);

(memtest_pattern is the integer you pass to it)
----
and in static void __init memtest:
if (start_bad) {
printk(KERN_CONT "\n %016lx bad mem addr %010lx - %010lx reserved",
val, start_bad, last_bad + incr);

KERN_CONT is nothing, so I presume it stays at the same loglevel (KERN_INFO=6).
You should probably see at least the "early_memtest:" line in dmesg...