Skip to contentSkip to conversation

trim memory not covered by WB MTRRs

PATCH In review Jesse Barnes 10 participants 50 messages Jun 6, 2007 – Jun 20, 2007

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.

Justin, can you please test and make sure this patch works for you too? It'll only work around the problem, but it's better than having to do mem= by hand or waiting for a fix from your BIOS vendor.

Thanks,
Jesse

arch/i386/kernel/cpu/mtrr/generic.c +1 -7
index c4ebb51..71fc768 100644
@@ -13,7 +13,7 @@
 #include "mtrr.h"
 
 struct mtrr_state {
-	struct mtrr_var_range *var_ranges;
+	struct mtrr_var_range var_ranges[NUM_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 +1 -1
index c7d8f17..d7922ce 100644
@@ -12,7 +12,7 @@
 #include "mtrr.h"
 
 /* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
+extern unsigned int usage_table[];
 
 
 #define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
arch/i386/kernel/cpu/mtrr/main.c +39 -14

94 lines not on this page · raw message

arch/i386/kernel/cpu/mtrr/mtrr.h +1 -0
index 289dfe6..a29dcba 100644
@@ -14,6 +14,7 @@
 #define MTRRphysMask_MSR(reg) (0x200 + 2 * (reg) + 1)
 
 #define NUM_FIXED_RANGES 88
+#define NUM_VAR_RANGES 256
 #define MTRRfix64K_00000_MSR 0x250
 #define MTRRfix16K_80000_MSR 0x258
 #define MTRRfix16K_A0000_MSR 0x259
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
Quoted 18 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.

Quoted 7 lines

Justin, can you please test and make sure this patch works for you too? It'll only work around the problem, but it's better than having to do mem= by hand or waiting for a fix from your BIOS vendor.

Thanks,
Jesse

Against what kernel version does this patch apply?

linux-2.6.21# patch -p1 < ../mtrr.patch
patching file arch/i386/kernel/cpu/mtrr/generic.c
Hunk #2 succeeded at 66 (offset -18 lines).
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
can't find file to patch at input line 160
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------

|diff --git a/arch/x86_64/kernel/bugs.c b/arch/x86_64/kernel/bugs.c
|index c3c6b91..c138eac 100644
|--- a/arch/x86_64/kernel/bugs.c
|+++ b/arch/x86_64/kernel/bugs.c

--------------------------
File to patch:

#2 lore raw
Quoted 24 lines · Justin Piszcz
Quoted 23 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.

Justin, can you please test and make sure this patch works for you too? It'll only work around the problem, but it's better than having to do mem= by hand or waiting for a fix from your BIOS vendor.

Quoted 4 lines
Quoted 2 lines

Thanks,
Jesse

Against what kernel version does this patch apply?

Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I should have updated before spinning the patch (will do now).

Jesse

#3 lore raw
Quoted 4 lines · Jesse Barnes
Quoted 1 line

Against what kernel version does this patch apply?

Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I should have updated before spinning the patch (will do now).

Appears to apply cleanly to git head as of a minute ago too.

Jesse

#4 lore raw
Quoted 10 lines · Jesse Barnes
Quoted 4 lines · Jesse Barnes
Quoted 1 line

Against what kernel version does this patch apply?

Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I should have updated before spinning the patch (will do now).

Appears to apply cleanly to git head as of a minute ago too.

Jesse

Can you produce a patch against 2.6.22-rc4 or 2.6.21 so I and other people can easily try it? I do not have git installed on this machine, thanks.

Justin.

#5 lore raw
Quoted 7 lines · Justin Piszcz
Quoted 6 lines · Jesse Barnes
Quoted 4 lines · Jesse Barnes
Quoted 1 line

Against what kernel version does this patch apply?

Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I should have updated before spinning the patch (will do now).

Quoted 7 lines
Quoted 3 lines

Appears to apply cleanly to git head as of a minute ago too.

Jesse

Can you produce a patch against 2.6.22-rc4 or 2.6.21 so I and other people can easily try it? I do not have git installed on this machine, thanks.

Seems to apply cleanly to 2.6.22-rc4 too. Haven't tested that though.

Jesse

#6 lore raw

Will give it a shot.

Quoted 20 lines · Jesse Barnes
Quoted 7 lines · Justin Piszcz
Quoted 6 lines · Jesse Barnes
Quoted 4 lines · Jesse Barnes
Quoted 1 line

Against what kernel version does this patch apply?

Um... git as of b4946ffb1860597b187d78d61ac6504177eb0ff8. Sorry I should have updated before spinning the patch (will do now).

Quoted 7 lines
Quoted 3 lines

Appears to apply cleanly to git head as of a minute ago too.

Jesse

Can you produce a patch against 2.6.22-rc4 or 2.6.21 so I and other people can easily try it? I do not have git installed on this machine, thanks.

Seems to apply cleanly to 2.6.22-rc4 too. Haven't tested that though.

Jesse

#7 lore raw
In reply to Jesse Barnes
Quoted 18 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.

Quoted 7 lines

Justin, can you please test and make sure this patch works for you too? It'll only work around the problem, but it's better than having to do mem= by hand or waiting for a fix from your BIOS vendor.

Thanks,
Jesse

Jesse, it worked.

With mem=8832M (without your patch): 2.6.22-rc4:

top - 17:39:02 up 1 day, 8:07, 25 users, load average: 2.33, 0.76, 0.30
Tasks: 325 total, 11 running, 314 sleeping, 0 stopped, 0 zombie
Cpu(s): 80.0%us, 20.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8039620k total, 7936472k used, 103148k free, 708k buffers
Swap: 16787768k total, 128k used, 16787640k free, 6646248k cached

With no mem= in append line (with your patch): 2.6.22-rc4:

top - 17:44:01 up 1 min, 1 user, load average: 0.97, 0.25, 0.08

Tasks: 145 total,   1 running, 144 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.2%us,  3.0%sy,  1.2%ni, 86.8%id,  3.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8039608k total,   969380k used,  7070228k free,     1232k buffers
Swap: 16787768k total,        0k used, 16787768k free,   109448k cached

Odd, remote netconsole did not capture the dmesg the E820 memory map.

Jun  6 17:43:03 p34 [   53.598611] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode Jun  6 17:43:03 p34 [   53.598683] ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part Jun  6 17:43:03 p34 [   53.598986] scsi0 : ahci Jun  6 17:43:03 p34 [   53.599131] scsi1 : ahci Jun  6 17:43:03 p34 [   53.599239] scsi2 : ahci Jun  6 17:43:03 p34 [   53.599340] scsi3 : ahci Jun  6 17:43:03 p34 [   53.599438] scsi4 : ahci

I will run with this patch for a while but so far, no issues, everything looks great.

Will it make it into 2.6.22-rc5? :)

Justin.

#8 lore raw
Mem:   8039620k total,  7936472k used,   103148k free,      708k buffers
Mem:   8039608k total,   969380k used,  7070228k free,     1232k buffers

I am curious, why does the patch != the mem=8832M?

Justin.

Quoted 58 lines · Justin Piszcz
Quoted 18 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.

Quoted 7 lines

Justin, can you please test and make sure this patch works for you too? It'll only work around the problem, but it's better than having to do mem= by hand or waiting for a fix from your BIOS vendor.

Thanks,
Jesse

Jesse, it worked.

With mem=8832M (without your patch): 2.6.22-rc4:

top - 17:39:02 up 1 day, 8:07, 25 users, load average: 2.33, 0.76, 0.30
Tasks: 325 total, 11 running, 314 sleeping, 0 stopped, 0 zombie
Cpu(s): 80.0%us, 20.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8039620k total, 7936472k used, 103148k free, 708k buffers
Swap: 16787768k total, 128k used, 16787640k free, 6646248k cached

With no mem= in append line (with your patch): 2.6.22-rc4:

top - 17:44:01 up 1 min, 1 user, load average: 0.97, 0.25, 0.08

Tasks: 145 total,   1 running, 144 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.2%us,  3.0%sy,  1.2%ni, 86.8%id,  3.8%wa,  0.0%hi,  0.0%si, 0.0%st
Mem:   8039608k total,   969380k used,  7070228k free,     1232k buffers
Swap: 16787768k total,        0k used, 16787768k free,   109448k cached

Odd, remote netconsole did not capture the dmesg the E820 memory map.

Jun  6 17:43:03 p34 [   53.598611] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode Jun  6 17:43:03 p34 [   53.598683] ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part Jun  6 17:43:03 p34 [ 53.598986] scsi0 : ahci Jun  6 17:43:03 p34 [   53.599131] scsi1 : ahci Jun 6 17:43:03 p34 [   53.599239] scsi2 : ahci Jun  6 17:43:03 p34 [   53.599340] scsi3 : ahci Jun  6 17:43:03 p34 [   53.599438] scsi4 : ahci

I will run with this patch for a while but so far, no issues, everything looks great.

Will it make it into 2.6.22-rc5? :)

Justin.

#9 lore raw
Quoted 5 lines · Justin Piszcz
Mem:   8039620k total,  7936472k used,   103148k free,      708k
buffers Mem:   8039608k total,   969380k used,  7070228k free,    

1232k buffers

I am curious, why does the patch != the mem=8832M?

I'm not sure... can you post your e820 map from boot and the contents of /proc/mtrr? Maybe my patch is trimming off a few too many pages, or maybe 8832M isn't quite right and actually ends up leaving you with a few uncached pages.

Jesse

#10 lore raw
Quoted 5 lines · Jesse Barnes
Quoted 4 lines · Justin Piszcz
Mem:   8039620k total,  7936472k used,   103148k free,      708k
buffers Mem:   8039608k total,   969380k used,  7070228k free,

1232k buffers

Quoted 9 lines
Quoted 1 line

I am curious, why does the patch != the mem=8832M?

I'm not sure... can you post your e820 map from boot and the contents of /proc/mtrr? Maybe my patch is trimming off a few too many pages, or maybe 8832M isn't quite right and actually ends up leaving you with a few uncached pages.

Jesse

I cannot post the E820 memory map, I have no way to capture it, I cannot get anything from netconsole and dmesg does not show it either.

BEFORE:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size= 8MB: uncachable, count=1
reg04: base=0xcf700000 (3319MB), size= 1MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg07: base=0x220000000 (8704MB), size= 128MB: write-back, count=1

AFTER:

$ cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size=   8MB: uncachable, count=1
reg04: base=0xcf700000 (3319MB), size=   1MB: uncachable, count=1
reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg07: base=0x220000000 (8704MB), size= 128MB: write-back, count=1

But that still works.

Justin.

#11 lore raw
In reply to Jesse Barnes
Quoted 5 lines · Jesse Barnes
Quoted 4 lines · Justin Piszcz
Mem:   8039620k total,  7936472k used,   103148k free,      708k
buffers Mem:   8039608k total,   969380k used,  7070228k free,

1232k buffers

Quoted 9 lines
Quoted 1 line

I am curious, why does the patch != the mem=8832M?

I'm not sure... can you post your e820 map from boot and the contents of /proc/mtrr? Maybe my patch is trimming off a few too many pages, or maybe 8832M isn't quite right and actually ends up leaving you with a few uncached pages.

Jesse

Unless you know of some other way I can capture the output, it only starts showing the dmesg from [50..] onward.

Justin.

#12 lore raw
Quoted 13 lines · Justin Piszcz
Quoted 12 lines · Jesse Barnes
Quoted 5 lines · Justin Piszcz
Mem:   8039620k total,  7936472k used,   103148k free,      708k
buffers Mem:   8039608k total,   969380k used,  7070228k free,

1232k buffers

I am curious, why does the patch != the mem=8832M?

I'm not sure... can you post your e820 map from boot and the contents of /proc/mtrr? Maybe my patch is trimming off a few too many pages, or maybe 8832M isn't quite right and actually ends up leaving you with a few uncached pages.

Quoted 4 lines
Quoted 1 line

Jesse

Unless you know of some other way I can capture the output, it only starts showing the dmesg from [50..] onward.

Did you boot the kernel with the 'debug' option? Maybe your dmesg buffer is too small (there's a config option for that iirc).

Jesse

#13 lore raw
Quoted 16 lines · Jesse Barnes
Quoted 15 lines · Justin Piszcz
Quoted 13 lines · Jesse Barnes
Quoted 5 lines · Justin Piszcz
Mem:   8039620k total,  7936472k used,   103148k free,      708k
buffers Mem:   8039608k total,   969380k used,  7070228k free,

1232k buffers

I am curious, why does the patch != the mem=8832M?

I'm not sure... can you post your e820 map from boot and the contents of /proc/mtrr? Maybe my patch is trimming off a few too many pages, or maybe 8832M isn't quite right and actually ends up leaving you with a few uncached pages.

Jesse

Quoted 8 lines
Quoted 2 lines

Unless you know of some other way I can capture the output, it only starts showing the dmesg from [50..] onward.

Did you boot the kernel with the 'debug' option? Maybe your dmesg buffer is too small (there's a config option for that iirc).

Jesse

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

#14 lore raw
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

It's called "kernel log buffer size" and it's in "General setup".

Jesse

#15 lore raw
Quoted 9 lines · Jesse Barnes
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

It's called "kernel log buffer size" and it's in "General setup".

Jesse

I was reviewing some OLD mailing list archives then!

--------------

Per: http://www.edlug.ed.ac.uk/archive/Aug2003/msg00270.html

The kernel has a cyclic buffer of length LOG_BUF_LEN (4096, since 1.3.54:
8192, since 2.1.113: 16384; in
recent kernels the size can be set at compile time) in which
messages
given as argument to the kernel
function printk() are stored (regardless of their loglevel).

So it doesn't look like you can without recompiling...

Bruce

--------------

Getting you the E820 memory map in a few moments.

Changed from 15 -> 16.

| | (16) Kernel log buffer size (16 => 64KB, 17 => 128KB)

Justin.

#16 lore raw
In reply to Jesse Barnes
Quoted 9 lines · Jesse Barnes
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

It's called "kernel log buffer size" and it's in "General setup".

Jesse

Here ya go (and full dmesg attached)

[    0.000000] Linux version 2.6.22-rc4 ([email protected]) (gcc
version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Wed Jun 6
18:30:43 EDT 2007
[    0.000000] Command line: auto BOOT_IMAGE=2.6.22-rc4-3 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] Linux version 2.6.22-rc4 ([email protected]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Wed Jun 6 18:30:43 EDT 2007
[    0.000000] Command line: auto BOOT_IMAGE=2.6.22-rc4-3 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-3 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.079506] time.c: Detected 2397.607 MHz processor.
[   48.080578] Console: colour VGA+ 80x25
[   48.088448] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[   48.094647] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   48.095721] Checking aperture...
[   48.095768] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[   48.132061] Placing software IO TLB between 0x951a000 - 0xd51a000
[   48.205318] Memory: 8039012k/9043968k available (3549k kernel code, 207808k reserved, 1317k data, 216k init)
[   48.264754] Calibrating delay using timer specific routine.. 4797.72 BogoMIPS (lpj=2398863)
[   48.264878] Mount-cache hash table entries: 256
[   48.265005] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.265068] CPU: L2 cache: 4096K
[   48.265108] using mwait in idle threads.
[   48.265150] CPU: Physical Processor ID: 0
[   48.265191] CPU: Processor Core ID: 0
[   48.265237] CPU0: Thermal monitoring enabled (TM2)
[   48.265284] Freeing SMP alternatives: 33k freed
[   48.265350] ACPI: Core revision 20070126
[   48.278788] Using local APIC timer interrupts.
[   48.320532] result 16650035
[   48.320571] Detected 16.650 MHz APIC timer.
[   48.320815] Booting processor 1/4 APIC 0x2
[   48.331205] Initializing CPU#1
[   48.391721] Calibrating delay using timer specific routine.. 4795.28 BogoMIPS (lpj=2397640)
[   48.391727] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.391728] CPU: L2 cache: 4096K
[   48.391730] CPU: Physical Processor ID: 0
[   48.391731] CPU: Processor Core ID: 2
[   48.391736] CPU1: Thermal monitoring enabled (TM2)
[   48.392159] Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz stepping 07
[   48.392222] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[   48.412781] Booting processor 2/4 APIC 0x1
[   48.423528] Initializing CPU#2
[   48.483700] Calibrating delay using timer specific routine.. 4795.23 BogoMIPS (lpj=2397616)
[   48.483706] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.483708] CPU: L2 cache: 4096K
[   48.483710] CPU: Physical Processor ID: 0
[   48.483711] CPU: Processor Core ID: 1
[   48.483716] CPU2: Thermal monitoring enabled (TM2)
[   48.484157] Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz stepping 07
[   48.484186] checking TSC synchronization [CPU#0 -> CPU#2]: passed.
[   48.504779] Booting processor 3/4 APIC 0x3
[   48.515172] Initializing CPU#3
[   48.575678] Calibrating delay using timer specific routine.. 4795.27 BogoMIPS (lpj=2397638)
[   48.575684] CPU: L1 I cache: 32K, L1 D cache: 32K
[   48.575686] CPU: L2 cache: 4096K
[   48.575688] CPU: Physical Processor ID: 0
[   48.575689] CPU: Processor Core ID: 3
[   48.575694] CPU3: Thermal monitoring enabled (TM2)
[   48.576114] Intel(R) Core(TM)2 Quad CPU           @ 2.40GHz stepping 07
[   48.576188] checking TSC synchronization [CPU#0 -> CPU#3]: passed.
[   48.596679] Brought up 4 CPUs
[   49.216748] migration_cost=17,3461
[   49.217116] NET: Registered protocol family 16
[   49.217217] ACPI: bus type pci registered
[   49.217266] PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved
[   49.217316] PCI: Not using MMCONFIG.
[   49.217368] PCI: Using configuration type 1
[   49.220054] ACPI: Interpreter enabled
[   49.220096] ACPI: Using IOAPIC for interrupt routing
[   49.223600] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   49.223659] PCI: Probing PCI hardware (bus 00)
[   49.224313] PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
[   49.224361] PCI quirk: region 0500-053f claimed by ICH6 GPIO
[   49.225260] PCI: Transparent bridge - 0000:00:1e.0
[   49.225372] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   49.225650] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT]
[   49.225851] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
[   49.225931] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT]
[   49.226010] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
[   49.226090] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
[   49.226169] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
[   49.229348] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12)
[   49.229638] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12)
[   49.229924] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12)
[   49.230250] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12)
[   49.230548] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 *9 10 11 12)
[   49.230834] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12)
[   49.231141] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12)
[   49.231448] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 10 *11 12)
[   49.231825] Linux Plug and Play Support v0.97 (c) Adam Belay
[   49.231875] pnp: PnP ACPI init
[   49.231921] ACPI: bus type pnp registered
[   49.234206] pnp: PnP ACPI: found 12 devices
[   49.234261] ACPI: ACPI bus type pnp unregistered
[   49.234441] SCSI subsystem initialized
[   49.234541] libata version 2.21 loaded.
[   49.234634] usbcore: registered new interface driver usbfs
[   49.234730] usbcore: registered new interface driver hub
[   49.234848] usbcore: registered new device driver usb
[   49.234931] PCI: Using ACPI for IRQ routing
[   49.234973] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   49.235126] PCI-GART: No AMD northbridge found.
[   49.235172] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[   49.235286] hpet0: 3 64-bit timers, 14318180 Hz
[   49.236430] pnp: 00:01: iomem range 0xf0000000-0xf7ffffff has been reserved
[   49.236491] pnp: 00:01: iomem range 0xfed13000-0xfed13fff has been reserved
[   49.236541] Time: tsc clocksource has been installed.
[   49.236597] pnp: 00:01: iomem range 0xfed14000-0xfed17fff has been reserved
[   49.236655] pnp: 00:01: iomem range 0xfed18000-0xfed18fff has been reserved
[   49.236706] pnp: 00:06: ioport range 0x500-0x53f has been reserved
[   49.236773] pnp: 00:06: ioport range 0x400-0x47f has been reserved
[   49.237372] pnp: 00:06: ioport range 0x680-0x6ff has been reserved
[   49.237848] ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 19
[   49.288159] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[e0084000-e00847ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
[   49.288289] PCI: Bridge: 0000:00:1c.0
[   49.288330]   IO window: disabled.
[   49.288373]   MEM window: e0700000-e07fffff
[   49.288416]   PREFETCH window: disabled.
[   49.288460] PCI: Bridge: 0000:00:1c.1
[   49.288501]   IO window: 5000-5fff
[   49.288545]   MEM window: e0400000-e04fffff
[   49.288599]   PREFETCH window: disabled.
[   49.288652] PCI: Bridge: 0000:00:1c.2
[   49.288694]   IO window: 4000-4fff
[   49.288736]   MEM window: e0300000-e03fffff
[   49.288800]   PREFETCH window: e0800000-e08fffff
[   49.288846] PCI: Bridge: 0000:00:1c.3
[   49.288887]   IO window: 3000-3fff
[   49.288930]   MEM window: e0200000-e02fffff
[   49.288973]   PREFETCH window: e0900000-e09fffff
[   49.289018] PCI: Bridge: 0000:00:1c.4
[   49.289060]   IO window: 2000-2fff
[   49.289102]   MEM window: e0100000-e01fffff
[   49.289146]   PREFETCH window: e0a00000-e0afffff
[   49.289192] PCI: Bridge: 0000:00:1e.0
[   49.289233]   IO window: 1000-1fff
[   49.289276]   MEM window: e0000000-e00fffff
[   49.289319]   PREFETCH window: e0b00000-e0bfffff
[   49.289376] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
[   49.289461] PCI: Setting latency timer of device 0000:00:1c.0 to 64
[   49.289474] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16
[   49.289559] PCI: Setting latency timer of device 0000:00:1c.1 to 64
[   49.289573] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
[   49.289677] PCI: Setting latency timer of device 0000:00:1c.2 to 64
[   49.289690] ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
[   49.289773] PCI: Setting latency timer of device 0000:00:1c.3 to 64
[   49.289785] ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17
[   49.289889] PCI: Setting latency timer of device 0000:00:1c.4 to 64
[   49.289897] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[   49.289944] NET: Registered protocol family 2
[   49.300806] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[   49.301356] TCP established hash table entries: 131072 (order: 9, 3145728 bytes)
[   49.302625] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[   49.303110] TCP: Hash tables configured (established 131072 bind 65536)
[   49.303158] TCP reno registered
[   49.307229] Installing knfsd (copyright (C) 1996 [email protected]).
[   49.307421] SGI XFS with large block/inode numbers, no debug enabled
[   49.307761] io scheduler noop registered
[   49.307813] io scheduler anticipatory registered (default)
[   49.307863] Boot video device is 0000:00:02.0
[   49.308278] PCI: Setting latency timer of device 0000:00:1c.0 to 64
[   49.308309] assign_interrupt_mode Found MSI capability
[   49.308380] Allocate Port Service[0000:00:1c.0:pcie00]
[   49.308402] Allocate Port Service[0000:00:1c.0:pcie02]
[   49.308460] PCI: Setting latency timer of device 0000:00:1c.1 to 64
[   49.308491] assign_interrupt_mode Found MSI capability
[   49.308569] Allocate Port Service[0000:00:1c.1:pcie00]
[   49.308602] Allocate Port Service[0000:00:1c.1:pcie02]
[   49.308658] PCI: Setting latency timer of device 0000:00:1c.2 to 64
[   49.308689] assign_interrupt_mode Found MSI capability
[   49.308757] Allocate Port Service[0000:00:1c.2:pcie00]
[   49.308777] Allocate Port Service[0000:00:1c.2:pcie02]
[   49.308835] PCI: Setting latency timer of device 0000:00:1c.3 to 64
[   49.308866] assign_interrupt_mode Found MSI capability
[   49.308933] Allocate Port Service[0000:00:1c.3:pcie00]
[   49.308956] Allocate Port Service[0000:00:1c.3:pcie02]
[   49.309015] PCI: Setting latency timer of device 0000:00:1c.4 to 64
[   49.309045] assign_interrupt_mode Found MSI capability
[   49.309134] Allocate Port Service[0000:00:1c.4:pcie00]
[   49.309156] Allocate Port Service[0000:00:1c.4:pcie02]
[   49.310808] lp: driver loaded but no devices found
[   49.310888] Real Time Clock Driver v1.12ac
[   49.311009] hpet_resources: 0xfed00000 is busy
[   49.311027] Linux agpgart interface v0.102 (c) Dave Jones
[   49.311105] agpgart: Detected an Intel 965G Chipset.
[   49.312363] agpgart: Detected 7676K stolen memory.
[   49.324807] agpgart: AGP aperture is 256M @ 0xd0000000
[   49.324885] [drm] Initialized drm 1.1.0 20060810
[   49.324944] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
[   49.325066] [drm] Initialized i915 1.6.0 20060119 on minor 0
[   49.325167] parport_pc 00:07: reported by Plug and Play ACPI
[   49.325285] parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
[   49.408131] lp0: using parport0 (interrupt-driven).
[   49.408298] loop: module loaded
[   49.408338] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
[   49.408385] Copyright (c) 1999-2006 Intel Corporation.
[   49.408457] ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20
[   49.408565] PCI: Setting latency timer of device 0000:00:19.0 to 64
[   49.427147] e1000: 0000:00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:19:d1:6e:9d:43
[   49.502455] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[   49.502543] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 21 (level, low) -> IRQ 21
[   49.764949] e1000: 0000:06:00.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:00:cd:b1
[   49.911684] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
[   49.911744] ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 22 (level, low) -> IRQ 22
[   50.158693] e1000: 0000:06:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:07:e9:29:37:db
[   50.184398] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
[   50.184493] netconsole: device eth0 not up yet, forcing it
[   50.544713] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0090270001c5be9f]
[   52.444887] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[   52.468712] netconsole: network logging started
[   52.468869] ahci 0000:00:1f.2: version 2.2
[   52.468883] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19
[   53.470122] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[   53.470195] ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part 
[   53.470269] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[   53.470484] scsi0 : ahci
[   53.470599] scsi1 : ahci
[   53.470694] scsi2 : ahci
[   53.470792] scsi3 : ahci
[   53.470892] scsi4 : ahci
[   53.471005] scsi5 : ahci
[   53.471098] ata1: SATA max UDMA/133 cmd 0xffffc2000002e100 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.471178] ata2: SATA max UDMA/133 cmd 0xffffc2000002e180 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.471256] ata3: SATA max UDMA/133 cmd 0xffffc2000002e200 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.471334] ata4: SATA max UDMA/133 cmd 0xffffc2000002e280 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.471412] ata5: SATA max UDMA/133 cmd 0xffffc2000002e300 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.471498] ata6: SATA max UDMA/133 cmd 0xffffc2000002e380 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   53.981909] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   53.985309] ata1.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   53.985379] ata1.00: ATA-6: WDC WD740GD-00FLC0, 33.08F33, max UDMA/133
[   53.985436] ata1.00: 145226112 sectors, multi 0: LBA48 
[   53.989871] ata1.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   53.989943] ata1.00: configured for UDMA/133
[   54.448246] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   54.451681] ata2.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   54.451751] ata2.00: ATA-6: WDC WD740GD-00FLC0, 33.08F33, max UDMA/133
[   54.451806] ata2.00: 145226112 sectors, multi 0: LBA48 
[   54.456220] ata2.00: ata_hpa_resize 1: sectors = 145226112, hpa_sectors = 145226112
[   54.456291] ata2.00: configured for UDMA/133
[   54.915523] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   54.917712] ata3.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   54.917783] ata3.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   54.917856] ata3.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   54.920699] ata3.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   54.920771] ata3.00: configured for UDMA/133
[   55.378761] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   55.380949] ata4.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.381029] ata4.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   55.381100] ata4.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   55.383936] ata4.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.384008] ata4.00: configured for UDMA/133
[   55.843019] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   55.845093] ata5.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.845164] ata5.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   55.845230] ata5.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   55.847887] ata5.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   55.847960] ata5.00: configured for UDMA/133
[   56.307338] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   56.309375] ata6.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.309446] ata6.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   56.309502] ata6.00: 293046768 sectors, multi 0: LBA48 NCQ (depth 31/32)
[   56.312166] ata6.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.312238] ata6.00: configured for UDMA/133
[   56.312366] scsi 0:0:0:0: Direct-Access     ATA      WDC WD740GD-00FL 33.0 PQ: 0 ANSI: 5
[   56.312519] sd 0:0:0:0: [sda] 145226112 512-byte hardware sectors (74356 MB)
[   56.312587] sd 0:0:0:0: [sda] Write Protect is off
[   56.312643] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   56.312654] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.312764] sd 0:0:0:0: [sda] 145226112 512-byte hardware sectors (74356 MB)
[   56.312830] sd 0:0:0:0: [sda] Write Protect is off
[   56.312888] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   56.312899] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.312989]  sda: sda1 sda2 sda3
[   56.322761] sd 0:0:0:0: [sda] Attached SCSI disk
[   56.322978] scsi 1:0:0:0: Direct-Access     ATA      WDC WD740GD-00FL 33.0 PQ: 0 ANSI: 5
[   56.323159] sd 1:0:0:0: [sdb] 145226112 512-byte hardware sectors (74356 MB)
[   56.323221] sd 1:0:0:0: [sdb] Write Protect is off
[   56.323274] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[   56.323289] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.323398] sd 1:0:0:0: [sdb] 145226112 512-byte hardware sectors (74356 MB)
[   56.323462] sd 1:0:0:0: [sdb] Write Protect is off
[   56.323513] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[   56.323528] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.323632]  sdb: sdb1 sdb2 sdb3
[   56.330482] sd 1:0:0:0: [sdb] Attached SCSI disk
[   56.330653] scsi 2:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.330826] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
[   56.330886] sd 2:0:0:0: [sdc] Write Protect is off
[   56.330942] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[   56.330958] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.331061] sd 2:0:0:0: [sdc] 293046768 512-byte hardware sectors (150040 MB)
[   56.331128] sd 2:0:0:0: [sdc] Write Protect is off
[   56.331176] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[   56.331191] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.331295]  sdc: sdc1
[   56.335795] sd 2:0:0:0: [sdc] Attached SCSI disk
[   56.335938] scsi 3:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.336132] sd 3:0:0:0: [sdd] 293046768 512-byte hardware sectors (150040 MB)
[   56.336206] sd 3:0:0:0: [sdd] Write Protect is off
[   56.336253] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[   56.336263] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.336374] sd 3:0:0:0: [sdd] 293046768 512-byte hardware sectors (150040 MB)
[   56.336431] sd 3:0:0:0: [sdd] Write Protect is off
[   56.336478] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[   56.336488] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.336580]  sdd: sdd1
[   56.343788] sd 3:0:0:0: [sdd] Attached SCSI disk
[   56.343935] scsi 4:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.344106] sd 4:0:0:0: [sde] 293046768 512-byte hardware sectors (150040 MB)
[   56.344166] sd 4:0:0:0: [sde] Write Protect is off
[   56.344220] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
[   56.344235] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.344339] sd 4:0:0:0: [sde] 293046768 512-byte hardware sectors (150040 MB)
[   56.344403] sd 4:0:0:0: [sde] Write Protect is off
[   56.344454] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00
[   56.344469] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.344573]  sde: sde1
[   56.355511] sd 4:0:0:0: [sde] Attached SCSI disk
[   56.355657] scsi 5:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   56.355824] sd 5:0:0:0: [sdf] 293046768 512-byte hardware sectors (150040 MB)
[   56.355884] sd 5:0:0:0: [sdf] Write Protect is off
[   56.355937] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[   56.355952] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.356059] sd 5:0:0:0: [sdf] 293046768 512-byte hardware sectors (150040 MB)
[   56.356126] sd 5:0:0:0: [sdf] Write Protect is off
[   56.356174] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[   56.356189] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   56.356293]  sdf: sdf1
[   56.361893] sd 5:0:0:0: [sdf] Attached SCSI disk
[   56.362122] sata_sil24 0000:03:00.0: version 0.9
[   56.362153] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 18 (level, low) -> IRQ 18
[   56.362327] PCI: Setting latency timer of device 0000:03:00.0 to 64
[   56.362382] scsi6 : sata_sil24
[   56.362501] scsi7 : sata_sil24
[   56.362616] ata7: SATA max UDMA/100 cmd 0xffffc20000038000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   56.362703] ata8: SATA max UDMA/100 cmd 0xffffc2000003a000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   56.766751] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   56.769241] ata7.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.769313] ata7.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   56.769369] ata7.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   56.772597] ata7.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   56.772670] ata7.00: configured for UDMA/100
[   57.176868] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   57.179393] ata8.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.179460] ata8.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   57.179511] ata8.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   57.182775] ata8.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.182847] ata8.00: configured for UDMA/100
[   57.182955] scsi 6:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   57.183126] sd 6:0:0:0: [sdg] 293046768 512-byte hardware sectors (150040 MB)
[   57.183191] sd 6:0:0:0: [sdg] Write Protect is off
[   57.183238] sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00
[   57.183248] sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.183361] sd 6:0:0:0: [sdg] 293046768 512-byte hardware sectors (150040 MB)
[   57.183418] sd 6:0:0:0: [sdg] Write Protect is off
[   57.183485] sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00
[   57.183495] sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.183566]  sdg: sdg1
[   57.194888] sd 6:0:0:0: [sdg] Attached SCSI disk
[   57.195063] scsi 7:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   57.195213] sd 7:0:0:0: [sdh] 293046768 512-byte hardware sectors (150040 MB)
[   57.195275] sd 7:0:0:0: [sdh] Write Protect is off
[   57.195327] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00
[   57.195342] sd 7:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.195470] sd 7:0:0:0: [sdh] 293046768 512-byte hardware sectors (150040 MB)
[   57.195526] sd 7:0:0:0: [sdh] Write Protect is off
[   57.195593] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00
[   57.195603] sd 7:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   57.195675]  sdh: sdh1
[   57.206857] sd 7:0:0:0: [sdh] Attached SCSI disk
[   57.206966] ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
[   57.207106] PCI: Setting latency timer of device 0000:04:00.0 to 64
[   57.207188] scsi8 : sata_sil24
[   57.207305] scsi9 : sata_sil24
[   57.207422] ata9: SATA max UDMA/100 cmd 0xffffc20000068000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   57.207507] ata10: SATA max UDMA/100 cmd 0xffffc2000006a000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   57.612628] ata9: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   57.614742] ata9.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.614823] ata9.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   57.614874] ata9.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   57.617628] ata9.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   57.617700] ata9.00: configured for UDMA/100
[   58.022845] ata10: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   58.024964] ata10.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.025035] ata10.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   58.025100] ata10.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   58.027875] ata10.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.027949] ata10.00: configured for UDMA/100
[   58.028056] scsi 8:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   58.028242] sd 8:0:0:0: [sdi] 293046768 512-byte hardware sectors (150040 MB)
[   58.028302] sd 8:0:0:0: [sdi] Write Protect is off
[   58.028354] sd 8:0:0:0: [sdi] Mode Sense: 00 3a 00 00
[   58.028370] sd 8:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.028474] sd 8:0:0:0: [sdi] 293046768 512-byte hardware sectors (150040 MB)
[   58.028540] sd 8:0:0:0: [sdi] Write Protect is off
[   58.028591] sd 8:0:0:0: [sdi] Mode Sense: 00 3a 00 00
[   58.028606] sd 8:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.028710]  sdi: sdi1
[   58.038904] sd 8:0:0:0: [sdi] Attached SCSI disk
[   58.039042] scsi 9:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   58.039193] sd 9:0:0:0: [sdj] 293046768 512-byte hardware sectors (150040 MB)
[   58.039253] sd 9:0:0:0: [sdj] Write Protect is off
[   58.039305] sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00
[   58.039320] sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.039454] sd 9:0:0:0: [sdj] 293046768 512-byte hardware sectors (150040 MB)
[   58.039519] sd 9:0:0:0: [sdj] Write Protect is off
[   58.039566] sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00
[   58.039576] sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.039668]  sdj: sdj1
[   58.047213] sd 9:0:0:0: [sdj] Attached SCSI disk
[   58.047352] ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[   58.047504] PCI: Setting latency timer of device 0000:05:00.0 to 64
[   58.047552] scsi10 : sata_sil24
[   58.047668] scsi11 : sata_sil24
[   58.047787] ata11: SATA max UDMA/100 cmd 0xffffc20000070000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   58.047872] ata12: SATA max UDMA/100 cmd 0xffffc20000072000 ctl 0x0000000000000000 bmdma 0x0000000000000000 irq 0
[   58.452485] ata11: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   58.454979] ata11.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.455050] ata11.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   58.455135] ata11.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   58.458386] ata11.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.458459] ata11.00: configured for UDMA/100
[   58.862662] ata12: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   58.865167] ata12.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.865238] ata12.00: ATA-7: WDC WD1500ADFD-00NLR1, 20.07P20, max UDMA/133
[   58.865294] ata12.00: 293046768 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   58.868544] ata12.00: ata_hpa_resize 1: sectors = 293046768, hpa_sectors = 293046768
[   58.868617] ata12.00: configured for UDMA/100
[   58.868723] scsi 10:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   58.868881] sd 10:0:0:0: [sdk] 293046768 512-byte hardware sectors (150040 MB)
[   58.868983] sd 10:0:0:0: [sdk] Write Protect is off
[   58.869031] sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00
[   58.869041] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.869152] sd 10:0:0:0: [sdk] 293046768 512-byte hardware sectors (150040 MB)
[   58.869237] sd 10:0:0:0: [sdk] Write Protect is off
[   58.869292] sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00
[   58.869302] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.869374]  sdk: sdk1
[   58.877168] sd 10:0:0:0: [sdk] Attached SCSI disk
[   58.877349] scsi 11:0:0:0: Direct-Access     ATA      WDC WD1500ADFD-0 20.0 PQ: 0 ANSI: 5
[   58.877517] sd 11:0:0:0: [sdl] 293046768 512-byte hardware sectors (150040 MB)
[   58.877593] sd 11:0:0:0: [sdl] Write Protect is off
[   58.877645] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00
[   58.877661] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.877767] sd 11:0:0:0: [sdl] 293046768 512-byte hardware sectors (150040 MB)
[   58.877847] sd 11:0:0:0: [sdl] Write Protect is off
[   58.877898] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00
[   58.877913] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   58.878019]  sdl: sdl1
[   58.885496] sd 11:0:0:0: [sdl] Attached SCSI disk
[   58.885641] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
[   58.885756] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   58.885790] scsi12 : pata_marvell
[   58.885892] scsi13 : pata_marvell
[   58.886030] ata13: PATA max UDMA/100 cmd 0x0000000000015018 ctl 0x0000000000015026 bmdma 0x0000000000015000 irq 0
[   58.886113] ata14: DUMMY
[   58.886182] 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.192728] ata13.00: ATAPI, max UDMA/33
[   59.349867] ata13.00: configured for UDMA/33
[   59.350932] scsi 12:0:0:0: CD-ROM            _NEC     DVD_RW ND-3520A  1.04 PQ: 0 ANSI: 5
[   59.355097] sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
[   59.355179] Uniform CD-ROM driver Revision: 3.20
[   59.355295] sr 12:0:0:0: Attached scsi CD-ROM sr0
[   59.355382] ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18
[   59.355485] PCI: Setting latency timer of device 0000:00:1a.7 to 64
[   59.355489] ehci_hcd 0000:00:1a.7: EHCI Host Controller
[   59.355585] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1
[   59.355679] ehci_hcd 0000:00:1a.7: debug port 1
[   59.355733] PCI: cache line size of 32 is not supported by device 0000:00:1a.7
[   59.355738] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xe0625c00
[   59.359701] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   59.359916] usb usb1: configuration #1 chosen from 1 choice
[   59.360043] hub 1-0:1.0: USB hub found
[   59.360100] hub 1-0:1.0: 4 ports detected
[   59.460812] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23
[   59.460915] PCI: Setting latency timer of device 0000:00:1d.7 to 64
[   59.460940] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   59.461058] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2
[   59.461166] ehci_hcd 0000:00:1d.7: debug port 1
[   59.461227] PCI: cache line size of 32 is not supported by device 0000:00:1d.7
[   59.461232] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xe0625800
[   59.465147] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   59.465349] usb usb2: configuration #1 chosen from 1 choice
[   59.465475] hub 2-0:1.0: USB hub found
[   59.465531] hub 2-0:1.0: 6 ports detected
[   59.566560] USB Universal Host Controller Interface driver v3.0
[   59.566659] ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
[   59.566756] PCI: Setting latency timer of device 0000:00:1a.0 to 64
[   59.566759] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[   59.566879] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[   59.566973] uhci_hcd 0000:00:1a.0: irq 16, io base 0x000060c0
[   59.567170] usb usb3: configuration #1 chosen from 1 choice
[   59.567298] hub 3-0:1.0: USB hub found
[   59.567937] hub 3-0:1.0: 2 ports detected
[   59.668727] ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 21 (level, low) -> IRQ 21
[   59.668825] PCI: Setting latency timer of device 0000:00:1a.1 to 64
[   59.668829] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[   59.668968] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[   59.669063] uhci_hcd 0000:00:1a.1: irq 21, io base 0x000060a0
[   59.669258] usb usb4: configuration #1 chosen from 1 choice
[   59.669386] hub 4-0:1.0: USB hub found
[   59.669442] hub 4-0:1.0: 2 ports detected
[   59.770816] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
[   59.770915] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[   59.770929] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   59.771061] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
[   59.771144] uhci_hcd 0000:00:1d.0: irq 23, io base 0x00006080
[   59.771355] usb usb5: configuration #1 chosen from 1 choice
[   59.771481] hub 5-0:1.0: USB hub found
[   59.771537] hub 5-0:1.0: 2 ports detected
[   59.872869] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
[   59.872966] PCI: Setting latency timer of device 0000:00:1d.1 to 64
[   59.872970] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   59.873098] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
[   59.873201] uhci_hcd 0000:00:1d.1: irq 19, io base 0x00006060
[   59.873394] usb usb6: configuration #1 chosen from 1 choice
[   59.873522] hub 6-0:1.0: USB hub found
[   59.873579] hub 6-0:1.0: 2 ports detected
[   59.974945] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
[   59.975042] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[   59.975046] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   59.975185] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7
[   59.975288] uhci_hcd 0000:00:1d.2: irq 18, io base 0x00006040
[   59.975488] usb usb7: configuration #1 chosen from 1 choice
[   59.975613] hub 7-0:1.0: USB hub found
[   59.975670] hub 7-0:1.0: 2 ports detected
[   60.077046] Initializing USB Mass Storage driver...
[   60.080010] usb 5-1: new low speed USB device using uhci_hcd and address 2
[   60.244227] usb 5-1: configuration #1 chosen from 1 choice
[   60.247286] usbcore: registered new interface driver usb-storage
[   60.247337] USB Mass Storage support registered.
[   60.247477] PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
[   60.250401] serio: i8042 KBD port at 0x60,0x64 irq 1
[   60.250448] serio: i8042 AUX port at 0x60,0x64 irq 12
[   60.250547] mice: PS/2 mouse device common for all mice
[   60.250886] input: PC Speaker as /class/input/input0
[   60.250976] i2c /dev entries driver
[   60.251125] coretemp coretemp.0: Using undocumented features, absolute temperature might be wrong!
[   60.251289] coretemp coretemp.1: Using undocumented features, absolute temperature might be wrong!
[   60.251442] coretemp coretemp.2: Using undocumented features, absolute temperature might be wrong!
[   60.251595] coretemp coretemp.3: Using undocumented features, absolute temperature might be wrong!
[   60.251733] md: raid1 personality registered for level 1
[   60.268013] raid6: int64x1   2027 MB/s
[   60.285002] raid6: int64x2   2781 MB/s
[   60.301998] raid6: int64x4   3101 MB/s
[   60.318996] raid6: int64x8   1914 MB/s
[   60.335979] raid6: sse2x1    3824 MB/s
[   60.352979] raid6: sse2x2    4222 MB/s
[   60.369967] raid6: sse2x4    6777 MB/s
[   60.370029] raid6: using algorithm sse2x4 (6777 MB/s)
[   60.370091] md: raid6 personality registered for level 6
[   60.370148] md: raid5 personality registered for level 5
[   60.370216] md: raid4 personality registered for level 4
[   60.370262] raid5: automatically using best checksumming function: generic_sse
[   60.374963]    generic_sse:  8524.000 MB/sec
[   60.375006] raid5: using function: generic_sse (8524.000 MB/sec)
[   60.375269] usbcore: registered new interface driver hiddev
[   60.823087] hiddev96: USB HID v1.00 Device [        UPS] on usb-0000:00:1d.0-1
[   60.823210] usbcore: registered new interface driver usbhid
[   60.823260] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[   60.823328] Advanced Linux Sound Architecture Driver Version 1.0.14 (Thu May 31 09:03:25 2007 UTC).
[   60.823664] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22
[   60.823775] PCI: Setting latency timer of device 0000:00:1b.0 to 64
[   60.892415] input: ImPS/2 Generic Wheel Mouse as /class/input/input1
[   60.916271] input: AT Translated Set 2 keyboard as /class/input/input2
[   60.957332] ALSA device list:
[   60.957377]   #0: HDA Intel at 0xe0620000 irq 22
[   60.957429] u32 classifier
[   60.957482]     Actions configured 
[   60.957527] nf_conntrack version 0.5.0 (8192 buckets, 65536 max)
[   60.957781] ip_tables: (C) 2000-2006 Netfilter Core Team
[   60.957880] TCP cubic registered
[   60.957937] NET: Registered protocol family 1
[   60.957994] NET: Registered protocol family 17
[   60.958370] md: Autodetecting RAID arrays.
[   61.110568] md: autorun ...
[   61.110608] md: considering sdl1 ...
[   61.110657] md:  adding sdl1 ...
[   61.110699] md:  adding sdk1 ...
[   61.110764] md:  adding sdj1 ...
[   61.110811] md:  adding sdi1 ...
[   61.110855] md:  adding sdh1 ...
[   61.110910] md:  adding sdg1 ...
[   61.110962] md:  adding sdf1 ...
[   61.111007] md:  adding sde1 ...
[   61.111052] md:  adding sdd1 ...
[   61.111095] md:  adding sdc1 ...
[   61.111139] md: sdb3 has different UUID to sdl1
[   61.111186] md: sdb2 has different UUID to sdl1
[   61.111233] md: sdb1 has different UUID to sdl1
[   61.111279] md: sda3 has different UUID to sdl1
[   61.111326] md: sda2 has different UUID to sdl1
[   61.111374] md: sda1 has different UUID to sdl1
[   61.111489] md: created md3
[   61.111542] md: bind<sdc1>
[   61.111588] md: bind<sdd1>
[   61.111632] md: bind<sde1>
[   61.111678] md: bind<sdf1>
[   61.111724] md: bind<sdg1>
[   61.111770] md: bind<sdh1>
[   61.111841] md: bind<sdi1>
[   61.111886] md: bind<sdj1>
[   61.111932] md: bind<sdk1>
[   61.111999] md: bind<sdl1>
[   61.112045] md: running: <sdl1><sdk1><sdj1><sdi1><sdh1><sdg1><sdf1><sde1><sdd1><sdc1>
[   61.112350] raid5: device sdl1 operational as raid disk 2
[   61.112401] raid5: device sdk1 operational as raid disk 3
[   61.112448] raid5: device sdj1 operational as raid disk 0
[   61.112496] raid5: device sdi1 operational as raid disk 1
[   61.112543] raid5: device sdh1 operational as raid disk 6
[   61.112591] raid5: device sdg1 operational as raid disk 5
[   61.112639] raid5: device sdf1 operational as raid disk 4
[   61.112686] raid5: device sde1 operational as raid disk 7
[   61.112734] raid5: device sdd1 operational as raid disk 8
[   61.112782] raid5: device sdc1 operational as raid disk 9
[   61.113360] raid5: allocated 10562kB for md3
[   61.113406] raid5: raid level 5 set md3 active with 10 out of 10 devices, algorithm 2
[   61.113474] RAID5 conf printout:
[   61.113517]  --- rd:10 wd:10
[   61.113559]  disk 0, o:1, dev:sdj1
[   61.113602]  disk 1, o:1, dev:sdi1
[   61.113646]  disk 2, o:1, dev:sdl1
[   61.113687]  disk 3, o:1, dev:sdk1
[   61.113730]  disk 4, o:1, dev:sdf1
[   61.113774]  disk 5, o:1, dev:sdg1
[   61.113819]  disk 6, o:1, dev:sdh1
[   61.113862]  disk 7, o:1, dev:sde1
[   61.113926]  disk 8, o:1, dev:sdd1
[   61.113970]  disk 9, o:1, dev:sdc1
[   61.114083] md: considering sdb3 ...
[   61.114140] md:  adding sdb3 ...
[   61.114184] md: sdb2 has different UUID to sdb3
[   61.114230] md: sdb1 has different UUID to sdb3
[   61.114278] md:  adding sda3 ...
[   61.114320] md: sda2 has different UUID to sdb3
[   61.114366] md: sda1 has different UUID to sdb3
[   61.114482] md: created md2
[   61.114534] md: bind<sda3>
[   61.114577] md: bind<sdb3>
[   61.114624] md: running: <sdb3><sda3>
[   61.114765] raid1: raid set md2 active with 2 out of 2 mirrors
[   61.114873] md: considering sdb2 ...
[   61.114929] md:  adding sdb2 ...
[   61.114984] md: sdb1 has different UUID to sdb2
[   61.115040] md:  adding sda2 ...
[   61.115084] md: sda1 has different UUID to sdb2
[   61.115219] md: created md1
[   61.115271] md: bind<sda2>
[   61.115317] md: bind<sdb2>
[   61.115361] md: running: <sdb2><sda2>
[   61.115499] raid1: raid set md1 active with 2 out of 2 mirrors
[   61.115609] md: considering sdb1 ...
[   61.115665] md:  adding sdb1 ...
[   61.115710] md:  adding sda1 ...
[   61.115753] md: created md0
[   61.115794] md: bind<sda1>
[   61.115840] md: bind<sdb1>
[   61.115887] md: running: <sdb1><sda1>
[   61.116029] raid1: raid set md0 active with 2 out of 2 mirrors
[   61.116720] md: ... autorun DONE.
[   61.146509] UDF-fs: No VRS found
[   61.146710] Filesystem "md2": Disabling barriers, not supported by the underlying device
[   61.156442] XFS mounting filesystem md2
[   61.237815] Ending clean XFS mount for filesystem: md2
[   61.237835] VFS: Mounted root (xfs filesystem) readonly.
[   61.237927] Freeing unused kernel memory: 216k freed
[   63.224910] Adding 16787768k swap on /dev/md0.  Priority:-1 extents:1 across:16787768k
[   63.273053] Filesystem "md2": Disabling barriers, not supported by the underlying device
[   64.303771] kjournald starting.  Commit interval 5 seconds
[   64.309323] EXT3 FS on md1, internal journal
[   64.309396] EXT3-fs: mounted filesystem with ordered data mode.
[   64.310221] Filesystem "md3": Disabling barriers, not supported by the underlying device
[   64.310483] XFS mounting filesystem md3
[   64.563068] Ending clean XFS mount for filesystem: md3
[   82.790183] e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
[   84.590210] process `syslogd' is using obsolete setsockopt SO_BSDCOMPAT
[  106.449661] mtrr: no more MTRRs available
#17 lore raw
In reply to Jesse Barnes
Quoted 9 lines · Jesse Barnes
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

It's called "kernel log buffer size" and it's in "General setup".

Jesse

Seems stable & fast so far, except when it hit swap :)

top - 18:38:13 up 5 min, 6 users, load average: 38.56, 12.65, 4.52

Tasks: 227 total,  64 running, 163 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us, 23.9%sy,  0.0%ni,  0.0%id, 72.7%wa,  0.0%hi,  3.4%si,  0.0%st
Cpu1  :  0.0%us, 23.5%sy,  0.0%ni,  1.0%id, 75.5%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us, 24.1%sy,  0.0%ni,  0.0%id, 75.9%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us, 23.6%sy,  0.0%ni,  0.0%id, 76.4%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8039576k total,  7998988k used,    40588k free,       12k buffers
Swap: 16787768k total,   879324k used, 15908444k free,    16316k cached

Tested with

$ stress --vm 32 --vm-bytes 250M
and
$ stress --vm 64 --vm-bytes 250M
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  248 root      10  -5     0    0    0 D   18  0.0   0:07.81 kswapd0
 3788 war       18   0  256m 115m  164 D    3  1.5   0:01.32 stress
 3800 war       18   0  256m 7300  160 R    3  0.1   0:00.58 stress
 3801 war       18   0  256m  34m  160 R    3  0.4   0:02.48 stress
 3808 war       18   0  256m 217m  164 R    3  2.8   0:01.16 stress
  559 root      10  -5     0    0    0 D    2  0.0   0:00.15 md0_raid1
 3771 war       18   0  256m 174m  164 R    2  2.2   0:01.30 stress
 3785 war       18   0  256m  30m  164 R    2  0.4   0:01.42 stress
 3813 war       18   0  256m  34m  164 R    2  0.4   0:01.06 stress
 3787 war       18   0  256m  24m  160 R    2  0.3   0:00.25 stress
 3794 war       18   0  256m  40m  160 R    2  0.5   0:00.14 stress
 3778 war       18   0  256m 109m  164 R    2  1.4   0:01.23 stress
 3783 war       18   0  256m 185m  164 R    2  2.4   0:01.29 stress
 3799 war       18   0  256m 172m  164 R    2  2.2   0:01.07 stress
 3816 war       18   0  256m 203m  160 R    2  2.6   0:00.39 stress
 3819 war       18   0  256m 144m  160 R    2  1.8   0:00.40 stress
 3820 war       18   0  256m 147m  160 R    2  1.9   0:00.39 stress
 3825 war       18   0  256m  91m  164 R    2  1.2   0:01.16 stress
 3777 war       18   0  256m  29m  164 R    1  0.4   0:01.05 stress
 3779 war       18   0  256m 197m  164 R    1  2.5   0:01.29 stress
 3805 war       18   0  256m 216m  160 R    1  2.8   0:00.36 stress
 3812 war       18   0  256m  30m  164 R    1  0.4   0:01.14 stress
 3830 war       18   0  256m 176m  164 R    1  2.3   0:01.17 stress
 3831 war       18   0  256m  64m  164 R    1  0.8   0:01.40 stress
 3769 war       18   0  256m  43m  164 R    1  0.6   0:01.23 stress
 3770 war       18   0  256m 169m  164 R    1  2.2   0:01.18 stress
 3773 war       18   0  256m  44m  160 R    1  0.6   0:00.29 stress
 3774 war       18   0  256m  21m  160 R    1  0.3   0:00.21 stress
 3780 war       18   0  256m 167m  164 R    1  2.1   0:01.33 stress
 3781 war       18   0  256m 143m  164 R    1  1.8   0:01.35 stress
 3798 war       18   0  256m 153m  164 R    1  1.9   0:01.16 stress
 3807 war       18   0  256m  31m  164 R    1  0.4   0:01.17 stress
 3817 war       18   0  256m 185m  160 R    1  2.4   0:00.40 stress
 3822 war       18   0  256m 200m  160 R    1  2.6   0:00.41 stress
 3824 war       18   0  256m 8684  160 R    1  0.1   0:00.16 stress
 3827 war       18   0  256m 103m  164 R    1  1.3   0:00.95 stress
 3828 war       18   0  256m 1976  160 R    1  0.0   0:00.19 stress
 2026 daemon    30  15 30580  436  372 D    1  0.0   0:02.10 bindgraph.pl
 3768 war       18   0  256m  81m  164 R    1  1.0   0:01.84 stress
 3772 war       18   0  256m 158m  164 R    1  2.0   0:01.11 stress
 3782 war       18   0  256m 180m  164 R    1  2.3   0:01.25 stress
 3786 war       18   0  256m 173m  164 R    1  2.2   0:01.13 stress
 3790 war       18   0  256m  20m  164 R    1  0.3   0:01.10 stress
 3791 war       18   0  256m  36m  164 R    1  0.5   0:01.80 stress
 3796 war       18   0  256m 111m  164 R    1  1.4   0:01.04 stress
 3797 war       18   0  256m 120m  164 R    1  1.5   0:01.12 stress
 3803 war       18   0  256m 129m  160 R    1  1.6   0:01.98 stress
 3804 war       18   0  256m 234m  160 R    1  3.0   0:00.40 stress
 3806 war       18   0  256m  49m  164 R    1  0.6   0:00.99 stress
 3809 war       18   0  256m  54m  164 R    1  0.7   0:01.16 stress
 3814 war       18   0  256m  38m  164 R    1  0.5   0:00.97 stress
 3815 war       18   0  256m  69m  164 R    1  0.9   0:01.06 stress
  246 root      15   0     0    0    0 D    0  0.0   0:00.01 pdflush
 3687 war       15   0 18012  896  560 R    0  0.0   0:00.88 top
 3775 war       18   0  256m 153m  164 R    0  2.0   0:01.14 stress
 3776 war       18   0  256m  55m  164 R    0  0.7   0:01.34 stress
 3784 war       18   0  256m  13m  164 R    0  0.2   0:00.96 stress
 3789 war       18   0  256m  46m  164 R    0  0.6   0:01.54 stress
 3792 war       18   0  256m  12m  164 R    0  0.2   0:01.00 stress
 3793 war       18   0  256m  44m  164 R    0  0.6   0:00.96 stress
 3795 war       18   0  256m 196m  164 R    0  2.5   0:01.06 stress
 3802 war       18   0  256m  22m  160 R    0  0.3   0:02.70 stress
 3810 war       18   0  256m  40m  164 R    0  0.5   0:01.06 stress
 3818 war       18   0  256m 146m  160 R    0  1.9   0:00.34 stress
 3829 war       18   0  256m 130m  164 R    0  1.7   0:01.11 stress
  247 root      15   0     0    0    0 D    0  0.0   0:00.01 pdflush
  554 root      10  -5     0    0    0 D    0  0.0   0:00.01 md2_raid1
 3811 war       18   0  256m  61m  160 R    0  0.8   0:05.85 stress
 3821 war       18   0  256m 136m  160 R    0  1.7   0:00.37 stress
 3823 war       18   0  256m 204m  160 R    0  2.6   0:00.34 stress
 3826 war       18   0  256m  95m  164 R    0  1.2   0:01.03 stress
#18 lore raw
In reply to Jesse Barnes
Quoted 6 lines · On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

It's called "kernel log buffer size" and it's in "General setup".

or you can just boot with "log_buf_len=256k" on the kernel boot line (e.g.)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

#19 lore raw
Quoted 7 lines · Randy Dunlap
Quoted 5 lines · On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

Quoted 8 lines
Quoted 1 line

It's called "kernel log buffer size" and it's in "General setup".

or you can just boot with "log_buf_len=256k" on the kernel boot line (e.g.)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Thanks, very useful note!

$ stress --vm 32 --vm-bytes 250M
stress: info: [4087] dispatching hogs: 0 cpu, 0 io, 32 vm, 0 hdd
Mem:   8039576k total,  5288036k used,  2751540k free,       12k buffers
Swap:        0k total,        0k used,        0k free,    37944k cached
$ stress --vm 40 --vm-bytes 250M
stress: info: [4120] dispatching hogs: 0 cpu, 0 io, 40 vm, 0 hdd
Mem:   8039576k total,  6661484k used,  1378092k free,       12k buffers
Swap:        0k total,        0k used,        0k free,    38000k cached
$ stress --vm 42 --vm-bytes 250M
stress: info: [4398] dispatching hogs: 0 cpu, 0 io, 42 vm, 0 hdd
Mem:   8039576k total,  6447048k used,  1592528k free,        8k buffers
Swap:        0k total,        0k used,        0k free,    11148k cached
$ stress --vm 45 --vm-bytes 250M
stress: info: [4352] dispatching hogs: 0 cpu, 0 io, 45 vm, 0 hdd
stress: FAIL: [4372] (494) hogvm malloc failed: Cannot allocate memory
stress: FAIL: [4352] (395) <-- worker 4372 returned error 1
stress: WARN: [4352] (397) now reaping child worker processes
stress: FAIL: [4352] (452) failed run completed in 4s
$ stress --vm 48 --vm-bytes 250M
stress: info: [4303] dispatching hogs: 0 cpu, 0 io, 48 vm, 0 hdd
stress: FAIL: [4323] (494) hogvm malloc failed: Cannot allocate memory
stress: FAIL: [4322] (494) hogvm malloc failed: Cannot allocate memory
stress: FAIL: [4303] (395) <-- worker 4323 returned error 1
stress: WARN: [4303] (397) now reaping child worker processes
stress: FAIL: [4303] (395) <-- worker 4322 returned error 1
stress: WARN: [4303] (397) now reaping child worker processes
stress: FAIL: [4303] (452) failed run completed in 4s

Is there a better way to verify I can use all the available memory?

Justin.

#20 lore raw
In reply to Randy Dunlap
Quoted 7 lines · Randy Dunlap
Quoted 5 lines · On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

Quoted 8 lines
Quoted 1 line

It's called "kernel log buffer size" and it's in "General setup".

or you can just boot with "log_buf_len=256k" on the kernel boot line (e.g.)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Hm, not sure if it was from the patch or what but I ran this:

1. swapoff -a
2. ./eatmem

The machine responded to ping and alt-sysrq-b but the box remain unresponsive, I guess the kernel did not kill the process? :(

The moments before it 'froze'

top - 18:48:01 up 15 min, 7 users, load average: 6.61, 18.50, 13.31

Tasks: 200 total,  18 running, 182 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us, 90.7%sy,  0.0%ni,  5.9%id,  3.3%wa,  0.0%hi,  0.0%si, 0.0%st
Mem:   8039576k total,  7998860k used,    40716k free,        8k buffers
Swap:        0k total,        0k used,        0k free,     1664k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  248 root      11  -5     0    0    0 R   85  0.0   0:16.05 kswapd0
 2265 nut       18   0 13320  244    4 R   40  0.0   0:03.13 newhidups
 2267 nut       18   0 12216  168    4 R   40  0.0   0:02.04 upsd
 2474 ntp       18   0 22192  400    8 R   39  0.0   0:02.00 ntpd
 3563 jpiszcz   18   0 41964 1264    4 R   38  0.0   0:02.20 pine
 3530 root      18   0 96240 3132   36 R   37  0.0   0:02.09 kdm_greet
 2052 root      18   0  6080  112    4 R   37  0.0   0:02.00 hald-addon-stor
 4479 war       17   0 18012  700  252 R   33  0.0   0:01.81 top
 4480 war       19   0 6948m 6.8g    4 R   22 88.4   0:05.81 eatmem
 2095 root      18   0 13128  216    8 R   10  0.0   0:00.50 dirmngr
 2545 root      18   0 95788 2488    4 R    5  0.0   0:00.25 apache2
 3564 war       18   0 41620  832    4 R    5  0.0   0:00.34 pine
 2270 nut       15   0 12212  144    4 S    1  0.0   0:00.05 upsmon
  561 root      10  -5     0    0    0 S    0  0.0   0:00.02 xfsbufd

Very simply program:

#include <iostream>
using namespace std;

int main()
{
long int interations = 10000000;
int counter = 1;

  for(counter;counter<interations;counter++)
  {
     double *d = new double[100];
  }

return 0;
}

Any idea why the OOM killer can or does not kill it?

Justin.

#21 lore raw
Quoted 38 lines · On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:

Hm, not sure if it was from the patch or what but I ran this:

1. swapoff -a
2. ./eatmem

The machine responded to ping and alt-sysrq-b but the box remain unresponsive, I guess the kernel did not kill the process? :(

The moments before it 'froze'

top - 18:48:01 up 15 min, 7 users, load average: 6.61, 18.50, 13.31
Tasks: 200 total, 18 running, 182 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 90.7%sy, 0.0%ni, 5.9%id, 3.3%wa, 0.0%hi, 0.0%si, 0.0%st

Mem:   8039576k total,  7998860k used,    40716k free,        8k buffers
Swap:        0k total,        0k used,        0k free,     1664k cached
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   248 root      11  -5     0    0    0 R   85  0.0   0:16.05 kswapd0
  2265 nut       18   0 13320  244    4 R   40  0.0   0:03.13 newhidups
  2267 nut       18   0 12216  168    4 R   40  0.0   0:02.04 upsd
  2474 ntp       18   0 22192  400    8 R   39  0.0   0:02.00 ntpd
  3563 jpiszcz   18   0 41964 1264    4 R   38  0.0   0:02.20 pine
  3530 root      18   0 96240 3132   36 R   37  0.0   0:02.09 kdm_greet
  2052 root      18   0  6080  112    4 R   37  0.0   0:02.00 hald-addon-stor
  4479 war       17   0 18012  700  252 R   33  0.0   0:01.81 top
  4480 war       19   0 6948m 6.8g    4 R   22 88.4   0:05.81 eatmem
  2095 root      18   0 13128  216    8 R   10  0.0   0:00.50 dirmngr
  2545 root      18   0 95788 2488    4 R    5  0.0   0:00.25 apache2
  3564 war       18   0 41620  832    4 R    5  0.0   0:00.34 pine
  2270 nut       15   0 12212  144    4 S    1  0.0   0:00.05 upsmon
   561 root      10  -5     0    0    0 S    0  0.0   0:00.02 xfsbufd

Very simply program:

#include <iostream>
using namespace std;

Quoted 8 lines

int main()

{
   long int interations = 10000000;
   int counter = 1;

   for(counter;counter<interations;counter++)
   {
      double *d = new double[100];

You usually have to access the allocated memory, like:

	*d = 1.0;

for it to actually be allocated (AFAIK).

Quoted 6 lines
   }
   return 0;
}

Any idea why the OOM killer can or does not kill it?

What are the values of /proc/sys/vm/overcommit* ?

See Documentation/vm/overcommit-accounting .

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

#22 lore raw
Quoted 16 lines · Randy Dunlap
Quoted 5 lines · On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:

Hm, not sure if it was from the patch or what but I ran this:

1. swapoff -a
2. ./eatmem

You usually have to access the allocated memory, like:

	*d = 1.0;

for it to actually be allocated (AFAIK).

Quoted 2 lines
   }
Quoted 8 lines
Quoted 4 lines
   return 0;
}

Any idea why the OOM killer can or does not kill it?

What are the values of /proc/sys/vm/overcommit* ?

See Documentation/vm/overcommit-accounting .

They should be the defaults as I do not change them:

p34:~# find /proc/|grep -i overcommit
/proc/sys/vm/overcommit_memory
/proc/sys/vm/overcommit_ratio
find: /proc/5128: No such file or directory
p34:~# cat /proc/sys/vm/overcommit_memory
0
p34:~# cat /proc/sys/vm/overcommit_ratio
50
p34:~#

Comments?

#23 lore raw
Quoted 37 lines · Justin Piszcz
Quoted 14 lines · Randy Dunlap
Quoted 4 lines · On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:

Hm, not sure if it was from the patch or what but I ran this:

1. swapoff -a
2. ./eatmem

You usually have to access the allocated memory, like:

	*d = 1.0;

for it to actually be allocated (AFAIK).

Quoted 2 lines
   }
Quoted 8 lines
Quoted 4 lines
   return 0;
}

Any idea why the OOM killer can or does not kill it?

What are the values of /proc/sys/vm/overcommit* ?

See Documentation/vm/overcommit-accounting .

They should be the defaults as I do not change them:

p34:~# find /proc/|grep -i overcommit
/proc/sys/vm/overcommit_memory
/proc/sys/vm/overcommit_ratio
find: /proc/5128: No such file or directory
p34:~# cat /proc/sys/vm/overcommit_memory
0
p34:~# cat /proc/sys/vm/overcommit_ratio
50
p34:~#
Quoted 1 line

Comments?

You can be sure your memory is available if reported in /proc/meminfo or at boot, since those represent the actual kernel data structures used for memory allocation:

[    0.000000] On node 0 totalpages: 2061783

That corresponds to 2061783*4k = 8445063168 bytes or ~8053M. Is that fairly close to what's actually installed in the machine?

Note that your boot also mentions this:

[  106.449661] mtrr: no more MTRRs available

which indicates that things like X may not be able to map the framebuffer with the 'write-combine' attribute, which will hurt performance. I've heard reports that turning of 'Intel QST fan control' in your BIOS settings will prevent all your MTRRs from being used (improperly, probably another BIOS bug) so that X will perform well. But if you don't use X on this machine, you don't have to worry about it. The other option would be to remap your MTRRs by hand to free one up for X, you can do that by combining the last one or two entries into a single MTRR using the API described in Documentation/mtrr.txt before you start X.

Jesse

#24 lore raw
Quoted 64 lines · Jesse Barnes
Quoted 37 lines · Justin Piszcz
Quoted 14 lines · Randy Dunlap
Quoted 4 lines · On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:

Hm, not sure if it was from the patch or what but I ran this:

1. swapoff -a
2. ./eatmem

You usually have to access the allocated memory, like:

	*d = 1.0;

for it to actually be allocated (AFAIK).

Quoted 2 lines
   }
Quoted 8 lines
Quoted 4 lines
   return 0;
}

Any idea why the OOM killer can or does not kill it?

What are the values of /proc/sys/vm/overcommit* ?

See Documentation/vm/overcommit-accounting .

They should be the defaults as I do not change them:

p34:~# find /proc/|grep -i overcommit
/proc/sys/vm/overcommit_memory
/proc/sys/vm/overcommit_ratio
find: /proc/5128: No such file or directory
p34:~# cat /proc/sys/vm/overcommit_memory
0
p34:~# cat /proc/sys/vm/overcommit_ratio
50
p34:~#
Quoted 1 line

Comments?

You can be sure your memory is available if reported in /proc/meminfo or at boot, since those represent the actual kernel data structures used for memory allocation:

[    0.000000] On node 0 totalpages: 2061783

That corresponds to 2061783*4k = 8445063168 bytes or ~8053M. Is that fairly close to what's actually installed in the machine?

Note that your boot also mentions this:

[  106.449661] mtrr: no more MTRRs available

which indicates that things like X may not be able to map the framebuffer with the 'write-combine' attribute, which will hurt performance. I've heard reports that turning of 'Intel QST fan control' in your BIOS settings will prevent all your MTRRs from being used (improperly, probably another BIOS bug) so that X will perform well. But if you don't use X on this machine, you don't have to worry about it. The other option would be to remap your MTRRs by hand to free one up for X, you can do that by combining the last one or two entries into a single MTRR using the API described in Documentation/mtrr.txt before you start X.

Quoted 2 lines

Jesse

FYI--

[  106.449661] mtrr: no more MTRRs available

This has always occurred, even with mem=8832M setting.

Justin.

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

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

It's called "kernel log buffer size" and it's in "General setup".

Jesse

Did the dmesg output get you what you needed? Why the few KB difference? :)

Justin.

#26 lore raw
Quoted 6 lines · Justin Piszcz
Quoted 5 lines · Jesse Barnes
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

Quoted 8 lines
Quoted 3 lines

It's called "kernel log buffer size" and it's in "General setup".

Jesse

Did the dmesg output get you what you needed? Why the few KB difference?

:)

Yeah, looked at your e820 and your MTRR settings and I think my patch is doing the right thing (i.e. trimming just the right amount of memory, leaving you with as much as possible).

The mem= approach though looks slightly off, but I haven't looked at x86_64's mem= handling to see why. From a high level though, adjusting end_pfn is the right thing to do, since theoretically mem= could choose to make holes in your low memory and keep your high memory in the allocation pools (though it's not generally implemented this way).

Jesse

#27 lore raw
Quoted 20 lines · Jesse Barnes
Quoted 6 lines · Justin Piszcz
Quoted 5 lines · Jesse Barnes
Quoted 3 lines · Justin Piszcz

Nope, I booted with only netconsole= options. I have a lot of HW in the box and I guess the buffer is too small. Not sure where to change it in the kernel. Looking..

Quoted 8 lines
Quoted 3 lines

It's called "kernel log buffer size" and it's in "General setup".

Jesse

Did the dmesg output get you what you needed? Why the few KB difference?

:)

Yeah, looked at your e820 and your MTRR settings and I think my patch is doing the right thing (i.e. trimming just the right amount of memory, leaving you with as much as possible).

Quoted 8 lines

The mem= approach though looks slightly off, but I haven't looked at x86_64's mem= handling to see why. From a high level though, adjusting end_pfn is the right thing to do, since theoretically mem= could choose to make holes in your low memory and keep your high memory in the allocation pools (though it's not generally implemented this way).

Jesse

Ahh, ok! Sounds great, I will keep running the kernel with your patch without mem= and let you know if I see any issues.

Chances of getting this into 2.6.22-rc5?

Justin.

#28 lore raw
Quoted 7 lines · Justin Piszcz
Quoted 7 lines

The mem= approach though looks slightly off, but I haven't looked at x86_64's mem= handling to see why. From a high level though, adjusting end_pfn is the right thing to do, since theoretically mem= could choose to make holes in your low memory and keep your high memory in the allocation pools (though it's not generally implemented this way).

Quoted 6 lines
Quoted 1 line

Jesse

Ahh, ok! Sounds great, I will keep running the kernel with your patch without mem= and let you know if I see any issues.

Chances of getting this into 2.6.22-rc5?

I'm not sure it's appropriate for -rc5 since it mucks around with some early boot ordering, but I'll leave that to Andi, since it does address some real bugs people have been seeing.

Can we add your "Tested-by: Justin Piszcz <[email protected]>" to the patch? :)

Thanks,
Jesse

#29 lore raw
Quoted 10 lines · Jesse Barnes
Quoted 9 lines · Justin Piszcz
Quoted 8 lines

The mem= approach though looks slightly off, but I haven't looked at x86_64's mem= handling to see why. From a high level though, adjusting end_pfn is the right thing to do, since theoretically mem= could choose to make holes in your low memory and keep your high memory in the allocation pools (though it's not generally implemented this way).

Jesse

Quoted 8 lines
Quoted 4 lines

Ahh, ok! Sounds great, I will keep running the kernel with your patch without mem= and let you know if I see any issues.

Chances of getting this into 2.6.22-rc5?

I'm not sure it's appropriate for -rc5 since it mucks around with some early boot ordering, but I'll leave that to Andi, since it does address some real bugs people have been seeing.

I don't think the patch is suitable for merging at this time. Perhaps if it survives some time in -mm* / 2.6.23* it could be backported in a later 2.6.22 stable release. But right now it definitely needs more testing and addressing of my review comments.

Quoted 2 lines

Can we add your "Tested-by: Justin Piszcz <[email protected]>" to the patch? :)

All such headers are only for the trail of blame and do you want to blame Justin if anything goes wrong? Perhaps it should rather have a
Blame-to: <whoever wrote Justin/Jesse's BIOS> but that also wouldn't help without concrete contact points.

-ANdi

#30 lore raw
Quoted 28 lines · Andi Kleen
Quoted 10 lines · Jesse Barnes
Quoted 9 lines · Justin Piszcz
Quoted 8 lines

The mem= approach though looks slightly off, but I haven't looked at x86_64's mem= handling to see why. From a high level though, adjusting end_pfn is the right thing to do, since theoretically mem= could choose to make holes in your low memory and keep your high memory in the allocation pools (though it's not generally implemented this way).

Jesse

Quoted 8 lines
Quoted 4 lines

Ahh, ok! Sounds great, I will keep running the kernel with your patch without mem= and let you know if I see any issues.

Chances of getting this into 2.6.22-rc5?

I'm not sure it's appropriate for -rc5 since it mucks around with some early boot ordering, but I'll leave that to Andi, since it does address some real bugs people have been seeing.

I don't think the patch is suitable for merging at this time. Perhaps if it survives some time in -mm* / 2.6.23* it could be backported in a later 2.6.22 stable release. But right now it definitely needs more testing and addressing of my review comments.

Quoted 2 lines

Can we add your "Tested-by: Justin Piszcz <[email protected]>" to the patch? :)

Quoted 7 lines

All such headers are only for the trail of blame and do you want to blame Justin if anything goes wrong? Perhaps it should rather have a
Blame-to: <whoever wrote Justin/Jesse's BIOS> but that also wouldn't help without concrete contact points.

-ANdi

Hah! Again, I'll keep runnihg with Jesse's patch and as long as I can keep patching newer kernels I can continue to run with it. So far, overnight with backups and the like, I have not noticed any problems. Also tested logging in to X/KDE, no issues. [yet]

Justin.

#31 lore raw
In reply to Andi Kleen
Quoted 10 lines · Andi Kleen
Quoted 4 lines · Jesse Barnes

[...]
I'm not sure it's appropriate for -rc5 since it mucks around with some early boot ordering, but I'll leave that to Andi, since it does address some real bugs people have been seeing.

I don't think the patch is suitable for merging at this time. Perhaps if it survives some time in -mm* / 2.6.23* it could be backported in a later 2.6.22 stable release. But right now it definitely needs more testing and addressing of my review comments.

BTW an unrelated/happy side-effect of the patch is that it removes the zero-size-guilty kmalloc()'s from the mtrr code. -mm does have some fixes that prevent those zero-size allocations, which could likely be retired if this gets merged in? ...

[ On another unrelated note, could someone tell me who maintains i386? I've looked around, but surprisingly can't seem to find anybody listed anywhere. ]

Satyam

#32 lore raw
In reply to Andi Kleen
Quoted 25 lines · Andi Kleen
Quoted 10 lines · Jesse Barnes
Quoted 9 lines · Justin Piszcz
Quoted 8 lines

The mem= approach though looks slightly off, but I haven't looked at x86_64's mem= handling to see why. From a high level though, adjusting end_pfn is the right thing to do, since theoretically mem= could choose to make holes in your low memory and keep your high memory in the allocation pools (though it's not generally implemented this way).

Jesse

Quoted 8 lines
Quoted 4 lines

Ahh, ok! Sounds great, I will keep running the kernel with your patch without mem= and let you know if I see any issues.

Chances of getting this into 2.6.22-rc5?

I'm not sure it's appropriate for -rc5 since it mucks around with some early boot ordering, but I'll leave that to Andi, since it does address some real bugs people have been seeing.

I don't think the patch is suitable for merging at this time. Perhaps if it survives some time in -mm* / 2.6.23* it could be backported in a later 2.6.22 stable release. But right now it definitely needs more testing and addressing of my review comments.

Quoted 7 lines
Quoted 2 lines

Can we add your "Tested-by: Justin Piszcz
<[email protected]>" to the patch? :)

All such headers are only for the trail of blame and do you want to blame Justin if anything goes wrong? Perhaps it should rather have a
Blame-to: <whoever wrote Justin/Jesse's BIOS> but that also wouldn't help without concrete contact points.

I think that header would be Lame-workaround-needed-because-of:
<[email protected]>. :) The idea of tested-by is to give people a clue about who would be able to test any changes in the area affected. So far from blaming Justin, it would give him credit for all his testing, and let people know that he might be able to test similar patches in the future. I think it's worthwhile to track that...

Jesse

#33 lore raw
In reply to Jesse Barnes
Quoted 14 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.

Quoted 8 lines

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.

Justin, can you please test and make sure this patch works for you too? It'll only work around the problem, but it's better than having to do mem= by hand or waiting for a fix from your BIOS vendor.

Ok. Overall this feels good but a few nits below. Would it make sense to split this into two patches. The first to just do the cleanup that removes the allocations for holding the mttr ranges?

Quoted 11 lines

Thanks,
Jesse

arch/i386/kernel/cpu/mtrr/generic.c +0 -0
index c4ebb51..71fc768 100644

arch/i386/kernel/cpu/mtrr/generic.c line 17

Quoted 6 lines
arch/i386/kernel/cpu/mtrr/generic.c +1 -1
@@ -13,7 +13,7 @@
 #include "mtrr.h"
 
 
 struct mtrr_state {
-	struct mtrr_var_range *var_ranges;
+	struct mtrr_var_range var_ranges[NUM_VAR_RANGES];

Could we name it MAX_VAR_RANGES and not NUM_VAR_RANGES. In practices this is going to be 8 for every cpu I know of, so calling this NUM_VAR_RANGES may be a little confusing.

Quoted 22 lines
arch/i386/kernel/cpu/mtrr/generic.c +0 -0
 	mtrr_type fixed_ranges[NUM_FIXED_RANGES];
 	unsigned char enabled;
arch/i386/kernel/cpu/mtrr/generic.c +0 -6
 	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;
 
arch/i386/kernel/cpu/mtrr/generic.c +0 -0
 	rdmsr(MTRRcap_MSR, lo, dummy);
arch/i386/kernel/cpu/mtrr/if.c +0 -0
index c7d8f17..d7922ce 100644

arch/i386/kernel/cpu/mtrr/if.c line 15

Quoted 5 lines
arch/i386/kernel/cpu/mtrr/if.c +1 -1
@@ -12,7 +12,7 @@
 #include "mtrr.h"
 
 /* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
+extern unsigned int usage_table[];

I think that should be:

arch/i386/kernel/cpu/mtrr/if.c line 16

Quoted 1 line
arch/i386/kernel/cpu/mtrr/if.c +1 -0
+extern unsigned int usage_table[NUM_VAR_RANGES];

Or even better yet the declaration moved to a header file.

Quoted 16 lines
arch/i386/kernel/cpu/mtrr/if.c +15 -0
+/**
+ * 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;
+	mtrr_type type;
+

arch/i386/kernel/cpu/mtrr/if.c

Quoted 10 lines
arch/i386/kernel/cpu/mtrr/if.c +10 -0
+	/* 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;
+	}

This looks like it will handle the common case, so I have no major objections to this code.

At least in theory and possibly in practice there are a couple of corner cases we have missed her.

- Overlapping MTRRs.
- What happens if we have uncached memory lower down?
Except for performance problems I guess that case is relatively harmless.
- Is it possible and worth it to amend the e820 map, so it shows the problem area as Reserved or otherwise not usable RAM?

Quoted 19 lines
arch/i386/kernel/cpu/mtrr/if.c +11 -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;
+	}
+}
 
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
arch/i386/kernel/cpu/mtrr/mtrr.h +0 -0
index 289dfe6..a29dcba 100644

arch/i386/kernel/cpu/mtrr/mtrr.h line 17

Quoted 4 lines
arch/i386/kernel/cpu/mtrr/mtrr.h +1 -0
@@ -14,6 +14,7 @@
 #define MTRRphysMask_MSR(reg) (0x200 + 2 * (reg) + 1)
 
 #define NUM_FIXED_RANGES 88
+#define NUM_VAR_RANGES 256

MAX_VAR_RANGES?

arch/i386/kernel/cpu/mtrr/mtrr.h line 20

Quoted 3 lines
arch/i386/kernel/cpu/mtrr/mtrr.h +0 -0
 #define MTRRfix64K_00000_MSR 0x250
 #define MTRRfix16K_80000_MSR 0x258
 #define MTRRfix16K_A0000_MSR 0x259

Eric

#34 lore raw
Quoted 4 lines · Eric W. Biederman

Ok. Overall this feels good but a few nits below. Would it make sense to split this into two patches. The first to just do the cleanup that removes the allocations for holding the mttr ranges?

I suppose we could split it, but it's small, and the only reason for removing the allocations was so that we could init it earlier.

Quoted 7 lines

arch/i386/kernel/cpu/mtrr/generic.c line 16

Quoted 3 lines

struct mtrr_state {

arch/i386/kernel/cpu/mtrr/generic.c +1 -1
-	struct mtrr_var_range *var_ranges;
+	struct mtrr_var_range var_ranges[NUM_VAR_RANGES];

Could we name it MAX_VAR_RANGES and not NUM_VAR_RANGES. In practices this is going to be 8 for every cpu I know of, so calling this NUM_VAR_RANGES may be a little confusing.

You're right, I should have kept the old name with MAX_ in it. I'll fix it up.

Quoted 8 lines

arch/i386/kernel/cpu/mtrr/if.c line 15

Quoted 3 lines

/* RED-PEN: this is accessed without any locking */

arch/i386/kernel/cpu/mtrr/if.c +1 -1
-extern unsigned int *usage_table;
+extern unsigned int usage_table[];

I think that should be:

Quoted 1 line

+extern unsigned int usage_table[NUM_VAR_RANGES];

Or even better yet the declaration moved to a header file.

Oops, yeah, this should just be in mtrr.h.

Quoted 7 lines

This looks like it will handle the common case, so I have no major objections to this code.

At least in theory and possibly in practice there are a couple of corner cases we have missed her.

- Overlapping MTRRs.

Overlapping should be ok, since that's usually intentional (e.g. one big wb range with a portion of uc space due to another mtrr).

Quoted 1 line

- What happens if we have uncached memory lower down?

Holes definitely aren't dealt with, but then we haven't seen any yet...

Quoted 3 lines

Except for performance problems I guess that case is relatively
harmless. - Is it possible and worth it to amend the e820 map, so it shows the problem area as Reserved or otherwise not usable RAM?

That would be useful, but only if we moved the check to a little earlier, prior to the addition of the active ranges from the e820. Might be a little nicer than adjusting end_pfn, but will ultimately achieve the same thing...

Jesse

#35 lore raw
Quoted 4 lines · Jesse Barnes
Quoted 1 line

- Overlapping MTRRs.

Overlapping should be ok, since that's usually intentional (e.g. one big wb range with a portion of uc space due to another mtrr).

I'm not say overlapping was a bug. I was saying that you don't handle overlapping mtrrs in figuring the last cached addresses. Therefore when a UC range overlaps a WB range we might thing the last page in the WB range is cached when it is not.

Quoted 4 lines
Quoted 1 line

- What happens if we have uncached memory lower down?

Holes definitely aren't dealt with, but then we haven't seen any yet...

Quoted 8 lines
Quoted 3 lines

Except for performance problems I guess that case is relatively
harmless. - Is it possible and worth it to amend the e820 map, so it shows the problem area as Reserved or otherwise not usable RAM?

That would be useful, but only if we moved the check to a little earlier, prior to the addition of the active ranges from the e820. Might be a little nicer than adjusting end_pfn, but will ultimately achieve the same thing...

Yes, with perhaps a little more consistency.

Eric

#36 lore raw
Quoted 10 lines · On Friday, June 8, 2007 4:13:22 Eric W. Biederman wrote:
Quoted 4 lines · Jesse Barnes
Quoted 1 line

- Overlapping MTRRs.

Overlapping should be ok, since that's usually intentional (e.g. one big wb range with a portion of uc space due to another mtrr).

I'm not say overlapping was a bug. I was saying that you don't handle overlapping mtrrs in figuring the last cached addresses. Therefore when a UC range overlaps a WB range we might thing the last page in the WB range is cached when it is not.

Oh right, that might be an issue, but we haven't seen it yet...

Jesse

#37 lore raw
In reply to Jesse Barnes
Quoted 6 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).

In theory -- while not recommended -- a BIOS could also
use a default fallback MTRR for cached and use explicit MTRRs to map the non existing ranges uncached. Would it make sense to handle this case?

Right now if someone used a default WC MTRR to make the memory cached you would clip all memory.

Perhaps a fail safe would be good -- always leave some memory left over even if it looks wrong.

Should also probably have some command line option to disable the check in case something bad happens with it.

Another thing that might be sense to investigate in relationship to this patch is large page mappings with MTRRs. iirc P4 and also K8 splits pages internally with MTRR boundaries and might have some other bad side effects. Should we use this as hints to use 4K pages for the boundary areas?

-Andi

#38 lore raw
Quoted 8 lines · Andi Kleen
Quoted 6 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).

Quoted 4 lines

In theory -- while not recommended -- a BIOS could also use a default fallback MTRR for cached and use explicit MTRRs to map the non existing ranges uncached. Would it make sense to handle this case?

Probably. I could just check the default memory type and bail out if it's cacheable.

Quoted 2 lines

Should also probably have some command line option to disable the check in case something bad happens with it.

Sure.

Quoted 5 lines

Another thing that might be sense to investigate in relationship to this patch is large page mappings with MTRRs. iirc P4 and also K8 splits pages internally with MTRR boundaries and might have some other bad side effects. Should we use this as hints to use 4K pages for the boundary areas?

Or I could trim to the nearest large page boundary... We'd lose a little more memory but it would keep things simple.

Jesse

#39 lore raw
Quoted 28 lines · Jesse Barnes
Quoted 8 lines · Andi Kleen
Quoted 6 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).

Quoted 4 lines

In theory -- while not recommended -- a BIOS could also use a default fallback MTRR for cached and use explicit MTRRs to map the non existing ranges uncached. Would it make sense to handle this case?

Probably. I could just check the default memory type and bail out if it's cacheable.

Quoted 2 lines

Should also probably have some command line option to disable the check in case something bad happens with it.

Sure.

Quoted 5 lines

Another thing that might be sense to investigate in relationship to this patch is large page mappings with MTRRs. iirc P4 and also K8 splits pages internally with MTRR boundaries and might have some other bad side effects. Should we use this as hints to use 4K pages for the boundary areas?

Quoted 5 lines

Or I could trim to the nearest large page boundary... We'd lose a little more memory but it would keep things simple.

Jesse

How much more memory are we going to lose? Is mem= a better option if its going to keep decreasing?

#40 lore raw
In reply to Jesse Barnes
Quoted 13 lines · On Wed, 6 Jun 2007 12:29:23 -0700 Jesse Barnes <[email protected]> wrote:
arch/i386/kernel/cpu/mtrr/if.c +1 -1
@@ -12,7 +12,7 @@
 #include "mtrr.h"
 
 /* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
+extern unsigned int usage_table[];
 
 

arch/i386/kernel/cpu/mtrr/main.c line 51

Quoted 6 lines
arch/i386/kernel/cpu/mtrr/main.c +1 -1
@@ -47,7 +47,7 @@
 
 u32 num_var_ranges = 0;
 
-unsigned int *usage_table;
+unsigned int usage_table[NUM_VAR_RANGES];
 static DEFINE_MUTEX(mtrr_mutex);

didn't it feel all dirty when you had to do that?

From: Andrew Morton <[email protected]>

- Move the declaration into a header file

- "usage_table" is a dumb name for an mtrr-specific kernel-wide identifier.

There appear to beseveral other poorly-chosen identifiers in mtrr.

Cc Andi Kleen <[email protected]>
Cc Jesse Barnes <[email protected]>

---

 arch/i386/kernel/cpu/mtrr/if.c   |    8 ++------
 arch/i386/kernel/cpu/mtrr/main.c |   17 +++++++++--------
 arch/i386/kernel/cpu/mtrr/mtrr.h |    2 ++
 3 files changed, 13 insertions(+), 14 deletions(-)
arch/i386/kernel/cpu/mtrr/if.c renamed from arch/i386/kernel/cpu/mtrr/if.c~i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix +2 -6
diff -puN arch/i386/kernel/cpu/mtrr/if.c~i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix arch/i386/kernel/cpu/mtrr/if.c
@@ -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] =
@@ -396,7 +392,7 @@ static int mtrr_seq_show(struct seq_file
 	for (i = 0; i < max; i++) {
 		mtrr_if->get(i, &base, &size, &type);
 		if (size == 0)
-			usage_table[i] = 0;
+			mtrr_usage_table[i] = 0;
 		else {
 			if (size < (0x100000 >> PAGE_SHIFT)) {
 				/* less than 1MB */
@@ -410,7 +406,7 @@ static int mtrr_seq_show(struct seq_file
 			len += seq_printf(seq, 
 				   "reg%02i: base=0x%05lx000 (%4luMB), size=%4lu%cB: %s, count=%d\n",
 			     i, base, base >> (20 - PAGE_SHIFT), size, factor,
-			     mtrr_attrib_to_str(type), usage_table[i]);
+			     mtrr_attrib_to_str(type), mtrr_usage_table[i]);
 		}
 	}
 	return 0;
arch/i386/kernel/cpu/mtrr/main.c renamed from arch/i386/kernel/cpu/mtrr/main.c~i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix +9 -8
diff -puN arch/i386/kernel/cpu/mtrr/main.c~i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix arch/i386/kernel/cpu/mtrr/main.c
@@ -47,7 +47,7 @@
 
 u32 num_var_ranges = 0;
 
-unsigned int usage_table[NUM_VAR_RANGES];
+unsigned int mtrr_usage_table[NUM_VAR_RANGES];
 static DEFINE_MUTEX(mtrr_mutex);
 
 u64 size_or_mask, size_and_mask;
@@ -127,7 +127,7 @@ static void __init init_table(void)
 
 	max = num_var_ranges;
 	for (i = 0; i < max; i++)
-		usage_table[i] = 1;
+		mtrr_usage_table[i] = 1;
 }
 
 struct set_mtrr_data {
@@ -381,7 +381,7 @@ int mtrr_add_page(unsigned long base, un
 			goto out;
 		}
 		if (increment)
-			++usage_table[i];
+			++mtrr_usage_table[i];
 		error = i;
 		goto out;
 	}
@@ -390,12 +390,13 @@ int mtrr_add_page(unsigned long base, un
 	if (i >= 0) {
 		set_mtrr(i, base, size, type);
 		if (likely(replace < 0))
-			usage_table[i] = 1;
+			mtrr_usage_table[i] = 1;
 		else {
-			usage_table[i] = usage_table[replace] + !!increment;
+			mtrr_usage_table[i] = mtrr_usage_table[replace] +
+						!!increment;
 			if (unlikely(replace != i)) {
 				set_mtrr(replace, 0, 0, 0);
-				usage_table[replace] = 0;
+				mtrr_usage_table[replace] = 0;
 			}
 		}
 	} else
@@ -525,11 +526,11 @@ int mtrr_del_page(int reg, unsigned long
 		printk(KERN_WARNING "mtrr: MTRR %d not used\n", reg);
 		goto out;
 	}
-	if (usage_table[reg] < 1) {
+	if (mtrr_usage_table[reg] < 1) {
 		printk(KERN_WARNING "mtrr: reg: %d has count=0\n", reg);
 		goto out;
 	}
-	if (--usage_table[reg] < 1)
+	if (--mtrr_usage_table[reg] < 1)
 		set_mtrr(reg, 0, 0, 0);
 	error = reg;
  out:
arch/i386/kernel/cpu/mtrr/mtrr.h renamed from arch/i386/kernel/cpu/mtrr/mtrr.h~i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix +2 -0
diff -puN arch/i386/kernel/cpu/mtrr/mtrr.h~i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix arch/i386/kernel/cpu/mtrr/mtrr.h
@@ -97,3 +97,5 @@ void mtrr_state_warn(void);
 const char *mtrr_attrib_to_str(int x);
 void mtrr_wrmsr(unsigned, unsigned, unsigned);
 
+/* RED-PEN: this is accessed without any locking */
+extern unsigned int mtrr_usage_table[];

_

#41 lore raw
Quoted 5 lines · On Thursday, June 7, 2007 5:20:50 Andrew Morton wrote:

Review

Quoted 3 lines
(quoted diff) +1 -1
-unsigned int *usage_table;
+unsigned int usage_table[NUM_VAR_RANGES];
 static DEFINE_MUTEX(mtrr_mutex);

didn't it feel all dirty when you had to do that?

Hey, this was already there... I didn't want to rewrite the whole thing at once. :) Patch looks fine though.

Thanks,
Jesse

#42 lore raw
In reply to Jesse Barnes

Hi!

Quoted 6 lines

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.

Way too obnoxious warning, I'd say. Just drop the *s.

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

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;

...and I'd print lost memory in kilobytes, to be more luser-friendly.

Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#43 lore raw
In reply to Jesse Barnes
Quoted 14 lines · On Wed, 6 Jun 2007 12:29:23 -0700 Jesse Barnes <[email protected]> wrote:

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.

Quoted 3 lines

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.

i386 allmodconfig:

arch/i386/kernel/cpu/mtrr/main.c: In function 'mtrr_trim_uncached_memory':
arch/i386/kernel/cpu/mtrr/main.c:655: error: 'end_pfn' undeclared (first use in this function) arch/i386/kernel/cpu/mtrr/main.c:655: error: (Each undeclared identifier is reported only once arch/i386/kernel/cpu/mtrr/main.c:655: error: for each function it appears in.)

I'll poke some ifdefs in there.

#44 lore raw
Quoted 14 lines · On Friday, June 8, 2007 2:15:00 Andrew Morton wrote:
Quoted 3 lines

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.

i386 allmodconfig:

arch/i386/kernel/cpu/mtrr/main.c: In function 'mtrr_trim_uncached_memory': arch/i386/kernel/cpu/mtrr/main.c:655:
error: 'end_pfn' undeclared (first use in this function) arch/i386/kernel/cpu/mtrr/main.c:655: error: (Each undeclared identifier is reported only once arch/i386/kernel/cpu/mtrr/main.c:655: error: for each function it appears in.)

Quoted 1 line

I'll poke some ifdefs in there.

Oops, sorry about that, the code is only called on x86_64 but compiled even for i386...

Jesse

#45 lore raw
In reply to Jesse Barnes
Quoted 7 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).

Quoted 6 lines

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.

A quick update. This patch is horribly incorrect on a socket F opteron/Athlon 64 with memory above 4GB.

In particular those cpus are capable of mapping all of memory above 4GB as write back without using a single MTRR.

So examining MTRRs is insufficient.

Eric

#46 lore raw
Quoted 15 lines · On Tuesday, June 12, 2007 6:11:21 Eric W. Biederman wrote:
Quoted 7 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).

Quoted 6 lines

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.

Quoted 7 lines

A quick update. This patch is horribly incorrect on a socket F opteron/Athlon 64 with memory above 4GB.

In particular those cpus are capable of mapping all of memory above 4GB as write back without using a single MTRR.

So examining MTRRs is insufficient.

Hm, yuck. What do you suggest? Should we only run this check when Intel chips are present? Checking only the bottom 4G isn't sufficient since we've seen platforms that have issues above that range...

Thanks,
Jesse

#47 lore raw
Quoted 19 lines · Jesse Barnes
Quoted 18 lines · On Tuesday, June 12, 2007 6:11:21 Eric W. Biederman wrote:
Quoted 7 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).

Quoted 6 lines

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.

A quick update. This patch is horribly incorrect on a socket F opteron/Athlon 64 with memory above 4GB.

Quoted 8 lines
Quoted 4 lines

In particular those cpus are capable of mapping all of memory above 4GB as write back without using a single MTRR.

So examining MTRRs is insufficient.

Hm, yuck. What do you suggest? Should we only run this check when Intel chips are present? Checking only the bottom 4G isn't sufficient since we've seen platforms that have issues above that range...

My gut feel says that we need to call a function that is potentially cpu specific, older AMD cpus and Intel cpus can just use the generic mtrr code.

I would also suggest we build a list of ranges of write-back memory. Which until we handle overlapping MTRRs in the generic MTRR case is just the write-back MTRRs.

Then we get the data in a linux specific form we can check the linux specific data structure against the e820 map.

I don't think that is going to much harder and it allows for creative cpu designers.

Although this suggests that we want to worry about all memory holes as well. Because I have seen at least one system which failed to cover the lower 4G with MTRRs. While everything above 4G was fine.

Eric

#48 lore raw
In reply to Jesse Barnes
Quoted 7 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).

Quoted 7 lines

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.

I assume this cannot be fixed by the simple approach of echoing some useful numbers into /proc/mtrr like we used to do for video memory? (Before X did this automatically?)

An extra bootscript seems better than loosing memory.

Helge Hafting

#49 lore raw
Quoted 6 lines

I assume this cannot be fixed by the simple approach of echoing some useful numbers into /proc/mtrr like we used to do for video memory? (Before X did this automatically?)

An extra bootscript seems better than loosing memory.

In some cases it probably can, in other cases not because the memory controller is misconfigured or not the right bits are set in the PCI bridges to enable DAC IO or ... or ...

There are also definite limits on how much quirks can do to fix this -- Linux is a generic kernel, not a BIOS replacement, and can never be as intimate with the current setup
as the BIOS is.

It's definitely far safer to not use the memory. You're running in a situation never tested or considered by the motherboard vendor and everything is possible.

-Andi