Skip to contentSkip to conversation

x86: disable_mtrr_trim only need for x86_64

PATCH In review Yinghai Lu 14 participants 87 messages Jan 20, 2008 – Apr 29, 2008 2 messages not in the archive

Subsystems (3)
lore
Share & tools
lore

Yinghai Lu

author
#0 lore raw

PATCH 1/1 x86: disable_mtrr_trim only need for x86_64

[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

arch/x86/kernel/cpu/mtrr/main.c +1 -1
index 46763e3..608c88a 100644
@@ -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
  *
#1 lore raw
Quoted 7 lines · 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

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

#2 lore raw
Quoted 9 lines · H. Peter Anvin
Quoted 7 lines · 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

Quoted 8 lines

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

author
#3 lore raw

PATCH 1/1 x86_64: update e820 instead of updating end_pfn

In reply to H. Peter Anvin

[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

arch/x86/kernel/cpu/mtrr/main.c +14 -3
index 46763e3..28ae79a 100644
@@ -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
 
arch/x86/kernel/setup_64.c +5 -2
index 2ad8bdd..5194c2a 100644
@@ -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;
 
include/asm-x86/mtrr.h +3 -2
index 96876ec..e552503 100644
@@ -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) {;}
 
#4 lore raw

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

Quoted 4 lines · 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

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

#5 lore raw

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

Quoted 9 lines · On Sunday 20 January 2008 10:20:27 Ingo Molnar wrote:
Quoted 4 lines · 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

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

author
#6 lore raw

PATCH 1/1 x86_64: update e820 instead of updating end_pfn v2

[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

arch/x86/kernel/cpu/mtrr/main.c +22 -10
Index: 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
 
arch/x86/kernel/setup_64.c +5 -2
Index: 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;
 
include/asm-x86/mtrr.h +3 -2
Index: 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) {;}
 
author
#7 lore raw

PATCH 1/1 x86_32: trim memory by updating e820

[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.

arch/x86/kernel/cpu/common.c +8 -4
Index: 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)
arch/x86/kernel/setup_32.c +8 -0
Index: 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
arch/x86/kernel/cpu/mtrr/main.c +0 -2
Index: 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
Documentation/kernel-parameters.txt +1 -1
Index: 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,
include/asm-x86/processor.h +1 -0
Index: 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 *);
arch/x86/kernel/e820_32.c +11 -0
Index: 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");
+}
include/asm-x86/e820_32.h +3 -0
Index: 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);
#8 lore raw

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

In reply to Yinghai Lu

arch/x86/kernel/cpu/mtrr/main.c static __init int amd_special_default_mt · line 666

Quoted 13 lines

{

arch/x86/kernel/cpu/mtrr/main.c +3 -2
 	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

#9 lore raw

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

Quoted 16 lines · Andi Kleen

arch/x86/kernel/cpu/mtrr/main.c static __init int amd_special_default_mt · line 666

Quoted 12 lines

{

arch/x86/kernel/cpu/mtrr/main.c +3 -2
 	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

#10 lore raw

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

Quoted 9 lines
Quoted 4 lines

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

#11 lore raw

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

Quoted 12 lines · Andi Kleen
Quoted 7 lines
Quoted 3 lines

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;
author
#12 lore raw

PATCH 1/1 x86_64: check if Tom2 is enabled

In reply to Andi Kleen

[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

arch/x86/kernel/cpu/mtrr/main.c +3 -1
index 289ba1a..26eed57 100644
@@ -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;
 }
#13 lore raw

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

[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 <[email protected]>
| 
| 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 -

#14 lore raw

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

Quoted 4 lines · Cyrill Gorcunov

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

#15 lore raw

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

[H. Peter Anvin - Mon, Jan 21, 2008 at 09:39:16AM -0800]

Quoted 9 lines
Quoted 2 lines · Cyrill Gorcunov

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.

Quoted 5 lines

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 -

#16 lore raw

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

In reply to Cyrill Gorcunov
Quoted 3 lines

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

#17 lore raw

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

[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 -

#18 lore raw

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

Quoted 11 lines · 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.
| 

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

#19 lore raw

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

Quoted 4 lines

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.

Quoted 3 lines

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

#20 lore raw

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

In reply to Ingo Molnar
Quoted 11 lines · Ingo Molnar
Quoted 4 lines · 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

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#23 lore raw

PATCH 1/1 x86_32: trim memory by updating e820 v2

[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

arch/x86/kernel/cpu/common.c +8 -4
Index: 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)
arch/x86/kernel/setup_32.c +8 -0
Index: 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
arch/x86/kernel/cpu/mtrr/main.c +0 -2
Index: 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
Documentation/kernel-parameters.txt +1 -1
Index: 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,
include/asm-x86/processor.h +1 -0
Index: 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 *);
arch/x86/kernel/e820_32.c +11 -0
Index: 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");
+}
include/asm-x86/e820_32.h +3 -0
Index: 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);
arch/x86/kernel/setup_64.c +1 -3
@@ -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;
 
Acked-by on v1 1/1
#24 lore raw

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

Quoted 10 lines · 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

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

or

as appropriate too.

Thanks,
Jesse

#25 lore raw

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

Quoted 17 lines · Jesse Barnes
Quoted 10 lines · 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

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

Quoted 9 lines

or

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.

author
#26 lore raw

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

Quoted 30 lines · Justin Piszcz
Quoted 17 lines · Jesse Barnes
Quoted 10 lines · 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

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

Quoted 9 lines

or

as appropriate too.

Thanks,
Jesse

Quoted 5 lines

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

#27 lore raw

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

Quoted 23 lines · Yinghai Lu

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

Quoted 9 lines

[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.

author
#28 lore raw

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

Quoted 33 lines · Justin Piszcz
Quoted 30 lines · Yinghai Lu

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

Quoted 6 lines
Quoted 2 lines

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

#29 lore raw

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

Quoted 45 lines · Yinghai Lu
Quoted 33 lines · Justin Piszcz
Quoted 30 lines · Yinghai Lu

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

Quoted 6 lines
Quoted 2 lines

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

Quoted 6 lines

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.

#30 lore raw

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

Quoted 2 lines · Justin Piszcz

...

Quoted 13 lines

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:

Quoted 8 lines

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

#31 lore raw

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

Quoted 27 lines · Yinghai Lu
Quoted 2 lines · Justin Piszcz

...

Quoted 13 lines

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:

Quoted 8 lines

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.

Quoted 6 lines

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.

#32 lore raw

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

In reply to Justin Piszcz
Quoted 19 lines · Justin Piszcz

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

Quoted 3 lines

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

#33 lore raw

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

Quoted 35 lines · Ingo Molnar
Quoted 19 lines · Justin Piszcz

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

Quoted 3 lines

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:

Quoted 8 lines
[    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.

#34 lore raw

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

In reply to Yinghai Lu
Quoted 11 lines · 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

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 <[email protected]>

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

---
 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(-)
Documentation/kernel-parameters.txt +1 -1
Index: 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,
arch/x86/kernel/cpu/common.c +8 -4
Index: 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)
arch/x86/kernel/cpu/mtrr/main.c +0 -2
Index: 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
arch/x86/kernel/e820_32.c +11 -0
Index: 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");
+}
arch/x86/kernel/setup_32.c +7 -0
Index: 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
arch/x86/kernel/setup_64.c +1 -3
Index: 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;
 
include/asm-x86/e820_32.h +3 -0
Index: 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);
include/asm-x86/processor.h +1 -0
Index: 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 *);

#
# 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

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!
author
#35 lore raw

PATCH 1/1 x86_32: trim memory by updating e820 v3

[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.

arch/x86/kernel/cpu/common.c +29 -1
Index: 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)
arch/x86/kernel/setup_32.c +6 -0
Index: 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
arch/x86/kernel/cpu/mtrr/main.c +0 -2
Index: 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
Documentation/kernel-parameters.txt +1 -1
Index: 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,
arch/x86/kernel/e820_32.c +11 -0
Index: 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");
+}
include/asm-x86/e820_32.h +3 -0
Index: 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);
#36 lore raw

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

Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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.

#37 lore raw

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

Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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

#38 lore raw

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

Quoted 83 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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

Quoted 7 lines

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

#39 lore raw

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

Quoted 6 lines · Yinghai Lu

On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <[email protected]> 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

#40 lore raw

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

Quoted 16 lines · Eric W. Biederman
Quoted 7 lines · Yinghai Lu

On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <[email protected]> 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.

Quoted 8 lines

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

#41 lore raw

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

In reply to Eric W. Biederman
Quoted 4 lines · Eric W. Biederman

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

#42 lore raw

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

Quoted 16 lines · Ingo Molnar
Quoted 4 lines · Eric W. Biederman

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.

Quoted 3 lines

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

#43 lore raw

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

Quoted 19 lines · Eric W. Biederman
Quoted 16 lines · Ingo Molnar
Quoted 4 lines · Eric W. Biederman

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.

Quoted 8 lines
Quoted 3 lines

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 ...

Quoted 10 lines

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

#44 lore raw

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

Quoted 6 lines · Yinghai Lu
Quoted 4 lines

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.

Quoted 9 lines

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

#45 lore raw

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

Quoted 23 lines · Eric W. Biederman
Quoted 6 lines · Yinghai Lu
Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 6 lines

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...

Quoted 3 lines

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

#46 lore raw

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

Quoted 25 lines · Yinghai Lu
Quoted 23 lines · Eric W. Biederman
Quoted 6 lines · Yinghai Lu
Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

Quoted 4 lines
Quoted 2 lines

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

#47 lore raw

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

In reply to Gabriel C
Quoted 74 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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 :

Quoted 7 lines

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

#48 lore raw

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

Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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 :

Quoted 7 lines

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

Quoted 5 lines

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

Quoted 3 lines

YH

Gabriel

#49 lore raw

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

Quoted 196 lines · Gabriel C
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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 :

Quoted 7 lines

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

Quoted 5 lines

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
Quoted 7 lines

--($:~)-- 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

#50 lore raw

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

Quoted 199 lines · Yinghai Lu
Quoted 198 lines · Gabriel C
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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 :

Quoted 7 lines

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

Quoted 5 lines

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

Quoted 8 lines
Quoted 4 lines

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.

Quoted 3 lines

YH

Gabriel

#51 lore raw

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

Quoted 227 lines · Gabriel C
Quoted 199 lines · Yinghai Lu
Quoted 198 lines · Gabriel C
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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 :

Quoted 7 lines

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

Quoted 5 lines

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

Quoted 7 lines
Quoted 4 lines

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

Quoted 1 line

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.

#52 lore raw

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

Quoted 7 lines · Gabriel C

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

#53 lore raw

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

Quoted 11 lines · Mika Fischer
Quoted 7 lines · Gabriel C

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

#54 lore raw

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

In reply to Gabriel C
Quoted 7 lines · Gabriel C
Quoted 3 lines

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

#55 lore raw

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

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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.

Quoted 3 lines

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. :)

Quoted 3 lines

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

#56 lore raw

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

Quoted 5 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Ingo Molnar schrieb:

Quoted 8 lines
Quoted 3 lines

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.

Quoted 3 lines

Regards,
Mika

Gabriel

#57 lore raw

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

Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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

#58 lore raw

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

Quoted 34 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 3 lines

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.

Quoted 3 lines

YH

Gabriel

#59 lore raw

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

Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 5 lines
Quoted 3 lines

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

#60 lore raw

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

Quoted 61 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 4 lines
Quoted 3 lines

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 )

Quoted 8 lines

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 :/

#61 lore raw

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

Quoted 68 lines · Gabriel C
Quoted 66 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 4 lines
Quoted 3 lines

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 )

Quoted 7 lines
Quoted 3 lines

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

Quoted 7 lines
Quoted 7 lines

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

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[    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

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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

#62 lore raw

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

Quoted 70 lines · Yinghai Lu
Quoted 69 lines · Gabriel C
Quoted 68 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 4 lines
Quoted 3 lines

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 :)

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

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 =)

Quoted 23 lines

mtrr by BIOS is very interesting:
before

Quoted 7 lines
Quoted 7 lines

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

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[    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.

Quoted 8 lines

or we can dumping the

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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

#63 lore raw

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

Quoted 78 lines · Gabriel C
Quoted 76 lines · Yinghai Lu
Quoted 74 lines · Gabriel C
Quoted 61 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 4 lines
Quoted 3 lines

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 )

Quoted 8 lines

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 :

Quoted 41 lines
Quoted 2 lines

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 =)

Quoted 31 lines

mtrr by BIOS is very interesting:
before

Quoted 7 lines
Quoted 7 lines

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

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[    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

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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

[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

arch/x86/kernel/cpu/mtrr/generic.c +14 -0
Index: 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)
 {
arch/x86/kernel/cpu/mtrr/main.c +376 -5

429 lines not on this page · raw message

arch/x86/kernel/cpu/mtrr/mtrr.h +2 -0
Index: 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);
Documentation/kernel-parameters.txt +10 -0
Index: 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
arch/x86/Kconfig +26 -0
Index: 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"
#64 lore raw

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

Quoted 115 lines · Yinghai Lu
Quoted 114 lines · Gabriel C
Quoted 70 lines · Yinghai Lu
Quoted 69 lines · Gabriel C
Quoted 68 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 4 lines
Quoted 3 lines

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 :)

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

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 =)

Quoted 27 lines

mtrr by BIOS is very interesting:
before

Quoted 7 lines
Quoted 7 lines

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

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[    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

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB

for extra entra...

Quoted 7 lines
Quoted 4 lines
Quoted 4 lines

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/

Quoted 3 lines

YH

Gabriel

#65 lore raw

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

Quoted 122 lines · Gabriel C
Quoted 120 lines · Yinghai Lu
Quoted 118 lines · Gabriel C
Quoted 70 lines · Yinghai Lu
Quoted 69 lines · Gabriel C
Quoted 68 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Quoted 3 lines · Ingo Molnar

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?

Quoted 8 lines
Quoted 4 lines

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
Quoted 4 lines
Quoted 3 lines

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 :)

Quoted 8 lines
Quoted 5 lines
Quoted 1 line

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 =)

Quoted 31 lines

mtrr by BIOS is very interesting:
before

Quoted 7 lines
Quoted 7 lines

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

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[    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

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[    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

Quoted 6 lines
Quoted 2 lines

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

[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

arch/x86/kernel/cpu/mtrr/generic.c +14 -0
Index: 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)
 {
arch/x86/kernel/cpu/mtrr/main.c +385 -5

438 lines not on this page · raw message

arch/x86/kernel/cpu/mtrr/mtrr.h +2 -0
Index: 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);
Documentation/kernel-parameters.txt +10 -0
Index: 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
arch/x86/Kconfig +26 -0
Index: 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"
#66 lore raw

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

Quoted 7 lines · Yinghai Lu

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

#67 lore raw

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

Quoted 11 lines · Ingo Molnar
Quoted 7 lines · Yinghai Lu

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

Quoted 1 line

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

#68 lore raw

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

In reply to Gabriel C
Quoted 15 lines · Gabriel C
Quoted 5 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Ingo Molnar schrieb:

Quoted 8 lines
Quoted 3 lines

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.

Quoted 9 lines

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

#69 lore raw

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

Quoted 20 lines · Yinghai Lu
Quoted 19 lines · Gabriel C
Quoted 5 lines · Mika Fischer

Hi Ingo,

I'm having the same problem.

Ingo Molnar schrieb:

Quoted 8 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 2 lines

YH

Gabriel

#70 lore raw

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

In reply to Ingo Molnar
Quoted 4 lines · Ingo Molnar
Quoted 2 lines · Gabriel C
Quoted 2 lines

please try v2 version

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

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.

Quoted 4 lines

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.

Quoted 4 lines

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 ?

Quoted 3 lines

Ingo

Gabriel

#71 lore raw

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

In reply to Ingo Molnar
Quoted 3 lines · Ingo Molnar

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

#72 lore raw

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

Quoted 9 lines · Jesse Barnes
Quoted 3 lines · Ingo Molnar

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

#73 lore raw

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

Quoted 6 lines · Mika Fischer
Quoted 5 lines · Jesse Barnes
Quoted 3 lines · Ingo Molnar

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 ;-)

Quoted 7 lines
Quoted 4 lines

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

#74 lore raw

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

In reply to Jesse Barnes
Quoted 8 lines · Jesse Barnes
Quoted 3 lines

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: [email protected]
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).

---
 Documentation/filesystems/sysfs-pci.txt |    1 
 drivers/pci/pci-sysfs.c                 |   82 +++++++++++++++++++++++---------
 include/linux/pci.h                     |    1 
 3 files changed, 63 insertions(+), 21 deletions(-)
Documentation/filesystems/sysfs-pci.txt +1 -0
Index: 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)
drivers/pci/pci-sysfs.c +61 -21

121 lines not on this page · raw message

include/linux/pci.h +1 -0
Index: 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
#75 lore raw

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

drivers/pci/pci-sysfs.c pci_remove_resource_files(struct pci_dev · line 575

Quoted 8 lines · On Tue, 29 Apr 2008 12:37:41 +0200 Ingo Molnar <[email protected]> wrote:
drivers/pci/pci-sysfs.c +8 -0
+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.

Quoted 7 lines
drivers/pci/pci-sysfs.c +7 -0
+	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;

drivers/pci/pci-sysfs.c pci_remove_resource_files(struct pci_dev · line 592

Quoted 10 lines
drivers/pci/pci-sysfs.c +10 -0
+		} 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.

Quoted 5 lines
drivers/pci/pci-sysfs.c +5 -0
+	} else
+		retval = -ENOMEM;
+
+	return retval;
+}
Acked-by
#76 lore raw

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

In reply to Ingo Molnar
Quoted 21 lines · Ingo Molnar
Quoted 8 lines · Jesse Barnes
Quoted 3 lines

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: [email protected]
Date: Tue, 18 Mar 2008 17:00:22 -0700

Quoted 6 lines

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

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.

Thanks,
Jesse

#77 lore raw

PATCH 1/1 PCI: export resource_wc in pci sysfs

Quoted 6 lines · Jesse Barnes

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.

thanks! Linus, please apply the patch below.

Ingo

------------------>
Subject: PCI: export resource_wc in pci sysfs
From: [email protected]
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).

---
 Documentation/filesystems/sysfs-pci.txt |    1 
 drivers/pci/pci-sysfs.c                 |   82 +++++++++++++++++++++++---------
 include/linux/pci.h                     |    1 
 3 files changed, 63 insertions(+), 21 deletions(-)
Documentation/filesystems/sysfs-pci.txt +1 -0
Index: 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)
drivers/pci/pci-sysfs.c +61 -21

121 lines not on this page · raw message

include/linux/pci.h +1 -0
Index: 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
#78 lore raw

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

Quoted 20 lines · On Wed, 30 Apr 2008 00:03:46 +0200 Ingo Molnar <[email protected]> wrote:
drivers/pci/pci-sysfs.c +20 -0
+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;
+		}

drivers/pci/pci-sysfs.c pci_remove_resource_files(struct pci_dev · line 597

Quoted 10 lines
drivers/pci/pci-sysfs.c +10 -0
+		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.

#79 lore raw

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

In reply to Andrew Morton
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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

#80 lore raw

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

Quoted 7 lines · Yinghai Lu
Quoted 2 lines · Andrew Morton

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

#81 lore raw

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

In reply to Andrew Morton
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 9 lines

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

Quoted 2 lines

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

or

Quoted 4 lines

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

Quoted 1 line

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

or

Quoted 2 lines

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

#82 lore raw

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

Quoted 16 lines · Yinghai Lu
Quoted 8 lines

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

Quoted 2 lines

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

Quoted 8 lines

or

Quoted 4 lines

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

#83 lore raw

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

In reply to Andrew Morton
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> 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.

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:

Quoted 8 lines

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

Quoted 5 lines

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

#84 lore raw

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

Hi Yinghai,

Quoted 9 lines · Yinghai Lu
Quoted 8 lines

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.

Quoted 12 lines

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

Quoted 5 lines

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

#85 lore raw

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

Quoted 51 lines · Mika Fischer

Hi Yinghai,

Quoted 9 lines · Yinghai Lu
Quoted 8 lines

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.

Quoted 12 lines

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

Quoted 5 lines

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:

Quoted 8 lines

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

#86 lore raw

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

Quoted 8 lines · Yinghai Lu
Quoted 6 lines
Quoted 6 lines

you should get

Quoted 5 lines

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

Quoted 1 line

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

#87 lore raw

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

Quoted 34 lines · Mika Fischer
Quoted 8 lines · Yinghai Lu
Quoted 6 lines
Quoted 6 lines

you should get

Quoted 5 lines

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

Quoted 8 lines

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

Quoted 1 line

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.

Quoted 3 lines

Regards,
Mika

Gabriel

author
#88 lore raw

PATCH 1/1 x86_64: update e820 instead of updating end_pfn v3

In reply to a message not in the archive

[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

arch/x86/kernel/cpu/mtrr/main.c +18 -8
Index: 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
 
arch/x86/kernel/setup_64.c +5 -2
Index: 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;
 
include/asm-x86/mtrr.h +3 -2
Index: 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) {;}