login
Search
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.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Index: linux-2.6/arch/x86/kernel/e820_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_64.c
+++ linux-2.6/arch/x86/kernel/e820_64.c
@@ -119,6 +119,40 @@ again:
return changed;
}
+/* Check for already reserved areas */
+static inline int
+bad_addr_size(unsigned long *addrp, unsigned long *sizep, unsigned long align)
+{
+ int i;
+ unsigned long addr = *addrp, last;
+ unsigned long size = *sizep;
+ int changed = 0;
+again:
+ last = addr + size;
+ for (i = 0; i < MAX_EARLY_RES && early_res[i].end; i++) {
+ struct early_res *r = &early_res[i];
+ if (last > r->start && addr < r->start) {
+ size = r->start - addr;
+ changed = 1;
+ goto again;
+ }
+ if (last > r->end && addr < r->end) {
+ addr = round_up(r->end, align);
+ size = last - addr;
+ changed = 1;
+ goto again;
+ }
+ if (last <= r->end && addr >= r->start) {
+ (*sizep)++;
+ return 0;
+ }
+ }
+ if (changed) {
+ *addrp = addr;
+ *sizep = size;
+ }
+ return changed;
+}
/*
* This function checks if any part of the range <start,end> is mapped
* with type.
@@ -195,7 +229,7 @@ unsigned long __init find_e820_area(unsi
ei_last = ei->addr + ei->size;
if (addr < start)
addr = round_up(start, align);
- if (addr > ei_last)
+ if (addr >= ei_last)
continue;
while (bad_addr(&addr, size, align) && addr+size <= ei_last)
;
@@ -210,6 +244,40 @@ unsigned long __init find_e820_area(unsi
}
/*
+ * Find next free range after *start
+ */
+unsigned long __init find_e820_area_size(unsigned long start, unsigned long *sizep, unsigned long align)
+{
+ int i;
+
+ for (i = 0; i < e820.nr_map; i++) {
+ struct ...very nice patch! I always thought that this was the proper way to do memtest - and we could in fact also do something like this after SMP bringup, and hit the memory bus via multiple CPUs. [that will need a different enumeration though than e820 maps] one structural observation: please make this unified functionality, so that 32-bit kernels can make use of it too. remove such lines or make them pr_debug(). (checkpatch also found more such cases) also, please add a CONFIG_BOOTPARAM_MEMTEST=y option so that distributions can enable this by default in their debug kernels. i've applied your current version to get some testing, please send delta patches against x86/latest. Ingo --
Indeed. Of course, it would also be nice if distros shipped bootloader-invoked prekernel test software, like memtest86+, by default. -hpa --
some do (Fedora for example), but it's still a bit quirky for users to invoke and it would be nice to see those results in the kernel log as well and flag possibly flaky systems that way. (add a taint bit, etc., etc.) Ingo --
It may even make sense to merge in the full memtest86. The code is small (both source and binary) and IIRC it shares a lot of init code with x86. The remaining problem would then be how to maintain its tests up do date. Willy --
memtester is another choice, and it is more easy to be merged. YH --
the current memtest86 is running in 32 bit mode, and only support 64G ram. I tried to expand that a bit, to support 1024g, but it only works on some machine. could be stack provide is not big enough? YH --
Wonder how hard it would be to make it run 64 bits... -hpa --
1. in 32 bit test less than 4g in 32 bit mode 2. switch to 64 bit, set page table under 4g to cover all ram... YH --
Perhaps this can even be used to provide on-the-fly badram patch semantics? --
yes. but bad ranges can not be too many. otherwise early_res array will overflow. then need to use memmap=nn$ss to exclude range already found. YH --
or 1. core0/node0 check all memory at first thanks. will submit delta patch. YH --
well, please try some non-PAE, checks-direct-mappings approach - if someone wants to extend it to the highmem bits i'm sure it will be done. Ingo --
OK, First need to move some early_res code from e820_64.c to e820_32.c or we can start to merge them. anyone is working on that? YH --
Does somebody still remember the bug report in which the fault was found to be in hardware? By bisecting, the user got "working" kernel when movnti was not used to copy data. Would be neat if also non-temporal moves were done in this early memtest. Having the memtest feature in kernel is useful, considering my grub can not load memtest86+ binary, failing with error "Selected item cannot fit into memory", with or without the patch at https://bugzilla.redhat.com/show_bug.cgi?id=237279 I have user-space app to test movnti... ask if you want it. -- Do what you love because life is too short for anything else. --
On Thu, 20 Mar 2008 23:58:33 -0700 be careful, there's some special memory that e820 right now says is not reserved, but still has bios data (the first 4Kb of memory come to mind) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org --
Is that true even after Yinghai's changes? I have lost track of all the patches... -hpa --
only test ranges that have E820_RAM and exclude range that is early_reserved... so it is safe. YH --
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds |