[PATCH] x86: disable_mtrr_trim only need for x86_64

[PATCH] x86: disable_mtrr_trim only need for x86_64

[Yinghai Lu]

[PATCH] x86: disable_mtrr_trim only need for x86_64

mtrr_trim_uncached_memory is only used in x86_64,

so disable_mtrr_trim is not needed for x86_32

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 46763e3..608c88a 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_driver = {
 	.resume		= mtrr_restore,
 };
 
+#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -633,7 +634,6 @@ static int __init disable_mtrr_trim_setup(char *str)
 }
 early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
 
-#ifdef CONFIG_X86_64
 /**
  * mtrr_trim_uncached_memory - trim RAM not covered by MTRRs
  *

Re: [PATCH] x86: disable_mtrr_trim only need for x86_64

[H. Peter Anvin]

Yinghai Lu wrote:
> [PATCH] x86: disable_mtrr_trim only need for x86_64
> 
> mtrr_trim_uncached_memory is only used in x86_64,
> 
> so disable_mtrr_trim is not needed for x86_32
> 
> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

That seems like a bug, and if so this patch goes the wrong direction. 
(If the 32-bit code has another solution for the same problem, they 
should be unified.)

The trimming of uncachable memory affects both 32- and 64-bit kernels; 
it's the same hardware, and even 32-bit kernels (with PAE) can access 
memory above 4 GB.

	-hpa

Re: [PATCH] x86: disable_mtrr_trim only need for x86_64

[Yinghai Lu]

On Jan 19, 2008 9:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Yinghai Lu wrote:
> > [PATCH] x86: disable_mtrr_trim only need for x86_64
> >
> > mtrr_trim_uncached_memory is only used in x86_64,
> >
> > so disable_mtrr_trim is not needed for x86_32
> >
> > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>
> That seems like a bug, and if so this patch goes the wrong direction.
> (If the 32-bit code has another solution for the same problem, they
> should be unified.)
>
> The trimming of uncachable memory affects both 32- and 64-bit kernels;
> it's the same hardware, and even 32-bit kernels (with PAE) can access
> memory above 4 GB.
>

the trim fix for x86_64 is update end_pfn, and use that as max_pfn,
and max_low_pfn in setup_arch.

but i386 is setup_arch is only using max_low_pfn.

to make you happy, the simple way is update e820 table so code could
be unified between i386 and x86_64

update the e820 table by checking mtrr like checking gart hole...

is that OK?

YH

[PATCH] x86_64: update e820 instead of updating end_pfn

[Yinghai Lu]

[PATCH] x86_64: update e820 instead of updating end_pfn

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

so we can reuse some code for x86_32.

need to add early_identify_cpu for x86_32, and move mtrr_bp_init early

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 46763e3..28ae79a 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -644,16 +644,17 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
  * it from the kernel's allocation pools, warning the user with an obnoxious
  * message.
  */
-void __init mtrr_trim_uncached_memory(void)
+int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
 	unsigned long i, base, size, highest_addr = 0, def, dummy;
 	mtrr_type type;
+	u64 trim_start, trim_size;
 
 	/* Make sure we only trim uncachable memory on Intel machines */
 	rdmsr(MTRRdefType_MSR, def, dummy);
 	def &= 0xff;
 	if (!is_cpu(INTEL) || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE)
-		return;
+		return 0;
 
 	/* Find highest cached pfn */
 	for (i = 0; i < num_var_ranges; i++) {
@@ -673,8 +674,18 @@ void __init mtrr_trim_uncached_memory(void)
 		       "memory, trimmed %ld pages\n", end_pfn -
 		       (highest_addr >> PAGE_SHIFT));
 		printk(KERN_WARNING "***************\n");
-		end_pfn = highest_addr >> PAGE_SHIFT;
+
+		printk(KERN_INFO "update e820 for mtrr\n");
+		trim_start = highest_addr;
+		trim_size = end_pfn;
+		trim_size <<= PAGE_SHIFT;
+		trim_size -= trim_start;
+		add_memory_region(trim_start, trim_size, E820_RESERVED);
+		update_e820();
+		return 1;
 	}
+
+	return 0;
 }
 #endif
 
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 2ad8bdd..5194c2a 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
-	/* Trim memory not covered by WB MTRRs */
+	/* update e820 for memory not covered by WB MTRRs */
 	mtrr_bp_init();
-	mtrr_trim_uncached_memory();
+	if (mtrr_trim_uncached_memory(end_pfn)) {
+		e820_register_active_regions(0, 0, -1UL);
+		end_pfn = e820_end_of_ram();
+	}
 
 	num_physpages = end_pfn;
 
diff --git a/include/asm-x86/mtrr.h b/include/asm-x86/mtrr.h
index 96876ec..e552503 100644
--- a/include/asm-x86/mtrr.h
+++ b/include/asm-x86/mtrr.h
@@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsigned long base, unsigned long size);
 extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi);
 extern void mtrr_ap_init(void);
 extern void mtrr_bp_init(void);
-extern void mtrr_trim_uncached_memory(void);
+extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 #  else
 #define mtrr_save_fixed_ranges(arg) do {} while (0)
 #define mtrr_save_state() do {} while (0)
@@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int reg, unsigned long base,
 {
     return -ENODEV;
 }
-static __inline__ void mtrr_trim_uncached_memory(void)
+static __inline__ int mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
+	return 0;
 }
 static __inline__ void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) {;}
 

Re: [PATCH] x86_64: update e820 instead of updating end_pfn

[Ingo Molnar]

* Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:

> [PATCH] x86_64: update e820 instead of updating end_pfn
> 
> when mtrr is not covering all e820 table, need to trim the ram, need 
> to update e820

ok, i like this approach even more - applied. Would you like to have a 
shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected 
by the same problem (if not more).

	Ingo

Re: [PATCH] x86_64: update e820 instead of updating end_pfn

[Andi Kleen]

On Sunday 20 January 2008 10:20:27 Ingo Molnar wrote:
> * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> > [PATCH] x86_64: update e820 instead of updating end_pfn
> >
> > when mtrr is not covering all e820 table, need to trim the ram, need
> > to update e820
>
> ok, i like this approach even more - applied. Would you like to have a
> shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected
> by the same problem (if not more).

What about the AMD fix I posted? You ignored that one for now but it is far 
more critical because it makes these patches break any modern AMD machine
with >3GB.

-Andi

Re: [PATCH] x86_64: update e820 instead of updating end_pfn

[Yinghai Lu]

On Jan 20, 2008 1:20 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>
> > [PATCH] x86_64: update e820 instead of updating end_pfn
> >
> > when mtrr is not covering all e820 table, need to trim the ram, need
> > to update e820
>
> ok, i like this approach even more - applied. Would you like to have a
> shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected
> by the same problem (if not more).

for 32 bit, it could use the same mtrr_trim_uncached_memory.

but we need to move mtrr_bp_init calling into setup_arch.

YH

YH

[PATCH] x86_64: update e820 instead of updating end_pfn v2

[Yinghai Lu]

[PATCH] x86_64: update e820 instead of updating end_pfn v2

need to be applied after andi's patch for AMD tom2 wb check

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

so we can reuse some code for x86_32.

need to add early_identify_cpu for x86_32, and move mtrr_bp_init early

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

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
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
+#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -633,17 +634,16 @@ static int __init disable_mtrr_trim_setu
 }
 early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
 
-#ifdef CONFIG_X86_64
-
 /*
  * Newer AMD K8s and later CPUs have a special magic MSR way to force WB
  * for memory >4GB. Check for that here.
  * Note this won't check if the MTRRs < 4GB where the magic bit doesn't
  * apply to are wrong, but so far we don't know of any such case in the wild.
  */
+#define Tom2Enabled (1U << 21)
 #define Tom2ForceMemTypeWB (1U << 22)
 
-static __init int amd_special_default_mtrr(void)
+static __init int amd_special_default_mtrr(unsigned long end_pfn)
 {
 	u32 l, h;
 
@@ -661,8 +661,9 @@ static __init int amd_special_default_mt
 	 * Memory between 4GB and top of mem is forced WB by this magic bit.
 	 * Reserved before K8RevF, but should be zero there.
 	 */
-	if (l & Tom2ForceMemTypeWB)
-		return 1;
+	if (l & Tom2Enabled)
+		if (l & Tom2ForceMemTypeWB)
+			return 1;
 	return 0;
 }
 
@@ -676,10 +677,11 @@ static __init int amd_special_default_mt
  * memory off the end by adjusting end_pfn, removing it from the kernel's
  * allocation pools, warning the user with an obnoxious message.
  */
-void __init mtrr_trim_uncached_memory(void)
+int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
 	unsigned long i, base, size, highest_addr = 0, def, dummy;
 	mtrr_type type;
+	u64 trim_start, trim_size;
 
 	/*
 	 * Make sure we only trim uncachable memory on machines that
@@ -688,7 +690,7 @@ void __init mtrr_trim_uncached_memory(vo
 	rdmsr(MTRRdefType_MSR, def, dummy);
 	def &= 0xff;
 	if (!is_cpu(INTEL) || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE)
-		return;
+		return 0;
 
 	/* Find highest cached pfn */
 	for (i = 0; i < num_var_ranges; i++) {
@@ -701,8 +703,8 @@ void __init mtrr_trim_uncached_memory(vo
 			highest_addr = base + size;
 	}
 
-	if (amd_special_default_mtrr())
-		return;
+	if (amd_special_default_mtrr(end_pfn))
+		return 0;
 
 	if ((highest_addr >> PAGE_SHIFT) < end_pfn) {
 		printk(KERN_WARNING "***************\n");
@@ -711,8 +713,18 @@ void __init mtrr_trim_uncached_memory(vo
 		       "memory, trimmed %ld pages\n", end_pfn -
 		       (highest_addr >> PAGE_SHIFT));
 		printk(KERN_WARNING "***************\n");
-		end_pfn = highest_addr >> PAGE_SHIFT;
+
+		printk(KERN_INFO "update e820 for mtrr\n");
+		trim_start = highest_addr;
+		trim_size = end_pfn;
+		trim_size <<= PAGE_SHIFT;
+		trim_size -= trim_start;
+		add_memory_region(trim_start, trim_size, E820_RESERVED);
+		update_e820();
+		return 1;
 	}
+
+	return 0;
 }
 #endif
 
Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6/arch/x86/kernel/setup_64.c
@@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
-	/* Trim memory not covered by WB MTRRs */
+	/* update e820 for memory not covered by WB MTRRs */
 	mtrr_bp_init();
-	mtrr_trim_uncached_memory();
+	if (mtrr_trim_uncached_memory(end_pfn)) {
+		e820_register_active_regions(0, 0, -1UL);
+		end_pfn = e820_end_of_ram();
+	}
 
 	num_physpages = end_pfn;
 
Index: linux-2.6/include/asm-x86/mtrr.h
===================================================================
--- linux-2.6.orig/include/asm-x86/mtrr.h
+++ linux-2.6/include/asm-x86/mtrr.h
@@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsig
 extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi);
 extern void mtrr_ap_init(void);
 extern void mtrr_bp_init(void);
-extern void mtrr_trim_uncached_memory(void);
+extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 #  else
 #define mtrr_save_fixed_ranges(arg) do {} while (0)
 #define mtrr_save_state() do {} while (0)
@@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int
 {
     return -ENODEV;
 }
-static __inline__ void mtrr_trim_uncached_memory(void)
+static __inline__ int mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
+	return 0;
 }
 static __inline__ void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) {;}
 

[PATCH] x86_32: trim memory by updating e820

[Yinghai Lu]

[PATCH] x86_32: trim memory by updating e820

need to be applied after the patch for x86_64 version mtrr fix e820 v2.

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

reuse some code for x86_64

here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early

compiled only, need someone test it.


Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 {
-	int i;
 
-	c->loops_per_jiffy = loops_per_jiffy;
 	c->x86_cache_size = -1;
 	c->x86_vendor = X86_VENDOR_UNKNOWN;
 	c->cpuid_level = -1;	/* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin
 
 	if (this_cpu->c_identify)
 		this_cpu->c_identify(c);
+}
 
+void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+{
+	int i;
+
+	c->loops_per_jiffy = loops_per_jiffy;
+	early_identify_cpu(c);
 	/*
 	 * Vendor-specific initialization.  In this section we
 	 * canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)
 	identify_cpu(&boot_cpu_data);
 	sysenter_setup();
 	enable_sep_cpu();
-	mtrr_bp_init();
 }
 
 void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-2.6/arch/x86/kernel/setup_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@
 
 #include <video/edid.h>
 
+#include <asm/mtrr.h>
 #include <asm/apic.h>
 #include <asm/e820.h>
 #include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = virt_to_phys(&__bss_start);
 	bss_resource.end = virt_to_phys(&__bss_stop)-1;
 
+	early_identify_cpu(&boot_cpu_data);
 	parse_early_param();
 
 	if (user_defined_memmap) {
@@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p)
 
 	max_low_pfn = setup_memory();
 
+	/* update e820 for memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	if (mtrr_trim_uncached_memory(max_pfn)) {
+		max_low_pfn = setup_memory();
+	}
+
 #ifdef CONFIG_VMI
 	/*
 	 * Must be after max_low_pfn is determined, and before kernel
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
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
-#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns
 
 	return 0;
 }
-#endif
 
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. 
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
-	disable_mtrr_trim [X86-64, Intel only]
+	disable_mtrr_trim [X86, Intel and AMD only]
 			By default the kernel will trim any uncacheable
 			memory out of your available memory pool based on
 			MTRR settings.  This parameter disables that behavior,
Index: linux-2.6/include/asm-x86/processor.h
===================================================================
--- linux-2.6.orig/include/asm-x86/processor.h
+++ linux-2.6/include/asm-x86/processor.h
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_
 
 void cpu_detect(struct cpuinfo_x86 *c);
 
+extern void early_identify_cpu(struct cpuinfo_x86 *);
 extern void identify_cpu(struct cpuinfo_x86 *);
 extern void identify_boot_cpu(void);
 extern void identify_secondary_cpu(struct cpuinfo_x86 *);
Index: linux-2.6/arch/x86/kernel/e820_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_32.c
+++ linux-2.6/arch/x86/kernel/e820_32.c
@@ -827,3 +827,14 @@ static int __init parse_memmap(char *arg
 	return 0;
 }
 early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+	u8 nr_map;
+
+	nr_map = e820.nr_map;
+	if (sanitize_e820_map(e820.map, &nr_map))
+		return;
+	e820.nr_map = nr_map;
+	printk(KERN_INFO "modified physical RAM map:\n");
+	print_memory_map("modified");
+}
Index: linux-2.6/include/asm-x86/e820_32.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820_32.h
+++ linux-2.6/include/asm-x86/e820_32.h
@@ -19,6 +19,7 @@
 #ifndef __ASSEMBLY__
 
 extern struct e820map e820;
+extern void update_e820(void);
 
 extern int e820_all_mapped(u64 start, u64 end, unsigned type);
 extern int e820_any_mapped(u64 start, u64 end, unsigned type);
@@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 start
 extern int is_memory_all_reserved(u64 start, u64 end);
 extern void find_max_pfn(void);
 extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+			      unsigned long long size, int type);
 extern void e820_register_memory(void);
 extern void limit_regions(unsigned long long size);
 extern void print_memory_map(char *who);

Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2

[Andi Kleen]

>  {
>  	u32 l, h;
>  
> @@ -661,8 +661,9 @@ static __init int amd_special_default_mt
>  	 * Memory between 4GB and top of mem is forced WB by this magic bit.
>  	 * Reserved before K8RevF, but should be zero there.
>  	 */
> -	if (l & Tom2ForceMemTypeWB)
> -		return 1;
> +	if (l & Tom2Enabled)
> +		if (l & Tom2ForceMemTypeWB)
> +			return 1;

That change is good agreed, but I would suggest to put it into a separate
patch with a description

-Andi

Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2

[Harvey Harrison]

On Mon, 2008-01-21 at 06:58 +0100, Andi Kleen wrote:
> >  {
> >  	u32 l, h;
> >  
> > @@ -661,8 +661,9 @@ static __init int amd_special_default_mt
> >  	 * Memory between 4GB and top of mem is forced WB by this magic bit.
> >  	 * Reserved before K8RevF, but should be zero there.
> >  	 */
> > -	if (l & Tom2ForceMemTypeWB)
> > -		return 1;
> > +	if (l & Tom2Enabled)
> > +		if (l & Tom2ForceMemTypeWB)
> > +			return 1;
> 
> That change is good agreed, but I would suggest to put it into a separate
> patch with a description
> 

Perhaps like this:

if (l & (Tom2Enabled|Tom2ForceMemTypeWB))
	return 1;

Harvey

Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2

[Andi Kleen]

> > That change is good agreed, but I would suggest to put it into a separate
> > patch with a description
> > 
> 
> Perhaps like this:
> 
> if (l & (Tom2Enabled|Tom2ForceMemTypeWB))
> 	return 1;

That's not equivalent.

-Andi

Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2

[Li Zefan]

Andi Kleen wrote:
>>> That change is good agreed, but I would suggest to put it into a separate
>>> patch with a description
>>>
>> Perhaps like this:
>>
>> if (l & (Tom2Enabled|Tom2ForceMemTypeWB))
>> 	return 1;
> 
> That's not equivalent.
> 
> -Andi
> 

The equivalence is:

if ((1 & Tom2Enabled) && (1 & Tom2ForceMemTypeWB))
	return 1;

[PATCH] x86_32: trim memory by updating e820 v2

[Yinghai Lu]

[PATCH] x86_32: trim memory by updating e820 v2

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

reuse some code for x86_64

here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early

compiled test only, need someone test it


Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 {
-	int i;
 
-	c->loops_per_jiffy = loops_per_jiffy;
 	c->x86_cache_size = -1;
 	c->x86_vendor = X86_VENDOR_UNKNOWN;
 	c->cpuid_level = -1;	/* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin
 
 	if (this_cpu->c_identify)
 		this_cpu->c_identify(c);
+}
 
+void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+{
+	int i;
+
+	c->loops_per_jiffy = loops_per_jiffy;
+	early_identify_cpu(c);
 	/*
 	 * Vendor-specific initialization.  In this section we
 	 * canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)
 	identify_cpu(&boot_cpu_data);
 	sysenter_setup();
 	enable_sep_cpu();
-	mtrr_bp_init();
 }
 
 void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-2.6/arch/x86/kernel/setup_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@
 
 #include <video/edid.h>
 
+#include <asm/mtrr.h>
 #include <asm/apic.h>
 #include <asm/e820.h>
 #include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = virt_to_phys(&__bss_start);
 	bss_resource.end = virt_to_phys(&__bss_stop)-1;
 
+	early_identify_cpu(&boot_cpu_data);
 	parse_early_param();
 
 	if (user_defined_memmap) {
@@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p)
 
 	max_low_pfn = setup_memory();
 
+	/* update e820 for memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	if (mtrr_trim_uncached_memory(max_pfn)) {
+		max_low_pfn = setup_memory();
+	}
+
 #ifdef CONFIG_VMI
 	/*
 	 * Must be after max_low_pfn is determined, and before kernel
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
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
-#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns
 
 	return 0;
 }
-#endif
 
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. 
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
-	disable_mtrr_trim [X86-64, Intel only]
+	disable_mtrr_trim [X86, Intel and AMD only]
 			By default the kernel will trim any uncacheable
 			memory out of your available memory pool based on
 			MTRR settings.  This parameter disables that behavior,
Index: linux-2.6/include/asm-x86/processor.h
===================================================================
--- linux-2.6.orig/include/asm-x86/processor.h
+++ linux-2.6/include/asm-x86/processor.h
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_
 
 void cpu_detect(struct cpuinfo_x86 *c);
 
+extern void early_identify_cpu(struct cpuinfo_x86 *);
 extern void identify_cpu(struct cpuinfo_x86 *);
 extern void identify_boot_cpu(void);
 extern void identify_secondary_cpu(struct cpuinfo_x86 *);
Index: linux-2.6/arch/x86/kernel/e820_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_32.c
+++ linux-2.6/arch/x86/kernel/e820_32.c
@@ -827,3 +827,14 @@ static int __init parse_memmap(char *arg
 	return 0;
 }
 early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+	u8 nr_map;
+
+	nr_map = e820.nr_map;
+	if (sanitize_e820_map(e820.map, &nr_map))
+		return;
+	e820.nr_map = nr_map;
+	printk(KERN_INFO "modified physical RAM map:\n");
+	print_memory_map("modified");
+}
Index: linux-2.6/include/asm-x86/e820_32.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820_32.h
+++ linux-2.6/include/asm-x86/e820_32.h
@@ -19,6 +19,7 @@
 #ifndef __ASSEMBLY__
 
 extern struct e820map e820;
+extern void update_e820(void);
 
 extern int e820_all_mapped(u64 start, u64 end, unsigned type);
 extern int e820_any_mapped(u64 start, u64 end, unsigned type);
@@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 start
 extern int is_memory_all_reserved(u64 start, u64 end);
 extern void find_max_pfn(void);
 extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+			      unsigned long long size, int type);
 extern void e820_register_memory(void);
 extern void limit_regions(unsigned long long size);
 extern void print_memory_map(char *who);
--- a/arch/x86/kernel/setup_64.c	2008-01-20 22:00:46.000000000 -0800
+++ b/arch/x86/kernel/setup_64.c	2008-01-20 22:01:21.000000000 -0800
@@ -158,8 +158,6 @@
 	.flags = IORESOURCE_RAM,
 };
 
-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c);
-
 #ifdef CONFIG_PROC_VMCORE
 /* elfcorehdr= specifies the location of elf core header
  * stored by the crashed kernel. This option will be passed
@@ -891,7 +889,7 @@
 /* Do some early cpuid on the boot CPU to get some parameter that are
    needed before check_bugs. Everything advanced is in identify_cpu
    below. */
-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 {
 	u32 tfms, xlvl;
 

[PATCH] x86_64: update e820 instead of updating end_pfn v3

[Yinghai Lu]

[PATCH] x86_64: update e820 instead of updating end_pfn v3

need to apply after x86_64 check if Tom2 is enabled

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

so we can reuse some code for x86_32.

after we add early_identify_cpu for x86_32, and move mtrr_bp_init early for x86_32

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

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
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
+#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -633,8 +634,6 @@ static int __init disable_mtrr_trim_setu
 }
 early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
 
-#ifdef CONFIG_X86_64
-
 /*
  * Newer AMD K8s and later CPUs have a special magic MSR way to force WB
  * for memory >4GB. Check for that here.
@@ -644,7 +643,7 @@ early_param("disable_mtrr_trim", disable
 #define Tom2Enabled (1U << 21)
 #define Tom2ForceMemTypeWB (1U << 22)
 
-static __init int amd_special_default_mtrr(void)
+static __init int amd_special_default_mtrr(unsigned long end_pfn)
 {
 	u32 l, h;
 
@@ -678,10 +677,11 @@ static __init int amd_special_default_mt
  * memory off the end by adjusting end_pfn, removing it from the kernel's
  * allocation pools, warning the user with an obnoxious message.
  */
-void __init mtrr_trim_uncached_memory(void)
+int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
 	unsigned long i, base, size, highest_addr = 0, def, dummy;
 	mtrr_type type;
+	u64 trim_start, trim_size;
 
 	/*
 	 * Make sure we only trim uncachable memory on machines that
@@ -690,7 +690,7 @@ void __init mtrr_trim_uncached_memory(vo
 	rdmsr(MTRRdefType_MSR, def, dummy);
 	def &= 0xff;
 	if (!is_cpu(INTEL) || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE)
-		return;
+		return 0;
 
 	/* Find highest cached pfn */
 	for (i = 0; i < num_var_ranges; i++) {
@@ -703,8 +703,8 @@ void __init mtrr_trim_uncached_memory(vo
 			highest_addr = base + size;
 	}
 
-	if (amd_special_default_mtrr())
-		return;
+	if (amd_special_default_mtrr(end_pfn))
+		return 0;
 
 	if ((highest_addr >> PAGE_SHIFT) < end_pfn) {
 		printk(KERN_WARNING "***************\n");
@@ -713,8 +713,18 @@ void __init mtrr_trim_uncached_memory(vo
 		       "memory, trimmed %ld pages\n", end_pfn -
 		       (highest_addr >> PAGE_SHIFT));
 		printk(KERN_WARNING "***************\n");
-		end_pfn = highest_addr >> PAGE_SHIFT;
+
+		printk(KERN_INFO "update e820 for mtrr\n");
+		trim_start = highest_addr;
+		trim_size = end_pfn;
+		trim_size <<= PAGE_SHIFT;
+		trim_size -= trim_start;
+		add_memory_region(trim_start, trim_size, E820_RESERVED);
+		update_e820();
+		return 1;
 	}
+
+	return 0;
 }
 #endif
 
Index: linux-2.6/arch/x86/kernel/setup_64.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6/arch/x86/kernel/setup_64.c
@@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
-	/* Trim memory not covered by WB MTRRs */
+	/* update e820 for memory not covered by WB MTRRs */
 	mtrr_bp_init();
-	mtrr_trim_uncached_memory();
+	if (mtrr_trim_uncached_memory(end_pfn)) {
+		e820_register_active_regions(0, 0, -1UL);
+		end_pfn = e820_end_of_ram();
+	}
 
 	num_physpages = end_pfn;
 
Index: linux-2.6/include/asm-x86/mtrr.h
===================================================================
--- linux-2.6.orig/include/asm-x86/mtrr.h
+++ linux-2.6/include/asm-x86/mtrr.h
@@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsig
 extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi);
 extern void mtrr_ap_init(void);
 extern void mtrr_bp_init(void);
-extern void mtrr_trim_uncached_memory(void);
+extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 #  else
 #define mtrr_save_fixed_ranges(arg) do {} while (0)
 #define mtrr_save_state() do {} while (0)
@@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int
 {
     return -ENODEV;
 }
-static __inline__ void mtrr_trim_uncached_memory(void)
+static __inline__ int mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
+	return 0;
 }
 static __inline__ void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) {;}
 

[PATCH] x86_64: check if Tom2 is enabled

[Yinghai Lu]

[PATCH] x86_64: check if Tom2 is enabled

need to applied after andi's amd special tom2 wb check patch

in amd_special_default_mtrr need to check if TOM2 is enabled

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 289ba1a..26eed57 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -641,6 +641,7 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
  * Note this won't check if the MTRRs < 4GB where the magic bit doesn't
  * apply to are wrong, but so far we don't know of any such case in the wild.
  */
+#define Tom2Enabled (1U << 21)
 #define Tom2ForceMemTypeWB (1U << 22)
 
 static __init int amd_special_default_mtrr(void)
@@ -661,7 +662,8 @@ static __init int amd_special_default_mtrr(void)
 	 * Memory between 4GB and top of mem is forced WB by this magic bit.
 	 * Reserved before K8RevF, but should be zero there.
 	 */
-	if (l & Tom2ForceMemTypeWB)
+	if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) ==
+		 (Tom2Enabled | Tom2ForceMemTypeWB))
 		return 1;
 	return 0;
 }

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Jesse Barnes]

On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
> [PATCH] x86_32: trim memory by updating e820 v2
>
> when mtrr is not covering all e820 table, need to trim the ram, need to
> update e820
>
> reuse some code for x86_64
>
> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
>
> compiled test only, need someone test it

I like this approach too.  So as long as the E820 modification method works 
(i.e. we have some testers, maybe Justin can give it a try), you can add

Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>

or

Acked-by:  Jesse Barnes <jesse.barnes@intel.com>

as appropriate too.

Thanks,
Jesse

Re: [PATCH] x86_64: check if Tom2 is enabled

[Cyrill Gorcunov]

[Yinghai Lu - Sun, Jan 20, 2008 at 10:57:46PM -0800]
| [PATCH] x86_64: check if Tom2 is enabled
| 
| need to applied after andi's amd special tom2 wb check patch
| 
| in amd_special_default_mtrr need to check if TOM2 is enabled
| 
| Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
| 
| diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
| index 289ba1a..26eed57 100644
| --- a/arch/x86/kernel/cpu/mtrr/main.c
| +++ b/arch/x86/kernel/cpu/mtrr/main.c
| @@ -641,6 +641,7 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
|   * Note this won't check if the MTRRs < 4GB where the magic bit doesn't
|   * apply to are wrong, but so far we don't know of any such case in the wild.
|   */
| +#define Tom2Enabled (1U << 21)
|  #define Tom2ForceMemTypeWB (1U << 22)
|  
|  static __init int amd_special_default_mtrr(void)
| @@ -661,7 +662,8 @@ static __init int amd_special_default_mtrr(void)
|  	 * Memory between 4GB and top of mem is forced WB by this magic bit.
|  	 * Reserved before K8RevF, but should be zero there.
|  	 */
| -	if (l & Tom2ForceMemTypeWB)
| +	if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) ==
| +		 (Tom2Enabled | Tom2ForceMemTypeWB))
|  		return 1;
|  	return 0;
|  }

is it possible to change 'l' and 'h' to 'low' and 'high'?
'cause 'l' does look like '1' (one) number...

		- Cyrill -

Re: [PATCH] x86_64: check if Tom2 is enabled

[H. Peter Anvin]

Cyrill Gorcunov wrote:
> 
> is it possible to change 'l' and 'h' to 'low' and 'high'?
> 'cause 'l' does look like '1' (one) number...
> 

I think you should use a different font.  Otherwise we're soon in a 
position where we can't abbreviate anything that starts with L and keep 
using lower case throughout.  That doesn't seem like a valid tradeoff to me.

There are plenty of fonts which have good visual distinction between l 
and 1 and O and 0.

	-hpa

Re: [PATCH] x86_64: check if Tom2 is enabled

[Cyrill Gorcunov]

[H. Peter Anvin - Mon, Jan 21, 2008 at 09:39:16AM -0800]
> Cyrill Gorcunov wrote:
>> is it possible to change 'l' and 'h' to 'low' and 'high'?
>> 'cause 'l' does look like '1' (one) number...
>
> I think you should use a different font.  Otherwise we're soon in a 
> position where we can't abbreviate anything that starts with L and keep 
> using lower case throughout.  That doesn't seem like a valid tradeoff to 
> me.
>
> There are plenty of fonts which have good visual distinction between l and 
> 1 and O and 0.
>
> 	-hpa
>

Hi Peter,

of course you're right!!! but... actually the only several symbols
affected on this: 1-l, O-0 (maybe a few more, dunno) and that is the
case for one-letter-ID only and that is so easy to avoid a such situation.

Anyway - as you wish ;)

		- Cyrill -

Re: [PATCH] x86_64: check if Tom2 is enabled

[Andi Kleen]

> is it possible to change 'l' and 'h' to 'low' and 'high'?
> 'cause 'l' does look like '1' (one) number...

It would be fine for me for someone to implement safe_rdtscll() and get rid
of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder
to read and error prone over the ll 64bit variants.

But I didn't want to add it just for this.

-Andi

Re: [PATCH] x86_64: check if Tom2 is enabled

[Cyrill Gorcunov]

[Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100]
| 
| > is it possible to change 'l' and 'h' to 'low' and 'high'?
| > 'cause 'l' does look like '1' (one) number...
| 
| It would be fine for me for someone to implement safe_rdtscll() and get rid
| of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder
| to read and error prone over the ll 64bit variants.
| 
| But I didn't want to add it just for this.
| 
| -Andi
| 

clear enough, thanks

		- Cyrill -

Re: [PATCH] x86_64: check if Tom2 is enabled

[H. Peter Anvin]

Cyrill Gorcunov wrote:
> [Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100]
> | 
> | > is it possible to change 'l' and 'h' to 'low' and 'high'?
> | > 'cause 'l' does look like '1' (one) number...
> | 
> | It would be fine for me for someone to implement safe_rdtscll() and get rid
> | of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder
> | to read and error prone over the ll 64bit variants.
> | 
> | But I didn't want to add it just for this.
> | 
> 
> clear enough, thanks
> 

Actually, I think it depends on the specific MSR - some use the halves 
for different data, whereas others treat it as a large 64-bit object.

Ironically enough, the way the MSR interfaces were carried into the 
64-bit world makes the situation worse on 64 bits; edx:eax is the common 
way to represent a 64-bit value on 32 bits.

	-hpa

Re: [PATCH] x86_64: check if Tom2 is enabled

[Andi Kleen]

> 
> Actually, I think it depends on the specific MSR - some use the halves 
> for different data, whereas others treat it as a large 64-bit object.

Even if there are different fields in there it is still much cleaner
and simpler if there is only a single number to manipulate.

> Ironically enough, the way the MSR interfaces were carried into the 
> 64-bit world makes the situation worse on 64 bits; edx:eax is the common 
> way to represent a 64-bit value on 32 bits.

It's merely an implementation detail of the instruction. But even on 32bit
there is about zero reason to expose that to C code. rdmsr/wrmsr et.al. should
have been defined as 64bit only interface in Linux from day zero.

-Andi

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Justin Piszcz]

On Mon, 21 Jan 2008, Jesse Barnes wrote:

> On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
>> [PATCH] x86_32: trim memory by updating e820 v2
>>
>> when mtrr is not covering all e820 table, need to trim the ram, need to
>> update e820
>>
>> reuse some code for x86_64
>>
>> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
>>
>> compiled test only, need someone test it
>
> I like this approach too.  So as long as the E820 modification method works
> (i.e. we have some testers, maybe Justin can give it a try), you can add
>
> Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>
>
> or
>
> Acked-by:  Jesse Barnes <jesse.barnes@intel.com>
>
> as appropriate too.
>
> Thanks,
> Jesse
>

Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2
                          ^^

I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me 
know and I can test, thanks.

Justin.

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Yinghai Lu]

On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
> 
> On Mon, 21 Jan 2008, Jesse Barnes wrote:
> 
> > On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote:
> >> [PATCH] x86_32: trim memory by updating e820 v2
> >>
> >> when mtrr is not covering all e820 table, need to trim the ram, need to
> >> update e820
> >>
> >> reuse some code for x86_64
> >>
> >> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
> >>
> >> compiled test only, need someone test it
> >
> > I like this approach too.  So as long as the E820 modification method works
> > (i.e. we have some testers, maybe Justin can give it a try), you can add
> >
> > Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>
> >
> > or
> >
> > Acked-by:  Jesse Barnes <jesse.barnes@intel.com>
> >
> > as appropriate too.
> >
> > Thanks,
> > Jesse
> >
> 
> Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2
>                           ^^
> 
> I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me 
> know and I can test, thanks.

please get x86.git

  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  cd linux-2.6
  #--------------{ x86.git instructions }---------->
  # Add Linus's tree as a remote
  git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

  # Add Ingo's tree as a remote
  git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

  # With that setup, just run the following to get any changes you
  # don't have.  It will also notice any new branches Ingo/Linus
  # add to their repo.  Look in .git/config afterwards, the format
  # to add new remotes is easy to figure out.
  git remote update
  #-------------------------
  git merge x86/master
  git merge x86/mm

and apply

[PATCH] x86_64: check if Tom2 is enabled
http://lkml.org/lkml/2008/1/21/20
[PATCH] x86_64: update e820 instead of updating end_pfn v3
http://lkml.org/lkml/2008/1/21/19
[PATCH] x86_32: trim memory by updating e820 v2
http://lkml.org/lkml/2008/1/21/18

YH

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Justin Piszcz]

On Mon, 21 Jan 2008, Yinghai Lu wrote:

> On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
> please get x86.git
>
>  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>  cd linux-2.6
>  #--------------{ x86.git instructions }---------->
>  # Add Linus's tree as a remote
>  git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
>  # Add Ingo's tree as a remote
>  git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
>  # With that setup, just run the following to get any changes you
>  # don't have.  It will also notice any new branches Ingo/Linus
>  # add to their repo.  Look in .git/config afterwards, the format
>  # to add new remotes is easy to figure out.
>  git remote update
>  #-------------------------
>  git merge x86/master
>  git merge x86/mm
>
> and apply
>
> [PATCH] x86_64: check if Tom2 is enabled
> http://lkml.org/lkml/2008/1/21/20
> [PATCH] x86_64: update e820 instead of updating end_pfn v3
> http://lkml.org/lkml/2008/1/21/19
> [PATCH] x86_32: trim memory by updating e820 v2
> http://lkml.org/lkml/2008/1/21/18
>
> YH
>

Thanks, I am all patched up and ready to test, unfortunately one of my disks
in my RAID 1 just died, I already filled out the advanced replacement form,
I will test when I receive the replacement disk.

p34:~# lilo
Fatal: Not all RAID-1 disks are active; use '-H' to install to active disks only
p34:~# lilo -H
Warning: Partial RAID-1 install on active disks only; booting is not failsafe

Warning: Faulty disk in RAID-1 array; boot with caution!!
Fatal: Unusual RAID bios device code: 0xFF
p34:~#

Don't feel like mucking up my system at the moment.

Justin.

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 7763 bytes --]


* Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:

> [PATCH] x86_32: trim memory by updating e820 v2
> 
> when mtrr is not covering all e820 table, need to trim the ram, need 
> to update e820
> 
> reuse some code for x86_64
> 
> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init 
> early
> 
> compiled test only, need someone test it

i picked up the patch below, and it crashes with:

  Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
  Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
  ------------[ cut here ]------------
  kernel BUG at arch/x86/mm/pageattr_32.c:327!
  invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC

  Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15)
  EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0
  EIP is at kernel_map_pages+0x52/0xb3

config and bootlog attached as well.

	Ingo

------------------>
Subject: x86_32: trim memory by updating e820
From: Yinghai Lu <Yinghai.Lu@Sun.COM>

when mtrr is not covering all e820 table, need to trim the ram, need to
update e820

reuse some code for x86_64

here need to add early_identify_cpu for x86_32, and move mtrr_bp_init
early

compiled test only, need someone test it

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/kernel-parameters.txt |    2 +-
 arch/x86/kernel/cpu/common.c        |   12 ++++++++----
 arch/x86/kernel/cpu/mtrr/main.c     |    2 --
 arch/x86/kernel/e820_32.c           |   11 +++++++++++
 arch/x86/kernel/setup_32.c          |    7 +++++++
 arch/x86/kernel/setup_64.c          |    4 +---
 include/asm-x86/e820_32.h           |    3 +++
 include/asm-x86/processor.h         |    1 +
 8 files changed, 32 insertions(+), 10 deletions(-)

Index: linux-x86.q/Documentation/kernel-parameters.txt
===================================================================
--- linux-x86.q.orig/Documentation/kernel-parameters.txt
+++ linux-x86.q/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. 
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
-	disable_mtrr_trim [X86-64, Intel only]
+	disable_mtrr_trim [X86, Intel and AMD only]
 			By default the kernel will trim any uncacheable
 			memory out of your available memory pool based on
 			MTRR settings.  This parameter disables that behavior,
Index: linux-x86.q/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/cpu/common.c
+++ linux-x86.q/arch/x86/kernel/cpu/common.c
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 {
-	int i;
 
-	c->loops_per_jiffy = loops_per_jiffy;
 	c->x86_cache_size = -1;
 	c->x86_vendor = X86_VENDOR_UNKNOWN;
 	c->cpuid_level = -1;	/* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin
 
 	if (this_cpu->c_identify)
 		this_cpu->c_identify(c);
+}
 
+void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+{
+	int i;
+
+	c->loops_per_jiffy = loops_per_jiffy;
+	early_identify_cpu(c);
 	/*
 	 * Vendor-specific initialization.  In this section we
 	 * canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)
 	identify_cpu(&boot_cpu_data);
 	sysenter_setup();
 	enable_sep_cpu();
-	mtrr_bp_init();
 }
 
 void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-x86.q/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-x86.q/arch/x86/kernel/cpu/mtrr/main.c
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
-#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns
 
 	return 0;
 }
-#endif
 
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-x86.q/arch/x86/kernel/e820_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/e820_32.c
+++ linux-x86.q/arch/x86/kernel/e820_32.c
@@ -749,3 +749,14 @@ static int __init parse_memmap(char *arg
 	return 0;
 }
 early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+	u8 nr_map;
+
+	nr_map = e820.nr_map;
+	if (sanitize_e820_map(e820.map, &nr_map))
+		return;
+	e820.nr_map = nr_map;
+	printk(KERN_INFO "modified physical RAM map:\n");
+	print_memory_map("modified");
+}
Index: linux-x86.q/arch/x86/kernel/setup_32.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/setup_32.c
+++ linux-x86.q/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@
 
 #include <video/edid.h>
 
+#include <asm/mtrr.h>
 #include <asm/apic.h>
 #include <asm/e820.h>
 #include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p)
 	bss_resource.start = virt_to_phys(&__bss_start);
 	bss_resource.end = virt_to_phys(&__bss_stop)-1;
 
+	early_identify_cpu(&boot_cpu_data);
 	parse_early_param();
 
 	if (user_defined_memmap) {
@@ -762,6 +764,11 @@ void __init setup_arch(char **cmdline_p)
 
 	max_low_pfn = setup_memory();
 
+	/* update e820 for memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	if (mtrr_trim_uncached_memory(max_pfn))
+		max_low_pfn = setup_memory();
+
 #ifdef CONFIG_VMI
 	/*
 	 * Must be after max_low_pfn is determined, and before kernel
Index: linux-x86.q/arch/x86/kernel/setup_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/setup_64.c
+++ linux-x86.q/arch/x86/kernel/setup_64.c
@@ -157,8 +157,6 @@ static struct resource bss_resource = {
 	.flags = IORESOURCE_RAM,
 };
 
-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c);
-
 #ifdef CONFIG_PROC_VMCORE
 /* elfcorehdr= specifies the location of elf core header
  * stored by the crashed kernel. This option will be passed
@@ -890,7 +888,7 @@ struct cpu_model_info {
 /* Do some early cpuid on the boot CPU to get some parameter that are
    needed before check_bugs. Everything advanced is in identify_cpu
    below. */
-static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
+void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c)
 {
 	u32 tfms, xlvl;
 
Index: linux-x86.q/include/asm-x86/e820_32.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/e820_32.h
+++ linux-x86.q/include/asm-x86/e820_32.h
@@ -19,12 +19,15 @@
 #ifndef __ASSEMBLY__
 
 extern struct e820map e820;
+extern void update_e820(void);
 
 extern int e820_all_mapped(unsigned long start, unsigned long end,
 			   unsigned type);
 extern int e820_any_mapped(u64 start, u64 end, unsigned type);
 extern void find_max_pfn(void);
 extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+			      unsigned long long size, int type);
 extern void e820_register_memory(void);
 extern void limit_regions(unsigned long long size);
 extern void print_memory_map(char *who);
Index: linux-x86.q/include/asm-x86/processor.h
===================================================================
--- linux-x86.q.orig/include/asm-x86/processor.h
+++ linux-x86.q/include/asm-x86/processor.h
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_
 
 void cpu_detect(struct cpuinfo_x86 *c);
 
+extern void early_identify_cpu(struct cpuinfo_x86 *);
 extern void identify_cpu(struct cpuinfo_x86 *);
 extern void identify_boot_cpu(void);
 extern void identify_secondary_cpu(struct cpuinfo_x86 *);

[-- Attachment #2: config --]
[-- Type: text/plain, Size: 44668 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc8
# Tue Jan 22 17:33:45 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
# CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set
CONFIG_ARCH_SUPPORTS_OPROFILE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
CONFIG_USER_NS=y
CONFIG_PID_NS=y
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
# CONFIG_CPUSETS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
# CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set
# CONFIG_PARAVIRT_GUEST is not set
CONFIG_M386=y
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
# CONFIG_X86_CMPXCHG is not set
CONFIG_X86_L1_CACHE_SHIFT=4
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_F00F_BUG=y
CONFIG_X86_MINIMUM_CPU_FAMILY=3
# CONFIG_HPET_TIMER is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
# CONFIG_SCHED_MC is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
CONFIG_TOSHIBA=y
CONFIG_I8K=y
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_X86_PAE is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_SUSPEND_SMP_POSSIBLE=y
# CONFIG_SUSPEND is not set
CONFIG_HIBERNATION_SMP_POSSIBLE=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
CONFIG_ACPI_SBS=y

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
CONFIG_MCA=y
CONFIG_MCA_LEGACY=y
# CONFIG_MCA_PROC_FS is not set
CONFIG_SCx200=y
# CONFIG_SCx200HR_TIMER is not set
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_PCMCIA is not set
CONFIG_CARDBUS=y

#
# PC-card bridges
#
# CONFIG_YENTA is not set
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
CONFIG_HOTPLUG_PCI_COMPAQ=y
CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=y
# CONFIG_HOTPLUG_PCI_CPCI is not set
CONFIG_HOTPLUG_PCI_SHPC=y

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
CONFIG_NET_IPGRE=y
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_IPV6_MIP6=y
CONFIG_INET6_XFRM_TUNNEL=y
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
# CONFIG_INET6_XFRM_MODE_BEET is not set
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y
# CONFIG_IPV6_SIT is not set
CONFIG_IPV6_TUNNEL=y
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_NETLABEL=y
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
CONFIG_NETFILTER_DEBUG=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NF_CONNTRACK_ENABLED is not set
# CONFIG_NF_CONNTRACK is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ESP=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
CONFIG_NETFILTER_XT_MATCH_MARK=y
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
CONFIG_NETFILTER_XT_MATCH_QUOTA=y
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=y
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set

#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not set
CONFIG_IP_NF_ARPTABLES=y
# CONFIG_IP_NF_ARPFILTER is not set
CONFIG_IP_NF_ARP_MANGLE=y

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
# CONFIG_IP6_NF_IPTABLES is not set

#
# DECnet: Netfilter Configuration
#
# CONFIG_DECNET_NF_GRABULATOR is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=y
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
CONFIG_SCTP_HMAC_SHA1=y
# CONFIG_SCTP_HMAC_MD5 is not set
CONFIG_TIPC=y
# CONFIG_TIPC_ADVANCED is not set
# CONFIG_TIPC_DEBUG is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
CONFIG_DECNET=y
# CONFIG_DECNET_ROUTER is not set
CONFIG_LLC=y
CONFIG_LLC2=y
# CONFIG_IPX is not set
CONFIG_ATALK=y
CONFIG_DEV_APPLETALK=y
CONFIG_IPDDP=y
# CONFIG_IPDDP_ENCAP is not set
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
CONFIG_LAPB=y
CONFIG_ECONET=y
# CONFIG_ECONET_AUNUDP is not set
# CONFIG_ECONET_NATIVE is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not set
CONFIG_IRDA=y

#
# IrDA protocols
#
# CONFIG_IRLAN is not set
# CONFIG_IRCOMM is not set
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
# CONFIG_IRDA_FAST_RR is not set
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=y

#
# Dongle support
#
CONFIG_DONGLE=y
# CONFIG_ESI_DONGLE is not set
# CONFIG_ACTISYS_DONGLE is not set
# CONFIG_TEKRAM_DONGLE is not set
# CONFIG_TOIM3232_DONGLE is not set
# CONFIG_LITELINK_DONGLE is not set
CONFIG_MA600_DONGLE=y
CONFIG_GIRBIL_DONGLE=y
# CONFIG_MCP2120_DONGLE is not set
# CONFIG_OLD_BELKIN_DONGLE is not set
# CONFIG_ACT200L_DONGLE is not set
CONFIG_KINGSUN_DONGLE=y
# CONFIG_KSDAZZLE_DONGLE is not set
CONFIG_KS959_DONGLE=y

#
# Old SIR device drivers
#

#
# Old Serial dongle support
#

#
# FIR device drivers
#
CONFIG_USB_IRDA=y
CONFIG_SIGMATEL_FIR=y
# CONFIG_NSC_FIR is not set
CONFIG_WINBOND_FIR=y
CONFIG_TOSHIBA_FIR=y
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
CONFIG_VLSI_FIR=y
# CONFIG_VIA_FIR is not set
CONFIG_MCS_FIR=y
CONFIG_BT=y
# CONFIG_BT_L2CAP is not set
# CONFIG_BT_SCO is not set

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=y
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_LL is not set
# CONFIG_BT_HCIBCM203X is not set
CONFIG_BT_HCIBPA10X=y
CONFIG_BT_HCIBFUSB=y
CONFIG_BT_HCIVHCI=y
CONFIG_AF_RXRPC=y
CONFIG_AF_RXRPC_DEBUG=y
CONFIG_RXKAD=y
CONFIG_FIB_RULES=y

#
# Wireless
#
# CONFIG_CFG80211 is not set
CONFIG_WIRELESS_EXT=y
# CONFIG_MAC80211 is not set
CONFIG_IEEE80211=y
CONFIG_IEEE80211_DEBUG=y
CONFIG_IEEE80211_CRYPT_WEP=y
CONFIG_IEEE80211_CRYPT_CCMP=y
# CONFIG_IEEE80211_CRYPT_TKIP is not set
# CONFIG_IEEE80211_SOFTMAC is not set
CONFIG_RFKILL=y
# CONFIG_RFKILL_INPUT is not set
CONFIG_NET_9P=y
# CONFIG_NET_9P_FD is not set
# CONFIG_NET_9P_DEBUG is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_DEBUG_DRIVER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_CPQ_DA=y
# CONFIG_BLK_CPQ_CISS_DA is not set
CONFIG_BLK_DEV_DAC960=y
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_CHR_DEV_OSST=y
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_CHR_DEV_SCH=y

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_SAS_ATA is not set
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=y
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
CONFIG_SATA_QSTOR=y
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
CONFIG_SATA_SIL=y
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
CONFIG_SATA_ULI=y
# CONFIG_SATA_VIA is not set
CONFIG_SATA_VITESSE=y
CONFIG_SATA_INIC162X=y
# CONFIG_PATA_ACPI is not set
CONFIG_PATA_ALI=y
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
CONFIG_PATA_CS5520=y
# CONFIG_PATA_CS5530 is not set
CONFIG_PATA_CS5535=y
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
CONFIG_PATA_EFAR=y
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
CONFIG_PATA_HPT37X=y
# CONFIG_PATA_HPT3X2N is not set
CONFIG_PATA_HPT3X3=y
CONFIG_PATA_HPT3X3_DMA=y
# CONFIG_PATA_IT821X is not set
CONFIG_PATA_IT8213=y
CONFIG_PATA_JMICRON=y
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_MARVELL=y
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
# CONFIG_PATA_NETCELL is not set
CONFIG_PATA_NS87410=y
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OPTI=y
CONFIG_PATA_OPTIDMA=y
CONFIG_PATA_PDC_OLD=y
CONFIG_PATA_RADISYS=y
# CONFIG_PATA_RZ1000 is not set
CONFIG_PATA_SC1200=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_PDC2027X=y
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
CONFIG_PATA_VIA=y
# CONFIG_PATA_WINBOND is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
CONFIG_DM_MULTIPATH=y
# CONFIG_DM_MULTIPATH_EMC is not set
# CONFIG_DM_MULTIPATH_RDAC is not set
# CONFIG_DM_MULTIPATH_HP is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=y
CONFIG_FIREWIRE_OHCI=y
CONFIG_FIREWIRE_SBP2=y
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
CONFIG_BONDING=y
CONFIG_MACVLAN=y
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
CONFIG_VETH=y
CONFIG_NET_SB1000=y
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=y
CONFIG_DAVICOM_PHY=y
# CONFIG_QSEMI_PHY is not set
CONFIG_LXT_PHY=y
CONFIG_CICADA_PHY=y
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_HAPPYMEAL=y
# CONFIG_SUNGEM is not set
CONFIG_CASSINI=y
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_NET_VENDOR_SMC=y
CONFIG_ULTRAMCA=y
CONFIG_NET_TULIP=y
CONFIG_DE2104X=y
CONFIG_TULIP=y
CONFIG_TULIP_MWI=y
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not set
CONFIG_WINBOND_840=y
CONFIG_DM9102=y
# CONFIG_ULI526X is not set
CONFIG_PCMCIA_XIRCOM=y
# CONFIG_AT1700 is not set
CONFIG_DEPCA=y
# CONFIG_HP100 is not set
# CONFIG_NE2_MCA is not set
CONFIG_IBMLANA=y
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
CONFIG_PCNET32_NAPI=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
CONFIG_FORCEDETH=y
CONFIG_FORCEDETH_NAPI=y
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
CONFIG_FEALNX=y
# CONFIG_NATSEMI is not set
CONFIG_NE2K_PCI=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
CONFIG_8139_OLD_RX_RESET=y
# CONFIG_SIS900 is not set
CONFIG_EPIC100=y
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
CONFIG_VIA_RHINE=y
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
CONFIG_NETDEV_1000=y
CONFIG_ACENIC=y
# CONFIG_ACENIC_OMIT_TIGON_I is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_E1000E is not set
CONFIG_IP1000=y
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=y
# CONFIG_R8169_NAPI is not set
CONFIG_SIS190=y
# CONFIG_SKGE is not set
CONFIG_SKY2=y
CONFIG_SKY2_DEBUG=y
CONFIG_SK98LIN=y
CONFIG_VIA_VELOCITY=y
CONFIG_TIGON3=y
CONFIG_BNX2=y
CONFIG_QLA3XXX=y
CONFIG_ATL1=y
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
CONFIG_IXGBE=y
CONFIG_IXGB=y
CONFIG_IXGB_NAPI=y
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
CONFIG_NETXEN_NIC=y
CONFIG_NIU=y
# CONFIG_MLX4_CORE is not set
CONFIG_TEHUTI=y
# CONFIG_TR is not set

#
# Wireless LAN
#
CONFIG_WLAN_PRE80211=y
# CONFIG_STRIP is not set
CONFIG_WLAN_80211=y
CONFIG_IPW2100=y
CONFIG_IPW2100_MONITOR=y
CONFIG_IPW2100_DEBUG=y
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
CONFIG_AIRO=y
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
CONFIG_PRISM54=y
CONFIG_USB_ZD1201=y
# CONFIG_HOSTAP is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=y
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
CONFIG_USB_RTL8150=y
CONFIG_USB_USBNET=y
# CONFIG_USB_NET_AX8817X is not set
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
CONFIG_USB_NET_ZAURUS=y
CONFIG_WAN=y
# CONFIG_LANMEDIA is not set
CONFIG_HDLC=y
# CONFIG_HDLC_RAW is not set
CONFIG_HDLC_RAW_ETH=y
# CONFIG_HDLC_CISCO is not set
CONFIG_HDLC_FR=y
# CONFIG_HDLC_PPP is not set
CONFIG_HDLC_X25=y
# CONFIG_PCI200SYN is not set
CONFIG_WANXL=y
CONFIG_PC300=y

#
# Cyclades-PC300 MLPPP support is disabled.
#

#
# Refer to the file README.mlppp, provided by PC300 package.
#
CONFIG_PC300TOO=y
# CONFIG_FARSYNC is not set
# CONFIG_DLCI is not set
CONFIG_SBNI=y
# CONFIG_SBNI_MULTILINE is not set
CONFIG_FDDI=y
CONFIG_DEFXX=y
CONFIG_DEFXX_MMIO=y
# CONFIG_SKFP is not set
CONFIG_HIPPI=y
# CONFIG_ROADRUNNER is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
CONFIG_SHAPER=y
CONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_ISDN=y
# CONFIG_ISDN_I4L is not set
CONFIG_ISDN_CAPI=y
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
# CONFIG_CAPI_TRACE is not set
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=y
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=y

#
# CAPI hardware drivers
#
CONFIG_CAPI_AVM=y
# CONFIG_ISDN_DRV_AVMB1_B1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_B1PCMCIA is not set
# CONFIG_ISDN_DRV_AVMB1_T1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_C4 is not set
# CONFIG_CAPI_EICON is not set
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_XTKBD=y
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_STOWAWAY=y
CONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
CONFIG_TABLET_USB_AIPTEK=y
CONFIG_TABLET_USB_GTCO=y
CONFIG_TABLET_USB_KBTAB=y
# CONFIG_TABLET_USB_WACOM is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_FUJITSU=y
CONFIG_TOUCHSCREEN_GUNZE=y
CONFIG_TOUCHSCREEN_ELO=y
CONFIG_TOUCHSCREEN_MTOUCH=y
# CONFIG_TOUCHSCREEN_MK712 is not set
CONFIG_TOUCHSCREEN_PENMOUNT=y
CONFIG_TOUCHSCREEN_TOUCHRIGHT=y
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
CONFIG_TOUCHSCREEN_UCB1400=y
CONFIG_TOUCHSCREEN_USB_COMPOSITE=y
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
CONFIG_TOUCHSCREEN_USB_3M=y
CONFIG_TOUCHSCREEN_USB_ITM=y
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
CONFIG_TOUCHSCREEN_USB_GOTOP=y
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
CONFIG_INPUT_WISTRON_BTNS=y
CONFIG_INPUT_ATLAS_BTNS=y
CONFIG_INPUT_ATI_REMOTE=y
# CONFIG_INPUT_ATI_REMOTE2 is not set
CONFIG_INPUT_KEYSPAN_REMOTE=y
# CONFIG_INPUT_POWERMATE is not set
CONFIG_INPUT_YEALINK=y
CONFIG_INPUT_UINPUT=y

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
CONFIG_SERIO_PARKBD=y
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_MCA is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_PRINTER is not set
CONFIG_PPDEV=y
CONFIG_IPMI_HANDLER=y
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_PANIC_STRING=y
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_SI is not set
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not set
CONFIG_HW_RANDOM_AMD=y
# CONFIG_HW_RANDOM_GEODE is not set
CONFIG_HW_RANDOM_VIA=y
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=y
CONFIG_MWAVE=y
# CONFIG_SCx200_GPIO is not set
CONFIG_PC8736x_GPIO=y
CONFIG_NSC_GPIO=y
CONFIG_CS5535_GPIO=y
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=y
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=y
CONFIG_I2C_AMD756=y
# CONFIG_I2C_AMD756_S4882 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_I810 is not set
CONFIG_I2C_PIIX4=y
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
CONFIG_I2C_PARPORT_LIGHT=y
CONFIG_I2C_PROSAVAGE=y
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
CONFIG_I2C_SIS96X=y
CONFIG_I2C_TAOS_EVM=y
# CONFIG_I2C_TINY_USB is not set
CONFIG_I2C_VIA=y
# CONFIG_I2C_VIAPRO is not set
CONFIG_I2C_VOODOO3=y

#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=y
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
CONFIG_SENSORS_PCF8574=y
# CONFIG_SENSORS_PCA9539 is not set
CONFIG_SENSORS_PCF8591=y
CONFIG_SENSORS_MAX6875=y
# CONFIG_SENSORS_TSL2550 is not set
CONFIG_I2C_DEBUG_CORE=y
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_I2C_DEBUG_CHIP=y

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
CONFIG_ACQUIRE_WDT=y
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
CONFIG_ALIM7101_WDT=y
CONFIG_SC520_WDT=y
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_IBMASR=y
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not set
CONFIG_PC87413_WDT=y
CONFIG_60XX_WDT=y
# CONFIG_SBC8360_WDT is not set
CONFIG_SBC7240_WDT=y
CONFIG_CPU5_WDT=y
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=y
CONFIG_W83697HF_WDT=y
CONFIG_W83877F_WDT=y
CONFIG_W83977F_WDT=y
# CONFIG_MACHZ_WDT is not set
CONFIG_SBC_EPX_C3_WATCHDOG=y

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=y
CONFIG_WDTPCI=y
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
CONFIG_SSB=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
# CONFIG_SSB_PCIHOST is not set
CONFIG_SSB_DEBUG=y

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set

#
# Graphics support
#
# CONFIG_AGP is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=y
CONFIG_DRM_RADEON=y
CONFIG_DRM_MGA=y
# CONFIG_DRM_VIA is not set
CONFIG_DRM_SAVAGE=y
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
# CONFIG_USB_HID is not set

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=y
CONFIG_USB_MOUSE=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_ISP116X_HCD=y
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_U132_HCD=y
CONFIG_USB_SL811_HCD=y
CONFIG_USB_R8A66597_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
CONFIG_USB_STORAGE_USBAT=y
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_KARMA=y
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=y
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=y

#
# USB port drivers
#
CONFIG_USB_USS720=y

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_SERIAL_GENERIC is not set
CONFIG_USB_SERIAL_AIRCABLE=y
# CONFIG_USB_SERIAL_AIRPRIME is not set
CONFIG_USB_SERIAL_ARK3116=y
# CONFIG_USB_SERIAL_BELKIN is not set
CONFIG_USB_SERIAL_CH341=y
# CONFIG_USB_SERIAL_WHITEHEAT is not set
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y
CONFIG_USB_SERIAL_CP2101=y
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
CONFIG_USB_SERIAL_EMPEG=y
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
CONFIG_USB_SERIAL_EDGEPORT=y
CONFIG_USB_SERIAL_EDGEPORT_TI=y
# CONFIG_USB_SERIAL_GARMIN is not set
CONFIG_USB_SERIAL_IPW=y
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
CONFIG_USB_SERIAL_KEYSPAN=y
# CONFIG_USB_SERIAL_KEYSPAN_MPR is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
# CONFIG_USB_SERIAL_KLSI is not set
CONFIG_USB_SERIAL_KOBIL_SCT=y
CONFIG_USB_SERIAL_MCT_U232=y
# CONFIG_USB_SERIAL_MOS7720 is not set
CONFIG_USB_SERIAL_MOS7840=y
# CONFIG_USB_SERIAL_NAVMAN is not set
CONFIG_USB_SERIAL_PL2303=y
# CONFIG_USB_SERIAL_OTI6858 is not set
CONFIG_USB_SERIAL_HP4X=y
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
CONFIG_USB_SERIAL_TI=y
CONFIG_USB_SERIAL_CYBERJACK=y
# CONFIG_USB_SERIAL_XIRCOM is not set
CONFIG_USB_SERIAL_OPTION=y
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG is not set
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=y
# CONFIG_USB_EMI26 is not set
CONFIG_USB_ADUTUX=y
CONFIG_USB_AUERSWALD=y
CONFIG_USB_RIO500=y
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=y
CONFIG_USB_CYPRESS_CY7C63=y
CONFIG_USB_CYTHERM=y
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
CONFIG_USB_FTDI_ELAN=y
CONFIG_USB_APPLEDISPLAY=y
CONFIG_USB_SISUSBVGA=y
# CONFIG_USB_SISUSBVGA_CON is not set
# CONFIG_USB_LD is not set
CONFIG_USB_TRANCEVIBRATOR=y
CONFIG_USB_IOWARRIOR=y
CONFIG_USB_TEST=y

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
CONFIG_INFINIBAND=y
# CONFIG_INFINIBAND_USER_MAD is not set
# CONFIG_INFINIBAND_USER_ACCESS is not set
CONFIG_INFINIBAND_ADDR_TRANS=y
# CONFIG_INFINIBAND_MTHCA is not set
CONFIG_INFINIBAND_AMSO1100=y
# CONFIG_INFINIBAND_AMSO1100_DEBUG is not set
# CONFIG_MLX4_INFINIBAND is not set
CONFIG_INFINIBAND_IPOIB=y
CONFIG_INFINIBAND_IPOIB_CM=y
CONFIG_INFINIBAND_IPOIB_DEBUG=y
# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
# CONFIG_INFINIBAND_SRP is not set
CONFIG_INFINIBAND_ISER=y
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not set
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_TEST=y

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
CONFIG_RTC_DRV_DS1672=y
CONFIG_RTC_DRV_MAX6900=y
CONFIG_RTC_DRV_RS5C372=y
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
CONFIG_RTC_DRV_PCF8583=y
CONFIG_RTC_DRV_M41T80=y
# CONFIG_RTC_DRV_M41T80_WDT is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1553=y
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_DS1742 is not set
CONFIG_RTC_DRV_M48T86=y
CONFIG_RTC_DRV_M48T59=y
CONFIG_RTC_DRV_V3020=y

#
# on-CPU RTC drivers
#
CONFIG_DMADEVICES=y

#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not set
CONFIG_AUXDISPLAY=y
# CONFIG_VIRTUALIZATION is not set

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y

#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
CONFIG_JFS_FS=y
# CONFIG_JFS_POSIX_ACL is not set
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
CONFIG_GFS2_FS=y
CONFIG_GFS2_FS_LOCKING_NOLOCK=y
CONFIG_GFS2_FS_LOCKING_DLM=y
# CONFIG_OCFS2_FS is not set
CONFIG_MINIX_FS=y
CONFIG_ROMFS_FS=y
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=y
CONFIG_GENERIC_ACL=y

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y

#
# Miscellaneous filesystems
#
CONFIG_ADFS_FS=y
# CONFIG_ADFS_FS_RW is not set
CONFIG_AFFS_FS=y
CONFIG_ECRYPT_FS=y
CONFIG_HFS_FS=y
CONFIG_HFSPLUS_FS=y
# CONFIG_BEFS_FS is not set
CONFIG_BFS_FS=y
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_HPFS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
CONFIG_UFS_FS=y
CONFIG_UFS_FS_WRITE=y
CONFIG_UFS_DEBUG=y
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_SUNRPC_XPRT_RDMA=y
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
CONFIG_RPCSEC_GSS_SPKM3=y
# CONFIG_SMB_FS is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_EXPERIMENTAL=y
# CONFIG_CIFS_UPCALL is not set
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=y
# CONFIG_CODA_FS_OLD_API is not set
CONFIG_AFS_FS=y
# CONFIG_AFS_DEBUG is not set
# CONFIG_9P_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
CONFIG_ACORN_PARTITION=y
# CONFIG_ACORN_PARTITION_CUMANA is not set
# CONFIG_ACORN_PARTITION_EESOX is not set
CONFIG_ACORN_PARTITION_ICS=y
# CONFIG_ACORN_PARTITION_ADFS is not set
# CONFIG_ACORN_PARTITION_POWERTEC is not set
CONFIG_ACORN_PARTITION_RISCIX=y
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
# CONFIG_SOLARIS_X86_PARTITION is not set
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
CONFIG_ULTRIX_PARTITION=y
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=y
CONFIG_NLS_CODEPAGE_857=y
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
CONFIG_NLS_CODEPAGE_864=y
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=y
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_3=y
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=y
CONFIG_NLS_ISO8859_9=y
# CONFIG_NLS_ISO8859_13 is not set
CONFIG_NLS_ISO8859_14=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
CONFIG_DLM=y
# CONFIG_DLM_DEBUG is not set
CONFIG_INSTRUMENTATION=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_MARKERS=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not set
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
CONFIG_SLUB_DEBUG_ON=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_FORCED_INLINING is not set
CONFIG_BOOT_PRINTK_DELAY=y
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_SAMPLES is not set
# CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set
# CONFIG_UNWIND_INFO is not set
# CONFIG_KGDB is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_PAGEALLOC=y
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
CONFIG_CPA_DEBUG=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not set
CONFIG_SECURITY_CAPABILITIES=y
CONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not set
CONFIG_CRYPTO_XTS=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_FCRYPT=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_586=y
CONFIG_CRYPTO_CAST5=y
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_ANUBIS=y
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_AUTHENC is not set
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=y
# CONFIG_CRYPTO_DEV_PADLOCK_AES is not set
CONFIG_CRYPTO_DEV_PADLOCK_SHA=y
# CONFIG_CRYPTO_DEV_GEODE is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y

[-- Attachment #3: crash.log --]
[-- Type: text/plain, Size: 9968 bytes --]

Linux version 2.6.24-rc8 (mingo@dione) (gcc version 4.2.2) #15 SMP Tue Jan 22 17:43:21 CET 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
console [earlyser0] enabled
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at [c00f5680] 000f5680
Entering add_active_range(0, 0, 229376) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   229376
On node 0 totalpages: 229376
  DMA zone: 52 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4044 pages, LIFO batch:0
  Normal zone: 2860 pages used for memmap
  Normal zone: 222420 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000F76F0, 0014 (r0 Nvidia)
ACPI: RSDT 3FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 3FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 3FFF3180, 6264 (r1 NVIDIA AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 3FFF0000, 0040
ACPI: SRAT 3FFF9500, 00A0 (r1 AMD    HAMMER          1 AMD         1)
ACPI: MCFG 3FFF9600, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: APIC 3FFF9440, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 15:3 APIC version 17
Processor #1 15:3 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 226464
Kernel command line: root=/dev/sda1 console=ttyS0,115200 console=tty earlyprintk=serial,ttyS0,115200 3 profile=0 debug initcall_debug enforcing=0 apic=verbose sysrq_always_enabled ignore_loglevel selinux=0 nosmp highres=0 nolapic idle=mwait nopat
kernel profiling enabled (shift: 0)
debug: sysrq always enabled.
debug: ignoring loglevel setting.
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 2160.224 MHz processor.
spurious 8259A interrupt: IRQ7.
Console: colour VGA+ 80x25
console handover: boot [earlyser0] -> real [tty0]
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 992 kB
 per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:failed|failed|  ok  |failed|failed|failed|
                 A-B-B-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-B-C-C-A deadlock:failed|failed|  ok  |failed|failed|failed|
             A-B-C-A-B-C deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-B-C-C-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-D-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
         A-B-C-D-B-C-D-A deadlock:failed|failed|  ok  |failed|failed|failed|
                    double unlock:  ok  |  ok  |failed|  ok  |failed|failed|
                  initialize held:failed|failed|failed|failed|failed|failed|
                 bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |failed|
           recursive read-lock #2:             |  ok  |             |failed|
            mixed read-write-lock:             |failed|             |failed|
            mixed write-read-lock:             |failed|             |failed|
  --------------------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/12:failed|failed|  ok  |
     hard-irqs-on + irq-safe-A/21:failed|failed|  ok  |
     soft-irqs-on + irq-safe-A/21:failed|failed|  ok  |
       sirq-safe-A => hirqs-on/12:failed|failed|  ok  |
       sirq-safe-A => hirqs-on/21:failed|failed|  ok  |
         hard-safe-A + irqs-on/12:failed|failed|  ok  |
         soft-safe-A + irqs-on/12:failed|failed|  ok  |
         hard-safe-A + irqs-on/21:failed|failed|  ok  |
         soft-safe-A + irqs-on/21:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/123:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/123:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/132:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/132:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/213:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/213:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/231:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/231:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/312:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/312:failed|failed|  ok  |
    hard-safe-A + unsafe-B #1/321:failed|failed|  ok  |
    soft-safe-A + unsafe-B #1/321:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/123:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/123:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/132:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/132:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/213:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/213:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/231:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/231:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/312:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/312:failed|failed|  ok  |
    hard-safe-A + unsafe-B #2/321:failed|failed|  ok  |
    soft-safe-A + unsafe-B #2/321:failed|failed|  ok  |
      hard-irq lock-inversion/123:failed|failed|  ok  |
      soft-irq lock-inversion/123:failed|failed|  ok  |
      hard-irq lock-inversion/132:failed|failed|  ok  |
      soft-irq lock-inversion/132:failed|failed|  ok  |
      hard-irq lock-inversion/213:failed|failed|  ok  |
      soft-irq lock-inversion/213:failed|failed|  ok  |
      hard-irq lock-inversion/231:failed|failed|  ok  |
      soft-irq lock-inversion/231:failed|failed|  ok  |
      hard-irq lock-inversion/312:failed|failed|  ok  |
      soft-irq lock-inversion/312:failed|failed|  ok  |
      hard-irq lock-inversion/321:failed|failed|  ok  |
      soft-irq lock-inversion/321:failed|failed|  ok  |
      hard-irq read-recursion/123:  ok  |
      soft-irq read-recursion/123:  ok  |
      hard-irq read-recursion/132:  ok  |
      soft-irq read-recursion/132:  ok  |
      hard-irq read-recursion/213:  ok  |
      soft-irq read-recursion/213:  ok  |
      hard-irq read-recursion/231:  ok  |
      soft-irq read-recursion/231:  ok  |
      hard-irq read-recursion/312:  ok  |
      soft-irq read-recursion/312:  ok  |
      hard-irq read-recursion/321:  ok  |
      soft-irq read-recursion/321:  ok  |
--------------------------------------------------------
142 out of 218 testcases failed, as expected. |
----------------------------------------------------
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
------------[ cut here ]------------
kernel BUG at arch/x86/mm/pageattr_32.c:327!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC

Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15)
EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0
EIP is at kernel_map_pages+0x52/0xb3
EAX: c0a6fc00 EBX: c0003000 ECX: c0a6fc00 EDX: c0a6fc00
ESI: c100109c EDI: 00000000 EBP: c0a19f34 ESP: c0a19f1c
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0a18000 task=c0902390 task.ti=c0a18000)
Stack: 00000000 00000001 00000002 c100109c 00000000 ffffffff c0a19f50 c014a77e 
       00000000 c090ba10 c100109c 00000000 00000003 c0a19f58 c014a844 c0a19f60 
       c014adea c0a19f70 c0a2f8b6 fffffff8 c100109c c0a19fa4 c0a2e2f5 00000005 
Call Trace:
 [<c014a77e>] ? free_hot_cold_page+0xb5/0x13c
 [<c014a844>] ? free_hot_page+0xa/0xc
 [<c014adea>] ? __free_pages+0x1b/0x26
 [<c0a2f8b6>] ? __free_pages_bootmem+0x54/0x58
 [<c0a2e2f5>] ? free_all_bootmem_core+0xde/0x154
 [<c0a2e378>] ? free_all_bootmem+0xd/0xf
 [<c0a2b2d1>] ? mem_init+0x26/0x21e
 [<c0a21862>] ? start_kernel+0x273/0x2f9
 =======================
Code: 00 c0 85 c9 74 04 31 ff eb 73 8b 55 ec c1 e2 0c 89 d8 e8 67 51 02 00 eb ed 8d 55 f0 89 d8 e8 e9 fa ff ff 89 c2 83 7d f0 03 74 04 <0f> 0b eb fe 83 7d e8 00 74 24 89 f0 2b 05 24 11 c4 c0 c1 f8 02 
EIP: [<c0116a3f>] kernel_map_pages+0x52/0xb3 SS:ESP 0068:c0a19f1c
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill the idle task!

[PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

[PATCH] x86_32: trim memory by updating e820 v3

when mtrr is not covering all e820 table, need to trim the ram, need to update e820

reuse some code for x86_64

here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early

need Justine to test with his special system with bug bios.

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

Index: linux-2.6/arch/x86/kernel/cpu/common.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/common.c
+++ linux-2.6/arch/x86/kernel/cpu/common.c
@@ -278,6 +278,33 @@ void __init cpu_detect(struct cpuinfo_x8
 			c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
 	}
 }
+static void __cpuinit early_get_cap(struct cpuinfo_x86 *c)
+{
+	u32 tfms, xlvl;
+	int ebx;
+
+	memset(&c->x86_capability, 0, sizeof c->x86_capability);
+	if (have_cpuid_p()) {
+		/* Intel-defined flags: level 0x00000001 */
+		if (c->cpuid_level >= 0x00000001) {
+			u32 capability, excap;
+			cpuid(0x00000001, &tfms, &ebx, &excap, &capability);
+			c->x86_capability[0] = capability;
+			c->x86_capability[4] = excap;
+		}
+
+		/* AMD-defined flags: level 0x80000001 */
+		xlvl = cpuid_eax(0x80000000);
+		if ((xlvl & 0xffff0000) == 0x80000000) {
+			if (xlvl >= 0x80000001) {
+				c->x86_capability[1] = cpuid_edx(0x80000001);
+				c->x86_capability[6] = cpuid_ecx(0x80000001);
+			}
+		}
+
+	}
+
+}
 
 /* Do minimum CPU detection early.
    Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment.
@@ -306,6 +333,8 @@ static void __init early_cpu_detect(void
 		early_init_intel(c);
 		break;
 	}
+
+	early_get_cap(c);
 }
 
 static void __cpuinit generic_identify(struct cpuinfo_x86 * c)
@@ -485,7 +514,6 @@ void __init identify_boot_cpu(void)
 	identify_cpu(&boot_cpu_data);
 	sysenter_setup();
 	enable_sep_cpu();
-	mtrr_bp_init();
 }
 
 void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
Index: linux-2.6/arch/x86/kernel/setup_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup_32.c
+++ linux-2.6/arch/x86/kernel/setup_32.c
@@ -49,6 +49,7 @@
 
 #include <video/edid.h>
 
+#include <asm/mtrr.h>
 #include <asm/apic.h>
 #include <asm/e820.h>
 #include <asm/mpspec.h>
@@ -762,6 +763,11 @@ void __init setup_arch(char **cmdline_p)
 
 	max_low_pfn = setup_memory();
 
+	/* update e820 for memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	if (mtrr_trim_uncached_memory(max_pfn))
+		max_low_pfn = setup_memory();
+
 #ifdef CONFIG_VMI
 	/*
 	 * Must be after max_low_pfn is determined, and before kernel
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
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
-#ifdef CONFIG_X86_64
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns
 
 	return 0;
 }
-#endif
 
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. 
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
-	disable_mtrr_trim [X86-64, Intel only]
+	disable_mtrr_trim [X86, Intel and AMD only]
 			By default the kernel will trim any uncacheable
 			memory out of your available memory pool based on
 			MTRR settings.  This parameter disables that behavior,
Index: linux-2.6/arch/x86/kernel/e820_32.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/e820_32.c
+++ linux-2.6/arch/x86/kernel/e820_32.c
@@ -749,3 +749,14 @@ static int __init parse_memmap(char *arg
 	return 0;
 }
 early_param("memmap", parse_memmap);
+void __init update_e820(void)
+{
+	u8 nr_map;
+
+	nr_map = e820.nr_map;
+	if (sanitize_e820_map(e820.map, &nr_map))
+		return;
+	e820.nr_map = nr_map;
+	printk(KERN_INFO "modified physical RAM map:\n");
+	print_memory_map("modified");
+}
Index: linux-2.6/include/asm-x86/e820_32.h
===================================================================
--- linux-2.6.orig/include/asm-x86/e820_32.h
+++ linux-2.6/include/asm-x86/e820_32.h
@@ -19,12 +19,15 @@
 #ifndef __ASSEMBLY__
 
 extern struct e820map e820;
+extern void update_e820(void);
 
 extern int e820_all_mapped(unsigned long start, unsigned long end,
 			   unsigned type);
 extern int e820_any_mapped(u64 start, u64 end, unsigned type);
 extern void find_max_pfn(void);
 extern void register_bootmem_low_pages(unsigned long max_low_pfn);
+extern void add_memory_region(unsigned long long start,
+			      unsigned long long size, int type);
 extern void e820_register_memory(void);
 extern void limit_regions(unsigned long long size);
 extern void print_memory_map(char *who);

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Yinghai Lu]

On Monday 21 January 2008 01:37:09 pm Justin Piszcz wrote:
> 
> On Mon, 21 Jan 2008, Yinghai Lu wrote:
> 
> > On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
> > please get x86.git
> >
> >  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >  cd linux-2.6
> >  #--------------{ x86.git instructions }---------->
> >  # Add Linus's tree as a remote
> >  git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >
> >  # Add Ingo's tree as a remote
> >  git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> >
> >  # With that setup, just run the following to get any changes you
> >  # don't have.  It will also notice any new branches Ingo/Linus
> >  # add to their repo.  Look in .git/config afterwards, the format
> >  # to add new remotes is easy to figure out.
> >  git remote update
> >  #-------------------------
> >  git merge x86/master
> >  git merge x86/mm
> >
> > and apply
> >
> > [PATCH] x86_64: check if Tom2 is enabled
> > http://lkml.org/lkml/2008/1/21/20
> > [PATCH] x86_64: update e820 instead of updating end_pfn v3
> > http://lkml.org/lkml/2008/1/21/19
> > [PATCH] x86_32: trim memory by updating e820 v2
> > http://lkml.org/lkml/2008/1/21/18
> >
> > YH
> >
> 
> Thanks, I am all patched up and ready to test, unfortunately one of my disks
> in my RAID 1 just died, I already filled out the advanced replacement form,
> I will test when I receive the replacement disk.

please get x86.git and apply
[PATCH] x86_32: trim memory by updating e820 v3
http://lkml.org/lkml/2008/1/22/394

Ingo already put other two into the tree.

Thanks

YH

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Justin Piszcz]

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



On Tue, 22 Jan 2008, Yinghai Lu wrote:

> On Monday 21 January 2008 01:37:09 pm Justin Piszcz wrote:
>>
>> On Mon, 21 Jan 2008, Yinghai Lu wrote:
>>
>>> On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
>>> please get x86.git
>>>
>>>  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>>  cd linux-2.6
>>>  #--------------{ x86.git instructions }---------->
>>>  # Add Linus's tree as a remote
>>>  git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>>
>>>  # Add Ingo's tree as a remote
>>>  git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>>>
>>>  # With that setup, just run the following to get any changes you
>>>  # don't have.  It will also notice any new branches Ingo/Linus
>>>  # add to their repo.  Look in .git/config afterwards, the format
>>>  # to add new remotes is easy to figure out.
>>>  git remote update
>>>  #-------------------------
>>>  git merge x86/master
>>>  git merge x86/mm
>>>
>>> and apply
>>>
>>> [PATCH] x86_64: check if Tom2 is enabled
>>> http://lkml.org/lkml/2008/1/21/20
>>> [PATCH] x86_64: update e820 instead of updating end_pfn v3
>>> http://lkml.org/lkml/2008/1/21/19
>>> [PATCH] x86_32: trim memory by updating e820 v2
>>> http://lkml.org/lkml/2008/1/21/18
>>>
>>> YH
>>>
>>
>> Thanks, I am all patched up and ready to test, unfortunately one of my disks
>> in my RAID 1 just died, I already filled out the advanced replacement form,
>> I will test when I receive the replacement disk.
>
> please get x86.git and apply
> [PATCH] x86_32: trim memory by updating e820 v3
> http://lkml.org/lkml/2008/1/22/394
>
> Ingo already put other two into the tree.
>
> Thanks
>
> YH
>

Tried it, it worked successfully!

With stock kernel, previous way I had to use it was mem=8832M and top 
showed this:

top - 18:53:52 up 1 min,  2 users,  load average: 1.03, 0.30, 0.10
Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.1%us,  2.6%sy,  4.5%ni, 81.3%id,  5.5%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8039464k total,  1288948k used,  6750516k free,     3640k buffers
Swap: 16787768k total,        0k used, 16787768k free,   178528k cached

With kernel you mentioned and use e820 v3:

top - 18:48:13 up 3 min,  6 users,  load average: 1.67, 0.68, 0.25
Tasks: 195 total,   2 running, 193 sleeping,   0 stopped,   0 zombie
Cpu(s): 18.5%us,  1.2%sy,  1.6%ni, 74.8%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8037668k total,  1438732k used,  6598936k free,     6844k buffers
Swap: 16787768k total,        0k used, 16787768k free,   273928k cached

No append mem= required.

A full dmesg is attached so you can analyze the e820/MTRR mapping.

File: dmesg-e820v3patch.txt.bz2

Justin.

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 12040 bytes --]

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Yinghai Lu]

On Jan 25, 2008 4:01 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>
>
...
> Tried it, it worked successfully!
>
> With stock kernel, previous way I had to use it was mem=8832M and top
> showed this:
>
> top - 18:53:52 up 1 min,  2 users,  load average: 1.03, 0.30, 0.10
> Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
> Cpu(s):  6.1%us,  2.6%sy,  4.5%ni, 81.3%id,  5.5%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   8039464k total,  1288948k used,  6750516k free,     3640k buffers
> Swap: 16787768k total,        0k used, 16787768k free,   178528k cached
>
> With kernel you mentioned and use e820 v3:
>
> top - 18:48:13 up 3 min,  6 users,  load average: 1.67, 0.68, 0.25
> Tasks: 195 total,   2 running, 193 sleeping,   0 stopped,   0 zombie
> Cpu(s): 18.5%us,  1.2%sy,  1.6%ni, 74.8%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   8037668k total,  1438732k used,  6598936k free,     6844k buffers
> Swap: 16787768k total,        0k used, 16787768k free,   273928k cached
>
> No append mem= required.
>


thanks

any chance to try 32 bit with higemem64 option?

YH

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Justin Piszcz]

On Fri, 25 Jan 2008, Yinghai Lu wrote:

> On Jan 25, 2008 4:01 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>
>>
> ...
>> Tried it, it worked successfully!
>>
>> With stock kernel, previous way I had to use it was mem=8832M and top
>> showed this:
>>
>> top - 18:53:52 up 1 min,  2 users,  load average: 1.03, 0.30, 0.10
>> Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
>> Cpu(s):  6.1%us,  2.6%sy,  4.5%ni, 81.3%id,  5.5%wa,  0.0%hi,  0.0%si,  0.0%st
>> Mem:   8039464k total,  1288948k used,  6750516k free,     3640k buffers
>> Swap: 16787768k total,        0k used, 16787768k free,   178528k cached
>>
>> With kernel you mentioned and use e820 v3:
>>
>> top - 18:48:13 up 3 min,  6 users,  load average: 1.67, 0.68, 0.25
>> Tasks: 195 total,   2 running, 193 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 18.5%us,  1.2%sy,  1.6%ni, 74.8%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
>> Mem:   8037668k total,  1438732k used,  6598936k free,     6844k buffers
>> Swap: 16787768k total,        0k used, 16787768k free,   273928k cached
>>
>> No append mem= required.
>>
>
>
> thanks
>
> any chance to try 32 bit with higemem64 option?
>
> YH
>

My distribution is setup for 64-bit (64bit-clean) only, I do not have a 
32-bit userland, so cannot help here, sorry.

Justin.

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Ingo Molnar]

* Justin Piszcz <jpiszcz@lucidpixels.com> wrote:

> Tried it, it worked successfully!
>
> With stock kernel, previous way I had to use it was mem=8832M and top 
> showed this:
>
> top - 18:53:52 up 1 min,  2 users,  load average: 1.03, 0.30, 0.10
> Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
> Cpu(s):  6.1%us,  2.6%sy,  4.5%ni, 81.3%id,  5.5%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   8039464k total,  1288948k used,  6750516k free,     3640k buffers
> Swap: 16787768k total,        0k used, 16787768k free,   178528k cached
>
> With kernel you mentioned and use e820 v3:
>
> top - 18:48:13 up 3 min,  6 users,  load average: 1.67, 0.68, 0.25
> Tasks: 195 total,   2 running, 193 sleeping,   0 stopped,   0 zombie
> Cpu(s): 18.5%us,  1.2%sy,  1.6%ni, 74.8%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   8037668k total,  1438732k used,  6598936k free,     6844k buffers
> Swap: 16787768k total,        0k used, 16787768k free,   273928k cached
>
> No append mem= required.
>
> A full dmesg is attached so you can analyze the e820/MTRR mapping.

thanks for testing it! The code indeed successfully trimmed your memory 
map by 64MB:

from:

 [    0.000000]  BIOS-e820: 0000000100000000 - 000000022c000000 (usable)

to:

 [    0.000000]   modified: 0000000100000000 - 0000000228000000 (usable)
 [    0.000000]   modified: 0000000228000000 - 000000022c000000 (reserved)

what happened on your box previously when you booted without any 
trimming - did it sometimes slow down or something like that?

	Ingo

Re: [PATCH] x86_32: trim memory by updating e820 v2

[Justin Piszcz]

On Mon, 28 Jan 2008, Ingo Molnar wrote:

>
> * Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>
>> Tried it, it worked successfully!
>>
>> With stock kernel, previous way I had to use it was mem=8832M and top
>> showed this:
>>
>> top - 18:53:52 up 1 min,  2 users,  load average: 1.03, 0.30, 0.10
>> Tasks: 169 total,   1 running, 168 sleeping,   0 stopped,   0 zombie
>> Cpu(s):  6.1%us,  2.6%sy,  4.5%ni, 81.3%id,  5.5%wa,  0.0%hi,  0.0%si,  0.0%st
>> Mem:   8039464k total,  1288948k used,  6750516k free,     3640k buffers
>> Swap: 16787768k total,        0k used, 16787768k free,   178528k cached
>>
>> With kernel you mentioned and use e820 v3:
>>
>> top - 18:48:13 up 3 min,  6 users,  load average: 1.67, 0.68, 0.25
>> Tasks: 195 total,   2 running, 193 sleeping,   0 stopped,   0 zombie
>> Cpu(s): 18.5%us,  1.2%sy,  1.6%ni, 74.8%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
>> Mem:   8037668k total,  1438732k used,  6598936k free,     6844k buffers
>> Swap: 16787768k total,        0k used, 16787768k free,   273928k cached
>>
>> No append mem= required.
>>
>> A full dmesg is attached so you can analyze the e820/MTRR mapping.
>
> thanks for testing it! The code indeed successfully trimmed your memory
> map by 64MB:
>
> from:
>
> [    0.000000]  BIOS-e820: 0000000100000000 - 000000022c000000 (usable)
>
> to:
>
> [    0.000000]   modified: 0000000100000000 - 0000000228000000 (usable)
> [    0.000000]   modified: 0000000228000000 - 000000022c000000 (reserved)
>
> what happened on your box previously when you booted without any
> trimming - did it sometimes slow down or something like that?
>
> 	Ingo
>

When I boot the box without any trimming it acts like a 286 or 386, takes 
about 10 minutes to boot (using raptor disks).

Justin.

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Andrew Morton]

On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:

> [PATCH] x86_32: trim memory by updating e820 v3
> 
> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
> 
> reuse some code for x86_64
> 
> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
> 
> need Justine to test with his special system with bug bios.
> 
> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>

Speaking of mtrr and e820....

Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?

For some reason we seem to have turned this:

[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
[    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
[    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

into this:

reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1

which screws up the X server's attempt to map the video memory at
0xd0000000.

Thanks.

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Andrew Morton wrote:
> On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> 
>> [PATCH] x86_32: trim memory by updating e820 v3
>>
>> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>>
>> reuse some code for x86_64
>>
>> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>>
>> need Justine to test with his special system with bug bios.
>>
>> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
> 
> Speaking of mtrr and e820....
> 
> Could someone please take a peek at
> http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
> 
> For some reason we seem to have turned this:
> 
> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
> [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
> 
> into this:
> 
> reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
> reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
> reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
> reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
> 
> which screws up the X server's attempt to map the video memory at
> 0xd0000000.

I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.

I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.

Also I get the mtrr type mismatch message on 32 and 64 bit kernels.

...

[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
[    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
[    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
...

cat /proc/mtrr :

reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1


dmesg is saying :

..

[   24.012694] [drm] Initialized i915 1.6.0 20060119 on minor 0
[   24.175500] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
[   24.423740] set status page addr 0x00033000

..

from Xorg log :

...

(WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000)
(II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000

...


Regards,

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>
>  > [PATCH] x86_32: trim memory by updating e820 v3
>  >
>  > when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>  >
>  > reuse some code for x86_64
>  >
>  > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>  >
>  > need Justine to test with his special system with bug bios.
>  >
>  > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>
>  Speaking of mtrr and e820....
>
>  Could someone please take a peek at
>  http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>
>  For some reason we seem to have turned this:
>
>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>  [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>  [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>
>  into this:
>
>  reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>
>  which screws up the X server's attempt to map the video memory at
>  0xd0000000.

can you check if you can set up MTRR mapping in BIOS from Continuous
to Discrete?

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
> Andrew Morton wrote:
>  > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>  >
>  >> [PATCH] x86_32: trim memory by updating e820 v3
>  >>
>  >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>  >>
>  >> reuse some code for x86_64
>  >>
>  >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>  >>
>  >> need Justine to test with his special system with bug bios.
>  >>
>  >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>  >
>  > Speaking of mtrr and e820....
>  >
>  > Could someone please take a peek at
>  > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>  >
>  > For some reason we seem to have turned this:
>  >
>  > [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  > [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>  > [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>  > [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>  > [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>  > [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>  >
>  > into this:
>  >
>  > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>  >
>  > which screws up the X server's attempt to map the video memory at
>  > 0xd0000000.
>
>  I see that on my box with ASUS P5E-VM DO and 4G RAM.
>  It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
>
>  I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
>
>  Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
>
>  ...
>
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>  [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>  ...
>
>  cat /proc/mtrr :
>
>  reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>
>
>  dmesg is saying :
>
>  ..
>
>  [   24.012694] [drm] Initialized i915 1.6.0 20060119 on minor 0
>  [   24.175500] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>  [   24.423740] set status page addr 0x00033000

another continuous MTRR mapping.

several months ago, we were talking about modifying MTRR. but Eric
said that is not safe because acpi and smi...

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>
>  > [PATCH] x86_32: trim memory by updating e820 v3
>  >
>  > when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>  >
>  > reuse some code for x86_64
>  >
>  > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>  >
>  > need Justine to test with his special system with bug bios.
>  >
>  > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>
>  Speaking of mtrr and e820....
>
>  Could someone please take a peek at
>  http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>
>  For some reason we seem to have turned this:
>
>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>  [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>  [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>
>  into this:
>
>  reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>
>  which screws up the X server's attempt to map the video memory at
>  0xd0000000.
>

the BIOS should have set memhole to 2048MB or 2560M instead of 1033MB

good mtrr should

>  reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
>  reg01: base=0x100000000 (4096MB), size=2048MB: write-back, count=1

or

>  reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
>  reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1
>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  reg03: base=0x140000000 (4096MB), size=512MB: write-back, count=1

so please talk to your HW esp CPU vendor to fix the BIOS problem.

AMD Rev F and Quadcore should get

>  reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1

or

>  reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
>  reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1

because [4G, TOM2) is WB by default.

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Yinghai Lu schrieb:
> On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>>  Could someone please take a peek at
>>  http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
> 
> can you check if you can set up MTRR mapping in BIOS from Continuous
> to Discrete?

Unfortunately my BIOS offers no advanced settings at all. The only thing
I can change is the size of the video memory. But changing this has no
effect on the MTRRs.

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Yinghai Lu wrote:
>>  reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>>  reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>  reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>  reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>
>>  which screws up the X server's attempt to map the video memory at
>>  0xd0000000.
> 
> the BIOS should have set memhole to 2048MB or 2560M instead of 1033MB
> 
> good mtrr should
> 
>>  reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
>>  reg01: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
> 
> or
> 
>>  reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
>>  reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1
>>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>  reg03: base=0x140000000 (4096MB), size=512MB: write-back, count=1
> 
> so please talk to your HW esp CPU vendor to fix the BIOS problem.

This is a Core 2 Duo CPU, so my CPU vendor is Intel. I assume that the
relevant people are already reading this, no?

I'm not sure what I'm supposed to do? Write an Email to Intel support,
referencing this thread? Doesn't anyone here already know the right
people at Intel who could actually do something about this. I think that
would be more useful since I doubt an email to Intel support would reach
those people...

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
> Andrew Morton wrote:
>  > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>  >
>  >> [PATCH] x86_32: trim memory by updating e820 v3
>  >>
>  >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>  >>
>  >> reuse some code for x86_64
>  >>
>  >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>  >>
>  >> need Justine to test with his special system with bug bios.
>  >>
>  >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>  >
>  > Speaking of mtrr and e820....
>  >
>  > Could someone please take a peek at
>  > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>  >
>  > For some reason we seem to have turned this:
>  >
>  > [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  > [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>  > [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>  > [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>  > [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  > [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>  > [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>  >
>  > into this:
>  >
>  > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>  >
>  > which screws up the X server's attempt to map the video memory at
>  > 0xd0000000.
>
>  I see that on my box with ASUS P5E-VM DO and 4G RAM.
>  It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
>
>  I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
>
>  Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
>
>  ...
>
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>  [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>  ...
>
>  cat /proc/mtrr :
>
>  reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1

please try the patch at

http://lkml.org/lkml/2008/4/28/52

with mtrr_chunk_size=1g

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>
>  > [PATCH] x86_32: trim memory by updating e820 v3
>  >
>  > when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>  >
>  > reuse some code for x86_64
>  >
>  > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>  >
>  > need Justine to test with his special system with bug bios.
>  >
>  > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>
>  Speaking of mtrr and e820....
>
>  Could someone please take a peek at
>  http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>
>  For some reason we seem to have turned this:
>
>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>  [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>  [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>
>  into this:
>
>  reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>
>  which screws up the X server's attempt to map the video memory at
>  0xd0000000.

please try the patch at

http://lkml.org/lkml/2008/4/28/52

with mtrr_chunk_size=1g, and you should get

you should get
>  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>  reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>  reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1

YH
YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Hi Yinghai,

Yinghai Lu schrieb:
>>  reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>>  reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>  reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>  reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>
>>  which screws up the X server's attempt to map the video memory at
>>  0xd0000000.
> 
> please try the patch at
> 
> http://lkml.org/lkml/2008/4/28/52
> 
> with mtrr_chunk_size=1g, and you should get
> 
> you should get
>>  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
>>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>>  reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>  reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>  reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1

Wow, thanks a lot for this patch! It almost works. This is what I get
with mtrr_chunk_size=1g:
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
reg04: base=0x100001000 (4096MB), size=   4KB: write-back, count=1
reg05: base=0x100002000 (4096MB), size=   8KB: write-back, count=1
reg06: base=0x100004000 (4096MB), size=  16KB: write-back, count=1
reg07: base=0x100008000 (4096MB), size=  32KB: write-back, count=1

And this is what I get without mtrr_chunk_size=1g:
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
reg04: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
reg05: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
reg06: base=0x100001000 (4096MB), size=   4KB: write-back, count=1
reg07: base=0x100002000 (4096MB), size=   8KB: write-back, count=1

I attached these outputs and the dmesgs to the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=10508

dmesg with mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15945

dmesg without mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15946

There are some warnings in the output:
[    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory,
losing 1023MB of RAM.
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at
/home/mika/src/linux-2.6/arch/x86/kernel/cpu/mtrr/main.c:1049
mtrr_trim_uncached_memory+0x118/0x250()
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.25 #5
[    0.000000]  [<c01273af>] warn_on_slowpath+0x5f/0x90
[    0.000000]  [<c03a8f9d>] _spin_unlock_irqrestore+0xd/0x10
[    0.000000]  [<c0127d4a>] release_console_sem+0x1ba/0x1e0
[    0.000000]  [<c01280d8>] vprintk+0x1c8/0x3a0
[    0.000000]  [<c010ebd3>] generic_get_mtrr+0x93/0x100
[    0.000000]  [<c01282cb>] printk+0x1b/0x20
[    0.000000]  [<c05069d8>] mtrr_trim_uncached_memory+0x118/0x250
[    0.000000]  [<c0504292>] setup_arch+0x312/0x590
[    0.000000]  [<c04fd774>] start_kernel+0x64/0x3a0
[    0.000000]  =======================
[    0.000000] ---[ end trace ca143223eefdc828 ]---

Let me know if there's anything else I can do to help!

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 1:38 AM, Mika Fischer <mika.fischer@zoopnet.de> wrote:
> Hi Yinghai,
>
>  Yinghai Lu schrieb:
>
> >>  reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  >>  reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  >>  reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  >>  reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  >>  reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>  >>
>  >>  which screws up the X server's attempt to map the video memory at
>  >>  0xd0000000.
>  >
>  > please try the patch at
>  >
>  > http://lkml.org/lkml/2008/4/28/52
>  >
>  > with mtrr_chunk_size=1g, and you should get
>  >
>  > you should get
>  >>  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
>  >>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>  >>  reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  >>  reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>  >>  reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>
>  Wow, thanks a lot for this patch! It almost works. This is what I get
>  with mtrr_chunk_size=1g:
>
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>  reg02: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
>  reg03: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
>  reg04: base=0x100001000 (4096MB), size=   4KB: write-back, count=1
>  reg05: base=0x100002000 (4096MB), size=   8KB: write-back, count=1
>  reg06: base=0x100004000 (4096MB), size=  16KB: write-back, count=1
>  reg07: base=0x100008000 (4096MB), size=  32KB: write-back, count=1
>
>  And this is what I get without mtrr_chunk_size=1g:
>
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>  reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
>  reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
>  reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
>  reg04: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
>  reg05: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
>  reg06: base=0x100001000 (4096MB), size=   4KB: write-back, count=1
>  reg07: base=0x100002000 (4096MB), size=   8KB: write-back, count=1
>
>  I attached these outputs and the dmesgs to the bug report:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=10508
>
>  dmesg with mtrr_chunk_size=1g:
>  http://bugzilla.kernel.org/attachment.cgi?id=15945
>
>  dmesg without mtrr_chunk_size=1g:
>  http://bugzilla.kernel.org/attachment.cgi?id=15946
>

thanks for testing

please check
http://lkml.org/lkml/2008/4/28/115

also, can you try 64bit too?

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Yinghai Lu wrote:
> On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Andrew Morton wrote:
>>  > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>>  >
>>  >> [PATCH] x86_32: trim memory by updating e820 v3
>>  >>
>>  >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>>  >>
>>  >> reuse some code for x86_64
>>  >>
>>  >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>>  >>
>>  >> need Justine to test with his special system with bug bios.
>>  >>
>>  >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>>  >
>>  > Speaking of mtrr and e820....
>>  >
>>  > Could someone please take a peek at
>>  > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>>  >
>>  > For some reason we seem to have turned this:
>>  >
>>  > [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>>  > [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>>  > [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>>  > [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>>  > [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>  > [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>>  > [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>>  >
>>  > into this:
>>  >
>>  > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>>  > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>>  > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>  > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>  > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>  >
>>  > which screws up the X server's attempt to map the video memory at
>>  > 0xd0000000.
>>
>>  I see that on my box with ASUS P5E-VM DO and 4G RAM.
>>  It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
>>
>>  I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
>>
>>  Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
>>
>>  ...
>>
>>  [    0.000000] BIOS-provided physical RAM map:
>>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>>  [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
>>  [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>
>> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>>  ...
>>
>>  cat /proc/mtrr :
>>
>>  reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>>  reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
> 
> please try the patch at
> 
> http://lkml.org/lkml/2008/4/28/52
> 
> with mtrr_chunk_size=1g

Hi,

With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).

It does without but I get a warning:

...


[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
[    0.000000]  BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
[    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
[    0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used
[    0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used
[    0.000000] max_pfn_mapped = 1228800
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] After WB checking
[    0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000
[    0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000
[    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
[    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
[    0.000000] After UC checking
[    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
[    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
[    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
[    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
[    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
[    0.000000] After sorting
[    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
[    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
[    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
[    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
[    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
[    0.000000] rangeX: 0000000000000000 - 00000000d0000000
[    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
[    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
[    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
[    0.000000] range0: 00000000cf801000 - 00000000cf801000
[    0.000000] range: 00000000cf801000 - 00000000d0000000
[    0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB
[    0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB
[    0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB
[    0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB
[    0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB
[    0.000000] range0: 0000000100001000 - 0000000110001000
[    0.000000] range: 0000000110001000 - 0000000120001000
[    0.000000] hole: 0000000120000000 - 0000000120001000
[    0.000000] DONE variable MTRRs
[    0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
[    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM.
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797
[    0.000000]
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0
[    0.000000]  [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d
[    0.000000]  [<ffffffff80747a08>] setup_arch+0x356/0x599
[    0.000000]  [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9
[    0.000000]  [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270
[    0.000000]
[    0.000000] ---[ end trace ca143223eefdc828 ]---
[    0.000000] update e820 for mtrr
[    0.000000] modified physical RAM map:
[    0.000000]  modified: 0000000000000000 - 000000000009cc00 (usable)
[    0.000000]  modified: 000000000009cc00 - 00000000000a0000 (reserved)
[    0.000000]  modified: 00000000000e4000 - 0000000000100000 (reserved)
[    0.000000]  modified: 0000000000100000 - 00000000cf550000 (usable)
[    0.000000]  modified: 00000000cf550000 - 00000000cf55e000 (ACPI data)
[    0.000000]  modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
[    0.000000]  modified: 00000000cf5e0000 - 00000000cf600000 (reserved)
[    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  modified: 00000000ffc00000 - 000000012c000000 (reserved)
[    0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used
[    0.000000] max_pfn_mapped = 1228800
[    0.000000] init_memory_mapping

...


--($:~)-- cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf801000 (3320MB), size=   4KB: write-back, count=1
reg04: base=0xcf802000 (3320MB), size=   8KB: write-back, count=1
reg05: base=0xcf804000 (3320MB), size=  16KB: write-back, count=1
reg06: base=0xcf808000 (3320MB), size=  32KB: write-back, count=1
reg07: base=0xcf810000 (3320MB), size=  64KB: write-back, count=1

--($:~)-- uname -a
Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux

Full dmesg can be found there :


http://frugalware.org/~crazy/mtrr/mtrr_dmesg


> 
> YH
> 

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 2:18 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
> Yinghai Lu wrote:
>  > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >> Andrew Morton wrote:
>  >>  > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>  >>  >
>  >>  >> [PATCH] x86_32: trim memory by updating e820 v3
>  >>  >>
>  >>  >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>  >>  >>
>  >>  >> reuse some code for x86_64
>  >>  >>
>  >>  >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>  >>  >>
>  >>  >> need Justine to test with his special system with bug bios.
>  >>  >>
>  >>  >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>  >>  >
>  >>  > Speaking of mtrr and e820....
>  >>  >
>  >>  > Could someone please take a peek at
>  >>  > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>  >>  >
>  >>  > For some reason we seem to have turned this:
>  >>  >
>  >>  > [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>  >>  > [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>  >>  > [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>  >>  > [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>  >>  > [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>  >>  >
>  >>  > into this:
>  >>  >
>  >>  > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>  >>  > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>  >>  > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>  >>  > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>  >>  > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>  >>  >
>  >>  > which screws up the X server's attempt to map the video memory at
>  >>  > 0xd0000000.
>  >>
>  >>  I see that on my box with ASUS P5E-VM DO and 4G RAM.
>  >>  It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
>  >>
>  >>  I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
>  >>
>  >>  Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
>  >>
>  >>  ...
>  >>
>  >>  [    0.000000] BIOS-provided physical RAM map:
>  >>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>  >>  [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
>  >>  [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>  >>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>  >>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>  >>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>  >>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>  >>
>  >> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  >>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>  >>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>  >>  ...
>  >>
>  >>  cat /proc/mtrr :
>  >>
>  >>  reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  >>  reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  >
>  > please try the patch at
>  >
>  > http://lkml.org/lkml/2008/4/28/52
>  >
>  > with mtrr_chunk_size=1g
>
>  Hi,
>
>  With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
>
>  It does without but I get a warning:
>
>
>  ...
>
>
>  [    0.000000] BIOS-provided physical RAM map:
>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
>  [    0.000000]  BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
>
> [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>  [    0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used
>  [    0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used
>  [    0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used
>  [    0.000000] max_pfn_mapped = 1228800
>  [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
>  [    0.000000] After WB checking
>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000
>  [    0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000
>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>  [    0.000000] After UC checking
>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>  [    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>  [    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
>  [    0.000000] After sorting
>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>  [    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
>  [    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>  [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>  [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  [    0.000000] range0: 00000000cf801000 - 00000000cf801000
>  [    0.000000] range: 00000000cf801000 - 00000000d0000000
>  [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB
>  [    0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB
>  [    0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB
>  [    0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB
>  [    0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB
>  [    0.000000] range0: 0000000100001000 - 0000000110001000
>  [    0.000000] range: 0000000110001000 - 0000000120001000
>  [    0.000000] hole: 0000000120000000 - 0000000120001000
>  [    0.000000] DONE variable MTRRs
>  [    0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
>  [    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM.
>  [    0.000000] ------------[ cut here ]------------
>  [    0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()
>
> [    0.000000] Modules linked in:
>  [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797
>  [    0.000000]
>  [    0.000000] Call Trace:
>  [    0.000000]  [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0
>  [    0.000000]  [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d
>  [    0.000000]  [<ffffffff80747a08>] setup_arch+0x356/0x599
>  [    0.000000]  [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9
>  [    0.000000]  [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270
>
> [    0.000000]
>  [    0.000000] ---[ end trace ca143223eefdc828 ]---
>  [    0.000000] update e820 for mtrr
>  [    0.000000] modified physical RAM map:
>  [    0.000000]  modified: 0000000000000000 - 000000000009cc00 (usable)
>  [    0.000000]  modified: 000000000009cc00 - 00000000000a0000 (reserved)
>  [    0.000000]  modified: 00000000000e4000 - 0000000000100000 (reserved)
>  [    0.000000]  modified: 0000000000100000 - 00000000cf550000 (usable)
>  [    0.000000]  modified: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>  [    0.000000]  modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>  [    0.000000]  modified: 00000000cf5e0000 - 00000000cf600000 (reserved)
>  [    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
>  [    0.000000]  modified: 00000000ffc00000 - 000000012c000000 (reserved)
>  [    0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used
>  [    0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used
>  [    0.000000] max_pfn_mapped = 1228800
>  [    0.000000] init_memory_mapping
>
>  ...
>
>
>  --($:~)-- cat /proc/mtrr
>
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>  reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
>  reg03: base=0xcf801000 (3320MB), size=   4KB: write-back, count=1
>  reg04: base=0xcf802000 (3320MB), size=   8KB: write-back, count=1
>  reg05: base=0xcf804000 (3320MB), size=  16KB: write-back, count=1
>  reg06: base=0xcf808000 (3320MB), size=  32KB: write-back, count=1
>  reg07: base=0xcf810000 (3320MB), size=  64KB: write-back, count=1
>
>  --($:~)-- uname -a
>  Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux
>
>  Full dmesg can be found there :
>
>
>  http://frugalware.org/~crazy/mtrr/mtrr_dmesg

please try v2 version

http://lkml.org/lkml/2008/4/28/115

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Yinghai Lu schrieb:
>>> you should get
>>>>  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
>>>>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>>>>  reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>>>  reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>>>  reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> please check
> http://lkml.org/lkml/2008/4/28/115

OK, this time it worked!

With mtrr_chunk_size=1g:
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1

Without mtrr_chunk_size=1g:
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
reg04: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
reg05: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1

Both seem equivalent and correct.

There are also no warnings anymore in the dmesg output:
With mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15950

Without mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15951

> also, can you try 64bit too?

I'm not sure how to do this. Can I compile it under 32bit Linux? If not that
will be difficult since I don't have space left for a 64bit installation on my
hard-drive. Maybe Gabiel C can test 64bit?

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Yinghai Lu wrote:
> On Mon, Apr 28, 2008 at 2:18 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Yinghai Lu wrote:
>>  > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>  >> Andrew Morton wrote:
>>  >>  > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>>  >>  >
>>  >>  >> [PATCH] x86_32: trim memory by updating e820 v3
>>  >>  >>
>>  >>  >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>>  >>  >>
>>  >>  >> reuse some code for x86_64
>>  >>  >>
>>  >>  >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>>  >>  >>
>>  >>  >> need Justine to test with his special system with bug bios.
>>  >>  >>
>>  >>  >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>>  >>  >
>>  >>  > Speaking of mtrr and e820....
>>  >>  >
>>  >>  > Could someone please take a peek at
>>  >>  > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>>  >>  >
>>  >>  > For some reason we seem to have turned this:
>>  >>  >
>>  >>  > [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>>  >>  > [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>>  >>  > [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>>  >>  > [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>>  >>  > [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>>  >>  >
>>  >>  > into this:
>>  >>  >
>>  >>  > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>>  >>  > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>>  >>  > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>  >>  > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>  >>  > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>  >>  >
>>  >>  > which screws up the X server's attempt to map the video memory at
>>  >>  > 0xd0000000.
>>  >>
>>  >>  I see that on my box with ASUS P5E-VM DO and 4G RAM.
>>  >>  It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
>>  >>
>>  >>  I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
>>  >>
>>  >>  Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
>>  >>
>>  >>  ...
>>  >>
>>  >>  [    0.000000] BIOS-provided physical RAM map:
>>  >>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>>  >>  [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
>>  >>  [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>>  >>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>>  >>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>  >>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>  >>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>  >>
>>  >> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>  >>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>>  >>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>>  >>  ...
>>  >>
>>  >>  cat /proc/mtrr :
>>  >>
>>  >>  reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>>  >>  reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>>  >
>>  > please try the patch at
>>  >
>>  > http://lkml.org/lkml/2008/4/28/52
>>  >
>>  > with mtrr_chunk_size=1g
>>
>>  Hi,
>>
>>  With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
>>
>>  It does without but I get a warning:
>>
>>
>>  ...
>>
>>
>>  [    0.000000] BIOS-provided physical RAM map:
>>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
>>  [    0.000000]  BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
>>
>> [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>  [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>>  [    0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used
>>  [    0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used
>>  [    0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used
>>  [    0.000000] max_pfn_mapped = 1228800
>>  [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
>>  [    0.000000] After WB checking
>>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000
>>  [    0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000
>>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>>  [    0.000000] After UC checking
>>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>>  [    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
>>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>>  [    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
>>  [    0.000000] After sorting
>>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>>  [    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
>>  [    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
>>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>>  [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>>  [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>  [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>  [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>  [    0.000000] range0: 00000000cf801000 - 00000000cf801000
>>  [    0.000000] range: 00000000cf801000 - 00000000d0000000
>>  [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB
>>  [    0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB
>>  [    0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB
>>  [    0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB
>>  [    0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB
>>  [    0.000000] range0: 0000000100001000 - 0000000110001000
>>  [    0.000000] range: 0000000110001000 - 0000000120001000
>>  [    0.000000] hole: 0000000120000000 - 0000000120001000
>>  [    0.000000] DONE variable MTRRs
>>  [    0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
>>  [    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM.
>>  [    0.000000] ------------[ cut here ]------------
>>  [    0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()
>>
>> [    0.000000] Modules linked in:
>>  [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797
>>  [    0.000000]
>>  [    0.000000] Call Trace:
>>  [    0.000000]  [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0
>>  [    0.000000]  [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d
>>  [    0.000000]  [<ffffffff80747a08>] setup_arch+0x356/0x599
>>  [    0.000000]  [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9
>>  [    0.000000]  [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270
>>
>> [    0.000000]
>>  [    0.000000] ---[ end trace ca143223eefdc828 ]---
>>  [    0.000000] update e820 for mtrr
>>  [    0.000000] modified physical RAM map:
>>  [    0.000000]  modified: 0000000000000000 - 000000000009cc00 (usable)
>>  [    0.000000]  modified: 000000000009cc00 - 00000000000a0000 (reserved)
>>  [    0.000000]  modified: 00000000000e4000 - 0000000000100000 (reserved)
>>  [    0.000000]  modified: 0000000000100000 - 00000000cf550000 (usable)
>>  [    0.000000]  modified: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>  [    0.000000]  modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>  [    0.000000]  modified: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>  [    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
>>  [    0.000000]  modified: 00000000ffc00000 - 000000012c000000 (reserved)
>>  [    0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used
>>  [    0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used
>>  [    0.000000] max_pfn_mapped = 1228800
>>  [    0.000000] init_memory_mapping
>>
>>  ...
>>
>>
>>  --($:~)-- cat /proc/mtrr
>>
>> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>>  reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
>>  reg03: base=0xcf801000 (3320MB), size=   4KB: write-back, count=1
>>  reg04: base=0xcf802000 (3320MB), size=   8KB: write-back, count=1
>>  reg05: base=0xcf804000 (3320MB), size=  16KB: write-back, count=1
>>  reg06: base=0xcf808000 (3320MB), size=  32KB: write-back, count=1
>>  reg07: base=0xcf810000 (3320MB), size=  64KB: write-back, count=1
>>
>>  --($:~)-- uname -a
>>  Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux
>>
>>  Full dmesg can be found there :
>>
>>
>>  http://frugalware.org/~crazy/mtrr/mtrr_dmesg
> 
> please try v2 version
> 
> http://lkml.org/lkml/2008/4/28/115

Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. 
I've quick tested some games and 3d things , all are working with this patch really nice.

Full dmesg :

http://frugalware.org/~crazy/mtrr/mtrr2_dmesg


--($:~)-- cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size=   8MB: write-back, count=1
reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg06: base=0x12c000000 (4800MB), size=  64MB: uncachable, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1


If you wish I can test 32bit too a bit later , just let me know.

> 
> YH
> 


Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Mika Fischer wrote:
> Yinghai Lu schrieb:
>>>> you should get
>>>>>  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
>>>>>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>>>>>  reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>>>>  reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>>>>  reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>> please check
>> http://lkml.org/lkml/2008/4/28/115
> 
> OK, this time it worked!
> 
> With mtrr_chunk_size=1g:
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
> reg02: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
> reg03: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
> reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> 
> Without mtrr_chunk_size=1g:
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
> reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
> reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
> reg04: base=0xbf700000 (3063MB), size=   1MB: uncachable, count=1
> reg05: base=0xbf800000 (3064MB), size=   8MB: uncachable, count=1
> reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
> 
> Both seem equivalent and correct.
> 
> There are also no warnings anymore in the dmesg output:
> With mtrr_chunk_size=1g:
> http://bugzilla.kernel.org/attachment.cgi?id=15950
> 
> Without mtrr_chunk_size=1g:
> http://bugzilla.kernel.org/attachment.cgi?id=15951
> 
>> also, can you try 64bit too?
> 
> I'm not sure how to do this. Can I compile it under 32bit Linux? If not that
> will be difficult since I don't have space left for a 64bit installation on my
> hard-drive. Maybe Gabiel C can test 64bit?

Yes sure, done already :) I could test 32/64 bit on this box if needed.
 
> 
> Regards,
>  Mika

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Gabriel C wrote:
> Yinghai Lu wrote:
>> On Mon, Apr 28, 2008 at 2:18 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>> Yinghai Lu wrote:
>>>  > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>>  >> Andrew Morton wrote:
>>>  >>  > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
>>>  >>  >
>>>  >>  >> [PATCH] x86_32: trim memory by updating e820 v3
>>>  >>  >>
>>>  >>  >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820
>>>  >>  >>
>>>  >>  >> reuse some code for x86_64
>>>  >>  >>
>>>  >>  >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
>>>  >>  >>
>>>  >>  >> need Justine to test with his special system with bug bios.
>>>  >>  >>
>>>  >>  >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
>>>  >>  >
>>>  >>  > Speaking of mtrr and e820....
>>>  >>  >
>>>  >>  > Could someone please take a peek at
>>>  >>  > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
>>>  >>  >
>>>  >>  > For some reason we seem to have turned this:
>>>  >>  >
>>>  >>  > [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
>>>  >>  > [    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
>>>  >>  > [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
>>>  >>  >
>>>  >>  > into this:
>>>  >>  >
>>>  >>  > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
>>>  >>  > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
>>>  >>  > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
>>>  >>  > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
>>>  >>  > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
>>>  >>  >
>>>  >>  > which screws up the X server's attempt to map the video memory at
>>>  >>  > 0xd0000000.
>>>  >>
>>>  >>  I see that on my box with ASUS P5E-VM DO and 4G RAM.
>>>  >>  It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
>>>  >>
>>>  >>  I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
>>>  >>
>>>  >>  Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
>>>  >>
>>>  >>  ...
>>>  >>
>>>  >>  [    0.000000] BIOS-provided physical RAM map:
>>>  >>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
>>>  >>  [    0.000000]  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
>>>  >>  [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>>>  >>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>>>  >>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>>  >>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>>  >>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>>  >>
>>>  >> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>>  >>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>>>  >>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>>>  >>  ...
>>>  >>
>>>  >>  cat /proc/mtrr :
>>>  >>
>>>  >>  reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>>>  >>  reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>>>  >
>>>  > please try the patch at
>>>  >
>>>  > http://lkml.org/lkml/2008/4/28/52
>>>  >
>>>  > with mtrr_chunk_size=1g
>>>
>>>  Hi,
>>>
>>>  With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
>>>
>>>  It does without but I get a warning:
>>>
>>>
>>>  ...
>>>
>>>
>>>  [    0.000000] BIOS-provided physical RAM map:
>>>  [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009cc00 (usable)
>>>  [    0.000000]  BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)
>>>
>>> [    0.000000]  BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
>>>  [    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf550000 (usable)
>>>  [    0.000000]  BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>>  [    0.000000]  BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>>  [    0.000000]  BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>>  [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
>>>  [    0.000000]  BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
>>>  [    0.000000]  BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
>>>  [    0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used
>>>  [    0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used
>>>  [    0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used
>>>  [    0.000000] max_pfn_mapped = 1228800
>>>  [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
>>>  [    0.000000] After WB checking
>>>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000
>>>  [    0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000
>>>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>>>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>>>  [    0.000000] After UC checking
>>>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>>>  [    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
>>>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>>>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>>>  [    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
>>>  [    0.000000] After sorting
>>>  [    0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600
>>>  [    0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000
>>>  [    0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000
>>>  [    0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000
>>>  [    0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000
>>>  [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>>>  [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>>  [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>>  [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>>  [    0.000000] range0: 00000000cf801000 - 00000000cf801000
>>>  [    0.000000] range: 00000000cf801000 - 00000000d0000000
>>>  [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB
>>>  [    0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB
>>>  [    0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB
>>>  [    0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB
>>>  [    0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB
>>>  [    0.000000] range0: 0000000100001000 - 0000000110001000
>>>  [    0.000000] range: 0000000110001000 - 0000000120001000
>>>  [    0.000000] hole: 0000000120000000 - 0000000120001000
>>>  [    0.000000] DONE variable MTRRs
>>>  [    0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
>>>  [    0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM.
>>>  [    0.000000] ------------[ cut here ]------------
>>>  [    0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()
>>>
>>> [    0.000000] Modules linked in:
>>>  [    0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797
>>>  [    0.000000]
>>>  [    0.000000] Call Trace:
>>>  [    0.000000]  [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0
>>>  [    0.000000]  [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d
>>>  [    0.000000]  [<ffffffff80747a08>] setup_arch+0x356/0x599
>>>  [    0.000000]  [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9
>>>  [    0.000000]  [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270
>>>
>>> [    0.000000]
>>>  [    0.000000] ---[ end trace ca143223eefdc828 ]---
>>>  [    0.000000] update e820 for mtrr
>>>  [    0.000000] modified physical RAM map:
>>>  [    0.000000]  modified: 0000000000000000 - 000000000009cc00 (usable)
>>>  [    0.000000]  modified: 000000000009cc00 - 00000000000a0000 (reserved)
>>>  [    0.000000]  modified: 00000000000e4000 - 0000000000100000 (reserved)
>>>  [    0.000000]  modified: 0000000000100000 - 00000000cf550000 (usable)
>>>  [    0.000000]  modified: 00000000cf550000 - 00000000cf55e000 (ACPI data)
>>>  [    0.000000]  modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS)
>>>  [    0.000000]  modified: 00000000cf5e0000 - 00000000cf600000 (reserved)
>>>  [    0.000000]  modified: 00000000fee00000 - 00000000fee01000 (reserved)
>>>  [    0.000000]  modified: 00000000ffc00000 - 000000012c000000 (reserved)
>>>  [    0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used
>>>  [    0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used
>>>  [    0.000000] max_pfn_mapped = 1228800
>>>  [    0.000000] init_memory_mapping
>>>
>>>  ...
>>>
>>>
>>>  --($:~)-- cat /proc/mtrr
>>>
>>> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
>>>  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
>>>  reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
>>>  reg03: base=0xcf801000 (3320MB), size=   4KB: write-back, count=1
>>>  reg04: base=0xcf802000 (3320MB), size=   8KB: write-back, count=1
>>>  reg05: base=0xcf804000 (3320MB), size=  16KB: write-back, count=1
>>>  reg06: base=0xcf808000 (3320MB), size=  32KB: write-back, count=1
>>>  reg07: base=0xcf810000 (3320MB), size=  64KB: write-back, count=1
>>>
>>>  --($:~)-- uname -a
>>>  Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux
>>>
>>>  Full dmesg can be found there :
>>>
>>>
>>>  http://frugalware.org/~crazy/mtrr/mtrr_dmesg
>> please try v2 version
>>
>> http://lkml.org/lkml/2008/4/28/115
> 
> Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. 
> I've quick tested some games and 3d things , all are working with this patch really nice.
> 
> Full dmesg :
> 
> http://frugalware.org/~crazy/mtrr/mtrr2_dmesg
> 
> 
> --($:~)-- cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
> reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
> reg03: base=0xcf800000 (3320MB), size=   8MB: write-back, count=1
> reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
> reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
> reg06: base=0x12c000000 (4800MB), size=  64MB: uncachable, count=1
> reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
> 
> 
> If you wish I can test 32bit too a bit later , just let me know.

BTW I just saw , there is this warning now :


[    0.305539] mtrr: your CPUs had inconsistent variable MTRR settings
[    0.305546] mtrr: probably your BIOS does not setup all CPUs.
[    0.305553] mtrr: corrected configuration.

but everything seems to work fine.

                                                                                                               

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Gabriel C schrieb:
> BTW I just saw , there is this warning now :
> 
> [    0.305539] mtrr: your CPUs had inconsistent variable MTRR settings
> [    0.305546] mtrr: probably your BIOS does not setup all CPUs.
> [    0.305553] mtrr: corrected configuration.
> 
> but everything seems to work fine.

Just, FYI, I got this warning too. I didn't get it before applying the patch.

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Ingo Molnar]

* Gabriel C <nix.or.die@googlemail.com> wrote:

> > please try v2 version
> > 
> > http://lkml.org/lkml/2008/4/28/115
> 
> Box still won't boot with mtrr_chunk_size=1g but without it is perfect 
> :)) Thx for your work. I've quick tested some games and 3d things , 
> all are working with this patch really nice.

excellent. So just to make sure: this box never had proper graphics 
under Linux (under no previous kernel), due to the way the BIOS has set 
up the MTRR's, right?

so fixing up the MTRRs during bootup, no matter how dangerous in theory, 
is pretty much the best option to get your system to work fine under 
Linux, with that specific Xorg version?

i think we should still try to make this a non-default option because 
modern Xorg should not have any need to touch MTRRs. Perhaps a .config 
dependent on CONFIG_DANGEROUS ;-)

	Ingo

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Hi Ingo,

I'm having the same problem.

Ingo Molnar schrieb:
> excellent. So just to make sure: this box never had proper graphics 
> under Linux (under no previous kernel), due to the way the BIOS has set 
> up the MTRR's, right?

Well, not quite. X still works fine, but since the video memory is
overlapped by two of the existing MTRRs, X cannot add a write-combining
range for the video memory. That makes X rather slow especially if you
use DRI for Compiz etc.

And this always happens with 4GB RAM, but not with 2GB RAM.

So yes, with this patch for the first time X works at normal speed with
4GB of RAM out of the box.

> so fixing up the MTRRs during bootup, no matter how dangerous in theory, 
> is pretty much the best option to get your system to work fine under 
> Linux, with that specific Xorg version?

Yes. That's what I'm doing at the moment with a shell script. :)

> i think we should still try to make this a non-default option because 
> modern Xorg should not have any need to touch MTRRs. Perhaps a .config 
> dependent on CONFIG_DANGEROUS ;-)

AFAICT X always tries to set up a write-combining range for the video
memory. And this will always fail if there are erroneous write-back or
even uncachable ranges overlapping the video memory...

But I don't know if this has changed in newer versions of Xorg (I'm
using 7.3).

In any case if I have a range in /proc/mtrr that is declared uncachable
and overlaps my video memory (which is the case without this patch),
is there even anything Xorg can do to make the video-memory use
write-combining?

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Ingo Molnar wrote:
> * Gabriel C <nix.or.die@googlemail.com> wrote:
> 
>>> please try v2 version
>>>
>>> http://lkml.org/lkml/2008/4/28/115
>> Box still won't boot with mtrr_chunk_size=1g but without it is perfect 
>> :)) Thx for your work. I've quick tested some games and 3d things , 
>> all are working with this patch really nice.
> 
> excellent. So just to make sure: this box never had proper graphics 
> under Linux (under no previous kernel), due to the way the BIOS has set 
> up the MTRR's, right?

The box is really new so far I tested 2.6.24* 2.6.25 , linux-next , current git from
which no one worked. And yes is right graphics under Linux didn't worked right without 
patch from http://lkml.org/lkml/2008/4/28/115.

> 
> so fixing up the MTRRs during bootup, no matter how dangerous in theory, 
> is pretty much the best option to get your system to work fine under 
> Linux, with that specific Xorg version?

Yes.

I run :

xorg-server 1.4.0.90-5 ( it has all fixes from server-1.4-branch )
mesa 7.0.2-2
xf86-video-intel 2.3.0-1

Probably I have to replace 2x2G with 2x1G to get it work without this patch but it is something I don't really want to do =)

Also I'm not sure whatever this is an BIOS bug ? I could contact ASUS people if someone tells me what is wrong with the BIOS.

> 
> i think we should still try to make this a non-default option because 
> modern Xorg should not have any need to touch MTRRs. Perhaps a .config 
> dependent on CONFIG_DANGEROUS ;-)

Hmm 1.4.0.90 is not that old , is it ?

> 
> 	Ingo
> 

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Mika Fischer wrote:
> Hi Ingo,
> 
> I'm having the same problem.
> 
> Ingo Molnar schrieb:
>> excellent. So just to make sure: this box never had proper graphics 
>> under Linux (under no previous kernel), due to the way the BIOS has set 
>> up the MTRR's, right?
> 
> Well, not quite. X still works fine, but since the video memory is
> overlapped by two of the existing MTRRs, X cannot add a write-combining
> range for the video memory. That makes X rather slow especially if you
> use DRI for Compiz etc.

Well you are lucky then :) 

Yeah X 'worked' but it worked as slow as with vesa video driver here.

Also starting something like supertuxkart made it crash or I got a black screen :(

The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell.
However I'm not a gamer but I need X to work right.


> Regards,
>  Mika
> 


Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Jesse Barnes]

On Monday, April 28, 2008 6:53 am Ingo Molnar wrote:
> i think we should still try to make this a non-default option because
> modern Xorg should not have any need to touch MTRRs. Perhaps a .config
> dependent on CONFIG_DANGEROUS ;-)

Well, not quite... we're still waiting on some way of getting WC semantics for 
sysfs PCI files.  Suresh tells me something like that is queued up, but until 
that hits the mainline X will still need to bang the MTRRs to get decent 
performance.

Jesse

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Mika Fischer]

Jesse Barnes schrieb:
> On Monday, April 28, 2008 6:53 am Ingo Molnar wrote:
>> i think we should still try to make this a non-default option because
>> modern Xorg should not have any need to touch MTRRs. Perhaps a .config
>> dependent on CONFIG_DANGEROUS ;-)
> 
> Well, not quite... we're still waiting on some way of getting WC semantics for 
> sysfs PCI files.  Suresh tells me something like that is queued up, but until 
> that hits the mainline X will still need to bang the MTRRs to get decent 
> performance.

Do you happen to know if this new sysfs-way will work correctly in the
case where the MTRRs explicitly say that the video-memory is uncachable?

Regards,
 Mika

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Jesse Barnes]

On Monday, April 28, 2008 9:31 am Mika Fischer wrote:
> Jesse Barnes schrieb:
> > On Monday, April 28, 2008 6:53 am Ingo Molnar wrote:
> >> i think we should still try to make this a non-default option because
> >> modern Xorg should not have any need to touch MTRRs. Perhaps a .config
> >> dependent on CONFIG_DANGEROUS ;-)
> >
> > Well, not quite... we're still waiting on some way of getting WC
> > semantics for sysfs PCI files.  Suresh tells me something like that is
> > queued up, but until that hits the mainline X will still need to bang the
> > MTRRs to get decent performance.
>
> Do you happen to know if this new sysfs-way will work correctly in the
> case where the MTRRs explicitly say that the video-memory is uncachable?

It should, since we'll be using PAT to set the cache control in the sysfs 
case.

Jesse

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Eric W. Biederman]

"Yinghai Lu" <yhlu.kernel@gmail.com> writes:

> On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:

> another continuous MTRR mapping.
>
> several months ago, we were talking about modifying MTRR. but Eric
> said that is not safe because acpi and smi...

I think it was Andi who spotted that originally, and yes I do think it
is a pretty horrific failure mode.  Reprogramming the MTRRs requires
full knowledge of the hardware and what is going on that we don't
always have.  PAT support has just been merged, and using that only
requires knowledge about the region whose attributes we intend to change.

So lets concentrate on PAT to solve contiguous MTRR region problems.

We can upgrade UC to WC with pat.  As well as demote WB to UC or WC.
So for those regions we know about we should be in good shape.

In a slightly related vein.  Trimming the memory we consider usable by
looking at MTRRs and if a region is not WB not considering it RAM
sounds like a very reasonable work around for one class of BIOS bugs.

Eric

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 3:07 AM, Mika Fischer <mika.fischer@zoopnet.de> wrote:
> Gabriel C schrieb:
>
> > BTW I just saw , there is this warning now :
>  >
>  > [    0.305539] mtrr: your CPUs had inconsistent variable MTRR settings
>  > [    0.305546] mtrr: probably your BIOS does not setup all CPUs.
>  > [    0.305553] mtrr: corrected configuration.
>  >
>  > but everything seems to work fine.
>
>  Just, FYI, I got this warning too. I didn't get it before applying the patch.

that is normal. because APs will copy the changes of MTRR from BP.
could add some condition for the print out.

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
> Mika Fischer wrote:
>  > Hi Ingo,
>  >
>  > I'm having the same problem.
>  >
>  > Ingo Molnar schrieb:
>  >> excellent. So just to make sure: this box never had proper graphics
>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>  >> up the MTRR's, right?
>  >
>  > Well, not quite. X still works fine, but since the video memory is
>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>  > range for the video memory. That makes X rather slow especially if you
>  > use DRI for Compiz etc.
>
>  Well you are lucky then :)
>
>  Yeah X 'worked' but it worked as slow as with vesa video driver here.

[    0.000000] rangeX: 0000000000000000 - 00000000d0000000
[    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
[    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
[    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
[    0.000000] range0: 00000000cf800000 - 00000000cf800000
[    0.000000] range: 00000000cf800000 - 00000000d0000000
[    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
[    0.000000] range0: 0000000100000000 - 0000000120000000
[    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
[    0.000000] range: 0000000120000000 - 0000000130000000
[    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
[    0.000000] hole: 000000012c000000 - 0000000130000000
[    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC

so your X server need two entries for WB?

can you send out /proc/mtrr with booting with disable_mtrr_cleanup?

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
> Mika Fischer wrote:
>  > Hi Ingo,
>  >
>  > I'm having the same problem.
>  >
>  > Ingo Molnar schrieb:
>  >> excellent. So just to make sure: this box never had proper graphics
>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>  >> up the MTRR's, right?
>  >
>  > Well, not quite. X still works fine, but since the video memory is
>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>  > range for the video memory. That makes X rather slow especially if you
>  > use DRI for Compiz etc.
>
>  Well you are lucky then :)
>
>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>
>  Also starting something like supertuxkart made it crash or I got a black screen :(
>
>  The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell.
>  However I'm not a gamer but I need X to work right.
>
or can you change graphics card memory in BIOS to some big like 256M
instead of 64M?

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Yinghai Lu wrote:
> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Mika Fischer wrote:
>>  > Hi Ingo,
>>  >
>>  > I'm having the same problem.
>>  >
>>  > Ingo Molnar schrieb:
>>  >> excellent. So just to make sure: this box never had proper graphics
>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>>  >> up the MTRR's, right?
>>  >
>>  > Well, not quite. X still works fine, but since the video memory is
>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>>  > range for the video memory. That makes X rather slow especially if you
>>  > use DRI for Compiz etc.
>>
>>  Well you are lucky then :)
>>
>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
> 
> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
> [    0.000000] range: 00000000cf800000 - 00000000d0000000
> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
> [    0.000000] range0: 0000000100000000 - 0000000120000000
> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
> [    0.000000] range: 0000000120000000 - 0000000130000000
> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
> [    0.000000] hole: 000000012c000000 - 0000000130000000
> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
> 
> so your X server need two entries for WB?
> 
> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?

I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.


> 
> YH
> 

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Yinghai Lu wrote:
> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Mika Fischer wrote:
>>  > Hi Ingo,
>>  >
>>  > I'm having the same problem.
>>  >
>>  > Ingo Molnar schrieb:
>>  >> excellent. So just to make sure: this box never had proper graphics
>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>>  >> up the MTRR's, right?
>>  >
>>  > Well, not quite. X still works fine, but since the video memory is
>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>>  > range for the video memory. That makes X rather slow especially if you
>>  > use DRI for Compiz etc.
>>
>>  Well you are lucky then :)
>>
>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>>
>>  Also starting something like supertuxkart made it crash or I got a black screen :(
>>
>>  The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell.
>>  However I'm not a gamer but I need X to work right.
>>
> or can you change graphics card memory in BIOS to some big like 256M
> instead of 64M?
> 

It is set to 256M , I cannot even set it to 64MB in BIOS.
I have options for 128/256 MB only and I think I can change the mode to fixed.

> YH
> 

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Gabriel C wrote:
> Yinghai Lu wrote:
>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>> Mika Fischer wrote:
>>>  > Hi Ingo,
>>>  >
>>>  > I'm having the same problem.
>>>  >
>>>  > Ingo Molnar schrieb:
>>>  >> excellent. So just to make sure: this box never had proper graphics
>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>>>  >> up the MTRR's, right?
>>>  >
>>>  > Well, not quite. X still works fine, but since the video memory is
>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>>>  > range for the video memory. That makes X rather slow especially if you
>>>  > use DRI for Compiz etc.
>>>
>>>  Well you are lucky then :)
>>>
>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>> [    0.000000] range: 0000000120000000 - 0000000130000000
>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>>
>> so your X server need two entries for WB?
>>
>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
> 
> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.

Here the output with v3 which is disabled by default:

--($:~)-- cat /proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1

dmesg is saying now :

[   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining


My card settings in BIOS ( that was default ) are the following :

DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )

Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )

Of course these settings are only possible when the card is not disabled :)

I'm gonna try v4 now and enable it. Please let me know if you need more infos.

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Gabriel C wrote:
> Gabriel C wrote:
>> Yinghai Lu wrote:
>>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>>> Mika Fischer wrote:
>>>>  > Hi Ingo,
>>>>  >
>>>>  > I'm having the same problem.
>>>>  >
>>>>  > Ingo Molnar schrieb:
>>>>  >> excellent. So just to make sure: this box never had proper graphics
>>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>>>>  >> up the MTRR's, right?
>>>>  >
>>>>  > Well, not quite. X still works fine, but since the video memory is
>>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>>>>  > range for the video memory. That makes X rather slow especially if you
>>>>  > use DRI for Compiz etc.
>>>>
>>>>  Well you are lucky then :)
>>>>
>>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>>> [    0.000000] range: 0000000120000000 - 0000000130000000
>>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>>>
>>> so your X server need two entries for WB?
>>>
>>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
>> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
> 
> Here the output with v3 which is disabled by default:
> 
> --($:~)-- cat /proc/mtrr
> reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
> reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
> 
> dmesg is saying now :
> 
> [   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
> 
> 
> My card settings in BIOS ( that was default ) are the following :
> 
> DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
> DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
> 
> Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
> Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
> PEG Port -> Auto ( possible settings Auto , Disabled )
> PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
> 
> Of course these settings are only possible when the card is not disabled :)
> 
> I'm gonna try v4 now and enable it. Please let me know if you need more infos.

Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ).
It takes 6 minutes to boot to :

sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray

after that the box hangs :/

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
> Gabriel C wrote:
>  > Gabriel C wrote:
>  >> Yinghai Lu wrote:
>  >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >>>> Mika Fischer wrote:
>  >>>>  > Hi Ingo,
>  >>>>  >
>  >>>>  > I'm having the same problem.
>  >>>>  >
>  >>>>  > Ingo Molnar schrieb:
>  >>>>  >> excellent. So just to make sure: this box never had proper graphics
>  >>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>  >>>>  >> up the MTRR's, right?
>  >>>>  >
>  >>>>  > Well, not quite. X still works fine, but since the video memory is
>  >>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>  >>>>  > range for the video memory. That makes X rather slow especially if you
>  >>>>  > use DRI for Compiz etc.
>  >>>>
>  >>>>  Well you are lucky then :)
>  >>>>
>  >>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>  >>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  >>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>  >>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>  >>> [    0.000000] range: 0000000120000000 - 0000000130000000
>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>  >>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>  >>>
>  >>> so your X server need two entries for WB?
>  >>>
>  >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
>  >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
>  >
>  > Here the output with v3 which is disabled by default:
>  >
>  > --($:~)-- cat /proc/mtrr
>  > reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  >
>  > dmesg is saying now :
>  >
>  > [   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>  >
>  >
>  > My card settings in BIOS ( that was default ) are the following :
>  >
>  > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
>  > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
>  >
>  > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
>  > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
>  > PEG Port -> Auto ( possible settings Auto , Disabled )
>  > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
>  >
>  > Of course these settings are only possible when the card is not disabled :)
>  >
>  > I'm gonna try v4 now and enable it. Please let me know if you need more infos.
>
>  Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ).
>  It takes 6 minutes to boot to :
>

so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is
another 8M address.

mtrr by BIOS is very interesting:
before
>  > reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
>  > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
>  > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
>  > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
>  > reg05: base=0x128000000 (4736MB), size=  64MB: write-back, count=1


after 256M chunk size got
>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC

so the convering is right..., need to spare another entry for your card.

or we can dumping the
>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
for extra entra...

but the mtrr trimming code need to be updated instead of only using highest_pfn

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Yinghai Lu wrote:
> On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Gabriel C wrote:
>>  > Gabriel C wrote:
>>  >> Yinghai Lu wrote:
>>  >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>  >>>> Mika Fischer wrote:
>>  >>>>  > Hi Ingo,
>>  >>>>  >
>>  >>>>  > I'm having the same problem.
>>  >>>>  >
>>  >>>>  > Ingo Molnar schrieb:
>>  >>>>  >> excellent. So just to make sure: this box never had proper graphics
>>  >>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>>  >>>>  >> up the MTRR's, right?
>>  >>>>  >
>>  >>>>  > Well, not quite. X still works fine, but since the video memory is
>>  >>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>>  >>>>  > range for the video memory. That makes X rather slow especially if you
>>  >>>>  > use DRI for Compiz etc.
>>  >>>>
>>  >>>>  Well you are lucky then :)
>>  >>>>
>>  >>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>>  >>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>  >>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>>  >>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>>  >>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>>  >>> [    0.000000] range: 0000000120000000 - 0000000130000000
>>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>>  >>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>>  >>>
>>  >>> so your X server need two entries for WB?
>>  >>>
>>  >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
>>  >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
>>  >
>>  > Here the output with v3 which is disabled by default:
>>  >
>>  > --($:~)-- cat /proc/mtrr
>>  > reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>>  >
>>  > dmesg is saying now :
>>  >
>>  > [   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>>  >
>>  >
>>  > My card settings in BIOS ( that was default ) are the following :
>>  >
>>  > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
>>  > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
>>  >
>>  > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
>>  > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
>>  > PEG Port -> Auto ( possible settings Auto , Disabled )
>>  > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
>>  >
>>  > Of course these settings are only possible when the card is not disabled :)
>>  >
>>  > I'm gonna try v4 now and enable it. Please let me know if you need more infos.
>>
>>  Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ).
>>  It takes 6 minutes to boot to :
>>
> 
> so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is
> another 8M address.

Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.

I'm not really sure why the 8MB are needed , BIOS book doesn't tell me.
I could try to disable and see what I get =)

> 
> mtrr by BIOS is very interesting:
> before
>>  > reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>>  > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
>>  > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
>>  > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
>>  > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
>>  > reg05: base=0x128000000 (4736MB), size=  64MB: write-back, count=1
> 
> 
> after 256M chunk size got
>>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
> 
> so the convering is right..., need to spare another entry for your card.
> 
> or we can dumping the
>>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
> for extra entra...
> 
> but the mtrr trimming code need to be updated instead of only using highest_pfn
> 
> YH
> 

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Mon, Apr 28, 2008 at 11:07 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>  > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
>
> > another continuous MTRR mapping.
>  >
>  > several months ago, we were talking about modifying MTRR. but Eric
>  > said that is not safe because acpi and smi...
>
>  I think it was Andi who spotted that originally, and yes I do think it
>  is a pretty horrific failure mode.  Reprogramming the MTRRs requires
>  full knowledge of the hardware and what is going on that we don't
>  always have.  PAT support has just been merged, and using that only
>  requires knowledge about the region whose attributes we intend to change.
>
>  So lets concentrate on PAT to solve contiguous MTRR region problems.
>
>  We can upgrade UC to WC with pat.  As well as demote WB to UC or WC.
>  So for those regions we know about we should be in good shape.
>
>  In a slightly related vein.  Trimming the memory we consider usable by
>  looking at MTRRs and if a region is not WB not considering it RAM
>  sounds like a very reasonable work around for one class of BIOS bugs.

yeah, i will look at to loop the ram region array instead of checking
highest_pfn only...


YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 6242 bytes --]

On Mon, Apr 28, 2008 at 3:56 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
> Yinghai Lu wrote:
>  > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >> Gabriel C wrote:
>  >>  > Gabriel C wrote:
>  >>  >> Yinghai Lu wrote:
>  >>  >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >>  >>>> Mika Fischer wrote:
>  >>  >>>>  > Hi Ingo,
>  >>  >>>>  >
>  >>  >>>>  > I'm having the same problem.
>  >>  >>>>  >
>  >>  >>>>  > Ingo Molnar schrieb:
>  >>  >>>>  >> excellent. So just to make sure: this box never had proper graphics
>  >>  >>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>  >>  >>>>  >> up the MTRR's, right?
>  >>  >>>>  >
>  >>  >>>>  > Well, not quite. X still works fine, but since the video memory is
>  >>  >>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>  >>  >>>>  > range for the video memory. That makes X rather slow especially if you
>  >>  >>>>  > use DRI for Compiz etc.
>  >>  >>>>
>  >>  >>>>  Well you are lucky then :)
>  >>  >>>>
>  >>  >>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>  >>  >>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>  >>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  >>  >>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>  >>  >>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>  >>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>  >>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>  >>  >>> [    0.000000] range: 0000000120000000 - 0000000130000000
>  >>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>  >>  >>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>  >>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>  >>  >>>
>  >>  >>> so your X server need two entries for WB?
>  >>  >>>
>  >>  >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
>  >>  >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
>  >>  >
>  >>  > Here the output with v3 which is disabled by default:
>  >>  >
>  >>  > --($:~)-- cat /proc/mtrr
>  >>  > reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  >>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  >>  >
>  >>  > dmesg is saying now :
>  >>  >
>  >>  > [   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>  >>  >
>  >>  >
>  >>  > My card settings in BIOS ( that was default ) are the following :
>  >>  >
>  >>  > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
>  >>  > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
>  >>  >
>  >>  > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
>  >>  > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
>  >>  > PEG Port -> Auto ( possible settings Auto , Disabled )
>  >>  > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
>  >>  >
>  >>  > Of course these settings are only possible when the card is not disabled :)
>  >>  >
>  >>  > I'm gonna try v4 now and enable it. Please let me know if you need more infos.
>  >>
>  >>  Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ).
>  >>  It takes 6 minutes to boot to :
>  >>
>  >
>  > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is
>  > another 8M address.
>
>  Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
>
>  I'm not really sure why the 8MB are needed , BIOS book doesn't tell me.
>  I could try to disable and see what I get =)
>
>
>
>  >
>  > mtrr by BIOS is very interesting:
>  > before
>  >>  > reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>  >>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  >>  > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
>  >>  > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
>  >>  > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
>  >>  > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
>  >>  > reg05: base=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  >
>  >
>  > after 256M chunk size got
>  >>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>  >>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>  >
>  > so the convering is right..., need to spare another entry for your card.
>  >
>  > or we can dumping the
>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  > for extra entra...
>  >
>  > but the mtrr trimming code need to be updated instead of only using highest_pfn
>  >
>  > YH
>  >

please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc.
only for test: i comment out the fill_var_state..

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mtrr_cleanup.patch --]
[-- Type: text/x-patch; name=mtrr_cleanup.patch, Size: 15648 bytes --]

[PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5

some BIOS like to use continus MTRR layout, and may X driver can not add
WB entries for graphical cards when 4g or more RAM installed.

the patch will change MTRR to discrete.

mtrr_chunk_size= could be used to have smaller continuous block to hold holes.
default is 256m, could be set according to size of graphics card memory.

v2: fix -1 for UC checking
v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
    skip the var state change warning.
    remove next_basek in range_to_mtrr()
v4: correct warning mask.
v5: CONFIG_MTRR_SANITIZER

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

Index: linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c
@@ -158,6 +158,20 @@ get_mtrr_var_range(unsigned int index, s
 	rdmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
 }
 
+/*  fill the MSR pair relating to a var range  */
+void fill_mtrr_var_range(unsigned int index,
+		u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi)
+{
+	struct mtrr_var_range *vr;
+
+	vr = mtrr_state.var_ranges;
+
+	vr[index].base_lo = base_lo;
+	vr[index].base_hi = base_hi;
+	vr[index].mask_lo = mask_lo;
+	vr[index].mask_hi = mask_hi;
+}
+
 static void
 get_fixed_ranges(mtrr_type * frs)
 {
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
@@ -37,6 +37,7 @@
 #include <linux/smp.h>
 #include <linux/cpu.h>
 #include <linux/mutex.h>
+#include <linux/sort.h>
 
 #include <asm/e820.h>
 #include <asm/mtrr.h>
@@ -609,6 +610,366 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
+#ifdef CONFIG_MTRR_SANITIZER
+
+#ifdef CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT
+static int enable_mtrr_cleanup __initdata = 1;
+#else
+static int enable_mtrr_cleanup __initdata;
+#endif
+
+#else
+
+static int enable_mtrr_cleanup __initdata = -1;
+
+#endif
+
+static int __init disable_mtrr_cleanup_setup(char *str)
+{
+	if (enable_mtrr_cleanup != -1)
+		enable_mtrr_cleanup = 0;
+	return 0;
+}
+early_param("disable_mtrr_cleanup", disable_mtrr_cleanup_setup);
+
+static int __init enable_mtrr_cleanup_setup(char *str)
+{
+	if (enable_mtrr_cleanup != -1)
+		enable_mtrr_cleanup = 1;
+	return 0;
+}
+early_param("enble_mtrr_cleanup", enable_mtrr_cleanup_setup);
+
+#define RANGE_NUM 256
+
+struct res_range {
+	size_t start;
+	size_t end;
+};
+
+static void __init subtract_range(struct res_range *range, size_t start,
+				size_t end)
+{
+	int i;
+	int j;
+
+	for (j = 0; j < RANGE_NUM; j++) {
+		if (!range[j].end)
+			continue;
+
+		if (start <= range[j].start && end >= range[j].end) {
+			range[j].start = 0;
+			range[j].end = 0;
+			continue;
+		}
+
+		if (start <= range[j].start && end < range[j].end && range[j].start < end + 1) {
+			range[j].start = end + 1;
+			continue;
+		}
+
+
+		if (start > range[j].start && end >= range[j].end && range[j].end > start - 1) {
+			range[j].end = start - 1;
+			continue;
+		}
+
+		if (start > range[j].start && end < range[j].end) {
+			/* find the new spare */
+			for (i = 0; i < RANGE_NUM; i++) {
+				if (range[i].end == 0)
+					break;
+			}
+			if (i < RANGE_NUM) {
+				range[i].end = range[j].end;
+				range[i].start = end + 1;
+			} else {
+				printk(KERN_ERR "run of slot in ranges\n");
+			}
+			range[j].end = start - 1;
+			continue;
+		}
+	}
+}
+
+static int __cpuinit cmp_range(const void *x1, const void *x2)
+{
+	const struct res_range *r1 = x1;
+	const struct res_range *r2 = x2;
+	s64 start1, start2;
+
+	start1 = r1->start;
+	start2 = r2->start;
+
+	return start1 - start2;
+}
+
+struct var_mtrr_state {
+	unsigned long range_startk, range_sizek;
+	unsigned long chunk_sizek;
+	unsigned int reg;
+	unsigned address_bits;
+};
+
+static void __init set_var_mtrr(
+	unsigned int reg, unsigned long basek, unsigned long sizek,
+	unsigned char type, unsigned address_bits)
+{
+	u32 base_lo, base_hi, mask_lo, mask_hi;
+	unsigned address_mask_high;
+
+	if (!sizek) {
+//		fill_mtrr_var_range(reg, 0, 0, 0, 0);
+		return;
+	}
+
+	address_mask_high = ((1u << (address_bits - 32u)) - 1u);
+
+	base_hi = basek >> 22;
+	base_lo  = basek << 10;
+
+	if (sizek < 4*1024*1024) {
+		mask_hi = address_mask_high;
+		mask_lo = ~((sizek << 10) - 1);
+	} else {
+		mask_hi = address_mask_high & (~((sizek >> 22) - 1));
+		mask_lo = 0;
+	}
+
+	base_lo |= type;
+	mask_lo |= 0x800;
+//	fill_mtrr_var_range(reg, base_lo, base_hi, mask_lo, mask_hi);
+}
+
+static unsigned int __init range_to_mtrr(unsigned int reg,
+	unsigned long range_startk, unsigned long range_sizek,
+	unsigned char type, unsigned address_bits)
+{
+	if (!range_sizek || (reg >= num_var_ranges))
+		return reg;
+
+	while (range_sizek) {
+		unsigned long max_align, align;
+		unsigned long sizek;
+		/* Compute the maximum size I can make a range */
+		if (range_startk)
+			max_align = ffs(range_startk) - 1;
+		else
+			max_align = 32;
+		align = fls(range_sizek) - 1;
+		if (align > max_align)
+			align = max_align;
+
+		sizek = 1 << align;
+		printk(KERN_INFO "Setting variable MTRR %d, base: %ldMB, range: %ldMB, type %s\n",
+			reg, range_startk >> 10, sizek >> 10,
+			(type == MTRR_TYPE_UNCACHABLE)?"UC":
+			    ((type == MTRR_TYPE_WRBACK)?"WB":"Other")
+			);
+		set_var_mtrr(reg++, range_startk, sizek, type, address_bits);
+		range_startk += sizek;
+		range_sizek -= sizek;
+		if (reg >= num_var_ranges)
+			break;
+	}
+	return reg;
+}
+
+static void __init range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek)
+{
+	unsigned long hole_basek, hole_sizek;
+	unsigned long range0_basek, range0_sizek;
+	unsigned long range_basek, range_sizek;
+	unsigned long chunk_sizek;
+
+	hole_basek = 0;
+	hole_sizek = 0;
+	chunk_sizek = state->chunk_sizek;
+	range0_basek = state->range_startk;
+
+	/* try to append some small hole */
+	range0_sizek = ALIGN(state->range_sizek, chunk_sizek);
+	if ((range0_sizek == state->range_sizek) ||
+		((range0_basek + range0_sizek > basek) && basek)) {
+			printk(KERN_INFO "rangeX: %016lx - %016lx\n", range0_basek<<10, (range0_basek + range0_sizek)<<10);
+			state->reg = range_to_mtrr(state->reg, range0_basek,
+				range0_sizek, MTRR_TYPE_WRBACK, state->address_bits);
+		return;
+	}
+
+	range0_sizek -= chunk_sizek;
+	range_basek = range0_basek + range0_sizek;
+	printk(KERN_INFO "range0: %016lx - %016lx\n", range0_basek<<10, (range0_basek + range0_sizek)<<10);
+	state->reg = range_to_mtrr(state->reg, range0_basek,
+			range0_sizek, MTRR_TYPE_WRBACK, state->address_bits);
+
+	range_sizek = chunk_sizek;
+	if (range_sizek - (state->range_sizek - range0_sizek) < (chunk_sizek >> 1))
+		hole_sizek = range_sizek - (state->range_sizek - range0_sizek);
+	else
+		range_sizek = state->range_sizek - range0_sizek;
+
+	printk(KERN_INFO "range: %016lx - %016lx\n", range_basek<<10, (range_basek + range_sizek)<<10);
+	state->reg = range_to_mtrr(state->reg, range_basek,
+			range_sizek, MTRR_TYPE_WRBACK, state->address_bits);
+	if (hole_sizek) {
+		printk(KERN_INFO "hole: %016lx - %016lx\n", hole_basek<<10, (hole_basek + hole_sizek)<<10);
+		state->reg = range_to_mtrr(state->reg, hole_basek,
+				hole_sizek, MTRR_TYPE_UNCACHABLE, state->address_bits);
+	}
+}
+
+static void __init set_var_mtrr_range(struct var_mtrr_state *state, size_t base_pfn, size_t size_pfn)
+{
+	unsigned long basek, sizek;
+
+	if (state->reg >= num_var_ranges)
+		return;
+
+	basek = base_pfn << (PAGE_SHIFT - 10);
+	sizek = size_pfn << (PAGE_SHIFT - 10);
+
+	/* See if I can merge with the last range */
+	if ((basek <= 1024) || (state->range_startk + state->range_sizek == basek)) {
+		unsigned long endk = basek + sizek;
+		state->range_sizek = endk - state->range_startk;
+		return;
+	}
+	/* Write the range mtrrs */
+	if (state->range_sizek != 0) {
+		range_to_mtrr_with_hole(state, basek);
+
+		state->range_startk = 0;
+		state->range_sizek = 0;
+	}
+	/* Allocate an msr */
+	state->range_startk = basek;
+	state->range_sizek  = sizek;
+}
+
+static u64 mtrr_chunk_size __initdata = (256ULL<<20);
+
+static int __init parse_mtrr_chunk_size_opt(char *p)
+{
+	if (!p)
+		return -EINVAL;
+	mtrr_chunk_size = memparse(p, &p);
+	return 0;
+}
+early_param("mtrr_chunk_size", parse_mtrr_chunk_size_opt);
+
+static void __init x86_setup_var_mtrrs(struct res_range *range, int nr_range, unsigned address_bits)
+{
+	struct var_mtrr_state var_state;
+	int i;
+
+	var_state.range_startk = 0;
+	var_state.range_sizek = 0;
+	var_state.reg = 0;
+	var_state.address_bits = address_bits;
+	var_state.chunk_sizek = mtrr_chunk_size >> 10;
+
+	/* Write the range etc */
+	for (i = 0; i < nr_range; i++)
+		set_var_mtrr_range(&var_state, range[i].start, range[i].end - range[i].start + 1);
+
+	/* Write the last range */
+	range_to_mtrr_with_hole(&var_state, 0);
+	printk(KERN_INFO "DONE variable MTRRs\n");
+	/* Clear out the extra MTRR's */
+	while (var_state.reg < num_var_ranges)
+		set_var_mtrr(var_state.reg++, 0, 0, 0, var_state.address_bits);
+}
+
+static int __init mtrr_cleanup(unsigned address_bits)
+{
+	unsigned long i, base, size, def, dummy;
+	mtrr_type type;
+	struct res_range range[RANGE_NUM];
+	int nr_range;
+
+	/* extra one for all 0 */
+	int num[MTRR_NUM_TYPES + 1];
+
+	if (!is_cpu(INTEL) || enable_mtrr_cleanup < 1)
+		return 0;
+	rdmsr(MTRRdefType_MSR, def, dummy);
+	def &= 0xff;
+	if (def != MTRR_TYPE_UNCACHABLE)
+		return 0;
+
+	/* check entries number */
+	memset(num, 0, sizeof(num));
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type >= MTRR_NUM_TYPES)
+			continue;
+		if (!size)
+			type = MTRR_NUM_TYPES;
+		num[type]++;
+	}
+
+	/* check if we got UC entries */
+	if (!num[MTRR_TYPE_UNCACHABLE])
+		return 0;
+
+	/* check if we only had WB and UC */
+	if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] !=
+		num_var_ranges - num[MTRR_NUM_TYPES])
+		return 0;
+
+	/*
+	 * get WB ranges at first
+	 * assume BIOS don't give us overlapping WB entries
+	 * or add add_range?
+	 */
+	memset(range, 0, sizeof(range));
+	nr_range = 0;
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type != MTRR_TYPE_WRBACK)
+			continue;
+		range[nr_range].start = base;
+		range[nr_range].end = base + size - 1;
+		nr_range++;
+	}
+	printk(KERN_INFO "After WB checking\n");
+	for (i = 0; i < nr_range; i++)
+		printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1);
+
+	/* take out UC ranges */
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type != MTRR_TYPE_UNCACHABLE)
+			continue;
+		if (!size)
+			continue;
+		subtract_range(range, base, base + size - 1);
+	}
+	/* get new range num */
+	nr_range = 0;
+	for (i = 0; i < RANGE_NUM; i++) {
+		if (!range[i].end)
+			continue;
+		nr_range++;
+	}
+	printk(KERN_INFO "After UC checking\n");
+	for (i = 0; i < nr_range; i++)
+		printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1);
+
+	/* sort the ranges */
+	sort(range, nr_range, sizeof(struct res_range), cmp_range, NULL);
+	printk(KERN_INFO "After sorting\n");
+	for (i = 0; i < nr_range; i++)
+		printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1);
+
+	/* convert ranges to var ranges state */
+	x86_setup_var_mtrrs(range, nr_range, address_bits);
+
+	return 1;
+
+}
+
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -729,18 +1090,21 @@ int __init mtrr_trim_uncached_memory(uns
  */
 void __init mtrr_bp_init(void)
 {
+	u32 phys_addr;
 	init_ifs();
 
+	phys_addr = 32;
+
 	if (cpu_has_mtrr) {
 		mtrr_if = &generic_mtrr_ops;
 		size_or_mask = 0xff000000;	/* 36 bits */
 		size_and_mask = 0x00f00000;
+		phys_addr = 36;
 
 		/* This is an AMD specific MSR, but we assume(hope?) that
 		   Intel will implement it to when they extend the address
 		   bus of the Xeon. */
 		if (cpuid_eax(0x80000000) >= 0x80000008) {
-			u32 phys_addr;
 			phys_addr = cpuid_eax(0x80000008) & 0xff;
 			/* CPUID workaround for Intel 0F33/0F34 CPU */
 			if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
@@ -758,6 +1122,7 @@ void __init mtrr_bp_init(void)
 			   don't support PAE */
 			size_or_mask = 0xfff00000;	/* 32 bits */
 			size_and_mask = 0;
+			phys_addr = 32;
 		}
 	} else {
 		switch (boot_cpu_data.x86_vendor) {
@@ -791,8 +1156,13 @@ void __init mtrr_bp_init(void)
 	if (mtrr_if) {
 		set_num_var_ranges();
 		init_table();
-		if (use_intel())
+		if (use_intel()) {
 			get_mtrr_state();
+
+			if (mtrr_cleanup(phys_addr))
+				mtrr_if->set_all();
+
+		}
 	}
 }
 
@@ -829,9 +1199,10 @@ static int __init mtrr_init_finialize(vo
 {
 	if (!mtrr_if)
 		return 0;
-	if (use_intel())
-		mtrr_state_warn();
-	else {
+	if (use_intel()) {
+		if (enable_mtrr_cleanup < 1)
+			mtrr_state_warn();
+	} else {
 		/* The CPUs haven't MTRR and seem to not support SMP. They have
 		 * specific drivers, we use a tricky method to support
 		 * suspend/resume for them.
Index: linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -81,6 +81,8 @@ void set_mtrr_done(struct set_mtrr_conte
 void set_mtrr_cache_disable(struct set_mtrr_context *ctxt);
 void set_mtrr_prepare_save(struct set_mtrr_context *ctxt);
 
+void fill_mtrr_var_range(unsigned int index,
+		u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi);
 void get_mtrr_state(void);
 
 extern void set_mtrr_ops(struct mtrr_ops * ops);
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -595,6 +595,16 @@ and is between 256 and 4096 characters. 
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
+	disable_mtrr_cleanup [X86]
+	enable_mtrr_cleanup [X86]
+			The kernel tries to adjust MTRR layout from continuous
+			to discrete, to make X server driver able to add WB
+			entry later. This parameter enables/disables that.
+
+	mtrr_chunk_size=nn[KMG] [X86]
+			used for mtrr cleanup. It is largest continous chunk
+			that could hold holes aka. UC entries.
+
 	disable_mtrr_trim [X86, Intel and AMD only]
 			By default the kernel will trim any uncacheable
 			memory out of your available memory pool based on
Index: linux-2.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -1035,6 +1035,32 @@ config MTRR
 
 	  See <file:Documentation/mtrr.txt> for more information.
 
+config MTRR_SANITIZER
+	def_bool y
+	prompt "MTRR cleanup support"
+	depends on MTRR
+	help
+	  Convert MTRR layout from continuous to discrete, so some X driver
+	  could add WB entries.
+
+	  Say N here if you see bootup problems (boot crash, boot hang,
+	  spontaneous reboots).
+
+	  Could be disabled with disable_mtrr_cleanup. Also mtrr_chunk_size
+	  could be used to send largest mtrr entry size for continuous block
+	  to hold holes (aka. UC entries)
+
+	  If unsure, say Y.
+
+config MTRR_SANITIZER_ENABLE_DEFAULT
+	def_bool y
+	prompt "Enable MTRR cleanup by default"
+	depends on MTRR_SANITIZER
+	help
+	  Enable mtrr cleanup by default
+
+	  If unsure, say Y.
+
 config X86_PAT
 	bool
 	prompt "x86 PAT support"

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Gabriel C]

Yinghai Lu wrote:
> On Mon, Apr 28, 2008 at 3:56 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>> Yinghai Lu wrote:
>>  > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>  >> Gabriel C wrote:
>>  >>  > Gabriel C wrote:
>>  >>  >> Yinghai Lu wrote:
>>  >>  >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>>  >>  >>>> Mika Fischer wrote:
>>  >>  >>>>  > Hi Ingo,
>>  >>  >>>>  >
>>  >>  >>>>  > I'm having the same problem.
>>  >>  >>>>  >
>>  >>  >>>>  > Ingo Molnar schrieb:
>>  >>  >>>>  >> excellent. So just to make sure: this box never had proper graphics
>>  >>  >>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>>  >>  >>>>  >> up the MTRR's, right?
>>  >>  >>>>  >
>>  >>  >>>>  > Well, not quite. X still works fine, but since the video memory is
>>  >>  >>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>>  >>  >>>>  > range for the video memory. That makes X rather slow especially if you
>>  >>  >>>>  > use DRI for Compiz etc.
>>  >>  >>>>
>>  >>  >>>>  Well you are lucky then :)
>>  >>  >>>>
>>  >>  >>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>>  >>  >>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>>  >>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>  >>  >>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>>  >>  >>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>>  >>  >>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>>  >>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>>  >>  >>> [    0.000000] range: 0000000120000000 - 0000000130000000
>>  >>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>>  >>  >>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>>  >>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>>  >>  >>>
>>  >>  >>> so your X server need two entries for WB?
>>  >>  >>>
>>  >>  >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
>>  >>  >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
>>  >>  >
>>  >>  > Here the output with v3 which is disabled by default:
>>  >>  >
>>  >>  > --($:~)-- cat /proc/mtrr
>>  >>  > reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>>  >>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>>  >>  >
>>  >>  > dmesg is saying now :
>>  >>  >
>>  >>  > [   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>>  >>  >
>>  >>  >
>>  >>  > My card settings in BIOS ( that was default ) are the following :
>>  >>  >
>>  >>  > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
>>  >>  > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
>>  >>  >
>>  >>  > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
>>  >>  > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
>>  >>  > PEG Port -> Auto ( possible settings Auto , Disabled )
>>  >>  > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
>>  >>  >
>>  >>  > Of course these settings are only possible when the card is not disabled :)
>>  >>  >
>>  >>  > I'm gonna try v4 now and enable it. Please let me know if you need more infos.
>>  >>
>>  >>  Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ).
>>  >>  It takes 6 minutes to boot to :
>>  >>
>>  >
>>  > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is
>>  > another 8M address.
>>
>>  Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
>>
>>  I'm not really sure why the 8MB are needed , BIOS book doesn't tell me.
>>  I could try to disable and see what I get =)
>>
>>
>>
>>  >
>>  > mtrr by BIOS is very interesting:
>>  > before
>>  >>  > reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>>  >>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>>  >>  > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
>>  >>  > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
>>  >>  > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
>>  >>  > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
>>  >>  > reg05: base=0x128000000 (4736MB), size=  64MB: write-back, count=1
>>  >
>>  >
>>  > after 256M chunk size got
>>  >>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>>  >>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>>  >
>>  > so the convering is right..., need to spare another entry for your card.
>>  >
>>  > or we can dumping the
>>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>>  > for extra entra...
>>  >
>>  > but the mtrr trimming code need to be updated instead of only using highest_pfn
>>  >
>>  > YH
>>  >
> 
> please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc.
> only for test: i comment out the fill_var_state..

There are the dmesg's , down to 2m and without chunk_size :

http://frugalware.org/~crazy/mtrr/mtrr/

> 
> YH
> 

Gabriel

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

[-- Attachment #1: Type: text/plain, Size: 7044 bytes --]

On Mon, Apr 28, 2008 at 6:05 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>
> Yinghai Lu wrote:
>  > On Mon, Apr 28, 2008 at 3:56 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >> Yinghai Lu wrote:
>  >>  > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >>  >> Gabriel C wrote:
>  >>  >>  > Gabriel C wrote:
>  >>  >>  >> Yinghai Lu wrote:
>  >>  >>  >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote:
>  >>  >>  >>>> Mika Fischer wrote:
>  >>  >>  >>>>  > Hi Ingo,
>  >>  >>  >>>>  >
>  >>  >>  >>>>  > I'm having the same problem.
>  >>  >>  >>>>  >
>  >>  >>  >>>>  > Ingo Molnar schrieb:
>  >>  >>  >>>>  >> excellent. So just to make sure: this box never had proper graphics
>  >>  >>  >>>>  >> under Linux (under no previous kernel), due to the way the BIOS has set
>  >>  >>  >>>>  >> up the MTRR's, right?
>  >>  >>  >>>>  >
>  >>  >>  >>>>  > Well, not quite. X still works fine, but since the video memory is
>  >>  >>  >>>>  > overlapped by two of the existing MTRRs, X cannot add a write-combining
>  >>  >>  >>>>  > range for the video memory. That makes X rather slow especially if you
>  >>  >>  >>>>  > use DRI for Compiz etc.
>  >>  >>  >>>>
>  >>  >>  >>>>  Well you are lucky then :)
>  >>  >>  >>>>
>  >>  >>  >>>>  Yeah X 'worked' but it worked as slow as with vesa video driver here.
>  >>  >>  >>> [    0.000000] rangeX: 0000000000000000 - 00000000d0000000
>  >>  >>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  >>  >>  >>> [    0.000000] range0: 00000000cf800000 - 00000000cf800000
>  >>  >>  >>> [    0.000000] range: 00000000cf800000 - 00000000d0000000
>  >>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>  >>  >>> [    0.000000] range0: 0000000100000000 - 0000000120000000
>  >>  >>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>  >>  >>  >>> [    0.000000] range: 0000000120000000 - 0000000130000000
>  >>  >>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>  >>  >>  >>> [    0.000000] hole: 000000012c000000 - 0000000130000000
>  >>  >>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>  >>  >>  >>>
>  >>  >>  >>> so your X server need two entries for WB?
>  >>  >>  >>>
>  >>  >>  >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
>  >>  >>  >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
>  >>  >>  >
>  >>  >>  > Here the output with v3 which is disabled by default:
>  >>  >>  >
>  >>  >>  > --($:~)-- cat /proc/mtrr
>  >>  >>  > reg00: base=0xd0000000 (3328MB), size= 256MB: 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=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  >>  >>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  >>  >>  >
>  >>  >>  > dmesg is saying now :
>  >>  >>  >
>  >>  >>  > [   22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
>  >>  >>  >
>  >>  >>  >
>  >>  >>  > My card settings in BIOS ( that was default ) are the following :
>  >>  >>  >
>  >>  >>  > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode )
>  >>  >>  > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
>  >>  >>  >
>  >>  >>  > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
>  >>  >>  > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look)
>  >>  >>  > PEG Port -> Auto ( possible settings Auto , Disabled )
>  >>  >>  > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
>  >>  >>  >
>  >>  >>  > Of course these settings are only possible when the card is not disabled :)
>  >>  >>  >
>  >>  >>  > I'm gonna try v4 now and enable it. Please let me know if you need more infos.
>  >>  >>
>  >>  >>  Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ).
>  >>  >>  It takes 6 minutes to boot to :
>  >>  >>
>  >>  >
>  >>  > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is
>  >>  > another 8M address.
>  >>
>  >>  Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
>  >>
>  >>  I'm not really sure why the 8MB are needed , BIOS book doesn't tell me.
>  >>  I could try to disable and see what I get =)
>  >>
>  >>
>  >>
>  >>  >
>  >>  > mtrr by BIOS is very interesting:
>  >>  > before
>  >>  >>  > reg02: base=0x00000000 (   0MB), size=4096MB: write-back, count=1
>  >>  >>  > reg06: base=0xcf600000 (3318MB), size=   2MB: uncachable, count=1
>  >>  >>  > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
>  >>  >>  > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
>  >>  >>  > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
>  >>  >>  > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
>  >>  >>  > reg05: base=0x128000000 (4736MB), size=  64MB: write-back, count=1
>  >>  >
>  >>  >
>  >>  > after 256M chunk size got
>  >>  >>  >>> [    0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB
>  >>  >>  >>> [    0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
>  >>  >
>  >>  > so the convering is right..., need to spare another entry for your card.
>  >>  >
>  >>  > or we can dumping the
>  >>  >>  >>> [    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
>  >>  > for extra entra...
>  >>  >
>  >>  > but the mtrr trimming code need to be updated instead of only using highest_pfn
>  >>  >
>  >>  > YH
>  >>  >
>  >
>  > please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc.
>  > only for test: i comment out the fill_var_state..
>
>  There are the dmesg's , down to 2m and without chunk_size :
>
>  http://frugalware.org/~crazy/mtrr/mtrr/

please check this one v6 test.

please only check =2g, 1g, and 512m, 256m, 128m, 64m.

Thanks

Yinghai Lu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mtrr_cleanup_v6.patch --]
[-- Type: text/x-patch; name=mtrr_cleanup_v6.patch, Size: 15910 bytes --]

[PATCH] x86: mtrr cleanup for converting continuous to discrete layout v6

some BIOS like to use continus MTRR layout, and may X driver can not add
WB entries for graphical cards when 4g or more RAM installed.

the patch will change MTRR to discrete.

mtrr_chunk_size= could be used to have smaller continuous block to hold holes.
default is 256m, could be set according to size of graphics card memory.

v2: fix -1 for UC checking
v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
    skip the var state change warning.
    remove next_basek in range_to_mtrr()
v4: correct warning mask.
v5: CONFIG_MTRR_SANITIZER
v6: 1g, 2g, 512 aligment with extra hole

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

Index: linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c
@@ -158,6 +158,20 @@ get_mtrr_var_range(unsigned int index, s
 	rdmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
 }
 
+/*  fill the MSR pair relating to a var range  */
+void fill_mtrr_var_range(unsigned int index,
+		u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi)
+{
+	struct mtrr_var_range *vr;
+
+	vr = mtrr_state.var_ranges;
+
+	vr[index].base_lo = base_lo;
+	vr[index].base_hi = base_hi;
+	vr[index].mask_lo = mask_lo;
+	vr[index].mask_hi = mask_hi;
+}
+
 static void
 get_fixed_ranges(mtrr_type * frs)
 {
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
@@ -37,6 +37,7 @@
 #include <linux/smp.h>
 #include <linux/cpu.h>
 #include <linux/mutex.h>
+#include <linux/sort.h>
 
 #include <asm/e820.h>
 #include <asm/mtrr.h>
@@ -609,6 +610,375 @@ static struct sysdev_driver mtrr_sysdev_
 	.resume		= mtrr_restore,
 };
 
+#ifdef CONFIG_MTRR_SANITIZER
+
+#ifdef CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT
+static int enable_mtrr_cleanup __initdata = 1;
+#else
+static int enable_mtrr_cleanup __initdata;
+#endif
+
+#else
+
+static int enable_mtrr_cleanup __initdata = -1;
+
+#endif
+
+static int __init disable_mtrr_cleanup_setup(char *str)
+{
+	if (enable_mtrr_cleanup != -1)
+		enable_mtrr_cleanup = 0;
+	return 0;
+}
+early_param("disable_mtrr_cleanup", disable_mtrr_cleanup_setup);
+
+static int __init enable_mtrr_cleanup_setup(char *str)
+{
+	if (enable_mtrr_cleanup != -1)
+		enable_mtrr_cleanup = 1;
+	return 0;
+}
+early_param("enble_mtrr_cleanup", enable_mtrr_cleanup_setup);
+
+#define RANGE_NUM 256
+
+struct res_range {
+	size_t start;
+	size_t end;
+};
+
+static void __init subtract_range(struct res_range *range, size_t start,
+				size_t end)
+{
+	int i;
+	int j;
+
+	for (j = 0; j < RANGE_NUM; j++) {
+		if (!range[j].end)
+			continue;
+
+		if (start <= range[j].start && end >= range[j].end) {
+			range[j].start = 0;
+			range[j].end = 0;
+			continue;
+		}
+
+		if (start <= range[j].start && end < range[j].end && range[j].start < end + 1) {
+			range[j].start = end + 1;
+			continue;
+		}
+
+
+		if (start > range[j].start && end >= range[j].end && range[j].end > start - 1) {
+			range[j].end = start - 1;
+			continue;
+		}
+
+		if (start > range[j].start && end < range[j].end) {
+			/* find the new spare */
+			for (i = 0; i < RANGE_NUM; i++) {
+				if (range[i].end == 0)
+					break;
+			}
+			if (i < RANGE_NUM) {
+				range[i].end = range[j].end;
+				range[i].start = end + 1;
+			} else {
+				printk(KERN_ERR "run of slot in ranges\n");
+			}
+			range[j].end = start - 1;
+			continue;
+		}
+	}
+}
+
+static int __cpuinit cmp_range(const void *x1, const void *x2)
+{
+	const struct res_range *r1 = x1;
+	const struct res_range *r2 = x2;
+	s64 start1, start2;
+
+	start1 = r1->start;
+	start2 = r2->start;
+
+	return start1 - start2;
+}
+
+struct var_mtrr_state {
+	unsigned long range_startk, range_sizek;
+	unsigned long chunk_sizek;
+	unsigned int reg;
+	unsigned address_bits;
+};
+
+static void __init set_var_mtrr(
+	unsigned int reg, unsigned long basek, unsigned long sizek,
+	unsigned char type, unsigned address_bits)
+{
+	u32 base_lo, base_hi, mask_lo, mask_hi;
+	unsigned address_mask_high;
+
+	if (!sizek) {
+//		fill_mtrr_var_range(reg, 0, 0, 0, 0);
+		return;
+	}
+
+	address_mask_high = ((1u << (address_bits - 32u)) - 1u);
+
+	base_hi = basek >> 22;
+	base_lo  = basek << 10;
+
+	if (sizek < 4*1024*1024) {
+		mask_hi = address_mask_high;
+		mask_lo = ~((sizek << 10) - 1);
+	} else {
+		mask_hi = address_mask_high & (~((sizek >> 22) - 1));
+		mask_lo = 0;
+	}
+
+	base_lo |= type;
+	mask_lo |= 0x800;
+//	fill_mtrr_var_range(reg, base_lo, base_hi, mask_lo, mask_hi);
+}
+
+static unsigned int __init range_to_mtrr(unsigned int reg,
+	unsigned long range_startk, unsigned long range_sizek,
+	unsigned char type, unsigned address_bits)
+{
+	if (!range_sizek || (reg >= num_var_ranges))
+		return reg;
+
+	while (range_sizek) {
+		unsigned long max_align, align;
+		unsigned long sizek;
+		/* Compute the maximum size I can make a range */
+		if (range_startk)
+			max_align = ffs(range_startk) - 1;
+		else
+			max_align = 32;
+		align = fls(range_sizek) - 1;
+		if (align > max_align)
+			align = max_align;
+
+		sizek = 1 << align;
+		printk(KERN_INFO "Setting variable MTRR %d, base: %ldMB, range: %ldMB, type %s\n",
+			reg, range_startk >> 10, sizek >> 10,
+			(type == MTRR_TYPE_UNCACHABLE)?"UC":
+			    ((type == MTRR_TYPE_WRBACK)?"WB":"Other")
+			);
+		set_var_mtrr(reg++, range_startk, sizek, type, address_bits);
+		range_startk += sizek;
+		range_sizek -= sizek;
+		if (reg >= num_var_ranges)
+			break;
+	}
+	return reg;
+}
+
+static void __init range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek)
+{
+	unsigned long hole_basek, hole_sizek;
+	unsigned long range0_basek, range0_sizek;
+	unsigned long range_basek, range_sizek;
+	unsigned long chunk_sizek;
+
+	hole_basek = 0;
+	hole_sizek = 0;
+	chunk_sizek = state->chunk_sizek;
+	range0_basek = state->range_startk;
+
+	/* try to append some small hole */
+	range0_sizek = ALIGN(state->range_sizek, chunk_sizek);
+	if ((range0_sizek == state->range_sizek) ||
+	    ((range0_basek + range0_sizek - chunk_sizek > basek) && basek)) {
+			printk(KERN_INFO "rangeX: %016lx - %016lx\n", range0_basek<<10, (range0_basek + state->range_sizek)<<10);
+			state->reg = range_to_mtrr(state->reg, range0_basek,
+				state->range_sizek, MTRR_TYPE_WRBACK, state->address_bits);
+		return;
+	}
+
+
+	range0_sizek -= chunk_sizek;
+	range_basek = range0_basek + range0_sizek;
+	printk(KERN_INFO "range0: %016lx - %016lx\n", range0_basek<<10, (range0_basek + range0_sizek)<<10);
+	state->reg = range_to_mtrr(state->reg, range0_basek,
+			range0_sizek, MTRR_TYPE_WRBACK, state->address_bits);
+
+	range_sizek = chunk_sizek;
+	if (range_sizek - (state->range_sizek - range0_sizek) < (chunk_sizek >> 1))
+		hole_sizek = range_sizek - (state->range_sizek - range0_sizek);
+	else
+		range_sizek = state->range_sizek - range0_sizek;
+
+	printk(KERN_INFO "range: %016lx - %016lx\n", range_basek<<10, (range_basek + range_sizek)<<10);
+	state->reg = range_to_mtrr(state->reg, range_basek,
+			range_sizek, MTRR_TYPE_WRBACK, state->address_bits);
+	if (hole_sizek) {
+		printk(KERN_INFO "hole: %016lx - %016lx\n", hole_basek<<10, (hole_basek + hole_sizek)<<10);
+		state->reg = range_to_mtrr(state->reg, hole_basek,
+				hole_sizek, MTRR_TYPE_UNCACHABLE, state->address_bits);
+	}
+}
+
+static void __init set_var_mtrr_range(struct var_mtrr_state *state, size_t base_pfn, size_t size_pfn)
+{
+	unsigned long basek, sizek;
+
+	if (state->reg >= num_var_ranges)
+		return;
+
+	basek = base_pfn << (PAGE_SHIFT - 10);
+	sizek = size_pfn << (PAGE_SHIFT - 10);
+
+	/* See if I can merge with the last range */
+	if ((basek <= 1024) || (state->range_startk + state->range_sizek == basek)) {
+		unsigned long endk = basek + sizek;
+		state->range_sizek = endk - state->range_startk;
+		return;
+	}
+	/* Write the range mtrrs */
+	if (state->range_sizek != 0) {
+		range_to_mtrr_with_hole(state, basek);
+
+		state->range_startk = 0;
+		state->range_sizek = 0;
+	}
+	/* Allocate an msr */
+	state->range_startk = basek;
+	state->range_sizek  = sizek;
+}
+
+static u64 mtrr_chunk_size __initdata = (256ULL<<20);
+
+static int __init parse_mtrr_chunk_size_opt(char *p)
+{
+	if (!p)
+		return -EINVAL;
+	mtrr_chunk_size = memparse(p, &p);
+	return 0;
+}
+early_param("mtrr_chunk_size", parse_mtrr_chunk_size_opt);
+
+static void __init x86_setup_var_mtrrs(struct res_range *range, int nr_range, unsigned address_bits)
+{
+	struct var_mtrr_state var_state;
+	int i;
+
+	var_state.range_startk = 0;
+	var_state.range_sizek = 0;
+	var_state.reg = 0;
+	var_state.address_bits = address_bits;
+	var_state.chunk_sizek = mtrr_chunk_size >> 10;
+
+	/* Write the range etc */
+	for (i = 0; i < nr_range; i++)
+		set_var_mtrr_range(&var_state, range[i].start, range[i].end - range[i].start + 1);
+
+	/* Write the last range */
+	range_to_mtrr_with_hole(&var_state, 0);
+	printk(KERN_INFO "DONE variable MTRRs\n");
+	/* Clear out the extra MTRR's */
+	while (var_state.reg < num_var_ranges)
+		set_var_mtrr(var_state.reg++, 0, 0, 0, var_state.address_bits);
+}
+
+static int __init x86_get_mtrr_mem_range(struct res_range *range, int nr_range)
+{
+	unsigned long i, base, size;
+	mtrr_type type;
+	/*
+	 * get WB ranges at first
+	 * assume BIOS don't give us overlapping WB entries
+	 * or add add_range?
+	 */
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type != MTRR_TYPE_WRBACK)
+			continue;
+		range[nr_range].start = base;
+		range[nr_range].end = base + size - 1;
+		nr_range++;
+	}
+	printk(KERN_INFO "After WB checking\n");
+	for (i = 0; i < nr_range; i++)
+		printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1);
+
+	/* take out UC ranges */
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type != MTRR_TYPE_UNCACHABLE)
+			continue;
+		if (!size)
+			continue;
+		subtract_range(range, base, base + size - 1);
+	}
+	/* get new range num */
+	nr_range = 0;
+	for (i = 0; i < RANGE_NUM; i++) {
+		if (!range[i].end)
+			continue;
+		nr_range++;
+	}
+	printk(KERN_INFO "After UC checking\n");
+	for (i = 0; i < nr_range; i++)
+		printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1);
+
+	/* sort the ranges */
+	sort(range, nr_range, sizeof(struct res_range), cmp_range, NULL);
+	printk(KERN_INFO "After sorting\n");
+	for (i = 0; i < nr_range; i++)
+		printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1);
+
+	return nr_range;
+}
+
+static int __init mtrr_cleanup(unsigned address_bits)
+{
+	unsigned long i, base, size, def, dummy;
+	mtrr_type type;
+	struct res_range range[RANGE_NUM];
+	int nr_range;
+
+	/* extra one for all 0 */
+	int num[MTRR_NUM_TYPES + 1];
+
+	if (!is_cpu(INTEL) || enable_mtrr_cleanup < 1)
+		return 0;
+	rdmsr(MTRRdefType_MSR, def, dummy);
+	def &= 0xff;
+	if (def != MTRR_TYPE_UNCACHABLE)
+		return 0;
+
+	/* check entries number */
+	memset(num, 0, sizeof(num));
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type >= MTRR_NUM_TYPES)
+			continue;
+		if (!size)
+			type = MTRR_NUM_TYPES;
+		num[type]++;
+	}
+
+	/* check if we got UC entries */
+	if (!num[MTRR_TYPE_UNCACHABLE])
+		return 0;
+
+	/* check if we only had WB and UC */
+	if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] !=
+		num_var_ranges - num[MTRR_NUM_TYPES])
+		return 0;
+
+	memset(range, 0, sizeof(range));
+	nr_range = x86_get_mtrr_mem_range(range, 0);
+
+	/* convert ranges to var ranges state */
+	x86_setup_var_mtrrs(range, nr_range, address_bits);
+
+	return 1;
+
+}
+
 static int disable_mtrr_trim;
 
 static int __init disable_mtrr_trim_setup(char *str)
@@ -729,18 +1099,21 @@ int __init mtrr_trim_uncached_memory(uns
  */
 void __init mtrr_bp_init(void)
 {
+	u32 phys_addr;
 	init_ifs();
 
+	phys_addr = 32;
+
 	if (cpu_has_mtrr) {
 		mtrr_if = &generic_mtrr_ops;
 		size_or_mask = 0xff000000;	/* 36 bits */
 		size_and_mask = 0x00f00000;
+		phys_addr = 36;
 
 		/* This is an AMD specific MSR, but we assume(hope?) that
 		   Intel will implement it to when they extend the address
 		   bus of the Xeon. */
 		if (cpuid_eax(0x80000000) >= 0x80000008) {
-			u32 phys_addr;
 			phys_addr = cpuid_eax(0x80000008) & 0xff;
 			/* CPUID workaround for Intel 0F33/0F34 CPU */
 			if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
@@ -758,6 +1131,7 @@ void __init mtrr_bp_init(void)
 			   don't support PAE */
 			size_or_mask = 0xfff00000;	/* 32 bits */
 			size_and_mask = 0;
+			phys_addr = 32;
 		}
 	} else {
 		switch (boot_cpu_data.x86_vendor) {
@@ -791,8 +1165,13 @@ void __init mtrr_bp_init(void)
 	if (mtrr_if) {
 		set_num_var_ranges();
 		init_table();
-		if (use_intel())
+		if (use_intel()) {
 			get_mtrr_state();
+
+			if (mtrr_cleanup(phys_addr))
+				mtrr_if->set_all();
+
+		}
 	}
 }
 
@@ -829,9 +1208,10 @@ static int __init mtrr_init_finialize(vo
 {
 	if (!mtrr_if)
 		return 0;
-	if (use_intel())
-		mtrr_state_warn();
-	else {
+	if (use_intel()) {
+		if (enable_mtrr_cleanup < 1)
+			mtrr_state_warn();
+	} else {
 		/* The CPUs haven't MTRR and seem to not support SMP. They have
 		 * specific drivers, we use a tricky method to support
 		 * suspend/resume for them.
Index: linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -81,6 +81,8 @@ void set_mtrr_done(struct set_mtrr_conte
 void set_mtrr_cache_disable(struct set_mtrr_context *ctxt);
 void set_mtrr_prepare_save(struct set_mtrr_context *ctxt);
 
+void fill_mtrr_var_range(unsigned int index,
+		u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi);
 void get_mtrr_state(void);
 
 extern void set_mtrr_ops(struct mtrr_ops * ops);
Index: linux-2.6/Documentation/kernel-parameters.txt
===================================================================
--- linux-2.6.orig/Documentation/kernel-parameters.txt
+++ linux-2.6/Documentation/kernel-parameters.txt
@@ -595,6 +595,16 @@ and is between 256 and 4096 characters. 
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
+	disable_mtrr_cleanup [X86]
+	enable_mtrr_cleanup [X86]
+			The kernel tries to adjust MTRR layout from continuous
+			to discrete, to make X server driver able to add WB
+			entry later. This parameter enables/disables that.
+
+	mtrr_chunk_size=nn[KMG] [X86]
+			used for mtrr cleanup. It is largest continous chunk
+			that could hold holes aka. UC entries.
+
 	disable_mtrr_trim [X86, Intel and AMD only]
 			By default the kernel will trim any uncacheable
 			memory out of your available memory pool based on
Index: linux-2.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -1035,6 +1035,32 @@ config MTRR
 
 	  See <file:Documentation/mtrr.txt> for more information.
 
+config MTRR_SANITIZER
+	def_bool y
+	prompt "MTRR cleanup support"
+	depends on MTRR
+	help
+	  Convert MTRR layout from continuous to discrete, so some X driver
+	  could add WB entries.
+
+	  Say N here if you see bootup problems (boot crash, boot hang,
+	  spontaneous reboots).
+
+	  Could be disabled with disable_mtrr_cleanup. Also mtrr_chunk_size
+	  could be used to send largest mtrr entry size for continuous block
+	  to hold holes (aka. UC entries)
+
+	  If unsure, say Y.
+
+config MTRR_SANITIZER_ENABLE_DEFAULT
+	def_bool y
+	prompt "Enable MTRR cleanup by default"
+	depends on MTRR_SANITIZER
+	help
+	  Enable mtrr cleanup by default
+
+	  If unsure, say Y.
+
 config X86_PAT
 	bool
 	prompt "x86 PAT support"

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Ingo Molnar]

* Eric W. Biederman <ebiederm@xmission.com> wrote:

> So lets concentrate on PAT to solve contiguous MTRR region problems.
> 
> We can upgrade UC to WC with pat.  As well as demote WB to UC or WC. 
> So for those regions we know about we should be in good shape.

sure, but whatever we do now in the sysfs API space, it will hit distros 
only in a year, relistically, because Xorg also has to adopt to it. The 
workaround from Yinghai looks reasonably configurable - if we mess up 
(say an SMM comes in while we fiddle with the MTRRs) we'll likely get a 
lockup right then, during bootup, so it wont be hard to realize what 
went wrong. In that sense it's in fact safer to do it during early init 
than let the user do it via some script, because the window is smaller, 
etc.

we still default to the safe mode of course and dont touch MTRRs, but 
for note the various configuration options that are available to distros 
and users.

	Ingo

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Ingo Molnar]

* Yinghai Lu <yhlu.kernel@gmail.com> wrote:

> v2: fix -1 for UC checking
> v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
>     skip the var state change warning.
>     remove next_basek in range_to_mtrr()
> v4: correct warning mask.
> v5: CONFIG_MTRR_SANITIZER
> v6: 1g, 2g, 512 aligment with extra hole

thanks Yinghai, i picked up v6.

	Ingo

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Ingo Molnar]

* Jesse Barnes <jesse.barnes@intel.com> wrote:

> > i think we should still try to make this a non-default option 
> > because modern Xorg should not have any need to touch MTRRs. Perhaps 
> > a .config dependent on CONFIG_DANGEROUS ;-)
> 
> Well, not quite... we're still waiting on some way of getting WC 
> semantics for sysfs PCI files.  Suresh tells me something like that is 
> queued up, but until that hits the mainline X will still need to bang 
> the MTRRs to get decent performance.

yes, the patch below is queued up for an eventual v2.6.26 merge. If it 
looks fine to you, could you please ack it so that we can send it to 
Linus? I'd like to do this after some pending PAT fixes are upstream.

	Ingo

---------------->
Subject: x86, PAT: export resource_wc in pci sysfs
From: venkatesh.pallipadi@intel.com
Date: Tue, 18 Mar 2008 17:00:22 -0700

For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface in
pci /sysfs along with resource (which is uncached).

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/filesystems/sysfs-pci.txt |    1 
 drivers/pci/pci-sysfs.c                 |   82 +++++++++++++++++++++++---------
 include/linux/pci.h                     |    1 
 3 files changed, 63 insertions(+), 21 deletions(-)

Index: linux-x86.q/Documentation/filesystems/sysfs-pci.txt
===================================================================
--- linux-x86.q.orig/Documentation/filesystems/sysfs-pci.txt
+++ linux-x86.q/Documentation/filesystems/sysfs-pci.txt
@@ -36,6 +36,7 @@ files, each with their own function.
        local_cpus	   nearby CPU mask (cpumask, ro)
        resource		   PCI resource host addresses (ascii, ro)
        resource0..N	   PCI resource N, if present (binary, mmap)
+       resource0_wc..N_wc  PCI WC map resource N, if prefetchable (binary, mmap)
        rom		   PCI ROM resource, if present (binary, ro)
        subsystem_device	   PCI subsystem device (ascii, ro)
        subsystem_vendor	   PCI subsystem vendor (ascii, ro)
Index: linux-x86.q/drivers/pci/pci-sysfs.c
===================================================================
--- linux-x86.q.orig/drivers/pci/pci-sysfs.c
+++ linux-x86.q/drivers/pci/pci-sysfs.c
@@ -489,13 +489,14 @@ pci_mmap_legacy_mem(struct kobject *kobj
  * @kobj: kobject for mapping
  * @attr: struct bin_attribute for the file being mapped
  * @vma: struct vm_area_struct passed into the mmap
+ * @write_combine: 1 for write_combine mapping
  *
  * Use the regular PCI mapping routines to map a PCI resource into userspace.
  * FIXME: write combining?  maybe automatic for prefetchable regions?
  */
 static int
 pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
-		  struct vm_area_struct *vma)
+		  struct vm_area_struct *vma, int write_combine)
 {
 	struct pci_dev *pdev = to_pci_dev(container_of(kobj,
 						       struct device, kobj));
@@ -518,7 +519,21 @@ pci_mmap_resource(struct kobject *kobj, 
 	vma->vm_pgoff += start >> PAGE_SHIFT;
 	mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
 
-	return pci_mmap_page_range(pdev, vma, mmap_type, 0);
+	return pci_mmap_page_range(pdev, vma, mmap_type, write_combine);
+}
+
+static int
+pci_mmap_resource_uc(struct kobject *kobj, struct bin_attribute *attr,
+		     struct vm_area_struct *vma)
+{
+	return pci_mmap_resource(kobj, attr, vma, 0);
+}
+
+static int
+pci_mmap_resource_wc(struct kobject *kobj, struct bin_attribute *attr,
+		     struct vm_area_struct *vma)
+{
+	return pci_mmap_resource(kobj, attr, vma, 1);
 }
 
 /**
@@ -541,9 +556,46 @@ pci_remove_resource_files(struct pci_dev
 			sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
 			kfree(res_attr);
 		}
+
+		res_attr = pdev->res_attr_wc[i];
+		if (res_attr) {
+			sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
+			kfree(res_attr);
+		}
 	}
 }
 
+static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine)
+{
+	/* allocate attribute structure, piggyback attribute name */
+	int name_len = write_combine ? 13 : 10;
+	struct bin_attribute *res_attr;
+	int retval;
+
+	res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC);
+	if (res_attr) {
+		char *res_attr_name = (char *)(res_attr + 1);
+
+		if (write_combine) {
+			pdev->res_attr_wc[num] = res_attr;
+			sprintf(res_attr_name, "resource%d_wc", num);
+			res_attr->mmap = pci_mmap_resource_wc;
+		} else {
+			pdev->res_attr[num] = res_attr;
+			sprintf(res_attr_name, "resource%d", num);
+			res_attr->mmap = pci_mmap_resource_uc;
+		}
+		res_attr->attr.name = res_attr_name;
+		res_attr->attr.mode = S_IRUSR | S_IWUSR;
+		res_attr->size = pci_resource_len(pdev, num);
+		res_attr->private = &pdev->resource[num];
+		retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
+	} else
+		retval = -ENOMEM;
+
+	return retval;
+}
+
 /**
  * pci_create_resource_files - create resource files in sysfs for @dev
  * @dev: dev in question
@@ -557,31 +609,19 @@ static int pci_create_resource_files(str
 
 	/* Expose the PCI resources from this device as files */
 	for (i = 0; i < PCI_ROM_RESOURCE; i++) {
-		struct bin_attribute *res_attr;
 
 		/* skip empty resources */
 		if (!pci_resource_len(pdev, i))
 			continue;
 
-		/* allocate attribute structure, piggyback attribute name */
-		res_attr = kzalloc(sizeof(*res_attr) + 10, GFP_ATOMIC);
-		if (res_attr) {
-			char *res_attr_name = (char *)(res_attr + 1);
+		retval = pci_create_attr(pdev, i, 0);
+		/* for prefetchable resources, create a WC mappable file */
+		if (!retval && pdev->resource[i].flags & IORESOURCE_PREFETCH)
+			retval = pci_create_attr(pdev, i, 1);
 
-			pdev->res_attr[i] = res_attr;
-			sprintf(res_attr_name, "resource%d", i);
-			res_attr->attr.name = res_attr_name;
-			res_attr->attr.mode = S_IRUSR | S_IWUSR;
-			res_attr->size = pci_resource_len(pdev, i);
-			res_attr->mmap = pci_mmap_resource;
-			res_attr->private = &pdev->resource[i];
-			retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
-			if (retval) {
-				pci_remove_resource_files(pdev);
-				return retval;
-			}
-		} else {
-			return -ENOMEM;
+		if (retval) {
+			pci_remove_resource_files(pdev);
+			return retval;
 		}
 	}
 	return 0;
Index: linux-x86.q/include/linux/pci.h
===================================================================
--- linux-x86.q.orig/include/linux/pci.h
+++ linux-x86.q/include/linux/pci.h
@@ -205,6 +205,7 @@ struct pci_dev {
 	struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */
 	int rom_attr_enabled;		/* has display of the rom attribute been enabled? */
 	struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */
+	struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file for WC mapping of resources */
 #ifdef CONFIG_PCI_MSI
 	struct list_head msi_list;
 #endif

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Tue, Apr 29, 2008 at 3:34 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
>  * Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
>  > v2: fix -1 for UC checking
>  > v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
>  >     skip the var state change warning.
>  >     remove next_basek in range_to_mtrr()
>  > v4: correct warning mask.
>  > v5: CONFIG_MTRR_SANITIZER
>  > v6: 1g, 2g, 512 aligment with extra hole
>
>  thanks Yinghai, i picked up v6.

please use v8 instead. will send it out in minutes.
also it need
[PATCH 2/2] x86: fix trimming e820 with MTRR holes.
it could check range is not coverred below 4g when 8g ram installed.

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Andrew Morton]

On Tue, 29 Apr 2008 12:37:41 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> +static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine)
> +{
> +	/* allocate attribute structure, piggyback attribute name */
> +	int name_len = write_combine ? 13 : 10;
> +	struct bin_attribute *res_attr;
> +	int retval;
> +
> +	res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC);

That (retained from current code) GFP_ATOMIC cannot be necessary.

> +	if (res_attr) {
> +		char *res_attr_name = (char *)(res_attr + 1);
> +
> +		if (write_combine) {
> +			pdev->res_attr_wc[num] = res_attr;
> +			sprintf(res_attr_name, "resource%d_wc", num);
> +			res_attr->mmap = pci_mmap_resource_wc;
> +		} else {
> +			pdev->res_attr[num] = res_attr;
> +			sprintf(res_attr_name, "resource%d", num);
> +			res_attr->mmap = pci_mmap_resource_uc;
> +		}
> +		res_attr->attr.name = res_attr_name;
> +		res_attr->attr.mode = S_IRUSR | S_IWUSR;
> +		res_attr->size = pci_resource_len(pdev, num);
> +		res_attr->private = &pdev->resource[num];
> +		retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);

Because of this.

> +	} else
> +		retval = -ENOMEM;
> +
> +	return retval;
> +}

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Jesse Barnes]

On Tuesday, April 29, 2008 3:37 am Ingo Molnar wrote:
> * Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > i think we should still try to make this a non-default option
> > > because modern Xorg should not have any need to touch MTRRs. Perhaps
> > > a .config dependent on CONFIG_DANGEROUS ;-)
> >
> > Well, not quite... we're still waiting on some way of getting WC
> > semantics for sysfs PCI files.  Suresh tells me something like that is
> > queued up, but until that hits the mainline X will still need to bang
> > the MTRRs to get decent performance.
>
> yes, the patch below is queued up for an eventual v2.6.26 merge. If it
> looks fine to you, could you please ack it so that we can send it to
> Linus? I'd like to do this after some pending PAT fixes are upstream.
>
> 	Ingo
>
> ---------------->
> Subject: x86, PAT: export resource_wc in pci sysfs
> From: venkatesh.pallipadi@intel.com
> Date: Tue, 18 Mar 2008 17:00:22 -0700
>
> For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface
> in pci /sysfs along with resource (which is uncached).
>
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>

I really would have preferred a new mmap flag for this like ia64 used to have, 
but Suresh and Venki tell me that a flag doesn't map very well to what some 
architectures support, so I suppose a new file is the way to go.  Should work 
fine for X's needs.

Acked-by:  Jesse Barnes <jbarnes@virtuousgeek.org>

Thanks,
Jesse

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Eric W. Biederman]

Ingo Molnar <mingo@elte.hu> writes:

> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> So lets concentrate on PAT to solve contiguous MTRR region problems.
>> 
>> We can upgrade UC to WC with pat.  As well as demote WB to UC or WC. 
>> So for those regions we know about we should be in good shape.
>
> sure, but whatever we do now in the sysfs API space, it will hit distros 
> only in a year, relistically, because Xorg also has to adopt to it. The 
> workaround from Yinghai looks reasonably configurable - if we mess up 
> (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a 
> lockup right then, during bootup, so it wont be hard to realize what 
> went wrong. In that sense it's in fact safer to do it during early init 
> than let the user do it via some script, because the window is smaller, 
> etc.
>
> we still default to the safe mode of course and dont touch MTRRs, but 
> for note the various configuration options that are available to distros 
> and users.

The potential problem isn't while we reprogram the MTRRs, the potential
problem is mapping the SMM area uncachable.  In which case we will
make each SMM interrupt drastically slower.  Which can have all kinds of
unpleasant side effects.

If we really can mess up SMM mode that way we have a really nasty
interaction that is horrible to debug, or recognize.

Further the opportunity for this kind of fixup is small.
Newer AMD systems don't need it as they have an extra
way of specifying memory about 4G as WB.  Systems with just
the MTRRs can only use this when they have right around 4GB
because with more memory there are not enough MTRRs to leave them
non-overlapping and still mark all of memory WB.

Eric

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Tue, Apr 29, 2008 at 10:29 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> Ingo Molnar <mingo@elte.hu> writes:
>
>  > * Eric W. Biederman <ebiederm@xmission.com> wrote:
>  >
>  >> So lets concentrate on PAT to solve contiguous MTRR region problems.
>  >>
>  >> We can upgrade UC to WC with pat.  As well as demote WB to UC or WC.
>  >> So for those regions we know about we should be in good shape.
>  >
>  > sure, but whatever we do now in the sysfs API space, it will hit distros
>  > only in a year, relistically, because Xorg also has to adopt to it. The
>  > workaround from Yinghai looks reasonably configurable - if we mess up
>  > (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a
>  > lockup right then, during bootup, so it wont be hard to realize what
>  > went wrong. In that sense it's in fact safer to do it during early init
>  > than let the user do it via some script, because the window is smaller,
>  > etc.
>  >
>  > we still default to the safe mode of course and dont touch MTRRs, but
>  > for note the various configuration options that are available to distros
>  > and users.
>
>  The potential problem isn't while we reprogram the MTRRs, the potential
>  problem is mapping the SMM area uncachable.  In which case we will
>  make each SMM interrupt drastically slower.  Which can have all kinds of
>  unpleasant side effects.

and ACPI area too.

that only try to make the continuous to discrete layout. and still try
to cover all that is (WBs - UC) directly with WB.
only thing is that could run out of MTRR..., and mtrr_gran_size is
used to avoid that.
then some RAM that is less than mtrr_gran_size could be dumped.
so mtrr_gran_size could do sth.
anyway this patch only can meet one end.
for example Mika Fischer's system doesn't need to trim any RAM in MTRR.
but for Gabriel's system may need to trim some RAM in MTRR.

current mtrr_gran_size is default to 64M...

may need another patch to loop all mtrr_chunk_size (2g, 1g, ...64M) ,
mtrr_gran_size (2g, 1g, ...1M) meet
1. leave one or two entry for X server driver
2. lose less cover for RAM in MTRR.

anyway that should be done in BIOS. but ...

>
>  If we really can mess up SMM mode that way we have a really nasty
>  interaction that is horrible to debug, or recognize.
>
>  Further the opportunity for this kind of fixup is small.
>  Newer AMD systems don't need it as they have an extra
>  way of specifying memory about 4G as WB.  Systems with just
>  the MTRRs can only use this when they have right around 4GB
>  because with more memory there are not enough MTRRs to leave them
>  non-overlapping and still mark all of memory WB.

yes. the patch handle the AMD rev f later with mtrr_tom2.
I have one system that give me - ( strange one ?)
0 - 128g WB
4g-512m, 4g wc

after the patch i got

0 - 2048m wb
2048m - 1024m wb
3072m - 3584m wb

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Eric W. Biederman]

"Yinghai Lu" <yhlu.kernel@gmail.com> writes:

>>  The potential problem isn't while we reprogram the MTRRs, the potential
>>  problem is mapping the SMM area uncachable.  In which case we will
>>  make each SMM interrupt drastically slower.  Which can have all kinds of
>>  unpleasant side effects.
>
> and ACPI area too.

True but at least that one is visible.

> that only try to make the continuous to discrete layout. and still try
> to cover all that is (WBs - UC) directly with WB.
> only thing is that could run out of MTRR..., and mtrr_gran_size is
> used to avoid that.
> then some RAM that is less than mtrr_gran_size could be dumped.
> so mtrr_gran_size could do sth.
> anyway this patch only can meet one end.
> for example Mika Fischer's system doesn't need to trim any RAM in MTRR.
> but for Gabriel's system may need to trim some RAM in MTRR.

Right.  Ram trimming (changing memory from WB to UC) is the potential
problem.

See my other post, in short I think we can address safely address all
of the systems where the only problem is the selection of MTRRs by the
BIOS.

Then have an option (mtrr_chunk_size) for RAM trimming that is
off by default.

It is good to hear that some users and some systems
get the benefit without trimming.

Eric

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Yinghai Lu]

On Tue, Apr 29, 2008 at 12:19 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>
> >>  The potential problem isn't while we reprogram the MTRRs, the potential
>  >>  problem is mapping the SMM area uncachable.  In which case we will
>  >>  make each SMM interrupt drastically slower.  Which can have all kinds of
>  >>  unpleasant side effects.
>  >
>  > and ACPI area too.
>
>  True but at least that one is visible.
>
>
>  > that only try to make the continuous to discrete layout. and still try
>  > to cover all that is (WBs - UC) directly with WB.
>  > only thing is that could run out of MTRR..., and mtrr_gran_size is
>  > used to avoid that.
>  > then some RAM that is less than mtrr_gran_size could be dumped.
>  > so mtrr_gran_size could do sth.
>  > anyway this patch only can meet one end.
>  > for example Mika Fischer's system doesn't need to trim any RAM in MTRR.
>  > but for Gabriel's system may need to trim some RAM in MTRR.
>
>  Right.  Ram trimming (changing memory from WB to UC) is the potential
>  problem.
>
>  See my other post, in short I think we can address safely address all
>  of the systems where the only problem is the selection of MTRRs by the
>  BIOS.

BIOS should provide the selection...

>
>  Then have an option (mtrr_chunk_size) for RAM trimming that is
>  off by default.

Yes. there is CONFIG option and boot command line to enable it.

YH

Re: [PATCH] x86_32: trim memory by updating e820 v3

[Eric W. Biederman]

"Yinghai Lu" <yhlu.kernel@gmail.com> writes:

> On Tue, Apr 29, 2008 at 12:19 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>>
>>
>> >>  The potential problem isn't while we reprogram the MTRRs, the potential
>>  >>  problem is mapping the SMM area uncachable.  In which case we will
>>  >>  make each SMM interrupt drastically slower.  Which can have all kinds of
>>  >>  unpleasant side effects.
>>  >
>>  > and ACPI area too.
>>
>>  True but at least that one is visible.
>>
>>
>>  > that only try to make the continuous to discrete layout. and still try
>>  > to cover all that is (WBs - UC) directly with WB.
>>  > only thing is that could run out of MTRR..., and mtrr_gran_size is
>>  > used to avoid that.
>>  > then some RAM that is less than mtrr_gran_size could be dumped.
>>  > so mtrr_gran_size could do sth.
>>  > anyway this patch only can meet one end.
>>  > for example Mika Fischer's system doesn't need to trim any RAM in MTRR.
>>  > but for Gabriel's system may need to trim some RAM in MTRR.
>>
>>  Right.  Ram trimming (changing memory from WB to UC) is the potential
>>  problem.
>>
>>  See my other post, in short I think we can address safely address all
>>  of the systems where the only problem is the selection of MTRRs by the
>>  BIOS.
>
> BIOS should provide the selection...

The BIOS will setup which areas should be WB in the mtrrs.
Having in the linux the ability to change from overlapping
mtrrs to discrete mtrrs with BIOS support appears very
practical, useful and always safe.

>>  Then have an option (mtrr_chunk_size) for RAM trimming that is
>>  off by default.
>
> Yes. there is CONFIG option and boot command line to enable it.

However when it is enabled the default chunk size is still 256M.
If we did not apply chunk size processing by default so we
did not transform any regions from WB to UC by default we could
unconditionally enable the code that yields discrete MTRRs.

Then the CONFIG option and the command line option could be made to
apply to the dangerous bits that change areas from WB to UC.  Which
I doubt we will want to have on by default but that can be useful
for people who really want to have X go fast and an uncached SMM
or ACPI area is not a problem. (ACPI we can handle by just copying
the code to a cached area, we can't even discover the SMM area).

Eric

[patch] PCI: export resource_wc in pci sysfs

[Ingo Molnar]

* Jesse Barnes <jesse.barnes@intel.com> wrote:

> I really would have preferred a new mmap flag for this like ia64 used 
> to have, but Suresh and Venki tell me that a flag doesn't map very 
> well to what some architectures support, so I suppose a new file is 
> the way to go.  Should work fine for X's needs.
> 
> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>

thanks! Linus, please apply the patch below.

	Ingo

------------------>
Subject: PCI: export resource_wc in pci sysfs
From: venkatesh.pallipadi@intel.com
Date: Tue, 18 Mar 2008 17:00:22 -0700

For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface in
pci /sysfs along with resource (which is uncached).

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/filesystems/sysfs-pci.txt |    1 
 drivers/pci/pci-sysfs.c                 |   82 +++++++++++++++++++++++---------
 include/linux/pci.h                     |    1 
 3 files changed, 63 insertions(+), 21 deletions(-)

Index: linux-x86.q/Documentation/filesystems/sysfs-pci.txt
===================================================================
--- linux-x86.q.orig/Documentation/filesystems/sysfs-pci.txt
+++ linux-x86.q/Documentation/filesystems/sysfs-pci.txt
@@ -36,6 +36,7 @@ files, each with their own function.
        local_cpus	   nearby CPU mask (cpumask, ro)
        resource		   PCI resource host addresses (ascii, ro)
        resource0..N	   PCI resource N, if present (binary, mmap)
+       resource0_wc..N_wc  PCI WC map resource N, if prefetchable (binary, mmap)
        rom		   PCI ROM resource, if present (binary, ro)
        subsystem_device	   PCI subsystem device (ascii, ro)
        subsystem_vendor	   PCI subsystem vendor (ascii, ro)
Index: linux-x86.q/drivers/pci/pci-sysfs.c
===================================================================
--- linux-x86.q.orig/drivers/pci/pci-sysfs.c
+++ linux-x86.q/drivers/pci/pci-sysfs.c
@@ -489,13 +489,14 @@ pci_mmap_legacy_mem(struct kobject *kobj
  * @kobj: kobject for mapping
  * @attr: struct bin_attribute for the file being mapped
  * @vma: struct vm_area_struct passed into the mmap
+ * @write_combine: 1 for write_combine mapping
  *
  * Use the regular PCI mapping routines to map a PCI resource into userspace.
  * FIXME: write combining?  maybe automatic for prefetchable regions?
  */
 static int
 pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
-		  struct vm_area_struct *vma)
+		  struct vm_area_struct *vma, int write_combine)
 {
 	struct pci_dev *pdev = to_pci_dev(container_of(kobj,
 						       struct device, kobj));
@@ -518,7 +519,21 @@ pci_mmap_resource(struct kobject *kobj, 
 	vma->vm_pgoff += start >> PAGE_SHIFT;
 	mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
 
-	return pci_mmap_page_range(pdev, vma, mmap_type, 0);
+	return pci_mmap_page_range(pdev, vma, mmap_type, write_combine);
+}
+
+static int
+pci_mmap_resource_uc(struct kobject *kobj, struct bin_attribute *attr,
+		     struct vm_area_struct *vma)
+{
+	return pci_mmap_resource(kobj, attr, vma, 0);
+}
+
+static int
+pci_mmap_resource_wc(struct kobject *kobj, struct bin_attribute *attr,
+		     struct vm_area_struct *vma)
+{
+	return pci_mmap_resource(kobj, attr, vma, 1);
 }
 
 /**
@@ -541,9 +556,46 @@ pci_remove_resource_files(struct pci_dev
 			sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
 			kfree(res_attr);
 		}
+
+		res_attr = pdev->res_attr_wc[i];
+		if (res_attr) {
+			sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
+			kfree(res_attr);
+		}
 	}
 }
 
+static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine)
+{
+	/* allocate attribute structure, piggyback attribute name */
+	int name_len = write_combine ? 13 : 10;
+	struct bin_attribute *res_attr;
+	int retval;
+
+	res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC);
+	if (res_attr) {
+		char *res_attr_name = (char *)(res_attr + 1);
+
+		if (write_combine) {
+			pdev->res_attr_wc[num] = res_attr;
+			sprintf(res_attr_name, "resource%d_wc", num);
+			res_attr->mmap = pci_mmap_resource_wc;
+		} else {
+			pdev->res_attr[num] = res_attr;
+			sprintf(res_attr_name, "resource%d", num);
+			res_attr->mmap = pci_mmap_resource_uc;
+		}
+		res_attr->attr.name = res_attr_name;
+		res_attr->attr.mode = S_IRUSR | S_IWUSR;
+		res_attr->size = pci_resource_len(pdev, num);
+		res_attr->private = &pdev->resource[num];
+		retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
+	} else
+		retval = -ENOMEM;
+
+	return retval;
+}
+
 /**
  * pci_create_resource_files - create resource files in sysfs for @dev
  * @dev: dev in question
@@ -557,31 +609,19 @@ static int pci_create_resource_files(str
 
 	/* Expose the PCI resources from this device as files */
 	for (i = 0; i < PCI_ROM_RESOURCE; i++) {
-		struct bin_attribute *res_attr;
 
 		/* skip empty resources */
 		if (!pci_resource_len(pdev, i))
 			continue;
 
-		/* allocate attribute structure, piggyback attribute name */
-		res_attr = kzalloc(sizeof(*res_attr) + 10, GFP_ATOMIC);
-		if (res_attr) {
-			char *res_attr_name = (char *)(res_attr + 1);
+		retval = pci_create_attr(pdev, i, 0);
+		/* for prefetchable resources, create a WC mappable file */
+		if (!retval && pdev->resource[i].flags & IORESOURCE_PREFETCH)
+			retval = pci_create_attr(pdev, i, 1);
 
-			pdev->res_attr[i] = res_attr;
-			sprintf(res_attr_name, "resource%d", i);
-			res_attr->attr.name = res_attr_name;
-			res_attr->attr.mode = S_IRUSR | S_IWUSR;
-			res_attr->size = pci_resource_len(pdev, i);
-			res_attr->mmap = pci_mmap_resource;
-			res_attr->private = &pdev->resource[i];
-			retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
-			if (retval) {
-				pci_remove_resource_files(pdev);
-				return retval;
-			}
-		} else {
-			return -ENOMEM;
+		if (retval) {
+			pci_remove_resource_files(pdev);
+			return retval;
 		}
 	}
 	return 0;
Index: linux-x86.q/include/linux/pci.h
===================================================================
--- linux-x86.q.orig/include/linux/pci.h
+++ linux-x86.q/include/linux/pci.h
@@ -205,6 +205,7 @@ struct pci_dev {
 	struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */
 	int rom_attr_enabled;		/* has display of the rom attribute been enabled? */
 	struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */
+	struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file for WC mapping of resources */
 #ifdef CONFIG_PCI_MSI
 	struct list_head msi_list;
 #endif

Re: [patch] PCI: export resource_wc in pci sysfs

[Andrew Morton]

On Wed, 30 Apr 2008 00:03:46 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> +static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine)
> +{
> +	/* allocate attribute structure, piggyback attribute name */
> +	int name_len = write_combine ? 13 : 10;
> +	struct bin_attribute *res_attr;
> +	int retval;
> +
> +	res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC);
> +	if (res_attr) {
> +		char *res_attr_name = (char *)(res_attr + 1);
> +
> +		if (write_combine) {
> +			pdev->res_attr_wc[num] = res_attr;
> +			sprintf(res_attr_name, "resource%d_wc", num);
> +			res_attr->mmap = pci_mmap_resource_wc;
> +		} else {
> +			pdev->res_attr[num] = res_attr;
> +			sprintf(res_attr_name, "resource%d", num);
> +			res_attr->mmap = pci_mmap_resource_uc;
> +		}
> +		res_attr->attr.name = res_attr_name;
> +		res_attr->attr.mode = S_IRUSR | S_IWUSR;
> +		res_attr->size = pci_resource_len(pdev, num);
> +		res_attr->private = &pdev->resource[num];
> +		retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
> +	} else
> +		retval = -ENOMEM;
> +
> +	return retval;
> +}

That GFP_ATOMIC should be switched to GFP_KERNEL.

Do we reeeeeeeely need to pull this
tack-the-string-onto-the-end-of-the-struct stunt?  If we didn't do that,
this code could then be taught about kasprintf() and things like that "? 
13 : 10" could be thankfully laid to rest.