[PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[Yinghai Lu]

make the print out right with size < 1M

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 arch/x86/kernel/cpu/mtrr/main.c |  109 ++++++++++++++++++++++++++++++----------
 1 file changed, 82 insertions(+), 27 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
@@ -905,6 +905,27 @@ set_var_mtrr_all(unsigned int address_bi
 	}
 }
 
+static unsigned long to_size_factor(unsigned long sizek, char *factorp)
+{
+	char factor;
+	unsigned long base = sizek;
+
+	if (base & ((1<<10) - 1)) {
+		/* not MB alignment */
+		factor = 'K';
+	} else if (base & ((1<<20) - 1)){
+		factor = 'M';
+		base >>= 10;
+	} else {
+		factor = 'G';
+		base >>= 20;
+	}
+
+	*factorp = factor;
+
+	return base;
+}
+
 static unsigned int __init
 range_to_mtrr(unsigned int reg, unsigned long range_startk,
 	      unsigned long range_sizek, unsigned char type)
@@ -926,13 +947,21 @@ range_to_mtrr(unsigned int reg, unsigned
 			align = max_align;
 
 		sizek = 1 << align;
-		if (debug_print)
+		if (debug_print) {
+			char start_factor = 'K', size_factor = 'K';
+			unsigned long start_base, size_base;
+
+			start_base = to_size_factor(range_startk, &start_factor),
+			size_base = to_size_factor(sizek, &size_factor),
+
 			printk(KERN_DEBUG "Setting variable MTRR %d, "
-				"base: %ldMB, range: %ldMB, type %s\n",
-				reg, range_startk >> 10, sizek >> 10,
+				"base: %ld%cB, range: %ld%cB, type %s\n",
+				reg, start_base, start_factor,
+				size_base, size_factor,
 				(type == MTRR_TYPE_UNCACHABLE)?"UC":
 				    ((type == MTRR_TYPE_WRBACK)?"WB":"Other")
 				);
+		}
 		save_var_mtrr(reg++, range_startk, sizek, type);
 		range_startk += sizek;
 		range_sizek -= sizek;
@@ -1244,6 +1273,8 @@ static int __init mtrr_cleanup(unsigned
 
 	if (mtrr_chunk_size && mtrr_gran_size) {
 		int num_reg;
+		char gran_factor, chunk_factor, lose_factor;
+		unsigned long gran_base, chunk_base, lose_base;
 
 		debug_print++;
 		/* convert ranges to var ranges state */
@@ -1269,12 +1300,15 @@ static int __init mtrr_cleanup(unsigned
 			result[i].lose_cover_sizek =
 				(range_sums - range_sums_new) << PSHIFT;
 
-		printk(KERN_INFO "%sgran_size: %ldM \tchunk_size: %ldM \t",
-			 result[i].bad?"*BAD*":" ", result[i].gran_sizek >> 10,
-			 result[i].chunk_sizek >> 10);
-		printk(KERN_CONT "num_reg: %d  \tlose cover RAM: %s%ldM \n",
+		gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
+		chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
+		lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
+		printk(KERN_INFO "%sgran_size: %ld%c \tchunk_size: %ld%c \t",
+			 result[i].bad?"*BAD*":" ",
+			 gran_base, gran_factor, chunk_base, chunk_factor);
+		printk(KERN_CONT "num_reg: %d  \tlose cover RAM: %s%ld%c\n",
 			 result[i].num_reg, result[i].bad?"-":"",
-			 result[i].lose_cover_sizek >> 10);
+			 lose_base, lose_factor);
 		if (!result[i].bad) {
 			set_var_mtrr_all(address_bits);
 			return 1;
@@ -1289,14 +1323,25 @@ static int __init mtrr_cleanup(unsigned
 	memset(min_loss_pfn, 0xff, sizeof(min_loss_pfn));
 	memset(result, 0, sizeof(result));
 	for (gran_size = (1ULL<<20); gran_size < (1ULL<<32); gran_size <<= 1) {
+		char gran_factor;
+		unsigned long gran_base;
+
+		if (debug_print)
+			gran_base = to_size_factor(gran_size >> 10, &gran_factor);
+
 		for (chunk_size = gran_size; chunk_size < (1ULL<<32);
 		     chunk_size <<= 1) {
 			int num_reg;
 
-			if (debug_print)
-				printk(KERN_INFO
-			       "\ngran_size: %lldM   chunk_size_size: %lldM\n",
-				       gran_size >> 20, chunk_size >> 20);
+			if (debug_print) {
+				char chunk_factor;
+				unsigned long chunk_base;
+
+				chunk_base = to_size_factor(chunk_size>>10, &chunk_factor),
+				printk(KERN_INFO "\n");
+				printk(KERN_INFO "gran_size: %ld%c   chunk_size: %ld%c \n",
+				       gran_base, gran_factor, chunk_base, chunk_factor);
+			}
 			if (i >= NUM_RESULT)
 				continue;
 
@@ -1339,12 +1384,18 @@ static int __init mtrr_cleanup(unsigned
 
 	/* print out all */
 	for (i = 0; i < NUM_RESULT; i++) {
-		printk(KERN_INFO "%sgran_size: %ldM \tchunk_size: %ldM \t",
-		       result[i].bad?"*BAD* ":" ", result[i].gran_sizek >> 10,
-		       result[i].chunk_sizek >> 10);
-		printk(KERN_CONT "num_reg: %d \tlose RAM: %s%ldM\n",
-		       result[i].num_reg, result[i].bad?"-":"",
-		       result[i].lose_cover_sizek >> 10);
+		char gran_factor, chunk_factor, lose_factor;
+		unsigned long gran_base, chunk_base, lose_base;
+
+		gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
+		chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
+		lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
+		printk(KERN_INFO "%sgran_size: %ld%c \tchunk_size: %ld%c \t",
+			 result[i].bad?"*BAD*":" ",
+			 gran_base, gran_factor, chunk_base, chunk_factor);
+		printk(KERN_CONT "num_reg: %d  \tlose cover RAM: %s%ld%c\n",
+			 result[i].num_reg, result[i].bad?"-":"",
+			 lose_base, lose_factor);
 	}
 
 	/* try to find the optimal index */
@@ -1369,14 +1420,18 @@ static int __init mtrr_cleanup(unsigned
 	}
 
 	if (index_good != -1) {
+		char gran_factor, chunk_factor, lose_factor;
+		unsigned long gran_base, chunk_base, lose_base;
+
 		printk(KERN_INFO "Found optimal setting for mtrr clean up\n");
 		i = index_good;
-		printk(KERN_INFO "gran_size: %ldM \tchunk_size: %ldM \t",
-				result[i].gran_sizek >> 10,
-				result[i].chunk_sizek >> 10);
-		printk(KERN_CONT "num_reg: %d \tlose RAM: %ldM\n",
-				result[i].num_reg,
-				result[i].lose_cover_sizek >> 10);
+		gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
+		chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
+		lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
+		printk(KERN_INFO "gran_size: %ld%c \tchunk_size: %ld%c \t",
+			 gran_base, gran_factor, chunk_base, chunk_factor);
+		printk(KERN_CONT "num_reg: %d  \tlose RAM: %ld%c\n",
+			 result[i].num_reg, lose_base, lose_factor);
 		/* convert ranges to var ranges state */
 		chunk_size = result[i].chunk_sizek;
 		chunk_size <<= 10;

[PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

one have gran < 1M

reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1

will get

Found optimal setting for mtrr clean up
gran_size: 512K         chunk_size: 2M  num_reg: 7      lose RAM: 0G
range0: 0000000000000000 - 00000000d8000000
Setting variable MTRR 0, base: 0GB, range: 2GB, type WB
Setting variable MTRR 1, base: 2GB, range: 1GB, type WB
Setting variable MTRR 2, base: 3GB, range: 256MB, type WB
Setting variable MTRR 3, base: 3328MB, range: 128MB, type WB
hole: 00000000d7f00000 - 00000000d7f80000
Setting variable MTRR 4, base: 3455MB, range: 512KB, type UC
rangeX: 0000000100000000 - 0000000128000000
Setting variable MTRR 5, base: 4GB, range: 512MB, type WB
Setting variable MTRR 6, base: 4608MB, range: 128MB, type WB

so start from 64k instead of 1M

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
 arch/x86/kernel/cpu/mtrr/main.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
@@ -1197,11 +1197,11 @@ struct mtrr_cleanup_result {
 };
 
 /*
- * gran_size: 1M, 2M, ..., 2G
+ * gran_size: 64K, 128K, 256K, 512K, 1M, 2M, ..., 2G
  * chunk size: gran_size, ..., 2G
- * so we need (1+12)*6
+ * so we need (1+16)*8
  */
-#define NUM_RESULT	78
+#define NUM_RESULT	136
 #define PSHIFT		(PAGE_SHIFT - 10)
 
 static struct mtrr_cleanup_result __initdata result[NUM_RESULT];
@@ -1322,7 +1322,7 @@ static int __init mtrr_cleanup(unsigned
 	i = 0;
 	memset(min_loss_pfn, 0xff, sizeof(min_loss_pfn));
 	memset(result, 0, sizeof(result));
-	for (gran_size = (1ULL<<20); gran_size < (1ULL<<32); gran_size <<= 1) {
+	for (gran_size = (1ULL<<16); gran_size < (1ULL<<32); gran_size <<= 1) {
 		char gran_factor;
 		unsigned long gran_base;
 

Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[H. Peter Anvin]

Applied series to tip:x86/mtrr, thanks!

	-hpa

Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Applied series to tip:x86/mtrr, thanks!

tested them and pushed it out into tip/master.

	Ingo

Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * H. Peter Anvin <hpa@zytor.com> wrote:
> 
> > Applied series to tip:x86/mtrr, thanks!
> 
> tested them and pushed it out into tip/master.

btw., now that we've got wide enough exposure (a kernel release), could 
we please flip around the default of CONFIG_MTRR_SANITIZER and make it 
default-y? This feature should only produce a worse result if there's a 
bug in that code, right?

	Ingo

Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[Yinghai Lu]

On Tue, Sep 30, 2008 at 1:11 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
>
>> * H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> > Applied series to tip:x86/mtrr, thanks!
>>
>> tested them and pushed it out into tip/master.
>
> btw., now that we've got wide enough exposure (a kernel release), could
> we please flip around the default of CONFIG_MTRR_SANITIZER and make it
> default-y? This feature should only produce a worse result if there's a
> bug in that code, right?

it will compare the exact mem range between the updated and original,
so it should be safe to set it to default-y.

YH

Re: [PATCH 1/2] x86: mtrr_cleanup prepare to make gran_size to less 1M

[H. Peter Anvin]

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
>> * H. Peter Anvin <hpa@zytor.com> wrote:
>>
>>> Applied series to tip:x86/mtrr, thanks!
>> tested them and pushed it out into tip/master.
> 
> btw., now that we've got wide enough exposure (a kernel release), could 
> we please flip around the default of CONFIG_MTRR_SANITIZER and make it 
> default-y? This feature should only produce a worse result if there's a 
> bug in that code, right?
> 

Yes.  Furthermore, right now the code has to be enabled *and* a kernel 
command line option has to be passed.  I suspect we eventually want to 
runtime-enable it by default, too.

	-hpa

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[J.A. Magallón]

On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:

> one have gran < 1M
> 
> reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1
> reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
> reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
> reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
> reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1
> 
> will get
> 
> Found optimal setting for mtrr clean up
> gran_size: 512K         chunk_size: 2M  num_reg: 7      lose RAM: 0G
> range0: 0000000000000000 - 00000000d8000000
> Setting variable MTRR 0, base: 0GB, range: 2GB, type WB
> Setting variable MTRR 1, base: 2GB, range: 1GB, type WB
> Setting variable MTRR 2, base: 3GB, range: 256MB, type WB
> Setting variable MTRR 3, base: 3328MB, range: 128MB, type WB
> hole: 00000000d7f00000 - 00000000d7f80000
> Setting variable MTRR 4, base: 3455MB, range: 512KB, type UC
> rangeX: 0000000100000000 - 0000000128000000
> Setting variable MTRR 5, base: 4GB, range: 512MB, type WB
> Setting variable MTRR 6, base: 4608MB, range: 128MB, type WB
> 
> so start from 64k instead of 1M
> 

Or there is something I don't catch about mtrrs, or it still does silly
things.

I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:

werewolf:/proc> cat mtrr
reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
reg05: base=0x7c000000 (1984MB), size=  64MB: write-back, count=1
reg06: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1

So it adds a last WB zone, but substracts the last 1Mb. (Why do 
I have that stupid uncacheable mb ? probably a bios issue...)
But those two 64 mb zones could be add to a 128Mb, that new one
with previous to 256Mb and so on, giving something like:

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1

Is this incorrect ?

dmesg is below

Linux version 2.6.26-jam14 (root@werewolf.home) (gcc version 4.3.2 (GCC) ) #2 SMP PREEMPT Thu Oct 2 23:48:10 CEST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000007fee0000 (usable)
 BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS)
 BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data)
 BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
last_pfn = 0x7fee0 max_arch_pfn = 0x100000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
total RAM coverred: 2047M
 gran_size: 64K 	chunk_size: 64K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 128K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 256K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 512K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 1M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 2M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 64K 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 64K 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 64K 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 0G
 gran_size: 64K 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 128K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 256K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 512K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 1M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 2M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 128K 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 128K 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 128K 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 0G
 gran_size: 128K 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 256K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 512K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 1M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 2M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 256K 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 256K 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 256K 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 0G
 gran_size: 256K 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 512K 	chunk_size: 512K 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 512K 	chunk_size: 1M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 512K 	chunk_size: 2M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 512K 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 512K 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 512K 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 512K 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 0G
 gran_size: 512K 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 1M 	chunk_size: 1M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 1M 	chunk_size: 2M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 1M 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 1M 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 1M 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 1M 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 0G
 gran_size: 1M 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 2M 	chunk_size: 2M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 2M 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 2M 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 2M 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 2M 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 1M
 gran_size: 2M 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 4M 	chunk_size: 4M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 4M 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
*BAD*gran_size: 4M 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: -1M
 gran_size: 4M 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 3M
 gran_size: 4M 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 8M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 16M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 32M 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 7M
 gran_size: 8M 	chunk_size: 4G 	num_reg: 8  	lose cover RAM: 7M
 gran_size: 16M 	chunk_size: 16M 	num_reg: 7  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 32M 	num_reg: 7  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 64M 	num_reg: 7  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 15M
 gran_size: 16M 	chunk_size: 4G 	num_reg: 7  	lose cover RAM: 15M
 gran_size: 32M 	chunk_size: 32M 	num_reg: 6  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 64M 	num_reg: 6  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 128M 	num_reg: 6  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 31M
 gran_size: 32M 	chunk_size: 4G 	num_reg: 6  	lose cover RAM: 31M
 gran_size: 64M 	chunk_size: 64M 	num_reg: 5  	lose cover RAM: 63M
 gran_size: 64M 	chunk_size: 128M 	num_reg: 5  	lose cover RAM: 63M
 gran_size: 64M 	chunk_size: 256M 	num_reg: 5  	lose cover RAM: 63M
 gran_size: 64M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 63M
 gran_size: 64M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 63M
 gran_size: 64M 	chunk_size: 2G 	num_reg: 2  	lose cover RAM: 63M
 gran_size: 64M 	chunk_size: 4G 	num_reg: 5  	lose cover RAM: 63M
 gran_size: 128M 	chunk_size: 128M 	num_reg: 4  	lose cover RAM: 127M
 gran_size: 128M 	chunk_size: 256M 	num_reg: 4  	lose cover RAM: 127M
 gran_size: 128M 	chunk_size: 512M 	num_reg: 4  	lose cover RAM: 127M
 gran_size: 128M 	chunk_size: 1G 	num_reg: 3  	lose cover RAM: 127M
Found optimal setting for mtrr clean up
gran_size: 64K 	chunk_size: 64M 	num_reg: 7  	lose RAM: 0G
range0: 0000000000000000 - 000000007c000000
Setting variable MTRR 0, base: 0GB, range: 1GB, type WB
Setting variable MTRR 1, base: 1GB, range: 512MB, type WB
Setting variable MTRR 2, base: 1536MB, range: 256MB, type WB
Setting variable MTRR 3, base: 1792MB, range: 128MB, type WB
Setting variable MTRR 4, base: 1920MB, range: 64MB, type WB
range: 000000007c000000 - 0000000080000000
Setting variable MTRR 5, base: 1984MB, range: 64MB, type WB
hole: 000000007ff00000 - 0000000080000000
Setting variable MTRR 6, base: 2047MB, range: 1MB, type UC
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
After WB checking
MTRR MAP PFN: 0000000000000000 - 0000000000080000
After UC checking
MTRR MAP PFN: 0000000000000000 - 000000000007ff00
After sorting
MTRR MAP PFN: 0000000000000000 - 000000000007ff00
kernel direct mapping tables up to 38000000 @ 7000-c000
DMI 2.3 present.
ACPI: RSDP 000F7260, 0014 (r0 IntelR)
ACPI: RSDT 7FEE3000, 0030 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 7FEE3040, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 7FEE30C0, 44C1 (r1 INTELR AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 7FEE0000, 0040
ACPI: ASF! 7FEE7680, 008A (r32 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: APIC 7FEE75C0, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
1150MB HIGHMEM available.
896MB LOWMEM available.
  mapped low ram: 0 - 38000000
  low ram: 00000000 - 38000000
  bootmap 00008000 - 0000f000
(8 early reservations) ==> bootmem [0000000000 - 0038000000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
  #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
  #3 [0000100000 - 00004b0ea0]    TEXT DATA BSS ==> [0000100000 - 00004b0ea0]
  #4 [00004b1000 - 00004b4000]    INIT_PG_TABLE ==> [00004b1000 - 00004b4000]
  #5 [000009f400 - 0000100000]    BIOS reserved ==> [000009f400 - 0000100000]
  #6 [0000007000 - 0000008000]          PGTABLE ==> [0000007000 - 0000008000]
  #7 [0000008000 - 000000f000]          BOOTMAP ==> [0000008000 - 000000f000]
found SMP MP-table at [c00f57c0] 000f57c0
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  Normal   0x00001000 -> 0x00038000
  HighMem  0x00038000 -> 0x0007fee0
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009f
    0: 0x00000100 -> 0x0007fee0
On node 0 totalpages: 523903
free_area_init_node: node 0, pgdat c041a680, node_mem_map c1000000
  DMA zone: 3967 pages, LIFO batch:0
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 292322 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Allocating PCI resources starting at 80000000 (gap: 7ff00000:7ed00000)
PERCPU: Allocating 38940 bytes of per cpu data
NR_CPUS: 4, nr_cpu_ids: 4, nr_node_ids 1
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 519809
Kernel command line: video=vesafb:mtrr,ywrap vga=773 ro root=/dev/sda1
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0478000 soft=c0474000
PID hash table entries: 4096 (order: 12, 16384 bytes)
TSC: PIT calibration confirmed by PMTIMER.
TSC: using PMTIMER calibration value
Detected 2405.452 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2073644k/2096000k available (2377k kernel code, 21180k reserved, 857k data, 272k init, 1178496k highmem)
virtual kernel memory layout:
    fixmap  : 0xfff85000 - 0xfffff000   ( 488 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc042d000 - 0xc0471000   ( 272 kB)
      .data : 0xc0352618 - 0xc0428bb8   ( 857 kB)
      .text : 0xc0100000 - 0xc0352618   (2377 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Calibrating delay loop (skipped), value calculated using timer frequency.. 4810.90 BogoMIPS (lpj=2405452)
Mount-cache hash table entries: 512
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 10k freed
ACPI: Core revision 20080609
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
CPU 1 irqstacks, hard=c0479000 soft=c0475000
Booting processor 1/6 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4810.31 BogoMIPS (lpj=2405156)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
CPU 2 irqstacks, hard=c047a000 soft=c0476000
Booting processor 2/1 ip 6000
Initializing CPU#2
Calibrating delay using timer specific routine.. 4810.28 BogoMIPS (lpj=2405141)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
x86 PAT enabled: cpu 2, old 0x7040600070406, new 0x7010600070106
CPU2: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
checking TSC synchronization [CPU#0 -> CPU#2]: passed.
CPU 3 irqstacks, hard=c047b000 soft=c0477000
Booting processor 3/7 ip 6000
Initializing CPU#3
Calibrating delay using timer specific routine.. 4810.31 BogoMIPS (lpj=2405159)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
x86 PAT enabled: cpu 3, old 0x7040600070406, new 0x7010600070106
CPU3: Intel(R) Xeon(TM) CPU 2.40GHz stepping 09
checking TSC synchronization [CPU#0 -> CPU#3]: passed.
Brought up 4 CPUs
Total of 4 processors activated (19241.81 BogoMIPS).
net_namespace: 296 bytes
NET: Registered protocol family 16
No dock devices found.
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfb7f0, last bus=3
PCI: Using configuration type 1 for base access
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: 0000:00:00.0 reg 10 32bit mmio: [f0000000, f1ffffff]
PCI: 0000:00:1d.0 reg 20 io port: [bc00, bc1f]
PCI: 0000:00:1d.1 reg 20 io port: [b000, b01f]
PCI: 0000:00:1d.2 reg 20 io port: [b400, b41f]
PCI: 0000:00:1d.3 reg 20 io port: [b800, b81f]
PCI: 0000:00:1d.7 reg 10 32bit mmio: [f7100000, f71003ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1d.7: PME# disabled
pci 0000:00:1f.0: Force enabled HPET at 0xfed00000
pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 0480-04bf claimed by ICH4 GPIO
PCI: 0000:00:1f.1 reg 10 io port: [0, 7]
PCI: 0000:00:1f.1 reg 14 io port: [0, 3]
PCI: 0000:00:1f.1 reg 18 io port: [0, 7]
PCI: 0000:00:1f.1 reg 1c io port: [0, 3]
PCI: 0000:00:1f.1 reg 20 io port: [f000, f00f]
PCI: 0000:00:1f.1 reg 24 32bit mmio: [0, 3ff]
PCI: 0000:00:1f.2 reg 10 io port: [c000, c007]
PCI: 0000:00:1f.2 reg 14 io port: [c400, c403]
PCI: 0000:00:1f.2 reg 18 io port: [c800, c807]
PCI: 0000:00:1f.2 reg 1c io port: [cc00, cc03]
PCI: 0000:00:1f.2 reg 20 io port: [d000, d00f]
PCI: 0000:00:1f.3 reg 20 io port: [500, 51f]
PCI: 0000:00:1f.5 reg 10 io port: [d800, d8ff]
PCI: 0000:00:1f.5 reg 14 io port: [dc00, dc3f]
PCI: 0000:00:1f.5 reg 18 32bit mmio: [f7101000, f71011ff]
PCI: 0000:00:1f.5 reg 1c 32bit mmio: [f7102000, f71020ff]
pci 0000:00:1f.5: PME# supported from D0 D3hot D3cold
pci 0000:00:1f.5: PME# disabled
PCI: 0000:01:00.0 reg 10 32bit mmio: [f2000000, f2ffffff]
PCI: 0000:01:00.0 reg 14 32bit mmio: [e0000000, efffffff]
PCI: 0000:01:00.0 reg 18 32bit mmio: [f3000000, f3ffffff]
PCI: 0000:01:00.0 reg 30 32bit mmio: [0, 1ffff]
PCI: bridge 0000:00:01.0 32bit mmio: [f2000000, f4ffffff]
PCI: bridge 0000:00:01.0 32bit mmio pref: [e0000000, efffffff]
PCI: 0000:02:01.0 reg 10 32bit mmio: [f7000000, f701ffff]
PCI: 0000:02:01.0 reg 18 io port: [a000, a01f]
pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
pci 0000:02:01.0: PME# disabled
PCI: bridge 0000:00:03.0 io port: [a000, afff]
PCI: bridge 0000:00:03.0 32bit mmio: [f7000000, f70fffff]
PCI: 0000:03:03.0 reg 10 32bit mmio: [f6008000, f60087ff]
PCI: 0000:03:03.0 reg 14 32bit mmio: [f6000000, f6003fff]
pci 0000:03:03.0: supports D1
pci 0000:03:03.0: supports D2
pci 0000:03:03.0: PME# supported from D0 D1 D2 D3hot
pci 0000:03:03.0: PME# disabled
PCI: 0000:03:0a.0 reg 10 io port: [8000, 80ff]
PCI: 0000:03:0a.0 reg 14 64bit mmio: [f6004000, f6005fff]
PCI: 0000:03:0a.0 reg 1c io port: [8400, 84ff]
PCI: 0000:03:0a.0 reg 30 32bit mmio: [0, 7ffff]
PCI: 0000:03:0a.1 reg 10 io port: [8800, 88ff]
PCI: 0000:03:0a.1 reg 14 64bit mmio: [f6006000, f6007fff]
PCI: 0000:03:0a.1 reg 1c io port: [8c00, 8cff]
PCI: 0000:03:0a.1 reg 30 32bit mmio: [0, 7ffff]
PCI: 0000:03:0b.0 reg 10 io port: [9000, 901f]
PCI: 0000:03:0b.1 reg 10 io port: [9400, 9407]
PCI: 0000:03:0d.0 reg 10 io port: [9800, 987f]
PCI: 0000:03:0d.0 reg 14 32bit mmio: [f6009000, f600907f]
PCI: 0000:03:0d.0 reg 30 32bit mmio: [0, 1ffff]
pci 0000:03:0d.0: supports D1
pci 0000:03:0d.0: supports D2
pci 0000:03:0d.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:03:0d.0: PME# disabled
pci 0000:00:1e.0: transparent bridge
PCI: bridge 0000:00:1e.0 io port: [8000, 9fff]
PCI: bridge 0000:00:1e.0 32bit mmio: [f5000000, f6ffffff]
bus 00 -> node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 *9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 16 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
hpet clockevent registered
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
ACPI: RTC can wake from S4
system 00:01: ioport range 0xb78-0xb7b has been reserved
system 00:01: ioport range 0xf78-0xf7b has been reserved
system 00:01: ioport range 0xa78-0xa7b has been reserved
system 00:01: ioport range 0xe78-0xe7b has been reserved
system 00:01: ioport range 0xbbc-0xbbf has been reserved
system 00:01: ioport range 0xfbc-0xfbf has been reserved
system 00:01: ioport range 0x4d0-0x4d1 has been reserved
system 00:0d: ioport range 0x400-0x4bf could not be reserved
system 00:0d: ioport range 0x295-0x296 has been reserved
system 00:0f: iomem range 0xd9e00-0xdbfff has been reserved
system 00:0f: iomem range 0xf0000-0xf7fff could not be reserved
system 00:0f: iomem range 0xf8000-0xfbfff could not be reserved
system 00:0f: iomem range 0xfc000-0xfffff could not be reserved
system 00:0f: iomem range 0x7fee0000-0x7fefffff could not be reserved
system 00:0f: iomem range 0x0-0x9ffff could not be reserved
system 00:0f: iomem range 0x100000-0x7fedffff could not be reserved
system 00:0f: iomem range 0xfec00000-0xfec00fff could not be reserved
system 00:0f: iomem range 0xfec01000-0xfed8ffff could not be reserved
system 00:0f: iomem range 0xfee00000-0xfee00fff could not be reserved
system 00:0f: iomem range 0xffb00000-0xffb7ffff could not be reserved
system 00:0f: iomem range 0xfff00000-0xffffffff could not be reserved
system 00:0f: iomem range 0xe0000-0xeffff has been reserved
pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
pci 0000:00:01.0:   IO window: disabled
pci 0000:00:01.0:   MEM window: 0xf2000000-0xf4ffffff
pci 0000:00:01.0:   PREFETCH window: 0x000000e0000000-0x000000efffffff
pci 0000:00:03.0: PCI bridge, secondary bus 0000:02
pci 0000:00:03.0:   IO window: 0xa000-0xafff
pci 0000:00:03.0:   MEM window: 0xf7000000-0xf70fffff
pci 0000:00:03.0:   PREFETCH window: disabled
pci 0000:00:1e.0: PCI bridge, secondary bus 0000:03
pci 0000:00:1e.0:   IO window: 0x8000-0x9fff
pci 0000:00:1e.0:   MEM window: 0xf5000000-0xf6ffffff
pci 0000:00:1e.0:   PREFETCH window: 0x00000080000000-0x000000801fffff
pci 0000:00:1e.0: setting latency timer to 64
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [0, ffffffff]
bus: 01 index 0 mmio: [0, 0]
bus: 01 index 1 mmio: [f2000000, f4ffffff]
bus: 01 index 2 mmio: [e0000000, efffffff]
bus: 01 index 3 mmio: [0, 0]
bus: 02 index 0 io port: [a000, afff]
bus: 02 index 1 mmio: [f7000000, f70fffff]
bus: 02 index 2 mmio: [0, 0]
bus: 02 index 3 mmio: [0, 0]
bus: 03 index 0 io port: [8000, 9fff]
bus: 03 index 1 mmio: [f5000000, f6ffffff]
bus: 03 index 2 mmio: [80000000, 801fffff]
bus: 03 index 3 io port: [0, ffff]
bus: 03 index 4 mmio: [0, ffffffff]
...

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[J.A. Magallón]

On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:

> one have gran < 1M
> 
> reg00: base=0xd8000000 (3456MB), size= 128MB: uncachable, count=1
> reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
> reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
> reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
> reg05: base=0xd7f80000 (3455MB), size= 512KB: uncachable, count=1
> 
> will get
> 
> Found optimal setting for mtrr clean up
> gran_size: 512K         chunk_size: 2M  num_reg: 7      lose RAM: 0G
> range0: 0000000000000000 - 00000000d8000000
> Setting variable MTRR 0, base: 0GB, range: 2GB, type WB
> Setting variable MTRR 1, base: 2GB, range: 1GB, type WB
> Setting variable MTRR 2, base: 3GB, range: 256MB, type WB
> Setting variable MTRR 3, base: 3328MB, range: 128MB, type WB
> hole: 00000000d7f00000 - 00000000d7f80000
> Setting variable MTRR 4, base: 3455MB, range: 512KB, type UC
> rangeX: 0000000100000000 - 0000000128000000
> Setting variable MTRR 5, base: 4GB, range: 512MB, type WB
> Setting variable MTRR 6, base: 4608MB, range: 128MB, type WB
> 
> so start from 64k instead of 1M
> 
>

Also, on a 64 bit box with 4Gb, it gives this:

cicely:~# cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1

Patch below cleans up formatting, with space for big bases and sizes (64 Gb).

diff -p -up arch/x86/kernel/cpu/mtrr/if.c.orig arch/x86/kernel/cpu/mtrr/if.c
--- arch/x86/kernel/cpu/mtrr/if.c.orig	2008-10-03 00:16:37.000000000 +0200
+++ arch/x86/kernel/cpu/mtrr/if.c	2008-10-03 00:22:34.000000000 +0200
@@ -16,7 +16,7 @@
 static const char *const mtrr_strings[MTRR_NUM_TYPES] =
 {
     "uncachable",               /* 0 */
-    "write-combining",          /* 1 */
+    "write-combine",            /* 1 */
     "?",                        /* 2 */
     "?",                        /* 3 */
     "write-through",            /* 4 */
@@ -405,9 +405,9 @@ static int mtrr_seq_show(struct seq_file
 			}
 			/* RED-PEN: base can be > 32bit */ 
 			len += seq_printf(seq, 
-				   "reg%02i: base=0x%05lx000 (%4luMB), size=%4lu%cB: %s, count=%d\n",
+				   "reg%02i: base=0x%06lx000 (%5luMB), size=%5lu%cB, count=%d: %s\n",
 			     i, base, base >> (20 - PAGE_SHIFT), size, factor,
-			     mtrr_attrib_to_str(type), mtrr_usage_table[i]);
+			     mtrr_usage_table[i], mtrr_attrib_to_str(type));
 		}
 	}
 	return 0;

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>>
>> so start from 64k instead of 1M
>>
>
> Or there is something I don't catch about mtrrs, or it still does silly
> things.
>
> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
>
> werewolf:/proc> cat mtrr
> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
> reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
> reg05: base=0x7c000000 (1984MB), size=  64MB: write-back, count=1
> reg06: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
>
> So it adds a last WB zone, but substracts the last 1Mb. (Why do
> I have that stupid uncacheable mb ? probably a bios issue...)
> But those two 64 mb zones could be add to a 128Mb, that new one
> with previous to 256Mb and so on, giving something like:
>
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
>
> Is this incorrect ?
>

can you boot with mtrr_cleanup_debug?

also what is /proc/mtrr with disable_mtrr_cleanup?

YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 3:32 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
> Also, on a 64 bit box with 4Gb, it gives this:
>
> cicely:~# cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
>
boundary handling may have problem...

should have
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1

can you post /proc/mtrr with disable_mtrr_cleanup?

YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 3:39 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Thu, Oct 2, 2008 at 3:32 PM, J.A. Magallón <jamagallon@ono.com> wrote:
>> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>>
>> Also, on a 64 bit box with 4Gb, it gives this:
>>
>> cicely:~# cat /proc/mtrr
>> reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
>> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
>> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
>>
> boundary handling may have problem...

can you try

diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index ef64128..70beb13 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -1044,7 +1044,7 @@ second_try:
                hole_sizek = range0_sizek - state->range_sizek - second_sizek;

                /* hole size should be less than half of range0 size */
-               if (hole_sizek > (range0_sizek >> 1) &&
+               if (hole_sizek >= (range0_sizek >> 1) &&
                    range0_sizek >= chunk_sizek) {
                        range0_sizek -= chunk_sizek;
                        second_sizek = 0;

YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 3:33 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón <jamagallon@ono.com> wrote:
>> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>>
>>>
>>> so start from 64k instead of 1M
>>>
>>
>> Or there is something I don't catch about mtrrs, or it still does silly
>> things.
>>
>> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
>>
>> werewolf:/proc> cat mtrr
>> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
>> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
>> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
>> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
>> reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
>> reg05: base=0x7c000000 (1984MB), size=  64MB: write-back, count=1
>> reg06: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
>>
>> So it adds a last WB zone, but substracts the last 1Mb. (Why do
>> I have that stupid uncacheable mb ? probably a bios issue...)
>> But those two 64 mb zones could be add to a 128Mb, that new one
>> with previous to 256Mb and so on, giving something like:
>>
>> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>> reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
>>
>> Is this incorrect ?
>>
>
> can you boot with mtrr_cleanup_debug?
>
> also what is /proc/mtrr with disable_mtrr_cleanup?

are you on latest tip/master?

YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[J.A. Magallón]

On Thu, 2 Oct 2008 15:33:10 -0700, "Yinghai Lu" <yinghai@kernel.org> wrote:

> On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> > On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >
> >>
> >> so start from 64k instead of 1M
> >>
> >
> > Or there is something I don't catch about mtrrs, or it still does silly
> > things.
> >
> > I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
> >
> > werewolf:/proc> cat mtrr
> > reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
> > reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
> > reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
> > reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
> > reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
> > reg05: base=0x7c000000 (1984MB), size=  64MB: write-back, count=1
> > reg06: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
> >
> > So it adds a last WB zone, but substracts the last 1Mb. (Why do
> > I have that stupid uncacheable mb ? probably a bios issue...)
> > But those two 64 mb zones could be add to a 128Mb, that new one
> > with previous to 256Mb and so on, giving something like:
> >
> > reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> > reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
> >
> > Is this incorrect ?
> >
> 
> can you boot with mtrr_cleanup_debug?
> 

I don't have such option in my kernel, this is -rc8-git3.

> also what is /proc/mtrr with disable_mtrr_cleanup?
> 
>
Yeah, it goes right on the Xeon:

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1

Will try your patch now.

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[J.A. Magallón]

On Thu, 2 Oct 2008 15:52:11 -0700, "Yinghai Lu" <yinghai@kernel.org> wrote:

> On Thu, Oct 2, 2008 at 3:33 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> > On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> >> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >>
> >>>
> >>> so start from 64k instead of 1M
> >>>
> >>
> >> Or there is something I don't catch about mtrrs, or it still does silly
> >> things.
> >>
> >> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
> >>
> >> werewolf:/proc> cat mtrr
> >> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
> >> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
> >> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
> >> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
> >> reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
> >> reg05: base=0x7c000000 (1984MB), size=  64MB: write-back, count=1
> >> reg06: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
> >>
> >> So it adds a last WB zone, but substracts the last 1Mb. (Why do
> >> I have that stupid uncacheable mb ? probably a bios issue...)
> >> But those two 64 mb zones could be add to a 128Mb, that new one
> >> with previous to 256Mb and so on, giving something like:
> >>
> >> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> >> reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
> >>
> >> Is this incorrect ?
> >>
> >
> > can you boot with mtrr_cleanup_debug?
> >
> > also what is /proc/mtrr with disable_mtrr_cleanup?
> 
> are you on latest tip/master?
> 

No, I use rc8-git3 with your patches (the small gran_size series and the
parameter rename, except the debug one) manually applied.

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 4:00 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> On Thu, 2 Oct 2008 15:52:11 -0700, "Yinghai Lu" <yinghai@kernel.org> wrote:
>
>> On Thu, Oct 2, 2008 at 3:33 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>> > On Thu, Oct 2, 2008 at 3:03 PM, J.A. Magallón <jamagallon@ono.com> wrote:
>> >> On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>> >>
>> >>>
>> >>> so start from 64k instead of 1M
>> >>>
>> >>
>> >> Or there is something I don't catch about mtrrs, or it still does silly
>> >> things.
>> >>
>> >> I have an ASUS PCDL, dual xeon, 2Gb of memory. Mtrrs after cleanup are:
>> >>
>> >> werewolf:/proc> cat mtrr
>> >> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
>> >> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
>> >> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1
>> >> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1
>> >> reg04: base=0x78000000 (1920MB), size=  64MB: write-back, count=1
>> >> reg05: base=0x7c000000 (1984MB), size=  64MB: write-back, count=1
>> >> reg06: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
>> >>
>> >> So it adds a last WB zone, but substracts the last 1Mb. (Why do
>> >> I have that stupid uncacheable mb ? probably a bios issue...)
>> >> But those two 64 mb zones could be add to a 128Mb, that new one
>> >> with previous to 256Mb and so on, giving something like:
>> >>
>> >> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>> >> reg01: base=0x7ff00000 (2047MB), size=   1MB: uncachable, count=1
>> >>
>> >> Is this incorrect ?
>> >>
>> >
>> > can you boot with mtrr_cleanup_debug?
>> >
>> > also what is /proc/mtrr with disable_mtrr_cleanup?
>>
>> are you on latest tip/master?
>>
>
> No, I use rc8-git3 with your patches (the small gran_size series and the
> parameter rename, except the debug one) manually applied.
>

ah..
please pick up all of them from tip/master...

      x86: don't need to go to chunksize to 4G
      x86: mtrr_cleanup optimization, v2
      x86: add mtrr_cleanup_debug command line
      x86: cleanup, remove extra ifdef
      x86: mtrr_cleanup hole size should be less than half of chunk_size, v2
      x86: mtrr_cleanup safe to get more spare regs now
      x86: mtrr_cleanup prepare to make gran_size to less 1M
      x86: mtrr_cleanup try gran_size to less than 1M
      x86: change MTRR_SANITIZER to def_bool y


YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[J.A. Magallón]

On Thu, 2 Oct 2008 15:39:34 -0700, "Yinghai Lu" <yinghai@kernel.org> wrote:

> On Thu, Oct 2, 2008 at 3:32 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> > On Mon, 29 Sep 2008 18:54:12 -0700, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
> >
> > Also, on a 64 bit box with 4Gb, it gives this:
> >
> > cicely:~# cat /proc/mtrr
> > reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
> > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
> > reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
> >
> boundary handling may have problem...
> 
> should have
> > reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1

should not this                           ^^^^^  be 4096MB ??

> > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
> 
> can you post /proc/mtrr with disable_mtrr_cleanup?
> 

Oops, sorry, this is without cleanup. This is a distro kernel and is built
but not enable by deafult. As it is rc7, I will use 'enble_mtrr_cleanup' ;):

cicely:~# cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1

I have lost 2Gb ?

cicely:~# free
             total       used       free     shared    buffers     cached
Mem:       3755568     182348    3573220          0      14024      72716
-/+ buffers/cache:      95608    3659960

I can't easily try your patch, this is a distro kernel.
I will get the src.rpm...

Ahhhhh....

This is a dual opteron board. dmidecode says:

Handle 0x0026, DMI type 16, 15 bytes
Physical Memory Array
    Location: System Board Or Motherboard
    Use: System Memory
    Error Correction Type: Single-bit ECC
    Maximum Capacity: 8 GB
    Error Information Handle: Not Provided
    Number Of Devices: 8

So it maps one Opteron memory in first 4Gb and the other on the second 4Gb.
So I should have 2Gb@0 and 2Gb@4Gb.
What I don't know is why the bios eats up 256Mb.

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 4:20 PM, J.A. Magallón <jamagallon@ono.com> wrote:
> On Thu, 2 Oct 2008 15:39:34 -0700, "Yinghai Lu" <yinghai@kernel.org> wrote:
>
> Oops, sorry, this is without cleanup. This is a distro kernel and is built
> but not enable by deafult. As it is rc7, I will use 'enble_mtrr_cleanup' ;):
>
> cicely:~# cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
>
> I have lost 2Gb ?

that is memhole

>
> cicely:~# free
>             total       used       free     shared    buffers     cached
> Mem:       3755568     182348    3573220          0      14024      72716
> -/+ buffers/cache:      95608    3659960
>
> I can't easily try your patch, this is a distro kernel.
> I will get the src.rpm...

just pull tip/master, and use your config from /boot/config....

>
> Ahhhhh....
>
> This is a dual opteron board. dmidecode says:
>
> Handle 0x0026, DMI type 16, 15 bytes
> Physical Memory Array
>    Location: System Board Or Motherboard
>    Use: System Memory
>    Error Correction Type: Single-bit ECC
>    Maximum Capacity: 8 GB
>    Error Information Handle: Not Provided
>    Number Of Devices: 8
>
> So it maps one Opteron memory in first 4Gb and the other on the second 4Gb.
> So I should have 2Gb@0 and 2Gb@4Gb.
> What I don't know is why the bios eats up 256Mb.

check if you enable memhole remapping in BIOS.

YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[D. Hugh Redelmeier]

| From: Yinghai Lu <yinghai@kernel.org>

| can you boot with mtrr_cleanup_debug?
| 
| also what is /proc/mtrr with disable_mtrr_cleanup?

Shouldn't mtrr_cleanup_debug show the pre-cleanup MTRR settings?

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Yinghai Lu]

On Thu, Oct 2, 2008 at 4:55 PM, D. Hugh Redelmeier <hugh@mimosa.com> wrote:
> | From: Yinghai Lu <yinghai@kernel.org>
>
> | can you boot with mtrr_cleanup_debug?
> |
> | also what is /proc/mtrr with disable_mtrr_cleanup?
>
> Shouldn't mtrr_cleanup_debug show the pre-cleanup MTRR settings?

yeah, will add some line about that.

YH

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Ingo Molnar]

* J.A. Magallón <jamagallon@ono.com> wrote:

> Also, on a 64 bit box with 4Gb, it gives this:
> 
> cicely:~# cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
> 
> Patch below cleans up formatting, with space for big bases and sizes (64 Gb).

applied to tip/x86/mtrr, thanks!

> +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
> @@ -16,7 +16,7 @@
>  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
>  {
>      "uncachable",               /* 0 */
> -    "write-combining",          /* 1 */
> +    "write-combine",            /* 1 */

hm, maybe this bit could confuse versions of Xorg that modifies 
/proc/mtrr - i.e. this could be part of the ABI towards user-space. 
We'll see.

	Ingo

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Ingo Molnar]

* Yinghai Lu <yinghai@kernel.org> wrote:

> > boundary handling may have problem...
> 
> can you try
> 
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index ef64128..70beb13 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -1044,7 +1044,7 @@ second_try:
>                 hole_sizek = range0_sizek - state->range_sizek - second_sizek;
> 
>                 /* hole size should be less than half of range0 size */
> -               if (hole_sizek > (range0_sizek >> 1) &&
> +               if (hole_sizek >= (range0_sizek >> 1) &&
>                     range0_sizek >= chunk_sizek) {

applied to tip/x86/mtrr, thanks Yinghai!

	Ingo

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[H. Peter Anvin]

Ingo Molnar wrote:
> * J.A. Magallón <jamagallon@ono.com> wrote:
> 
>> Also, on a 64 bit box with 4Gb, it gives this:
>>
>> cicely:~# cat /proc/mtrr
>> reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
>> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
>> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
>>
>> Patch below cleans up formatting, with space for big bases and sizes (64 Gb).
> 
> applied to tip/x86/mtrr, thanks!
> 
>> +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
>> @@ -16,7 +16,7 @@
>>  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
>>  {
>>      "uncachable",               /* 0 */
>> -    "write-combining",          /* 1 */
>> +    "write-combine",            /* 1 */
> 
> hm, maybe this bit could confuse versions of Xorg that modifies 
> /proc/mtrr - i.e. this could be part of the ABI towards user-space. 
> We'll see.
> 

This *IS* part of the ABI toward userspace, although I think Xorg uses 
the ioctl() interface.

	-hpa

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[H. Peter Anvin]

Ingo Molnar wrote:
> 
>> +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
>> @@ -16,7 +16,7 @@
>>  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
>>  {
>>      "uncachable",               /* 0 */
>> -    "write-combining",          /* 1 */
>> +    "write-combine",            /* 1 */
> 
> hm, maybe this bit could confuse versions of Xorg that modifies 
> /proc/mtrr - i.e. this could be part of the ABI towards user-space. 
> We'll see.
> 

By the way, this is just plain wrong; the cachability name is "Write 
Combining (WC)" not "write-combine".

	-hpa

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[J.A. Magallón]

On Fri, 3 Oct 2008 09:37:27 +0200, Ingo Molnar <mingo@elte.hu> wrote:

> 
> * J.A. Magallón <jamagallon@ono.com> wrote:
> 
> > Also, on a 64 bit box with 4Gb, it gives this:
> > 
> > cicely:~# cat /proc/mtrr
> > reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
> > reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> > reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
> > reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
> > reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
> > 
> > Patch below cleans up formatting, with space for big bases and sizes (64 Gb).
> 
> applied to tip/x86/mtrr, thanks!
> 
> > +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
> > @@ -16,7 +16,7 @@
> >  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
> >  {
> >      "uncachable",               /* 0 */
> > -    "write-combining",          /* 1 */
> > +    "write-combine",            /* 1 */
> 
> hm, maybe this bit could confuse versions of Xorg that modifies 
> /proc/mtrr - i.e. this could be part of the ABI towards user-space. 
> We'll see.
> 
> 	Ingo

Oops, it's not only used for messages, also for writes in /proc !!!

Forget this part.

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2009.0 (Cooker) for i586
Linux 2.6.25-jam18 (gcc 4.3.1 20080626 (GCC) #1 SMP

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Ingo Molnar wrote:
>> * J.A. Magallón <jamagallon@ono.com> wrote:
>>
>>> Also, on a 64 bit box with 4Gb, it gives this:
>>>
>>> cicely:~# cat /proc/mtrr
>>> reg00: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>>> reg01: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>> reg02: base=0x140000000 (5120MB), size= 512MB: write-back, count=1
>>> reg03: base=0x160000000 (5632MB), size= 256MB: write-back, count=1
>>> reg04: base=0x80000000 (2048MB), size=2048MB: uncachable, count=1
>>>
>>> Patch below cleans up formatting, with space for big bases and sizes (64 Gb).
>>
>> applied to tip/x86/mtrr, thanks!
>>
>>> +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
>>> @@ -16,7 +16,7 @@
>>>  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
>>>  {
>>>      "uncachable",               /* 0 */
>>> -    "write-combining",          /* 1 */
>>> +    "write-combine",            /* 1 */
>>
>> hm, maybe this bit could confuse versions of Xorg that modifies  
>> /proc/mtrr - i.e. this could be part of the ABI towards user-space.  
>> We'll see.
>>
>
> This *IS* part of the ABI toward userspace, although I think Xorg uses 
> the ioctl() interface.

yeah, but aspects of the ABI that applications do not rely on can 
generally be changed. OTOH, i've undone this aspect of the patch - 
/proc/mtrr is a legacy interface and changes to it are unnecessary. I 
kept the boot printout cleanups.

	Ingo

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

> Ingo Molnar wrote:
>>
>>> +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
>>> @@ -16,7 +16,7 @@
>>>  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
>>>  {
>>>      "uncachable",               /* 0 */
>>> -    "write-combining",          /* 1 */
>>> +    "write-combine",            /* 1 */
>>
>> hm, maybe this bit could confuse versions of Xorg that modifies  
>> /proc/mtrr - i.e. this could be part of the ABI towards user-space.  
>> We'll see.
>>
>
> By the way, this is just plain wrong; the cachability name is "Write 
> Combining (WC)" not "write-combine".

and "uncachable" should be "uncacheable" i guess.

anyway, agreed, lets not touch this.

	Ingo

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[H. Peter Anvin]

Ingo Molnar wrote:
>>>
>>>> +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
>>>> @@ -16,7 +16,7 @@
>>>>  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
>>>>  {
>>>>      "uncachable",               /* 0 */
>>>> -    "write-combining",          /* 1 */
>>>> +    "write-combine",            /* 1 */
>>> hm, maybe this bit could confuse versions of Xorg that modifies  
>>> /proc/mtrr - i.e. this could be part of the ABI towards user-space.  
>>> We'll see.
>>>
>> This *IS* part of the ABI toward userspace, although I think Xorg uses 
>> the ioctl() interface.
> 
> yeah, but aspects of the ABI that applications do not rely on can 
> generally be changed. OTOH, i've undone this aspect of the patch - 
> /proc/mtrr is a legacy interface and changes to it are unnecessary. I 
> kept the boot printout cleanups.
> 

Great.  It's worth noting that these strings aren't just used for 
readout, but also for setting.

	-hpa

Re: [PATCH 2/2] x86: mtrr_cleanup try gran_size to less than 1M

[D. Hugh Redelmeier]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1642 bytes --]

| From: H. Peter Anvin <hpa@zytor.com>

| Ingo Molnar wrote:
| > * J.A. Magallón <jamagallon@ono.com> wrote:

| > > +++ arch/x86/kernel/cpu/mtrr/if.c     2008-10-03 00:22:34.000000000 +0200
| > > @@ -16,7 +16,7 @@
| > >  static const char *const mtrr_strings[MTRR_NUM_TYPES] =
| > >  {
| > >      "uncachable",               /* 0 */
| > > -    "write-combining",          /* 1 */
| > > +    "write-combine",            /* 1 */
| > 
| > hm, maybe this bit could confuse versions of Xorg that modifies /proc/mtrr -
| > i.e. this could be part of the ABI towards user-space. We'll see.
| > 
| 
| This *IS* part of the ABI toward userspace, although I think Xorg uses the
| ioctl() interface.

My mtrr-uncover program uses this interface.

One reason is that the ioctl interface is broken.  See
http://lkml.org/lkml/2008/8/5/62

I too understand that Xorg drivers uses the ioctl interface.  Since
they only use it on video device buffers, and those buffers always
seem to start and end below 4GiB, the ioctl bugs probably don't affect
Xorg.

The ioctl bugs do mean that Xorg drivers cannot even see the MTRR
nesting problems let alone address them.

The ib_path driver apparently uses MTRRs in a way analogous to Xorg
drivers.  There is a script that is part of Fedora that uses the
/proc/mtrr interface to attempt to fix nested MTRRs:
  http://cvs.fedora.redhat.com/viewvc/devel/rdma/rdma-fixup-mtrr.awk

There may well be other users of this API.  Or is it an ABI.  I'm not sure.

It would be useful to know what code exists that uses the
MTRR-changing interfaces.  I only know about the ones I've mentioned
above.  Does anyone know of others?