Skip to contentSkip to conversation

trim memory not covered by WB MTRRs

PATCH NAK Jesse Barnes 8 participants 31 messages Jun 7, 2007 – Jun 25, 2007 Documentation

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 trim memory not covered by WB MTRRs

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

Documentation/kernel-parameters.txt +6 -0
index 5d0283c..cb728a8 100644
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in the file
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
+	disable_mtrr_trim [X86-64]
+			By default the kernel will trim any uncacheable
+			memory out of your available memory pool based on
+			MTRR settings.  This parameter disables that behavior,
+			possibly causing your machine to run very slowly.
+
 	dmascc=		[HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
 			support available.
 			Format: <io_dev0>[,<io_dev1>[,..<io_dev32>]]
arch/i386/kernel/cpu/mtrr/generic.c +1 -7
index c4ebb51..8eb3085 100644
@@ -13,7 +13,7 @@
 #include "mtrr.h"
 
 struct mtrr_state {
-	struct mtrr_var_range *var_ranges;
+	struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
 	mtrr_type fixed_ranges[NUM_FIXED_RANGES];
 	unsigned char enabled;
 	unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
 	struct mtrr_var_range *vrs;
 	unsigned lo, dummy;
 
-	if (!mtrr_state.var_ranges) {
-		mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct mtrr_var_range), 
-						GFP_KERNEL);
-		if (!mtrr_state.var_ranges)
-			return;
-	} 
 	vrs = mtrr_state.var_ranges;
 
 	rdmsr(MTRRcap_MSR, lo, dummy);
arch/i386/kernel/cpu/mtrr/if.c +0 -4
index c7d8f17..0e34a67 100644
@@ -11,10 +11,6 @@
 #include <asm/mtrr.h>
 #include "mtrr.h"
 
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
 #define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
 
 static const char *const mtrr_strings[MTRR_NUM_TYPES] =
arch/i386/kernel/cpu/mtrr/main.c +54 -14

109 lines not on this page · raw message

arch/i386/kernel/cpu/mtrr/mtrr.h +3 -0
index 289dfe6..627b339 100644
@@ -14,6 +14,7 @@
 #define MTRRphysMask_MSR(reg) (0x200 + 2 * (reg) + 1)
 
 #define NUM_FIXED_RANGES 88
+#define MAX_VAR_RANGES 256
 #define MTRRfix64K_00000_MSR 0x250
 #define MTRRfix16K_80000_MSR 0x258
 #define MTRRfix16K_A0000_MSR 0x259
@@ -34,6 +35,8 @@
    an 8 bit field: */
 typedef u8 mtrr_type;
 
+extern unsigned int usage_table[MAX_VAR_RANGES];
+
 struct mtrr_ops {
 	u32	vendor;
 	u32	use_intel_if;
arch/x86_64/kernel/bugs.c +0 -1
index c3c6b91..c138eac 100644
@@ -14,7 +14,6 @@
 void __init check_bugs(void)
 {
 	identify_cpu(&boot_cpu_data);
-	mtrr_bp_init();
 #if !defined(CONFIG_SMP)
 	printk("CPU: ");
 	print_cpu_info(&boot_cpu_data);
arch/x86_64/kernel/setup.c +4 -0
index eb6524f..409b63c 100644
@@ -266,6 +266,10 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
+	/* Trim memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	mtrr_trim_uncached_memory();
+
 	num_physpages = end_pfn;
 
 	check_efer();
include/asm-x86_64/mtrr.h +1 -0
index b557c48..cc62bd8 100644
@@ -78,6 +78,7 @@ extern int mtrr_add_page (unsigned long base, unsigned long size,
 		     unsigned int type, char increment);
 extern int mtrr_del (int reg, unsigned long base, unsigned long size);
 extern int mtrr_del_page (int reg, unsigned long base, unsigned long size);
+extern void mtrr_trim_uncached_memory(void);
 #  else
 static __inline__ int mtrr_add (unsigned long base, unsigned long size,
 				unsigned int type, char increment)
#1 lore raw

Will see if it still patches against -rc4.

Quoted 274 lines · Jesse Barnes

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

Documentation/kernel-parameters.txt +6 -0
index 5d0283c..cb728a8 100644
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in the file
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
+	disable_mtrr_trim [X86-64]
+			By default the kernel will trim any uncacheable
+			memory out of your available memory pool based on
+			MTRR settings.  This parameter disables that behavior,
+			possibly causing your machine to run very slowly.
+
 	dmascc=		[HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
 			support available.
 			Format: <io_dev0>[,<io_dev1>[,..<io_dev32>]]
arch/i386/kernel/cpu/mtrr/generic.c +1 -7
index c4ebb51..8eb3085 100644
@@ -13,7 +13,7 @@
 #include "mtrr.h"
 
 struct mtrr_state {
-	struct mtrr_var_range *var_ranges;
+	struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
 	mtrr_type fixed_ranges[NUM_FIXED_RANGES];
 	unsigned char enabled;
 	unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
 	struct mtrr_var_range *vrs;
 	unsigned lo, dummy;
 
-	if (!mtrr_state.var_ranges) {
-		mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct mtrr_var_range),
-						GFP_KERNEL);
-		if (!mtrr_state.var_ranges)
-			return;
-	}
 	vrs = mtrr_state.var_ranges;
 
 	rdmsr(MTRRcap_MSR, lo, dummy);
arch/i386/kernel/cpu/mtrr/if.c +0 -4
index c7d8f17..0e34a67 100644
@@ -11,10 +11,6 @@
 #include <asm/mtrr.h>
 #include "mtrr.h"
 
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
 #define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
 

static const char *const mtrr_strings[MTRR_NUM_TYPES] =

arch/i386/kernel/cpu/mtrr/main.c +54 -14
index 7202b98..ef552ba 100644
@@ -38,8 +38,8 @@
 #include <linux/cpu.h>
 #include <linux/mutex.h>
 
+#include <asm/e820.h>
 #include <asm/mtrr.h>
-
 #include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/msr.h>
@@ -47,7 +47,7 @@
 
 u32 num_var_ranges = 0;
 
-unsigned int *usage_table;
+unsigned int usage_table[MAX_VAR_RANGES];
 static DEFINE_MUTEX(mtrr_mutex);
 
 u64 size_or_mask, size_and_mask;
@@ -121,11 +121,6 @@ static void __init init_table(void)
 	int i, max;
 
 	max = num_var_ranges;
-	if ((usage_table = kmalloc(max * sizeof *usage_table, GFP_KERNEL))
-	    == NULL) {
-		printk(KERN_ERR "mtrr: could not allocate\n");
-		return;
-	}
 	for (i = 0; i < max; i++)
 		usage_table[i] = 1;
 }
@@ -589,16 +584,11 @@ struct mtrr_value {
 	unsigned long	lsize;
 };
 
-static struct mtrr_value * mtrr_state;
+static struct mtrr_value mtrr_state[MAX_VAR_RANGES];
 
 static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
 {
 	int i;
-	int size = num_var_ranges * sizeof(struct mtrr_value);
-
-	mtrr_state = kzalloc(size,GFP_ATOMIC);
-	if (!mtrr_state)
-		return -ENOMEM;
 
 	for (i = 0; i < num_var_ranges; i++) {
 		mtrr_if->get(i,
@@ -620,7 +610,6 @@ static int mtrr_restore(struct sys_device * sysdev)
 				 mtrr_state[i].lsize,
 				 mtrr_state[i].ltype);
 	}
-	kfree(mtrr_state);
 	return 0;
 }
 
@@ -631,6 +620,57 @@ static struct sysdev_driver mtrr_sysdev_driver = {
 	.resume		= mtrr_restore,
 };
 
+static int disable_mtrr_trim;
+
+static int __init disable_mtrr_trim_setup(char *str)
+{
+	disable_mtrr_trim = 1;
+	return 0;
+}
+early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
+
+/**
+ * mtrr_trim_uncached_memory - trim RAM not covered by MTRRs
+ *
+ * Some buggy BIOSes don't setup the MTRRs properly for systems with certain
+ * memory configurations.  This routine checks to make sure the MTRRs having
+ * a write back type cover all of the memory the kernel is intending to use.
+ * If not, it'll trim any 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)
+{
+	unsigned long i, base, size, highest_addr = 0, def, dummy;
+	mtrr_type type;
+
+	/* Make sure we only trim uncachable memory on Intel machines */
+	rdmsr(MTRRdefType_MSR, def, dummy);
+	def &= 0xff;
+	if (!use_intel() || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE)
+		return;
+
+	/* Find highest cached pfn */
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type != MTRR_TYPE_WRBACK)
+			continue;
+		base <<= PAGE_SHIFT;
+		size <<= PAGE_SHIFT;
+		if (highest_addr < base + size)
+			highest_addr = base + size;
+	}
+
+	if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+		printk(KERN_WARNING "***************\n");
+		printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+		printk(KERN_WARNING "**** MTRRs don't cover all of "
+		       "memory, trimmed %ld pages\n", end_pfn -
+		       (highest_addr >> PAGE_SHIFT));
+		printk(KERN_WARNING "***************\n");
+		end_pfn = highest_addr >> PAGE_SHIFT;
+	}
+}
 
 /**
 * mtrr_bp_init - initialize mtrrs on the boot CPU
arch/i386/kernel/cpu/mtrr/mtrr.h +3 -0
index 289dfe6..627b339 100644
@@ -14,6 +14,7 @@
 #define MTRRphysMask_MSR(reg) (0x200 + 2 * (reg) + 1)
 
 #define NUM_FIXED_RANGES 88
+#define MAX_VAR_RANGES 256
 #define MTRRfix64K_00000_MSR 0x250
 #define MTRRfix16K_80000_MSR 0x258
 #define MTRRfix16K_A0000_MSR 0x259
@@ -34,6 +35,8 @@
   an 8 bit field: */
 typedef u8 mtrr_type;
 
+extern unsigned int usage_table[MAX_VAR_RANGES];
+
 struct mtrr_ops {
 	u32	vendor;
 	u32	use_intel_if;
arch/x86_64/kernel/bugs.c +0 -1
index c3c6b91..c138eac 100644
@@ -14,7 +14,6 @@
 void __init check_bugs(void)
 {
 	identify_cpu(&boot_cpu_data);
-	mtrr_bp_init();
 #if !defined(CONFIG_SMP)
 	printk("CPU: ");
 	print_cpu_info(&boot_cpu_data);
arch/x86_64/kernel/setup.c +4 -0
index eb6524f..409b63c 100644
@@ -266,6 +266,10 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
+	/* Trim memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	mtrr_trim_uncached_memory();
+
 	num_physpages = end_pfn;
 
 	check_efer();
include/asm-x86_64/mtrr.h +1 -0
index b557c48..cc62bd8 100644
@@ -78,6 +78,7 @@ extern int mtrr_add_page (unsigned long base, unsigned long size,
 		     unsigned int type, char increment);
 extern int mtrr_del (int reg, unsigned long base, unsigned long size);
 extern int mtrr_del_page (int reg, unsigned long base, unsigned long size);
+extern void mtrr_trim_uncached_memory(void);
 #  else
 static __inline__ int mtrr_add (unsigned long base, unsigned long size,
 				unsigned int type, char increment)
#2 lore raw
In reply to Jesse Barnes
p34:/usr/src/linux# patch -p1 < ../mtrr-v2.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
patching file arch/i386/kernel/cpu/mtrr/mtrr.h
patching file arch/x86_64/kernel/bugs.c
patching file arch/x86_64/kernel/setup.c
patching file include/asm-x86_64/mtrr.h
p34:/usr/src/linux#

Applies clean to 2.6.22-rc4, verifying shortly.

Quoted 274 lines · Jesse Barnes

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

Documentation/kernel-parameters.txt +6 -0
index 5d0283c..cb728a8 100644
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in the file
 			See drivers/char/README.epca and
 			Documentation/digiepca.txt.
 
+	disable_mtrr_trim [X86-64]
+			By default the kernel will trim any uncacheable
+			memory out of your available memory pool based on
+			MTRR settings.  This parameter disables that behavior,
+			possibly causing your machine to run very slowly.
+
 	dmascc=		[HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
 			support available.
 			Format: <io_dev0>[,<io_dev1>[,..<io_dev32>]]
arch/i386/kernel/cpu/mtrr/generic.c +1 -7
index c4ebb51..8eb3085 100644
@@ -13,7 +13,7 @@
 #include "mtrr.h"
 
 struct mtrr_state {
-	struct mtrr_var_range *var_ranges;
+	struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
 	mtrr_type fixed_ranges[NUM_FIXED_RANGES];
 	unsigned char enabled;
 	unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
 	struct mtrr_var_range *vrs;
 	unsigned lo, dummy;
 
-	if (!mtrr_state.var_ranges) {
-		mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct mtrr_var_range),
-						GFP_KERNEL);
-		if (!mtrr_state.var_ranges)
-			return;
-	}
 	vrs = mtrr_state.var_ranges;
 
 	rdmsr(MTRRcap_MSR, lo, dummy);
arch/i386/kernel/cpu/mtrr/if.c +0 -4
index c7d8f17..0e34a67 100644
@@ -11,10 +11,6 @@
 #include <asm/mtrr.h>
 #include "mtrr.h"
 
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
 #define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
 

static const char *const mtrr_strings[MTRR_NUM_TYPES] =

arch/i386/kernel/cpu/mtrr/main.c +54 -14
index 7202b98..ef552ba 100644
@@ -38,8 +38,8 @@
 #include <linux/cpu.h>
 #include <linux/mutex.h>
 
+#include <asm/e820.h>
 #include <asm/mtrr.h>
-
 #include <asm/uaccess.h>
 #include <asm/processor.h>
 #include <asm/msr.h>
@@ -47,7 +47,7 @@
 
 u32 num_var_ranges = 0;
 
-unsigned int *usage_table;
+unsigned int usage_table[MAX_VAR_RANGES];
 static DEFINE_MUTEX(mtrr_mutex);
 
 u64 size_or_mask, size_and_mask;
@@ -121,11 +121,6 @@ static void __init init_table(void)
 	int i, max;
 
 	max = num_var_ranges;
-	if ((usage_table = kmalloc(max * sizeof *usage_table, GFP_KERNEL))
-	    == NULL) {
-		printk(KERN_ERR "mtrr: could not allocate\n");
-		return;
-	}
 	for (i = 0; i < max; i++)
 		usage_table[i] = 1;
 }
@@ -589,16 +584,11 @@ struct mtrr_value {
 	unsigned long	lsize;
 };
 
-static struct mtrr_value * mtrr_state;
+static struct mtrr_value mtrr_state[MAX_VAR_RANGES];
 
 static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
 {
 	int i;
-	int size = num_var_ranges * sizeof(struct mtrr_value);
-
-	mtrr_state = kzalloc(size,GFP_ATOMIC);
-	if (!mtrr_state)
-		return -ENOMEM;
 
 	for (i = 0; i < num_var_ranges; i++) {
 		mtrr_if->get(i,
@@ -620,7 +610,6 @@ static int mtrr_restore(struct sys_device * sysdev)
 				 mtrr_state[i].lsize,
 				 mtrr_state[i].ltype);
 	}
-	kfree(mtrr_state);
 	return 0;
 }
 
@@ -631,6 +620,57 @@ static struct sysdev_driver mtrr_sysdev_driver = {
 	.resume		= mtrr_restore,
 };
 
+static int disable_mtrr_trim;
+
+static int __init disable_mtrr_trim_setup(char *str)
+{
+	disable_mtrr_trim = 1;
+	return 0;
+}
+early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
+
+/**
+ * mtrr_trim_uncached_memory - trim RAM not covered by MTRRs
+ *
+ * Some buggy BIOSes don't setup the MTRRs properly for systems with certain
+ * memory configurations.  This routine checks to make sure the MTRRs having
+ * a write back type cover all of the memory the kernel is intending to use.
+ * If not, it'll trim any 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)
+{
+	unsigned long i, base, size, highest_addr = 0, def, dummy;
+	mtrr_type type;
+
+	/* Make sure we only trim uncachable memory on Intel machines */
+	rdmsr(MTRRdefType_MSR, def, dummy);
+	def &= 0xff;
+	if (!use_intel() || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE)
+		return;
+
+	/* Find highest cached pfn */
+	for (i = 0; i < num_var_ranges; i++) {
+		mtrr_if->get(i, &base, &size, &type);
+		if (type != MTRR_TYPE_WRBACK)
+			continue;
+		base <<= PAGE_SHIFT;
+		size <<= PAGE_SHIFT;
+		if (highest_addr < base + size)
+			highest_addr = base + size;
+	}
+
+	if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+		printk(KERN_WARNING "***************\n");
+		printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+		printk(KERN_WARNING "**** MTRRs don't cover all of "
+		       "memory, trimmed %ld pages\n", end_pfn -
+		       (highest_addr >> PAGE_SHIFT));
+		printk(KERN_WARNING "***************\n");
+		end_pfn = highest_addr >> PAGE_SHIFT;
+	}
+}
 
 /**
 * mtrr_bp_init - initialize mtrrs on the boot CPU
arch/i386/kernel/cpu/mtrr/mtrr.h +3 -0
index 289dfe6..627b339 100644
@@ -14,6 +14,7 @@
 #define MTRRphysMask_MSR(reg) (0x200 + 2 * (reg) + 1)
 
 #define NUM_FIXED_RANGES 88
+#define MAX_VAR_RANGES 256
 #define MTRRfix64K_00000_MSR 0x250
 #define MTRRfix16K_80000_MSR 0x258
 #define MTRRfix16K_A0000_MSR 0x259
@@ -34,6 +35,8 @@
   an 8 bit field: */
 typedef u8 mtrr_type;
 
+extern unsigned int usage_table[MAX_VAR_RANGES];
+
 struct mtrr_ops {
 	u32	vendor;
 	u32	use_intel_if;
arch/x86_64/kernel/bugs.c +0 -1
index c3c6b91..c138eac 100644
@@ -14,7 +14,6 @@
 void __init check_bugs(void)
 {
 	identify_cpu(&boot_cpu_data);
-	mtrr_bp_init();
 #if !defined(CONFIG_SMP)
 	printk("CPU: ");
 	print_cpu_info(&boot_cpu_data);
arch/x86_64/kernel/setup.c +4 -0
index eb6524f..409b63c 100644
@@ -266,6 +266,10 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
+	/* Trim memory not covered by WB MTRRs */
+	mtrr_bp_init();
+	mtrr_trim_uncached_memory();
+
 	num_physpages = end_pfn;
 
 	check_efer();
include/asm-x86_64/mtrr.h +1 -0
index b557c48..cc62bd8 100644
@@ -78,6 +78,7 @@ extern int mtrr_add_page (unsigned long base, unsigned long size,
 		     unsigned int type, char increment);
 extern int mtrr_del (int reg, unsigned long base, unsigned long size);
 extern int mtrr_del_page (int reg, unsigned long base, unsigned long size);
+extern void mtrr_trim_uncached_memory(void);
 #  else
 static __inline__ int mtrr_add (unsigned long base, unsigned long size,
 				unsigned int type, char increment)
#3 lore raw
In reply to Jesse Barnes
Quoted 28 lines · Jesse Barnes

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Quoted 8 lines

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

v1 of your patch:

top - 18:53:46 up 1 day, 1 min, 27 users, load average: 2.82, 1.11, 0.90
Tasks: 356 total, 7 running, 348 sleeping, 1 stopped, 0 zombie
Cpu(s): 2.2%us, 0.4%sy, 0.0%ni, 97.0%id, 0.1%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 8039576k total, 7962376k used, 77200k free, 716k buffers
Swap: 16787768k total, 128k used, 16787640k free, 6713332k cached

v2 of your patch: (dmesg also attached)

top - 18:58:59 up 2 min, 4 users, load average: 0.12, 0.13, 0.05
Tasks: 155 total, 1 running, 154 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.0%us, 1.1%sy, 0.5%ni, 94.8%id, 1.5%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8039576k total, 982192k used, 7057384k free, 1876k buffers
Swap: 16787768k total, 0k used, 16787768k free, 114492k cached

If the box has no issues over the next 8 hours with me pounding it with backups, bzip2s etc I'll consider it good, so far it boots fine etc, no issues, but I'll let it cook for a bit. Will update tomorrow.

Thanks,

Justin.

[    0.000000] Linux version 2.6.22-rc4 ([email protected]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #4 SMP Thu Jun 7 18:54:18 EDT 2007
[    0.000000] Command line: auto BOOT_IMAGE=2.6.22-rc4-4 ro root=902 [email protected]/eth0,[email protected]/00:50:8D:ED:3C:E7
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[    0.000000]  BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cf58f000 (usable)
[    0.000000]  BIOS-e820: 00000000cf58f000 - 00000000cf59c000 (reserved)
[    0.000000]  BIOS-e820: 00000000cf59c000 - 00000000cf653000 (usable)
[    0.000000]  BIOS-e820: 00000000cf653000 - 00000000cf6a5000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cf6a5000 - 00000000cf6a8000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cf6a8000 - 00000000cf6ef000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cf6ef000 - 00000000cf6f1000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cf6f1000 - 00000000cf6f2000 (usable)
[    0.000000]  BIOS-e820: 00000000cf6f2000 - 00000000cf6ff000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
[    0.000000]  BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 000000022c000000 (usable)
[    0.000000] Entering add_active_range(0, 0, 143) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 849295) 1 entries of 256 used
[    0.000000] Entering add_active_range(0, 849308, 849491) 2 entries of 256 used
[    0.000000] Entering add_active_range(0, 849649, 849650) 3 entries of 256 used
[    0.000000] Entering add_active_range(0, 849663, 849664) 4 entries of 256 used
[    0.000000] Entering add_active_range(0, 1048576, 2277376) 5 entries of 256 used
[    0.000000] end_pfn_map = 2277376
[    0.000000] ***************
[    0.000000] **** WARNING: likely BIOS bug
[    0.000000] **** MTRRs don't cover all of memory, trimmed 16384 pages
[    0.000000] ***************
[    0.000000] DMI 2.4 present.
[    0.000000] ACPI: RSDP 000FE020, 0014 (r0 INTEL )
[    0.000000] ACPI: RSDT CF6FD038, 0050 (r1 INTEL  DG965WH       64C       1000013)
[    0.000000] ACPI: FACP CF6FC000, 0074 (r1 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: DSDT CF6F7000, 40E9 (r1 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: FACS CF6A8000, 0040
[    0.000000] ACPI: APIC CF6F6000, 0078 (r1 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: WDDT CF6F5000, 0040 (r1 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: MCFG CF6F4000, 003C (r1 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: ASF! CF6F3000, 00A6 (r32 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: HPET CF6F2000, 0038 (r1 INTEL  DG965WH       64C MSFT  1000013)
[    0.000000] ACPI: SSDT CF6F0000, 01BC (r1 INTEL     CpuPm      64C MSFT  1000013)
[    0.000000] ACPI: SSDT CF6EF000, 0175 (r1 INTEL   Cpu0Ist      64C MSFT  1000013)
[    0.000000] ACPI: SSDT CF6A7000, 0175 (r1 INTEL   Cpu1Ist      64C MSFT  1000013)
[    0.000000] ACPI: SSDT CF6A6000, 0175 (r1 INTEL   Cpu2Ist      64C MSFT  1000013)
[    0.000000] ACPI: SSDT CF6A5000, 0175 (r1 INTEL   Cpu3Ist      64C MSFT  1000013)
[    0.000000] Entering add_active_range(0, 0, 143) 0 entries of 256 used
[    0.000000] Entering add_active_range(0, 256, 849295) 1 entries of 256 used
[    0.000000] Entering add_active_range(0, 849308, 849491) 2 entries of 256 used
[    0.000000] Entering add_active_range(0, 849649, 849650) 3 entries of 256 used
[    0.000000] Entering add_active_range(0, 849663, 849664) 4 entries of 256 used
[    0.000000] Entering add_active_range(0, 1048576, 2260992) 5 entries of 256 used
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   DMA32        4096 ->  1048576
[    0.000000]   Normal    1048576 ->  2260992
[    0.000000] early_node_map[6] active PFN ranges
[    0.000000]     0:        0 ->      143
[    0.000000]     0:      256 ->   849295
[    0.000000]     0:   849308 ->   849491
[    0.000000]     0:   849649 ->   849650
[    0.000000]     0:   849663 ->   849664
[    0.000000]     0:  1048576 ->  2260992
[    0.000000] On node 0 totalpages: 2061783
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 1395 pages reserved
[    0.000000]   DMA zone: 2532 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 14280 pages used for memmap
[    0.000000]   DMA32 zone: 831104 pages, LIFO batch:31
[    0.000000]   Normal zone: 16576 pages used for memmap
[    0.000000]   Normal zone: 1195840 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x408
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] Processor #0 (Bootup-CPU)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] Processor #2
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] Processor #1
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] Processor #3
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Setting APIC routing to flat
[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] Allocating PCI resources starting at d4000000 (gap: d0000000:2ff00000)
[    0.000000] PERCPU: Allocating 24744 bytes of per cpu data
[    0.000000] Built 1 zonelists.  Total pages: 2029476
[    0.000000] Kernel command line: auto BOOT_IMAGE=2.6.22-rc4-4 ro root=902 [email protected]/eth0,[email protected]/00:50:8D:ED:3C:E7
[    0.000000] netconsole: local port 4444
[    0.000000] netconsole: local IP 192.168.168.253
[    0.000000] netconsole: interface eth0
[    0.000000] netconsole: remote port 514
[    0.000000] netconsole: remote IP 192.168.168.254
[    0.000000] netconsole: remote ethernet address 00:50:8d:ed:3c:e7
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[   48.130591] time.c: Detected 2397.606 MHz processor.
[   48.131666] Console: colour VGA+ 80x25
[   48.139532] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[   48.145756] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   48.146855] Checking aperture...
[   48.146909] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[   48.186683] Placing software IO TLB between 0x951a000 - 0xd51a000
[   48.256438] Memory: 8039012k/9043968k available (3549k kernel code, 207808k reserved, 1317k data, 216k init)
[   48.315841] Calibrating delay using timer specific routine.. 4797.71 BogoMIPS (lpj=2398858)
[   48.315963] Mount-cache hash table entries: 256
[   48.316090] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.316152] CPU: L2 cache: 4096K
[   48.316192] using mwait in idle threads.
[   48.316234] CPU: Physical Processor ID: 0
[   48.316275] CPU: Processor Core ID: 0
[   48.316320] CPU0: Thermal monitoring enabled (TM2)
[   48.316367] Freeing SMP alternatives: 33k freed
[   48.316433] ACPI: Core revision 20070126
[   48.329824] Using local APIC timer interrupts.
[   48.371568] result 16650025
[   48.371607] Detected 16.650 MHz APIC timer.
[   48.371903] Booting processor 1/4 APIC 0x2
[   48.382292] Initializing CPU#1
[   48.442807] Calibrating delay using timer specific routine.. 4795.14 BogoMIPS (lpj=2397570)
[   48.442814] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.442816] CPU: L2 cache: 4096K
[   48.442818] CPU: Physical Processor ID: 0
[   48.442819] CPU: Processor Core ID: 2
[   48.442824] CPU1: Thermal monitoring enabled (TM2)
[   48.443247] Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz stepping 07
[   48.443310] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[   48.463868] Booting processor 2/4 APIC 0x1
[   48.474628] Initializing CPU#2
[   48.534787] Calibrating delay using timer specific routine.. 4795.30 BogoMIPS (lpj=2397650)
[   48.534793] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.534794] CPU: L2 cache: 4096K
[   48.534796] CPU: Physical Processor ID: 0
[   48.534797] CPU: Processor Core ID: 1
[   48.534802] CPU2: Thermal monitoring enabled (TM2)
[   48.535246] Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz stepping 07
[   48.535273] checking TSC synchronization [CPU#0 -> CPU#2]: passed.
[   48.555867] Booting processor 3/4 APIC 0x3
[   48.566258] Initializing CPU#3
[   48.626765] Calibrating delay using timer specific routine.. 4795.21 BogoMIPS (lpj=2397608)
[   48.626771] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.626773] CPU: L2 cache: 4096K
[   48.626775] CPU: Physical Processor ID: 0
[   48.626776] CPU: Processor Core ID: 3
[   48.626782] CPU3: Thermal monitoring enabled (TM2)
[   48.627204] Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz stepping 07
[   48.627274] checking TSC synchronization [CPU#0 -> CPU#3]: passed.
[   48.647766] Brought up 4 CPUs
[   49.290497] migration_cost=26,3427
[   49.290867] NET: Registered protocol family 16
[   49.290968] ACPI: bus type pci registered
[   49.291017] PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
[   49.291064] PCI: Not using MMCONFIG.
[   49.291105] PCI: Using configuration type 1
[   49.293817] ACPI: Interpreter enabled
[   49.293859] ACPI: Using IOAPIC for interrupt routing
[   49.297371] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   49.297430] PCI: Probing PCI hardware (bus 00)
[   49.298083] PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
[   49.298132] PCI quirk: region 0500-053f claimed by ICH6 GPIO
[   49.299041] PCI: Transparent bridge - 0000:00:1e.0
[   49.299139] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   49.299405] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT]
[   49.299607] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[   49.299689] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT]
[   49.299768] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
[   49.299848] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
[   49.299927] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[   49.303177] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12)
[   49.303465] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12)
[   49.303754] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12)
[   49.304060] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12)
[   49.304364] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 *9 10 11 12)
[   49.304653] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12)
[   49.304938] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12)
[   49.305263] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 10 *11 12)
[   49.305553] Linux Plug and Play Support v0.97 (c) Adam Belay
[   49.305604] pnp: PnP ACPI init
[   49.305650] ACPI: bus type pnp registered
[   49.307458] pnp: PnP ACPI: found 12 devices
[   49.307500] ACPI: ACPI bus type pnp unregistered
[   49.307664] SCSI subsystem initialized
[   49.307760] libata version 2.21 loaded.
[   49.307814] usbcore: registered new interface driver usbfs
[   49.307881] usbcore: registered new interface driver hub
[   49.307950] usbcore: registered new device driver usb
[   49.308022] PCI: Using ACPI for IRQ routing
[   49.308064] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   49.308236] PCI-GART: No AMD northbridge found.
[   49.308281] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[   49.308415] hpet0: 3 64-bit timers, 14318180 Hz
[   49.309523] pnp: 00:01: iomem range 0xf0000000-0xf7ffffff has been reserved
[   49.309573] pnp: 00:01: iomem range 0xfed13000-0xfed13fff has been reserved
[   49.309622] Time: tsc clocksource has been installed.
[   49.309667] pnp: 00:01: iomem range 0xfed14000-0xfed17fff has been reserved
[   49.309715] pnp: 00:01: iomem range 0xfed18000-0xfed18fff has been reserved
[   49.309768] pnp: 00:06: ioport range 0x500-0x53f has been reserved
[   49.309814] pnp: 00:06: ioport range 0x400-0x47f has been reserved
[   49.310422] pnp: 00:06: ioport range 0x680-0x6ff has been reserved
[   49.310738] ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 19
[   49.360956] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0084000-e00847ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[   49.361085] PCI: Bridge: 0000:00:1c.0
[   49.361125]   IO window: disabled.
[   49.361168]   MEM window: e0700000-e07fffff
[   49.361211]   PREFETCH window: disabled.
[   49.361275] PCI: Bridge: 0000:00:1c.1
[   49.361317]   IO window: 5000-5fff
[   49.361359]   MEM window: e0400000-e04fffff
[   49.361413]   PREFETCH window: disabled.
[   49.361466] PCI: Bridge: 0000:00:1c.2
[   49.361508]   IO window: 4000-4fff
[   49.361552]   MEM window: e0300000-e03fffff
[   49.361597]   PREFETCH window: e0800000-e08fffff
[   49.361643] PCI: Bridge: 0000:00:1c.3
[   49.361684]   IO window: 3000-3fff
[   49.361726]   MEM window: e0200000-e02fffff
[   49.361770]   PREFETCH window: e0900000-e09fffff
[   49.361815] PCI: Bridge: 0000:00:1c.4
[   49.361857]   IO window: 2000-2fff
[   49.361899]   MEM window: e0100000-e01fffff
[   49.361943]   PREFETCH window: e0a00000-e0afffff
[   49.361988] PCI: Bridge: 0000:00:1e.0
[   49.362030]   IO window: 1000-1fff
[   49.362072]   MEM window: e0000000-e00fffff
[   49.362116]   PREFETCH window: e0b00000-e0bfffff
[   49.362172] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
[   49.362256] PCI: Setting latency timer of device 0000:00:1c.0 to 64
[   49.362280] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16
[   49.362373] PCI: Setting latency timer of device 0000:00:1c.1 to 64
[   49.362386] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
[   49.362490] PCI: Setting latency timer of device 0000:00:1c.2 to 64
[   49.362502] ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
[   49.362586] PCI: Setting latency timer of device 0000:00:1c.3 to 64
[   49.362600] ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17
[   49.362683] PCI: Setting latency timer of device 0000:00:1c.4 to 64
[   49.362691] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[   49.362739] NET: Registered protocol family 2
[   49.371587] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   49.372107] TCP established hash table entries: 131072 (order: 9, 3145728 bytes)
[   49.373400] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[   49.373900] TCP: Hash tables configured (established 131072 bind 65536)
[   49.373948] TCP reno registered
[   49.377996] Installing knfsd (copyright (C) 1996 [email protected]).
[   49.378132] SGI XFS with large block/inode numbers, no debug enabled
[   49.378483] io scheduler noop registered
[   49.378525] io scheduler anticipatory registered (default)
[   49.378575] Boot video device is 0000:00:02.0
[   49.379026] PCI: Setting latency timer of device 0000:00:1c.0 to 64
[   49.379058] assign_interrupt_mode Found MSI capability
[   49.379129] Allocate Port Service[0000:00:1c.0:pcie00]
[   49.379177] Allocate Port Service[0000:00:1c.0:pcie02]
[   49.379263] PCI: Setting latency timer of device 0000:00:1c.1 to 64
[   49.379294] assign_interrupt_mode Found MSI capability
[   49.379362] Allocate Port Service[0000:00:1c.1:pcie00]
[   49.379410] Allocate Port Service[0000:00:1c.1:pcie02]
[   49.379494] PCI: Setting latency timer of device 0000:00:1c.2 to 64
[   49.379525] assign_interrupt_mode Found MSI capability
[   49.379603] Allocate Port Service[0000:00:1c.2:pcie00]
[   49.379638] Allocate Port Service[0000:00:1c.2:pcie02]
[   49.379725] PCI: Setting latency timer of device 0000:00:1c.3 to 64
[   49.379763] assign_interrupt_mode Found MSI capability
[   49.379838] Allocate Port Service[0000:00:1c.3:pcie00]
[   49.379873] Allocate Port Service[0000:00:1c.3:pcie02]
[   49.379960] PCI: Setting latency timer of device 0000:00:1c.4 to 64
[   49.379996] assign_interrupt_mode Found MSI capability
[   49.380073] Allocate Port Service[0000:00:1c.4:pcie00]
[   49.380133] Allocate Port Service[0000:00:1c.4:pcie02]
[   49.382757] lp: driver loaded but no devices found
[   49.382849] Real Time Clock Driver v1.12ac
[   49.383002] hpet_resources: 0xfed00000 is busy
[   49.383012] Linux agpgart interface v0.102 (c) Dave Jones
[   49.383135] agpgart: Detected an Intel 965G Chipset.
[   49.384311] agpgart: Detected 7676K stolen memory.
[   49.396970] agpgart: AGP aperture is 256M @ 0xd0000000
[   49.397047] [drm] Initialized drm 1.1.0 20060810
[   49.397105] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
[   49.397255] [drm] Initialized i915 1.6.0 20060119 on minor 0
[   49.397396] parport_pc 00:07: reported by Plug and Play ACPI
[   49.397520] parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
[   49.479882] lp0: using parport0 (interrupt-driven).
[   49.480096] loop: module loaded
[   49.480139] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
[   49.480188] Copyright (c) 1999-2006 Intel Corporation.
[   49.480275] ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20
[   49.480369] PCI: Setting latency timer of device 0000:00:19.0 to 64
[   49.497933] e1000: 0000:00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:19:d1:6e:9d:43
[   49.573213] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[   49.573300] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 21 (level, low) -> IRQ 21
[   49.834558] e1000: 0000:06:00.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:00:cd:b1
[   49.981554] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
[   49.981615] ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 22 (level, low) -> IRQ 22
[   50.228621] e1000: 0000:06:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:07:e9:29:37:db
[   50.255346] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
[   50.255480] netconsole: device eth0 not up yet, forcing it
[   50.617119] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0090270001c5be9f]
[   52.334278] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[   52.358716] netconsole: network logging started
[   52.358929] ahci 0000:00:1f.2: version 2.2
[   52.358946] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
[   53.359807] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[   53.359880] ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part 
[   53.359936] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[   53.360168] scsi0 : ahci
[   53.360286] scsi1 : ahci
[   53.360386] scsi2 : ahci
[   53.360487] scsi3 : ahci
[   53.360585] scsi4 : ahci
[   53.360700] scsi5 : ahci
[   53.360795] ata1: SATA max UDMA/133 cmd 0xffffc2000002e100 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.360874] ata2: SATA max UDMA/133 cmd 0xffffc2000002e180 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.360952] ata3: SATA max UDMA/133 cmd 0xffffc2000002e200 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.361030] ata4: SATA max UDMA/133 cmd 0xffffc2000002e280 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.361108] ata5: SATA max UDMA/133 cmd 0xffffc2000002e300 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.361205] ata6: SATA max UDMA/133 cmd 0xffffc2000002e380 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.820558] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   53.823973] ata1.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   53.824043] ata1.00: ATA-6: WDC WD740GD-00FLC0, 33.08F33, max UDMA/133
[   53.824098] ata1.00: 145226112 sectors, multi 0: LBA48 
[   53.828532] ata1.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   53.828605] ata1.00: configured for UDMA/133
[   54.286854] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   54.290267] ata2.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   54.290337] ata2.00: ATA-6: WDC WD740GD-00FLC0, 33.08F33, max UDMA/133
[   54.290391] ata2.00: 145226112 sectors, multi 0: LBA48 
[   54.294838] ata2.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   54.294909] ata2.00: configured for UDMA/133
[   54.755252] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   54.757454] ata3.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   54.757534] ata3.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   54.757606] ata3.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   54.760453] ata3.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   54.760525] ata3.00: configured for UDMA/133
[   55.219479] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   55.221656] ata4.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.221727] ata4.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   55.221783] ata4.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   55.224617] ata4.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.224689] ata4.00: configured for UDMA/133
[   55.682687] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   55.684748] ata5.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.684819] ata5.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   55.684874] ata5.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   55.687539] ata5.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.687611] ata5.00: configured for UDMA/133
[   56.146925] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   56.148986] ata6.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.149058] ata6.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   56.149113] ata6.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   56.151795] ata6.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.151867] ata6.00: configured for UDMA/133
[   56.151994] scsi 0:0:0:0: Direct-Access     ATA      WDC WD740GD-00FL 33.0 PQ: 0 ANSI: 5
[   56.152166] sd 0:0:0:0: [sda] 145226112 512-byte hardware sectors (74356 MB)
[   56.152223] sd 0:0:0:0: [sda] Write Protect is off
[   56.152279] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   56.152290] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.152401] sd 0:0:0:0: [sda] 145226112 512-byte hardware sectors (74356 MB)
[   56.152468] sd 0:0:0:0: [sda] Write Protect is off
[   56.152524] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   56.152534] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.152616]  sda: sda1 sda2 sda3
[   56.163015] sd 0:0:0:0: [sda] Attached SCSI disk
[   56.163184] scsi 1:0:0:0: Direct-Access     ATA      WDC WD740GD-00FL 33.0 PQ: 0 ANSI: 5
[   56.163310] sd 1:0:0:0: [sdb] 145226112 512-byte hardware sectors (74356 MB)
[   56.163367] sd 1:0:0:0: [sdb] Write Protect is off
[   56.163414] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[   56.163425] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.163531] sd 1:0:0:0: [sdb] 145226112 512-byte hardware sectors (74356 MB)
[   56.163596] sd 1:0:0:0: [sdb] Write Protect is off
[   56.163643] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[   56.163656] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.163744]  sdb: sdb1 sdb2 sdb3
[   56.167415] sd 1:0:0:0: [sdb] Attached SCSI disk
[   56.167520] scsi 2:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.167651] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
[   56.167713] sd 2:0:0:0: [sdc] Write Protect is off
[   56.167760] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[   56.167770] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.167880] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
[   56.167938] sd 2:0:0:0: [sdc] Write Protect is off
[   56.167985] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[   56.167995] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.168068]  sdc: sdc1
[   56.173303] sd 2:0:0:0: [sdc] Attached SCSI disk
[   56.173408] scsi 3:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.173528] sd 3:0:0:0: [sdd] 293046768 512-byte hardware sectors (150040 MB)
[   56.173583] sd 3:0:0:0: [sdd] Write Protect is off
[   56.173630] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[   56.173640] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.173734] sd 3:0:0:0: [sdd] 293046768 512-byte hardware sectors (150040 MB)
[   56.173788] sd 3:0:0:0: [sdd] Write Protect is off
[   56.173855] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[   56.173865] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.173936]  sdd: sdd1
[   56.182236] sd 3:0:0:0: [sdd] Attached SCSI disk
[   56.182379] scsi 4:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.182498] sd 4:0:0:0: [sde] 293046768 512-byte hardware sectors (150040 MB)
[   56.182552] sd 4:0:0:0: [sde] Write Protect is off
[   56.182599] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
[   56.182609] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.182704] sd 4:0:0:0: [sde] 293046768 512-byte hardware sectors (150040 MB)
[   56.182758] sd 4:0:0:0: [sde] Write Protect is off
[   56.182805] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
[   56.182815] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.182886]  sde: sde1
[   56.191616] sd 4:0:0:0: [sde] Attached SCSI disk
[   56.191720] scsi 5:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.191835] sd 5:0:0:0: [sdf] 293046768 512-byte hardware sectors (150040 MB)
[   56.191891] sd 5:0:0:0: [sdf] Write Protect is off
[   56.191938] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[   56.191949] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.192045] sd 5:0:0:0: [sdf] 293046768 512-byte hardware sectors (150040 MB)
[   56.192099] sd 5:0:0:0: [sdf] Write Protect is off
[   56.192146] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[   56.192156] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.192248]  sdf: sdf1
[   56.200792] sd 5:0:0:0: [sdf] Attached SCSI disk
[   56.200925] sata_sil24 0000:03:00.0: version 0.9
[   56.200945] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 18 (level, low) -> IRQ 18
[   56.201098] PCI: Setting latency timer of device 0000:03:00.0 to 64
[   56.201152] scsi6 : sata_sil24
[   56.201229] scsi7 : sata_sil24
[   56.201302] ata7: SATA max UDMA/100 cmd 0xffffc20000038000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   56.201375] ata8: SATA max UDMA/100 cmd 0xffffc2000003a000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   56.605136] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   56.607673] ata7.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.607744] ata7.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   56.607800] ata7.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   56.611033] ata7.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.611106] ata7.00: configured for UDMA/100
[   57.015233] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   57.017747] ata8.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.017818] ata8.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   57.017875] ata8.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   57.021110] ata8.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.021182] ata8.00: configured for UDMA/100
[   57.021288] scsi 6:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   57.021440] sd 6:0:0:0: [sdg] 293046768 512-byte hardware sectors (150040 MB)
[   57.021507] sd 6:0:0:0: [sdg] Write Protect is off
[   57.021554] sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00
[   57.021565] sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.021678] sd 6:0:0:0: [sdg] 293046768 512-byte hardware sectors (150040 MB)
[   57.021735] sd 6:0:0:0: [sdg] Write Protect is off
[   57.021803] sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00
[   57.021813] sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.021885]  sdg: sdg1
[   57.029146] sd 6:0:0:0: [sdg] Attached SCSI disk
[   57.029286] scsi 7:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   57.029404] sd 7:0:0:0: [sdh] 293046768 512-byte hardware sectors (150040 MB)
[   57.029458] sd 7:0:0:0: [sdh] Write Protect is off
[   57.029505] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00
[   57.029516] sd 7:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.029612] sd 7:0:0:0: [sdh] 293046768 512-byte hardware sectors (150040 MB)
[   57.029666] sd 7:0:0:0: [sdh] Write Protect is off
[   57.029713] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00
[   57.029723] sd 7:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.029816]  sdh: sdh1
[   57.037301] sd 7:0:0:0: [sdh] Attached SCSI disk
[   57.037420] ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
[   57.037567] PCI: Setting latency timer of device 0000:04:00.0 to 64
[   57.037611] scsi8 : sata_sil24
[   57.037687] scsi9 : sata_sil24
[   57.037757] ata9: SATA max UDMA/100 cmd 0xffffc20000068000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   57.037832] ata10: SATA max UDMA/100 cmd 0xffffc2000006a000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   57.444772] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   57.446869] ata9.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.446940] ata9.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   57.447004] ata9.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   57.449754] ata9.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.449826] ata9.00: configured for UDMA/100
[   57.854989] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   57.857111] ata10.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.857182] ata10.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   57.857256] ata10.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   57.860018] ata10.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.860092] ata10.00: configured for UDMA/100
[   57.860198] scsi 8:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   57.860352] sd 8:0:0:0: [sdi] 293046768 512-byte hardware sectors (150040 MB)
[   57.860406] sd 8:0:0:0: [sdi] Write Protect is off
[   57.860453] sd 8:0:0:0: [sdi] Mode Sense: 00 3a 00 00
[   57.860464] sd 8:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.860574] sd 8:0:0:0: [sdi] 293046768 512-byte hardware sectors (150040 MB)
[   57.860632] sd 8:0:0:0: [sdi] Write Protect is off
[   57.860680] sd 8:0:0:0: [sdi] Mode Sense: 00 3a 00 00
[   57.860690] sd 8:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.860761]  sdi: sdi1
[   57.866025] sd 8:0:0:0: [sdi] Attached SCSI disk
[   57.866160] scsi 9:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   57.866311] sd 9:0:0:0: [sdj] 293046768 512-byte hardware sectors (150040 MB)
[   57.866365] sd 9:0:0:0: [sdj] Write Protect is off
[   57.866412] sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00
[   57.866422] sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.866533] sd 9:0:0:0: [sdj] 293046768 512-byte hardware sectors (150040 MB)
[   57.866591] sd 9:0:0:0: [sdj] Write Protect is off
[   57.866649] sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00
[   57.866660] sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.866732]  sdj: sdj1
[   57.871781] sd 9:0:0:0: [sdj] Attached SCSI disk
[   57.871887] ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[   57.872070] PCI: Setting latency timer of device 0000:05:00.0 to 64
[   57.872120] scsi10 : sata_sil24
[   57.872195] scsi11 : sata_sil24
[   57.872265] ata11: SATA max UDMA/100 cmd 0xffffc20000070000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   57.872339] ata12: SATA max UDMA/100 cmd 0xffffc20000072000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   58.276407] ata11: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   58.278892] ata11.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.278964] ata11.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   58.279019] ata11.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   58.282273] ata11.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.282345] ata11.00: configured for UDMA/100
[   58.686525] ata12: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   58.689025] ata12.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.689096] ata12.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   58.689180] ata12.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   58.692407] ata12.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.692481] ata12.00: configured for UDMA/100
[   58.692587] scsi 10:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   58.692737] sd 10:0:0:0: [sdk] 293046768 512-byte hardware sectors (150040 MB)
[   58.692819] sd 10:0:0:0: [sdk] Write Protect is off
[   58.692866] sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00
[   58.692876] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.692988] sd 10:0:0:0: [sdk] 293046768 512-byte hardware sectors (150040 MB)
[   58.693061] sd 10:0:0:0: [sdk] Write Protect is off
[   58.693126] sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00
[   58.693136] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.693207]  sdk: sdk1
[   58.702890] sd 10:0:0:0: [sdk] Attached SCSI disk
[   58.703033] scsi 11:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   58.703169] sd 11:0:0:0: [sdl] 293046768 512-byte hardware sectors (150040 MB)
[   58.703238] sd 11:0:0:0: [sdl] Write Protect is off
[   58.703286] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00
[   58.703296] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.703408] sd 11:0:0:0: [sdl] 293046768 512-byte hardware sectors (150040 MB)
[   58.703482] sd 11:0:0:0: [sdl] Write Protect is off
[   58.703529] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00
[   58.703539] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.703610]  sdl: sdl1
[   58.712922] sd 11:0:0:0: [sdl] Attached SCSI disk
[   58.713060] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
[   58.713177] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   58.713217] scsi12 : pata_marvell
[   58.713294] scsi13 : pata_marvell
[   58.713386] ata13: PATA max UDMA/100 cmd 0x0000000000015018 ctl 0x0000000000015026 bmdma 0x0000000000015000 irq 0
[   58.713458] ata14: DUMMY
[   58.713527] BAR5:00:00 01:7F 02:22 03:CA 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:01 0D:00 0E:00 0F:00 
[   59.019568] ata13.00: ATAPI, max UDMA/33
[   59.178746] ata13.00: configured for UDMA/33
[   59.179810] scsi 12:0:0:0: CD-ROM            _NEC     DVD_RW ND-3520A  1.04 PQ: 0 ANSI: 5
[   59.184063] sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
[   59.184112] Uniform CD-ROM driver Revision: 3.20
[   59.184193] sr 12:0:0:0: Attached scsi CD-ROM sr0
[   59.184253] ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18
[   59.184358] PCI: Setting latency timer of device 0000:00:1a.7 to 64
[   59.184361] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[   59.184450] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[   59.184541] ehci_hcd 0000:00:1a.7: debug port 1
[   59.184588] PCI: cache line size of 32 is not supported by device 0000:00:1a.7
[   59.184591] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xe0625c00
[   59.188525] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   59.188683] usb usb1: configuration #1 chosen from 1 choice
[   59.188755] hub 1-0:1.0: USB hub found
[   59.188803] hub 1-0:1.0: 4 ports detected
[   59.289605] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23
[   59.289707] PCI: Setting latency timer of device 0000:00:1d.7 to 64
[   59.289711] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   59.289813] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[   59.289900] ehci_hcd 0000:00:1d.7: debug port 1
[   59.289970] PCI: cache line size of 32 is not supported by device 0000:00:1d.7
[   59.289976] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xe0625800
[   59.293909] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   59.294043] usb usb2: configuration #1 chosen from 1 choice
[   59.294136] hub 2-0:1.0: USB hub found
[   59.294180] hub 2-0:1.0: 6 ports detected
[   59.395292] USB Universal Host Controller Interface driver v3.0
[   59.395383] ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
[   59.395508] PCI: Setting latency timer of device 0000:00:1a.0 to 64
[   59.395510] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[   59.395578] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[   59.395662] uhci_hcd 0000:00:1a.0: irq 16, io base 0x000060c0
[   59.395796] usb usb3: configuration #1 chosen from 1 choice
[   59.395868] hub 3-0:1.0: USB hub found
[   59.396512] hub 3-0:1.0: 2 ports detected
[   59.498341] ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 21 (level, low) -> IRQ 21
[   59.498438] PCI: Setting latency timer of device 0000:00:1a.1 to 64
[   59.498442] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[   59.498542] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[   59.498628] uhci_hcd 0000:00:1a.1: irq 21, io base 0x000060a0
[   59.498779] usb usb4: configuration #1 chosen from 1 choice
[   59.498848] hub 4-0:1.0: USB hub found
[   59.498896] hub 4-0:1.0: 2 ports detected
[   59.599341] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
[   59.599439] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[   59.599442] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   59.599547] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
[   59.599631] uhci_hcd 0000:00:1d.0: irq 23, io base 0x00006080
[   59.599783] usb usb5: configuration #1 chosen from 1 choice
[   59.599855] hub 5-0:1.0: USB hub found
[   59.599902] hub 5-0:1.0: 2 ports detected
[   59.700337] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
[   59.700443] PCI: Setting latency timer of device 0000:00:1d.1 to 64
[   59.700446] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   59.700538] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
[   59.700619] uhci_hcd 0000:00:1d.1: irq 19, io base 0x00006060
[   59.700772] usb usb6: configuration #1 chosen from 1 choice
[   59.700842] hub 6-0:1.0: USB hub found
[   59.700890] hub 6-0:1.0: 2 ports detected
[   59.801355] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
[   59.801458] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[   59.801461] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   59.801549] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
[   59.801631] uhci_hcd 0000:00:1d.2: irq 18, io base 0x00006040
[   59.801782] usb usb7: configuration #1 chosen from 1 choice
[   59.801851] hub 7-0:1.0: USB hub found
[   59.801898] hub 7-0:1.0: 2 ports detected
[   59.902371] Initializing USB Mass Storage driver...
[   59.906365] usb 5-1: new low speed USB device using uhci_hcd and address 2
[   60.066711] usb 5-1: configuration #1 chosen from 1 choice
[   60.069764] usbcore: registered new interface driver usb-storage
[   60.069814] USB Mass Storage support registered.
[   60.069933] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
[   60.072839] serio: i8042 KBD port at 0x60,0x64 irq 1
[   60.072886] serio: i8042 AUX port at 0x60,0x64 irq 12
[   60.072959] mice: PS/2 mouse device common for all mice
[   60.073175] input: PC Speaker as /class/input/input0
[   60.073224] i2c /dev entries driver
[   60.073338] coretemp coretemp.0: Using undocumented features, absolute temperature might be wrong!
[   60.073453] coretemp coretemp.1: Using undocumented features, absolute temperature might be wrong!
[   60.073562] coretemp coretemp.2: Using undocumented features, absolute temperature might be wrong!
[   60.073675] coretemp coretemp.3: Using undocumented features, absolute temperature might be wrong!
[   60.073779] md: raid1 personality registered for level 1
[   60.090134] raid6: int64x1   2023 MB/s
[   60.107135] raid6: int64x2   2781 MB/s
[   60.124120] raid6: int64x4   3109 MB/s
[   60.141143] raid6: int64x8   1917 MB/s
[   60.158123] raid6: sse2x1    3843 MB/s
[   60.175118] raid6: sse2x2    4238 MB/s
[   60.192112] raid6: sse2x4    6796 MB/s
[   60.192154] raid6: using algorithm sse2x4 (6796 MB/s)
[   60.192202] md: raid6 personality registered for level 6
[   60.192247] md: raid5 personality registered for level 5
[   60.192294] md: raid4 personality registered for level 4
[   60.192340] raid5: automatically using best checksumming function: generic_sse
[   60.197110]    generic_sse:  8584.000 MB/sec
[   60.197153] raid5: using function: generic_sse (8584.000 MB/sec)
[   60.197228] usbcore: registered new interface driver hiddev
[   60.643555] hiddev96: USB HID v1.00 Device [        UPS] on usb-0000:00:1d.0-1
[   60.643672] usbcore: registered new interface driver usbhid
[   60.643721] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[   60.643781] Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
[   60.643996] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22
[   60.644106] PCI: Setting latency timer of device 0000:00:1b.0 to 64
[   60.711615] input: ImPS/2 Generic Wheel Mouse as /class/input/input1
[   60.735452] input: AT Translated Set 2 keyboard as /class/input/input2
[   60.779950] ALSA device list:
[   60.779996]   #0: HDA Intel at 0xe0620000 irq 22
[   60.780049] u32 classifier
[   60.780102]     Actions configured 
[   60.780167] nf_conntrack version 0.5.0 (8192 buckets, 65536 max)
[   60.780378] ip_tables: (C) 2000-2006 Netfilter Core Team
[   60.780475] TCP cubic registered
[   60.780533] NET: Registered protocol family 1
[   60.780590] NET: Registered protocol family 17
[   60.780895] md: Autodetecting RAID arrays.
[   60.926037] md: autorun ...
[   60.926077] md: considering sdl1 ...
[   60.926145] md:  adding sdl1 ...
[   60.926190] md:  adding sdk1 ...
[   60.926235] md:  adding sdj1 ...
[   60.926290] md:  adding sdi1 ...
[   60.926345] md:  adding sdh1 ...
[   60.926389] md:  adding sdg1 ...
[   60.926434] md:  adding sdf1 ...
[   60.926479] md:  adding sde1 ...
[   60.926524] md:  adding sdd1 ...
[   60.926566] md:  adding sdc1 ...
[   60.926610] md: sdb3 has different UUID to sdl1
[   60.926658] md: sdb2 has different UUID to sdl1
[   60.926705] md: sdb1 has different UUID to sdl1
[   60.926751] md: sda3 has different UUID to sdl1
[   60.926798] md: sda2 has different UUID to sdl1
[   60.926846] md: sda1 has different UUID to sdl1
[   60.926926] md: created md3
[   60.926967] md: bind<sdc1>
[   60.927013] md: bind<sdd1>
[   60.927058] md: bind<sde1>
[   60.927104] md: bind<sdf1>
[   60.927160] md: bind<sdg1>
[   60.927216] md: bind<sdh1>
[   60.927262] md: bind<sdi1>
[   60.927308] md: bind<sdj1>
[   60.927374] md: bind<sdk1>
[   60.927420] md: bind<sdl1>
[   60.927467] md: running: <sdl1><sdk1><sdj1><sdi1><sdh1><sdg1><sdf1><sde1><sdd1><sdc1>
[   60.927774] raid5: device sdl1 operational as raid disk 2
[   60.927824] raid5: device sdk1 operational as raid disk 3
[   60.927872] raid5: device sdj1 operational as raid disk 0
[   60.927919] raid5: device sdi1 operational as raid disk 1
[   60.927968] raid5: device sdh1 operational as raid disk 6
[   60.928016] raid5: device sdg1 operational as raid disk 5
[   60.928063] raid5: device sdf1 operational as raid disk 4
[   60.928111] raid5: device sde1 operational as raid disk 7
[   60.928159] raid5: device sdd1 operational as raid disk 8
[   60.928227] raid5: device sdc1 operational as raid disk 9
[   60.928780] raid5: allocated 10562kB for md3
[   60.928825] raid5: raid level 5 set md3 active with 10 out of 10 devices, algorithm 2
[   60.928893] RAID5 conf printout:
[   60.928937]  --- rd:10 wd:10
[   60.928979]  disk 0, o:1, dev:sdj1
[   60.929022]  disk 1, o:1, dev:sdi1
[   60.929065]  disk 2, o:1, dev:sdl1
[   60.929106]  disk 3, o:1, dev:sdk1
[   60.929150]  disk 4, o:1, dev:sdf1
[   60.929193]  disk 5, o:1, dev:sdg1
[   60.929236]  disk 6, o:1, dev:sdh1
[   60.929300]  disk 7, o:1, dev:sde1
[   60.929343]  disk 8, o:1, dev:sdd1
[   60.929386]  disk 9, o:1, dev:sdc1
[   60.929487] md: considering sdb3 ...
[   60.929531] md:  adding sdb3 ...
[   60.929576] md: sdb2 has different UUID to sdb3
[   60.929620] md: sdb1 has different UUID to sdb3
[   60.929668] md:  adding sda3 ...
[   60.929709] md: sda2 has different UUID to sdb3
[   60.929756] md: sda1 has different UUID to sdb3
[   60.929832] md: created md2
[   60.929872] md: bind<sda3>
[   60.929918] md: bind<sdb3>
[   60.929964] md: running: <sdb3><sda3>
[   60.930104] raid1: raid set md2 active with 2 out of 2 mirrors
[   60.930172] md: considering sdb2 ...
[   60.930218] md:  adding sdb2 ...
[   60.930262] md: sdb1 has different UUID to sdb2
[   60.930331] md:  adding sda2 ...
[   60.930375] md: sda1 has different UUID to sdb2
[   60.930451] md: created md1
[   60.930515] md: bind<sda2>
[   60.930557] md: bind<sdb2>
[   60.930604] md: running: <sdb2><sda2>
[   60.930742] raid1: raid set md1 active with 2 out of 2 mirrors
[   60.930813] md: considering sdb1 ...
[   60.930860] md:  adding sdb1 ...
[   60.930904] md:  adding sda1 ...
[   60.930949] md: created md0
[   60.930991] md: bind<sda1>
[   60.931038] md: bind<sdb1>
[   60.931085] md: running: <sdb1><sda1>
[   60.931223] raid1: raid set md0 active with 2 out of 2 mirrors
[   60.931889] md: ... autorun DONE.
[   60.956814] UDF-fs: No VRS found
[   60.957045] Filesystem "md2": Disabling barriers, not supported by the underlying device
[   60.969374] XFS mounting filesystem md2
[   61.038746] Ending clean XFS mount for filesystem: md2
[   61.038765] VFS: Mounted root (xfs filesystem) readonly.
[   61.038867] Freeing unused kernel memory: 216k freed
[   63.031810] Adding 16787768k swap on /dev/md0.  Priority:-1 extents:1 across:16787768k
[   63.085652] Filesystem "md2": Disabling barriers, not supported by the underlying device
[   63.876749] kjournald starting.  Commit interval 5 seconds
[   63.883153] EXT3 FS on md1, internal journal
[   63.883225] EXT3-fs: mounted filesystem with ordered data mode.
[   63.883591] Filesystem "md3": Disabling barriers, not supported by the underlying device
[   63.883845] XFS mounting filesystem md3
[   64.258308] Ending clean XFS mount for filesystem: md3
[   82.579367] e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
[   84.433542] process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
[  105.528789] mtrr: no more MTRRs available
#4 lore raw
In reply to Jesse Barnes
Quoted 28 lines · Jesse Barnes

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Quoted 8 lines

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

Looks good, it sustained many backups, bzip2, and even some encoding processes, no issues. Let me know if you need me to test any future iterations of the patch, so far each has been fine, no problems to report using the 965WH motherboard with 8GB of memory.

#5 lore raw
In reply to Jesse Barnes

Hi!

Quoted 7 lines

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

arch/i386/kernel/cpu/mtrr/main.c static struct sysdev_driver mtrr_sysdev_driver = { · line 671

Quoted 8 lines
arch/i386/kernel/cpu/mtrr/main.c +8 -0
+	if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+		printk(KERN_WARNING "***************\n");
+		printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+		printk(KERN_WARNING "**** MTRRs don't cover all of "
+		       "memory, trimmed %ld pages\n", end_pfn -
+		       (highest_addr >> PAGE_SHIFT));
+		printk(KERN_WARNING "***************\n");
+		end_pfn = highest_addr >> PAGE_SHIFT;

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#6 lore raw
Quoted 9 lines · On Tuesday, June 12, 2007 7:50:08 Pavel Machek wrote:

Hi!

Quoted 7 lines

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

Quoted 11 lines

arch/i386/kernel/cpu/mtrr/main.c static struct sysdev_driver mtrr_sysdev_driver = { · line 671

Quoted 8 lines
arch/i386/kernel/cpu/mtrr/main.c +8 -0
+	if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+		printk(KERN_WARNING "***************\n");
+		printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+		printk(KERN_WARNING "**** MTRRs don't cover all of "
+		       "memory, trimmed %ld pages\n", end_pfn -
+		       (highest_addr >> PAGE_SHIFT));
+		printk(KERN_WARNING "***************\n");
+		end_pfn = highest_addr >> PAGE_SHIFT;

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

How missing about 1G of memory? We already discussed this, and Andi and Venki felt that either a panic or a really obnoxious message was the way to go...

Jesse

#7 lore raw
Quoted 6 lines
Quoted 2 lines

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

How missing about 1G of memory? We already discussed this, and Andi and Venki felt that either a panic or a really obnoxious message was the way to go...

Perhaps you could vary the number of stars based on the missing amount to satisfy Pavel @)

-Andi

#8 lore raw
In reply to Jesse Barnes

Hi!

Quoted 19 lines
Quoted 7 lines
Quoted 7 lines

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

Quoted 11 lines

arch/i386/kernel/cpu/mtrr/main.c static struct sysdev_driver mtrr_sysdev_driver = { · line 671

Quoted 8 lines
arch/i386/kernel/cpu/mtrr/main.c +8 -0
+	if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+		printk(KERN_WARNING "***************\n");
+		printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+		printk(KERN_WARNING "**** MTRRs don't cover all of "
+		       "memory, trimmed %ld pages\n", end_pfn -
+		       (highest_addr >> PAGE_SHIFT));
+		printk(KERN_WARNING "***************\n");
+		end_pfn = highest_addr >> PAGE_SHIFT;

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

Quoted 3 lines

How missing about 1G of memory? We already discussed this, and Andi and Venki felt that either a panic or a really obnoxious message was the way to go...

Just use panic, then.
Pavel,
who still thinks anyone missing 1GB of ram will not miss friendly notice in dmesg, even if it goes without 20 stars.

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#9 lore raw
Quoted 21 lines · Pavel Machek

Hi!

Quoted 19 lines
Quoted 18 lines
Quoted 7 lines

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

arch/i386/kernel/cpu/mtrr/main.c static struct sysdev_driver mtrr_sysdev_driver = { · line 671

Quoted 8 lines
arch/i386/kernel/cpu/mtrr/main.c +8 -0
+	if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+		printk(KERN_WARNING "***************\n");
+		printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+		printk(KERN_WARNING "**** MTRRs don't cover all of "
+		       "memory, trimmed %ld pages\n", end_pfn -
+		       (highest_addr >> PAGE_SHIFT));
+		printk(KERN_WARNING "***************\n");
+		end_pfn = highest_addr >> PAGE_SHIFT;

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

Quoted 13 lines
Quoted 3 lines

How missing about 1G of memory? We already discussed this, and Andi and Venki felt that either a panic or a really obnoxious message was the way to go...

Just use panic, then.
Pavel,
who still thinks anyone missing 1GB of ram will not miss friendly notice in dmesg, even if it goes without 20 stars.

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

What is wrong with Jesse's patch? I've been using it for quite a few days now, no issues.

Justin.

#10 lore raw
In reply to Pavel Machek
Quoted 19 lines · Pavel Machek
Quoted 19 lines
Quoted 18 lines
Quoted 8 lines

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

+ if ((highest_addr >> PAGE_SHIFT) != end_pfn) {

arch/i386/kernel/cpu/mtrr/main.c static struct sysdev_driver mtrr_sysdev_driver = { · line 671

Quoted 7 lines
arch/i386/kernel/cpu/mtrr/main.c +7 -0
+         printk(KERN_WARNING "***************\n");
+         printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+         printk(KERN_WARNING "**** MTRRs don't cover all of "
+                "memory, trimmed %ld pages\n", end_pfn -
+                (highest_addr >> PAGE_SHIFT));
+         printk(KERN_WARNING "***************\n");
+         end_pfn = highest_addr >> PAGE_SHIFT;

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

Quoted 8 lines
Quoted 3 lines

How missing about 1G of memory? We already discussed this, and Andi and Venki felt that either a panic or a really obnoxious message was the way to go...

Just use panic, then.
Pavel,
who still thinks anyone missing 1GB of ram will not miss friendly notice in dmesg, even if it goes without 20 stars.

Panicking when it's not necessary is anti-social. If the kernel can continue, then it should, unless it's a correctness issue that may cause data corruption. Given that the kernel can even work around the problem now, throwing a panic is even less warranted.

Ray

#11 lore raw
Quoted 29 lines · Ray Lee
Quoted 19 lines · Pavel Machek
Quoted 19 lines
Quoted 18 lines
Quoted 8 lines

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

+ if ((highest_addr >> PAGE_SHIFT) != end_pfn) {

arch/i386/kernel/cpu/mtrr/main.c static struct sysdev_driver mtrr_sysdev_driver = { · line 671

Quoted 7 lines
arch/i386/kernel/cpu/mtrr/main.c +7 -0
+         printk(KERN_WARNING "***************\n");
+         printk(KERN_WARNING "**** WARNING: likely BIOS bug\n");
+         printk(KERN_WARNING "**** MTRRs don't cover all of "
+                "memory, trimmed %ld pages\n", end_pfn -
+                (highest_addr >> PAGE_SHIFT));
+         printk(KERN_WARNING "***************\n");
+         end_pfn = highest_addr >> PAGE_SHIFT;

Missing 4K of memory is not worth 4K of junk in syslog per boot. Can you drop the stars and stop shouting?

Quoted 8 lines
Quoted 3 lines

How missing about 1G of memory? We already discussed this, and Andi and Venki felt that either a panic or a really obnoxious message was the way to go...

Just use panic, then.
Pavel,
who still thinks anyone missing 1GB of ram will not miss friendly notice in dmesg, even if it goes without 20 stars.

Quoted 4 lines

Panicking when it's not necessary is anti-social. If the kernel can continue, then it should, unless it's a correctness issue that may cause data corruption. Given that the kernel can even work around the problem now, throwing a panic is even less warranted.

Printk("*********************** WARNING")

is anti-social, too.

Here's what my dmesg looks. Lots of uninteresting, unneccessary crap.

Instead of removing some of that crap, this patch starts "I'm more important than you" wars, trying to get attetion with stars. How do you like dump below?

Come on, we have printk loglevels. They are meant for getting attetion. Shouting printk with ton of stars is not.

Pavel

Linux version 2.6.22-rc4 (pavel@amd) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #440 SMP Sat Jun 9 15:25:43 CEST 2007
...
DMI present.
ACPI: RSDP 000F6880, 0024 (r2 LENOVO)
ACPI: XSDT 7F6E6621, 0074 (r1 LENOVO TP-7B 1060 LTP 0)
ACPI: FACP 7F6E6700, 00F4 (r3 LENOVO TP-7B 1060 LNVO 1)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!ACPI WARNING (TBFADT-0434): OPTIONAL FIELD !!!!!!!!!!!!!!!!!!"GPE1BLOCK" HAS ZERO ADDRESS OR LENGTH: 000000000000102C/0 [20070126] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ACPI: DSDT 7F6E68E7, C463 (r1 LENOVO TP-7B 1060 MSFT 100000E)
ACPI: FACS 7F6F4000, 0040
ACPI: SSDT 7F6E68B4, 0033 (r1 LENOVO TP-7B 1060 MSFT 100000E)
ACPI: ECDT 7F6F2D4A, 0052 (r1 LENOVO TP-7B 1060 LNVO 1)
ACPI: TCPA 7F6F2D9C, 0032 (r2 LENOVO TP-7B 1060 LNVO 1)
ACPI: APIC 7F6F2DCE, 0068 (r1 LENOVO TP-7B 1060 LNVO 1)
ACPI: MCFG 7F6F2E36, 003E (r1 LENOVO TP-7B 1060 LNVO 1)
ACPI: HPET 7F6F2E74, 0038 (r1 LENOVO TP-7B 1060 LNVO 1)
ACPI: BOOT 7F6F2FD8, 0028 (r1 LENOVO TP-7B 1060 LTP 1)
ACPI: SSDT 7F6E5BDC, 0507 (r1 LENOVO TP-7B 1060 INTL 20050513)
ACPI: SSDT 7F6E5A04, 01D8 (r1 LENOVO TP-7B 1060 INTL 20050513)
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:14 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:14 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) //////////////////////////////////////////////////////////////////// /////////////////////////////ACPI: IRQ0 used by override. /////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// /////////////////////////////ACPI: IRQ2 used by override. //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// /////////////////////////////ACPI: IRQ9 used by override. //////////////////////////////////////////////////////////////////// Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 88000000 (gap: 80000000:70000000) Built 1 zonelists. Total pages: 517875
Kernel command line: root=/dev/sda4 resume=/dev/sda1 psmouse.psmouse_proto=imps psmouse_proto=imps psmouse.proto=imps
vga=791 init=/tmp/swsusp-init
************ Unknown boot option `psmouse.psmouse_proto=imps': ignoring mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
....
Total of 2 processors activated (7318.93 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization [CPU#0 -> CPU#1]:
************
*
*
*
* Measured 627605 cycles TSC warp between CPUs, turning off TSC clock.
*
*
*
*
*
**********************
##########################################################################
##### Marking TSC unstable due to: check_tsc_sync_source failed. ########
########################################################################
Brought up 2 CPUs
migration_cost=10000

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#12 lore raw
Quoted 9 lines · Pavel Machek
Quoted 4 lines · Ray Lee

Panicking when it's not necessary is anti-social. If the kernel can continue, then it should, unless it's a correctness issue that may cause data corruption. Given that the kernel can even work around the problem now, throwing a panic is even less warranted.

Printk("*********************** WARNING")

is anti-social, too.

Pavel, this warning isn't even going to print on any of your systems. So it's completely different than the straw-man you're proposing (that I snipped).

Look, if you want to argue that the stars should go away, then sure, I'm not going to stop you. But panicking over a BIOS misconfiguration issue? One that can be corrected by the kernel? That's just plain stupid.

Ray

#13 lore raw

Hi!

Quoted 9 lines
Quoted 8 lines
Quoted 4 lines

Panicking when it's not necessary is anti-social. If the kernel can continue, then it should, unless it's a correctness issue that may cause data corruption. Given that the kernel can even work around the problem now, throwing a panic is even less warranted.

Printk("*********************** WARNING")

is anti-social, too.

Quoted 8 lines

Pavel, this warning isn't even going to print on any of your systems. So it's completely different than the straw-man you're proposing (that I snipped).

Look, if you want to argue that the stars should go away, then sure, I'm not going to stop you. But panicking over a BIOS misconfiguration issue? One that can be corrected by the kernel? That's just plain stupid.

Well, either the warning is _really_ important. Then it is not really warning, but a fatal problem, and we should panic for it (so that user sees the message) and ask for a command line option (so we really really know user wants to ignore that warning).

Or it is important but not _that_ important. We have printk(KERN_EMERG) for that.

Or maybe it is not so important. We have printk(KERN_WARNING) for that.

Pick one, but doing "KERN_WARNING" level with message "************************* I'm extremely important warning, ************************** uhuh maybe there is something bad in your bios but I'm not really sure" is just wrong.

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#14 lore raw
In reply to Jesse Barnes

Thanks for this patch. I was having the exact same symptoms as Justin Piszcz, on a different, but similar motherboard:

Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21-1.3194.fc7

Building vanilla 2.6.22-rc4 with your patch solved the problem.

I'm now seeing this in the syslog

***************
**** WARNING: likely BIOS bug
**** MTRRs don't cover all of memory, trimmed 196608 pages
***************

leaving me 7416672 kB of usable memory.

If there's any way I can help with more info or testing, then let me know.

Thanks,
Pim

#15 lore raw
Quoted 18 lines · Pim Zandbergen

Thanks for this patch. I was having the exact same symptoms as Justin Piszcz, on a different, but similar motherboard:

Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21-1.3194.fc7

Building vanilla 2.6.22-rc4 with your patch solved the problem.

I'm now seeing this in the syslog

***************
**** WARNING: likely BIOS bug
**** MTRRs don't cover all of memory, trimmed 196608 pages
***************

Quoted 8 lines

leaving me 7416672 kB of usable memory.

If there's any way I can help with more info or testing, then let me know.

Thanks,
Pim

That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top:

Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers

What type of memory are you using and what is your DVT set to?

Justin.

#16 lore raw
Quoted 20 lines · On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote:
Quoted 19 lines · Pim Zandbergen

Thanks for this patch. I was having the exact same symptoms as Justin Piszcz, on a different, but similar motherboard:

Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21-1.3194.fc7

Building vanilla 2.6.22-rc4 with your patch solved the problem.

I'm now seeing this in the syslog

***************
**** WARNING: likely BIOS bug
**** MTRRs don't cover all of memory, trimmed 196608 pages
***************

Quoted 7 lines
Quoted 7 lines

leaving me 7416672 kB of usable memory.

If there's any way I can help with more info or testing, then let me know.

Thanks,
Pim

Thanks for testing, Pim. Glad it works for you. Keep an eye out for BIOS upgrades, the next version might fix it.

Quoted 8 lines

That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top:

Mem: 8039576k total, 6187304k used, 1852272k free, 696k
buffers

What type of memory are you using and what is your DVT set to?

Different BIOSes will map things differently, so I'd expect differences in the "trimmmed xxx pages" message across machines. But yeah, BIOS config options can also affect things, in particular I've heard that the fan control options change MTRR setup significantly.

Jesse

#17 lore raw
Quoted 39 lines · Jesse Barnes
Quoted 20 lines · On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote:
Quoted 19 lines · Pim Zandbergen

Thanks for this patch. I was having the exact same symptoms as Justin Piszcz, on a different, but similar motherboard:

Motherboard: GigaByte GA-G33-DS3R
BIOS rev: F2
Chipset: Intel G33
Memory: 8GB
Distro: Fedora 7 x86_64
Kernel: kernel-2.6.21-1.3194.fc7

Building vanilla 2.6.22-rc4 with your patch solved the problem.

I'm now seeing this in the syslog

***************
**** WARNING: likely BIOS bug
**** MTRRs don't cover all of memory, trimmed 196608 pages
***************

Quoted 7 lines
Quoted 7 lines

leaving me 7416672 kB of usable memory.

If there's any way I can help with more info or testing, then let me know.

Thanks,
Pim

Thanks for testing, Pim. Glad it works for you. Keep an eye out for BIOS upgrades, the next version might fix it.

Quoted 7 lines

That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top:

Mem: 8039576k total, 6187304k used, 1852272k free, 696k
buffers

Quoted 9 lines
Quoted 1 line

What type of memory are you using and what is your DVT set to?

Different BIOSes will map things differently, so I'd expect differences in the "trimmmed xxx pages" message across machines. But yeah, BIOS config options can also affect things, in particular I've heard that the fan control options change MTRR setup significantly.

Jesse

To Intel,

When will HECI be supported via the kernel? When it becomes supported, would that alter the MTRR map at all?

Justin.

#18 lore raw
Quoted 4 lines · On Thursday, June 14, 2007 2:21:16 Justin Piszcz wrote:

To Intel,

When will HECI be supported via the kernel? When it becomes supported, would that alter the MTRR map at all?

I *think* HECI is related to our IT remote management stuff, but I don't work on it. It *may* affect the MTRR mappings, but I think it's just a PCI device, so I don't think enabling it will change the MTRR layout.

Arjan, do you know who's doing our AMT stuff?

Thanks,
Jesse

#19 lore raw
In reply to Jesse Barnes
Quoted 1 line · Jesse Barnes

Thanks for testing, Pim. Glad it works for you.

The pleasure was all on my side.

Quoted 2 lines

Keep an eye out for BIOS upgrades, the next version might fix it.

What, are you going to report this to GigaByte?

Thanks,
Pim

#20 lore raw
Quoted 8 lines · On Friday, June 15, 2007 3:21:17 Pim Zandbergen wrote:
Quoted 1 line · Jesse Barnes

Thanks for testing, Pim. Glad it works for you.

The pleasure was all on my side.

Quoted 1 line

Keep an eye out for BIOS upgrades, the next version might fix it.

What, are you going to report this to GigaByte?

No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though...

Jesse

#21 lore raw
Quoted 6 lines · Jesse Barnes
Quoted 2 lines

What, are you going to report this to GigaByte?

No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though...

I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh!

They sent the BIOS image in a private message, so it might take a while before it's available on their website.

#22 lore raw
Quoted 4 lines · Pim Zandbergen
Quoted 3 lines · Jesse Barnes
Quoted 2 lines

What, are you going to report this to GigaByte?

Quoted 10 lines
Quoted 3 lines

No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though...

I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh!

They sent the BIOS image in a private message, so it might take a while before it's available on their website.

Wow, totally the opposite from Intel.

Justin.

#23 lore raw
In reply to Pim Zandbergen

Pim Zandbergen wrote

Quoted 6 lines
Quoted 1 line

I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh!

They sent the BIOS image in a private message, so it might take a while before it's available on their website.

It is now, and it is described as "Fix Vista boot lag with 8GB memory issue" ...

Pim

#24 lore raw

Impressive.

Jesse, can you touch base with Intel's BIOS department? Also, what are the chances of that patch making it into 2.6.22-rc6/7 if it hasn't already?

Quoted 11 lines · Pim Zandbergen

Pim Zandbergen wrote

Quoted 6 lines
Quoted 1 line

I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh!

They sent the BIOS image in a private message, so it might take a while before it's available on their website.

It is now, and it is described as "Fix Vista boot lag with 8GB memory issue" ...

Pim

#25 lore raw
In reply to Justin Piszcz
Quoted 3 lines · Justin Piszcz

That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top:

Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers

Me:
Mem: 7416672k total, 378988k used, 7037684k free, 13592k buffers

Quoted 1 line

What type of memory are you using

2x Kingston KVR667D2N5K2/4G

Quoted 1 line

and what is your DVT set to?

GigaByte's BIOS config options of the onboard graphics controller are very limited compared to those on your Intel motherboard.

I can only choose the graphics buffer size, between "1MB+1~2MB for GTT" or "8MB+1~2MB for GTT".
I chose the latter. The POST says 9MB are taken for video.

Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver.

Thanks,
Pim

#26 lore raw
Quoted 17 lines · Pim Zandbergen
Quoted 3 lines · Justin Piszcz

That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top:

Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers

Me:
Mem: 7416672k total, 378988k used, 7037684k free, 13592k buffers

Quoted 1 line

What type of memory are you using

2x Kingston KVR667D2N5K2/4G

Quoted 1 line

and what is your DVT set to?

GigaByte's BIOS config options of the onboard graphics controller are very limited compared to those on your Intel motherboard.

I can only choose the graphics buffer size, between "1MB+1~2MB for GTT" or "8MB+1~2MB for GTT".
I chose the latter. The POST says 9MB are taken for video.

Quoted 6 lines

Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver.

Thanks,
Pim

I use the exact same memory model. So it must be the difference in BIOS MTRR/E820 memory mappings.

Justin.

#27 lore raw
In reply to Pim Zandbergen
Quoted 2 lines · On Friday, June 15, 2007 3:17:11 Pim Zandbergen wrote:

Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver.

I *think* the latest trees support that chip. If you're feeling brave, checkout the latest version of the xf86-video-intel driver from freedesktop.org and give it a try (to get 3d you'll also need newer DRM and AGP bits).

Jesse

#28 lore raw
Quoted 7 lines · Jesse Barnes
Quoted 3 lines · On Friday, June 15, 2007 3:17:11 Pim Zandbergen wrote:

Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver.

I *think* the latest trees support that chip. If you're feeling brave, checkout the latest version of the xf86-video-intel driver from freedesktop.org and give it a try

As it happens, the Fedora guys just released a new Intel xorg driver RPM that supports the G33. It works.

Quoted 2 lines

(to get 3d you'll also need newer DRM and AGP bits).

No 3D indeed. The newer DRM and AGP bits probably go into the kernel.

But hey, it's a server. I've got another machine with the exact same hardware running Windows 2003. No video driver support there at all.

Thanks,
Pim

#29 lore raw
In reply to Jesse Barnes
Quoted 28 lines · Jesse Barnes

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Quoted 8 lines

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

NAK.

for AMD Rev F Opteron later CPU, BIOS will not set WB in MTRR for 4G above mem.

This patch will get rid of those RAM.

YH

#30 lore raw
Quoted 37 lines · On Thursday, June 21, 2007 12:40:58 Yinghai Lu wrote:
Quoted 28 lines · Jesse Barnes

On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time).

This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug.

Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup.

This patch incorporates the feedback from Eric and Andi:
- use MAX_VAR_RANGES instead of NUM_VAR_RANGES
- move array declaration to header file as an extern
- add command line disable option "disable_mtrr_trim"
- don't run the trim code if the MTRR default type is cacheable
- don't run the trim code on non-Intel machines

Justin, feel free to test again if you have time and add your "Tested-by" signoff.

Quoted 7 lines

Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity?

Thanks,
Jesse

Quoted 6 lines

NAK.

for AMD Rev F Opteron later CPU, BIOS will not set WB in MTRR for 4G above mem.

This patch will get rid of those RAM.

Yeah, Eric already mentioned that. I'll rework it to only run on Intel CPUs per Eric's last mail.

Thanks,
Jesse